Re: 02/02: gnu: linux-libre: Update to 6.9.

On Tue, Jun 04, 2024 at 08:41:47AM +0200, Ludovic Courtès wrote: > It seems that it broke ‘x86-energy-perf-policy’ and ‘zfs-auto-snapshot’: > > https://ci.guix.gnu.org/eval/1374635?status=newly-failed Aha, a new feature in the CI web interface! Wonderful! The failure of

Re: Is git the best tool for pulling packages?

>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

Re: Adding plumbing subcommand 'derivation'?

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)

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

Re: xz backdoor

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

Re: Rust team branch merged

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

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

Re: Welcome Oleg (sharlatan) as a new committer

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

Re: bug#67790: New signing key

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"

Re: bug#67790: New signing key

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

Re: bug#67790: New signing key

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

New signing key

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

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. &g

Re: Ext4 corruption in some stable kernels

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

Re: role of core-updates

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

Re: Upgrading Guix's security team

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

Re: Need people to help with kernel updates

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

Re: Need people to help with kernel updates

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

Re: Need people to help with kernel updates

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.

Re: Making linux-libre@6.5 the default kernel

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

Re: Making linux-libre@6.5 the default kernel

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

Re: Need people to help with kernel updates

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

Need people to help with kernel updates

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

Re: About donation to GNU Guix project

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

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

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

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

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

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

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

Re: evince: Is this a bug?

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. > ** >

Re: Setuid handling?

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,

Re: Core-updates merge

ller). > - 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

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"?

Re: staging branch merged to master

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)

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

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

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

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

Re: Syntax and gexp for ff5f34ae757d709987896d6164bf125319a0f764

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

Re: Comparison of branches on CI

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

Re: Syntax and gexp for ff5f34ae757d709987896d6164bf125319a0f764

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

Re: Comparison of branches on CI

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

Re: Discussion notes on releases and branches

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

Re: Procps in core-updates

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.)

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

Re: gnu: inetutils: Update to 2.4.

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

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

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

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

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

Re: Ungoogled-chromium in core-updates

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

Re: [PATCH] Cuirass: Complete IPv6 support

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. &

Re: [PATCH] Cuirass: Complete IPv6 support

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

Re: Qt in core-updates

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

Re: Question on the process of packge withdrawal

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

Re: Question on the process of packge withdrawal

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

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

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:

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

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?

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

Re: Golang go-updates feature branch?

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

Re: Guix release broken without substitutes on ungrafted openssl

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

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

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;

Re: Merging core-updates?

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

FOSDEM: Sunday night dinner?

Friends of Guix, Anyone interested in having dinner tonight in Brussels? Leo

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

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 >

Re: Golang go-updates feature branch?

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'

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

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.sava

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

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?

t-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-au

Golang go-updates feature branch?

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

Re: Be careful with PyPI

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

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

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?

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

Has ci.guix.gnu.org stopped building?

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

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

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

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

LibreSSL?

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?

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

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

- 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

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

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

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

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

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

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 >+

WARNING: Git merges are tricky. Rebasing is better?

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

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

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

Re: Document /homeless-shelter?

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 >

Re: Document /homeless-shelter?

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. >

Re: Document /homeless-shelter?

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

Re: Guix Documentation Meetup

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:

Re: Guix Documentation Meetup

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

Re: Assisting reviewing & committing with tags?

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

Re: version-1.4.0 branch updated

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

Re: Guix Documentation Meetup

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

Re: GNU Guix maintainer rotation

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

Re: Convention for new “guix style“?

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

Re: Convention for new “guix style“?

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

Re: Convention for new “guix style“?

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 > >

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

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

Re: Updating old blog posts?

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

Updating old blog posts?

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:

Re: git hook error

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

Re: git hook error

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

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)

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

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

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. > > Mayb

  1   2   3   4   5   6   7   8   9   10   >