Hi,

Thank you for maintaining d-i!

I may be late to the bookworm party but… It would be nice if d-i could
provide deb822-style sources.list (by default) for newly installed
machines.

Apologies in advance if I missed a duplicate in a more appropriate
module.

Cheers,

taffit

Hi,

David Prévot <taffit@debian.org> (2023-02-28):

This seems late indeed.


Cheers,

Hiya, we just flipped the switch for Ubuntu, I think it's about time
we switch apt-setup for trixie.

The path we picked for Ubuntu was to keep a transtional sources.list
file:

# Ubuntu sources have moved to the /etc/apt/sources.list.d/ubuntu.sources
# file, which uses the deb822 format. Use deb822-formatted .sources files
# to manage package sources in the /etc/apt/sources.list.d/ directory.
# See the sources.list(5) manual page for details.

We probably should use the same text with s/Ubuntu/Debian/;s/ubuntu/debian/.

Having the transitional commented sources.list helps various tools
that identify a debian-style system by looking at sources.list
presence and guides the user.

The Debian sources should then be in sources.list.d/debian.sources. See
the Docker images tianon builds for Debian, they have already switched
and provide (only) the debian.sources.

Thank you!

Control: severity -1 important

This has been sitting for almost 2 years again; the style of sources
apt-setup generate now triggers complaints from apt as APT recommends
every source have a signed-by field (and it then goes on to tell you
to migrate to deb822 .sources too if a missing signed-by is in a
.list file).

As such I'm bumping this to important.

My prefered solution is to use a template, for `debian.sources`:

    # Official @VENDOR@ sources.
    # Available types: deb (binaries) deb-src (source code)
    # Available suites: @SUITE@ (release) @SUITE@-updates (urgent updates)
    # Available components:
    #   - main (free software)
    #   - contrib (explanation)
    #   - non-free (explanation)
    #
    # Make sure to keep the security updates configured for the same set
    # of components in the following paragraph.
    Types: deb @DEBSRC@
    URIs: @MIRROR@
    Suites: @SUITE@ @SUITE_UPDATE@
    Components: @COMPONENTS@
    Signed-By: @SIGNED_BY@

    # Security updates.
    Types: deb @DEBSRC@
    URIs: @MIRROR_SECURITY@
    Suites: @SUITE_SECURITY@
    Components: @COMPONENTS@
    Signed-By: @SIGNED_BY@

Note that @SUITE_UPDATES@ and @DEBSRC@ can be empty. You need to delete
trailing whitespaces and collapse multiple whitespaces:

    's/ */ /g;s/ $//'

Note that the canonical format that software-properties generates
only supports comments at the start and end of the section, otherwise

    Types: deb # deb-src

also would work.

An alternative approach is to use fine-grained key specification with
the individual archive security keys in each signed-by, rather than
using debian-archive-keyring.gpg; this however significantly worsens
user experience when changing Suites and whatnot so it's not
recommended.

Another alternative is to use default values instead of template
variables and sed them out like you'd sed the template values;
this way the template also is itself a valid sources file.

I propose removing apt-setup-verify and keeping failed sources
enabled, this is both significantly easier to implement, and
also means users will actually see warnings on their systems
rather than have to dig through disabled sources.

for third-party sources, `$NAME.sources`:

    Types: deb @DEBSRC@
    URIs: @MIRROR@
    Suites: @SUITE@
    Components: @COMPONENTS@
    Signed-By: @SIGNED_BY@


The cdrom sources should be added ephemerally in cdrom.sources,
I'd prefer for them to not stick around in the installed system
as the cdrom code is not well-tested.

Hello Julian,

The new version of apt (2.9.24) will now cause a FTBFS for the daily
d-i. This has been noticed already in the daily live ISO images based on
sid.

I have a question about timing...
This wishlist/change request has been sitting for a long time, but now a
short-term solution is enforced (at least for sid).

I have been thinking (just to keep the daily sid-based live images
building) to temporarily add a '[trusted=yes]', which is (from a
security point of view) a nightmare, and exactly the opposite of that
what is intended by the specification of a 'signed-by' field.

With kind regards,
Roland Clobus

[1] https://jenkins.debian.net/view/live/ -> Already 2 sid-based images
are failing, the rest will fail tomorrow.

Sorry for the phone reply but

Roland Clobus <rclobus@rclobus.nl> schrieb am Di., 21. Jan. 2025, 23:11:


That sounds like nonsense. I've added Notices, they are only shown in
interactive use in the apt(8) command which is not involved anywhere in the
process, and they are not fatal either way.


I have a question about timing...

That's absurd, you could just use signed-by.


Roland Clobus

I see rsync failures there, no apt failures.

Julian Andres Klode <jak@debian.org> (2025-01-21):

Maybe it's nonsense but I'm seeing a new failure for `æpt-get update`:

    E: Method gave invalid 400 URI Failure message: List of files can't be created as '/home/kibi/debian-installer/installer/build/apt.udeb/etc/apt/trusted.gpg.d/' is not a directory

and that indeed breaks d-i builds.

Looking at the few commits between 2.9.23 and 2.9.24 suggests
6f618323d2d1cea47df0952a9ed2cebcda6c7193 might trigger this, but I'm not
going to spend time on this right now, especially if what we're getting
is name calling…

