Bug#1034712: ITP: livi -- Minimalistic video player targeting mobile devices
Package: wnpp Severity: wishlist Owner: Guido Günther X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: livi Version : 0.0.3 Upstream Contact: Guido Günther * URL : https://gitlab.gnome.org/guidog/livi * License : GPL Programming Lang: C Description : Minimalistic video player targeting mobile devices A minimalistic GTK4 and gstreamer based video player for mobile phones like the Librem 5 aiming for minimal battery usage. It supports: - Inhibiting suspend/idle when playing video - li>Stopping video playback on (i.e. power button toggled) blank - Registering as default video player in GNOME control center - An indicator whether hardware accleration is in usex
Re: DEP 17: Improve support for directory aliasing in dpkg
On Fri, 21 Apr 2023 at 15:29:33 +0100, Luca Boccassi wrote:
> After Bookworm ships I plan to propose a policy change to the CTTE and
> policy maintainers to forbid shipping files in the legacy directories
> altogether, followed by a debhelper change to adjust any stragglers
> automatically at build time and a mass rebuild
That seems quite likely to trigger the scenario Helmut is trying to avoid,
which if I understand correctly is this:
* foo_12.0 in Debian 12 ships /lib/abcd
* bar_13.0 takes over /lib/abcd from foo, but because of either your
proposed change or a manual action by the maintainer, it is actually in
the data.tar as ./usr/lib/abcd (not ./lib/abcd like it was in foo_12.0)
* the maintainer of bar didn't add the correct Breaks/Replaces on foo
* a user upgrading from Debian 12 to 13 installs bar_13.0, perhaps pulled
in as a dependency
* expected result: dpkg refuses to unpack bar ("trying to overwrite ..."),
the upgrade is cancelled, and the user reports a RC bug in bar
* actual result: /usr/lib/abcd in bar quietly overwrites /lib/abcd from foo
* if bar is subsequently removed, then dpkg (and therefore apt) thinks foo
is fully functional, but in fact /{usr/,}lib/abcd is missing
(For simplicity I've described that scenario in terms of files directly
shipped in the data.tar, but dpkg also tracks the ownership of files
created by dpkg-divert or alternatives, and similar things can happen
to those.)
I had hoped that the last section of technical committee resolution
#994388 (which concerns this situation) would become irrelevant in Debian
13, but it's looking as though without the sort of dpkg changes discussed
in this thread, the concern about files moving between packages would
remain a valid concern.
However, as far as I can see, the other reasons not to do this that were
mentioned in the last section of #994388 *do* become irrelevant in Debian
13, so solving the files-moved-between-packages thing is the last major
blocker for doing what you propose. (Unless someone has a reason why this
is not the case?)
You might reasonably say that "the maintainer of bar didn't add the
correct Breaks/Replaces on foo" is a RC bug in bar - and it is! - but
judging by the number of "missing Breaks/Replaces" bug reports that have
to be opened by unstable users (sometimes me), it's a very easy mistake
to make.
One thing that's particularly tricky about this is that the move from
/ into /usr and the move from foo to bar might be 18 months apart if
they happen to occur at opposite ends of our stable release cycle. In
particular, if the move from / into /usr is done as soon as the Debian 13
cycle opens, we cannot predict whether the packages that have undergone
that move will also need to undergo a package split/merge at some point
in the following 18 months (but it's reasonable to assume that at least
some of them will).
smcv
Re: DEP 17: Improve support for directory aliasing in dpkg
Hi Luca, On Fri, Apr 21, 2023 at 03:29:33PM +0100, Luca Boccassi wrote: > After Bookworm ships I plan to propose a policy change to the CTTE and > policy maintainers to forbid shipping files in the legacy directories > altogether, followed by a debhelper change to adjust any stragglers > automatically at build time and a mass rebuild, plus MBF for the small > % that does not use dh and a piuparts test to stop migration for > anything that is uploaded and doesn't comply. That should bring the > matter to an end, without needing to modify dpkg. I agree with the goal of removing aliases by moving files to their canonical locations. However, I do not quite see us getting there in the way you see it, but maybe I am missing something. As long as dpkg does not understand the effects of aliasing, we cannot safely move those files and thus the file move moratorium will have to be kept in place. And while moving the files would bring the matter to an end, we cannot do so without either modifying dpkg or rolling back the transition and starting over. I hope that we all agree that rolling back would be too insane to even consider, but I fail to see how you safely move files without dpkg being changed. Can you elaborate on that aspect? I'd also be interested on how you plan to move important files in essential packages. This is an aspect raised by Simon Richter and where I do not see an obvious answer yet. Helmut
Re: DEP 17: Improve support for directory aliasing in dpkg
Hi Raphaël, On Fri, Apr 21, 2023 at 03:03:10PM +0200, Raphael Hertzog wrote: > Here you are considering all files, but for the purpose of our issue, > we can restrict ourselves to the directories known by dpkg. We really > only care about directories that have been turned into symlinks (or > packaged symlinks that are pointing to directories). That's a a much lower > number of paths that we would have to check. Considering just sid amd64 main, I count around 14 directories, which clearly is less than millions. A typical installation will only have a fraction of that, probably less than 5. I think this is the number of stat() calls we'd have to do. I timed this on a reasonably fast system (admittedly using Python but I think the overhead is not huge) and this can complete in around 0.1s (with a hot vfs cache). So depending on the cache invalidation strategy this may be viable or not. This is looking at it from a performance point of view. Guillem also raised that this is changing the source of truth from the dpkg database to the actual filesystem, which Guillem considers wrong and I find that vaguely agreeable. > We don't add any new public interface to dpkg, but we also have the > possibility to remove to /var/lib/dpkg/aliases to force an new scan > (some sort of "dpkg --refresh-aliases" without an official name). Can I rephrase this as your cache invalidation strategy is that any external entity (such as a maintainer script) introducing aliases should explicitly invalidate the cache. > It might still be cleaner to have that "dpkg --refresh-aliases" command > so that we can invoke it for example in "dpkg-maintscript-helper > symlink_to_dir/dir_to_symlink" when we are voluntarily turning a directory > into a symlink (or vice-versa). If you put it this way, it is not that different from the --add-alias/--remove-alias proposal. It is a different interface to dpkg, but the semantics are roughly the same: In both cases, something external to dpkg is responsible for performing the moves and creating the symbolic links followed by informing dpkg about the alias (explicitly or implicitly via scanning directories). Would you agree with me that this is a minor adaption of DEP17? In essence what changes is the way that a user communicates aliases to dpkg, but the assumption that a user must communicate aliases to dpkg is not affected. I'd be fine with changing this aspect in principle, but I still consider this a new public interface to dpkg with much the same effects to long term maintenance. > In any case, now that you have a database of aliases, you can do the other > modifications to detect conflicting files and avoid file losses. > > How does that sound? It sounds all the same as DEP17 with a different color to me. Hope I got it right. What I tried ruling out as naive solution is eliminating the need to tell dpkg about aliasing changes and then we'd have to incur this 0.1s delay after every maintainer script invocation, which would amount to 5 minutes of stat()ing on a typical dist-upgrade assuming a hot vfs cache on a fast x86 CPU. > The proposal I made above is not a real database in the sense that we > don't record what was shipped by the .deb when we installed the files... > it's rather the opposite, it analyzes the system to detect possible > conflicts with dpkg's view of the system. I think that Guillem considers this a bad property as he has expressed in his reply on debian-dpkg, that .debs should be the source of truth. > It can be seen as complimentary to it. In any case, I don't see how > implementing metadata tracking would help to solve the problem that we > have today. dpkg would know that all .deb have /bin as a directory and > not as a symlink, and it would be able to conclude that the directory > has been replaced by a symlink by something external, but that's it. Let me put it subtly different. As we currently do not ship the aliasing symbolic links in any data.tar, metadata tracking will not tell dpkg about the aliasing and therefore metadata tracking cannot help resolve the current situation (as singular measure). We can only add the symbolic links to a data.tar after the aliasing has been resolved (see Simon Richter's mails on how dpkg resolves directory vs symlink) and thus metadata tracking can only help with resolving the situation after we have fully resolved the situation. I don't see a way to resolve this vicious circle and shall update the DEP17 text. Helmut
Re: DEP 17: Improve support for directory aliasing in dpkg
Hi Simon, On Fri, Apr 21, 2023 at 06:05:27PM +0200, Simon Richter wrote: > The first thing we need consensus on, IMO, is the definition of "complete". I honestly had hoped that we did have consensus on this point. > The maintainers of the usrmerge package consider the status quo an > acceptable technical solution, so their definition of "complete" is to roll > out the change to the remaining users. I find this description inaccurate. As is evident from this very thread, Luca Boccassi considers that there is more work to do and intends to do some of it. For clarity let me propose the following requirements for the definition of done: * All files shipped in Debian packages are shipped in their canonical location rather than an aliased path. * The symbolic links are part of some essential package. * Therefore no special handling code is needed in bootstrapping tools for future releases. Would anyone disagree with this? > The alternative would be a consensus that dpkg is simply not expected to > always leave the system in a useful state if it encounters certain invalid > situations, and hoping that we will also be able to point to a few million > installations where that has not exploded and call it a success, but that > would need to be communicated. This is a view that I had initially ruled out as absurd, but I see how it has some appeal. In essence, our strategy would be based on extensive testing (and occasionally getting it wrong). It would also be based on considering the undefined behaviour area of dpkg and integral part of our solution, which would make modifying dpkg very difficult (as any innocuous change to dpkg might break things). However, if we can get past that period, we'd be able to leave the transition behind without turning dpkg into a Jenga tower (as Guillem put it). I am still not convinced of this option. My main reason for disliking it is that it shifts the effort from the proponents to everyone else. The aliasing effects consume so much mental capacity of regular package maintainers that I find it difficult to justify enduring that any longer and the approach essentially encodes this as the way forward. > Testing alone will be an absolute nightmare because we can enter invalid > states through multiple avenues, for example, if I have a conflict > > a.deb: /bin/test > b.deb: /usr/bin/test > c.deb: /bin -> /usr/bin Arguably, we can rule out a lot of test cases by policy. We already have policy that forbids the combination of a.deb and b.deb in Debian. This property can relatively simply be checked on a distribution level and therefore I think we can entirely skip this case. So while I agree that testing will be a difficult part of it, I also think that reducing the test matrix to what we really need is key to keeping it manageable. > The latter case is also what should happen if b declares "Replaces: a". > > # move file to /usr, install symlink, then remove symlink, move back > dpkg -i a.deb c.deb > dpkg --remove c.deb Again, I think c.deb would likely be essential and since removal of essential packages is undefined, we can remove such cases from our test matrix. Helmut
Re: DEP 17: Improve support for directory aliasing in dpkg
On Sat, 22 Apr 2023 at 11:41, Simon McVittie wrote:
>
> On Fri, 21 Apr 2023 at 15:29:33 +0100, Luca Boccassi wrote:
> > After Bookworm ships I plan to propose a policy change to the CTTE and
> > policy maintainers to forbid shipping files in the legacy directories
> > altogether, followed by a debhelper change to adjust any stragglers
> > automatically at build time and a mass rebuild
>
> That seems quite likely to trigger the scenario Helmut is trying to avoid,
> which if I understand correctly is this:
>
> * foo_12.0 in Debian 12 ships /lib/abcd
> * bar_13.0 takes over /lib/abcd from foo, but because of either your
> proposed change or a manual action by the maintainer, it is actually in
> the data.tar as ./usr/lib/abcd (not ./lib/abcd like it was in foo_12.0)
> * the maintainer of bar didn't add the correct Breaks/Replaces on foo
> * a user upgrading from Debian 12 to 13 installs bar_13.0, perhaps pulled
> in as a dependency
> * expected result: dpkg refuses to unpack bar ("trying to overwrite ..."),
> the upgrade is cancelled, and the user reports a RC bug in bar
> * actual result: /usr/lib/abcd in bar quietly overwrites /lib/abcd from foo
> * if bar is subsequently removed, then dpkg (and therefore apt) thinks foo
> is fully functional, but in fact /{usr/,}lib/abcd is missing
>
> (For simplicity I've described that scenario in terms of files directly
> shipped in the data.tar, but dpkg also tracks the ownership of files
> created by dpkg-divert or alternatives, and similar things can happen
> to those.)
>
> I had hoped that the last section of technical committee resolution
> #994388 (which concerns this situation) would become irrelevant in Debian
> 13, but it's looking as though without the sort of dpkg changes discussed
> in this thread, the concern about files moving between packages would
> remain a valid concern.
>
> However, as far as I can see, the other reasons not to do this that were
> mentioned in the last section of #994388 *do* become irrelevant in Debian
> 13, so solving the files-moved-between-packages thing is the last major
> blocker for doing what you propose. (Unless someone has a reason why this
> is not the case?)
>
> You might reasonably say that "the maintainer of bar didn't add the
> correct Breaks/Replaces on foo" is a RC bug in bar - and it is! - but
> judging by the number of "missing Breaks/Replaces" bug reports that have
> to be opened by unstable users (sometimes me), it's a very easy mistake
> to make.
>
> One thing that's particularly tricky about this is that the move from
> / into /usr and the move from foo to bar might be 18 months apart if
> they happen to occur at opposite ends of our stable release cycle. In
> particular, if the move from / into /usr is done as soon as the Debian 13
> cycle opens, we cannot predict whether the packages that have undergone
> that move will also need to undergo a package split/merge at some point
> in the following 18 months (but it's reasonable to assume that at least
> some of them will).
We already have piuparts tests detecting files moving, it should be
easy enough to extend that to check that the appropriate
Breaks/Replaces have been added. Correct me if I'm wrong, but I
believe it's already against policy to do this without
Breaks/Replaces, so it's not a use case that we need to support, no?
If someone does that by mistake, the package will not migrate to
testing.
Kind regards,
Luca Boccassi
Re: DEP 17: Improve support for directory aliasing in dpkg
On Sat, 22 Apr 2023 at 11:50, Helmut Grohne wrote: > > Hi Luca, > > On Fri, Apr 21, 2023 at 03:29:33PM +0100, Luca Boccassi wrote: > > After Bookworm ships I plan to propose a policy change to the CTTE and > > policy maintainers to forbid shipping files in the legacy directories > > altogether, followed by a debhelper change to adjust any stragglers > > automatically at build time and a mass rebuild, plus MBF for the small > > % that does not use dh and a piuparts test to stop migration for > > anything that is uploaded and doesn't comply. That should bring the > > matter to an end, without needing to modify dpkg. > > I agree with the goal of removing aliases by moving files to their > canonical locations. However, I do not quite see us getting there in the > way you see it, but maybe I am missing something. As long as dpkg does > not understand the effects of aliasing, we cannot safely move those > files and thus the file move moratorium will have to be kept in place. > And while moving the files would bring the matter to an end, we cannot > do so without either modifying dpkg or rolling back the transition and > starting over. I hope that we all agree that rolling back would be too > insane to even consider, but I fail to see how you safely move files > without dpkg being changed. Can you elaborate on that aspect? Moving files within _the same_ package is actually fine as far as I know. It's moving between location _and_ packages within the same upgrade that is problematic. The piuparts test I added is overzealous, but it doesn't need to be. > I'd also be interested on how you plan to move important files in > essential packages. This is an aspect raised by Simon Richter and where > I do not see an obvious answer yet. Do you have a pointer? Not sure I follow what "important" files means here, doesn't ring a bell. Kind regards, Luca Boccassi
Re: DEP 17: Improve support for directory aliasing in dpkg
Hi, On 22.04.23 11:36, Helmut Grohne wrote: For clarity let me propose the following requirements for the definition of done: * All files shipped in Debian packages are shipped in their canonical location rather than an aliased path. With proper support in dpkg, that is even somewhat optional. * The symbolic links are part of some essential package. Yes, but simple symbolic links in packages would lose against directories in other packages due to the symlink-vs-directory rule. Treating these as a conflict in the future instead of silently resolving them is not sufficient for transition handling, and making symlinks win over directories and cause aliases to be created automatically will cause curious and interesting effects if someone makes a mistake in a .links file while packaging. I'd ship the aliases as part of base-files, because that is Essential and has very few reverse dependencies, so giving it a Pre-Depends on a recent dpkg version does not cause ordering issues on upgrade. The Pre-Depends is ignored during bootstrap, but that is fine as the dpkg that is about to be installed is already new enough if it is from the same distribution. In addition, derived distributions that don't want usrmerge will likely ship their own base-files package. * Therefore no special handling code is needed in bootstrapping tools for future releases. For the requirement that unpacking Essential packages gives enough of a running system that installing packages is possible, this unpack phase needs to leave us with a working ld.so in the place the ABI standard requires it, so we probably need to ship the symlinks as symlinks in data.tar.gz, and register them as aliases from metadata so they are not overwritten by a directory. The alternative would be to keep shipping ld.so in /lib, and let dpkg do usrmerge during the phase where the unpacked Essential packages are overwritten using dpkg. We won't really be able to avoid at least some ugliness there, given the interaction between usrmerge and the ABI standard. The alternative would be a consensus that dpkg is simply not expected to always leave the system in a useful state if it encounters certain invalid situations My main reason for disliking it is that it shifts the effort from the proponents to everyone else. The aliasing effects consume so much mental capacity of regular package maintainers Exactly that's what I'm feeling as well, and why I want dpkg to be able to reject invalid packages safely so if a maintainer makes a mistake, this can simply be fixed by an updated package. Testing alone will be an absolute nightmare because we can enter invalid states through multiple avenues, for example, if I have a conflict a.deb: /bin/test b.deb: /usr/bin/test c.deb: /bin -> /usr/bin Arguably, we can rule out a lot of test cases by policy. We already have policy that forbids the combination of a.deb and b.deb in Debian. This property can relatively simply be checked on a distribution level and therefore I think we can entirely skip this case. No, dpkg needs to be able to handle situations forbidden in Policy. File conflicts without declaring "Conflicts:" are also forbidden in Policy, but detecting these is one of the main functions of dpkg. # move file to /usr, install symlink, then remove symlink, move back dpkg -i a.deb c.deb dpkg --remove c.deb Again, I think c.deb would likely be essential and since removal of essential packages is undefined, we can remove such cases from our test matrix. Essential packages can become non-Essential in a later release, can change or be replaced, including piecewise. If we ship the symlinks inside the data.tar, then at least the latter is very unlikely, but I'd think that there needs to be a way to remove aliases. The only thing we could argue that this can be delayed for a release or two, but this would introduce additional error paths into package removal, and possibly create situations that the package resolver does not understand, so I'd rather not. Simon OpenPGP_signature Description: OpenPGP digital signature
Re: DEP 17: Improve support for directory aliasing in dpkg
On Sat, 22 Apr 2023 at 12:43:09 +0200, Helmut Grohne wrote: > Guillem also > raised that this is changing the source of truth from the dpkg database > to the actual filesystem, which Guillem considers wrong and I find that > vaguely agreeable. To be fair, dpkg does already have at least one case where it treats the filesystem as the source of truth, namely a local sysadmin (or even a package, I think?) substituting a symlink-to-directory for a "real" directory. It has supported this for a long time, and requires specific action to avoid that behaviour (usually the dir-to-symlink and symlink-to-dir maintscript actions). The strategy used in the usrmerge package wouldn't have worked otherwise. I believe the original use-case for this was offloading large subtrees to a secondary filesystem, like a symlink /usr/share/games -> /srv/large-secondary-disk/games (which is better achieved with bind-mounts, or perhaps btrfs subvolumes if you use btrfs, on modern systems). If I understand correctly, this feature is considered vaguely deprecated, but is also quite entrenched, to the extent that we even have wording in Policy specifically to make it work better, namely the rule about symlinks within a top-level directory (/usr/lib/foo/data -> ../../share/foo/data) being relative, while symlinks between separate top-level directories (/usr/bin/foo -> /etc/alternatives/foo -> /usr/bin/foo-full) are absolute. The key difference in how usrmerge uses this dpkg feature is that traditionally the target directory would be somewhere non-dpkg-managed (meaning that the resulting path aliasing doesn't affect dpkg's behaviour), whereas in usrmerge, both the symlink and the target directory are in the subset of the filesystem tree that is managed by dpkg (meaning that the resulting path aliasing becomes significant). smcv
Bug#1034738: ITP: libjenkins-api-perl -- wrapper around the Jenkins API
Package: wnpp Owner: Mason James Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libjenkins-api-perl Version : 0.18 Upstream Author : Colin Newell * URL : https://metacpan.org/release/Jenkins-API * License : Artistic or GPL-1+ Programming Lang: Perl Description : wrapper around the Jenkins API This package provides a Perl wrapper around the Jenkins API. More info for this Perl module at: https://metacpan.org/release/Jenkins-API More info for the Jenkins API at: https://jenkinsapi.readthedocs.io The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#1034741: ITP: libnet-pop3s-perl -- SSL/STARTTLS support for Net::POP3
Package: wnpp Owner: Mason James Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libnet-pop3s-perl Version : 0.12 Upstream Author : Tomo M. * URL : https://metacpan.org/release/Net-POP3S * License : Artistic or GPL-1+ Programming Lang: Perl Description : SSL/STARTTLS support for Net::POP3 Net::POP3S implements a wrapper for Net::POP3, enabling over-SSL/STARTTLS support. This module inherits all the methods from Net::POP3. You may use all the friendly options that came bundled with Net::POP3. You can control the SSL usage with the options of new() constructor method. 'doSSL' option is the switch, and, If you would like to control detailed SSL settings, you can set SSL_* options that are brought from IO::Socket::SSL. Please see the document of IO::Socket::SSL about these options detail. Just one method difference from the Net::POP3, you may select POP AUTH mechanism as the third option of auth() method. As of Version 3.10 of Net::POP3(libnet) includes SSL/STARTTLS capabilities, so this wrapper module's significance disappareing. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#1034742: ITP: libcollision-2d-perl -- continuous 2d collision detection
Package: wnpp Owner: Mason James Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libcollision-2d-perl Version : 0.07 Upstream Author : Zach Morgan * URL : https://metacpan.org/release/Collision-2D * License : Artistic or GPL-1+ Programming Lang: Perl Description : continuous 2d collision detection Collision::2D contains sets of several geometrical classes to help you model dynamic (continuous) collisions in your programs. It is targeted for any game or other application that requires dynamic collision detection between moving circles, rectangles, and points. The package will be maintained under the umbrella of the Debian Perl Group. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#1034743: ITP: node-theming -- CSS-in-JS theming solution for ReactJS
Package: wnpp Severity: wishlist Owner: Yadd X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: node-theming Version : 3.3.0 Upstream Contact: https://github.com/cssinjs/theming/issues * URL : https://github.com/cssinjs/theming * License : Expat Programming Lang: Javascript Description : CSS-in-JS theming solution for ReactJS node-theming is a CSS-in-JS theming solution for ReactJS. * ThemeProvider allows one to pass, update, merge and augment "theme" through context down react tree * withTheme allows one to receive theme and its updates in your components as a "theme" prop * createTheming allows one to integrate "theming" into its CSS-in-JS library with custom "channel" node-theming is a dependency of node-jss which is a dependency of JupyterLab. It will be maintained under JS Team umbrella.
Bug#1034745: ITP: node-shallow-equal -- Node.js light library to shallowly compare JavaScript objects
Package: wnpp Severity: wishlist Owner: Yadd X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: node-shallow-equal Version : 3.1.0 Upstream Contact: https://github.com/moroshko/shallow-equal/issues * URL : https://github.com/moroshko/shallow-equal * License : Expat Programming Lang: JavaScript Description : Node.js light library to shallowly compare JavaScript objects node-shallow-equal provides super light functions to deeply compare JavaScript Objects. It's a dependency of node-jss which is a dependency of Jupyterlab. It will be maintained under JS Team umbrella.
