New `debian-cd` mirror application

2024-03-21 Thread Tran Trong Nghia FX05823 
Hi, I'd like to apply for a new Debian CD mirror, based in Vietnam
Here's the link to the mirror: http://mirror.kirbee.tech/debiancd/
Server bandwidth: 200Mbit/s

Thanks and regards.

lvm2 udebs vs. libaio1-udeb (was: Progress on t64 transition -> building the installer in sid)

2024-03-21 Thread Cyril Brulebois 
Hi,

Cyril Brulebois  (2024-03-21):
> I'm a bit conflicted about what to do here. At the moment, libaio1-udeb
> is the only udeb with t64 (at least according to the output of
> `apt-file search -Iudeb t64`); but a rebuild of the reverse dependencies
> would be sufficient (and might happen at some point anyway).
> 
> For the sake of consistency, I think I'm tempted to suggest a revert of
> the udeb part (it wasn't renamed so there's a contents vs. package name
> mismatch anyway).

Checking libaio's changelog (last mail got sent a little too fast,
sorry) is enlightening: this library required special attention and
wasn't just about getting rebuilt with a different package name.

  
https://tracker.debian.org/news/1509816/accepted-libaio-03113-6-source-into-unstable/

Guillem is absolutely right regarding avoiding the roundtrip to NEW and
d-i's not caring, but some kind of heads-up to debian-boot@ (now cc'd)
would have been welcome.

It'd be nice if the Debian LVM Team (hello waldi) could pick it up from
here and see whether requesting a binNMU is what makes most sense here,
or if there other plans on the t64 front. A local, cowbuilder-powered
rebuild of unstable's lvm2 results in udebs referencing libaio.so.1t64
as expected (i.e. libaio1t64's shlibs).


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


signature.asc
Description: PGP signature

Re: Progress on t64 transition -> building the installer in sid

2024-03-21 Thread Cyril Brulebois 
Hi,

Roland Clobus  (2024-03-21):
> On 21/03/2024 15:58, Cyril Brulebois wrote:

[…]

> The diagram shows nicely that the t64-transition is affecting the
> installer, with currently 1 major bottleneck, libpng16-16t64-udeb:
> https://d-i.debian.org/dose/graph-unstable-amd64.png

Glad you like it, those have been quite useful a very long while back;
it's been a while since the last time we had such a huge archive-wide
transition…

> > Do you have more details? That thing doesn't exist, but libaio.so.1
> > does (different suffix order).
> 
> My bad, I reversed the order when typing.

No worries, thanks for confirming.

> I've done some basic triaging in the openQA comment:
> https://openqa.debian.net/tests/244163#comments
> 
> The installer fails here:
> https://openqa.debian.net/tests/244163#step/grub/3
> 
> Some details are here (/var/log/syslog):
> https://openqa.debian.net/tests/244163#step/grub/35

Thanks, that's pvs from lvm2-udeb; for some reason libaio1-udeb got
t64-transitioned, and without an lvm2 rebuild, its tools will want the
non-t64 version.

I'm a bit conflicted about what to do here. At the moment, libaio1-udeb
is the only udeb with t64 (at least according to the output of
`apt-file search -Iudeb t64`); but a rebuild of the reverse dependencies
would be sufficient (and might happen at some point anyway).

For the sake of consistency, I think I'm tempted to suggest a revert of
the udeb part (it wasn't renamed so there's a contents vs. package name
mismatch anyway).

> > In any case, there are no reasons to complicate the t64 transition with
> > transitioning udebs, so I wouldn't be surprised if “images” (whatever
> > they are) built against old udebs would break if newer udebs are pulled
> > from the network.
> 
> The images I've spoken of are the daily-built Debian live ISO-images based
> on sid. They are built by Jenkins https://jenkins.debian.net/view/live/

OK, but what I meant to say is that the failure mode I was alluding to
isn't specific to d-i daily builds, or debian-cd builds, or live builds;
that's something that can happen, and might do until things stabilize.


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


signature.asc
Description: PGP signature

Re: Progress on t64 transition -> building the installer in sid

2024-03-21 Thread Roland Clobus 

Hello Cyril, list,

On 21/03/2024 15:58, Cyril Brulebois wrote:

https://lists.debian.org/debian-boot/2024/03/msg00102.html


The diagram shows nicely that the t64-transition is affecting the 
installer, with currently 1 major bottleneck, libpng16-16t64-udeb:

https://d-i.debian.org/dose/graph-unstable-amd64.png


On openQA I've additionally seen that for Debian Edu, the installer fails
with the message that libaio.1.so is missing, so some udeb is probably also
requiring an update.


Do you have more details? That thing doesn't exist, but libaio.so.1
does (different suffix order).


My bad, I reversed the order when typing.

I've done some basic triaging in the openQA comment:
https://openqa.debian.net/tests/244163#comments

The installer fails here:
https://openqa.debian.net/tests/244163#step/grub/3

Some details are here (/var/log/syslog):
https://openqa.debian.net/tests/244163#step/grub/35


In any case, there are no reasons to complicate the t64 transition with
transitioning udebs, so I wouldn't be surprised if “images” (whatever
they are) built against old udebs would break if newer udebs are pulled
from the network.


The images I've spoken of are the daily-built Debian live ISO-images 
based on sid. They are built by Jenkins 
https://jenkins.debian.net/view/live/
Seeing the breakage on sid before the weekly-build installer breaks on 
trixie would be nice :-)


With kind regards,
Roland


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1067442: marked as done (contains files for different architecture)

