bug#63255: Firefox crashes when triggering file dialog open

[Steven Roose]

Whenever I right click and "safe image as" or when I try to do a file 
upload, firefox segfaults.



This is an excerpt trying to save google's logo to disk:


** Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion 
failed (error == NULL): Failed to load 
/run/current-system/profile/share/icons/Adwaita/16x16/status/image-missing.png: 
Unrecognized image file format (gdk-pixbuf-error-quark, 3) Bail out! 
Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed 
(error == NULL): Failed to load 
/run/current-system/profile/share/icons/Adwaita/16x16/status/image-missing.png: 
Unrecognized image file format (gdk-pixbuf-error-quark, 3) Redirecting 
call to abort() to mozalloc_abort

bug#56005: bug#61642: intermittent write_wait_fd error when updating

[Ludovic Courtès]

Christopher Baines  skribis:

> Simon Tournier  writes:
>
>> Hi,
>>
>> On Mon, 20 Feb 2023 at 11:46, Christopher Baines  wrote:
>>
>>> It's not, since it relates to code in the (guix substitutes) module.
>>
>> Do you mean that if "https://substitutes.nonguix.org; is incorrectly
>> configured, then the code in (guix substitutes) should handle the
>> error instead of crash with a backtrace?
>
> No, but to answer your question, yes.
>
> I don't think this is a server side code/configuration issue. Also see
> this older bug for the same issue https://issues.guix.gnu.org/56005

The Guile-GnuTLS change you submitted in
 may well fix this
issue.

We have yet to put out a new Guile-GnuTLS release, but we should keep an
eye on it.

Ludo’.

bug#62163: Suppress logging shepherd evaluation in mcron.log

[Ludovic Courtès]

Hi,

Bruno Victal  skribis:

 While it does work for expunging them from mcron log, I noticed that
 these lines are also polluting /var/log/messages and the snippet above
 doesn't handle that.
 Is there perhaps something else I'm missing?
>>>
>>> Nope, you cannot prevent them from ending up in /var/log/messages; they
>>> are purposefully logged.
>
> Perhaps we could have a “low-noise” way to query for running services? (or 
> non modifying actions done on shepherd)
> Filling /var/log/messages with messages of (IMO) dubious value seems 
> counterproductive.

The reasoning was that “eval is evil”, as we know :-), so we’d rather
log uses of ‘herd eval root’.

Ludo’.

bug#63050: Reducing the closure size of Graphviz

[Ludovic Courtès]

Hey!

Ludovic Courtès  skribis:

> This is apparently coming from Graphviz:
>
> $ guix graph --path guix libx11
> guix@1.4.0-5.286cdf0
> graphviz@2.49.0
> libx11@1.7.3.1
> $ guix graph --path guix libxt
> guix@1.4.0-5.286cdf0
> graphviz@2.49.0
> libxaw@1.0.14
> libxt@1.2.1
>
> Surprising to me, but apparently it’s been this way from the start,
> commit b1b07d72c755ea314fb0c8333cd88293ee504ce4 (2013!).
>
> Maybe these are optional dependencies?

All the X libraries can be seen in the output of:

  ldd $(guix build graphviz |grep -v 'doc$')/lib/graphviz/libgvplugin_xlib.so

I haven’t checked but I suppose that’s used by ‘xdot’.

We can get an X11-free Graphviz like so:

diff --git a/gnu/packages/graphviz.scm b/gnu/packages/graphviz.scm
index 26ee96afd4..3a5d33e662 100644
--- a/gnu/packages/graphviz.scm
+++ b/gnu/packages/graphviz.scm
@@ -94,16 +94,12 @@ (define-public graphviz
   (string-append extdir
  "/libgv_guile.so"
 (inputs
- (list libxrender
-   libx11
-   gts
+ (list gts
gd
guile-3.0;Guile bindings
-   pango
fontconfig
freetype
libltdl
-   libxaw
expat
libjpeg-turbo
libpng))

The closure size reduction is substantial:

--8<---cut here---start->8---
$ ./pre-inst-env guix size graphviz | tail -1
total: 183.6 MiB
$ guix size graphviz | tail -1
total: 242.3 MiB
--8<---cut here---end--->8---

But I suspect we’d still need the full-blown variant for things like
xdot.

Ludo’.

bug#63252: Graphviz uses bundled copy of libltdl

[Ludovic Courtès]

As of 44d70440944aa47e5f37493346e560f38907d777, Graphviz uses a bundled
copy of libltdl (GNU Libtool):

--8<---cut here---start->8---
make[3]: Entering directory 
'/tmp/guix-build-graphviz-7.0.1.drv-0/graphviz-7.0.1/libltdl'
  CC   libltdlc_la-lt__alloc.lo
  CC   libltdlc_la-lt_dlloader.lo
  CC   libltdlc_la-ltdl.lo
  CC   libltdlc_la-lt_error.lo
  CC   libltdlc_la-slist.lo
  CC   lt__strl.lo
  CC   loaders/dlopen.lo
  CC   loaders/libltdlc_la-preopen.lo
  CCLD dlopen.la
ar: `u' modifier ignored since `D' is the default (see `U')
  CCLD libltdlc.la
ar: `u' modifier ignored since `D' is the default (see `U')
make[3]: Leaving directory 
'/tmp/guix-build-graphviz-7.0.1.drv-0/graphviz-7.0.1/libltdl'
--8<---cut here---end--->8---

We should make sure it uses our own copy instead.

Ludo’.

bug#63050: "guix pull" requires graphical libraries

[Ludovic Courtès]

Hi!

Simon Tournier  skribis:

> On mar., 25 avril 2023 at 23:48, Ludovic Courtès  wrote:
>
>> Maybe these are optional dependencies?
>
> Why does Guix require ’graphviz’ in the first place?

It uses it to build images in the manual.

Ludo’.

bug#63178: shepherd 0.10.0-rc1 riscv64 build failure

[Ludovic Courtès]

Hey Efraim,

Efraim Flashner  skribis:

> I reran it and got a different test failure

> FAIL: tests/starting-status.sh

Could you retry from the ‘master’ branch?  I pushed a couple of commits
since your message that probably fixed this one.

Thanks a lot for testing!

Ludo’.

bug#47949: Failed to produce output path for guix-package-cache

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer  skribis:

> $ guix pull
> [...]
> \builder for 
> `/gnu/store/zliavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv' failed 
> to produce output path 
> `/gnu/store/0m2c2zrphqpmfhjb60k85yhfq704ay5r-guix-package-cache'
> la compilation de 
> /gnu/store/zliavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv a échoué
> conseil : This usually indicates a bug in one of the channels you are pulling 
> from, or some incompatibility
> among them.  You can check the build log and report the issue to the channel 
> developers.
>
> The channels you are pulling from are: guix sfl-packages.
>
> Vous trouverez le journal de compilation dans « 
> /var/log/guix/drvs/zl/iavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv ».
> cannot build derivation 
> `/gnu/store/v5rszp4m1vv7zf20vrb1sghi4528d40j-profile.drv': 1 dependencies 
> couldn't be built
> guix pull: erreur : build of 
> `/gnu/store/v5rszp4m1vv7zf20vrb1sghi4528d40j-profile.drv' failed
>
> $ tail 
> /var/log/guix/drvs/zl/iavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv
>   1694:48  4 (thunk)
> In sfl/packages/sflvault.scm:
> 75:29  3 (propagated-inputs #)
> In ice-9/boot-9.scm:
>   1685:16  2 (raise-exception _ #:continuable? _)
>   1780:13  1 (_ #< components: (#)
> In unknown file:
>0 (backtrace #)
>
> (exception unbound-variable (value #f) (value "Unbound variable: ~S")
> (value (python-pycrypto)) (value #f))

Isn’t the advice above correct?  The unbound-variable error appears to
come from sfl/packages/sflvault.scm, not from the ‘guix’ channel.

HTH,
Ludo’.

bug#63068: What I was trying to do

[Julian Flake]

Hi,


$ guix shell --with-version=maven=3.9.1 maven


Just to be sure, are you using the Guix where you applied the 
patch?


No, the proposed patch is just an untested guess. I didn't test 
the patch yet, because I didn't manage to build (make) my guix 
working copy yet.


Best Regards,
Julian

On Wed, May 03 2023, Simon Tournier wrote:


Hi,

On Fri, 28 Apr 2023 at 22:36, Julian Flake 
 wrote:



$ guix shell --with-version=maven=3.9.1 maven


Just to be sure, are you using the Guix where you applied the 
patch?


I mean, from the Guix repository where you applied you patch, I 
am

expecting:

$ ./pre-inst-env guix shell --with-version=maven=3.9.1 maven

If that’s the case, it means the issue is elsewhere. :-)

Cheers,
simon



--
Dipl.-Inf. Julian Flake

Universität Koblenz
Fachbereich Informatik
Institut für Softwaretechnik
Postfach 20 16 02 | D-56016 Koblenz

Tel.: +49 261 287 2787
E-Mail: fl...@uni-koblenz.de
Website: https://www.uni-koblenz.de/~flake

bug#63068: What I was trying to do

[Simon Tournier]

Hi,

On Fri, 28 Apr 2023 at 22:36, Julian Flake  wrote:

> $ guix shell --with-version=maven=3.9.1 maven

Just to be sure, are you using the Guix where you applied the patch?

I mean, from the Guix repository where you applied you patch, I am
expecting:

$ ./pre-inst-env guix shell --with-version=maven=3.9.1 maven

If that’s the case, it means the issue is elsewhere. :-)

Cheers,
simon

bug#63024: bug#62334: bug#63024: Crash during `guix import pypi -r'

[Simon Tournier]

Hi Ludo,

On Wed, 03 May 2023 at 11:04, Ludovic Courtès  wrote:

> diff --git a/libguile/posix.c b/libguile/posix.c
> index 3adc743c4..2d55d985c 100644
> --- a/libguile/posix.c
> +++ b/libguile/posix.c

Does it mean patch the current Guile or a new release of Guile?


Cheers,
simon

bug#47949: Failed to produce output path for guix-package-cache

[Simon Tournier]

Hi Maxim,

On Fri, 28 Apr 2023 at 12:47, Maxim Cournoyer  wrote:

> I think I may have experienced this issue

Well, I think it’s different from the issue reported by Vagrant; IIUC,
something related to mixed branches and/or locations of repository from
where Vagrant pulled.

Instead, your issue seems related to channels.

>the symptoms:
>
> --8<---cut here---start->8---
> $ guix pull
> [...]
> \builder for 
> `/gnu/store/zliavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv' failed 
> to produce output path 
> `/gnu/store/0m2c2zrphqpmfhjb60k85yhfq704ay5r-guix-package-cache'
> la compilation de 
> /gnu/store/zliavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv a échoué
> conseil : This usually indicates a bug in one of the channels you are pulling 
> from, or some incompatibility
> among them.  You can check the build log and report the issue to the channel 
> developers.
>
> The channels you are pulling from are: guix sfl-packages.
>
> Vous trouverez le journal de compilation dans « 
> /var/log/guix/drvs/zl/iavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv ».
> cannot build derivation 
> `/gnu/store/v5rszp4m1vv7zf20vrb1sghi4528d40j-profile.drv': 1 dependencies 
> couldn't be built
> guix pull: erreur : build of 
> `/gnu/store/v5rszp4m1vv7zf20vrb1sghi4528d40j-profile.drv' failed
>
> $ tail 
> /var/log/guix/drvs/zl/iavnqgx3jxp8yc44nn1y34b3bjvlcw-guix-package-cache.drv
>   1694:48  4 (thunk)
> In sfl/packages/sflvault.scm:
> 75:29  3 (propagated-inputs #)
> In ice-9/boot-9.scm:
>   1685:16  2 (raise-exception _ #:continuable? _)
>   1780:13  1 (_ #< components: (#)
> In unknown file:
>0 (backtrace #)
>
> (exception unbound-variable (value #f) (value "Unbound variable: ~S")
> (value (python-pycrypto)) (value #f))
>
> $ guix time-machine --commit=9ed65e6af77893b658a7159b091b5002892c2f95 -- show 
> python-pycrypto
> name: python-pycrypto
> version: 2.6.1
> [...]
> --8<---cut here---end--->8---
>
> The problematic channel is pinned via an inferior at the above commit,
> so I'm surprised the error mentions python-pyrypto is unbound (it exists
> at least, according to the above time-machine invocation).

Could you share the link of the other channel, if it’s public?


Cheers,
simon

bug#62698: bind:utils

[Brian Cully via Bug reports for GNU Guix]

Maxim Cournoyer  writes:

Thanks for finding the problem.  Should we leave this bug open 
until
specification->package+output is properly documented in our 
manual, with
an example?  If yes, would you like to try your hand at adding 
it?


I've looked at this briefly, and can't figure out a good place to 
document this (I'm also not particularly good with TexInfo).


I'm okay with closing the bug. Though I will say that I think this 
procedure is a bit of a foot-gun. Multiple value returns are 
always kind of weird, and in this particular case I don't see the 
value at all; the only reason to use 
‘specification->package+output’ would be to get both the package 
and the output, so the minor advantages of multi-value returns are 
obviated. On top of that, does this even get used outside of 
system/home definitions? And in those places you always want a 
list.


I realize a lot of code uses the current semantics, so changing 
them would be extremely difficult at this late stage. It's worth 
thinking about adding another procedure that does the expected 
thing (returning a list of package and output), IMHO, and 
transitioning over to that.


-bjc

bug#63247: guix weather should report on all substitute servers configured

[Steven Roose]

Currently guix weather only reports on the two default guix substitute 
servers. When you have configured other servers in your guix-daemon 
config, I think it would be expected behavior that guix weather also 
checks these for the given package.


Currently using guix weather with an already-configured substitute URL 
requires manually passing that URL in --substitute-urls=.

bug#62698: bind:utils

[Maxim Cournoyer]

Hi,

Brian Cully  writes:

> Αντώνιος Τσώλης  writes:
>
>> Well, I use this:
>>
>>   (packages
>>  (append(map specification->package+output
>>   '("bind:utils" ... ))
>>  %base-packages))
>>
>> But I am new to scheme/guile/guix, so maybe I do something
>> wrong. Anyway, thanks for confirming that it works on your
>> side. It's probably an issue with my configuration. :)
>
> I suspected this was the problem. You really do need to use:
>
> (map (compose list specification->package+output)
> '("bind:utils"))
>
> Because ‘specification->package+output’ returns two values, and you'll
> need to combine those into a list for the second value (the ‘utils’
> output) to be seen.

Thanks for finding the problem.  Should we leave this bug open until
specification->package+output is properly documented in our manual, with
an example?  If yes, would you like to try your hand at adding it?

-- 
Thanks,
Maxim

bug#62985: [GNOME] MTP mounts in Nautilus doesn't work out of the box

[Maxim Cournoyer]

Hi,

Maxim Cournoyer  writes:

> Hi,
>
> Csepp  writes:
>
>> Maxim Cournoyer  writes:
>>
>>> Hi,
>>>
>>> Connecting an Android phone via USB to a Guix System that has GNOME
>>> installed, and selecting the transfer mode to be USB/media, I'd expect
>>> it to appear in Nautilus, the same it does in other mainstream
>>> distributions.  Instead, nothing happens.
>>>
>>> In Fedora, for example, the device appears in the left panel of
>>> Nautilus, and a 'gvfsd-mtp' process starts running.  In Guix System,
>>> there's no 'gvfsd-mtp' process running, although a
>>> 'gvfs-mtp-volume-monitor' process is running.
>>>
>>> To be investigated.
>>
>> I've also experienced this with plain USB block devices like some of my
>> microSD adapters.  No idea what causes it.  Sometimes it shows up in
>> Nautilus for a split second and then disappears.
>> Weirdly enough, running fdisk -l on the block device makes it show up in
>> Nautilus.
>>
>> But it should be noted that our Nautilus version is behind by two versions.
>
> Did you have a chance to update your system following the core-updates
> merge yet?  At least on a fresh install it was working correctly now on
> one machine, where it wasn't before.

I tried it again on my own machine, but with a different device (old HTC
U Play phone), and it didn't work.  I wonder what suddenly caused it to
work on a different machine.

-- 
Thanks,
Maxim

bug#63198: cups-service-type uses PAM-enabled 'cups' by default which prevents authentication

[Maxim Cournoyer]

Hi,

Maxim Cournoyer  writes:

> Hi,
>
> Today I encountered an issue where after re-installing a Guix System, I
> couldn't add a new printer anymore.  Any CUPS client (including the
> trusty localhost:631 HTTP page) would loop on authenticating my user.
>
> After consulting the logs and finding this kind of line:
>
> pam_authenticate() returned 7 (Authentication failure)
>
> I started looking at our PAM configuration for CUPS, but we currently
> have none, which is probably the issue.  Using 'cups-minimal' instead of
> cups (which is built with linux-pam) solves the issue, as the 'cups'
> value provided to the  record.

Fixed using the above strategy in 6bc3e3f ("services: cups: Use
cups-minimal to avoid PAM authentication.")

-- 
Thanks,
Maxim

bug#62334: bug#63024: Crash during `guix import pypi -r'

[Ludovic Courtès]

Hey,

Ludovic Courtès  skribis:

> Looks like we shoudn’t dup(4, 1) in the child process, because 4 is the
> other end of our sleep pipe.  :-)

How about this patch, Josselin?

Ludo’.

diff --git a/libguile/posix.c b/libguile/posix.c
index 3adc743c4..2d55d985c 100644
--- a/libguile/posix.c
+++ b/libguile/posix.c
@@ -1388,11 +1388,27 @@ do_spawn (char *exec_file, char **exec_argv, char **exec_env,
 }
 
   /* Move the fds out of the way, so that duplicate fds or fds equal
- to 0, 1, 2 don't trample each other */
+ to 0, 1, 2 don't trample each other.  Since 'system*' might give
+ us -1 for IN, OUT, or ERR, open /dev/null when that's the case.  */
+
+  if (in < 0)
+posix_spawn_file_actions_addopen (, fd_slot[0],
+  "/dev/null", O_RDONLY | O_CLOEXEC, 0);
+  else
+posix_spawn_file_actions_adddup2 (, in, fd_slot[0]);
+
+  if (out < 0)
+posix_spawn_file_actions_addopen (, fd_slot[1],
+  "/dev/null", O_WRONLY | O_CLOEXEC, 0);
+  else
+posix_spawn_file_actions_adddup2 (, out, fd_slot[1]);
+
+  if (err < 0)
+posix_spawn_file_actions_addopen (, fd_slot[2],
+  "/dev/null", O_WRONLY | O_CLOEXEC, 0);
+  else
+posix_spawn_file_actions_adddup2 (, err, fd_slot[2]);
 
-  posix_spawn_file_actions_adddup2 (, in, fd_slot[0]);
-  posix_spawn_file_actions_adddup2 (, out, fd_slot[1]);
-  posix_spawn_file_actions_adddup2 (, err, fd_slot[2]);
   posix_spawn_file_actions_adddup2 (, fd_slot[0], 0);
   posix_spawn_file_actions_adddup2 (, fd_slot[1], 1);
   posix_spawn_file_actions_adddup2 (, fd_slot[2], 2);
diff --git a/test-suite/tests/posix.test b/test-suite/tests/posix.test
index d5cf47cda..18dad8902 100644
--- a/test-suite/tests/posix.test
+++ b/test-suite/tests/posix.test
@@ -374,7 +374,17 @@
 (system* "sh" "-c" "echo bong >&2"
 
   (and (zero? (status:exit-val status))
-   (call-with-input-file file get-string-all)
+   (call-with-input-file file get-string-all
+
+  (pass-if-equal "https://bugs.gnu.org/63024;
+  0
+(if (file-exists? "/proc/self/fd/0")  ;on GNU/Linux?
+(parameterize ((current-output-port (%make-void-port "w0")))
+  (system* "guile" "-c"
+   (object->string
+'(exit (string=? "/dev/null"
+ (readlink "/proc/self/fd/1"))
+(throw 'unresolved
 
 ;;
 ;; spawn