bug#63728: GHC cannot find lrt

[Antero Mejr via Bug reports for GNU Guix]

Attempting to build a trivial Haskell program using ghc fails, as the
linker cannot find the rt library:

```
~ $ ghc -O2 test.hs
Linking test ...
/home/a/.guix-profile/bin/ld: cannot find -lrt: No such file or directory
collect2: error: ld returned 1 exit status
`gcc' failed in phase `Linker'. (Exit code: 1)
```

Glibc and gcc-toolchain are installed in the profile, and
~/.guix-profile/lib/librt.so.1 exists.

Maybe this is related to this new bug, or the recent core-updates merge?
https://issues.guix.gnu.org/63238

bug#63726: time-machine without options does not get the latest commit

[Ludovic Courtès]

Hi,

Simon Tournier  skribis:

> Now, what I am missing.  The manual says:
>
>As for ‘guix pull’, the absence of any options means that the latest
> commit on the master branch will be used.  The command
>
>  guix time-machine -- build hello
>
>will thus build the package ‘hello’ as defined in the master branch,
> which is in general a newer revision of Guix than you have installed.
> Time travel works in both directions!
>
> and I get:
>
> $ guix time-machine -- describe
>   guix e499cb2
> repository URL: https://git.savannah.gnu.org/git/guix.git
> commit: e499cb2c12d7f1c6d2f004364c9cc7bdb7e38cd5
>
>
> But I do not understand from where this commit hash is coming from.  And
> please note that this commit seems coming from my previous experiments
> reported in #63667 [1].
>
> Well, the last commit seems a9cde26133b,

I had to check the code, but ‘guix time-machine’ follows the same logic
as ‘guix pull’: it reads ~/.config/guix/channels.scm, and so on (that’s
the ‘channel-list’ procedure).

I must say I’m surprised, but it’s always been this way.

Should we fix the doc or should we fix the code?…

Ludo’.

bug#63727: libffi propagation in glib versions causes issues

[Csepp]

guix upgrade: error: profile contains conflicting entries for libffi
guix upgrade: error:   first entry: libffi@3.4.4 
/gnu/store/w8b0l8hk6g0fahj4fvmc4qqm3cvaxnmv-libffi-3.4.4
guix upgrade: error:... propagated from glib@2.72.3
guix upgrade: error:... propagated from dconf@0.40.0
guix upgrade: error:... propagated from eog@42.3
guix upgrade: error:   second entry: libffi@3.3 
/gnu/store/wgqhlc12qvlwiklam7hz2r311fdcqfim-libffi-3.3
guix upgrade: error:... propagated from glib@2.70.2
guix upgrade: error:... propagated from gdk-pixbuf@2.42.4
guix upgrade: error:... propagated from libnotify@0.7.9

Why do these need to be propagated?

bug#52362: guix import go error

[Nicolas Goaziou]

Hello,

Simon Tournier  writes:

> On mar., 01 mars 2022 at 00:55, Nicolas Goaziou  
> wrote:
>
>>   ./pre-inst-env guix import go --recursive rclone
>
> Using Guix 14c0380, I get:
>
> --8<---cut here---start->8---
> $ guix import go --recursive rclone
> guix import: warning: Failed to import package "rclone".
> reason: "https://proxy.golang.org/rclone/@v/list; could not be fetched: HTTP 
> error 404 ("Not Found").
> This package and its dependencies won't be imported.
> --8<---cut here---end--->8---

Oops! For the record, I meant:

   guix import go --recursive github.com/rclone/rclone

Regards,
-- 
Nicolas Goaziou

bug#52362: guix import go error

[Simon Tournier]

Hi,


On mar., 01 mars 2022 at 00:55, Nicolas Goaziou  wrote:

>   ./pre-inst-env guix import go --recursive rclone

Using Guix 14c0380, I get:

--8<---cut here---start->8---
$ guix import go --recursive rclone
guix import: warning: Failed to import package "rclone".
reason: "https://proxy.golang.org/rclone/@v/list; could not be fetched: HTTP 
error 404 ("Not Found").
This package and its dependencies won't be imported.
--8<---cut here---end--->8---

Moreover, instead of the patch in this thread, I am proposing #63647 [1]
which warns by handling the error, for instance, it displays using
another example from the thread,

--8<---cut here---start->8---
guix import: warning: Git error: reference 'refs/tags/v0.11.29' not found in 
https://github.com/Azure/go-autorest
(define-public go-github-com-azure-go-autorest-autorest
  (package
(name "go-github-com-azure-go-autorest-autorest")
(version "0.11.29")
(source (origin
  (method git-fetch)
  (uri (git-reference
(url "https://github.com/Azure/go-autorest;)
(commit (string-append "v" version
  (file-name (git-file-name name version))
  (sha256
   (base32
""
(build-system go-build-system)
(arguments
 '(#:import-path "github.com/Azure/go-autorest/autorest"
   #:unpack-path "github.com/Azure/go-autorest"))
(propagated-inputs `(("go-golang-org-x-crypto" ,go-golang-org-x-crypto)
 ("go-github-com-golang-jwt-jwt-v4" 
,go-github-com-golang-jwt-jwt-v4)
 ("go-github-com-azure-go-autorest-tracing" 
,go-github-com-azure-go-autorest-tracing)
 ("go-github-com-azure-go-autorest-logger" 
,go-github-com-azure-go-autorest-logger)
 ("go-github-com-azure-go-autorest-autorest-mocks" 
,go-github-com-azure-go-autorest-autorest-mocks)
 ("go-github-com-azure-go-autorest-autorest-adal" 
,go-github-com-azure-go-autorest-autorest-adal)
 ("go-github-com-azure-go-autorest" 
,go-github-com-azure-go-autorest)))
(home-page "https://github.com/Azure/go-autorest;)
(synopsis #f)
(description
 "Package autorest implements an HTTP request pipeline suitable for use 
across
multiple go-routines and provides the shared routines relied on by AutoRest (see
@@url{https://github.com/Azure/autorest/,https://github.com/Azure/autorest/})
generated Go code.")
(license license:asl2.0)))
--8<---cut here---end--->8---

Aside, indeed the proposed patch in this thread could also be merged.

1: https://issues.guix.gnu.org/issue/63647


Cheers,
simon

bug#63726: time-machine without options does not get the latest commit

[Simon Tournier]

Hi,

Well, I do not know if it is a bug or if I misuse something.  Feel free
to close if I am missing a point.

--8<---cut here---start->8---
$ guix describe
Generation 25   mai 19 2023 13:30:14(current)
  guix 14c0380
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 14c03807ba4bc81d42cf869f5b827f7da54ff843

$ git -C 
~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq 
log --oneline -1
14c03807ba4 (HEAD -> master) gnu: ruby-3.2: Upgrade to 3.2.2 [fixes 
CVE-2023-{28755, 28756}].
--8<---cut here---end--->8---

Well, that’s just a luck that both commit hash matches.

Now, what I am missing.  The manual says:

   As for ‘guix pull’, the absence of any options means that the latest
commit on the master branch will be used.  The command

 guix time-machine -- build hello

   will thus build the package ‘hello’ as defined in the master branch,
which is in general a newer revision of Guix than you have installed.
Time travel works in both directions!

and I get:

--8<---cut here---start->8---
$ guix time-machine -- describe
  guix e499cb2
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: e499cb2c12d7f1c6d2f004364c9cc7bdb7e38cd5
--8<---cut here---end--->8---

But I do not understand from where this commit hash is coming from.  And
please note that this commit seems coming from my previous experiments
reported in #63667 [1].

Well, the last commit seems a9cde26133b,

--8<---cut here---start->8---
$ git -C 
~/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq 
log origin/master --oneline -1
a9cde26133b (origin/master, origin/HEAD) gnu: Add mouseloupe.
--8<---cut here---end--->8---

Therefore, let create a Guix revision:

--8<---cut here---start->8---
$ guix time-machine --commit=a9cde26133b -- describe
  guix a9cde26
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: a9cde26133bd98498869a3528d9dff0d3f456a96
--8<---cut here---end--->8---

However, still this e499cb2 one:

--8<---cut here---start->8---
$ guix time-machine -- describe
  guix e499cb2
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: e499cb2c12d7f1c6d2f004364c9cc7bdb7e38cd5
--8<---cut here---end--->8---

Cheers,
simon


1: https://issues.guix.gnu.org/issue/63667

bug#52362: guix import go error

[Simon Tournier]

Hi,

Sorry for the delay.  Thanks for this contribution.  I included this
patch in the series #63647 [1].  Therefore, I guess this bug report can
be close.  WDYT?

1: https://issues.guix.gnu.org/issue/63647#6


Cheers,
simon

bug#63669: Cutter package is heavily outdated and uses wrong backend

[Simon Tournier]

Hi,

On mar., 23 mai 2023 at 22:34, XVilka Haos of System  wrote:

> Since Guix already has packaged Rizin, upgrading the Cutter package
> should be straightforward:
> https://packages.guix.gnu.org/packages/rizin

Do you want to give a try?  Maybe this update is a good candidate for a
contribution. :-)


Cheers,
simon

bug#63666: sporadic “guix substitute: error: connect*: Connection timed out”

[Simon Tournier]

Hi,

On mer., 24 mai 2023 at 17:01, Ludovic Courtès  wrote:

>>  gumbo-parser-0.10.1  149KiB 
>>  
>>  555KiB/s 00:00 ▕██▏ 
>> 100.0%
>>  cups-minimal-2.4.2  4.9MiB  
>>  
>>  533KiB/s 00:03 ▕█▎▏ 
>>  29.2%guix substitute: warning: while fetching 
>> https://ci.guix.gnu.org/nar/lzip/mcdi162f45smrgvjmm3vldx2i1xhz0x5-iso-codes-4.5.0:
>>  server is somewhat slow
>> guix substitute: warning: try `--no-substitutes' if the problem persists
>> retrying download of 
>> '/gnu/store/mcdi162f45smrgvjmm3vldx2i1xhz0x5-iso-codes-4.5.0' with other 
>> substitute URLs...
>
> Good, that’s the expected behavior.  (Of course that may still fail if
> there are no other valid substitute URLs.)

Well, I do not have other substitutes and sometimes it displays this
message but it does not fail.  Does it retry?


>> And I do not know which other substitute URLs are since I pass the
>> option ’--substitute-urls=https://ci.guix.gnu.org’; both to guix-daemon
>> and to “guix shell”.
>>
>> Last, I start to see the progress bar, then something happens and I only
>> see this:
>>
>> substitution of 
>> /gnu/store/6r4brvchlkbbqx2n2iz2p6i2ki78zfp2-kexec-tools-2.0.23 complete
>>
>> substitution of /gnu/store/rfx142plc19c12mcfk86a8ff0c7bpch0-lame-3.100 
>> complete
>>
>> substitution of /gnu/store/65rbvsb9fyx74ff1sjnar1bp8qif7k07-libaacs-0.11.0 
>> complete
>>
>> No more progress bars.
>
> That’s because you have max-jobs > 1: progress bars aren’t displayed
> when several jobs are running in parallel.

Well, I only see this “substitution of …” message when before the
progress bar is broken by a warning.  Then I do not see again any
progress bar.


Cheers,
simon

bug#63526: [PATCH] gnu: hubbub: Disable building tests

[Andy Tai]

Will do. Thanks

On Thu, May 25, 2023 at 6:35 AM Bruno Victal  wrote:
>
> On 2023-05-25 14:02, Greg Hogan wrote:

>
> > Based on the error, can we instead add
> > "-Wno-error=maybe-uninitialized" to the configure-flags?
>
> I'd report this upstream first, it can be the case that the error
> (which is being flagged by the compiler) is unmasking a real bug
> upstream.
>

bug#63368: Build coordiantor "Signals delivery fails constantly" crashes

[Christopher Baines]

Ludovic Courtès  writes:

> Christopher Baines  skribis:
>
>> Since the recent core-updates merge, I've seen the build coordinator
>> using less memory, but it's also been crashing in a new way, up to 10
>> times a day.
>>
>> In the log, you see something like:
>>
>>   2023-05-07 09:15:42 Signals delivery fails constantly at GC #71051
>>   2023-05-07 09:15:42 Signals delivery fails constantly
>>
>> I'm guessing the switch from libgc-8.0.4 to libgc-8.2.2 has something to
>> do with this.
>
> Normally on GNU/Linux libgc has:
>
>   #define SIG_SUSPEND SIGPWR
>
> The Coordinator fiddles with SIGALRM, SIGUSR1, SIGINT, and SIGPIPE,
> which should normally be fine.
>
> Is there anything else that might interfere with libgc?

I've seen this issue in both the build coordinator and nar-herder, both
of which use guile-sqlite, so I wonder if that could have something to
do with it.


signature.asc
Description: PGP signature

bug#63368: Build coordiantor "Signals delivery fails constantly" crashes

[Ludovic Courtès]

Hi,

Christopher Baines  skribis:

> Since the recent core-updates merge, I've seen the build coordinator
> using less memory, but it's also been crashing in a new way, up to 10
> times a day.
>
> In the log, you see something like:
>
>   2023-05-07 09:15:42 Signals delivery fails constantly at GC #71051
>   2023-05-07 09:15:42 Signals delivery fails constantly
>
> I'm guessing the switch from libgc-8.0.4 to libgc-8.2.2 has something to
> do with this.

Normally on GNU/Linux libgc has:

  #define SIG_SUSPEND SIGPWR

The Coordinator fiddles with SIGALRM, SIGUSR1, SIGINT, and SIGPIPE,
which should normally be fine.

Is there anything else that might interfere with libgc?

Ludo’.

bug#63717: [Shepherd] Replaced services remain active in the shadows

[Ludovic Courtès]

Ludovic Courtès  skribis:

> What seems to happen is that, in both cases, the registry points to the
> new service; ‘herd status’ & co. look up the service by name in the
> registry, find the new service, and rightfully show that it’s stopped.
> But the old service still exists: it’s no longer in the registry, but it
> handles SIGCHLD, incoming connections on port 22, etc.

Fixed in Shepherd commit 63af9d7c4460b55953bfa199ea44ac0114289b64.

We’ll have to make a new release soon.

Ludo’.

bug#63675: shepherd 0.10.0 test 2 fail on riscv64-linux

[Ludovic Courtès]

Ludovic Courtès  skribis:

> Here it looks as though process 6499 (associated with service ‘test’) is
> either not receiving SIGHUP as sent by “kill 6499” or is ignoring it.

It’s a similar issue in ‘tests/pid-file.sh’, it seems.

To get a better understanding of what’s happening, could you replace:

  shepherd -I …

by:

  strace -f -t -s 80 -o /tmp/shepherd.strace shepherd -I …

at the beginning of ‘tests/forking-service.sh’?  Then, once you’ve
managed to get the test to fail again, please send both
‘tests/forking-service.log’ and ‘/tmp/shepherd.strace’.

TIA!

Ludo’.

bug#63719: can't cross-build guix

[Efraim Flashner]

I just now attempted to cross-build guix from x86_64 to riscv64 and I
got an error in the 'set-font-path phase. Build log attached.

-- 
Efraim Flashner  רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted


4sxkafsd9nwwlivnxgjjyl7vqijyrs-guix-1.4.0-6.dc5430c.drv.gz
Description: application/gunzip


signature.asc
Description: PGP signature

bug#63675: shepherd 0.10.0 test 2 fail on riscv64-linux

[Ludovic Courtès]

Hi,

(Cc: Efraim as another RISC-V person.)

Z572 <873216...@qq.com> skribis:

> shepherd 0.10.0 test 2 fail on riscv64-linux. same error use
> `guix build shepherd -s riscv64-linux` on x86_64 or
> `guix build shepherd` on riscv64.

[…]

> FAIL: tests/forking-service
[…]
> + herd -s t-socket-3968 start test
> Starting service test...
> Service test has been started.
> + herd -s t-socket-3968 start test2
> Starting service test2...
> Service test2 has been started.
> + grep running
> + herd -s t-socket-3968 status test
>   It is running since 03:39:18 (3 seconds ago).
> + test -f t-service-pid-3968
> ++ cat t-service-pid-3968
> + service_pid_value=6499
> + kill 6499
> + kill -0 6499
> + sleep 0.3
> + kill -0 6499
> + sleep 0.3
> + kill -0 6499

Here it looks as though process 6499 (associated with service ‘test’) is
either not receiving SIGHUP as sent by “kill 6499” or is ignoring it.

How reproducible is it?  You can run it with
“make check TESTS=tests/forking-service.sh” to see.

Thanks,
Ludo’.

bug#63371: [bug#63534] [PATCH] gnu: openboard: Update to 1.7-dev-0.47a96e1

[Giovanni Biscuolo]

Hello,

Nicolas Goaziou  writes:

[...]

> Nitpick: missing full stops at the end of sentences.

OK, I'll prepare a V2 patch ASAP

>> [arguments]: Fix quazip and poppler library path

sorry: maybe this description is a little bit misleading

> [...]
>
>>  (substitute* "OpenBoard.pro"
>> -  (("/usr/include/quazip")
>> -   (search-input-directory inputs "/include/quazip5"))
>> +  (("/usr/include/quazip5")

This one is important, it fixes quazip include path (/usr/include/quazip
-> /usr/include/quazip5)

>> +   (search-input-directory inputs "include/quazip5"))
>>(("/usr/include/poppler")
>> -   (search-input-directory inputs "/include/poppler")
>> +   (search-input-directory inputs "include/poppler")
>
> I don't think these changes are warranted. Do they fix something?

No [1], I'll strip this changes from the V2 of this patch

> Otherwise LGTM.

Thanks! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

bug#63526: [PATCH] gnu: hubbub: Disable building tests

[Bruno Victal]

On 2023-05-25 14:02, Greg Hogan wrote:
> Hi Andy,
> 
> Disabling tests should be a last resort, especially without a process
> to evaluate re-enabling tests in the future.

I concur.

A test failure, unless it is caused by things such as “requiring
network access” or is expected due to guix specifics should be
considered a problem with the package. (if tests are disabled simply
because they happen to fail without doing any investigation, why have
tests at all?)

> Based on the error, can we instead add
> "-Wno-error=maybe-uninitialized" to the configure-flags?

I'd report this upstream first, it can be the case that the error
(which is being flagged by the compiler) is unmasking a real bug
upstream.


-- 
Furthermore, I consider that nonfree software must be eradicated.

Cheers,
Bruno.

bug#63678: Can't restart/halt system with shepherd 0.9.3 after upgrading

[Christopher Baines]

Ludovic Courtès  writes:

> Hi,
>
> Christopher Baines  skribis:
>
>> On a system running shepherd 0.9.3 [1], I've reconfigured, but now can't
>> reboot or halt.
>>
>> root@hamal ~# halt
>> Service root is not running.
>
> Hey, why halt it if it’s not running?
>
> Seriously though, any insight from /var/log/messages?  I upgraded a
> bunch of machines and didn’t hit this particular problem.  Bruno
> reported a similar problem with 0.9.3, but this had nothing to do with
> the upgrade:
>
>   https://issues.guix.gnu.org/62619
>
> Could it be the same problem?  Do you see:
>
>   Assertion (eq? (canonical-name new) (canonical-name old)) failed.
>
> in /var/log/messages?

I don't see that, but I think these are the relevant log messages:

May 24 11:17:02 localhost shepherd[1]: Evaluating user expression (and 
(defined? (quote transient?)) (map (# ?) ?)).
May 24 11:17:02 localhost shepherd[1]: Evaluating user expression 
(register-services (primitive-load "/gnu/st?") ?).
May 24 11:17:03 localhost shepherd[1]: Service host-name has been started.
May 24 11:17:03 localhost shepherd[1]: Service user-homes has been started.
May 24 11:17:03 localhost shepherd[1]: [sysctl] fs.protected_hardlinks = 1
May 24 11:17:03 localhost shepherd[1]: [sysctl] fs.protected_symlinks = 1
May 24 11:18:41 localhost shepherd[1]: Exiting shepherd...
May 24 11:18:46 localhost shepherd[1]: Grace period of 5 seconds is over; 
sending -337 SIGKILL.
May 24 11:23:55 localhost shepherd[1]: Service root is not running.
May 24 11:24:16 localhost last message repeated 2 times
May 24 11:30:49 localhost syslogd (GNU inetutils 2.3): restart
May 24 11:30:49 localhost vmunix: [0.00] Booting Linux on physical CPU 
0x00 [0x410fd083]
May 24 11:30:49 localhost vmunix: [0.00] Linux version 
6.3.3-arm64-generic (guix@guix) (gcc (GCC) 11.3.0, GNU ld (GNU Binutils) 2.38) 
#1 SMP PREEMPT 1


signature.asc
Description: PGP signature

bug#63678: Can't restart/halt system with shepherd 0.9.3 after upgrading

[Ludovic Courtès]

Hi,

Christopher Baines  skribis:

> On a system running shepherd 0.9.3 [1], I've reconfigured, but now can't
> reboot or halt.
>
> root@hamal ~# halt
> Service root is not running.

Hey, why halt it if it’s not running?

Seriously though, any insight from /var/log/messages?  I upgraded a
bunch of machines and didn’t hit this particular problem.  Bruno
reported a similar problem with 0.9.3, but this had nothing to do with
the upgrade:

  https://issues.guix.gnu.org/62619

Could it be the same problem?  Do you see:

  Assertion (eq? (canonical-name new) (canonical-name old)) failed.

in /var/log/messages?

Ludo’.

bug#63526: [PATCH] gnu: hubbub: Disable building tests

[Greg Hogan]

On Mon, May 22, 2023 at 2:46 AM Andy Tai  wrote:
>
> Fix for https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63526
>
> * gnu/packages/web.scm (hubbub): [arguments] (tests): Set to #f to disable 
> test build
> ---
>  gnu/packages/web.scm | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/web.scm b/gnu/packages/web.scm
> index fe52f673e2..203e3283cf 100644
> --- a/gnu/packages/web.scm
> +++ b/gnu/packages/web.scm
> @@ -5252,7 +5252,9 @@ (define-public hubbub
> perl))
>  (propagated-inputs
>   (list libparserutils)) ;for libhubbub.pc
> -(arguments netsurf-buildsystem-arguments)
> +(arguments
> + `(#:tests? #f  ;build error in building tests with gcc 11; skip for now
> +   ,@netsurf-buildsystem-arguments))
>  (home-page "https://www.netsurf-browser.org/projects/hubbub/;)
>  (synopsis "HTML5 compliant parsing library")
>  (description
>
> base-commit: 3abcf1663b86bc075e29563140698d8bfae44992
> --
> 2.40.1

Hi Andy,

Disabling tests should be a last resort, especially without a process
to evaluate re-enabling tests in the future.

Based on the error, can we instead add
"-Wno-error=maybe-uninitialized" to the configure-flags?

Greg

bug#63717: [Shepherd] Replaced services remain active in the shadows

[Ludovic Courtès]

Hello!

A bug we noticed with the Shepherd 0.10.0 on berlin: after
reconfiguring, which registers a “replacement” for services currently
running, restarting said services (with ‘herd restart’ or similar, which
is supposed to instate the replacement) happens to leave the old service
behind.

Example: ‘ssh-daemon’ is marked as stopped because it cannot bind to
port 22; indeed, there’s still a service listening on port 22, the one
service that should have been replaced.

Likewise for ‘cuirass-web’ for instance: it’s marked as failing to
start, but in fact it’s running; if you try to kill the ‘cuirass web’
process, you can see it’s respawned and /var/log/messages shows that
very clearly.

What seems to happen is that, in both cases, the registry points to the
new service; ‘herd status’ & co. look up the service by name in the
registry, find the new service, and rightfully show that it’s stopped.
But the old service still exists: it’s no longer in the registry, but it
handles SIGCHLD, incoming connections on port 22, etc.

Ludo’.

bug#63371: [bug#63534] [PATCH] gnu: openboard: Update to 1.7-dev-0.47a96e1

[Nicolas Goaziou]

Hello,

Giovanni Biscuolo  writes:

> From c0405d2762eb173fb7357de700f1aefc606682f6 Mon Sep 17 00:00:00 2001
> Message-Id: 
> 
> From: Giovanni Biscuolo 
> Date: Tue, 16 May 2023 08:08:56 +0200
> Subject: [PATCH] gnu: openboard: Update to 1.7-dev-0.47a96e1
>
> * gnu/packages/education.scm (openboard)[version]: Update to
> 1.7-dev-0.47a96e1

Nitpick: missing full stops at the end of sentences.

> [arguments]: Fix quazip and poppler library path


[...]

>  (substitute* "OpenBoard.pro"
> -  (("/usr/include/quazip")
> -   (search-input-directory inputs "/include/quazip5"))
> +  (("/usr/include/quazip5")
> +   (search-input-directory inputs "include/quazip5"))
>(("/usr/include/poppler")
> -   (search-input-directory inputs "/include/poppler")
> +   (search-input-directory inputs "include/poppler")

I don't think these changes are warranted. Do they fix something?

Otherwise LGTM.

Regards,
-- 
Nicolas Goaziou

bug#62487: guix-daemon fails on SELinux/systemd distros

[Ludovic Courtès]

Ludovic Courtès  skribis:

> I thought we could improve on that by having ‘guix-install.sh’ take care
> of most things dynamically and documenting any remaining bits with
> copy/pastable snippets.
>
> The attached patch does 90% of the job!  I tested it on the Rocky Linux 9
> live image available at:
>
>   
> https://dl.rockylinux.org/pub/rocky/9/live/x86_64/Rocky-9-Workstation-Lite-x86_64-latest.iso

I fixed it with these commits (and with help from Ricardo, thanks!):

  ca1ea6373a * self: Install 'guix-daemon.cil'.
  b59c18f761 * doc: Tweak SELinux instructions.
  4166b583fb * guix-install.sh: Install SELinux policy and relabel file systems 
if needed.
  3bf612eaa1 * etc: SELinux: Update policy file.

Tested again in the Rocky Linux 9 image above.

Ludo’.

bug#63280: bug#63593: [PATCH] gnu: encfs: Depend on OpenSSL v1.1 to fix test segfault.

[Ludovic Courtès]

Bon dia,

Ivan Vilata i Balaguer  skribis:

> Fixes .
>
> * gnu/packages/crypto.scm (encfs): Update to 1.9.
> [inputs]: Replace openssl with openssl-1.1.

Applied, thanks!

Ludo’.