(All of that seems orthogonal to src:apt-setup and this specific bug
report anyway, but that's not a reason to be so dismissive.)


Cheers,

This is fine and it makes some sense, but it's unrelated to the matter
being discussed here. And let me assure you, I combed through the logs of the
failing builds and all I see is:

	P: building the debian-installer
	building build_cdrom_gtk failed, see log file dest/build_cdrom_gtk.log for details
	building build_cdrom_isolinux failed, see log file dest/build_cdrom_isolinux.log for details
	grep: ./dest//MANIFEST.udebs: No such file or directory
	cp: cannot stat 'chroot/debian-installer/build/dest/cdrom/vmlinuz': No such file or directory

and then it starts failing to rsync some fails.

So there is no evidence to substantiate that theory, so I need to
dismiss is as "unsubstantiated wild take" as happens all the time
when people blame apt for anything apt adjecent, like hooks hanging,
postinsts crashing, or their network being misconfigured.

That's not true at all. I don't know what your exposure to debate
culture is, but I can explain:

Starting with, there are three levels at which you can debate:

1. the matter itself (the other argument is nonsense)
   ^ this is what I commented on, providing evidence to substantiate the claim
2. the position from which the argument is made (the APT maintainer)
3. the person who made the argument (Julian)
   ^ this is where name calling would be at

I don't know your background, but my general set of guidelines and
expectations for the style of debate follows the established rules
of the British parliament: Personal attacks are taboo, and discussions
should be on the merit of the matter being discussed.

Taken together we end up with some examples of what kind of statements
are acceptable and which are not:

- "This is nonsense, there is no evidence supporting this claim"
  is an acceptable statement questioning the merit of the claim.

- "The APT maintainer is saying nonsense, there is no evidence"
  remains acceptable as it makes the argument at a level of position
  and doesn't attack the person.

- "Julian is saying nonsense" is not acceptable as, while it questions
  the merit of the argument, it does so at a personal level.

- "The APT maintainer is stupid" is not acceptable because it does not
  question the merit of the matter. It is not a personal attack, since
  it only attacks the position, but could still be considered impertinent.

- "Julian is stupid" is clearly a personal attack and not acceptable.

Hello Julian,
in the logs.

The FTBFS was first detected on Jenkins (as you have seen):
https://jenkins.debian.net/view/live/job/reproducible_debian_live_build_lxqt_sid/1085/consoleFull

The line that points to d-i FTBFS is (as you have seen):
`building build_cdrom_gtk failed, see log file dest/build_cdrom_gtk.log
for details`

Unfortunately, the log file that is pointed to
(dest/build_cdrom_gtk.log) is not available in Jenkins. That makes my
claim that the FTBFS is caused by the newer version of apt without
evidence. The following rsync failures are be caused by the missing d-i
image.

Yesterday I've built the installer locally, using sid in a chroot, and
was able to reproduce the FTBFS, which is caused by the line starting
with 'E:', that Cyril reported.
Having said directory already created does unfortunately not fix the
error message.
A log is now available here:
https://d-i.debian.org/daily-images/amd64/20250122-00:06/build_cdrom_isolinux.log

Perhaps I should not have re-used this bug report, but you bumped the
severity of this bug report, and after that the legacy one-line
configuration stopped working, which made me think that there is a
direct correlation.

For live-build I've implemented a quick fix, which adds 'signed-by' at
https://salsa.debian.org/live-team/live-build/-/merge_requests/401, but
that (temporarily) breaks the multi-distro functionality of live-build
(due to the non-configurable filename 'debian-archive-keyring.gpg').
Unfortunately, this quick fix will also not be applicable to all use
cases for debian-installer.

The current code for d-i parses the /etc/apt/sources.list file and uses
that to generate a new single-line style sources.list for the retrieval
of the udeb files.

It will take some effort to migrate to deb822 for d-i, and additionally
live-build needs to migrate to deb822 as well.

With kind regards,
Roland Clobus

This all seems very reminiscent of:

https://salsa.debian.org/installer-team/debian-installer/-/merge_requests/54

with the example failure I pointed to in that including this line:

https://salsa.debian.org/philh/cdebconf/-/jobs/6829946#L3432

with the complaint about it not being a directory.

I'm just not immediately remembering the details of the fix, and haven't
got time to remind myself just now, so thought I'd fire off a quick mail
in case it's obvious to someone else.

Cheers, Phil.

Philip Hands <phil@hands.com> (2025-01-22):

There might be some similarities, but you singled that out as being a
consequence of an earlier apt version, while today's problem is new in
2.9.24 (and fixed in 2.9.25, see apt-team/apt!433).

https://salsa.debian.org/apt-team/apt/-/merge_requests/433

(This is just to clarify the scope, rather than commenting about any
proposed changes.)


Cheers,

Which is fairly similar to what I have here:

Types: deb
URIs: https://deb.debian.org/debian
Suites: bookworm-updates bookworm bookworm-backports
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg

Types: deb
URIs: https://deb.debian.org/debian-debug
Suites: bookworm-debug bookworm-backports-debug
Components: main contrib non-free non-free-firmware
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
------

The key advantage to the above combined sources file is that it
remains extremely compact and mostly easy to read for someone
migrating from the old format. In the above, 'bookworm' could also be
replaced by 'stable' if someone doesn't wanna manually edit the file
at every new Debian release. Since 'backports' is pinned at a lower
priority by APT by default, no package will be fetched from there
unless explicitly told using e.g. 'apt-get install package/backports'
or pinned using /etc/apt/preferences.

On Hurd (read: any architecture supported only via Ports), I have a
slightly more complex file due to having to source both Debian (all,
sources) and Debian-Ports (hurd-i386) which uses 2 keyrings and
permanently tracks 'unstable' since Hurd doesn't offer any 'stable'
release because it's a non-supported port.
Types: deb
URIs: http://deb.debian.org/debian-ports/
Suites: unstable
Components: main
Signed-By: /usr/share/keyrings/debian-ports-archive-keyring.gpg

Types: deb deb-src
URIs: http://deb.debian.org/debian/
Suites: unstable
Components: main
Architectures: all
Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
------

There's good chances that 'crosshurd' will adopt this debian.sources
file as a default on time for Trixie.

Btw, 'dselect' will need upgrading since it tries to create a new
/etc/apt/sources.list if none exists even if /etc/apt/sources.list.d/
is populated. See #1104283.

Martin-Éric