bug#68895: `guix repl` breaks Guile REPL features
Adriel Dumas--Jondeau writes: > (guix-user)> ,use (guix scripts build) > (guix-user)> ,trace (guix-build "hello") ; doesn't output any trace for some > reason It looks like this isn't the only REPL command that doesn't work in `guix repl`. I haven't done anything close to a full investigation (I am new to using Guile!), but many other commands simply don't work. For example, breakpoints are not respected. `guix repl`: --8<---cut here---start->8--- scheme@(guix-user)> (define (my-f x) (+ x 1)) scheme@(guix-user)> ,break my-f Trap 0: Breakpoint at #. scheme@(guix-user)> (my-f 2) $1 = 3 --8<---cut here---end--->8--- `guile`: --8<---cut here---start->8--- scheme@(guix-user)> (define (my-f x) (+ x 1)) scheme@(guix-user)> ,break my-f Trap 0: Breakpoint at #. scheme@(guix-user)> (my-f 2) $1 = 3 --8<---cut here---end--->8--- Neither are tracepoints. `guix repl`: --8<---cut here---start->8--- scheme@(guix-user)> (define (my-f x) (+ x 1)) scheme@(guix-user)> ,tracepoint my-f Trap 0: Tracepoint at #. scheme@(guix-user)> (my-f 2) $1 = 3 --8<---cut here---end--->8--- `guile`: --8<---cut here---start->8--- scheme@(guile-user)> (define (my-f x) (+ x 1)) scheme@(guile-user)> ,tracepoint my-f Trap 0: Tracepoint at #. scheme@(guile-user)> (my-f 2) Trap 0: (my-f 2) Trap 0: 3 $1 = 3 --8<---cut here---end--->8---
bug#75552: Non-committers can't keep authenticated forks updated
Hi Guix, A small update - I've implemented a `guix fork` command that should solve this issue. I opened a new issue for it rather than spamming both guix-devel and help-guix with patches: https://lists.gnu.org/archive/html/guix-patches/2025-01/msg02847.html And here is a link to v1.5 of the same series, since lists.gnu.org splits the thread index by month: https://lists.gnu.org/archive/html/guix-patches/2025-02/msg00024.html It's not ready to merge, but it is ready for testing and feedback. Plus, v1.5 is good enough to use to set up your own fork, or to convert your existing fork into a properly authenticated one. Hope this helps, 45mg
bug#30642: LibreOffice crashes with 'org.gtk.Settings.FileChooser' is not installed error
Hi all, Though the bug is closed, I still faced this issue. Solution was to explicitly install gtk+ along with libreoffice (ie. specify it in the 'packages' field of my home-environment declaration, in my case). I'm not sure if this is expected or if there's any way to fix it. Just wanted to share how I got it to work. I should note that in order to run libreoffice even in a `guix shell`, you need to specify gtk+, as well as coreutils and sed (for the /bin/libreoffice startup script, I think) - guix shell --pure coreutils sed libreoffice -- libreoffice
bug#30642: LibreOffice crashes with 'org.gtk.Settings.FileChooser' is not installed error
45mg <45mg.wri...@gmail.com> writes: > guix shell --pure coreutils sed libreoffice -- libreoffice Argh, typo. Should have been: guix shell --pure gtk+ coreutils sed libreoffice -- libreoffice
bug#30642: LibreOffice crashes with 'org.gtk.Settings.FileChooser' is not installed error
Hi Tomas, Tomas Volf <~@wolfsden.cz> writes: > I have sent a series fixing the issue (/me checks the list of open > bugs) 1 year, 3 weeks, 2 days ago. Would you mind linking to it? I am unable to solve this riddle :) I checked the issue tracker and did a 'date:400 days .. 365 days' Notmuch search over the bug-guix and guix-patches archives, but couldn't find your patch series.
bug#75822: guix home/system don't report errors in loaded modules
Attached is a tarball that can be used to minimally reproduce the issue. There are two files - test-home.scm and test-home-packages.scm. The latter defines and exports `%my-packages`, but before it's defined, line 5 has an error. --8<---cut here---start->8--- $ guix home build -L . test-home.scm ice-9/eval.scm:223:20: In procedure proc: error: %my-packages: unbound variable hint: Did you forget `(use-modules (test-home-packages))'? --8<---cut here---end--->8--- I would expect to see a report of the error on line 5, but that doesn't happen. `guix system` behaves the same way. This becomes extremely annoying once you have a large configuration split up between separate files, because if you make a mistake in any file except the one being passed to `guix home` or `guix system`, you don't see the error message for it. guix-L-test.tar Description: archive/tar
bug#75552: Non-committers can't keep authenticated forks updated
Hi Nicolas! Nicolas Graves writes: > A lightly-related comment : > > I recently started a guix extension to help manage complexities of > maintaining guix soft-forks. I haven't advertised it yet, and I'm fine > authenticating locally for now. I mainly focus on reproducibility of > patches sent (recording where patches are sent to be able to generate a > list of patches from a repo) and pulling from patched channels. > > There still some work ahead before I can even advertise it properly, but > feel free to take a look! There's no doc yet. > > https://git.sr.ht/~ngraves/guix-stack Sounds cool! Please let us know once you've added documentation so we can take a look. We definitely need more tooling in this regard.
bug#75843: shepherd: cron-string->calendar-event does not accept "*/15 * * * *"
Tomas Volf <~@wolfsden.cz> writes:
> ERROR: In procedure eval:
> ERROR:
> 1. &message: "\"*/15 * * * *\": invalid minutes cron field"
> --8<---cut here---end--->8---
>
> It seems to work with 0-59/15, so there possibly is some bug in handling
> the *.
I get a similar error with `(cron-string->calendar-event "* * * * *")`
in a `shepherd-service`:
--8<---cut here---start->8---
$ sudo guix system reconfigure config.scm
...
guix system: warning: exception caught while executing 'eval' on service 'root':
Throw to key `%exception' with args `("#<&message message: \"calendar-event:
hours: 24: value out of range (0-23)\">")'.
--8<---cut here---end--->8---
but '* 0-23 * * *' works.
bug#75843: shepherd: cron-string->calendar-event does not accept "*/15 * * * *"
45mg <45mg.wri...@gmail.com> writes: > I get a similar error with `(cron-string->calendar-event "* * * * *")` [...] > but '* 0-23 * * *' works. Oh, nevermind, you already opened a separate bug for this: https://issues.guix.gnu.org/75836
bug#75552: Non-committers can't keep authenticated forks updated
t was merged... The idea is - the primary introduction is for the part of the tree under YOUR control. When you fork Guix and create your own branch, you use the initial commit on your branch as the primary channel introduction. You add upstream Guix's primary channel introduction as an additional channel introduction. If you add anyone else's fork as a remote and pull one of their branches, you add their primary introduction as one of your additional introductions. Thus, any merge into one of YOUR branches (ie. any branch with the primary introduction as the most recent ancestor) only needs to be signed by a key that's authorized on that branch. But you can't merge into a branch from upstream Guix or someone else's authenticated fork (unless you're authorized to commit to those), because the first parent of the merge commit would not be a primary parent (see 2b) - it would be a commit on someone else's branch. And people not authorized by you can't merge into your branch either, because of 2a. And finally, you can't merge someone else's fork and upstream, or anything like that. The merge commit would not be authenticated in any of these cases. --8<---cut here---end--->8--- So What Do You Want From Me Anyway, 45mg? I've tried to think of ways in which this modification to the behaviour of `guix git authenticate` could compromise security, but so far I haven't been able to think of any attacks it might enable. Of course, this only means that /I/ haven't been able to think of anything wrong. You, dear reader, have the advantage of a unique perspective and a fresh view on this idea. So, I'm hoping that you'll be able to sniff out any fundamental issues with the design here. I've actually started work on a patch series to implement this, but it's going to be pretty slow going - I've spent several hours on it so far, and I'm maybe a fifth of the way done. (Obviously, I'm going to have to pace myself more; so don't hold your breath.) In the meantime, if there's a fundamental problem with the approach I've described, I hope you will be able to find it sooner rather than later, before I sink even more time and energy into this endeavor. Thanks for reading this far, and here's hoping we can achieve a better experience for budding contributors! 45mg [1] https://lists.gnu.org/archive/html/guix-devel/2025-01/msg00072.html [2] https://lists.gnu.org/archive/html/help-guix/2023-09/msg00078.html [3] https://git.wolfsden.cz/guix/tree/etc/0001-git-authenticate-Trust-all-keys-from-already-authent.patch [4] https://lists.gnu.org/archive/html/help-guix/2025-01/msg00097.html [5] https://lists.gnu.org/archive/html/help-guix/2025-01/msg00101.html [6] From the 'Securing Updates' Guix blog post: > A commit is considered authentic if and only if it is signed by > one of the keys listed in the .guix-authorizations file of each of > its parents. This is the authorization invariant. https://guix.gnu.org/en/blog/2020/securing-updates/ [7] https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection
bug#75550: smartd fails to send an email
Hi Tomas, Tomas Volf <~@wolfsden.cz> writes: > Hi, > > I have tried to write a service type for smartd from smartmontools, > however the bundled script fails. > > When the test (-m root -M test) is executed, some programs seem to be > missing in the $PATH: > > --8<---cut here---start->8--- > Jan 14 01:34:19 localhost smartd[3138]: Executing test of to root ... > Jan 14 01:34:19 localhost smartd[3138]: Test of to root produced > unexpected output (118 bytes) to STDOUT/STDERR: > Jan 14 01:34:19 localhost smartd[3138]: > /gnu/store/ks6lnp8hssm9zkka47ysa4qp9xd9f8bv-smartmontools-7.4/etc/smartd_warning.sh: > line 132: sed: command not found > Jan 14 01:34:19 localhost smartd[3138]: Test of to root: failed > (32-bit/8-bit exit status: 32512/127) > --8<---cut here---end--->8--- I've seen other package definitions deal with this problem by using `substitute*` to replace executables specified in scripts, etc. (like sed here) with the corresponding store paths. See 'light' in (gnu packages linux) for an example.
bug#75552: Non-committers can't keep authenticated forks updated
Hi Liliana, Liliana Marie Prikler writes: > Hi, > > Am Mittwoch, dem 15.01.2025 um 15:48 + schrieb 45mg: >> The idea of authentication is that once you trust the channel >> introduction, you can be sure that everything you pull after that is >> authentic. The introduction only needs to be trusted once. If you're >> bumping the introduction every time, then you need to obtain and >> verify the introduction every time. You're going from 'Trust On First >> Use' to 'Trust On Every Use'. Not ideal IMO. > Let's recall that the entity you need to trust is still yourself in > most of those cases. If you host your repo unauthenticated on a server, you need to fully trust the server, as well as the connection between you and the server. Regarding the former, none of the most popular ways to host a git repo (eg. GitHub, Codeberg, your own forge instance on a VPS) allow you to know much about the underlying server, so you can't really assume it to be secure. The latter is a ridiculously complicated topic that I'm not qualified to go into. To avoid trusting all these intermediaries more than once if at all, we have authentication. I realise it may seem silly to worry about your own little fork being directly targeted in ways like this, but the main reason I chose Guix in the first place is the focus on getting the fundamentals right - reproducibility, bootstrappability, free software, etc. - even though most projects don't put in as much effort towards them, and even though a lot of users may not be directly affected by these things. I think security is one such thing. As the 'Authenticate Your Git Checkouts' blog post [9] pointed out, we wouldn't need `guix git authenticate` if we were willing to delegate our security to a trusted third party, like all the open source projects that sport those "fancy “✅ verified” badges as found on GitLab and on GitHub" do. We shouldn't force anyone hosting a fork to do so as well. >> You could do it like this: >> 0) Before creating your fork, authenticate every commit in the Guix >> checkout (as described in the manual). >> 1) Switch to your branch that tracks upstream. >> 2) Pull from upstream. >> 3) Run `guix git authenticate`, supplying Guix's channel introduction >> as >> arguments. >> 4) After this succeeds, create and switch to a branch from the >> current >> tip of your upstream-tracking branch. Edit .guix_authorizations to >> add your key, and create a signed commit. >> 5) Merge this branch into your fork branch. >> 6) Switch back to your fork branch. >> 7) Delete the [guix "authentication"] section from .git/config. >> 8) Run `guix git authenticate` with the introduction of your fork >> branch, to authenticate the merge commit. >> >> That's a lot of manual steps for every pull from upstream! While I do >> have to give you credit for this idea - at least we now have a >> workaround for people who are determined enough - I'm guessing a lot >> of people will probably just skip authentication if it's going to be >> this annoying. Authenticating a fresh clone from scratch will be even >> more annoying, especially if you have multiple fork branches (eg. >> you're tracking someone else's fork). > I think you're making this more complicated than it needs to be. > checkout, authenticate, rebase*, merge* ought to have you covered. > > * you can authenticate after these if you're paranoid The complexity is due to the requirements of not bumping the channel introduction (to avoid the increased attack surface from having to keep obtaining the updated one, as I discussed earlier), keeping fork history intact (to avoid force pulls), keeping upstream history intact, and being able to authenticate both upstream and fork commits. If you can think of a simpler method that meets these requirements, I'd love to hear it. Also, I just realised that this one won't even work. The commit created in step 4 cannot be authenticated, as it's signed with your key, which is not in its parent's .guix_authorizations. >> We could create a script to do all the steps for us, but if and when >> it fails on whatever insane edge cases people are able to come up >> with, they're going to need to understand all the steps involved >> anyway. Abstraction is not a substitute for a clean underlying >> design. >> >> Also I just want to point out that rebasing /will/ change the >> history. >> The `guix pull` after every time you update your fork will need to be >> a force-pull (--allow-downgrades [1]). > No, it wouldn't. You would rebase those changes on t
bug#75552: [Attila Lendvai] Re: Non-committers can't keep authenticated forks updated
Forwarding Attila's message here, because it wasn't sent to bug-guix, so
it may not have reached some of you and won't show up in the issue
tracker.
As far as I can tell, this is exactly what the 'rebase' approach
mentioned upthread would look like in practice. As mentioned, it has the
problem of having to bump the introduction every time, and I've written
about the security aspects of this (beginning of [1]). Also, as Attila
notes, it's burdensome.
[1] https://lists.gnu.org/archive/html/bug-guix/2025-01/msg00135.html
Start of forwarded message
Date: Wed, 15 Jan 2025 17:15:44 +
To: 45mg <45mg.wri...@gmail.com>
From: Attila Lendvai
Cc: Felix Lechner , Tomas Volf <~@wolfsden.cz>,
help-g...@gnu.org, guix-de...@gnu.org
Subject: Re: Non-committers can't keep authenticated forks updated
i haven't read the entire thread [sorry], but with that in mind here's how i'm
solving this:
i have various branches where i keep my not-yet-merged work. i also have a
script that creates/overwrites a branch (called 'attila', starting at the tag
'attila-baseline') and cherry picks everything into it. i sometimes `git tag
-f` the 'attila-baseline' tag to pick a new baseline.
then i update my intro commit hash wherever i want to pull my
rebased/cherry-picked changes (this is a several machines setup, and yes, it's
burdensome).
when a cherry pick fails, then i cancel the script, rebase the problematic
branch on 'attila-baseline', and restart the script pasted below.
--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Is there an idea more radical in the history of the human race than turning
your children over to total strangers whom you know nothing about, and having
those strangers work on your child's mind, out of your sight, for a period of
twelve years? […] Back in Colonial days in America, if you proposed that kind
of idea, they'd burn you at the stake, you mad person! It's a mad idea!”
— John Taylor Gatto (1935–2018), Teacher of the Year, both in New York
City and State, multiple times
#!/usr/bin/env bash
BRANCHES="kludges ui-warnings print-branch-name"
BRANCHES+=" shepherd-guix-side"
set -e
initial_branch=$(git branch --show-current)
git rebase attila-baseline attila-initial-commit
git checkout attila
git reset --hard attila-baseline
git pull . attila-initial-commit
for branch in ${BRANCHES}; do
echo "*** Processing branch ${branch}"
#git rebase attila-baseline $branch
git cherry-pick attila-baseline..$branch
done
#git checkout $initial_branch
git -c pager.log=false log --pretty=oneline
attila-initial-commit~1..attila-initial-commit
End of forwarded message
bug#75552: Non-committers can't keep authenticated forks updated
Liliana Marie Prikler writes: [...] > You can roll your own service definitions, but it does become harder > when you want to keep all changes to that service from master as well. > But `(use-modules (my-channel services nftables))` should pull that > nftables code :) [...] >> Then there is anything modifying any of the guix commands. #74832 is >> over month old, and as far as I know, I am not able to fix guix-copy >> from a channel. #72928 took over a month to merge, and again, not >> sure how to patch guix-describe from a channel. > Have you considered extensions? [...] >> (Yes, I am aware I can just copy&paste the service code into my >> channel. But at that point I am again just "replicating Guix", just >> by more manual and error-prone means. And even for packages, >> adjusting system configuration to use package from my channel, >> getting it merged and then adjusting back to upstream is annoying >> chore.) > You could code your channel in a way that it serves upstream stuff > either silently or with a deprecation warning if a particular package > is requested. Not a channel, but [1] illustrates my point. You could probably get all these ideas to work. But try to put yourself in the shoes of someone who's just sent any of these patches. After putting in the hard work to fix an issue by modifying the upstream code, they now need to fix it AGAIN in a different way (via their channel). Imagine trying to reimplement something as complex as the bootloader subsystem rewrite [2] in your channel. If you're going to have to incorporate every contribution into your channel, you're heavily incentivized to only ever work on your channel, and never bother sending any patches to upstream. > Cheers > > [1] > https://git.ist.tugraz.at/clingabomino/clingabomino/-/blob/0.2.0/pkg/guix.scm?ref_type=tags#L30
bug#75552: Non-committers can't keep authenticated forks updated
Hi Liliana, Liliana Marie Prikler writes: > Am Donnerstag, dem 16.01.2025 um 13:10 + schrieb 45mg: >> As the 'Authenticate Your Git Checkouts' >> blog post [9] pointed out, we wouldn't need `guix git authenticate` >> if we were willing to delegate our security to a trusted third party, >> like all the open source projects that sport those "fancy “✅ >> verified” badges as found on GitLab and on GitHub" do. We shouldn't >> force anyone hosting a fork to do so as well. > I mean, you can host your own fork and use the fancy “✅ verified” badge > of your host as source of trust – it just won't be checked by `guix > pull', that's all. If you do do that, I'd recommend using a file:// > URI with a local checkout for your channel, so that you can verify that > little check mark on your own (then you only need to trust your own > file system). Yeah, I know I can. My point is that people who use remote forks shouldn't have to rely on a trusted third party. We've figured out a way for upstream Guix not to have to, now let's try to extend that to forks. >> > I think you're making this more complicated than it needs to be. >> > checkout, authenticate, rebase*, merge* ought to have you covered. >> > >> > * you can authenticate after these if you're paranoid >> >> The complexity is due to the requirements of not bumping the channel >> introduction (to avoid the increased attack surface from having to >> keep obtaining the updated one, as I discussed earlier), keeping fork >> history intact (to avoid force pulls), keeping upstream history >> intact, and being able to authenticate both upstream and fork >> commits. If you can think of a simpler method that meets these >> requirements, I'd love to hear it. > Guix committers are more than happy to use work trees and rebases, > which simplify this a lot – again, it's as simple as pull, > authenticate, rebase. No doubt this works for those with commit access. The title of this issue is 'Non-committers can't keep authenticated forks updated'. Since most future committers will take years to attain that status, and many (most?) Guix contributors can't commit (heh) to being committers, I think it would be a good thing for them to be able to make use of our security mechanisms. (Actually, if you mean the variant of rebasing you describe below, then I see what you mean, never mind) > W.r.t. keeping history intact, we had the following exchange on IRC > yesterday. > > lfam: that's interesting that there is really a merge > commit, for example if I remember right, the core updates merge few > months ago happened by directly appending the commits instead of a > merge commit > Yes, there are two ways to do it (rebase and merge) and it's a > matter of taste > Of course there is a correct choice, as with all questions of > taste ;) > I personally prefer a merge commit, since it has two > parents, you can track where the previous master pointed to > And I prefer a rebase. But ultimately it's up to whoever is in > front of the keyboard >FWIW, a rebase is cleaner, but requires that only one person > signs off commits on any given branch (or else you're signing commits > that someone else signed before and have to update the trailer… not > ideal) > It doesn't matter who signs the commits as long as they are > authorized. That's the security model we have > > So yeah, even for (branch-)local work at least some committers prefer > rebasing. That seems to be a discussion about a merge commit in upstream Guix, not about the kind of merge commits that I'm trying to allow. Again, not disputing that things work fine for people with commit access. Perhaps that is part of why this issue hasn't been addressed before :P >> > No, it wouldn't. You would rebase those changes on top of what you >> > already have on those respective branches. >> >> It looks like at least one of us is misunderstanding rebasing. Could >> be me, so I'm consulting the relevant chapter from the Pro Git book >> [11] for a refresher. >> >> Let's imagine that the first example given there represents our fork >> of Guix, where the 'experiment' branch marks the beginning of our >> fork (and its channel introduction) and the 'master' branch tracks >> upstream Guix. After `git rebase master`, the commit that used to be >> C4 is gone, and now C4' takes its place. It may contain the same >> changes, but it's a different commit - so it (and any commits that >> it's the paren
bug#75552: Non-committers can't keep authenticated forks updated
Hi Liliana! Liliana Marie Prikler writes: > For most use cases, this is a non-issue. Assuming you are a single > committer to your fork, you can always rebase your changes on top of > Guix (if you're willing to bump the introductory commit) The idea of authentication is that once you trust the channel introduction, you can be sure that everything you pull after that is authentic. The introduction only needs to be trusted once. If you're bumping the introduction every time, then you need to obtain and verify the introduction every time. You're going from 'Trust On First Use' to 'Trust On Every Use'. Not ideal IMO. > or sign the changes to Guix with your own key (if you are willing to > accept that this changes the history). With multiple committers, you > will need to do the latter. While this could actually work, without changing the history, the problem is that there is no easy way to authenticate upstream commits. You could do it like this: 0) Before creating your fork, authenticate every commit in the Guix checkout (as described in the manual). 1) Switch to your branch that tracks upstream. 2) Pull from upstream. 3) Run `guix git authenticate`, supplying Guix's channel introduction as arguments. 4) After this succeeds, create and switch to a branch from the current tip of your upstream-tracking branch. Edit .guix_authorizations to add your key, and create a signed commit. 5) Merge this branch into your fork branch. 6) Switch back to your fork branch. 7) Delete the [guix "authentication"] section from .git/config. 8) Run `guix git authenticate` with the introduction of your fork branch, to authenticate the merge commit. That's a lot of manual steps for every pull from upstream! While I do have to give you credit for this idea - at least we now have a workaround for people who are determined enough - I'm guessing a lot of people will probably just skip authentication if it's going to be this annoying. Authenticating a fresh clone from scratch will be even more annoying, especially if you have multiple fork branches (eg. you're tracking someone else's fork). We could create a script to do all the steps for us, but if and when it fails on whatever insane edge cases people are able to come up with, they're going to need to understand all the steps involved anyway. Abstraction is not a substitute for a clean underlying design. Also I just want to point out that rebasing /will/ change the history. The `guix pull` after every time you update your fork will need to be a force-pull (--allow-downgrades [1]). > Of course, you can also keep your own fork unauthenticated, which > might be preferable if you only do local work anyway, but that's > besides the issue here. Yes, to be clear, I'm talking about the use-case where your fork is hosted remotely, and you or someone else needs to pull changes from it. For example, my prospective use case would be quickly bootstrapping Guix on a new machine - I build my own installation image, and I'd want it to pull from my fork. I can include my introduction into my installer, just like the official one. But if the introduction changes before I use my installer, then the first pull can't be authenticated. > This does not state how the additional introductions are used, if at > all. It may mean that the additional introductions are pointless other > than for blocking case 4. My bad, I guess I forgot to explain that. The purpose of the additional introductions is to make it so that signed commits from upstream Guix, or commits from other people's forks, can still be authenticated. As I mentioned above, the current design is not suited to this. To go a bit more into detail - we will accomplish authentication by doing a postorder traversal of the commit tree, considering the latest commit as the root node. We traverse its parents recursively until we reach a commit whose parent is one of the channel introductions (primary or additional). Then that commit and all its children are authenticated from the introduction that we encountered. In this way, every commit is authenticated from the introduction that is its most recent ancestor. > I think this might still hide a serious flaw. With the way *upstream* > authentication works. Let's flip the example in [6] around a little > bit and construct the following: > > -A---B---C---D > \ \ >\ \-E---F---💀 > \ / > \G--H--I*-/ > > Both A and I* are introductory commits on their various branches. In > 💀, any committer who has valid keys in both F and I* can merge a > branch with unsigned commits, effectively voiding the invariant of > BCEF, e.g. by undoing any changes that happened there. Of course, they > can do so with signed commits as well, given that they have commit > access to the main repository, but the point still holds that they may > introduce unsigned commits to any fork where their key is valid in. So, my design enables an attacker who can make a
bug#76660: current guix pull doesn't authenticate
Tomas Volf <~@wolfsden.cz> writes: > There is git_graph_descendant_of function in libgit2, but it is not > exposed by the guile-git binding. Maybe we could try to use it to > implement the check instead the current approach (which does it in > Guile). I wonder how well that would perform compared to --is-ancestor. I actually opened a MR to add that binding upstream. Maybe copying the code from there might save you a little bit of work: https://gitlab.com/guile-git/guile-git/-/merge_requests/38
bug#76418: distrobox: incomplete dependencies
Consider: --8<---cut here---start->8--- $ guix shell --pure distrobox -- distrobox enter container-name /gnu/store/rmqfnbqa517s5y4acx6fbmgfr148vj83-profile/bin/distrobox: line 61: dirname: command not found ...(trial and error) $ guix shell --pure distrobox coreutils sed gawk grep -- distrobox enter container-name /gnu/store/fhyzghpyr1ql4x7a1iz8bkv9lkprqc73-profile/bin/distrobox-enter: line 728: rev: command not found /gnu/store/fhyzghpyr1ql4x7a1iz8bkv9lkprqc73-profile/bin/distrobox-enter: line 733: exec: exec: not found $ guix shell --pure distrobox coreutils sed gawk grep util-linux -- distrobox enter container-name (success) --8<---cut here---end--->8--- Distrobox is a collecton of shell scripts, of which `distrobox-enter` is just one. I'd be willing to guess that the remaining scripts also require various other utils, which need to be added as dependencies [1]. To figure out what these are, one could attempt to use each of the distrobox subcommands in a `guix shell`, as shown above. Normally I'd get to work on a patch, but I ended up deciding against using distrobox, so I won't be working on this. Just thought I should point it out, anyway. Good luck, 45mg P.S Maybe we should ask contributors to test that their package works in `guix shell`? Along with the other instructions in "(guix) Submitting Patches". [1] Notably, distrobox-host-exec requires flatpak to be installed on the host. AFAICT this is not documented /anywhere/: https://github.com/89luca89/distrobox/issues/1692
bug#76660: current guix pull doesn't authenticate
Tomas Volf <~@wolfsden.cz> writes: > Jack Hill writes: [...] >> jackhill@lissome ~$ guix pull >> Updating channel 'guix' from Git repository at >> 'https://git.savannah.gnu.org/git/guix.git'... >> guix pull: error: aborting update of channel 'guix' to commit >> 6ca7b07a251739dfaefa639e74c01e3013c9454c, which is not a descendant of >> f13f0769688493271f43f31a016957355dbecb30 >> hint: This could indicate that the channel has been tampered with and is >> trying to force a >> roll-back, preventing you from getting the latest updates. If you think >> this is not the >> case, explicitly allow non-forward updates. >> >> I don't have reason to believe the channel needs to be rolled back, I assume >> something is wrong with the savannah copy of the repo, but don't know. Can >> someone confirm? > > Can confirm. [...] > Given that f13f0769688493271f43f31a016957355dbecb30 has fairly large > commit message, maybe the known bugs in how we are using guile-git > finally caught up with us. I just re-authenticated my existing checkout of Guix from scratch (`rm -r ~/.cache/guix/authentication/* && guix git authenticate`), and the authentication was successful. (The checkout is up-to-date, as both 6ca7b07a251739dfaefa639e74c01e3013c9454c and f13f0769688493271f43f31a016957355dbecb30 can be found in `git log`.) However, I have not yet pulled 6ca7b07a251739dfaefa639e74c01e3013c9454c. I'm currently on b9063be5a73114c1bfb23121b7c9b612835d014d [1]. So, I think you're right - it's probably an issue in `guix pull` or the authentication mechanism, not the Guix repository (assuming that others can also reproduce this). [1] ...well, technically, I'm pulling from a personal authenticated fork where upstream commits are rebased onto the branch I pull from; so the hashes are all different even though the commit contents are all the same. So I'm not actually on b9063be5a73114c1bfb23121b7c9b612835d014d; rather, that's the last commit that I rebased onto my fork branch.
bug#30642: (close) Re: bug#30642: LibreOffice crashes with 'org.gtk.Settings.FileChooser' is not installed error
Nicolas Graves writes: > On 2025-02-17 13:22, Andreas Enge wrote: > >> Hello, >> >> I have just pushed the fix for the other bug. >> Could you please check that it solves this issue as well and close it >> in this case? > > I didn't experience the issue myself, can you do it 45mg? Thanks! Yep, it's fixed. Thanks everyone! > -- > Best regards, > Nicolas Graves
bug#76486: `guix substitute' occasionally crashes while looking for substitutes
Hi Timo, "Timo Wilken" writes: > substitute: looking for substitutes on 'https://bordeaux.guix.gnu.org'... > 0.0%guix substitute: error: TLS error in procedure > 'write_to_session_record_port': Error in the push function. > guix system: error: > `/gnu/store/jpbjljfva1hqspw1kd6hgnl63sgvw966-guix-1.4.0-32.5f6fdad/bin/guix > substitute' died unexpectedly This issue has been around for a while: https://yhetil.org/guix/1843db1b-0ed0-7e77-5a31-de8ee9ca5...@gmail.com/ I and others I know also face it.
bug#70826: [PATCH] system: Allow distinguishing s.
We use records to represent the different types of mapped devices (LUKS, RAID, LVM). When variables are defined for these records, we can distinguish them with eq?; when they are created by procedures, like luks-device-mapping-with-options, this does not work. Therefore, add a 'name' field to to distinguish them. * gnu/system/mapped-devices.scm (): Add name field. (luks-device-mapping, raid-device-mapping, lvm-device-mapping): Initialize it with appropriate values for each of these types. * gnu/system.scm (operating-system-bootloader-crypto-devices): Use it to identify LUKS mapped devices. Change-Id: I4c85824f74316f07239374d9df6c007dd47a9d0c --- I've tested this on my system; in conjunction with [1], I can finally mount my LUKS volume with the no_read_workqueue and no_write_workqueue flags. [1] [bug#77499] [PATCH] mapped-devices/luks: Support extra options. https://issues.guix.gnu.org/77499 https://yhetil.org/guix/fb637872bd14abe305d810b9d32e0db290b26dd6.1743702237.git.45mg.wri...@gmail.com/ gnu/system.scm| 6 -- gnu/system/mapped-devices.scm | 6 ++ 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/gnu/system.scm b/gnu/system.scm index 0d98e5a036..87247f06ee 100644 --- a/gnu/system.scm +++ b/gnu/system.scm @@ -16,6 +16,7 @@ ;;; Copyright © 2021 raid5atemyhomework ;;; Copyright © 2023 Bruno Victal ;;; Copyright © 2024 Nicolas Graves +;;; Copyright © 2025 45mg <45mg.wri...@gmail.com> ;;; ;;; This file is part of GNU Guix. ;;; @@ -676,8 +677,9 @@ (define operating-system-bootloader-crypto-devices "Return the sources of the LUKS mapped devices specified by UUID." ;; XXX: Device ordering is important, we trust the returned one. (let* ((luks-devices (filter (lambda (m) - (eq? luks-device-mapping -(mapped-device-type m))) + (eq? (mapped-device-kind-name + (mapped-device-type m)) +'luks)) (operating-system-boot-mapped-devices os))) (uuid-crypto-devices non-uuid-crypto-devices (partition (compose uuid? mapped-device-source) diff --git a/gnu/system/mapped-devices.scm b/gnu/system/mapped-devices.scm index 667a495570..50626b8df9 100644 --- a/gnu/system/mapped-devices.scm +++ b/gnu/system/mapped-devices.scm @@ -3,6 +3,7 @@ ;;; Copyright © 2016 Andreas Enge ;;; Copyright © 2017, 2018 Mark H Weaver ;;; Copyright © 2024 Tomas Volf <~@wolfsden.cz> +;;; Copyright © 2025 45mg <45mg.wri...@gmail.com> ;;; ;;; This file is part of GNU Guix. ;;; @@ -55,6 +56,7 @@ (define-module (gnu system mapped-devices) mapped-device-kind mapped-device-kind? +mapped-device-kind-name mapped-device-kind-open mapped-device-kind-close mapped-device-kind-modules @@ -110,6 +112,7 @@ (define-deprecated (mapped-device-target md) (define-record-type* mapped-device-kind make-mapped-device-kind mapped-device-kind? + (name mapped-device-kind-name) (open mapped-device-kind-open) ;source target -> gexp (close mapped-device-kind-close ;source target -> gexp (default (const #~(const #f @@ -283,6 +286,7 @@ (define* (check-luks-device md #:key (define luks-device-mapping ;; The type of LUKS mapped devices. (mapped-device-kind + (name 'luks) (open open-luks-device) (close close-luks-device) (check check-luks-device) @@ -338,6 +342,7 @@ (define (close-raid-device sources targets) (define raid-device-mapping ;; The type of RAID mapped devices. (mapped-device-kind + (name 'raid) (open open-raid-device) (close close-raid-device))) @@ -358,6 +363,7 @@ (define (close-lvm-device source targets) (define lvm-device-mapping (mapped-device-kind + (name 'lvm) (open open-lvm-device) (close close-lvm-device) (modules '((srfi srfi-1) base-commit: 0b754ceeded322e8079130e6793b0c68356967cf -- 2.49.0
bug#70826: [PATCH] system: Allow distinguishing s.
Hi Ludovic, Ludovic Courtès writes: > Hi 45mg, > > Did you have a chance to look into the proposed change below? > > Thanks, > Ludo’. Sorry for the delay, I've been quite busy lately. If I understand correctly, your proposal would make luks-device-mapping-with-options obsolete, so users would have to change from this: --8<---cut here---start->8--- (mapped-device (source "/dev/sdb1") (target "data") (type (luks-device-mapping-with-options #:allow-discards? #t))) --8<---cut here---end--->8--- to this: --8<---cut here---start->8--- (mapped-device (source "/dev/sdb1") (target "data") (type luks-device-mapping) (arguments (list #:allow-discards? #t))) --8<---cut here---end--->8--- Is that correct? Just trying to make sure I understand your idea. Regarding different arguments for open, close and check methods - I think it's fine to have a single keyword argument list like above, and then, like you suggested, have the methods only respect the keywords that are relevant to them (use `#:allow-other-keys #:rest keys` in the define* form). Like you said, this would lead to extra boilerplate (though we could reduce this by writing a procedure to inspect `keys` for a given keyword), but I think it would be more robust. At any rate, I should be able to work on this within two weeks at most; feel free to ping me if I don't send a v2 by then.
bug#78717: New etc-profile-d-service-type test fails, breaking many other tests
I noticed this when I ran the 'encrypted-home-os-key-file' test to test a new patch to [1], and it failed due to the '/etc/profile.d is sourced' test failing. Eventually I figured out that it fails on the latest master as well, and the latest CI run confirms this: https://ci.guix.gnu.org/build/10936896/details Looking at the log file, you can see the failing test: https://ci.guix.gnu.org/build/10936896/log/raw --8<---cut here---start->8--- ... Test begin: test-name: "/etc/profile.d is sourced" source-file: "/gnu/store/178h83msb53wf8v57zabi8s4q4ksfid8-encrypted-home-os-builder" source-line: 1 source-form: (test-assert "/etc/profile.d is sourced" (zero? (marionette-eval (quote (system "\n. /etc/profile\nset -e -x\ntest -f /etc/profile.d/test_profile_d.sh\ntest \"$PROFILE_D_OK\" = yes")) marionette))) Test end: result-kind: fail actual-value: #f ... --8<---cut here---end--->8--- Looking at some of the other failing tests, you can see that they fail in exactly the same way: encrypted-root-os https://ci.guix.gnu.org/build/10936887/details encrypted-home-os https://ci.guix.gnu.org/build/10936894/details jfs-root-os https://ci.guix.gnu.org/build/10936890/details btrfs-root-os https://ci.guix.gnu.org/build/10936905/details Before this, the last CI run that ran to completion was on commit 85b5c2c, which was before the etc/profile.d test was added. In total, there are 23 new failing tests from this CI run: https://ci.guix.gnu.org/eval/2062380?status=newly-failed The strange thing is, the etc/profile.d test passes if I run it normally as part of the basic tests, like this: --8<---cut here---start->8--- guix shell -D guix --pure -- make check-system TESTS=basic --8<---cut here---end--->8--- [1] https://yhetil.org/guix/87jz7rsu49@gnu.org/
