Re: Debian choice of upstream tarballs for packaging
On Wed, Aug 25, 2021 at 10:01 AM Simon Richter wrote: > FWIW, I'd love to see git bundles as a source archive format -- this > would allow shipping a (signed) tag, its commit, and the tree and blob > objects for that commit as a single file that can be built in a > reproducible way and allows changes on top to be easily tracked, > including the branch point. The dpkg-source 3.0 (git) format is exactly this, IIRC ftp-masters didn't want to have to review the full history in the bundle, but that could be mitigated by allowing single-commit bundles. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Debian choice of upstream tarballs for packaging
On Wed, Aug 25, 2021 at 2:36 PM Simon Richter wrote: > "git archive" is reproducible I'm told by the Bootstrappable Builds folks that `git archive` isn't deterministic in some cases to do with filtering, I lost the details though. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Automated backports based on Janitor work?
On 26.08.21 11:39, Lucas Nussbaum wrote:
> Additionally, one could imagine a DSL to:
> - make minor changes to the source package before building (adjust
> dependencies, apply an additional patch, etc.)
> - tell sbuild that some build-dependencies must be pulled from backported
> packages
>
> Jelmer, did you already think about that? Is there a way one could help
> you?
I worked on something like this last fall, which I tentatively named
'apt-derive'.
Given a source package in some origin distribution, apt-derive can
automatically create a derivative of the source package, and of any
necessary dependencies, for a target distribution.
The popular derivation would be the backport type, of course. But other
possibilities exist. For example, I was interested in optimized build
flavors for certain target environments.
Here's sample code for a numpy buster backport, with the following
output reflecting the rebuild chain needed on amd64 circa September
2020, when I ran this:
| from apt_derive import RebuildResolver
|
| # Used to identify Releases in python-apt
| bullseye = dict(origin='Debian', codename='bullseye')
| buster_bpo = dict(origin='Debian Backports', codename='buster backports')
| buster = dict(origin='Debian', codename='buster')
|
| # origin: bullseye
| # target: buster-backports
| # Packages from buster can be used to satisfy build dependencies
| rr = RebuildResolver(wanted_dist=bullseye,
| target=buster_bpo,
| added_dists=[buster])
|
| # Figure out what needs to be rebuilt
| tree = rr.resolve('numpy')
| if tree:
| print(tree.pformat())
python3-numpy_1:1.19.2-2
└─cython_0.29.21-1
└─dvisvgm_2.10.1-1
└─freetype_2.10.2+dfsg-3
└─python-hypothesis_5.32.1-1
└─sphinx_3.2.1-1
└─python-lark_0.9.0-1
└─sphinx_3.2.1-1
So back then, 7 unique packages needed to be backported (numpy and 6
others for newer build dependencies).
That's the resolving part of apt-derive. There's more to it of course,
for example there is a "blocked" list of packages where automatic
derivation would be refused (eg: for libc).
The rebuild part of apt-derive would create backported sources (with
changelog entries, and any other configured extensions) for the
packages.
My plan was to provide such a automated backports service under the name
"autobpo", with package suffix ~autobpo11, and suites
* bullseye-autobpo-dangerous for the immediate build results
* bullseye-autobpo for results that passed CI and rebuilt
reproducibly
As to which packages to automatically backport, my plan was two-fold:
* By popular request
* Maintainers indicating so with X-AutoBPO-Policy:
somewhere in debian/control
What eventually stalled my effort was that I was lacking a reasonably
simple build environment for multiple architectures. I wrote sbuild-qemu
to get local access to many architectures, but in the end, I didn't see
a way around wanna-build etc. for a multi-node build farm. I found
wanna-build overly complicated, and then other stuff came up in $LIFE.
Raphael initiated debusine in the meantime, which seems to be ideal
solution to my build problem.
However, If anyone with wanna-build experience is interested in
collaborating to get this launched sooner, please ping me.
I'll try to finalize the first draft of apt-derive as soon as possible
in the hopes that something can come of it.
Best,
Christian
Re: Automated backports based on Janitor work?
On Thu, Aug 26, 2021 at 11:39:06AM +0200, Lucas Nussbaum wrote: > There's probably a large number of packages that just require a > rebuild (+ test with autopkgtest) to be backported. uploading to -backports also implies the promise to keep maintaining that backport until the next release is out... I'm not sure that part of the upload should be automated nor forgotten ;) -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Make racists afraid again. signature.asc Description: PGP signature
Re: Automated backports based on Janitor work?
On 27/08/21 at 12:54 +, Holger Levsen wrote:
> On Thu, Aug 26, 2021 at 11:39:06AM +0200, Lucas Nussbaum wrote:
> > There's probably a large number of packages that just require a
> > rebuild (+ test with autopkgtest) to be backported.
>
> uploading to -backports also implies the promise to keep maintaining that
> backport until the next release is out... I'm not sure that part of the
> upload should be automated nor forgotten ;)
Oh I wasn't thinking about uploading to the official backports suite.
In the same spirit as the fresh-{releases,snapshots} suites provided by
janitor, I was thinking about an automatically-generated backports
suite.
Lucas
Re: Automated backports based on Janitor work?
On Fri, Aug 27, 2021 at 03:04:34PM +0200, Lucas Nussbaum wrote:
> > uploading to -backports also implies the promise to keep maintaining that
> > backport until the next release is out... I'm not sure that part of the
> > upload should be automated nor forgotten ;)
> Oh I wasn't thinking about uploading to the official backports suite.
> In the same spirit as the fresh-{releases,snapshots} suites provided by
> janitor, I was thinking about an automatically-generated backports
> suite.
oh, ic, this makes sense to me too, thanks for clarifying!
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
Change is coming whether you like it or not.
signature.asc
Description: PGP signature
Re: Automated backports based on Janitor work?
Hey Lucas
On 2021/08/27 15:04, Lucas Nussbaum wrote:
Oh I wasn't thinking about uploading to the official backports suite.
In the same spirit as the fresh-{releases,snapshots} suites provided by
janitor, I was thinking about an automatically-generated backports
suite.
That sounds great. Firstly there's a lot of benefit to many people who
would use that, but also at the same time it would also count towards
some testing to newer packages that will end up in the next release.
There'll probably be some complications as always, but overall it sounds
like a great idea!
-Jonathan
Bug#993120: ITP: python-oslo.metrics -- OpenStack Oslo Metrics API
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-oslo.metrics Version : 0.0.3 Upstream Author : OpenStack Foundation * URL : https://opendev.org/openstack/oslo.metrics * License : Apache-2.0 Programming Lang: Python Description : OpenStack Oslo Metrics API This Oslo metrics API supports collecting metrics data from other Oslo libraries and exposing the metrics data to monitoring system. Note: This is a new dependency of python3-oslo.messaging
Re: next steps after usrunmess
On Fri, Aug 27, 2021 at 03:39:57AM +0100, Phil Morrell wrote: > > - reverting the changes in deboostrap in sid, bullseye (and ideally > > in buster too), > > - reverting the notion that split-/usr is unsupported (which includes > > the extremely confusing interpretation about this applying to > > sid/testing too), and update documentation such as release-notes, > > This bullet point response confuses me - and then what? > > If I understand your position correctly, you don't want merged-/usr as > an end-goal and you disagree with usrmerge transition as a hack. In > order to achieve the result above without bypassing Debian processes, > the formal method would to pass a GR overriding the tech-ctte minority. > Is the only reason you haven't proposed that as a GR that you've already > sunk too much energy into this? Or that you don't trust that process? My question is the reverse. If there is rough consensus that we as a community *do* want to go forward with /usr unification in a way which is compatible with all of the other distrubtions --- and Debian is definitely in thet trailing edge here --- and a very small number of dpkg developers are refusing to help resolve these issues, are they entitled to perform a pocket veto on /usr unification? Simon and I have proposed technical paths forward which appear to be sound, and I note that Guillem has not commented on them. Which is why I haven't really participated in this thread in the last couple of days; I've said my piece, and if folks who essentially want to rollback the clock by several years refuse to engage, just simply repeating my points doesn't seem to be a good use of electrons. But the question remains --- how do we as a community move forward? Debian is made up of volunteers, so we can't *force* the dpkg developers to do anything they don't want to do. So what then? Does someone need to create patches to dpkg which attempt to teach it that /bin/foo and /usr/bin/foo are the same file, if there exists a symlink from /bin to usr/bin? And then with some kind of process, maybe with the blessing of the technical committee, upload it as an NMU over the objections of the dpkg developers if they continue to refuse to engage with solutions that proceed forward with /usr-unification? That seems to be rather non-ideal from a community perspective. But what's the alternative? Should a single DD have the power to overturn a techical committee because they are the maintainer of a highly important package? That doesn't seem great, either. As I've said before, I've never been a fan of /usr-unification; I don't hate it, but I've never thought it was worth it in and of itself, other the "compatibility with the rest of the world argument". I'm not a huge fan of systemd, either, although I never hated it as much as some. But the entire Linux ecosystem has spoken, and so my personal views aren't really important at this point. Part of living in a community is realizing that one doesn't always get one's own way, and subsuming one's individual wants for the greater good. So I repeat the question to the entire community --- what is to be done? How do we move forward? - Ted
Re: next steps after usrunmess
Le ven. 27 août 2021 à 17:20, Theodore Ts'o a écrit : > On Fri, Aug 27, 2021 at 03:39:57AM +0100, Phil Morrell wrote: > > > - reverting the changes in deboostrap in sid, bullseye (and ideally > > > in buster too), > > > - reverting the notion that split-/usr is unsupported (which includes > > > the extremely confusing interpretation about this applying to > > > sid/testing too), and update documentation such as release-notes, > > > > This bullet point response confuses me - and then what? > > > > If I understand your position correctly, you don't want merged-/usr as > > an end-goal and you disagree with usrmerge transition as a hack. In > > order to achieve the result above without bypassing Debian processes, > > the formal method would to pass a GR overriding the tech-ctte minority. > > Is the only reason you haven't proposed that as a GR that you've already > > sunk too much energy into this? Or that you don't trust that process? > > My question is the reverse. If there is rough consensus that we as a > community *do* want to go forward with /usr unification in a way which > is compatible with all of the other distrubtions --- and Debian is > definitely in thet trailing edge here --- and a very small number of > dpkg developers are refusing to help resolve these issues, are they > entitled to perform a pocket veto on /usr unification? > > Simon and I have proposed technical paths forward which appear to be > sound, and I note that Guillem has not commented on them. Which is > why I haven't really participated in this thread in the last couple of > days; I've said my piece, and if folks who essentially want to > rollback the clock by several years refuse to engage, just simply > repeating my points doesn't seem to be a good use of electrons. > > But the question remains --- how do we as a community move forward? > Debian is made up of volunteers, so we can't *force* the dpkg > developers to do anything they don't want to do. So what then? > > Does someone need to create patches to dpkg which attempt to teach it > that /bin/foo and /usr/bin/foo are the same file, if there exists a > symlink from /bin to usr/bin? And then with some kind of process, > maybe with the blessing of the technical committee, upload it as an > NMU over the objections of the dpkg developers if they continue to > refuse to engage with solutions that proceed forward with > /usr-unification? That seems to be rather non-ideal from a community > perspective. But what's the alternative? Should a single DD have the > power to overturn a techical committee because they are the maintainer > of a highly important package? That doesn't seem great, either. > > > As I've said before, I've never been a fan of /usr-unification; I > don't hate it, but I've never thought it was worth it in and of > itself, other the "compatibility with the rest of the world argument". > I'm not a huge fan of systemd, either, although I never hated it as > much as some. But the entire Linux ecosystem has spoken, and so my > personal views aren't really important at this point. Part of living > in a community is realizing that one doesn't always get one's own way, > and subsuming one's individual wants for the greater good. > > So I repeat the question to the entire community --- what is to be > done? How do we move forward? > See the proposal here of guillem: https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking > > - Ted > >
Re: next steps after usrmerge
On Fri, Aug 27, 2021 at 07:34:06PM +0200, Bastien ROUCARIES wrote: > > See the proposal here of guillem: > https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking This proposal doesn't directly address usrmerge, and the fact that new Debian installs have been installing systems with top-level symlinks for two stable releases now. The only proposal I've seen from guillem which directly addresses the usrmerge merge is to attempt to rollback the clock by two stable releases, in direct contravention of the decisiopn made by the technical committee. - Ted
Re: next steps after usrunmess
On Fri, Aug 27, 2021 at 07:34:06PM +0200, Bastien ROUCARIES wrote: > Le ven. 27 août 2021 à 17:20, Theodore Ts'o a écrit : > > On Fri, Aug 27, 2021 at 03:39:57AM +0100, Phil Morrell wrote: > > > > - reverting the changes in deboostrap in sid, bullseye (and ideally > > > > in buster too), > > > > - reverting the notion that split-/usr is unsupported (which includes > > > > the extremely confusing interpretation about this applying to > > > > sid/testing too), and update documentation such as release-notes, > > > > > > This bullet point response confuses me - and then what? > > > > > > If I understand your position correctly, you don't want merged-/usr as > > > an end-goal and you disagree with usrmerge transition as a hack. In > > > order to achieve the result above without bypassing Debian processes, > > > the formal method would to pass a GR overriding the tech-ctte minority. > > > > But the question remains --- how do we as a community move forward? > > Debian is made up of volunteers, so we can't *force* the dpkg > > developers to do anything they don't want to do. So what then? > > > > Does someone need to create patches to dpkg which attempt to teach it > > that /bin/foo and /usr/bin/foo are the same file, if there exists a > > symlink from /bin to usr/bin? > > > > So I repeat the question to the entire community --- what is to be > > done? How do we move forward? > > See the proposal here of guillem: > https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking Hi Bastien, it's hard for me to see as an outsider to dpkg how that proposal specifically addresses merged-/usr. It seems to be trying to solve a much, much more generalised problem of which merged-/usr is just a part. Is there no way to achieve the goal of making the dpkg database correspond with reality without that complexity? Secondly, assuming that this mechanism is needed, then according to that wiki page it appears to be almost complete? Can you confirm that the only thing needed to support merged-/usr as an option is these two remaining blockers? > [ ] (blocker) dpkg database access (.list and .md5sums) > * reportbug (no interface to map a db pathname to a pkgname) > [ ] (blocker) We cannot install .mtree files under /var/lib/dpkg/info/ > because old or new .debs could have shipped those, and these might be > invalid, or not match the contents. In general it seems like a bad > idea to store the files handled and generated by dpkg itself, with > files coming straight from the .debs. We need to separate them into > different directories. Perhaps /var/lib/dpkg/info/. > and /var/lib/dpkg/meta/. or similar. signature.asc Description: PGP signature
Re: next steps after usrunmess
On 8/27/21 10:20 AM, Theodore Ts'o wrote: Does someone need to create patches to dpkg which attempt to teach it that /bin/foo and /usr/bin/foo are the same file, if there exists a symlink from /bin to usr/bin? Yes. I can't speak to the dpkg internals, but conceptually, this seems like the right thing to do. Even if we eliminated usrmerge entirely, I'm not sure what's harmful about dpkg canonicalizing filenames. In fact, it seems very much like the right thing to do. So unless the patch is very invasive, I don't see why one would object to this change on its own. And then with some kind of process, maybe with the blessing of the technical committee, upload it as an NMU over the objections of the dpkg developers if they continue to refuse to engage with solutions that proceed forward with /usr-unification? Yes. If the dpkg maintainer does not accept a reasonable patch, then this may need to be presented to the TC to overrule him, which requires a 3:1 TC majority. One might argue the existing TC decision implies this, but the least ambiguous procedural option would be to have the TC explicitly overrule the maintainer once a specific implementation is available. It is my view that the usrunmess utility also needs to be dropped before the bookworm release. That quite clearly follows from the existing TC decision, which is that only the merged-usr layout is supported, so I don't think that needs further TC action. However, I think removing that utility should wait until such time as we have the other issues reasonably resolved. Should a single DD have the power to overturn a techical committee because they are the maintainer of a highly important package? No. This is settled in the Debian constitution. If a DD wishes to override the TC, they need to propose a GR. -- Richard OpenPGP_signature Description: OpenPGP digital signature
Bug#993139: ITP: flake8-class-newline -- flake8 Extension to lint for a method newline after a Class definition
Package: wnpp Severity: wishlist Owner: Jose Luis Rivero X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: flake8-class-newline Version : 1.6.0 Upstream Author : Alexander van Eck * URL : https://github.com/AlexanderVanEck/flake8-class-newline * License : MIT Programming Lang: Python Description : flake8 Extension to lint for a method newline after a Class definition flake8 Extension to lint for a method newline after a Class definition PEP8 says we should surround every class method with a single blank line. See https://www.python.org/dev/peps/pep-0008/#blank-lines However flake8 is ambiguous about the first method having a blank line above it. This plugin was made to enforce the blank line just after the method declaration.
Re: next steps after usrunmess
Le ven. 27 août 2021 à 20:33, Phil Morrell a écrit : > On Fri, Aug 27, 2021 at 07:34:06PM +0200, Bastien ROUCARIES wrote: > > Le ven. 27 août 2021 à 17:20, Theodore Ts'o a écrit : > > > On Fri, Aug 27, 2021 at 03:39:57AM +0100, Phil Morrell wrote: > > > > > - reverting the changes in deboostrap in sid, bullseye (and > ideally > > > > > in buster too), > > > > > - reverting the notion that split-/usr is unsupported (which > includes > > > > > the extremely confusing interpretation about this applying to > > > > > sid/testing too), and update documentation such as > release-notes, > > > > > > > > This bullet point response confuses me - and then what? > > > > > > > > If I understand your position correctly, you don't want merged-/usr > as > > > > an end-goal and you disagree with usrmerge transition as a hack. In > > > > order to achieve the result above without bypassing Debian processes, > > > > the formal method would to pass a GR overriding the tech-ctte > minority. > > > > > > But the question remains --- how do we as a community move forward? > > > Debian is made up of volunteers, so we can't *force* the dpkg > > > developers to do anything they don't want to do. So what then? > > > > > > Does someone need to create patches to dpkg which attempt to teach it > > > that /bin/foo and /usr/bin/foo are the same file, if there exists a > > > symlink from /bin to usr/bin? > > > > > > So I repeat the question to the entire community --- what is to be > > > done? How do we move forward? > > > > See the proposal here of guillem: > > https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking > > Hi Bastien, it's hard for me to see as an outsider to dpkg how that > proposal specifically addresses merged-/usr. It seems to be trying to > solve a much, much more generalised problem of which merged-/usr is just > a part. Is there no way to achieve the goal of making the dpkg database > correspond with reality without that complexity? > No it will be more complex to spécial case then to solve thé général dir to symlink problem. Dpkg is a graph mathematical solver and as usual un math solving général problem ils often easier > > Secondly, assuming that this mechanism is needed, then according to that > wiki page it appears to be almost complete? Can you confirm that the > only thing needed to support merged-/usr as an option is these two > remaining blockers? > > > [ ] (blocker) dpkg database access (.list and .md5sums) > > * reportbug (no interface to map a db pathname to a pkgname) > > [ ] (blocker) We cannot install .mtree files under /var/lib/dpkg/info/ > > because old or new .debs could have shipped those, and these might be > > invalid, or not match the contents. In general it seems like a bad > > idea to store the files handled and generated by dpkg itself, with > > files coming straight from the .debs. We need to separate them into > > different directories. Perhaps /var/lib/dpkg/info/. > > and /var/lib/dpkg/meta/. or similar. > Yes ans no. It is a needed condition to track symlink dir between package. After it will need the same mécanism than that i have implemented with dpkg-maintscript-helper. But instead of failling like now when some file under dir are owned by otherpackage, we could do something sensible and notify thé other packages that dir is now symlink Bastien >
Bug#993142: ITP: flake8-comprehensions -- flake8 plugin that helps you write better list/set/dict comprehensions.
Package: wnpp Severity: wishlist Owner: Jose Luis Rivero X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: flake8-comprehensions Version : 3.6.1 Upstream Author : Adam Johnson * URL : https://github.com/adamchainz/flake8-comprehensions * License : MIT Programming Lang: Python Description : flake8 plugin that helps you write better list/set/dict comprehensions. Package adds check for the flake8 linter related to list/set/dict comprehensions. Examples are: Unnecessary generator, Unnecessary list comprehension, Unnecessary call, etc.
Re: Future of /usr/bin/which in Debian?
Hi, 在 2021-08-22星期日的 17:36 +0200，Andrej Shadura写道： > Hi, > > On Thu, 19 Aug 2021, at 23:17, Boyuan Yang wrote: > > 在 2021-08-18星期三的 22:59 +0200，Geert Stappers写道: > > > > /usr/bin/which.debianutils 0 > > > > > > > > in postinst and so on so that FreeBSD which and GNU which and friends > > > > could > > > > take over. > > > > > > Please do. Make such take over possible. > > > It is what > > > https://salsa.debian.org/debian/debianutils/-/merge_requests/6#note_242172 > > > is asking for. > > > > So we will have https://salsa.debian.org/debian/which-gnu providing a > > binary > > package with name "which". I will upload it to the NEW queue soon. > > I'd rather suggest the FreeBSD which, which I'm mirroring here: > https://salsa.debian.org/andrewsh/freebsd-which/ > > I think it's much simpler than the GNU one. The GNU which package is now in NEW queue: https://ftp-master.debian.org/new/gnu-which_2.21-1.html Having both freebsd which and gnu which in Debian archive is definitely ok. If you would like, please also upload freebsd-which onto unstable. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Re: Debian choice of upstream tarballs for packaging
Hello, On Fri 27 Aug 2021 at 07:58AM GMT, Paul Wise wrote: > On Wed, Aug 25, 2021 at 2:36 PM Simon Richter wrote: > >> "git archive" is reproducible > > I'm told by the Bootstrappable Builds folks that `git archive` isn't > deterministic in some cases to do with filtering, I lost the details > though. git-deborig in devscripts has code to handle the filtering problem, I believe. -- Sean Whitton signature.asc Description: PGP signature
Re: Debian choice of upstream tarballs for packaging
Hello zigo, On Wed 25 Aug 2021 at 04:11PM +02, Thomas Goirand wrote: > I wrote this many times, but I don't see why we should use any "upstream > tarball" when the Git repository itself contains the tarball with: > > git archive --prefix=$(DEBPKGNAME)-$(VERSION)/ $(GIT_TAG) \ > | xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz > > (which leads to a .xz, which is nicer) > > Not only then, only only has to merge the upstream tag in the Debian > branch to get the new release, but on top, no need to "gbp import" or > "pristine-tar commit", and a single packaging branch becomes enough. > > I very much wish this packaging workflow gained more traction, and the > pristine-tar abomination dies... I agree. I'd like to suggest using 'git deborig' which is much shorter to type :) -- Sean Whitton signature.asc Description: PGP signature
Re: Future of /usr/bin/which in Debian?
Hello Boyuan, On Fri 27 Aug 2021 at 04:48PM -04, Boyuan Yang wrote: > Hi, > > 在 2021-08-22星期日的 17:36 +0200，Andrej Shadura写道： >> Hi, >> >> On Thu, 19 Aug 2021, at 23:17, Boyuan Yang wrote: >> > 在 2021-08-18星期三的 22:59 +0200，Geert Stappers写道: >> > > > /usr/bin/which.debianutils 0 >> > > > >> > > > in postinst and so on so that FreeBSD which and GNU which and friends >> > > > could >> > > > take over. >> > > >> > > Please do. Make such take over possible. >> > > It is what >> > > https://salsa.debian.org/debian/debianutils/-/merge_requests/6#note_242172 >> > > is asking for. >> > >> > So we will have https://salsa.debian.org/debian/which-gnu providing a >> > binary >> > package with name "which". I will upload it to the NEW queue soon. >> >> I'd rather suggest the FreeBSD which, which I'm mirroring here: >> https://salsa.debian.org/andrewsh/freebsd-which/ >> >> I think it's much simpler than the GNU one. > > The GNU which package is now in NEW queue: > https://ftp-master.debian.org/new/gnu-which_2.21-1.html > > Having both freebsd which and gnu which in Debian archive is definitely ok. If > you would like, please also upload freebsd-which onto unstable. It's okay, indeed, but please do consider NEW queue workload with things like this -- upload it if you're sure it's going to get used, not just for completeness. -- Sean Whitton signature.asc Description: PGP signature
Re: Debian choice of upstream tarballs for packaging
Hello, On Wed 25 Aug 2021 at 12:00PM +02, Simon Richter wrote: > Hi, > > On 8/25/21 1:21 AM, Sean Whitton wrote: > >> From my point of view, signing git tags is no less well established a >> best practice than signing tarballs -- in fact, to me, it seems *more* >> well established. > > That is ecosystem dependent. Yes, that was my point. We're going to have upstreams who release tarballs and upstreams who release tags for some time. -- Sean Whitton signature.asc Description: PGP signature
Re: Debian choice of upstream tarballs for packaging
Hello, On Wed 25 Aug 2021 at 07:01PM +02, Thomas Goirand wrote: > If pushing the upstream git tags to Salsa, you're safe, and the way we > do in the OpenStack team, we still generate and upload tarballs to the > Debian archive matching each tags. Branches on salsa can be force-pushed, so it's not completely safe. When you 'dgit push-source' or 'dgit push', that history is immutable in that only the service admins can rewrite it. -- Sean Whitton signature.asc Description: PGP signature
Re: Future of /usr/bin/which in Debian?
在 2021/8/28 上午4:54, Sean Whitton 写道: I'd rather suggest the FreeBSD which, which I'm mirroring here: https://salsa.debian.org/andrewsh/freebsd-which/ I think it's much simpler than the GNU one. The GNU which package is now in NEW queue: https://ftp-master.debian.org/new/gnu-which_2.21-1.html Having both freebsd which and gnu which in Debian archive is definitely ok. If you would like, please also upload freebsd-which onto unstable. It's okay, indeed, but please do consider NEW queue workload with things like this -- upload it if you're sure it's going to get used, not just for completeness. If there are several different versions of which in Debian, this will give the user that have a chance to choice one. -- 肖盛文 xiao sheng wen Faris Xiao 微信(wechat)：atzlinux 《铜豌豆 Linux》https://www.atzlinux.com 基于 Debian 的 Linux 中文 桌面 操作系统 Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com GnuPG Public Key: 0x00186602339240CB OpenPGP_0x00186602339240CB.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
