Re: GNU Guix 1.3.0rc1 available for testing!

[Maxim Cournoyer]

Hi Leo,

Thanks for the feedback!

Leo Famulari  writes:

> On Sat, May 01, 2021 at 10:52:18PM -0400, Maxim Cournoyer wrote:
>> > https://guix.gnu.org/manual/en/
>> > https://guix.gnu.org/manual/devel/en/
>> 
>> Thank you for pointing that issue; I caught the problem with
>> guix-install.sh before posting, but overlooked that one.  As you
>> pointed, that won't be reflected on our website, but I agree that having
>> the new key covered in the devel manual (master branch) is already an
>> improvement.  The attached patch augments the manual to cover for the
>> new key.  Let me know if it looks good to you.  If it does, I will push
>> it to the master branch (IIUC we can't push this change to the
>> version-1.3.0 branch as that would break the string freeze there).

I've clarified this with Julien, our Natural Language Support (NLS)
expert, and they said: "As long as you change only examples, @code, @url
etc, fragments I should be able to do the change manually in the po
files even if I don't know the language".  So this mean we can carefully
update some very limited parts of the manual; Julien will do one last
pass to adjust the .po files accordingly before the release.

[...]

> Your patch looks good except that the instructions about 'mykeyring.kbx'
> are a no-op: The created keyring contains no keys afterwards. This is
> with GnuPG 2.2.27 from current Guix. We should just remove these
> instructions since "--recv-keys" almost never works these days, since
> the keyserver network collapsed. For example:
>
> --
> $ gpg --no-default-keyring --keyring mykeyring.kbx --recv-keys 
> 27D586A4F8900854329FF09F1260E46482E63562 
> gpg: keybox '/home/leo/.gnupg/mykeyring.kbx' created
> gpg: WARNING: server 'dirmngr' is older than us (2.2.12 < 2.2.27)
> gpg: Note: Outdated servers may lack important security fixes.
> gpg: Note: Use the command "gpgconf --kill all" to restart them.
> gpg: key 1260E46482E63562: no user ID
> gpg: Total number processed: 1
> $ gpg --no-default-keyring --keyring mykeyring.kbx --recv-keys 
> 3CE464558A84FDC69DB40CFB090B11993D9AEBB5  
> gpg: WARNING: server 'dirmngr' is older than us (2.2.12 < 2.2.27) 
>
> gpg: Note: Outdated servers may lack important security fixes.
> gpg: Note: Use the command "gpgconf --kill all" to restart them.
> gpg: key 090B11993D9AEBB5: no user ID
> gpg: Total number processed: 1
> $ cat ~/.gnupg/mykeyring.kbx 
>  KBXf`)y`)y%
> $ wc -c ~/.gnupg/mykeyring.kbx
> 32 /home/leo/.gnupg/mykeyring.kbx
> --
>
> As you can see, it does not contain two PGP keys.

FWIW, it worked for me:

$ gpg --no-default-keyring --keyring mykeyring.kbx --recv-keys 
27D586A4F8900854329FF09F1260E46482E63562
gpg: keybox '/home/maxim/.gnupg/mykeyring.kbx' created
gpg: key 1260E46482E63562: public key "Maxim Cournoyer 
" imported
gpg: Total number processed: 1
gpg:   imported: 1
maxim@hurd ~/src/guix [env]$ gpg --no-default-keyring --keyring mykeyring.kbx 
--recv-keys 3CE464558A84FDC69DB40CFB090B11993D9AEBB5  
gpg: key 090B11993D9AEBB5: public key "Ludovic Courtès " imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:   imported: 1
maxim@hurd ~/src/guix [env]$ 
maxim@hurd ~/src/guix [env]$ wc -c ~/.gnupg/mykeyring.kbx
8781 /home/maxim/.gnupg/mykeyring.kbx

I had similar bad experience in the past, but my understanding was that
these problems had been (mostly?) resolved.  In case the default server
is often problematic, we could perhaps suggest an alternative that is
known to be reliable (if such an alternative exists?).

I've pushed a commit to master; and a slightly different one to
version-1.3.0 later, adjusting the commit so as the manual text is
untouched.

Thank you!

Maxim

Re: guix-install.sh: Add support for more than one signing key.

[Maxim Cournoyer]

Hi Tobias,

Tobias Geerinckx-Rice  writes:

> Maxim,
>
> Maxim Cournoyer 写道：
>> The forthcoming 1.3.0 release will be signed with my personal
>> GnuPG key
>
> \o/
>
> Don't forget to also update OPENPGP-SIGNING-KEY-{ID,URL} in
> doc/guix.texi on the master and release-1.3.0 branches.

Now done!

Thanks for the feedback :-)

Maxim

Re: bug#48173: [PATCH] maint: Do not xz-compress ISO images.

[Maxim Cournoyer]

Hi,

Julien Lepiller  writes:

[...]

>>In what sense does it break the string freeze?
>>
>>I understand translations would appear as below 100% on Weblate, but I
>>checked guix.{fr,es,de}.info and they all read well after this change.
>>
>>Am I missing something?
>
> po4a is not that intelligent. The result will be either the old
> translated string, or the new English string.
>
> But it's fine. We already have a similar change on version-1.3.0, so
> go ahead and push this, I'll take care of weblate :)

