bug#47271: guix graph --path results in backtrace

[Julien Lepiller]

Sounds like you might have stale .go files somewhere maybe?

Le 19 mars 2021 20:01:44 GMT-04:00, Mark H Weaver  a écrit :
>This is at commit 1955ef93b76e51cab5bed4c90f7eb9df7035355a on the
>master
>branch, plus some local patches on my private branch which I suspect
>are
>irrelevant to this:
>
>--8<---cut here---start->8---
>mhw@jojen ~$ guix graph --path gtk+ imagemagick
>Backtrace:
>In ice-9/boot-9.scm:
>1736:10 13 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
>In unknown file:
>  12 (apply-smob/0 #)
>In ice-9/boot-9.scm:
>718:2 11 (call-with-prompt _ _ #proc)>)
>In ice-9/eval.scm:
>619:8 10 (_ #(#(#)))
>In guix/ui.scm:
>  2164:12  9 (run-guix-command _ . _)
>In guix/scripts/graph.scm:
>573:2  8 (guix-graph . _)
>In ice-9/boot-9.scm:
>1736:10  7 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
>1731:15  6 (with-exception-handler #ice-9/boot-9.scm:1815:7 (exn)> _ #:unwind? _ #:unwind-for-type _)
>1736:10  5 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
>In guix/store.scm:
>   636:37  4 (thunk)
>In guix/scripts/graph.scm:
>   598:37  3 (_ #)
>   598:37  2 (_ #f)
>In ice-9/boot-9.scm:
>  1669:16  1 (raise-exception _ #:continuable? _)
>  1669:16  0 (raise-exception _ #:continuable? _)
>
>ice-9/boot-9.scm:1669:16: In procedure raise-exception:
>Wrong type to apply: #
>mhw@jojen ~$
>--8<---cut here---end--->8---

bug#47257: [PATCH 1/1] gnu: mariadb: Update to 10.5.9 [fixes CVE-2021-27928].

[Mark H Weaver]

Mark H Weaver  writes:
> 'package/inherit' is usually the right thing when defining other kinds
> of package variants, however.

One addendum to this guideline: if the package variant you're defining
overrides the 'source' field[*], it's probably pointless to use
'package/inherit', because the fixes embodied in the original package's
replacement would most likely be lost anyway.

[*] One exception is if the overridden 'source' field merely adds some
additional patches to the original package, while taking care to
preserve any existing patches -- that last part is important, even if
the original package doesn't including any patches at the time you look.
In that case, 'package/inherit' might well be helpful.

More generally, when inheriting from another package, it's useful to ask
yourself what should happen if the package you're inheriting from is
later grafted, and to try to arrange for that to happen automatically.

 Thanks,
   Mark

bug#47257: [PATCH 1/1] gnu: mariadb: Update to 10.5.9 [fixes CVE-2021-27928].

[Mark H Weaver]

Hi Léo,

Léo Le Bouter via Bug reports for GNU Guix  writes:

> * gnu/packages/databases.scm (mariadb/fixed): New variable.
> (mariadb)[replacement]: Graft.
> ---
>  gnu/packages/databases.scm | 33 +
>  1 file changed, 33 insertions(+)
>
> diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scm
> index 8be83f5cbe..6fdb22d7fb 100644
> --- a/gnu/packages/databases.scm
> +++ b/gnu/packages/databases.scm
> @@ -734,6 +734,7 @@ Language.")
>  (append (find-files "extra/wolfssl")
>  (find-files "zlib")))
>#t
> +(replacement mariadb/fixed)
>  (build-system cmake-build-system)
>  (outputs '("out" "lib" "dev"))
>  (arguments
> @@ -969,6 +970,38 @@ Language.")
>  as a drop-in replacement of MySQL.")
>  (license license:gpl2)))
>  
> +(define mariadb/fixed
> +  (package/inherit mariadb

Please don't use 'package/inherit' when the package you're defining is a
replacement to the package you're inheriting from.  It creates a package
object with an infinite chain of grafts.  I guess that the infinite
chain gets truncated somewhere in the grafting machinery, but I seem to
recall that this kind of thing has caused real problems in the past.

'package/inherit' is usually the right thing when defining other kinds
of package variants, however.

Thanks again for all of your recent work on improving our security.  It
is a great help.

  Regards,
Mark

bug#47271: guix graph --path results in backtrace

[Mark H Weaver]

This is at commit 1955ef93b76e51cab5bed4c90f7eb9df7035355a on the master
branch, plus some local patches on my private branch which I suspect are
irrelevant to this:

--8<---cut here---start->8---
mhw@jojen ~$ guix graph --path gtk+ imagemagick
Backtrace:
In ice-9/boot-9.scm:
  1736:10 13 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In unknown file:
  12 (apply-smob/0 #)
In ice-9/boot-9.scm:
718:2 11 (call-with-prompt _ _ #)
In ice-9/eval.scm:
619:8 10 (_ #(#(#)))
In guix/ui.scm:
  2164:12  9 (run-guix-command _ . _)
In guix/scripts/graph.scm:
573:2  8 (guix-graph . _)
In ice-9/boot-9.scm:
  1736:10  7 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
  1731:15  6 (with-exception-handler # _ #:unwind? _ #:unwind-for-type _)
  1736:10  5 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
In guix/store.scm:
   636:37  4 (thunk)
In guix/scripts/graph.scm:
   598:37  3 (_ #)
   598:37  2 (_ #f)
In ice-9/boot-9.scm:
  1669:16  1 (raise-exception _ #:continuable? _)
  1669:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1669:16: In procedure raise-exception:
Wrong type to apply: #
mhw@jojen ~$
--8<---cut here---end--->8---

bug#46779: GnuTLS uses the hard-coded /etc/ssl/certs location for TLS certificates

[Mark H Weaver]

Ludovic Courtès  writes:

> Maxim Cournoyer  skribis:
>
>> We should patch GnuTLS so that it also honors the SSL_* environment
>> variables documented in the Guix manual.
>
> Note that (1) the SSL_* variables are originally from OpenSSL, and (2)
> GnuTLS developers made the conscious decision to not honor any
> environment variable, leaving it up to application developers to do
> that.
>
> That’s the reason we are in this situation.  See the thread at
> .

That thread is worth reading, but for those who are short on time, I
want to call attention to a specific point I made:

  However, GnuTLS does not support an environment variable setting, so we
  would have to patch the code (add_system_trust in lib/system.c).  I
  strongly considered doing this, but I'm worried about the possible
  security implications.  For example, consider a setuid program that uses
  GnuTLS and assumes that the person who ran the program will not be
  capable of changing the trust store that GnuTLS uses.  This assumption
  would be correct for the upstream GnuTLS, but not for ours.



 Thanks,
   Mark

bug#47266: guix pull: error (substituter)

[Christoph Schumacher]

On Fri, Mar 19, 2021 at 09:12:24PM +0100, Ludovic Courtès wrote:
> Hi Christoph,
> 
> Christoph Schumacher 
> skribis:
> 
> > I run guix on Debian stable, and guix asked me to report this error.
> > I already tried to run the garbage collector and re-run guix pull,
> > and that actually changed the error message to suggest --fallback.
> > But that failed, too, and the resulting output is below.
> 
> [...]
> 
> > downloading from 
> > https://ci.guix.gnu.org/nar/lzip/8p3jgqza89ai4fl74vv9hf3nq3h2i29d-module-import-compiled
> >  ...
> >  module-import-compiled 
> >   4.5MiB/s 00:00 | 
> > 1.9MiB transferred
> >
> > Backtrace:
> > In guix/ui.scm:
> >   2164:12 19 (run-guix-command _ . _)
> > In guix/scripts/substitute.scm:
> > 652:2 18 (guix-substitute . _)
> > In unknown file:
> >   17 (with-continuation-barrier #)
> > In ice-9/boot-9.scm:
> >   1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
> > In unknown file:
> >   15 (apply-smob/0 #)
> > In ice-9/boot-9.scm:
> >   1736:10 14 (with-exception-handler _ _ #:unwind? _ # _)
> >   1736:10 13 (with-exception-handler _ _ #:unwind? _ # _)
> >   1731:15 12 (with-exception-handler # …)
> > In guix/scripts/substitute.scm:
> >701:17 11 (_)
> > 410:7 10 (process-substitution _ "/gnu/store/clvvp2j3l0hfk6nfm9…" …)
> > In ice-9/boot-9.scm:
> >   1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
> > In guix/scripts/substitute.scm:
> > 419:9  8 (_)
> 
> [...]
> 
> > Throw to key `bad-response' with args `("Bad Response-Line: ~s" (""))'.
> > Backtrace:
> >1 (primitive-load "/gnu/store/lf5bkkwfi27w9bshgks9yh2k84x…")
> > In guix/ui.scm:
> >   2164:12  0 (run-guix-command _ . _)
> >
> > guix/ui.scm:2164:12: In procedure run-guix-command:
> > Throw to key `bad-response' with args `("Bad Response-Line: ~s" (""))'.
> > substitution of 
> > /gnu/store/clvvp2j3l0hfk6nfm9f1v7zqp45b8q8q-module-import-compiled failed
> 
> Could you indicate the version of the daemon that you’re running?  You
> can do that presumably by running:
> 
>   guix describe -p /var/guix/profiles/per-user/root/current-guix
>   /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --version
> 
> I suspect the bug is the same as .
> 
> Thanks in advance!
> 
> Ludo’.

Hi Ludo'!

Thank you for your answer!

Here are the versions of guix and guix-daemon:

$ guix describe -p /var/guix/profiles/per-user/root/current-guix
Generation 136  Mar 12 2021 20:25:23(current)
  guix 35b3ab8
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 35b3ab8e5748d9911ae7a0189065d0c25392895b

$ /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --version
guix-daemon (GNU Guix) 1.2.0-15.f8953be

Meanwhile, I also found .
It sounds very similar to my problem,
although there seems to be no version mentioned yet.
I started guix pull --no-substitutes, as suggested there.
So far the error has not occured again, but it's not finished yet.

Anything else I can contribute?

Thank you again!
--Christoph

bug#47266: guix pull: error (substituter)

[Ludovic Courtès]

Hi Christoph,

Christoph Schumacher 
skribis:

> I run guix on Debian stable, and guix asked me to report this error.
> I already tried to run the garbage collector and re-run guix pull,
> and that actually changed the error message to suggest --fallback.
> But that failed, too, and the resulting output is below.

[...]

> downloading from 
> https://ci.guix.gnu.org/nar/lzip/8p3jgqza89ai4fl74vv9hf3nq3h2i29d-module-import-compiled
>  ...
>  module-import-compiled   
> 4.5MiB/s 00:00 | 
> 1.9MiB transferred
>
> Backtrace:
> In guix/ui.scm:
>   2164:12 19 (run-guix-command _ . _)
> In guix/scripts/substitute.scm:
> 652:2 18 (guix-substitute . _)
> In unknown file:
>   17 (with-continuation-barrier #)
> In ice-9/boot-9.scm:
>   1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
>   15 (apply-smob/0 #)
> In ice-9/boot-9.scm:
>   1736:10 14 (with-exception-handler _ _ #:unwind? _ # _)
>   1736:10 13 (with-exception-handler _ _ #:unwind? _ # _)
>   1731:15 12 (with-exception-handler # …)
> In guix/scripts/substitute.scm:
>701:17 11 (_)
> 410:7 10 (process-substitution _ "/gnu/store/clvvp2j3l0hfk6nfm9…" …)
> In ice-9/boot-9.scm:
>   1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
> In guix/scripts/substitute.scm:
> 419:9  8 (_)

[...]

> Throw to key `bad-response' with args `("Bad Response-Line: ~s" (""))'.
> Backtrace:
>1 (primitive-load "/gnu/store/lf5bkkwfi27w9bshgks9yh2k84x…")
> In guix/ui.scm:
>   2164:12  0 (run-guix-command _ . _)
>
> guix/ui.scm:2164:12: In procedure run-guix-command:
> Throw to key `bad-response' with args `("Bad Response-Line: ~s" (""))'.
> substitution of 
> /gnu/store/clvvp2j3l0hfk6nfm9f1v7zqp45b8q8q-module-import-compiled failed

Could you indicate the version of the daemon that you’re running?  You
can do that presumably by running:

  guix describe -p /var/guix/profiles/per-user/root/current-guix
  /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --version

I suspect the bug is the same as .

Thanks in advance!

Ludo’.

bug#47266: guix pull: error (substituter)

[Brian Zwahr]

I was pointed to this issue from the IRC channel. I am also 
experiencing similar "bad response" errors during `guix pull` and `guix 
upgrade`. Thanks to help from IRC, I was able to sort of work around 
the issue by simply brute-forcing the commands, running them over and 
over again until they completed successfully.


Here are all the `guix pull` attempts it took: 

bug#47260: Package GNU MediaGoblin as a Guix service

[jgart]

This sounds like a great project. I would love MediaGoblin to be in Guix also.

> 6. Rewrite MediaGoblin's JavaScript code not to use jQuery. Maybe
> improve the no-bundled-JavaScript video/audio playing experience.

What are your thoughts on rewriting the jquery? 

Should MediaGoblin be using vanilla javascript instead?

Some other possibilities could be purescript (https://www.purescript.org) or 
mint (http://mint-lang.com), although mint and crystal are not in guix yet and 
mint uses preact (http://preactjs.com) as its' runtime since 0.8.0 
(https://www.mint-lang.com/blog/mint-0.8.0).

bug#47266: guix pull: error (substituter)

[Christoph Schumacher]

Dear guix!

I run guix on Debian stable, and guix asked me to report this error.
I already tried to run the garbage collector and re-run guix pull,
and that actually changed the error message to suggest --fallback.
But that failed, too, and the resulting output is below.

I am unsure how to proceed now and would greatly appreciate advice
on how to report the error better and on how to fix my system.

Thank you very much!
--Christoph

# guix pull --fallback
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   1521775
downloading from 
https://ci.guix.gnu.org/nar/lzip/fbn395nfpbp4d4fr6jsbmwcx6n10kg16-python-minimal-3.8.2
 ...
 python-minimal-3.8.2  11.9MiB  
   3.3MiB/s 00:04 
[##] 100.0%

downloading from 
https://ci.guix.gnu.org/nar/lzip/7hizrpdsqf6q3pjgzmi51r5vbzlijkw0-python-minimal-wrapper-3.8.2
 ...
 python-minimal-wrapper-3.8.2  353B 
67KiB/s 00:00 
[##] 100.0%

downloading from 
https://ci.guix.gnu.org/nar/lzip/l59033zbr31zl132cmfzr6i7x5d4iybm-libx11-1.6.12-doc
 ...
 libx11-1.6.12-doc  
  3.0MiB/s 00:00 | 1.4MiB 
transferred

downloading from 
https://ci.guix.gnu.org/nar/lzip/d2c09h0xxlmql98yd989hibi347arwqv-libtiff-4.2.0-doc
 ...
 libtiff-4.2.0-doc  
  2.6MiB/s 00:00 | 410KiB 
transferred

downloading from 
https://ci.guix.gnu.org/nar/lzip/xc2b4nifbx8ma71qzxpn6sg0sva0cljc-git-minimal-2.30.2
 ...
 git-minimal-2.30.2  4.2MiB 
   4.2MiB/s 00:01 
[##] 100.0%

downloading from 
https://ci.guix.gnu.org/nar/gzip/r7xjz7k2183yz1ldggzbxxivd9nskdn0-config.scm ...
 config.scm  501B   
74KiB/s 00:00 
[##] 100.0%

downloading from 
https://ci.guix.gnu.org/nar/gzip/li1smyw1vdws879mdf6vhh25vl9kjzzr-git.scm ...
 git.scm  101B  
27KiB/s 00:00 
[##] 100.0%

downloading from 
https://ci.guix.gnu.org/nar/gzip/vzfwki1q60i42xhnn3mdm1r7wfnav48h-hash.scm ...
 hash.scm  132B 
37KiB/s 00:00 
[##] 100.0%

downloading from 
https://ci.guix.gnu.org/nar/lzip/2fdfnzz61x3xx9jh732hqaw3kc1vv1r3-module-import 
...
 module-import  2KiB
   108KiB/s 00:00 
[##] 100.0%

downloading from 
https://ci.guix.gnu.org/nar/lzip/xbwxggc9314nw15qfy806hvcc53mis2m-module-import 
...
 module-import  2KiB
   136KiB/s 00:00 
[##] 100.0%

downloading from 
https://ci.guix.gnu.org/nar/lzip/8p3jgqza89ai4fl74vv9hf3nq3h2i29d-module-import-compiled
 ...
 module-import-compiled 
  4.5MiB/s 00:00 | 1.9MiB 
transferred

Backtrace:
In guix/ui.scm:
  2164:12 19 (run-guix-command _ . _)
In guix/scripts/substitute.scm:
652:2 18 (guix-substitute . _)
In unknown file:
  17 (with-continuation-barrier #)
In ice-9/boot-9.scm:
  1736:10 16 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
  15 (apply-smob/0 #)
In ice-9/boot-9.scm:
  1736:10 14 (with-exception-handler _ _ #:unwind? _ # _)
  1736:10 13 (with-exception-handler _ _ #:unwind? _ # _)
  1731:15 12 (with-exception-handler # …)
In guix/scripts/substitute.scm:
   701:17 11 (_)
410:7 10 (process-substitution _ "/gnu/store/clvvp2j3l0hfk6nfm9…" …)
In ice-9/boot-9.scm:
  1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
In guix/scripts/substitute.scm:
419:9  8 (_)
In ice-9/boot-9.scm:
  1731:15  7 (with-exception-handler # …)
  1669:16  6 (raise-exception _ #:continuable? _)
  1667:16  5 (raise-exception _ #:continuable? _)
  1669:16  4 (raise-exception _ #:continuable? _)
  1764:13  3 (_ #< components: (#<> #<…>)
  1669:16  2 (raise-exception _ #:continuable? _)
  1667:16  1 (raise-exception _ #:continuable? _)
  1669:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1669:16: In procedure raise-exception:
Throw to key `bad-response' with args `("Bad Response-Line: ~s" (""))'.

bug#40442: srt2vtt does not work

[sirgazil via Bug reports for GNU Guix]

Problem solved. Thanks, Dave.


P.S. I think you forgot to bump the version in the script.

$ srt2vtt --version
srt2vtt 0.1

bug#47192: issues.guix.org not showing patch series?

[Joshua Branson via Bug reports for GNU Guix]

I gather that this is not a very common bug.  So I suppose we'll close
this bug.

Thanks for your quick response Tobias!

-- 
Joshua Branson (joshuaBPMan in #guix)
Sent from Emacs and Gnus
  https://gnucode.me
  https://video.hardlimit.com/accounts/joshua_branson/video-channels
  https://propernaming.org
  "You can have whatever you want, as long as you help
enough other people get what they want." - Zig Ziglar
  

bug#47265: Guix System: improve support for intentional statefullness.

[Vitaliy Shatrov via Bug reports for GNU Guix]

Recently i saw WebKit failing to build on Cuirass.

For Guix System it ought to be in the Manual:
"Setting up FHS for auxiliary applications obtained from upstream Free 
binaries".

This way Joe has a base system which is obviously important to keep reprobuilt.
Then Joe happily pile things on top of it, rather than install Guix on top of 
legacy.

Will definitely try this myself, but if someone already has notes and so, do 
share.
-- 
Сэнт фром май Андроидык девайс уит Канайн майл.

bug#47253: network-manager shepherd services does not wait to be online

[raid5atemyhomework via Bug reports for GNU Guix]

Hello Mark,

> > Of course, the big problem is that Shepherd is single-threadded and
> > `nm-online` will block all other bootup.
>
> That's not good. For the sake of users who are not always connected to
> the internet, I'd strongly prefer for the Guix boot process of a desktop
> system to not be blocked for 30 seconds when there's no active
> internet connection.
>
> How about leaving "networking" as it is now, and instead adding a new
> service called "network-online" or similar, that requires "networking"
> and then waits until a network connection is established?
>
> What do you think?


Ideally the `init` system should be multithreaded, such that anything that 
isn't dependent on `networking` does not get delayed but gets started as soon 
as its dependencies complete.

In particular, `transmission-daemon-service-type` creates a Shepherd service 
that is dependent on `networking`, but is in fact the second daemon I 
mentioned, which fails to properly bind to the command 9091 port, requiring the 
daemon to be restarted each time.  So if we use a separate `network-online` 
shepherd provision, `transmission-daemon-service-type` also needs to be 
modified (on my system I have a separate provision similar to your 
`network-online` idea and I wrote my own shepherd service for 
`transmission-daemon` just to add this requirement).

With a separate `network-online` shepherd provision we would also need to audit 
all the other network-requiring daemons to see if similar problems exist.

As well, `networking` is provided by multiple possible services, so if we add a 
separate `network-online` we also need to modify the other options.

* `network-manager-service-type`.
* `dhcp-client-service-type`.
* `wicd-service-type`.
* `connman-service-type`.

For that matter, we probably need to review the above other options, as they 
might just start up the networking service without actually ensuring that the 
networking service has actually completed.  I use 
`network-manager-service-type` as part of `%desktop-services` but if this issue 
isn't properly handled by Guix for NetworkManager then it probably isn't 
properly handled for the above other options --- in all likelihood the network 
interfaces are not available just after the networking shepherd services are 
started.

In addition --- do we always have a `network-online` shepherd service, or not?

* Each of the `network-manager-service-type`, `dhcp-client-service-type`, 
`wicd-service-type`, `connman-service-type` instantiate both a `networking` and 
`network-online` shepherd provision.
  * Then other network-requiring services can always assume that 
`network-online` exists.
  * However, not-always-online users would always find that `shepherd` 
completion is delayed.
* This manifests as `herd` commands not responding until the 
wait-to-be-online timeout ends.
* We have separate `network-manager-online-service-type`, 
`dhcp-client-online-service-type`, `wicd-online-service-type`, and 
`connman-online-service-type` that provides the `network-online` shepherd 
provision to the corresponding `networking` backend.
  * Thus, not-always-online users would omit the `*-online-*` service type in 
order not to suffer the wait.
  * However, the user has to know to add the *corresponding* service type as 
well if they have to use a daemon like `transmission-daemon`.
  * Do we add `network-manager-online-service-type` to `%desktop-services`?
* I think we should, as most `%desktop-services`-using users will be mostly 
online anyway, and they are the ones most likely to want to start other 
network-using services as well.
* We somehow implement polymorphic service types so that services like 
`transmission-daemon` have a `(service-extension 
i-need-network-online-service-type (const #f))`, which only instantiates 
`network-online` provision, appropriately for the network backend, if at least 
one service requires it.
  * Probably a lot more code and design and nerd wars about the best possible 
design and delays and ...

What do *you* think?


Note as well that in the SystemD case, typically, 
`NetworkManager-wait-online.service` is always enabled, and when I boot up my 
system on SystemD-based OSs even without any network available I don't 
experience any network-going-up delays during boot (at least in the last few 
years, I do remember circa oughts Ubuntu having that problem).

In addition, `nm-online -s` has this:

>   -s | --wait-for-startup
>   Wait for NetworkManager startup to complete, rather than waiting 
> for network connectivity specifically. Startup is considered complete once 
> NetworkManager has activated (or
>   attempted to activate) every auto-activate connection which is 
> available given the current network state. (This is generally only useful at 
> boot time; after startup has
>   completed, nm-online -s will just return immediately, regardless of 
> the current network state.)

My interpretation of the above is that 

bug#40442: [EXT] bug#40442: srt2vtt does not work

[Thompson, David]

Reviving this old issue.

On Sat, Apr 4, 2020 at 6:59 PM sirgazil via Bug reports for GNU Guix
 wrote:
>
> I installed srt2vtt but it errors when I run it.
>
>
> ## Steps to reproduce
>
> 1. Run "guix install srt2vtt"
> 2. Run "srt2vtt --help"
>
>
> ## Expected result
>
> I can see the help information indicated in srt2vtt's website:
>
> $ srt2vtt --help
> Usage: srt2vtt [OPTIONS]
> Convert SubRip formatted subtitles to WebVTT format.
>
>   -h, --help display this help and exit
>   -v, --version  display version and exit
>   -i, --input=FILE-NAME  read input from FILE-NAME
>   -o, --output=FILE-NAME write output to FILE-NAME
>
>
> ## Unexpected result
>
> $ srt2vtt --help
> Backtrace:
> In ice-9/boot-9.scm:
>  160: 17 [catch #t # ...]
> In unknown file:
>?: 16 [apply-smob/1 #]
> In ice-9/boot-9.scm:
>   66: 15 [call-with-prompt prompt0 ...]
> In ice-9/eval.scm:
>  432: 14 [eval # #]
> In ice-9/boot-9.scm:
> 2412: 13 [save-module-excursion # ice-9/boot-9.scm:4084:3 ()>]
> 4089: 12 [#]
> 1734: 11 [%start-stack load-stack ...]
> 1739: 10 [#]
> In unknown file:
>?: 9 [primitive-load "/home/sirgazil/.guix-profile/bin/srt2vtt"]
> In ice-9/eval.scm:
>  505: 8 [# (use-modules 
> # #)]
> In ice-9/psyntax.scm:
> 1107: 7 [expand-top-sequence ((use-modules (ice-9 match) (srt2vtt ui))) () 
> ...]
>  990: 6 [scan ((use-modules (ice-9 match) (srt2vtt ui))) () ...]
>  279: 5 [scan ((# #) #(syntax-object *unspecified* # #)) () (()) ...]
> In ice-9/boot-9.scm:
> 3622: 4 [process-use-modules (((ice-9 match)) ((srt2vtt ui)))]
>  710: 3 [map # 
> (# #)]
> 3623: 2 [# (#)]
> 2903: 1 [resolve-interface (srt2vtt ui) #:select ...]
> In unknown file:
>?: 0 [scm-error misc-error #f "~A ~S" ("no code for module" (srt2vtt ui)) 
> #f]
>
> ERROR: In procedure scm-error:
> ERROR: no code for module (srt2vtt ui)

This is because the package recipe doesn't wrap the srt2vtt script.
This package has probably been broken for a very long time due to
this.

Commit 48781484ef98d93f775ee9bbfeb805ecae8f8e5a upgrades srt2vtt to
0.2 so that it runs with Guile 3 and wraps the srt2vtt executable so
GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH are configured
appropriately.

sirgazil, could you give it a shot and close this bug if things work for you?

Thanks,

- Dave

bug#47020: [PATCH 1/4] gnu: gnu-make-boot0: Don't include debug output.

[Efraim Flashner]

On Thu, Mar 18, 2021 at 10:26:27PM +0100, Ludovic Courtès wrote:
> Hi Efraim,
> 
> Efraim Flashner  skribis:
> 
> > * gnu/packages/commencement.scm (gnu-make-boot0)[outputs]: Remove debug
> > from inherited outputs.
> 
> Make sure nothing inherits from these packages, in which case we might
> inadvertently override ‘outputs’ in those packages too.
> 
> Otherwise this and the subsequent patches LGTM!
> 
> Thanks,
> Ludo’.

Thanks. gcc-final inherits from gcc-boot0, but it already deleted the
debug output.

Patches pushed.

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


signature.asc
Description: PGP signature

bug#47258: guix pull bug: the program '/gnu/store/...-compute-guix-derivation' failed to compute the derivation for Guix

[Maxime Devos]

On Fri, 2021-03-19 at 14:01 +0100, Pierre Neidhardt wrote:
> --fallback fails as well :(
> 

As a work-around, maybe try --no-substitutes to *not* built any
sources *at all*, in which case the network should only be consulted
for downloading source code?



signature.asc
Description: This is a digitally signed message part

bug#47258: guix pull bug: the program '/gnu/store/...-compute-guix-derivation' failed to compute the derivation for Guix

[zimoun]

Hi Pierre,

On Fri, 19 Mar 2021 at 11:25, Pierre Neidhardt  wrote:

> --8<---cut here---start->8---
> $ guix pull

[...]

> @ substituter-succeeded 
> /gnu/store/1nxd28y29f0ksmbplbrshkc71bky2g8n-gnutls-3.6.15-debug
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
> @ substituter-started 
> /gnu/store/d2c09h0xxlmql98yd989hibi347arwqv-libtiff-4.2.0-doc substitute
> guix substitute: error: host name lookup error: Name or service not known
> @ substituter-failed 
> /gnu/store/d2c09h0xxlmql98yd989hibi347arwqv-libtiff-4.2.0-doc  fetching path 
> `/gnu/store/d2c09h0xxlmql98yd989hibi347arwqv-libtiff-4.2.0-doc' (empty 
> status: '')
> Backtrace:
>   11 (primitive-load 
> "/gnu/store/h0lkna6hicpsdxx9sxgapqpy2p1y9azw-compute-guix-derivation")
> In ice-9/eval.scm:
> 155:9 10 (_ _)
> 159:9  9 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(# 7fd77621cf?> ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
> In ./guix/store.scm:
>   2066:24  8 (run-with-store # _ 
> #:guile-for-build _ #:system _ #:target _)
>1900:8  7 (_ _)
> In ./guix/gexp.scm:
>256:18  6 (_ _)
>1136:2  5 (_ _)
>1002:2  4 (_ _)
> 849:4  3 (_ _)
> In ./guix/store.scm:
>   1948:12  2 (_ #)
>1362:5  1 (map/accumulate-builds # _ 
> _)
>   1373:15  0 (_ # _ _)
>
> ./guix/store.scm:1373:15: ERROR:
>   1. :
>   message: "some substitutes for the outputs of derivation 
> `/gnu/store/plq0nz84mannv87aiip646vr2a1z7mb1-libtiff-4.2.0.drv' failed 
> (usually happens due to networking issues); try `--fallback' to build 
> derivation from source "
>   status: 1
> guix pull: error: You found a bug: the program 
> '/gnu/store/h0lkna6hicpsdxx9sxgapqpy2p1y9azw-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "1155a88308df7649fe74bd5bb8279a4d103ce386"; system: "x86_64-linux";
> host version: "5fa4814b4f12b82a7a7747bfacfb45b0348eae1e"; pull-version: 1).
> Please report it by email to .
> --8<---cut here---end--->8---

The similar command:

  guix machine --commit=5fa4814b4f12b82a7a7747bfacfb45b0348eae1e \
   -- time-machine --commit=1155a88308df7649fe74bd5bb8279a4d103ce386 \ 
   -- help

works for me.

It looks like a transient network issue.  I agree it is annoying.
First, it should automatically fallback.  And in any case, it should not
raise this ugly backtrace.

Cheers,
simon

bug#47260: Package GNU MediaGoblin as a Guix service

[Ben Sturmfels via Bug reports for GNU Guix]

This is a "meta" bug to keep track of the progress of packaging GNU
MediaGoblin, a platform for publishing images/audio/video etc. See
https://mediagoblin.org/

We have a guix-env.scm in the upstream source which should always have
the latest copy of our packaging progress and instructions to run it:

https://git.savannah.gnu.org/cgit/mediagoblin.git/tree/guix-env.scm

Current plan is:

1. Add OGG support to libsndfile which is needed to package
python-soundfile [patch 47210]

2. Package python-soundfile (see above). After this the test suite
should pass 100% with pytest installed from PyPI [patch 47181]

3. Work out why python-pytest-6/python-pytest-xdist/python-pytest-forked
in Guix seem to be incompatible. After this our test suite should run
100% with only dependencies from Guix!

4. Package MediaGoblin itself. The build process is ./configure/make
which is a bit weird for a Python project.

5. Get a basic Guix service working, with sqlite3 and without the
offloaded media transcoding currently using Celery/RabbitMQ.

6. Rewrite MediaGoblin's JavaScript code not to use jQuery. Maybe
improve the no-bundled-JavaScript video/audio playing experience.

7. Work out why H264 support is missing.

8. Either package RabbitMQ (probably hard) or rewrite MediaGoblin's
processing backend from Celery/RabbitMQ to RQ/Redis. Celery has been
implicated in many bugs anyway, so there may benefits to the project to
doing this anyway.

9. Figure out how to deal with translations.

10. Add a PostgreSQL database to the Guix service instead of sqlite3.

11. We win. Maybe :)


signature.asc
Description: PGP signature

bug#47253: network-manager shepherd services does not wait to be online

[Mark H Weaver]

Hi,

raid5atemyhomework via Bug reports for GNU Guix 
writes:

> I have a small number of daemons that need access to the network at
> startup.  I have configured their Shepherd services to require
> `networking`.
>
> However, to my puzzlement, I consistently find that they are unable to
> access the network at startup.  One daemon dies (and gets respawned so
> often that it sometimes gets disabled by Shepherd), the other daemon
> just keeps running without having set up the server that I need it to
> expose.
>
> Thus, in many cases whenever I reboot I have to manually `herd enable`
> and `herd restart` the first daemon and `herd restart` the second.
> This is fairly bad since I want to be able to leave this server alone
> and have it survive power interruptions etc.
[...]
> I would like to propose this change:
>
> ```diff
> --- a/gnu/services/networking.scm
> +++ b/gnu/services/networking.scm
> @@ -1106,17 +1106,22 @@ and @command{wicd-curses} user interfaces."
>(documentation "Run the NetworkManager.")
>(provision '(networking))
>(requirement '(user-processes dbus-system wpa-supplicant 
> loopback))
> -  (start #~(make-forkexec-constructor
> -(list (string-append #$network-manager
> - "/sbin/NetworkManager")
> -  (string-append "--config=" #$conf)
> -  "--no-daemon")
> -#:environment-variables
> -(list (string-append "NM_VPN_PLUGIN_DIR=" #$vpn
> - "/lib/NetworkManager/VPN")
> -  ;; Override non-existent default users
> -  "NM_OPENVPN_USER="
> -  "NM_OPENVPN_GROUP=")))
> +  (start #~(let ((constructor   (make-forkexec-constructor
> +  (list (string-append 
> #$network-manager
> +   
> "/sbin/NetworkManager")
> +(string-append 
> "--config=" #$conf)
> +"--no-daemon")
> +  #:environment-variables
> +  (list (string-append 
> "NM_VPN_PLUGIN_DIR=" #$vpn
> +   
> "/lib/NetworkManager/VPN")
> +;; Override non-existent 
> default users
> +"NM_OPENVPN_USER="
> +"NM_OPENVPN_GROUP="
> + (lambda args
> +   (let ((pid (apply constructor args)))
> + (invoke/quiet (string-append #$network-manager 
> "/bin/nm-online")
> +   "-s" "-q" "--timeout=30")
> + pid
>(stop #~(make-kill-destructor
>
>  (define network-manager-service-type
> ```
>
>
> Of course, the big problem is that Shepherd is single-threadded and
> `nm-online` will block all other bootup.

That's not good.  For the sake of users who are not always connected to
the internet, I'd strongly prefer for the Guix boot process of a desktop
system to *not* be blocked for 30 seconds when there's no active
internet connection.

How about leaving "networking" as it is now, and instead adding a new
service called "network-online" or similar, that requires "networking"
and then waits until a network connection is established?

What do you think?

  Mark

bug#47257: mariadb is vulnerable to CVE-2021-27928 (RCE)

[zimoun]

Hi,

On Fri, 19 Mar 2021 at 11:25, Léo Le Bouter via Bug reports for GNU Guix 
 wrote:

> Is it possible to graft mariadb you think? I am thinking this issue
> doesnt need updating of the "lib" output which is what's causing the
> high number of dependents AIUI. I am not sure we could actually update
> individual outputs right now though. Might be a good idea to split the
> packages for the future.

Instead of grafting, I would fix first check the compatibility between
mariadb  and zstd.  Because mariadb@10.5.8 does not build with
zstd@1.4.9, at least on my machine.

Other said, I seem better to do this fix as a whole on core-updates
without any graft.  Instead of grafting here and there; and not
necessary small changes (zstd from 1.4.4 to 1.4.9, mariadb from 10.5.8
to 10.5.8).

All the best,
simon

bug#47257: [PATCH 0/1] gnu: mariadb: Update to 10.5.9 [fixes CVE-2021-27928].

[Léo Le Bouter via Bug reports for GNU Guix]

I made a patch, please review and push if you think that's OK, I will otherwise
push it myself after some time.

The patch produces some test error, not sure if deterministic, looks related to
networking disabled in build sandboxes, log:

The servers were restarted 778 times
Spent 6689.041 of 234 seconds executing testcases

Failure: Failed 1/2711 tests, 99.96% were successful.

Failing test(s): main.system_mysql_db

The log files in var/log may give you some hint of what went wrong.

If you want to report this error, please read first the documentation
at http://dev.mysql.com/doc/mysql/en/mysql-test-suite.html

969 tests were skipped, 161 by the test itself.

mysql-test-run: *** ERROR: there were failing test cases
Error happened at lib/mtr_report.pm line 687.
mtr_report::mtr_error("there were failing test cases") called at 
lib/mtr_report.pm line 556
mtr_report::mtr_report_stats("Failure", 1, ARRAY(0x19d75d0), 
ARRAY(0x1420d08)) called at 
/tmp/guix-build-mariadb-10.5.9.drv-0/mariadb-10.5.9/mysql-test/mysql-test-run.pl
 line 586
main::main() called at 
/tmp/guix-build-mariadb-10.5.9.drv-0/mariadb-10.5.9/mysql-test/mysql-test-run.pl
 line 387
command "./mtr" "--verbose" "--retry=3" "--testcase-timeout=40" 
"--suite-timeout=600" "--parallel" "48" "--skip-rpl" 
"--skip-test-list=unstable-tests" failed with status 1
builder for `/gnu/store/hk1awalxmnd7a7qz4v8r5h7bpxc4ig5b-mariadb-10.5.9.drv' 
failed with exit code 1
@ build-failed /gnu/store/hk1awalxmnd7a7qz4v8r5h7bpxc4ig5b-mariadb-10.5.9.drv - 
1 builder for `/gnu/store/hk1awalxmnd7a7qz4v8r5h7bpxc4ig5b-mariadb-10.5.9.drv' 
failed with exit code 1
derivation '/gnu/store/hk1awalxmnd7a7qz4v8r5h7bpxc4ig5b-mariadb-10.5.9.drv' 
offloaded to 'www.proxmox-2.schmilblick.org' failed: build of 
`/gnu/store/hk1awalxmnd7a7qz4v8r5h7bpxc4ig5b-mariadb-10.5.9.drv' failed
build of /gnu/store/hk1awalxmnd7a7qz4v8r5h7bpxc4ig5b-mariadb-10.5.9.drv failed
View build log at 
'/var/log/guix/drvs/hk/1awalxmnd7a7qz4v8r5h7bpxc4ig5b-mariadb-10.5.9.drv.bz2'.
guix build: error: build of 
`/gnu/store/hk1awalxmnd7a7qz4v8r5h7bpxc4ig5b-mariadb-10.5.9.drv' failed

Léo Le Bouter (1):
  gnu: mariadb: Update to 10.5.9 [fixes CVE-2021-27928].

 gnu/packages/databases.scm | 33 +
 1 file changed, 33 insertions(+)

-- 
2.31.0

bug#47257: [PATCH 1/1] gnu: mariadb: Update to 10.5.9 [fixes CVE-2021-27928].

[Léo Le Bouter via Bug reports for GNU Guix]

* gnu/packages/databases.scm (mariadb/fixed): New variable.
(mariadb)[replacement]: Graft.
---
 gnu/packages/databases.scm | 33 +
 1 file changed, 33 insertions(+)

diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scm
index 8be83f5cbe..6fdb22d7fb 100644
--- a/gnu/packages/databases.scm
+++ b/gnu/packages/databases.scm
@@ -734,6 +734,7 @@ Language.")
 (append (find-files "extra/wolfssl")
 (find-files "zlib")))
   #t
+(replacement mariadb/fixed)
 (build-system cmake-build-system)
 (outputs '("out" "lib" "dev"))
 (arguments
@@ -969,6 +970,38 @@ Language.")
 as a drop-in replacement of MySQL.")
 (license license:gpl2)))
 
+(define mariadb/fixed
+  (package/inherit mariadb
+(version "10.5.9")
+(source (origin
+  (method url-fetch)
+  (uri (string-append "https://downloads.mariadb.com/MariaDB;
+  "/mariadb-" version "/source/mariadb-"
+  version ".tar.gz"))
+  (sha256
+   (base32
+"1kv8226ydyh4nyfx432dxqdkbry92c92bwlc33f1y56yp2p1kas0"))
+  (modules '((guix build utils)))
+  (snippet
+   '(begin
+  ;; Delete bundled snappy and xz.
+  (delete-file-recursively 
"storage/tokudb/PerconaFT/third_party")
+  (substitute* "storage/tokudb/PerconaFT/CMakeLists.txt"
+;; This file checks that the bundled sources are present 
and
+;; declares build procedures for them.
+(("^include\\(TokuThirdParty\\)") ""))
+  (substitute* "storage/tokudb/PerconaFT/ft/CMakeLists.txt"
+;; Don't attempt to use the procedures we just removed.
+((" build_lzma build_snappy") ""))
+
+  ;; Preserve CMakeLists.txt for these.
+  (for-each (lambda (file)
+  (unless (string-suffix? "CMakeLists.txt" file)
+(delete-file file)))
+(append (find-files "extra/wolfssl")
+(find-files "zlib")))
+  #t))
+
 (define-public mariadb-connector-c
   (package
 (name "mariadb-connector-c")
-- 
2.31.0

bug#47257: mariadb is vulnerable to CVE-2021-27928 (RCE)

[Julien Lepiller]

You need to graft: when building a package, the output hash depends on the 
inputs, sources and instructions, so even if the content of the lib output does 
not change, its store path does, leading to a rebuild.

Le 19 mars 2021 06:25:31 GMT-04:00, "Léo Le Bouter via Bug reports for GNU 
Guix"  a écrit :
>CVE-2021-27928 04:15
>A remote code execution issue was discovered in MariaDB 10.2 before
>10.2.37, 10.3 before 10.3.28, 10.4 before 10.4.18, and 10.5 before
>10.5.9; Percona Server through 2021-03-03; and the wsrep patch through
>2021-03-03 for MySQL. An untrusted search path leads to eval injection,
>in which a database SUPER user can execute OS commands after modifying
>wsrep_provider and wsrep_notify_cmd. NOTE: this does not affect an
>Oracle product.
>
>From https://jira.mariadb.org/browse/MDEV-25179 it looks like 10.5.9
>fixes it for us since we package 10.5.8 currently.
>
>However:
>
>$ ./pre-inst-env guix refresh -l mariadb
>Building the following 552 packages would ensure 1047 dependent
>packages are rebuilt:
>[..]
>
>Is it possible to graft mariadb you think? I am thinking this issue
>doesnt need updating of the "lib" output which is what's causing the
>high number of dependents AIUI. I am not sure we could actually update
>individual outputs right now though. Might be a good idea to split the
>packages for the future.
>
>Léo

bug#47228: Check binary consistency after grafting with e.g. ldd

[Ludovic Courtès]

Hi,

Léo Le Bouter  skribis:

> On Thu, 2021-03-18 at 14:38 +0100, Ludovic Courtès wrote:
>> I don’t think all the testing that needs to be done when grafting can
>> be
>> automated.
>
> Not all but part of it?

Not even sure; at least I don’t have any ideas.

>> In particular, packagers who want to introduce a replacement for a
>> library should use libabigail’s ‘abi-diff’ tool to check that the
>> package and its replacement are ABI-compatible.  It’s also a good
>> idea
>> to make some quick manual tests.
>
> That's great! Maybe we can have some quick tooling to in GNU Guix to
> aid that?

Again it’s on a case-by-case basis, it depends on what you’re grafting,
so I wouldn’t know how to do that.

Perhaps a first step would be consolidate this “insider knowledge” about
security updates and grafts into a check list.

>> The .so file symlinks in
>> <
>> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=2e0ff59f0cd836b156f1ef2e78791d864ce3cfcd
>> >
>> look very scary to me.  To me, it’s likely to hide the ABI
>> incompatibility issue rather than “fix” it.
>
> :-/ Yes it is scary, we were having an user with an Inkscape issue on
> IRC and this commit fixed it for them and they could work without an
> issue though, we were discussing with rekado and rekado suggested we
> cheat like this and I've done it, the only alternative we have is
> porting/applying all patches to our version by digging commit history
> (with always the doubt of adding an incomplete fix which is likely if
> we have to dig commit history manually).

It’s the kind of patch that should be reviewed before it gets in.

In this case, review will have to happen after the fact, but it still
has to happen IMO.  I’d prefer not to do it myself; perhaps Leo F. can
take a look?

> If nobody can put time to dig patches for all individuals CVEs until we
> ungraft then I'd rather have this scary commit in.

Security is a spectrum; we’ll never close all CVEs.  :-)

Security issues often call for quick reaction, but to me that doesn’t
mean we should dismiss our practices and workflow, in particular peer
review.

Thanks,
Ludo’.

bug#47259: python-pillow-simd package vulnerable to at least CVE-2021-25293

[Léo Le Bouter via Bug reports for GNU Guix]

Hello!

pillow-simd is a fork of pillow (
https://github.com/uploadcare/pillow-simd), it's currently still at
version 7.x and it does not seem like it backports security patches
from pillow.

$ ./pre-inst-env guix refresh -l python-pillow-simd
No dependents other than itself: python-pillow-simd@7.1.2

Do we remove it? Do we want to commit to backporting/applying all fixes
from python-pillow back in python-pillow-simd ourselves (I don't)?

Léo


signature.asc
Description: This is a digitally signed message part

bug#47257: mariadb is vulnerable to CVE-2021-27928 (RCE)

[Léo Le Bouter via Bug reports for GNU Guix]

CVE-2021-27928  04:15
A remote code execution issue was discovered in MariaDB 10.2 before
10.2.37, 10.3 before 10.3.28, 10.4 before 10.4.18, and 10.5 before
10.5.9; Percona Server through 2021-03-03; and the wsrep patch through
2021-03-03 for MySQL. An untrusted search path leads to eval injection,
in which a database SUPER user can execute OS commands after modifying
wsrep_provider and wsrep_notify_cmd. NOTE: this does not affect an
Oracle product.

From https://jira.mariadb.org/browse/MDEV-25179 it looks like 10.5.9
fixes it for us since we package 10.5.8 currently.

However:

$ ./pre-inst-env guix refresh -l mariadb
Building the following 552 packages would ensure 1047 dependent
packages are rebuilt:
[..]

Is it possible to graft mariadb you think? I am thinking this issue
doesnt need updating of the "lib" output which is what's causing the
high number of dependents AIUI. I am not sure we could actually update
individual outputs right now though. Might be a good idea to split the
packages for the future.

Léo


signature.asc
Description: This is a digitally signed message part

bug#47256: generic-html updater does not work for mediainfo package

[Léo Le Bouter via Bug reports for GNU Guix]

Hello!

$ ./pre-inst-env guix refresh mediainfo
gnu/packages/video.scm:3852:2: warning: 'generic-html' updater failed
to determine available releases for mediainfo

I tried adding a release-monitoring-url and hardcoding the name into
the url instead of using the variable 'name' but that did not help.

The release area has a folder with version and then a tar.gz with
version inside it's name as well, not sure if generic-html updater
supports that.

See: https://mediaarea.net/download/source/mediainfo/

Thank you!
Léo


signature.asc
Description: This is a digitally signed message part

bug#47230: Build phase to graft during build for better grafts QA

[Léo Le Bouter via Bug reports for GNU Guix]

On Thu, 2021-03-18 at 21:41 +0100, Ludovic Courtès wrote:
> I think it’s more of a discussion for guix-devel than a bug
> report.  :-)

Yes but then I was thinking how do we track progress without losing it
in the pile of emails from guix-devel people receive everyday which
made me create a bug in the idea of "feature-request".. don't know.

> What you describe, AIUI, is not possible: there are no phases or
> anything like that happening on grafted packages.  Quoth the manual
> (info "(guix) Security Updates"):
> 
>   Other restrictions may apply: for instance, when adding a graft to
> a
>   package providing a shared library, the original shared library and
> its
>   replacement must have the same ‘SONAME’ and be binary-compatible.

I am not sure we understand each other, I am proposing we could add
tooling to aid that testing.

> As I wrote earlier today, these things have to be checked by
> packagers;
> they’re not easily automated because that usually involves knowing
> the
> intent of upstream developers, for example whether they intend the
> new
> version to be ABI-compatible with the version we have at hand, etc.
> 
> HTH!

Yes of course, but aided by tooling that process can me smoother, e.g.
figuring out the SONAME has changed could at least be checked
automatically and issue a warning/error. Same thing with abidiff etc.
these tools are really great and we could create an easy way to run the
test suite of a package with the graft in also.

> Ludo’.

Thank you


signature.asc
Description: This is a digitally signed message part

bug#47228: Check binary consistency after grafting with e.g. ldd

[Léo Le Bouter via Bug reports for GNU Guix]

On Thu, 2021-03-18 at 14:38 +0100, Ludovic Courtès wrote:
> I don’t think all the testing that needs to be done when grafting can
> be
> automated.

Not all but part of it?

> In particular, packagers who want to introduce a replacement for a
> library should use libabigail’s ‘abi-diff’ tool to check that the
> package and its replacement are ABI-compatible.  It’s also a good
> idea
> to make some quick manual tests.

That's great! Maybe we can have some quick tooling to in GNU Guix to
aid that?

> The .so file symlinks in
> <
> https://git.savannah.gnu.org/cgit/guix.git/commit/?id=2e0ff59f0cd836b156f1ef2e78791d864ce3cfcd
> >
> look very scary to me.  To me, it’s likely to hide the ABI
> incompatibility issue rather than “fix” it.

:-/ Yes it is scary, we were having an user with an Inkscape issue on
IRC and this commit fixed it for them and they could work without an
issue though, we were discussing with rekado and rekado suggested we
cheat like this and I've done it, the only alternative we have is
porting/applying all patches to our version by digging commit history
(with always the doubt of adding an incomplete fix which is likely if
we have to dig commit history manually).

If nobody can put time to dig patches for all individuals CVEs until we
ungraft then I'd rather have this scary commit in.

Léo


signature.asc
Description: This is a digitally signed message part

bug#47154: ungoogled-chromium@88.0.4324.182 package vulnerable to various severe CVEs

[Léo Le Bouter via Bug reports for GNU Guix]

Fixed by 1155a88308df7649fe74bd5bb8279a4d103ce386


signature.asc
Description: This is a digitally signed message part