Re: Splitting udev-udeb out of src:systemd

[Cyril Brulebois]

Hi,

Luca Boccassi  (2025-01-15):
> I plan to split out udev-udeb and libudev1-udeb from the current
> src:systemd source package/repo into a new src:systemd-udeb (forked
> from the old one, so generated udebs will be the same).

The current set of packages doesn't work as the shlibs now only
references the libudev1 deb (without the extra udeb line), and
mdadm-udeb just picked up a dependency on libudev1.

(I'll file the mdadm bug report later on, I'm on my way out.)


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1037256: debian-installer: GUI font for Japanese was incorrectly rendered

[Kentaro HAYASHI]

On Mon, 20 Jan 2025 20:13:24 +0100 Cyril Brulebois 
wrote:
...
> > if I had a knowledge about d-i internals. :-<
> 
> I think (I wanted but I'm not sure I did…) I said I would look into
> this after Trixie Alpha 1, so if you don't mind waiting a little,
> I'll look into it eventually…

Thanks!

I'm happy to hear that you still have interest about this issue.
I guess that this issue will not be so attractive for non-Japanese
speaker, just wanted to know how to make it forward. (I'm just curious)

So, I'll wait you look into it.

Regards,

Re: Splitting udev-udeb out of src:systemd

[Luca Boccassi]

On Thu, 23 Jan 2025 at 11:13, Cyril Brulebois  wrote:
>
> Hi,
>
> Luca Boccassi  (2025-01-15):
> > I plan to split out udev-udeb and libudev1-udeb from the current
> > src:systemd source package/repo into a new src:systemd-udeb (forked
> > from the old one, so generated udebs will be the same).
>
> The current set of packages doesn't work as the shlibs now only
> references the libudev1 deb (without the extra udeb line), and
> mdadm-udeb just picked up a dependency on libudev1.
>
> (I'll file the mdadm bug report later on, I'm on my way out.)

Thanks for the report, this looks like to be the problem, in DEBIAN/shlibs:

libudev 1 libudev1 (>= 257.2)
udeb: libudev 1 libudev1-udeb (>= 257.2)

became

libudev 1 libudev1 (>= 257.2)

I'll do a few experiments and upload a fix as soon as I have it

Bug#1093565: partman: changing partition usage may leave the wrong type in partition table

[Pascal Hambourg]

On 20/01/2025 at 00:01, Pascal Hambourg wrote:


Possible mitigations/solutions:

(...)
3) Modify parted_server to set only the last type flag when processing a 
SET_FLAGS command (all scripts send the new flag last).

Advantage: no need to change affected packages.
Downsides: changes SET_FLAGS behaviour; needs to be updated whenever 
libparted supports a new flag.


4) Modify parted_server to add a new SET_FLAG command which sets a 
single flag and use it in synchronization scripts.

Downside: requires a change in all affected packages.

I think solution #3 is the best because it requires changes only in 
partman-base to fully fix the issue.


At least in the short term (for trixie ?). But I think solution #4 would 
be better, simpler and more reliable in the long term without the need 
to classify flags. I implemented the SET_FLAG command in parted_server 
and tested it successfully with the "boot" flag.

Bug#1093852: network sources are added without non-free-firmware when using d-i on a live image

[Steve McIntyre]

Package: apt-setup
Severity: important
Tags: d-i

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: live image
Image version: debian-live-12.9.0-amd64-xfce.iso

Found when installing via d-i from a variety of live images:

 * The live image apt sources are added including non-free-firmware
 * Network apt sources are added without non-free-firmware

Initially tested in a VM (where the firmware-summary listed no needed
firmware packages, as expected).