I've pushed this to version-1.3.0, along a slightly edited version of a
a diff Julien shared earlier that fixed an issue with building the doc
after recent changes.

Thank you both!

Closing.

Maxim

Re: A "cosmetic changes" commit that removes security fixes

[Bengt Richter]

Hi Pierre,

On +2021-05-03 09:25:21 +0200, Pierre Neidhardt wrote:
> Hi Giovanni,
> 
> > Guix is a GNU project and AFAIU GNU project management is well
> > documented:
> >
> > https://www.gnu.org/gnu/gnu-structure.html
> 
> This applies to GNU at the top level, but it does not specify how
> sub-projects (referred to as "packages" in the aforementioned document)
> are governed locally.  This question is mostly left unanswered as I
> understand it.
>

You may find some clues here:
https://www.gnu.org/help/evaluation.html#whatmeans
And links to more :)

> Cheers!
> 
> -- 
> Pierre Neidhardt
> https://ambrevar.xyz/

-- 
Regards,
Bengt Richter

Re: GNU Guix 1.3.0rc1 available for testing!

[Leo Famulari]

On Mon, May 03, 2021 at 09:38:56PM +0200, Tissevert wrote:
> I've just given the binary tarball a spin on Devuan. Worked almost flawlessly
> (daemonize wasn't installed and I missed the part when it was mentioned 
> because
> I was a bit in a hurry but apart from that the overall experience was great —
> the guix text art was surprising in a good kind of way).

I think that a big part of why we offer the SysV-init "/etc/init.d"
service management script is to serve Devuan — there are not many
distros using that style of service management anymore. If `daemonize`
is not available by default on Devuan, I wonder if there is some other
way we should be writing the script.

Can you check some "Devuan provided" scripts in '/etc/init.d' and see if
they use a different method of daemonizing things?
 
> I got the warning about the GPG keys, and I confirm I got a single warning for
> both keys at once with a very simple click'n'paste command to import the keys
> and fix the problem.

Great!

> Once installed and the daemon started manually, it looks like it works (at
> least the simple things I use do). To answer Leo's question if I understand it
> correctly, I can guarantee you that absolutely no guix-related user or group
> existed before I ran the script, and they have been successfully created (10
> guix builder users named `printf "guixbuilder%02d" <$> [1..10]` and 1 group 
> named
> guixbuild).

Awesome, thanks for checking! That sounds exactly right.

Re: GNU Guix 1.3.0rc1 available for testing!

[Tissevert]

Hi !!

I've just given the binary tarball a spin on Devuan. Worked almost flawlessly
(daemonize wasn't installed and I missed the part when it was mentioned because
I was a bit in a hurry but apart from that the overall experience was great —
the guix text art was surprising in a good kind of way).

I got the warning about the GPG keys, and I confirm I got a single warning for
both keys at once with a very simple click'n'paste command to import the keys
and fix the problem.

Once installed and the daemon started manually, it looks like it works (at
least the simple things I use do). To answer Leo's question if I understand it
correctly, I can guarantee you that absolutely no guix-related user or group
existed before I ran the script, and they have been successfully created (10
guix builder users named `printf "guixbuilder%02d" <$> [1..10]` and 1 group 
named
guixbuild).

It's so cool to be able to use Guix on that box (I'll soon reinstall it with
Guix I think but in the meantime it's there and that's handy). Thanks !


Tissevert

On Sat, 01 May 2021 01:45:57 -0400
Maxim Cournoyer  wrote:

