Re: Unexpected --export-manifest with simple transformations

Hi Ludo, On Thu, 11 Feb 2021 at 00:01, Ludovic Courtès wrote: > That’s because when using ‘-m’, transformations are not recorded. Yes. The question is: is it a conscientious choice or a missing feature? It makes sense to save the transformations from a manifest, IMHO. But it is not clear wh

Re: Unexpected --export-manifest with simple transformations

Hi, zimoun skribis: > So far, so good. Then let use this manifest to create a profile. > >$ guix package -p /tmp/profile-exported -m /tmp/manifest.scm > > and the issue is that ’/tmp/profile-exported/manifest’ does not contain > the transformation. Other said: > > $ guix package -p /tmp/pr

Re: Discover GNU Guix eco-system with awesome-guix!

On Wed, 2021-02-10 at 23:03 +0100, Ludovic Courtès wrote: > Hi, > Hello! > Léo Le Bouter skribis: > > > I created an awesome-guix list at > > https://git.sr.ht/~lle-bout/awesome-guix#awesome-guix > > Nice! In the channels section, you could add Guix-Science, Guix- > Past, > Guix-HPC, and pe

Re: The Guix Build Coordinator in 2021

Hi! Mathieu Othacehe skribis: > We are now in a situation where our continuous integration system, > while performing better and better is getting out of hand. Here are the > different software I'm keeping track of: > > * Cuirass, deployed on ci.guix.gnu.org > * The Guix Build Coordinator, deplo

Re: Discover GNU Guix eco-system with awesome-guix!

On Tue, 2021-02-09 at 12:19 +0100, Léo Le Bouter wrote: > Hello! > > I created an awesome-guix list at > https://git.sr.ht/~lle-bout/awesome-guix#awesome-guix > > Please contribute new items by email with patches to > ~lle-bout/awesome-guix-de...@lists.sr.ht! No promotion of proprietary > softw

GNU Guix for Google Summer of Code (GSoC)

The GNU project will apply for GSoC again. I have started a page for project ideas here: https://libreplanet.org/wiki/Group:Guix/GSoC-2021 If you think a student can help your project, do add your idea. Every project should have 2 or 3 mentors. Note that the work should be doable in ~180 hours o

Re: Discover GNU Guix eco-system with awesome-guix!

Hi, Léo Le Bouter skribis: > I created an awesome-guix list at > https://git.sr.ht/~lle-bout/awesome-guix#awesome-guix Nice! In the channels section, you could add Guix-Science, Guix-Past, Guix-HPC, and perhaps a few others from . :-) Thanks, Ludo’.

Re: Guix Day: Notes frome the Bootstrap session

Hi! Jan Nieuwenhuizen skribis: > Attached the notes from the "Bootstrap what's next" session yesterday. Thanks for sharing! > - Making the guix build system code less dependent on Guile and more > dependent on MES Not necessarily more dependent on Mes :-), but rather portable between the tw

Re: branch naming conventions [was Re: Guix Day: Notes from the CI session]

Leo Famulari skribis: > On Wed, Feb 10, 2021 at 04:09:15PM +0200, Efraim Flashner wrote: >> My concern about that is that it basically swaps what we have now. Using >> -frozen makes it a bit clearer that we're building it out. > > Good idea, I like it. +1 Would someone be willing to add a coupl

Re: Guix Day: Notes from the CI session

Hi! Leo Famulari skribis: > As for the hardware itself, yes, it's expensive, but not any more than > what we'd pay for our x86_64 build farm (~1500 CPU cores and terabytes > of RAM). Again, do we know anyone who would donate some? Should we try > negotiating a discount with vendors? Yes, I thin

Re: Guix Day: Notes from the CI session

Hi! Mathieu Othacehe skribis: >> I think the status quo of 64-bit ARM for us is untenable. The emulated >> builds cause mass failures that can't be reproduced on real hardware. >> There is a growing demand for this platform among hobbyists and hackers >> who we could convert to Guix contributors

Re: GWL 0.3.0 released

Heya, Ricardo Wurmus skribis: > The Guix Workflow Language 0.3.0 has been released. > > I forgot to Cc y’all in the release announcement: > >https://lists.gnu.org/archive/html/gwl-devel/2021-02/msg0.html Congrats on all the hard work! If you didn’t follow FOSDEM, don’t miss Ricardo’s t

Re: Handling nars/narinfos at scale, some ideas...

Hi Chris! Christopher Baines skribis: > When serving from a store, you can use guix gc to remove items, and gc > roots to protect the items you want to keep. I'm not aware of similar > tooling when you just have a bunch of nars+narinfo files. This means you > either just delete files based on wh

Re: Potential security weakness in Guix services

