Debian Bug report logs - #805988
aboot: FTBFS on amd64 when built with dpkg-buildpackage -A

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@debian.org>

To: Debian BTS <submit@bugs.debian.org>

Subject: aboot: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

Date: Tue, 24 Nov 2015 15:24:26 +0000

Package: src:aboot
Version: 1.0~pre20040408-4
User: sanvila@debian.org
Usertags: binary-indep
Severity: important

Dear maintainer:

I tried to build this package with "dpkg-buildpackage -A"
(i.e. only architecture-independent packages), and it failed:

--------------------------------------------------------------------------------
[...]
 fakeroot debian/rules binary-indep
dh binary-indep
   dh_testroot -i
   dh_prep -i
   dh_installdirs -i
   debian/rules override_dh_auto_install
make[1]: Entering directory '/<<PKGBUILDDIR>>'
install -m 755 tools/isomarkboot debian/aboot-cross/usr/bin
install -m 755 srmbootfat/srmbootfat debian/aboot-cross/usr/bin
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
   dh_install -i
   dh_installdocs -i
cp: cannot stat 'doc/faq/SRM-HOWTO': No such file or directory
dh_installdocs: cp --reflink=auto -a doc/faq/SRM-HOWTO debian/aboot-base/usr/share/doc/aboot-base returned exit code 1
debian/rules:28: recipe for target 'binary-indep' failed
make: *** [binary-indep] Error 2
dpkg-buildpackage: error: fakeroot debian/rules binary-indep gave error exit status 2
--------------------------------------------------------------------------------

Sorry not to have a fix, as I am reporting many bugs similar to
this one, but I can give some general hints:

* If all the arch-independent packages are dummy transitional packages
released with jessie, the easy fix is to drop them now.
 
* If not, debian/rules should be modified so that the binary-indep
target works in all cases, even when binary-arch is not used (this is
what the "Architecture: all" autobuilder does). For that:
    
* If you are using debhelper, you might want to use options -a and -i
for dh_* commands so that they do not act on packages they do not
have to act.

* Also, if you are using dh, the (independently) optional targets
override_dh_foo-arch and override_dh_foo-indep (for several values
of "foo") may be useful to write a debian/rules which behaves exactly
as desired.


After checking that both "dpkg-buildpackage -A" and "dpkg-buildpackage -B"
work properly, this package will be suitable to be uploaded in
source-only form if you wish (you might want to try it).

Thanks.

Message #10 received at 805988@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: 805988@bugs.debian.org, Debian BTS <control@bugs.debian.org>

Cc: Steve Langasek <vorlon@debian.org>

Subject: Re: Bug#805988: aboot: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

Date: Sun, 17 Apr 2016 20:44:41 +0200 (CEST)

retitle 805988 aboot: FTBFS on amd64 when built with dpkg-buildpackage -A
tags 805988 + help
thanks