2024-03-21 Thread Debian Bug Tracking System 
Your message dated Thu, 21 Mar 2024 17:25:35 +0100
with message-id <20240321162535.eo3ebgnohaq5o...@mraw.org>
and subject line Re: Bug#1067442: contains files for different architecture
has caused the Debian Bug report #1067442,
regarding contains files for different architecture
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
1067442: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067442
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: syslinux-efi
Version: 3:6.04~git20190206.bf6db5b4+dfsg1-3
Severity: grave
X-Debbugs-Cc: dbarysh...@gmail.com

The ARM64 syslinux-efi package binaries for x86 instead instead of ARM
binaries:

$ uname -m
aarch64

$ file /usr/lib/SYSLINUX.EFI/efi*/syslinux.efi
/usr/lib/SYSLINUX.EFI/efi32/syslinux.efi: PE32 executable (EFI application) 
Intel 80386 (stripped to external PDB), for MS Windows
/usr/lib/SYSLINUX.EFI/efi64/syslinux.efi: PE32+ executable (EFI application) 
x86-64 (stripped to external PDB), for MS Windows

As such these binaries are unusable on ARM64 hosts.

-- System Information:
Debian Release: 12.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 6.6.9-qcomlt-arm64-00188-g31f49428dc7d (SMP w/4 CPU threads; 
PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

syslinux-efi depends on no packages.

Versions of packages syslinux-efi recommends:
ii  syslinux-common  3:6.04~git20190206.bf6db5b4+dfsg1-3

Versions of packages syslinux-efi suggests:
ii  dosfstools  4.2-1

-- no debconf information
--- End Message ---
--- Begin Message ---
Hi,

Dmitry Baryshkov  (2024-03-21):
> Package: syslinux-efi
> Version: 3:6.04~git20190206.bf6db5b4+dfsg1-3
> Severity: grave
> X-Debbugs-Cc: dbarysh...@gmail.com
> 
> The ARM64 syslinux-efi package binaries for x86 instead instead of ARM
> binaries:
> 
> $ uname -m
> aarch64
> 
> $ file /usr/lib/SYSLINUX.EFI/efi*/syslinux.efi
> /usr/lib/SYSLINUX.EFI/efi32/syslinux.efi: PE32 executable (EFI application) 
> Intel 80386 (stripped to external PDB), for MS Windows
> /usr/lib/SYSLINUX.EFI/efi64/syslinux.efi: PE32+ executable (EFI application) 
> x86-64 (stripped to external PDB), for MS Windows
> 
> As such these binaries are unusable on ARM64 hosts.

There's a single `Architecture: all` package, there are no
architecture-specific builds for this package…

https://repo.or.cz/syslinux.git/tree/HEAD:/efi knows about efi32 and
efi64, not about ARM.

And I can't find any information about ARM anywhere anyway…

 extlinux arch=amd64,i386,x32
 isolinux arch=all
 pxelinux arch=all
 syslinux arch=amd64,i386,x32
 syslinux-common arch=all
 syslinux-efi arch=all
 syslinux-utils arch=amd64,i386,x32

Sounds like not a bug, instead of a grave bug…


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


signature.asc
Description: PGP signature
--- End Message ---

Bug#1067442: contains files for different architecture

2024-03-21 Thread Dmitry Baryshkov 
Package: syslinux-efi
Version: 3:6.04~git20190206.bf6db5b4+dfsg1-3
Severity: grave
X-Debbugs-Cc: dbarysh...@gmail.com

The ARM64 syslinux-efi package binaries for x86 instead instead of ARM
binaries:

$ uname -m
aarch64

$ file /usr/lib/SYSLINUX.EFI/efi*/syslinux.efi
/usr/lib/SYSLINUX.EFI/efi32/syslinux.efi: PE32 executable (EFI application) 
Intel 80386 (stripped to external PDB), for MS Windows
/usr/lib/SYSLINUX.EFI/efi64/syslinux.efi: PE32+ executable (EFI application) 
x86-64 (stripped to external PDB), for MS Windows

As such these binaries are unusable on ARM64 hosts.

-- System Information:
Debian Release: 12.5
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 6.6.9-qcomlt-arm64-00188-g31f49428dc7d (SMP w/4 CPU threads; 
PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

syslinux-efi depends on no packages.

Versions of packages syslinux-efi recommends:
ii  syslinux-common  3:6.04~git20190206.bf6db5b4+dfsg1-3

Versions of packages syslinux-efi suggests:
ii  dosfstools  4.2-1

-- no debconf information

Re: Progress on t64 transition -> building the installer in sid

2024-03-21 Thread Cyril Brulebois 
Roland Clobus  (2024-03-19):
> For the other images, the installer is currently failing to build from
> source, as some dependencies (in the udebs) are still missing (due to
> the t64-transition).
> 
> The latest message (from my local build_cdrom_gtk.log) is:
> 
> The following packages have unmet dependencies:
>  libcairo2-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not
> installable
>  libfreetype6-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it is not
> installable
>  libgdk-pixbuf-2.0-0-udeb : Depends: libpng16-16t64-udeb (>= 1.6.2) but it
> is not installable
>  libinput10-udeb : Depends: libmtdev1t64 but it is not installable

https://lists.debian.org/debian-boot/2024/03/msg00102.html

> On openQA I've additionally seen that for Debian Edu, the installer fails
> with the message that libaio.1.so is missing, so some udeb is probably also
> requiring an update.

Do you have more details? That thing doesn't exist, but libaio.so.1
does (different suffix order).

In any case, there are no reasons to complicate the t64 transition with
transitioning udebs, so I wouldn't be surprised if “images” (whatever
they are) built against old udebs would break if newer udebs are pulled
from the network.


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


signature.asc
Description: PGP signature