Ludovic Courtès writes: > I think it’s a good endeavor, but it’s a longer-term one since it’ll > take some time before this new version is in use by all the Guix code. > > The difficulty in designing such an interface is that the Scheme API is > more about ports than it’s about file names and file

Re: Potential security weakness in Guix services

Hi Maxime, Maxime Devos skribis: > On Sat, 2021-02-06 at 22:28 +0100, Ludovic Courtès wrote: >> Maxime Devos skribis: >> >> I just remembered this subtlety: during bootup, the activation code is >> evaluated by the Guile that’s in the initrd, which is a >> statically-linked Guile, and thus we

Re: The Guix Build Coordinator in 2021

Mathieu Othacehe writes: > We are now in a situation where our continuous integration system, > while performing better and better is getting out of hand. Here are the > different software I'm keeping track of: > > * Cuirass, deployed on ci.guix.gnu.org > * The Guix Build Coordinator, deployed o

Re: Guix Day: Notes from the CI session

On Wed, Feb 10, 2021 at 06:11:08PM +0100, Mathieu Othacehe wrote: > Thanks to Ricardo support I was able to setup a Wireguard tunnel between > berlin and the overdrive1. It seems to work pretty well and > https://ci.guix.gnu.org/workers shows that it is building some packages. > > I plan to connec

Re: Guix Day: Notes from the CI session

Hello, > I think the status quo of 64-bit ARM for us is untenable. The emulated > builds cause mass failures that can't be reproduced on real hardware. > There is a growing demand for this platform among hobbyists and hackers > who we could convert to Guix contributors! Following discussions th

Re: branch naming conventions [was Re: Guix Day: Notes from the CI session]

On Wed, Feb 10, 2021 at 04:09:15PM +0200, Efraim Flashner wrote: > My concern about that is that it basically swaps what we have now. Using > -frozen makes it a bit clearer that we're building it out. Good idea, I like it.

Re: Mitigating "dependency confusion" attacks on Guix users

On Wed, Feb 10, 2021 at 07:51:23AM +, Christopher Baines wrote: > > Ryan Prior writes: > > > However, I'm still thinking about how to attack Guix users. Somebody who > > adds an internal channel for their own packages could still be > > vulnerable to a dependency confusion attack via a compr

Re: Mitigating "dependency confusion" attacks on Guix users

On 2/10/21 2:51 AM, Christopher Baines wrote: I'm not sure you can escape trusting the collection of channels you're using. Because channels are code that's expected to interact, I'm not sure it's easy to target a single package from a specific channel, and expect that this provides some security

branch naming conventions [was Re: Guix Day: Notes from the CI session]

On Tue, Feb 09, 2021 at 04:46:36PM -0500, Leo Famulari wrote: > On Mon, Feb 08, 2021 at 06:07:25PM +0100, Ludovic Courtès wrote: > > ## Open issue: branching strategy > > > > - currently: building all of `master` + the "core" of `core-updates` > > - schedule > > - currently ad-hoc: volunte

Re: Staging branch [substitute availability]

Hey, > The network team asks me to test it now. Could you please give it a > try? I ran a few tests, it seems to work perfectly! It's really impressive how Wireguard is easy to set up. I think it deserves a complete Guix service :). --8<---cut here---start-

Re: Staging branch [substitute availability]

Mathieu Othacehe writes: >> Yes, this should be okay. Does this mean that we can get rid of all the >> other ports that we previously requested? > > Yes, the SSH tunnels and the associated open ports shouldn't be useful > anymore, as we'll be able to route all the build nodes traffic through >

Re: Mitigating "dependency confusion" attacks on Guix users

Hi Ryan, On Wed, 10 Feb 2021 at 00:08, Ryan Prior wrote: > What comes to my mind is that we should encourage (require?) people to > specify the channel name a package belongs to, if it's not the "guix" > channel. So instead of referring to "python-beautifulsoup4" (ambiguous: > is this from my ch

Re: The Guix Build Coordinator in 2021

Hello Chris, > Near the beginning of 2020, things changed such that I suddenly had some > time, and some of that time I spend putting idea's I'd had for a while > around building derivations, including across multiple machines, in to > practice [1]. With the Guix Build Coordinator, you made an

Re: Staging branch [substitute availability]

Hello, > Yes, this should be okay. Does this mean that we can get rid of all the > other ports that we previously requested? Yes, the SSH tunnels and the associated open ports shouldn't be useful anymore, as we'll be able to route all the build nodes traffic through the VPN. > If you’re sure

Re: ZFS on Guix

On Mon, Feb 08, 2021 at 09:32:27AM +, raid5atemyhomework wrote: > > * the shepherd services defined in `configuration.scm` > > seem one-shot services to me, so maybe add '(one-shot? #t)'. > > I was wary of making the `zfs-scan` one-shot, since there is a dependent > service on top of it. N