Today trying to see how a new person who wants to start maintaining new packages would do and trying to do research thinking from his point of
view and from simple searches on the internet I found unfortunately that these parts are fragmented and do not help at all to aim for something unified but not even simple and fast enough.
Opinion against this post will include something about hallucination.
In the case LLM write something that does not compile at all, or write
some non-existent API, a human is intelligent enough to easily notice
that build failure or lintian error and tell whether it is hallucination
or not. I personally believe LLMs, at the current stage, is useful
as long as used and interpreted properly.
BTW, I was in the middle of evaluation LLMs for the nm-template. I did lots of procrastinations towards finishing the evaluation, but the first
several questions were answered perfectly. https://salsa.debian.org/lumin/ai-noises/-/tree/main/nm-templates?ref_type=heads
If anybody is interested in seeing the LLM evaluation against nm-templates, please let me know and your message will be significantly useful for me
to conquer my procrastination on it.
Opinion against this post will include something about hallucination.
In the case LLM write something that does not compile at all, or write
some non-existent API, a human is intelligent enough to easily notice
that build failure or lintian error and tell whether it is hallucination
or not.
Even if somebody in Debian community has enough time to overhaul everything and create a new documentation, it will become the situation described
in XKCD meme "standards": xkcd.com/927/ -- we just got yet another document as a fragment as time goes by.
Debian should consider allocating some budget like several hundred USD
per month for the LLM API calls for all members and new-comers' usage.
There is no need to start new duplicate parallel efforts. Simply
contribute to the existing ones.
Anyone can edit the current wiki pages if they want to improve them
(although most people I spoke to don't like using MoinMoin, but that
is another topic). If you would like to improve a man page, most
packages in Debian accept Merge Requests on Salsa to improve the man
pages. For example, git-buildpackage has now 29 accepted merge
requests [1], dh-make 16 [2] and debmake 14 [3]. Contributions to
these tool man pages are reviewed by the tool maintainers and thus
likely end up in man pages that are actually correct. Sending MRs to
the tool maintainers likely also helps them stay motivated to continue
to maintain the tools, and the MR contents helps the maintainers get
insight of the "user point of view".
Account creation failed: Automatic account creation disabled to stop spammers signing up. Please contact wiki@debian.org and describe what you want to do in the wiki. Please contact us in English, otherwise we will have to pass your message to onlinetranslation services..
I don't think Debian should as an organization pay for LLMs. On the
contrary I would expect LLM providers to offer API keys for free to
Debian Developers just like we have other perks listed at https://wiki.debian.org/MemberBenefits.
On Sat, Jan 11, 2025 at 07:13:58PM -0800, Otto Keklinen wrote:
I don't think Debian should as an organization pay for LLMs. On the contrary I would expect LLM providers to offer API keys for free to
Debian Developers just like we have other perks listed at https://wiki.debian.org/MemberBenefits.
I'd go further and say that the ecological and social costs of most of
the contraptions provided by those providers means that using them in
any way is unethical, and I personally refuse to do so. I recommend
that other people do the same.
(I have less fixed views on locally-trained models, but I see no very compelling need to find more things to spend energy on even if the costs
are lower.)
--
Colin Watson (he/him) [cjwatson@debian.org]
(I have less fixed views on locally-trained models, but I see no very compelling need to find more things to spend energy on even if the costs
are lower.)
On 11/01/2025 20:43, Otto Kekäläinen wrote:[..]
Just a heads up on wiki signup:translation services..
Account creation failed: Automatic account creation disabled to stop spammers signing up. Please contact wiki@debian.org and describe what you want to do in the wiki. Please contact us in English, otherwise we will have to pass your message to online
Understandable of course, but the email slows things down a bit.
MoinMoin doesn't have SSO support, but if anyone's interested in OAuth2
and writes python, it's typically very straightforward: https://moinmo.in/EasyToDo/implement%20oauth
It would be super nice if connected to Salsa or Gitlab.com account
No-one is stopped from using any of the free offers. I don't think we
need our own chat bot. Of course that means, in turn, that we give up on feeding it domain-specific knowledge and our own prompt. But that's... probably fine?
If those LLMs support that, one could still produce a guide on how to
feed more interesting data into it - or provide a LoRA. It's not like inference requires a GPU.
But then again saying things like "oh, look, I could easily answer the
NM templates with this" is the context you want to put this work in.
So what I was talking is simply a choice among the two:
1. A contributor who needs help can leverage LLM for its immediate response and
help even if it only correct, for 30% of the time. It requires the contributor
to have knowledge and skill to properly use this new technology.
2. A contributor who needs help has to wait for a real human for indefinite time
period, but the correctness is above 99$.
The existing voice chose the second one. I want to mention that "waiting for a real
human for help on XXX for indefinite time" was a bad experience when I was a new comer.
The community not agreeing on using that new technology to aid such pain point,
seems understandable to me.
On Sun Jan 12, 2025 at 4:52 PM CET, Ahmad Khalifa wrote:online translation services..
On 11/01/2025 20:43, Otto Kekäläinen wrote:[..]
Just a heads up on wiki signup:
Account creation failed: Automatic account creation disabled to stop spammers signing up. Please contact wiki@debian.org and describe what you want to do in the wiki. Please contact us in English, otherwise we will have to pass your message to
Understandable of course, but the email slows things down a bit.
MoinMoin doesn't have SSO support, but if anyone's interested in OAuth2 and writes python, it's typically very straightforward: https://moinmo.in/EasyToDo/implement%20oauth
It would be super nice if connected to Salsa or Gitlab.com account
what would be truly amazing, imho, would be the whole wiki on git. that'd allow
for mass-updates, and reusing one's code (salsa) workflows for documentation
Watching other people find and fix bugs, even in code they
have written or know well, I can't trust systems built on modern
Markov chains to do better, no matter how much input you give them, and that's without crediting LLMs as able to create good novel code..
So what I was talking is simply a choice among the two:
1. A contributor who needs help can leverage LLM for its immediate response and
help even if it only correct, for 30% of the time. It requires the contributor
to have knowledge and skill to properly use this new technology.
On Sat, 2025-01-11 at 13:49 +0100, Fabio Fantoni wrote:
Today trying to see how a new person who wants to start maintaining new packages would do and trying to do research thinking from his point of view and from simple searches on the internet I found unfortunately that these parts are fragmented and do not help at all to aim for something unified but not even simple and fast enough.
And those fragments also changes as the time goes by. Such as the sbuild schroot -> unshare changes. They are not necessarily well documented in
every introduction material for new comers.
Even if somebody in Debian community has enough time to overhaul everything and create a new documentation, it will become the situation described
in XKCD meme "standards": xkcd.com/927/ -- we just got yet another document as a fragment as time goes by.
LLMs are good companions as long as the strong ones are used. In order to help new comers to learn, it is better for Debian to allocate some LLM API credits to them, instead of hoping for someone to work on the documentation and falling in the XKCD-927 infinite loop.
Considering the price, the LLM API call for helping all DDs + newcomers,
I believe, will be cheaper than hiring a real person to overhaul those documentations and keep them up to date. This is a feasible way to partly solve the issue without endlessly waiting for the HERO to appear.
Debian should consider allocating some budget like several hundred USD
per month for the LLM API calls for all members and new-comers' usage.
DebGPT can be hooked somewhere within the debian development process,
such as sbuild/ratt for build log analysis, etc. It is cheap enough
and people will eventually figure out the useful apsect of them.
Opinion against this post will include something about hallucination.
In the case LLM write something that does not compile at all, or write
some non-existent API, a human is intelligent enough to easily notice
that build failure or lintian error and tell whether it is hallucination
or not. I personally believe LLMs, at the current stage, is useful
as long as used and interpreted properly.
BTW, I was in the middle of evaluation LLMs for the nm-template. I did lots of procrastinations towards finishing the evaluation, but the first
several questions were answered perfectly. https://salsa.debian.org/lumin/ai-noises/-/tree/main/nm-templates?ref_type=heads
If anybody is interested in seeing the LLM evaluation against nm-templates, please let me know and your message will be significantly useful for me
to conquer my procrastination on it.
what would be truly amazing, imho, would be the whole wiki on git.
that'd allow for mass-updates, and reusing one's code (salsa)
workflows for documentation
Understandable of course, but the email slows things down a bit.
MoinMoin doesn't have SSO support, but if anyone's interested in OAuth2
and writes python, it's typically very straightforward: https://moinmo.in/EasyToDo/implement%20oauth
On Sun Jan 12, 2025 at 3:52 PM GMT, Ahmad Khalifa wrote:
Understandable of course, but the email slows things down a bit.
MoinMoin doesn't have SSO support, but if anyone's interested in OAuth2
and writes python, it's typically very straightforward: https://moinmo.in/EasyToDo/implement%20oauth
I'm *fairly* sure that a more pressing issue is that MoinMoin requires
Python 2, which has been abandoned.
At least the stable and deployed versions: 2.0.0a1 is the first release from the 2.x branch which is a rewrite for Python 3, released 2024-03-24.
Hi Serafeim, and others,[..]
Quoting Serafeim (Serafi) Zanikolas (2025-01-12 21:54:58)
what would be truly amazing, imho, would be the whole wiki on git. that'd allow
for mass-updates, and reusing one's code (salsa) workflows for documentation
For those not only wishing that others made that happen, but consider scratching that particular itch themselves, I am happy to chat with you
more detailed about what that involves, and how it is a quite exciting challenge - so exciting, in fact, that Debian has had several attempts
at doing a migration over the years, but none so far have succeeded.
But let's not hijack any further this thread about welcoming newcomers,
I just wanted to chime in to encourage anyone wanting to do the wiki modernization to get in touch with me to discuss further.
On Mon Jan 13, 2025 at 12:45 AM CET, Jonas Smedegaard wrote:
Quoting Serafeim (Serafi) Zanikolas (2025-01-12 21:54:58)
what would be truly amazing, imho, would be the whole wiki on git.
that'd allow for mass-updates, and reusing one's code (salsa)
workflows for documentation
For those not only wishing that others made that happen, but[..]
consider scratching that particular itch themselves, I am happy to
chat with you more detailed about what that involves, and how it is
a quite exciting challenge - so exciting, in fact, that Debian has
had several attempts at doing a migration over the years, but none
so far have succeeded.
But let's not hijack any further this thread about welcoming
newcomers,
let's create a new thread then :)
I just wanted to chime in to encourage anyone wanting to do the wiki modernization to get in touch with me to discuss further.
thank you for the offer but why not have the follow up in a publicly
archived list? happy to switch to -www, if -devel is not ideal
I think that a retrospective/postmortem of past attempts would be very valuable.
I offer to write one if you'd be okay to share all of the context with
me (you could review it before it gets published).
also, I'd think that nailing down the requirements for a new platform
and for the content to be migrated (e.g. drop any pages that are >X
years old) would be an important prerequisite for any technical work.
has this been done in previous migration attempts? to start with, do
we have "rough consensus" that a git-backed wiki would be preferable?
Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)
also, I'd think that nailing down the requirements for a new platform
and for the content to be migrated (e.g. drop any pages that are >X
years old) would be an important prerequisite for any technical work.
has this been done in previous migration attempts? to start with, do
we have "rough consensus" that a git-backed wiki would be preferable?
No, I am unaware of any consensus on any changes, just have a vague
feeling that MoinMoin is somewhat as appreciated in Debian as CDBS :-)
Anyone interested in discussing practicalities of migrating away from MoinMoin for the Debian wiki, please join the tinker mailinglist at https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel
Anyone interested in discussing practicalities of migrating away from MoinMoin for the Debian wiki, please join the tinker mailinglist at https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel
Anyone interested in discussing practicalities of migrating away from MoinMoin for the Debian wiki, please join the tinker mailinglist at https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel
I can't imagine there are more features in MoinMoin that can't be
migrated to MediaWiki and friends, so I want to find out what I'm
missing.
On Mon Jan 13, 2025 at 9:43 PM GMT, Jonas Smedegaard wrote:
Anyone interested in discussing practicalities of migrating away from MoinMoin for the Debian wiki, please join the tinker mailinglist at https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel
What is "Tinker blend development discussion"? I've never heard of it.
On Sun, 2025-01-12 at 16:56 +0000, Colin Watson wrote:
(I have less fixed views on locally-trained models, but I see no very
compelling need to find more things to spend energy on even if the costs
are lower.)
Locally-trained models are not practical in the current stage. State-of-the-art
models can only be trained by the richest capitals who have GPU clusters. Training
and deploying smaller models like 1 billion can lead to a very wrong impression
and conclusion on those models.
I'd really like to know how it is possible for one to use an LLM to make
a contribution to a permissively licensed project (e.g. Expat) without
in effect stealing the code from one's own tribe of Copyleft authors.
Can one even play with an LLM without somehow contaminating one's brain?
Wikis have their own version control and they're meant for a much
wider audience. I think general documentation definitely belongs on a
wiki, not git. Edit, fix typo, done in 30 seconds :)
Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)
thank you for the offer but why not have the follow up in a publicly
archived list? happy to switch to -www, if -devel is not ideal
Then let's move to the tinker team mailinglist: >https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel
Jonas wrote:
Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)
thank you for the offer but why not have the follow up in a publicly
archived list? happy to switch to -www, if -devel is not ideal
Then let's move to the tinker team mailinglist: >https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel
Erm, WTF? How about keeping this on a main project list. And maybe
even include the current people working on web and wiki admin?
Unimpressed...
Quoting Steve McIntyre (2025-01-14 15:16:49)
Jonas wrote:
Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)Erm, WTF? How about keeping this on a main project list. And maybe
thank you for the offer but why not have the follow up in a publicly
archived list? happy to switch to -www, if -devel is not ideal
Then let's move to the tinker team mailinglist:
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel >>
even include the current people working on web and wiki admin?
Unimpressed...
WTF what? Should we stop work in smaller groups and discuss everything
here in one giant mailinglist for every detail of the project, or what
in particular makes this detail so F'ing global?
Offended...
I'm *fairly* sure that a more pressing issue is that MoinMoin requires
Python 2, which has been abandoned.
At least the stable and deployed versions: 2.0.0a1 is the first release
Jonas wrote:
Quoting Steve McIntyre (2025-01-14 15:16:49)
Jonas wrote:
Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)
thank you for the offer but why not have the follow up in a publicly
archived list? happy to switch to -www, if -devel is not ideal
Then let's move to the tinker team mailinglist:
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel
Erm, WTF? How about keeping this on a main project list. And maybe
even include the current people working on web and wiki admin?
Unimpressed...
WTF what? Should we stop work in smaller groups and discuss everything
here in one giant mailinglist for every detail of the project, or what
in particular makes this detail so F'ing global?
What on earth makes the blend-tinker-devel list a reasonable place to
discuss the Debian wiki and maybe working on replacing its software?
Serafeim suggested debian-www, which seems like a much more reasonable
place to me at least.
Offended...
What, that people questioned this? That the people in the team
*running the service you're talking about* might care about
discussions about it?
Quoting Andrej Shadura (2025-01-15 11:24:31)
Hello,
On Tue, 14 Jan 2025, at 18:01, Jonas Smedegaard wrote:
Then let's move to the tinker team mailinglist:
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel
No, but that my proposal for discussion place was so out of this earth that you felt the need to curse over it.
I hate to be the person to break the news to you, but some random unrelated mailing list of which very few relevant people are members, seems like a very wrong suggestion indeed.
Then it might please you know know that you didn't break it to me,
others fucking did.
But thanks for stepping on it. Anyone else while we are at it?
Then let's move to the tinker team mailinglist:
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel
No, but that my proposal for discussion place was so out of this earth
that you felt the need to curse over it.
Hello,
On Tue, 14 Jan 2025, at 18:01, Jonas Smedegaard wrote:
Then let's move to the tinker team mailinglist:
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel
No, but that my proposal for discussion place was so out of this earth
that you felt the need to curse over it.
I hate to be the person to break the news to you, but some random unrelated mailing list of which very few relevant people are members, seems like a very wrong suggestion indeed.
* Jonas Smedegaard <jonas@jones.dk> [250115 11:40]:
Quoting Andrej Shadura (2025-01-15 11:24:31)
Hello,
On Tue, 14 Jan 2025, at 18:01, Jonas Smedegaard wrote:
Then let's move to the tinker team mailinglist:
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel
No, but that my proposal for discussion place was so out of this earth that you felt the need to curse over it.
I hate to be the person to break the news to you, but some random unrelated mailing list of which very few relevant people are members, seems like a very wrong suggestion indeed.
Then it might please you know know that you didn't break it to me,
others fucking did.
But thanks for stepping on it. Anyone else while we are at it?
Actually, yes. It's really unclear to me what you are trying to
achieve here, with the continuation of this communication style.
One long term goal of debian deep learning team is to host an LLM with
the team's AMD GPUs and expose it to the members. That said, the necessary packages to run that kind of service are still missing from our archive.
It is a good way to use existing GPUs any way.
Even if we get no commercial sponsorship of API calls, we will eventually experiment and evaluate one with the team's infrastructure. We are still working towards that.
First, DebGPT is designed to conveniently put any particular information whether or not Debian-specific, to the context of LLM. I have also implemented
some mapreduce algorithm to let the LLM deal with extremely overlength context such as a whole ratt buildlog directory.
My intention is always to explore possible and potential ways to make LLM useful in any possible extent. To support my idea, I wrote DebGPT, and
I tend to only claim things that is *already implemented* and *reproducible* in DebGPT.
Agreed 100%, the openness for editing is really what makes wikis
shine. It can be hard to accept, with many of us firmly set in Git's pre-approval style PR/MR workflows, to allow anyone with an account,
to just change anything, but that empowerment is what makes wikis work
and really blossom.
As one of the maintainers of the MediaWiki package in Debian[1] and a wholehearted wiki enthusiast (longtime Wikipedia admin, etc.), I have
a lot of thoughts on this that I'll save for later, but I want to
cross-link the ongoing discussion at <https://salsa.debian.org/debian/grow-your-ideas/-/issues/2> that goes
over a lot of the same topics.
Hi Steve and others with interest in wiki.debian.org!
I've added some of the people who participated in https://salsa.debian.org/debian/grow-your-ideas/-/issues/2 and who's
email address I have easily available as CC here, and I've posted a
note about this BoF in that issue. I have also added some research
about potential Markdown+git software in https://salsa.debian.org/debian/grow-your-ideas/-/issues/2#note_288815.
...
Debian should consider allocating some budget like several hundred USD
per month for the LLM API calls for all members and new-comers' usage.
I don't think Debian should as an organization pay for LLMs. On the
contrary I would expect LLM providers to offer API keys for free to
Debian Developers just like we have other perks listed at https://wiki.debian.org/MemberBenefits.
Considering how much the LLMs have utilized open source software when building and training them, it would actually make a lot of sense for
those companies to step up and partner with Debian just like many web
hosting companies have, as they all likewise have built their
businesses on top of open source software. Currently, I don't see any
AI companies at https://www.debian.org/partners/.
If anyone has contacts at OpenAI, Anthropic, xAI, DeepSeek, 01 AI,
Zhipu AI, Meta, Mistral, Nexus, Alibaba, AI21 Labs, Cohere etc, please
tell them about the opportunity to sponsor Debian :)
Codex CLI is built for developers who already live in the terminal and
want ChatGPT-level reasoning plus the power to actually run code,
manipulate files, and iterate - all under version control. In short,
it's chat-driven development that understands and executes your repo.
* Zero setup - bring your OpenAI API key and it just works! Full
* auto-approval, while safe + secure by running network-disabled and
* directory-sandboxed Multimodal - pass in screenshots or diagrams to
implement features ✨
And it's fully open-source so you can see and contribute to how it
develops!
(Of course, the "open source" part applies to the client app, not to the model)
OpenAI has an Open Source fund. Maybe Debian should apply[1] for a grant
so that Debian contributors could get hands-on experience on how this
could help their Debian activities?
I'm willing to handle the paperwork and apply on behalf on Debian (and
then handle giving access to DDs), but of course this would need DPL
approval (Cced).
[0]https://github.com/openai/codex [1]https://openai.com/form/codex-open-source-fund/
Lucas
OpenAI has an Open Source fund. Maybe Debian should apply[1] for a grant
so that Debian contributors could get hands-on experience on how this
could help their Debian activities?
On Wed, Jun 04, 2025 at 05:04:34PM +0200, Lucas Nussbaum wrote:
OpenAI has an Open Source fund. Maybe Debian should apply[1] for a grant
so that Debian contributors could get hands-on experience on how this
could help their Debian activities?
or maybe Debian should not.
On Fri, Jun 06, 2025 at 12:03:32PM +0200, Lucas Nussbaum wrote:
or maybe Debian should not.Maybe. Honestly, I don't know.
I'd rather not take their offer based on moral grounds: they stole
and
steal from everyone and want to make that normal. And for that, they
offer some breadcrumbs to the people they stole from.
Also they contribute massivly to burning down our only planet faster.
On Fri, Jun 06, 2025 at 12:48:11PM +0200, Ansgar 🙀 wrote:
Also they contribute massivly to burning down our only planetSo do in-person conferences, rebuilding software just to observe
faster.
that
no changes happen,
horseshit. those things dont require dozens of entire powerplants...
or maybe Debian should not.Maybe. Honestly, I don't know.
Also they contribute massivly to burning down our only planet faster.So do in-person conferences, rebuilding software just to observe that
no changes happen,
OpenAI has an Open Source fund. Maybe Debian should apply[1] for a grant so that Debian contributors could get hands-on experience on how this could help their Debian activities?
or maybe Debian should not.
Maybe. Honestly, I don't know.
(A) an "agent", that is the client software running on your machine that
you talk with, and that interacts with your codebase (read files, make changes to files, run commands, create git commits, etc.). Ideally in
some kind of sandbox and/or with permissions management.
Examples include 'Claude Code' (works in CLI, proprietary, interacts
only with Anthropic models), Cursor(.com) (VS Code fork, proprietary, interacts with either Claude* (Anthropic) or Gemini* (Google)), Codex
CLI (free software, developed by OpenAI and focused on their models, but supposed to work with other providers). DebGPT fits here too (but is
less advanced for coding tasks than Claude Code or Cursor).
(B) a way to query models:
- either subscription-based from commercial services such as OpenAI,
Anthropic, Gemini, ... or brokers like OpenRouter.
- or using "open" models that you can download and run yourself,
typically with ollama (free software)
(C) good matching between (A) and (B): it helps if the client side (A)
knows how to tune to queries ("prompt engineering") for the specific provider/model in use (B). Typically, in my tests, trying to use Codex
CLI with ollama fails there (or I could not find a model that produced reasonable results). (Also the OpenAI API has variants that are not
supported by all models ("tools support").)
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 491 |
Nodes: | 16 (2 / 14) |
Uptime: | 84:47:26 |
Calls: | 9,679 |
Files: | 13,722 |
Messages: | 6,173,507 |