bug#47479: inkscape retains a reference to imagemagick, even though it is in native-inputs

[Efraim Flashner]

On Mon, Mar 29, 2021 at 05:16:01PM -0400, Mark H Weaver wrote:
> Hi Maxime,
> 
> Maxime Devos  writes:
> 
> > On
> > $ guix --version
> >> guix (GNU Guix) 510e24f973a918391d8122fd6ad515c0567bf23e
> >
> > with
> > $ guix graph --type=references inkscape
> >
> > it can be seen inkscape retains the reference to imagemagick,
> > even though imagemagick is in native-inputs.
> 
> I believe this is incorrect.  On my Guix system, I see this:
> 
> --8<---cut here---start->8---
> mhw@jojen ~$ guix package -I inkscape
> inkscape  0.92.4  out 
> /gnu/store/rx26f9xn14fng2gnzsigr74492lrkydl-inkscape-0.92.4
> mhw@jojen ~$ guix gc -R 
> /gnu/store/rx26f9xn14fng2gnzsigr74492lrkydl-inkscape-0.92.4 | grep -i 
> imagemagick
> --8<---cut here---end--->8---

It is the case for inkscape@1.0.2

(ins)efraim@3900XT ~$ guix package -A inkscape
inkscape1.0.2   out gnu/packages/inkscape.scm:121:2
inkscape0.92.4  out gnu/packages/inkscape.scm:56:2
(ins)efraim@3900XT ~$ guix gc --references $(guix build inkscape@1) | grep -i 
imagemagick
/gnu/store/y4rym48vihmh3jk9qnll0zqfnxzi9n6v-imagemagick-6.9.12-4

I believe it comes from the glib-or-gtk-wrap phase where it wraps the
XDG_DATA_DIRS and likely grabs more than it needs.

> I guess that "guix graph --type=references" is not a reliable indicator
> of what we need to check for.
> 
> FYI, this is what I do to check that my system and user profile do not
> have references to imagemagick:
> 
> --8<---cut here---start->8---
> mhw@jojen ~$ guix gc -R $(readlink /run/current-system) | grep -i imagemagick
> mhw@jojen ~$ guix gc -R $(readlink -f ~/.guix-profile) | grep -i imagemagick
> --8<---cut here---end--->8---
> 
> Regards,
>   Mark
> 
> 
> 

-- 
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#46871: [bug#47407] [PATCH] gnu: guix: Fix openrc init scripts.

[Efraim Flashner]

Thanks. Patch 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#47458: Terrible UX upgrading Emacs in Guix

[Ludovic Courtès]

Hello,

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:

[...]

>> Ouch.  “It used to be” (speaking like a veteran :-)) that Emacs in Guix
>> would not use EMACSLOADPATH.  Then we switched to EMACSLOADPATH, which
>> had some advantages, but necessarily has this drawback.
>>
>> IIUC,  is about possibly
>> backtracking.  Maxim, what’s the status of this one?
>
> It's abandoned, The MUMI tracker lacks the responses from Leo Prickler,
> but they had good arguments maintaining the status quo rather than going
> with the extra complexity.  It also wouldn't change the issue at hand;
> it'd merely prevent conflicts of *resources* files of Emacs packages
> (and somewhat integrate with the Emacs native package manager, while
> making the autoloading a bit slower).  It seems the price to pay is too
> high for such a small gain.  I'm closing it now.

I see, makes sense!

> On the other hand, this very problem was the motivation for this patch
> series here: https://issues.guix.gnu.org/43627, which would solve the
> issue ta hand.  You were skeptical of the benefits the last time you
> took a look at it; perhaps it's time to take a new look at it :-).

Ah!  Now I may have to revisit it, indeed.

Thanks for explaining!

Ludo’.

bug#47492: texlive: texlua fails to run

[Efraim Flashner]

Bug fixed with commit 9098745b181b3022587a35afd255f7ff1d41ac86.

-- 
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#47212: texlive: luatex missing shared library: libzzip-0.so.13

[Efraim Flashner]

Bug fixed with commit 9098745b181b3022587a35afd255f7ff1d41ac86.

-- 
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#47448: lualatex doesn't find libzzip-0.so.13 (easy bug?)

[Efraim Flashner]

Bug fixed with commit 9098745b181b3022587a35afd255f7ff1d41ac86.

-- 
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#46871: [bug#47407] [PATCH] gnu: guix: Fix openrc init scripts.

[zimoun]

Hi Efraim,

On Tue, 30 Mar 2021 at 09:32, Efraim Flashner  wrote:
>
> Thanks. Patch pushed.

Thanks.  Cheers,
simon

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

[zimoun]

Hi Léo,

On Tue, 30 Mar 2021 at 02:26, Léo Le Bouter  wrote:

> I pushed 00c67375b17f4a4cfad53399d1918f2e7eba2c7d to core-updates. Your
> patch. Thank you for it. Let's watch for upstream zstd fix also.

Thanks.  It mitigates zstd, even if it does not solve MariaDB.  One
foot, then another. :-)

> I pushed 9feef62b73e284e106717a386624d6da90750a3d to master.

Cool!  LTGM.

> Ubuntu released a patch in the mean time, so while we couldnt make such
> patch in a timely manner because the backport was non-trivial and
> security-sensitive also didnt want to risk failing to fix the flaw
> because I don't have much expertise on it, Ubuntu now has done that
> work and we can just use it.

Thanks for taking care.  And do not consider my concerns as a slowdown
but instead as a way to reach something better.  For instance
9feef62b73 seems The Right Thing (AFAIU), whereas 6f873731a0 and
2bcfb944bd are not (AFAIK).  On one hand, I agree that ~3 weeks
appears long through the lens of security vulnerabilities.  On the
other hand, it is usually worth to take the time; as here. :-)
Examine the various options and so the best move always takes time.

Well, thanks for pushing forward with security.

All the best,
simon

bug#47479: inkscape retains a reference to imagemagick, even though it is in native-inputs

[Mark H Weaver]

Hi Efraim,

Efraim Flashner  writes:
> It is the case for inkscape@1.0.2

I see now that I'm using an older version, although I would have
preferred the newer one.  I refer to the variable name 'inkscape' from
my manifest file, and I expected that to point to the latest stable
version.  However, it seems that one must use the 'inkscape-1.0'
variable to get the latest stable version.  That's seems suboptimal.

