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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/11/25 5:25 PM, M. Zhou wrote:

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.

LLMs ingest documentation. If we stop writing or overhauling
documentation, what is the LLM going to suggest? Even hallucination
aside, how can it be the least bit accurate if it is not fed up-to-date information about how things work?

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.

If anyone is attempting to answer these using LLMs, I'd expect them to
be excluded from the process. It's one thing to generate documentation
by reviewing LLM output for accuracy and potentially publishing that to
be helpful. It's another thing to try to lie yourself through the
process in order to gain the project's trust.

(In job interviews candidates already regularly use LLMs in the
background to answer the questions. There I think it's still noticable
when people claim knowledge that they do not have. In offline
communication all bets are off.)

Kind regards
Philipp Kern

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Jan 11, 2025 at 11:25:20AM -0500, M. Zhou wrote:

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.

No, I don't think a human is intelligent enough for that. Based on my
limited experience with people trying to learn how to use tools I'm the upstream for I fully expect that human to go to -mentors and ask why the
tool or option proposed by the LLM doesn't exist (without mentioning where
do they get that) or even why does the d/control they wrote results in a dpkg-source error about a not recognized field.
It's possible that probability of doing this is lower for people learning packaging than for people learning a tool/langauge/framework in general,
but remember that a noticeable share of people learning packaging is
people who want to package their pet project.

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmeCubYtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh WTMP/iYkndZ8NLBLnXktO6sUIav0lhFpAbn7kQQRoL7yv9XkIdh5zltht6K7GKiF mhrg6R/sHoLrRU1LrT1BbiNvpyG97zJW5aN5fLKUQD632Tf0xEsM5sAKYFbNh4Mk v7ZlXnM1dmpi4uRs0geO6Gd5lXj3S2ubZtIbeCvSZ0cKe5iijyqtwjP4tDH75rk8 z8DF4ByBDbmww+jvN8DoiO8ELUQ651/tI7CxGtrEkIq5oufEOJ6J485k+MT4BtNj 0d8Rnnw0TQ9cBx1uNrc6LwKCe5ywaXCd2CxheQ5fvgGy81EcePiWtNsUvhOkzAtp FWQGoAHRmQDTJZJYjvhYUdtLLdjY2ohcsQZGQAHgbDhVLutqraoeL9+Yc2wIXze1 AFah7rQV8BuVNRWuK3gWFVjtVZHYtAcs4ArliUhwo3kW6PlbPgvetbk5yxnfxjmL fMOY//MUVLH+TyXUBOEkerKgJQPxm9jQ2BqPvChLA1m/eER8YNBKAmltlcspO5RN 28A916l7GM6ZiP62PkjpN+8DJkgk/7IsyPTq7tTSUYy2gDD8BlZAY+fbxEMB52Bw u99Cl3rogNgs0H2sglKfjHQoKpTpkPw8/R9n3vzRwv5UMRGyTmiJJNgOyzNDomOq 65in7DLnB3CRhNtRbaz0Eg74cruXI3k3di/4lXf7Eefcz7eO
=ytvH
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.mentors

Hi!

(cross-posting to mentors as they have most experience on what is
wrong with our current docs)

...

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.

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".

You can easily also contribute to the Debian Developers Reference,
which has already accepted 26 merge requests [4]. The same goes for
the Guide for Debian Maintainers, which has already accepted 26 MRs as
well [5]. The Debian New Maintainers' Guide is abandoned and
deprecated, it should have a more clear banner stating it. The Debian
FAQ [6] has already accepted 13 MRs (8 of them in the past 6 months),
so nothing should be blocking you from contributing improvements
there. The debian.org website has accepted a whopping 716 MRs [7],
contributing there should be easy and fruitful as there are active
reviewers who will guide/help that the update is as good as possible.
The mentors.debian.net has also very active team and 205 accepted MRs
[8].

I have at least MR in all of the above, so I speak out of experience.
The process is smooth and most recipients give the first review
feedback within a week, and after polishing the submissions are likely
to accept.

I warmly recommend others who have time to engage in long discussions
on debian-devel@ to divert some of that energy into updating some of
the documentation.



[1] https://salsa.debian.org/agx/git-buildpackage/-/merge_requests?scope=all&state=merged
[2] https://salsa.debian.org/debian/dh-make/-/merge_requests?scope=all&state=merged
[3] https://salsa.debian.org/debian/debmake/-/merge_requests?scope=all&state=merged
[4] https://salsa.debian.org/debian/developers-reference/-/merge_requests?scope=all&state=merged
[5] https://salsa.debian.org/debian/debmake-doc/-/merge_requests?scope=all&state=merged
[6] https://salsa.debian.org/ddp-team/debian-faq/-/merge_requests?scope=all&state=merged
[7] https://salsa.debian.org/webmaster-team/webwml/-/merge_requests?scope=all&state=merged
[8] https://salsa.debian.org/mentors.debian.net-team/debexpo/-/merge_requests?scope=all&state=merged

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

...

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 :)


Also, in my view LLMs are still far from being able to do Debian
development, they can't even write good git commit messages explaining
*why* a particular change is made. They may in some cases, however, be
useful assistants doing proof-reading and simple tasks. Debian
contributors should be exploring sensible way to use LLMs in ways that
fit their personal workflows, so that the human originated Merge
Requests / patches get written faster and have a higher quality. But
no thanks to LLM written stuff that wasn't closely co-authored and
reviewed by a human. The risk of getting garbage is far too high.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.mentors

On 11/01/2025 20:43, Otto Kekäläinen wrote:

There is no need to start new duplicate parallel efforts. Simply
contribute to the existing ones.

+1, please. Too many docs already :)

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".

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 online

translation services..

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


--
Regards,
Ahmad

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Jan 11, 2025 at 07:13:58PM -0800, Otto Kekäläinen 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]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, Jan 12, 2025 at 04:56:15PM +0000, Colin Watson wrote:

On Sat, Jan 11, 2025 at 07:13:58PM -0800, Otto Kek�l�inen 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.

You can label me as extremely reactionary on this: I think LLM providers shouldn't be providing LLMs to Debian unless they are of proven benefit
to the whole Project. I don't think they are and I don't trust the motives
of those who suggest them as a cure-all. At the very best, LLMs are at
the level of a Google Translate: at worst, they're wholly inaccurate and untrustworthy.

I chose Google Translate as a deliberate example here: it's provided
by one of the most influential agents on the Internet with the largest
corpus of text to train on.I wouldn't trust it against the opinion
of a good native speaker to translate to/from English, say, though I might
rely on it to give some vague sense of an unknown text in a language I don't understand or read well..

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 think the ecological costs have a bearing here: currently, it seems
improper to use systems that appear to imperil energy grids for entire - countries. 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..

(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.)

Absolutely: even if the costs to the Debian project for LLMs were to be
nil at present, there are better things for the project to spend time on.

With every good wish, as ever,

--
Colin Watson (he/him) [cjwatson@debian.org]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

Based on the comments, what I saw is that using LLMs as an organization is too radical for Debian. In that sense leaving this new technology to individuals' personal
evaluation and usage is more reasonable.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

--321753c7bfbe0e4aad5e36429ec31f355fba3908ec273f94c8e35f605f9b Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

On Sun Jan 12, 2025 at 4:52 PM CET, Ahmad Khalifa wrote:

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 online

translation services..

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

thanks,
serafi

