Bug#991038: ITP: golang-step-crypto -- collection of packages used by Smallstep products
Package: wnpp Severity: wishlist Owner: Peymaneh Nejad * Package name: golang-step-crypto Version : 0.9.0-1 Upstream Author : Smallstep * URL : https://github.com/smallstep/crypto * License : Apache-2.0 Programming Lang: Go Description : collection of packages used by Smallstep products this package is needed for step-ca (#990946)
Bug#991039: ITP: golang-step-cli-utils -- Common code between step-cli and step-ca
Package: wnpp Severity: wishlist Owner: Peymaneh Nejad * Package name: golang-step-cli-utils Version : 0.4.1-1 Upstream Author : Smallstep * URL : https://github.com/smallstep/cli-utils * License : Apache-2.0 Programming Lang: Go Description : Common code between step and step-ca This package is needed for step-ca (#990946)
Bug#991047: ITP: golang-step-linkedca -- go library supporting Linked CAs using protocol buffers and gRPC
Package: wnpp Severity: wishlist Owner: Peymaneh Nejad * Package name: golang-step-linkedca Version : 0.0~git20210611.27424aa-1 Upstream Author : Smallstep * URL : https://github.com/smallstep/linkedca * License : Apache-2.0 Programming Lang: Go Description : library supporting Linked CAs using protocol buffers and gRPC This package is needed for step-ca (#990946)
Re: Need help with Multi-Arch in systemd
Hi Michael, I'm not yet fully convinced that we're out of options, but let's for a moment assume we were. On Fri, Jul 09, 2021 at 10:26:43PM +0200, Michael Biebl wrote: > So, unless we get a :arch annotation that can be used for M-A:foreign > packages, maybe the best option is Given Johannes' reply, I think that :arch annotations can be a strict improvement to the status quo. dose will ignore them, so you aren't worse off with it. apt and dpkg agree to honour them, so they'd practically solve the symptoms (despite leading dose into non-solutions to certain satisfiability issues that are mostly relevant to cross building only). The one question here is whether those are the semantics that we want for this corner case of multiarch. A while ago, David changed apt to make it stop behaving like dose and instead make it behave like dpkg. That looks like we had consensus back then. Did we document it anywhere? > 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. If :arch qualifiers are an option, I think they are a strict improvement over doing nothing. That's something I couldn't convincingly say about any other option. In any case, I don't think fixing this in time for bullseye is reasonable, so we do have some time figuring out whether :arch is a solution. Helmut
Re: Need help with Multi-Arch in systemd
Hi Michael, Michael Biebl ezt írta (időpont: 2021. júl. 9., P, 22:42): > > 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. IMO what Guillem recommends, i.e. the name-versioned libsystemd package with versioned shared library name is still the cleanest and so far the only reasonably reliable solution. IMO going through NEW in every few months could be an acceptable cost especially since I was quite happy with the pace at which NEW is processed recently. I don't maintain systemd in Ubuntu anymore, but if I were, I'd be happy to accept this increased maintenance burden for the sake of having a clean solution for the Multi-Arch problem. If release candidates will be uploaded only to experimental then the incompatible changes won't cause problems. Even if RC-s are uploaded to unstable and a rarely occurring incompatible change takes place then the library package name can be bumped again. After we discussed this topic on #debian devel on 2020-05-05 I even started implementing the solution but did not finish it because it was not an important problem from Ubuntu's POV. I think the rpath usage search counted a lot of hits which don't have to be changed and maybe upstream would be willing to accept the patch. Cheers, Balint
Re: Need help with Multi-Arch in systemd
Helmut Grohne wrote: > 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. This seems like a rather reasonable approach, actually. It's a little unusual, but it has all the advantages of making systemd multi-arch aware while not creating the trap of making a `systemd` dependency do the wrong thing, because `systemd` has the right multi-arch dependency on `systemd-core:any`. The handful of packages that really do need a same-arch dependency on systemd (those that are part of systemd itself and need libsystemd-shared) could depend on `systemd-core` directly, and everything else can continue depending on systemd with no transition required. And there's only one trip through NEW, once.
Debian 11
Hi I installed Debian 11 on my new hard disk yesterday in preparation for the release, everything went very smoothly, I did manage to skip selecting a mirror (error on my part) but adding that manually worked fine after asking for help on IRC. Also good learning point on adding items manually, so not a bad thing. Looks really nice, so really well done to the developer and other teams on the upcoming release. I have now set up a separate home partition too Keep up the good work Paul -- Paul Sutton, Cert Cont Sci (Open) https://personaljournal.ca/paulsutton/ Pronoun : him/his/he OpenPGP : 4350 91C4 C8FB 681B 23A6 7944 8EA9 1B51 E27E 3D99 21st Debian Conference August 22 to August 29, 2021. DebCamp from August 15 to August 21, 2021 https://debconf21.debconf.org/ OpenPGP_signature Description: OpenPGP digital signature
