bug#42420: git-fetch origins produce same store output when set recursive is set to true or false
Hello, Marius Bakke writes: > pkill9 writes: > >> I built a source that uses git-fetch - by default (recursive? #f) - and >> the package failed to build, then I remembered it uses submodules, so I >> set (recursive? #t) but it failed with the same error. The problem is >> that the store path of the source is the same for both, so it didn't >> try to rebuild the git checkout with submodules checked out. >> >> After garbage collecting the source so it rebuilds it, I can build the >> package. > > Could it be that you did not update the sha256 checksum of the package > after setting (recursive? #t), so Guix thought it already had the > complete checkout in the store? Yes, that just happened to me. It's confusing, but I don't see how we can improve on that. pkill, next time this happens, you might want to force a check on the cached source via 'guix build --source --check'. I believe this would flag the discrepancy. Is there an action to do here, or should we simply close it? Thanks, Maxim
bug#37309: ‘ssh-daemon’ service fails to start at boot
Christopher Lemmer Webber skriver: > Giovanni Biscuolo writes: > >> Hi, >> >> following a recent discussion on guix-sysadmin I have to confirm the >> ssh-daemon issue since it is still happening on some of the machines I >> administer >> >> Previous possibly related bug reports are >> https://issues.guix.gnu.org/issue/30993 and >> https://issues.guix.gnu.org/issue/32197 >> >> Unfortunately this issue is *not* well reproducible, it depends on some >> mysterious (to me) timing factor; AFAIU it does *not* depend on the >> shepherd version, probably it depends on "something" related to IPv6 >> (read below the details) > > This issue continues to plauge me, and has ever since I started to use > GuixSD. However it is much worse now that I am running Guix on > servers... I frequently have to log in via Linode's (nonfree!) web > console on every server that is rebooted and kick herd to restart > openssh. Once I do that it's fine. Can you share an excerpt of /var/log/messages (ideally the whole boot sequence) from when SSH failed to start? > I don't think my linode machine is on "spinning rust" so I don't think > this is the cause. IPv6, maybe? Dunno what. > > However I think that it's probably really a dependency issue somewhere; > herd is starting opensshd before some other dependent service is > spawned. But what? Maybe something authentication related like > networking, or something. But hm, networking is required... > > I'm assuming others must be experiencing this still too... right? FWIW I have never encountered this. :-/ > Would really like to see it fixed. It's one of the few things holding > me back from recommending Guix on servers to others. > > Do others have any idea? > > I noticed the lsh daemon requires networking. Why doesn't openssh? It's really for legacy reasons, from before we had the Guix System installer. Then a common way to install was to run dhclient and "herd start ssh-daemon" manually on the live image, so people could do the installation over SSH: https://issues.guix.gnu.org/26548#5 Nowadays, the installer gives a nice and quick way to deploy a minimal system, and I suspect the SSH method has fallen out of favor. > What about the following "fix"? [...] >(list (shepherd-service > (documentation "OpenSSH server.") > - (requirement '(syslogd loopback)) > + (requirement '(syslogd networking loopback)) If it works for you, let's do this. It would be good to find the underlying cause though... Not sure what to do about the installer however: perhaps create yet-another undocumented field of openssh-service-type that makes the networking requirement optional? signature.asc Description: PGP signature
bug#44906: Substitute requests fail if URL has trailing slash
Dear,
Thank you for the report.
Tweaking the function such as:
--8<---cut here---start->8---
(define (narinfo-request cache-url path)
"Return an HTTP request for the narinfo of PATH at CACHE-URL."
(let ((url (string-append cache-url "/" (store-path-hash-part path)
".narinfo"))
(headers '((User-Agent . "GNU Guile"
(format #t "~%Narinfo request: ~a~%~%" url)
(build-request (string->uri url) #:method 'GET #:headers headers)))
--8<---cut here---end--->8---
and removing the cache adequately, then running:
--8<---cut here---start->8---
./pre-inst-env guix weather \
--substitute-urls="https://ci.guix.gnu.org/ https://ci.guix.gnu.org; \
hello
computing 1 package derivations for x86_64-linux...
looking for 1 store items on https://ci.guix.gnu.org/...
Narinfo request:
https://ci.guix.gnu.org//a462kby1q51ndvxdv3b6p0rsixxrgx1h.narinfo
updating substitutes from 'https://ci.guix.gnu.org/'... 100.0%
https://ci.guix.gnu.org/
0.0% substitutes available (0 out of 1)
[...]
'https://ci.guix.gnu.org//api/queue?nr=1000' returned 400 ("Bad Request")
looking for 1 store items on https://ci.guix.gnu.org...
Narinfo request:
https://ci.guix.gnu.org/a462kby1q51ndvxdv3b6p0rsixxrgx1h.narinfo
updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
https://ci.guix.gnu.org
100.0% substitutes available (1 out of 1)
[...]
at least 1,000 queued builds
[...]
build rate: 36.89 builds per hour
[...]
--8<---cut here---end--->8---
On Fri, 27 Nov 2020 at 22:19, Hartmut Goebel
wrote:
> According to RFC 7230, sec 2.7.3 "http and https URI Normalization and
> Comparison" [1]:
>
>[…] an empty
>path component is equivalent to an absolute path of "/", so the
>normal form is to provide a path of "/" instead.
>
> [1] https://tools.ietf.org/html/rfc7230#section-2.7.3
Now, the question is where should the fix go? “guix publish” exposing
the narinfos or “guix weather“? Or both?
>From my understanding, one fix should go to ‘guix publish’ exposing the
narinfos since:
https://ci.guix.gnu.org//a462kby1q51ndvxdv3b6p0rsixxrgx1h.narinfo
should be a valid URL and return the narinfo file. However, taking this
road, it means that the cache folder will not be the same:
~/.cache/guix/substitute/x2wcz6gz3evwlqcrz3fqstmezkfcfnpfb5kfyxbz7kjikc7upkiq/
~/.cache/guix/substitute/4refhwxbjmeua2kwg2nmzhv4dg4d3dorpjefq7kiciw2pfhaf26a/
https://ci.guix.gnu.org/ resp. https://ci.guix.gnu.org Therefore, ‘guix
weather’ should be fixed too.
WDYT?
All the best,
simon
bug#37309: ‘ssh-daemon’ service fails to start at boot
Giovanni Biscuolo writes: > Hi, > > following a recent discussion on guix-sysadmin I have to confirm the > ssh-daemon issue since it is still happening on some of the machines I > administer > > Previous possibly related bug reports are > https://issues.guix.gnu.org/issue/30993 and > https://issues.guix.gnu.org/issue/32197 > > Unfortunately this issue is *not* well reproducible, it depends on some > mysterious (to me) timing factor; AFAIU it does *not* depend on the > shepherd version, probably it depends on "something" related to IPv6 > (read below the details) This issue continues to plauge me, and has ever since I started to use GuixSD. However it is much worse now that I am running Guix on servers... I frequently have to log in via Linode's (nonfree!) web console on every server that is rebooted and kick herd to restart openssh. Once I do that it's fine. I don't think my linode machine is on "spinning rust" so I don't think this is the cause. IPv6, maybe? Dunno what. However I think that it's probably really a dependency issue somewhere; herd is starting opensshd before some other dependent service is spawned. But what? Maybe something authentication related like networking, or something. But hm, networking is required... I'm assuming others must be experiencing this still too... right? Would really like to see it fixed. It's one of the few things holding me back from recommending Guix on servers to others. Do others have any idea? I noticed the lsh daemon requires networking. Why doesn't openssh? What about the following "fix"? diff --git a/gnu/services/ssh.scm b/gnu/services/ssh.scm index 1891db0487..c9bd62bab7 100644 --- a/gnu/services/ssh.scm +++ b/gnu/services/ssh.scm @@ -508,7 +508,7 @@ of user-name/file-like tuples." (list (shepherd-service (documentation "OpenSSH server.") - (requirement '(syslogd loopback)) + (requirement '(syslogd networking loopback)) (provision '(ssh-daemon ssh sshd)) (start #~(make-forkexec-constructor #$openssh-command #:pid-file #$pid-file))
bug#44914: gnutls-dane does not build: failed test status-request-revoked
I cannot update Guix right now, because gnutls-dane fails to build. The build log is attached. make[4]: Entering directory '/tmp/guix-build-gnutls-dane-3.6.12.drv-0/gnutls-3.6.12/tests' … FAIL: status-request-revoked q6971vxd8k1vhx8qp13al2lp3y11rc-gnutls-dane-3.6.12.drv.bz2 Description: Binary data Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
bug#44898: (No Subject)
I would like to clarify that whenever I wrote "boot parameters", I meant installation arguments passed to grub-install.
bug#44827: tests/channels.scm: Test failures building on Debian i386 or armhf with libgit2-dev 1.0.1
On 2020-11-27, Ludovic Courtès wrote: > Vagrant Cascadian skribis: >> On 2020-11-26, Ludovic Courtès wrote: >>> In particular, Guile-Git 0.4.0 has this thing compile-time check to make >>> sure it matches the ABI of the underlying libgit2 version (0.28 or 1.0): >>> >>> >>> https://gitlab.com/guile-git/guile-git/-/commit/2b4d077c6f55648f42af31ae783ca4d8c1c5f1de >>> >>> So if you change libgit2 versions, you need to rebuild Guile-Git. >> >> Oh, this will be fun to keep track of in debian... :/ :) > > Note that the problem is the same for packages written in C since it’s > an ABI change in libgit2. (Except that in C perhaps you get a SONAME > mismatch at load time rather than an error at run time…) > >> Yeah, the guile-git was built with the older 0.28 version of libgit2-dev >> (although also with all the architectures). >> >> Interestingly enough, guix pull completely fails with the older >> libgit2-dev version installed, but installing the new version it works >> fine. >> >> I'll build a newer guile-git version and force it to use the newer >> libgit2-dev package, and see if that fixes the issues. >> >> Then I'll have to come up with complicated versioned dependencies to >> ensure it keeps working in Debian and it becomes detectable when it >> needs to be rebuilt... > > Heheh. Let me know how it goes! Rebuilding guile-git against the newer libgit2 seems to resolve the issues; the test suites passed on amd64, armhf, i386 (the only platforms currently buildable on Debian). live well, vagrant signature.asc Description: PGP signature
bug#44906: Substitute requests fail if URL has trailing slash
If the substitute-URL ends with a slash, api requests fail.
Expected behavior:
Substitute-URLs with and without trailing slash should behave the same.
This is especially true for substitute-URLs with empty path
("http://server;) and path "/" (http://server/;) - for which the RFCs
explicitly state to be equivalent.
According to RFC 7230, sec 2.7.3 "http and https URI Normalization and
Comparison" [1]:
[…] an empty
path component is equivalent to an absolute path of "/", so the
normal form is to provide a path of "/" instead.
[1] https://tools.ietf.org/html/rfc7230#section-2.7.3
How to reproduce:
no trailing slash:
$ guix weather --substitute-urls="https://ci.guix.gnu.org; gcc-toolchain
…
https://ci.guix.gnu.org
100.0% substitutes available (3 out of 3)
…
Trailing slash:
$ guix weather --substitute-urls="https://ci.guix.gnu.org/; gcc-toolchain
…
https://ci.guix.gnu.org/
0.0% substitutes available (0 out of 3)
…
'https://ci.guix.gnu.org//api/queue?nr=1000' returned 400 ("Bad Request")
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
bug#44820: MPD fails after respawning too often
Martin Becze writes: > I also ran into this problem. Here is the relevnat part of > /var/run/mpd//log > >> exception: Failed to create pid file "/var/run/mpd//pid": >> Permission denied > > A quick dirty fix is just to chown the /var/run/mpd folder so that mpd > can create its pid file. I have the the same error message in my log file too, and chowning ownership of directories helps too. > > On 11/27/20 4:31 AM, Ludovic Courtès wrote: >> Hi, >> Simon skribis: >> >>> On a recent pull, MPD will not start any more. >>> >>> Herd status reports: >>> >>> Status of mpd: >>>It is stopped. >>>It is disabled. >>>Provides (mpd). >>>Requires (user-processes). >>>Conflicts with (). >>>Will be respawned. >>>Last respawned on Mon Nov 23 10:22:07+0100 2020. >>> >>> >>> Reading my messages, I find: >>> >>> Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd. >>> Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started. >>> Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd. >>> Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started. >>> Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd. >>> Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started. >>> Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd. >>> Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started. >>> Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd. >>> Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started. >>> Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd. >>> Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started. >>> Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been disabled. >>> Nov 23 10:22:07 localhost shepherd[1]: (Respawning too fast.) >>> >>> >>> Unfortunately, there are no further messages as to why the service is >>> disabled, or why the daemon is respawning too often. >> Does /var/log/mpd/mpd.log or similar contain useful info? >> Could you share your ‘mpd-configuration’? >> There have been two changes recently, which fixed the mpd system >> test, >> but perhaps they introduced other issues: >> >> https://git.savannah.gnu.org/cgit/guix.git/log?id=bb124f6e9c0af0a23736f233c2ea2c9c9b4a40a6 >> Thanks for reporting the issue, >> Ludo’. If I read it correctly in the changes made above, ownership of the directory should be changed, but it is not. I just deleted the directory in /run/mpd and did a reboot. The user directory is recreated, and .mpd too, but only ownership is changed in .mpd. Too bad that my knowledge in guile is too limited at the moment to provide a solution. But I'd really love too at the moment. :) But I believe ownership of the parent directory should be changed according to the user. Sorry that I can't provide any better solution at the moment. Cheers, Simon
bug#44891: Chromium does not start
Andrea Rossi via Bug reports for GNU Guix writes: > On 27/11/20 09:32, Giovanni Biscuolo wrote: >> [...] >> 1. sudo sysctl -w kernel.unprivileged_userns_clone=1 >> 2. sudo su -c "echo 'kernel.unprivileged_userns_clone=1' > >> /etc/sysctl.d/00-local-userns.conf" > > It works! Fine! Closing this bug. Ciao, Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
bug#44891: Chromium does not start
On 27/11/20 09:32, Giovanni Biscuolo wrote: > [...] > 1. sudo sysctl -w kernel.unprivileged_userns_clone=1 > 2. sudo su -c "echo 'kernel.unprivileged_userns_clone=1' > > /etc/sysctl.d/00-local-userns.conf" > It works! Thanks, Andrea
bug#44898: [wishlist] Make the GRUB installation procedure smarter
Every time the operating system is instantiated the GRUB boot-loader is inexplicitly re-installed. This behaviour leads to unsolicited changes to the user's boot configuration on UEFI systems; and leads to unnecessary write operations on the ESP, and/or the MBR, which, in case they are abruptly aborted during the building of the install-bootloader derivation, can leave the system in an unbootable state. Futhermore, frequent writes to the platform's NV-RAM may negatively impact its lifespan. NixOS stores the GRUB derivation as well as boot parameters in a state file, and only re-installs the boot-loader if the computed state is different from the stored state: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/loader/grub/install-grub.pl#L626. However, unless I am mistaken, that alone will not prevent GRUB from altering the user's boot configuration in a scenario, in which we want GRUB to be re-installed because it has received an update. To summarize, I think that consecutive grub-install invocations should not be allowed to modify the user's boot configuration on UEFI systems, and that we should teach Guix to only re-install the boot-loader if the boot parameters has been changed and/or the GRUB package has been upgraded. Although other boot-loaders are not in the scope of this wish, brining their installation procedures to the same high standard would be beneficial, too.
bug#44872: Fw: bug#44872: GuixSD 1.2.0 installer fails with exception when formatting drive
> It looks like the UUID extraction of an "ext4" partition failed. Did you use automatic or manual partitioning? I used automatic partitioning this time. But it failed with an exception when I had previously tried manual partitioning as well. Though I believe it was a different error then.
bug#44862:
I've been experiencing the same since I started using Guix some months ago. In my experience, this happens only with manually added shortcuts, it seems XFCE links directly to the store in that case. It can be fixed manually, although I agree it would be nice if it wasn't necessary. In case znavko finds it helpful here's a manual workaround: to fix the shortcut for 'foo', run 'which foo' and copy the path (it should be to the profile instead of to the store). Then right click on the shortcut for 'foo'', click on "edit" and replace the old path to the store with the path to the profile. Hope it helps! Tomás
bug#44820: MPD fails after respawning too often
I also ran into this problem. Here is the relevnat part of /var/run/mpd//log exception: Failed to create pid file "/var/run/mpd//pid": Permission denied A quick dirty fix is just to chown the /var/run/mpd folder so that mpd can create its pid file. On 11/27/20 4:31 AM, Ludovic Courtès wrote: Hi, Simon skribis: On a recent pull, MPD will not start any more. Herd status reports: Status of mpd: It is stopped. It is disabled. Provides (mpd). Requires (user-processes). Conflicts with (). Will be respawned. Last respawned on Mon Nov 23 10:22:07+0100 2020. Reading my messages, I find: Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd. Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started. Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd. Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started. Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd. Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started. Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd. Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started. Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd. Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started. Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd. Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started. Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been disabled. Nov 23 10:22:07 localhost shepherd[1]: (Respawning too fast.) Unfortunately, there are no further messages as to why the service is disabled, or why the daemon is respawning too often. Does /var/log/mpd/mpd.log or similar contain useful info? Could you share your ‘mpd-configuration’? There have been two changes recently, which fixed the mpd system test, but perhaps they introduced other issues: https://git.savannah.gnu.org/cgit/guix.git/log?id=bb124f6e9c0af0a23736f233c2ea2c9c9b4a40a6 Thanks for reporting the issue, Ludo’.
bug#44881: glib build fail for armhf
Hi Mathieu, Mathieu Othacehe skribis: > The glib build is broken on armhf due to a timeout in the test suite, > see: > https://ci.guix.gnu.org/log/m6rd864j30khc6k60gr2wqr1pz40f1di-glib-2.62.6-bin. > > It looks like it's also broken on the 1.2.0 branch. Yeah. We were discussing it with Chris Baines on IRC. My hypothesis is that those tests time out on low-end ARMv7 devices (like guix-x15.sjd.se). Previously, we were building them on the more powerful OverDrives probably, and indeed, the tests pass there. Berlin now has a substiute for this one built on an OverDrive. > This prevents the evaluation of the guix-modular specification, see: > https://ci.guix.gnu.org/eval/19035/log/raw. I disabled the armhf-linux > system for that specification until this is understood. I think we can re-enable it now? Thanks, Ludo’.
bug#44820: MPD fails after respawning too often
Hi, Simon skribis: > On a recent pull, MPD will not start any more. > > Herd status reports: > > Status of mpd: > It is stopped. > It is disabled. > Provides (mpd). > Requires (user-processes). > Conflicts with (). > Will be respawned. > Last respawned on Mon Nov 23 10:22:07+0100 2020. > > > Reading my messages, I find: > > Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd. > Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started. > Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd. > Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started. > Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd. > Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started. > Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd. > Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started. > Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd. > Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started. > Nov 23 10:22:07 localhost shepherd[1]: Respawning mpd. > Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been started. > Nov 23 10:22:07 localhost shepherd[1]: Service mpd has been disabled. > Nov 23 10:22:07 localhost shepherd[1]: (Respawning too fast.) > > > Unfortunately, there are no further messages as to why the service is > disabled, or why the daemon is respawning too often. Does /var/log/mpd/mpd.log or similar contain useful info? Could you share your ‘mpd-configuration’? There have been two changes recently, which fixed the mpd system test, but perhaps they introduced other issues: https://git.savannah.gnu.org/cgit/guix.git/log?id=bb124f6e9c0af0a23736f233c2ea2c9c9b4a40a6 Thanks for reporting the issue, Ludo’.
bug#44827: tests/channels.scm: Test failures building on Debian i386 or armhf with libgit2-dev 1.0.1
Hi, Vagrant Cascadian skribis: > On 2020-11-26, Ludovic Courtès wrote: [...] >> In particular, Guile-Git 0.4.0 has this thing compile-time check to make >> sure it matches the ABI of the underlying libgit2 version (0.28 or 1.0): >> >> >> https://gitlab.com/guile-git/guile-git/-/commit/2b4d077c6f55648f42af31ae783ca4d8c1c5f1de >> >> So if you change libgit2 versions, you need to rebuild Guile-Git. > > Oh, this will be fun to keep track of in debian... :/ :) Note that the problem is the same for packages written in C since it’s an ABI change in libgit2. (Except that in C perhaps you get a SONAME mismatch at load time rather than an error at run time…) > Yeah, the guile-git was built with the older 0.28 version of libgit2-dev > (although also with all the architectures). > > Interestingly enough, guix pull completely fails with the older > libgit2-dev version installed, but installing the new version it works > fine. > > I'll build a newer guile-git version and force it to use the newer > libgit2-dev package, and see if that fixes the issues. > > Then I'll have to come up with complicated versioned dependencies to > ensure it keeps working in Debian and it becomes detectable when it > needs to be rebuilt... Heheh. Let me know how it goes! Thanks, Ludo’.
bug#44891: Chromium does not start
Hi raingloom, raingloom writes: > On Thu, 26 Nov 2020 16:53:29 +0100 > Andrea Rossi via Bug reports for GNU Guix wrote: [...] >> [20998:20998:1126/122306.639343:FATAL:zygote_host_impl_linux.cc(117)] >> No usable sandbox! Update your kernel or see >> https://chromium.9oo91esource.qjz9zk/chromium/src/+/master/docs/linux/suid_sandbox_development.md >> for more information on developing with the SUID sandbox. If you want >> to live dangerously and need an immediate workaround, you can try >> using --no-sandbox. [...] > Saw a similar issue on Arch recently, my guess is that the sandbox > binary (I don't remember its name or path) is missing the execute > permission bit. As reported in my previous reply to Andrea, AFAIU (thanks Marius Bakke) Chromium can use two methods to start the sandbox: 1. use the SUID binary 2. use user namespaces AFAIU the second is better and anyway it's the method used by Guix ungoogled-chromium > Not sure how to fix that on Guix, since modifying a store item is > generally a big no-no. You could maybe write a quick and dirty package > that takes ungoogled-chromium as its only input, copies it (or just > creates symlinks?), and runs chmod +x on the sandbox binary. > That way you don't have to recompile the whole package. Non need for all this :-D Thanks, Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
bug#44891: Chromium does not start
Ciao Andrea, To the list: Andrea is a friend and a collegue, I'm helping him starting using Guix as a package manager. Andrea: next time when reporting bugs on Guix please mention you are using it on a foreign distro (not as Guix System), in your case Debian. Andrea Rossi via Bug reports for GNU Guix writes: > after the installation of ungoogled-chromium I tried to run it, > receiving this message: > > [20998:20998:1126/122306.639343:FATAL:zygote_host_impl_linux.cc(117)] No > usable sandbox! Update your kernel or see > https://chromium.9oo91esource.qjz9zk/chromium/src/+/master/docs/linux/suid_sandbox_development.md > for more information on developing with the SUID sandbox. If you want to > live dangerously and need an immediate workaround, you can try using > --no-sandbox. > > Maybe I'm missing something, or is the case of a proper bug? In Jan this year I had the same issue, reported in help-guix, on Debian as foreign distro and Marius Bakke [1] helped me solve it: 1. sudo sysctl -w kernel.unprivileged_userns_clone=1 2. sudo su -c "echo 'kernel.unprivileged_userns_clone=1' > /etc/sysctl.d/00-local-userns.conf" This is because (ungoogled-)chromium sandbox relies on user namespaces support in the kernel but Debian [2] disables user namespaces by default, the above commands enables them for your current boot session and permanently for next reboots. Andrea please try the above fixes and tell us if they solve your issue. Ciao, Gio' [1] https://lists.gnu.org/archive/html/help-guix/2020-01/msg00059.html [2] Chromium on Debian uses an alternative sandboxing method that relies on a setuid binary, Guix do not use this :-) -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