> Hello Guix!
> 
> A first RC for the upcoming 1.3.0 release is now available for
> testing:
> 
>   source:
> https://alpha.gnu.org/gnu/guix/guix-1.3.0rc1.tar.gz
> 
>   binary tarball (to install on a “foreign distro”):
> https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.aarch64-linux.tar.xz
> https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.armhf-linux.tar.xz
> https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.i686-linux.tar.xz
> 
> https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.powerpc64le-linux.tar.xz
> https://alpha.gnu.org/gnu/guix/guix-binary-1.3.0rc1.x86_64-linux.tar.xz
> 
>   system installation:
> 
> https://alpha.gnu.org/gnu/guix/guix-system-install-1.3.0rc1.i686-linux.iso.xz
> 
> https://alpha.gnu.org/gnu/guix/guix-system-install-1.3.0rc1.x86_64-linux.iso.xz
> 
>   virtual machine image:
> 
> https://alpha.gnu.org/gnu/guix/guix-system-vm-image-1.3.0rc1.x86_64-linux.qcow2.xz
> 
> SHA256 hashes:
> 
> 46525e84d2a1d30a53bb40569de23bb1813b8df78731d09b5eac977818106ea7
> guix-1.3.0rc1.tar.gz
> 2427e73f5f18c51446174cd230b6dc19c8461838641bec6f66761537e7aa7ad4
> guix-binary-1.3.0rc1.aarch64-linux.tar.xz
> 89028139d049e1a868d41c5d1155f6b3be1b1b0407d93bfa86b7c713a87c1daf
> guix-binary-1.3.0rc1.armhf-linux.tar.xz
> 5da4edf9075c87d575d653140b53fe316305f94b58179aa935af223f037b36c2
> guix-binary-1.3.0rc1.i686-linux.tar.xz
> f7c2a42f9f48fc6b2d7ba672ed49c3a6fc483cb3fbe261a8a79385b8381205ec
> guix-binary-1.3.0rc1.powerpc64le-linux.tar.xz
> 3348ec2fd116ed97c1806f8eac777ab2f7cff2b466b7c0dc5c2d1a904e4395f7
> guix-binary-1.3.0rc1.x86_64-linux.tar.xz
> 429deb5af3a956e7530cd0ed4cab7d5b13a7f1d22a0fe690f6714ab89a846db6
> guix-system-install-1.3.0rc1.i686-linux.iso.xz
> a1772a8d08729471e7b1c04ac4d9213f4db077458aeacc59d14ff9f2399357b2
> guix-system-install-1.3.0rc1.x86_64-linux.iso.xz
> 58ccabbc61cd00d9b1ec1f417360827aa2f8428567f1cfb0a83dc2191e67897e
> guix-system-vm-image-1.3.0rc1.x86_64-linux.qcow2.xz
> 
> All these files have an associated ‘.sig’, an OpenPGP signature that
> you can verify as explained at
> .
> 
> You can help by:
> 
>   1. Testing the binary tarball on the distro of your choice.  You can
>  download .  Uncomment the
>  ‘GNU_URL’ variable assignment that refers to alpha.gnu.org and it
>  should pick up 1.3.0rc1 automatically.
> 
>   2. Testing the graphical installer of Guix System.
> 
>   3. Testing the VM image.
> 
> In any case, please report success, failure, and annoyances in this
> thread.
> 
> The remaining outstanding issues, which you can track here [0], are as
> follow and affect the installer:
> 
> 47567 Installer crash in 'uuid->string' for a FAT16 partition
> 44872 Installer crash: 'uuid->string' is passed #f in lieu of a UUID
> 
> If everything goes well, the final release is planned for the 10th of
> May, which gives us about a week to test and fix any remaining issues.
> 
> Thanks in advance!
> 
> Maxim
> 
> [0]  http://issues.guix.gnu.org/47297
> 

Re: ISO image: to xz or not to xz?

[Vagrant Cascadian]

On 2021-05-03, Tobias Geerinckx-Rice wrote:
> Tangent: I sense some undeserved mysticism surrounding squashfs. 
> It is not designed to be loop-mounted, any more than ext2 was.  It 
> does not enjoy it.  People should stop doing it.

The only mysticism I see here is attributing enjoyment to a
filesystem. :)

Is mounting on a loopback device really any different from any other
block device?


> But they won't, because many distributions still insist that the 
> same installer image must be both a bootable CD/DVD *and* boot 
> when dd'd to a USB drive, on every PC ever made.

> That ‘isohybrid’ dream justifies doing unmentionable things to an 
> iso9660 file system (and only an iso9660 file system), so they 
> must put the real squashfs on top of that and loop-mount it and 
> ignore the screams I guess and--

Never heard the screams; what frequency does squashfs emit screams at?
:)

People have made it work well enough for only slightly less long than I
can remember using free software operating systems...


> Vagrant Cascadian 写道：
>> Well, the suggestion to use squashfs does bear merit;
>
> It's not a *bad* suggestion, just a bit obvious.

Fair enough.


>> it would require having some type of writeable filesystem on top,
>> such as using overlay fs to mount the installer rootfs with squashfs
>> for the readonly bits, and tmpfs for the writeable bits.
>
> We've always done this.

I *thought* so, but...


>> As a bonus, using a tmpfs overlay would solve the issue brought up
>> recently by someone who tried using the same installer image multiple
>> times, and /gnu/store and /var/guix got out of sync due to the
>> cow-store only writing to the newly installed system, so that the
>> second install failed.
>
> ...so no, it definitely wouldn't, but I think it's valuable to 
> understand why you thought so!
>
> Could you elaborate?

Mostly I was referring to:

  https://lists.gnu.org/archive/html/guix-devel/2021-04/msg00546.html

Though I haven't confirmed that behavior myself. Probably deserves a
proper bug report.


live well,
  vagrant


signature.asc
Description: PGP signature

Re: ISO image: to xz or not to xz?

[Tobias Geerinckx-Rice]

Hi Vagrant!

Tangent: I sense some undeserved mysticism surrounding squashfs. 
It is not designed to be loop-mounted, any more than ext2 was.  It 
does not enjoy it.  People should stop doing it.


But they won't, because many distributions still insist that the 
same installer image must be both a bootable CD/DVD *and* boot 
when dd'd to a USB drive, on every PC ever made.


That ‘isohybrid’ dream justifies doing unmentionable things to an 
iso9660 file system (and only an iso9660 file system), so they 
must put the real squashfs on top of that and loop-mount it and 
ignore the screams I guess and--


...sorry; I got carried away.

Vagrant Cascadian 写道：

Well, the suggestion to use squashfs does bear merit;


It's not a *bad* suggestion, just a bit obvious.


it would require
having some type of writeable filesystem on top, such as using 
overlay
fs to mount the installer rootfs with squashfs for the readonly 
bits,

and tmpfs for the writeable bits.


We've always done this.

As a bonus, using a tmpfs overlay would solve the issue brought 
up
recently by someone who tried using the same installer image 
multiple
times, and /gnu/store and /var/guix got out of sync due to the 
cow-store
only writing to the newly installed system, so that the second 
install

failed.


