bug#37999: clang fails to pickup/supply startfiles to ld
> Marius: I believe this will only cause a rebuild for clang and not > llvm, which means that it only affects ~30 packages. Perhaps this can > go in master? Would love to know your thoughts. There is also the problem that IceCat depends on Rust which depends on Clang as stated by Mark. Mathieu
bug#38064: Simple Scan: Scanner is not detected
On Mon, 4 Nov 2019, sirgazil via Bug reports for GNU Guix wrote: I can't use the scanner because Simple Scan (a.k.a. Document Scanner) does not detect it. That's unfortunate. I think the follow information might help in troubleshooting: What scanner is it, and how is it connected (e.g. USB)? What does running `scanimage -L` from the terminal report? scanimage can be found in the sane-backends package (yes, it contains frontends too :)) I expect this to also report no scanners found just like simple-scan, but it's worth checking just to be sure. I've added `(simple-service 'custom-udev-rules udev-service-type (list sane-backends))` to my system services, which may help the scanning tools have permission to access your scanner. Best, Jack
bug#38064: Simple Scan: Scanner is not detected
I can't use the scanner because Simple Scan (a.k.a. Document Scanner) does not detect it. ## Steps to reproduce 1. guix install simple-scan 2. Connect the scanner. 3. Launch Simple Scan. 4. Click the Scan button in Simple Scan. ## Unexpected behavior In step 3, Simple scan displays the following warning: ``` No scanners detected Please check your scanner is connected and powered on ``` In step 4, you see the following message: ``` Failed to scan No scanners available. Please connect a scanner. ``` ## Expected behavior * The scanner is detected in step 3 (no warning message is shown). * Performing step 4 makes the scanner scan. ## System information I'm using the Guix System and simple-scan 3.34.1: ``` $ LANG=C guix describe Generation 5Nov 04 2019 14:24:15(current) guix bf7b08c repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: bf7b08c4fe7d14c25a83bde99f19eca1119d88ff ``` ## Additional information The scanner works. I can use it from a Trisquel 8 Live USB stick, which comes with Simple Scan. Running simple-scan from a terminal displays the following warnings: ``` $ LANG=C simple-scan (simple-scan:3953): Gtk-WARNING **: 18:42:44.193: Failed to register client: GDBus.Error:org.gnome.SessionManager.AlreadyRegistered: Unable to register client ``` --- https://sirgazil.bitbucket.io/
bug#35589: Scribus and GIMP: Clipped, non-resizable windows and pixelated icons
I can reproduce this bug in $ LANG=C guix describe Generation 5 Nov 04 2019 14:24:15 (current) guix bf7b08c repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: bf7b08c4fe7d14c25a83bde99f19eca1119d88ff Programs affected: GIMP 2.10.12 Pencil2D 0.6.4 Scribus 1.5.5 --- https://sirgazil.bitbucket.io/
bug#35584: CD/DVD does not work
Just to add that the problem is still present today on: $ LANG=C guix describe Generation 5 Nov 04 2019 14:24:15 (current) guix bf7b08c repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: bf7b08c4fe7d14c25a83bde99f19eca1119d88ff Also, I was able to use the drive successfully from a Trisquel 8 Live USB stick. So, at least I know the drive works. --- https://sirgazil.bitbucket.io/
bug#38062: Offloading + timeout + --keep-going leads to assertion failure
Hi, Ludovic Courtès skribis: > An offloaded build that times out in the presence of ‘--keep-going’ > leads to an assertion failure. To reproduce, set up offloading and run > something like this: > > $ guix build vim --no-substitutes --timeout=5 --keep-going > The following derivation will be built: >/gnu/store/5mnnym9xwl145s1b88aqfmrka810w9ci-vim-8.1.0644.drv > process 4277 acquired build slot '/var/guix/offload/localhost:/0' > load on machine 'localhost' is 0.04 (normalized: 0.01) > building /gnu/store/5mnnym9xwl145s1b88aqfmrka810w9ci-vim-8.1.0644.drv... > sending 1 store item (48 MiB) to 'localhost'... > exporting path > `/gnu/store/mlwyk5vcja0gqm20xxj8mwgf0fbqv8cz-vim-8.1.0644-checkout' > building of `/gnu/store/5mnnym9xwl145s1b88aqfmrka810w9ci-vim-8.1.0644.drv' > timed out after 5 seconds > build of /gnu/store/5mnnym9xwl145s1b88aqfmrka810w9ci-vim-8.1.0644.drv failed > View build log at > '/var/log/guix/drvs/5m/nnym9xwl145s1b88aqfmrka810w9ci-vim-8.1.0644.drv.bz2'. > guix build: error: corrupt input while restoring archive from # 7ff2769cdc40> > > > The last error is due to premature EOF on the client socket: the child > ‘guix-daemon’ process crashed, and thus ‘guix build’ gets EPIPE on its > client socket. Here’s how the ‘guix-daemon’ process crashed: > > $ tail -3 /var/log/guix-daemon.log > accepted connection from pid 4270, user ludo > accepted connection from pid 4277, user root > guix-daemon: nix/libstore/build.cc:3448: void nix::Worker::run(const Goals&): > Assertion `!settings.keepGoing || children.empty()' failed. Fixed by af73beeba1fc9effab60b11aea1d7ed8c24e7367. I’ll update the ‘guix’ package soonish. Ludo’.
bug#37967: guix environment -CN: Operation not permitted mounting host's /var/run/nscd
Ludovic Courtès (2019-11-04 18:07:05 +0100) wrote:
> Ivan Vilata i Balaguer skribis:
>
> > BTW, I ran that under strace and it looks like the read-only remount fails
> > after mounting `/var/run/nscd` in the new namespace has succeeded:
> >
> > $ strace -f unshare -mUr mount --bind -o ro /var/run/nscd /tmp/tt
> > […]
> > access("/run/mount", R_OK|W_OK) = -1 EACCES (Permission denied)
> > mount("/run/nscd", "/tmp/tt", 0x14c25b0, MS_RDONLY|MS_BIND, NULL) = 0
> > mount("none", "/tmp/tt", NULL, MS_RDONLY|MS_REMOUNT|MS_BIND, NULL) = -1
> > EPERM (Operation not permitted)
> > write(2, "mount: ", 7mount: ) = 7
> > write(2, "/tmp/tt: filesystem was mounted,"..., 89/tmp/tt: filesystem
> > was mounted, but any subsequent operation failed: Unknown error 5005.) = 89
> > write(2, "\n", 1
> > […]
>
> Weird, why does it remount it?
>
> What does:
>
> mount | grep /run
$ mount | grep /run
tmpfs on /run type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=1641444k,mode=755)
[…]
> returns? I just tried on a Debian 10 image with Linux 4.19.0 and /run
> is a tmpfs, which may be the reason why read-only bind-mounts fail (or
> at least there’s a bug in that area.)
>
> Anyway, below is a patch for you to test. Let me know how it goes. :-)
>
> Thanks,
> Ludo’.
I applied your patch on top of bf7b08c4, pulled Guix and did successfully
start `guix environment -CN`, with network support and all.
Cool! `:)`
> diff --git a/gnu/system/file-systems.scm b/gnu/system/file-systems.scm
> index 6cf6ccc53e..6cdb2b749d 100644
> --- a/gnu/system/file-systems.scm
> +++ b/gnu/system/file-systems.scm
> @@ -507,7 +507,8 @@ a bind mount."
> ;; XXX: On some GNU/Linux systems, /etc/resolv.conf is a
> ;; symlink to a file in a tmpfs which, for an unknown
> reason,
> ;; cannot be bind mounted read-only within the container.
> - (writable? (string=? file "/etc/resolv.conf"
> + (writable? (or (string=? file "/etc/resolv.conf")
> +(string=? file "/var/run/nscd")
>(cons "/var/run/nscd" %network-configuration-files)))
>
> (define (file-system-type-predicate type)
--
Ivan Vilata i Balaguer -- https://elvil.net/
bug#38062: Offloading + timeout + --keep-going leads to assertion failure
Hello,
An offloaded build that times out in the presence of ‘--keep-going’
leads to an assertion failure. To reproduce, set up offloading and run
something like this:
--8<---cut here---start->8---
$ guix build vim --no-substitutes --timeout=5 --keep-going
The following derivation will be built:
/gnu/store/5mnnym9xwl145s1b88aqfmrka810w9ci-vim-8.1.0644.drv
process 4277 acquired build slot '/var/guix/offload/localhost:/0'
load on machine 'localhost' is 0.04 (normalized: 0.01)
building /gnu/store/5mnnym9xwl145s1b88aqfmrka810w9ci-vim-8.1.0644.drv...
sending 1 store item (48 MiB) to 'localhost'...
exporting path
`/gnu/store/mlwyk5vcja0gqm20xxj8mwgf0fbqv8cz-vim-8.1.0644-checkout'
building of `/gnu/store/5mnnym9xwl145s1b88aqfmrka810w9ci-vim-8.1.0644.drv'
timed out after 5 seconds
build of /gnu/store/5mnnym9xwl145s1b88aqfmrka810w9ci-vim-8.1.0644.drv failed
View build log at
'/var/log/guix/drvs/5m/nnym9xwl145s1b88aqfmrka810w9ci-vim-8.1.0644.drv.bz2'.
guix build: error: corrupt input while restoring archive from #
--8<---cut here---end--->8---
The last error is due to premature EOF on the client socket: the child
‘guix-daemon’ process crashed, and thus ‘guix build’ gets EPIPE on its
client socket. Here’s how the ‘guix-daemon’ process crashed:
--8<---cut here---start->8---
$ tail -3 /var/log/guix-daemon.log
accepted connection from pid 4270, user ludo
accepted connection from pid 4277, user root
guix-daemon: nix/libstore/build.cc:3448: void nix::Worker::run(const Goals&):
Assertion `!settings.keepGoing || children.empty()' failed.
--8<---cut here---end--->8---
In Cuirass, this manifests itself with EPIPE while writing to the client
socket:
--8<---cut here---start->8---
2019-11-04T20:11:26 fatal: uncaught exception 'system-error' in
'restart-builds' fiber!
2019-11-04T20:11:26 exception arguments: ("fport_write" "~A" ("Broken pipe")
(32))
In ice-9/boot-9.scm:
829:9 5 (catch _ _ # ?)
751:25 4 (dispatch-exception 0 system-error ("fport_write" "~A" ?))
In cuirass/utils.scm:
183:8 3 (_ _ "fport_write" "~A" ("Broken pipe") (32))
In ice-9/boot-9.scm:
829:9 2 (catch #t # ?)
In cuirass/utils.scm:
184:22 1 (_)
In unknown file:
0 (make-stack #t)
ERROR: In procedure make-stack:
In procedure fport_write: Broken pipe
--8<---cut here---end--->8---
This bug is almost certainly a consequence of commit
ada9a19a2dca74feafcf24df1152abd685d4142f.
To be continued…
Ludo’.
bug#37999: clang fails to pickup/supply startfiles to ld
Thank you so much Mathieu for the patch! Marius: I believe this will only cause a rebuild for clang and not llvm, which means that it only affects ~30 packages. Perhaps this can go in master? Would love to know your thoughts. Cheers, Carl Dong cont...@carldong.me "I fight for the users" ‐‐‐ Original Message ‐‐‐ On Thursday, October 31, 2019 10:57 PM, Marius Bakke wrote: > Mathieu Othacehe m.othac...@gmail.com writes: > > > From f126146880e3904f39728313dfc10288b51fc23a Mon Sep 17 00:00:00 2001 > > From: Mathieu Othacehe m.othac...@gmail.com > > Date: Thu, 31 Oct 2019 15:05:54 +0100 > > Subject: [PATCH] gnu: clang-from-llvm: Fix set-glibc-file-names phase. > > > > - gnu/packages/llvm.scm (clang-from-llvm)[arguments]: Turn case on major > > version into a cond, so that newer versions of clang have the same > > behaviour as > > version 6 and 7. > > > > LGTM. It will have to wait for the next 'staging' window, though.
bug#38061: [minimal reproducer included] libstdc++ mutex references cause clang builds to fail
Hi all,
I'm having another issue with the clang toolchain right now and I've come up
with a minimal reproducer:
Given the following manifest.scm:
--8<---cut here---start->8---
(use-modules (gnu packages gcc)
(gnu packages linux)
(gnu packages llvm))
(packages->manifest
(list clang
(make-libstdc++ gcc)
linux-libre-headers))
--8<---cut here---end--->8---
And test.cpp:
--8<---cut here---start->8---
#include
#include
typedef std::once_flag once_flag;
int
main()
{
std::cout << "Hello, World\n";
}
--8<---cut here---end--->8---
If you invoke:
--8<---cut here---start->8---
guix environment --manifest=manifest.scm --container --pure -- clang++ test.cpp
--8<---cut here---end--->8---
The output looks like:
--8<---cut here---start->8---
test.cpp:4:14: error: no type named 'once_flag' in namespace 'std'
typedef std::once_flag once_flag;
~^
1 error generated.
--8<---cut here---end--->8---
In my original non-minimal build, other things in also cause compilation
errors, which seem odd to me.
Any help would be very much appreciated!
Cheers,
Carl Dong
cont...@carldong.me
"I fight for the users"
bug#37911: Cannot build a system with colord-service.
Hello, Pierre Langlois skribis: > I can confirm it's working for me on GNOME on my thinkpad! I can use the > night light settings and the laptop screen was detected in the "Color" > section of the settings. And I can see the colord daemon is running. Jack Hill skribis: > Yes, I can confirm that it works now. Awesome, closing! Thank you, Ludo’.
bug#26302: [website] translations
Hi,
"pelzflorian (Florian Pelz)" skribis:
> On Fri, Nov 01, 2019 at 03:54:42PM +0100, Ludovic Courtès wrote:
>> > + (modules '((guix build utils)
>> > +(ice-9 popen)))
>> > + (snippet
>> > + #~(begin
>> > + ;; the nginx source code is part of the module’s source
>> > + (format #t "decompressing nginx source code~%")
>> > + (call-with-output-file "nginx.tar"
>> > +(lambda (out)
>> > + (let ((pipe (open-pipe* OPEN_READ
>> > + #+(file-append gzip
>> > "/bin/gzip") "-cd"
>> > + #$(package-source nginx
>> > +(dump-port pipe out)
>> > +(unless (= (status:exit-val (close-pipe pipe)) 0)
>> > + (error "gzip decompress failed")
>> > + (invoke #+(file-append tar "/bin/tar") "xvf" "nginx.tar"
>> > + "--strip-components=1")
>> > + (delete-file "nginx.tar")
>>
>> I’d suggest doing it in a phase.
>
> This changes many things. :)
>
> With a phase, `guix build -S` would only return the source files of
> nginx-accept-language-module directly but not of statically linked
> nginx. I have added a further patch to doc/guix.texi warning of `guix
> build -S` not always returning complete and corresponding sources, see
> attachment.
>
> The good thing is that with a phase I no longer get an import cycle
> because I no longer need a reference to the tar package. So I put
> nginx-accept-language-module inside web.scm now and there is no need
> for a separate module.
Good!
>> > + (license (delete-duplicates
>> > +(cons license:bsd-2 ;license of nginx-mod-accept-language
>> > + (package-license nginx))) ;the module’s code is
>> > linked
>>
>> To avoid circular dependencies in top-level references, I suggest
>> copying the license of ‘nginx’ instead of writing (package-license
>> nginx).
>>
>
> I believe this is no longer an issue now that
> nginx-accept-language-module is in the same Guile module as nginx, is
> it?
You’re right: it’s no longer an issue.
>> > +++ b/gnu/packages/web-xyz.scm
>> > @@ -0,0 +1,175 @@
>> > +;;; GNU Guix --- Functional package management for GNU
>> > + TODO should I really add copyright lines for people I copied from??
>> > +;;; Copyright © 2014, 2015 Mark H Weaver
>> > +;;; Copyright © 2016 Tobias Geerinckx-Rice
>> > +;;; Copyright © 2017, 2018 Marius Bakke
>>
>> I don’t think you need to add these 3 lines here; the package definition
>> is yours.
>>
>
> This does not matter anymore after putting
> nginx-accept-language-module in the same Guile module file as nginx.
>
> In general though: IANAL but I have largely copied nginx’ configure
> phase, so at least Mark would surely have copyright on parts of it.
> However I believe copyright lines have limited legal significance
> anyway and adding these authorship lines in a file not added by Mark
> seems unreasonable.
Agreed.
>> […]
>> Perhaps “nginx-accept-language-module”, to match the name of the
>> upstream repo?
>>
>
> I agree. Arch (who have no package for nginx-accept-language-module)
> change their various nginx module package names to be more consistent,
> I think, but this is not necessary in Guix, I think.
For Guix the general rule is to follow upstream (info "(guix) Package
Naming").
> From b6da504736866bae655e2b4025729345e1ea19b7 Mon Sep 17 00:00:00 2001
> From: Florian Pelz
> Date: Sat, 2 Nov 2019 13:13:01 +0100
> Subject: [PATCH 1/3] doc: Add warning on the '--source' build option when
> linking statically.
>
> * doc/guix.texi (Additional Build Options): Add warning.
> ---
> doc/guix.texi | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/doc/guix.texi b/doc/guix.texi
> index da2423b422..30b69d8869 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -8328,6 +8328,12 @@ The returned source tarball is the result of applying
> any patches and
> code snippets specified in the package @code{origin} (@pxref{Defining
> Packages}).
>
> +Note that for statically linked packages, @command{guix build -S} will
> +@emph{not} return the complete and corresponding sources since these
> +would include the sources of statically linked dependencies. In this
> +case, when distributing sources for license compliance, you may want to
> +play it safe and use the following @code{--sources} option instead.
I don’t think this bit is necessary: ‘-S’ is documented to return “the
source of the package” and that’s exactly what it does; static
vs. dynamic linking is not a concern at this level, as I see it.
WDYT?
> From 21e6064f42defad1e2d35bbf95a4825fec9e4615 Mon Sep 17 00:00:00 2001
> From: Florian Pelz
> Date: Sat, 2 Nov 2019 12:43:47 +0100
> Subject: [PATCH 2/3] gnu: Add Nginx Accept Language module.
>
> * gnu/packages/web.scm (nginx-accept-language-module): New
bug#37967: guix environment -CN: Operation not permitted mounting host's /var/run/nscd
Saluton!
Ivan Vilata i Balaguer skribis:
> Ivan Vilata i Balaguer (2019-11-01 11:10:02 -0400) wrote:
>
>> Ludovic Courtès (2019-11-01 15:26:27 +0100) wrote:
>>
>> > […] What about a read-only bind mount like this:
>> >
>> > unshare -mUr mount --bind -o ro /var/run/nscd /tmp/tt
>> >
>> > ?
>>
>> This one looks more interesting:
>>
>> $ unshare -mUr mount --bind -o ro /var/run/nscd /tmp/tt && echo ok
>> mount: /tmp/tt: filesystem was mounted, but any subsequent operation
>> failed: Unknown error 5005.
>> $ echo $?
>> 32
>
> BTW, I ran that under strace and it looks like the read-only remount fails
> after mounting `/var/run/nscd` in the new namespace has succeeded:
>
> $ strace -f unshare -mUr mount --bind -o ro /var/run/nscd /tmp/tt
> […]
> access("/run/mount", R_OK|W_OK) = -1 EACCES (Permission denied)
> mount("/run/nscd", "/tmp/tt", 0x14c25b0, MS_RDONLY|MS_BIND, NULL) = 0
> mount("none", "/tmp/tt", NULL, MS_RDONLY|MS_REMOUNT|MS_BIND, NULL) = -1
> EPERM (Operation not permitted)
> write(2, "mount: ", 7mount: ) = 7
> write(2, "/tmp/tt: filesystem was mounted,"..., 89/tmp/tt: filesystem was
> mounted, but any subsequent operation failed: Unknown error 5005.) = 89
> write(2, "\n", 1
> […]
Weird, why does it remount it?
What does:
mount | grep /run
returns? I just tried on a Debian 10 image with Linux 4.19.0 and /run
is a tmpfs, which may be the reason why read-only bind-mounts fail (or
at least there’s a bug in that area.)
Anyway, below is a patch for you to test. Let me know how it goes. :-)
Thanks,
Ludo’.
diff --git a/gnu/system/file-systems.scm b/gnu/system/file-systems.scm
index 6cf6ccc53e..6cdb2b749d 100644
--- a/gnu/system/file-systems.scm
+++ b/gnu/system/file-systems.scm
@@ -507,7 +507,8 @@ a bind mount."
;; XXX: On some GNU/Linux systems, /etc/resolv.conf is a
;; symlink to a file in a tmpfs which, for an unknown reason,
;; cannot be bind mounted read-only within the container.
- (writable? (string=? file "/etc/resolv.conf"
+ (writable? (or (string=? file "/etc/resolv.conf")
+(string=? file "/var/run/nscd")
(cons "/var/run/nscd" %network-configuration-files)))
(define (file-system-type-predicate type)
bug#38045: Video Rendering Issues on IceCat
Earlier, I wrote: > I have a hypothesis of what might have happened here. > > Since the upgrade to version 68, the IceCat package in GNU Guix is no > longer using our system ffmpeg. Sorry, I forgot to mention why I think this might be relevant. The reason is because upstream Firefox adopts the approach of downloading certain codecs in pre-compiled form, to avoid certain patent concerns. That's not necessary when using Guix's system ffmpeg library, but maybe Mozilla rigged the bundled ffmpeg library to avoid including support for those codecs. Mark
bug#38045: Video Rendering Issues on IceCat
Hi Chris! > Are you actively working on this bug? If you are not, then as a > matter > of etiquette, I think it would be best not to change its severity. I am not. Sorry about that. I read the control-debbugs help page and it mentions that criteria for 'important' is unusablity of the program. So I presumed that anyone can change the serverity level. No worries, moving forward, I refrain from changing it. :-) > Can you provide specific example URLs that do not work? https://playedvid.com/whsfksz0zw8c https://streamp1ay.me/yb4kihqvq8c9 > Did you try installing the gst-plugins-* packages? I observed > similar > behavior in the past. I believe I resolved it by installing the > right > gst-plugins-* packages, which is probably one of these: > > gst-plugins-base > gst-plugins-good > gst-plugins-bad > gst-plugins-ugly Yes, I have them installed. > You might also have to adjust some settings in about:config. I can't > remember if I did that or not. Video in IceCat generally works, but > depending on the video you might need to jump through some extra > hoops > to make it happen. I see. It was just weird that this is issue started after the upgrade. Before that, all was fine. Regards, RG.
bug#38046: Font Issues in GNOME
>> After installing fonts you may have to refresh the font cache to use >> them in applications. The same applies when applications installed >> via Guix do not seem to find fonts. To force rebuilding of the font >> cache run ‘fc-cache -rv’. It worked. Thank you :-) Regards, RG.
