bug#39575: guix time-machine fails when a tarball was modified in-place
Hi, On Sat, 15 Feb 2020 at 21:01, Tobias Geerinckx-Rice wrote: > Janneke 写道： > > https://snapshot.debian.org/archive/debian/20190406T212022Z/pool/main/h/harfbuzz/harfbuzz_2.4.0.orig.tar.bz2 > > This is a wonderful resource! Thank you, Janneke (and Debian)! > > zimoun 写道： > > Cool! > > But how do you determine the "date", i.e., this reference > > '20190406T212022Z' ? > > You'd take the timestamp immediately preceding your desired (Guix) > commit's date, or something like that. The fact that git commit > dates aren't linear shouldn't hurt here. You assume that Debian packs packages as fast as Guix, I mean on the same schedule which is a strong assumption IMHO. For example, if it was the contrary and the "new" release of harfbuzz 2.4.0 were missing, then would Debian be helpful? > Also, this doesn't seem to be a supported service yet[0]: > > “This is an implementation for a possible snapshot.debian.org > service. >It's not yet finished, it's more a prototype/proof of concept >to show >and learn what we want and can provide. So far it seems to >actually work.” > > Still really cool, Yes, still cool! :-) Thanks, simon
bug#39632: Wrong keymap when decrypting master key
Tobias Geerinckx-Rice writes: > Didn't you already[0] report this bug as #39288? Then I'll merge > the two. no, it's not me. I deny it… Sorry, I'm getting old. Please merge them. -- Damien Cassou "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
bug#39575: guix time-machine fails when a tarball was modified in-place
Hi Ludo, On Sun, 16 Feb 2020 at 11:59, Ludovic Courtès wrote: > zimoun skribis: > > On Fri, 14 Feb 2020 at 22:34, Ludovic Courtès wrote: > >> Also, one could argue that we’d steer users towards downloading from our > >> server, which could be a privacy concern (probably not a strong argument > >> since one can easily change the substitute URLs.) > > > > I am not following the privacy concern. > > What do you mean? > > I mean that by default, someone who’s disabled substitutes (presumably > out of security or privacy concerns) would find themself downloading > source code from ci.guix.gnu.org instead of various upstream sites. I do not see the difference between mirroring and traveling back in time with missing upstream sources. And because it is content-addressed, it seems even more secure than downloading from a upstream URL, IMHO. If one trusts Guix, then an attacker needs to corrupt in the same time the Guix history and Berlin (and/or any other farm). If one does not trust Guix, why does they use the recipe coming from Guix? To be precise, this person has to check all the recipes of all the dependencies. Well, I do not see a security concern because we are talking about serving the sources. It is another story when the substitutes serve the results of the build (binaries); because one does not have any strong guarantee that the substitute serves the expected binaries. By privacy concern, do you mean that Guix could collect who downloads what; in a central fashion? Which is not the case when one downloads from several distributed upstream sources. Right? Well, I am not convinced because the case of missing upstream source is rare. And it is easy to protect against such collecting data process. In paranoid mode, traveling back in time is becoming difficult because of the reliability of the sources; I mean if the sources were reliable, SWH would not exist. ;-) The solution should be an IPFS / GNUnet / full distributed archive... which is not ready... yet! :-) Well, maybe for the TODO list of the time-machine: add an option to allow substitutes *only* for the sources (substitutes meaning ci.guix.gnu.org and/or SWH). If this option does not exist yet. ;-) Cheers, simon
bug#39575: guix time-machine fails when a tarball was modified in-place
On Mon, Feb 17, 2020 at 09:47:41AM +0100, zimoun wrote: > Hi, > > On Sat, 15 Feb 2020 at 21:01, Tobias Geerinckx-Rice wrote: > > > Janneke 写道： > > > https://snapshot.debian.org/archive/debian/20190406T212022Z/pool/main/h/harfbuzz/harfbuzz_2.4.0.orig.tar.bz2 > > > > This is a wonderful resource! Thank you, Janneke (and Debian)! > > > > zimoun 写道： > > > Cool! > > > But how do you determine the "date", i.e., this reference > > > '20190406T212022Z' ? > > > > You'd take the timestamp immediately preceding your desired (Guix) > > commit's date, or something like that. The fact that git commit > > dates aren't linear shouldn't hurt here. > > You assume that Debian packs packages as fast as Guix, I mean on the > same schedule which is a strong assumption IMHO. > For example, if it was the contrary and the "new" release of harfbuzz > 2.4.0 were missing, then would Debian be helpful? > > We could first try mirror://debian/pool/main/harfbuzz/harfbuzz_2.4.0.orig.tar.bz2 and then scrape https://snapshot.debian.org/package/harfbuzz/ for 2.4.0-1 and then parse the website for harfbuzz_2.4.0.orig.tar.bz2. Or for just 'orig.tar' > > Also, this doesn't seem to be a supported service yet[0]: > > > > “This is an implementation for a possible snapshot.debian.org > > service. > >It's not yet finished, it's more a prototype/proof of concept > >to show > >and learn what we want and can provide. So far it seems to > >actually work.” > > > > Still really cool, > > Yes, still cool! :-) > > > Thanks, > simon > > > -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
bug#28659: bug#39575: guix time-machine fails when a tarball was modified in-place
Hi, zimoun skribis: > On Sun, 16 Feb 2020 at 11:59, Ludovic Courtès wrote: >> zimoun skribis: >> > On Fri, 14 Feb 2020 at 22:34, Ludovic Courtès wrote: > >> >> Also, one could argue that we’d steer users towards downloading from our >> >> server, which could be a privacy concern (probably not a strong argument >> >> since one can easily change the substitute URLs.) >> > >> > I am not following the privacy concern. >> > What do you mean? >> >> I mean that by default, someone who’s disabled substitutes (presumably >> out of security or privacy concerns) would find themself downloading >> source code from ci.guix.gnu.org instead of various upstream sites. [...] > By privacy concern, do you mean that Guix could collect who downloads > what; in a central fashion? Which is not the case when one downloads > from several distributed upstream sources. Right? Exactly. But like I wrote above, I don’t think it’s a strong argument. What remains is the issue with ‘content-addressed-item?’, then. Ludo’.
bug#39643: (Out-of-tree) system kernel modules only found in :out
Guix, After adding (specification->package+output "zfs:module") to my system packages, it's still missing from current-system: $ guix system reconfigure … $ ls /run/current-system/profile/lib/modules/ 5.4.0-pf7-4-ed26-M88 That's my horrible custom Linux fork/version/abomination. Apologies. The ZFS package simply compiles against Guix's default linux-libre-5.4.20-gnu package. After editing the zfs package to install everything into the main :out output: $ guix system reconfigure … $ ls /run/current-system/profile/lib/modules/ 5.4.0-pf7-4-ed26-M88 5.4.20-gnu $ ls /run/current-system/profile/lib/modules/5.4.20-gnu/extra/zfs/ zfs.ko Kind regards, T G-R signature.asc Description: PGP signature
bug#39575: guix time-machine fails when a tarball was modified in-place
zimoun 写道： You assume that Debian packs packages as fast as Guix Indeed I do! :-D Efraim's solution sounds reasonable. Kind regards, T G-R signature.asc Description: PGP signature
bug#28659: bug#39575: guix time-machine fails when a tarball was modified in-place
On Mon, 17 Feb 2020 at 15:40, Ludovic Courtès wrote: > Exactly. But like I wrote above, I don’t think it’s a strong argument. I agree and the big picture depends on the audience. Scientific communities would be fine with centralized archives such as SWH. And only centralized archives IMHO can provide a reliable "long term" support which is the point for that communities. (Quote because not clearly defined what it is. :-)) Other communities would prefer distributed archive such as IPFS or GNUnet but 1. it still needs some work and 2. the "long term" is not guarantee by nature, IMHO. But it is probably not an issue for that communities. > What remains is the issue with ‘content-addressed-item?’, then. I agree. The bridge with SWH is in good shape, IMHO. And the pending IPFS patch would deserve more love. :-) Maybe soon... Cheers, simon
bug#39637: mongo-tools test fail with Go 1.13
On Sun, 16 Feb 2020, Jack Hill wrote: I have opened a bug report upstream: https://jira.mongodb.org/browse/TOOLS-2482 Upstream reports, "MongoDB 3.4 is now EOL so it is no longer supported. For MongoDB Tools specifically, we're only making critical fixes to versions <4.2." Therefore, it seems like the thing to do is to work on updating our mongo-tools package. Best, Jack
bug#39646: GNOME desktop experience regressions
Hello all, In January I upgraded my machine after a long time not doing so. Mostly things went fine, which is great! Some things didn't, though, so I started looking. One is that if I Alt-F2 and then run "~/Documents", I expect Nautilus to open the folder. Instead Baobab does. This is because GNOME has multiple applications are registered for the directory mime type, but doesn't express a preference between them: it leaves this to the distro. That is the reason for the gnome-default-applications package, which used to be installed as part of (service gnome-desktop-service-type). However that is no longer the case; since a8cda7f57992e9ce9ae4a694eba54e3eab42c39b, the "gnome" meta-package, which is installed by the GNOME desktop, no longer includes this package. That led me to look and I think there are a number of other regressions: * pinentry-gnome3 is no longer included; this breaks use of GPG and GNOME * font-cantarell and font-dejavu are no longer included; probably not a good idea? * xdg-user-dirs is no longer included, which means that fresh installs likely no longer create the ~/Documents directories as they should; see c20cd0d24d9b5e8a47b864db9799e0992ffd44b9 * I suspect that the removal of gnome-themes-standard and hicolor-icon-theme may also pose some problems but am not sure. * Likewise Guix users of the GNOME desktop service will probably want pulseaudio and zenity. Now, I understand wanting the "GNOME" package to reflect exactly what upstream says is part of GNOME. Great. But the desktop is a separate thing. Perhaps what we did before was an error in conflating the gnome meta-package with the desktop; should we define a different metapackage or package list for the GNOME desktop service? Regards, Andy
bug#39646: GNOME desktop experience regressions
Hi Andy! > That led me to look and I think there are a number of other > regressions: > > * pinentry-gnome3 is no longer included; this breaks use of GPG and > GNOME > > * font-cantarell and font-dejavu are no longer included; probably > not > a good idea? > > * xdg-user-dirs is no longer included, which means that fresh > installs > likely no longer create the ~/Documents directories as they > should; > see c20cd0d24d9b5e8a47b864db9799e0992ffd44b9 > > * I suspect that the removal of gnome-themes-standard and > hicolor-icon-theme may also pose some problems but am not sure. > > * Likewise Guix users of the GNOME desktop service will probably > want > pulseaudio and zenity. > > Now, I understand wanting the "GNOME" package to reflect exactly what > upstream says is part of GNOME. Great. But the desktop is a > separate > thing. Perhaps what we did before was an error in conflating the > gnome > meta-package with the desktop; should we define a different > metapackage > or package list for the GNOME desktop service? Thanks for your email. Yes, I removed those packages from 'gnome' meta-package as it did not reflect the upstream. I did it to avoid confusion on what to expect when any user sees a meta-package named just 'gnome'. But you are right, there is no one size that fits all. I am already working on to create two different meta-packages 'gnome' and 'gnome-minimal'. Also, packages like fonts and pin-entry can always be installed as system package. Some packages like gnome-default-applications and gnome-themes-standard are depracted by gnome project. Their contents were moved to other gnome core packages. I am still working on clearing all the hickups on gnome experience in guix. I will look into whether dedicated meta-package is required for desktop service. Regards, RG signature.asc Description: This is a digitally signed message part
bug#39463: Enlightenment desktop - multiple programs from other desktop environments
On Thu, 2020-02-06 at 20:01 +, Scott C. MacCallum via Bug reports for GNU Guix wrote: > After the installation of all the available desktop environments, > in the Enlightenment desktop environment there are multiple programs > from some of the other desktop environments to choose from, not just > the Enlightenment default ones. > > Scott > scmguru - irc.freenode.net > > > Sent with ProtonMail Secure Email. > > Does this happen when only Enlightenment is installed? If not, I do not think this is necessarily a bug. It makes sense that englightenment would detect all programs installed. Since other desktop environments install programs, enlightenment should detect the other programs. If gnome is installed alongside enlightenment, I would expect both environments to detect the same packages, including those installed by gnome and those installed by enlightenment. I suppose if it is nevertheless an undesirable behavior, we could try to allow a configuration to specify global profiles, so the desktop environments can be isolated from each other. Can anyone poke holes (bonus points if security-related) in this proposed solution?
bug#39469: Openbox - Ark File Archiver does not load
On Thu, 2020-02-06 at 16:05 -0500, Julien Lepiller wrote: > Le 6 février 2020 15:44:35 GMT-05:00, "Scott C. MacCallum via Bug > reports for GNU Guix" a écrit : > > After the installation of all the available desktop environments, > > in > > Openbox from the Accessories menu, Ark File Archiver does not load. > > Error message, "Failed to execute child process "ark" (No such file > > or > > directory)." > > > > Scott > > scmguru - irc.freenode.net > > > > Sent with [ProtonMail](https://protonmail.com) Secure Email. > > See #39468. Ark is not installed on your computer, and the menu is > static. I don't think we can do anything about it. > > > We could... - patch the source so the menu is not static - package ark (kde-ark) and include it as a propagated-input to openbox - make sure openbox respects $PATH
bug#39575: guix time-machine fails when a tarball was modified in-place
HI Jan, On Fri, 14 Feb 2020 at 14:24, Jan Nieuwenhuizen wrote: This command > >> $ guix download -o /tmp/harfbuzz-old.tar.bz2 \ > >> > >> https://ci.guix.gnu.org/file/harfbuzz-2.4.0.tar.bz2/sha256/1mpah6kwqid1kxsj4rwqsniivqbrx231j65v51yncx6s0dch0dch now works. However, this command $ guix time-machine \ --commit=56e95d54d209c2428f970d65d9b27ae4168449ad -- help still fails for me with the message: --8<---cut here---start->8--- [...] building /gnu/store/gglbrs8j0iq8ygh55inwfvpwb5z2x254-guile-2.2.4.drv... - 'check' phasebuilder for `/gnu/store/gglbrs8j0iq8ygh55inwfvpwb5z2x254-guile-2.2.4.drv' failed with exit code 1 build of /gnu/store/gglbrs8j0iq8ygh55inwfvpwb5z2x254-guile-2.2.4.drv failed View build log at '/var/log/guix/drvs/gg/lbrs8j0iq8ygh55inwfvpwb5z2x254-guile-2.2.4.drv.bz2'. cannot build derivation `/gnu/store/yqpxm07zm0mirrdvl2c4qvf8biyzg468-guix-56e95d54d.drv': 1 dependencies couldn't be built cannot build derivation `/gnu/store/7z7p0m7abi246gzigw8as2q3w33k1n31-profile.drv': 1 dependencies couldn't be built guix time-machine: error: build of `/gnu/store/7z7p0m7abi246gzigw8as2q3w33k1n31-profile.drv' failed --8<---cut here---end--->8--- The log /var/log/guix/drvs/gg/lbrs8j0iq8ygh55inwfvpwb5z2x254-guile-2.2.4.drv.bz2 is not meaningful for me... but I can report it here. > that i'm trying now, and for now it looks fine (lots of stuff to build, > i'll report success or failure when it's done). Well, is it a success or a failure for you? Cheers, simon
bug#39469: Openbox - Ark File Archiver does not load
Le 17 février 2020 12:49:28 GMT-05:00, Jesse Gibbons a écrit : >On Thu, 2020-02-06 at 16:05 -0500, Julien Lepiller wrote: >> Le 6 février 2020 15:44:35 GMT-05:00, "Scott C. MacCallum via Bug >> reports for GNU Guix" a écrit : >> > After the installation of all the available desktop environments, >> > in >> > Openbox from the Accessories menu, Ark File Archiver does not load. >> > Error message, "Failed to execute child process "ark" (No such file >> > or >> > directory)." >> > >> > Scott >> > scmguru - irc.freenode.net >> > >> > Sent with [ProtonMail](https://protonmail.com) Secure Email. >> >> See #39468. Ark is not installed on your computer, and the menu is >> static. I don't think we can do anything about it. >> >> >> >We could... >- patch the source so the menu is not static >- package ark (kde-ark) and include it as a propagated-input to openbox >- make sure openbox respects $PATH Openbox already respects $PATH. As an openbox user, I don't expect the menu to be dynamic, unless I install a menu builder (which I kind of do, since I use the guix home manager for that). Ark is not a component of openbox, so I don't think it makes sense to propagate it. I certainly don't want to have it on my system. As was suggested, the right thing to do is to have an %openbox-suggested-packages added to the set of system packages when installing openbox from the graphical installer. Then it would be up to users to decide what to do. We could also warn that openbox has less automation than other desktop managers. It's only a window manager.
bug#39648: Reverse my commits on GNOME meta-package
Hello Guix! @Danny Could you please reverse my following commits: 1) d36fa50fbf8169018193774782fd21f1b13b9c0e 2) 7922b6f795eb575084546ec9bfb9d40508a9378e 3) 8d8c6bffc528b60574f84620bd6c3ee9bfa1173f 4) a8cda7f57992e9ce9ae4a694eba54e3eab42c39b I will re-test throughly and re-commit them later. I also apologize for the mishap. Thank you! Regards, RG. signature.asc Description: This is a digitally signed message part
bug#39646: GNOME desktop experience regressions
Hi Andy! > > That led me to look and I think there are a number of other > > regressions: > > > > * pinentry-gnome3 is no longer included; this breaks use of GPG > > and > > GNOME > > > > * font-cantarell and font-dejavu are no longer included; probably > > not > > a good idea? > > > > * xdg-user-dirs is no longer included, which means that fresh > > installs > > likely no longer create the ~/Documents directories as they > > should; > > see c20cd0d24d9b5e8a47b864db9799e0992ffd44b9 > > > > * I suspect that the removal of gnome-themes-standard and > > hicolor-icon-theme may also pose some problems but am not sure. > > > > * Likewise Guix users of the GNOME desktop service will probably > > want > > pulseaudio and zenity. > > > > Now, I understand wanting the "GNOME" package to reflect exactly > > what > > upstream says is part of GNOME. Great. But the desktop is a > > separate > > thing. Perhaps what we did before was an error in conflating the > > gnome > > meta-package with the desktop; should we define a different > > metapackage > > or package list for the GNOME desktop service? > > Thanks for your email. > > Yes, I removed those packages from 'gnome' meta-package as it did not > reflect the upstream. I did it to avoid confusion on what to expect > when any user sees a meta-package named just 'gnome'. But you are > right, there is no one size that fits all. I am already working on to > create two different meta-packages 'gnome' and 'gnome-minimal'. > > Also, packages like fonts and pin-entry can always be installed as > system package. Some packages like gnome-default-applications and > gnome-themes-standard are depracted by gnome project. Their contents > were moved to other gnome core packages. > > I am still working on clearing all the hickups on gnome experience in > guix. I will look into whether dedicated meta-package is required for > desktop service. Since I am working on further changes to GNOME in guix, I think it is better to test it throughly altogether. So I have asked to reverse my commits on meta-package ( http://debbugs.gnu.org/cgi/bugreport.cgi?bug=39648). That should reverse the hickups you are facing. :-) Regards, RG. signature.asc Description: This is a digitally signed message part
bug#39648: Reverse my commits on GNOME meta-package
Raghav Gururajan 写道： Could you please reverse my following commits: 1) d36fa50fbf8169018193774782fd21f1b13b9c0e 2) 7922b6f795eb575084546ec9bfb9d40508a9378e 3) 8d8c6bffc528b60574f84620bd6c3ee9bfa1173f 4) a8cda7f57992e9ce9ae4a694eba54e3eab42c39b Copy-pasted from #guix: Whoa there, that's drastic, let's put that on hold. The first two only add packages (did they break anything? what?), the third has no effect on packages if your commit message is accurate. The fourth is the only one that removes packages, and even that might be better tweaked (this time: with comments noting what each non-core package brings to the GNOME table) than flat-out reverted. What do you think? Kind regards, T G-R signature.asc Description: PGP signature
bug#39648: Reverse my commits on GNOME meta-package
> Copy-pasted from #guix: > > Whoa there, that's drastic, let's put that on hold. > > The first two only add packages (did they break anything? what?), > the third has no effect on packages if your commit message is > accurate. > > The fourth is the only one that removes packages, and even that > might be better tweaked (this time: with comments noting what each > non-core package brings to the GNOME table) than flat-out > reverted. > > What do you think? I made a mistake of not reading comments of previous commits that were done to gnome meta-package. Since we got lot of feedbacks regarding gnome experience, I will re-conyemplate my plans for gnome, make the changes, test it throughly and then re-commit later. Also, this reverse should be smooth and does not break anything. It just takes the GNOME meta-package back to the time before I started making my commits to it. Regards, RG. signature.asc Description: This is a digitally signed message part
bug#39648: Reverse my commits on GNOME meta-package
Hello Tobias, Tobias Geerinckx-Rice via Bug reports for GNU Guix ezt írta (időpont: 2020. febr. 17., H, 20:03): > > Raghav Gururajan 写道： > > Could you please reverse my following commits: > > > > 1) d36fa50fbf8169018193774782fd21f1b13b9c0e > > > > 2) 7922b6f795eb575084546ec9bfb9d40508a9378e > > > > 3) 8d8c6bffc528b60574f84620bd6c3ee9bfa1173f > > > > 4) a8cda7f57992e9ce9ae4a694eba54e3eab42c39b > > Copy-pasted from #guix: > > Whoa there, that's drastic, let's put that on hold. I agree. > > The first two only add packages (did they break anything? what?), > the third has no effect on packages if your commit message is > accurate. These findings are accurate. I checked the diff of the third, it's ok. > > The fourth is the only one that removes packages, and even that > might be better tweaked (this time: with comments noting what each > non-core package brings to the GNOME table) than flat-out > reverted. > I believe the fourth can be reverted if needed. > What do you think? > > Kind regards, > > T G-R Best regards, g_bor -- OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21
bug#39648: Reverse my commits on GNOME meta-package
> I believe the fourth can be reverted if needed. Some packages that were removed, I made a mistake of not reading the comments of why it were added in the first place. Some of them were non-core and some were core but depracated. It gonna take some time for me to read and understand their exact role and effect on GNOME experience. Since I am planning+working on new changes anyway, I will study and test them throughly all together to see how the experience is and then commit them. :-) Regards, RG. signature.asc Description: This is a digitally signed message part
bug#39650: wish: search shows whether a package is installed
Hi, It would be great if `guix search TERMS` could show for each record whether the package is installed and which versions are installed. I regularly search for a library and then check with guix package -I whether I already have it, and that’s quite inconvenient. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken
bug#39650: wish: search shows whether a package is installed
Hi Arne, On Mon, 17 Feb 2020 at 23:16, Arne Babenhauserheide wrote: > It would be great if `guix search TERMS` could show for each record > whether the package is installed and which versions are installed. I agree. Say if it is already in '/gnu/store' is often helpful. And "guix search" should even provide in which profile it is already installed (maybe even in which generation of which profile it is already) > I regularly search for a library and then check with guix package -I > whether I already have it, and that’s quite inconvenient. In the meantime, something along these lines should do the trick... --8<---cut here---start->8--- for profile in $(guix package --list-profiles) do echo $profile guix package -p $profile -I | grep done --8<---cut here---end--->8--- and it is not convenient, I agree. :-) All the best, simon
