Re: Is git the best tool for pulling packages?

[Leo Famulari]

>From a computational perspective, downloading tarballs is much simpler than 
>fetching from Git.

But Git offers so many advantages, and computing has become so inexpensive, 
that it's become very common to use Git instead.

Recent Git implementations have optimized serving of specific Git commits, as 
compared to fetching the entire Git history. That means that you can fetch a 
single revision of a huge repo, using a small amount of bandwidth.

For the specific case of `guix pull`, the Git server is hosted at Savannah, 
which does not use one of these optimized Git implementations, so it is 
relatively slow and expensive to fetch.

Additionally, Guix's authentication mechanism requires fetching many Git 
revisions in order to verify the chain of trusted revisions (Git commits).

This requirement to fetch many Git revisions, combined with the unoptimized Got 
server on Savannah, means that `guix pull` may be slower than comparable 
actions on other distros, especially the first time, and if you haven't pulled 
in a while 

On Sun, Apr 21, 2024, at 18:31, Adam wrote:
> Hi guix!
> Recently I used nixos on one of my machines. And I noticed people there use 
> tar balls for fetching package definitions. And It worked much faster for me.
> That was surprising and I decided to write this letter.
> Is git the right tool for getting new package definitions? What if git 
> commits history will become enormous? 
> As I see, first guix pull running too long for a lot of people.
> Probably there are ways to cache all of this.
> Anyway,  I'm just curious about it. If there are already answers for my 
> question, I would like to read them.

Re: Adding plumbing subcommand 'derivation'?

[Leo Famulari]

On Sat, Apr 13, 2024 at 12:32:45PM +0200, Simon Tournier wrote:
> So I propose to add the plumbing command ’derivation’.  Any objection?

Sounds good to me, but give it a couple days for everyone else to ponder
the bike shed ;)

Re: Guix extension to display derivation (and rewrite fixed-output)

[Leo Famulari]

On Fri, Apr 12, 2024 at 08:28:11PM +0200, Simon Tournier wrote:
> Therefore, I wrote a very simple Guix extension [1] that outputs
> derivation content using recutils format.

Amazing! That's so useful.

> Do you think it would be useful to package it?  Or maybe to include it
> as another subcommand (or part of some subcommand)?

I'd love for this to be built in to Guix. I'm often struggling to read
derivations while debugging or analysing something.

Re: xz backdoor

[Leo Famulari]

On Mon, Apr 01, 2024 at 09:46:12PM +0200, Reza Housseini wrote:
> Just stumbled upon this recently discovered supply chain attack on xz,
> inserting a backdoor via test files [1, 2]. And it made me wondering, what
> would have been the effects on guix and how can we potentially avoid it?

There's actually suspicious code by the xz attacker in one of our
packages right now:

https://issues.guix.gnu.org/issue/70113

Please help review that patch!


signature.asc
Description: PGP signature

Re: Rust team branch merged

[Leo Famulari]

On Thu, Feb 29, 2024, at 02:11, Efraim Flashner wrote:
> * Most of the packages in rust-apps have been upgraded.
> * rav1e was upgraded from 0.6.6 to 0.7.1
> * dav1d was upgraded from 1.0.0 to 1.3.0
> * libaom was upgraded from 3.5.0 to 3.8.0

Thanks for updating these AV1 video packages!

Re: Guix Days: Patch flow discussion

[Leo Famulari]

On Mon, Feb 5, 2024, at 04:39, Steve George wrote:
> Our goal for the discussion:
>
>   How do we double the number of patches that are *reviewed* and
>   *applied* to Guix in the next six months?
>
> Patch flow is a pipeline, to change it we could:
>
> a. Increase the number of committers - more people to do the
> work
> b. Increase the efficiency of existing committers
> c. Open the gates by decreasing the quality expected from patches

Hi George,

It's an important subject and, in my opinion, more important than any technical 
questions at this stage of the project.

However, I think the question assumes that all contributions should be 
accepted, and that the entire problem is that we are not accepting them 
efficiently enough. We should not unconsciously accept this assumption.

Guix can reject contributions, either in a general way (we don't want that type 
of thing in Guix), or due to specific reasons (the code is not idiomatic, the 
contributor can't work effectively with the rest of the group, etc).

Leo

Re: Welcome Oleg (sharlatan) as a new committer

[Leo Famulari]

On Tue, Jan 09, 2024 at 11:19:51PM -0500, Maxim Cournoyer wrote:
> Hello Guix!
> 
> I'm happy to start the 2024 year with a new committer onboard: Sharlatan
> (Oleg).
> 
> Sharlatan is maintaining a growing collection of astronomy packages in
> Guix, among others.
> 
> Let's Wish them a warm welcome!

Welcome aboard!

Re: bug#67790: New signing key

[Leo Famulari]

On Fri, Dec 15, 2023 at 06:06:26AM +, John Kehayias wrote:
> I suppose I should have been more specific than "something bad" :) I
> merely meant this wasn't an actual security issue of losing control of
> a private key, but merely moving to a new one for other reasons.

The old key "expired" last summer. I had been faking the date for months
to work around that. I did not feel motivated to change the expiration
date or to remove the expiration date either :)

It was easier to make a new key.

Re: bug#67790: New signing key

[Leo Famulari]

On Wed, Dec 13, 2023, at 22:17, John Kehayias wrote:
> And I assume all this was just to use a new key (did I see some
> mention of subkeys on #guix? that's what I use) and not because of
> something bad happening to the old one right?

I don't know if anything bad happened to the old key. That's fundamentally 
unknowable. But I decided to start using a new key.

Re: bug#67790: New signing key

[Leo Famulari]

On Tue, Dec 12, 2023 at 12:02:33PM -0500, Maxim Cournoyer wrote:
> Note that I believe you can simply update to your new key yourself.
> You'll want to add your new key to the keyring branch, then adjust the
> .guix-authorizations file with its new keygrip.

Thanks, I pushed to 'keyring' as
935e3c9e93548a566cf3b3039b0822d4179974e4, and to 'master' as
4c4222f32a2906b7bcab74fab70ff2c2f152e8eb.


signature.asc
Description: PGP signature

New signing key

[Leo Famulari]

Hello,

I'm changing my Guix signing key from
B0515948F1E7D3C1B98038A02646FA30BACA7F08 to
68407224D3A64EE53EAC6AAC1963757F47FF.

Patches to follow. Testing is appreciated!

Leo


signature.asc
Description: PGP signature

Re: Ext4 corruption in some stable kernels

[Leo Famulari]

On Mon, Dec 11, 2023 at 11:30:10AM +0800, Hilton Chain wrote:
> On Mon, 11 Dec 2023 08:13:58 +0800,
> Leo Famulari wrote:
> >
> > Everyone with commit privileges should feel free to push these patches to
> > master if they seem okay. I won't be able to help today.
> 
> 
> OK, I have applied "[PATCH 2/8] gnu: linux-libre 6.1: Update to 6.1.66." from
> #67724 as 65334547674bdaeb75eb37ffbe23ba6f9fd486b1 and pushed.

Thank you for this and the subsequent update! I'm preparing to push the
remainder now.

Re: Ext4 corruption in some stable kernels

[Leo Famulari]

Everyone with commit privileges should feel free to push these patches to 
master if they seem okay. I won't be able to help today.

Leo

On Sun, Dec 10, 2023, at 00:35, Hilton Chain wrote:
> Hi Felix (and Leo, Cc-ed)
>
> On Sun, 10 Dec 2023 11:00:47 +0800,
> Felix Lechner via Development of GNU Guix and the GNU System 
> distribution. wrote:
>>
>> Hi,
>>
>> It's possible Guix never shipped the affected "stable" kernels, but a brief
>> pointer seemed appropriate. For details, please see here. [1]
>>
>> Kind regards
>> Felix
>>
>> [1] https://lore.kernel.org/stable/20231205122122.dfhhoaswsfscuhc3@quack3/
>>
>
> From the linked thread and report in Debian[1], 6.1.64 (and maybe 5.10.202 +
> 5.15.140) are affected.  Unfortunately we have shipped them for about 1 week.
>
> Leo has sent #67724 yesterday to update kernels, maybe we can merge updates 
> for
> these three versions quicker?
>
> Thanks
> ---
> [1]: https://micronews.debian.org/2023/1702150551.html

Re: role of core-updates

[Leo Famulari]

On Mon, Nov 27, 2023, at 01:53, Andy Tai wrote:
> Hi, hope Guix maintainers can clarify the role of the now core-updates
> branch; the current documentation does not specify the core-updates
> branch as a thing but there are clearly interests and uses of this
> branch for package updates not belonging to a feature branch like
> gnome and it is useful for, say, updating to the GNU make package
> which would have caused world rebuild.  Thanks

Hi!

I'm not a maintainer but I did suggest the new 'feature branch' workflow so I 
will speak up.

The core-updates branch was / is for updating core packages, which are listed 
here:

 https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/ci.scm?h=v1.4.0#n136

Perhaps other packages like 'make' could be considered honorary members of this 
group as well, or maybe some other workflow can be imagined by the project.

I hope that helps!

Leo

Re: Upgrading Guix's security team

[Leo Famulari]

On Wed, Nov 22, 2023 at 07:16:21PM +0100, Ludovic Courtès wrote:
> Leo, Tobias, and John: What would be a good end-of-term date for each
> one of you?  As I see it, it wouldn’t mean you cannot do an additional
> term but rather that you’ll have an opportunity to leave and that you’ll
> do your best to be around by then.

I think my end date should be ASAP. I'm sure everyone noticed that I
haven't been very involved in Guix lately, and I don't know when I can
be more involved again.

Re: Need people to help with kernel updates

[Leo Famulari]

Hello everyone,

It seems that linux-libre 6.6 will be released soon.

Would anyone like to try their hand at packaging it for Guix? Wilko, do
you feel up to it?

As I mentioned previously, this requires a bit more work than minor
kernel upgrades because the kernel configs need to be updated.

I'm happy to assist with this, give advice, etc.

Leo

Re: Need people to help with kernel updates

[Leo Famulari]

On Thu, Oct 12, 2023 at 02:15:41PM +0200, Wilko Meyer wrote:
> seems to be good again at least, as in:
> 
> - it builds locally
> - QA[1] looks okayish as far as I can tell (no lint warnings, build
>   statuses look good on more common ISA)

I agree, this already counts as "good".

I pushed your patches as 06acda9715711c406f30b3a314387002244d8792

> even though we still seem to have partial build failures on some
> architectures:
> 
> - x86_64-linux and aarch64-linux build completely fine according to QA
> - without any failures or unknown status
> - i686-linux has mostly succeeding builds, 5 unknown
> - armhf-linux has one failing and 18 unknown

Things are even better since you wrote!

The only failure is of a quasi-obsolete wireguard package on i686.
Newer kernels don't require this package to provide an out-of-tree
Wireguard driver.

I see that ppc64le is still "unknown", which in this case means that the
builds are scheduled but haven't been performed yet.

Overall, the fact that qa.guix.gnu.org is successfully building across
so many architectures means that we have a strong foundation for the
future of building kernel packages in Guix.

Thanks you for taking the initiative to write the patches and manage QA
for this latest round of updates!

I'm curious, now that we've done a round, do you have any thoughts about
the work so far?

Re: Need people to help with kernel updates

[Leo Famulari]

On Mon, Oct 9, 2023, at 12:21, Wilko Meyer wrote:
> I've seen the recent thread on making linux-libre
> 6.5 the default kernel[0] and will have some time at hand later on
> today. I could try to prepare a patch set doing this to get more
> familiar with the process, which would then need a review. WDYT?

There's actually a patch for this already:

https://issues.guix.gnu.org/66409

But it seems to have failed the QA process:

https://qa.guix.gnu.org/issue/66409

Are you able to try applying the patch on the master branch and reporting back? 
I figure that double-checking that it applies is the first to figuring out 
what's gone wrong.

On CI, at least the 6.5.6 kernel package was built:

http://ci.guix.gnu.org/eval/831643

Re: Making linux-libre@6.5 the default kernel

[Leo Famulari]

On Mon, Oct 9, 2023, at 03:20, Ada Stevenson wrote:
> So, to make things clear, the delay in making 6.5 the default kernel is 
> in part because you lack sufficient support in the case that things go 
> wrong or some urgent change needs to be pushed? 

There's almost never anything wrong, but I haven't even had the time to 
download the upstream updates, calculate the hashes, prepare patches, push to a 
staging branch, wait for results from CI, then push to master. Or to put it 
another way, I haven't wanted to use the time I have available.

Re: Making linux-libre@6.5 the default kernel

[Leo Famulari]

On Tue, Oct 03, 2023 at 11:05:40AM +, Ada Stevenson wrote:
> Hi Guix!

Hi!

> I understand why that may be; the commit is quite new, and pushing new
> kernel versions on everyone is a pretty big thing. I just want to know what
> the timeline on this sort of thing is - when can we expect the new 6.5
> kernel to become the default?

Thanks for asking about this. The reason is that I haven't had enough
time to make these changes lately, and for a while I have been the only
person updating the kernel in Guix.

I'd like for more people to join the effort, and there's some info about
that subject here:

https://lists.gnu.org/archive/html/guix-devel/2023-10/msg00079.html

Re: Need people to help with kernel updates

[Leo Famulari]

On Sat, Oct 07, 2023 at 08:31:58PM +0200, Wilko Meyer wrote:
> I could imagine myself helping with these tasks. Practically this means,
> that, whenever a new linux-libre minor update is being released, the
> versions in linux-libre-* packages in gnu/packages/linux.scm have to be
> bumped/a patch has to be sent?

Yes, the hashes of the kernel source code and linux-libre's "deblobbing"
scripts have to be updated. I have some scripts that fetch and calculate
the hashes (attached).

> Also: Is there anything to know/to have in mind when generating a new
> kernel config for major releases?

My workflow is to check out the upstream source code, copy the previous
version's configuration file into the source tree, create a development
environment with `guix shell -D linux-libre`, and then do `make
oldconfig`.

The idea with a distro kernel configuration is to make it as generically
useful as possible. That means enabling support for all kinds of
hardware and picking sensible defaults (which are usually the upstream
default).

I use the cateee.net website to get a little more info about things I
don't understand, and use Google and LKML to go beyond if necessary.
Cateee.net has references for every kernel configuration option. For
example:

https://cateee.net/lkddb/web-lkddb/HSA_AMD.html

If I'm really puzzled I ask on IRC or the mailing list, but this is a
"best effort" kind of task. In my several years with Guix, the kernel
config has occasionally received feedback.

I'm not a kernel developer or expert. The upstream defaults for kernel
'settings' are sensible. We usually differ from the defaults by enabling
support for lots of hardware.

> How's the coverage for different ISA? Do the current CI jobs also cover
> all the architectures we seem to support:
> 
> '("x86_64-linux" "i686-linux" "armhf-linux"
> "aarch64-linux" "powerpc64le-linux" "riscv64-linux")

There's a 'kernel-updates' jobset for ci.guix.gnu.org that builds off
the 'kernel-updates' Git branch:

https://ci.guix.gnu.org/jobset/kernel-updates
https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/modules/sysadmin/services.scm?id=8fa8d6affb7702fa81c795de5625c7b7938fae85#n359

And qa.guix.gnu.org will build any patches that are submitted to the
mailing list.

To be honest, I only pay attention to x86_64-linux and i686-linux. The
build farm don't reliably build the kernel packages for other
architectures (not even the source code!) on the build farm and nobody
has stepped up to make sure the kernel packages build there.

My impression is that x86_64-linux is by far the most popular platform
for Guix users, and then aarch64-linux, and then the rest.

My understanding of kernels for aarch64-linux is that the 'generic'
kernel packages work better for users than the packages built with the
Guix kernel configs, and that's fine. The 'generic' kernel configs are
generated automatically.

Architectural support is a problem of the type "What came first: the
chicken or the egg?" So, if anyone wants to improve support for these
other architectures, you'll be making an egg from scratch, in the hope
that people will start using the kernels :)

> or are there cases where it could be beneficial to build locally first
> using:
> 
> guix build -s $ISA linux-libre
> 
> for certain ISAs? I could use my workstation for this, if there's a
> benefit to it.

I don't do this, but it wouldn't hurt! I just use the resources on CI
and QA. I do build my own x86_64-linux kernels for my own machines, as a
minor "full test", but that's not expected to join in this work.

> How would the communication around this be organized? If n>=2 people are
> trying to work on the same set of tasks duplication may happen.

I invite you to choose, email or IRC :)

To summarize, this work needs regular but brief attention. There's not
much feedback from the community, so we do our best and make sure the
basics work before pushing (reboot and connect to the internet). I'm
eager to help grow the community of people working on this, and can help
answer questions and give advice about things like the configs.

Leo


linux-libre packaging scripts.tar.xz
Description: Binary data

Need people to help with kernel updates

[Leo Famulari]

Hello,

For a few years, I've been handling updates of the linux-libre kernel by
myself. Now I want some more people to help with this.

The work itself is fairly mechanical and updates occur about once a
week. It takes about 30 minutes to prepare the patches and push them to
CI or send them to the mailing list.

When a new major kernel version is released, then we also need to make a
new kernel config file, which takes a few hours in total.

There is plenty of support for the CI and QA infrastructure to build the
kernels, so you don't need a powerful computer.

This isn't the sort of the task that needs to be performed by a single
person. The work could be spread, like most other packages in Guix.

If you want to join in, please reply!

Leo

Re: About donation to GNU Guix project

[Leo Famulari]

On Sun, Jun 11, 2023 at 09:43:52PM -0400, Maxim Cournoyer wrote:
> Donating hardware is a bit tricky because it needs to be hosted
> somewhere, but it can be discussed and welcome, especially if the
> hosting can also be provided somehow (we have a couple machines running
> in people's home connecting via a WireGuard tunnel to the build farm
> from which we can get packages built via Cuirass).

+1

Donation of hosting may be more impactful than donating hardware.

Thanks for your interest!

Re: Rebasing or merging? [was: Re: 01/03: gnu: wxwidgets: Add libxtst to inputs.]

[Leo Famulari]

On Sun, Jun 11, 2023 at 08:47:54PM -0400, Maxim Cournoyer wrote:
> I'm not sure how that'd work, since Git only allows a single PGP
> signature per commit, as far as I can tell.  When you rewrite the
> history (by using rebase, say), the existing signatures of the rewritten
> (rebased) commits are replaced with new ones generated from your key.

Is it so bad to re-sign commits on feature branches that we should lose
the easy-to-read history of rebased branches?

To me, it's much easier to understand and review a branch that has been
updated by rebasing rather than merging. I think that counts for a lot.
Do many people feel the same way?

Re-signing the commits is messy but I don't think there's even been a
consensus that it's very bad.

I think that re-signing commits while rebasing is consistent with our
security model which (as I understand it) considers committers' and their
machines to be trusted. And that the meaning of the signature is merely
that the committed changeset was definitively made by someone with the
key.