I wonder if the 'inkscape' variable should be renamed 'inkscape/stable'
(for use in packages such as 'dblatex/stable'), and then 'inkscape'
could be repurposed to point to the latest stable version.  Thoughts?

> (ins)efraim@3900XT ~$ guix package -A inkscape
> inkscape1.0.2   out gnu/packages/inkscape.scm:121:2
> inkscape0.92.4  out gnu/packages/inkscape.scm:56:2
> (ins)efraim@3900XT ~$ guix gc --references $(guix build inkscape@1) | grep -i 
> imagemagick
> /gnu/store/y4rym48vihmh3jk9qnll0zqfnxzi9n6v-imagemagick-6.9.12-4
>
> I believe it comes from the glib-or-gtk-wrap phase where it wraps the
> XDG_DATA_DIRS and likely grabs more than it needs.

Good catch!

So, for now, we shouldn't use 'imagemagick/stable' in 'inkscape', even
though it's in 'native-inputs'.  This shows that we'll have to be very
careful about this, at least until we have better tooling to catch these
problems automatically.

I think the fundamental problem here is that the build-side code cannot
distinguish between 'inputs' and 'native-inputs' unless you are
cross-compiling.  When compiling natively, the 'inputs' keyword argument
passed to the build phases includes the packages listed in the
'native-inputs' package field, and the 'native-inputs' keyword argument
is not passed at all.

This is why we must write (or native-inputs inputs) in so many places:
because to find the location of a package listed in the 'native-inputs'
package field from within build-side code, you must look in one of two
places depending on whether you're cross-compiling.  If you're
cross-compiling you must look in 'native-inputs'.  When compiling
natively, that argument doesn't even exist, and you must look in the
'inputs' keyword argument instead.

I don't know why it was done this way.  It seems to me an error-prone
design, but at this point it would be hard to change it.

Now we see another disadvantage.  The 'glib-or-gtk-wrap' phase should be
iterating over the 'inputs' but not the 'native-inputs'.  It's not
obvious how to fix this given the current design.

What do you think?

Regards,
  Mark

bug#45316: [WIP PATCH 1/3] profiles: Add hook for Emacs subdirs.

[Leo Prikler]

* guix/profiles.scm (emacs-subdirs): New variable.
(%default-profile-hooks): Add it here.
* guix/status.scm (hook-message): Add a message for emacs-subdirs.
---
 guix/profiles.scm | 41 +
 guix/status.scm   |  2 ++
 2 files changed, 43 insertions(+)

