Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #93122 > unrolled thread

Uploading linux (7.0.14-1)

Started bySalvatore Bonaccorso <carnil@debian.org>
First post2026-06-27 16:30 +0200
Last post2026-07-03 17:50 +0200
Articles 10 — 5 participants

Back to article view | Back to linux.debian.kernel

Contents

  Uploading linux (7.0.14-1) Salvatore Bonaccorso <carnil@debian.org> - 2026-06-27 16:30 +0200
    Re: Uploading linux (7.0.14-1) Cyril Brulebois <kibi@debian.org> - 2026-06-27 16:50 +0200
      Re: Uploading linux (7.0.14-1) Cyril Brulebois <kibi@debian.org> - 2026-06-28 15:00 +0200
        Re: Uploading linux (7.0.14-1) Cyril Brulebois <kibi@debian.org> - 2026-06-28 15:30 +0200
          Re: Uploading linux (7.0.14-1) Adrian Bunk <bunk@debian.org> - 2026-06-28 16:10 +0200
          Re: Uploading linux (7.0.14-1) Cyril Brulebois <kibi@debian.org> - 2026-06-28 19:10 +0200
            Re: Uploading linux (7.0.14-1) Cyril Brulebois <kibi@debian.org> - 2026-07-01 16:30 +0200
              Re: Uploading linux (7.0.14-1) Holger Levsen <holger@layer-acht.org> - 2026-07-01 17:00 +0200
    Re: Uploading linux (7.0.14-1) John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> - 2026-06-27 17:20 +0200
    Re: Uploading linux (7.0.14-1) Salvatore Bonaccorso <carnil@debian.org> - 2026-07-03 17:50 +0200

#93122 — Uploading linux (7.0.14-1)

FromSalvatore Bonaccorso <carnil@debian.org>
Date2026-06-27 16:30 +0200
SubjectUploading linux (7.0.14-1)
Message-ID<NaCcF-1iYm-7@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

Hi

I would like to upload linux version 7.0.14-1 to unstable. It is a
small release containing a set of selected important fixes upstream.

I will wait that 7.0.13-1 migrated first to testing.

Regards,
Salvatore

[toc] | [next] | [standalone]

#93126

FromCyril Brulebois <kibi@debian.org>
Date2026-06-27 16:50 +0200
Message-ID<NaCw2-1j7d-11@gated-at.bofh.it>
In reply to#93122

[Multipart message — attachments visible in raw view] — view raw

Hi,

Salvatore Bonaccorso <carnil@debian.org> (2026-06-27):
> I would like to upload linux version 7.0.14-1 to unstable. It is a
> small release containing a set of selected important fixes upstream.
> 
> I will wait that 7.0.13-1 migrated first to testing.

I'd like to get d-i uploaded to sid (per reproducible builds people
request) when 7.0.13-1 reaches testing. That isn't a prelude to a
release, so as soon as it's built everywhere on unstable, 7.0.14-1 (and
others) can be uploaded as you see fit.


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [prev] | [next] | [standalone]

#93137

FromCyril Brulebois <kibi@debian.org>
Date2026-06-28 15:00 +0200
Message-ID<NaXh7-1uo3-1@gated-at.bofh.it>
In reply to#93126

[Multipart message — attachments visible in raw view] — view raw

[ cc += reproducible-builds@ ]

Cyril Brulebois <kibi@debian.org> (2026-06-27):
> Salvatore Bonaccorso <carnil@debian.org> (2026-06-27):
> > I would like to upload linux version 7.0.14-1 to unstable. It is a
> > small release containing a set of selected important fixes upstream.
> > 
> > I will wait that 7.0.13-1 migrated first to testing.
> 
> I'd like to get d-i uploaded to sid (per reproducible builds people
> request) when 7.0.13-1 reaches testing. That isn't a prelude to a
> release, so as soon as it's built everywhere on unstable, 7.0.14-1
> (and others) can be uploaded as you see fit.

I'm currently fighthing a depthcharge-related oddity: a build in a sid
development (so very unclean, with lots of history and extra packages)
works just fine, but a build inside a fresh sid cowbuilder env doesn't.

I'm working on understanding the problem and fixing it. If I can't
manage to do that in a reasonable time, I'll probably give you a green
light to upload 7.0.14-1 to sid, and the d-i upload window would open
again once 7.0.14-1 reaches testing.

Sorry for holding the kernel team up.


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [prev] | [next] | [standalone]

#93138

FromCyril Brulebois <kibi@debian.org>
Date2026-06-28 15:30 +0200
Message-ID<NaXK9-1uHb-1@gated-at.bofh.it>
In reply to#93137

