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.
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.
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.
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.
Control: user debian-alpha@lists.debian.org Control: usertags alpha 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
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.
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:
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
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.
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. 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.
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
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.
"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. cu Adrian
Le mercredi 18 janvier à 18h 54mn 10s (+0100), Santiago Vila a écrit : 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
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
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
Hi, Here is an updated set of patches. I haven't tested with schroot on amd64, nor to boot a real alpha workstation - and I'm afraid it won't happen very soon. I hope it will help nevertheless ! Regards, JH Chatenet
Hi JH, Due to the large list of patches, reviewing these patches will take some time, so I can't give you immediate feedback. I'll start with the review process next week and also give those patches a test on real hardware. We should also upstream as many patches as possible so that Gentoo and other interested distributions will profit from these improvements as well. PS: Do you mind using your full name for the git commit messages? Thanks a lot, Adrian