Ubuntu

FTBFS

Reported by Reinhard Tartler on 2006-10-07
34
This bug affects 2 people
Affects Status Importance Assigned to Milestone
openhackware (Debian)
Won't Fix
Unknown
openhackware (Ubuntu)
High
Unassigned

Bug Description

This package fails to build from source:
https://launchpad.net/+builds/+build/207108

This package only works on ppc as it contains ppc assembler code. The
architecture field in debian/control should therefor be

Architecture: powerpc

Cheers,

Peter (p2).

package openhackware
severity 322300 normal
retitle 322300 openhackware: should not try to build on !powerpc environments
thanks

On Wed, Aug 10, 2005 at 09:22:17AM +0200, Reinhard Tartler wrote:
> Package: openhackware
> Version: 0.4.1-1
> Severity: Serious

> I tried to build openhackware on i386 (well, actually on amd64 inside a
> chroot), but did not succeed. I attached the build log.

Yes, it does not build because as Peter explained it's ppc specific
code, and needs a ppc build environment.

On Wed, Aug 10, 2005, Peter 'p2' De Schrijver wrote:
> This package only works on ppc as it contains ppc assembler code. The
> architecture field in debian/control should therefor be
>
> Architecture: powerpc

No, it's code that can be used by emulators like qemu, that's why
it's an all package, there's existing practice for this, and the
problem comes from a deficiency in the source format, that does
not allow to specify that an all package needs a specific building
environment (or arch).

The only thing I can do is fail gracefully with a message if the
environment, be it native or a cross toolchain, is not the
apropropriate.

regards,
guillem

Hi,

> No, it's code that can be used by emulators like qemu, that's why
> it's an all package, there's existing practice for this, and the

No. The emulator is still a ppc processor (albeit a software
implementation of it). The Architecture: field specifies the cpu
architecture(s) for which binaries have to be generated, which is
only powerpc in this case. Otherwise we could just as well have no
Architecture: field. Afterall qemu can also emulate an i386 processor, so
you can always run the i386 binary, no matter what architecture you're
using.

> problem comes from a deficiency in the source format, that does
> not allow to specify that an all package needs a specific building
> environment (or arch).
>

No. The problem is that cross compiling is not covered by debian yet.
The solution is to make debian cross compiler aware, not to hack around
the problem by declaring every package Architecture: all.

> The only thing I can do is fail gracefully with a message if the
> environment, be it native or a cross toolchain, is not the
> apropropriate.

That defeats the purpose of build dependencies. The whole idea of having
build dependencies is that the buildds know what's required to build a
package instead of just trying and see what happens.

Cheers,

Peter (p2).

package openhackware
severity 339870 normal
retitle 339870 openhackware: should not try to build on !powerpc environments
merge 339870 322300
thanks

On Sat, Nov 19, 2005 at 01:55:43PM +0100, Roland Stigge wrote:
> Package: openhackware
> Version: 0.4.1-1
> Severity: serious

> building the package openhackware in a clean sid build environment
> (with pbuilder) on i386 results in:

It's supposed to only be buildable on a ppc environment, be it native
or crosscompiled. The problem is that right now we don't have a clear
way to specify this kind of build requirement.

What I can do is ask for an addition to Packages-arch-specific so that
buildd (using P-a-s should not try this package if not on ppc), and
then add checks to the package itself to bail out sooner and give a
proper error message.

regards,
guillem

# The package doesn't build on the Architecture (all) it it declared for
severity 339870 serious
thanks

Hi,

Guillem Jover wrote:
>>building the package openhackware in a clean sid build environment
>>(with pbuilder) on i386 results in:
>
>
> It's supposed to only be buildable on a ppc environment, be it native
> or crosscompiled. The problem is that right now we don't have a clear
> way to specify this kind of build requirement.

As p2 explained, the package is clearly "Architecture: powerpc". The
current "Architecture: all" is definitely broken.

bye,
  Roland

severity 339870 normal
thanks

Hi,

On Sat, Nov 19, 2005 at 06:01:39PM +0100, Roland Stigge wrote:
> # The package doesn't build on the Architecture (all) it it declared for
> Guillem Jover wrote:
> > > building the package openhackware in a clean sid build environment
> > > (with pbuilder) on i386 results in:

> > It's supposed to only be buildable on a ppc environment, be it native
> > or crosscompiled. The problem is that right now we don't have a clear
> > way to specify this kind of build requirement.

> As p2 explained, the package is clearly "Architecture: powerpc". The
> current "Architecture: all" is definitely broken.

Well and as I've said, I disagree. After requesting it, openhwackware
is now on Packages-arch-specific, so if you want to build arch:all
packages configure your build daemon properly. I'll close this bug
once I add a note on when building on the wrong environment.

regards,
guillem

Reinhard Tartler (siretart) wrote :

This package fails to build from source:
https://launchpad.net/+builds/+build/207108

Changed in openhackware:
importance: Undecided → Critical
status: Unconfirmed → Confirmed
Reinhard Tartler (siretart) wrote :

The problem is that the openhackware package expects ppc hardware to build.

Changed in openhackware:
status: Unknown → Unconfirmed
Andrew Ash (ash211) wrote :

So is it impossible for openhackware to compile if it's not on ppc hardware? That seems unreasonable.

Reinhard Tartler (siretart) wrote :

well, that's it. The debian maintainer does not seem willing or able to fix the bug. I talked to fabionne about this, and he promised me to talk to elmo about this problem to get this problem resolved for dapper. Nothing happend since then, and I lost this bug out of the mind as well, so this is mainly my fault for not having kept an eye on this.

I'm now subscribing the archive administrators for further input for this bug. Perhaps they have some idea how to get this package built in ubuntu?

Tollef Fog Heen (tfheen) wrote :

Just fix the compilation parameters to make it compile. This has nothing to do with ubuntu-archive; unsubscribing them.

Reinhard Tartler (siretart) wrote :

subscribing infinity. Here releavant irc snippets (from #ubuntu-devel)

22:02:56 < siretart> Mithrandir: the problem seems to be that the package only builds on ppc
22:03:09 < siretart> Mithrandir: and binary:all packages are built on i386 only in ubuntu
22:03:30 < Mithrandir> siretart: how is that something ubuntu-archive can change?
22:03:50 < siretart> Mithrandir: I'm seeking for input on how to solve this issue
22:04:02 < Mithrandir> siretart: fix CFLAGS to not include -mregnames?
22:04:32 < siretart> which breaks compilation
22:04:43 < Mithrandir> uh?
22:05:05 < siretart> it needs an ppc assembler
22:05:29 < siretart> cross compilation would be an option, but nobody is working on that. in debian, the problem doesn't exist
22:05:46 < siretart> since binary uploads are possible there
22:06:13 < Mithrandir> at least for now, yes. *shrug*; it needs to be fixed to cross-compile in Ubuntu or something then.
22:07:20 < siretart> err, we are talking about firmware, which qemu needs to boot emulated ppc systems
22:07:35 < siretart> requiring the firmware to be cross compiled seems a bit awkward to me :/
22:08:16 < siretart> hm. I could perhaps compile it on ppc, include it uuencoded, and just unpack it in the package
22:08:35 < siretart> but *that's* really nasty :/
22:09:10 < sistpoty> siretart: yep, that's nasty, but I guess it's the best option... have been doing this for mit-scheme
22:09:14 < Mithrandir> hm, indeed.
22:09:34 < Mithrandir> siretart: you could talk to Adam about it and see if he can do a manual build on a ppc box.
22:10:15 < siretart> Mithrandir: we could indeed upload ppc binaries to the archive?
22:10:33 < siretart> hm. okay, I'll subscribe him then

Reinhard Tartler (siretart) wrote :

I'm subscribing this bug to Adam Conrad for now as suggested by Tollef. Adam, feel free to unassign this bug from yourself if you feel there is nothing you can do about this.

I'm mainly doing this because of lack of feedback on this.

Changed in openhackware:
assignee: nobody → adconrad
status: Confirmed → Triaged
Richard Elkins (texadactyl) wrote :

Suggestion: Since Ubuntu is so close to Beta and I'll assume that there is nothing critical that requires it, drop this package. One of two things will happen:
1) Nothing - Ubuntu is no worse off than now.
2) The maintainer will find time to port to x86 etc.

-Richard

Barry deFreese (bddebian) wrote :

Richard,

Have you spoken to upstream? It is really not a distributions package maintainer's job to actively develop the software, it is their job to make sure the existing package works in it's current form in the distribution. Everything I have read on this package openly states that it was developed on PPC FOR PPC.

Yes, you could argue that it's the maintainers job to work directly with upstream but upstream isn't always responsive.

Barry,

I agree with you about Ubuntu's responsibility. I was just commenting that Ubuntu shouldn't allow a package to fester if the package maintainer did not take responsibility for quality [seems to be the case here]. On the contrary, Ubuntu would be justified in removing it ASAP so as not distract folks who could spend their time more fruitfully elsewhere.

I am also a developer and I understand how a project can get held up by "one bad apple".

-Richard

Barry deFreese <email address hidden> wrote: Richard,

Have you spoken to upstream? It is really not a distributions package
maintainer's job to actively develop the software, it is their job to
make sure the existing package works in it's current form in the
distribution. Everything I have read on this package openly states that
it was developed on PPC FOR PPC.

Yes, you could argue that it's the maintainers job to work directly with
upstream but upstream isn't always responsive.

--
FTBFS
https://bugs.launchpad.net/bugs/64501
You received this bug notification because you are a direct subscriber
of the bug.

---------------------------------
Be a better Globetrotter. Get better travel answers from someone who knows.
Yahoo! Answers - Check it out.

Marco Costantini (costanti) wrote :

See also Bug #60478 in qemu (Ubuntu)

mirak (mirak-mirak) wrote :

just to say some people are still expecting a bug fix ^^

Source: openhackware
Source-Version: 0.4.1-3

We believe that the bug you reported is fixed in the latest version of
openhackware, which is due to be installed in the Debian FTP archive:

openhackware_0.4.1-3.diff.gz
  to pool/main/o/openhackware/openhackware_0.4.1-3.diff.gz
openhackware_0.4.1-3.dsc
  to pool/main/o/openhackware/openhackware_0.4.1-3.dsc
