Re: Salsa CI introducing world-writable permissions
Hi, On Sun, 6 Feb 2022, at 15:22, John Goerzen wrote: > In the relevant repo, I could type: > > ``` > $ git ls-tree 91df28f0cc4b0d58cfda57fc1cc5c350bdbaf76d -- service/ > 100644 blob ec429c0bbdb50da81ba0fbef5fc516fc5dc5791f > service/nncp-caller.service > 100644 blob af287bb8255a1fbb774777d56b17b32178dd712e > service/nncp-daemon.service > 100644 blob 13201ad7b83ba30cd0370060aede9bd9f5f5893d > service/nncp-toss.service > ``` > > There - mode 0644. I know this is irrelevant to the issue itself, but: while Git technically can store modes other than 100644 or 100755, it never does so, so I would not take the modes ls-tree prints too seriously. -- Cheers, Andrej
Bug#1005114: ITP: python-model-bakery -- smart object creation facility for Django (Python 3 version)
Package: wnpp Severity: wishlist Owner: Neil Williams X-Debbugs-Cc: debian-devel@lists.debian.org, codeh...@debian.org * Package name: python-model-bakery Version : 1.4.0 Upstream Author : berinfontes * URL : https://github.com/model-bakers/model_bakery * License : Apache 2 Programming Lang: Python Description : smart object creation facility for Django (Python 3 version) Model-Bakery is the replacement for model-mommy and offers you a smart way to create fixtures for testing in Django. With a simple and powerful API you can create many objects with a single line of code. . This package provides Python 3 module bindings only. The model-mommy name was dropped upstream in favour of model-bakery. """ Model Mommy’s creator and the maintainers decided to rename the project to not reinforce gender stereotypes for women in technology """ Note: the newest model-bakery is a *lower* version string than the legacy model-mommy which it replaces and the package is in no way a drop-in replacement. model-mommy will need to persist until packages migrate. New upstream versions will only be made as model-bakery. Model-Bakery includes support for Django4 which is not going to be supported, upstream, by model-mommy. This package will be maintained within the Debian Python Team. Freexian is using a system which can be the first to migrate to the new bakery.
Re: NEW processing friction
On Mon, Feb 07, 2022 at 12:06:24AM -0700, Sean Whitton wrote: > > When we treat any of the above just like other RC bugs, we are accepting > a lower likelihood that the bugs will be found, and also that they will > be fixed Another part of this discussion which shouldn't be lost is the probabiltiy that these bugs will even *exist* (since if they don't exist, they can't be found :-P) in the case where there is a NEW binary package caused by a shared library version bump (and so we have libflakey12 added and libflakey11 dropped as binary packages) and a NEW source package. If we can't do anything else, I suspect we can reduce project a friction a lot of we only subject packages to copyright hazing when it is a NEW source package, and not when there is a NEW binary package caused by some usptream maintainers not being able to maintain ABI backwards compatibility. Granted, I'm being selfish here since that's where I experience the friction, but I'm a big believer in half a loaf being better than none. - Ted
Bug#1005131: ITP: utf8-locale -- detect a UTF-8-capable locale for running child processes in
Package: wnpp Severity: wishlist Owner: Peter Pentchev X-Debbugs-Cc: debian-devel@lists.debian.org, r...@debian.org * Package name: utf8-locale Version : 0.2.0 Upstream Author : Peter Pentchev * URL : https://gitlab.com/ppentchev/utf8-locale * License : BSD-2 Programming Lang: Python, Rust Description : detect a UTF-8-capable locale for running child processes in Sometimes it is useful for a program to be able to run a child process and more or less depend on its output being valid UTF-8. This can usually be accomplished by setting one or more environment variables, but there is the question of what to set them to - what UTF-8-capable locale is present on this particular system? This is where the utf8_locale module comes in.
Re: NEW processing friction
On Mon, Feb 07 2022, Theodore Ts'o wrote: > If we can't do anything else, I suspect we can reduce project a > friction a lot of we only subject packages to copyright hazing when it > is a NEW source package, and not when there is a NEW binary package > caused by some usptream maintainers not being able to maintain ABI > backwards compatibility. Yes. Also, with backports. When packaging up Go packages, which require all their little dependencies to be independent packages, I have probably gone through more than 50 NEW reviews in the past few months. unstable, bullseye, and buster backports. This process is not yet finished for some packages. Another related problem is with languages like Go; when a package adds a dependency, suddenly I can't upload new releases to unstable properly until all the deps have made it through NEW. - John
Re: NEW processing friction
On February 7, 2022 6:00:16 PM UTC, John Goerzen wrote: > >On Mon, Feb 07 2022, Theodore Ts'o wrote: > >> If we can't do anything else, I suspect we can reduce project a >> friction a lot of we only subject packages to copyright hazing when it >> is a NEW source package, and not when there is a NEW binary package >> caused by some usptream maintainers not being able to maintain ABI >> backwards compatibility. > >Yes. > >Also, with backports. When packaging up Go packages, which require all >their little dependencies to be independent packages, I have probably >gone through more than 50 NEW reviews in the past few months. unstable, >bullseye, and buster backports. This process is not yet finished for >some packages. > >Another related problem is with languages like Go; when a package adds a >dependency, suddenly I can't upload new releases to unstable properly >until all the deps have made it through NEW. Backports is an entirely different team. Let's not mix it in with this discussion. It should be it's own thread. Scott K
Re: NEW processing friction
Hello, On Mon 07 Feb 2022 at 12:00PM -05, Theodore Ts'o wrote: > On Mon, Feb 07, 2022 at 12:06:24AM -0700, Sean Whitton wrote: >> >> When we treat any of the above just like other RC bugs, we are accepting >> a lower likelihood that the bugs will be found, and also that they will >> be fixed > > Another part of this discussion which shouldn't be lost is the > probabiltiy that these bugs will even *exist* (since if they don't > exist, they can't be found :-P) in the case where there is a NEW > binary package caused by a shared library version bump (and so we have > libflakey12 added and libflakey11 dropped as binary packages) and a > NEW source package. Which category of bugs do you mean? I distinguished three. -- Sean Whitton signature.asc Description: PGP signature
Re: NEW processing friction
On Mon, Feb 07, 2022 at 07:05:59PM -0700, Sean Whitton wrote: > Hello, > > On Mon 07 Feb 2022 at 12:00PM -05, Theodore Ts'o wrote: > > > On Mon, Feb 07, 2022 at 12:06:24AM -0700, Sean Whitton wrote: > >> > >> When we treat any of the above just like other RC bugs, we are accepting > >> a lower likelihood that the bugs will be found, and also that they will > >> be fixed > > > > Another part of this discussion which shouldn't be lost is the > > probabiltiy that these bugs will even *exist* (since if they don't > > exist, they can't be found :-P) in the case where there is a NEW > > binary package caused by a shared library version bump (and so we have > > libflakey12 added and libflakey11 dropped as binary packages) and a > > NEW source package. > > Which category of bugs do you mean? I distinguished three. The argument why a package which has an upstream-induced shared library version bump, has to go through the entire NEW gauntlent, is because it is Good Thing that to check to see if it has any copyright or licensing issue. But if you have a different package which doesn't have upstream-induced shared library bump, it doesn't go throguh the same kind of copyright and license hazing. And I believe this isn't fair. Either we should force every single package to go through a manual copyright/licensing recheck, because Debian Cares(tm) about copyright, or "copyright/licensing concerns are an existential threat to the project" (I disagree with both arguments), or a package such as libflakey which is going through constant shared library version bumps should not go through the NEW gauntlet just because it has new binary packages (libflakey11, libflakey12, libflakey13, etc.) at every single upstream release. - Ted
Re: NEW processing friction
On Mon, Feb 07, 2022 at 09:28:16PM -0500, Theodore Ts'o wrote: > The argument why a package which has an upstream-induced shared > library version bump, has to go through the entire NEW gauntlet [...] I hear your frustration but don't you think that language like "gauntlet" makes it, uhm, very hard for the "gauntlet team" to reply, and even more importantly, reason with you? IOW: how can we get to 'no NEW (or a much lighter one) for new binary packages' or how can we communicate this if we already have this, maybe also? 'cause I think the latter could very well also be true, or very close to it. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Never waste a crisis. signature.asc Description: PGP signature
Re: NEW processing friction
On February 8, 2022 2:38:48 AM UTC, Holger Levsen wrote: >On Mon, Feb 07, 2022 at 09:28:16PM -0500, Theodore Ts'o wrote: >> The argument why a package which has an upstream-induced shared >> library version bump, has to go through the entire NEW gauntlet [...] > >I hear your frustration but don't you think that language like "gauntlet" >makes it, uhm, very hard for the "gauntlet team" to reply, and even more >importantly, reason with you? > >IOW: how can we get to 'no NEW (or a much lighter one) for new binary packages' >or how can we communicate this if we already have this, maybe also? > >'cause I think the latter could very well also be true, or very close >to it. He either didn't read the rest of the thread or didn't really care about what was said. It doesn't really leave an impression that communication is the goal. To restate: when there's a new binary package, there's several reasons to go through New again, many, if not all except the licensing check, can be automated. Speaking only for myself, I think that if the tools were up to it (they aren't now), we could probably skip New for packages that aren't empty and don't steal binaries from other sources (when we aren't in freeze - we often catch things from going to Unstable that should really be in Experimental because they aren't targeted at the next Stable release), but with the current state of our tooling that's not a policy that could be implemented (even if there was a consensus among the FTP Masters to do so). Scott K
