bug#72828: Grafting breaks libcamera signatures

2024-09-05 Thread Andrew Tropin via Bug reports for GNU Guix 
On 2024-09-04 21:42, Andrew Tropin wrote:

> On 2024-09-04 18:42, Ludovic Courtès wrote:
>
>> Hi Jacopo,
>>
>> Jacopo Mondi  skribis:
>>
>>> Not exactly. In libcamera, apart from creating a library to ease all
>>> the camera stack plumbing, we're creating an ecosystem of open-source
>>> 3A algorithms (what we call the IPA modules).
>>>
>>> Camera vendors and ODMs which invested in products with specific
>>> camera features, consider 3A algorithms and their tuning their secret
>>> sauce and are usually not willing to consider releasing them as open
>>> source with, fortunately, notable exceptions such as RaspberryPi
>>>
>>> Please note that all the platforms libcamera supports have an
>>> open-source 3A algorithm module available part of the main code base,
>>> and we consider open source 3A modules our 'first class citizens' and
>>> we're willing to develop and maintain them in libcamera mainline
>>> branch as free software, but at this point we have to provide a way for
>>> third-parties to load binary modules if they want to.
>>>
>>> The alternative is to have them continue developing camera stacks
>>> fully behind closed doors as it has been done so far.
>>
>> OK, I see, thanks for explaining the context.
>>
>>> As said, modules not built against the libcamera sources will not be
>>> signed, as they are distributed by other means by a vendor in binary
>>> form. To establish if a module has been built with the libcamera
>>> sources or not, we sign it during the build with a volatile key and
>>> validate the signature at run-time, when the IPA module is loaded.
>>>
>>> IPA modules for which the signature is not valid (either because they
>>> are distributed as binaries or, as in this case, because the build
>>> system strips symbols before installing the objects) are loaded in an
>>> isolated process and instead of being operated with direct function
>>> calls, we have implemented an IPC mechanism to communicate with them.
>>> This path is way less tested by our regular users and in our daily
>>> work on libcamera. Vendors that are running their binaries as isolated
>>> might have fixed issues here and there but maybe they have not
>>> reported the issue and the associated fix upstream (we have no control
>>> over this).
>>>
>>> For this reason I don't suggest running modules as isolated, even more
>>> if you have no reasons to do so. If all it takes is re-signing IPA modules
>>> after stripping them as Andrew did I would really consider doing that.
>>
>> Yeah, got it.  The other option, with the understanding that IPA modules
>> are all going to be free software here, would be to dismiss both the
>> authentication and the isolation mechanism, possibly with a custom
>> patch.  It seems like the change wouldn’t be too intrusive and it would
>> solve the problem for “grafts” as well (grafts modify files in a
>> non-functional way).
>
> On 2024-09-02 10:45, Andrew Tropin via Bug reports for GNU Guix wrote:
>> Anyway, I think the current most reasonable solution is to remove
>> signing step at all, because the signaturs will be invalidated by
>> grafting anyway and make it work somehow (either by loading in
>> isolation if it's possible or by loading unsigned libraries without
>> signature check directly).
>
> Everything indicates that we need to disable module authentication.
>
> Jacopo, I think I'll patch IPAManager::isSignatureValid to always return
> true.
>
> https://git.libcamera.org/libcamera/libcamera.git/tree/src/libcamera/ipa_manager.cpp#n285
>
> Like that:
>
> From c99706475cde3d963a17f4f8871149711ce6c467 Mon Sep 17 00:00:00 2001
> From: Andrew Tropin 
> Date: Wed, 4 Sep 2024 21:36:16 +0400
> Subject: [PATCH] libcamera: ipa_manager: Disable signature verification
>
> ---
>  src/libcamera/ipa_manager.cpp | 28 +---
>  1 file changed, 5 insertions(+), 23 deletions(-)
>
> diff --git a/src/libcamera/ipa_manager.cpp b/src/libcamera/ipa_manager.cpp
> index cfc24d38..4fd3cf3e 100644
> --- a/src/libcamera/ipa_manager.cpp
> +++ b/src/libcamera/ipa_manager.cpp
> @@ -284,33 +284,15 @@ IPAModule *IPAManager::module(PipelineHandler *pipe, 
> uint32_t minVersion,
>  
>  bool IPAManager::isSignatureValid([[maybe_unused]] IPAModule *ipa) const
>  {
> -#if HAVE_IPA_PUBKEY
> - char *force = utils::secure_getenv("LIBCAMERA_IPA_FORCE_ISOLATION");
> - if (force && force[0] != '\0') {
> - LOG(IPAManager, Debug)
> - << "Isolation of IPA module " << ipa->path()
> - << " forced through environment variable";
> - return false;
> - }
> -
> - File file{ ipa->path() };
> - if (!file.open(File::OpenModeFlag::ReadOnly))
> - return false;
> -
> - Span data = file.map();
> - if (data.empty())
> - return false;
> -
> - bool valid = pubKey_.verify(data, ipa->signature());
> + LOG(IPAManager, Debug)
> + << "Signature verification is disabled by Guix. "
> + << "See h

bug#72828: Grafting breaks libcamera signatures

2024-09-05 Thread Jacopo Mondi 
Hi Andrew, Ludovic,

On Wed, Sep 04, 2024 at 09:42:17PM GMT, Andrew Tropin wrote:
> On 2024-09-04 18:42, Ludovic Courtès wrote:
>
> > Hi Jacopo,
> >
> > Jacopo Mondi  skribis:
> >
> >> Not exactly. In libcamera, apart from creating a library to ease all
> >> the camera stack plumbing, we're creating an ecosystem of open-source
> >> 3A algorithms (what we call the IPA modules).
> >>
> >> Camera vendors and ODMs which invested in products with specific
> >> camera features, consider 3A algorithms and their tuning their secret
> >> sauce and are usually not willing to consider releasing them as open
> >> source with, fortunately, notable exceptions such as RaspberryPi
> >>
> >> Please note that all the platforms libcamera supports have an
> >> open-source 3A algorithm module available part of the main code base,
> >> and we consider open source 3A modules our 'first class citizens' and
> >> we're willing to develop and maintain them in libcamera mainline
> >> branch as free software, but at this point we have to provide a way for
> >> third-parties to load binary modules if they want to.
> >>
> >> The alternative is to have them continue developing camera stacks
> >> fully behind closed doors as it has been done so far.
> >
> > OK, I see, thanks for explaining the context.
> >
> >> As said, modules not built against the libcamera sources will not be
> >> signed, as they are distributed by other means by a vendor in binary
> >> form. To establish if a module has been built with the libcamera
> >> sources or not, we sign it during the build with a volatile key and
> >> validate the signature at run-time, when the IPA module is loaded.
> >>
> >> IPA modules for which the signature is not valid (either because they
> >> are distributed as binaries or, as in this case, because the build
> >> system strips symbols before installing the objects) are loaded in an
> >> isolated process and instead of being operated with direct function
> >> calls, we have implemented an IPC mechanism to communicate with them.
> >> This path is way less tested by our regular users and in our daily
> >> work on libcamera. Vendors that are running their binaries as isolated
> >> might have fixed issues here and there but maybe they have not
> >> reported the issue and the associated fix upstream (we have no control
> >> over this).
> >>
> >> For this reason I don't suggest running modules as isolated, even more
> >> if you have no reasons to do so. If all it takes is re-signing IPA modules
> >> after stripping them as Andrew did I would really consider doing that.
> >
> > Yeah, got it.  The other option, with the understanding that IPA modules
> > are all going to be free software here, would be to dismiss both the
> > authentication and the isolation mechanism, possibly with a custom
> > patch.  It seems like the change wouldn’t be too intrusive and it would
> > solve the problem for “grafts” as well (grafts modify files in a
> > non-functional way).
>
> On 2024-09-02 10:45, Andrew Tropin via Bug reports for GNU Guix wrote:
> > Anyway, I think the current most reasonable solution is to remove
> > signing step at all, because the signaturs will be invalidated by
> > grafting anyway and make it work somehow (either by loading in
> > isolation if it's possible or by loading unsigned libraries without
> > signature check directly).
>
> Everything indicates that we need to disable module authentication.
>
> Jacopo, I think I'll patch IPAManager::isSignatureValid to always return
> true.
>
> https://git.libcamera.org/libcamera/libcamera.git/tree/src/libcamera/ipa_manager.cpp#n285
>
> Like that:
>


>
> Everyone is ok with it?

At this point is a distro decision, either if you prefer to carry an
out-of-tree patch in your tree or tweak the build system.

Be aware that, sooner or later, the signature mechanism will be reworked and
your custom patch might not apply anymore.

Up to you :)

>
> --
> Best regards,
> Andrew Tropin





signature.asc
Description: PGP signature

bug#71936: [Cuirass] ‘cuirass remote-server’ crashes badly when it receives garbage

2024-09-05 Thread Ludovic Courtès 
Ludovic Courtès  skribis:

> 2024-07-01 13:33:38 In cuirass/scripts/remote-server.scm:
> 2024-07-01 13:33:38 430:6 11 (serve-build-requests _ #< getq: 
> # 
> #))> getq-gc-counter: # value: 22> putq: # putq-gc-counter: 
> #>)
> 2024-07-01 13:33:38 In ice-9/boot-9.scm:
> 2024-07-01 13:33:38   1752:10 10 (with-exception-handler _ _ #:unwind? _ 
> #:unwind-for-type _)
> 2024-07-01 13:33:38 In cuirass/scripts/remote-server.scm:
> 2024-07-01 13:33:38436:25  9 (_)
> 2024-07-01 13:33:38 In cuirass/remote.scm:
> 2024-07-01 13:33:38483:41  8 (receive-message _ #:router? _)
> 2024-07-01 13:33:38 In ice-9/iconv.scm:
> 2024-07-01 13:33:38 75:20  7 (bytevector->string _ _ _)
> 2024-07-01 13:33:38 In ice-9/rdelim.scm:
> 2024-07-01 13:33:38160:18  6 (read-string _)
> 2024-07-01 13:33:38 In ice-9/suspendable-ports.scm:
> 2024-07-01 13:33:38591:33  5 (read-char _)
> 2024-07-01 13:33:38522:13  4 (peek-char-and-next-cur/iconv # string 7f5cd6c72150>)
> 2024-07-01 13:33:38 In unknown file:
> 2024-07-01 13:33:383 (port-decode-char # 7f5cd6c72150> #vu8(130 163 101 110 99 165 99 108 101 97 114 164 108 111 97 
> 100 129 163 99 109 100 175 95 112 114 101 112 95 97 117 116 104 95 105 110 
> 102 111 0 0 0 160 162 141 207 92 127 0 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 21 0 
> 0 0 0 0 0 0 96 163 159 214 92 127 0 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 21 0 0 
> 0 0 0 0 0 192 162 141 207 92 127 0 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 95 160 
> 108 42 163 128 255 255 0 0 0 0 0 0 0 0 95 139 120 42 163 128 255 # ?) ?)
> 2024-07-01 13:33:38 In ice-9/boot-9.scm:
> 2024-07-01 13:33:38   1685:16  2 (raise-exception _ #:continuable? _)
> 2024-07-01 13:33:38   1683:16  1 (raise-exception _ #:continuable? _)
> 2024-07-01 13:33:38   1685:16  0 (raise-exception _ #:continuable? _)
> 2024-07-01 13:33:38 ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> 2024-07-01 13:33:38 Throw to key `decoding-error' with args `("decode-char" 
> "input decoding error" 84 #)'.

Fixed in Cuirass commit fbfbc6641cadfa15d3cc05c11b0d46ee1278a6c6.

I’ll update the ‘cuirass’ package soonish.

Ludo’.

bug#72917: ffmpeg@{3,4,5} build failures on i686-linux

2024-09-05 Thread Ludovic Courtès 
Hello,

André Batista  skribis:

> Fixes .
>
> * gnu/packages/video.scm (ffmpeg-5): Replace 'bypass-openal-check
> string substitution with one that matches on this and earlier
> versions of ffmpeg.
> (ffmpeg-4): Inherit package arguments from ffmpeg-5.
>
> Reported-by: Dariqq 
>
> Change-Id: Ie5b51a174be45b511757dece369563975e498bac

As it turns out, while all 3 variants built fine for i686 on a machine
of mine, there are test failures at ci.guix:

>From :

--8<---cut here---start->8---
--- ./tests/ref/fate/filter-lavd-scalenorm  2023-11-09 23:38:51.0 
+
+++ tests/data/fate/filter-lavd-scalenorm   2024-09-04 17:57:08.701821746 
+
@@ -1,15 +0,0 @@
-#tb 0: 1/5
-#media_type 0: video
-#codec_id 0: rawvideo
-#dimensions 0: 128x96
-#sar 0: 1/1
-0,  0,  0,1,18432, 0xac484db5
-0,  1,  1,1,18432, 0x94734db6
-0,  2,  2,1,18432, 0x3fac4db3
-0,  3,  3,1,18432, 0x37a94dcd
-0,  4,  4,1,18432, 0x2b3e4dbb
-0,  5,  5,1,18432, 0xd23a67bf
-0,  6,  6,1,18432, 0x898368e1
-0,  7,  7,1,18432, 0x79466438
-0,  8,  8,1,18432, 0x458c5d95
-0,  9,  9,1,18432, 0x9d9a56ee
Test filter-lavd-scalenorm failed. Look at 
tests/data/fate/filter-lavd-scalenorm.err for details.
make: *** [tests/Makefile:304: fate-filter-lavd-scalenorm] Error 1
make: *** Waiting for unfinished jobs
TESTfilter-refcmp-psnr-rgb

Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("fate" "-j" "24") 
exit-status: 2 term-signal: #f stop-signal: #f> 
phase `check' failed after 8.7 seconds
command "make" "fate" "-j" "24" failed with status 2
build process 18 exited with status 256
builder for `/gnu/store/7wsa154li4w974z2p6qnaaw97ng9m8hq-ffmpeg-5.1.4.drv' 
failed with exit code 1
--8<---cut here---end--->8---

And from :

--8<---cut here---start->8---
--- ./tests/ref/lavf/fits   1970-01-01 00:00:01.0 +
+++ tests/data/fate/lavf-fits   2024-09-04 17:57:17.900035764 +
@@ -1,9 +1,9 @@
 ed9fd697d0d782df6201f6a2db184552 *./tests/data/lavf/graylavf.fits
 5328000 ./tests/data/lavf/graylavf.fits
-./tests/data/lavf/graylavf.fits CRC=0xbacf446c
+./tests/data/lavf/graylavf.fits CRC=0xeb450e41
 48e6caf6a59e32f9a8a39979c9183a7f *./tests/data/lavf/gray16belavf.fits
 10368000 ./tests/data/lavf/gray16belavf.fits
-./tests/data/lavf/gray16belavf.fits CRC=0xae2b58d4
+./tests/data/lavf/gray16belavf.fits CRC=0xcc6d0df7
 be2f7112fd193c9a909304c81e662769 *./tests/data/lavf/gbrplavf.fits
 15408000 ./tests/data/lavf/gbrplavf.fits
 ./tests/data/lavf/gbrplavf.fits CRC=0x04ed3828
TESTfilter-pixdesc-yuv422p
TESTfilter-pixdesc-yuv444p
Test lavf-fits failed. Look at tests/data/fate/lavf-fits.err for details.
make: *** [tests/Makefile:226: fate-lavf-fits] Error 1
make: *** Waiting for unfinished jobs

Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("fate" "-j" "24") 
exit-status: 2 term-signal: #f stop-signal: #f> 
phase `check' failed after 17.3 seconds
command "make" "fate" "-j" "24" failed with status 2
build process 18 exited with status 256
builder for `/gnu/store/90fv07zbjc92dscaj42c2yzrqpl1qlza-ffmpeg-3.4.13.drv' 
failed with exit code 1
--8<---cut here---end--->8---

Are you seeing this?  Does the Internet have something to say about
these?

Thanks,
Ludo’.

bug#67535: Does anyone use i686-linux? [was Re: bug#67535: ci.guix.gnu.org 'Cannot allocate memory' while building for i686-linux]

2024-09-05 Thread Ricardo Wurmus 
André Batista  writes:

>> > Keeping this to i686-linux specifically, what generation of hardware
>> > supports i686 but not x86_64? Some (very) quick checking on wikipedia
>> > suggests that the x60 from 2006 was either 32-bit or 64-bit, and I
>> > believe there was an atom chip from 2015 that was 32-bit. Specifically,
>> > that makes the newest hardware (at least from the CPU perspective) 10
>> > years old at least.
>> 
>> FWIW, I'm using one of those Atom chips in a netbook for an installation
>> of Sugar Desktop.  I upgrade it every few months or so.  If I'm the only
>> user of i686-linux I would not want to condemn the project to supporting
>> the architecture for my sake.
>
> For the record, I'm another one still using those atom netbooks.

I just noticed that my Atom-powered netbook should also be able to run
an x86_64 system.  I'll try to upgrade today; if this is successful I
won't have any i686 system left at home.

-- 
Ricardo

bug#57005: Close

2024-09-05 Thread Andreas Enge 
Hello Lars,

apologies for my lack of engagement.

If I understood things correctly, Ludovic's recent patch from
https://issues.guix.gnu.org/72877 solves the reproducibility issue.
So I am closing this bug. If I am mistaken, please feel free to reopen it
with an updated patch.

Thanks,

Andreas

bug#73039: guile is not reproducible

2024-09-05 Thread lgcoelho--- via Bug reports for GNU Guix 
Hello, I've been dealing with really annoying errors recently, most of 
them related to this:

--8<---cut here---start->8---

guile: warning: failed to install locale

--8<---cut here---end--->8---

This led me to running guix challenge on guile, and I discovered it 
isn't reproducible as for now.


--8<---cut here---start->8---

+radio at buer in scm/guix > guix challenge guile
/gnu/store/mfkz7fvlfpv3ppwbkv0imb19nrf95akf-guile-3.0.9 contents differ:
  local hash: 15294835c2mnmg5q07l0k57l9iy0k0nj0z2kyi21r2ypdsq0qdii
  
https://ci.guix.gnu.org/nar/lzip/mfkz7fvlfpv3ppwbkv0imb19nrf95akf-guile-3.0.9: 
0gv6wj2wyp6ar2bxardcbd3p1vvhva2rlkabmnki5ybclk5q4m45
  
https://bordeaux.guix.gnu.org/nar/lzip/mfkz7fvlfpv3ppwbkv0imb19nrf95akf-guile-3.0.9: 
15294835c2mnmg5q07l0k57l9iy0k0nj0z2kyi21r2ypdsq0qdii

  differing file:
/lib/guile/3.0/ccache/ice-9/ftw.go

1 store items were analyzed:
  - 0 (0.0%) were identical
  - 1 (100.0%) differed
  - 0 (0.0%) were inconclusive

--8<---cut here---end--->8---

Is there any temporary solution for the locale issue? Repulling and/or 
reconfiguring the home environment doesn't solve it.


Thanks for the attention

bug#73039: (no subject)

2024-09-05 Thread lgcoelho 
Reading the documentation I managed to solve the locale problem using 
`make-glibc-utf8-locales` and declaring `GUIX_LOCPATH`, but it never has 
been needed before in my almost 2 years of Guix. I would like to 
understand why this now.

bug#72042: [PATCH 1/1] gnu: python-gst: Fix build.

2024-09-05 Thread Andrew Tropin via Bug reports for GNU Guix 
On 2024-09-02 21:38, Remco van 't Veer wrote:

> * gnu/packages/glib.scm: Add package python-pygobject-3.48.
> * gnu/packages/gstreamer.scm (python-gst) [inputs]:
>   Use python-pygobject-3.48 to fix tests.
>
> Change-Id: I3038b85db67ff354a6d77708fa4fd7c63aa6732c
> ---
>  gnu/packages/glib.scm  | 15 +++
>  gnu/packages/gstreamer.scm |  3 ++-
>  2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scm
> index 9827856f32..d6275ea63e 100644
> --- a/gnu/packages/glib.scm
> +++ b/gnu/packages/glib.scm
> @@ -20,6 +20,7 @@
>  ;;; Copyright © 2022 Petr Hodina 
>  ;;; Copyright © 2023 Saku Laesvuori 
>  ;;; Copyright © 2024 Zheng Junjie <873216...@qq.com>
> +;;; Copyright © 2024 Remco van 't Veer 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -1077,6 +1078,20 @@ (define-public python-pygobject
>   '((upstream-name . "pygobject")))
>  (license license:lgpl2.1+)))
>  
> +(define-public python-pygobject-3.48
> +  (package
> +(inherit python-pygobject)
> +(version "3.48.2")
> +(source
> + (origin
> +   (inherit (package-source python-pygobject))
> +   (uri (string-append "mirror://gnome/sources/pygobject/"
> +   (version-major+minor version)
> +   "/pygobject-" version ".tar.xz"))
> +   (sha256
> +(base32
> + "19yii8lydnjw225k4gclhn8hya7caiginqi0mj9a0cdym6sax507"))
> +
>  (define-public perl-glib
>(package
>  (name "perl-glib")
> diff --git a/gnu/packages/gstreamer.scm b/gnu/packages/gstreamer.scm
> index ad08285181..66978fc2bc 100644
> --- a/gnu/packages/gstreamer.scm
> +++ b/gnu/packages/gstreamer.scm
> @@ -11,6 +11,7 @@
>  ;;; Copyright © 2020 Liliana Marie Prikler 
>  ;;; Copyright © 2020 Michael Rohleder 
>  ;;; Copyright © 2023 Maxim Cournoyer 
> +;;; Copyright © 2024 Remco van 't Veer 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -1126,7 +1127,7 @@ (define-public python-gst
>  (native-inputs
>   (list pkg-config python))
>  (propagated-inputs
> - (list gst-plugins-base python-pygobject))
> + (list gst-plugins-base python-pygobject-3.48))
>  (home-page "https://gstreamer.freedesktop.org/";)
>  (synopsis "GStreamer GObject Introspection overrides for Python")
>  (description

Thank you!  Applied the fix, pushed as
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=7d2ced8d6d

-- 
Best regards,
Andrew Tropin


signature.asc
Description: PGP signature

bug#73052: emacs 30 ssh: couldn't find a proper `ls' command

2024-09-05 Thread Christopher Howard 
Hi, I've recently started using emacs 30 which I compile from source. Something 
that broke in the switch from emacs 29->30 is I am not able to use tramp to ssh 
into any of my guix servers. I get this error

```
Debugger entered--Lisp error: (file-error "Couldn't find a proper `ls' command")
```

I reported this as an Emacs bug - 72861 - and based on the data I provided -- 
full backtrace, etc. -- they indicated it was a guix bug. They pointed me to 
guix bug 64534.

However, I tried adding the appropriate directory to tramp-remote-path 
(/run/current-system/profile/bin) and that did not work.

If I switch back to 29.4 then I can access my servers again normally through 
tramp.

Here is my system information:

```
christopher@theoden 
--- 
OS: Guix System x86_64 
Host: OptiPlex 9020 00 
Kernel: 5.15.161-gnu 
Uptime: 63 days, 19 hours, 14 mins 
Packages: 167 (guix-system), 251 (guix-user) 
Shell: bash 5.1.16 
Resolution: 1920x1080 
DE: GNOME 
Theme: Adwaita [GTK2/3] 
Icons: Adwaita [GTK2/3] 
Terminal: guix 
CPU: Intel i5-4570 (4) @ 3.600GHz 
GPU: AMD ATI Radeon HD 8490 / R5 235X OEM 
GPU: Intel HD Graphics 
Memory: 5038MiB / 15914MiB 
```

``` guix describe
Generation 143  Sep 03 2024 10:14:51(current)
  guix 82174b2
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 82174b2742c2a59fd7959ba9acc80edd6f93d9f7
```

The emacs version I am testing is:

GNU Emacs 30.0.90 (build 5, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, cairo 
version 1.18.0) of 2024-09-03


-- 
📛 Christopher Howard
🚀 gemini://gem.librehacker.com
🌐 http://gem.librehacker.com

בראשית ברא אלהים את השמים ואת הארץ

bug#72780: [PATCH] gnu: emacs-treemacs: add missing package to propagated-inputs

2024-09-05 Thread Nicolas Goaziou via Bug reports for GNU Guix 
Hello,

Rodrigo Morales  writes:

> This is the first time I'm sending a patch to the guix project. If this
> is not the correct way to send patches to Guix, please let me know so
> that I don't make the same mistake in the future.

Thank you for your contribution.

I'm surprised it arrived in the wrong mailing list. Did you follow the
steps mentioned in the manual (at "(guix) Submitting Patches"), or
arguably better, used mumi?

Anyhow I applied your patch. I just reordered inputs alphabetically.

Regards,
-- 
Nicolas Goaziou

bug#72917: ffmpeg@{3,4,5} build failures on i686-linux

2024-09-05 Thread Dariqq 

Hi,

On 05.09.24 09:25, Ludovic Courtès wrote:

Hello,




As it turns out, while all 3 variants built fine for i686 on a machine
of mine, there are test failures at ci.guix:

 From :

--8<---cut here---start->8---
--- ./tests/ref/fate/filter-lavd-scalenorm  2023-11-09 23:38:51.0 
+
+++ tests/data/fate/filter-lavd-scalenorm   2024-09-04 17:57:08.701821746 
+
@@ -1,15 +0,0 @@
-#tb 0: 1/5
-#media_type 0: video
-#codec_id 0: rawvideo
-#dimensions 0: 128x96
-#sar 0: 1/1
-0,  0,  0,1,18432, 0xac484db5
-0,  1,  1,1,18432, 0x94734db6
-0,  2,  2,1,18432, 0x3fac4db3
-0,  3,  3,1,18432, 0x37a94dcd
-0,  4,  4,1,18432, 0x2b3e4dbb
-0,  5,  5,1,18432, 0xd23a67bf
-0,  6,  6,1,18432, 0x898368e1
-0,  7,  7,1,18432, 0x79466438
-0,  8,  8,1,18432, 0x458c5d95
-0,  9,  9,1,18432, 0x9d9a56ee
Test filter-lavd-scalenorm failed. Look at 
tests/data/fate/filter-lavd-scalenorm.err for details.
make: *** [tests/Makefile:304: fate-filter-lavd-scalenorm] Error 1
make: *** Waiting for unfinished jobs
TESTfilter-refcmp-psnr-rgb

Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("fate" "-j" "24") 
exit-status: 2 term-signal: #f stop-signal: #f>
phase `check' failed after 8.7 seconds
command "make" "fate" "-j" "24" failed with status 2
build process 18 exited with status 256
builder for `/gnu/store/7wsa154li4w974z2p6qnaaw97ng9m8hq-ffmpeg-5.1.4.drv' 
failed with exit code 1
--8<---cut here---end--->8---

And from :

--8<---cut here---start->8---
--- ./tests/ref/lavf/fits   1970-01-01 00:00:01.0 +
+++ tests/data/fate/lavf-fits   2024-09-04 17:57:17.900035764 +
@@ -1,9 +1,9 @@
  ed9fd697d0d782df6201f6a2db184552 *./tests/data/lavf/graylavf.fits
  5328000 ./tests/data/lavf/graylavf.fits
-./tests/data/lavf/graylavf.fits CRC=0xbacf446c
+./tests/data/lavf/graylavf.fits CRC=0xeb450e41
  48e6caf6a59e32f9a8a39979c9183a7f *./tests/data/lavf/gray16belavf.fits
  10368000 ./tests/data/lavf/gray16belavf.fits
-./tests/data/lavf/gray16belavf.fits CRC=0xae2b58d4
+./tests/data/lavf/gray16belavf.fits CRC=0xcc6d0df7
  be2f7112fd193c9a909304c81e662769 *./tests/data/lavf/gbrplavf.fits
  15408000 ./tests/data/lavf/gbrplavf.fits
  ./tests/data/lavf/gbrplavf.fits CRC=0x04ed3828
TESTfilter-pixdesc-yuv422p
TESTfilter-pixdesc-yuv444p
Test lavf-fits failed. Look at tests/data/fate/lavf-fits.err for details.
make: *** [tests/Makefile:226: fate-lavf-fits] Error 1
make: *** Waiting for unfinished jobs

Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #<&invoke-error program: "make" arguments: ("fate" "-j" "24") 
exit-status: 2 term-signal: #f stop-signal: #f>
phase `check' failed after 17.3 seconds
command "make" "fate" "-j" "24" failed with status 2
build process 18 exited with status 256
builder for `/gnu/store/90fv07zbjc92dscaj42c2yzrqpl1qlza-ffmpeg-3.4.13.drv' 
failed with exit code 1
--8<---cut here---end--->8---

Are you seeing this?  Does the Internet have something to say about
these?



ffmpeg@5 builds without issues for me. For ffmpeg@3 the tests always 
fail at the lavf-fits tests same as the ci system.


For ffmpeg@4 which has by far the most dependants (including things like 
webkitgtk etc) i have no test issues.



Thanks,
Ludo’.


I hope this helps,
Dariqq

bug#73059: Flatpak is vulnerable to CVE-2024-42472

2024-09-05 Thread DonaldSanders1968 via Bug reports for GNU Guix 
Hi Guix,

Current flatpak version in Guix channel is affected by 
[CVE-2024-42472](https://github.com/flatpak/flatpak/security/advisories/GHSA-7hgv-f2j8-xw87).

Kind regards,
Donald

bug#72968: Patches applied

2024-09-05 Thread Andreas Enge 
Hello,

I have applied Carlos's second patch of
   https://issues.guix.gnu.org/72943
which gives an explanation why we skip the tests,
and Noé's patch of
   https://issues.guix.gnu.org/72968
adding the missing inputs.

As php currently does not build after the core-updates merge and this issue
has been turning up regularly over the past few days, I have taken the
liberty to push the commits directly without going through QA; I have
tested that the package builds and works with one of my local php projects.

I am closing the second issue, which is thus handled.
And I am leaving the first issue open; while the immediate php problem is
(hopefully) solved, it remains to be discussed whether we should propagate
the gd inputs in the longer term.

My understanding is that given the pkg-config file, we normally would
propagate the inputs. On the other hand, propagated inputs tend to create
problems (for instance, when two different packages propagate two different
versions of the same input library); and I do not quite understand why
with over 5000 packages depending on gd, most of them do not seem to be
affected. Maybe these do not use pkg-config to check for gd?
So it may be a better option to only patch the affected packages (if any
are left) and leave gd as it is.

Andreas

bug#52150: childsplay: ImportError

2024-09-05 Thread Nicolas Goaziou via Bug reports for GNU Guix 
Hello,

> Hi, after running guix pull today, I tried to run childsplay (using guix
> shell) but get an error:

Childsplay is no longer provided by Guix. I'm closing this bug report.

Thanks!

Regards,
-- 
Nicolas Goaziou

bug#73009: Close

2024-09-05 Thread Andreas Enge 
Hello Christopher,

thanks for the report!

This is a well-known problem after the core-updates merge, see
   https://issues.guix.gnu.org/72943

Hopefully it has just been fixed by my last two commits; please do a
   guix pull
and give it another try.

Andreas

bug#73062: Wrong name for org.jackaudio.service

2024-09-05 Thread Ricardo Wurmus 
I see this in my /var/log/messages file:

Sep  5 23:20:35 localhost dbus-daemon[938]: [system] Service file 
"/gnu/store/8hjpbskyk9k9kd3mlzj24xy0rzym5in5-jack2-1.9.21/share/dbus-1/services/org.jackaudio.service"
 should have been named "org.jackaudio.service.service" and will not work with 
system bus activation

The contents of the file:

--8<---cut here---start->8---
[D-BUS Service]
Name=org.jackaudio.service
Exec=/gnu/store/8hjpbskyk9k9kd3mlzj24xy0rzym5in5-jack2-1.9.21/bin/jackdbus auto
--8<---cut here---end--->8---

I assume that the file name must be the value of the "Name" field
followed by ".service".  So the file would either have to be named
"org.jackaudio.service.service", or the value of the "Name" field would
need to be changed to "org.jackaudio".

What do other distros do here?

-- 
Ricardo

bug#72990: Core packages updated broke Guix

2024-09-05 Thread Preston Miller Firestone 



Thanks Ludo, by removing the value configured in LD_LIBRARY_PATH you can
rebuild the entire system without problems and Guix worked well again.


I can also confirm: I was having this same problem on the same update 
and unsetting LD_LIBRARY_PATH also fixed it for me. I was then able to 
run `guix pull` and everything was good again.


Thanks Ludo for the fix! I wonder how LD_LIBRARY_PATH got set in the 
first place? I'm running Guix system.


Thanks,

Preston


OpenPGP_0xB01943DB9465BC4F.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#67685: ‘guix shell --export-manifest’ ignores transformations for ‘-D’ packages

2024-09-05 Thread Evgenii Klimov via Bug reports for GNU Guix 
I think that transformations should be applied to `-D --file'
combination as well (probably to `-D --manifest' too).

It would support the following use case (this is the reason I fould this
very bug).  When we have a project under development which is controlled
by guix.scm file and we want to try out the dependency from another fork
or branch, it would be useful for transformations to be propagated to
inputs/propagated-inputs/etc. inside guix.scm file.

Currently it doesn't apply transformations:

--8<---cut here---start->8---
guix shell -D -f guix.scm \
 
--with-git-url=python-pytelegrambotapi=https://github.com/coder2020official/pyTelegramBotAPI
 \
 --with-branch=python-pytelegrambotapi=polling-improvements
--8<---cut here---end--->8---

However it does propagate:

--8<---cut here---start->8---
guix shell -f guix.scm \
 
--with-git-url=python-pytelegrambotapi=https://github.com/coder2020official/pyTelegramBotAPI
 \
 --with-branch=python-pytelegrambotapi=polling-improvements
--8<---cut here---end--->8---

and this, when dependency is mentioned explicitly:

--8<---cut here---start->8---
guix shell -D -f guix.scm python-pytelegrambotapi \
 
--with-git-url=python-pytelegrambotapi=https://github.com/coder2020official/pyTelegramBotAPI
 \
 --with-branch=python-pytelegrambotapi=polling-improvements
--8<---cut here---end--->8---

bug#72917: ffmpeg@{3,4,5} build failures on i686-linux

2024-09-05 Thread André Batista 
Hi,

qui 05 set 2024 às 09:25:36 (1725539136), l...@gnu.org enviou:
> Hello,
> 
> As it turns out, while all 3 variants built fine for i686 on a machine
> of mine, there are test failures at ci.guix:
> 
> From :
> 
> --8<---cut here---start->8---
> --- ./tests/ref/fate/filter-lavd-scalenorm2023-11-09 23:38:51.0 
> +
> +++ tests/data/fate/filter-lavd-scalenorm 2024-09-04 17:57:08.701821746 
> +
> @@ -1,15 +0,0 @@
> -#tb 0: 1/5
> -#media_type 0: video
> -#codec_id 0: rawvideo
> -#dimensions 0: 128x96
> -#sar 0: 1/1
> -0,  0,  0,1,18432, 0xac484db5
> -0,  1,  1,1,18432, 0x94734db6
> -0,  2,  2,1,18432, 0x3fac4db3
> -0,  3,  3,1,18432, 0x37a94dcd
> -0,  4,  4,1,18432, 0x2b3e4dbb
> -0,  5,  5,1,18432, 0xd23a67bf
> -0,  6,  6,1,18432, 0x898368e1
> -0,  7,  7,1,18432, 0x79466438
> -0,  8,  8,1,18432, 0x458c5d95
> -0,  9,  9,1,18432, 0x9d9a56ee
> Test filter-lavd-scalenorm failed. Look at 
> tests/data/fate/filter-lavd-scalenorm.err for details.
> make: *** [tests/Makefile:304: fate-filter-lavd-scalenorm] Error 1
> make: *** Waiting for unfinished jobs
> TESTfilter-refcmp-psnr-rgb
> 
> Test suite failed, dumping logs.
> error: in phase 'check': uncaught exception:
> %exception #<&invoke-error program: "make" arguments: ("fate" "-j" "24") 
> exit-status: 2 term-signal: #f stop-signal: #f> 
> phase `check' failed after 8.7 seconds
> command "make" "fate" "-j" "24" failed with status 2
> build process 18 exited with status 256
> builder for `/gnu/store/7wsa154li4w974z2p6qnaaw97ng9m8hq-ffmpeg-5.1.4.drv' 
> failed with exit code 1
> --8<---cut here---end--->8---
> 
> And from :
> 
> --8<---cut here---start->8---
> --- ./tests/ref/lavf/fits 1970-01-01 00:00:01.0 +
> +++ tests/data/fate/lavf-fits 2024-09-04 17:57:17.900035764 +
> @@ -1,9 +1,9 @@
>  ed9fd697d0d782df6201f6a2db184552 *./tests/data/lavf/graylavf.fits
>  5328000 ./tests/data/lavf/graylavf.fits
> -./tests/data/lavf/graylavf.fits CRC=0xbacf446c
> +./tests/data/lavf/graylavf.fits CRC=0xeb450e41
>  48e6caf6a59e32f9a8a39979c9183a7f *./tests/data/lavf/gray16belavf.fits
>  10368000 ./tests/data/lavf/gray16belavf.fits
> -./tests/data/lavf/gray16belavf.fits CRC=0xae2b58d4
> +./tests/data/lavf/gray16belavf.fits CRC=0xcc6d0df7
>  be2f7112fd193c9a909304c81e662769 *./tests/data/lavf/gbrplavf.fits
>  15408000 ./tests/data/lavf/gbrplavf.fits
>  ./tests/data/lavf/gbrplavf.fits CRC=0x04ed3828
> TESTfilter-pixdesc-yuv422p
> TESTfilter-pixdesc-yuv444p
> Test lavf-fits failed. Look at tests/data/fate/lavf-fits.err for details.
> make: *** [tests/Makefile:226: fate-lavf-fits] Error 1
> make: *** Waiting for unfinished jobs
> 
> Are you seeing this?  Does the Internet have something to say about
> these?

No I did not see this here, all tests passed. I've tried searching
ffmpeg bug tracker and commit logs but nothing useful came up.

Is it possible to see that 'tests/data/fate/lavf-fits.err' file on
CI somehow? I don't actually expect it to be of much help though.

I also see errors on ffmpeg-3, as Dariqq mentioned, but looking at
the build history on CI it had also appeared on
 which was before
the core-updates merge, so it seems unrelated.