bug#41541: merge wip-hurd-vm
Hi, Jan Nieuwenhuizen skribis: > From 37c2a57d72f5678ec21a48ed4a3b733a20b71ab1 Mon Sep 17 00:00:00 2001 > From: "Jan (janneke) Nieuwenhuizen" > Date: Thu, 30 Apr 2020 15:40:07 +0200 > Subject: [PATCH v2] gnu: services: Add %hurd-startup-service. > > This decouples startup of the Hurd from the "hurd" package, moving the RC > script into SYSTEM. > > * gnu/packages/hurd.scm (hurd)[inputs]: Remove hurd-rc-script. > [arguments]: Do not substitute it. Update "runsystem.sh" to parse kernel > arguments and exec into --system=SYSTEM/rc. > (hurd-rc-script): Move to... > * gnu/services.scm (%hurd-rc-file): ...this new variable. > (hurd-rc-entry): New procedure. > (%hurd-startup-service): Use it in new variable. > * gnu/system.scm (hurd-default-essential-services): Use it. LGTM, thank you! Ludo’.
bug#41604: guix pull impossible after rebasing a local repository
Hi John, John Soo skribis: > I use a local git repo with branch that I specify in channels.scm. > My usual workflow is: > > 1. rebase on origin > 2. guix pull > > This stopped working with the following error: > > Updating channel 'guix' from Git repository at > 'file:///home/john/projects/guix/.git'... > guix pull: error: aborting update of channel 'guix' to commit > 1444040933ac35b967720288dc30ed70e5481ed3, which is not a descendant of > 57518fc7bf1efc899c0dabaa76685a319661f8e4 > 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. What happens is that ‘guix pull’ ensures that it only ever makes “fast-forward” updates by default, in Git parlance. The goal is to detect obvious “downgrade attacks”: https://issues.guix.gnu.org/41425 (This can be overridden this by passing ‘--allow-downgrades’.) The rebase workflow you describe unavoidably triggers the error because every time you pull, you do a non-fast-forward pull (because the commit you were previously using, as shown in ‘guix describe’, has been rewritten and no longer exists in the new commit graph.) So at least, it shows that the machinery works as advertised. :-) What I would recommend is for your channel to be a regular “fork”: you create a branch containing your patches and regularly merge upstream master back into your branch. That way, you don’t need to rewrite history and ‘guix pull’ is happy. Alternately, if you like to have linear history (for example because you intend to eventually submit your patches upstream), you could use TopGit, which roughly allows you to version-control your rebases. HTH! >From a pure Guix perspective, it’s “not-a-bug”. If one of the above suggestions works for you, I think we can close this issue. Thanks for your feedback! Ludo’.
bug#22883: Authenticating a Git checkout
Hi, John Soo skribis: > I like this idea a lot since I use a checkout which I guess constitutes > a "fork" in this scenario. I opened bug#41604 > (http://issues.guix.gnu.org/issue/41604) after having trouble with a > rebase based workflow. Some of my problems certainly come from my lack > of understanding of the authentication process and machinery. Would the > channel introduction allow me to use the rebase workflow in my checkout? No. Note that the authentication code is not used at all by ‘guix pull’ currently. When all this is in place, channel introductions would be how you publish your own channel such that ‘guix pull’ can consume it. But as I wrote in the other issue, a rebase workflow is not supported by ‘guix pull’ (just like it’s not supported by ‘git pull’ actually). HTH! Ludo’.
bug#41207: accountsservice daemon lacks dbus interfaces
Hi,
L p R n d n skribis:
> Ludovic Courtès writes:
>
>> Hello,
>>
>> L p R n d n skribis:
>>
>>> The accountsservice service hasn't access to dbus' interfaces throwing
>>> an error when they're needed.The problem, at least, appears with LightDM.
>>> The error looks like:
>>>
>>> WARNING: Error updating user /org/freedesktop/Accounts/User1000:
>>> GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: No such interface
>>> "org.freedesktop.DisplayManager.AccountsService"
>>
>> Apparently this error message comes from lightdm, so the issue is that
>> lightdm doesn’t find the ‘org.freedesktop.Accounts.service’, right?
>
> Not exactly, my understanding is that *accountsservice* doesn't find
> 'org.freedesktop.Accounts.service' which is provided (and asked) by
> lightdm. (I think the error comes from accountsservice)
But see:
--8<---cut here---start->8---
$ (cd /tmp; tar xf $(guix build -S lightdm))
$ grep -r "Error updating user" /tmp/lightdm-1.30.0/
/tmp/lightdm-1.30.0/common/user-list.c:g_warning ("Error updating user
%s: %s", priv->path, error->message);
/tmp/lightdm-1.30.0/common/user-list.c:g_warning ("Error updating user
%s: %s", priv->path, error->message);
$ (cd /tmp; tar xf $(guix build -S accountsservice))
$ find /tmp/accountsservice-0.6.50/ -name org.freedesktop\*.service.in
/tmp/accountsservice-0.6.50/data/org.freedesktop.Accounts.service.in
$ find $(guix build accountsservice) -name org.freedesktop\*.service
/gnu/store/l9qyf0brhhq7mwcsyhjsh7k0d3ri3ay2-accountsservice-0.6.50/share/dbus-1/system-services/org.freedesktop.Accounts.service
--8<---cut here---end--->8---
That’s why I think it’s lightdm (or dbus-daemon?) that fails to find the
.service file.
‘accountsservice-service-type’ extends dbus, such that we have
/etc/dbus-1/system-services/org.freedesktop.Accounts.service. Do you
see this as well?
Thanks,
Ludo’.
bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible
Hi all, Chris Marusich writes: > The derivation that produced the differing output was: > > /gnu/store/pygln3lr6qbxcps3kmn3w4bc0d0nlpd3-gcc-stripped-tarball-5.5.0.drv > > On my x86_64-linux system, twice I tried running "guix build --check" on > this derivation, but each time it surprisingly reported no difference. This derivation corresponds to %gcc-bootstrap-tarball from (gnu packages make-bootstrap), which just creates a tarball of the output of %gcc-stripped. Therefore, it's not too surprising that it's reproducible. Similarly, %gcc-stripped just strips some store references from the output of %gcc-static. The %gcc-static package is more interesting: it's where we actually build the statically linked bootstrap GCC (which is then stripped and packed into a tarball as mentioned above), so I thought that it might be where the non-determinism is coming from. However, I haven't yet pinpointed the problem. If you examine the derivations and their inputs, you'll find that they depend upon each other in the following order: guix build --target=powerpc64-linux-gnu -d -e '(@ (gnu packages make-bootstrap) %gcc-bootstrap-tarball)' /gnu/store/pygln3lr6qbxcps3kmn3w4bc0d0nlpd3-gcc-stripped-tarball-5.5.0.drv guix build --target=powerpc64-linux-gnu -d -e '(@@ (gnu packages make-bootstrap) %gcc-stripped)' /gnu/store/kcv3ja1rfr93hw6ly51878zjhdwpgv7z-gcc-stripped-5.5.0.drv guix build --target=powerpc64-linux-gnu -d -e '(@@ (gnu packages make-bootstrap) %gcc-static)' /gnu/store/m9hfwppla8lph0vxa15lfkp81s2bbjjs-gcc-static-5.5.0.drv In other words, gcc-static-5.5.0.drv is an input of gcc-stripped-5.5.0.drv, which is an input of gcc-stripped-tarball-5.5.0.drv. Above, I've included example guix commands you can use to obtain each derivation. Using "guix build --check", I confirmed that all three of these derivations build reproducibly on my machine. I hoped to find more information by invoking "guix build --check" on every input of gcc-static-5.5.0.drv. When I tried that, what I found was that all of its inputs build reproducibly except the following two: /gnu/store/x32cnfkd50fnxs10xp1jdn24h7ai2gxr-guile-3.0.2.drv /gnu/store/g9fpkg2qa27mka1znqsvx8vxqyabsj2y-gcc-7.5.0.drv I haven't investigated guile-3.0.2.drv. However, gcc-7.5.0.drv felt more suspicious to me, and it is actually the derivation that builds gcc-final from (gnu packages commencement), which you can see via: guix build -d -e '(@@ (gnu packages commencement) gcc-final)' Using "guix gc", I deleted the outputs of gcc-stripped-tarball-5.5.0.drv, gcc-stripped-5.5.0.drv, gcc-static-5.5.0.drv, and gcc-7.5.0.drv. I then tried building these four derivations again (without substitutes, the same as before). Before doing this, I stored the SHA-512 hashes of their output files, and after the build succeeded, I compared the hashes of the new files with the previous values. I found that these derivations' newly rebuilt outputs were identical to their original values, except for gcc-7.5.0.drv, which produced some different files. Most significantly, this means that gcc-stripped-tarball-5.5.0.drv produced the exact same tarball for me as it did the first time I built it, even though some of its inputs are not themselves reproducible. At present, it seems possible that within the context of a single machine, gcc-stripped-tarball-5.5.0.drv builds reproducibly, but on a different machine, it may (reproducibly) build a different output. I'm a bit paranoid about making mistakes, so I'll perform another full GC and then try yet again to build gcc-stripped-tarball-5.5.0.drv in order to verify whether it truly produces the same output when all (or nearly all) of its inputs are rebuilt from scratch. Some people have also shared their differing copies of the binaries on the email list. It could be productive to compare the contents with diffoscope, although I suspect the diff might be too large to be useful. -- Chris signature.asc Description: PGP signature
bug#22883: Channel introductions
Hi, zimoun skribis: > On Mon, 1 Jun 2020 at 16:08, Ludovic Courtès wrote: > >> I think we need a way to “introduce” a channel to its users that goes >> beyond a mere URL. > > Just to be sure to well understand, will the good ol' > ~/.config/guix/channels.scm > > ;; Tell 'guix pull' to use my own repo. > (list (channel > (name 'guix) > (url "https://example.org/my-guix.git";) > (branch "super-hacks"))) > > still work as it is now? i.e., using the current "unauthorized" > mechanism. Or will a new keyword be added to this channel description > to say "this channel does not use authorized machinery but it is > fine"? Yeah, we have to keep it working. So I guess in that case it would just emit a warning saying this channel is not authenticated, and that’s it. >> If that information were stored in ‘.guix-channel’, it would be >> trivial for an attacker to fork the project (or push a new commit) >> and pretend the authentication process must not take previous >> commits into account. > > What will happen to recursive '.guix-channel'? The '.guix-channel' of > channel A contains the reference to the channel B where the > '.guix-channel' contains the reference to the channel C, etc. I’m not sure I understand. (The sentence above is about *not* storing info in ‘.guix-channel’.) >> 4. When publishing a fork of a channel, one emits a new channel >> introduction. Users switching to the fork have to explicitly allow >> that new channel via its introduction; flipping the URL won’t be >> enough because ‘guix pull’ would report unauthorized commits. > > I am a bit afraid by this... and I hope that a fork of a channel will > still work without emitting a new channel introduction. No, when publishing a fork of an authenticated channel, you’ll have to publish its introduction alongside its URL. I think it’s unavoidable: we want to be able to distinguish between a mirror that has been tampered with and a fork. >> 5. The channel URL is not included in the introduction. However, the >> official URL is an important piece of information: it tells users >> this is where they’ll get the latest updates. It should be >> possible to create mirrors, but by default users should go to the >> official URL. They should be aware that mirrors can be outdated. > > I do not understand this paragraph. The aim of mirrors is to avoid > the users to go to the official URL, isn't it? And the mirrors do not > have by design the latest updates (time to propagate, etc.). > > >> I think the official URL can be stored in ‘.guix-channel’ in the >> repo (which is subject to the authentication machinery). That way, >> ‘guix pull’ can let the user know if they’re talking to a mirror >> rather than to the official channel. > > Why does it matter? The user should authenticate the downloaded > content whatever the URL serving it, isn't it? > And can 'guix pull' already let the users know to who they are talking? You’re right: ideally the URL wouldn’t matter at all. However, from a security perspective, we not only want to make sure users get genuine commits, we also want to know they’re not talking to a possibly outdated mirror. Since there’s no way to answer the question “is this the latest commit?” in a general way, the best we can do, I think, is to detect whether we’re talking to the “official” Git repo. Thanks for your feedback! Ludo’.
bug#41207: accountsservice daemon lacks dbus interfaces
Hello,
Ludovic Courtès writes:
>>> L p R n d n skribis:
[...]
>> Not exactly, my understanding is that *accountsservice* doesn't find
>> 'org.freedesktop.Accounts.service' which is provided (and asked) by
>> lightdm. (I think the error comes from accountsservice)
>
> But see:
>
> $ (cd /tmp; tar xf $(guix build -S lightdm))
> $ grep -r "Error updating user" /tmp/lightdm-1.30.0/
> /tmp/lightdm-1.30.0/common/user-list.c:g_warning ("Error updating
> user %s: %s", priv->path, error->message);
> /tmp/lightdm-1.30.0/common/user-list.c:g_warning ("Error updating
> user %s: %s", priv->path, error->message);
> $ (cd /tmp; tar xf $(guix build -S accountsservice))
> $ find /tmp/accountsservice-0.6.50/ -name org.freedesktop\*.service.in
> /tmp/accountsservice-0.6.50/data/org.freedesktop.Accounts.service.in
> $ find $(guix build accountsservice) -name org.freedesktop\*.service
> /gnu/store/l9qyf0brhhq7mwcsyhjsh7k0d3ri3ay2-accountsservice-0.6.50/share/dbus-1/system-services/org.freedesktop.Accounts.service
>
> That’s why I think it’s lightdm (or dbus-daemon?) that fails to find the
> .service file.
>
> ‘accountsservice-service-type’ extends dbus, such that we have
> /etc/dbus-1/system-services/org.freedesktop.Accounts.service. Do you
> see this as well?
You're right! ;) And probably a dbus-daemon problem from what I
understand. But I really don't know what I'm talking about here...
However, just to clarify, I think it's not that it's not finding
dbus-1/system-services/org.freedesktop.Accounts.service but
dbus-1/interfaces/org.freedesktop.Accounts(.Users?).xml. In that case,
using #:env-variable for the dbus service might be a possibility.
Really, I have quite a lot of files in
/run/current-system/profile/share/dbus-1/interfaces but I don't know what are
their purpose... :/
> Thanks,
> Ludo’.
Have a nice day,
L p R n d n
bug#41604: guix pull impossible after rebasing a local repository
Hi Ludo! I hope you are well. Ludovic Courtès writes: > What happens is that ‘guix pull’ ensures that it only ever makes > “fast-forward” updates by default, in Git parlance. The goal is to > detect obvious “downgrade attacks”: > > https://issues.guix.gnu.org/41425 Oh I see, I'm sorry I did not participate in that issue, now. That makes sense and I'm glad to know this is part of the design. > (This can be overridden this by passing ‘--allow-downgrades’.) Does '--allow-downgrades' support unrelated git histories? I tried that flag and it did not work. > The rebase workflow you describe unavoidably triggers the error because > every time you pull, you do a non-fast-forward pull (because the commit > you were previously using, as shown in ‘guix describe’, has been > rewritten and no longer exists in the new commit graph.) So at least, > it shows that the machinery works as advertised. :-) Totally. I think I understand the design goal now. > What I would recommend is for your channel to be a regular “fork”: you > create a branch containing your patches and regularly merge upstream > master back into your branch. That way, you don’t need to rewrite > history and ‘guix pull’ is happy. So far the need to avoid downgrade attacks makes sense. Here are the things I think should be considered: I have branches based on master in savannah that contain specific patch sets associated to patch requests upstream. I think I have 3 or 4 right now. My patches are also in the branch I have in channels.scm. I do that for a few reasons: 1. To test the patches 2. To workaround or use bugs/features/packages I want but are not upstream yet. That means I tend to want to use my patches whether or not they are upstream yet. In fact I stopped working on my channel because it was so easy to just make patches on upstream to contribute back. It can take many months for patches to be merged. That is expected since we are all volunteers. Rebasing the patches is the easiest way to keep them up to date so they can be applied cleanly. There are two design and community goals I love about Guix: hackability and inclusivity. I feel that disallowing linear history makes the easiest way to contribute to, hack on, and participate in Guix much harder without proper support. For instance: instead of making patches on top of upstream it is now easier just to work on my channel. Certainly some tradeoffs should be made for security and I think your recent commit authentication work does that elegantly. Perhaps we can easily have hackability and security with a flag like --allow-downgrades called --allow-unrelated that allows the rebase workflow. WDYT? > Alternately, if you like to have linear history (for example because you > intend to eventually submit your patches upstream), you could use > TopGit, which roughly allows you to version-control your rebases. Hmm. I am unaware of TopGit but I find rebasing to be the simplest and easiest way to do my work. I'll look into it but I would rather not have to use another tool for simplicity's sake. > From a pure Guix perspective, it’s “not-a-bug”. If one of the above > suggestions works for you, I think we can close this issue. I think I understand the reasoning now. I do hope a flag like --allow-unrelated might solve all the things. > HTH! Thanks as always. I really appreciate your communications. - John
bug#41237: guix deploy hangs when a file-system-device is set to a UUID
Hi Brice,
Brice Waegeneire skribis:
> When manually executing the second 'remote-assertion.scm' file, the one
> containing the 'find-partition-by-uuid-bit', it hangs indefinitely, I
> have
> attached it's strace to this email.
>
> $ cat /gnu/store/wzvn8r2z7lnf5mqzagxzcb64wr69kgk4-remote-assertion.scm
> (eval-when (expand load eval) (let ((extensions (quote ())) (prepend
> (lambda (items lst) (let loop ((items items) (lst lst)) (if (null?
> items) lst (loop (cdr items) (cons (car items) (delete (car items)
> lst (set! %load-path (prepend (cons
> "/gnu/store/7jpv8kkq13k9xjazrkpq3cm1vz4m5arv-module-import" (map (lambda
> (extension) (string-append extension "/share/guile/site/"
> (effective-version))) extensions)) %load-path)) (set!
> %load-compiled-path (prepend (cons
> "/gnu/store/gac0pvsnc0zvsfxizfqjgg9lig8sf200-module-import-compiled"
> (map (lambda (extension) (string-append extension "/lib/guile/"
> (effective-version) "/site-ccache")) extensions))
> %load-compiled-path(begin (use-modules (gnu build file-systems) (gnu
> system uuid)) (define uuid (string->uuid "B5DE-B0B9"))
> (find-partition-by-uuid uuid))
> # strace -o /tmp/^Crace3.txt guile
> /gnu/store/wzvn8r2z7lnf5mqzagxzcb64wr69kgk4-remote-assertion.scm
It seems to be doing what we expect initially:
> openat(AT_FDCWD, "/dev/sda1", O_RDONLY) = 9
[...]
> fstat(9, {st_mode=S_IFBLK|0660, st_rdev=makedev(0x8, 0x1), ...}) = 0
> lseek(9, 0, SEEK_CUR) = 0
> lseek(9, 32768, SEEK_SET) = 32768
> read(9,
> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096)
> = 4096
> close(9)= 0
> openat(AT_FDCWD, "/dev/sda1", O_RDONLY) = 9
[...]
> fstat(9, {st_mode=S_IFBLK|0660, st_rdev=makedev(0x8, 0x1), ...}) = 0
> lseek(9, 0, SEEK_CUR) = 0
> lseek(9, 1024, SEEK_SET)= 1024
> read(9,
> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096)
> = 4096
> close(9)= 0
> openat(AT_FDCWD, "/dev/sda1", O_RDONLY) = 9
[...]
> fstat(9, {st_mode=S_IFBLK|0660, st_rdev=makedev(0x8, 0x1), ...}) = 0
> lseek(9, 0, SEEK_CUR) = 0
> lseek(9, 65536, SEEK_SET) = 65536
> read(9,
> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096)
> = 4096
> close(9)= 0
> openat(AT_FDCWD, "/dev/sda1", O_RDONLY) = 9
[...]
> fstat(9, {st_mode=S_IFBLK|0660, st_rdev=makedev(0x8, 0x1), ...}) = 0
> mmap(0x7f1806869000, 1576960, PROT_READ|PROT_WRITE,
> MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f180662d000
> lseek(9, 0, SEEK_CUR) = 0
> lseek(9, 0, SEEK_SET) = 0
> read(9, "\353X\220mkfs.fat\0\2\10 \0\2\0\0\0\0\370\0\0?\0\377\0\0\10\0\0"...,
> 4096) = 4096
> close(9)= 0
> openat(AT_FDCWD, "/dev/sda1", O_RDONLY) = 9
[...]
> fstat(9, {st_mode=S_IFBLK|0660, st_rdev=makedev(0x8, 0x1), ...}) = 0
> lseek(9, 0, SEEK_CUR) = 0
> lseek(9, 0, SEEK_SET) = 0
> read(9, "\353X\220mkfs.fat\0\2\10 \0\2\0\0\0\0\370\0\0?\0\377\0\0\10\0\0"...,
> 4096) = 4096
> close(9)= 0
> openat(AT_FDCWD, "/dev/sda1", O_RDONLY) = 9
[...]
> fstat(9, {st_mode=S_IFBLK|0660, st_rdev=makedev(0x8, 0x1), ...}) = 0
> lseek(9, 0, SEEK_CUR) = 0
> lseek(9, 32768, SEEK_SET) = 32768
> read(9,
> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096)
> = 4096
> close(9)= 0
> openat(AT_FDCWD, "/dev/sda1", O_RDONLY) = 9
[...]
> fstat(9, {st_mode=S_IFBLK|0660, st_rdev=makedev(0x8, 0x1), ...}) = 0
> lseek(9, 0, SEEK_CUR) = 0
> lseek(9, 1024, SEEK_SET)= 1024
> read(9,
> "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096)
> = 4096
> close(9)= 0
And then it seems to enter an endless loop:
> write(6, "\0", 1) = 1
> clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=0, tv_nsec=104694235}) = 0
> rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
> futex(0x7f180a6c5f68, FUTEX_WAKE_PRIVATE, 2147483647) = 3
> futex(0x7f180a6c5b40, FUTEX_WAKE_PRIVATE, 1) = 1
> futex(0x7f180a6c5f54, FUTEX_WAIT_PRIVATE, 3, NULL) = -1 EAGAIN (Resource
> temporarily unavailable)
> futex(0x7f180a6c5f60, FUTEX_WAKE_PRIVATE, 1) = 1
> futex(0x7f180a6c5f68, FUTEX_WAKE_PRIVATE, 2147483647) = 2
> futex(0x7f180a6c5f6c, FUTEX_WAKE_PRIVATE, 2147483647) = 3
> futex(0x7f180a6c5b40, FUTEX_WAKE_PRIVATE, 1) = 1
> futex(0x7f180a6c5b40, FUTEX_WAKE_PRIVATE, 1) = 0
> futex(0x7f180a6c5f6c, FUTEX_WAKE_PRIVATE, 2147483647) = 3
> clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=0, tv_nsec=111569830}) = 0
> clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {tv_sec=0, tv_nsec=114489967}) = 0
> rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[...]
> madvise(0x7f1806e01000, 12288, MADV_DONTNEED) = 0
> futex(
bug#41604: guix pull impossible after rebasing a local repository
Hello, John Soo skribis: > Ludovic Courtès writes: [...] >> (This can be overridden this by passing ‘--allow-downgrades’.) > > Does '--allow-downgrades' support unrelated git histories? I tried that > flag and it did not work. It supports unrelated Git histories. It could really be called ‘--allow-anything’ but I thought it’d be less descriptive. :-) If you hit a problem with that, please report it (perhaps I just overlooked it in the other issue.) > I have branches based on master in savannah that contain specific patch > sets associated to patch requests upstream. I think I have 3 or 4 right > now. My patches are also in the branch I have in channels.scm. I do > that for a few reasons: > > 1. To test the patches > 2. To workaround or use bugs/features/packages I want but are not upstream > yet. > > That means I tend to want to use my patches whether or not they are > upstream yet. In fact I stopped working on my channel because it was so > easy to just make patches on upstream to contribute back. > > It can take many months for patches to be merged. That is expected > since we are all volunteers. Rebasing the patches is the easiest way to > keep them up to date so they can be applied cleanly. Yes. > There are two design and community goals I love about Guix: hackability > and inclusivity. I feel that disallowing linear history makes the > easiest way to contribute to, hack on, and participate in Guix much > harder without proper support. For instance: instead of making patches > on top of upstream it is now easier just to work on my channel. > > Certainly some tradeoffs should be made for security and I think your > recent commit authentication work does that elegantly. Perhaps we can > easily have hackability and security with a flag like --allow-downgrades > called --allow-unrelated that allows the rebase workflow. Interesting, I hadn’t thought about how this mechanism would give an incentive to have a channel vs. contributing directly upstream. Normally, ‘--allow-downgrades’ does exactly what you need, at least that’s the intent. I’d argue that it’s also reasonable to use it in this case because obviously you know what you’re doing, and you’re pulling from a local Git repository, so that’s fine. >> Alternately, if you like to have linear history (for example because you >> intend to eventually submit your patches upstream), you could use >> TopGit, which roughly allows you to version-control your rebases. > > Hmm. I am unaware of TopGit but I find rebasing to be the simplest and > easiest way to do my work. I'll look into it but I would rather not have > to use another tool for simplicity's sake. Yeah, that makes sense to me. Thanks, Ludo’.
bug#41541: merge wip-hurd-vm
Ludovic Courtès writes: >> From 37c2a57d72f5678ec21a48ed4a3b733a20b71ab1 Mon Sep 17 00:00:00 2001 >> From: "Jan (janneke) Nieuwenhuizen" >> Date: Thu, 30 Apr 2020 15:40:07 +0200 >> Subject: [PATCH v2] gnu: services: Add %hurd-startup-service. >> >> This decouples startup of the Hurd from the "hurd" package, moving the RC >> script into SYSTEM. >> >> * gnu/packages/hurd.scm (hurd)[inputs]: Remove hurd-rc-script. >> [arguments]: Do not substitute it. Update "runsystem.sh" to parse kernel >> arguments and exec into --system=SYSTEM/rc. >> (hurd-rc-script): Move to... >> * gnu/services.scm (%hurd-rc-file): ...this new variable. >> (hurd-rc-entry): New procedure. >> (%hurd-startup-service): Use it in new variable. >> * gnu/system.scm (hurd-default-essential-services): Use it. > > LGTM, thank you! Great...pushed to wip-hurd-vm. So...in the hope that this is helpful I created an overview of all of current wip-hurd-vm. Legend (in order of merge'ability / is there a convention for this?): [M] Mathieu [L] Ludo g good to go LGTM'd t trivial (self-LGTM :-) . direct dependency of/partially superseded by a LGTM ack or review needed ! troublesome My take on wip-hurd-vm: g 37c2a57d72 gnu: services: Add %hurd-startup-service. . ef647de139 hurd-boot: Use setxattr instead of MAKEDEV. . 27f049273f hurd-boot: Further cleanup of "rc". b73d83f217 syscalls: set-thread-name, thread-name: Stub for the Hurd. t 60a510741c system: bare-hurd.tmpl: Add openssh client and service. t 57c16e4e6a system: hurd: Remove 'cross-hurd-image' hack. . f287c8992a system: hurd: Populate services. g ac0fc836a2 services: Add `hurd-getty-service-type'. g e28364ea2d services: Add `hurd-console-service-type'. . 8e31888648 gnu: hurd: Create minimal "runsystem" script to invoke "rc". 17638f3b4d services: hurd: Use activation-service, hurd-etc-service. 6ed827c281 system: Add `hurd-activation'. 83a245a8e0 services: hurd: Add `hurd-etc-service'. d04e51d196 system: examples: Add bare-hurd.tmpl. t b8bccce071 system: Use 'hurd' package in label. g cf92e7393b bootloader: grub: Add support for multiboot. g 1a236d1535 system: Add 'multiboot-modules' field to . g 6a6fc5fd64 bootloader: Extend `' for multiboot. dd0a930ea8 system: Add 'hurd' field to . da3afc95f4 system: hurd: Add hurd-default-essential-services. ! ee81319934 image: Support extra-directives, add hurd-directives. t 4479c1c1e3 linux-boot: Update 'make-hurd-device-nodes'. [M] a17f91bd50 image: Add Hurd support. t 7359403993 gnu: hurd: Update to upstream Hurd-reserved xattr index. [L] 68a8a26a57 gnu: guile-static: Disable JIT on ARMv7. [L] 220243a2c6 vm: Shared-store script runs that native QEMU and Bash. [L] e3b6c5dce2 vm: compiler honors system and target. [L] d43423f074 vm: 'qemu-image' preserves the cross-compilation target of the OS. [L] c6ee3a059b vm: 'qemu-image' uses the native partitioning tools and bootloader. [L] ab06638f57 vm: 'expression->derivation-in-linux-vm' always returns a native build. [L] 113ba9d7a9 system: 'system-linux-image-file-name' takes an optional parameter. Hoping this is helpful, Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#41541: merge wip-hurd-vm
Hey! > Legend (in order of merge'ability / is there a convention for this?): > > [M] Mathieu > [L] Ludo >g good to go LGTM'd >t trivial (self-LGTM :-) >. direct dependency of/partially superseded by a LGTM > > ack or review needed >! troublesome Hehe, nice one :) >! ee81319934 image: Support extra-directives, add hurd-directives. This one now only contains the hurd symlink, that you could be done at activation I guess. >t 4479c1c1e3 linux-boot: Update 'make-hurd-device-nodes'. > [M] a17f91bd50 image: Add Hurd support. >t 7359403993 gnu: hurd: Update to upstream Hurd-reserved xattr index. > [L] 68a8a26a57 gnu: guile-static: Disable JIT on ARMv7. > [L] 220243a2c6 vm: Shared-store script runs that native QEMU and Bash. > [L] e3b6c5dce2 vm: compiler honors system and target. > [L] d43423f074 vm: 'qemu-image' preserves the cross-compilation target of > the OS. > [L] c6ee3a059b vm: 'qemu-image' uses the native partitioning tools and > bootloader. > [L] ab06638f57 vm: 'expression->derivation-in-linux-vm' always returns a > native build. > [L] 113ba9d7a9 system: 'system-linux-image-file-name' takes an optional > parameter. For the rest, maybe you could send a patch serie by email with all the patch that are tagged ' ' or '!'. This way we could proceed to a last review round? Thanks, Mathieu
bug#41237: guix deploy hangs when a file-system-device is set to a UUID
Hello Ludo', On 2020-06-03 14:56, Ludovic Courtès wrote: Could you try running this at the REPL: (load "/gnu/store/wzvn8r2z7lnf5mqzagxzcb64wr69kgk4-remote-assertion.scm") and then hit C-c and type “,bt” to get a backtrace? Here is the backtrace: --8<---cut here---start->8--- In ice-9/boot-9.scm: 2806:4 6 (save-module-excursion _) 4351:12 5 (_) In unknown file: 4 (find # …) In gnu/system/uuid.scm: 302:5 3 (uuid=? . _) In unknown file: While executing meta-command: In procedure frame-local-ref: Argument 2 out of range: 0 --8<---cut here---end--->8--- - Brice
bug#22883: Channel introductions
Hi Ludo, Thank you for the explanations. On Wed, 3 Jun 2020 at 11:50, Ludovic Courtès wrote: > zimoun skribis: > > On Mon, 1 Jun 2020 at 16:08, Ludovic Courtès wrote: > >> If that information were stored in ‘.guix-channel’, it would be > >> trivial for an attacker to fork the project (or push a new commit) > >> and pretend the authentication process must not take previous > >> commits into account. > > > > What will happen to recursive '.guix-channel'? The '.guix-channel' of > > channel A contains the reference to the channel B where the > > '.guix-channel' contains the reference to the channel C, etc. > > I’m not sure I understand. (The sentence above is about *not* storing > info in ‘.guix-channel’.) Sorry, I have misread. The question about recursive still applies. ;-) Currently, if the local channel file points to a channel A which contains the file '.guix-channel' which points to another channel B, then when one runs "guix pull" well the channel A will be pulled and then the channel B, even if this channel B is not explicit in the initial local channel. (Even, there is bug about recursive implicit pulls, see http://issues.guix.gnu.org/issue/41069; well another story.) What happens for such situation? > >> I think we need a way to “introduce” a channel to its users that goes > >> beyond a mere URL. > > > > Just to be sure to well understand, will the good ol' > > ~/.config/guix/channels.scm > > > > ;; Tell 'guix pull' to use my own repo. > > (list (channel > > (name 'guix) > > (url "https://example.org/my-guix.git";) > > (branch "super-hacks"))) > > > > still work as it is now? i.e., using the current "unauthorized" > > mechanism. Or will a new keyword be added to this channel description > > to say "this channel does not use authorized machinery but it is > > fine"? > > Yeah, we have to keep it working. So I guess in that case it would just > emit a warning saying this channel is not authenticated, and that’s it. [...] > >> 4. When publishing a fork of a channel, one emits a new channel > >> introduction. Users switching to the fork have to explicitly allow > >> that new channel via its introduction; flipping the URL won’t be > >> enough because ‘guix pull’ would report unauthorized commits. > > > > I am a bit afraid by this... and I hope that a fork of a channel will > > still work without emitting a new channel introduction. > > No, when publishing a fork of an authenticated channel, you’ll have to > publish its introduction alongside its URL. I do not understand your two answers. Well, there is 4 situations when publishing: 1- an authenticated fork of an authenticated channel 2- an authenticated fork of an unauthenticated channel 3- an unauthenticated fork of an authenticated channel 4- an unauthenticated fork of an unauthenticated channel "authenticated channel" means a channel using all the authentication machinery. "authenticated fork" means add a "channel introduction" and so become a "authenticate channel" then. Today, we are in the situation 4. and we are going to the 1. if I understand correctly. And if I understand your answer above about good ol' channel, the 4. will still work and emit a warning, isn't it? What about the 2. and 3.? These situations correspond to: 1- the correct way 2- bootstrap the trust 3- and 4- quick and dirty "Scientific" workflows where the security is not a concern. > I think it’s unavoidable: we want to be able to distinguish between a > mirror that has been tampered with and a fork. I understand. But this break the symmetry and the distributed model of Guix, IMHO. > >> 5. The channel URL is not included in the introduction. However, the > >> official URL is an important piece of information: it tells users > >> this is where they’ll get the latest updates. It should be > >> possible to create mirrors, but by default users should go to the > >> official URL. They should be aware that mirrors can be outdated. > > > > I do not understand this paragraph. The aim of mirrors is to avoid > > the users to go to the official URL, isn't it? And the mirrors do not > > have by design the latest updates (time to propagate, etc.). > > > >> I think the official URL can be stored in ‘.guix-channel’ in the > >> repo (which is subject to the authentication machinery). That way, > >> ‘guix pull’ can let the user know if they’re talking to a mirror > >> rather than to the official channel. > > > > Why does it matter? The user should authenticate the downloaded > > content whatever the URL serving it, isn't it? > > And can 'guix pull' already let the users know to who they are talking? > > You’re right: ideally the URL wouldn’t matter at all. However, from a > security perspective, we not only want to make sure users get genuine > commits, we also want to know they’re not talking to a possibly outdated > mirror. Ge
bug#41693: freshly installed system cannot run “guix pull”
I just installed two servers with the installer image built from commit 2f49007dd076b14feb40d7c3331dee3e737265c8. Both of these servers boot just fine, but “guix pull” does not work. It fails with the following error: guix pull: error: glibc-bootstrap-system-2.2.5.patch: patch not found -- Ricardo
bug#34275: clementine-1.3.1 fails test
I ignored Clementine failing at updates a few times ... and now checked to see that it fails at a different test! [100%] Linking CXX executable fmpsparser_test cd /tmp/guix-build-clementine-1.3.1-2.4619a4c.drv-0/build/tests && /gnu/store/89rj5fqcg48afgk99639ds602pgf92k4-cmake-minimal-3.16.5/bin/cmake -E cmake_link_script CMakeFiles/fmpsparser_test.dir/link.txt --verbose=1 /gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/bin/c+ + -std=c++0x -fpermissive -Wno-c++11-narrowing -U__STRICT_ANSI__ -O2 -g -DNDEBUG -rdynamic CMakeFiles/fmpsparser_test.dir/fmpsparser_test.cpp.o -o fmpsparser_test libgmock.a libgtest.a ../src/libclementine_lib.a libtest_utils.a /gnu/store/nash8slqngrzn2pgqrff6abz8vp6vws6-qtbase-5.12.7/lib/libQt5Test.so. 5.12.7 libtest_main.a libgmock.a libgtest.a ../src/libclementine_lib.a ../ext/libclementine-spotifyblob/libclementine-spotifyblob-messages.a ../ext/libclementine-tagreader/liblibclementine-tagreader.a ../ext/libclementine-remote/liblibclementine-remote.a ../ext/libclementine-common/liblibclementine-common.a -lprotobuf -lssl -lcrypto -ltag -lmygpo-qt5 -lQt5Network -lQt5Core -lchromaprint ../3rdparty/qtsingleapplication/libqtsingleapplication.a ../3rdparty/qtiocompressor/libqtiocompressor.a -lgio-2.0 -lgstapp-1.0 -lgsttag-1.0 -lgstpbutils-1.0 -lgstvideo-1.0 -lz -lgio-2.0 -lgstapp-1.0 -lgsttag-1.0 -lgstpbutils-1.0 -lgstvideo-1.0 -lz -lpthread ../3rdparty/qocoa/libQocoa.a /gnu/store/nash8slqngrzn2pgqrff6abz8vp6vws6-qtbase-5.12.7/lib/libQt5OpenGL.so. 5.12.7 /gnu/store/nash8slqngrzn2pgqrff6abz8vp6vws6-qtbase-5.12.7/lib/libQt5Network.so. 5.12.7 /gnu/store/nash8slqngrzn2pgqrff6abz8vp6vws6-qtbase-5.12.7/lib/libQt5Xml.so. 5.12.7 /gnu/store/nash8slqngrzn2pgqrff6abz8vp6vws6-qtbase-5.12.7/lib/libQt5Concurrent.so. 5.12.7 /gnu/store/nash8slqngrzn2pgqrff6abz8vp6vws6-qtbase-5.12.7/lib/libQt5DBus.so. 5.12.7 -lcdio -lm ../gst/moodbar/libgstmoodbar.a -lgobject-2.0 -lglib-2.0 -lgstbase-1.0 -lgstreamer-1.0 -lgstaudio-1.0 -lgobject-2.0 -lglib-2.0 -lgstbase-1.0 -lgstreamer-1.0 -lgstaudio-1.0 -lfftw3 -lmtp -lpulse ../3rdparty/qxt/libqxt.a /gnu/store/nash8slqngrzn2pgqrff6abz8vp6vws6-qtbase-5.12.7/lib/libQt5Widgets.so. 5.12.7 /gnu/store/353jqf59wb1nmcd49zx3301r34nr8ibw-qtx11extras-5.12.7/lib/libQt5X11Extras.so. 5.12.7 /gnu/store/nash8slqngrzn2pgqrff6abz8vp6vws6-qtbase-5.12.7/lib/libQt5Gui.so. 5.12.7 ../3rdparty/qsqlite/libqsqlite.a /gnu/store/nash8slqngrzn2pgqrff6abz8vp6vws6-qtbase-5.12.7/lib/libQt5Sql.so. 5.12.7 /gnu/store/nash8slqngrzn2pgqrff6abz8vp6vws6-qtbase-5.12.7/lib/libQt5Core.so. 5.12.7 -lsqlite3 -lX11 -ldl collect2: error: ld returned 1 exit status make[3]: *** [tests/CMakeFiles/fmpsparser_test.dir/build.make:120: tests/fmpsparser_test] Error 1 make[3]: Leaving directory '/tmp/guix-build-clementine-1.3.1-2.4619a4c.drv-0/build' make[2]: *** [CMakeFiles/Makefile2:1592: tests/CMakeFiles/fmpsparser_test.dir/all] Error 2 make[2]: Leaving directory '/tmp/guix-build-clementine-1.3.1-2.4619a4c.drv-0/build' make[1]: *** [CMakeFiles/Makefile2:990: tests/CMakeFiles/clementine_test.dir/rule] Error 2 make[1]: Leaving directory '/tmp/guix-build-clementine-1.3.1-2.4619a4c.drv-0/build' make: *** [Makefile:388: clementine_test] Error 2
bug#41693: freshly installed system cannot run “guix pull”
Hello Ricardo, > I just installed two servers with the installer image built from commit > 2f49007dd076b14feb40d7c3331dee3e737265c8. Both of these servers boot > just fine, but “guix pull” does not work. > > It fails with the following error: > > guix pull: error: glibc-bootstrap-system-2.2.5.patch: patch not found The commit you picked should create an installer with a Guix package that contains the appropriate fix: 179e6c524ae4957e6ace83f72a5651767f786ca4. Could you run a "guix describe" just to be sure? Thanks, Mathieu
bug#41693: freshly installed system cannot run “guix pull”
Mathieu Othacehe writes: >> I just installed two servers with the installer image built from commit >> 2f49007dd076b14feb40d7c3331dee3e737265c8. Both of these servers boot >> just fine, but “guix pull” does not work. >> >> It fails with the following error: >> >> guix pull: error: glibc-bootstrap-system-2.2.5.patch: patch not found > > The commit you picked should create an installer with a Guix package > that contains the appropriate fix: > 179e6c524ae4957e6ace83f72a5651767f786ca4. > > Could you run a "guix describe" just to be sure? “guix describe” tells me that my Guix was not created with “guix pull” but says: Its version string is 1.1.0-3.52b01cb. -- Ricardo
bug#41541: merge wip-hurd-vm
Mathieu Othacehe writes:
Hi!
>> Legend (in order of merge'ability / is there a convention for this?):
>>
>> [M] Mathieu
>> [L] Ludo
>>g good to go LGTM'd
>>t trivial (self-LGTM :-)
>>. direct dependency of/partially superseded by a LGTM
>>
>> ack or review needed
>>! troublesome
>
> Hehe, nice one :)
>
>>! ee81319934 image: Support extra-directives, add hurd-directives.
>
> This one now only contains the hurd symlink, that you could be done at
> activation I guess.
I never believed that could work, but to my own eh, ..., I found a way
to make it work. We "only" need to make sure that /hurd/startup etc.
are found by substitute*'ing some more, and create the symlink.
Reverting that patch and using this diff
--8<---cut here---start->8---
diff --git a/gnu/build/hurd-boot.scm b/gnu/build/hurd-boot.scm
index 20d012fbfa..31260b52a1 100644
--- a/gnu/build/hurd-boot.scm
+++ b/gnu/build/hurd-boot.scm
@@ -45,6 +45,35 @@ Return the value associated with OPTION, or #f on failure."
(lambda (arg)
(substring arg (+ 1 (string-index arg #\=)))
+;; XXX FIXME c&p from guix/utils.scm
+(define (readlink* file)
+ "Call 'readlink' until the result is not a symlink."
+ (define %max-symlink-depth 50)
+
+ (let loop ((file file)
+ (depth 0))
+(define (absolute target)
+ (if (absolute-file-name? target)
+ target
+ (string-append (dirname file) "/" target)))
+
+(if (>= depth %max-symlink-depth)
+file
+(call-with-values
+(lambda ()
+ (catch 'system-error
+(lambda ()
+ (values #t (readlink file)))
+(lambda args
+ (let ((errno (system-error-errno args)))
+(if (or (= errno EINVAL))
+(values #f file)
+(apply throw args))
+ (lambda (success? target)
+(if success?
+(loop (absolute target) (+ depth 1))
+file))
+
(define* (make-hurd-device-nodes #:optional (root "/"))
"Make some of the nodes needed on GNU/Hurd."
(define (scope dir)
@@ -199,18 +228,25 @@ XXX TODO: use Linux xattr/setxattr to remove (settrans
in) /libexec/RUNSYSTEM
(format #t "Setting-up essential translators...\n")
(set-hurd-device-translators)
- (format #t "Starting pager...\n")
- (unless (zero? (system* "/hurd/mach-defpager"))
- (format #t "FAILED...Good luck!\n"))
-
(let* ((args(command-line))
(system (find-long-option "--system" args))
(to-load (find-long-option "--load" args)))
+
(false-if-exception (delete-file "/run/current-system"))
(format #t "Setting current system...~a\n" system)
(mkdir-p "/run")
(symlink system "/run/current-system")
+
+ (false-if-exception (delete-file "/hurd"))
+ (let ((hurd/hurd (readlink* (string-append system "/profile/hurd"
+ (symlink hurd/hurd "/hurd"))
+
+ (format #t "Starting pager...\n")
+ (unless (zero? (system* "/hurd/mach-defpager"))
+ (format #t "FAILED...Good luck!\n"))
+
(cond ((member "--repl" args)
+ (format #t "Starting repl...\n")
(start-repl))
(to-load
(format #t "loading '~a'...\n" to-load)
diff --git a/gnu/packages/hurd.scm b/gnu/packages/hurd.scm
index 9dc03c6c9c..087574cd61 100644
--- a/gnu/packages/hurd.scm
+++ b/gnu/packages/hurd.scm
@@ -390,6 +390,8 @@ PATH=@PATH@
fsck --yes --force /
fsysopts / --writable
+
+# Note: this /hurd/ gets substituted
settrans -c /servers/socket/1 /hurd/pflocal
# parse multiboot arguments
@@ -421,9 +423,18 @@ exec ${system}/rc \"$@\"
(substitute* '("utils/uptime.sh")
(("/bin/w")
(string-append out "/bin/w")))
- (substitute* "daemons/console-run.c"
+ (substitute* '("boot/boot.c"
+ "daemons/console-run.c"
+ "startup/startup.c")
(("/hurd/")
(string-append out "/hurd/")))
+ (substitute* "hurd/paths.h"
+ (("_HURD_STARTUP\t")
+ (string-append "_HURD_STARTUP\t\"" out "\" "))
+ (("_HURD_PROC\t")
+ (string-append "_HURD_PROC\t\"" out "\" "))
+ (("_HURD_AUTH\t")
+ (string-append "_HURD_AUTH\t\"" out "\" ")))
(substitute* '("daemons/runsystem.sh"
"sutils/MAKEDEV.sh")
(("^PATH=.*")
--8<---cut here---end--->8---
produces a bootable VM. So...this could be great or maybe...well, what
do you think?
>>t 4479c1c1e3 linux-boot: Update 'make-hurd-device-nodes'.
>> [M] a17f91bd50 image: Add Hurd support.
>>t 73594039
bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible
Is that showing the same (or a similar) problem : https://data.guix-patches.cbaines.net/gnu/store/0lcbxpw1vrca02dzpzw2rxhad7pn4zw7-gcc-objc-5.5.0 ? -- Vincent Legoll