--321753c7bfbe0e4aad5e36429ec31f355fba3908ec273f94c8e35f605f9b
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEA2RWqo7IwLCLSFYbT59tVQ7WEioFAmeELCMACgkQT59tVQ7W EipNXhAAypoxffmmTQA0OhYANWDCxB1T/5SEaSfDdlAT9bSknQNzD4/M1/VhYu3l 46ty5st8yxdGeqDWh9mGzFZTbr7PDnauIEK6Xpt6Ax7Zo3e30Vn1jZUsiZ4df2+4 CTz25ZwxPS3Ej85NjHOH7pl1bnRS2vw+WGF28aTWH8emqxH9/y4e+C5Z8pCtG+v+ CJPfdqhSbjZ0FExeeUoMbtlbqsVcwRlvPwxI+TJ6ulMzeOy9OIhZyUljMri5Zwnc L0ga3tWF3oE93EmzKLuD+NI2TOyszyVOSICA5LZH6AFZEv0Y9gKNcxdCA8RrJI2P z4f3XjYeD/j0brPZFVOEFoK60GeWqi8mzWaSzA0xWWdehyYDf+ydqy5M5Hc1DBV1 R333Ya/rVsybAKN7YBnumsOasmjM6bpfB11iiZlDjkN9XyCzCajJyOsfrVINOIyH HwBQF+To1sIj0o28Bu+GwiGNnWKznXGWCZ3yzpXzP10YmQDdg5kPHMrRcxEwAQCY ggIctrYHsBSeBrhVgyCAzjYurjaPlXBSuQozktMmWU9gBmBXoX628PzKP1+UCtqe D2IUfrzvh9/23TPCgHZ+8bte/U7Zz62y7dLFp3lfVpiNtmJPc2PtJCCPD89Zk3kw bw9FeFu+ZC1OUBkY5VmVQgNq+EZblBctQu3wlC935GZBR2bXfgA=/0m0
-----END PGP SIGNATURE-----

--321753c7bfbe0e4aad5e36429ec31f355fba3908ec273f94c8e35f605f9b--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun, 2025-01-12 at 22:36 +0100, Philipp Kern wrote:

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?

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.

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.

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.

LoRA is only sound when you have a clear definition on the task you want
the LLM to deal with. If we do not know what the user want, then forget
about LoRA and just carefully provide the context to LLM. DebGPT is
technically on the right way in terms of feasibility and efficiency.

RAG may help. I have already implemented the vector database and the
retrieval modules in DebGPT, but the frontend part for RAG is still
under development.

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.

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.

For instance, I've added the automatic answering of the nm-tempaltes in
DebGPT and the following script can quickly give all the answer.
The answers are pretty good at a first glance. I'll postpone the full evaluation when I wrote the code for all nm-templates.

I simply dislike saying nonsense that cannot be implemented in DebGPT.
But please do not limit your imagination with my readily available
demo examples or the use cases I claimed.


(you need to use the latest git version of DebGPT)
```
# nm_assigned.txt
debgpt -f nm:nm_assigned -a 'pretend to be lumin@debian.org and answer the question. Give concrete examples, and links as evidence supporting them are preferred.' -o nm-assigned-selfintro.txt

# nm_pp1.txt
for Q in PH0 PH1 PH2 PH3 PH4 PH5 PH6 PH7 PHa; do
debgpt -HQf nm:pp1.${Q} -a 'Be concise and answer in just several sentences.' -o nm-pp1-${Q}-brief.txt;
debgpt -HQf nm:pp1.${Q} -a 'Be precise and answer with details explained.' -o nm-pp1-${Q}-detail.txt;
done

# nm_pp1_extras.txt
for Q in PH0 PH8 PH9 PHb; do
debgpt -HQf nm:pp1e.${Q} -a 'Be concise and answer in just several sentences.' -o nm-pp1e-${Q}-brief.txt;
debgpt -HQf nm:pp1e.${Q} -a 'Be precise and answer with details explained.' -o nm-pp1e-${Q}-detail.txt;
done
```

[1] DebGPT: https://salsa.debian.org/deeplearning-team/debgpt

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/12/25 7:46 PM, M. Zhou wrote:

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.

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.

Kind regards
Philipp Kern

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Serafeim, and others,

Quoting Serafeim (Serafi) Zanikolas (2025-01-12 21:54:58)

On Sun Jan 12, 2025 at 4:52 PM CET, Ahmad Khalifa wrote:

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

online translation services..

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

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.

I don't say this to scare you off, but to make you aware that it is not
because Debianites love the archane MoinMoin wiki, but because it is challenging to migrate away from it.

I originally packaged the MoinMoin wiki engine many years ago, before
Ubuntu existed. Then git was invented, and Ikiwiki. Some has tried to
migrate to Ikiwiki, some has tried to migrate to Mediawiki. Personally,
I would today migrate to zola, but you (i.e. those wanting to roll up
your sleeves and actually do this migration task) no doubt have your own opinion on which should be the goal and why that is ideal. Regardless of
the goal, some of the preparations to get there is likely similar to
those previous attempts, where I and others might have input from those previous attempts. If you think you have a novel new approach then I
would love to learn about it, as I still run a few legacy wikis that I
would like to migrate.

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.

Kind regards,

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private --==============A37205751928917522=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

wsG7BAABCgBvBYJnhFQPCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmdwpPqUfj/mBxj/CsPb89NB/jRWQBq7LXNMVvGYIB+D 4xYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAACdrhAAh8TtQkfWRgwbRqLjHSgvodat ng2ORyGhY1CcnV/NoDJm11udxoxY5atV2YDKeHunIBJgMryt52SO+iekO3BviweZ Kbr/qRH0K/1MUSnJYC1q5R9rP9lK7rH54FuoOBVBpeDplpI+i3Lzx790rndjJKk1 pFoU/o0M1N7LVExerbbHtOWOoyPdNxyScZQsSeXt8C9sx2yVHw9/RzyjCXLw5pYc QuzUQ2DXYgwQkufvgpNh9ph7NhklPv1dxrWGDKVm4VuT8r7UGzQ7wd84uOAsV6TN oXbo7VT933LXMH3kNpcEXNEBHZUeYExi3rRJcF3+PNTst08CpPvQu5LIULUseXq6 d/aqQK6Q9YiZ1br2jGdeHrBNPctHDFq/zKKI32b3

On 2025-01-12 at 18:03 +0000, Andrew M.A. Cater wrote:

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..

This is something I have thought before, and which I find lacking in
most (all?) instances of the "let's program with an LLM" topic.

When a human¹ programs something, I expect there is a logical process
through which he arrives to the decision to write a set of lines of
code. This doesn't mean those lines will be the right ones, or bug-
free. Just that it makes sense.

For example, a program that does chdir("/"); at the beginning may
suggest it my run as a daemon, as this allows it not to block
filesystems from umounting.
If it has a number of calls to getuid(), setuid(), setresuid()... it
might switch to a different user.

However, if the code was generated by a LLM, all bets are off, since
the lines could make no sense at all for this specific program.


It wouldn't be that strange if a LLM asked to generate a control file
for a perl module could suggest a line such as
Depends: libc6 (>= 2.34)
just because there are lots of packages with that dependency.²

A person could make a similar mistake of including unnecessary
dependencies if copying its work on an unrelated package, if not
properly cleaned. But how to fix those things if the mentor is a LLM?



¹ somewhat competent as a programmer
² hopefully, a LLM wouldn't be trained on the *output* of the
templates, though.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On 1/13/25 03:46, M. Zhou wrote:

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.

The "skill required" aspect is an important one. I'm willing to review
packages and provide feedback so learning can occur.

LLMs interrupt the learning process here, because they provide a
solution that makes me assume that the contributor already has a
specific mental model, so my feedback is designed to fine tune this.

When the contributor is using LLM generated code, my feedback is no
longer helpful for learning -- at best, it can be used to iteratively
arrive at a correct solution, but playing a game of telephone is a very inefficient way to do it, and does not prepare the new contributor to
work unsupervised -- so LLMs basically disrupt our intake pipeline in
the same way they are doing in commercial software development.

Simon

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Jan 11, 2025 at 11:25:20AM -0500, M. Zhou wrote:

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.

--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Wir sollten allen Milliardären weltweit ein Ultimatum setzen: Wenn ihr in einem Jahr die Klimakrise nicht gelöst habt, werdet ihr enteignet!“ (@nicosemsrott)

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmeEz7sACgkQCRq4Vgaa qhwNdA/9G5BBVF5gu0AThJD1RdWpzSoTWt7vFuXbcN49Rq3649UiOk0ICQOdE+GJ +4jkzKPbYP78/PhtNpBAE22PsBV41pRGRUl84V22PY5aQlPnbEcoVg14bfzfBIYJ JbIDY1IB1x4F8s7P6OA52R+TRhzVlsFZy1/8SzcfQBItMOasTc8MYee9fz4F1O2q af/1OZrQUA/Bs7A4jUAwJkUi/H0/JCvzpxPGoeRnqyrpRNcclyYthiKX9pUCnZUz lxtz5/YIIl6pcsnBzqo4pY7rkbQGJ4RG67NPln48iLio17r8qtddgE4s2IgB50cb m6F+gB/yMqtuepxliwuGc40BilF2EvElveklfPa9xcczEG1KEpJTW24kF4DfItLe m3Ml5X8huslpNZk3xev8HgFCZZtqwx8YKIRW3HFwCEkbh7QsxAVCAPthR8HPzMGk 7eKAeFA5N1ZCg+u/nM8a0irRZSrLNAWX/MxjaaLPGCWu8O+EketsdrEj0bNokhMO jTdvNSfSGldhDc5

On Sun Jan 12, 2025 at 8:54 PM GMT, Serafeim (Serafi) Zanikolas wrote:

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

Back before we adopted MoinMoin (the previous wiki tech was kwiki iirc)
a couple of us did a brief exploration of using IkiWiki for Debian; it
didn't go anywhere (on my part I didn't put enough into it) but one of
the advantages of it would have been that IkiWiki supports using git as back-end storage.

If there's anyone interested in the Debian Wiki at FOSDEM I would be interested in having a chat. I haven't personally done any work on it
for many years but I've remained interested in it all along. My
particular passion (back at the kwiki→MoinMoin transition) was ensuring
that wiki content was DFSG compatible; that's still something I would
like to see improved.


Best wishes

--
Please do not CC me for listmail.

👱🏻 Jonathan Dowland
✎ jmtd@debian.org
🔗 https://jmtd.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.devel.mentors

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.



--
Please do not CC me for listmail.

👱🏻 Jonathan Dowland
✎ jmtd@debian.org
🔗 https://jmtd.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, Jan 13, 2025 at 10:10:25AM +0000, Jonathan Dowland wrote:

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.

Hello,

I take care of the administrative side of https://wiki.cacert.org/ which is also based on MoinMoin. We did a test installation and content copy of the CAcert wiki based on the 2.x branch after FrOSCon 2024. A a lot of our
content had blocking issues (we use many macros to include shared content on multiple pages.

We (another CAcert member, not myself) were in contact with MoinMoin people, but progress on the issues is quite slow. I think the MoinMoin people would appreciate help to get the 2.x-branch ready. Unfortunately I don't have
enough time to help there.


Best regards
Jan

--
Jan Dittberner - Debian Developer
GPG-key: 4096R/0xA73E0055558FB8DD 2009-05-10
B2FF 1D95 CE8F 7A22 DF4C F09B A73E 0055 558F B8DD https://portfolio.debian.net/ - https://people.debian.org/~jandd/

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEKHuXKkUYdvdO9493DXkdyNc3wdkFAmeE7SIACgkQDXkdyNc3 wdmL0wf/dss20LbLgd1Aepcx7PyS3R28PE5KLPAnSfSxdb2ooomIwB/Lh4dx7sSj nT3GC1zASCCqTPOLP+Xkpi3j3jcqMBit6I6KAKeSHgu1BFqUXmrZWU5ES37g67BG m/4j593LiBh9CfpAXIDAXB5YDDYhOgXDSAJAaSQvPTY+iutToNbpyNDJ3XQO7qne WrMPdbMRh8BnMSO5jqtyWQ9nPqMWOAbRFqDpzLnxhLpzeu6aQhz9sfsgA1CR+GqD RoqztDAq51z8Jkul6xcXJpxr/WAROhfUG9iViADIEQK1iVdulOBVoG34gzSV/Z9a 5WmwioxXNOu7CeiLJKIuqKZianT5ZA==
=Pk9y
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

--a48349db803f08fb254babeff8a44d1df1ce9bbd7e499174a5bcdbeac358 Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

hi Jonas,

On Mon Jan 13, 2025 at 12:45 AM CET, Jonas Smedegaard wrote:

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,

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?

thanks,
serafi

--a48349db803f08fb254babeff8a44d1df1ce9bbd7e499174a5bcdbeac358
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEA2RWqo7IwLCLSFYbT59tVQ7WEioFAmeFgDkACgkQT59tVQ7W Eiq2PQ/9G7Nnp1q4YM13a0te7VFM8m+8tavvsUcaFNU9FhDD1AwtRpuRBbs8ci8y IFEhkP0eb9+FXP1Tp1CfKuD/FnyGFsbgstPnkVOiGmOvLCy2VIt7W42sb8h2bn/4 Jje5GBu6b9jkINCFMQLfmfrryza/4VOgS1v2UDi4R+e6Hxk4LoS5M3/G9ual1JTI iFevJ9Cx1UG5kf0b0MZh7zC6c3jQjYqf/7a0rWIRy7BhFBNCpSn9VvD+nQp8hpYH PYA8Etxongq0konabG8sAcMsNk0E3nqjRAiZHNRTHX1eoBZB3ryZMHCpueTeJBbO AH0BgNui4aDGcygMpUraIw8l+3Z3gQzJtXH2rjp6nLAiycywh/HQa+Yv8ZGHZk+C 7jPABNjWqKgmzcx6TaCqIplGachVrtGZw0SFS93aKcb7vDEQ7Bqkkpbv0y48lPNF qB+PAWVCPjlwxgj0vbaEStCfKOqfFO0Mx02El7+FHuIPRP0gjVPMizewUBVuEpJn NskoKCPunlQ5fXnmNkuKcY/gbUnaZlEHixqrBDyPY+o57cSXXPc9X1wynWSlk/w5 c4LspBhRPhxqHvpeCE8mcbVMu/s/crFA++SqLks15xqS6ir5lSVwyhSMdSoW3Ogn Mcu71hr9NFYnrqzzG2SLrm5lhtH33m3FGffait9FpPJ77cfKi9s=1uYr
-----END PGP SIGNATURE-----

--a48349db803f08fb254babeff8a44d1df1ce9bbd7e499174a5bcdbeac358--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Quoting Serafeim (Serafi) Zanikolas (2025-01-13 22:06:01)

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

Then let's move to the tinker team mailinglist: https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/blend-tinker-devel

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).

