apt-get install debian-wizard

Insider infos, master your Debian/Ubuntu distribution

  • About
    • About this blog
    • About me
    • My free software history
  • Support my work
  • Get the newsletter
  • More stuff
    • Support Debian Contributors
    • Other sites
      • My company
      • French Blog about Free Software
      • Personal Website (French)
  • Mastering Debian
  • Contributing 101
  • Packaging Tutorials

Debian’s General Resolution on AI and LLM

August 26, 2026 by Raphaël Hertzog Leave a Comment

As a Debian developer, I have had to cast a vote for the General Resolution named LLM usage in Debian (progress report here). This was not an easy task for me…

It’s a good thing that the vote is secret so that people are not scared of voting according to their own beliefs. I have Debian friends on the whole spectrum of opinions that are represented here, and I hesitated twice on sharing my own thoughts for fear of alienating my relationship with them. But in the end, we all make efforts to respect the opinions of those who are not thinking like us, and it’s precisely that willingness to work together towards a solution that is acceptable by the majority that makes Debian so strong. So here’s the train of thoughts that I followed to cast my vote.

The difficulty for me was to reconcile the political statement that I want to make and my desire for this vote to not be (too) divisive for the Debian community, and to make sure we are not putting off newcomers with choices that might be hard to stand by in the long term.

So let’s be clear : if I had a magical wand to make AI and LLM disappear, I would use it for that purpose, since at this point in time I don’t believe that the benefits outweigh the costs that the AI race is inflicting on us. If I were a political decision-maker, I would forbid the construction of new data centers unless they also build renewable energy infrastructure to cover for their additional energy consumption. I would also legislate so that AI companies have to document what material they used to train their models, and I would forbid scraping for that purpose, and build ways for those companies to buy copies of properly-sourced training data. That is to say, I don’t like the way LLM are built by the players in that market, I’m pretty scared of the ecological impact of what those players are doing, and I’m certainly worried about the long term effect that LLM will have on society as a whole.

Nevertheless what brought me to Debian is the ability to experiment and contribute to something useful with cool technologies, and as a computer scientist, the potential of LLM done right is hard to ignore. Given what we have seen already, I expect that LLM will empower (a part of) the next generation to learn IT, computing and even Debian packaging. Completely refusing the use of LLM is likely to make it harder for us to attract new contributors. In fact, we have already seen people inside Debian that would likely stop contributing if they are now forbidden to use LLM. I know there are likely others that will quit Debian if we accept it too, but I hope we can find a middle-ground where such persons can decide that LLM are not welcome in the small corner of Debian that they are in charge of…

In the end, I decided that answering clearly the question “Shall we accept LLM contributions ?” was more important than making the political statement about the current state of affairs in the AI landscape, both because I believe that Debian statements have a negligible impact on policy-makers, and because historically Debian has grown by staying close to technical excellence and relatively far from politics, except when it comes to the way we handle people. And as much as I care about climate change, I don’t see how bringing this up in the context of a Debian statement is helping its cause.

More concretely, it gives the following ranking (in decreasing order of importance):

  • B, D: those two choices are the clearest to express “Yes we should accept LLM contributions” and still acknowledge concerns about the way AI is built today
  • F, H: those two choices do not forbid LLM usage but discourage their use and clearly voice the concerns
  • E: this choice is basically the statu-quo and fails to acknowledge the concerns, but it does not forbid LLM usage
  • None of the above
  • G, A, C: those choices forbid LLM usage in various ways

I don’t know what option will win, but assuming that LLM-assisted contributions are allowed, I believe that it would be helpful to have further statements to clarify a few things:

  • Even if Debian as a whole doesn’t want to ban LLM-assisted contributions, each maintainer or each team shall be free to forbid LLM assisted contributions in the parts of Debian that they are maintaining
  • We should discourage usage of LLM provided by players with unethical behaviors (not sure if there are good players but well…)

How to choose your SSH agent with Wayland and systemd

November 10, 2025 by Raphaël Hertzog

If you read the above title, you might wonder how the switch to wayland (yes, the graphical stack replacing the venerable X11) can possibly relate to SSH agents. The answer is easy.

For as long as I can remember, as a long time user of gpg-agent as SSH agent (because my SSH key is a GPG sub-key) I relied on /etc/X11/Xsession.d/90gpg-agent that would configure the SSH_AUTH_SOCK environment variable (pointing to gpg-agent’s socket) provided that I added enable-ssh-support in ~/.gnupg/gpg-agent.conf.

Now when I switched to Wayland, that shell script used in the startup sequence of Xorg was no longer used. During a while I cheated a bit by setting SSH_AUTH_SOCK directly in my ~/.bashrc. But that only works for terminals, and not for other applications that are started by the session manager (which is basically systemd --user).

So how is that supposed to work out of the box nowadays? The SSH agents (as packaged in Debian) have all adopted the same trick, their .socket unit have an ExecStartPost setting which runs systemctl --user set-environment SSH_AUTH_SOCK=some-value. This command dynamically modifies the environment of the running systemd daemon and thus influences the environment for the future units started. Putting this in a socket unit ensures an early run, before most of the applications are started so it’s a good choice. They tend to also explicitly ensure this with a directive like Before=graphical-session-pre.target.

