Re: Packages missing for debootstrapping Debian/riscv64 (was: Bug#906429: systemd: Please raise timeout for tests (for riscv64))
Hi!
2018-08-17 19:20 GMT+02:00 Karsten Merker <merker@debian.org>:
> life is strange ;-). I've tried a similar approach yesterday
> evening, had the test build finished today and just wanted to
> send off the bugreport when I have received your mail. A timeout
> increase to 300 seconds looks good - in my test builds on an
> otherwise idle system, the longest test took ~100 seconds, so 300
> seconds should provide a reasonable security margin for a loaded
> buildd.
Heh, yeah, so I started to work on this to try to solve the last
remaining things with the base system and the "debootstrap problem".
After 4h+ building systemd in riscv64 (1h+ in mips64el, another
release architecture, and with "real hardware"), ~5 minutes of timeout
for some tests doesn't look too much, even if they can take more than
5 mins -- they are not all done in parallel, I think. But the whole
thing is basically in the noise. So I just multiplied by 10 the
existing and default timeouts to make it all "300" (one of them was 90
already).
I saw similar timings, slightly over 100s, perhaps 120s. Apart from
the buildds being more loaded, I think that the added margin is good
because it will be a problem if existing or new tests duplicate their
time from say, 10s in amd64 to 20s, but that might mean from 100s to
200s in riscv64 with qemu-system.
> Regarding stuff missing in unstable for properly debootstrapping
> a system: there is at least one other package, and that is
> libffi, which is used by apt. Unfortunately upstream support for
> RISC-V is only available in libffi git head, but not yet in an
> official release. Upstream had originally planned to release a
> new libffi version (3.3) in May 2018, but that didn't work out
> and AIUI there are a number of (not riscv64-related) regressions
> compared to version 3.2.1 that need to be sorted out before a
> release can happen.
We had a conversation about this in the IRC channel, more or less
touching all the points that you mention here.
Right now, using "debootstrap" appears to work but apt is broken in
the target system.
It turns out that some libsystemd is required by apt and doesn't work
at all without it, and libffi is also required by apt but only when
using gnutls, presumably for https targets. So the hope is that one
can debootstrap using http://ftp.ports.debian.org/debian-ports,
instead of an https address on the target system, and have a mostly
functional system, or at least with apt mostly working, and from then
on it can self-heal.
Of course it would be great to solve also libffi, but being able to
debootstrap and having a functional system, even with the caveat of
non-https URLs, would be a nice step to avoid pointless busy-work. I
think that after debootstrap with non-https URLs (without loss of
security, if someone wonders about that), one can "apt-get -f install"
or similar to get the missing deps, and after that one can use https
addresses.
> Another package that is currently only in unreleased and which is
> required at least for debootstrapping with --variant=buildd is
> elfutils. Elfutils actually builds fine but fails a number of
> tests. Andreas Schwab (from SUSE) has recently contributed some
> RISC-V-related updates, but current elfutils git head still fails
> some tests on riscv64. Unfortunately I know way too little about
> ELF internals to debug those failures :-(.
>From my POV this is less critical, because after having a basic system
installed with the methods above, one can "apt-get install buildd" and
maybe other handful of packages and have the same result, and the
operation should not be needed too often and usually only a handful of
individuals involved.
(Of course, having elfutils out of "unreleased" is interesting in its
own right).
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>
Reply to: