Apologies for spamming, autocomplete added the wrong "developers" as
recipient for this email.
Hi!
Congrats on the MariaDB 11.8 release! So far in Debian and Ubuntu no
regressions have been reported and looks everything is working well.
The most frequent thing I see people complain about is not new to
11.8, but I think introduced in 10.4 with InnoDB refusing to start if
crash recovery is n
> [...]
> > The big question here you seem to avoid commenting on is what is
> > the workflow you expect the next generation to seriously adopt?
> [...]
>
> Perhaps playing devil's advocate a bit, but why do you assume that
> young people are incapable of learning and using working,
> established s
..
> over a mailing list. And people who uploaded the patch to a Forge
> won't see the comments in the Forge's pull request. If they don't read
> e-mail, then they won't see the replies --- just as people who don't monitor
> salsa won't see the pull requests. Oh, well
You are aware that
> > If you are concerned about the PR being updated without you noticing it
> > (very unlikely), you can git pull it locally, review locally and git
> > push on mainline, which with all modern Forges will automatically close
> > the PR/MR/issue.
>
> Yes, that would also work. That's not what people
Hi,
> In general, no. Using a forge introduces numerous opportunities for race
> conditions (reviewing a PR and having someone else update it before you
> merge it, for instance) and compromises of other systems (the forge shows
> you something different than what it would merge when you press the
> > After a `git fetch` or a `git pull` it is very easy to review what
> > the change is or diff it against the current main branch. There are
> > a bunch of tolls, including of course the usual gitk and `git
> > difftool --dir-diff` + Meld.
>
> The problem is that it's also very easy *not* to do a
Hi,
> If some debian developer wants to make it to be their special mission
> to help out new contributors, and be that ombudsperson to review
> patches, and tell them how "no really, you need to follow the
> upstream's documented requirements for code submissions[4]", or "gee,
> it appears that y
Hi,
> I would recommend you first create a bug and an associated MR. Then, if you
> get no response (which is obviously different than a NACK), you can choose if
> you would like to salvage the package or if you would like to leave the MR
> there for someone else who to to come along and salvage
https://www.debian.org/devel/join/ already says:
"As a prospective developer, you should also subscribe to debian-mentors.
Here you can ask questions about packaging and infrastructure projects as
well as other developer-related issues. Please note that this list is meant
for new contributors, not
> > 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
>
han yet another new page pop up to add to burden of
documentation new people need to wade through..
- Otto
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
> >As unfortunate as it may sound, some of this is actually true. The worse
> >part is
> >if the newcomers want to chat, the official media in Debian for that is IRC,
> >which
> >is hard to use and setup a bouncer and so on. I don't argue against making
> >our tooling
> >better.
>
> Do you serio
Hi,
> Perhaps, to ease the burden of those of us maintaining many packages,
> we could instead have this more complex rule:
>
> > The default debian branch is the first available of these, in order:
> > 1. debian/latest
> > 2. debian/unstable
> > 3. debian/experimental
If no other information was
have gone without a review for months
- Review your project webhook settings and use of
https://salsa.debian.org/salsa/salsa-webhook to have MRs and Salsa
commits automatically update bug reports
Thanks!
- Otto
did see it and
added a comment to the bug report. Hopefully you can follow up with
the logrotate snippet.
Feel free to request a review from me if the maintainer is too busy to
review your next MR.
- Otto
Hi!
> Arguably, such setup is spam: I is a bot that messes with the bugs but
> is not accountable for its actions, since it is only a one-way
> communication. Sure, I can then investigate the email and figure out
> which non-email side channel might reach the true originator of the
> bot activity,
eir learning journey and can't cope with too many options, in
particular these two:
- https://optimizedbyotto.com/post/debian-packaging-from-git/
- https://optimizedbyotto.com/post/debian-source-package-git/
I have tried my best to make them relatively short, concrete and
illustrative with diagrams etc.
- Otto
and
contribute to fixing it, and report back to this list if the thing is
owned by someone who is reluctant to accept contributions to get more
visibility.
- Otto
> I endorse basically all of this. (I had really hoped to be able to put
> significant effort into modernizing debbugs over the past year or so,
I understand time is always a limitation, but if/when you have time
for debbugs, could you please prioritize reviewing/merging the open
MRs?
I would as
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.d
> >Please don't make strawman arguments. If you read the links I provided
> >and the how Guix folks summarized their needs, you can see that
> >maintaining the e-mail capabilities was one of their main
> >requirements.
>
> I have seen Debian discuss introducing Discourse to replace the
> mailing li
> I would significantly reduce my enjoyment of Debian if we were to move
> away from mailing lists and the BTS. Surely the BTS could be a bit
> more friendly in its advanced features, but new contibutors can simply
> ignore those, and a motivated person mght build a nice web interface
> for those.
Hi!
I came across this post https://issues.guix.gnu.org/76503 in Guix
where they discuss how to improve the contributor experience, and in
particular what technical changes they are doing.
Guix is interesting as they use a clone of Debbugs as their bug
tracker at https://debbugs.gnu.org/cgi/pkgre
On Wed, 16 Oct 2024 at 10:42, Daniel Baumann wrote:
>
> On 10/16/24 18:18, Iustin Pop wrote:
> > Gitea/Forgejo are common recommended solutions for "home hosting", but
> > neither is packaged.
>
> (jftr) I'm currently working with Forgejo upstream to get one last
> feature implemented that we'll
Hi,
> > * Package name: gwh
> > Version : 0.6.14
> > Upstream Contact: Roland Mas
> > * URL : https://salsa.debian.org/lolando/gwh
> > * License : GPL-3+
> > Programming Lang: bash
> > Description : git-buildpackage workflow helper
> >
> > This is a wrap
Package: wnpp
Severity: wishlist
Owner: Otto Kekalainen
* Package name: golang-github-xo-tblfmt
Version : 0.15.1
Upstream Author : XO and Kenneth Shaw
* URL : https://github.com/xo/tblfmt
* License : Expat
Programming Lang: Go
Description : Streaming
Package: wnpp
Severity: wishlist
Owner: Otto Kekalainen
* Package name: golang-github-ziutek-telnet
Version : 0.1.0
Upstream Author : Michał Derkacz
* URL : https://github.com/ziutek/telnet
* License : Expat
Programming Lang: Go
Description : Go
Package: wnpp
Severity: wishlist
Owner: Otto Kekalainen
* Package name: golang-github-google-goexpect
Version : 0.0~git20210430.ab937bf
Upstream Author : Google
* URL : https://github.com/google/goexpect
* License : BSD-3-clause
Programming Lang: Go
Package: wnpp
Severity: wishlist
Owner: Otto Kekalainen
* Package name: golang-github-mattn-go-sixel
Version : 0.0.5
Upstream Author : Yasuhiro Matsumoto
* URL : https://github.com/mattn/go-sixel
* License : Expat
Programming Lang: Go
Description : Go
Package: wnpp
Severity: wishlist
Owner: Otto Kekalainen
* Package name: golang-github-gohxs-readline
Version : 1.4
Upstream Author : Luis Figueiredo
* URL : https://github.com/gohxs/readline
* License : Expat
Programming Lang: Go
Description : Go
+Jelmer, who is the maintainer of the metadata specification
> https://wiki.debian.org/UpstreamMetadata
>
> That's pretty much where we are now. This was done in the pre-Salsa time, and
> if people get excited about the concept, I guess that Salsa offers new
> opportunities to play with the conce
> > >> debian/README.source as described in the developers-reference.
> > >
> > > It would be great also to have an easy way to cherry peak from the
> > > upstream
> > > git repository in order to prepare patch series.
> > >
> > > Do we have a tool around DEP-14, which allows this ?
> >
> > Well,
> >Regarding "I don't want a gbp.conf", I think that we should aim for DRY,
> >and that adding a gbp.conf in every package doesn't sound too great for
> >teams that maintain hundreds or thousands of packages...
>
> Yes, please.
That could have been an option 10 years ago when people were creating
> > I think this significantly underestimates the annoyance involved in renaming
> > existing long-lived branches (in that all clients have to re-clone or
> > manually adjust), which is certainly why I generally avoid doing so unless I
> > absolutely have to.
...
> This could even be something that
Hi
> So, it looks like among the largest packaging teams, only the go team,
> the gnome team, and the php team have significantly adopted DEP-14.
>
> Note that this is not a criticism of DEP-14, only an attempt at
> providing numbers about DEP-14 adoption.
I have published similar stats before an
Hi!
I think Soren and Antonio summarized what I am thinking as well. If
there are seemingly unmaintained packages and we have people who are
willing to take care of them and update/refresh them by doing
something between a small NMU and a full-scale adoption, then that is
only positive.
On Wed, 7
> I'm interested in package popularity. I'm aware of popcon
> (https://popcon.debian.org/), but I'm more interested in actual
> downloads.
I am also interested in usage statistics. I feel it is much more
meaningful to work on packages that I know how have a lot of users.
While neither popcon of d
Hi,
> > >For what it is worth: I use `adduser` outside maintainer script.
> > >
> > >I think I'm not alone in that.
> >
> > Useradd has grown most of that functionality in the last two decades.
> > That leaves no space for adduser between useradd and sysusers. At
> > least not enouch space to wast
Hi,
I am not able to reproduce the test failure visible at
https://buildd.debian.org/status/fetch.php?pkg=insighttoolkit5&arch=amd64&ver=5.4.3-2&stamp=1745014062&raw=0
in a local build myself, so I can't help with that. I did however
notice that the size of the resulting packages were quite small
Package: wnpp
Severity: wishlist
Owner: Otto Kekäläinen
* Package name: usql
Version : 0.19.19-1
Upstream Author : xo
* URL : https://github.com/xo/usql
* License : Expat
Programming Lang: Go
Description : Universal command-line interface for SQL
Hi,
> Unfortunatly1 I have to ask this question, as this is not how you and
> (your|the) salvaging team is operating at the moment - IMHO.
>
> I acknowledge, while -- after being scoulted -- the approach how to
> handle ITS' by the team has changed, it continues to move or create
> repos of projec
> > Just out of curiosity, what email client and plugins do you use to
> > achieve your optimal email-based workflow?
>
> I don't see where Wookey made a claim that his workflow was "optimal",
> merely that it was effective for him personally. Debian Developers are
> a diverse bunch and approach p
Hi!
> >But the core of my question here was about the apparent conflict of
> >signing up for LowThresholdNmu as an indication that you are open for
> >collaboration, yet not having the package in VCS, which would make the
> >collaboration easier. I am trying to understand why certain people
> >obj
> NMUing is working on packages that someone else are responsible for,
> without coordinating that work ahead of time, just informing after the
> fact that the changes was done (and then being responsible for any mess
> the changes might cause).
Surely not "without coordinating that work ahead of
Hi,
> > > Question: Should uncoordinated NMUs unilaterally choose Salsa as the VCS
> > > for a package?
> >
> > Why are you opposed to using Salsa as the VCS for cpuset? You use
> > Salsa for many other packages and Github for some others.
> >
> I am not opposed to using Salsa. As you note, I alre
balls
checking it at least superficially.
- Otto
How about adding a new header field in debian/copyright
(https://dep-team.pages.debian.net/deps/dep5/) called something like
"Reviews" which would be a list of URLs pointing to whatever public
system was used to record a review?
Then whoever reviews the debian/copyright file has easy access to
rev
Hi,
> > Apparently the problem isn't that no help is needed but that nobody has time
> > to train the new help, citing possible burn-out trying to get answers from
> > the
> > existing members and leaving in disappointment, if not disgust. (My
> > interpretation …)
> >
> > While that's a valid co
Hi!
> Around 12 years ago, I proposed a peer-review system to increase the quality
> of
> the packages in the NEW queue. https://wiki.debian.org/CopyrightReview
For packages that I sponsor, I already do reviews of the
debian/copyright and all other files. These are recorded as Merge
Requests in
Hi!
> > Salsa CI has had for many years the job 'missing-breaks' that
> > complements piuparts by checking that the files a package introduce
> > don't clash with files shipped by any other package in the
> > distribution without having proper Breaks/Replaces in the
> > `debian/control` file. This
Hi!
> Given the above four points, I propose the line from the code of conduct
> quoted above be changed to read:
>
> “There is no expectation that emails sent to the mailing lists are wrapped by
> the sender at a particular column, but those sending emails may wrap them if
> they choose.”
>
>
t
no other changes has been pending almost two months, and the new
contributor Travis Wrightsman has been mostly idle with his Debian
work just waiting for the package to pass in order to proceed with new
Godot version.
With this experience I am surprised that one FTP-team member is saying
that no help is needed? I wonder if that really is the opinion of
others in the team too?
- Otto
Thanks for the feedback!
Ideally the script
https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/images/scripts/check_for_missing_breaks_replaces.py
would live in the devscripts package and be extended to have the
features suggested in this thread. However, even in its current form
it ha
Hi all package maintainers who use Salsa CI,
Salsa CI has had for many years the job 'missing-breaks' that
complements piuparts by checking that the files a package introduce
don't clash with files shipped by any other package in the
distribution without having proper Breaks/Replaces in the
`debia
Hi!
Sorry, my email client auto-completed as the "developers" mailing list
the one I usually write to, and not the one this was intended to be
submitted at...
Anyway, I am sure there are some Emacs users here too and if you never
heard about Magit+Forge then maybe this was useful info.
> [1] htt
oming contributions. Also some parts of the
contributions process are not very optimal, and the process is likely
to become smoother only if enough of current core developers at least
occasionally "eat their own cooking" and experience (at least parts)
of the contribution process.
-
general, if anybody wants to take a stab to improve it, feel free
to add me as reviewer in MRs targeting this script.
- Otto
PS. Props to Johannes SMR for reviewing and testing the script in past months!
Hi!
> > I'm going to have to disagree with this part, the whole point of DEP14
> > is that our debianisms are namespaced, so there's no harm in pushing
> > all branches.
>
> Are you really sure that there is no harm in, for example, pushing all
> the 5785 (and counting) branches of https://github.
Hi Rene,
> What should debian/latest be? The latest upstream (pre-)release? Aka what is
> in experimental? Or not even there,
> just preparing stuff for experimental?
This is a good question, as it goes to the core of why DEP-14
recommends debian/latest first, respectively in the debian/unstable
> Is there some way to drill down into groups and then set preferences on
> an individual repo that's not in one's own namespace?
Yes - you can for example open https://salsa.debian.org/debian/openqa
and in the top right corner click on the bell icon, and select
"Watch". That will make you get not
Please explain to me how I am failing to read correctly what you meant
> by that last paragraph I cite above, Otto, because I cannot believe that
> you are really arguing the above - I must be mistaken.
>
> Please help me assume good faith.
First of all, thanks for maintaining 1000
Thanks everyone for sharing your viewpoints, it is interesting to read!
I feel I need to clarify that I am not a native English speaker and my
intent was to write a polite and honest email. It does not say
anywhere that "you must use debian/latest". I am happy with whatever
the convention is, as l
Hi,
On Thu, 23 Jan 2025 at 17:52, Wookey wrote:
..
> Right. I look at bug reports for my packages (eventually). I have
> never looked at a Salsa merge request in my life. That's just
> /dev/null for my packages. That could change one day, but I don't know when.
Could you give it a try please? Sa
Hi!
Current https://dep-team.pages.debian.net/deps/dep14/ states that the
default Debian branch name is 'debian/latest':
> In Debian this means that uploads to unstable and experimental should be
> prepared either in
> the debian/latest branch or respectively in the debian/unstable and
> debian
Hi!
> I think it would improve collaboration a lot if we could make an effort
> to get salsa projects into one of two states:
>
> * Merge requests are disabled for that project
>
> * Merge requests are actively watched at least as closely as the BTS
We should revisit the decision to have email no
Hi Matthew!
> > Numerous people are posting Merge Requests on Salsa. Please help review
> > them!
>
> I'd much much rather MRs were associated with bug reports; that way I
> only have to remember to check one place for outstanding issues in my
> packages, and years down the line when I wonder "wh
Hi,
> Are discussions at Salsa preserved years down the line?
I don't think there is any special concern to suspect that Salsa or
any other official Debian service would seize to exist abruptly?
GitHub.com and GitLab.com has done a pretty good job at hosting
contents for years and years, hopefull
git
branches work.
- Otto
Hi all!
If you haven't noticed, lintian.debian.org has been online now for
almost 4 months.
A special thanks for that goes to Nicolas Peugnet for creating
lintian-ssg that generates the site, and Louis-Philippe Véronneau
(pollo) for taking care of Lintian!
After lintian.debian.org went offline i
> > 938 (9657) https://salsa.debian.org/groups/debian/-/merge_requests
> [..]
> > If you have some spare time for Debian today, please consider
> > collaborating with another maintainer by providing them
> > review/feedback on an open Merge Request.
>
> I gave this, specifically reviewing MRs in th
lopers
I personally feel strongly that code reviews and discussing optimal
solutions with other people makes Debian packaging way more fun than
simply working solo.
- Otto
Hi,
> I've been parsing a few package lists lately for nefarious reasons. Some
> packages have Built-Using or Static-Built-Using tags, which seem to
> serve the same purpose.
>
> Is there a subtle difference I need to be aware of?
I suspect the best summary of the situation is in the attachment i
> please be careful in your efforts to make contributing easier to not alienate
> those who already contribute, sometimes for decades. also: it's rather easy to
> kill motivation but very hard to revive it, once killed.
The above got quoted in the latest LWN, so it may be a sign that the
above vie
...
> 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 Devel
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/ -
> > two things: first, what is a "core component of Debian" is very much up to
> > debate, but I'd be quite surprised if anybody made the case that adequate
> > is.
>
> adequate is run on all 7 binary packages on piuparts.debian.org. I'm
> really
> curious whether this will blow up when piupa
Hi,
> > > This change basically adds the recommendation to use "upstreamvcs" as the
> > > name of the "git remote" to access the upstream repository and it also
> > > documents the possibility to merge the upstream commits in the
> > > "upstream/latest" branch (as proposed by gbp import-orig
> > >
/debcraft.git (fetch)
origin g...@salsa.debian.org:debian/debcraft.git (push)
origin g...@gitlab.com:ottok/debcraft.git (push)
origin g...@github.com:ottok/debcraft.git (push)
otto g...@salsa.debian.org:otto/debcraft.git (fetch)
otto g...@salsa.debian.org:otto/debcraft.git (push)
otto g...@gitlab.com:ott
> That's fair. I maintain a package of a project where I eventually
> moved the upstream codebase into revision control but have been too
> lazy/distracted to do the same for the debian directory (which I
> realistically only update once every year or two). I'm committed to
> importing that into Sa
Thanks for encouragement. I filed
https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/411 and will
continue research on libfaketime/datefudge in CI there.
Hi,
> Gioele Barabucci:
> We need different levels of responsibility:
>
> * Nobody cares ⇒ orphan package
> * I care a bit, but I don't have time to handle all the responsibilities
> that a maintainership entail, but try to contact me anyway, I may reply
> ⇒ MISSING LEVEL discussed here
> * I care
Hi!
> This is an update for my previous MBF announcement here:
>
> https://lists.debian.org/debian-devel/2024/05/msg00414.html
>
> I did another test rebuild and found 11 new packages failing
> in the not-so-distant future. I also found another package
> for which the fix was lost and the bug had
Hi!
> Number of packages not on Salsa
> ---
>
> In my campaign, I stated [os1] that I aimed to reduce the number of
> packages maintained outside Salsa to below 2,000. As of March 28, 2024,
> the count was 2,368. As of this writing, the count stands at 1,928
> [os2], so
uthor.
Let's make 2025 a year when code reviews became common in Debian! It
will hopefully both help increase quality and also make people feel
the joy of working together!
- Otto
Hi,
> >> >> i think the barrier is likely to be "i didnt know you could do that?"
> >> >> rather than "how do i use that?"
> >> >
> >> > Salsa CI is and has always been opt-in.
> >>
> >> oops - i meant the oppposite, ie make people have to opt out of having
> >> it run, rather than have to enable
> >> > Salsa CI is a great system for all aspiring Debian packagers to test
> >> > their packages before requesting review from mentors
> >>
> >> > However, as there are still packages not using Salsa CI, I wonder is
> >> > it straightforward enough for everyone?
> >> >
> >>
> >> I think the best s
Hi!
> > Salsa CI is a great system for all aspiring Debian packagers to test
> > their packages before requesting review from mentors
>
> > However, as there are still packages not using Salsa CI, I wonder is
> > it straightforward enough for everyone?
> >
>
> I think the best solution would be to
Hi all,
This list has had plenty of discussions regarding best practices in
packaging. I noticed some of the views stemmed out of
misunderstandings or unawareness of certain easy to use
solutions and techniques exist. Hence, I am glad to see that Guido
just uploaded git-buildpackage 0.9.36, which
Hi,
> Before we move on, please allow me to ask what problem the nproc tool is
> supposed to solve. Of course it tells you the number of processors, but
> that is not a use case on its own. If you search for uses, "make
> -j$(nproc)" (with varying build systems) is the immediate hit. This use
> i
README. All
feedback on how to improve the documentation so it is easy to digest
in particular for newcomers is welcome as replies to this email or as
comments at
https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/563.
- Otto
> From
> https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group:
>
> The debian group is for CollaborativeMaintenance (the old collab-maint
> on Alioth).
>
> The group is accessible to all Debian developers upon linking their
> SSO Account, and are granted Maintain
> > Commits onto a git repo can be reversed easily (via `git revert`
> > or forced push, if one really wants to), but problematic uploaded
> > packages to the archive are irreversible and might cause broader
> > damages. That is why people are okay with allowing random git commits
> > to Debian gro
> The https://go-team.pages.debian.net/ pages may have some flaws, but one
> key social function is that it establishes the group as a team effort.
> That goal is something to take after. I'm trying migrate my
+1
> pkg-auth-maintainers packages to pkg-security just because
> https://wiki.debian.
> > I changed my personal preference from DEP-0 to DEP0 as I now consider
> > DEP0 the best option based as I have seen so much of RFC822, dep3,
> > dep8 and DEP14 in use in many places. However, that +22 for DEP-0 is
> > pretty large majority so I have to conclude it won.
>
> "it won", yes, but wh
[...]
> Can we agree on calling Debian Enhancement Proposals DEP-N with a dash?
>
> My eyes get sore when looking at commit messages like these:
>
> * cd4d154 DEP 15: initial draft
> * f54478c DEP8: Fix link to current specification
> * 1f20e9d DEP-14: Version -> refname mangling: Escape dots
Resu
Hi,
> [forking to -devel]
>
> On Wed Dec 11, 2024 at 11:15 AM CET, Holger Levsen wrote:
> > On Tue, Dec 10, 2024 at 09:38:57PM +0100, Serafeim (Serafi) Zanikolas wrote:
> > > > On Sat Dec 7, 2024 at 5:15 AM CET, Paul Wise wrote:
> > > > Probably adequate is the logical place for this test, but ade
Hi,
> > While I personally think e-mail-based workflows can be quite nice, the
> > BTS' asynchronous nature did cause me a lot of extra pointless work
> > when I was an outsider attempting to learn the ropes. Being not 100%
> > confident with the system, I way too often found myself waiting
> > mi
Hi and thanks for quick reply,
> > As you know I have been testing dgit and reviewing tag2upload, and to
> > my understanding tag2upload will generate the *.orig.tar.gz tarballs
> > using dgit
>
> (Using 'git deborig', not dgit.)
Right, it is a separate tool in devscripts
(https://manpages.debian
1 - 100 of 313 matches
Mail list logo