Apparently (see Bug #821332), I would need somebody having an alpha to
check that "dpkg-buildpackage -A" works.

Can someone check this? (The package is very small so it should not take
a long time to build).

If the package may only be built on alpha, it would not make sense to
have it in my list to eheck for "dpkg-buildpackage -A".

Thanks.

Message #19 received at 805988@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: Steve Langasek <vorlon@debian.org>, 805988@bugs.debian.org

Subject: Re: Bug#805988: aboot: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

Date: Mon, 23 May 2016 13:21:21 +0200 (CEST)

Hi.

I see that the "Architecture: all" package which may not be built on amd64
is really a "trick" to build the package on alpha and have its contents
to be automatically available on other architectures.

So: Could not we use "multiarch" for that?

We already use multiarch to make i386 libraries available to amd64 users.
Is this case very different?

Thanks.

Message #24 received at 805988@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@debian.org>

To: 805988@bugs.debian.org

Subject: aboot: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

Date: Thu, 14 Jul 2016 22:08:43 +0000

Greetings.

I have the ok from the Release Managers to consider this issue as RC
for stretch. I'm going to wait at least one week before raising
this to "serious".

If you need help to fix this bug, please tag it as "help".

Thanks.

Message #33 received at 805988@bugs.debian.org (full text, mbox, reply):

From: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

To: Santiago Vila <sanvila@unex.es>

Cc: Steve Langasek <vorlon@debian.org>, 805988@bugs.debian.org, debian-alpha@lists.debian.org

Subject: Re: Bug#805988: aboot: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

Date: Sun, 8 Jan 2017 16:38:36 +0100

Control: user debian-alpha@lists.debian.org
Control: usertags alpha

> Apparently (see Bug #821332), I would need somebody having an alpha to
> check that "dpkg-buildpackage -A" works.

I can actually do that, I have access to an alpha porterbox. However, you
can also actually do it yourself by setting up a qemu-based alpha chroot,
similar to this [1].

In any case, I'm adding debian-alpha@l.d.o to the discussion as the alpha
porters should actually be put in the loop here.

Adrian

> [1] https://wiki.debian.org/SH4/sbuildQEMU

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Message #38 received at 805988@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>

Cc: Steve Langasek <vorlon@debian.org>, 805988@bugs.debian.org, debian-alpha@lists.debian.org

Subject: Re: Bug#805988: aboot: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

Date: Sun, 8 Jan 2017 16:43:50 +0100

On Sun, Jan 08, 2017 at 04:38:36PM +0100, John Paul Adrian Glaubitz wrote:
> Control: user debian-alpha@lists.debian.org
> Control: usertags alpha
> 
> > Apparently (see Bug #821332), I would need somebody having an alpha to
> > check that "dpkg-buildpackage -A" works.
> 
> I can actually do that, I have access to an alpha porterbox. However, you
> can also actually do it yourself by setting up a qemu-based alpha chroot,
> similar to this [1].
> 
> In any case, I'm adding debian-alpha@l.d.o to the discussion as the alpha
> porters should actually be put in the loop here.

Even if "dpkg-buildpackage -A" works on alpha, that could be not enough.

Our Arch:all autobuilder runs amd64, not alpha.

What I would do here is to convert the package to a pure Arch:any or
Arch:alpha package, without Arch:all tricks to distribute the files
to other architectures. IMO, those who really need the files
outside an alpha machine will figure out how to get them.

Thanks.

Message #43 received at 805988@bugs.debian.org (full text, mbox, reply):

From: jhcha54008 <jhcha54008@free.fr>

To: 805988@bugs.debian.org, debian-alpha@lists.debian.org, Santiago Vila <sanvila@debian.org>

Subject: aboot : dpkg-buildpackage -A on amd64

Date: Wed, 11 Jan 2017 00:07:54 +0100

Hi,

I was able to build aboot-base on amd64 without error (but with a lot of
warnings) with the patch below and the two patches [1], [2] of #832491.

The package built is not very useful as there are no binary files bootlx,
net_aboot.nh and net_pad inside (#821332)

I hope it will help nevertheless !

Regards,
JH Chatenet

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832491#5
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832491#23

diff -Naur aboot-1.0~pre20040408/debian/rules aboot-1.0~pre20040408/debian/rules
--- aboot-1.0~pre20040408/debian/rules
+++ aboot-1.0~pre20040408/debian/rules
@@ -42,6 +42,7 @@
 	$(MAKE) -C srmbootfat srmbootfat srmbootfat.1 CC=$(CC) $(shell dpkg-buildflags --export=configure)
 	$(MAKE) -C doc/man isomarkboot.1
 	$(MAKE) -C doc/man/de isomarkboot.de.1 srmbootfat.de.1
+	$(MAKE) -C doc/faq
 endif
 
 override_dh_auto_clean:

Message #48 received at 805988@bugs.debian.org (full text, mbox, reply):

From: jhcha54008 <jhcha54008@free.fr>

To: 805988@bugs.debian.org, debian-alpha@lists.debian.org, Santiago Vila <sanvila@debian.org>

Subject: aboot : dpkg-buildpackage -A on alpha

Date: Wed, 11 Jan 2017 00:27:00 +0100

[Message part 1 (text/plain, inline)]

Hi,

On an alpha worstation

dpkg-buildpackage -A

does indeed build aboot-base with bootlx, net_aboot.nh and net_pad in.
(I didn't test them to boot from a CD-ROM or tftp though)

A first try (first.script attached) failed because of #832491 and a missing doc/faq in debian/rules.
A second one (second.script attached) was successful thanks three patches [1].

How could we keep a working bootloader for our alpha workstations ?

Regards,
JH Chatenet

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805988#43

[first.script (text/plain, attachment)]

[second.script.gz (application/gzip, attachment)]

Message #53 received at 805988@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: jhcha54008 <jhcha54008@free.fr>

Cc: 805988@bugs.debian.org, debian-alpha@lists.debian.org

Subject: Re: aboot : dpkg-buildpackage -A on alpha

Date: Wed, 11 Jan 2017 00:29:54 +0100

On Wed, Jan 11, 2017 at 12:27:00AM +0100, jhcha54008 wrote:

> How could we keep a working bootloader for our alpha workstations ?

Can you figure out what changes would be required in the package so
that the Arch:all package becomes really Arch:alpha?

I would start by modifying debian/control to read like this:

Package: aboot-base
Architecture: alpha

then debian/rules may need some adjustment, but I can't test that.

I think that would be the orthodox thing to do for a package which is
really alpha-specific.

The Arch:all thing I admit that it's a clever trick, but it is against
the release goal (or current setup, depending on how you look at it)
that every Arch:all package must be buildable in the Arch:all
autobuilder (which runs amd64).

Thanks.

Message #58 received at 805988@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Santiago Vila <sanvila@unex.es>, 805988@bugs.debian.org

Cc: jhcha54008 <jhcha54008@free.fr>, debian-alpha@lists.debian.org

Subject: Re: Bug#805988: aboot : dpkg-buildpackage -A on alpha

Date: Thu, 12 Jan 2017 01:50:21 +0200

[Message part 1 (text/plain, inline)]

On Wed, Jan 11, 2017 at 12:29:54AM +0100, Santiago Vila wrote:
> On Wed, Jan 11, 2017 at 12:27:00AM +0100, jhcha54008 wrote:

> > How could we keep a working bootloader for our alpha workstations ?

> Can you figure out what changes would be required in the package so
> that the Arch:all package becomes really Arch:alpha?

> I would start by modifying debian/control to read like this:

> Package: aboot-base
> Architecture: alpha

> then debian/rules may need some adjustment, but I can't test that.

> I think that would be the orthodox thing to do for a package which is
> really alpha-specific.

But then the package containing the bootloader-bits-as-data would not be
available to people running on !alpha architectures for purposes of building
installer images.

> The Arch:all thing I admit that it's a clever trick, but it is against
> the release goal (or current setup, depending on how you look at it)
> that every Arch:all package must be buildable in the Arch:all
> autobuilder (which runs amd64).

Well, alpha hasn't been a release architecture for quite some time, so I
don't think that's the most important thing, either.

But it's possible that a better option nowadays would be to use the
gcc-alpha-linux-gnu cross-compiler package.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #63 received at 805988@bugs.debian.org (full text, mbox, reply):

From: jhcha54008 <jhcha54008@free.fr>

To: 805988@bugs.debian.org

Cc: Santiago Vila <sanvila@debian.org>

Subject: Bug#805988: aboot : include the binaries in source to build on amd64

Date: Wed, 18 Jan 2017 18:38:44 +0100

[Message part 1 (text/plain, inline)]

Hi,

I wonder if the following solution would be accepted (see the two patches 
attached) : let the source package ship the two binaries (bootlx and 
net_aboot.nh). One can build aboot-base on amd64 then.
The two binaries are generated from source if the source package is
built on alpha.
(The inspiration came from Helge Deller's palo package on hppa)

I tested so far that dpkg-buildpackage -B builds aboot (on alpha)
and aboot-cross (on amd64),
and that dpkg-builpackage -A builds aboot-base (on both).

A bootable CD including a just compiled bootlx indeed booted an XP1000 
alpha workstation.

I hope it will help !

Regards,
JH Chatenet

[01-build-depends-on-sp.patch (text/x-diff, attachment)]

[02-bootlx-in-source.patch (text/x-diff, attachment)]

Message #68 received at 805988@bugs.debian.org (full text, mbox, reply):

From: Santiago Vila <sanvila@unex.es>

To: jhcha54008 <jhcha54008@free.fr>

Cc: 805988@bugs.debian.org

Subject: Re: Bug#805988: aboot : include the binaries in source to build on amd64

Date: Wed, 18 Jan 2017 18:54:10 +0100

On Wed, Jan 18, 2017 at 06:38:44PM +0100, jhcha54008 wrote:

> I wonder if the following solution would be accepted (see the two patches 
> attached) : let the source package ship the two binaries (bootlx and 
> net_aboot.nh). [...]

Hmm, but this is like removing a hack and creating another one in another place.

The previous package was a "fake" Arch:all package, so to speak, and now
we would have a "fake" source package, as it would include binaries.

We don't want binaries inside source packages (and I think ftpmasters
would surely agree on this).

If alpha is not a release architecture, would it really be a problem
to remove this from testing before the release of stretch while we keep it in
unstable?

We could meet the release goal of all packages being buildable
in our Arch:all autobuilder that way without causing a major headache
to users of alpha.

Alternatively, there is also the possibility of asking the Release
Managers for permission to use stretch-ignore here.

Thanks.

Message #73 received at 805988@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@debian.org>

To: Santiago Vila <sanvila@unex.es>, 805988@bugs.debian.org

Cc: jhcha54008 <jhcha54008@free.fr>

Subject: Re: Bug#805988: aboot : include the binaries in source to build on amd64

Date: Wed, 18 Jan 2017 21:40:29 +0200

On Wed, Jan 18, 2017 at 06:54:10PM +0100, Santiago Vila wrote:
> On Wed, Jan 18, 2017 at 06:38:44PM +0100, jhcha54008 wrote:
> 
> > I wonder if the following solution would be accepted (see the two patches 
> > attached) : let the source package ship the two binaries (bootlx and 
> > net_aboot.nh). [...]
> 
> Hmm, but this is like removing a hack and creating another one in another place.
> 
> The previous package was a "fake" Arch:all package, so to speak, and now
> we would have a "fake" source package, as it would include binaries.
> 
> We don't want binaries inside source packages (and I think ftpmasters
> would surely agree on this).
> 
> If alpha is not a release architecture, would it really be a problem
> to remove this from testing before the release of stretch while we keep it in
> unstable?
> 
> We could meet the release goal of all packages being buildable
> in our Arch:all autobuilder that way without causing a major headache
> to users of alpha.
> 
> Alternatively, there is also the possibility of asking the Release
> Managers for permission to use stretch-ignore here.

"Arch:all autobuilder" is only part of the problem, since alpha won't be 
part of stretch there is no option to build this package on *any* machine
running stretch.

Looks like a clear GPL violation to me.

As Steve already suggested, using the gcc-alpha-linux-gnu package might 
be an option for building aboot.

I'll open a similar bug against palo.

> Thanks.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Message #78 received at 805988@bugs.debian.org (full text, mbox, reply):

From: jhcha54008 <jhcha54008@free.fr>

To: Santiago Vila <sanvila@unex.es>

Cc: Adrian Bunk <bunk@debian.org>, 805988@bugs.debian.org, debian-alpha@lists.debian.org

Subject: Re: Bug#805988: aboot : cross-compile aboot-base

Date: Thu, 26 Jan 2017 22:31:24 +0100

[Message part 1 (text/plain, inline)]

Le mercredi 18 janvier à 18h 54mn 10s (+0100), Santiago Vila a écrit :
> On Wed, Jan 18, 2017 at 06:38:44PM +0100, jhcha54008 wrote:
> 
> > I wonder if the following solution would be accepted (see the two patches 
> > attached) : let the source package ship the two binaries (bootlx and 
> > net_aboot.nh). [...]
> 
> Hmm, but this is like removing a hack and creating another one in another place.
> 
> The previous package was a "fake" Arch:all package, so to speak, and now
> we would have a "fake" source package, as it would include binaries.
> 
> We don't want binaries inside source packages (and I think ftpmasters
> would surely agree on this).
> 
> If alpha is not a release architecture, would it really be a problem
> to remove this from testing before the release of stretch while we keep it in
> unstable?
> 
> We could meet the release goal of all packages being buildable
> in our Arch:all autobuilder that way without causing a major headache
> to users of alpha.
> 
> Alternatively, there is also the possibility of asking the Release
> Managers for permission to use stretch-ignore here.
> 
> Thanks.

Hi, 

I was able to build aboot-base on amd64 with the two attached patches.
(dpkg-buildpackage -A -uc -us builds successfully on amd64, i386 and alpha)
I have tested the resulting package to boot a real alpha workstation
(both CDROM- and TFTP-boot).

A build-dependency on gcc-alpha-linux-gnu was added.
Three (possibly different) compilers are needed :
1. a native one to compile helpers which are run during the build
2. one to generate Alpha code to build aboot-base (and possibly aboot)
3. one to generate $DEB_HOST_ARCH code to build aboot-cross
debian/rules sets variables for each.

Cross-building the alpha specific aboot binary package on amd64
requires some manual tweaking :
* libc6.1:alpha is needed when dh_shlibdeps is run, and is currently
(Version: 2.24-5) not co-installable (libc6:amd64 is Version: 2.24-9)
* opensp:alpha is flagged as a missing build-dependency (opensp is 
Arch: any and not Multi-Arch). It is currently uninstallable because
libc6.1:alpha is.
As a workaround, one may enable the alpha architecture
(dpkg --add-architecture alpha), unpack (and not install)
libc6.1:alpha and run dpkg-buildpackage -a alpha -d

I hope it will help to find an acceptable solution !

Regards,
JH Chatenet

[01-build-depends-on-opensp.patch (text/x-diff, attachment)]

[02-support-cross-compilation.patch (text/x-diff, attachment)]

Message #83 received at 805988@bugs.debian.org (full text, mbox, reply):

From: jhcha54008 <jhcha54008@free.fr>

To: 805988@bugs.debian.org

Subject: Re: Bug#805988: aboot : cross-compile aboot-base

Date: Fri, 27 Jan 2017 18:42:02 +0100

I am unsure : shouldn't the build dependencies
gcc-alpha-linux-gnu [!alpha], libc6.1-dev-alpha-cross [!alpha]
appear in a field
Build-Depends-Indep
instead of
Build-Depends ?

They are required to build aboot-base (Arch: all)
and not aboot-cross (Arch: any).

Regards,
JH Chatenet

Message #88 received at 805988@bugs.debian.org (full text, mbox, reply):

From: jhcha54008 <jhcha54008@free.fr>

To: 805988@bugs.debian.org

Subject: Re: Bug#805988: aboot : cross-compile aboot-base

Date: Tue, 7 Feb 2017 23:32:41 +0100

Hi,

I wish to correct my preceding patch 02-support-cross-compilation.patch [1] : 
I should have written
	CC = $(DEB_HOST_GNU_TYPE)-gcc
instead of
	CC ?= $(DEB_HOST_GNU_TYPE)-gcc
in debian/rules.
(At this point, CC is already defined as "cc" (its default value))

Regards,
JH Chatenet

[1] : https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=805988;filename=02-support-cross-compilation.patch;msg=78

Send a report that this bug log contains spam.