diff --git a/guix/profiles.scm b/guix/profiles.scm
index 67d90532c1..26fe266a61 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -1115,6 +1115,46 @@ MANIFEST.  Single-file bundles are required by programs 
such as Git and Lynx."
 `((type . profile-hook)
   (hook . ca-certificate-bundle
 
+(define (emacs-subdirs manifest)
+  (define build
+(with-imported-modules (source-module-closure
+'((guix build profiles)
+  (guix build utils)))
+  #~(begin
+  (use-modules (guix build utils)
+   (guix build profiles)
+   (ice-9 ftw) ; scandir
+   (srfi srfi-1) ; append-map
+   (srfi srfi-26))
+
+  (let ((destdir (string-append #$output "/share/emacs/site-lisp"))
+(subdirs
+ (append-map
+  (lambda (dir)
+(filter
+ file-is-directory?
+ (map (cute string-append dir "/" <>)
+  (scandir dir (negate (cute member <> '("." 
"..")))
+  (filter file-exists?
+  (map (cute string-append <> "/share/emacs/site-lisp")
+   '#$(manifest-inputs manifest))
+(mkdir-p destdir)
+(with-directory-excursion destdir
+  (call-with-output-file "subdirs.el"
+(lambda (port)
+  (write
+   `(normal-top-level-add-to-load-path
+ (list ,@subdirs))
+   port)
+  (newline port)
+  #t)))
+  (gexp->derivation "emacs-subdirs" build
+#:local-build? #t
+#:substitutable? #f
+#:properties
+`((type . profile-hook)
+  (hook . emacs-subdirs
+
 (define (glib-schemas manifest)
   "Return a derivation that unions all schemas from manifest entries and
 creates the Glib 'gschemas.compiled' file."
@@ -1672,6 +1712,7 @@ MANIFEST."
 fonts-dir-file
 ghc-package-cache-file
 ca-certificate-bundle
+emacs-subdirs
 glib-schemas
 gtk-icon-themes
 gtk-im-modules
diff --git a/guix/status.scm b/guix/status.scm
index d47bf1700c..ccde3d3063 100644
--- a/guix/status.scm
+++ b/guix/status.scm
@@ -379,6 +379,8 @@ the current build phase."
  (G_ "building GHC package cache..."))
 ('ca-certificate-bundle
  (G_ "building CA certificate bundle..."))
+('emacs-subdirs
+ (G_ "listing Emacs subdirs..."))
 ('glib-schemas
  (G_ "generating GLib schema cache..."))
 ('gtk-icon-themes
-- 
2.31.0

bug#45316: [WIP PATCH 2/3] build-system: emacs: Use subdirectories again.

[Leo Prikler]

With this, Emacs libraries are installed in the ELPA_NAME-VERSION subdirectory
of site-lisp and potential subdirectories should no longer collide.

* guix/build/emacs-build-system.scm (build, patch-el-files, make-autoloads):
Use ELPA name and version to construct subdirectories of %install-dir.
(install): Install in subdirectory.  Also create a subdirs.el, so that
emacs-build-system can find the library without needing to hack EMACSLOADPATH.
---
 guix/build/emacs-build-system.scm | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/guix/build/emacs-build-system.scm 
b/guix/build/emacs-build-system.scm
index 26ea59bc25..adc4861f02 100644
--- a/guix/build/emacs-build-system.scm
+++ b/guix/build/emacs-build-system.scm
@@ -96,10 +96,11 @@ environment variable\n" source-directory)))
   "Compile .el files."
   (let* ((emacs (string-append (assoc-ref inputs "emacs") "/bin/emacs"))
  (out (assoc-ref outputs "out"))
- (site-lisp (string-append out %install-dir)))
+ (elpa-name-ver (store-directory->elpa-name-version out))
+ (el-dir (string-append out %install-dir "/" elpa-name-ver)))
 (setenv "SHELL" "sh")
 (parameterize ((%emacs emacs))
-  (emacs-byte-compile-directory site-lisp
+  (emacs-byte-compile-directory el-dir
 
 (define* (patch-el-files #:key outputs #:allow-other-keys)
   "Substitute the absolute \"/bin/\" directory with the right location in the
@@ -116,7 +117,8 @@ store in '.el' files."
   #:binary #t))
 
   (let* ((out (assoc-ref outputs "out"))
- (site-lisp (string-append out %install-dir))
+ (elpa-name-ver (store-directory->elpa-name-version out))
+ (el-dir (string-append out %install-dir "/" elpa-name-ver))
  ;; (ice-9 regex) uses libc's regexp routines, which cannot deal with
  ;; strings containing NULs.  Filter out such files.  TODO: Remove
  ;; this workaround when  is fixed.
@@ -130,7 +132,7 @@ store in '.el' files."
  (error "patch-el-files: unable to locate " cmd-name))
(string-append "\"" cmd "\"")
 
-(with-directory-excursion site-lisp
+(with-directory-excursion el-dir
   ;; Some old '.el' files (e.g., tex-buf.el in AUCTeX) are still
   ;; ISO-8859-1-encoded.
   (unless (false-if-exception (substitute-program-names))
@@ -182,16 +184,22 @@ parallel. PARALLEL-TESTS? is ignored when using a 
non-make TEST-COMMAND."
 
   (let* ((out (assoc-ref outputs "out"))
  (site-lisp (string-append out %install-dir))
+ (elpa-name-ver (store-directory->elpa-name-version out))
+ (el-dir (string-append site-lisp "/" elpa-name-ver))
  (files-to-install (find-files source install-file?)))
 (cond
  ((not (null? files-to-install))
   (for-each
(lambda (file)
  (let* ((stripped-file (string-drop file (string-length source)))
-(target-file (string-append site-lisp stripped-file)))
+(target-file (string-append el-dir stripped-file)))
(format #t "`~a' -> `~a'~%" file target-file)
(install-file file (dirname target-file
files-to-install)
+  (call-with-output-file (string-append site-lisp "/subdirs.el")
+(lambda (port)
+  (write `(normal-top-level-add-to-load-path (list ,el-dir)) port)
+  (newline port)))
   #t)
  (else
   (format #t "error: No files found to install.\n")
@@ -219,11 +227,11 @@ parallel. PARALLEL-TESTS? is ignored when using a 
non-make TEST-COMMAND."
   "Generate the autoloads file."
   (let* ((emacs (string-append (assoc-ref inputs "emacs") "/bin/emacs"))
  (out (assoc-ref outputs "out"))
- (site-lisp (string-append out %install-dir))
  (elpa-name-ver (store-directory->elpa-name-version out))
- (elpa-name (package-name->name+version elpa-name-ver)))
+ (elpa-name (package-name->name+version elpa-name-ver))
+ (el-dir (string-append out %install-dir "/" elpa-name-ver)))
 (parameterize ((%emacs emacs))
-  (emacs-generate-autoloads elpa-name site-lisp
+  (emacs-generate-autoloads elpa-name el-dir
 
 (define* (enable-autoloads-compilation #:key outputs #:allow-other-keys)
   "Remove the NO-BYTE-COMPILATION local variable embedded in the generated
-- 
2.31.0

bug#45316: [WIP PATCH 3/3] gnu: emacs-libgit: Adjust to changes in emacs-build-system.

[Leo Prikler]

* gnu/packages/emacs-xyz.scm (emacs-libgit)[set-libgit--module-file]: Adjust
libgit--module-file path.
---
 gnu/packages/emacs-xyz.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index f45507c647..3712429651 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -500,7 +500,8 @@ on stdout instead of using a socket as the Emacsclient 
does.")
  (make-file-writable "libgit.el")
  (emacs-substitute-variables "libgit.el"
("libgit--module-file"
-(string-append out "/share/emacs/site-lisp/libegit2.so")))
+(string-append out "/share/emacs/site-lisp/"
+   "libgit-" ,version "/libegit2.so")))
  #t)))
(add-before 'install 'prepare-for-install
  (lambda _
-- 
2.31.0

bug#46769: guix pull fails when quoted symbol is the 'name' of dependent channel

[Ludovic Courtès]

Ozhap  skribis:

> So for eg, this:
>
> (channel
>  (version 0)
>  (dependencies
>   (channel
>(name 'some-collection)
>...
>)))
>
> ...as given in info:guix#Declaring_Channel_Dependencies causes 'guix
> pull' to fail ("channels.scm:719:22"). But when the value is unquoted:
>
> (channel
>  (version 0)
>  (dependencies
>   (channel
>(name some-collection)
>...
>)))
>
> ...it works fine.

Fixed in 52e64b21be50e2c5febd7bf1accd88ffdc05a4bb, thanks!

Ludo’.

bug#47479: inkscape retains a reference to imagemagick, even though it is in native-inputs

[Efraim Flashner]

On Tue, Mar 30, 2021 at 04:55:13AM -0400, Mark H Weaver wrote:
> Hi Efraim,
> 
> Efraim Flashner  writes:
> > It is the case for inkscape@1.0.2
> 
> I see now that I'm using an older version, although I would have
> preferred the newer one.  I refer to the variable name 'inkscape' from
> my manifest file, and I expected that to point to the latest stable
> version.  However, it seems that one must use the 'inkscape-1.0'
> variable to get the latest stable version.  That's seems suboptimal.
> 
> I wonder if the 'inkscape' variable should be renamed 'inkscape/stable'
> (for use in packages such as 'dblatex/stable'), and then 'inkscape'
> could be repurposed to point to the latest stable version.  Thoughts?

In the past we've kept the most up-to-date version as the 'main version'
and given the version suffix to the older version(s). Except for when
they all get version suffixes and then a separate (define rust
rust-1.45) package added.

> 
> > (ins)efraim@3900XT ~$ guix package -A inkscape
> > inkscape1.0.2   out gnu/packages/inkscape.scm:121:2
> > inkscape0.92.4  out gnu/packages/inkscape.scm:56:2
> > (ins)efraim@3900XT ~$ guix gc --references $(guix build inkscape@1) | grep 
> > -i imagemagick
> > /gnu/store/y4rym48vihmh3jk9qnll0zqfnxzi9n6v-imagemagick-6.9.12-4
> >
> > I believe it comes from the glib-or-gtk-wrap phase where it wraps the
> > XDG_DATA_DIRS and likely grabs more than it needs.
> 
> Good catch!
> 
> So, for now, we shouldn't use 'imagemagick/stable' in 'inkscape', even
> though it's in 'native-inputs'.  This shows that we'll have to be very
> careful about this, at least until we have better tooling to catch these
> problems automatically.
> 
> I think the fundamental problem here is that the build-side code cannot
> distinguish between 'inputs' and 'native-inputs' unless you are
> cross-compiling.  When compiling natively, the 'inputs' keyword argument
> passed to the build phases includes the packages listed in the
> 'native-inputs' package field, and the 'native-inputs' keyword argument
> is not passed at all.

I ran into this also with the cargo-build-system. I only wanted to
propagate regular inputs, not native inputs. It's probably worth
figuring out how to fix some of it on core-updates.

> This is why we must write (or native-inputs inputs) in so many places:
> because to find the location of a package listed in the 'native-inputs'
> package field from within build-side code, you must look in one of two
> places depending on whether you're cross-compiling.  If you're
> cross-compiling you must look in 'native-inputs'.  When compiling
> natively, that argument doesn't even exist, and you must look in the
> 'inputs' keyword argument instead.
> 
> I don't know why it was done this way.  It seems to me an error-prone
> design, but at this point it would be hard to change it.
> 
> Now we see another disadvantage.  The 'glib-or-gtk-wrap' phase should be
> iterating over the 'inputs' but not the 'native-inputs'.  It's not
> obvious how to fix this given the current design.
> 
> What do you think?

We can always try to make it better. In the mean time perhaps we can try
changing the way some of the wrappers work to only accept regular
inputs, or possibly to specify exactly which inputs to iterate over and
to use in the wrap phases.

> Regards,
>   Mark

-- 
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#47260: Package GNU MediaGoblin as a Guix service

[Ben Sturmfels via Bug reports for GNU Guix]

On Tue, 30 Mar 2021, Ben Sturmfels wrote:

>> 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!
>
> Discovered we'll also need to upgrade Guix's python-wtforms, but in the
> mean time, installing only wtforms, pytest, pytest-xdist, pytest-forked
> from PyPI allows us to pass the test suite 100% Getting closer!

Pytest issues have now been resolved. We now need ZERO packages from
PyPI for a basic install and full test suite run. :)

Regards,
Ben

bug#47480: gprolog: hash mismatch

[zimoun]

Hi,

On Mon, 29 Mar 2021 at 23:37, Ludovic Courtès  wrote:
> zimoun  skribis:
>
>> It is probably an upstream in-place replacement.  This kind of thing is
>> really annoying because it means that people using substitutes do not
>> notice whereas people building from source do.
>
> Could you send a diff of the two tarballs?

Hehe!  I have opened the bug because I wanted to avoid to investigate
myself. ;-)

Basically, I think it is a classical upstream in-place replacement.


>From upstream:

--8<---cut here---start->8---
$ guix build -S  gprolog --no-substitutes
The following derivation will be built:
   /gnu/store/yjrcalnckwmi1ah217xh85sd7ksjcxfw-gprolog-1.4.5.tar.gz.drv
building /gnu/store/yjrcalnckwmi1ah217xh85sd7ksjcxfw-gprolog-1.4.5.tar.gz.drv...

Starting download of 
/gnu/store/wm72f18w1gvshkz39yp12vnmnkkib79k-gprolog-1.4.5.tar.gz
>From http://gprolog.org/gprolog-1.4.5.tar.gz...
downloading from http://gprolog.org/gprolog-1.4.5.tar.gz ...
 gprolog-1.4.5.tar.gz  3.4MiB 556KiB/s 00:06 [##] 100.0%
sha256 hash mismatch for 
/gnu/store/wm72f18w1gvshkz39yp12vnmnkkib79k-gprolog-1.4.5.tar.gz:
  expected hash: 0z4cc42n3k6i35b8mr816iwsvrpxshw6d7dgz6s2h1hy0l7g1p5z
  actual hash:   18mrmx44fll0g1qphadna9g6m7miw8d22lkjavah22vzc38kalyf
hash mismatch for store item 
'/gnu/store/wm72f18w1gvshkz39yp12vnmnkkib79k-gprolog-1.4.5.tar.gz'
build of /gnu/store/yjrcalnckwmi1ah217xh85sd7ksjcxfw-gprolog-1.4.5.tar.gz.drv 
failed
View build log at 
'/var/log/guix/drvs/yj/rcalnckwmi1ah217xh85sd7ksjcxfw-gprolog-1.4.5.tar.gz.drv.bz2'.
guix build: error: build of 
`/gnu/store/yjrcalnckwmi1ah217xh85sd7ksjcxfw-gprolog-1.4.5.tar.gz.drv' failed

$ guix download http://gprolog.org/gprolog-1.4.5.tar.gz

Starting download of /tmp/guix-file.aqmcFI
>From http://gprolog.org/gprolog-1.4.5.tar.gz...
 gprolog-1.4.5.tar.gz  3.4MiB 557KiB/s 00:06 [##] 100.0%
/gnu/store/59hpvhs8zk66g62yisx363fkl53svcnf-gprolog-1.4.5.tar.gz
18mrmx44fll0g1qphadna9g6m7miw8d22lkjavah22vzc38kalyf
--8<---cut here---end--->8---

>From Guix CI:

--8<---cut here---start->8---
$ guix hash $(guix build -S gprolog)
3.6 MB will be downloaded:
   /gnu/store/wm72f18w1gvshkz39yp12vnmnkkib79k-gprolog-1.4.5.tar.gz
substituting /gnu/store/wm72f18w1gvshkz39yp12vnmnkkib79k-gprolog-1.4.5.tar.gz...
downloading from 
https://ci.guix.gnu.org/nar/wm72f18w1gvshkz39yp12vnmnkkib79k-gprolog-1.4.5.tar.gz
 ...
 gprolog-1.4.5.tar.gz  3.4MiB 559KiB/s 00:06 [##] 100.0%

0z4cc42n3k6i35b8mr816iwsvrpxshw6d7dgz6s2h1hy0l7g1p5z
--8<---cut here---end--->8---

Then, let get the content:

--8<---cut here---start->8---
$ tar -xf /gnu/store/59hpvhs8zk66g62yisx363fkl53svcnf-gprolog-1.4.5.tar.gz
$ mv gprolog-1.4.5 from-upstream

$ tar -xf /gnu/store/wm72f18w1gvshkz39yp12vnmnkkib79k-gprolog-1.4.5.tar.gz
$ mv gprolog-1.4.5 from-ci
--8<---cut here---end--->8---

and show which files are differing:

--8<---cut here---start->8---
$ diff -r --no-dereference from-{ci,upstream}
diff -r --no-dereference from-ci/ChangeLog from-upstream/ChangeLog
diff -r --no-dereference from-ci/doc/copyright.tex 
from-upstream/doc/copyright.tex
Binary files from-ci/doc/gprolog.dvi and from-upstream/doc/gprolog.dvi differ
diff -r --no-dereference from-ci/doc/gprolog.html from-upstream/doc/gprolog.html
Binary files from-ci/doc/gprolog.pdf and from-upstream/doc/gprolog.pdf differ
diff -r --no-dereference from-ci/doc/gprolog.ps from-upstream/doc/gprolog.ps
diff -r --no-dereference from-ci/doc/html_node/gprolog001.html 
from-upstream/doc/html_node/gprolog001.html

[...]

diff -r --no-dereference from-ci/doc/html_node/gprolog073.html 
from-upstream/doc/html_node/gprolog073.html
diff -r --no-dereference from-ci/doc/html_node/gprolog-idx.html 
from-upstream/doc/html_node/gprolog-idx.html
diff -r --no-dereference from-ci/doc/html_node/index.html 
from-upstream/doc/html_node/index.html
diff -r --no-dereference from-ci/NEWS from-upstream/NEWS
diff -r --no-dereference from-ci/src/EnginePl/gp_config.h 
from-upstream/src/EnginePl/gp_config.h
diff -r --no-dereference from-ci/src/EnginePl/gprolog_cst.h 
from-upstream/src/EnginePl/gprolog_cst.h
diff -r --no-dereference from-ci/src/Ma2Asm/x86_64_any.c 
from-upstream/src/Ma2Asm/x86_64_any.c
diff -r --no-dereference from-ci/src/Wam2Ma/wam2ma.c 
from-upstream/src/Wam2Ma/wam2ma.c
--8<---cut here---end--->8---

Basically, most seems a Copyright update and a documentation
regeneration. Except this:

--8<---cut here---start->8---
$ diff -r --no-dereference from-ci/src/Ma2Asm/x86_64_any.c 
from-upstream/src/Ma2Asm/x86_64_any.c
213,214c213,216
< #if defined(M_x86_64_darwin) || defined(M_x86_64_bsd) || 
defined(M_x86_64_linux) 

bug#41930: ‘guix pull’ shows raw build log output

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> ‘guix pull’ & co. show raw “detailed log” output for things
> built/downloaded while building ‘compute-guix-derivation.drv’:
>
> $ guix time-machine -- build …
> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...

[...]

> @ substituter-started 
> /gnu/store/frg642g7pxh95cdahar2s884ig82i1xn-nghttp2-1.41.0-lib substitute
> @ substituter-started 
> /gnu/store/v5rgf8v6cjxjbngkzjcznj98dkxj8svg-jansson-2.12 substitute
> @ substituter-started /gnu/store/23d9f16wbv22qin71ac32hql81bzzkab-libev-4.31 
> substitute
> @ download-started /gnu/store/23d9f16wbv22qin71ac32hql81bzzkab-libev-4.31 
> https://ci.guix.gnu.org/nar/lzip/23d9f16wbv22qin71ac32hql81bzzkab-libev-4.31 
> 124297
> @ download-started /gnu/store/v5rgf8v6cjxjbngkzjcznj98dkxj8svg-jansson-2.12 
> https://ci.guix.gnu.org/nar/lzip/v5rgf8v6cjxjbngkzjcznj98dkxj8svg-jansson-2.12
>  27840

The attached patch fixes that in an unimaginative but efficient fashion:

  1. the parent process (which runs ‘build-self.scm’) accepts connections on
 a named socket;

  2. the ‘compute-guix-derivation’ process connects to that socket and
 sends it its raw build output (what we see in the snippet above);

  3. the parent process reads that and sends it to its own
 (current-build-output-port); that port processes those “@” build
 traces according to the current ‘--verbosity’—see (guix status).

With this in place, builds or downloads triggered during the evaluation
of ‘compute-guix-derivation’ are reported in a consistent way from a UI
viewpoint.

There was one remaining glitch: the spinner that
‘compute-guix-derivation’ prints would show up in the middle of the
prettified build output.  The second patch addresses that.

Feedback welcome!

Ludo’.

>From 882c47b51223c6002eaec79466106a29ac84c613 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ludovic=20Court=C3=A8s?= 
Date: Tue, 30 Mar 2021 16:07:26 +0200
Subject: [PATCH 1/2] build-self: Forward sub-process build output to
 (current-build-output-port).

Fixes .

* build-aux/build-self.scm (build-program): Add extra 'build-output'
parameter.  Interpret it as a socket name and connect to it; use it as
the CURRENT-BUILD-OUTPUT-PORT.
(proxy): New procedure.
(build): Open a named socket.  Accept connections and call 'proxy' on it.
---
 build-aux/build-self.scm | 90 +---
 1 file changed, 65 insertions(+), 25 deletions(-)

diff --git a/build-aux/build-self.scm b/build-aux/build-self.scm
index dd845d1596..3e057ca5d2 100644
--- a/build-aux/build-self.scm
+++ b/build-aux/build-self.scm
@@ -336,7 +336,8 @@ interface (FFI) of Guile.")
 (loop (cdr spin)
 
   (match (command-line)
-((_ source system version protocol-version)
+((_ source system version protocol-version
+build-output)
  ;; The current input port normally wraps a file
  ;; descriptor connected to the daemon, or it is
  ;; connected to /dev/null.  In the former case, reuse
@@ -349,16 +350,22 @@ interface (FFI) of Guile.")
   (current-input-port)
   "w+0")
  #:version proto)
-   (open-connection
+   (open-connection)))
+(sock  (socket AF_UNIX SOCK_STREAM 0)))
(call-with-new-thread
 (lambda ()
   (spin system)))
 
+   ;; Connect to BUILD-OUTPUT and send it the raw
+   ;; build output.
+   (connect sock AF_UNIX build-output)
+
(display
 (and=>
  ;; Silence autoload warnings and the likes.
  (parameterize ((current-warning-port
- (%make-void-port "w")))
+ (%make-void-port "w"))
+(current-build-output-port sock))
(run-with-store store
  (guix-derivation source version
   #$guile-version
@@ -370,6 +377,20 @@ interface (FFI) of Guile.")
  derivation-file-name))
   #:module-path (list source
 
+(define (proxy input output)
+  "Dump the contents of INPUT to OUTPUT until EOF is reached on INPUT."
+  (setvbuf input 'block 16384)
+  (let loop ()
+(match (select (list input) '() '())
+  ((() () 

bug#47448: lualatex doesn't find libzzip-0.so.13 (easy bug?)

[Sergiu Ivanov]

Perfect, works like a charm!

Thanks a lot!

-
Sergiu


Thus quoth  Efraim Flashner  on Tue Mar 30 2021 at 10:06 (+0200):
> Bug fixed with commit 9098745b181b3022587a35afd255f7ff1d41ac86.

bug#42001: “SQLite database is busy”: contention on the store database

[Ludovic Courtès]

Hi,

Ludovic Courtès  skribis:

> On berlin.guix.gnu.org, we’ve seen a lot of contention on the store
> database for a month or so, with messages like:
>
>   warning: SQLite database is busy
>
> More often than not, everything slows down to a halt, and builds don’t
> proceed.

I think we can now close this bug: several issues around ‘guix offload’
were fixed, as mentioned in this issue, and Cuirass no longer uses ‘guix
offload’ anyway.

Ludo’.

bug#47479: inkscape retains a reference to imagemagick, even though it is in native-inputs

[Leo Famulari]

On Tue, Mar 30, 2021 at 04:55:13AM -0400, Mark H Weaver wrote:
> I see now that I'm using an older version, although I would have
> preferred the newer one.  I refer to the variable name 'inkscape' from
> my manifest file, and I expected that to point to the latest stable
> version.  However, it seems that one must use the 'inkscape-1.0'
> variable to get the latest stable version.  That's seems suboptimal.
> 
> I wonder if the 'inkscape' variable should be renamed 'inkscape/stable'
> (for use in packages such as 'dblatex/stable'), and then 'inkscape'
> could be repurposed to point to the latest stable version.  Thoughts?

I think we should do this, or even remove the old Inkscape package now.

I'm guessing the reason for keeping the older release series is that
the Inkscape save-file format changed?

By the way, there is a new upstream release of the old series available,
0.92.5.

bug#47458: [PATCH] gnu: emacs: Wrap EMACSLOADPATH.

[Leo Prikler]

With this, the search path specification of EMACSLOADPATH does no longer
depend on the version of Emacs, which should make upgrading major versions
less painful.  See also:
- 
- 

* gnu/packages/emacs.scm (emacs)[#:phases]: Add ‘wrap-load-path’.
[native-search-path]: Do not search for builtin libraries.
(emacs-next)[native-search-path]: Inherit from emacs.
---
 gnu/packages/emacs.scm | 31 ---
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index 7447cfe33a..e12c489f8d 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -201,6 +201,20 @@
 (car (find-files "bin" "^emacs-([0-9]+\\.)+[0-9]+$"))
 "bin/emacs")
#t)))
+ (add-after 'strip-double-wrap 'wrap-load-path
+   (lambda* (#:key outputs #:allow-other-keys)
+ (let* ((out (assoc-ref outputs "out"))
+(lisp-dirs (find-files (string-append out "/share/emacs")
+   "^lisp$"
+   #:directories? #t)))
+   (for-each
+(lambda (prog)
+  (wrap-program prog
+`("EMACSLOADPATH" suffix ,lisp-dirs)))
+(find-files (string-append out "/bin")
+;; versioned and unversioned emacs binaries
+"^emacs(-[0-9]+(\\.[0-9]+)*)?$"))
+   #t)))
  (add-before 'reset-gzip-timestamps 'make-compressed-files-writable
;; The 'reset-gzip-timestamps phase will throw a permission error
;; if gzip files aren't writable then.  This phase is needed when
@@ -255,9 +269,7 @@
 (native-search-paths
  (list (search-path-specification
 (variable "EMACSLOADPATH")
-;; The versioned entry is for the Emacs' builtin libraries.
-(files (list "share/emacs/site-lisp"
- (string-append "share/emacs/" version "/lisp"
+(files '("share/emacs/site-lisp")))
(search-path-specification
 (variable "INFOPATH")
 (files '("share/info")
@@ -294,18 +306,7 @@ languages.")
"0igjm9kwiswn2dpiy2k9xikbdfc7njs07ry48fqz70anljj8y7y3"
   (native-inputs
`(("autoconf" ,autoconf)
- ,@(package-native-inputs emacs)))
-  (native-search-paths
-   (list (search-path-specification
-  (variable "EMACSLOADPATH")
-  ;; The versioned entry is for the Emacs' builtin libraries.
-  (files (list "share/emacs/site-lisp"
-   (string-append "share/emacs/"
-  (version-major+minor+point version)
-  "/lisp"
- (search-path-specification
-  (variable "INFOPATH")
-  (files '("share/info"
+ ,@(package-native-inputs emacs))
 
 (define-public emacs-next-pgtk
   (let ((commit "ae18c8ec4f0ef37c8c9cda473770ff47e41291e2")
-- 
2.31.0

bug#47502: perl build commencment

[testdell...@yahoo.com]

I am trying to build a updated skeleton version of perl in a GUIX_PACKAGE-PATH 
folder, tweaking as necessary. I set up an inferior to add necessary packages. 
When I try to bulid the package,  i get this error
:~/.config/guix/local$ guix build -f perl_barebones.scm -K
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
gnu/packages/commencement.scm:2932:30: error: perl: unbound variable
hint: Did you forget `(use-modules (gnu packages perl))'?
 i Have tried to modify the perl_barebones file so that that doesn't happen but 
it Appears there isn't a way to make perl available to the commencement file to 
build the bootstrap perl to build perl. It appears there is a flaw in the 
commencement file. I tried updating guix, and checking with repl to see if it 
was something else. 
https://www.reddit.com/r/GUIX/comments/l5b1r9/guile_question_inheritance/
I've checked, r/GUIX the IRC and mailing list archives, so i'm pretty sure this 
a bug, or at least not a known issue. I apologize in advance if this a problem 
with what i did.
perl_barebone.scm full text:


;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2012, 2013, 2014, 2015, 2016, 2017 Ludovic Courtès 

;;; Copyright © 2013, 2019, 2020 Andreas Enge 
;;; Copyright © 2015, 2016, 2017, 2019, 2021 Ricardo Wurmus 
;;; Copyright © 2015, 2016, 2017, 2019, 2020 Eric Bavier 
;;; Copyright © 2015 Eric Dvorsak 
;;; Copyright © 2016, 2018 Mark H Weaver 
;;; Copyright © 2016 Jochem Raat 
;;; Copyright © 2016, 2017, 2018, 2019, 2020 Efraim Flashner 

;;; Copyright © 2016 Nikita 
;;; Copyright © 2016 Alex Sassmannshausen 
;;; Copyright © 2016, 2018, 2020 Roel Janssen 
;;; Copyright © 2016 Ben Woodcroft 
;;; Copyright © 2016, 2020 Jan (janneke) Nieuwenhuizen 
;;; Copyright © 2017 Raoul J.P. Bonnal 
;;; Copyright © 2017, 2018 Marius Bakke 
;;; Copyright © 2017 Adriano Peluso 
;;; Copyright © 2017, 2018, 2019, 2020 Tobias Geerinckx-Rice 
;;; Copyright © 2017 Leo Famulari 
;;; Copyright © 2017 Christopher Allan Webber 
;;; Copyright © 2018, 2019 Oleg Pykhalov 
;;; Copyright © 2018, 2019 Pierre Neidhardt 
;;; Copyright © 2018 Kei Kebreau 
;;; Copyright © 2019 Alex Griffin 
;;; Copyright © 2019 Mathieu Othacehe 
;;; Copyright © 2019 Stephen J. Scheck 
;;; Copyright © 2020 Vincent Legoll 
;;; Copyright © 2020 Paul Garlick 
;;; Copyright © 2020 Nicolas Goaziou 
;;; Copyright © 2020 Malte Frank Gerdes 
;;; Copyright © 2021 Maxim Cournoyer 
;;;
;;; This file is part of GNU Guix.
;;;
;;; GNU Guix is free software; you can redistribute it and/or modify it
;;; under the terms of the GNU General Public License as published by
;;; the Free Software Foundation; either version 3 of the License, or (at
;;; your option) any later version.
;;;
;;; GNU Guix is distributed in the hope that it will be useful, but
;;; WITHOUT ANY WARRANTY; without even the implied warranty of
;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;;; GNU General Public License for more details.
;;;
;;; You should have received a copy of the GNU General Public License
;;; along with GNU Guix.  If not, see .
;;; Test version to have updated package refrences

(define-module (gnu packages perl)
  #:use-module (guix inferior)
  #:use-module (guix channels)
  #:use-module (gnu packages package-management)
  ;; #:use-module (gnu packages perl)
  #:use-module (srfi srfi-1)
  #:use-module ((guix licenses) #:prefix license:)
  #:use-module (gnu packages)
  #:use-module (guix packages)
  #:use-module (guix download)
  #:use-module (guix git-download)
  #:use-module (guix utils)
  #:use-module (guix build-system gnu)
  #:use-module (guix build-system perl)
  #:use-module (gnu packages base)
  #:use-module (gnu packages bash)
  #:use-module (gnu packages compression)
  #:use-module (gnu packages databases)
  #:use-module (gnu packages fontutils)
  #:use-module (gnu packages freedesktop)
  #:use-module (gnu packages gd)
  #:use-module (gnu packages gl)
  #:use-module (gnu packages gtk)
  #:use-module (gnu packages hurd)
  #:use-module (gnu packages image)
  #:use-module (gnu packages less)
  #:use-module (gnu packages ncurses)
  #:use-module (gnu packages perl-check)
  #:use-module (gnu packages perl-compression)
  #:use-module (gnu packages perl-web)
  #:use-module (gnu packages pkg-config)
  #:use-module (gnu packages readline)
  #:use-module (gnu packages sdl)
  #:use-module (gnu packages textutils)
  #:use-module (gnu packages video)
  #:use-module (gnu packages web)
  #:use-module (gnu packages xorg))

;;;
;;; Please: Try to add new module packages in alphabetic order.
;;;



;;; In order to make this work outside of the primary channel We need to create 
a inferior for the channel packages we need.
;;; First we need to define the channel(s)

(define channels
    (list (channel 
        (name `guix)
        (url "https://git.savannah.gnu.org/git/guix.git";)
        (commit "414fc58cef4eb9c2cc18a381629d17

bug#33848: Store references in SBCL-compiled code are "invisible"

[Ludovic Courtès]

Hi,

Pierre Neidhardt  skribis:

> Many grafting issues with Nyxt have been reported recently:
>
> https://github.com/atlas-engineer/nyxt/issues/1257
>
> Seems that glib is being grafted, which breaks cl-cffi-gtk and thus
> Nyxt.
>
> Is there a way to disable grafting for a given package?  This would at
> least be a local workaround for Nyxt.

No.  I provided guidance in 2018 on how to address this issue:

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

Did anyone talk to the SBCL folks?  Please, let’s address this rather
than look for workarounds.

Thanks,
Ludo’.

bug#47480: gprolog: hash mismatch

[Ludovic Courtès]

Hi!

zimoun  skribis:

> Basically, most seems a Copyright update and a documentation
> regeneration. Except this:
>
> $ diff -r --no-dereference from-ci/src/Ma2Asm/x86_64_any.c 
> from-upstream/src/Ma2Asm/x86_64_any.c
> 213,214c213,216
> < #if defined(M_x86_64_darwin) || defined(M_x86_64_bsd) || 
> defined(M_x86_64_linux) 
> <   pic_code = 1; /* NB: on darwin and BSD everything is 
> PIC code, last gcc 6 needs this for linux */
> ---
>> #if defined(M_x86_64_darwin) || defined(M_x86_64_bsd)
>>   pic_code = 1; /* NB: on darwin and BSD everything is PIC 
>> code */
>> #elif defined(M_x86_64_linux) && __GNUC__ >= 6 /* gcc >= 6 needs PIC for 
>> linux */
>>   pic_code = 1;
>
> $ diff -r --no-dereference from-ci/src/Wam2Ma/wam2ma.c 
> from-upstream/src/Wam2Ma/wam2ma.c
> 514c514,516
> < Syntax_Error("multifile or multifile expected");
> ---
>> {
>>   Syntax_Error("multifile or multifile expected");
>> }

Bah, sadness.

Anyway, I guess that means we can update the hash, with a link to this
report for posterity.

Thanks,
Ludo’.

bug#47479: inkscape retains a reference to imagemagick, even though it is in native-inputs

[Mark H Weaver]

Hi Leo,

Leo Famulari  writes:

> On Tue, Mar 30, 2021 at 04:55:13AM -0400, Mark H Weaver wrote:
>> I wonder if the 'inkscape' variable should be renamed 'inkscape/stable'
>> (for use in packages such as 'dblatex/stable'), and then 'inkscape'
>> could be repurposed to point to the latest stable version.  Thoughts?
>
> I think we should do this,

Thanks.

> or even remove the old Inkscape package now.

I don't think we can remove the old Inkscape, because 'inkscape' is an
input of 'dblatex/stable', which 'gtk-doc/stable' depends on.

There might or might not be other reasons to keep an older version of
'inkscape' around, but either way, if 'gtk-doc/stable' depends on
Inkscape, I think we'd better have an 'inkscape/stable' too, so that our
'inkscape' package can be freely updated on 'master'.

Going forward, if it turns out that Inkscape is not truly needed as an
input to 'dblatex/stable', and moreover, if _nothing_ deep in our stack
truly needs to depend on Inkscape, then we could perhaps eliminate
'inkscape/stable' altogether.  However, that would need to happen on
either 'core-updates' or 'staging' (or similar), because changing
'dblatex/stable' entails too many rebuilds.

What do you think?

Thanks,
  Mark

bug#44541: Blender addon can't find Python libraries

[raingloom]

On Tue, 30 Mar 2021 13:31:39 +0900
Sébastien Lerique  wrote:

> Hi raingloom,
> 
> > Reproduce by installing an addon like AnimationNodes. Or just 
> > open thescripting REPL and enter 'import numpy'.  
> 
> I just hit this, and calling blender with 
> `--python-use-system-env` works as a workaround. Is this maybe 
> expected behaviour?
> 
> Sébastien
> 
> 
> 

Ah, missed that flag. I don't think it's necessarily expected, I
remember it working without that on Arch, and I don't think they patch
Blender. I could just pacman -Si python-numpy and Animation Nodes
worked.
Maybe we should make that the default if we wanna package Blender
addons. (Which I very much want. A reproducible art pipeline would be a
very nice use case indeed.)

bug#47509: OpenEXR may be vulnerable to CVE-2021-3474, CVE-2021-3476 and CVE-2021-3475

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

CVE-2021-3474   30.03.21 20:15
There's a flaw in OpenEXR in versions before 3.0.0-beta. A crafted
input file that is processed by OpenEXR could cause a shift overflow in
the FastHufDecoder, potentially leading to problems with application
availability.

Fix: 
https://github.com/AcademySoftwareFoundation/openexr/commit/c3ed4a1db1f39bf4524a644cb2af81dc8cfab33f

CVE-2021-3476   30.03.21 20:15
A flaw was found in OpenEXR's B44 uncompression functionality in
versions before 3.0.0-beta. An attacker who is able to submit a crafted
file to OpenEXR could trigger shift overflows, potentially affecting
application availability.

Fix: 
https://github.com/AcademySoftwareFoundation/openexr/commit/eec0dba242bedd2778c973ae4af112107b33d9c9

CVE-2021-3475   30.03.21 20:15
There is a flaw in OpenEXR in versions before 3.0.0-beta. An attacker
who can submit a crafted file to be processed by OpenEXR could cause an
integer overflow, potentially leading to problems with application
availability.

Fix: 
https://github.com/AcademySoftwareFoundation/openexr/commit/2a18ed424a854598c2a20b5dd7e782b436a1e753

I could not check if these flaws affect the 2.5.2 version packaged in
GNU Guix yet.


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

bug#47510: cflow is vulnerable to CVE-2019-16165 and CVE-2019-16166

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

I asked the maintainer to fix the issues because they were unfixed
since a while, they have done so recently:

https://git.savannah.gnu.org/cgit/cflow.git/commit/?id=b9a7cd5e9d4efb54141dd0d11c319bb97a4600c6

They have not made a recently, also it seems they fixed other issues
that could be security relevant in their commit log, not sure if we
apply/backport patches or wait for release.


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

bug#47479: inkscape retains a reference to imagemagick, even though it is in native-inputs

[Leo Famulari]

On Tue, Mar 30, 2021 at 06:48:16PM -0400, Mark H Weaver wrote:
> I don't think we can remove the old Inkscape, because 'inkscape' is an
> input of 'dblatex/stable', which 'gtk-doc/stable' depends on.
> 
> There might or might not be other reasons to keep an older version of
> 'inkscape' around, but either way, if 'gtk-doc/stable' depends on
> Inkscape, I think we'd better have an 'inkscape/stable' too, so that our
> 'inkscape' package can be freely updated on 'master'.
> 
> Going forward, if it turns out that Inkscape is not truly needed as an
> input to 'dblatex/stable', and moreover, if _nothing_ deep in our stack
> truly needs to depend on Inkscape, then we could perhaps eliminate
> 'inkscape/stable' altogether.  However, that would need to happen on
> either 'core-updates' or 'staging' (or similar), because changing
> 'dblatex/stable' entails too many rebuilds.
> 
> What do you think?

I didn't realize / remember that Inkscape was used that deep in the
package graph. I agree, we should delay this change, at least until a
rebuild cycle.

I do think it's suboptimal that an end-user application like Inkscape
is depended on by so many packages...