[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Building a sparc64 chroot with debootstrap (?)

On 09/18/2015 03:07 AM, jhcha54008 wrote:
> Hi,
> I just read the ongoing discussion on sparc64 chroots (
> https://lists.debian.org/debian-sparc/2015/09/msg00015.html
> and https://lists.debian.org/debian-sparc/2015/09/msg00016.html)
> Perhaps my debootstrap script 
> https://lists.debian.org/debian-alpha/2014/06/msg00012.html
> may help in this regard. It was tested only on alpha so far
> (and hppa where it is irrelevant) and I would be thankful
> for test reports on other architectures. 

That's actually a nice idea, thanks for the patch. Have you
considered sending this patch to the debbootstrap maintainer?

Being able to use unreleased when bootstrapping a ports architecture
is an incredibly helpful feature. Please file a bug against
debbootstrap with your patch attached if you haven't already.

> P-S : It seems that the package libaudit1 currently causes the
> installation to fail - it is perhaps advisable to wait for a newer
> version.
> .....The following dependency problems occur :
> required  package libaudit1(1:2.4.4-3) :  unmet dependency  libaudit-common 
>   (>= 1:2.4.4-3)  -  libaudit-common (1:2.4.4-2)  will be installed

Yeah, but we still stumble over libpcre3 which is not available
in unstable but unreleased only. I had to patch the package
as it won't build on sparc64 without modifications.

Normally, I can just build such packages manually with

$ export DEB_BUILD_OPTIONS="nobench nocheck" ; sbuild ...

but that doesn't help as the pcre3 source package ignores these
settings, it will run the testsuite in any case. Running with
"nobench nocheck" set normally disables the testsuite for
most packages.

Fixing the testsuite failure for pcre3 is also a high priority
task, btw. But first we have to fix the linker issue as having
a properly working toolchain is most important since a broken
toolchain can result into broken binaries which expose weird
crashes which are often incorrectly identified as a bug in the
particular package instead of the toolchain.

FWIW, the audit problem has already resolved itself. It was just
the debian-ports FTP server which hadn't synced the audit-common
package yet.


 .''`.  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

Reply to: