Bug#774196: Sparc netboot building broken
Package: live-build
Version: 4.0.4-1
There are one or more issues with the code in the
installer_debian-installer script where it obtains vmlinuz and initrd
files for sparc netboot builds.
Issue #1 - Wrong path
------------------------------
On line 290, it uses the path ${URL}/mini.iso, where ${URL} is of the
pattern {MIRROR}/dists/{DIST}/main/installer-{ARCH}/current/images/.
The correct path is actually
{MIRROR}/dists/{DIST}/main/installer-{ARCH}/current/images/netboot/
(i.e. ${URL}/netboot/mini.iso).
Issue #2 - No GTK copy
-------------------------------
For all other builds, a GTK copy is also downloaded, but not here.
Perhaps it wasn't available previously, or isn't actually useful, but
one does exist (netboot/gtk/mini.iso) and should perhaps be retrieved.
Issue #3 - Use of mini.iso
---------------------------------
Lines 288-289 claim that there are no prepared kernel/initrd pairs for
this build, and so downloads and unpacks a 'mini.iso' file instead.
Currently there do appear to be unpacked copies of these files available
on the mirrors, within the following paths. I am not certain whether
things have changed since that code was written, or whether these files
are not suitable in some way, but I'd assume the former.
{MIRROR}/dists/{DIST}/main/installer-{ARCH}/current/images/netboot/debian-installer/{ARCH}/linux
{MIRROR}/dists/{DIST}/main/installer-{ARCH}/current/images/netboot/debian-installer/{ARCH}/initrd.gz
{MIRROR}/dists/{DIST}/main/installer-{ARCH}/current/images/netboot/gtk/debian-installer/{ARCH}/linux
{MIRROR}/dists/{DIST}/main/installer-{ARCH}/current/images/netboot/gtk/debian-installer/{ARCH}/initrd.gz
If these files are used, with the exception of the awkward kernel file
name ("linux"), this build case could actually be handled without the
special branching of lines 286-299.
Solution
--------------
I am very close to a complete solution for bug 718225, which will be
significantly modifying lines such as these, and therefore creates a bit
of a conflict. Ideally I'd like to avoid forcing maintainer to have to
manually merge separate work for these two bugs.
Issue #1 will end up getting fixed in my bug 718225 solution one way or
another. My solution, being fairly large will actually be offered up as
a small set of patches. To keep proper record of this fix, I will likely
address issue #1 here as its own commit, within the set for my 718225
solution.
The other issues, I could leave to be resolved later, or I could just as
easily address them in the same commit. I guess it largely hinges on
whether issues #2 and #3 are acceptible to get into jessie (which I hope
my 718225 solution will). Maintainer, do you have a preference?
Reply to: