Hi all!
I just wanted to advertise once more in case somebody missed it: There
is now a https://wiki2025.debian.org/ and work to migrate to a new
Mediawiki based Debian wiki is in the progress. If you want to
contribute, please see the discussions on
https://lists.debian.org/debian-wiki/2025/07/th
Thanks Antonio!
Your changes at https://salsa.debian.org/salsa/salsa-webhook look good to me
> I am considering to package a software stored at GitHub.
> It is under active development and it builds well in Sid.
> However it appears that its source tarball at GitHub does not
> contain all the necessary material: its submodules are not included.
> This issue seems to be an old GitHub issue.
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
>
Hi,
> > As a very new contributor to Debian as part of the Google Summer of Code
> > (GSoC) '25 program I can only second Andreas' point. Packages / package
> > teams who are willing/have the bandwith to mentor newcomers are most
> > certainly a great starting point for newbies. Is there an easy w
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
Hi!
I am not sure what is the default in Salsa for new repositories right
now, but I suggest all Debian Developers/Maintainers who use Salsa to:
- Review your global notification settings at
https://salsa.debian.org/-/profile/notifications
- For each Salsa project you feel responsible for, go th
Hi!
...
> One fundamental thing is that you may not be welcomed simply because
> there is nobody there welcoming you. Adding a merge request for a fix
> may be pointless, because nobody will merge it. Reviewing is a certain
> effort and nobody has time for that.
..
> My experience does however als
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,
Hi,
In my experience many of the discussions about packaging workflows on
this list have many misconceptions, which in turn I think stems from
that our tools are a bit challenging to use, and the documentation is
somewhat lacking. Many tend to struggle to figure out how to do
something, and once t
> > Debian has certainly done many things right in the past 30 years, but
> > treatment of new contributors is currently pretty harsh, considering
> > how many cracks and false turns they need to overcome on to become
> > regular contributors.
>
> The impact successive roadblocks can have on new co
> 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
+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
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
Hi,
Would Matthias or anyone else active in this discussion be willing to
be the reviewer for
https://salsa.debian.org/debian/devscripts/-/merge_requests/478?
It has been pending for almost two weeks with zero reviews. I don't
feel it would be prudent of me to merge it with no additional eyeballs
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.”
>
>
Hi,
On Wed, 5 Mar 2025 at 10:24, Nilesh Patra wrote:
> On 05/03/25 4:47 pm, Sean Whitton wrote:
> > On Tue 04 Mar 2025 at 09:40am +01, Andreas Tille wrote:
> >
> >> Dear Debian community,
> >>
> >> this is bits from DPL for February.
> >>
> >>
> >> Ftpmaster team is seeking for new team members
>
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
Hi!
I don't use Emacs myself, but I learned last weekend at FOSDEM that
some Emacs users love using the Emacs extension Magit [1] with the
Forge [2] feature to list and review GitHub Pull Requests directly
from Emacs without opening a browser.
Just curious to know if any Emacs users here (Monty?)
Hi!
> > - because it is not easy and fast to migrate and if you do it you have to
> > redo the local repository, if you are alone working on the repository it is
> > not a big problem while if you are many it can create inconveniences
>
> IMO this is the real hurdle.
> Migrating thousands (in the
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
Hi Jonas!
> > If you don't like using Salsa or don't like reviewing Merge Requests,
> > then this call is probably not for you. However, if you want Debian to
> > grow and you want to welcome new contributors, or in general work in a
> > collaborative way towards ending single-maintainer packages,
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
Hi,
While discussing git-buildpackage use, various DEP-14 branches,
pristine-tar purpose, how to correctly filter/repackage upstream
tarballs in past 6 months I noticed that many people have
misconceptions of what is the purpose of the various branches and how
git merges across them are supposed t
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
Hi,
Numerous people are posting Merge Requests on Salsa. Please help review them!
There is no single dashboard to show all Merge Requests for all Debian
packages, but here are the largest teams listed to show how many they
have open (and total count in parentheses):
938 (9657) https://salsa.debi
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
> > >
Hi,
> > > While I'd love to see all packages on Salsa
> >
> > I think that being able to host the primary git repository of packages
> > elsewhere is a freedom worth maintaining for many reasons.
>
> No, I don't think this is a good idea, and at my first thought, I
> personally don't see any pract
> 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
Hi,
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.
There are currently 938 open merge requests in the main Debian group on Salsa:
https://salsa.debian.org/groups/debian/-/merge_request
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
Hi!
Salsa CI is a great system for all aspiring Debian packagers to test
their packages before requesting review from mentors, and also for
experienced packagers to ensure there are no easily testable lapses
before uploading to Debian.
Anyone with a Salsa account can use it. Simply follow the REA
> 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
Hi!
...
> - tag2upload will improve the situation with .orig.tar because the
> tag2upload server will always ensure that the uploaded source package
> is prepared using an .orig.tar that dak will be happy with.
> It won't matter what you're using locally for, e.g., the purpose of
> feeding
Hi,
> > Wouldn't another option be to allow for multiple ways to write things,
> > as long as they are consistently written in the same style for the same
> > purpose?
> >
> > I prefer writing DEP 4711 in text.
> >
> > I prefer writing https://example.org/dep4711.txt in URLs.
> >
> > I prefer writ
Hi
On Fri., Nov. 29, 2024, 15:20 Richard Lewis,
wrote:
> > Please also help Guido iterate on git-buildpackage so that it works
> > well, is easy to debug, has good docs etc. Based on discussions in
> > this thread there are a lot of people with misconceptions and
> > polishing the docs would be t
1 - 100 of 254 matches
Mail list logo
