Extended description of filesystem namespace clashes
Hi! On Wed, 2024-02-28 at 07:41:50 +0100, Helmut Grohne wrote: > That said, I appreciate your work on analyzing the situation as it also > uncovers tangential problems e.g. where different packages put programs > with different functionality into bin and sbin. It is up to > interpretation of Debian policy whether that should be considered an > RC-bug (10.1 "same filenames"). The Debian policy distinguishes between filename and pathname, and other implementations make little sense TBH, but it could be stated explicitly to make sure there's no room for misinterpretation. In any case this seem like a more generic problem with conflicting interfaces which would be nice to clarify. Some time ago I proposed #562863, but it got eventually closed as inactive. Although I'd be happy to work on that again if there is interest, by proposing some wording. > In general, I think that having each > program name on either bin or sbin but not both is a desirable property > and it should be easier to gain consensus on this. For the same implementation I think this is fine, if it provides compatibility or for a transition period. For different implementations or worse for different interfaces, this would be just wrong, as each one might shadow the other depending on the system or user PATH order. Thanks, Guillem
Re: Package marked for autoremoval due to closed bug? [and 1 more messages]
Hi! On Tue, 2024-03-19 at 10:32:04 +, Ian Jackson wrote: > [2] In my case src:dgit depends on git-buildpackage. The autoremoval > robot wants to remove git-buildpackage because of the time_t bugs > against rpm, xdelta, and pristine-tar. One root cause is that > src:dpkg isn't migrating because of #1066952. Just to clarify, I've now closed that report as I mentioned I'd be doing, but this will have no effect, because dpkg and gcc-* are not migrating primarily because they are being used by the release team to gate the transition, to avoid having them get into testing and potentially then getting things to build with the wrong ABI there > The logic of the autoremoval system is that as an affected maintainer > I ought to go and involve myself with #1066952. Perhaps the release team blocks should be listed more prominently at the beginning of the tracker page and perhaps be somewhat linkified (I'll file a report)? (Or maybe you got this information from somewhere else, which lacks that information or is also listed at the end?) Regards, Guillem
Bug#1067194: ITP: ansible-creator -- fastest way to generate all your ansible content
Package: wnpp Severity: wishlist Owner: Guilherme de Paula Xavier Segundo X-Debbugs-Cc: debian-devel@lists.debian.org, guilherme@gmail.com * Package name: ansible-creator Version : 24.2.0 Upstream Contact: Ansible by Red Hat * URL : https://github.com/ansible/ansible-creator * License : Apache 2.0 Programming Lang: Python Description : fastest way to generate all your ansible content CLI tool for scaffolding all your Ansible Content. This package is a Command-Line Interface (CLI) tool designed for effortless scaffolding all your Ansible content. Used to initializing an Ansible collection or creating a framework for specific plugins, this tool streamlines the process with efficiency, standard and precision based on your requirements.
Bug#1067187: ITP: golang-github-lmittmann-tint -- slog.Handler that writes tinted (colorized) logs
Package: wnpp Severity: wishlist Owner: Daniel Swarbrick X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: golang-github-lmittmann-tint Version : 1.0.4 Upstream Contact: lmittmann * URL : https://github.com/lmittmann/tint * License : Expat Programming Lang: Go Description : slog.Handler that writes tinted (colorized) logs tint implements a zero-dependency slog.Handler that writes tinted (colorized) logs. Its output format is inspired by the zerolog.ConsoleWriter and slog.TextHandler. I am packaging this primarily for my own selfish reasons, however I can see it being useful to other Go packages which may wish to import it in future. I will maintain it as a member of the Debian Go Packaging team.
Bug#1067184: ITP: krecorder -- recorder application
Package: wnpp Severity: wishlist Owner: Salvo Tomaselli X-Debbugs-Cc: debian-devel@lists.debian.org, ltw...@debian.org * Package name: krecorder Version : 24.02.0 Upstream Contact: Devin Lin * URL : https://apps.kde.org/it/krecorder/ * License : GPL Programming Lang: C++ Description : recorder application kirigami based audio recorder for plasma. It can be used on small touchscreens or on desktop
Bug#1067183: ITP: skladnik -- formerly known as ksokoban, a sokoban game
Package: wnpp Severity: wishlist Owner: Salvo Tomaselli X-Debbugs-Cc: debian-devel@lists.debian.org, ltw...@debian.org * Package name: skladnik Version : 0.5.2 Upstream Contact: Łukasz Kalamłacki * URL : https://apps.kde.org/it/skladnik/ * License : GPL Programming Lang: C++ Description : formerly known as ksokoban, a sokoban game The usual sokoban game, about pushing things on a destination inside a maze.
Re: Package marked for autoremoval due to closed bug? [and 1 more messages]
Hi,
On 19-03-2024 11:32 a.m., Ian Jackson wrote:
Paul Gevers writes ("Re: Package marked for autoremoval due to closed bug?"):
For bookkeeping purposes, please usertag downgraded bugs with user
release.debian@packages.debian.org and usertag time_t-downgrade.
I was informed that time_t-downgrade isn't a valid usertag. Please use
time-t-downgrade instead.
Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: Package marked for autoremoval due to closed bug?
Hi Paul, Am Fri, Mar 15, 2024 at 09:52:06PM +0100 schrieb Paul Gevers: > For bookkeeping purposes, please usertag downgraded bugs with user > release.debian@packages.debian.org and usertag time_t-downgrade. > > Please be careful with downgrading RC bugs. I agree with Ian that it might make sense that Steve, who probably has a complete list of the bugs, can do this more safely than individual maintainers. (BTW, thanks again to Steve for doing all the work.) I think this migration has shown another problem which was not yet dicussed here. In Debian Med and R pkg team we identified packages where a time_t transition would be a) complex (there was no patch provided by time_t people) b) not helpful for users since usage on 32bit is probably zero Thus we considered it a good idea to remove 32bit architectures of those packages and its dependencies. This has shown that removing packages is a similarly time consuming way of dealing with this. The method to file individual bug reports for every single package on the side of the maintainer as well as dealing with the actual removal done by ftpmaster is quite inefficient. The removal bug for emboss[1] was filed six weeks ago (1 Feb 2024) and countless testing removal warnings were sent to the maintainer list since it is not fixed until now. Even worse for r-bioc-rhtslib[2] which had quite a tree of rdepends and kept several people (including ftpmaster) busy. Please understand me correctly: It is not blaming ftpmaster to be slow with ROM requests. Maybe I could have adjusted severity somehow - I just don't know any documentation what is appropriate or not. I made mistakes myself when filing ROM bugs against rdepends. My point is: I as a maintainer have control about what is inside the pool. But once a package is there I have a hard time to get it removed again. This does not make sense. We have tools who can generate a dependency tree. So filing separate bugs on one hand and deal with separate bugs on the other hand is somehow a rudiment from last century. I wished we could solve this more elegantly. Kind regards Andreas. [1] https://bugs.debian.org/1062371 [2] https://bugs.debian.org/1063376 -- http://fam-tille.de
Bug#1067153: ITP: reform-setup-wizard -- GTK-based first-boot setup wizard
Package: wnpp Severity: wishlist Owner: Johannes Schauer Marin Rodrigues X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: reform-setup-wizard Version : 0.1.0 Upstream Contact: Lukas F. Hartmann * URL : https://source.mnt.re/reform/mnt-reform-setup-wizard * License : GPL-3+ Programming Lang: Rust Description : GTK-based first-boot setup wizard This package provides a step-by-step graphical setup wizard for systems that are not setup using the Debian installer. As such it is supposed to be executed only once upon the first boot of a vanilla system image. Using a GTK-based user interface, it provides the following functionalities: - choosing the keyboard layout - choosing the local timezone - setting up a new user and password This utility will be used by the MNT Reform system images as provided on mntre.com. I intend to package this software for Debian so that I can also add this functionality to the system images I'm offering on https://reform.debian.net without having to resort to pre-built binary blobs. The reform-setup-wizard is not specific to the MNT Reform laptop but can be re-used on other platforms which are installed using a system image as well, like Raspberry Pi based systems. One of its dependencies, rust-pwhash, is not in Debian yet. I provided packaging for it to the Rust team here: https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/631 Thanks! cheers, josch
Re: Package marked for autoremoval due to closed bug? [and 1 more messages]
Steve Langasek writes ("Re: Package marked for autoremoval due to closed bug?"):
> Migration to testing is largely out of control of the maintainers at this
> point, it's very much dependent on folks rebootstrapping armel and armhf
> against the new library names. Should these bugs be downgraded again to
> important severity?
Yes.
It seems we have consensus on this.
Paul Gevers writes ("Re: Package marked for autoremoval due to closed bug?"):
> For bookkeeping purposes, please usertag downgraded bugs with user
> release.debian@packages.debian.org and usertag time_t-downgrade.
Rather than every maintainer affected by unactionable autoremoval
warnings[1][2] doing this by hand:
Steve, could you please do this for *all* the time_t transition RC
bugs?
That will reduce the scope for individual slips and mistakes,
fulfilling Paul's request:
> Please be careful with downgrading RC bugs.
[1] IMO unactionable autoremoval warnings are extremely undesirable.
The autoremoval system has two purposes: one is to get rid of things
that are in the way of other work, or just rotten. Another is to spur
action where action is needed. Action by a responsible maintainer, or
failing that by anyone else.
An unactionable autoremoval warning represents, at best, a robot
shouting at a human to do something that cannot be done. That can
lead to many humans from afar all turning up being confuseed at the
same problem trying to "help" (or at least, to try to stop the
screaming). If the autoremovals were to actually occur, it would be
automated destruction of non-broken stuff.
To preserve autorm's usefulness, unactionable autoremoval warnings
must be very rare. In this situation, Debian's processes have failed
to ensure this, and there hasn't been an effective backstop.
I suggest that when a widely-applicable problem is generating
unactionable autoremovals, the whole autoremoval system should be
suspended.
The problem is particularly severe when an underlying cause is that
some package, which contains the underlying RC bugfix, isn't
migrating. This seems to be becoming more common.
[2] In my case src:dgit depends on git-buildpackage. The autoremoval
robot wants to remove git-buildpackage because of the time_t bugs
against rpm, xdelta, and pristine-tar. One root cause is that
src:dpkg isn't migrating because of #1066952.
The logic of the autoremoval system is that as an affected maintainer
I ought to go and involve myself with #1066952.
And all of this is nonsense since surely we're not going to autorm
git-buildpackage, but right now we have a giant klaxon saying that's
what's going to happen.
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