Re: Should commit signing always be required for local work? [was Re: bug#63261: Recent changes to git config cause errors for non-committers]

[Leo Famulari]

On Fri, May 19, 2023 at 11:34:35AM +0200, Josselin Poiret wrote:
> I'm curious Leo, in general (not Guix because we have a pre-push hook),
> how do you make sure you always publish signed commits?  I don't want to
> put unsigned commits anywhere except locally, but it feels like I might
> just forget to sign them before pushing.

In general, I don't rigorously sign Git commits for projects that aren't
Guix.

You could set "gpgsign = true" in '~/.gitconfig'.

I do sign commits sometimes for non-Guix projects, but without a
code-authentication system like Guix's, I don't perceive a strong reason
to always sign commits.

There is *some* reason to always sign commits, which is to provide an
unambiguous statement of authorship / provenance. But, it doesn't seem
like most projects have a mechanism with which to derive value from the
signatures. Also, it doesn't seem like there is much demand for this, in
general.

Git itself offers nothing, so each project has to design their own
solution. I doubt many projects would consider that effort to be
worthwhile. Instead they rely on the access controls of their
centralized repo, typically Github, and Github's security seems fine in
practice.

I think that Guix is pushing the state of the art here.


signature.asc
Description: PGP signature

Should commit signing always be required for local work? [was Re: bug#63261: Recent changes to git config cause errors for non-committers]

[Leo Famulari]

On Mon, May 15, 2023 at 09:38:33AM -0400, Maxim Cournoyer wrote:
> Hi Leo,
> 
> Leo Famulari  writes:
> 
> > Can someone help me by pointing to the original discussion of this
> > change?
> 
> It was the team.scm issue in https://issues.guix.gnu.org/58813 that led
> to this change.

Thanks for pointing it out.

In my opinion, this change should be discussed more publicly so that a
consensus can be reached about it.

This change affects the workflow of everyone that hacks on Guix,
including people who are trying it for the very first time.

It's a big change.

It's not okay to only discuss such a big change in a ticket with the
title "can't substitute etc/teams.scm command as doc suggests".

I am asking for this to be reverted until a consensus is reached.

Re: evince: Is this a bug?

[Leo Famulari]

On Tue, May 02, 2023 at 01:43:35AM +, jgart wrote:
> Is this a bug?
> 
> $ evince
> 
> (evince:8881): Gtk-WARNING **: 20:41:52.851: Could not load a pixbuf from 
> icon theme.
> This may indicate that pixbuf loaders or the mime database could not be found.
> **
> Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed 
> (error == NULL): Failed to load 
> /gnu/store/vkcl29s7qcfgqz1cs6lab98fyxsxyczx-adwaita-icon-theme-43/share/icons/Adwaita/48x48/status/image-missing.png:
>  Unrecognized image file format (gdk-pixbuf-error-quark, 3)
> Bail out! Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion 
> failed (error == NULL): Failed to load 
> /gnu/store/vkcl29s7qcfgqz1cs6lab98fyxsxyczx-adwaita-icon-theme-43/share/icons/Adwaita/48x48/status/image-missing.png:
>  Unrecognized image file format (gdk-pixbuf-error-quark, 3)
> 
> I have gnome-desktop-service running fine that brought with it evince

Did this start happening after the recent merge of core-updates?

Re: Setuid handling?

[Leo Famulari]

On Tue, Apr 25, 2023 at 09:21:52AM -0700, Felix Lechner via Development of GNU 
Guix and the GNU System distribution. wrote:
> Well, the home profile ends up being first here:

That's wrong on Guix System.

Check your user's shell initialization files, such as ~/.bash_profile,
~/.profile, ~/.bashrc. If you are using something besides Bash, adjust
accordingly.

Something is changing your $PATH in a way that is broken on Guix System.

Re: Core-updates merge

[Leo Famulari]

Thank you for leading this effort!

The value of leadership and project management is sometimes underappreciated in 
software projects, but they are essential for our success.

On Tue, Apr 25, 2023, at 10:09, Andreas Enge wrote:
> Hello all,
>
> I have just merged core-updates into master and deleted the branch!
> This has been a long adventure, which became particularly intensive
> after the last Guix Days in February. First and foremost many thanks to
> everyone who contributed to the branch, be it by commits, discussions or
> by working on the infrastructure.
>
> Each and every package is not yet in shape; please feel free to submit
> patches for your favourite packages that fail to build. In particular:
> - python-yubikey-manager does not build currently; work to correct this
>   is underway.
> - R on powerpc does not build; this will also be corrected soon;
> - aarch64 has very few substitutes; I think this is mainly due to the build
>   farm catching up and not so much to packages not building, but this is
>   difficult to know.
> If any of these are essential to you, you may wish to wait a little bit
> longer before a "guix pull", or for the time being pull to a commit just
> before the merge by issuing
>guix pull --commit=472706ae2f9160833951a4e4bcc4c206e03097b0
>
> Every end of a story is the beginning of many new ones. Several areas of
> work have already been identified; I will summarise what came up on the
> mailing list and who expressed interest to work on it - please feel free
> to join if a topic interests you, or launch another initiative if you
> want to work on a different subject!
> - rust-team already has a branch that is almost ready to be built and
>   merged, as a precursor to the team based workflow that we need to invent
>   (Efraim Flashner).
> - R on powerpc64le needs to be built by changes to valgrind and lz4
>   (Simon Tournier, I).
> - Many Python packages need updates, in particular with the aim of building
>   python-yubikey-manager (John Kehayias, Lars-Dominik Braun, Brian Cully).
> - There is still work to do to bootstrap GHC until the latest version on
>   i686, and to potentially shorten the bootstrap chain (Lars-Dominik Braun).
> - OCaml could be simplified by dropping version 4.07 (Julien Lepiller).
> - After the mesa update is before the mesa update, and it looks like more
>   features can be enabled (Kaelyn Takata, John Kehayias).
> - Too much in Guix depends on too much else, which makes building things
>   needlessly entangled; in particular time zone data should not be referred
>   to by packages, but be loaded at runtime (Leo Famulari).
>
> All the best in your Guix endeavours,
>
> Andreas

Re: Ungrafted dependency

[Leo Famulari]

On Fri, Apr 21, 2023 at 11:11:07AM -0400, Greg Hogan wrote:
> mariadb is grafted on master. Why does libreoffice depend on the
> ungrafted mariadb rather than the grafted version? And, perhaps
> related, since libreoffice depends on mariadb's "dev" output, why does
> libreoffice pull in "out"? mariadb:dev was created specifically as a
> libreoffice dependency in the commits referenced by 2c9d3416.

Thanks for pointing this out.

TLDR: Libreoffice does not depend on the ungrafted mariadb. But there is
something weird going on.

First, to be clear, mariadb is not itself grafted on the master branch
as of commit 13ebf5e36cc676627a19072d3712c399b7aae61f (currently the
latest commit).

The package variable 'mariadb' in 'gnu/packages/databases.scm' does not
contain a '(replacement ...)' field. There are not any replacements in
the databases module at all.

However, the mariadb package is affected by other package grafts, as you
saw when building it with and without grafting enabled:

--
> $ guix build mariadb
> /gnu/store/3ygd7xks9glpnppjs3ir9q9py3cqr14f-mariadb-10.10.2-dev
> /gnu/store/0a1v0adgk43552hnjcy13pn4yj7rcimh-mariadb-10.10.2-lib
> /gnu/store/iyns06rxvm865a3fp7dclm2q2ff0nay8-mariadb-10.10.2
> 
> $ guix build --no-grafts mariadb
> /gnu/store/fjk994z0s3g429napn7cxgrdvqgbrj6p-mariadb-10.10.2-dev
> /gnu/store/08nbg7cm6fqkyxls5ap5p1ypr1s2f988-mariadb-10.10.2-lib
> /gnu/store/cdsdm8mqs13hp3pf013q1i4lka19g1sc-mariadb-10.10.2
--

Moving on to the specific case:

--
> $ guix size libreoffice
--

Now, I'm not totally sure, but I don't think that `guix size` is aware
of grafts, but I don't think it is, due to reasons:

https://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/size.scm?id=13ebf5e36cc676627a19072d3712c399b7aae61f#n317

However, the correct way to inspect run-time dependencies of store items
on your system is `guix gc --references`, for example like this:

--
$ guix gc --references $(./pre-inst-env guix build libreoffice) | grep mariadb
/gnu/store/6xn39pwxa4rqjf43di84fyrvr90sfw54-mariadb-10.10.2-lib
/gnu/store/hdz68bigrndswi0kh2mn8rbf3lbfpxmp-mariadb-10.10.2-dev
$ guix gc --references $(./pre-inst-env guix build --no-grafts libreoffice) | 
grep mariadb
/gnu/store/08nbg7cm6fqkyxls5ap5p1ypr1s2f988-mariadb-10.10.2-lib
/gnu/store/fjk994z0s3g429napn7cxgrdvqgbrj6p-mariadb-10.10.2-dev
--

These 'references' are the actual strings in the store items that point
to other store items.

We see that, with grafts enabled, libreoffice does not refer to the
ungrafted mariadb.

Instead, it refers to some other mariadb, and I don't know where that
comes from. I wonder if libreoffice depending on `(,mariadb "dev")
accidentally creates a new derivation:

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/libreoffice.scm?id=13ebf5e36cc676627a19072d3712c399b7aae61f#n1120

If so, that's a bug. Any ideas?

Re: staging branch merged to master

[Leo Famulari]

On Fri, Apr 14, 2023 at 03:29:01PM -0400, Maxim Cournoyer wrote:
> The staging branch has been merged to master.

Thanks! 

> Should we remove the branch from Cuirass and Guix, knowing that teams
> is the way going forward?

I am in favor!

Re: [core-updates] It would be nice to fix libsndfile CVE-2021-3246 (arbitrary code execution via crafted WAV file)

[Leo Famulari]

On Wed, Apr 05, 2023 at 10:46:05AM +0200, Andreas Enge wrote:
> Well, an update causes a lot of rebuilds anyway. The NEWS of 1.2.0 look
> like it is in fact only a bugfix release, so I took the risk to update to
> this latest version. pulseaudio still compiles, and pavucontrol still works
> on my machine.
> 
> The update is pushed to core-updates, but I would suggest to keep the bug
> open until it is merged to master.

Thank you Andreas!

[core-updates] It would be nice to fix libsndfile CVE-2021-3246 (arbitrary code execution via crafted WAV file)

[Leo Famulari]

See , which was never applied
anywhere. Like I said in that thread, I no longer understand the patch,
but I guess it's enough to update libsndfile to 1.1.0 on core-updates.

Re: Contributing guide building from git make check failure

[Leo Famulari]

On Tue, Mar 28, 2023 at 04:42:25AM +, Philip Nelson wrote:
> I've been following the Contributing guide "Building from Git" section (
> https://guix.gnu.org/manual/devel/en/html_node/Building-from-Git.html). I
> get as far as `make check` but it fails on the following test. Others on
> IRC have reported this issue. I'm unsure how to proceed. Any suggestions?

Thanks for your report! I forwarded it to the bug tracker:

https://issues.guix.gnu.org/62594

Re: Syntax and gexp for ff5f34ae757d709987896d6164bf125319a0f764

[Leo Famulari]

On Fri, Mar 31, 2023 at 10:15:06AM +0200, Josselin Poiret wrote:
> >> files).  I would suggest a good old `grep -Rl --include '*.go'
> >> perl-extutils-pkgconfig ./gnu | xargs rm`.
> >
> > I saw this error too, but it went away after `make clean-go && make`.
> 
> Don't want to praise myself too much, but the above command should only
> delete .go files which contain references to perl-extutils-pkgconfig,
> thus avoiding a rebuild of all go files!

That's much better :)

Re: Comparison of branches on CI

[Leo Famulari]

On Thu, Mar 30, 2023 at 07:59:49AM -0400, Leo Famulari wrote:
> It is possible to use data.guix.gnu.org to create these comparisons. 
> Sometimes it takes me a few minutes to remember how to do it, so the UI could 
> grow some hints or "affordances". I'll provide an example later today, when I 
> am near a computer.

Here is the page to use:

https://data.guix.gnu.org/compare/package-derivations?base_commit=d7673b49c086c898a8e749fd042081dc9d4631b8_commit=cf26ee1f99f84f817f96269541073846d546026b_change=broken_name=_results=40

When comparing core-updates to master, the base commit should be from
the master branch, and the target commit should be from core-updates.

However, it looks like the Data Service doesn't know about these commits
on core-updates, which is unfortunate.

My understanding is that Cuirass stopped sending information to the Data
Service after this commit was deployed:

https://git.savannah.gnu.org/cgit/guix/guix-cuirass.git/commit/?id=e598f89445b58eede595e66076405931e6bb1e55

So, in the short term, to get useful information about core-updates from
the Data Service, we'd want to build core-updates in Bordeaux.

Re: Syntax and gexp for ff5f34ae757d709987896d6164bf125319a0f764

[Leo Famulari]

On Thu, Mar 30, 2023 at 08:49:43PM +0200, Josselin Poiret wrote:
> Hi Andreas,
> 
> Andreas Enge  writes:
> 
> > Hello,
> >
> > it looks as if commit ff5f34ae757d709987896d6164bf125319a0f764 breaks
> > building of at least one package, perl-gd, depending on
> > perl-extutils-pkgconfig.
> >
> > The latter is now defined as
> > (define-syntax perl-extutils-pkgconfig
> >   (identifier-syntax (perl-extutils-pkgconfig-for-target
> >   (%current-target-system
> > which apparently does not play well with what is written in the former as
> > (native-inputs
> >  (list perl-extutils-pkgconfig)) :
> > guix package: error: gnu/packages/gd.scm:103:2: package `perl-gd@2.73' has 
> > an invalid input: ("_" #)
> 
> Usually errors which involve # somewhere are caused
> by stale .go files (guile doesn't know how to recompile dependent .scm
> files).  I would suggest a good old `grep -Rl --include '*.go'
> perl-extutils-pkgconfig ./gnu | xargs rm`.

I saw this error too, but it went away after `make clean-go && make`.


signature.asc
Description: PGP signature

Re: Comparison of branches on CI

[Leo Famulari]

On Thu, Mar 30, 2023, at 05:24, Andreas Enge wrote:
> Leo mentioned some time ago that cuirass was missing useful functionality
> from hydra, and I wonder if I have not come across one. How about comparison
> of different branches and/or evaluations? I did not see how to do it, but
> maybe I just overlooked something.

This is the missing feature that I think is most important.

It is possible to use data.guix.gnu.org to create these comparisons. Sometimes 
it takes me a few minutes to remember how to do it, so the UI could grow some 
hints or "affordances". I'll provide an example later today, when I am near a 
computer.

Re: Discussion notes on releases and branches

[Leo Famulari]

On Fri, Mar 17, 2023 at 08:24:44AM -0700, Felix Lechner via Development of GNU 
Guix and the GNU System distribution. wrote:
> Instead of dividing similar tasks among many people with different
> priorities, I would appoint a "feature branch manager" (or perhaps,
> chief pruner).
> 
> That person's job would be to keep an eye on the number of feature
> branches on Savannah so they do not grow stale, or out of control.

There should be someone like this, although I suspect this particular
role could be informally performed by the people who are paying
attention to loads on the build farm at any given time. Generally, we
don't have success appointing people to jobs; rather, they volunteer or
even emerge non-explicitly.

Re: Procps in core-updates

[Leo Famulari]

I recommend trying the latest upstream version, 4.0.3. The Sourceforge
download page points to the new canonical location:

https://gitlab.com/procps-ng/procps

If that doesn't work, I would just disable the test, unless there is
some authoritative upstream opinion about which patch to apply.

Re: Branch and release process (was: gnu: inetutils: Update to 2.4.)

[Leo Famulari]

On Tue, Mar 14, 2023, at 23:30, Maxim Cournoyer wrote:
> Hi,
>
> Leo Famulari  writes:
>
>> On Tue, Mar 14, 2023 at 09:10:33PM -0400, Maxim Cournoyer wrote:
>>> Felix Lechner  writes:
>>> > With the core-updates process now abandoned, I retitled the issue to
>>> 
>>> Could you share the reference of that?  I'm not against it, but our
>>> currently documented process still mention the good old staging and
>>> core-updates branches.
>>
>> At the Guix Days in February, we discussed the branching workflow and
>> reached a rough consensus that for non-core packages (defined in
>> %core-packages), we should try to adopt a more targeted "feature branch"
>> workflow. That's actually what we used to do, before we outgrew our old
>> build farm, after which we were barely able to build one branch at a
>> time (IIRC, we would stop building master in order to build core-updates
>> or staging).
>>
>> The discussion was summarized by Andreas here:
>>
>> https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00066.html
>
> Thanks!  I had missed it.  It sounds promising!
>
>> Currently we are demo-ing this workflow in the wip-go-updates branch and
>> go-team Cuirass jobset.
>
> So the review happens first on the ML, then the changes land to the team
> branch, and then finally the feature branch gets merged to master?  If
> the review has already happened and the package been tested (and built
> by QA), why is a feature branch needed?

Because QA currently cannot process changes that cause more than 200 rebuilds.

Re: gnu: inetutils: Update to 2.4.

[Leo Famulari]

On Tue, Mar 14, 2023 at 09:10:33PM -0400, Maxim Cournoyer wrote:
> Felix Lechner  writes:
> > With the core-updates process now abandoned, I retitled the issue to
> 
> Could you share the reference of that?  I'm not against it, but our
> currently documented process still mention the good old staging and
> core-updates branches.

At the Guix Days in February, we discussed the branching workflow and
reached a rough consensus that for non-core packages (defined in
%core-packages), we should try to adopt a more targeted "feature branch"
workflow. That's actually what we used to do, before we outgrew our old
build farm, after which we were barely able to build one branch at a
time (IIRC, we would stop building master in order to build core-updates
or staging).

The discussion was summarized by Andreas here:

https://lists.gnu.org/archive/html/guix-devel/2023-02/msg00066.html

Currently we are demo-ing this workflow in the wip-go-updates branch and
go-team Cuirass jobset.

My hope is that we can rewrite the relevant documentation in the coming
months, as we learn from these early efforts.

I don't think the core-updates process is abandoned, but we should
reduce its scope. For the core of Guix, both the packages and Guix
itself, it makes sense to alter things in tandem.

But as we have >22000 packages, there are many packages that would
currently qualify for core-updates but aren't core, and can be
relatively easily tested in smaller themed batches.

I would suggest abandoning the staging branch approach after its current
patches are merged to master. The staging branch was always a kludge
from when our build farm was struggling.

For something like inetutils, I would suggest borrowing from its package
module name (gnu packages admin), and attempt to update the
administrative packages as a group. Those who are interested in system
administration should lead the effort.

Cuirass package build timeouts and max-silent-time [was Re: Merging branch wip-haskell]

[Leo Famulari]

On Wed, Mar 08, 2023 at 08:31:33PM +0100, Lars-Dominik Braun wrote:
> Hello Felix,
> 
> > I see build failures [1] for Ghc 9.2.5 in the Cuirass job set [2] for
> > my own feature branch. [3] They are caused by a one-hour timeout. Did
> > you folks figure out how to extend the timeout limit on Cuirass when
> > working on your own branch? Thanks!
> 
> I don’t see GHC being rebuild in [2] and GHC 9.2 should
> have a higher max-silent-time than 1 hour on master since
> 3bb2078a12d78a13f1e1520fe3705333a74ef6e3 (which is part of your
> branch). So I’m slightly confused.

I suspect that GHC was never built by Cuirass, but that somebody logged
in to the build server and invoked `guix build ghc
--max-silent-time=9`.

There's no logs of a successful build of GHC 9.2.5 available through the
Cuirass web interface, which is a clue that my hunch is correct. Builds
performed "by hand" don't appear in the web interface.

https://ci.guix.gnu.org/search?query=spec%3Amaster+ghc-9.2.5

Are we sure that Cuirass honors the max-silent-time property? If I
remember correctly, it did not do so in the past.

Re: bug#61894: [PATCH RFC] Team approval for patches

[Leo Famulari]

I don't have a strong opinion one way or the other about whether we
should formalize the review process. The status quo isn't working well,
so I'm in favor of trying something.

On Tue, Mar 07, 2023 at 01:29:51PM -0500, Maxim Cournoyer wrote:
> I think the main problem we have is social, not organizational.  There's
> little incentive to jump into the laborious review process compared to
> hack on something we like in our free time.  We need to promote and
> value review work more, without making it feel like a compulsory chore.
> That's a great challenge to solve for a project that's driven by
> volunteers.

However, I agree with this point wholeheartedly. We really need to ask
ourselves, why would anyone review patches? It's a lot of work, often
thankless, and unfortunately sometimes unpleasant.

> I'll venture a suggestion to explore: adding enticements to review (some
> playful guidelines such as "while waiting for your 2 weeks review
> period, please try to review twice as many other submissions that have
> been patiently waiting on the patches tracker :-)", or some stats
> crunched and advertised periodically to guix-devel or even our to our
> blog about our top reviewers, etc.).

In release announcements, alongside to the the normal `git shortlog`
list of authors, I suggest also publicizing the list of committers:

`git shortlog --numbered --summary --committer v1.4.0..HEAD`

A small thing, but hopefully one of many incentives to review and
commit.

Re: Ungoogled-chromium in core-updates

[Leo Famulari]

On Tue, Mar 07, 2023 at 06:14:46PM +0100, Andreas Enge wrote:
> Ah, this is a crazy program - C++!
> It just failed after 17h of compilation in the very last step:
> [52515/52515] LINK ./chrome
> FAILED: chrome
> since I had only 51 GB of free space on my disk...
> 
> Otherwise said, I expect it to still build, but will not try it again
> myself :)

