> "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
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 suppo
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 l
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
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 : abstr
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 requ
* 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
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
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
> >
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/bi
* 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 yo
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
unb
* 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 ve
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
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
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 missin
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
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 c
18 matches
Mail list logo