I've just run a d-i install from tge Gnome live image onto a laptop
that needs firmware-iwlwifi. That was installed fine using the package
from the source on the live image, but still no mention of
non-free-firmware in the network sources - "main" is the only
component listed for those. :-(

Re: Splitting udev-udeb out of src:systemd

[Luca Boccassi]

On Thu, 23 Jan 2025 at 11:56, Luca Boccassi  wrote:
>
> On Thu, 23 Jan 2025 at 11:13, Cyril Brulebois  wrote:
> >
> > Hi,
> >
> > Luca Boccassi  (2025-01-15):
> > > I plan to split out udev-udeb and libudev1-udeb from the current
> > > src:systemd source package/repo into a new src:systemd-udeb (forked
> > > from the old one, so generated udebs will be the same).
> >
> > The current set of packages doesn't work as the shlibs now only
> > references the libudev1 deb (without the extra udeb line), and
> > mdadm-udeb just picked up a dependency on libudev1.
> >
> > (I'll file the mdadm bug report later on, I'm on my way out.)
>
> Thanks for the report, this looks like to be the problem, in DEBIAN/shlibs:
>
> libudev 1 libudev1 (>= 257.2)
> udeb: libudev 1 libudev1-udeb (>= 257.2)
>
> became
>
> libudev 1 libudev1 (>= 257.2)
>
> I'll do a few experiments and upload a fix as soon as I have it

Ok I have a fix that results in:

Package: mdadm-udeb
Source: mdadm
Version: 4.4-2
Architecture: amd64
Maintainer: Daniel Baumann 
Installed-Size: 1040
Depends: libc6-udeb (>= 2.40), libudev1-udeb (>= 247)

Which looks correct to me, so I'll upload that. mdadm will require a
rebuild afterwards. Thanks for finding this!

Bug#1093859: release.debian.org: mips64el vs. librsvg needs resolving for trixie

[Simon McVittie]

Package: release.debian.org
Severity: normal
Tags: trixie
X-Debbugs-Cc: debian-m...@lists.debian.org, debian-gtk-gn...@lists.debian.org, 
debian-boot@lists.debian.org

The current version of librsvg is not migrating to testing because it
FTBFS on mips64el. This appears to be caused by a kernel or hardware
issue where otherwise-working code fails with EFAULT in a read() call
on bookworm kernels (see #1093200): this is not librsvg-specific, and
affects other Rust components, as well as git, Erlang and Go.

Presumably something in the Rust and Go ecosystem is making use of a
function-calling pattern that is more likely to trigger this than typical
C/C++ code, but I don't know the full details. buster kernels (as used on
the mips64el porterbox and some older buildds) do not seem to be affected.

Indications from the bug are that bullseye kernels (5.10) might also be
unaffected, at least for git (I don't think the rust packages have
necessarily been tried there).

It is unknown whether trixie/bookworm-backports kernels are affected.

This seems to have been happening for about 6 months (since 2024-08-15),
although until recently it was possible to mitigate it by retrying builds
until they got scheduled on a buildd that happened to be using a buster
kernel.

Is the mips porting team actively looking into this, for example attempting
to reproduce it on similar hardware with bookworm-backports kernels?

Or, is the release team perhaps already considering demoting mips64el to
non-release status?

If there is no prospect of a fix, and if mips64el is still a release
architecture, then we will need to remove librsvg from mips64el so that it
isn't holding all other architectures back. A quick experiment with
`dak rm -R -n` says this would involve architecture-specific removals
of around 250 packages (plus whatever depends on those packages,
recursively). It might also require sourceful changes in some of the
affected packages, to add a Build-Depends on a package from librsvg
(where there is not one already), to ensure they don't get rebuilt on
mips64el until librsvg is buildable again.

In particular removing librsvg would mean we lose a build-dependency of
debian-installer from mips64el (-boot cc'd) which would make mips64el into
another upgradable-but-not-installable architecture with no installer,
like armel and i386.

Other Rust/Erlang/Go packages are likely to be in a similar situation,
but most of them are higher up the dependency stack (less key) than
librsvg, so removing them might be less painful.

smcv

Bug#1093907: Installation Report: Weekly Build 20250120-03:23: /etc/network/interfaces Set Up Incorrectly.

[Pascal Hambourg]

On 24/01/2025 à 00:14, Charles Curley wrote:


The installation was preseeded using a configuration that has worked
well on this and other machines. Normally the network setup runs
correctly. However this time the Ethernet was changed from eth0 to
enp1s0, as usual, but the entry in /etc/network/interfaces was for
eth0.


The installer syslog does not mention enp1s0, so udev did not rename 
eth0. It may be caused by missing /usr/lib/systemd/network/*.link files 
in the new udev-udeb package.

Bug#1093715: [INTL:es] Spanish translation of the debconf template blendsel

[Holger Wansing]

Control: tags -1 + pending


jathan  wrote (Tue, 21 Jan 2025 12:38:04 -0600):
> Package: blendsel
> Severity: wishlist
> 
> Hello,
> 
> Please find attached the Spanish debconf translation of blendsel.

Just pushed to git.

Thanks


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Processed: Re: Bug#1093715: [INTL:es] Spanish translation of the debconf template blendsel

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + pending
Bug #1093715 [blendsel] [INTL:es] Spanish translation of the debconf template 
blendsel
Added tag(s) pending.

-- 
1093715: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1093715
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems