Re: Bug#1068197: debian-installer: accesses the internet during build

[Bastian Blank]

On Mon, Apr 01, 2024 at 07:39:18PM +0200, Jonathan Carter wrote:
> As far as I know, this doesn't happen until after d-i asked the question "Do
> you want to use a network mirror?" and the user answered "Yes", in which
> case I think that would count as informed consent.

During build, not during usage.

And I don't see how it can work any different, as d-i build works by
fetching packages somehow.

Bastian

-- 
Killing is stupid; useless!
-- McCoy, "A Private Little War", stardate 4211.8

Re: What to do with d-i on armel?

[Bastian Blank]

[ Remove -arm and -release }

Hi

On Sun, Mar 03, 2024 at 09:01:06PM +0100, Cyril Brulebois wrote:
> Maybe have it marked Not-For-Us on armel, also requesting the binary to
> be dropped there? And maybe poke the ftp team to have installer-armel/
> cleaned up? (The “disabling daily builds” part being trivial.)

i would remove the d-i package itself (don't we already set the
supported architectures?)

Cleanup installer-armel.

Remove armel specific udeb sources (I doubt we hve any).

I would not try to remove udebs itself but just continue to build them.

Bastian

-- 
No one wants war.
-- Kirk, "Errand of Mercy", stardate 3201.7

Re: What to do with d-i on armel?

[Bastian Blank]

On Fri, Jan 19, 2024 at 05:33:23PM +0100, Arnd Bergmann wrote:
> Right, though changing the kernel package to support this
> sounds easier than changing the installer to use a
> foreign architecture kernel package.

Well.  It is a "dpkg --add-architecture" in the right spot of
base-installer/debian/bootstrap-base.postinst.

Bastian

-- 
Yes, it is written.  Good shall always destroy evil.
-- Sirah the Yang, "The Omega Glory", stardate unknown

What to do with d-i on armel?

[Bastian Blank]

Hi

With Linux 6.6 we dropped the Marvell specific kernel image, as it
was not known to work on any of the available devices.  We still have
another armel kernel left, the one of the Raspberry Pi 0 and 1, which
uses an ARMv6 CPU.

This also removed all the udebs from armel, which makes many d-i
components not longer have fullfiled dependencies and the release stuff
of course acting up.

Do we have any armel subarch that can be installed via d-i?

Bastian

-- 
Without freedom of choice there is no creativity.
-- Kirk, "The return of the Archons", stardate 3157.4

Re: Immediate fallouts from the big linux changes, and actions

[Bastian Blank]

On Sun, Dec 24, 2023 at 08:38:57AM +0100, Cyril Brulebois wrote:
> - kernel-image-* packages are now shipping /boot/vmlinuz-* (or
>   /boot/vmlinux-* depending on the arch), instead of just /boot/vmlinuz
>   (respectively /boot/vmlinux).

This was even dependent on architecture.  A lot of secondary
architectures already had various suffixes.

> - Modules are compressed now, so the drm workaround needed an updated to
>   cope with the extra .xz suffix:
> 
> https://salsa.debian.org/installer-team/debian-installer/-/commit/bd0f1106f90756e6f4514108492d71e1f2e695ea

This now hardcodes .xz.  And I'm not really sure what this does and why
this can't be fixed in the kernel packages.

> - Finally, the armel build fails because it can't find its kernel. The
>   marvell flavour seems to have been dropped entirely (at least that's
>   how I read the linux changelog for 6.6.3-1~exp1:
> 
> https://tracker.debian.org/news/1482751/accepted-linux-663-1exp1-source-into-experimental/

Yes, the kermel was broken and the checks for this disabled since quite
some time.

Bastian

-- 
Extreme feminine beauty is always disturbing.
-- Spock, "The Cloud Minders", stardate 5818.4

Re: Bug#1040901: Upcoming changes to Debian Linux kernel packages

[Bastian Blank]

On Fri, Oct 27, 2023 at 08:43:46AM +0200, Julian Andres Klode wrote:
> > > ## Image packages contains more version info
> > > 
> > > Example: linux-image-6.5.3-cloud-arm64
> > 
> > > It will not longer be possible to reliably derive the package name from
> > > kernel release (see above), as both values are not really related
> > > anymore.
> 
> This package name seems to be missing the Debian release, which is
> mandatory to ensure that you can install 6.5.3-2 and 6.5.3-1 in
> parallel, which again is mandatory. That's not something we can
> compromise on; it's absolutely vital that

Sadly in Debian there is no way to make that happen.  Think for example
about bin-nmu.

In the end we can approximate it in testing (usually not multiple
releases are migrated, but bin-nmu might show up), stable (where usualy
new upstream releases go in) and security (by uploading as 6.6.1,
6.6.1+1, 6.6.1+2, yes this is a hack, but it reduces the complexity of
the whole system).

Right now I simply don't see a way to not have multiple releases within
the same package, which override each other.

> - you can revert to the kernel you last booted succesfully, i.e. 6.5.3-1
>   if 6.5.3-2 is broken (think toolchain broke or something on buildds)

You can revert to 6.5.2, which is a separate package.  Or 6.4.

> - the currently booted kernel is not impacted. This means it must be
>   able to load additional modules. Some platforms even require
>   additional modules to be loaded to reboot, I've seen this on
>   laptops.

Could you provide an example?

Then we have to find another way to make sure modules survive unrelated
to what dpkg does.  Even right now there is no guarante you can load
modules from a different version at all.

> Needless to say I do not believe that uname -s is necessarily a
> single word.

Please provide an example.

[ Snipped the rest for now, will come back later ]

Bastian

-- 
Where there's no emotion, there's no motive for violence.
-- Spock, "Dagger of the Mind", stardate 2715.1

Re: Upcoming changes to Debian Linux kernel packages

[Bastian Blank]

On Thu, Oct 05, 2023 at 07:59:54AM -0600, Sam Hartman wrote:
> I think that's what you mean by the first-level error.
> If not, I'm still confused.
> In the second level error case you are talking about is:

No, the first level is always: but the new kernel does not work.
The second is: I need to upgrade external modules.

> I think what you are saying is that
> 
> 1) the current system is fragile: sometimes you want a kernel headers
> that is not available and sometimes you have version skew between the
> kernel headers and kernel even though you have both installed.
> 
> 2) In your system, fewer things are possible, but the combination that
> is possible is more likely to work.

Yes.

> And I think people's response is that
> they care enough about some of the things you are breaking that they are
> willing to accept the fragility.

For now it looks like a better solution is to just create more meta
packages and accept that they become uninstallable from time to time.

In the future we might want to split off the modules into it's own
package anyway.  That will then allow
- a different image package containing prebuilt UKI,
- a different modules package to replace the special cloud flavours.

Regards,
Bastian

-- 
Without facts, the decision cannot be made logically.  You must rely on
your human intuition.
-- Spock, "Assignment: Earth", stardate unknown

Re: Bug#1040901: Upcoming changes to Debian Linux kernel packages

[Bastian Blank]

Moin

On Sun, Sep 24, 2023 at 03:01:51PM +0200, Bastian Blank wrote:
> ## Kernel modules will be signed with an ephemeral key

This is now
https://salsa.debian.org/kernel-team/linux/-/merge_requests/607.

> ## Image packages contains more version info
> 
> Example: linux-image-6.5.3-cloud-arm64

> It will not longer be possible to reliably derive the package name from
> kernel release (see above), as both values are not really related
> anymore.

I missed that apt does something similar (maintainers cced).  It wants
to see if a particular package matches the current kernel to make the
autoremove prevention work.  That lookup is quite a hard problem.

What should work:  We define a new control field.  It contains both the
kernel name and a version prefix. 

Example:
- Linux 6.6 (would match 6.6-1, 6.6.1-1)
- Linux 6.6.3 (would match 6.6.3-1, but not 6.6.3+2-1)
- Linux 6.6.3+2

The algorithm would be something like this:
- Check $(uname -s) against the first word.  Otherwise completely
  ignore.
- Check if $(uname -r) matches the version prefix in this field.  Mark
  as keep if it matches.
- Aggregate packages by version prefix.
- Sort as version, keep newest two(?).

This means:
- Images and headers are always kept with the same versions.
- Different images (-arm64, -rt-arm64) are always kept together.

Counter proposal: Use see the kernel release as debian version and match
on the upstream version.  But then we need to re-define what we put into
the kernel release field.  In 6.6.1-1-cloud-arm64, the upstream version
is 6.6.1-1-cloud, not 6.6.1 as we would need.  We could of course change
that to: 6.6.1-1~cloud+arm64.  That should always sort correctly in
regard of the package version.

> ## Header and tool packages will not longer contain version

This is obsolete with the counter proposal of a meta package that always
pulls in image and headers of the same version.

Regards,
Bastian

-- 
Without followers, evil cannot spread.
-- Spock, "And The Children Shall Lead", stardate 5029.5

Re: Bug#1040901: Upcoming changes to Debian Linux kernel packages

[Bastian Blank]

Hi

On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> > Multiple uploads of the same upstream version will have
> > the same package name, but those rarely happens.
> Those happen fairly often for urgent security updates.

We could encode that in the upstream version.  Aka to have
co-installable packages for security updates we do:

- 6.6.1-1
- 6.6.1+1-1
- 6.6.1+2-1

This allows for easy semantic, aka we only care for package names about
the upstream part of the version, which then needs to follow a certain
syntax.

Regards,
Bastian

-- 
A Vulcan can no sooner be disloyal than he can exist without breathing.
-- Kirk, "The Menagerie", stardate 3012.4

Re: Upcoming changes to Debian Linux kernel packages

[Bastian Blank]

On Tue, Oct 03, 2023 at 03:00:53PM -0500, Robert Nelson wrote:
> On Tue, Oct 3, 2023 at 2:54 PM Adrian Bunk  wrote:
> > How will the user get the headers matching this previously-used kernel
> > that are required until we provide a kernel with the regression fixed?

The same as now: nowhere, because those packages have been removed from
the archive already.

And sadly you did not answer the question why a second degree error must
not be worse then a worked around first degree error?

> I know there is a lot of history behind the linux-headers package in
> debian.  However since 5.2 there is a kernel config option, which
> allows you to build the kernel headers as a module (built-in or
> external)..
> https://cateee.net/lkddb/web-lkddb/IKHEADERS.html
> As long as this was enabled (ignore bugs/regressions), users can go
> back and forth on kernel versions as they wish.

If it would be so easy.  This would include all the generated things of
the build.  But it still needs all the static headers, all the support
binaries and scripts (shipped as linux-kbuild-*), which also change with
every version.

Regards,
Bastian

-- 
Each kiss is as the first.
-- Miramanee, Kirk's wife, "The Paradise Syndrome",
   stardate 4842.6

Re: Upcoming changes to Debian Linux kernel packages

[Bastian Blank]

Hi Andreas

On Tue, Oct 03, 2023 at 11:58:29PM +0200, Andreas Beckmann wrote:
> That should solve the problem where several source packages need to be
> updated together.

The problem does not come from multiple source packages that need to be
updated together.  Instead it comes from the way Debian does signing of
secure boot components.  After the linux packages got built and accepted,
an automatic process takes the output and produces a new source package
that is uploaded, built and accepted.  So the signed stuff will always
come later (between hours or days in normal cases, but esp for backports
even more then a week later).

Regards,
Bastian

-- 
Insults are effective only where emotion is present.
-- Spock, "Who Mourns for Adonais?"  stardate 3468.1

Re: Upcoming changes to Debian Linux kernel packages

[Bastian Blank]

Hi Sam

On Tue, Oct 03, 2023 at 08:31:57AM -0600, Sam Hartman wrote:
> I still think it would help if you would work more on articulating what
> problem you are trying to solve with the linux-headers versioning
> change.  I have read multiple versions of this proposal, and your
> follow-ups, and I still do not understand what is prompting the
> linux-headers change.

The core problem is that people assume they can get headers matching the
currently running kernel, without upgrading first, see also the parallel
thread.  Or freak out because meta packages remain uninstallable in
backports for days.

With this plan you can only get the correct ones by using something
I think like:

| apt satisfy 'linux-headers (= $(uname -r))'

There is somewhere again a maybe possible plan to get meta packages in
place that actually support the case of always providing the headers to
the installed (not running!) kernel.

Then we need to use the same versioning anyway again.  In the end I
don't really care, but we need then a way to fix the version skew
between the different source package for the kernel.  Aka either redo
larger parts of the linux package (which can never fix it completely),
plus gcc or we change how backports works.

> My intuition mirrors others in the conversation that it is problematic
> to support multiple kernel versions without also supporting multiple
> header versions.

Usually you try to guard against one error.  Noone claimed that we can't
work with one error.  All the other conversations already have to argue
with two errors at the same time.  When should we stop then?

Regards,
Bastian

-- 
Deflector shields just came on, Captain.

Re: Upcoming changes to Debian Linux kernel packages

[Bastian Blank]

On Mon, Sep 25, 2023 at 04:35:08AM +0200, Andreas Beckmann wrote:
> On 25/09/2023 00.50, Bastian Blank wrote:
> > Already built modules remain until someone deletes it.  So you can also
> > switch back to the still installed older kernel version and it will have
> > the still working module available.
> Assume I have Linux 6.6 and a third-party gpu driver module installed (so
> there are dkms and the Linux 6.6 headers as well) and everything is working
> fine.
> Then I upgrade the system, which brings Linux 6.7 (along linux-image-6.6
> which is kept installed) and a new version of the gpu driver (which adds
> support for 6.7). So the old gpu module for 6.6 gets removed and a new one
> is built for 6.7 only (since there are only 6.7 headers now).

Ah, here lays the missconception.  No, the 6.6 ones are not removed.  Why
should they be?  The system knows it can't rebuild them.

If the current implementation would remove them, it is a problem there,
not in the concept.

Bastian

-- 
Superior ability breeds superior ambition.
-- Spock, "Space Seed", stardate 3141.9

Re: Bug#1040901: Upcoming changes to Debian Linux kernel packages

[Bastian Blank]

Hi Ben

On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> On Sun, 2023-09-24 at 15:01 +0200, Bastian Blank wrote:
> > The same upstream version in testing and backports will have the same
> > package name.
> This is not OK, because they will be incompatible on architectures
> supporting SB (and sometimes incompatible on others due to compiler
> differences or required config changes).

I don't know what you are talking about.  Those two packages have
different versions, so won't contain anything compatible.  It is the
same between 1.2.3-1 vs 1.2.3-2 and 1.2.3-1~bpo13+1 vs 1.2.3-1.

> If someone upgrades from stable + backports to testing, and has OOT
> modules:
> - With DKMS, will a rebuild be triggered if the linux-image package
>   name doesn't change?

The same as with a normal package upgrade, it will rebuilt against the
new version.  It just runs into the same version skew as everything
else.

> - With module-assistant, the new linux-image package will satisfy
>   dependencies of the old modules even though they are incompatible.

No, the two linux-image packages have different versions, so won't
satisfy the dependencies.

> > Multiple uploads of the same upstream version will have
> > the same package name, but those rarely happens.
> Those happen fairly often for urgent security updates.   

Right.  Maybe we need a manual or automatic override for this, we can do
a lot of things.

> > It will not longer be possible to reliably derive the package name from
> > kernel release (see above), as both values are not really related
> > anymore.
> Given all the drawbacks, I don't see the benefit of decoupling package
> names from release strings.
> In the same way that shared library packages must be renamed for every
> backward-incompatible ABI changes, I believe we should keep doing this
> for linux-image packages.

Noted, but I don't see a way to do that.  We can't map versions cleanly
into package names.  We have binNMU, which can't change package names,
so will already in violation of that.  And we already don't do that, see
that huge version ignore list.

Also the ABI in shared libraries is to have two independent updateable
identities.  Nothing is true in case of the kernel, it will just break
on every update of either side, which would be the equivalent of a =
dependency.  So no, shared libraries are not a good comparison.

> > ## Header and tool packages will not longer contain version
> > 
> > The headers packages will not longer include the version.  It won't be
> > reliably possible to derive the package name anyway from the running
> > kernel.
> >
> > This means that only headers of one single version can be available on
> > the system at one time.  This might be a bit inconvinient for dkms, as
> > it can't longer build modules for multiple versions.
> >
> > But we too often have the problem that image and headers go out of sync
> > and then you can't find the correct ones anyway.
> > 
> > Example: linux-headers-cloud-arm64
> 
> This is all downside with no justification given.  Please explain what
> the benefit is.

The current way does not work.  See all the bug reports about
uninstallable packages and what not with dkms.

To build modules against version x, you'll need to install version x of
the headers, not x-1 or x+1.  This currently works most of the time, but
is by far stable.  And if you already have to search for the specific
version, it does not matter if you might have the ability to install
multiple at the same time, the archive will in any case only contain one
version at a time.

IMHO the only way around would be to install image and headers always in
one piece for those who want to build own modules against.  But this
will require further restructuring, as the headers for this then need to
be built from linux-signed-* and arch-any to be without skew.  And
use proper dependencies so everything is installed with the same version
always.

Aka something like that:

Package: linux-image-cloud-arm64
Depends:
 linux-image-1.2.3-cloud-arm64 (= 1.2.3-1)

Package: linux-modules-thirdparty-cloud-arm64
Depends:
 linux-image-1.2.3-cloud-arm64 (= 1.2.3-1),
 linux-modules-1.2.3-cloud-arm64 (= 1.2.3-1),
 linux-headers-1.2.3-cloud-arm64 (= 1.2.3-1)

Package: linux-image-1.2.3-cloud-arm64
Depends: linux-modules-1.2.3-cloud-arm64 (= 1.2.3-1)

Package: linux-headers-1.2.3-cloud-arm64
Depends: linux-modules-1.2.3-cloud-arm64 (= 1.2.3-1)

Package: linux-modules-1.2.3-cloud-arm64

However doesn't building modules currently need the vmlinux as well?
Which would not be fullfiled anyway right now.

> > ## Installer packages will not longer contain too much version
> > 
> > The installer can only ever handle one version of kernel.  Also it got
> > an internal mechan

Re: Upcoming changes to Debian Linux kernel packages

[Bastian Blank]

Hi Andreas

On Sun, Sep 24, 2023 at 11:10:36PM +0200, Andreas Beckmann wrote:
> On 24/09/2023 15.01, Bastian Blank wrote:
> > ## Kernel modules will be signed with an ephemeral key
> > 
> > The modules will not longer be signed using the Secure Boot CA like the
> > EFI kernel image itself.  Instead a key will be created during the build
> > and thrown away after.
> 
> Do I correctly assume that change only affects the modules shipped by the
> linux-image packages and not third-party modules built with dkms?

Yes.  Nothing calls for changes to MOK keys, which are used by dkms.

> > ## Header and tool packages will not longer contain version
> 
> > This means that only headers of one single version can be available on
> > the system at one time.  This might be a bit inconvinient for dkms, as
> > it can't longer build modules for multiple versions.
> 
> That sounds problematic in case of third party modules. If it is possible to
> have multiple linux-image-* packages installed, but only headers for one of
> them, the third-party modules will only be available for one of the kernel
> versions for sure (maybe there are still old module builds available, but no
> guarantee especially after the third-party module got updated). This will
> make switching between different kernel versions difficult to impossible,
> e.g. it may be hard to go back to a working older kernel version in case the
> new one does not work properly (or the third-party module cannot be built or
> does not work for the new version).

Already built modules remain until someone deletes it.  So you can also
switch back to the still installed older kernel version and it will have
the still working module available.

Yes, you would not be able to build new modules for the older kernel
until you also install the matching headers.

> Regarding getting the correct linux-header-* packages installed for the
> installed linux-image-* packages:
> Maybe linux-image-* could have
>   Recommends: linux-headers-* | no-linux-headers
> s.t. the correct linux-headers-* are installed by default (installation of
> recommends is enabled by default) for all installed linux-image-* packages.
> no-linux-headers would be an opt-out package that can be installed manually
> if someone does not want to get linux-headers-* installed at all. It should
> never be installed automatically.

Nack.  I actually thought about that.  But third-party modules are too
much a special configuration to do that and pay the 50MiB or so penalty
for each system.  Also this still have the version skew problem between
linux and linux-signed-*, so will be unreliable.

> For dkms it is hard recommend the correct linux-header-* package, right now
> we have
>   Recommends: linux-headers-generic | linux-headers-686-pae |
> linux-headers-amd64 | linux-headers
> which does not really work for the non-default kernel flavor, e.g. the
> -cloud or -i386 kernel. So some improvement on the kernel side would be nice
> here.

I thought about adding a versioned provides with the complete kernel
release string as version, so something like
| Provides: linux-headers (= $(uname -r))

This can then be installed via apt-get and the correct version as long
as the package is available.  This however can't be done via
dependencies, because it is dynamic.  So dkms would need to actively
make sure it got the correct package, if they are still reachable at
all.

Bastian

-- 
We have found all life forms in the galaxy are capable of superior
development.
-- Kirk, "The Gamesters of Triskelion", stardate 3211.7

Upcoming changes to Debian Linux kernel packages

[Bastian Blank]

Hi folks

Debian currently does Secure Boot signing using a shim chained to the
Microsoft key.  This use requires that we follow certain rules.  And one
of the recent changes to those rules state that our method of signing
kernel modules also with the same key will not be allowed anymore.  Some
information are in #1040901.

We could just do the minimal change, sign the modules a different way
and let users walk into authenticated failures and other scary error
messages.  Or we could change the existing ABI setting on every upload,
creating a new set of binary packages.

But maybe we can enhance the user experience a bit, by reducing the
chance of scarry errors, but with the chance of simple errors like "you
need to reboot".  So let's do some more changes and hopefully don't
break the user experience too much.  The planned changes are discussed
in more detail.

## Kernel modules will be signed with an ephemeral key

The modules will not longer be signed using the Secure Boot CA like the
EFI kernel image itself.  Instead a key will be created during the build
and thrown away after.

Yes, this will make the build unreproducible, but no better solution
currently exists.  There are some plans, but no-one is working on them.
If a suitable replacement shows up, we can always switch to that
solution.

## Kernel release value includes complete Debian version

The kernel release is what "uname -r" shows, and how modules are
organized in /lib/modules.  This value will include the complete version
of the binary package, so even binNMU will somehow work.  This will make
sure the value changes with every upload and modules will not be
compatible already from that check.

Example: 6.5.3-2+b2-cloud-arm64

## Image packages contains more version info

By renaming the kernel packages we try to make several kernels
installable at the same time.  In contrast to rpm, where you can have
the same package installed multiple times in different versions, dpkg
only supports a single one at the same time.  So the co-installable
versions needs to have different package names.

The packages will include the full upstream version.  There exists the
exception of devel builds and uploads to experimental, wich will contain
even less of the version, to avoid new names in that cases.

Example: linux-image-6.5.3-cloud-arm64

There are some drawbacks.

The same upstream version in testing and backports will have the same
package name.  Multiple uploads of the same upstream version will have
the same package name, but those rarely happens.  Those packages will
not be compatible and a reboot is necessary to be able to load modules
again.

It will not longer be possible to reliably derive the package name from
kernel release (see above), as both values are not really related
anymore.

## Header and tool packages will not longer contain version

The headers packages will not longer include the version.  It won't be
reliably possible to derive the package name anyway from the running
kernel.

This means that only headers of one single version can be available on
the system at one time.  This might be a bit inconvinient for dkms, as
it can't longer build modules for multiple versions.

But we too often have the problem that image and headers go out of sync
and then you can't find the correct ones anyway.

Example: linux-headers-cloud-arm64

## Installer packages will not longer contain too much version

The installer can only ever handle one version of kernel.  Also it got
an internal mechanism to detect which packages belong together
(the Kernel-Version control entry).  So we have no need to rename them
and force a matching change in d-i itself just because a new kernel
exists.  So it will not longer contain the full version in the package
names if not needed.

## Further work

The changes outlined here try to avoid changes to the initramfs
protocol, aka /etc/kernel/.  There are larger change is cooking somehow,
see
https://lists.debian.org/msgid-search/y2gbkyerb10ky...@shell.thinkmo.de

Regards,
Bastian

-- 
You!  What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0

Re: Bug#1030939: e2fsprogs: generates filesystems that grub-install doesn't recognize

[Bastian Blank]

Hi

On Thu, Feb 09, 2023 at 03:16:15PM -0500, Theodore Ts'o wrote:
> Right, but if the conflict in e2fsprogs-udeb prevents the installer
> from pulling in an overly new version of e2fsprogs-udeb, that woul be
> sufficient, no?

No, it does not.  Conflicts have undefined behaviour for udebs.

Bastian

-- 
There are certain things men must do to remain men.
-- Kirk, "The Ultimate Computer", stardate 4929.4

Re: Total removal of floppy support?

[Bastian Blank]

Hi Cyril

On Wed, Jan 18, 2023 at 03:28:25PM +0100, Cyril Brulebois wrote:
> While working on extending firmware support, I've stumbled upon floppy
> support in various components. Even if the maintenance costs are low, I
> suppose this could go away nowadays?

It can completely go in the installer.  There is no useful way to use
floppies still.

The kernel needs to retain support for access floppy devices.  But even
it can't use floppies to boot.

Bastian

-- 
To live is always desirable.
-- Eleen the Capellan, "Friday's Child", stardate 3498.9

Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

[Bastian Blank]

On Thu, Dec 08, 2022 at 11:35:43AM +0100, Jan Kowalsky wrote:
> So: please set a default again which is reasonable for laptops and
> workstations. We always recommend debian for desktops to our customers.
> But if many things are not really suitable for Desktops people will
> avoid debian.

The current default is suitable.  Hibernation does not work on any
modern x86 machine and you don't want to have huge swap on desktop
machines as it only adds latency.

Bastian

-- 
Worlds are conquered, galaxies destroyed -- but a woman is always a woman.
-- Kirk, "The Conscience of the King", stardate 2818.9

Bug#1018740: debootstrap: better initialisisation of /etc/machine-id

[Bastian Blank]

On Mon, Aug 29, 2022 at 10:52:07PM +0200, Holger Levsen wrote:
> So probably it would be better to either remove the file or write 
> "uninitialized"
> into it... or support both via commandline flags :)

Actually debootstrap must write it as _empty_, to avoid running into
first boot setup.[1]  Only a tool who knows what comes next can actually
write "uninitialized" into it.

Bastian

[1]: https://www.freedesktop.org/software/systemd/man/machine-id.html
-- 
"We have the right to survive!"
"Not by killing others."
-- Deela and Kirk, "Wink of An Eye", stardate 5710.5

Re: s390-dasd: sbuild fails, when building on amd64 machine

[Bastian Blank]

On Sun, Aug 28, 2022 at 08:21:15PM +0200, Holger Wansing wrote:
> +STRIPTOOL=/usr/bin/s390x-linux-gnu-strip

This should use DEB_HOST_GNU_TYPE at least.  And not absolue path.

Bastian

-- 
Conquest is easy. Control is not.
-- Kirk, "Mirror, Mirror", stardate unknown

Re: debian-installer missing Standards-Version

[Bastian Blank]

On Wed, Mar 23, 2022 at 10:46:08AM +0100, John Paul Adrian Glaubitz wrote:
> Does anyone know whether this is by design or is this an oversight?

This is by design.  udeb don't follow policy.  So listing a policy
version is somewhat distracting.

Bastian

-- 
... The prejudices people feel about each other disappear when they get
to know each other.
-- Kirk, "Elaan of Troyius", stardate 4372.5

Bug#1000239: Rescue system won't find root partition, but insists on /usr

[Bastian Blank]

Control: severity -1 normal

On Fri, Dec 03, 2021 at 04:08:24PM -0500, Nicholas D Steeves wrote:
> Steps I used to try to reproduce:
> 
> 1. Downloaded debian-testing-amd64-netinst.iso2021-12-03 16:21 408M
> 2. Installed to EFI-enabled qemu eg:
>kvm -bios /usr/share/ovmf/bios.bin -m 2G \
>-hda debian-separate-usr-sda.raw \
>-cdrom debian-testing-amd64-netinst.iso
> 3. Guided partitioning with separate /home, then changed the mount point
>to /usr.  Partition layout is:
>   sda1: ESP  fat32
>   sda2: /ext4
>   sda3: swap swap
>   sda4: /usr ext4

/usr as separate partition is not provided as option.  So, why do you
select it?  Sorry, but pointing the gun at your foot and firing is not
the smartest idea.

Bastian

-- 
You!  What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0

Re: Naming convention for udebs: -udeb/-installer suffix

[Bastian Blank]

On Wed, Jan 13, 2021 at 03:49:40PM -0500, John Scott wrote:
> It's going to take a while for me to figure out how to incorporate it into 
> the 
> installer for Bookworm, but just because it's otherwise ready I'm thinking of 
> doing an upload of firmware-ath9k-htc adding a udeb.

We don't ship udebs for firmware.  So please discuss first how this
sould work

Bastian

-- 
There's a way out of any cage.
-- Captain Christopher Pike, "The Menagerie" ("The Cage"),
   stardate unknown.

Re: Bug#959037: lintian: FPOS? for executable-in-usr-lib

[Bastian Blank]

On Thu, Apr 30, 2020 at 11:41:44AM +0200, Bastian Blank wrote:
> The _other_ d-i parts are only looking in the specified directories in
> /usr/lib.

Okay, let's expand on this.

The following directories are part of the API of several d-i components:

- /usr/lib/post-base-installer.d/
- /usr/lib/pre-pkgsel.d/

The same is e.g. true for /usr/lib/apt/ (okay, maybe this was extended
to include /usr/libexec/apt/ as well in the meantime).

It is however irrelevant if this API is provided by a deb or udeb.  You,
as user of this API, can't just move a file from /usr/lib/x to
/usr/libexec/x and expect it to continue working.  This is an API
transition and needs to be coordinated.

I would assume this tag is in the pedantic pile for a reason:  You can't
just run, but need to think about it.

Bastian

-- 
If a man had a child who'd gone anti-social, killed perhaps, he'd still
tend to protect that child.
-- McCoy, "The Ultimate Computer", stardate 4731.3

Re: Bug#959037: lintian: FPOS? for executable-in-usr-lib

[Bastian Blank]

Hi Mattia

On Wed, Apr 29, 2020 at 06:40:07PM +0200, Mattia Rizzolo wrote:
> On Tue, Apr 28, 2020 at 11:38:44PM +0100, Steve McIntyre wrote:
> > ACK. d-i won't be looking in /usr/libexec. Please leave things where
> > they are...
> Good, then @lintian-maint: please exclude udebs from this check :)
> (as I think used to be in the past, since I don't think I saw this tag
> years ago in this package, but I know it has been there for a while…)

Why?  The tag is completely correct.

The _other_ d-i parts are only looking in the specified directories in
/usr/lib.

Bastian

-- 
But Captain -- the engines can't take this much longer!

Bug#949788: s390-dasd FTCBFS: strips with the build architecture strip

[Bastian Blank]

Moin

On Sat, Jan 25, 2020 at 05:50:40AM +0100, Helmut Grohne wrote:
> s390-dasd fails to cross build from source, because it strips using the
> build architecture strip during build. Beyond breaking cross
> compilation, this also breaks DEB_BUILD_OPTIONS=nostrip as well as
> generation of -dbgsym packages. It is best to defer all stripping to
> dh_strip. Please consider applying the attached patch.

This is the wrong fix.  Take a look at the Makefile.

Bastian

-- 
Time is fluid ... like a river with currents, eddies, backwash.
-- Spock, "The City on the Edge of Forever", stardate 3134.0

Bug#940801: missing virtio block Kernel Objects

[Bastian Blank]

On Thu, Sep 19, 2019 at 10:56:55PM +0200, Geert Stappers wrote:
> The netboot tarball misses virtio block drivers.
> This makes it unnessecary tiresome
> to install Debian VMs on not-Internet-connected server.

This is intentional.  netboot is for booting from _network_.  On the
network you got a distribution mirror, otherwise you have problems
installing Debian anyway.

Bastian

-- 
War isn't a good life, but it's life.
-- Kirk, "A Private Little War", stardate 4211.8

Re: D-I on riscv64 / new "u-boot-menu-installer" udeb

[Bastian Blank]

Hi Karsten

On Mon, Aug 19, 2019 at 08:36:58AM +0200, Karsten Merker wrote:
> - As the udeb only contains shell scripts, in conformance with
>   normal policy rules

Normal policy only applies pretty limited to udebs.

>   I have marked it as an arch:all package
>   that currently limits its execution to riscv64 with an
>   "isinstallable" file, i.e. it would potentially be pulled in
>   by other architectures as well, although only actually executed
>   on riscv64 for now.

This is broken for udebs.  See lilo-installer as an example.

> - I would like to move the git repository into the installer-team
>   namespace on salsa once the question above is answered and the
>   package can be uploaded to unstable.  Any objections to that?

All udeb only packages are maintained there.  Everything else might give
weird reponses by people.

Bastian

-- 
Men of peace usually are [brave].
-- Spock, "The Savage Curtain", stardate 5906.5

Re: Bug#930856: autopkgtest-build-qemu: captures something from host

[Bastian Blank]