I don't mind discussing in public, but do mind doing it in this large
forum.

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

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private --==============`88063803688278757=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

wsG7BAABCgBvBYJnhYkcCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmfPAHPhtXS1YApMGWwIftsXWP132RNRscRmZGzoqBUS vhYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAADgfQ//VsjZKspnjPE1NQya3C7+P4Py UD5Q4gHSfM8rGa8kschWvdfLV4Uk4ZAG6lY4A9L5NALhgZj9uuetVfhzgkhnl4q6 xoNfyaoh6bBnnpGZo6NoXZf0TDWWfvZaPyPkmuePMKJZlYOnsgDOZ0kv4MCujcmf XT7YjlEgkNR/TnCU4/bVQHJsoAeWVAc27qWhU6yzbgQJ4szGqTeLaeg5VFaL0OTa DCb45MuNic9LKeGdavC9Or5i2yzN1RlA/Hg0gBflvoxw384f+EFqZwB7EVlRXoke jfiPb4lw+JSXnS0aKicO9g8K113oTrDYlDRt1W7wwqsFeNfufcyNtSuipwOdWTBx fmEsC5rhNiSjnim4SIleoK9Bxl5HZ5Kf/VeVr14V

On 13/01/2025 21:43, Jonas Smedegaard wrote:

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?

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 :)

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

I'd be interested in knowing more as well. 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.


--
Regards,
Ahmad

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.


Thanks,

--
Please do not CC me for listmail.

👱🏻 Jonathan Dowland
✎ jmtd@debian.org
🔗 https://jmtd.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2025-01-13 22:43:59 +0100 (+0100), 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

Out of curiosity, what does the Tinker Blend have to do with Debian
Wiki management? It's described as "a Debian Pure Blend which aims
to provide fully configured installations for various forms of tinkering/hacking on electronics and other hardware devices."
--
Jeremy Stanley

-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmeFktlfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCnYGw/9FoEl6RLtqn5svii484BhoRQh/j9vKr/uVtJeLfiPsHEWRsYHI+ksImU7 2ShzOLnid8n8BAkc8wbLK7aJCWk6h8PsB7aNn8lxZXh19A5MHXRJr/l9ybAVBQLm PL1ZFTbVsl7fCpY9gumpmsQnuXsT9YBOP+nBMPoVyW8TOmqJLxm/y49u9M/NHmmK eLKn/hUdTwBWvQVny8XdFsyFs7RuetNoHewsoHVNEnv/pBrp7L+GpN02SqEryya9 vhNpXP2BGbe5RFxQ9lilDv+zOSeEWm0ox9Vas8Z58c+FFj2avyISCqJIJo4m9MMo 04/wwWfvJfEerUOCdn/08UWz53LdbHVpy7VVm6QkX4IhAWBFe4cUvgAYPSYaKtNT klmtEOxxx0EQOXo3zGs5otgoVZo2Gr7J9BTbYqDa9T+ZlcKnV/2mu+eX7dEUkKr2 yarA1hPN5aUOakXXjyIP8fOlvJBMCAim6k2a8GraW185IurMDJRoCpDdExONxYWx oQlQ+zx4c+VzAUK1EB7S83U1YBQUieFSmN/Bn3MLx9luGPsbwlQsXgdBUTiAD5O1 tkuKkFbmMZHnW89Jp5+1NH9VNExG7RdDgOLWsoCjPxGCMFix6U6ZxM7UTTlPsh4W 0AjhZgaCSbiH0rJ8Idzb/fcLdsc6YwsrwB35M6PK0gR83XY52dM=
=Lz9/
-----END PGP SIGNATURE-----

--- SoupGate-Win32

On 2025-01-13 22:27:21 +0000 (+0000), Ahmad Khalifa wrote:
[...]

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.

Another free/libre open source software community I'm involved in
migrated a fairly large corpus of content (10k+ pages) from MoinMoin
to MediaWiki, mainly for access to more robust spam and abuse
handling features. The effort was managed by a community member who
was also a Wikipedia sysadmin on the WMF staff, and required a fair
amount of cleanup after the fact, so not for the faint of heart.
Granted, that was about a decade ago now; it's possible the tools
for doing it have gotten smoother in the meantime.

Having acted as a site admin and moderator on both, I can't say
there's anything I miss from MoinMoin other than the fact that it's
implemented in Python instead of PHP, which made modifying it or
writing custom plugins for MoinMoin myself a little easier and less
dicey.
--
Jeremy Stanley

-----BEGIN PGP SIGNATURE-----

iQKTBAABCgB9FiEEl65Jb8At7J/DU7LnSPmWEUNJWCkFAmeFmHJfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 QUU0OTZGQzAyREVDOUZDMzUzQjJFNzQ4Rjk5NjExNDM0OTU4MjkACgkQSPmWEUNJ WCnMgA/+M74nq4lQD4Qfc2yZ6nxshzrDQNCnZj0Svtgg+Pa1sVt7dHrPmgnHH36J SVrGT4CxqLkE0R6lK0XaYJjlg7nHBY6WgajjGjBiJuhiMbIlpZAXbp0JOWmiUOUA 6maTJAc3hU0X6Mfm4y4D/EqiOBqPBRNyyWREs6NG+GYwcL08+sRBKqXlo0alfEfB UQd2/OHJcLEb0w9NL2sL11zIqzUVDa7tSRxEOCdvpgBDCj4MNVhM9qhEBF+I+wEi tNhlx5W4rX2FmBS5ECLWhMmOOsk1rV1/56XL3sZia0plN9rskyyIrHn4XktK8SLJ tVP2ioUMFbzx5tgZUvrD1v83DAf7wkl4c257fF2TaW13imteITmx8z7M5QKZSGYM pOH3DMLJgLrzz2dKT6fM+ibHg3B00BdPTxC1/IKSMsza6ElkT4+Agf59Z04Jy1Gv jKlUE5HyW+6jRDyj3ZukS835rslE28JaWFIgnD1vTD803FGEjc8yJtz103IhHsIm Fwp28JBZ4YLvMUMdEftNGew7EHyKODa8049NMsTzpYbrBuZ2bSjtpPpJuuaGmC1e CGOa99r0QQs/oIPzyOZ4ur69HFim1qCYCmvDrAkEghrdA54nbdBj0geqsTsNV69S q5JlO0xTqyPbJ+oWQm6Z1GxRxiIP0h7fVQNKlrd0doMB7KgGRSc=
=GPS6
-----END PGP SIGNATURE-----

--- SoupGate-Win32

Quoting Jonathan Dowland (2025-01-13 23:15:35)

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.

People interested in lightweight systems, like the OSHW-certified
ARM-based laptop and server systems from Olimex.

There is no "MoinMoin" in that team, but very little is going on in that
team, and among those few people there have also been an interest in
hosting MoinMoin due to its neither being bloated nor PHP-based, and consequently some interest in migrating away from it in more recent
time.

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private --==============h03754117178762237=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

wsG7BAABCgBvBYJnhaCeCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmcDmXridk6Ayyj0tD6PEMqfnrvj87shj7AzvaE1GBCU aRYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAADohQ/+Nim5ApuPCqwY19fD91TZ+moQ X6dW1RZOTNndULv08NkMWdRvRxLW4s2xKmrnxUxLr4iOt5cGbVHJX8+VmT1dWL/J zMdQYRGESjmdAPAUsKXS2725zpnVJ943NZ3KVajrf/voFrE6EuGMyia5VOCe39P3 3rJ3xhJYwuvix7E8xp3zwgo8wOn2s8BMnyvsnIyW07PYd/h22P7piuK1HNVGTa1W tMAuxQzDNWnhB37PaXbwwkZsERUZzDtKDsBGlgCMJ24bihifR7tRI5WU8PwAoJJA XIKRIYFACqoHnZFDYZD6tHKTpPCdIEtrv0+f9WSfAuMAoPO9mWzArYwB5z7/7vOs SkE6cKpeO3Ibq1YAyfAwgXuwPjTNGlHChtNrfcEo

"M. Zhou" <lumin@debian.org> writes:

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.

Isn't the corollary of that statement that all the useful models
available have been trained on material that we have no clues about
regarding the status of the copyright/licensing?

Even without considering the case where the training data belongs to
some litigious corporation, the thing that concerns me is that these
models have presumably sucked up every scrap of e.g. GPL code on the
net.

Having done that, they produce answers that are somehow informed by that
data, without any indication of how they arrived at the answer, and
certainly not a notice that the authors who produced the training data
intended there to be restrictions on the use of their creativity (that
an ethical person would want to honour).

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?

Cheers, Phil.

P.S. AFAIK the likes of OpenAI declare that the output of the model
belongs to the prompter, but that strikes me as self-serving nonsense
that the courts will eventually rule on. I'd love to be proved wrong on
that though, because I'd quite like to play with LLMs, if only to do
things like generating potentially lethal cooking recipes to try out ;-)
--
Philip Hands -- https://hands.com/~phil

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3/FBWs4yJ/zyBwfW0EujoAEl1cAFAmeGF8cACgkQ0EujoAEl 1cBxShAAhZ8eNPA9/jHBm0yw/DoCfV2T7K69lquv7O/3iek12lcL8gwNKMlj4L66 lI5Bw7dkyQ+/1ItK0jfzGSUgrytc0AZ9O/gFPY4ofVPwzpcX7HSf+5+ZyUlR361y pWGVZEC7PN/wXvbGpdcIBYNMAIvAUWhH2xwJ7NK1TBPIbOib/aXX4nm4Eg0FiYJq xEG2McEpE6EdsrA1rXpxhs1ru+34+gtXfQtN66SjxXKSoYvhGEiozIppsMv22sJB IUTaLhhs5qorCYE1O9nMturGAkYtcOJ9FD/pLv6vojleixAdYFzUWqYhlVCevCRv Z8zz/uWYn4kPhWg3FEfPrlKv+FR+mealXG8X4ZafbAvbwB71KaAW2l37cZjzJmN5 eWc2N9i5YvLMJ6wfRVWpH1+Qa2SZloZziuIlSd3cfWabSR1bE4eSkE+rR+3LDw1y L3rflOMKtBt0XGTL2tNSvccIxuJqCU2klmVabZbLpfAD7m4TKRRaNRP1OIy+/DNI 5VV/nom/FafE3B8NOqLsdS2j/eVZGeYefrYy1t1CjBRApc/oTOWIO/rxSNsvrfeZ CShrHk3P/oA2x5ec5h/r6ZOaiDleMLXSRNusvEe5MBLoGumPREdMqvsKQKIct78e 6mAB/JvSrjsW/w66+wSEEqPw4qGopw7w+QhsUgjHz3N6Hf9lJwI=uvLt
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gatewa

On Tue, Jan 14, 2025 at 08:52:39AM +0100, Philip Hands wrote:

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?

Is this the same with reading some GPL code directly instead of using an
LLM that have read it?

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmeGGhQtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh EjcQAJtfNi+ra2zVjJHi9s9cT1GYKSUfn1zrIBoff52Y1rNhcyxcmVIF67CI5tW3 tvyAHB31ip6ny+2ImpJvIZeQ4eY9XvOysz9UiQZ4YqXpdG4POii6/ADboZYFE2pQ vVBUpP1Hbov9rfl11TUg0ysqVr2Q2iAsAGfjcTSzmYar0muEI4OSV29B+G+X58+l f5SMDsrnhM14JHYVpbJF1H8FzolspDhLYHA9i9i1z66EYBwXmHxIbwy1UL5gfj+z sRGz8MLNLvsH9P9oP+qQToy1a5G2ALY6Rn9CkgBt7XsNmaiKvk0aeEdr7SxgiY1V reS8D4ZdKIMyjBx8EPL2i3B3UFp7/n7c8CJ55OW6wlTapV7F1S8D2jeEh4zWBXCJ I6Xt9Fiwj8gJGGXD9NgDlnzxnEC/GLNvjzufa8QuyNVOJ7eXfBygJ0MhY68dAgho trL0V0xeXB4OPmoQVuZH0w1UFaPirHF2EDutouO9qO+k4byyBZH9+MmMNuOrwsZb 3jz2a9lTsAdHRDVJZsjKxUllZMfRNTAOqkvRONZeJP3LW8cORMoyHVyVJTalajFv yr+Dic2TW/w6waGgQ29AybZVG/mOCTs2Boy3NpjJFQgOyTSlbrgdC9EmcZyTVj02 tvlwfRJlnnKhddaCEnqzJ/ukVvhWRb/NqM6K1RYjrDi90t6L
=3Giy
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon Jan 13, 2025 at 10:27 PM GMT, Ahmad Khalifa wrote:

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 :)

The two git-backed wikis I am familiar with (IkiWiki, and GitLab) have a
full, traditional web UI for interacting with the wiki, and the Git
back-end is effectively invisible from that perspective, but, power
users have the ability to easily create a full backup of the full wiki history; perform large-scale or complex, machine-assisted edits on the
local copy; use advanced merge-conflict resolution tools.

Having said all that, I believe any effort to revamp the Debian Wiki
should start with determining the requirements and goals, rather than
start picking solutions.

--
Please do not CC me for listmail.

👱🏻 Jonathan Dowland
✎ jmtd@debian.org
🔗 https://jmtd.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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...

--
Steve McIntyre, Cambridge, UK. steve@einval.com Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

Offended...

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private --==============%30625836974125452=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

wsG7BAABCgBvBYJnhnyZCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmfsTnsAvuwygy0rY/t9oFt1iQm/dnmarPAbeYUUjlwG FBYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAAB77A//YeJyvdSXVPmsnkkYkmf834zn 54iP40hrP6ekl1fEDItXEO9JgR5zq3pymrnDoVEnaijW8owqtLw7ozsNGO/J6zxI 8Qb9M1immn/Ftl/l59Dg859UlNBPx0QWBxqnbC+ofVdzRYKCHh6FdCK70PjYaBep DirXISEPceq4xYWVrLSOdwLnBbyz4D4eNCdyAcSmVE3VDh+pd+Eob/PCCkTgsAcx NxGhvChDpTOkbpa5ulQeX7p1T6447Uo7OD11ukoMNWV247+TJgkohR1Rnqel1ypl 6USriv/Rwc6py7bSsk70sUPGdyzz0waUR+S0/N6Zf/k4d9/JjsrQwdq4SVdd+y9U 6/vPYH/Z8898TMndKcShcUL0K+ZUZFrQIpZxiuy/

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?

--
Steve McIntyre, Cambridge, UK. steve@einval.com Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Jon Dowland wrote:

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

*nod*

I think we have moin2 packages just about ready for use, but I have
worries: it's not simply a dropin replacement, and the first few
attempts I've made at migrating some test wikis didn't go very
well. And then lots of ENOTIME :-(

"We" are a small team running the wiki. Like a number of places in
Debian infrastructure, ongoing admin is a time commitment that it
seems very few people are ready to make.

--
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Quoting Steve McIntyre (2025-01-14 17:27:20)

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?

No, but that my proposal for discussion place was so out of this earth
that you felt the need to curse over it.

Obviously I am so fucking stupid that I didn't know that the wiki team
used same mailinglist as the www team.

I stand fucking corrected.

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private --==============p58005984343207030=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

wsG7BAABCgBvBYJnhphLCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmfzAI0QQzsLxFOvjNKQR0x7wkUSw8Dbb9CfFoYm9g4I kxYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAADo8Q/9GLm3DmBbWlrfAMAiSznCOCwC pn4Su2/VsrEfMuiFGq5GWa+tqBNBOCgfw6R3KM6x7rILREEA11tIWqf1JBDPfzyr wHEbEJMqlUSoWsgR7gMzH8vkq1gduPEzXZfw7gEuO/dU0XzU6KOwbz4yr9Zb0821 vdXuiHVzzGPhfJhObV1O+lvgVnkfRn+wax30KLFT/ouKKXVCjKqzGpSJCUeDiY+8 6RaOfztRTrVHW0ntnwAM1vtMC5436kugzYktxox2w8iHXSo0zUZjTkzRvALnzUDV VcIcqYyCL53gDZLl3CEV6Mecx2PKnZEP1igiX9Nm/42sljbPwUp5zWlBMk8qL8md 0yLmtNJT7y9bulIodcyE6asj+Xk5DJ2JC59Dl35V

* 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.

Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--
Cheers,
Andrej

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private --==============89488005009962021=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

wsG7BAABCgBvBYJnh5CJCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmffeSeW6UX2Xpjg8U9mB1qz8ZQ9yqbO9Zp+4i84Q8I4 wxYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAAAn4g//RkGY55zHjRAU3FHxEzTR+A1d Dh3CeusoD2jaLwJ51cRiqJBwNJOYtKaRhQtvCOFL2OyI6XMB6sDNGkB4bTmPrSZx 4VPUlAkdm7o7FqRoeN+I/04ORdhy3ccEg9cULYUdNQiIwwelM18T0DNEZo19jq3s 2VgC/mVg/e5E0sUIMEpAV+MnEQ54HytAqrz+dxT0x89HEEUwie4EB2O9FQUwe4Ik B/1EOrdQPi8vD6KwFrlcZ0gPbHC6JWIR6mM+mv6ipyekzBiNouoc2c0W4ig8RA0c m+1yKVq1xEL4DZcXS194Wh3tbe50WYUh6X6wYxLS9pwBxyTv5cFQLXRsRvhIZbG1 lxj1wqt+8eGoZXyn5RD+LXvHytDOmWa8fliVOycB

Quoting Chris Hofstaedtler (2025-01-15 11:44:19)

* 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.

Nothing. My posts here contribute nothing - they are not moving the conversation forward. Speaking just for myself, that is...

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private --==============87422599481955973=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

wsG7BAABCgBvBYJnh5huCRAsfDFGwaABIUcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmdaEDI3i9gC6jj9Jj1xPdNdcDxXpIzFf6n7chPN3ZK/ QxYhBJ/j6cNmkaaf9TzGhCx8MUbBoAEhAADCJA//UUnJvLNA5wfhYFcSmaw9SqRm jXyNY3a/LYXs/JmLEVDYy7PNNFb+KcJ2BiiKppRmhut6w/4HnaHcmhgU8CO8uZNF WGMxPBd2sqXpW8dCoWPpAHuUmfx/SBAWhojbISQjKxonmUAOe6LvR/pN6Y23636C FSDG0rWrhA02admQjpHDLR36df8AgkbBDYWt4XL7wBbYYpUwOUX6u0ysGT34h9+y KAsYT8QBML+UtcK4vQoKajaawjmABtJrL9nqryzB7XKSY0GUzMaakcT6SaY1eyW4 5g/s5pBEkUGmvvrDUIvJxMUYANxqmvkXhqrf4G9VSqAM29llux6h3718AWF5gI5h wglgMVJLV5tusBBW4dwnTOy4NBt/zrqwQmGXI8oQ

Hi Mo,

before going into criticizing things, I would like to thank you for your continued work in the AI space. In particular, your way of classifying
models into different degrees of freedom demonstrates how much you care
about Debian's values. I see that your focus is on enabling users and
that's amazing!

On Sun, Jan 12, 2025 at 05:01:33PM -0500, M. Zhou wrote:

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.

Disregarding the ecological and political aspects that have been
discussed elsewhere at length, let me also note that successfully using
a LLM is not trivial. Whether you get something useful very much depends
on what you ask. Typically, you should expect that something between 30%
and 70% of answers are factually wrong in some regard. As a result,
asking questions where the answer is not verifiable is not very useful.
Using the answers without verifying them poses a risk to us as a
community that myths are propagated and become harder to falsify. We are talking about ai dementia already and can observe it happening. How do
you see us mitigating this problem?

That said, it can be useful to use a LLM if your premise is that you
verify the answer. For instance if you are searching for a library
function that does something particular, searching the documentation can
be time consuming. Describing your function to a LLM and then looking up
the documentation of the presented suggestions has a significant chance
of turning up something useful (in addition to the rubbish included).
Likewise, searching for a particular statement in a mailing list thread
can be a daunting task where a LLM may be able to interpret your vague
memory sufficiently well that it can provide a few candidates.

This way of using LLMs is effectively limiting it to behave as a search
engine with a different query language. I suspect that most of us use
search engines all day without thinking much about them being driven by corporate actors running big clusters. Is using LLMs in this way that
much different from using a search engine?

Ecological and economical reasons aside, would anyone see an issue with providing an AI-driven search engine to Debian's documentation, mailing
lists, bugs and the wiki?

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.

I am actually looking forward to this as I trust you to do it in a
responsible way given your earlier work.

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.

Indeed. I can imagine that a LLM may be able to also suggest particular
lines in a build log that may hint at the cause of a failure whereas we
now have a set of patterns (e.g. "Waiting for unfinished jobs") and hope
that one of them locates the problem.

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.

I have not experimented with DebGPT yet. Maybe I should. Unless already
done so, let me suggest that you engineer the default prompt in such a
way that your LLM references its information sources whenever possible.
Also including some text that asks the user to verify the answer using
external sources may help (in an opt-out way).

Practically speaking, the use of neural networks is not something we can
stop even if we wanted to. In ten years, all of us will be using neural networks on a daily basis. Even today, they're difficult to avoid (e.g.
when dealing with customer service of any corporation). The best we can
do here is making the use of them as free as possible and that's what I
see Mo is doing.

Helmut

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed Jan 15, 2025 at 12:37 AM GMT, Kunal Mehta wrote:

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.

Please note that git ≠ GitHub or GitLab, and the PR/MR workflows are
just one way git is used. I can see the advantages of accessing wiki
content with git, but I also agree with you that wikis need openness
of editing (in fact I think that's a core principle of what makes a
wiki, a wiki)

The two are not incompatible (even if MR/PR-style approvals are). For
example anyone can go and edit ikiwiki.info, either on the web or by
cloning the git repository and pushing their commits back.

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.

Thank you.


--
Please do not CC me for listmail.

👱🏻 Jonathan Dowland
✎ jmtd@debian.org
🔗 https://jmtd.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Steve and others with interest in wiki.debian.org!

I wanted to follow up on this thread and advertise that Steve is
running a BoF session about the wiki future at DebConf: https://debconf25.debconf.org/talks/146-debian-wiki-bof/

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.

Maybe you Steve could invite people to the BoF in advance to ensure
there is good attendance at least by the people who have publicly
committed they would be willing to work on upgrading/migrating the
wiki?

I probably won't have bandwidth to help with the software part, but
feel free to add me as co-organizer in the BoF if you want further
help with the BoF session itself.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun May 25, 2025 at 5:37 AM BST, Otto Kekäläinen wrote:

Hi Steve and others with interest in wiki.debian.org!

Thanks for the ping. I was aware there's going to be a BoF, and
(schedule permitting) I hope to attend (virtually).

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.

I think this is worthy of discussion, but I hope it doesn't dominate the
whole BoF: there's only 45 minutes, and several other wiki topics to
cover.


Best wishes,

--
Please do not CC me for listmail.

👱🏻 Jonathan Dowland
✎ jmtd@debian.org
🔗 https://jmtd.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On 11/01/25 at 19:13 -0800, Otto Kekäläinen wrote:

...

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 :)

Did something happen about this?

I saw that OpenAI released Codex CLI[0] (an alternative to Claude Code). Quoting the README:

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.
Please roll me (and potentially debian-ai@lists.debian.org) in the CC list.

On 6/4/25 11:04 AM, Lucas Nussbaum wrote:

(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

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><font face="monospace">Please roll me (and potentially
<a class="moz-txt-link-abbreviated" href="mailto:debian-ai@lists.debian.org">debian-ai@lists.debian.org</a>) in the CC list.</font></p>
<div class="moz-cite-prefix">On 6/4/25 11:04 AM, Lucas Nussbaum
wrote:<span style="white-space: pre-wrap">
</span></div>
<blockquote type="cite" cite="mid:aEBggpb5oRsCotyH@grub.nussbaum.fr">
<pre wrap="" class="moz-quote-pre">(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] <a class="moz-txt-link-freetext" href="https://github.com/openai/codex">https://github.com/openai/codex</a>
[1] <a class="moz-txt-link-freetext" href="https://openai.com/form/codex-open-source-fund/">https://openai.com/form/codex-open-source-fund/</a>

Lucas

</pre>
</blockquote>
</body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Die meisten Menschen können sich eher das Aussterben der Menschheit vorstellen als das Ende von Herrschaftsideologie und Kapitalismus. (@elektra_42)

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmhBgckACgkQCRq4Vgaa qhzSDxAAuf9cqhmv1IbhDKP72FEhGHRnZJd9pTIuq1Q3r65PV3dEqJe6lzWp4YUs 5ZcmfA4NK58pTEhXnDEXz7t0ACyUiZvmpWU7LsZBiqDR2u6YwfqmBUdtEvPJzm8k /5w6AjR1Q+T+mZYv9qgVxb1wqPuIy1RDNKQ/3GnpPTHfXi9rMGVXc5d2sYeE6My7 6kFvX3jERObzPf9F7uOKv8rISxlYhXRSrAS54IxroItsPtl+HBob4taLr43TuEM8 52wISc/8+RSvXFG2hxk90AyfKmMsSoKcbxeuGmHkYl1oPOL9JLeCiOoLSQrFmCrR ByRCSLQ123LaOavAPiN8eEmPPJ4ApiBP/NcfHTUxMikU9+1QOxK94xeocYtl8nNZ d/OWYOnp12EqKGX0iR5cueTpq6ni63CyWhD3vyx8RK+5mDbaZTfs/s7UXmrB8+S+ hqB9djF5yQj/jCUCus3nsoOWmas2i8TVQLc5tgvbzRB4iHB3aMZiMq2YE/s/oXRn uCMfe2WAx308TTZwPN1K51+J8bAn

On 05/06/25 at 11:38 +0000, Holger Levsen wrote:

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.

Maybe. Honestly, I don't know.

Based on my limited experiments on this (everyone, feel free to correct
me), in the specific context of AI-assisted Debian development, the
question is threefold. As a Debian contributor, you would needed:

(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").)


As Debian, we should probably care if (A) is free software, and
ultimately package those in Debian. Currently the ecosystem is not quite
there yet, but that doesn't sound like a super-hard problem (there are
attempts at free alternatives and no real blocker). Those could go in
Debian main: it's not very different from packaging an OpenAI API client (python-openai) or a GitHub client.

For Debian, the real question is about (B). Should we just accept that
the best services are the commercial ones currently, and if they can
help us make Debian better, embrace them? After all, we:
- use commercial CDNs to distribute packages
- rely on cloud providers for hosting various services
- fix issues detect by tools that are not free software
(I don't have an answer for that question, but I think that it's useful
for us to investigate how AI-assisted coding could help us)


Note that I don't buy the 'AI produces crap anyway' argument: after experimenting with Claude Code and Cursor, I'm fully convinced that they
can help with some of the tasks involved in Debian development (and
their ability to help us will probably only increase over time).

Also, I don't think that the question is "should we trust AI-generated
code" at this point (and if it was asked at this point, the answer
should be a clear "no" in our context). We should continue to require
that contributions are linked to a developer who made reasonable
efforts to ensure that no errors were made, and are able to act
responsibly if that fails somehow.

Lucas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Fri, 2025-06-06 at 10:33 +0000, Holger Levsen wrote:

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.

The four freedoms of the FSF explicitly include "the freedom to study
the source code [and make changes]". Presumably this is not limited to
specific use cases just like the freedom to run the program as you
wish.

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, crypto currencies, blockchains and lots of other
things. Arguably some of these things might have less value than LLMs.

Ansgar

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Fri, 2025-06-06 at 10:51 +0000, Holger Levsen wrote:

On Fri, Jun 06, 2025 at 12:48:11PM +0200, Ansgar 🙀 wrote:

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,

horseshit. those things dont require dozens of entire powerplants...

Smelly bullshit. Just because planes don't fly with electric power,
they still require energy. And data processing already required
multiple powerplants before LLMs came along.

Ansgar

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

We are not moving into a 1.5C world, we are briefly passing through it in 2024. (James Hansen)

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmhCw98ACgkQCRq4Vgaa qhwclBAAu14RnHmdwPLbiXszl4dkeP40wX15Etu4ti3mw1VwdwEv8KkTkJJ/3IGF dQSHDpSlotonc7fFkALSWXVTnnUnIVFZ9GyPP869dap9ZP9Mh9VZq18e0r+V/U5W y5PToSvC9x74I2400MRpAnyHfUP0HwAzKBRBjN1EWHDfw34EEXx7wffj9r4BKwhG fBIgkr4/h45NGkgi63L2tlKXPM9vncUbeATCgYl+vPJvRKDkHfProjpnxRZ6s951 lHrLnsv1bJhFF+NqVXC7W73DX12NijhmcyVBNgBvJ4gscG9yptavGHFoPg0oALwC 6yf8990nSxMWCwKnkJGpJyUmIMd5qU36vwOLF5M2Frs2En7VzaUfX9JBHVa4y/Qj O8gYXOy0AyqcNsnLu+qzVTsJ5f2FgE+B/z9XZHpAHs1ZhQpMbdndhgu6EQXb0DaU T1PejMzebz2+lUCtqfjkqZbZSjeqoQ3TS2sXZ99msfqf1bKhu4AFzfdLrU4n9UGv NDVM6dlz2qp42NYBKz8zvRxKfXLZR/8XYozUVkmJr9yi4s7tPCAs25CooWzFcDVD te6ak+lNfsWUaHYZK

On Fri, Jun 06, 2025 at 12:48:11PM +0200, Ansgar 🙀 wrote:

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,

horseshit. those things dont require dozens of entire powerplants...


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

The purpose of propaganda isn't to make you believe something. It's to make you believe nothing. So that you do nothing. (@DarthPutinKGB)

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmhCyEQACgkQCRq4Vgaa qhxIXw//ezjugM+0Vz+RRff/82wb0KQXorbefZO4QsVF9TETHXZonCBeU25b5uP8 rIPXmZUuSMa2NUKhbguzspcDLuoSJnff44zLprP2C65aq8rGKh9n8IejGi+yGvcx 8O/rRvjs4xCmJUrEoVhjz1bT2Ul9kFQdi1ajiNZLc92jpNDkXq/r1QkotDWBhp75 tAnulfz8CV204te3hk37anIlVesjRlicotwSJI37Ks2eyTA5/DZdTTa1UNE/RNtJ 22Vf4t+Ut7+ez8fs6mWLl3kkqKHmfIbmds3hiDkkTioKvGZsBPKrtV/Q66xzw9Vp jPNhQXNWlB08G7VAhJ15JMmfyRR+3MtYV6P3qVS1xKK9cFRDo7R5CgDpxy+fVwfy yEwEo1IkN/c43xmRnkHM0vft/wKDAx+46XxfEi2K47D0iaBpqf5+mkSngdZzCIli LSP9Es+TPzhshQISbo7KtNUKURFMlAguptbKVRfgnol6VoQf4fpQQos8qcVfqBxd T54Olgi4pDfcopzvZWrrbAUA66irqMO4oFHTNz1C

Hi!

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.

I still think it would be a nice perk for DDs, along the other perks
listed at https://wiki.debian.org/MemberBenefits

It is up to each DD to decide how to use the tools and services.
Personally I don't recommend using them to generate code as in the
Debian context they seem to output so much bad results, but using
LLM's for example to review code seems to be working pretty well and
is faster and cheaper than waiting for humans to review (and humans
can still review, they will just seem more polished stuff).

...

(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).

All of the above are closed-source solutions. I have been playing
around with the fully open https://aider.chat/ for well over a year
and I would recommend it instead. I hope to some day write a blog post
about how I run it inside a container safely and how I have customized
it to give better results than what it does out-of-the-box.

(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)

I am a big fan of OpenRouter.ai, but they are just a router. I would
like to see the actual model trainers contribute back to open source
by issuing free API usage to Debian Developers etc. If you have time,
please reach out to the three companies you mentioned. I had hoped
that the Debian Machine Learning team had direct contacts to these
companies, but apparently not.

(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").)

I usually look at these leaderboards to see what currently yields the
best results with specific models and tools combined:

https://aider.chat/docs/leaderboards/
https://openrouter.ai/rankings

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/06/25 at 22:10 +0300, Otto Kek�l�inen wrote:

Hi!

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.

I still think it would be a nice perk for DDs, along the other perks
listed at https://wiki.debian.org/MemberBenefits

It is up to each DD to decide how to use the tools and services.
Personally I don't recommend using them to generate code as in the
Debian context they seem to output so much bad results, but using
LLM's for example to review code seems to be working pretty well and
is faster and cheaper than waiting for humans to review (and humans
can still review, they will just seem more polished stuff).

My experience is a bit different -- I've found it useful to treat the LLM
as an inexperienced coworker:
- decide on what I would like to do
- ask the LLM to do it
- review carefully
- refine what the LLM proposes either by asking with more details, or
edit directly

(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).

All of the above are closed-source solutions.

Not Codex CLI

I have been playing
around with the fully open https://aider.chat/ for well over a year
and I would recommend it instead. I hope to some day write a blog post
about how I run it inside a container safely and how I have customized
it to give better results than what it does out-of-the-box.

Right, aider.chat came up in another discussion, and looks promising.
There was an ITP about it (#1082026, abandonned).

Another Free Software alternative is Zed (https://github.com/zed-industries/zed), but it looks less open in the
spirit than Aider.
Other closed-source products are WindSurf, Augment Code.

Lucas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

All of the above are closed-source solutions.

Not Codex CLI

Indeed, I guess I need to try it out now to evaluate it.

I have been playing
around with the fully open https://aider.chat/ for well over a year
and I would recommend it instead. I hope to some day write a blog post about how I run it inside a container safely and how I have customized
it to give better results than what it does out-of-the-box.

Right, aider.chat came up in another discussion, and looks promising.
There was an ITP about it (#1082026, abandonned).

Yes, I am in 'X-Debbugs-Cc' for it as it was my mentee working on it,
but dependencies turned out too complex.

Another Free Software alternative is Zed (https://github.com/zed-industries/zed), but it looks less open in the
spirit than Aider.

Zed is a full editor, written by the same authors who originally did
Atom at GitHub, which later got killed by Microsoft in their push for
VS Code, and then Atom reincarnated as Pulsar. I still use Pulsar but
might switch to Zed (ITP stalled at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=10761659.

Anyway, I am glad if you can contact the major LLM producers and see
if they want to offer free API access to Debian Developers. Healthy
scepticism is good, but we should not categorically dismiss use of
LLMs.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On 6/12/25 16:42, Lucas Nussbaum wrote:

My experience is a bit different -- I've found it useful to treat the LLM
as an inexperienced coworker:
- decide on what I would like to do
- ask the LLM to do it
- review carefully
- refine what the LLM proposes either by asking with more details, or
edit directly

My feeling is that LLMs are not really useful in the context of newcomer onboarding, neither as a resource we want to make available to newcomers
for "easy tasks", nor as a tool to produce documentation aimed at newcomers.

The only thing worse than no documentation is wrong documentation, and
I've had the "pleasure" of reviewing way too many merge requests where
someone ran a .pot file through Google Translate and submitted that, or
had an LLM generate Doxygen documentation for the entire project to make
the CI warnings about undocumented structs and functions go away.

This is still a compilation process, so it *removes* information. It is
not reproducible because it also adds randomness, and it merges a
massive lossily compressed database in the process, but the actual
information that needs to be conveyed comes from us, and we need to take
care that any processed form of that information that we publish is
still accurate. This is further complicated by the fact that the
database we're merging contains potentially conflicting or outdated information.

Simon

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Lucas,

Thank you for bringing up the idea of Debian applying for the OpenAI
Open Source Fund. I appreciate you taking the initiative to explore
potential funding opportunities that could benefit DDs who might decide
freely to profit from it or not.

Since you've asked for DPL approval, I hereby approve your initiative to explore and apply for the OpenAI Open Source Fund.

Kind regards
Andreas.

Am Thu, Jun 12, 2025 at 09:42:48AM +0200 schrieb Lucas Nussbaum:

On 11/06/25 at 22:10 +0300, Otto Kek�l�inen wrote:

Hi!

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.

I still think it would be a nice perk for DDs, along the other perks
listed at https://wiki.debian.org/MemberBenefits

It is up to each DD to decide how to use the tools and services.
Personally I don't recommend using them to generate code as in the
Debian context they seem to output so much bad results, but using
LLM's for example to review code seems to be working pretty well and
is faster and cheaper than waiting for humans to review (and humans
can still review, they will just seem more polished stuff).

My experience is a bit different -- I've found it useful to treat the LLM
as an inexperienced coworker:
- decide on what I would like to do
- ask the LLM to do it
- review carefully
- refine what the LLM proposes either by asking with more details, or
edit directly

(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).

All of the above are closed-source solutions.

Not Codex CLI

I have been playing
around with the fully open https://aider.chat/ for well over a year
and I would recommend it instead. I hope to some day write a blog post about how I run it inside a container safely and how I have customized
it to give better results than what it does out-of-the-box.

Right, aider.chat came up in another discussion, and looks promising.
There was an ITP about it (#1082026, abandonned).

Another Free Software alternative is Zed (https://github.com/zed-industries/zed), but it looks less open in the
spirit than Aider.
Other closed-source products are WindSurf, Augment Code.

Lucas

--
https://fam-tille.de

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE8fAHMgoDVUHwpmPKV4oElNHGRtEFAmhKpdMACgkQV4oElNHG RtEp9hAAgIA0hsujdVfg9x8+iJ0UJtPyKfkrqb5GHZSpPJDwBv1HxwrZmtrthFUL sV+0mXEOay0FJx7RB1lypiPCQo9c77g/JeB25aqr3OL8BMktXTv/WsPHJsHvutR4 iG7UV6VzXLWZHPw0cdqafeog4XNG895C3wawJOFvrnBdD6hYwwcQcawB55tTLl3w n86sgy2yZ3JNkBm5nb/1m5TIosAxS5NvwVKChCgR454tKy5pLo0U+mVsVCTq7YV+ 8bZCrZ4Ngg2+DTBjAl53UzEdXIPQYTMK6nojMObgXZWNydON0ooRFsWWFdMcl3is x6yDuhJzZpmtJaJ8pZccwCbRtujuqjYjWq4GTE4oabtQFZbBwCj7qkfeFCR2RpaL 90MhnO+EVWLeFuB0krLEe1mO4I6lAImkh4dKX2F7geCoIAm9hyR5lEuNaHAKg5i1 syAErbRzSKsLOUQkLzj6rWGzjzu80eg+u6J5J4FNCRCGPKeZZm3XbageKuO1dR9H J8KGcYeMSGCV2GP6LYvcZXIejd23penZd5arfq5mB/12XX4DZEBio8FwMyVrnvHh oYdT0tmyW8gesZVnXStS8zNOP3pxnJQfGXeBpC0llORRfAdWbsT5tRnwiOMPYXqT 8paOEWaaBKP98H5hc3crLXoRM0qjFeFl/zF9qGFhSZBhlr2L0Bg=
=AbtL
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)