openhackware_0.4.1-3_all.deb
  to pool/main/o/openhackware/openhackware_0.4.1-3_all.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Guillem Jover <email address hidden> (supplier of updated openhackware package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Wed, 12 Dec 2007 08:57:39 +0200
Source: openhackware
Binary: openhackware
Architecture: source all
Version: 0.4.1-3
Distribution: unstable
Urgency: low
Maintainer: Guillem Jover <email address hidden>
Changed-By: Guillem Jover <email address hidden>
Description:
 openhackware - OpenFirmware emulator for PowerPC
Closes: 322300 339870 390236
Changes:
 openhackware (0.4.1-3) unstable; urgency=low
 .
   * Fix typo in package description. (Closes: #390236)
     Thanks to Simon Waters <email address hidden>.
   * Now using Standards-Version 3.7.3 (no changes needed).
   * Error out if the toolchain used to build is not powerpc-linux-gnu.
     (Closes: #322300, #339870)
   * Support cross-compiling by passing a cross prefix to make when not
     building natively.
   * Remove commented debhelper commands.
   * Do not ignore make errors on 'debian/rules clean'.
   * Switch to quilt:
     - Remove now unused debian/patch.mk.
     - Replace include of patch.mk with quilt.make in debian/rules.
     - Add Build-Depends on 'quilt (>= 0.40)'.
   * Move debhelper from Build-Depends-Indep to Build-Depends, needed by clean.
   * Add Homepage field.
   * Add Vcs-Browser and Vcs-Git fields.
Files:
 dc9b4219e8c4e95b07c1889ad4528747 787 misc optional openhackware_0.4.1-3.dsc
 e2cfe9016ad55f406c296889e7ecc9e4 3654 misc optional openhackware_0.4.1-3.diff.gz
 5ee25afe03f5b683ed85dca768fad19d 74488 misc optional openhackware_0.4.1-3_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHX4icuW9ciZ2SjJsRAuXvAJ98hVnV5SMwTAh+ADxh+OWA/BCsCACg6fo9
GYdiIs38nmE8x1O4uiHFsRE=
=WhHe
-----END PGP SIGNATURE-----

Changed in openhackware:
status: New → Fix Released

reopen 339870
thanks

Hi,

Debian Bug Tracking System wrote:
> * Error out if the toolchain used to build is not powerpc-linux-gnu.
> (Closes: #322300, #339870)

Again, I don't agree here (backed by p2): The package is wrong if it
asserts that it's "Architecture: all". It contains powerpc specific
stuff and can only be built on (i.e. for) that architecture. Therefore,
it should be "Architecture: powerpc".

Workarounds like an error on wrong toolchain architecture are wrong
(there is an error anyway if you try to build on !powerpc).

Thanks for considering.

Roland

Changed in openhackware:
status: Fix Released → New

tags 339870 wontfix
thanks

Hi,

On Sat, 2008-01-12 at 18:47:53 +0100, Roland Stigge wrote:
> Debian Bug Tracking System wrote:
> > * Error out if the toolchain used to build is not powerpc-linux-gnu.
> > (Closes: #322300, #339870)
>
> Again, I don't agree here (backed by p2): The package is wrong if it
> asserts that it's "Architecture: all". It contains powerpc specific
> stuff and can only be built on (i.e. for) that architecture. Therefore,
> it should be "Architecture: powerpc".

The only relevant part here is that it provides ppc binaries, the fact
that it needs a ppc toolchain is not, I'd say, it's an arch:all package
after all. Take vgabios as a similar example, it can be built anywhere
(because it uses bcc and bin86), it's an arch:all package that provides
i386 binaries, but yet it cannot be used on real i386 hardware, so
making it arch:any would make it a bit useless, you could only use it
under i386 to emulate i386 systems.

Also those are firmwares, you will not be able to run them directly on
your host system anyway, they either might need to be installed in a
BIOS/PROM/whatever or used inside an emulator, so I don't think they
are in the same situation as normal binaries.

Yes, ideally, to be pedantically correct, we would either have
powerpc (or other) cross-toolchains on the archive, or we'd have
Multiarch support and the package could be arch:powerpc and would be
possible to install on other arches. But this is not possible right
now, so consider this wontfix.

Other packages in a similar situation are proll, openbios-sparc,
bochsbios and vgabios (there might be others).

> Workarounds like an error on wrong toolchain architecture are wrong
> (there is an error anyway if you try to build on !powerpc).

That error is too late, and this one at least explains why it's
failing.

regards,
guillem

Changed in openhackware:
status: New → Won't Fix
Adam Conrad (adconrad) wrote :

While I could manually build this on powerpc, I will *not* manually build it for every upload, no matter how infrequent they are.

Have a look at the palo source, which solves this in two ways:

1) When on hppa, debian/rules clean builds hppa-specific stuff (and the source package is obviously always built on hppa because of this)

2) The package is Debian-native (ie: no diff.gz), so the above works easily, without having to uuencode stuff.

I suggest at least using the trick in (1), and if you choose to uuncode it in a diff.gz, or just tar it up in a Debian-native package, that's up to you.

Changed in openhackware:
assignee: adconrad → siretart
ski (skibrianski) wrote :

For those who don't have access to a ppc machine or a debian install, here's openhackware-sparc32 from debian etch as of 2008-11-01 (attached)

ski (skibrianski) wrote :

And openbios-sparc64... You can just copy these into /usr/share/openhackware/ and you should be good to go.

Changed in openhackware:
assignee: siretart → nobody
Adam Niedling (krychek) wrote :

Openhackware doesn't seem to be in the Karmic repos so maybe it's no longer supported?
Why is this bug critical and been open since 3 years? Shouldn't it be won't fix instead?

Sense Egbert Hofstede (sense) wrote :

Marking this bug as Fix Released since it has been built successfully quite a few times since this issue was reported.

Changed in openhackware (Ubuntu):
status: Triaged → Fix Released
Loïc Minier (lool) wrote :

I see no such build, actually I see no builds or build attempts, just a very old failed i386 build in *dapper* and nothing since.

(Reopening)

Changed in openhackware (Ubuntu):
status: Fix Released → Triaged
Loïc Minier (lool) wrote :
Download full text (3.7 KiB)

I tried a build on ppc (using an ugly hack) and got:
gcc -c -Wall -g -O2 -fno-builtin -fno-common -nostdinc -mregnames -DBUILD_DATE=2010-03-22 -DBUILD_TIME=17:30:40 -Isrc/ -Isrc/libc/include -I/usr/lib/gcc/powerpc-linux-gnu/4.4.3//include -Isrc/dev -Isrc/dev/block -Isrc/dev/char -Isrc/dev/bus -o .objs/part_prep.o src/libpart/prep.c
src/libpart/prep.c: In function 'PREP_find_partition':
src/libpart/prep.c:167: warning: pointer targets in passing argument 3 of 'part_register' differ in signedness
src/libpart/libpart.h:56: note: expected 'const unsigned char *' but argument is of type 'char *'
gcc -c -Wall -g -O2 -fno-builtin -fno-common -nostdinc -mregnames -DBUILD_DATE=2010-03-22 -DBUILD_TIME=17:30:40 -Isrc/ -Isrc/libc/include -I/usr/lib/gcc/powerpc-linux-gnu/4.4.3//include -Isrc/dev -Isrc/dev/block -Isrc/dev/char -Isrc/dev/bus -o .objs/dev_char_pckbd.o src/dev/char/pckbd.c
gcc -c -Wall -g -O2 -fno-builtin -fno-common -nostdinc -mregnames -DBUILD_DATE=2010-03-22 -DBUILD_TIME=17:30:40 -Isrc/ -Isrc/libc/include -I/usr/lib/gcc/powerpc-linux-gnu/4.4.3//include -Isrc/dev -Isrc/dev/block -Isrc/dev/char -Isrc/dev/bus -o .objs/dev_char_kbdadb.o src/dev/char/kbdadb.c
gcc -c -Wall -g -O2 -fno-builtin -fno-common -nostdinc -mregnames -DBUILD_DATE=2010-03-22 -DBUILD_TIME=17:30:40 -Isrc/ -Isrc/libc/include -I/usr/lib/gcc/powerpc-linux-gnu/4.4.3//include -Isrc/dev -Isrc/dev/block -Isrc/dev/char -Isrc/dev/bus -o .objs/dev_char_kbd.o src/dev/char/kbd.c
ld -O2 -g -nostdlib -T src/main.ld -o .objs/main.out .objs/main.o .objs/bootinfos.o .objs/bloc.o .objs/pci.o .objs/of.o .objs/start.o .objs/nvram.o .objs/vga.o .objs/mm.o .objs/char.o .objs/malloc.o .objs/errno.o .objs/_vprintf.o .objs/printf.o .objs/sprintf.o .objs/snprintf.o .objs/vprintf.o .objs/vsprintf.o .objs/vsnprintf.o .objs/dprintf.o .objs/vdprintf.o .objs/memcpy.o .objs/memccpy.o .objs/mempcpy.o .objs/memmove.o .objs/memcmove.o .objs/mempmove.o .objs/memset.o .objs/memcmp.o .objs/memchr.o .objs/rawmemchr.o .objs/memrchr.o .objs/memmem.o .objs/strcpy.o .objs/strdup.o .objs/strndup.o .objs/stpcpy.o .objs/stpncpy.o .objs/strcat.o .objs/strncat.o .objs/strcmp.o .objs/strcasecmp.o .objs/strncmp.o .objs/strncasecmp.o .objs/strchr.o .objs/strchrnul.o .objs/strrchr.o .objs/basename.o .objs/dirname.o .objs/strlen.o .objs/strnlen.o .objs/exec_core.o .objs/exec_elf.o .objs/exec_xcoff.o .objs/exec_macho.o .objs/exec_chrp.o .objs/exec_prep.o .objs/exec_pef.o .objs/fs_core.o .objs/fs_raw.o .objs/fs_ext2.o .objs/fs_isofs.o .objs/fs_hfs.o .objs/part_core.o .objs/part_apple.o .objs/part_isofs.o .objs/part_prep.o .objs/dev_char_pckbd.o .objs/dev_char_kbdadb.o .objs/dev_char_kbd.o
.objs/bootinfos.o: In function `residual_build':
/build/buildd/openhackware-0.4.1/src/bootinfos.c:282: undefined reference to `__stack_chk_fail'
.objs/bloc.o: In function `fdc_read_sector':
/build/buildd/openhackware-0.4.1/src/bloc.c:555: undefined reference to `__stack_chk_fail'
.objs/bloc.o: In function `fdc_initialize':
/build/buildd/openhackware-0.4.1/src/bloc.c:514: undefined reference to `__stack_chk_fail'
.objs/of.o: In function `OF_vga_register':
/build/buildd/openhackware-0.4.1/src/of.c:3509: undefined reference to `__stack_chk_fa...

Read more...

Loïc Minier (lool) wrote :

With -fno-stack-protector in CFLAGS, the package builds; I tried building the arch: all package during binary-arch on powerpc, but that failed to upload; see bug #183495

Changed in openhackware (Ubuntu):
importance: Critical → High
Jackson Doak (noskcaj) wrote :

This builds fine raring onwards

Changed in openhackware (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.