ITP: golang-github-gopasspw-pinentry -- Pinentry client in Go
Package: wnpp Severity: wishlist Owner: Taowa * Package name: golang-github-gopasspw-pinentry Version : 0.0.2-1 Upstream Author : Gopass Authors * URL : https://github.com/gopasspw/pinentry * License : Expat Programming Lang: Go Description : Pinentry client in Go Pinentry client in Go This pinentry library from gopass is an rdep of yubikey-agent (#969181). -- Taowa (they) people.debian.org/~taowa LOC FN35EL
Bug#990846: ITP: golang-github-go-piv-piv-go -- Keys and certificates for YubiKeys, written in Go
Package: wnpp Severity: wishlist Owner: Taowa X-Debbugs-CC: debian-devel@lists.debian.org, debian...@lists.debian.org * Package name: golang-github-go-piv-piv-go Version : 1.8.0-1 Upstream Author : Eric Chiang * URL : https://github.com/go-piv/piv-go * License : Apache-2.0 Programming Lang: Go Description : Keys and certificates for YubiKeys, written in Go A Go YubiKey PIV implementation . YubiKeys implement the PIV specification for managing smart card certificates. This applet is a simpler alternative to GPG for managing asymmetric keys on a YubiKey. This is an rdep for yubikey-agent (#969181). -- Taowa (they) people.debian.org/~taowa LOC FN35EL
Re: Need help with Multi-Arch in systemd
Hi Michael,
thanks for reaching out!
On Thu, Jul 08, 2021 at 11:03:48PM +0200, Michael Biebl wrote:
> a couple of days ago, the following bug report was filed against systemd
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990547
Imo, this is bug should be serious. In essence, it is a missing
dependency and we track missing dependencies as serious.
At the same time, I find it so unlikely to happen in practice combined
with the difficulty of finding a good solution that I'd propose
bullseye-ignore.
> Asking on #debian-systemd, Marco d'Itri suggested, that we move
> libsystemd-shared into a separate binary package. This would only help, if
> we moved libsystemd-shared into a Multi-Arch location (which means, we'd
> have to carry a patch against upstream). It would also mean, that on every
> new upstream release, systemd would have to go through NEW.
> So I'm not very keen on doing that.
I concur with Marco here and I argue that splitting the library is my
preferred solution. I confirm that you'd need to move the library for
this to work. For the other points I do not follow. I think it would be
ok to move the library using code inside debian/. Is there any reason
why you ruled out that option?
I also disagree with the need to go through NEW more than once. The new
package could quite simply be named libsystemd-private and lack a
.symbols and .shlibs file. Internal users would always use (=
${binary:Version}) anyway. The package description would declare that
any external dependency on libsystemd-private is a bug. Prior art:
libbinutils/binutils-dev.
One could argue that packaging a shared library like that is a policy
violation. If that is the case, then the current bundling is a policy
violation as well. So meh. It really sounds like a fair compromise to
me.
I am actually wondering now whether we should have a separate archive
section for "private" packages. I would define it as follows:
A private package is an implementation detail used by a single source.
Binary packages built from a one source package must not depend on
private packages built from another. Dependencies on private packages
should use tight version requirements (e.g. (= ${binary:Version}).
I suppose that a number of *-common and *-data packages as well as
gcc-N-base could be moved to such a section. User interfaces for package
managers could hide private packages by default.
Regardless of whether we add an archive section, lintian could carry a
list of private packages and enforce the no-dependency rule.
> Option 2 would be to drop Multi-Arch: foreign from systemd. This would mean,
> that packages like libpam-systemd/libnss-systemd can no longer be installed
> for a foreign architecture (even though those modules only use architecture
> independent interfaces of systemd).
That would break a pile of use cases and cause a lot of pain downstream.
Please don't.
> Option 3 is something I came up with after reading the Multi-Arch related
> wiki pages:
> https://salsa.debian.org/systemd-team/systemd/-/commit/c379461a14dcd13e0b625bd8faabbcf7fb3d19d6
> It would mean marking systemd as Multi-Arch: allowed. And packages that only
> use architecture interfaces of systemd would have to use the :any
> annotation.
Yeah, this technically works, but it causes a lot of maintenance effort,
because you get to hunt down every single systemd dependency in the
archive for years. I think our time is worth more than the cost of
introducing a new binary package into the archive.
> I would appreciate feedback, if option 3 is proper solution or not, or if
> there are other, better alternatives. If we go with option 3, should I
> inform all rdeps of systemd to update their dependency accordingly, i.e. do
> a MBF?
The problem I see here is less with annotating all deps once. It is more
the constant effort it incurs. It is not obvious that you should
annotate your systemd dependency :any. People will forget that when
adding systemd dependencies. What I take issue with is the permanent
cost that we keep in the long run.
Hope this helps
Helmut
Re: Need help with Multi-Arch in systemd
Am 09.07.21 um 10:28 schrieb Helmut Grohne: I concur with Marco here and I argue that splitting the library is my preferred solution. I confirm that you'd need to move the library for this to work. For the other points I do not follow. I think it would be ok to move the library using code inside debian/. Is there any reason why you ruled out that option? I also disagree with the need to go through NEW more than once. The new package could quite simply be named libsystemd-private and lack a .symbols and .shlibs file. Splitting out libsystemd-shared (once) will make PID1 very brittle. It can lead to situations where old systemd + new libsystemd-private is installed. If the installation is aborted at this point, you have an unbootable system. This is why I think it's not a viable approach. OpenPGP_signature Description: OpenPGP digital signature
Re: Need help with Multi-Arch in systemd
Am 09.07.21 um 10:28 schrieb Helmut Grohne: On Thu, Jul 08, 2021 at 11:03:48PM +0200, Michael Biebl wrote: Option 2 would be to drop Multi-Arch: foreign from systemd. This would mean, that packages like libpam-systemd/libnss-systemd can no longer be installed for a foreign architecture (even though those modules only use architecture independent interfaces of systemd). That would break a pile of use cases and cause a lot of pain downstream. Please don't. Can you iterate on that a bit? I was looking for use cases, but couldn't come up with them. Option 3 is something I came up with after reading the Multi-Arch related wiki pages: https://salsa.debian.org/systemd-team/systemd/-/commit/c379461a14dcd13e0b625bd8faabbcf7fb3d19d6 It would mean marking systemd as Multi-Arch: allowed. And packages that only use architecture interfaces of systemd would have to use the :any annotation. Yeah, this technically works, but it causes a lot of maintenance effort, because you get to hunt down every single systemd dependency in the archive for years. I think our time is worth more than the cost of introducing a new binary package into the archive. As said, option 1 is not something I really consider a viable option for the aforementioned reasons. I would appreciate feedback, if option 3 is proper solution or not, or if there are other, better alternatives. If we go with option 3, should I inform all rdeps of systemd to update their dependency accordingly, i.e. do a MBF? The problem I see here is less with annotating all deps once. It is more the constant effort it incurs. It is not obvious that you should annotate your systemd dependency :any. People will forget that when adding systemd dependencies. What I take issue with is the permanent cost that we keep in the long run. So, packages need to decide whether they use architecture independent interfaces of systemd or not and annotate it accordingly. But they only need to do that once. Isn't this the same as with any python, ruby or perl dependency? Maybe having something like the inverse of M-A: allowed would be useful? Instead of having packages explicitly opt-in via a :any annotation, they can opt out and request the same architecture even if a package is marked as M-A: foreign? So the select few cases which use an architecture dependent interface of M-A: foreign package would use something like pkg:arch ? OpenPGP_signature Description: OpenPGP digital signature
Re: Need help with Multi-Arch in systemd
* Michael Biebl [2021-07-09 11:01]: Splitting out libsystemd-shared (once) will make PID1 very brittle. It can lead to situations where old systemd + new libsystemd-private is installed. If the installation is aborted at this point, you have an unbootable system. Helmut suggested a tightly versioned dependency, so such a state would never be consistent. And given that system updates are not atomic transactions, I'm pretty confident you can interrupt *any* update of a boot-critical package at a point that leaves the system unbootable. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Need help with Multi-Arch in systemd
Am 09.07.2021 um 11:37 schrieb Timo Röhling: * Michael Biebl [2021-07-09 11:01]: Splitting out libsystemd-shared (once) will make PID1 very brittle. It can lead to situations where old systemd + new libsystemd-private is installed. If the installation is aborted at this point, you have an unbootable system. Helmut suggested a tightly versioned dependency, so such a state would never be consistent. That tightly versioned dependency doesn't help unfortunately. There is still a time window between the new libsystemd-shared and the new systemd being unpacked. Michael
Re: Need help with Multi-Arch in systemd
* Michael Biebl [2021-07-09 12:29]: That tightly versioned dependency doesn't help unfortunately. There is still a time window between the new libsystemd-shared and the new systemd being unpacked. There's also a time window between files in /usr/bin and files in /usr/lib being replaced. If you reboot your system with an unfinished/interrupted upgrade, you cannot assume a consistent or bootable state. Packaging all stuff in the same package *may* reduce the above time window somewhat, but it will not eliminate the underlying problem, so it is a non-solution. There may be other reasons to object Helmut's proposal, but this is not it. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Need help with Multi-Arch in systemd
Am 09.07.2021 um 13:01 schrieb Timo Röhling: * Michael Biebl [2021-07-09 12:29]: That tightly versioned dependency doesn't help unfortunately. There is still a time window between the new libsystemd-shared and the new systemd being unpacked. There's also a time window between files in /usr/bin and files in /usr/lib being replaced. If you reboot your system with an unfinished/interrupted upgrade, you cannot assume a consistent or bootable state. Packaging all stuff in the same package *may* reduce the above time window somewhat, but it will not eliminate the underlying problem, so it is a non-solution. There may be other reasons to object Helmut's proposal, but this is not it. I don't agree. The time window between dpkg unpacking a single package and ending up in a inconsistent state is neglibible to apt updating multiple packages during a dist-upgrade. Let me be blunt here: I'm not willing to compromise on robustness here.
Re: Need help with Multi-Arch in systemd
On Fri, 2021-07-09 at 12:29:19 +0200, Michael Biebl wrote: > Am 09.07.2021 um 11:37 schrieb Timo Röhling: > > * Michael Biebl [2021-07-09 11:01]: > > > Splitting out libsystemd-shared (once) will make PID1 very brittle. > > > It can lead to situations where old systemd + new libsystemd-private > > > is installed. If the installation is aborted at this point, you have > > > an unbootable system. > > Helmut suggested a tightly versioned dependency, so such a state > > would never be consistent. > That tightly versioned dependency doesn't help unfortunately. There is still > a time window between the new libsystemd-shared and the new systemd being > unpacked. If the private library has no backwards or forward compatibility (due to the SONAME used) the time window where the library does not match the expectations of the stuff linked to it might indeed be too big. But the reported bug is just a symptom of a bigger issue. This problem already exists for any of the other binary packages built against this private shared library, there's a time-window where they will not work if the installation gets interrupted or fails, compared with public shared libraries. This implies to me the correct solution is a name-versioned package, even though that seems cumbersome given our current archive handling practices this is IMO the only correct solution. The alternative of using Multi-Arch:allowed is a workaround for this packaging problem. Another solution might be to request upstream to stabilize this library? Yet another solution, which seems suboptimal, might be to statically link it, but the shared library seems rather big, but perhaps if the programs linked only use parts of it, that might not be too bad? Thanks, Guillem
Re: Need help with Multi-Arch in systemd
Hi Michael,
in your other mail, you gave a very good reason for keeping the systemd
binary and libsystemd-shared.so in the same binary package. That
improves my understanding of why you favour option 3.
On Fri, Jul 09, 2021 at 11:31:15AM +0200, Michael Biebl wrote:
> Am 09.07.21 um 10:28 schrieb Helmut Grohne:
> >
> > On Thu, Jul 08, 2021 at 11:03:48PM +0200, Michael Biebl wrote:
>
> > > Option 2 would be to drop Multi-Arch: foreign from systemd. This would
> > > mean,
> > > that packages like libpam-systemd/libnss-systemd can no longer be
> > > installed
> > > for a foreign architecture (even though those modules only use
> > > architecture
> > > independent interfaces of systemd).
> >
> > That would break a pile of use cases and cause a lot of pain downstream.
> > Please don't.
>
> Can you iterate on that a bit? I was looking for use cases, but couldn't
> come up with them.
I guess you already know what comes next: cross building. 4700 packages
include systemd in their Build-Depends. Many of them would immediately
become cross bd-uninstallable. For others, the installation set would be
satisfied with a foreign systemd, which would quite simply fail to work.
Any kind of mixed-arch system where you want to install a daemon that
depends on systemd for a foreign architecture would also be affected.
Someone attempting to do so might accidentally cross grade systemd in
doing so.
> As said, option 1 is not something I really consider a viable option for the
> aforementioned reasons.
>From my pov, the only reason left against 1 is partial upgrades breaking
the installation. It's a strong one anyhow.
> So, packages need to decide whether they use architecture independent
> interfaces of systemd or not and annotate it accordingly. But they only need
> to do that once. Isn't this the same as with any python, ruby or perl
> dependency?
Yes. For perl and python, we haven't even annotated half of the relevant
Depends with :any yet. Experience tells, the annotation is not gonna
happen.
> Maybe having something like the inverse of M-A: allowed would be useful?
> Instead of having packages explicitly opt-in via a :any annotation, they can
> opt out and request the same architecture even if a package is marked as
> M-A: foreign?
> So the select few cases which use an architecture dependent interface of
> M-A: foreign package would use something like pkg:arch ?
If I were to design Multi-Arch today, I would likely agree. The
transition cost to get there seems prohibitively high though. I've tried
hard to change the spec and I did not succeed (on the Multi-Arch
interpreter problem). Yet, we devised a workaround for that issue. So
you made me thinking, can we somehow implement this with our current
spec? The most important requirements seem to be:
* libsystemd-shared.so and /sbin/systemd need to reside in the same
binary package.
* It shall be possible to depend on libsystemd-shared.so for a
particular architecture.
* A dependency on "systemd" should request a native systemd.
Now let's do something stupid. Rename systemd to systemd-core (taking
all files with it, please refrain from discussing the name unless you
seriously consider doing this). Mark it Multi-Arch: allowed. Add a new,
empty binary package systemd. It is Multi-Arch: foreign and depends on
systemd-core:any. This approach would technically satisfy all three
requirements, but it feels a little crazy to me.
Another possibility (kudos to David Kalnischkies) would be exploiting
something I might call a loophole in the Multi-Arch spec. While we don't
currently use arch-qualified dependencies in the archive, the spec
considers them and dpkg and apt support them (somewhat). So in theory,
we could say that systemd-container Depends: systemd:${DEB_HOST_ARCH}.
I'm not sure whether all resolvers agree on this, but I'd expect this
dependency to pull the right instance (despite being marked Multi-Arch:
foreign). Before jumping onto this, please consider David's warning:
here be dragons.
I'm relaying another question from David: Assuming we'd solve the
libsystemd-shared.so issue, would systemd-container:arch1 actually work
with systemd:arch2 or are there more aspects where the same architecture
is assumed?
As we already are going crazy in the search for solutions to this, let
me propose a scary one. I have no idea whether this works in practice.
Split out libsystemd-shared.so into systemd-private like before, but at
the same time ship it in systemd. That causes a conflict of course, so
systemd-private Conflicts: systemd:${DEB_HOST_ARCH} and systemd
Conflicts: systemd-private:${DEB_HOST_ARCH} as well as Provides:
systemd-private:${DEB_HOST_ARCH}. These Conflicts must be arch-qualified
as otherwise they're interpreted as any instance. We already have
arch-qualified Conflicts in the archive, so this aspect likely works.
I'm less sure about arch-qualified Provides though. In any case, the
(common) native case would be systemd without systemd-private
Re: Need help with Multi-Arch in systemd
* Michael Biebl [2021-07-09 13:24]: Let me be blunt here: I'm not willing to compromise on robustness here. Well, I have had my say and ultimately, it's your package and your decision, of course. Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
DKMS packages and Debian 11, system.map
Hello everyone, A DKMS-built kernel module that I have on my system relies on system.map. A build script for the module parses that file in order to figure out addresses of certain functions. Now, without that file in Debian 11, there is simply no way for my DKMS-built module to find out the required function's address (unless I install that gargantuan debug package). Any ideas how I could get things to work the way they worked in Debian 10? Thanks!
Bug#990860: ITP: golang-github-smallstep-nosql -- abstraction layer for data persistency written in go
Package: wnpp Severity: wishlist Owner: Peymaneh Nejad * Package name: golang-github-smallstep-nosql Version : 0.3.6-1 Upstream Author : Smallstep * URL : https://github.com/smallstep/nosql * License : Apache-2.0 Programming Lang: Go Description : abstraction layer for data persistency written in go Currently this library provides following implementations: - BoltDB (https://github.com/etcd-io/bbolt) etcd fork. - Badger - MariaDB/MySQL
Re: packaging python3 material generated through swig: examples
Hi, thanks for the hint. I could step forward. On 07/07/2021 17:19, Andrey Rahmatullin wrote: On Wed, Jul 07, 2021 at 01:33:41PM +0200, Jerome BENOIT wrote: Hello, I am current packaging plfit (ITP #987559). The main part is written in C and a python module is provided. The python is created with swig. Can anyone direct me to good examples of packaging which deals with these kind of material source ? Do you mean the upstream build system doesn't do everything that needs to be done or what problems do you have with this package? Foe examples you can probably look at `reverse-depends -b swig`. The upstream does not indeed do everything and I needed a good sample involving swig. I used plplot as example. Cheers, Jerome
Re: Need help with Multi-Arch in systemd
Hi Guillem,
thanks for your feedback
Am 09.07.21 um 13:46 schrieb Guillem Jover:
If the private library has no backwards or forward compatibility (due
to the SONAME used) the time window where the library does not match
the expectations of the stuff linked to it might indeed be too big.
The libsystemd-shared library is considered an implementation detail and
indeed has no guaranteed backwards or forward compatibility.
The soname is bumped when the first rc1 release is made (e.g v249-rc1 →
libsystemd-shared-249.so) and there might even be incompatible changes
between the rc1 and the final release.
But the reported bug is just a symptom of a bigger issue. This problem
already exists for any of the other binary packages built against this
private shared library, there's a time-window where they will not work
if the installation gets interrupted or fails, compared with public
shared libraries.
This observation is correct I'd say. Currently we have the following
split-off binary packages which ship binaries that link against
libsystemd-shared:
systemd-container (4 binaries in $PATH, 7 services, 11 total)
systemd-coredump (1 binary in $PATH, 1 service, 2 total)
systemd-journal-remote (3 services, 3 total)
systemd-timesyncd (1 service, 1 total)
(I'll exclude systemd-tests, as this is a special case)
The main difference here, is that none of those binaries is really
critical for the runtime of the system.
An unbootable system though is one of the worst things that can happen.
Which is why I'm really reluctant to split off libsystemd-shared from
systemd and hopefully also explains why in general I'm not super keen on
chopping up src:systemd unnecessarily.
This implies to me the correct solution is a name-versioned package,
even though that seems cumbersome given our current archive handling
practices this is IMO the only correct solution.
A name-versioned package would certainly be better then an unversioned
libsystemd-shared package. It still would make PID 1 a bit more brittle
though (see e.g. my comment regard rc releases).
It would also need patching of the build system, to override the rpath,
which would have to be multi-arch aware.
$ find . -name meson.build | xargs grep rpath | wc -l
123
This would be a significant patch with a lot of ongoing churn and
maintenance effort. I'm not sure if I'm willing or even able to do that.
Another solution might be to request upstream to stabilize this library?
The point of libsystemd-shared is to be an internal implementation
detail where ABI can be broken. There are certainly no plans to change
that upstream and I don't think I can convince upstream otherwise on
this matter.
Yet another solution, which seems suboptimal, might be to statically
link it, but the shared library seems rather big, but perhaps if the
programs linked only use parts of it, that might not be too bad?
So, option 4).
I tried that for v249. It's doable, but as this there no upstream
support for that, it requires a patch which is significant and would
require ongoing maintenance effort as well.
Regarding the numbers:
systemd-container (11 binaries)
Installed-Size: [-1278-] {+5644+}
systemd-coredump (2 binaries)
Installed-Size: [-276-] {+1106+}
systemd-journal-remote (3 binaries)
Installed-Size: [-336-] {+1218+}
systemd-timesyncd (1 binary)
Installed-Size: [-209-] {+595+}
I think the increase in size is significant.
More importantly, I'd need help maintaining this patch going forward
I acknowledge, that option 2 and 3 makes Helmut's work on cross-building
harder, although I think that option 3 would be preferrable to 2, as it
as least leaves the door open for making cross-building possible.
So, unless we get a :arch annotation that can be used for M-A:foreign
packages, maybe the best option is
option 5)
do nothing?
I mean, we shipped the M-A: foreign notation for systemd since 2014.
If there is one bug report regarding such an architecture mismatch in 7
years, maybe the most pragmatic approach is to simply ignore it, given
the downsides of the alternatives? I'm not sure what the best course of
action is here.
Regards,
Michael
OpenPGP_signature
Description: OpenPGP digital signature
Re: Need help with Multi-Arch in systemd
Quoting Helmut Grohne (2021-07-09 14:24:01)
> Another possibility (kudos to David Kalnischkies) would be exploiting
> something I might call a loophole in the Multi-Arch spec. While we don't
> currently use arch-qualified dependencies in the archive, the spec considers
> them and dpkg and apt support them (somewhat). So in theory, we could say
> that systemd-container Depends: systemd:${DEB_HOST_ARCH}. I'm not sure
> whether all resolvers agree on this, but I'd expect this dependency to pull
> the right instance (despite being marked Multi-Arch: foreign). Before jumping
> onto this, please consider David's warning: here be dragons.
No, not all solvers agree on this. Imagine this situation:
Package: pkga
Architecture: amd64
Depends: pkgb:i386
Multi-Arch: no
Package: pkgb
Architecture: i386
Multi-Arch: foreign
dose3, apt and dpkg agree that pkga can be installed because its dependency is
satisfied by pkgb. But if we change pkgb:i386 to pkgb:amd64 to end up with
this:
Package: pkga
Architecture: amd64
Depends: pkgb:amd64
Multi-Arch: no
Package: pkgb
Architecture: i386
Multi-Arch: foreign
Then dose3 can satisfy the dependency of pkg while apt and dpkg cannot. This is
because when building the cudf representation of above two packages, dose3
considers pkg to provide pkgb for all architectures, including amd64, because
it is marked as m-a:foreign.
Thanks!
cheers, josch
signature.asc
Description: signature
Re: Need help with Multi-Arch in systemd
> "Helmut" == Helmut Grohne writes: Helmut> Looks like this leaves us between a rock and a hard Helmut> place. None of the options seems particularly attractive to Helmut> me at this point. We seem to be in a brainstorming space here, throwing out half baked ideas because none of us has a great answer. So, I'm going to join the party. Are there games we could play with prerm scripts in a systemd-private package to make sure that the old systemd private library sticks around until the upgrade finishes when upgrading systemd-private? --Sam
