all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Linux-libre 5.8 and beyond
@ 2020-08-08 20:57 Vagrant Cascadian
  2020-08-09  0:02 ` Mark H Weaver
                   ` (2 more replies)
  0 siblings, 3 replies; 34+ messages in thread
From: Vagrant Cascadian @ 2020-08-08 20:57 UTC (permalink / raw)
  To: guix-devel; +Cc: Marius Bakke

[-- Attachment #1: Type: text/plain, Size: 1640 bytes --]

Thanks for updating linux-libre to 5.7!

I saw the 5.8 was out, and gave a quick shot at updating it, but it hung
python indefinitely during the deblobbing process. I also tried
switching to python 3 instead of python 2, but it had the same
issue. Apparently this is a known issue:

  https://lists.gnu.org/archive/html/info-gnu/2020-08/msg00001.html

When I tried switching deblob to use gawk instead, it produced the
cleaned tarball, but resulted in syntax errors when building
linux-libre.

So I asked a bit in #linux-libre on freenode and they wondered why we
don't use the git repository instead of running the deblob scripts again
in guix.

One of the issues might be that linux-libre may occasionally remove
releases that accidentally contained non-free code breaking guix's
ability to build old versions. Not sure exactly where guix's balance
between functional package management and software freedom interplays
there.

That said, using their git repository could allow guix to take advantage
of the software heritage as a fallback; though I'm not quite sure how
well that would work with removed versions.

Downloading the git repository of a project as large as linux-libre
every time is probably somewhat expensive. Though the process of
deblobbing in guix is also quite expensive...


There's more debugging to do (and admittedly, wrapping my head around
the deblobbing code in linux.scm is a bit difficult) and the linux-libre
folks are somewhat interested to figure out what exactly is wrong with
the process building on guix.


Not sure how much time I can throw at it, but curious what others think!


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: Linux-libre 5.8 and beyond
@ 2020-08-09 20:15 Jason Self
  2020-08-13  0:39 ` Mark H Weaver
  0 siblings, 1 reply; 34+ messages in thread
From: Jason Self @ 2020-08-09 20:15 UTC (permalink / raw)
  To: guix-devel

[-- Attachment #1: Type: text/plain, Size: 2303 bytes --]

> the linux-libre project periodically deletes most of its older
> tarballs, even if there are no accidents.

Just FYI that git://linux-libre.fsfla.org/releases.git was created
mainly to solve that problem. Versions are now pretty much permanent.

> It may be useful for users with newer hardware devices, which are
> not yet well supported by the latest stable release, to use an
> arbitrary commit from either Linus' mainline git repository or some
> other subsystem tree.

The cleaning up scripts are version-specific and won't work on an 
"arbitrary commit from Linus's mainline git repository" (i.e., someone
wanting to get today's most recent commit going into 5.9.) The scripts
would fall over and die in such a scenario, or if forced to continue by
using --force the result would be incomplete cleaning. Using the
scripts on a version other than what the precise version that they were
intended for can also cause them to fail in obscure ways, as Vagrant
Cascadian has found out firsthand by running the 5.7 cleaning scripts
on 5.8 (that was determined to be the source of the problems they were
having.) If you look closely at the results of Vagrant Cascadian's
attempt, you'll see there was more than syntax errors: plenty of blobs
were certainly left in. Thus: As said, the clean up scripts can only be
used for the version that they were intended. Use with any other
version invites problems.

> It allows us to update to a new point version (which usually
> includes security fixes) more quickly, before the linux-libre
> project reacts.

Any attempt outrun the Linux-libre project and get updates out sooner
is unwise. While major new kernel releases will definitely require 
updates to the cleanup scripts, even minor patched versions 
occasionally require changes too. Updating to a new version prior to 
the Linux-libre project having had time to review that new version and 
determine if any updates are needed to the scripts risks introducing
freedom problems in the corresponding Guix version.

The moment that the Linux-libre project determines that scripts are
suitable is the moment that the new cleaned-up release is ready to
publish in git and the appropriate tags will then appear in git. The
compressed tarballs come some time later.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

^ permalink raw reply	[flat|nested] 34+ messages in thread
* Re: Linux-libre 5.8 and beyond
@ 2020-08-11  4:07 Mark H Weaver
  0 siblings, 0 replies; 34+ messages in thread
From: Mark H Weaver @ 2020-08-11  4:07 UTC (permalink / raw)
  To: Bengt Richter; +Cc: guix-devel, Vagrant Cascadian, Marius Bakke

Bengt Richter <bokr@bokr.com> wrote:
> BTW, how did nix get such a weird alphabet for 0-31 ?

My guess is that the weird alphabet was chosen to avoid some of the most
common letters in English text, so that when scanning build outputs for
embedded hashes, one is less likely to mistake something else (e.g. text
or some other base32/base64 encoding) as a Nix hash.  The omitted
letters in Nix hashes are (e t o u), whereas (e t a o) are the most
common letters in English text.  I'm not sure why they chose to omit 'u'
though, given that it's quite far down the list of most common English
letters.

    Regards,
      Mark


^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2020-08-26 15:42 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-08-08 20:57 Linux-libre 5.8 and beyond Vagrant Cascadian
2020-08-09  0:02 ` Mark H Weaver
2020-08-09  3:30 ` Mark H Weaver
2020-08-09  3:43   ` Vagrant Cascadian
2020-08-09 18:09     ` Vagrant Cascadian
2020-08-09 22:17       ` Mark H Weaver
2020-08-10  1:59         ` bug#42789: " Leo Famulari
2020-08-10 17:16           ` bug#42789: Linux-libre 'deblob-check' file-names do not include a version number Leo Famulari
2020-08-11  3:46           ` bug#42789: Linux-libre 5.8 and beyond Mark H Weaver
2020-08-11 22:46             ` Leo Famulari
2020-08-12  3:24               ` Leo Famulari
2020-08-12 21:34           ` Mark H Weaver
2020-08-21 22:02             ` Leo Famulari
2020-08-10 22:39         ` Bengt Richter
2020-08-11  2:37           ` Tobias Geerinckx-Rice
2020-08-09 18:49   ` Leo Famulari
2020-08-25 21:01 ` Leo Famulari
2020-08-26  3:17   ` Leo Famulari
2020-08-26 15:41     ` Katherine Cox-Buday
  -- strict thread matches above, loose matches on Subject: below --
2020-08-09 20:15 Jason Self
2020-08-13  0:39 ` Mark H Weaver
2020-08-14 13:47   ` Alexandre Oliva
2020-08-15  6:03     ` Mark H Weaver
2020-08-16  1:24       ` Mark H Weaver
2020-08-16 12:43         ` Jason Self
2020-08-16 10:54       ` Jason Self
2020-08-24  3:45       ` Alexandre Oliva
2020-08-25  4:14         ` Mark H Weaver
2020-08-25 11:12           ` Alexandre Oliva
2020-08-24  3:58       ` Alexandre Oliva
2020-08-24  4:12       ` Alexandre Oliva
2020-08-24  4:34       ` Alexandre Oliva
2020-08-24  4:42       ` Alexandre Oliva
2020-08-11  4:07 Mark H Weaver

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.