Bug#1091148: apt-setup: FTBFS on arm64: /usr/sbin/chroot: failed to run command ‘./cd-exec’: No such file or directory

[Lucas Nussbaum]

Source: apt-setup
Version: 1:0.190
Severity: serious
Justification: FTBFS
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20241222 ftbfs-trixie

Hi,

During a rebuild of all packages in sid, your package failed to build
on arm64.


Relevant part (hopefully):
> make[1]: Entering directory '/<>'
> FAKECHROOT_EXCLUDE_PATH=/tmp:/dev:/bin:/usr/bin:/usr/share/shunit2: 
> fakechroot chroot test/chroot ./cd-exec  /test/20-local-repo-upgrade.sh
> /usr/sbin/chroot: failed to run command ‘./cd-exec’: No such file or directory
> make[1]: *** [Makefile:16: test] Error 127
> make[1]: Leaving directory '/<>'
> dh_auto_test: error: make -j8 test returned exit code 2


The full build log is available from:
http://qa-logs.debian.net/2024/12/22/apt-setup_0.190_unstable-arm64.log

All bugs filed during this archive rebuild are listed at:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20241222;users=lu...@debian.org
or:
https://udd.debian.org/bugs/?release=na&merged=ign&fnewerval=7&flastmodval=7&fusertag=only&fusertagtag=ftbfs-20241222&fusertaguser=lu...@debian.org&allbugs=1&cseverity=1&ctags=1&caffected=1#results

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please mark it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.

Bug#1091099: override: linux-sysctl-defaults:kernel/important

[Noah Meyerhans]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: override
X-Debbugs-Cc: debian-boot@lists.debian.org

linux-sysctl-defaults should be installed by default on typical Debian systems.
See #1090811 for background.

Thanks
noah

Processed: Re: Bug#1091085: d-i.debian.org: libfakeroot internal error: payload not recognized!

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 src:debian-installer
Bug #1091085 [d-i.debian.org] d-i.debian.org: libfakeroot internal error: 
payload not recognized!
Bug reassigned from package 'd-i.debian.org' to 'src:debian-installer'.
Ignoring request to alter found versions of bug #1091085 to the same values 
previously set
Ignoring request to alter fixed versions of bug #1091085 to the same values 
previously set

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

Bug#1091085: d-i.debian.org: libfakeroot internal error: payload not recognized!

[m.alfa...@gmail.com]

Package: d-i.debian.org
Severity: normal
Tags: d-i
X-Debbugs-Cc: m.alfa...@gmail.com

Dear Maintainer,

After some update im recieving error message : " libfakeroot internal error: 
payload not recognized!". It appers in a stream of messages when
building debian-installer with following commands : make reallyclean, fakeroot 
make and fakeroot make build_netboot or without the fakeroot.
The weird thing is that the build procces is succesfull.

Thank You

Bug#1091085: d-i.debian.org: libfakeroot internal error: payload not recognized!

[Cyril Brulebois]

Control: reassign -1 src:debian-installer

m.alfa...@gmail.com  (2024-12-22):
> After some update im recieving error message : " libfakeroot internal error: 
> payload not recognized!". It appers in a stream of messages when
> building debian-installer with following commands : make reallyclean, 
> fakeroot make and fakeroot make build_netboot or without the fakeroot.
> The weird thing is that the build procces is succesfull.

Yes, that's been happening for a while but it's low on my “should be
debugging” list.

We use eatmydata to speed some things up, and presumably unrecognized
payloads just go through unmodified, hence the overall success despite
the noisy build logs.


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


signature.asc
Description: PGP signature

Bug#1087489: [RFD] partman: Add support of the 'legacy_boot' flag to manual partitioning

[Pascal Hambourg]

On 21/11/2024 at 05:08, Holger Wansing wrote:


Please go ahead.


Now going into technical implementation details.

Script partman-partitioning/active_partition/toggle_bootable/choices 
enables the "Bootable flag" toggle in partition settings.


Script partman-partitioning/active_partition/toggle_bootable/do_option 
sets or clears the 'boot' flag.


Script partman-base/update.d/bootable syncs the "bootable" file in the 
partition directory with the 'boot' flag state.


Script partman-base/visual.d/bootable prints "B" in the partition view 
if the "bootable" file is present in the partition directory.


The same "bootable" file could be sync'ed with the 'legacy_boot' flag on 
GPT but other packages (I found partman-efi and partman-newworld) also 
interact with the 'boot' flag and the "bootable" file. partman-newworld 
was removed from the Debian archive years ago and was built only for 
powermac architectures (which do not use GPT) so it should not be an 
issue. However sync'ing the "bootable" file with the 'legacy_boot' flag 
interferes with partman-efi logic (in update.d/efi_sync_flag) and 
conversely [1].


So for now I chose to sync a separate file with the 'legacy_boot' flag. 
I also chose to do minimal changes to existing code rather than 
optimizing it, resulting in the following two merge requests for 
partman-base and partman-partitioning:





[1] IMO partman-efi logic is flawed and should be fixed because it 
interferes with the 'boot' flag logic in partman-base in unexpected ways.