bug#58285: secrets crashes when unlocking database

[kiasoc5 via Bug reports for GNU Guix]

On Mon, Oct 10 2022, 01:21:36 AM -0400
Maxim Cournoyer  wrote:

> I could reproduce that; I first updated to version 7, but I had an
> unrelated problem with otp something.  Unfortunately I'm not sure
> what's wrong.  Would you have the time to open an issue with
> upstream?  You'll need an account with their gitlab here:
> https://gitlab.gnome.org/World/secrets.
> 

Reported at https://gitlab.gnome.org/World/secrets/-/issues/434

-- 

bug#57878: Minimal reproducible setup

[Liliana Marie Prikler]

Am Donnerstag, dem 13.10.2022 um 12:31 +0300 schrieb Max Brieiev:
> > I think this reasoning really falls flat in presence of any non-
> > Emacs package manager.  Like, obviously wanting to natively compile
> > packages managed by (dpkg, rpm, pacman, emerge, guix), but not
> > natively compiling a random elisp script you just downloaded from
> > the web is a legitimate use case.
> 
> If security is a concern, you should not load random Elisp in the
> first place. It is much easier to just directly run harmful elisp,
> then to exploit native compiler, which stays silent until after you
> evaluate some (possibly harmful) elisp.
The nature of compiled code being compiled makes it much easier to
exploit, however.  Assume you have a genuine dash.el, but a malicious
person delivers you a dash.eln with some backdoor.  Unless you know how
to read x86 assembly, you won't debug the latter, whereas you could
reasonably find the former if you're an Elisp hacker.

This is typically not a concern for Guix, where the challenge mechanism
provides tools to highlight that something is going wrong, but it might
be a concern for traditional distros.  Then again, the same applies to
bytecode too, and here as well the solution is to typically use a
trusted package manager.

Cheers

bug#58452: openldap fails to cross-compile to aarch64 (strip errors) (was: guix pack cross-compile failed to build docker img of openldap for aarch64)

[Dominik Riva via Bug reports for GNU Guix]

--- Original Message ---
On Wednesday, October 12th, 2022 at 14:32, Maxime Devos 
 wrote:


> retitle 58452 openldap fails to cross-compile to aarch64 (strip errors)
> thanks
> 

> "guix pack" and Docker seem unrelated here, rather it seems to be
> regular cross-compilation bug to me that could presumably be reproduced
> with "guix build openldap --target=aarch64-linux-gnu".
> 

> Greetings,
> Maxime.

I can confirm that "guix build openldap --target=aarch64-linux-gnu" results in 
the exact same error.

Regards,
Dominik

publickey - driva@protonmail.com - 0x53958C99.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

bug#58497: opam import doesn't work with ocaml_intrinsics among others

[Julien Lepiller]

(beautify-description #f _)

Seems to be the cause. Yet, there is a description. Maybe parsing ends a bit 
too soon?

Le 13 octobre 2022 18:07:08 GMT+02:00, Csepp  a écrit :
>The error might not be the same for others, I have a slightly patched
>opam->guix-package function.
>
>guix import opam ocaml_intrinsics
>Backtrace:
>In ice-9/boot-9.scm:
>  1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
>In unknown file:
>   9 (apply-smob/0 #)
>In ice-9/boot-9.scm:
>724:2  8 (call-with-prompt _ _ #)
>In ice-9/eval.scm:
>619:8  7 (_ #(#(#)))
>In guix/ui.scm:
>   2263:7  6 (run-guix . _)
>  2226:10  5 (run-guix-command _ . _)
>In guix/scripts/import.scm:
>92:11  4 (guix-import . _)
>In guix/scripts/import/opam.scm:
>   105:24  3 (guix-import-opam . _)
>In guix/import/opam.scm:
>   385:24  2 (opam->guix-package _ #:repo _ #:version _)
>In guix/import/utils.scm:
>   290:27  1 (beautify-description #f _)
>In unknown file:
>   0 (string-trim-both #f # # #)
>
>ERROR: In procedure string-trim-both:
>In procedure string-trim-both: Wrong type argument in position 1 (expecting 
>string): #f
>
>
>

bug#58497: opam import doesn't work with ocaml_intrinsics among others

[Csepp]

The error might not be the same for others, I have a slightly patched
opam->guix-package function.

guix import opam ocaml_intrinsics
Backtrace:
In ice-9/boot-9.scm:
  1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
   9 (apply-smob/0 #)
In ice-9/boot-9.scm:
724:2  8 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8  7 (_ #(#(#)))
In guix/ui.scm:
   2263:7  6 (run-guix . _)
  2226:10  5 (run-guix-command _ . _)
In guix/scripts/import.scm:
92:11  4 (guix-import . _)
In guix/scripts/import/opam.scm:
   105:24  3 (guix-import-opam . _)
In guix/import/opam.scm:
   385:24  2 (opam->guix-package _ #:repo _ #:version _)
In guix/import/utils.scm:
   290:27  1 (beautify-description #f _)
In unknown file:
   0 (string-trim-both #f # # #)

ERROR: In procedure string-trim-both:
In procedure string-trim-both: Wrong type argument in position 1 (expecting 
string): #f

bug#58495: opam import generates wrong check phase

[Csepp]

Julien Lepiller  writes:

> Maybe this could be fixed in the dune-build-system?
>
Actually, good call.  I'll look into it, unless you want to take a stab
at it.

bug#58495: opam import generates wrong check phase

[Julien Lepiller]

Maybe this could be fixed in the dune-build-system?

Le 13 octobre 2022 17:03:43 GMT+02:00, Csepp  a écrit :
>So I'm working on building MirageOS unikernels with Guix, which means
>using the OPAM importer *a lot*, which unearths some very Fun TM bugs.
>Here is the first one:
>
>guix import opam mirage-clock
>
>The correct check phase is this:
>```
>(replace 'check
>   (lambda* (#:key tests? #:allow-other-keys)
> (invoke "dune" "runtest" "--release")))
>```
>
>
>

bug#58495: opam import generates wrong check phase

[Csepp]

So I'm working on building MirageOS unikernels with Guix, which means
using the OPAM importer *a lot*, which unearths some very Fun TM bugs.
Here is the first one:

guix import opam mirage-clock

The correct check phase is this:
```
(replace 'check
   (lambda* (#:key tests? #:allow-other-keys)
 (invoke "dune" "runtest" "--release")))
```

bug#58485: [shepherd] Restarting guix-publish fails

[Liliana Marie Prikler]

Am Donnerstag, dem 13.10.2022 um 13:35 +0200 schrieb Lars-Dominik
Braun:
> Hi Liliana,
> 
> > Shouldn't [1] address this very issue?
> > [1]
> > http://git.savannah.gnu.org/cgit/guix.git/commit/?id=2a37f174becbafd70591f6eb1d98493c5c1df0e2
> no, if the process is running make-systemd-destructor is just an
> alias for make-kill-destructor. So it does not matter which one we
> use in this case.
Ahh, so the issue is that shepherd waits neither for the process to be
actually killed nor for the socket to become available, isn't it?

bug#55360: bug#58375: Installer does not show what is being downloaded

[Ludovic Courtès]

Hi!

Mathieu Othacehe  skribis:

>> I’m not sure it’s a good idea for ‘guix system init’: we’d be logging
>> mostly progress bars, package names, and the likes to syslog—not super
>> useful.  So I’d suggest not capturing stdout of ‘guix system init’.
>
> In the bug report https://issues.guix.gnu.org/57983 capturing the 'guix
> system init' output highlighted a "guix substitute" crash. So it does
> seem like a useful mechanism, especially while 56005 is still open.

Hmm right.   is not
installer-specific, so it’s annoying that we have to prepare for that,
but we can’t deny such bugs exist and prevent installation.

If we really want to capture the output of ‘guix system init’, then we
need to open a pseudo-terminal with ‘openpty’ & co. instead of ‘pipe’ in
‘run-external-command-with-handler’.  That may be relatively easy
actually.

But then I think this should be used sparsely, maybe only for ‘guix
system init’.

> Now the current situation is also not really acceptable.

Nope.  :-)

> What about hiding the "guix system init" output completely and display
> a progress bar page instead?

I don’t think we can do that (with grafts, only part of the build plan
is known upfront so we don’t even know beforehand how many items will be
built/downloaded).

Also, I think there are two strategies: either we run ‘guix system
init’, in which case we let its output through, or we integrate ‘guix
system init’ functionality in the installer so we have more fine-grain
control over the process, in which case we could also have more
graphical output or something.

That second solution is a lot of work, though.

Thanks,
Ludo’.

bug#58485: [shepherd] Restarting guix-publish fails

[Lars-Dominik Braun]

Hi Liliana,

> Shouldn't [1] address this very issue?
> [1]
> http://git.savannah.gnu.org/cgit/guix.git/commit/?id=2a37f174becbafd70591f6eb1d98493c5c1df0e2
no, if the process is running make-systemd-destructor is just an alias
for make-kill-destructor. So it does not matter which one we use in this case.

Lars

bug#53480: i686 ISO image from CI is installing an x86_64 system

[Mathieu Othacehe]

Hello,

Fixed with: 84b4216e988ec6791b6df8f894d5a01cbf2e5fa5.

Thanks,

Mathieu

bug#58485: [shepherd] Restarting guix-publish fails

[Liliana Marie Prikler]

Am Donnerstag, dem 13.10.2022 um 09:51 +0200 schrieb Lars-Dominik
Braun:
> The obvious explanation would be that stopping does not wait for the
> process to actually exit. make-kill-destructor does not waitpid it
> seems and 'running is set unconditionally to #f after 'stop has
> finished.
Shouldn't [1] address this very issue?

[1]
http://git.savannah.gnu.org/cgit/guix.git/commit/?id=2a37f174becbafd70591f6eb1d98493c5c1df0e2

bug#57232: [installer] ENTER in guided partitioner destroys partition table

[Mathieu Othacehe]

Hey,

> Fixes: .
>
> * gnu/installer/newt/partition.scm (run-label-confirmation-page): New
> procedure.
> (run-label-page): Call the above procedure before proceeding.

I pushed a slightly edited version of this patch.

Thanks,

Mathieu

bug#58485: [shepherd] Restarting guix-publish fails

[Lars-Dominik Braun]

Hi,

it seems that `herd restart guix-publish` stopped working after the
introduction of socket activation into shepherd. This is a problem,
because I restart guix-publish automatically after unattended-upgrades. It
fails with the following error for me:

---snip---
Backtrace:
   7 (primitive-load "/gnu/store/7xrg2sbb529ki6hv99n27svg0fi?")
In ice-9/boot-9.scm:
724:2  6 (call-with-prompt ("prompt") # ?)
  1752:10  5 (with-exception-handler _ _ #:unwind? _ # _)
In ice-9/eval.scm:
619:8  4 (_ #(#(#)))
In ice-9/boot-9.scm:
   260:13  3 (for-each # _)
In gnu/services/herd.scm:
168:4  2 (invoke-action guix-publish restart () #)
176:7  1 (failure)
In ice-9/boot-9.scm:
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
ERROR:
  1. :
  service: guix-publish
  action: start
  key: system-error
  args: ("bind" "~A" ("Address already in use") (98))
---snap---

Note that due to the socket activation you must visit the URL at least
once to start up the guix-publish process. Otherwise a restart will
work fine. It also works fine the second time I invoke `herd restart
guix-publish`, because `guix-publish` is dead by that time.

Looking at an strace shepherd is indeed trying to kill `guix-publish`
and re-bind to the same address:

---snip---
1 read(23, "(shepherd-command (version 0) (action restart) (service 
guix-publish) (arguments ()) (directory \"/root\"))", 1024) = 105
1 getpgid(18096)= 18096
1 getpgid(0)= 0
1 kill(-18096, SIGTERM) = 0
1 newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0444, 
st_size=2298, ...}, 0) = 0
1 write(17, "shepherd[1]: Service guix-publish has been stopped.\n", 52) = 
52
1 socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 36
1 setsockopt(36, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
1 bind(36, {sa_family=AF_INET, sin_port=htons(8082), 
sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EADDRINUSE (Address already in use)
1 write(23, "(reply (version 0) (result #f) (error (error (version 0) 
action-exception start guix-publish system-error (\"bind\" \"~A\" (\"Address 
already in use\") (98 (messages (\"Service guix-publish has been 
stopped.\")))", 208) = 208
1 close(23)
---snap---

The obvious explanation would be that stopping does not wait for the
process to actually exit. make-kill-destructor does not waitpid it seems
and 'running is set unconditionally to #f after 'stop has finished.

Cheers,
Lars

bug#55360: bug#58375: Installer does not show what is being downloaded

[Mathieu Othacehe]

Hey Ludo!

> I’m not sure it’s a good idea for ‘guix system init’: we’d be logging
> mostly progress bars, package names, and the likes to syslog—not super
> useful.  So I’d suggest not capturing stdout of ‘guix system init’.

In the bug report https://issues.guix.gnu.org/57983 capturing the 'guix
system init' output highlighted a "guix substitute" crash. So it does
seem like a useful mechanism, especially while 56005 is still open.

Now the current situation is also not really acceptable. What about
hiding the "guix system init" output completely and display a progress
bar page instead?

Thanks,

Mathieu

bug#58483: perl-gtk3 blocking widget

[Julien Lepiller]

Hi Guix!

I was trying to use a perl software that uses gtk3. Its main window
does not show up and it seems to get stuck. I tried to come up with a
reproducer. In guix shell perl perl-gtk3:

```
#!/usr/bin/env perl

use strict;
use warnings;
use diagnostics;
use feature ':5.14';
use Gtk3 '-init';
use Glib qw/TRUE FALSE/;

my $window = Gtk3::Window->new('toplevel');
$window->set_title("Basic Check Boxes");
$window->set_position("mouse");
$window->set_default_size(400, 200);
$window->set_border_width(5);
$window->signal_connect (delete_event => sub { Gtk3->main_quit });

my $vbox = Gtk3::Box->new("vertical", 5);
$window->add($vbox);

say "hello";

my $entry = Gtk3::Entry->new;

say "hello again";

Gtk3->main;
```

says "hello" but gets stuck when creating the entry. I get some error
messages, but it doesn't prevent perl-gtk3 from showing relatively
complex windows: I get the same errors with a script like, but the
window is properly shown:

https://github.com/kevinphilp/Perl-gtk3-Tutorial/blob/master/5a-Fun-with-labels.pl

any perl expert around? :)