Pause /usr-merge moves
Hi developers, I have unfortunate news regarding /usr-merge. I uncovered yet another problem that we haven't seen mentioned earlier. We do not yet know how to deal with it and it may take some time to come up with a good compromise. As a result, please pause further moves from / to /usr. Exceptions: * With more uploads, more systemd units will move. While such moves may trigger the new problem, I expect that to be rare. * Continue fixing RC bugs, in particular those that are due to dh_installsystemd or systemd.pc having moved to /usr. * Continue applying DEP17P7 mitigations for udev rules. Patches for these have been sent by Christian Hofstaedler and a few people from the Cambridge miniconf. These are unrelated. The rest of this mail is lots of funky details for those interested in understanding what went wrong here. Others are encouraged to do something more joyful :) Before we go, let me express sincere thanks to so many people that helped me track this down. In particular, the input of David Kalnischkies, Guillem Jover and Julian Andres Klode was invaluable. Fundamentally, Conflicts do not reliably prevent concurrent unpacking of packages as policy §7.4 may suggest. I have reported this as #1057199. Consequently, what we look at here is situations where Conflicts are used to mitigate file loss in the face of aliasing changes. Debian policy §6.6 is more precise and details that when unpacking a package, conflicting packages may be deconfigured and removed after the unpack. In theory, the difference should not be noticeable, because dpkg accurately tracks ownership of files with respect to packages. Aliasing changes this and can cause file loss. The situation arises when installing or upgrading a package to a version that happens to be in conflict with another package to be removed. A simple example is upgrading a bookworm system with molly-guard and systemd-sysv to sid and in the process deleting molly-guard. A similar issue happens when upgrading a bookworm system with busybox-static to sid and in that process installing busybox and thus removing busybox-static. The situation is hard to come by, because apt tends to remove the package that goes away early when it can. I have implemented a reproducer without apt for systemd-sysv #1057220. There are also situations where apt reproduces this available from the policy bug mentioned earlier. In particular, when one package has versioned Conflicts for another and the other has versioned Breaks for the former, this reproduces with apt. This essentially breaks DEP17 proposed mitigations M7 and M18. I have also locally extended dumat to produce a report of affected Conflicts and am attaching it to this mail. The only packages that have not yet migrated and have this problem are systemd-sysv, busybox/busybox-static and resolvconf and I have filed RC bugs for them. There are other instances in trixie already. I welcome ideas for solving these problems. Let me summarize those I already am aware of. Julian Andres Klode proposes adding a "barrier package" that we may call usrmerge-support (or repurpose usr-is-merged). Affected Conflicts can be moved to the barrier package and the conflicting package would then express Pre-Depends on the barrier package. When the barrier's postinst runs, any conflicting package definitely has been removed and due to using Pre-Depends, the conflicting package definitely has not been unpacked yet. Another option is duplicating affected files (e.g. using hard links) in the data.tar and then restoring lost files during postinst. Depending on what problem we are solving, we may also move to protective diversions (DEP17 M8). It also is not clear how easy it is to reproduce this bug class in an actual upgrade. It took long to find the issue for a reason. Depending on what files go missing, we may get away with asking users to dpkg --audit and then apt reinstall affected packages. That barrier package approach sounds relatively promising to me, but there is no implementation of that approach as of this writing. If you want to support finding a solution, please contribute to this email thread of join #debian-usrmerge on oftc. Helmut ineffective_conflicts.yaml Description: application/yaml
Re: inability to resolve localhost to 127.0.0.1 in IPv6-only environments
On 2023-12-01 12:30, Simon McVittie wrote: This does not prevent to have 127.0.0.1. I don't think this is a good use of time to fix builds broken because there is no IPv4 loopback. This is the same kind of artificial conditions as the 1-core builders. Unfortunately, no, it's a bit more complicated than that. Thanks for your explanation on that! I retract my position about building on IPv6-only environments and agree you should be able to build with an IPv6-only connectivity.
Bug#1057224: ITP: golang-github-microsoft-dev-tunnels -- Dev Tunnels SDK
Package: wnpp Severity: wishlist Owner: Anthony Fok * Package name: golang-github-microsoft-dev-tunnels Version : 0.0.25-1 Upstream Author : Microsoft Corporation * URL : https://github.com/microsoft/dev-tunnels * License : Expat Programming Lang: Go Description : Dev Tunnels SDK (Go library) Dev tunnels allows developers to securely expose local web services to the Internet, control who has access, and easily & debug your web applications from anywhere. Learn more at https://aka.ms/devtunnels/docs Reason for packaging: Dependency of gh (>= 2.36.0)
Re: Default font: Transition from DejaVu to Noto
On Sun, 10 Sept 2023 at 02:57, Gunnar Hjalmarsson wrote: > Hi! > > With fontconfig 2.14, which entered testing last January, upstream > fontconfig prefers Noto over DejaVu in /etc/fonts/conf.d/60-latin.conf. > The change was not preceded by any discussion I'm aware of. It appears > to be related to this Fedora measure: > > https://fedoraproject.org/wiki/Changes/DefaultToNotoFonts > > So Debian was kind of caught off guard. > > This is in line with the consistent pattern of making changes without much user consultation in that world. Seems change relates to giving a consistent look n feel, by using the same font family across scripts. Since its been a while since this mail , I only want to respond to specific example picked. > My personal view is that it is a change in the right direction, and I > have taken a couple of follow-up steps in Debian. There are still loose > ends and more work to be done to achieve a consistent configuration in > this respect. However, before taking further steps, I feel there is a > need to reach out to a broader audience about the change. Hence this > message. Basically I'm asking if this move towards Noto is desirable > and, if so, I plea for relevant input for the completion of the transition. > > -- > These are some points for consideration I have in mind: > > * The task-* packages should be reconsidered. At first hand I'm thinking > of all the non-latin task-* packages which recommend a particular font. > Let's take task-hindi-desktop as an example, which currently recommends > fonts-lohit-deva. I think it would be consistent to change that to: > > Recommends: fonts-noto-core | fonts-lohit-deva > > fonts-noto-core covers "all" scripts, so with that package installed > there shouldn't be a need to install fonts-lohit-deva. (And for many > non-latin scripts Noto offers better quality than the other non-latin > font packages in the archive.) > > While above should be fine technically for Hindi desktop to be viewable, but as a user I would expect additional fonts that are available get installed too, fonts-lohit-deva , fonts-deva etc. Even though these extra fonts would not be used for desktop itself, and only in say LibreOffice. Karunakar
Re: Signature strength of .dsc
Hi, > > Dmitri, could you re-run the numbers with the debian-maintainer keyring? > > That is correct. I have updated the results now. > The 2,455 no public key has now become 1,238 Another is the DN keyring. Also I'd expect many keys to be found in older versions of the keyring package/keyring repository and on keyservers like keyserver.ubuntu.com signature.asc Description: This is a digitally signed message part.
Bug#1057201: ITP: rl-renderpm -- contains the ReportLab accelerator module
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rl-renderpm Version : 4.0.3 Upstream Contact: the ReportLab team * URL : https://www.reportlab.org/ * License : LGPL,MIT/X Programming Lang: C, Python3 Description : contains the ReportLab accelerator module rl_renderPM is a package containing the ReportLab accelerator module _renderPM which can be used to speedup the reportlab.graphics.renderPM functions. . The python bitmap render module reportlab.graphics.renderPM can either use rlPyCairo, pycairo and freetype-py or rl_renderPM + built in freetype libraries. . The choice is made by overriding the reportlab.rl_settings module value _renderPMBackend using one of the settings files reportlab/local_reportlab_settings.py, reportlab_settings.py or ~/.reportlab_settings, which are searched for in that order. . The default value of _renderPMBackend is 'rlPyCairo', but it can be set to '_renderPM' to use this extension which is based on an older library libart_lgpl. . Deprecation notice: --- . As from version 4.0, the package python-reportlab removes the renderPM extension which lets one create bitmap versions of complex graphics. It now uses other python libraries which wrap up freetype, the font rendering engine, so that one doesn't need to worry about linking to it. Under the hood it uses PyCairo as a renderer by default (rather than the no-longer-supported libart), and freetype-py to render text glyphs. See more at: https://docs.reportlab.com/releases/notes/whats-new-40/ This package makes it easier for people who were using python-reportlab << 4.0 to let their programs upgrade to python-reportlab >= 4.0 without modifying the configuration. It is maitained at https://salsa.debian.org/python- team/packages/rl-renderpm and I intend to keep it up to date (I am already uploader for the package python-reportlab)
Re: Signature strength of .dsc
On Fri, Dec 01, 2023 at 12:20:16AM +, Dimitri John Ledkov wrote: > And many of them cannot be verified using debian-keyring: > 2,455 no public key > 3 wrong key usage And how many can be verified? Do any show broken signatures? > Should we stop requiring signed .dsc on uploads? We had exactly that discussion some years ago in those two tag2upload thread. Maybe you should re-read that. Why do you believe that 0% is better then 90%? Bastian -- All your people must learn before you can reach for the stars. -- Kirk, "The Gamesters of Triskelion", stardate 3259.2
Re: Signature strength of .dsc
Hi, On Fri, 1 Dec 2023 at 10:50, Simon Josefsson wrote: > > Salvo Tomaselli writes: > > >> hi, on "no public key" list there are my uploads, I'm debian maintainer > >> (https://nm.debian.org/person/fantu/), I signed with my key and I have > >> DM upload right for them > >> (https://qa.debian.org/developer.php?login=fantonifabio%40tiscali.it) > > > > I think he just didn't check the debian-maintainer keyring at all. > > Dmitri, could you re-run the numbers with the debian-maintainer keyring? That is correct. I have updated the results now. The 2,455 no public key has now become 1,238 -- Regards, Dimitri.
Re: Clarification for broken packages in IPv6-only environments
Hi Vincent, Simon, On Fri, Dec 01, 2023 at 09:24:00AM +0100, Vincent Bernat wrote: > I don't think this is a good use of time to fix builds broken because > there is no IPv4 loopback. On Fri, Dec 01, 2023 at 11:30:50AM +, Simon McVittie wrote: > I agree that we should consider a working 127.0.0.1 to be "part of the > API" that packages (and in particular their test-suites) can assume, > even if there is no other IPv4 connectivity. I'd liket to offer a different perspective: complete IPv4 stack removal including loopback addressing is inevitable even if still a fair way off, it's a good idea to get an early start here. It's valuable for us to give upstreams backpressure on having legacy IP requirements in the package build process of all places and I don't think this is onerous requirement, it's just exposing holes in IPv6 support that should really be there already. Requiring support for IPv6 singlestack at runtime is a whole different beast ofc, but are we really seeing an insurmountable number of issues due to build time problems only? Either way I'd be happy to help get issues like this fixed upstream. --Daniel signature.asc Description: PGP signature
Re: inability to resolve localhost to 127.0.0.1 in IPv6-only environments
On Fri, 01 Dec 2023 at 09:24:00 +0100, Vincent Bernat wrote: > This does not prevent to have 127.0.0.1. I don't think this is a good use of > time to fix builds broken because there is no IPv4 loopback. This is the > same kind of artificial conditions as the 1-core builders. Unfortunately, no, it's a bit more complicated than that. I agree that we should consider a working 127.0.0.1 to be "part of the API" that packages (and in particular their test-suites) can assume, even if there is no other IPv4 connectivity. However, the situation for some Debian buildds is that there *is* a working 127.0.0.1, but resolving localhost with the AI_ADDRCONFIG option (which is the default under some circumstances, and widely regarded as a good idea to enable) will only return ::1, excluding 127.0.0.1 even though actually it works fine. This is unexpected, but it's actually AI_ADDRCONFIG behaving as documented: If hints.ai_flags includes the AI_ADDRCONFIG flag, then IPv4 addresses are returned in the list pointed to by res only if the local system has at least one IPv4 address configured, and IPv6 addresses are returned only if the local system has at least one IPv6 address configured. The loopback address is not considered for this case as valid as a configured address. — getaddrinfo(3) and no exception to this rule is made for names like "localhost" that we expect to be able to resolve statically via /etc/hosts, libnss-myhostname or systemd-resolved without creating DNS traffic. For "real" addresses, the AI_ADDRCONFIG behaviour is desirable: when you resolve (say) "www.debian.org", it stops your application from wasting time on resolving and trying to contact 130.89.148.77 if it only has IPv6 connectivity, or resolving and trying to contact 2001:67c:2564:a119::77 if it only has IPv4 connectivity, either of which would be a performance penalty. However, AI_ADDRCONFIG doesn't seem to be useful for "localhost" specifically: we probably want "localhost" to resolve to both 127.0.0.1 and ::1, even if there is no external connectivity on the matching protocol. One solution to this is for libraries and applications that resolve names to have a special exception for "localhost", and possibly also "*.localdomain" and other reserved names: hard-coding those names to resolve to 127.0.0.1 and/or ::1 without ever calling getaddrinfo(). This approach was suggested in RFC draft https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-let-localhost-be-localhost-02 (which unfortunately never made it to RFC status, I don't know why not), and is implemented in several web browsers and in GLib's GResolver (https://gitlab.gnome.org/GNOME/glib/-/blob/2.78.1/gio/gresolver.c?ref_type=tags#L485). However, this requires code changes in any library or application that calls getaddrinfo() directly, which is a boil-the-ocean sort of effort, because many software authors consider minimal dependencies to be a virtue and strongly prefer not to rely on a higher-level library like GLib that is in a position to solve this somewhat centrally for them. Another solution to this is for libraries and applications that resolve names to have a more narrowly-scoped exception for "localhost" and similar names: special-case those names to specify hints that do not include AI_ADDRCONFIG. This is what older versions of Mozilla (NSPR/Firefox) used to do, before switching to hard-coding the result of resolving localhost: https://hg.mozilla.org/releases/mozilla-1.9.2/rev/c5d74bcd7421 Again, this requires code changes in anything that calls getaddrinfo() directly. Doing name resolution with AF_UNSPEC happens to be a workaround for this, but only because of https://bugs.debian.org/854301, which is at least arguably a bug in its own right; so we should probably not rely on that one. Or, glibc itself could change its behaviour (but I have not seen any response from glibc maintainers to bug reports about this in the past, so that doesn't seem particularly likely to happen soon). I believe some Fedora developers were trying to make this happen in the past, but that seems to have stalled. See https://bugs.debian.org/952740 for a previous writeup of this, with links to numerous related issues. smcv
Bug#1057193: ITP: rl-accel -- accelerator module for the ReportLab Toolkit
Package: wnpp Severity: wishlist Owner: Georges Khaznadar X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: rl-accel Version : 0.9.0 Upstream Contact: the ReportLab team N * URL : https://www.reporlab.org/ * License : MIT/X Programming Lang: C, Python3 Description : accelerator module for the ReportLab Toolkit This is an accelerator module for the ReportLab Toolkit Open Source Python library for generating PDFs and graphics. . Since python-reportlab 4.0, the rl_accel C module which accelerates some functions is generally not necessary any more; Python is a lot faster than it was 20 years ago. You can still use it if you wish. As from version 4.0, the ReportLab Toolkit considers C modules as deprecated, this package can be used optionally to ensure a smooth transition for packages which depended on python3-reporlab << 4.0 The package is maintained at https://salsa.debian.org/debian/rl-accel and I intend to keep it up to date.
Re: Signature strength of .dsc
Salvo Tomaselli writes: >> hi, on "no public key" list there are my uploads, I'm debian maintainer >> (https://nm.debian.org/person/fantu/), I signed with my key and I have >> DM upload right for them >> (https://qa.debian.org/developer.php?login=fantonifabio%40tiscali.it) > > I think he just didn't check the debian-maintainer keyring at all. Dmitri, could you re-run the numbers with the debian-maintainer keyring? The numbers suggest to me that signing strength of DSC signatures on the contrary really do provide value and that it is working well. The instances of RIPEMD160/SHA1 I checked were old, and the numbers of failures are quite low compared to overall number of uploaded packages. Thus we have good assurance on the majority of packages. We should make sure RIPEMD160/SHA1 signatures are rejected going forward, as well as the wrong-key-usage. /Simon signature.asc Description: PGP signature
Re: Clarification for broken packages in IPv6-only environments
On 2023-11-30 22:42, Dale Richards wrote: I recently submitted a patch for uvloop that was FTBFS on IPv6-only builds (#1024079) and it really didn't take very long. While building/running in IPv6-only environments is not currently mandated in the Policy it's a fairly safe bet that it could/should be in future updates, so it makes sense to start making all packages agnostic of IP version now. This one seems to be because localhost was resolved to ::1, which is not Debian-default configuration where localhost is 127.0.0.1. Also, the patch is overly complex and is not upstreamed. While correct (even if the original test was testing with and without name resolution), this may become a maintenance hurdle in the future.
Re: Signature strength of .dsc
Il 01/12/2023 01:20, Dimitri John Ledkov ha scritto: Hi, Currently dak requires signatures on .changes & .dsc uploads. .changes with signatures are publicly announced and then .dsc are published in the archive with signatures. .changes references .dsc. All .dsc have Checksums-Sha256 for the files they reference, .dsc itself can be verified through strong checksum in Sources metadata, chained via InRelease to the strong debian archive key signature. The same is not true for signatures on .dsc themselves. Majority of .dsc use at least sha256 and can be successfully verified. But some use weak hash: 5 dsc signed using Hash: RIPEMD160 152 dsc signed using Hash: SHA1 And many of them cannot be verified using debian-keyring: 2,455 no public key hi, on "no public key" list there are my uploads, I'm debian maintainer (https://nm.debian.org/person/fantu/), I signed with my key and I have DM upload right for them (https://qa.debian.org/developer.php?login=fantonifabio%40tiscali.it) I did something wrong that I don't know? 3 wrong key usage Lists of affected .dsc are published at https://people.canonical.com/~xnox/dsc-analysis/ due to size. This makes me wonder if signatures on uploaded or published .dsc have any value at all. Ultimately one should use apt secure to retrieve both .deb and .dsc; and verify .changes signature if one wants to figure out authorship. Should we upload sourceful NMU to eliminate SHA1, RIPEMD160, wrong-key-usage signatures in .dsc? Should we stop requiring signed .dsc on uploads? -- Regards, Dimitri. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Clarification for broken packages in IPv6-only environments
On 2023-11-30 21:38, Paul Tagliamonte wrote: Now I would like to know if being able to run in an IPv6-only environment is a must have feature for any debian package? I run an IPv6 only LAN on my home network, where I use `jool`, and `dns64-prefix`+`unbound` to interoperate with legacy IP space. There's no assigned IPv4 addresses for hosts on that LAN. This does not prevent to have 127.0.0.1. I don't think this is a good use of time to fix builds broken because there is no IPv4 loopback. This is the same kind of artificial conditions as the 1-core builders.
Re: Signature strength of .dsc
Also note that some of the listed packages are signed with 1024-bit DSA (Logjam attack), which would be more concerning if there were no additional release signatures. Regards Stephan signature.asc Description: This is a digitally signed message part
