Re: amd64 daily installer images not updated since 2026-07-05

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

Cyril Brulebois wrote:
>  - [x] Trick myself into actually looking instead of just giving a few
>        examples.

Roughly comparing 13.5.0-amd64-netinst to testing-amd64-netinst of
2026-06-29 by executing

  old_iso=/dvdbuffer/debian-13.5.0-amd64-netinst.iso
  new_iso=/dvdbuffer/debian-testing-amd64-netinst.iso
  old_du=/tmp/old_du
  new_du=/tmp/new_du

  xorriso -indev "$old_iso" -dus "/*" "/pool/*" "/pool/main/*" -- >"$old_du"
  xorriso -indev "$new_iso" -dus "/*" "/pool/*" "/pool/main/*" -- >"$new_du"

and viewing the resulting /tmp/*_du files side-by-side, i see inflation
mostly at firmware and somewhat with /install.amd.
 Old:                        New:
 167592 '/firmware'          361697 '/firmware'
 198849 '/install.amd'       219552 '/install.amd'

/pool does not look promising for size reduction. All files in
/pool/non-free-firmware share their content with files in /firmware.
So the size increase of /pool
 584572 '/pool'              768112 '/pool'
is only virtual.
/pool/main even shrunk:
 417892 '/pool/main'         407515 '/pool/main'

The ten fattest firmware packages in testing-amd64-netinst are
 103221 'firmware-qcom-dsp_0~20260519-1_all.deb'
 101724 'firmware-nvidia-graphics_20260519-1_all.deb'
  37053 'firmware-atheros_20260519-1_all.deb'
  25307 'firmware-mediatek_20260519-1_all.deb'
  23169 'firmware-iwlwifi_20260519-1_all.deb'
  15177 'firmware-amd-graphics_20260519-1_all.deb'
  13289 'intel-microcode_3.20260227.1_amd64.deb'
   7791 'firmware-intel-graphics_20260519-1_all.deb'
   5260 'firmware-brcm80211_20260519-1_all.deb'
   4986 'firmware-misc-nonfree_20260519-1_all.deb'
summing up to 336977 of 361697 KiB.


>  - [ ] Bump the size from 1G to 1.1G or even 1.2G, effectively punting
>        the investigation to “later”. This is likely easier and quicker
>        than what I mentioned, but I can't help but worry this could be a
>        one-way street, and I'd rather try and avoid bumping the limit if
>        some reasonable amount of work lets us stay below the existing
>        limit.

I don't see much chance to curb the growth of firmware blobs.
Even if a big one is thrown out, the others will eat up the free space
quickly.

Consider to expand generously without giving up the goal to make netinst
as small as possible.
Some data points from my desk:
My smallest USB stick from around 2005 offers 1.9 GiB.
The next larger one has ~ 4 GiB.
The size of a DVD is 2295104 * 2048 = 4,700,372,992 bytes.
(DVD-RAM are smaller. Their size depends on formatting.)


Have a nice day :)

Thomas