Request for merging "go-team" branch
Hi! I'm tempted to merge go-team to master today/tomorrow. Nothing major was added since last time I've rebased it and the build coverage looks positive without regression. ARM builds are still scheduled, but as I noticed it's quite normal. -- Thanks, Oleg signature.asc Description: PGP signature
Magic Wormhole Package Weirdness/Potential Security Issues?
Hey folks, I tried to update magic-wormhole today and things went super smoothly. All I had to do was change the version number. I didn't even have to change the source hash. If that strikes you as odd, good! It should! To cover all my bases, I pk'd the hash produced by `pypi-uri` and used `guix download` to try to fetch the same file and check its hash, only to find that `guix download` couldn't find anything at that URL or its fallbacks. To test if things were being exceptionally weird, I switched to pulling and building from git, and the build failed, expectedly, probably because one of the dependencies (magic-wormhole-transit-relay) was not the right version, which was what I had initially expected to happen. Does anyone know what might be going on here? Given the intended secure nature of this program, I'm concerned there may be something malicious happening somewhere along the way. I would love an explanation that quiets that concern. You can look at the current magic-wormhole package source and play around with it yourself to see what I'm talking about. Best, Juli PS I was trying to update all three packages in magic-wormhole.scm, but the transit relay in particular requires later versions of twisted and autobahn than the other two, which is minorly annoying. I know twisted can't be updated without rebuilding a bunch of stuff, so I don't plan to pursue this further for the time being.
Re: Magic Wormhole Package Weirdness/Potential Security Issues?
Hi Juliana, I’ve observed some similar weirdness in the past when I’ve updated versions. I believe what’s happening is that Guix uses the hash to look up the file in a content-addressed store (either the local store or SWH), and is lacking verification that the retrieved object is the expected one. — Ian Juliana Sims writes: Hey folks, I tried to update magic-wormhole today and things went super smoothly. All I had to do was change the version number. I didn't even have to change the source hash. If that strikes you as odd, good! It should! To cover all my bases, I pk'd the hash produced by `pypi-uri` and used `guix download` to try to fetch the same file and check its hash, only to find that `guix download` couldn't find anything at that URL or its fallbacks. To test if things were being exceptionally weird, I switched to pulling and building from git, and the build failed, expectedly, probably because one of the dependencies (magic-wormhole-transit-relay) was not the right version, which was what I had initially expected to happen. Does anyone know what might be going on here? Given the intended secure nature of this program, I'm concerned there may be something malicious happening somewhere along the way. I would love an explanation that quiets that concern. You can look at the current magic-wormhole package source and play around with it yourself to see what I'm talking about. Best, Juli PS I was trying to update all three packages in magic-wormhole.scm, but the transit relay in particular requires later versions of twisted and autobahn than the other two, which is minorly annoying. I know twisted can't be updated without rebuilding a bunch of stuff, so I don't plan to pursue this further for the time being.
Re: Magic Wormhole Package Weirdness/Potential Security Issues?
Hi Juli, On Fri, 2024-11-08 at 13:26 -0500, Juliana Sims wrote: > To cover all my bases, I pk'd the hash produced by `pypi-uri` and > used > `guix download` to try to fetch the same file and check its hash, > only > to find that `guix download` couldn't find anything at that URL or > its > fallbacks. It seems at some point in between version 0.14.0 and 0.17.0 the name of the tarball has changed from `magic-wormhole` to `magic_wormhole`. You have to change the uri-field accordingly to successfully download the source code from PyPI. When building it in the way you describe, the source code cannot be found on PyPI, so it is pulled from tarballs.nixos.org instead. It seems NixOS uses content-addressable storage, so the hash is used to download the source code and since you have not changed the hash, it downloads version 0.14.0 again. Why tarballs.nixos.org is used as a backup, I do not know. I do not recall ever having seen this behaviour before. Hope this helps a bit though! Best wishes, Troy signature.asc Description: This is a digitally signed message part
Re: Magic Wormhole Package Weirdness/Potential Security Issues?
If you only change the version number, guix will cry to download that version. If it fails, then it relies on the provided hash to fetch from a content-adressed store, such as ci or sohtware heritage. It relies on the hash as the source of truth. Usually, when updating a package, I alter the hash to make sure it doesn't build the old version. Replace the initial 1 with a 0 or initial 0 with a 1, and you get a wrong hash. If it fails to download the file, you'll notice immediately. Otherwise, it will print the expected hash. Le 8 novembre 2024 20:18:54 GMT+01:00, Troy Figiel a écrit : >Hi Juli, > >On Fri, 2024-11-08 at 13:26 -0500, Juliana Sims wrote: >> To cover all my bases, I pk'd the hash produced by `pypi-uri` and >> used >> `guix download` to try to fetch the same file and check its hash, >> only >> to find that `guix download` couldn't find anything at that URL or >> its >> fallbacks. > >It seems at some point in between version 0.14.0 and 0.17.0 the name of >the tarball has changed from `magic-wormhole` to `magic_wormhole`. You >have to change the uri-field accordingly to successfully download the >source code from PyPI. > >When building it in the way you describe, the source code cannot be >found on PyPI, so it is pulled from tarballs.nixos.org instead. It >seems NixOS uses content-addressable storage, so the hash is used to >download the source code and since you have not changed the hash, it >downloads version 0.14.0 again. > >Why tarballs.nixos.org is used as a backup, I do not know. I do not >recall ever having seen this behaviour before. > >Hope this helps a bit though! > >Best wishes, > >Troy
Re: Bug triage
This email just to add Arun to the loop, IIUC he's also working on this. On 2024-11-08 15:11, Rostislav Svoboda wrote: > Hello, > >> I've tried to do some bug/patch triage yesterday and marked a bunch of >> patches as "easy" > > How well does mumi, the issue tracker, support predicates? > > This does not work: 'tag:easy AND (NOT (is:closed OR is:done))' > https://issues.guix.gnu.org/search?query=tag%3Aeasy+AND+%28NOT+%28is%3Aclosed+OR+is%3Adone%29%29 > > This works: 'tag:easy AND (is:closed OR is:done)' > https://issues.guix.gnu.org/search?query=tag%3Aeasy+AND+%28is%3Aclosed+OR+is%3Adone%29 > > (It would be great to have little explanation and/or an example under the > Hint and/or Help https://issues.guix.gnu.org/help#search) > > Cheers Bost -- Best regards, Nicolas Graves
Re: Bug triage
Hi, > Isn't this the same as [...] I wasn't talking about the meaning of the predicates in my examples. I wanted to point out that: - it would be nice to have a few predicate examples under the Hint and/or in the Help https://issues.guix.gnu.org/help#search - it seems like negation (i.e. "NOT") can't be used to form a predicate. Cheers Bost
Re: Bug triage
Hi, On 8/11/24 14:11, Rostislav Svoboda wrote: Hello, > I've tried to do some bug/patch triage yesterday and marked a bunch of > patches as "easy" How well does mumi, the issue tracker, support predicates? This does not work: 'tag:easy AND (NOT (is:closed OR is:done))' https://issues.guix.gnu.org/search?query=tag%3Aeasy+AND+%28NOT+%28is%3Aclosed+OR+is%3Adone%29%29 Isn't this the same as requesting open issues tagged "easy"? Because, if I understand correctly, that is done by typing «tag:easy is:open» (without the quotes): https://issues.guix.gnu.org/search?query=is%3Aopen+tag%3Aeasy This works: 'tag:easy AND (is:closed OR is:done)'https://issues.guix.gnu.org/search?query=tag%3Aeasy+AND+%28is%3Aclosed+OR+is%3Adone%29 And this would be «tag:easy is:closed» (I think closed and done are the same): https://issues.guix.gnu.org/search?query=tag%3Aeasy+is%3Aclosed OpenPGP_0x0AB0D067012F08C3.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Fwd: Re: New North American based Guix Substitute Server, cuirass.genenetwork.org Now Available
Didn't send this to the mailing list by accident. Forwarding for reference. Start of forwarded message From: "Collin J. Doering" To: Vagrant Cascadian Subject: Re: New North American based Guix Substitute Server, cuirass.genenetwork.org Now Available Date: Mon, 04 Nov 2024 10:55:09 -0500 Hi Vagrant, Firstly, thanks for reaching out! > The last evaluation that actually seems to have succeeded was from late > August: > > https://cuirass.genenetwork.org/eval/154706 > > All the evaluations since then have failed, up until around > mid-september... I am aware of the evaluation failures, but haven't got around to resolving it. However, your email was the push I needed (thank you!), and I have now opened https://issues.guix.gnu.org/74203. TLDR: builds started failing due to a coreutils test that occasionally can fail on systems using btrfs. I hope to get this resolved ASAP so newer evaluations and substitutes can be built. > I was pretty thrilled to use it while it was working... especially as it > provided another reference point to check reproducible builds of guix! That's great to hear! We're excited about it too! > I imagine running a whole build farm would be pretty intensive resource. > S... I am curious what the current prospects are of getting it > running again? :) Yes, definitely not a cheap endeavor. I'm very gracious for the folks at University of Tennessee for their support (and patience as I get this resolved). Please keep an eye on the issue I opened up, as once resolved, I should be able to get builds running again on cuirass.genenetwork.org. Thanks again for reaching out, and excited to hear you've been getting value out of cuirass.genenetwork.org (at least, while it was building)! On 03 Nov 2024 at 20:43, Vagrant Cascadian wrote: > On 2024-07-06, Collin J. Doering wrote: >> I am excited to announce that Guix substitutes (for x86_64) are now >> available in North America, thanks to the generous contribution of >> server hardware and infrastructure from GeneNetwork.org. > > The last evaluation that actually seems to have succeeded was from late > August: > > https://cuirass.genenetwork.org/eval/154706 > > All the evaluations since then have failed, up until around > mid-september... > > I was pretty thrilled to use it while it was working... especially as it > provided another reference point to check reproducible builds of guix! > > I imagine running a whole build farm would be pretty intensive resource. > S... I am curious what the current prospects are of getting it > running again? :) > > > live well, > vagrant -- Collin J. Doering http://rekahsoft.ca http://blog.rekahsoft.ca http://git.rekahsoft.ca signature.asc Description: PGP signature End of forwarded message -- Collin J. Doering http://rekahsoft.ca http://blog.rekahsoft.ca http://git.rekahsoft.ca signature.asc Description: PGP signature
Re: Bug triage
Hello, > I've tried to do some bug/patch triage yesterday and marked a bunch of > patches as "easy" How well does mumi, the issue tracker, support predicates? This does not work: 'tag:easy AND (NOT (is:closed OR is:done))' https://issues.guix.gnu.org/search?query=tag%3Aeasy+AND+%28NOT+%28is%3Aclosed+OR+is%3Adone%29%29 This works: 'tag:easy AND (is:closed OR is:done)' https://issues.guix.gnu.org/search?query=tag%3Aeasy+AND+%28is%3Aclosed+OR+is%3Adone%29 (It would be great to have little explanation and/or an example under the Hint and/or Help https://issues.guix.gnu.org/help#search) Cheers Bost
Re: (unrelated and off-topics) Visiting a future of GNU
Am Fri, Nov 01, 2024 at 02:53:56PM +0100 schrieb Ricardo Wurmus: > The GNU Assembly ended up being rather immobilized by Not to mention Covid. And the fact that the hard part would have started when we wanted to not just define our basic manifesto, but move on to concrete governance structures. Notice that this is also where we are currently stuck in Guix... Andreas
Re: Running a Guix User and Contributor survey
Hi Denis, Thanks for reading through it. On 5 Nov, Denis 'GNUtoo' Carikli wrote: > On Wed, 30 Oct 2024 12:03:26 + > Steve George wrote: > Here's some feedback on the proposal below. > > > # Audience > > The audience for this survey are all Guix users and contributors > > [^1]. This means: > > > > - Guix user: anyone who uses all or part of Guix, whether as their > > operating system or hosted on another GNU/Linux distro. > > - Guix contributor: anyone who sends changes (patches) to the > > project. This includes code changes, but also other improvements > > including documentation, design and translation. This is an extensive > > group beyond those with commit rights. > > - Guix community: the totality of both groups. > Most Guix contributors are also users, so this may need to be reflected > in some ways. (...) This is a difficult to do in a nice way without a wall of text. It's a key question so I've added help text: For this question choose **User** if you use Guix: this includes community members who promote the project and take part in the support channels. Choose **Contributor** if you also sent patches of any form: whether those are code, documentation, translations or anything else. Choose **Committer** if you have access to the Guix Git repository. (...) > > **Q1. How knowledgeable a Linux user are you?** > GNU/Linux would probably be better given the audience here. > > > - an official GNU FSF (Free Software Foundation) project > The distribution is certified by the FSF but it's a GNU package. The > FSF doesn't maintain the Guix package though. > > So maybe this could be better: > > **Q5. Why were you initially interested in Guix?** > [...] > > An FSF certified 100% free software distribution. > I think these are equivalent to be honest, but happy to change it. > I'm also unsure if it should be added to the list or not but being able > to install software on top of another distribution is a common use case > so that might be a reason to use it. And this can be done for a wide > variety of reasons (ship software to users, use it in some QA process, > etc). > > I'm also aware that this option is also included in a question on how > we use Guix. (...) Added it, since that's certainly the reason I started using Guix. This question is trying explore the "initial interest" so it's reasonable to have a variety of things. Steve / Futurile
system-sexps?
Hi, I am trying to troubleshoot some old code (bug#74272). Did there used to be a guix function called system-sexps? Can anyone tell me where it used to be, or what function replaced it? -- 📛 Christopher Howard 🚀 gemini://gem.librehacker.com 🌐 http://gem.librehacker.com בראשית ברא אלהים את השמים ואת הארץ