On Sat, Jun 29, 2019 at 04:44:32PM +0200, Bastian Blank wrote:
> On Sat, Jun 29, 2019 at 02:25:55PM +, Dmitry Bogatov wrote:
> > Note that APT tries to use Devuan keyring to validate Debian release and
> > fail. How does `debootstrap' decides, which keyring to use?
> "dpkg -s debootstrap"?  How did that keyring get on the system in the
> first place?

Devuan includes a patched version of debootstrap.  See
https://pkginfo.devuan.org/stage/ascii/ascii/debootstrap_1.0.89+devuan2.1.html

Please show that you use an unpatched version on a system without a
Devuan key.

Bastian

-- 
Vulcans believe peace should not depend on force.
-- Amanda, "Journey to Babel", stardate 3842.3

Re: Bug#930856: autopkgtest-build-qemu: captures something from host

[Bastian Blank]

On Sat, Jun 29, 2019 at 02:25:55PM +, Dmitry Bogatov wrote:
> Note that APT tries to use Devuan keyring to validate Debian release and
> fail. How does `debootstrap' decides, which keyring to use?

"dpkg -s debootstrap"?  How did that keyring get on the system in the
first place?

Bastian

-- 
Violence in reality is quite different from theory.
-- Spock, "The Cloud Minders", stardate 5818.4

Bug#925545: busybox: please provide runscript file

[Bastian Blank]

Hi Dmitry

On Sat, Jun 15, 2019 at 06:37:03PM +, Dmitry Bogatov wrote:
> But, after all, we all volonteers here. So hereby I inform you,
> following advice in Developer reference, section 5.11, that I plan to
> do non-maintainer upload in two weeks or so.

As we are before a release, NACK.

Bastian

-- 
A little suffering is good for the soul.
-- Kirk, "The Corbomite Maneuver", stardate 1514.0

Bug#923091: That merged-usr is mandatory is RC

[Bastian Blank]

Control: severity -1 wishlist

Hi Ian

On Mon, May 13, 2019 at 11:22:35AM +0100, Ian Jackson wrote:
> In #923091, Guillem (with dpkg maintainer hat on) asks for a
> base-installer option to allow installing buster without merged-usr.

No, he did not mention dpkg.  But as always, please provide a patch and
answer kibi's questions.

Regards,
Bastian

-- 
First study the enemy.  Seek weakness.
-- Romulan Commander, "Balance of Terror", stardate 1709.2

Re: UEFI Secure Boot changes in d-i and live images

[Bastian Blank]

On Sun, Jan 20, 2019 at 12:35:16AM +, Ben Hutchings wrote:
> Yes, this is expected.  Does anyone want to implement the proposal I
> made at 
> or are we just going to have a flag day and hope no-one screws up after
> that?

The FTP team aggreed on this solution.[1]

Bastian

[1]: http://meetbot.debian.net/debian-ftp/2019/debian-ftp.2019-01-11-19.58.html
-- 
Power is danger.
-- The Centurion, "Balance of Terror", stardate 1709.2

NEW udeb: libcrypt1-udeb

[Bastian Blank]

Moin

Please ACK the NEW udeb: libcrypt1-udeb.

AFAIK it is supposed to replace the libcrypt integrated in glibc in the
future.

Regards,
Bastian

-- 
Where there's no emotion, there's no motive for violence.
-- Spock, "Dagger of the Mind", stardate 2715.1

Bug#911241: grub-installer - Remove grub-legacy support

[Bastian Blank]

Package: grub-installer
Version: 1.157

Please remove grub-legacy support.  I intend to request removal pretty
soon as it does not longer work.

Bastian

-- 
Behind every great man, there is a woman -- urging him on.
-- Harry Mudd, "I, Mudd", stardate 4513.3

Bug#907704: choose-mirror: default to deb.debian.org

[Bastian Blank]

Hi Philipp

On Tue, Sep 04, 2018 at 09:02:42AM +0200, Philipp Kern wrote:
> I pulled out my RT account to check for mirror-related problems (they
> seem to be in a different queue I can't see) and found [0], so it looks
> like there's now a third unannounced provider that is not in the
> rotation (yet?). Unfortunately it seems to be TLS-less as well.

This was my project, as you can see.  Due to the completely non-existant
communication from DSA side, I have no idea how to go forward.  Google
actually supports TLS, it is even enabled, but needs some help to get
certificates in.

People from mainland China reported that it works lot better then for
example Fastly.

> I also wonder if we actually have sensible escalation points to solve
> problems for the users and the bandwidth to do so. That concern is
> especially grave if we're going to auto-hide the question by default.
> Defaulting is something that makes sense to me.

Not really, from my experience in the past months.

Regards,
Bastian

-- 
The heart is not a logical organ.
-- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4

Bug#723966: installation-reports: /root directory deleted when re-installing

[Bastian Blank]

On Sat, Aug 18, 2018 at 06:52:26PM -0700, Paul Hardy wrote:
> Would it be possible to copy /root someplace temporarily during
> installation, for example to /home/root if /home is an available file
> system or even a RAM-based temporary file system (which won't help
> during a kernel panic)?  Then after /root is re-created, files could
> get copied back.

Sure, you can do copy that yourself.  You must not work as root, so
/root does not contain anything useful.

> Alternatively, if there are files in /root maybe a warning message
> could be printed.

The whole filesystem is not empty.  You asked it to create a new one.
Of cause it will do what you ask.

Bastian

-- 
Virtue is a relative term.
-- Spock, "Friday's Child", stardate 3499.1

Bug#905165: debootstrap - fails in docker environment

[Bastian Blank]

Package: debootstrap
Version: 1.0.106
Severity: grave

debootstrap fails in docker environment completely by:

- symlinking $TARGET/proc to /proc
- running chroot $TARGET mount -t proc none /proc

The later obviously failing with a recursive symlink:

| mount: mount proc on /proc failed: Too many levels of symbolic links

I have no idea what this detection is about, but if you are going to run
chroot, you have to also mount /proc.

Regards,
Bastian

-- 
We Klingons believe as you do -- the sick should die.  Only the strong
should live.
-- Kras, "Friday's Child", stardate 3497.2

Re: Archiving the attic folders from d-i for ports

[Bastian Blank]

On Sat, May 05, 2018 at 01:29:03PM +0200, John Paul Adrian Glaubitz wrote:
> (Please CC me, I'm not subscribed to debian-boot@ at the moment).

Mail-Followup-To exists and is both set and respected by decent MUA.

> On 04/27/2018 08:14 AM, Bastian Blank wrote:
> > On Fri, Apr 27, 2018 at 05:37:25AM +0200, John Paul Adrian Glaubitz wrote:
> >> Since there are still some repositories that we need for debian-ports
> >> in the attic, I was wondering whether we should take care of the
> >> attic stuff and move it over to salsa or github.
> > Could you show a list?  Just migrate them the same way.
> Basically everything from the attic:

I was only talking about the still needed ones.  linux-kernel-* is
clearly not and I doubt it have any practical value to look at.

Bastian

-- 
Too much of anything, even love, isn't necessarily a good thing.
-- Kirk, "The Trouble with Tribbles", stardate 4525.6

Re: Salsa

[Bastian Blank]

On Fri, May 04, 2018 at 02:08:40PM +0100, Steve McIntyre wrote:
> On Fri, May 04, 2018 at 10:44:00AM +0200, Bastian Blank wrote:
> >Does that mean you export all the old cruft from
> >/trunk/{build,kernel,tools,utils} to this new git repo?
> So far, yes. As I said, "For now, I've not filtered
> any branches or anything". If people are sure that this is junk and
> can be dropped, that's easily done.

I would assume only manual, packages/po and scripts have any value to
be preserved.  Everything else was already exported into different a
gazillion different git repos.

For .mrconfig the history is pretty pointless.

Bastian

-- 
A Vulcan can no sooner be disloyal than he can exist without breathing.
-- Kirk, "The Menagerie", stardate 3012.4

Re: Salsa

[Bastian Blank]

On Thu, May 03, 2018 at 10:10:28PM +0100, Steve McIntyre wrote:
> match /trunk/
>   repository d-i.git
>   branch master
> end match

Does that mean you export all the old cruft from
/trunk/{build,kernel,tools,utils} to this new git repo?

Bastian

-- 
Each kiss is as the first.
-- Miramanee, Kirk's wife, "The Paradise Syndrome",
   stardate 4842.6

Re: Archiving the attic folders from d-i for ports

[Bastian Blank]

On Fri, Apr 27, 2018 at 05:37:25AM +0200, John Paul Adrian Glaubitz wrote:
> Since there are still some repositories that we need for debian-ports
> in the attic, I was wondering whether we should take care of the
> attic stuff and move it over to salsa or github.

Could you show a list?  Just migrate them the same way.

>Still, I think we should
> archive everything.

The complete content of alioth is going to be archived, so this is
covered.

Bastian

-- 
We do not colonize.  We conquer.  We rule.  There is no other way for us.
-- Rojan, "By Any Other Name", stardate 4657.5

Re: Salsa

[Bastian Blank]

On Mon, Jan 22, 2018 at 06:52:01PM +0100, Christian PERRIER wrote:
> Quoting Cyril Brulebois (k...@debian.org):
> > If you have time/motivation to explore salsa.debian.org for d-i things,
> > that's more than welcome!
> > > Does anyone have any objection if I create a d-i/boot team on Salsa?
> > Not from me.
> I will then need to convert the last remaining SVN parts (mostly l10n
> stuff, which was never gitified.for lazyness reasons). 

Okay, that would be:
- the manual
- the package po files
- the scripts

> which means updates to the scripts that process them (l10n-sync).

Yeah.

Does it need changes if we just start to move the package repos to
salsa, apart from the authentication for the sync process?

Bastian

-- 
Conquest is easy. Control is not.
-- Kirk, "Mirror, Mirror", stardate unknown

Re: Salsa

[Bastian Blank]

On Sat, Jan 27, 2018 at 11:46:30AM +, Chris Boot wrote:
> I have added the following people to the project as members:
> { Alioth Role / Position } => { GitLab Role }
> Admin => Owner
> Senior Developer => Master
> Developer => Developer
> 
> I haven't added "Junior Developers" yet because I'm not convinced that
> GitLab has an equivalent. The next level down from Developer is
> Reporter. Shall I just add Junior Developers as Developers?

It always depends on what you think this people should be allowed to do.
On Alioth all where member of the d-i group and could do anything with
the git repositories.  On Salsa there are actually different permissions
to the repos attached.

> I also haven't added Translators. Should they also be Developers?
> Alternatively, we can create a sub-team for translators if finer-grained
> access to repos is required.

It may make sense to have sub-groups for such special topics.

> - I haven't made any attempt to add -guest users, even those who might
>   now be Debian Developers but who stuck with their -guest accounts on
>   Alioth.

We can now give out access to single repos.

> - I haven't been able to add the various DD (emeritus) people who are
>   still on the Alioth project, for hopefully obvious reasons.

This is by choice.  Disabled DD accounts are also blocked from Salsa.

Bastian

-- 
Beam me up, Scotty, there's no intelligent life down here!

Re: Salsa

[Bastian Blank]

On Thu, Jan 25, 2018 at 08:43:57PM +0100, Philip Hands wrote:
> 'installer-team' would be my top choice too (given that the -team bit
> seems to be necessary to accommodate the fact that gitlab uses the same
> namespace for teams and users).

It is possible to get different names, esp for teams who already have a
Debian user.

Bastian

-- 
Without facts, the decision cannot be made logically.  You must rely on
your human intuition.
-- Spock, "Assignment: Earth", stardate unknown

Re: Salsa

[Bastian Blank]

On Mon, Jan 22, 2018 at 05:28:43PM +0100, Cyril Brulebois wrote:
> Chris Boot  (2018-01-22):
> > I think it would be helpful to start using Salsa for some of our repos.
> > 
> > I would like to move my personal busybox work-in-progress repo to Salsa;
> > I know nothing prevents me from doing that but it feels like everything
> > would be more joined-up if the main busybox repo was also in Salsa and
> > in a debian-boot team/group.
> 
> If you have time/motivation to explore salsa.debian.org for d-i things,
> that's more than welcome!
> 
> > Does anyone have any objection if I create a d-i/boot team on Salsa?
> 
> Not from me.
> 
> > What should it be called?
> 
> Good question. d-i looks good to me, and would match the current group
> on alioth. debian-boot is historical and I think we should keep only
> the list named this way (along with IRC).

Or just use "installer-team".

> > Should its membership just be copied from the Alioth team?
> If possible, that would look good to me. Not sure about non-DD accounts
> support though (I've had too little time to keep track of salsa things,
> which seemed to be fast moving).

This just needs to be done by hand.

> Not necessary for busybox AFAICT, but we'll need to have that later when
> moving all repositories there: we need to have access for the l10n robot
> (including write access), working from dillon.debian.org these days.

What about the stuff still in SVN?

> > Alternatively, would it be preferable to use the "Debian" group given
> > we have such a large membership anyway?
> I'm not sure. ISTR having seen people mention on IRC that views weren't
> too practical when projects are under the Debian umbrella, because
> everything is listed altogether? Maybe a separate group would be best?

No, the Debian group is for single repositories, not such large lumbs.

Bastian

-- 
Captain's Log, star date 21:34.5...

Re: Avoiding use of symlinks in d-i archive tar

[Bastian Blank]

Moin

On Sat, Aug 05, 2017 at 03:15:51PM +0200, Bastian Blank wrote:
> On Sun, Jul 30, 2017 at 04:45:38PM +0200, Cyril Brulebois wrote:
> > Yeah. Feel free to propose patches for that then.
> Pushed as branch "waldi/dedup-links" to debian-installer.git.

Any more thoughts on this?

Bastian

-- 
Where there's no emotion, there's no motive for violence.
-- Spock, "Dagger of the Mind", stardate 2715.1

Bug#872867: is ISO-3166 really the optimal list for our users?

[Bastian Blank]

On Tue, Aug 22, 2017 at 12:28:18AM +0200, Daniel Pocock wrote:
> According to this section in the Debian Installer i18n guide[1], the
> list of countries is based on ISO3166.

Kosovo is listed in ISO3166 as RS-KM, see
https://www.iso.org/obp/ui/#iso:code:3166:RS 

However we don't list subdivisions.

> According to wikipedia, ISO3166 comes from a group of 10
> representatives[2] from mostly rich countries.

Most of them from countries actually reognizing Kosovo as independent,
so what?

> It may be interesting to support micronations like the Principality of
> Hutt River[5] too.

This one is not recognized by anyone.

Please let the peolpe of Kosovo speak for themselves.

Bastian

-- 
Actual war is a very messy business.  Very, very messy business.
-- Kirk, "A Taste of Armageddon", stardate 3193.0

Re: Avoiding use of symlinks in d-i archive tar

[Bastian Blank]

On Sun, Jul 30, 2017 at 04:45:38PM +0200, Cyril Brulebois wrote:
> Yeah. Feel free to propose patches for that then.

Pushed as branch "waldi/dedup-links" to debian-installer.git.

> > This symlink is handled by the archive anyway.
> OK; I would have thought so but I've never looked at implementation details.

I looked again and I was wrong.  However I'll change that.

Bastian

-- 
... bacteriological warfare ... hard to believe we were once foolish
enough to play around with that.
-- McCoy, "The Omega Glory", stardate unknown

Re: Avoiding use of symlinks in d-i archive tar

[Bastian Blank]

On Sun, Jul 30, 2017 at 03:54:59PM +0200, Cyril Brulebois wrote:
> Bastian Blank <wa...@debian.org> (2017-07-30):
> > Now there is exactly one other part in the archive that makes
> > excessive use of symlinks: the installer.
> > 
> > I would like to get rid of them within the installer.  Most users
> > don't see them anyway, as HTTP does not provide informations about
> > symlinks.
> 
> Are we talking about these in debian-installer-images tarball?
> 
>   installer-amd64/20170608/images/cdrom/xen/initrd.gz
>   installer-amd64/20170608/images/cdrom/xen/vmlinuz
>   
> installer-amd64/20170608/images/netboot/debian-installer/amd64/pxelinux.cfg/default
>   
> installer-amd64/20170608/images/netboot/gtk/debian-installer/amd64/pxelinux.cfg/default
>   installer-amd64/20170608/images/netboot/gtk/pxelinux.0
>   installer-amd64/20170608/images/netboot/gtk/pxelinux.cfg
>   installer-amd64/20170608/images/netboot/pxelinux.0
>   installer-amd64/20170608/images/netboot/pxelinux.cfg
>   installer-amd64/20170608/images/netboot/xen/initrd.gz
>   installer-amd64/20170608/images/netboot/xen/vmlinuz

These.  Another architectures have a lot more.

>   installer-amd64/current
> in which case I'm assuming the 'current' symlink needs to stay anyway?

This symlink is handled by the archive anyway.

> > They can remain in the installer debs.
> Do you mean dini binaries, like debian-installer-8-netboot-amd64?

Yes.

Bastian

-- 
Beam me up, Scotty!  It ate my phaser!

Avoiding use of symlinks in d-i archive tar

[Bastian Blank]

Moin

I recently did some changes to the Debian archive so that most
ressources that actually change are just symlinks.  This much more suits
the way rsync does it's work regarding symlinks and hardlinks.  In the
next step I want to change our mirror script to ignore symlinks in the
first sync stage to fix some more latent bugs.  This means that all
symlinks will be handled in the time sensitive part of the mirror sync.

Also there was a global deduplication step running on the main Debian
archive that hardlinked all identical files together.  It has been
disable due to it's implications it had on some parts of the archive.
So all deduplication needs to be done elsewhere.

Now there is exactly one other part in the archive that makes excessive
use of symlinks: the installer.

I would like to get rid of them within the installer.  Most users don't
see them anyway, as HTTP does not provide informations about symlinks.
They can remain in the installer debs.

Instead all identical files should be hardlinked.  This allows the
mirrors to only hold one copy of each.

Regards,
Bastian

-- 
Fascinating is a word I use for the unexpected.
-- Spock, "The Squire of Gothos", stardate 2124.5

Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

[Bastian Blank]

On Wed, Mar 01, 2017 at 02:25:12PM +0100, Julien Cristau wrote:
> Changing semantics of an existing struct member is classic ABI breakage.
>  This does very much need a SONAME bump.

Technically yes.  But this one is noe used uncontrolled outside.  So it
works without.

Bastian

-- 
Warp 7 -- It's a law we can live with.

Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

[Bastian Blank]

On Tue, Feb 28, 2017 at 10:00:01PM +, Steven Chamberlain wrote:
> That differs from the latest version of my patch, and from what I sent
> earlier today to the release team when asking about a potential unblock:
> https://lists.debian.org/debian-release/2017/02/msg01033.html

This happens if you send incomplete patches and do uncoordinated unblock
requests.

Bastian

-- 
Bones: "The man's DEAD, Jim!"

Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

[Bastian Blank]

On Sun, Feb 26, 2017 at 06:30:31PM +, Steven Chamberlain wrote:
> I've attached only the most minimal patch to allow reverse-depends do
> implement SHA256.  They must adapt to the new names of struct members
> *and* remember that the hash length is now different.  (The hash data is
> stored in variable-length fields but the length is not recorded in the
> structs, and the has is denoted by a magic number not an enum;  that
> could be made better, but requiring a much larger diff).

Adopted and commited to
https://anonscm.debian.org/git/d-i/libdebian-installer.git, branch
sha256

Bastian

-- 
Totally illogical, there was no chance.
-- Spock, "The Galileo Seven", stardate 2822.3

Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

[Bastian Blank]

On Tue, Feb 28, 2017 at 04:11:50AM +0100, Cyril Brulebois wrote:
> > (If we really wanted, we could maybe avoid the ABI bump:  no library
> > functions are being added/removed, only the name and meaning of a struct
> > member (a pointer, which remains the same length).  The
> > dynamically-sized buffer it points to, would change from storing an MD5
> > to a SHA256 hash, and would only cause a regression where something is
> > still trying to validate MD5).
> 
> Given the number of reverse dependencies, I doubt this is worth abusing
> md5 storage for sha256 things. Bumping the ABI seems reasonable to me,
> even if that's effectively starting a mini-transition from a release
> point of view.

On second thought, let's just do it without ABI name change.  For d-i
breaks don't work well, but if we update them en block this will not
show any breakage.  For the rest (exactl one user) breaks works fine.

Bastian

-- 
It would be illogical to assume that all conditions remain stable.
-- Spock, "The Enterprise Incident", stardate 5027.3

Bug#856210: libdebian-installer: please parse SHA256 field and add it to di_* structs

[Bastian Blank]

Hi Steven

On Sun, Feb 26, 2017 at 06:30:31PM +, Steven Chamberlain wrote:
> I've attached only the most minimal patch to allow reverse-depends do
> implement SHA256.  They must adapt to the new names of struct members
> *and* remember that the hash length is now different.  (The hash data is
> stored in variable-length fields but the length is not recorded in the
> structs, and the has is denoted by a magic number not an enum;  that
> could be made better, but requiring a much larger diff).

This change breaks the existing ABI and therefor needs an ABI bump, but
it is missing from the patch.

Regards,
Bastian

-- 
It is necessary to have purpose.
-- Alice #1, "I, Mudd", stardate 4513.3

ABI bump libdebian-installer

[Bastian Blank]

Hi folks

We finally need to do an ABI bump for libdebian-installer.  It currently
have hardcoded only support for md5 and I hacked in support for sha1
some years back.  This needs to be fixed finally, but will change so
core structures of the packages support.

Please speak up if there are problems with that.

Regards,
Bastian

-- 
You!  What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0

Re: own cloud task in tasksel?

[Bastian Blank]

On Wed, Mar 09, 2016 at 11:51:58PM +0900, Charles Plessy wrote:
> This reminds me #696154 ("Please install 'less' by default on official Debian
> AMIs.").  Basically, there is a tension between:

Also 'less' is already important, so it is supposed to be installed
somehow.

> Maybe this problem can be solved by the use of metapackages ?  With the
> exclusion of cloud-init, specialised kernels etc., can we converge on a
> metapackage that would represent the most frequent expectations of users of
> non-minimal cloud images in Debian and elsewhere ?

Thats what a task is, a meta-package.

Regards,
Bastian

-- 
I'm a soldier, not a diplomat.  I can only tell the truth.
-- Kirk, "Errand of Mercy", stardate 3198.9

Re: s390-zfcp: Not sure I want to send translators on this bunch of cryptic strings to translate

[Bastian Blank]

On Tue, Feb 09, 2016 at 07:22:19AM +0100, Christian PERRIER wrote:
> As a consequence, I'm highly tempted to mark all these strings as "non
> translatable". Indeed they are.

Just do it.

Bastian

-- 
Fascinating, a totally parochial attitude.
-- Spock, "Metamorphosis", stardate 3219.8

Bug#772657: ttf-cjk-compact: build-depends on ruby1.8

[Bastian Blank]

On Tue, Dec 09, 2014 at 09:16:50PM +0100, Ralf Treinen wrote:
 In fact, the jessie Sources file contains both 1.20 and 1.23. Which means 
 there is indeed no bug against ttf-cjk-compact.

It is marked with
| Extra-Source-Only: yes
So it is only there to fullfil source requirements with a Built-Using
declaration.

 However, this seems still strange to me. I know that sid may contain
 temporarily multiple versions of the same package, but I don't think
 that this is OK for testing.

Different problem.  Unstable can have binary packages of different
version on different architectures and the corresponding sources.

Bastian

-- 
First study the enemy.  Seek weakness.
-- Romulan Commander, Balance of Terror, stardate 1709.2


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141209214921.ga3...@mail.waldi.eu.org

Re: Bug#757985: kfreebsd: hang with ENOSPC after a few components are loaded

[Bastian Blank]

On Wed, Aug 20, 2014 at 01:19:52AM +0100, Steven Chamberlain wrote:
 On 14/08/14 18:15, Cyril Brulebois wrote:
  [...] If a
  single extra udeb (or udeb size increase, which happens from time to
  time) is going to break kfreebsd-*, it seems to me that their status
  is far too brittle.
 The fixed-size d-i initrds had to be carefully sized for kfreebsd wheezy.

Please move d-i to an unfixed size filesystem.  Even freebsd have some
sort of tmpfs.

 And/or we could maybe lose some unnecessary udebs.  I mentioned
 partman-iscsi as an example to start with (I also didn't understand
 how/why that was being included in the image at all?) but there are
 probably other and larger candidates.

Sorry, not in this stage of the Jessie development.

Bastian

-- 
Only a fool fights in a burning house.
-- Kank the Klingon, Day of the Dove, stardate unknown


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140820064719.ga10...@mail.waldi.eu.org

Bug#753442: debootstrap: host's /run/shm gets unmounted after debootstrap run

[Bastian Blank]

On Wed, Jul 02, 2014 at 12:10:15AM +0200, Daniel Reichelt wrote:
 I tried debootstrap on clean and current wheezy and jessie installations, only
 wheezy was affected.

This is due to systemd breakage.

Bastian

-- 
Without followers, evil cannot spread.
-- Spock, And The Children Shall Lead, stardate 5029.5


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140702150717.gb7...@mail.waldi.eu.org

Bug#728706: Debian-installer crashes on IA64 in HPVM (Integrity Virtual Machines)

[Bastian Blank]

Control: severity -1 important
Control: reassign -1 src:linux 3.2.46-1

On Mon, Nov 04, 2013 at 02:41:43PM +0100, Lennert Van Alboom wrote:
 Severity: grave

Not really, it is not broken for many people.

 Booting debian 7.x installer isos in an Integrity VM (virtualization on top of
 HP-UX/IA64) causes a guest crash after loading the initrd (the menu does work,
 and the crash happens regardless of selecting 'Install' or 'Expert'):

So the kernel crashes somewhere.  There is no real development for ia64
in Debian, so I'm not sure who can help.

 There is a 3911856 byte vm.core file which I presume is the dump mentioned in
 the console. 

Can you try if the crash util is able to read this?

Bastian

-- 
Spock: The odds of surviving another attack are 13562190123 to 1, Captain.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131104152506.gb15...@mail.waldi.eu.org

Bug#721869: install appropriate linux-headers

[Bastian Blank]

On Wed, Sep 04, 2013 at 05:03:46PM -0400, Joey Hess wrote:
 The CD images include linux-headers packages, but d-i does not install
 these by default.

Which distro does? A normal user does not need to build its own modules.
We also don't install a toolchain, aka build-essential.

Bastian

-- 
No one wants war.
-- Kirk, Errand of Mercy, stardate 3201.7


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130904224821.ga14...@mail.waldi.eu.org

Re: Plan of action for Secure Boot support

[Bastian Blank]

On Wed, Aug 14, 2013 at 12:30:55AM +0200, Ben Hutchings wrote:
 Editing of binary packages is icky, so that's not part of the plan.
 Instead, after dak signs an executable, the package maintainer downloads
 and copies those into a separate 'source' package, which has a trivial
 debian/rules.  (And of course will generate an appropriate 'Built-Using'
 header.)

This will most likely go via by-hand. So a script on the dak side is
needed anyway.

Why not do the dummy source package stuff in this script and let dak do
all the work semi-automatically? It needs a prepared binary tree in a
tar, a list of files to be signed and a DEBIAN dir.

Bastian

-- 
Landru! Guide us!
-- A Beta 3-oid, The Return of the Archons, stardate 3157.4


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130814094925.ga16...@mail.waldi.eu.org

Re: Using out of tree modules in d-i?

[Bastian Blank]

On Wed, May 22, 2013 at 05:16:39PM +0200, Turbo Fredriksson wrote:
 On May 22, 2013, at 3:52 PM, Ben Hutchings wrote:
  Also, there are questions as to whether it would be legal.
 Legal as in CDDL clashes with GPL you mean?

Binaries of ZFS linked against the Linux kernel would be licensed under
both CDDL and GPL-2. This _does_ _not_ _work_.

 I've heard that to. It would be nice to hear, once and for all
 if this is the case or not...

Please show that CDDL does not impose additional restrictions over
GPL-2.

Bastian

-- 
... bacteriological warfare ... hard to believe we were once foolish
enough to play around with that.
-- McCoy, The Omega Glory, stardate unknown


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130525201221.ga...@mail.waldi.eu.org

Bug#703146: Better debootstrap InRelease handling fix

[Bastian Blank]

On Wed, Mar 27, 2013 at 12:53:44AM +0100, Bernhard R. Link wrote:
 Sorry, but this is not enough to properly extract the contents of a
 inline signed message. You still need to do possible unescaping between
 those lines.

Is the unescaping part necessary for InRelease files? What are the rules
for this?

Bastian

-- 
Another Armenia, Belgium ... the weak innocents who always seem to be
located on a natural invasion route.
-- Kirk, Errand of Mercy, stardate 3198.4


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130327092948.ga16...@waldi.eu.org

Bug#703979: Available person to review/pull my fix for #703979?

[Bastian Blank]

On Tue, Mar 26, 2013 at 06:46:12PM -0300, Ben Armstrong wrote:
 git clone http://syn.theti.ca/git/debian-installer-launcher.git
 gitweb: http://syn.theti.ca/gitweb/?p=debian-installer-launcher.git

This does one change to restrict rm to one filesyste. The second,
replace umount -f with umount -l, is a no-op after that.

Please fix this completely, with something like:
- mount -t tmpfs none /lib/live/installer
- umount /lib/live/installer

Bastian

-- 
I object to intellect without discipline;  I object to power without
constructive purpose.
-- Spock, The Squire of Gothos, stardate 2124.5


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130326233018.gb9...@waldi.eu.org

Bug#686502: pxz produces archives broken for busybox's unxz

[Bastian Blank]

On Sat, Dec 22, 2012 at 12:03:31AM +0100, Abou Al Montacir wrote:
 --- busybox-1.20.0/debian/patches/fix-unxz-with-multiple-streams.patch
 1970-01-01 01:00:00.0 +0100
 +++ busybox-1.20.0/debian/patches/fix-unxz-with-multiple-streams.patch
 2012-12-21 19:23:12.0 +0100
 @@ -0,0 +1,25 @@
 +Author: Abou Al Montacir abou.almonta...@sfr.fr
 +Purpose: Fix decompression of multi stream XZ compressed files
 + (Closes: bug#686502)
 +
 +--- busybox-1.20.0~/archival/libarchive/decompress_unxz.c2012-12-20 
 21:51:04.0 +0100
  busybox-1.20.0/archival/libarchive/decompress_unxz.c 2012-12-20 
 21:49:11.0 +0100
 +@@ -87,7 +87,17 @@ unpack_xz_stream(transformer_aux_data_t *aux, int src_fd, 
 int dst_fd)
 + iobuf.out_pos = 0;
 + }
 + if (r == XZ_STREAM_END) {
 +-break;
 ++if (iobuf.in_pos != iobuf.in_size) {
 ++// Initialize decoder for new stream
 ++xz_dec_end(state);
 ++state = xz_dec_init(XZ_DYNALLOC, 64*1024*1024);

Why can't you use the existing call somewhere at the beginning? If I
remember correctly, you need 128*1024*1024 to decompress all valid
files.

 ++// Eat padding
 ++while (iobuf.in[iobuf.in_pos] == 0){
 ++iobuf.in_pos += 1;
 ++}

Padding is a multiple of _four_ bytes. Did you read the spec?

 ++}
 ++// Look for other streams
 ++continue;

Does it bail out if there is no new stream?

Bastian

-- 
Men will always be men -- no matter where they are.
-- Harry Mudd, Mudd's Women, stardate 1329.8


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130106203959.ga12...@waldi.eu.org

Bug#686502: pxz produces archives broken for busybox's unxz

[Bastian Blank]

On Sun, Jan 06, 2013 at 09:40:00PM +0100, Bastian Blank wrote:

This was the wrong mail.

Bastian

-- 
Oblivion together does not frighten me, beloved.
-- Thalassa (in Anne Mulhall's body), Return to Tomorrow,
   stardate 4770.3.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130106222618.ga14...@waldi.eu.org

Bug#686502: pxz produces archives broken for busybox's unxz

[Bastian Blank]

On Thu, Dec 27, 2012 at 10:08:07PM +0100, Abou Al Montacir wrote:
 + if (r == XZ_STREAM_END) {
 + /* Eat padding. Stream never starts with zeros, and 
 padding is 32 aligned */
 + while ((iobuf.in_pos  iobuf.in_size)  
 (iobuf.in[iobuf.in_pos] == 0)) {
 + iobuf.in_pos += 1;
 + }
 + /* Reached end of buffer. Fill it again from stream */
 + if (iobuf.in_pos == iobuf.in_size) {
 + continue;
 + }
 + if(iobuf.in_pos % 4){

Are you sure this is correct? in_pos is the position in tht buffer, not
the file. Also look out for coding style.

 + if (r == XZ_STREAM_END) {

Again the same check?

   if (r == XZ_STREAM_END) {
 - break;
 + xz_dec_end(state);
 + /* Look for any other streams */
 + continue;

Why do you have three XZ_STREAM_END checks in this state machine?

Bastian

-- 
There are always alternatives.
-- Spock, The Galileo Seven, stardate 2822.3


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130106223213.gb14...@waldi.eu.org

Bug#686502: pxz produces archives broken for busybox's unxz

[Bastian Blank]

On Fri, Dec 21, 2012 at 02:06:31PM +0100, Abou Al Montacir wrote:
 On Thu, 2012-12-20 at 23:08 +0100, Bastian Blank wrote:
  On Thu, Dec 20, 2012 at 10:42:41PM +0100, Abou Al Montacir wrote:
   Can you please test the attached patch
  How does it implement stream padding?
 As it is implemented, it will iterate until end of stream, but I did not
 test this particular case.

I ask you how it implements a mandantory feature and you are not able to
tell me?

 If you can provide an example of files on which it will fail, I can try
 to fix it.

Add stream padding as specified in the spec.

Bastian

-- 
There's a way out of any cage.
-- Captain Christopher Pike, The Menagerie (The Cage),
   stardate unknown.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121221132405.ga23...@waldi.eu.org

Bug#686502: pxz produces archives broken for busybox's unxz

[Bastian Blank]

On Thu, Dec 20, 2012 at 12:22:12PM +0400, Michael Tokarev wrote:
 This is a grave bug in busybox.  Grave because it causes silent
 data loss - valid (according to the format specs) input is
 decompressed only partially.

The documentation say: SHOULD support files that have more than one
Stream or Stream padding. Please note the should. So missing support is
no bug on its own, but it should at least check that there is no
trailing garbage.

Bastian

-- 
What terrible way to die.
There are no good ways.
-- Sulu and Kirk, That Which Survives, stardate unknown


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121220113037.ga27...@waldi.eu.org

Bug#686502: pxz produces archives broken for busybox's unxz

[Bastian Blank]

On Thu, Dec 20, 2012 at 10:42:41PM +0100, Abou Al Montacir wrote:
 Can you please test the attached patch

How does it implement stream padding?

Bastian

-- 
What kind of love is that?  Not to be loved; never to have shown love.
-- Commissioner Nancy Hedford, Metamorphosis,
   stardate 3219.8


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121220220835.ga5...@waldi.eu.org

Re: packages matching running kernel 3.2.0-3-amd64 in archive

[Bastian Blank]

On Sat, Nov 10, 2012 at 02:11:31PM +0100, Geert Stappers wrote:
 How to fix the version mismatch in the Debian archive?

Don't use the netboot image. A D-I update is necessary to fix this.

Bastian

-- 
No one wants war.
-- Kirk, Errand of Mercy, stardate 3201.7


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121110140609.ga17...@waldi.eu.org

Re: [PATCH 3/3] install-files: Include modules.{builtin,order} in Linux kernel-image udebs

[Bastian Blank]

On Tue, Sep 25, 2012 at 02:07:16AM +0100, Ben Hutchings wrote:
 libkmod expects these files to be present.  However they are not
 being installed in the s390 tape image packages, so this probably
 should be made conditional.  That might be a bug in the linux package
 though.  Bastian?

This is intentional. The s390 dasd and s390 tape images share the ABI.
So there are no modules built for the later.

Bastian

-- 
Klingon phaser attack from front!
100% Damage to life support


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120925075458.ga18...@wavehammer.waldi.eu.org

Re: IPv6 support in d-i

[Bastian Blank]

On Sat, Sep 08, 2012 at 11:05:55AM +0200, Michelle Konzack wrote:
 Am 2012-09-08 00:19:54, hacktest Du folgendes herunter:
 Hey, I have since some weeks my own GE access in Kehl/Germany and am not
 able to get any additional IPv4 adresses from RIPE.   I Have to  use  my
 assigned IPv6 block!

This is properly documented by RIPE and have been for a long time.

 I have only 256 IPv4 addresses, which I have to  use  for  my  customers
 Wireless (BreezeACCESS VL) and FTTH (Iskratel SI3000) access. Which kind
 crap is this, that not a singel customer can access the  Internet  if  I
 assign dem to a IPv6 instead of IPv4?  If I use my T42 with  Debian,  it
 works properly...  So it seems to be a Windoes thing or the used Routers

You missed several years of development. Things like DS-lite are
properly specified and supported by the vendors.

 But I can not get a IPv6 capable mirror.  I have tried http.debian.net
 without success.

You can use DNS64/NAT64 to access IPv4 destinations, you will need to
make this possible for some years anyway.

 Is there a known IPv6 aware Debian Mirror?

ftp.uni-stuttgart.de

 Note:   Du to my ISP infrastructure, DHCP does not work for security
 reason and I have to use definitively my from RIPE  assigned
 IPv6 block.

IPv6 for endusers without static assignments needs DHCPv6-PD.

Bastian

-- 
I'm a soldier, not a diplomat.  I can only tell the truth.
-- Kirk, Errand of Mercy, stardate 3198.9


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120908092101.ga31...@wavehammer.waldi.eu.org

Re: IPv6 support in d-i

[Bastian Blank]

On Sat, Sep 08, 2012 at 04:54:54PM +0200, Bjørn Mork wrote:
 where 2001:db8::/96 is the prefix you've allocated for your NAT64
 service. Using a /96 is recommended as it makes things very simple when
 the IPv4 addresses just fits at the end.

You may want to use the well-known prefix 64:ff9b::/96.

 And DNS64 can run on any server. You just need to delegate the IPv6
 NAT64 prefix reverse to it, and point all IPv6 clients there as well.

It needs to run on the recursive resolver.

Bastian

-- 
I'm a soldier, not a diplomat.  I can only tell the truth.
-- Kirk, Errand of Mercy, stardate 3198.9


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120908155450.ga2...@wavehammer.waldi.eu.org

Re: EFI approach and patches

[Bastian Blank]

On Mon, Aug 13, 2012 at 01:10:31AM +0100, Steve McIntyre wrote:
 1. Add a new subarch of efi for i386 and amd64 in
libdebian-installer, worked out (as usual for EFI) from whether
/sys/firmware/efi is accessible. This filters through readily to
archdetect, used all over the place elsewhere in d-i.

This needs efivars loaded AFAIK. I'm not yet familiar with the EFI part
of the Linux kernel.

 2. Build efi-reader for amd64 as well as ia64. Not sure if this
provides anything important, but it doesn't hurt. :-)

This is needed for what?

 3. Build elilo-installer for amd64 too, and mark it as installable for
i386/efi|amd64/efi.

Does elilo provide 32 and 64-bit efi binaries? All the current machines
need 64-bit binaries.

 4. Mark grub-installer as not installable for i386/efi|amd64/efi

No.

 5. Mark lilo-installer as not installable for i386/efi|amd64/efi

Okay.

 6. Several tweaks to partman-auto:
   * Switch from fat16 to fat32 in ia64 recipes

Why?

   The first of these needs testing - is EFI on ia64 *definitely* ok
   with fat32, or must it have fat16? I've also upped the size of the
   EFI partition to 512MB, a more sensible minimum in case of multiple
   OS installs. I cloned tha ia64 recipes, then the diff shows the
   changes since. Not 100% sure of the best approach for partman-auto,
   I'll admit here. Thoughts?

It works fine with FAT16, however grub needs the partition properly
alligned.

 8. partman-partitioning: for amd64/efi and i386/efi, use gpt instead
of msdos

Nope. EFI works fine with msdos.

 +/* Are we on an EFI system? Check to see if /sys/firmware/efi
 + * exists */
 +static int is_efi(void)
 +{
 +   int ret = access(/sys/firmware/efi, R_OK);
 +if (ret == 0)
 +   return 1;
 +else
 +   return 0;
 +}

Whitespace damage.

Bastian


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120813101547.ga18...@wavehammer.waldi.eu.org

Re: Byte queue limits in Linux for wheezy / linux kernel ABI bumps

[Bastian Blank]

On Sun, Aug 05, 2012 at 07:43:50PM +0200, Bastian Blank wrote:
 On Sat, Aug 04, 2012 at 10:06:48PM +0100, Ben Hutchings wrote:
  A possible solution would be something like:
  1. Keep multiple versions of udebs in the same suite (currently possible
  for arch:all, but maybe not supported for arch-dependent packages)
 Breaks the expectations within d-i. This is listed on my TODO.
  4. Make anna try older package versions if dependencies can't be reolved
  for the newest version
 Versions in dependencies will be ignored.

The packages stuff used in d-i is limited. It only allows one version of
a package, which produced problems with cdebootstrap. In addition it
disallows several other constructs: Breaks, Conflicts and ignores all
versions in relations.

I have the problem with multiple version on my list for a larger
rewrite, which will make it need more memory. It can't be fixed in a
backward compatible way.

Bastian

-- 
The sight of death frightens them [Earthers].
-- Kras the Klingon, Friday's Child, stardate 3497.2


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120813104949.ga19...@wavehammer.waldi.eu.org

Re: [SCM] d-i libdebian-installer repository branch, master, updated. 0.79-8-g4ac8107

[Bastian Blank]

On Mon, Aug 06, 2012 at 02:04:08PM +0100, Ian Campbell wrote:
 Yes, I normally would, don't know how I missed it this time. I'll go fix
 it up now.

dch should do this by itself in the meantime. Otherwise add
DEBCHANGE_RELEASE_HEURISTIC=changelog
to ~/.devscripts.

Bastian

-- 
Each kiss is as the first.
-- Miramanee, Kirk's wife, The Paradise Syndrome,
   stardate 4842.6


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120806132549.ga18...@wavehammer.waldi.eu.org

Re: Byte queue limits in Linux for wheezy / linux kernel ABI bumps

[Bastian Blank]

On Sat, Aug 04, 2012 at 10:06:48PM +0100, Ben Hutchings wrote:
 A possible solution would be something like:
 1. Keep multiple versions of udebs in the same suite (currently possible
 for arch:all, but maybe not supported for arch-dependent packages)

Breaks the expectations within d-i. This is listed on my TODO.

 2. Make kernel-wedge add versioned dependencies to the udebs
 4. Make anna try older package versions if dependencies can't be reolved
 for the newest version

Versions in dependencies will be ignored.

Bastian

-- 
Intuition, however illogical, is recognized as a command prerogative.
-- Kirk, Obsession, stardate 3620.7


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120805174350.ga30...@wavehammer.waldi.eu.org

Re: Thank you so much for breaking d-i!

[Bastian Blank]

On Sun, Jul 15, 2012 at 03:05:17PM +0200, Marco d'Itri wrote:
 WTF are you talking about? We switched from module-init-tools to kmod 
 months ago, and the last time I discussed d-i and modules with 
 debian-boot people my understanding was that modules are now loaded by 
 busybox.

Can you provide the number of the bugreport requesting removal of the
udeb? However, why is there a udeb called libkmod2-udeb then?

 module-init-tools is not coming back, if d-i still needs something from 
 kmod then just let me know without getting crazy for no reason.

http://hermes.jura.uni-tuebingen.de/~blank/debian/kmod.diff

Bastian

-- 
Where there's no emotion, there's no motive for violence.
-- Spock, Dagger of the Mind, stardate 2715.1


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120715131625.ga31...@wavehammer.waldi.eu.org

Re: Bug#680900: flash-kernel: support for local overrides of db settings

[Bastian Blank]

On Mon, Jul 09, 2012 at 01:47:18AM +0100, Ian Campbell wrote:
 As discussed in #667681 it would be very useful to be able to override certain
 per-machine settings locally. For example Boot-Device defaults to /dev/sda1 on
 Dreamplug but can also be sdb1 depending on local configuration.

Use /dev/disk/* for such definitions. /dev/sdX is _not_ stable.

Bastian

-- 
You can't evaluate a man by logic alone.
-- McCoy, I, Mudd, stardate 4513.3


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120709113917.gc16...@wavehammer.waldi.eu.org

Bug#482092: partman-crypto: xts support

[Bastian Blank]

On Sat, Jun 23, 2012 at 03:11:00PM +0200, Bastian Blank wrote:
 We only want to support plain64 for Wheezy.
 There is. You need at least 256 bit (128 for encryption, 128 for XTS).

I commited support for xts-plain64 to partman-crypto. It will just
double the key size used for xts, so no additional checking is
necessary.

Maybe someone wants to check them before I'll upload it.

Bastian

-- 
Only a fool fights in a burning house.
-- Kank the Klingon, Day of the Dove, stardate unknown



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120709133747.ga2...@wavehammer.waldi.eu.org

Re: CD sizes again (and BoF reminder!)

[Bastian Blank]

On Fri, Jul 06, 2012 at 10:10:04PM +0100, Steve McIntyre wrote:
   http://cdimage.debian.org/cdimage/tmp/new-tasks/gnome-cd.list.gz

Why does this contain debug packages?

Bastian

-- 
I've already got a female to worry about.  Her name is the Enterprise.
-- Kirk, The Corbomite Maneuver, stardate 1514.0


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120707131015.ga25...@wavehammer.waldi.eu.org

Re: CD sizes again (and BoF reminder!)

[Bastian Blank]

On Sat, Jul 07, 2012 at 02:34:44PM +0100, Steve McIntyre wrote:
 The list posted there is the full sorted list of *all* packages, as
 applied to the full set of CDs. The last one on CD#1 is
 gnome-packagekit-data, as I said, and I don't see any debug packages
 above that in the list.

Ups, I did the wrong check.

Anyway, some remarks:
- aptitude: can be downgraded from standard
- gcc-4.[56]-base
- python2.6: 2.7 is already there
- loop-aes-utils: loop-aes is not supported
- grub-legacy
- build-essential, linux-kbuild-3.2, kernel-package: development stuff
- module-assistant: deprecated for dkms
- localepurge
- pump

This is all before X.

Bastian

-- 
Insults are effective only where emotion is present.
-- Spock, Who Mourns for Adonais?  stardate 3468.1


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120707141409.gb25...@wavehammer.waldi.eu.org

Bug#482092: partman-crypto: xts support

[Bastian Blank]

On Sat, Jun 23, 2012 at 12:15:36PM +0200, Philipp Kern wrote:
 So there's nothing special about key sizes with xts as stated basically at the
 top of the bug report? 

There is. You need at least 256 bit (128 for encryption, 128 for XTS).

 Also I guess one should support xts-plain64 too? Is there any value in 
 offering
 xts-plain at this point, shouldn't we go to 64bit sector numbers directly?
 Upstream even says that there's no performance penalty.

We only want to support plain64 for Wheezy.

Bastian

-- 
That unit is a woman.
A mass of conflicting impulses.
-- Spock and Nomad, The Changeling, stardate 3541.9



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120623131100.gb15...@wavehammer.waldi.eu.org

Re: tasksel upload

[Bastian Blank]

On Thu, Jun 14, 2012 at 02:48:14PM -0400, Joey Hess wrote:
 Bastian Blank wrote:
  Is there anything that speaks against an upload of tasksel? It works
  fine in my tests.
 This heuristic is just asking for trouble.
 # Exclude packages starting with lib
 $package !~ /^lib/ 

Yeah. I asked the ftp team to fix some sections, so this is gone.

Bastian

-- 
Those who hate and fight must stop themselves -- otherwise it is not stopped.
-- Spock, Day of the Dove, stardate unknown


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120615083218.ga17...@wavehammer.waldi.eu.org

tasksel upload

[Bastian Blank]

Hi

Is there anything that speaks against an upload of tasksel? It works
fine in my tests.

Okay, #676777 in debhelper needs to be fixed also.

Bastian

-- 
No one wants war.
-- Kirk, Errand of Mercy, stardate 3201.7


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120613125349.ga...@wavehammer.waldi.eu.org

tasksel todo

[Bastian Blank]

Hi

This is some sort of tasksel todo.

Remove tasksel-data
===
tasksel-data was introduced to help derivates change it. However most of
the information is now installed as packages and more should come. Also
tasksel and tasksel-data currently have a recursive dependency. So this
is not gonna work without changes to tasksel anyway.

My proposal is to move all missing information to the packages. The
task packages should be moved to a different source package, so tasksel
only provides the scripts and the tasks can be easily replaced without
medling with tasksel themself.

Task dependencies
=
Tasks currently don't depend on each other. For example I can install
task-german-desktop without task-desktop. tasksel have some internal
logic to resolve this, but I think this should be also enforced on the
package level.

Base localization task
==
util-linux-locales is currently included in some languages but not in
others. Such packages should move into it's own base task.

Different dictionaries
==
Currently we may install four different dictionaries:
- hunspell
- aspell
- w*
- i*
Sometimes hunspell is included in the desktop task, sometimes in the
base local task.

Fonts
=
hungarian-desktop for example _depends_ on a large amount of fonts. None
of them hungarian specific.

Bastian

-- 
Spock: The odds of surviving another attack are 13562190123 to 1, Captain.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120611092314.ga7...@wavehammer.waldi.eu.org

Bug#674060: Doesn't support reading InRelease files

[Bastian Blank]

On Fri, May 25, 2012 at 11:01:57AM +0200, Mehdi Dogguy wrote:
 index 67aa412..0b0f802 100644
 --- a/src/parser_rfc822.c
 +++ b/src/parser_rfc822.c
 @@ -60,6 +60,7 @@ int di_parser_rfc822_read (char *begin, size_t size, 
 di_parser_info *info, di_pa
di_rstring field_modifier_string;
di_rstring value_string;
void *act = NULL;
 +  int pgp_mode = 0;
  
cur = begin;
end = begin + size;
 @@ -81,6 +82,25 @@ int di_parser_rfc822_read (char *begin, size_t size, 
 di_parser_info *info, di_pa
  
  while (1)
  {
 +  if (!strncmp(cur, -BEGIN PGP SIGNED MESSAGE-, 34))

Please don't use magic numbers.
| const char pgp_begin = …;
| if (!strncmp(cur, pgp_begin, strlen(pgp_begin))
or something like that. The strlen call should be optimized away.

Also this string may only appear at the beginning of the file, not
somewhere in between. So this should be done before the large loop.
Also the end of the preamble can be searched with \n\n.

 +  else if (pgp_mode  !strncmp(cur, -BEGIN PGP SIGNATURE-, 
 29))
 +  {
 +// Let's exit, the rest of the file is not interesting
 +cur += size;
 +break;
 +  }

Okay.

Bastian

-- 
The best diplomat I know is a fully activated phaser bank.
-- Scotty



--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120531101729.ga2...@wavehammer.waldi.eu.org

Re: installer location on mirrors

[Bastian Blank]

On Sat, May 19, 2012 at 10:24:17PM +0200, Joerg Jaspert wrote:
 I also take it we don't need/want the main/contrib/non-free in
 installer/, as our d-i will always be main/ only.

What about firmware stuff?

Bastian

-- 
One does not thank logic.
-- Sarek, Journey to Babel, stardate 3842.4


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120521154824.ga8...@wavehammer.waldi.eu.org

Bug#670993: busybox: Please use dpkg-buildflags for hardening support

[Bastian Blank]

On Mon, Apr 30, 2012 at 11:00:38PM -0700, Steve Langasek wrote:
 On Tue, May 01, 2012 at 09:53:14AM +0400, Michael Tokarev wrote:
  Why do you filter this -W option?
 Well, it causes a build failure if you don't. ;)  I inherited this from the
 previous Ubuntu changes, so I haven't fully reviewed the reason for this
 change but I believe they're all in the category of things that are safe but
 that gcc can't prove are safe.

Is there a patch forwarded to busybox upstream to fix the problems?

Bastian

-- 
Vulcans do not approve of violence.
-- Spock, Journey to Babel, stardate 3842.4



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120502123930.ga22...@wavehammer.waldi.eu.org

Bug#666399: s390-dasd fails to work with 20 devices visible (mostly in LPAR mode)

[Bastian Blank]

On Fri, Mar 30, 2012 at 02:52:58PM +0200, Philipp Kern wrote:
 I'm not sure about the rationale for this.

s390 system can have hundreds or thousands of DASD devices. With the
text frontend it is simply impossible to display such a long list, with
slang it is just not pretty. So this code should ask for the device id
instead of showing a list.

Bastian

-- 
It would seem that evil retreats when forcibly confronted.
-- Yarnek of Excalbia, The Savage Curtain, stardate 5906.5



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120404073250.ga10...@wavehammer.waldi.eu.org

Re: libstdc++6-udeb package (Re: RFC: auto-load of D-I drivers in GNU/kFreeBSD)

[Bastian Blank]

On Sun, Mar 11, 2012 at 08:07:46PM +0100, Robert Millan wrote:
 El 5 de març de 2012 21:51, Robert Millan r...@debian.org ha escrit:
  1- Add libstdc++6-udeb package (needed by devd).
 Oh, I wasn't aware that libstdc++ udeb had already been proposed, and
 it seems to be a controversial topic...

Reducing libstdc++ with mklibs is tricky, so only the unreduced lib can
be included into the boot image. C++ is controversial, because the
output is usually rather large.

Bastian

-- 
Klingon phaser attack from front!
100% Damage to life support


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120311202753.ga20...@wavehammer.waldi.eu.org

Re: libstdc++6-udeb package (Re: RFC: auto-load of D-I drivers in GNU/kFreeBSD)

[Bastian Blank]

On Sun, Mar 11, 2012 at 05:37:35PM -0300, Otavio Salvador wrote:
 On Sun, Mar 11, 2012 at 17:27, Bastian Blank wa...@debian.org wrote:
  Reducing libstdc++ with mklibs is tricky, so only the unreduced lib can
  be included into the boot image. C++ is controversial, because the
  output is usually rather large.
 IIRC you stared working on a reduced stdc++ library, didn't you?

I used it for some years with the tuxbox project. But it needs patches
to gcc.

Bastian

-- 
We'll pivot at warp 2 and bring all tubes to bear, Mr. Sulu!


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120311212140.ga21...@wavehammer.waldi.eu.org

Re: #657560: apt: ...i18n_Translation-en Encountered a section with no Package: header

[Bastian Blank]

On Thu, Mar 01, 2012 at 03:35:51PM +0100, Didier 'OdyX' Raboud wrote:
 a) gracefully fallback on short translations when it fails to
 uncompress/parse the Translation packages;

Do we need the full translations anyway?

Bastian

-- 
You!  What PLANET is this!
-- McCoy, The City on the Edge of Forever, stardate 3134.0


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120301145231.gc3...@wavehammer.waldi.eu.org

Re: #657560: apt: ...i18n_Translation-en Encountered a section with no Package: header

[Bastian Blank]

On Thu, Mar 01, 2012 at 08:24:10PM +0100, Didier Raboud wrote:
 Bastian Blank wrote:
  Do we need the full translations anyway?
 Good point. Is it possible to instruct `apt-get update` to avoid downloading 
 the Translation-en.bz2 long descriptions file (from my understanding of 
 `man apt.conf`, no.) ?

| Acquire::Languages none;

Bastian

-- 
Even historians fail to learn from history -- they repeat the same mistakes.
-- John Gill, Patterns of Force, stardate 2534.7


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120301194026.ga10...@wavehammer.waldi.eu.org