...so no, it definitely wouldn't, but I think it's valuable to 
understand why you thought so!


Could you elaborate?

Another angle might be to use a compressable but writeable 
filesystem

(btrfs?).


A persistently mutable . . . installation medium . . . ?

Very lost, slightly frightened,

T G-R


signature.asc
Description: PGP signature

Re: ISO image: to xz or not to xz?

[Vagrant Cascadian]

On 2021-05-03, Leo Famulari wrote:
> On Mon, May 03, 2021 at 01:47:02PM -0300, Alexandre Oliva wrote:
>> Indeed, install ISOs normally hold already-compressed filesystems or
>> files, so recompressing the .iso doesn't gain much if at all.
>
> To quote the introductory message of this thread:
>
> "The xz-compressed image is 23% smaller, which is not negligible."

Well, the suggestion to use squashfs does bear merit; it would require
having some type of writeable filesystem on top, such as using overlay
fs to mount the installer rootfs with squashfs for the readonly bits,
and tmpfs for the writeable bits.

As a bonus, using a tmpfs overlay would solve the issue brought up
recently by someone who tried using the same installer image multiple
times, and /gnu/store and /var/guix got out of sync due to the cow-store
only writing to the newly installed system, so that the second install
failed.

Another angle might be to use a compressable but writeable filesystem
(btrfs?).

Obviously, it requires someone to do the work to get there!


live well,
  vagrant


signature.asc
Description: PGP signature

Re: ISO image: to xz or not to xz?

[Tobias Geerinckx-Rice]

Alexandre Oliva 写道：
Consider using something like a loopback-mounted squashfs for 
the bulk

of the data in the install media for a future release.


Read .

I did play with the obvious alternative, but got so bored -- 
squashfs is no forgotten 1990s Linux-only extension to iso9660! -- 
that saving a mere 20% more was not worth it.


By this I hope to trick you into thinking it is, and submitting a 
patch, because to do so you'd have to fix one of the Forever Bugs 
that *is* worth fixing: separate /boot support.  :-)


Kind regards,

T G-R


signature.asc
Description: PGP signature

Re: Guix help page

[Vincent Legoll]

Hello,

On Mon, May 3, 2021 at 4:11 PM Luis Felipe
 wrote:
> I just sent a patch to add this (https://issues.guix.gnu.org/48187/).

At a cursory glance, it LGTM.

Thanks a lot.

-- 
Vincent Legoll

Re: linux-libre source tarballs

[Leo Famulari]

On Mon, May 03, 2021 at 01:39:54PM -0300, Alexandre Oliva wrote:
> You don't have to clone anything.  If all you want is a tarball, use
> 'git archive --remote'.

Thanks, I didn't know about this feature. Is the tarball generation
"stable" across Git releases? Or is it subject to change? We had this
issue with Git archive creation in the past.

> Is it correct to assume that they have never reached you?  Would you
> like to have a look and let me know whether they make sense to you?  I'd
> be glad to dig them up and share them with you, if so, and to take your
> feedback towards making them available to the public at large.

Personally, as a non-maintainer, I'd prefer to preserve the status quo
of our linux-libre packaging. If the maintainers decide that it should
be changed, I'll follow their decision.

Re: ISO image: to xz or not to xz?

[Leo Famulari]

On Mon, May 03, 2021 at 01:47:02PM -0300, Alexandre Oliva wrote:
> Indeed, install ISOs normally hold already-compressed filesystems or
> files, so recompressing the .iso doesn't gain much if at all.

To quote the introductory message of this thread:

"The xz-compressed image is 23% smaller, which is not negligible."

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

[Mark H Weaver]

Hi Leo,

Leo Prikler  writes:

> Am Montag, den 03.05.2021, 05:00 -0400 schrieb Mark H Weaver:
>> Leo Prikler  writes:
>> 
>> > Am Samstag, den 01.05.2021, 23:13 -0400 schrieb Mark H Weaver:
>> > > I don't think I fumbled on the facts at all.  It's true that I
>> > > didn't yet have _all_ of the relevant facts, but as far as I
>> > > know, every fact that I presented is true.
>> > > 
>> > > If you disagree, can you please provide a counterexample?
>> > 
>> > In your very first message you made it seems as though Raghav
>> > single-handedly authored and pushed the changes in question and
>> > called into question their reliability as a committer.  The former
>> > was based on "facts", that turned out half-true – Raghav did push
>> > that commit, but they did so thinking that Léo did proper review,
>> > which they did not –
>> 
>> Here, once again, you've failed to point out any of my *actual* words
>> to back up your (bogus) claim that I "fumbled on the
>> facts".  Instead, you speak of how I "made it seem".  You put more
>> words into my mouth.

> If you want to read your actual words, they were

>> Behold, Raghav's "cosmetic changes" to our 'cairo' package

I don't know how the genitive case is used in German, but in English, it
can mean a great many things, from possession (Mark's bicycle) to mere
association (Mark's community of friends) and many other things.  It
certainly does *not* imply single-handed authorship as you suggest
above.

I'll grant that you are correct in your speculation that at the time I
wrote the words above, in my *mind* I more-or-less assumed that Raghav
had authored the commit.  After all, Raghav digitally signed and pushed
the commit, whose metadata indicated that he was the sole author.

However, I never *wrote* anything that implied he was the sole author.
Therefore, I still maintain that in my actual communications, I didn't
"fumble on the facts" *at all*.

I'm going to _try_ to refrain from responding again, because in order
for this exchange to be finite, *one* of us must eventually let the
other one have the final word.

   Regards,
 Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

Re: ISO image: to xz or not to xz?

[Alexandre Oliva]

On Apr 28, 2021, Ludovic Courtès  wrote:

> However, it’s apparently quite unusual to distribute compressed ISOs and
> some services/tools such as libosinfo require plain ISOs (uncompressed).

Indeed, install ISOs normally hold already-compressed filesystems or
files, so recompressing the .iso doesn't gain much if at all.

> Should we distribute the installation ISO without xz compression?

If the iso is so compressible, offering a compressed version for
download makes sense, but it will still be wasteful of install media.

Consider using something like a loopback-mounted squashfs for the bulk
of the data in the install media for a future release.

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: linux-libre source tarballs

[Alexandre Oliva]

Hello, Leo,

On May  1, 2021, Leo Famulari  wrote:

> it's not "source code" in the GNU sense, which is the "preferred form
> of the work for making changes in it":

That's not accurate.  Linux-libre sources, whether obtained from a git
repository or from a tarball, are just as suitable for kernel
development as any other snapshot.

There is an alternate understanding of source code form taking shape in
some communities that suggests that a version control repository is
somehow more "source"ish than any of the versions held in it.

No doubt the additional versions in it may be useful in some cases, but
it does not follow that other versions and their relationship are part
of "source code" in the GNU sense.

In the GNU sense, any individual snapshot or release meets the
definition of source code.

> Not to mention that cloning a 1 GB Git repo is rather expensive compared
> to downloading a tarball

You don't have to clone anything.  If all you want is a tarball, use
'git archive --remote'.

> As you say, these tarballs are not available for very long.

*nod*, that's why we switched to a git repo, and extract the tarballs
from it.

Back when we made the switch, I wrote extensive documentation and
recipes as to the possibilities of getting to the GNU Linux-libre
sources from it, how to verify signatures, etc.  It was to be assessed
by then maintainers of Guix recipes to build GNU Linux-libre before
publishing, but it doesn't look like I ever got feedback on them, and
they hvae been unpublished so far.

Is it correct to assume that they have never reached you?  Would you
like to have a look and let me know whether they make sense to you?  I'd
be glad to dig them up and share them with you, if so, and to take your
feedback towards making them available to the public at large.

Thanks,

-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

Re: bug#48173: [PATCH] maint: Do not xz-compress ISO images.

[Julien Lepiller]

Le 3 mai 2021 11:39:03 GMT-04:00, "Ludovic Courtès"  a écrit :
>Hi Julien,
>
>Julien Lepiller  skribis:
>
>>> --- a/doc/guix.texi
>>> +++ b/doc/guix.texi
>>> @@ -2099,7 +2099,7 @@ about their support in GNU/Linux.
>>>  
>>>  An ISO-9660 installation image that can be written to a USB stick
>or
>>>  burnt to a DVD can be downloaded from
>>>
>-@indicateurl{@value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso.xz},
>>>
>+@indicateurl{@value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso},
>>>  where you can replace @code{x86_64-linux} with one of:
>>
>> Sorry, this actually breaks string freeze. Now for something like
>this,
>> we could grant an exception? It's not like it's too hard to fix, even
>> manually and even if you don't know the language :)
>
>In what sense does it break the string freeze?
>
>I understand translations would appear as below 100% on Weblate, but I
>checked guix.{fr,es,de}.info and they all read well after this change.
>
>Am I missing something?

po4a is not that intelligent. The result will be either the old translated 
string, or the new English string.

But it's fine. We already have a similar change on version-1.3.0, so go ahead 
and push this, I'll take care of weblate :)

>
>Thanks for commenting!
>
>Ludo’.

Re: bug#48173: [PATCH] maint: Do not xz-compress ISO images.

[Ludovic Courtès]

Julien Lepiller  skribis:

> I have to ask about the patch title: what does "maint" mean?

It means “maintenance”.  Some GNU packages use this convention to
categorize changes related to “maintenance” in a broad sense, things
that are not user-visible.

Thanks for paying attention.  ;-)

Ludo’.

Re: linux-libre source tarballs (disable "deblob-check"?)

[Leo Famulari]

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.


signature.asc
Description: PGP signature

Re: bug#48173: [PATCH] maint: Do not xz-compress ISO images.

[Ludovic Courtès]

Hi Julien,

Julien Lepiller  skribis:

>> --- a/doc/guix.texi
>> +++ b/doc/guix.texi
>> @@ -2099,7 +2099,7 @@ about their support in GNU/Linux.
>>  
>>  An ISO-9660 installation image that can be written to a USB stick or
>>  burnt to a DVD can be downloaded from
>> -@indicateurl{@value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso.xz},
>> +@indicateurl{@value{BASE-URL}/guix-system-install-@value{VERSION}.x86_64-linux.iso},
>>  where you can replace @code{x86_64-linux} with one of:
>
> Sorry, this actually breaks string freeze. Now for something like this,
> we could grant an exception? It's not like it's too hard to fix, even
> manually and even if you don't know the language :)

In what sense does it break the string freeze?

I understand translations would appear as below 100% on Weblate, but I
checked guix.{fr,es,de}.info and they all read well after this change.

Am I missing something?

Thanks for commenting!

Ludo’.

Re: [bug#48173] [PATCH] maint: Do not xz-compress ISO images.

[François]

On Mon, May 03, 2021 at 02:15:22AM +0200, Julien Lepiller wrote:
> LGTM, but what should we do about the strings?

sed -i 's/\.iso\.xz/.iso/g' po/doc/guix-manual.*.po

and add that to the patch ?

(notwithstanding some misunderstanding related to how translation works
as I know nothing about that)

Re: Outreachy: Timeline tasks

[Christopher Baines]

Luciana Lima Brito  writes:

> On Sun, 02 May 2021 10:20:56 +0100
> Christopher Baines  wrote:
>
>> I think what things are happening when is relevant, but that's more
>> about understanding the hierarchy, rather than specific start and end
>> times.
>
>> Basically, although using more colours (from a gradient, like white to
>> red) would probably convey more information than just two colours.
>
> I submitted my final application. I added to it some notes on what we
> have been discussing, but I think some specific things could be better
> discussed visually with a mock up.

Great :)

> Don't you think now would be a good time for some new task? :)

As the Outreachy contribution period has now ended, there's no specific
need.

If you really want something to look at, you could investigate the slow
package metadata related query that Canan was looking in to. There's
some details in this email [1] and then later on in that same thread as
well [2].

1: https://lists.gnu.org/archive/html/guix-devel/2021-04/msg00395.html
2: https://lists.gnu.org/archive/html/guix-devel/2021-04/msg00434.html


signature.asc
Description: PGP signature

Re: Outreachy: Timeline tasks

[Luciana Lima Brito]

On Sun, 02 May 2021 10:20:56 +0100
Christopher Baines  wrote:

> I think what things are happening when is relevant, but that's more
> about understanding the hierarchy, rather than specific start and end
> times.

> Basically, although using more colours (from a gradient, like white to
> red) would probably convey more information than just two colours.

I submitted my final application. I added to it some notes on what we
have been discussing, but I think some specific things could be better
discussed visually with a mock up.

Don't you think now would be a good time for some new task? :)

-- 
Best Regards,

Luciana Lima Brito
MSc. in Computer Science

Re: Guix help page

[Luis Felipe]

Hi,

On Monday, April 19, 2021 10:13 PM, Luis Felipe  
wrote:

> On Monday, April 19, 2021 5:58 PM, Vincent Legoll vincent.leg...@gmail.com 
> wrote:
>
> > > I'll give it a shot
> >
> > Here is an (untested) attempt, is it any good ?
>
> Personally, I would add the development version of the manual as a separate 
> item in that page because the current Manual item already looks a bit crowded.
>
> So I'd have one item titled "GNU Guix Manual X.Y.Z" and another one titled 
> "GNU Guix Manual Latest" (or something like that). For the former, one can 
> use the parameter "latest-guix-version" from the "(apps base utils)" module.
>
> And I'd come up with appropriate summaries for both items.

I just sent a patch to add this (https://issues.guix.gnu.org/48187/).

Re: How is the LaTeX-related file psfonts.map installed on Guix?

[Ricardo Wurmus]

Hi Rovanion

there was a problem with the profile hook.  It only did half of 
the work that “texlive-union” normally does.  “texlive-union” is 
used for packages only, but some of the steps it performs should 
also have been done by the profile hook.


Commit a6b8794c69446730b5f12eb8eefc5ef3b99c97dc fixes this 
problem.


I saved your document in a file “doc.tex” and then ran this 
command successfully:


   guix environment --pure --ad-hoc \
 texlive-base \
 texlive-url \
 texlive-latex-hyperref \
 texlive-fonts-ec \
 texlive-lm \
 texlive-babel-swedish \
 texlive-pagenote \
 texlive-ifmtarg \
 texlive-morefloats \
 texlive-sectsty -- pdflatex doc.tex

This produces a PDF file “doc.pdf” with an almost empty page with 
the text “Notes”.


There was a warning about Babel, which may indicate some other 
problem:


--8<---cut here---start->8---
Package babel Warning: Unknown language `nil'. Very likely you
(babel)requested it in a previous run. Expect some
(babel)wrong results in this run, which should 
vanish

(babel)in the next one. Reported on input line 19.
--8<---cut here---end--->8---

--
Ricardo

Re: Bringing substitutes from the Guix Build Coordinator to users

[Christopher Baines]

Ludovic Courtès  writes:

> Thanks for your message!  It’s great to see a summary of what’s been
> cooking in the Coordinator and your vision around it.
>
> Christopher Baines  skribis:
>
>> More specifically, while the architecture is similar to daemon
>> offloading, there are some practical advantages. Since the switch to
>> Cuirass remote workers for ci.guix.gnu.org, the advantages of building
>> things across multiple machines in a coordinated manor have also become
>> clear. Additionally, there are things that the Guix Build Coordinator
>> enables, like automated retries, with the option to target specific
>> agents, which can help with avoiding issues with non-reproducible
>> failures, as well as helping to avoid issues when mixing QEMU emulated
>> and native builds.
>
> These are nice examples of current QA blind spots that would be nice to
> address.
>
> [...]
>
>> This is a topic I haven't got directly involved in, until now. I'm just
>> a volunteer, in some ways the most involved I am is that I host an idle
>> ARM build machine, I don't have any particular connection in the default
>> approach to substitutes for users, or the hardware currently
>> involved.
>
> It would be great to have that OverDrive plugged in behind ci.guix
> because we’re still short on CPU power for ARM.  (Not great we had
> forgotten about this one!)
>
> It could be reconfigured with a config similar to
> ,
> with a different host name and IP.  We can discuss the details in a
> separate thread and/or on guix-sysadmin, let me know!

It was/is being discussed, the relevant thread is here:
  https://lists.gnu.org/mailman/private/guix-sysadmin/2021-March/003487.html

>> However, I think some of the stuff I've been working on could be
>> helpful, as I say, I think the Guix Build Coordinator is a step
>> forward in terms of building things for substitutes, and that shows in
>> the substitute availability percentages.
>>
>> Is there still a path to bring some of these benefits to users, and if
>> so, what things need doing?
>
> My understanding is that, to build substitutes, we need more than the
> Coordinator; we also need something to perform evaluations, similar to
> the “top half” of Cuirass and the Data Service, right?  How would you
> envision setting it up?

The queue builds script bundled in with the guix-build-coordinator seems
to work fine, that's how bayfront is currently set up:

  (service guix-build-coordinator-queue-builds-service-type
 (guix-build-coordinator-queue-builds-configuration
  (systems '("x86_64-linux"

https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/bayfront.scm#n781

> To me, the way forward is not necessarily substitutes; it could be QA,
> as you showed that it has helpful features.  You already have access to
> bayfront and it’d be great to experiment there.  Do you have ideas on
> how to do make progress on that front?

Ideas yes, and the two things are interrelated, but my perspective at
the moment is that it'll be harder to try and get some value from the
Guix Build Coordinator in terms of quality assurance, as compared to
substitutes.

> Besides, I feel that the Data Service has a huge role to play with a
> variety of applications, including QA, but also way beyond as you showed
> in the blog post¹.  I think it’s time take advantage of it.  :-)
>
> Specifically, as far as QA is concerned, I think we should place the
> Data Service at the center of the stage.  It already does things that
> Cuirass cannot and will not do, notably: linting, challenging substitute
> servers to estimate reproducibility, and recording the history of all
> this.  Couldn’t it gather these other QA metrics mentioned above,
> possibly from a Coordinator-powered bayfront?

To me, linting and substitute comparison are less important quality
assurance things. I think the key issues are around testing packages and
things like system tests.

There's been some progress, albeit slow progress with the patch testing
setup I've been working on, but I've been viewing that as a way to test
branches as well. Given changes happen through patches and branches, I
think this makes sense, and I think the Guix Data Service has some nice
features for helping with this, like comparing two revisions and working
out what breakages have occurred.

However, with patches and branches, this is very much a continuous
integration tooling issue, much more than substitutes. Cuirass is
already building branches, and it's been gaining features previously
found in the Guix Data Service, like tracking the history of which
derivations relate to which revision, and separating out packages from
system tests so that it's easier to look at them.

As people are going to Cuirass to look at the build status for packages,
system tests and various branches, the problem is similar to that of
substitutes. It doesn't matter if the Guix Build 

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

[Leo Prikler]

Hi Mark,

Am Montag, den 03.05.2021, 05:00 -0400 schrieb Mark H Weaver:
> Leo Prikler  writes:
> 
> > Am Samstag, den 01.05.2021, 23:13 -0400 schrieb Mark H Weaver:
> > > I don't think I fumbled on the facts at all.  It's true that I
> > > didn't
> > > yet have _all_ of the relevant facts, but as far as I know, every
> > > fact that I presented is true.
> > > 
> > > If you disagree, can you please provide a counterexample?
> > 
> > In your very first message you made it seems as though Raghav
> > single-
> > handedly authored and pushed the changes in question and called
> > into
> > question their reliability as a committer.  The former was based on
> > "facts", that turned out half-true – Raghav did push that commit,
> > but
> > they did so thinking that Léo did proper review, which they did not
> > –
> 
> Here, once again, you've failed to point out any of my *actual* words
> to back up your (bogus) claim that I "fumbled on the
> facts".  Instead, you speak of how I "made it seem".  You put more
> words into my mouth.
If you want to read your actual words, they were
> Behold, Raghav's "cosmetic changes" to our 'cairo' package
Again, those were not Raghav's changes, they were added by Léo and
"once again" pushed by Raghav, who trusted them on the matter.  You
made an incorrect assumption based on incomplete information.  I call
that fumbling.  It was an honest mistake based on the facts you thought
present at the time, but nonetheless a mistake.

Please don't assume I'm acting in bad faith and throw around words like
bogus lightly.  I don't think I'm making any extraordinary claim here,
my statements should follow from the words themselves or the
interpretations of a casual observer.  I am not aiming to grossly
misrepresent you here, I'm trying to help you find an answer to the
question 
> Is it possible that you read more in my messages than I
> actually wrote?
The answer is "Yes, always".  People don't just derive raw information
from messages, there's all sorts of other cues – including social cues
– that swing with them.  Even in newspaper articles or scientific
literature, there is such a thing as framing.  You absolutely have to
consider many forms of subtext both when reading and when writing.

I hope this clears up any remaining misconceptions.  If not and you're
fine having me as conversation partner, I'm still willing to answer
(some) questions off-list.  Again, I am not attacking you for calling
attention to an objectively bad commit, I think it was right of you to
do so.  All of what I'm saying here should at worst be seen as
"criticism of your tone".

Regards,
Leo

Re: RISC-V is giving away developer boards

[Ekaitz Zarraga]

> Could interested developers raise their hands?  :-)

Me: raises hand

Re: How is the LaTeX-related file psfonts.map installed on Guix?

[Andreas Enge]

Hello,

as a quick fix, you can install the (huge) texlive package, which in one
place contains the full texlive distribution. Your document compiles with
pdflatex then.

Am Sun, May 02, 2021 at 05:03:18PM +0200 schrieb Rovanion Luckey:
> \usepackage[colorlinks=true, linkcolor=blue, urlcolor=blue]{hyperref\
> }

(After dropping the "\" after "hyperref", which I assume sneaked in through
email formatting.)

There may be a way using less space, but at least this one works.

Andreas

Re: Criticisms of my "tone" (was Re: A "cosmetic changes" commit that removes security fixes)

[Mark H Weaver]

Hi Leo,

I think we're mostly going in circles at this point, so I think we
should finish up this conversation, as Ludovic suggested.  I'll let you
have the last word on most of our conversation threads, but I feel
compelled to briefly counter one claim of yours:

Leo Prikler  writes:

> Am Samstag, den 01.05.2021, 23:13 -0400 schrieb Mark H Weaver:
>> I don't think I fumbled on the facts at all.  It's true that I didn't
>> yet have _all_ of the relevant facts, but as far as I know, every
>> fact that I presented is true.
>> 
>> If you disagree, can you please provide a counterexample?
>
> In your very first message you made it seems as though Raghav single-
> handedly authored and pushed the changes in question and called into
> question their reliability as a committer.  The former was based on
> "facts", that turned out half-true – Raghav did push that commit, but
> they did so thinking that Léo did proper review, which they did not –

Here, once again, you've failed to point out any of my *actual* words to
back up your (bogus) claim that I "fumbled on the facts".  Instead, you
speak of how I "made it seem".  You put more words into my mouth.

That's not nice.  Please stop it.

 Thanks,
   Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about .

Re: Guix Home upstreaming plan

[Andrew Tropin]

Xinglu Chen  wrote:

> WDYT Andrew?

As I said, a few months should be enough, but I hope we will accomplish
it faster)

Re: Guix Home upstreaming plan

[Andrew Tropin]

Hi Ludovic, 

Ludovic Courtès  wrote:

> So, I have yet to go ahead and use it for myself to get a better feel.
> In the meantime, I looked at
> , and I like what I
> see!  It’s great that you already have clear documentation and that
> everything looks consistent with the rest of Guix.

> Since this kind of tool is rather unusual (there’s no real equivalent
> I’m aware of in other distros), I think the manual will have to
> carefully explain what problems this solves and explain why someone
> would want to use it.  For example, I think the term “home environment”
> should be defined upfront (I’d summarize it as user configuration files
> + user services, from my reading.)

Sounds reasonable, added a TODO note for that.

> I’m all for it.  We’ll have to discuss it together, in particular among
> maintainers, but an option would be to give you commit access for the
> purposes of developing this branch.

Sound good to me.  We still have some work to be finished before
upstreaming, but hope we will be good to go by the time other
maintainers will reply.

> I would also like to know what Julien thinks; I think it’s in our
> interest to see cooperation and not competition between the two
> approaches you developed.  Julien, WDYT of the plan?  More specifically,
> is there anything about the design that you’d like to discuss before we
> go further?  Are there guix-home-manager features that could eventually
> make it in Guix Home?

BTW, from time to time people ask about read-only home feature) I reply
that it is theoretically possible, but probably won't be implemented
anytime soon.

> I find the steady progress on Guix Home and the level of polish already
> achieved pretty exciting.  If people agree, I think we could aim for
> merging it in the next Guix release, which would leave us a few months.

Thank you for kind words!)  A few months should be enough.  Looking
forward to see other maintainers thoughts.

> Thank you!

Sure!

Re: A "cosmetic changes" commit that removes security fixes

[Pierre Neidhardt]

Hi Giovanni,

> Guix is a GNU project and AFAIU GNU project management is well
> documented:
>
> https://www.gnu.org/gnu/gnu-structure.html

This applies to GNU at the top level, but it does not specify how
sub-projects (referred to as "packages" in the aforementioned document)
are governed locally.  This question is mostly left unanswered as I
understand it.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature

Re: A "cosmetic changes" commit that removes security fixes

[Pierre Neidhardt]

Hi!

Yasuaki Kudo  writes:

> I don't know the details of the case at all but let met mention this:
> https://communityrule.info/
> It comes from the world of worker cooperatives and I think them "rules of the 
> community" is discussed a lot there as well 

Thanks for sharing, I didn't know about this!
I think it's a great starting point.  I like these ones in particular:

https://communityrule.info/create/?r=consensus
https://communityrule.info/create/?r=jury

communityrule.info helps identifying different types of governance, with
different strategies to various decision problems.

Let's note this down and bring it back up in a thread that's more
focused on the governance question of Guix.

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/


signature.asc
Description: PGP signature