On Thu, Jul 15, 2021 at 08:08:13AM +0200, Helmut Grohne wrote:
> I also proposed a solution here, which is avoiding
> SystemCallArchitectures=native. Initially, that sounds like a
> maintenance nightmare until you notice that it can be solved on a
> technical level. We already have
On 16200 March 1977, Michael Lustfield wrote:
I do recall that the FTP masters would've been generally open to have
such an auto-approver (but maybe I'm wrong), but that no-one stepped
up
yet to code it up?
A few of us came up with some proof of concept designs/models, but we
ultimately
On Wed, 14 Jul 2021 18:48:24 +0200
Philipp Kern wrote:
> On 14.07.21 13:47, Michael Biebl wrote:
> > Am 14.07.21 um 12:59 schrieb Simon McVittie:
> I do recall that the FTP masters would've been generally open to have
> such an auto-approver (but maybe I'm wrong), but that no-one stepped up
On 16194 March 1977, Simon McVittie wrote:
Would it be feasible for dak to have a list of binary package name
regexes mapped to a source package and a section/priority, and
auto-accept
packages from the given source package that match the regex, assigning
the given section/priority, without
Hi Michael,
On Thu, Jul 15, 2021 at 12:22:59AM +0200, Michael Biebl wrote:
> You are right. Thinking more about this, splitting out libsystemd-shared as
> a Multi-Arch: same library will not help with
> SystemCallArchitectures=native, which is used by the services in
>
Am 09.07.21 um 14:24 schrieb Helmut Grohne:
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
On Wed, 2021-07-14 at 11:59:11 +0100, Simon McVittie wrote:
> On Thu, 08 Jul 2021 at 23:03:48 +0200, Michael Biebl wrote:
> > [a separate libsystemd-shared-249 .deb] would also mean, that on every
> > new upstream release, systemd would have to go through NEW
>
> It seems like we're rejecting a
On 14.07.21 13:47, Michael Biebl wrote:
Am 14.07.21 um 12:59 schrieb Simon McVittie:
Would it be feasible for dak to have a list of binary package name
regexes mapped to a source package and a section/priority, and
auto-accept
packages from the given source package that match the regex,
On Wed, Jul 14, 2021 at 11:59:11AM +0100, Simon McVittie wrote:
> It seems like this would also be good for src:linux, where ABI breaks
> are often tied to security fixes that should enter the archive ASAP.
As security updates are hand approved, accepting by NEW does not help
that much.
Bastian
On Thu, Jul 08, 2021 at 11:03:48PM +0200, Michael Biebl wrote:
> 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
* Simon McVittie [2021-07-14 11:59]:
Would it be feasible for dak to have a list of binary package name
regexes mapped to a source package and a section/priority, and auto-accept
packages from the given source package that match the regex, assigning
the given section/priority, without manual
Am 14.07.21 um 13:47 schrieb Michael Biebl:
Am 14.07.21 um 12:59 schrieb Simon McVittie:
Would it be feasible for dak to have a list of binary package name
regexes mapped to a source package and a section/priority, and
auto-accept
packages from the given source package that match the regex,
Am 14.07.21 um 12:59 schrieb Simon McVittie:
Would it be feasible for dak to have a list of binary package name
regexes mapped to a source package and a section/priority, and auto-accept
packages from the given source package that match the regex, assigning
the given section/priority, without
On Thu, 08 Jul 2021 at 23:03:48 +0200, Michael Biebl wrote:
> [a separate libsystemd-shared-249 .deb] would also mean, that on every
> new upstream release, systemd would have to go through NEW
It seems like we're rejecting a good technical solution because
social/organisational factors block it
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
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
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'
On Fri, Jul 09, 2021 at 10:28:57AM +0200, Helmut Grohne wrote:
>...
> 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})
> "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
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
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
* 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
* 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
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
* 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
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
Hi,
a couple of days ago, the following bug report was filed against systemd
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990547
I'm quoting the relevant parts
I noticed that systemd-machined was failing to start on an arm64
box. This box had armhf enabled, and turns out systemd had been
32 matches
Mail list logo