However, in a typical installation you end up with multiple SSH agents (right now I have ssh-agent, gpg-agent, and gcr-ssh-agent), which one is the one that the user ends up using? Well, that is not clearly defined, the one that wins is the one that runs last… because each of them overwrites the value in the systemd environment.

Some of them fight to have that place (cf #1079246 for gcr-ssh-agent) by setting explicit After directives. In the above bug I argue that we should let gpg-agent.socket have the priority since that’s the only one that is not enabled by default and that requires the user to opt-in. However, ultimately there will always be cases where you will want to be explicit about the SSH agent that should win.

You could rely on systemd overrides to add/remove ordering directives but that’s pretty fragile. Instead the right way to deal with this is to “mask” the socket units of the SSH agents that you don’t want. Note that disabling (i.e. systemctl --user disable) either will not work[1] or will not be sufficient[2]. In my case, I wanted to keep gpg-agent.socket so I masked gcr-ssh-agent.socket and ssh-agent.socket:

$ systemctl --user mask ssh-agent.socket gcr-ssh-agent.socket
Created symlink '/home/rhertzog/.config/systemd/user/ssh-agent.socket' → '/dev/null'.
Created symlink '/home/rhertzog/.config/systemd/user/gcr-ssh-agent.socket' → '/dev/null'.

Note that if you want that behaviour to apply to all users of your computer, you can use sudo systemctl --global mask ssh-agent.socket gcr-ssh-agent.socket. Now on next login, you will only get a single ssh agent socket unit that runs and the SSH_AUTH_SOCK value will thus be predictable again!

Hopefully you will find that useful as it’s already the second time that I stumble upon this either for me or for a relative. Next time, I will know where to look it up. 🙂

[1]: If you try to run systemctl --user disable gcr-ssh-agent.socket, you will get a message saying that it will not work because the unit is enabled for all users at the “global” level. You can do it with --global instead of --user but it doesn’t help, cf below.

[2]: Disabling an unit basically means stopping to explicitely schedule its startup as part of a desired target. However, the unit can still be started as a dependency of other units and that’s the case here because a socket unit will typically be pulled in by its corresponding service unit.

Freexian is looking to expand its team with more Debian contributors

March 29, 2024 by Raphaël Hertzog

It’s been a while that I haven’t posted anything on my blog, the truth is that Freexian has been doing very well in the last years and that I have a hard time to allocate time to write articles or even to contribute to my usual Debian projects… the exception being debusine since that’s part of the Freexian work (have a look at our most recent announce!).

That being said, given Freexian’s growth and in the hope to reduce my workload, we are looking to extend our team with Debian members of more varied backgrounds and skills, so they can help us in areas like sales / marketing / project management. Have a look at our announce on debian-jobs@lists.debian.org.

As a mission-oriented company, we are looking to work with persons already involved in Debian (or persons who were waiting the right opportunity to get involved). All our collaborators can spend 20% of their paid work time on the Debian projects they care about.

Freexian’s report about Debian Long Term Support, July 2022

August 31, 2022 by Raphaël Hertzog

A Debian LTS logo

Like each month, have a look at the work funded by Freexian’s Debian LTS offering.

Debian project funding

No any major updates on running projects.
Two 1, 2 projects are in the pipeline now.
Tryton project is in a review phase. Gradle projects is still fighting in work.

In July, we put aside 2389 EUR to fund Debian projects.

We’re looking forward to receive more projects from various Debian teams! Learn more about the rationale behind this initiative in this article.

Debian LTS contributors

In July, 14 contributors have been paid to work on Debian LTS, their reports are available:

  • Abhijith PA did 0.00h (out of 14.00h assigned, thus carrying over 14.00h to the next month).
  • Andreas Rönnquist did 0.00h (out of 0.00h assigned and 10.50h from previous period, thus carrying over 10.50h to the next month).
  • Anton Gladky did 23.00h (out of 25.00h assigned, thus carrying over 2.00h to the next month).
  • Ben Hutchings did 3.00h (out of 24.00h assigned, thus carrying over 21.00h to the next month).
  • Dominik George did 0.00h (out of 0.00h assigned and 22.17h from previous period, thus carrying over 22.17h to the next month).
  • Emilio Pozuelo Monfort did 72.00h (out of 35.75h assigned).
  • Enrico Zini did 0.00h (out of 0.00h assigned and 8.00h from previous period, thus carrying over 8.00h to the next month).
  • Markus Koschany did 35.75h (out of 35.75h assigned).
  • Ola Lundqvist did 8.00h (out of 0.00h assigned and 12.00h from previous period, thus carrying over 4.00h to the next month).
  • Roberto C. Sánchez did 14.25h (out of 29.25h assigned and 2.75h from previous period, thus carrying over 17.75h to the next month).
  • Stefano Rivera did 8.00h (out of 6.25h assigned and 20.75h from previous period, thus carrying over 19.00h to the next month).
  • Sylvain Beucler did 3.50h (out of 35.75h assigned, thus carrying over 32.25h to the next month).
  • Thorsten Alteholz did 20.00h (out of 35.75h assigned).
  • Utkarsh Gupta did not report back about their work so we assume they did nothing (out of 35.75 available hours, thus carrying them over to the next month).

Evolution of the situation

In July, we have released 3 DLAs. July was the period, when the Debian Stretch had already ELTS status, but Debian Buster was still in the hands of security team. Many member of LTS used this time to update internal infrastructure, documentation and some internal tickets. Now we are ready to take the next release in our hands: Buster!

Thanks to our sponsors

Sponsors that joined recently are in bold.

  • Platinum sponsors:
    • TOSHIBA (for 83 months)
    • GitHub (for 74 months)
    • Civil Infrastructure Platform (CIP) (for 51 months)
  • Gold sponsors:
    • Roche Diagnostics International AG (for 94 months)
    • Linode (for 88 months)
    • Babiel GmbH (for 78 months)
    • Plat’Home (for 77 months)
    • University of Oxford (for 33 months)
    • Deveryware (for 20 months)
    • VyOS Inc (for 15 months)
    • EDF SA (for 4 months)
  • Silver sponsors:
    • Domeneshop AS (for 99 months)
    • The Positive Internet Company (for 99 months)
    • Nantes Métropole (for 93 months)
    • Université Jean Monnet de St Etienne (for 85 months)
    • Univention GmbH (for 84 months)
    • Ribbon Communications, Inc. (for 78 months)
    • Exonet B.V. (for 68 months)
    • Leibniz Rechenzentrum (for 62 months)
    • CINECA (for 52 months)
    • Ministère de l’Europe et des Affaires Étrangères (for 46 months)
    • Cloudways Ltd (for 35 months)
    • Dinahosting SL (for 33 months)
    • Bauer Xcel Media Deutschland KG (for 27 months)
    • Platform.sh (for 27 months)
    • Moxa Intelligence Co., Ltd. (for 21 months)
    • sipgate GmbH (for 18 months)
    • Tilburg University (for 17 months)
    • OVH US LLC (for 16 months)
    • GSI Helmholtzzentrum für Schwerionenforschung GmbH (for 8 months)
    • Soliton Systems K.K. (for 5 months)
  • Bronze sponsors:
    • Evolix (for 99 months)
    • Seznam.cz, a.s. (for 99 months)
    • Intevation GmbH (for 96 months)
    • Linuxhotel GmbH (for 96 months)
    • Daevel SARL (for 95 months)
    • Bitfolk LTD (for 93 months)
    • Greenbone Networks GmbH (for 93 months)
    • Megaspace Internet Services GmbH (for 93 months)
    • NUMLOG (for 93 months)
    • WinGo AG (for 92 months)
    • Ecole Centrale de Nantes – LHEEA (for 88 months)
    • Entr’ouvert (for 83 months)
    • Adfinis AG (for 81 months)
    • GNI MEDIA (for 75 months)
    • Laboratoire LEGI – UMR 5519 / CNRS (for 75 months)
    • Tesorion (for 75 months)
    • Bearstech (for 67 months)
    • LiHAS (for 67 months)
    • Catalyst IT Ltd (for 61 months)
    • Supagro (for 57 months)
    • Demarcq SAS (for 55 months)
    • Université Grenoble Alpes (for 41 months)
    • TouchWeb SAS (for 33 months)
    • SPiN AG (for 30 months)
    • CoreFiling (for 26 months)
    • Institut des sciences cognitives Marc Jeannerod (for 20 months)
    • Observatoire des Sciences de l’Univers de Grenoble (for 17 months)
    • Tem Innovations GmbH (for 12 months)
    • WordFinder.pro (for 11 months)
    • CNRS DT INSU Résif (for 10 months)
    • Alter Way (for 3 months)
  • 1
  • 2
  • 3
  • …
  • 102
  • Next Page »

Get the Debian Handbook

Available as paperback and as ebook.
Book cover

Email newsletter

Get updates and exclusive content by email, join the Debian Supporters Guild:

Follow me

  • Email
  • Facebook
  • GitHub
  • RSS
  • Twitter

Discover my French books

Planets

  • Planet Debian

Archives

I write software, books and documentation. I'm a Debian developer since 1998 and run my own company. I want to share my passion and knowledge of the Debian ecosystem. Read More…

Tags

3.0 (quilt) Activity summary APT aptitude Blog Book Cleanup conffile Contributing CUT d-i Debconf Debian Debian France Debian Handbook Debian Live Distro Tracker dpkg dpkg-source Flattr Flattr FOSS Freexian Funding Git GNOME GSOC HOWTO Interview LTS Me Multiarch nautilus-dropbox News Packaging pkg-security Programming PTS publican python-django Reference release rolling synaptic Ubuntu WordPress

Recent Posts

  • Debian’s General Resolution on AI and LLM
  • How to choose your SSH agent with Wayland and systemd
  • Freexian is looking to expand its team with more Debian contributors
  • Freexian’s report about Debian Long Term Support, July 2022
  • Freexian’s report about Debian Long Term Support, June 2022

Copyright © 2005-2021 Raphaël Hertzog