[Summary]: Another take on package relationship substvars
Hi
It seems the discussion on this topic has settled, so I am now doing a
summary of the discussion as I understand it.
* Generally, the original proposal seems to have been received
favorably at a conceptual level.
* Several people requested the scope to be expanded to extra fields.
So far, no one seems to have questioned any of the extra fields
proposed. Accordingly, I will expand the scope to all mentioned
extra fields (such as Built-Using/Static-Built-Using and negative
relationship).
* My alternative proposal of making relational substvars mandatory
did not have anyone supporting. Additionally, Simon McVittie provided
a strong argument for why the alternative would scale poorly. Given
the argument from Simon and no one openly supporting that proposal,
I am considering it a dead-end with no support.
* All the concerns raised related to promotion and demotion of
substvars were related to the shlib subvars (such as
${shlib:Depends} vs Pre-Depends/Recommends). I have yet to see anyone
concerned about a non-shlib related variable, which is great since
dpkg-shlibdeps as the only substvars provider has infrastructure for
promotion/demotion. No case presented seems to have been problematic
nor controversial. I have included an extended section below on this
topic for the details, should you be interested in those.
* Guillem proposed some concrete ideas for moving parts of the
implementation into the dpkg layer, which seems fine with me.
I consider these implementation detail and will handle that
bilaterally with Guillem.
In other words, it seems like there is consensus that this proposal at a
conceptual level is acceptable. I will look into the implementation
details with Guillem (as mentioned, in a smaller forum).
I fully anticipate that there will be a transition for this feature
(such as a debhelper compat bump) to ensure we have a controlled
migration. Notably substvar demotion does not work out of the box (see
below) as one of my arguments to ensure it happens in a controlled manner.
= Detailed explanations =
From here on, I will expand on the substvars cases and how they work.
If you are not interested in those, you can stop reading as the
remainder of the email is dedicated only to this topic.
# Promotion and demotion of substvars
For those, who are curious or concerned about promotion or demotion of a
substvar, here is an extended coverage of cases presented in the
discussion and how they work.
First, a bit of terminology as people might not have read the full
thread. I use the word "promotion" when the substvar is used in a
**stronger** field that the one it is named for. Example:
# The substvar in this example is promoted to Pre-Depends
Pre-Depends: ${shlib:Depends}
Demotion is the opposite. Here the substvars implies a strong field than
the one it is used in:
# The substvar in this example is demoted to Recommends
Recommends: ${shlib:Depends}
For the case, where the tool can split the substvar into multiple
substvars, I will use the phrase selective promotion or selective
demotion of the content. The only known tool that supports this is
`dpkg-shlibdeps` and the only known usage involves the ${shlib:*} namespace.
There are multiple cases to cover and how they would interact with this
proposal:
* Selective promotion/demotion of content (Unaffected)
* Full substvar promotion (Unaffected)
* Full substvar demotion (Breaks)
* Manual fiddling with substvars (Unaffected)
Each will be expanded in their own subsection below. The `(Unaffected)`
and `(Breaks)`-marker represents what happens in a rebuild of an
unchanged source package with with this proposal suddenly active. As
mentioned, I expect we will do this as an a opt-in style transition to
avoid unexpectedly triggering any cases that might break.
## Selective promotion/demotion of content
Selective promotion and demotion of the content works out of the box
with this proposal.
* The logic for splitting a substvars will generally be in debian/rules
via manual calls to dpkg-shlibdeps or dh_shlibdeps. This part remains
unaltered.
* The main difference is that you no longer have to manually any of the
substvars in debian/control.
This method generally only works with dpkg-shlibdeps, since that is the
only tool with infrastructure to do the splitting. At the same time, it
is also the only substvar provider mentioned in the discussion so far,
where anyone had an example of needing promotion or demotion.
Note in this case, the split off substvars will be named are the field
they go in. Strictly speaking, none of the substvars have been promoted
nor demoted in this particular case. This is also why it is promotion /
demotion of **content** rather than of the substvar itself.
## Full substvar promotion
This is the case of doing `
Bug#1065346: ITP: way-shell -- Gnome inspired desktop shell for Wayland compositors/window managers
Package: wnpp Severity: wishlist Owner: Birger Schacht X-Debbugs-Cc: debian-devel@lists.debian.org, bir...@debian.org * Package name: way-shell Version : no release yet Upstream Contact: Louis DeLosSantos * URL : https://github.com/ldelossa/way-shell/ * License : GPL-2 Programming Lang: C Description : Gnome inspired desktop shell for Wayland compositors/window managers A Gnome inspired desktop shell for Wayland compositors/window managers written in C and Gtk4. Way-Shell expects a Gnome-like environment to be available. This means DBus must be running and the following services must be available: Logind, NetworkManager, WirePlumber/Pipewire, PowerProfiles Daemon, UPower
Bug#1065352: ITP: libhyprlang -- Configuration language for Linux applications
Package: wnpp Severity: wishlist Owner: Alan M Varghese X-Debbugs-Cc: debian-devel@lists.debian.org, a...@digistorm.in * Package name: libhyprlang Version : 0.4.1 Upstream Contact: vaxerski * URL : https://github.com/hyprwm/hyprlang * License : GPL Programming Lang: C++ Description : Configuration language for Linux applications The hypr configuration language is an extremeley efficient, yet easy to work with, configuration language for Linux applications. This is a dependency for the Hyprland window manager for Wayland[1][2]. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040971 [2] https://github.com/hyprwm/Hyprland/
Bug#1065378: ITP: libiir -- DSP IIR realtime filter library
Package: wnpp Severity: wishlist Owner: Stephen Kitt X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libiir Version : 1.9.4 Upstream Author : Bernd Porr * URL : https://github.com/berndporr/iir1 * License : MIT Programming Lang: C++ Description : DSP IIR realtime filter library libiir is an infinite impulse response library implementing Butterworth, RBJ, and Chebychev filters. The filter processes data sample by sample for realtime processing. This is a dependency of dosbox-staging. The GH repository is named iir1 but internally the library refers to itself as iir (e.g. for pkg-config). The current soname is libiir.so.1 so the library binary package will end up being called libiir1.
Re: Any way to install packages+run autopkgtests on porterbox machines?
Hi, On 01-03-2024 1:58 p.m., Nilesh Patra wrote: Have you found any way around these? https://salsa.debian.org/mbanck/dd-autopkgtest/ Alternative, probably not the best solution, but until better ones are found (and as long it's not too much used): Antonio and I offer DD's access to testbeds with failed tests when contacted (preferably by signed e-mail). This is no wildcard access, we'll need to align on the time you want access. The advantage is that you run inside the setup that's used by ci.d.n on the arch you need. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Another take on package relationship substvars
> Can we also consider ${*:Built-Using} as typically seen in
> ${sphinxdoc:Built-Using}?
> This is another field that people keep forget adding. While missing
> this field is not severely harmful, having it automatically handled
> would be beneficial.
Automatic expansion of ${*:(Static-)Built-Using} would improve the
situation for variables managed by packaging helpers.
But for the record, dh-builtusing [1] already provides an
auto-definition of ${dh-builtusing:[DPSa-z]+} variables expanded by
the maintainer in the (Static-)Built-Using fields.
The use cases should rarely overlap, but the mechanisms seem
compatible. For example, dh_builtusing parses debian/*.substvars so
that dh_sphinxdoc may one day set
sphinxdoc:Built-Using=${dh-builtusing:libjs-sphinxdoc}.
[1] https://manpages.debian.org/testing/dh-builtusing/dh_builtusing.1.en.html
Re: Any way to install packages+run autopkgtests on porterbox machines?
On Sun, Mar 03, 2024 at 06:09:47PM +0100, Paul Gevers wrote: > On 01-03-2024 1:58 p.m., Nilesh Patra wrote: > > Have you found any way around these? > > https://salsa.debian.org/mbanck/dd-autopkgtest/ Thanks, I will use this for autopkgtests. This however also only partially solves the issue for me. If I want to run tests with another package (say a test dependency) that I fixed locally on a particular arch (which is not amd64) -- how doI run autopkgtests with this combo on a porter machine? Best, Nilesh signature.asc Description: PGP signature
Re: Any way to install packages+run autopkgtests on porterbox machines?
On Sun, 03 Mar 2024 at 22:52:26 +0530, Nilesh Patra wrote: > If I want to run tests with another package (say a test dependency) that I > fixed > locally on a particular arch (which is not amd64) -- how doI run autopkgtests > with > this combo on a porter machine? Unfortunately, the general answer is that you can't. If this makes it impossible for you to solve a bug, then you can't solve that bug without assistance from a user of that architecture. For specific classes of package, you might be able to work around this: for example if you've attempted to fix a bug in a C/C++ library, you might be able to convince the autopkgtest to pick up the patched library via LD_LIBRARY_PATH, or if you've attempted to fix a bug in a Python library, the same is true for PYTHONPATH. This will not be testing the package "as-installed", so it's far from perfect, but it's better than nothing. If we had porterboxes where it was possible to create a container environment as an unprivileged user (see https://salsa.debian.org/debian/grow-your-ideas/-/issues/40, which I'm sorry to say I have not had sufficient energy to drive beyond opening the initial suggestion) then that would be a 95% solution for this, but that would require the DSA team to be willing to allow that, which would increase security exposure to an extent that might well be considered to be unacceptable. I'm sorry to be bringing bad news without presenting an actionable solution. smcv
Re: Any way to install packages+run autopkgtests on porterbox machines?
On Fri, Mar 01, 2024 at 06:28:50PM +0530, Nilesh Patra wrote: > When I want to fix autopkgtests for a package on a particular architecture, I > currently > see no way to run autopkgtests before I dput since porter boxes do not > provide root > access which autopkgtest needs. Not exactly an answer, but an alternative - it's easy to get an ARM VM from many cloud providers. For a buck or two, I've avoided hours of futzing with the porterboxes. I've heard of providers with PPC, but haven't ever actually used one. Ross
Re: hardinfo rebooted as hardinfo2 - community edition - RELEASE 2.0.12
Hi Simon Quiqley, (CC: debian-devel) I'm trying to figure out how to get the hardinfo2 - release 2.0.12 into debian repository. hardinfo2 is a community fork of hardinfo and should continue as hardinfo package, currently maintained in debian by Simon Quiqley. Salvo Tomaselli suggested to do ITP - And I would really love a common platform for developers and debian maintainers along with an easy to maintain package. - But the pro's on "#debian-mentors on oftc" are so out of my league. - I am missing the overview - eg. how to test the debian build system with packages - do I need a salsa git? - Is this for project maintainers also? I have made deb source package with the build-in CPack - it has a debian directory - see https://github.com/hardinfo2/hardinfo2/releases/tag/release-2.0.12 attachments. All the binary packages for multiple architectures also work for all debian (7-13) - see https://hardinfo2.org/github/?latest_prerelease But according to talk on oftc with sney, this might not be good enough for debian package building system. So I started doing something like in your salsa git. https://salsa.debian.org/tsimonq2/hardinfo/-/tree/master/debian?ref_type=heads Guess that I have to be a debian maintainer for doing the salsa git?! - Why does CPack not work with debian build system - could a small script fix it like: https://github.com/hardinfo2/hardinfo2/blob/master/tools/create_debian_source.sh *I have no knowledge about debian distributions building - but if anyone from debian would help us - _the hardinfo2 community project closes ALL BUGS in BTS for hardinfo!!_* - Hoping that could make someone interesting in guiding/helping with debian repository update of hardinfo to hardinfo2 community edition for all tested versions (debian 7-13(sid)). In advance thanx,* * *Here is the status of hardinfo debian bugs - _All except 2 on wish list are to be closed_ - And there are a lot more fixes in hardinfo2 - release 2.0.12!: * #853749 [i| | ] [hardinfo] hardinfo gets segmentation fault -> FIXED ~7 crashes and alot more #947159 [i| | ] [hardinfo] hardinfo segfaults when running benchmarks -> FIXED out of range crash Outstanding bugs -- Normal bugs; Unclassified (7 bugs) #523930 [n| | ] [hardinfo] [hardinfo] After some time it stops giving any kind of information -> FIXED OLD ERROR #585685 [n| | ] [hardinfo] hardinfo: Sometimes hangs when using "Devices->Storage". Missed dependencies. -> FIXED udisks2 #638951 [n| | ] [hardinfo] hardinfo: does not show usb devices -> FIXED sysfs #658985 [n| | ] [hardinfo] hardinfo: benchmark graphic bar lengths confusing and undocumented. -> FIXED #721122 [n| | ] [hardinfo] hardinfo: unable to generate or/and save reports -> FIXED OLD ERROR #967518 [n| |♔] [src:hardinfo] hardinfo: depends on deprecated GTK 2 -> FIXED GTK3 #1014266 [n| | ] [src:hardinfo] hardinfo: Consider packaging new upstream snapshot? - FIXED when hardinfo2 released as hardinfo package. Outstanding bugs -- Minor bugs; Unclassified (4 bugs) #492989 [m| | ] [hardinfo] hardinfo: doesn't use gnome preferred browser -> FIXED xdg_open #524844 [m| | ] [hardinfo] hardinfo: benchmark results unreadable -> FIXED GTK3 #572799 [m| | ] [hardinfo] hardinfo: dipslays SATA drives as SCSI -> FIXED sysfs #886280 [m| | ] [hardinfo] hardinfo: Change icon in .desktop file -> FIXED .desktop file Outstanding bugs -- Wishlist items; Patch Available (1 bug) #1051775 [w|+| ] [hardinfo] hardinfo: Please add support for hardinfo -> FIXED loongarch Outstanding bugs -- Wishlist items; Unclassified (1 bug) #486471 [w| | ] [hardinfo] [hardinfo] library for icons which are in hardinfo and tango? -> CLOSE WON'T FIX Forwarded bugs -- Minor bugs (1 bug) #483136 [m| |↝] [hardinfo] [hardinfo] shows only one temperature-sensor -> FIXED Forwarded bugs -- Wishlist items (6 bugs) #446613 [w| |↝] [hardinfo] gpu benchmark -> *ON WISH LIST - LEAVE OPEN* #455568 [w| |↝] [hardinfo] hardinfo: 'Storage>IDE Disks>CD-RW 52x24>Speeds' gives puzzling DVD speed. -> FIXED OLD ERROR #455569 [w| |↝] [hardinfo] hardinfo: Please add sorting to 'Computer>Kernel Modules', et al. #458507 [w| |↝] [hardinfo] improve benchmark-system -> FIXED new methods #458838 [w| |↝] [hardinfo] benchmarks: marking average -> FIXED on webpage - lot more to come. #487835 [w| |↝] [hardinfo] [hardinfo] phoronix & hardinfo? -> *ON WISH LIST - LEAVE OPEN* above is from: https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;src=hardinfo Best Regards hardinfo2 *Søren B. Kristensen* hwspeedy hardinfo2 Community Maintainer GitHub - https://github.com/hardinfo2/hardinfo2 Project www - https://hardinfo2.org On 02/03/2024 02:58, hwspeedy wrote: Hi Simon Quigley, Debian Maintainer, (CC: debian-devel list) We are proud to suggest new hardinfo2 release 2.0.12 to be included in debian repositories - test on debian 7 - SID(13). https://github.com/hardinfo2/hardinfo2/releases/tag/release-2.0.12
Re: time_t transition and bugs
On Sat, Mar 02, 2024 at 10:37:33PM +0500, Andrey Rahmatullin wrote: > On Sat, Mar 02, 2024 at 06:34:43AM -0700, Antonio Russo wrote: > > There's a similar issue with versioned dependencies by un-transitioned > > packages have on non-t64 libraries (e.g., libqt5sql5). > It's not similar, it's caused by some t64 libraries having wrong Provides. > I've filed bugs about this on poppler, qt5 and curl, there may be more. As mentioned on IRC, I isolated the bug in the script that caused this, which allowed working out the full list of affected packages. https://paste.debian.net/1309262/ curl, nordugrid-arc, poppler, qtbase-opensource-src, and xmlrpc-c have been uploaded with the fix. petsc will take a little bit, as there are other bugs that need fixing at the same time. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: New requirements for APT repository signing
Johannes Schauer Marin Rodrigues writes: >> APT 2.7.13 just landed in unstable and with GnuPG 2.4.5 installed, >> requires repositories >> to be signed using one of >> >> - RSA keys of at least 2048 bit >> - Ed25519 >> - Ed448 >> >> Any other keys will cause warnings. These warnings will become >> errors in March > I talked to David in #debian-devel and had a look at apt commit 50e3fee26a. > This change requires a version of gpgv with support for the > --assert-pubkey-algo commandline argument. The version of gnupg2 in unstable > or > experimental does not include this, so it seems we cannot currently test this > in Debian. > > Furthermore, if you really need support for repositories with fewer RSA bits > even after a new version of gnupg2 lands in Debian, you can change the apt > configuration APT::Key::Assert-Pubkey-Algo which has a default value of > ">=rsa2048,ed25519,ed448" to something else or set it to the empty string > to entirely disable this functionality. > > Maybe this helps someone. It does - but also makes me wonder: is this going to affect Debian users with 3rd party repositories when they upgrade to trixie? (or is that not yet known?) (release-notes do say to remove all 3rd party packages before upgrades but i suspect that is ignored: helpful to provide a heads-up anyway) Seems like a candidate for the release-notes: - happy to help draft, but would need some information:. - Does this affect 'official' debian repostitories? (i assume not) - Does this affect local repositories built with reprepro or other tools in debian? - If i am using 3rd party/local (reprepro etc) repositories with "old" signatures, will they stop working (assume a dist upgrade to trixie with new enough apt, gpg etc) - How will this affect upgrades: will apt error out or just keep packages back? - how would a user with 3rd party repos check if they are affected? (is there a command/file to check that shows the algorithm used for each repository enabled?) - how to disable this feature? I assume: if you need to re-enable a 3rd party repo with an older signature algorithm, you will need to add a file in /etc/apt/apt.conf.d/ (or use the -o option to apt) to set APT::Key::Assert-Pubkey-Algo to the algorithm used -- is there a way to say ">=rsa2048,ed25519,ed448 or X" where X is the algorithm needed to allow some repository to continue to be used? can we turn this off for just one un-updated repo and keep the check for everything else? or is the only workaround to set the option to the empty string? or is there a NEWS.Debian for apt we can point to that explains all this?
Re: dpkg --verify not helpful?
Andreas Metzler writes: > Hello, > > iirc it was recently proposed to add a suggestion to run dpkg --verify > to the trixie upgrade notes to find missing files due to the usr-merge > transition. (Cannot find the reference right now). https://lists.debian.org/debian-devel/2023/12/msg00167.html But i didnt add a bug against release-notes (yet). It would be very helpful if someone could summarise how 'dpkg --verify' is meant to be used -- is it a case of "ignore the output, if it exit 0 then all is well"?
Re: time_t transition and bugs
Thanks Steve for uploading a fixed curl on Saturday. Just checking did you notice amel/armhf are still not building due to secondary issues and n dependencies? https://buildd.debian.org/status/package.php?p=curl
Re: New requirements for APT repository signing
On 2024-03-03, RL wrote: > It does - but also makes me wonder: is this going to affect Debian users > with 3rd party repositories when they upgrade to trixie? (or is that not > yet known?) In theory. I don't know if there are any statistics on 'popular' 3rdparty repositories and their keys. But assuming they're doing key rolls at 5-10 years intervals or less, it should be okay. Or just if the 3rdparty repository doesn't have decade(s) long history. > (release-notes do say to remove all 3rd party packages before upgrades > but i suspect that is ignored: helpful to provide a heads-up anyway) But that doesn't remove the old imported keys from the keyring. Which I guess is the main issue is a combination of things: - People never reinstall their system - Someone 10 years ago added a now insecure key to their apt and forgot about it. - Modern hardware might be able to in the not too distant future recreate matching keys... Even if said repository is now dead and reoved from the keyring. If just one of those were not valid, we could probably keep ignoring the issue. /Sune