Haha! Yes, I think you can count this as a success :)

Re: [PATCH] Cuirass: Complete IPv6 support

[Leo Famulari]

On Sat, Mar 4, 2023, at 03:12, Christopher Baines wrote:
> Leo Famulari  writes:
>
>> On Wed, Mar 01, 2023 at 12:34:08AM -0800, Ryan Sundberg wrote:
>>> Hello Guix hackers,
>>> 
>>> I have implemented IPv6 support for Cuirass in the attached patchset.
>>> This has been tested on a multi-node cluster running Cuirass over IPv6
>>> with some real builds. It should maintain full backwards compatibility
>>> with the default IPv4, only enabling IPv6 when given the arguments to
>>> bind to IPv6 addresses. See the commit log for full details!
>>
>> Thanks, this is great! Can you send the patches to
>> , so that we can use qa.guix.gnu.org for testing?
>
> Note that these are patches for cuirass rather than guix, which
> qa.guix.gnu.org doesn't currently support applying/testing.

Oh right! Well, who shall review? :)

Re: [PATCH] Cuirass: Complete IPv6 support

[Leo Famulari]

On Wed, Mar 01, 2023 at 12:34:08AM -0800, Ryan Sundberg wrote:
> Hello Guix hackers,
> 
> I have implemented IPv6 support for Cuirass in the attached patchset.
> This has been tested on a multi-node cluster running Cuirass over IPv6
> with some real builds. It should maintain full backwards compatibility
> with the default IPv4, only enabling IPv6 when given the arguments to
> bind to IPv6 addresses. See the commit log for full details!

Thanks, this is great! Can you send the patches to
, so that we can use qa.guix.gnu.org for testing?

To send a multi-patch series, you'll need to first send an introductory
message to , and then send the patches to the
special ticket-number email address that it gives you in response.

Re: Qt in core-updates

[Leo Famulari]

Qtwebkit has been removed from the master branch.

On Tue, Feb 28, 2023, at 13:09, Andreas Enge wrote:
> Am Tue, Feb 28, 2023 at 04:13:52PM +0100 schrieb Andreas Enge:
>> Now I am trying to build all
>> the Qt packages before applying the patch to core-updates; it looks good
>> so far.
>
> It went well with all the qt* packages.
>
> Then python-pyqt-without-qtwebkit fails already in its configure phase,
> hopefully an easily solved problem.
>
> Andreas

Re: Question on the process of packge withdrawal

[Leo Famulari]

On Tue, Feb 28, 2023 at 03:57:33PM +0100, Andreas Enge wrote:
> Updating packages that noone is interested in is an unnecessary drag
> on volunteers' time.

This is the key point, in my opinion.

Those who wanted to use this package were very welcome to do something
about it. And they are still welcome to contribute a working package.
They will even receive help and advice on IRC and the mailing lists :)
But they must lead the effort.

This whole conversation seems contrived because, clearly, nobody was
using jrnl in Guix, since it was broken for 4(!) years.

Guix is a distro for using programs. Not a graveyard, a junkyard, or a
collection of historical artifacts.

Re: Question on the process of packge withdrawal

[Leo Famulari]

On Mon, Feb 27, 2023, at 12:12, Maxim Cournoyer wrote:
> I think packages removal should go to the patch tracker, with a CC to
> guix-devel to give more visibility to let time for all parties to
> comment or find a solution (perhaps a maintained fork exists, etc.)

I agree that removal should go through the patch tracker. However, for a case 
like this one, I don't think there's any reason to wait very long before pushing

>From the users' point of view, the package is effectively already gone, 
>because it does not build. 

It's confusing and frustrating for the list of available packages in the UI to 
include broken packages, so I suggest that speedy removal is best.

Re: Thoughts on committers pushing simple changes from other committers?

[Leo Famulari]

On Tue, Feb 21, 2023 at 03:57:10PM +0100, Andreas Enge wrote:
> Concerning other people's patches, what makes this policy a bit complicated
> is that I think we do not have a list of committers on the web.

Commit access is controlled via membership of the Savannah project:

https://savannah.gnu.org/project/memberlist.php?group=guix

Thus, that is the list.

Re: Thoughts on committers pushing simple changes from other committers?

[Leo Famulari]

On Tue, Feb 21, 2023 at 12:54:32PM +, Christopher Baines wrote:
> Thoughts?

I think it's fine to push other people's patches. Already, we push the
patches of non-committers. It's no big deal to push committers' patches.

Re: Golang go-updates feature branch?

[Leo Famulari]

On Thu, Feb 16, 2023 at 09:05:42PM +0100, Josselin Poiret wrote:
> What's the reason behind branch-specific manifests? I'd imagine we'd
> want to test that Guix as a whole still works, even when upgrading just
> specific parts.  Otherwise, I guess this shouldn't qualify for a blog
> post, maybe the cookbook but I'd even just add this as a comment at the
> very top of `build-aux/cuirass/evaluate.scm`, since that's where people
> will go looking for it.  If it does end up becoming widespread, perhaps
> a section of the manual/cookbook dedicated to how feature branches work
> could be a nice home for these bits of info.

Well, now that you ask, I guess there's not a good reason to use
manifests here.

After creating the kernel-updates CI job based on a manifest, I figured
we'd use the same pattern for this, but I agree it's a bit clunky.

On the other hand, Cuirass does tend to obscure the salient information
when testing a branch that doesn't rebuild the world (i.e.
core-updates).

For example, for kernel updates, I want to know 1) if the kernel
packages built and 2) do the system tests still pass? If I simply asked
Cuirass to build everything on the kernel-updates branch, it might end
up showing me the result of a bunch of unrelated package builds just
because they happened to be selected as part of this jobset rather than
'master', due to (un)lucky timing. Does that make sense?

Zooming out, our tooling still has a very long way to go. There are so
many crucial features of Nix's Hydra (which we used previously) that we
are still missing from Cuirass, and it's made it *much* more difficult
to efficiently and carefully perform big updates to Guix, even though
the build farm hardware is more capable than when we used to run Hydra.
This was all so much easier with Hydra.

Sorry for the rambling response that went off-topic. This has been on my
mind.

Re: Golang go-updates feature branch?

[Leo Famulari]

On Tue, Feb 14, 2023 at 10:22:07PM +0100, Josselin Poiret wrote:
> The inferior that's used in 'build-aux/cuirass/evaluate.scm' is built
> from the current check-out by first adding the checkout to the store and
> then building it the usual way.  However, that copy only selects files
> that belong to the git tree using the git-predicate.  If you add the
> manifest to the git checkout by first committing it, it should proceed
> happily (at least it did over here).

Thank you for your help Josselin! It's much appreciated.

As part of our effort to move towards a "feature branch" development
workflow, it will be useful to collect these tips so that everyone can
create and test their own manifests and Cuirass specs.

I wonder where it should go: a blog post, the cookbook, the Guix manual,
etc?

Re: Guix release broken without substitutes on ungrafted openssl

[Leo Famulari]

On Wed, Feb 15, 2023 at 12:15:21PM -0500, Greg Hogan wrote:
> Installing guix from source fails on the build of openssl@1.1.1l. I
> see the same error on my working system (log attached) when executing
> the command below. The issue looks to be caused by OpenSSL's expired
> test certs fixed in 1.1.1p [0]. Guix currently grafts openssl 1.1.1s
> but it seems grafts are not part of the bootstrap process (substitutes
> disabled).
> 
> If this is the correct diagnosis then we should be ungrafting before
> future releases any bootstrap dependencies relating to build failures
> (not necessarily for security updates).
> 
> My personal fix was to adapt my installation script to iteratively set
> back then reset the clock, as openssl only builds in the past but
> diffutils-boot0 then fails due to newly created files being older than
> distributed files.

Thanks for the notes.

I do believe this has been discussed previously, to be found in the
archives!

In general, SSL/TLS implementations keep making this... unfortunate
mistake in their test suites.

It only really affects distros like Guix or Nix, so it's our problem to
fix.

I'd guess it's happened 4 times in the last several years.

It's one of several reasons that rebuilding old Guix releases actually
approaches being a Hard Problem.

Re: Moving forward with teams and feature branches (was: Discussion notes on releases and branches)

[Leo Famulari]

On Mon, Feb 13, 2023 at 03:07:58PM +0100, Andreas Enge wrote:
> Am Sun, Feb 12, 2023 at 10:13:35PM +0100 schrieb Josselin Poiret:
> > 4. staging merge happens, and the branch gets deleted.
> 
> I failed to compile my profile on staging, since rust-rav1e, a dependency
> of ffmpeg, failed to build; see bug #61475.

If this can't be fixed quickly, my recommendation would be to remove the
dependency.

Rust-rav1e is an AV1 video encoder, but FFmpeg also has this
functionality via libaom, which is the reference implementation and
considered to be very high quality.

Re: Merging core-updates?

[Leo Famulari]

On Sun, Feb 12, 2023 at 10:05:40AM +0100, Julien Lepiller wrote:
> As discussed at Guix Days before Fosdem, we haven't merged core-updates
> in a very long time. I'd volunteer to lead this effort, but I don't
> know what steps I should follow. Do we have some documentation about
> that?

The process could be considered "free form".

Basically, you can try to reconfigure your system on core-updates. It
will fail, many build failures will have to be fixed, and eventually it
will work.

Then I would run the Guix test suite and the system tests, and also
try to make use of QA.

It's likely that different architectures will have some specific
problems to be fixed.

FOSDEM: Sunday night dinner?

[Leo Famulari]

Friends of Guix,

Anyone interested in having dinner tonight in Brussels?

Leo

Re: branch master updated: gnu: w3m: Update to 0.5.3+git20230121.

[Leo Famulari]

On Tue, Jan 31, 2023 at 09:20:37AM +, Christopher Baines wrote:
> Given the +1800 dependent packages, the contributing guidance suggests
> this change should go to the core-updates branch.
> 
> → guix refresh -l w3m
> Building the following 984 packages would ensure 1859 dependent packages
> are rebuilt: ranger@1.9.3 ...

Wow! It's not great that this package has so many dependents. It's
basically abandonware, dangerous to use on the web, and not exactly a
popular way to browse the web anyways.

Re: Golang go-updates feature branch?

[Leo Famulari]

On Wed, Jan 11, 2023 at 10:11:09AM -0700, Katherine Cox-Buday wrote:
> I also think this is a fantastic idea, and like John, I think mesa is another 
> good candidate (and not only because I recently would have benefited from 
> this).

Yeah, mesa is *the* archetypal package for the 'staging' branch, since
its reverse dependency graph is too big to rebuild on the 'master'
branch but it's not a "core" package. If we do go down that road, we
will still need to be judicious about how often we do it. Mesa has ~4000
dependents and we don't want to boil the ocean.

Before we can continue, I / we have to debug the patches I sent a few
messages ago:

https://lists.gnu.org/archive/html/guix-devel/2023-01/msg00131.html

Paging guix-sysadmin for assistance...

Re: Ability to specify compiler package for Go build system.

[Leo Famulari]

On Wed, Jan 11, 2023 at 08:02:15PM -0500, Leo Famulari wrote:
> That's correct. You can put something like this in the package
> arguments:
> 
> #:go ,go-1.19

This was undocumented... sorry! I just rectified that in commit
9ec62d1b9c55104f9ab81b95d82988c627a23415.

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=9ec62d1b9c55104f9ab81b95d82988c627a23415

Re: Ability to specify compiler package for Go build system.

[Leo Famulari]

On Wed, Jan 11, 2023 at 05:25:18PM +, ( wrote:
> Pretty sure there *is* already a #:go argument, but I might be misremembering.

That's correct. You can put something like this in the package
arguments:

#:go ,go-1.19

Re: Golang go-updates feature branch?

[Leo Famulari]

) 
(with-exception-handler ("ice-9/boot-9.scm" 1746 15)) (#f ("guix/repl.scm" 125 
7)))>)
In thread:
uncaught throw to %exception: (#< arguments: (wrong-type-arg 
"primitive-load" "Wrong type argument in position ~A (expecting ~A): ~S" (1 
"string" #f) (#f)) inferior: # stack: ((#f 
("ice-9/boot-9.scm" 1779 13)) (raise-exception ("ice-9/boot-9.scm" 1682 16)) 
(raise-exception ("ice-9/boot-9.scm" 1684 16)) (primitive-load (#f #f #f)) 
(save-module-excursion ("ice-9/boot-9.scm" 2835 4)) (#f (#f #f #f)) (map1 
("srfi/srfi-1.scm" 585 17)) (append-map ("srfi/srfi-1.scm" 672 15)) (#f 
("gnu/ci.scm" 449 8)) (map1 ("srfi/srfi-1.scm" 585 17)) (append-map 
("srfi/srfi-1.scm" 672 15)) (cuirass-jobs ("gnu/ci.scm" 489 4)) (#f 
("ice-9/eval.scm" 158 9)) (with-exception-handler ("ice-9/boot-9.scm" 1751 10)) 
(call-with-prompt ("ice-9/boot-9.scm" 723 2)) (#f (#f #f #f)) (#f 
("guix/repl.scm" 98 21)) (with-exception-handler ("ice-9/boot-9.scm" 1751 10)) 
(with-exception-handler ("ice-9/boot-9.scm" 1746 15)) (#f ("guix/repl.scm" 125 
7)))>)
--
diff --git a/build-aux/cuirass/evaluate.scm b/build-aux/cuirass/evaluate.scm
index 7ae5c266d1..92743508df 100644
--- a/build-aux/cuirass/evaluate.scm
+++ b/build-aux/cuirass/evaluate.scm
@@ -96,7 +96,9 @@ (define derivation
 inferior store
 `(lambda (store)
(cuirass-jobs store
- '((subset . all)
+ '((subset
+. (manifests
+   "etc/go-manifest.scm"))
(systems . ,(list system))
(channels . ,channels))
   (file
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2023 Leo Famulari 
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.

(use-modules (guix packages)
 (guix profiles)
 (gnu packages)
 (guix build-system go))

(manifest
  (map package->manifest-entry
   (fold-packages
 (lambda (package result)
   (if (or (eq? (package-build-system package) go-build-system)
   (equal? (package-name package) "go"))
 (cons package result)
 result))
 '(

Golang go-updates feature branch?

[Leo Famulari]

Hello!

Now that our build farm is running smoothly, I propose we revive the
practice of feature branches, when appropriate.

The first one that I propose is a go-updates branch, where we update the
Go compilers. This will affect ~500 packages.

If I understand correctly, Go is a relatively self-contained reverse
dependency graph within Guix and thus a good candidate for this
approach. It contains the Go libaries, and then some end-user
applications, and they don't really affect other packages. So, it should
be easy to understand when the update is ready to push.

I can set up a jobset on ci.guix.gnu.org if people like the idea.

Leo

Re: Be careful with PyPI

[Leo Famulari]

On Fri, Jan 06, 2023 at 03:36:38PM +0100, zimoun wrote:
> If the origin does not exist upstream, then Guix try other servers as
> fallback.  For instance,
[...]
> downloading from 
> https://tarballs.nixos.org/sha256/1j8bsqzh49vjdxy6l1k4iwax5vpjzniynyd041xjavdzvfii1dlh
>  ...

> One potential issue is that the tarballs.nixos.org is using the checksum
> as lookup key.  Therefore, when modifying only the version and not the
> checksum, the something is returned with an inconsistent name/content.

Many of us discover this behaviour the hard way. It's not just about
PyPi: this can happen with any download, unless something changed.

Thanks for the detailed explanation!

Re: Has ci.guix.gnu.org stopped building?

[Leo Famulari]

On Wed, Jan 04, 2023 at 02:58:41PM -0500, Leo Famulari wrote:
> The issue seems to lie in the range of guix.git commits
> e84f17e..8e883dc, which are about Kodi and Wayland.
> 
> Ricardo is taking a look.

This was fixed with commit 658c09333da095edf6e1b3c5e351a7bfa3c87354

Re: Has ci.guix.gnu.org stopped building?

[Leo Famulari]

On Wed, Jan 04, 2023 at 09:43:11AM +0100, Mathieu Othacehe wrote:
> Yes the master specification has not been evaluated since December 30.
> It looks like all subsequent evaluations are never finishing which
> causes a database slots starvation causing even more evaluations to
> fail.
> 
> A good way to investigate that is often to run `make cuirass-jobs`
> locally. I'll try to do that today or tomorrow.

The issue seems to lie in the range of guix.git commits
e84f17e..8e883dc, which are about Kodi and Wayland.

Ricardo is taking a look.

Has ci.guix.gnu.org stopped building?

[Leo Famulari]

According to the web interface, ci.guix.gnu.org stopped building things
on December 31, with evaluation 79343.

Is this true? What's wrong?

Re: Teams: first draft list

[Leo Famulari]

On Tue, Jun 21, 2022 at 05:21:11PM +0200, zimoun wrote:
> * Kernel
> 
>  + Tobias Geerinckx-Rice

Feel free to add my name to the kernel team.


signature.asc
Description: PGP signature

Re: Rust in the kernel

[Leo Famulari]

On Thu, Jun 30, 2022 at 12:37:54PM -0400, Leo Famulari wrote:
> Within Guix, we'll need to adapt our kernel build processes in order to
> support this.

An update on GCC support for Rust:

https://lwn.net/Articles/899385/


signature.asc
Description: PGP signature

Rust in the kernel

[Leo Famulari]

The effort to use the Rust programming language within the Linux kernel
is progressing and may be realized in the next few months:

https://lwn.net/SubscriberLink/899182/6c831b90eaee015e/
https://www.memorysafety.org/blog/memory-safety-in-linux-kernel/

Within Guix, we'll need to adapt our kernel build processes in order to
support this.

Although I help with updating and configuring the kernel builds, I won't
be able to participate in the "Rust in the kernel" effort for Guix.

So, interested volunteers should begin organizing :)


signature.asc
Description: PGP signature

LibreSSL?

[Leo Famulari]

I noticed that some Guix packages depend on LibreSSL, but it seems that
we are not successfully keeping this package up to date with upstream
security releases:

https://www.libressl.org/releases.html

Will anyone step up to maintain this package? Or should we remove it
from Guix?

Re: Excessively energy-consuming software considered malware?

[Leo Famulari]

On Fri, Feb 25, 2022 at 06:35:19PM +0100, Taylan Kammer wrote:
> There's a gnu-misc-discuss mailing list which seems to be used for topics
> that are only tangentially on-topic.  It might be a candidate.  Though it
> has some... well, trolls IMO, though I won't name names.  So maybe it's
> not the best place.  Just throwing it out there.
> 
> https://lists.gnu.org/archive/html/gnu-misc-discuss/

That list is a bad place because it's where all the bad conversations go
--- tautological.

If Guix were to set up a similar list, we'd end up hosting something
just as bad, and to outsiders, it would reflect poorly on Guix. Just
like gnu-misc-discuss makes GNU look awful to outsiders.

It won't benefit Guix to have a mailing list dedicated to off-topic
tangents. We should strive to maintain an atmosphere that is focused,
courteous, and collegial.

There *is* a Guix community, but Guix is not a community space, or a
place to live. It's a software project.

On the topic of cryptomining and its inclusion in the distro, there have
always been programs that people think should not be distributed. The
problem is that there's no consensus about which programs are beyond the
pale.

[guix-comm...@gnu.org: branch master updated: gnu: linux-libre 4.14.266: Fix source code hash.]

[Leo Famulari]

- Forwarded message from guix-comm...@gnu.org -
> commit e0168c72bd8ba629b693bf6aa5cdbaf0777ef7b2
> Author: Leo Famulari 
> AuthorDate: Sun Feb 13 12:36:01 2022 -0500
> 
> gnu: linux-libre 4.14.266: Fix source code hash.
> 
> This is a followup to commit 54ac2ec4e95a3ef7f95dcbc03089fbffc47e609b.
> 
> * gnu/packages/linux.scm (linux-libre-4.14-pristine-source): Fix hash.

What happened here?

I accidentally fetched the source code for and calculated the hash of
4.14.226, instead of 4.14.266.

Then, my command-line invocations that test the build of the linux-libre
tarball did something like "--keep-going", and the error messages were
lost in the scroll back. I'll adjust the workflow to catch this kind of
error in the future.


signature.asc
Description: PGP signature

Re: License of your contributions to the blog at guix.gnu.org

[Leo Famulari]

On Sat, Feb 05, 2022 at 02:47:04PM +0100, Ludovic Courtès wrote:
> Hello,
> 
> I am emailing you on behalf of the GNU Guix project because you are the
> author or coauthor of one or more articles to the blog at
> .
> 
> With a few exceptions, these articles do not have a clear license, which
> we would like to fix.  We propose to dual-license all the articles under
> CC-BY-SA 4.0 and GFDL version 1.3 or later, with no Invariant Sections,
> no Front-Cover Texts, and no Back-Cover Texts.
> 
> Do you agree with the proposed licensing terms for your contributions to
> the blog?
> 
> If you do, please reply to this message to say so, keeping
> guix-devel@gnu.org Cc’d (if you already replied in the previous thread,
> you do not need to reply again).

I agree.

Re: linux-libre kernel 4.4 series will end next month (Feb 2022)

[Leo Famulari]

On Wed, Feb 02, 2022 at 11:43:57AM -0500, Maxim Cournoyer wrote:
> It's been 4 weeks, and nobody offered an opinion.  I suggest we stick to
> upstream Linux LTS schedule and drop 4.4, otherwise we'll have even more
> variants to maintain.

Indeed. I don't think it's being used anyways.

The final version was released today:

https://lwn.net/Articles/883684/

Re: WARNING: Git merges are tricky. Rebasing is better?

[Leo Famulari]

On Mon, Jan 17, 2022 at 05:26:08PM -0500, Kyle Meyer wrote:
> Fwiw I don't think Git automatically resolved that conflict:
> 
>   $ git checkout 276f40fdc349d2ad62582b23ea55e061b689cfc0^
>   $ git merge 276f40fdc349d2ad62582b23ea55e061b689cfc0^2
[...]   
>   ++<<< HEAD
>+"0r7m34xzz3shdfxf2abxb069izak3yv3ijlg29qy4pfmyawkilfs"))
>+  (patches
>+   (search-patches "epiphany-update-libportal-usage.patch"
>   ++||| d91de53caa
>   ++"0r7m34xzz3shdfxf2abxb069izak3yv3ijlg29qy4pfmyawkilfs"
>   ++
>   ++===
>   + "0k7b22zq3z1kllzqxgwsvwb1lp0j6rjb3k1hvhna3i573wc4mpji"
>   + 
>   ++>>> 276f40fdc349d2ad62582b23ea55e061b689cfc0^2

So, you think it was a mistake made when resolving conflicts by hand? I
can certainly understand that.

Either way, it's bad that the Git history doesn't show these types of
changes.

WARNING: Git merges are tricky. Rebasing is better?

[Leo Famulari]

Take note that Git merges can be tricky and hide mistakes! Please
consider using a rebasing workflow instead of a merging workflow for
your branches.

For example, today we merged the version-1.4.0 branch into the master
branch, with commit 276f40fdc349d2ad62582b23ea55e061b689cfc0.

After the merge, we got a report on the #guix IRC channel [0] that the
Epiphany package's source hash was incorrect. It was using the hash of
the previously packaged version of Epiphany.

Using Git, we can see that in commit 291c4fa0ba, Epiphany was updated to
version 41.2, with a correct change in hash:

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=291c4fa0baf24b9d600872fce99441f5471cdb40

Later, the version-1.4.0 branch was merged into master.

View the Git log from the commit where Epiphany was updated through the
merge:

$ git log --patch 291c4fa0baf^..276f40fdc34 gnu/packages/gnome.scm

It does not show that the update of Epiphany's source hash was reverted.

And to be sure that something is wrong, we can examine the file based on
the merge commit:

--
$ git show 276f40fdc349d2ad62582b23ea55e061b689cfc0:gnu/packages/gnome.scm | 
grep "define-public epiphany" -A11
(define-public epiphany
  (package
(name "epiphany")
(version "41.2")
(source (origin
  (method url-fetch)
  (uri (string-append "mirror://gnome/sources/epiphany/"
  (version-major version) "/"
  "epiphany-" version ".tar.xz"))
  (sha256
   (base32
"0r7m34xzz3shdfxf2abxb069izak3yv3ijlg29qy4pfmyawkilfs"))
--   ^
*This is the hash of Epiphany 40.3, the old version!*

Git's automatic merge conflict resolution algorithm did the wrong thing
here. And Git does not show the reversion in `git log`, hiding it from
review.

My guess is that commit f7afefba0 ("gnu: epiphany: Fix build with
libportal-0.5."), which happened on the master branch while the
version-1.4.0 branch was forked off, made Git think that this line was
more "up to date" on master than on version-1.4.0, causing it to select
the old hash when faced with the conflict.

Once again, consider using a workflow based on rebasing instead of
merging for forked branches that will live for weeks to a month or two.
This type of mistake cannot be obscured when rebasing.

[0] http://logs.guix.gnu.org/guix/2022-01-17.log#195313

Re: Profile definition, was Re: bug#53224: Cookbook recipe about profile collisions

[Leo Famulari]

On Mon, Jan 17, 2022 at 12:56:20PM -0500, Matt wrote:
> Leo is 100% correct that my understanding is still rather weak. I'll do my 
> best despite that to help make the documentation better.

I hope you will not feel too bad about that. Remember, everyone begins
by not knowing anything. Your situation is not unique at all. Rather,
your energy for improving the documentation for yourself and others is
exemplary, and will improve Guix in the long run.

Overall, this highlights a case where there is tension between when an
implementation detail doesn't matter, and when it does. That is, the
ideal situation is that the implementation details of profiles do not
matter. However, when there are "profile collisions", it does matter.

Re: Document /homeless-shelter?

[Leo Famulari]

On Sun, Jan 16, 2022 at 07:16:11PM +0100, Maxime Devos wrote:
> > +(modify-phases %standard-phases
> > +  (add-before 'check 'fix-home-directory
> > +(lambda _
> > +  (setenv "HOME" "/tmp"
> > +@end lisp
> 
> Sometimes ‘hand-written, automake/cmake/... is bloat!’-style Makefiles
> install things to $HOME in the 'install' target, maybe you could give
> something like that as an example for when setting HOME to /tmp won't
> work?

As I suggested in my reply (concurrent to yours), this use of /tmp is
not something we need to document authoritatively. Rather, packagers
have to make a judgement about how to handle package build scripts that
try using $HOME.


signature.asc
Description: PGP signature

Re: Document /homeless-shelter?

[Leo Famulari]

On Sun, Jan 16, 2022 at 12:38:52PM -0500, Matt wrote:
> Subject: [PATCH] Document /homeless-shelter

I pushed a simpler addition to the manual:

https://git.savannah.gnu.org/cgit/guix.git/tree/doc/guix.texi#n1181

Of course I made a silly typo and so this change takes place over two
commits.

> +The @env{HOME} environment variable is set to @file{/homeless-shelter}
> +during the build process.  This ensures builds are determistic and
> +highlights all uses of @env{HOME}.  Packages should not depend on the
> +pathname of a home directory.  Instead, modify the build phase to set
> +@env{HOME} to @file{/tmp}:
> +
> +@lisp
> +(modify-phases %standard-phases
> +  (add-before 'check 'fix-home-directory
> +(lambda _
> +  (setenv "HOME" "/tmp"
> +@end lisp

This text is basically correct but we have to balance verbosity with
readability.

The important thing was to document /homeless-shelter, so that packagers
understand it comes from Guix, and to explain its rationale.

It's not 100% true that setting HOME=homeless-shelter ensures that
builds are deterministic and highlights all uses of $HOME, although it
does help with those goals.

I don't think we want to document the use of /tmp, or recommend it as an
authoritative workaround.

Rather, it's a common solution, but packagers must seek to understand
how the package build scripts are trying to use $HOME and make a
judgement.

Additionally, I don't think that Build Environment Setup is the right
place to document workarounds.

Re: Document /homeless-shelter?

[Leo Famulari]

On Sat, Jan 15, 2022 at 10:19:54PM -0500, Matt wrote:
> As I understand it, $HOME is set to /homeless-shelter during build because 
> that's how Nix does/did it and "there’s no home
> directory in build environments, and perhaps Eelco Dolstra and others back 
> then found that setting ‘HOME’ to a non-existing directory broke
> fewer builds that leaving it unset."

A further rationale is that by using an obviously strange and bogus
value for $HOME, all uses of $HOME in the build container are
highlighted.

Otherwise, if $HOME was unset, build scripts might fall back to
something like $HOME/$USER.

To be clear, the situation is not simply that "there's no home directory
in the build environment". Rather, there must not be a home directory
there. By design, that's a small part of how we ensure that builds are
deterministic.

In all cases, package builds should not be able to depend on the
pathname of a home directory.

> Is this something that should be documented, and if so, where?

It could be documented briefly in the manual section Build Environment
Setup.

Re: Guix Documentation Meetup

[Leo Famulari]

On Sat, Jan 08, 2022 at 11:24:35AM -0500, Matt wrote:
> 2. http://excalamus.com/2021-10-06-guix-debug.html

The error about "profile contains conflicting entries" is something we
should improve the documentation about, for sure.

I opened a tracking bug about it: 

https://issues.guix.gnu.org/53224

I think we can adapt some older presentations (video-recorded) about
Guix, because they helped me understand the subject quite clearly when I
watched them when I first learned about Guix.

The manual's treatment of profiles and propagation is authoritative and
correct, but it does not quite communicate the subject in a way that
combines to make these error messages understandable.

Re: Guix Documentation Meetup

[Leo Famulari]

On Sun, Jan 09, 2022 at 04:12:57PM -0500, Matt wrote:
> I did.  Maybe you missed the two blog posts I linked in the previous email?   
>  

Yeah, I did miss that you intended to contribute them.

There is another side of my advice about submitting your contributions
however you can: It's still important to try to communicate clearly.
Your message includes several paragraphs of meta-discussion before
mentioning that you have some things to contribute, rather than just a
desire to contribute in general. Based on that, both me and Ricardo did
not understand that your blog posts were potential contributions.

Sorry if that comes across as harsh, but it's always true that
successful collaboration is helped by clear and concise communication.

Maybe that's a good thing, maybe it's a bad thing. It's the reality in
any collaborative environment where people are busy.

So, if you have a goal, my advice is to state it clearly and concisely.

If you have both long-term goals (make it easier to contribute
documentation) and short-term goals (add some Cookbook recipes or wiki
pages), then you should present them separately, or else people will
only focus on one of them.

Re: Assisting reviewing & committing with tags?

[Leo Famulari]

On Sun, Jan 09, 2022 at 11:54:25AM +0100, Maxime Devos wrote:
> Hi guix reviewers and committers,
> 
> WDYT of tagging reviewed patches that look good with a usertag,
> e.g. 'reviewed-looks-good':
> 
> https://debbugs.gnu.org/cgi/pkgreport.cgi?tag=reviewed-looks-good=guix
> 
> then if a committer doesn't have much time to review and hence doesn't
> subscribe to guix-patches@, but they do trust the reviewer, they can visit
> that URL to look for reviewed patches that can be applied.
> 
> There could also be a tag 'reviewed-looks-good2' if the patch appears ok
> to two reviewers, or a 'reviewed-needs-work', etc.

This is a great idea. I guess we will need to adjust the software that
runs issues.guix.gnu.org to make use of it, but in the meantime you
should keep using this tag. Thanks!

Re: version-1.4.0 branch updated

[Leo Famulari]

On Mon, Jan 10, 2022 at 07:31:45PM -0500, Maxim Cournoyer wrote:
> The CI hasn't yet been switched on to build the branch yet; let's give a
> bit more time for other changes like this to have a chance to be
> considered/merged and then switch it on!  Perhaps Wednesday.

It seems risky to me to put world-rebuilding changes on the release
branch, because we won't have time to squash the bugs that inevitably
appear after deployment before releasing.

However, what do you think about also adding a fix for #53005,
"cryptsetup-static aborts opening LUKS2 volume with Argon2i PBKDF"? The
proposed fix changes glibc:

https://issues.guix.gnu.org/53005

Re: Guix Documentation Meetup

[Leo Famulari]

On Sat, Jan 08, 2022 at 11:24:35AM -0500, Matt wrote:
> Let me walk through what that looks like from my perspective.  I'm afraid, 
> however, that it comes across as aggressive, ungrateful, or demanding.  None 
> of those are my intent! I genuinely want to help but struggle to understand 
> the process.  My goal is to outline a "user story".
> 
> From my perspective, contributing to the cookbook looks as follows.  I've 
> tried to be factual and ask rhetorical questions. 
> 
> How do I contribute to the cookbook? I see no information in the cookbook 
> about how to do that. I'm looking at 
> https://guix.gnu.org/cookbook/en/guix-cookbook.html
> 
> The contribute page (https://guix.gnu.org/en/contribute/) links to this 
> mailing list. I am willing and ready to contribute. Now what?
> 
> I see the manual has a section on contributing: 
> https://guix.gnu.org/manual/en/html_node/Contributing.html#Contributing
> 
> I see nothing about how to contribute to documentation. 
> 
> Do I need to submit a patch? 
> How do I submit a patch? 
> Do I have to write in TexInfo?
> What is the roadmap from me spending hours authoring something to it being 
> available for review from experts or to being useful to others?

I see that this all seems confusing. If you have something to
contribute, you should just mail it to this list or guix-patches.
Definitely, we prefer you send patches, but if that is too hard, you can
send your contribution in *any* form.

Re: GNU Guix maintainer rotation

[Leo Famulari]

On Thu, Jan 06, 2022 at 03:22:51PM -0500, Maxim Cournoyer wrote:
> Hello Guix!
> 
> I'd like to bring your attention to a change to the current Guix
> maintainers collective; in a nutshell, Ludovic and Marius are stepping
> down from maintainer-ship while Efraim is joining.

Thank you Ludovic and Marius, for all you've done for Guix and the world
of free software.

And welcome to your new role Efraim! I can't think of somebody that is
better suited for it.

Re: Convention for new “guix style“?

[Leo Famulari]

On Mon, Jan 03, 2022 at 09:05:00PM +0100, zimoun wrote:
> BTW, I hope you will be able to schedule some time to watch this video.
> It provides some points that appears to me being really worth to
> consider when we speak about «Grow a Community».  Rust is not a model
> to bootstrap a compiler but the community structure seems great. :-)

I definitely agree with the overall initiative of improving the Guix
community. But I'm already working, as a volunteer, at the limit of my
motivation and my ability.

Re: Convention for new “guix style“?

[Leo Famulari]

On Mon, Jan 03, 2022 at 05:23:22PM +0100, zimoun wrote:
> Well, I disagree.  But yeah, as you said elsewhere 1) the proposal had
> been done more than 6 months ago so I had time to wake up and raise and
> 2) let avoid to fall into the Walder’s law; as exposed by the excellent
> food for thought video [1] you pointed [2].

Can you summarize Walder's law? I don't have time to watch that video.

Re: Convention for new “guix style“?

[Leo Famulari]

On Mon, Jan 03, 2022 at 02:48:27PM -0500, Leo Famulari wrote:
> On Mon, Jan 03, 2022 at 05:23:22PM +0100, zimoun wrote:
> > Well, I disagree.  But yeah, as you said elsewhere 1) the proposal had
> > been done more than 6 months ago so I had time to wake up and raise and
> > 2) let avoid to fall into the Walder’s law; as exposed by the excellent
> > food for thought video [1] you pointed [2].
> 
> Can you summarize Walder's law? I don't have time to watch that video.

Never mind, I see that it's Wadler's law:

--
In any language design, the total time spent discussing
a feature in this list is proportional to two raised to
the power of its position.
 0. Semantics
 1. Syntax
 2. Lexical syntax
 3. Lexical syntax of comments
--

linux-libre kernel 4.4 series will end next month (Feb 2022)

[Leo Famulari]

The Linux / linux-libre kernel "longterm" support series version 4.4 is
scheduled to reach the end of its life next month, in February 2022:

https://www.kernel.org/category/releases.html

There is a project by the Civil Infrastructure Platform (CIP) called
"SLTS" kernels, which offer "super longterm support". They begin by
pledging support for the 4.4 series until 2027:

https://wiki.linuxfoundation.org/civilinfrastructureplatform/start

So, we could use that if somebody wanted to make the necessary
adjustments to our packaging and agree to help keep it working.

I think this is the first time we face end of support of a kernel with
longterm suport in Guix, at least since we started to keep all the
longterm kernels packaged [0].

What should we do?

I'm not sure that many people are using this kernel series, but anybody
who is should speak up and give their opinion.

[0] Interesting parts of our Git history:
The first linux-libre package (3.3.8):
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=beacfcabe735b6d8d07a682f1c0663e4670cea5b

The first linux-libre update (to 3.11):
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=e7b385008ca0f0817c3514357cf53151cea0f511

First additional linux-libre variant (adding 4.0.8):
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=97121c2a2189c0880cfb4c9a7eb8efd3b6e1c16e

Re: Updating old blog posts?

[Leo Famulari]

On Fri, Dec 31, 2021 at 12:14:10PM +0100, Liliana Marie Prikler wrote:
> Given that time machine ownership is significantly higher among Guix
> users than ordinary citizens, I think we should only update that blog
> post to have a small notification directing them to a new blog post or
> the cookbook and in the case of the former write that blog post.

I added a note to the blog post with commit
a341840f15e39e3cd92e5f92d344136055b5457b

Updating old blog posts?

[Leo Famulari]

I updated a section of the cookbook so that it was still useful after
some changes in Guix:

https://git.savannah.gnu.org/cgit/guix.git/commit/?id=c7d74a9bccfc1b1274fc8754a6e78bb6887c7fea

There was also a blog post made from this cookbook recipe:

https://guix.gnu.org/en/blog/2019/creating-and-using-a-custom-linux-kernel-on-guix-system/

Should we update it too?

Re: git hook error

[Leo Famulari]

On Tue, Dec 28, 2021 at 11:31:10PM +0100, Ricardo Wurmus wrote:
> The motivation for that is not found in just one big problem.  It’s a
> small trickle of minor annoyances:
> 
> - Savannah’s uptime isn’t quite as high as we’d like

Okay. I wonder if we could actually do a better job, or if anybody who
hosts a comparable repo does.

Our own record with the build farm and the record of major hosts like
Github are both somewhat discouraging. And if we could only hope for an
equivalent uptime to Savannah, it doesn't seem worth it to shoulder this
work ourselves.

> - we can’t have server-side checks to prevent pushing bad commits
> - we can’t have server-side hooks to better integrate with the build farm
> - we can’t have per-branch rules (e.g. to allow contributors to push to
>   some but not all branches)

We do actually have a server-side hook in place to prevent pushing
unsigned commits. And if we wanted to add more tooling, the Savannah
admin(s) would help us.

Now, if we just wanted more control and visibility into the
infrastructure, that's a reason, but again, I wonder if it's worth the
effort. In terms of infrastructure maintenance, we already seem to be
stretched thin.

My opinion is that, in order to consider hosting our own Git server, we
should wait until people are using declarative Guix configuration to
operate reliable, performant, and public Git servers that would meet our
needs. That is, the Guix project needs to grow this capability without
the heroic effort of a single volunteer. Because that's what we have now
with Savannah, more or less, and we don't have to work for it. Maybe
this has already been achieved, I don't know.

Re: git hook error

[Leo Famulari]

On Tue, Dec 28, 2021 at 10:09:06PM +0100, Ricardo Wurmus wrote:
> So… uhm, what do you all think about hosting our Git repos by ourselves?
> Ideally *not* on the servers of the build farm, but on other hardware?

I would ask, why would we want to do that?

Re: git hook error

[Leo Famulari]

On Tue, Dec 28, 2021 at 09:26:54PM +0100, Tobias Geerinckx-Rice wrote:
> Ricardo,
> 
> This is .

Also happened in 2017:

https://www.mail-archive.com/savannah-hackers-public@gnu.org/msg05571.html

search-input-file vs (assoc-ref inputs)

[Leo Famulari]

I noticed that, as part of the transition to the new inputs style [0],
we are sometimes replacing code like (assoc-ref inputs "foo") with
(search-input-file inputs "/bin/foo").

I think that we should instead replace the old style with gexps that
specify which package, in order to keep the equivalent functionality.

Otherwise, we risk regressions, when the code finds a match for the
desired filename in the wrong input.

I would say that (search-input-file) is a replacement for the Guile
(which) procedure.

On the other hand, we can replace (assoc-ref inputs ...) with
(this-package-input "foo").

What do you think?

[0] https://guix.gnu.org/en/blog/2021/the-big-change/

Re: Should the linter warn if a package depends on multiple versions of the same program?

[Leo Famulari]

On Fri, Dec 17, 2021 at 12:59:16PM -0500, Leo Famulari wrote:
> Currently we have a problem caused by glibmm-2.64 propagating two
> different versions of libsigc++:
> 
> https://issues.guix.gnu.org/52519
> 
> I think this is something that is rarely desirable.
> 
> Maybe the linter could check for cases like this? Of course, "cases like
> this" still needs to be defined exactly...

Oh, as happens so often, I spoke too soon. The linter actually warns:

--
gnu/packages/glib.scm:811:3: glibmm@2.64.5: propagated inputs libsigc++@2.9.3 
and libsigc++@3.0.6 collide
--

Should the linter warn if a package depends on multiple versions of the same program?

[Leo Famulari]

Currently we have a problem caused by glibmm-2.64 propagating two
different versions of libsigc++:

https://issues.guix.gnu.org/52519

I think this is something that is rarely desirable.

Maybe the linter could check for cases like this? Of course, "cases like
this" still needs to be defined exactly...