From: Leo Famulari <leo@famulari.name>
To: Vagrant Cascadian <vagrant@debian.org>
Cc: guix-devel <guix-devel@gnu.org>,
Maxim Cournoyer <maxim.cournoyer@gmail.com>
Subject: Re: linux-libre source tarballs (disable "deblob-check"?)
Date: Mon, 3 May 2021 11:44:30 -0400 [thread overview]
Message-ID: <YJAaXhha9LLjhBED@jasmine.lan> (raw)
In-Reply-To: <YI4SQtQSIQNvyApa@jasmine.lan>
[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]
On Sat, May 01, 2021 at 10:45:22PM -0400, Leo Famulari wrote:
> The immediate solution is for me to make sure the tarballs have built
> before committing the updates. I already do this for x86_64 and I can
> start doing it for aarch64 too.
Well, this is easier said than done, currently.
I was able to build the "arm64-generic" tarball for 5.11.18, but we
actually don't have the capability to build these things reliably at the
moment.
We only have 1 real aarch64 machine (Overdrive 1000) [0] in the build
farm, and it's never idle. The emulated builders are super slow.
We could change (gnu ci) to increase the timeout for these jobs, like
Ludo suggested, but I'm not sure it's worth it? I estimate the Overdrive
would spend at least one day a week just building tarballs, which is
unreasonable IMO.
The problem is that the linux-libre team told us that we shouldn't trust
the linux-libre deblobbing scripts to work and that we have to
"deblob-check" them, which takes a very long time. [1]
I suggest we disable these checks for now, at least for aarch64; have
they ever actually found a problem?
At least for aarch64, the choice is not between "blobby tarball or
non-blobby tarball", but rather between "no tarball or tarball".
[0] I can add another 4 cores (Macchiatobin) to the build farm, maybe
next weekend.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-05-03 15:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-02 1:45 linux-libre source tarballs Vagrant Cascadian
2021-05-02 2:45 ` Leo Famulari
2021-05-02 4:42 ` Leo Famulari
2021-05-02 21:08 ` Ludovic Courtès
2021-05-02 22:26 ` Leo Famulari
2021-05-02 22:38 ` Leo Famulari
2021-05-03 15:44 ` Leo Famulari [this message]
2021-05-03 16:39 ` Alexandre Oliva
2021-05-03 17:13 ` Leo Famulari
2021-05-06 4:10 ` Alexandre Oliva
2021-05-06 21:23 ` Leo Famulari
2021-05-06 20:30 ` Maxim Cournoyer
2021-05-09 3:27 ` Alexandre Oliva
2021-05-30 4:50 ` Vagrant Cascadian
2021-05-31 3:42 ` Leo Famulari
2021-05-31 19:57 ` Mathieu Othacehe
2021-08-01 20:45 ` source tarballs potentially built for each derivation Vagrant Cascadian
2021-08-01 21:04 ` Vagrant Cascadian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YJAaXhha9LLjhBED@jasmine.lan \
--to=leo@famulari.name \
--cc=guix-devel@gnu.org \
--cc=maxim.cournoyer@gmail.com \
--cc=vagrant@debian.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.