[Multipart message — attachments visible in raw view] — view raw

Cyril Brulebois <kibi@debian.org> (2026-06-28):
> I'm currently fighthing a depthcharge-related oddity: a build in a sid
> development (so very unclean, with lots of history and extra packages)
> works just fine, but a build inside a fresh sid cowbuilder env doesn't.

The same issue happens with daily builds, at least on some archs. Given
the absence of changes on the installer side, the timing, and the
expression of the bug, I'm pretty sure this is due to the Python bump
from 3.13 to 3.14 (which would also explain why my development
environment is behaving differently).

  https://tracker.debian.org/news/1768399/accepted-python3-defaults-3146-1-source-into-unstable/

I haven't tracked down the exact reason for the failure (yet) though.

> I'm working on understanding the problem and fixing it. If I can't
> manage to do that in a reasonable time, I'll probably give you a green
> light to upload 7.0.14-1 to sid, and the d-i upload window would open
> again once 7.0.14-1 reaches testing.

I'll be filing a serious bug report against depthcharge-tools shortly…

Unless the kernel team is happy to wait until that's resolved, I think
it would make sense to proceed with 7.0.14-1, and try again (to upload
d-i to unstable) in a few days, once 7.0.14-1 reaches testing and
depthcharge-tools is fixed.


Previous build logs looked like this:

    update-manifest dest/cdrom/gtk/debian-cd_info.tar.gz "isolinux help screens for CD (graphical)"
    pigz -nm -v -d <tmp/cdrom_gtk/initrd.gz |   xz -T0 --check=crc32 --block-size=1M -v >tmp/cdrom_gtk/initrd.xz
    <stdin> to <stdout> 
    (stdin): 57.1 MiB / 134.4 MiB = 0.425, 14 MiB/s, 0:09
    rm -f ./tmp/cdrom_gtk/depthcharge/*
    mkdir -p ./tmp/cdrom_gtk/depthcharge
    for board in amd64-generic; do \
            depthchargectl build -v \
                    --board ${board} \
                    --kernel-release 7.0.13+deb14-amd64 \
                    --kernel ./tmp/cdrom_gtk/vmlinuz \
                    --initramfs ./tmp/cdrom_gtk/initrd.xz \
                    --root none \
                    --kernel-cmdline "partman-partitioning/default_label=gpt --- quiet" \
                    --output ./tmp/cdrom_gtk/depthcharge/${board}.kernel.img; \
            gen-hd-image -v -z \
                    -X gpt \
                    -p $(($(stat -c%s ./tmp/cdrom_gtk/depthcharge/${board}.kernel.img) / 512 + 2048)) \
                    -i $(mktemp -d) \
                    -o ./tmp/cdrom_gtk/depthcharge/${board}.disk.img \
                    -d FE3A2A5D-4F32-41A7-B725-ACCC3285A309 \
                    ./tmp/cdrom_gtk/depthcharge/${board}.kernel.img \
                    2048; \
            pigz -9nmf ./tmp/cdrom_gtk/depthcharge/${board}.kernel.img; \
    done
    Couldn't find /boot in fstab, falling back to '/boot'.
    Assuming board 'Unnamed amd64-generic board' ('amd64-generic') by codename argument or config.
    Using kernel cmdline from given options: partman-partitioning/default_label=gpt --- quiet
    Building depthcharge image for board 'Unnamed amd64-generic board' ('amd64-generic').
    Building for kernel version '7.0.13+deb14-amd64'.
    Trying with compression 'none'.
    Using file '/build/reproducible-path/debian-installer-20250804/build/tmp/cdrom_gtk/vmlinuz' as a vmlinuz.
    Trying to decompress file '/build/reproducible-path/debian-installer-20250804/build/tmp/cdrom_gtk/vmlinuz'. 
    Using file '/build/reproducible-path/debian-installer-20250804/build/tmp/cdrom_gtk/initrd.xz' as an initramfs.
    Using keyblock file '/usr/share/vboot/devkeys/kernel.keyblock'.
    Using signprivate file '/usr/share/vboot/devkeys/kernel_data_key.vbprivk'.
    Using signpubkey file '/usr/share/vboot/devkeys/kernel_subkey.vbpubk'.
    Vmlinuz pref_address is 0x1000000, with init_size 0x3c47000.
    Padding vmlinuz to size 0xdaa000
    Packing files as temporary image.
    […]

New build logs look like this instead:

    update-manifest dest/cdrom/gtk/debian-cd_info.tar.gz "isolinux help screens for CD (graphical)"
    pigz -nm -v -d <tmp/cdrom_gtk/initrd.gz |   xz -T0 --check=crc32 --block-size=1M -v >tmp/cdrom_gtk/initrd.xz
    <stdin> to <stdout> 
    (stdin): 57.1 MiB / 134.4 MiB = 0.425, 14 MiB/s, 0:09
    rm -f ./tmp/cdrom_gtk/depthcharge/*
    mkdir -p ./tmp/cdrom_gtk/depthcharge
    for board in amd64-generic; do \
            depthchargectl build -v \
                    --board ${board} \
                    --kernel-release 7.0.13+deb14-amd64 \
                    --kernel ./tmp/cdrom_gtk/vmlinuz \
                    --initramfs ./tmp/cdrom_gtk/initrd.xz \
                    --root none \
                    --kernel-cmdline "partman-partitioning/default_label=gpt --- quiet" \
                    --output ./tmp/cdrom_gtk/depthcharge/${board}.kernel.img; \
            gen-hd-image -v -z \ 
                    -X gpt \
                    -p $(($(stat -c%s ./tmp/cdrom_gtk/depthcharge/${board}.kernel.img) / 512 + 2048)) \
                    -i $(mktemp -d) \
                    -o ./tmp/cdrom_gtk/depthcharge/${board}.disk.img \
                    -d FE3A2A5D-4F32-41A7-B725-ACCC3285A309 \
                    ./tmp/cdrom_gtk/depthcharge/${board}.kernel.img \
                    2048; \
            pigz -9nmf ./tmp/cdrom_gtk/depthcharge/${board}.kernel.img; \
    done
    Traceback (most recent call last):
      File "/usr/bin/depthchargectl", line 33, in <module>
        sys.exit(load_entry_point('depthcharge-tools==0.6.2', 'console_scripts', 'depthchargectl')())
                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
      File "/usr/lib/python3/dist-packages/depthcharge_tools/utils/argparse.py", line 895, in main
        parser = cls.parser
                 ^^^^^^^^^^
      File "/usr/lib/python3/dist-packages/depthcharge_tools/utils/argparse.py", line 1042, in parser
        return cls.__build()
               ~~~~~~~~~~~^^
      File "/usr/lib/python3/dist-packages/depthcharge_tools/utils/argparse.py", line 1065, in __build
        arg.build(parser)
        ~~~~~~~~~^^^^^^^^
      File "/usr/lib/python3/dist-packages/depthcharge_tools/utils/argparse.py", line 439, in build
        return parent.add_argument(*option_strings, **kwargs)
               ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/usr/lib/python3.14/argparse.py", line 1531, in add_argument
        kwargs = self._get_positional_kwargs(*args, **kwargs)
      File "/usr/lib/python3.14/argparse.py", line 1666, in _get_positional_kwargs
        raise ValueError('nargs for positionals must be != 0')
    ValueError: nargs for positionals must be != 0
    stat: cannot statx './tmp/cdrom_gtk/depthcharge/amd64-generic.kernel.img': No such file or directory
    /bin/sh: 10: arithmetic expression: expecting primary: " / 512 + 2048"
    make[4]: *** [config/x86.cfg:437: arch_depthcharge] Error 2
    make[3]: *** [Makefile:315: _build] Error 2
    make[2]: *** [Makefile:309: build_cdrom_gtk] Error 2
    make[1]: *** [Makefile:315: _build] Error 2
    make: *** [Makefile:309: build_cdrom_isolinux] Error 2

In passing, one might be confused by the mix of Python traceback and
error issues: the failure of depthchargectl doesn't trigger the exit, so
gen-hd-image is attempted with parameters computed via shell-based maths
on… a file that hasn't been created by the previous command, hence the
stat/arithmetic expression errors.


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [prev] | [next] | [standalone]

#93140

FromAdrian Bunk <bunk@debian.org>
Date2026-06-28 16:10 +0200
Message-ID<NaYmS-1v56-5@gated-at.bofh.it>
In reply to#93138
On Sun, Jun 28, 2026 at 03:20:49PM +0200, Cyril Brulebois wrote:
>...
> New build logs look like this instead:
>...
>       File "/usr/lib/python3/dist-packages/depthcharge_tools/utils/argparse.py", line 439, in build
>         return parent.add_argument(*option_strings, **kwargs)
>                ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
>       File "/usr/lib/python3.14/argparse.py", line 1531, in add_argument
>         kwargs = self._get_positional_kwargs(*args, **kwargs)
>       File "/usr/lib/python3.14/argparse.py", line 1666, in _get_positional_kwargs
>         raise ValueError('nargs for positionals must be != 0')
>     ValueError: nargs for positionals must be != 0
>...

Workaround (untested):
https://github.com/alpernebbi/depthcharge-tools/pull/14

> Cheers,

cu
Adrian

[toc] | [prev] | [next] | [standalone]

#93142

FromCyril Brulebois <kibi@debian.org>
Date2026-06-28 19:10 +0200
Message-ID<Nb11n-1wo0-5@gated-at.bofh.it>
In reply to#93138

[Multipart message — attachments visible in raw view] — view raw

Cyril Brulebois <kibi@debian.org> (2026-06-28):
> I'll be filing a serious bug report against depthcharge-tools shortly…

Thanks to Colin's prompt actions on #1140927, I'll be giving the upload
another try shortly. It'd be great if the reproducible builds team could
indicate when the tests they wanted to run yield results, so that the
kernel team can resume work.


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [prev] | [next] | [standalone]

#93170

FromCyril Brulebois <kibi@debian.org>
Date2026-07-01 16:30 +0200
Message-ID<Nc46R-26Ni-1@gated-at.bofh.it>
In reply to#93142

[Multipart message — attachments visible in raw view] — view raw

Hi r-b team,

Cyril Brulebois <kibi@debian.org> (2026-06-28):
> Cyril Brulebois <kibi@debian.org> (2026-06-28):
> > I'll be filing a serious bug report against depthcharge-tools shortly…
> 
> Thanks to Colin's prompt actions on #1140927, I'll be giving the upload
> another try shortly. It'd be great if the reproducible builds team could
> indicate when the tests they wanted to run yield results, so that the
> kernel team can resume work.

I'm no expert but that looks rather good:
  https://reproduce.debian.net/excuses.html?source_name=debian-installer

Does that mean the kernel team can resume uploading src:linux?


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [prev] | [next] | [standalone]

#93171

FromHolger Levsen <holger@layer-acht.org>
Date2026-07-01 17:00 +0200
Message-ID<Nc4qd-26Vb-3@gated-at.bofh.it>
In reply to#93170

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jul 01, 2026 at 04:24:28PM +0200, Cyril Brulebois wrote:
> I'm no expert but that looks rather good:
>   https://reproduce.debian.net/excuses.html?source_name=debian-installer

yes, thanks to the many changes in debian-installer.git added in the last
year and which were finally uploaded! very nice!
 
> Does that mean the kernel team can resume uploading src:linux?

sure.


-- 
cheers,
	Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

»Die Wüstengebiete werden sich ausdehnen, die Polkappen werden abschmelzen,
 der Wasserspiegel wird ansteigen, all das wirkt jetzt noch wie ein Szenario
 aus einem Science-Fiction-Roman, unsere Kinder, spätestens unsere Enkelkinder
 werden erfahren, dass das mehr ist.« - Hoimar von Ditfurth, 1978

[toc] | [prev] | [next] | [standalone]

#93128

FromJohn Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Date2026-06-27 17:20 +0200
Message-ID<NaCZ3-1jsF-9@gated-at.bofh.it>
In reply to#93122
On Sat, 2026-06-27 at 16:20 +0200, Salvatore Bonaccorso wrote:
> I would like to upload linux version 7.0.14-1 to unstable. It is a
> small release containing a set of selected important fixes upstream.
> 
> I will wait that 7.0.13-1 migrated first to testing.

It would have been nice to have either scsi-modules [1] on sparc64 switched
to the common module list or at least nvme added to its current list as I
requested around six weeks ago [2].

Thanks,
Adrian

> [1] https://salsa.debian.org/kernel-team/linux/-/blob/debian/latest/debian/installer/modules/sparc64/scsi-modules?ref_type=heads
> [2] https://salsa.debian.org/kernel-team/linux/-/merge_requests/1936

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

[toc] | [prev] | [next] | [standalone]

#93199

FromSalvatore Bonaccorso <carnil@debian.org>
Date2026-07-03 17:50 +0200
Message-ID<NcOjn-2wOk-5@gated-at.bofh.it>
In reply to#93122
Hi,

On Sat, Jun 27, 2026 at 04:20:38PM +0200, Salvatore Bonaccorso wrote:
> Hi
> 
> I would like to upload linux version 7.0.14-1 to unstable. It is a
> small release containing a set of selected important fixes upstream.
> 
> I will wait that 7.0.13-1 migrated first to testing.

FTR, 7.0.14-1 was uploaded after green light from Cyril. Note as 7.0.y
is EOL upstream we will next move 7.1.y to unstable soon to make as
well the way free in experimental for the 7.2-rcX uploads.

Regards,
Salvatore

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web