bug#69961: java-jmh has flaky tests

Dear Guix, brave java team, When building java-jmh, we experienced a flaky test: https://bordeaux.guix.gnu.org/build/0aa9b4ea-57ad-439b-a5c7-7d59dd14e9cd/log However, the build system does not give us enough information to know what went wrong, as far as I understand. Best regards, Vivien

bug#69800: [PATCH gnome-team] gnu: kcalendarcore: Disable failing test.

* gnu/packages/kde-frameworks.scm (kcalendarcore) [#:phases]: Add 'disable-failing-test. Change-Id: Ia0a5828b032d1940f30a7d38ebd276e60929c310 --- gnu/packages/kde-frameworks.scm | 6 ++ 1 file changed, 6 insertions(+) diff --git a/gnu/packages/kde-frameworks.scm

bug#69800: kcalendarcore is a time bomb

Dear Guix, Kcalendarcore does not build anymore. According to CI, it stopped working this march, on gnome-team and rust-branch (I can’t build it either on master). http://ci.guix.gnu.org/search?query=kcalendarcore Best regards, Vivien

bug#63077: [PATCH] gnu: gnutls: skip examples on mingw.

Hello, Le vendredi 08 mars 2024 à 18:22 +0100, Simon Tournier a écrit : > > > +   #$@(if (target-mingw?) > > > +  #~((add-after 'unpack 'skip-doc-examples > > > +   ;; The examples in doc do not link to > > > correct > > > +  

bug#69682: [PATCH v2] gnu: ocaml-extlib: Convert to dune-build-system.

* gnu/packages/ocaml.scm (ocaml-extlib) [build-system]: Convert to dune-build-system. [arguments]: Remove '#:phases' and add '#:package'. Change-Id: Ia50c05423f3062200704fbcbb0680f2b326a7ca4 --- Opam still builds on gnome-team. gnu/packages/ocaml.scm | 6 ++ 1 file changed, 2 insertions(+),

bug#69682: [PATCH 1/1] gnu: ocaml-extlib: Build with minimal=1.

* gnu/packages/ocaml.scm (ocaml-extlib) [arguments]: Convert to list of G-Expressions. Add #:make-flags. Change-Id: I42ee3c21a52788f20ddc3381927ef6ef40b2a354 --- gnu/packages/ocaml.scm | 8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/gnu/packages/ocaml.scm

bug#69682: [PATCH 0/1] ocaml-extlib: Build with minimal=1.

Dear Guix, brave ocaml-team members, According to https://github.com/ocaml/opam/issues/5694 it looks like ocaml-extlib should build with minimal=1. This also fixes a build failure on gnome-team. What do you think? Best regards, Vivien Vivien Kraus (1): gnu: ocaml-extlib: Build with

bug#69682: Opam should be using a minimal version of extlib

Dear OCaml-aware Guix, opam seems to imply that we have to use a minimal variant of ocaml- extlib to build opam: https://github.com/ocaml/opam/issues/5694 This is likely related to a build failure we are experiencing on the gnome-team branch: https://issues.guix.gnu.org/69677

bug#67651: [gnome-team] What should we do with the "gnome" package?

This is being worked on at https://issues.guix.gnu.org/68716

bug#67838: [gnome-team] epiphany pdf.js can't save pdf

Hello Jack! It is possible that the issue has been fixed with the newer webkitgtk or the newer epiphany. Can you try that again? Best regards, Vivien

bug#67651: [gnome-team] What should we do with the "gnome" package?

Dear Guix, Le dimanche 07 janvier 2024 à 17:53 +0100, Liliana Marie Prikler a écrit : > I've summarised our TODOs below: Each commented line (preceded by #) > denotes a package that doesn't exist on the gnome-team branch yet. > > core:atkmm:2.28.3: Oops, I missed that one. Sorry. I checked the

bug#67651: [gnome-team] What should we do with the "gnome" package?

Dear guix, On the one hand, we have this list of packages: https://ftp2.nluug.nl/windowing/gnome/teams/releng/44.6/versions On the other hand, we have the propagated-inputs of the gnome package. Should we update the latter so that it contains everything from the former? What should we do about

bug#66339: [PATCH gnome-team v6] gnu: dbus-service: make the session available under /run/dbus

According to https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3101, glib now searches for the session bus socket in runstatedir. The dbus service must thus have its socket in /run/dbus. For interoperability with the dbus standard, /run/dbus is also symlinked to /var/run/dbus. *

bug#66339: [PATCH gnome-team v5] gnu: glib: Set runstatedir.

Glib has made /run the default runstatedir: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3101 However, in Guix, the default runstatedir is /var/run. * gnu/packages/glib.scm (glib): Set runtime_dir to /var/run. --- I changed my mind again! Following the IRC discussion, Guix has a

bug#66339: [PATCH gnome-team v4] gnu: dbus-service: make the session available under /run/dbus

According to https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3101, glib now searches for the session bus socket in runstatedir. The dbus service must thus have its socket in /run/dbus. For interoperability with the dbus standard, /run/dbus is also symlinked to /var/run/dbus. *

bug#66339: [PATCH gnome-team v3] gnu: dbus-service: make the session available under /run/dbus

According to https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3101, glib now searches for the session bus socket in runstatedir. The dbus service must thus have its socket in /run/dbus. For interoperability with the dbus standard, /run/dbus is also symlinked to /var/run/dbus. *

bug#66339: [PATCH gnome-team v2] gnu: dbus-service: make the session available under /run/dbus

According to https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3101, glib now searches for the session bus socket in runstatedir. The dbus service must thus have its socket in /run/dbus. For interoperability with the dbus standard, /run/dbus is also symlinked to /var/run/dbus. *

bug#66339: [WIP PATCH gnome-team] gnu: dbus-service: make the session available under /run/dbus

* gnu/services/dbus.scm (dbus-activation): Symlink /var/run/dbus to /run/dbus. --- gnu/services/dbus.scm | 1 + 1 file changed, 1 insertion(+) diff --git a/gnu/services/dbus.scm b/gnu/services/dbus.scm index 5a0c634393..80968ac1a4 100644 --- a/gnu/services/dbus.scm +++ b/gnu/services/dbus.scm @@

bug#63331: Guile-GnuTLS/Git circular dependency and built-in git checkouts

Hello! Le lundi 11 septembre 2023 à 16:36 +0200, Ludovic Courtès a écrit : > Eventually, when users are all running recent versions of > ‘guix-daemon’ with support for “builtin:git-download” (2–4 > years from now?), we’ll be able to use “builtin:git-download” > unconditionally and thus be sure

bug#29644: gcc-objc is unusable without its 'gcc' executable

Hello! I would like to learn and play with gnustep with objective-C, but it seems like GCC does not come with objective-C in Guix. I don’t know much about GCC or how Guix packages it. There is an early comment by Ricardo Wurmus: > The fix here is to patch “lang-spec.h”, so that it does not

bug#63331: Guile-GnuTLS/Git circular dependency

Le mardi 09 mai 2023 à 14:23 +0200, Simon Josefsson a écrit : > A GitLab CI/CD build check on Guix would be nice, does anyone publish > docker images for a Guix system? The guix builder uses linux tools to provide an isolated build environment. It is possible to run the guix build daemon without

bug#63331: Guile-GnuTLS/Git circular dependency

Hi! Le samedi 06 mai 2023 à 19:20 +0200, Ludovic Courtès a écrit : > We need to solve that.  For now, the only fix I can think of is > having > ‘guile-gnutls’ built from a “make dist”-provided tarballs.  > Apparently > we can add assets at ; would > you >

bug#63077: [PATCH] gnu: gnutls: skip examples on mingw.

* gnu/packages/tls.scm (gnutls): Skip the doc/examples subdir on mingw, because the gnulib modules are not correct. --- gnu/packages/tls.scm | 9 + 1 file changed, 9 insertions(+) diff --git a/gnu/packages/tls.scm b/gnu/packages/tls.scm index 6d7cff41b0..9e16b04702 100644 ---

bug#63076: This is for core-updates

Hello, This patch should go to core-updates, but I can’t find the branch. Best regards, Vivien

bug#63076: [PATCH] gnu: libunistring: Update to 1.1.

* gnu/packages/libunistring.scm (libunistring): Update to 1.1. --- gnu/packages/libunistring.scm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gnu/packages/libunistring.scm b/gnu/packages/libunistring.scm index eccd053a35..f0b071f11c 100644 ---

bug#62181: [PATCH v2 1/2] gnu: gnulib: Reset the shebangs.

Hi! Le vendredi 17 mars 2023 à 22:48 +0100, Ludovic Courtès a écrit : > > * gnu/packages/tls.scm (guile-gnutls) [phase patch-more-shebangs]: > > Fix how > > autogen.sh invokes gnulib-tool, and how configure.ac invokes git- > > version-gen, > > so as not to rely on shebangs. > > [...] > > > +

bug#62181: [PATCH v2 1/2] gnu: gnulib: Reset the shebangs.

* gnu/packages/build-tools.scm (gnulib) [phase reset-shebangs]: After installation, rewrite the /gnu/store shebangs in the distributed build-aux files. [inputs, native-inputs]: Add bash-minimal. [phase let-autogen-execute-gnulib-tool]: Specify a shell to execute gnulib-tool from autogen.sh. ---

bug#62181: [PATCH v2 0/2] Drop references to other store items in /src, with better style

So I applied Ludo’s proposed style improvement with a few more tweaks to respect the gnulib-intended shebangs, and making sure that substitute* failure on /lib/javaversion.class and the .mo test data can be recovered. This v2 is still not a silver bullet, because gnulib users need to patch a

bug#62181: [PATCH v2 2/2] gnu: guile-gnutls: Do not expect gnulib shebangs to work.

* gnu/packages/tls.scm (guile-gnutls) [phase patch-more-shebangs]: Fix how autogen.sh invokes gnulib-tool, and how configure.ac invokes git-version-gen, so as not to rely on shebangs. --- gnu/packages/tls.scm | 6 ++ 1 file changed, 6 insertions(+) diff --git a/gnu/packages/tls.scm

bug#62181: [PATCH 2/2] gnu: guile-gnutls: Do not expect gnulib shebangs to work.

Le jeudi 16 mars 2023 à 11:48 +0100, Ludovic Courtès a écrit : > > +  (substitute* "configure.ac" > > +    (("build-aux/git-version-gen") > > + "sh build-aux/git-version-gen")) > >    (for-each patch-shebang > >

bug#62181: [PATCH 0/2] Re: bug#62181: Gnulib package keeps references to clisp, Python, Perl, and Bash

Le jeudi 16 mars 2023 à 11:41 +0100, Ludovic Courtès a écrit : > Apart from ‘gnulib-tool’, every script is first > copied into the source tree, and that happens before the > ‘patch-source-shebangs’ phase no? Precisely, so if they are executed during the bootstrap phase, we can’t rely on their

bug#62181: [PATCH 2/2] gnu: guile-gnutls: Do not expect gnulib shebangs to work.

* gnu/packages/tls.scm (guile-gnutls) [phase patch-more-shebangs]: Fix how autogen.sh invokes gnulib-tool, and how configure.ac invokes git-version-gen, so as not to rely on shebangs. --- gnu/packages/tls.scm | 6 ++ 1 file changed, 6 insertions(+) diff --git a/gnu/packages/tls.scm

bug#62181: [PATCH 1/2] gnu: gnulib: Reset the shebangs.

* gnu/packages/build-tools.scm (gnulib) [phase reset-shebangs]: After installation, rewrite the /gnu/store shebangs in the distributed build-aux files. [inputs, native-inputs]: Add bash-minimal. [phase let-autogen-execute-gnulib-tool]: Specify a shell to execute gnulib-tool from autogen.sh. ---

bug#62181: [PATCH 0/2] Re: bug#62181: Gnulib package keeps references to clisp, Python, Perl, and Bash

Hi! Le mardi 14 mars 2023 à 09:34 +0100, Ludovic Courtès a écrit : > The Gnulib package, which is meant to be source, retains references > to > several packages: > > --8<---cut here---start->8--- > $ guix describe > Generation 250 Mar 12 2023 23:58:03

bug#60811: Can’t change the build system of p11-kit to meson

Hello! Le samedi 14 janvier 2023 à 21:10 +0100, Csepp a écrit : > The way I debugged a cycle was: > * use package graph type > * import graph into Python's networkx using pydot > * run networkx's cycle detection If I select the "package" graph type, guix graph completes: $ ./pre-inst-env guix

bug#60811: Can’t change the build system of p11-kit to meson

Dear guix, p11-kit is switching its build system to meson. The README already advertises it as the way to build p11-kit. When I try to change that, guix builds fine. Then, if I try to run guix build p11-kit, guix will crash after exhausting all my memory. I suspect a circular dependency of some

bug#52667: System reconfiguration fails to build linux-modules.drv

Dear guix, On master, I can’t reconfigure my system, because the linux-modules.drv fails with the following error: Backtrace: 17 (primitive-load "/gnu/store/bvjcb7jbwlky0czin8p66949mil?") In ice-9/eval.scm: 619:8 16 (_ #f) 626:19 15 (_ #) 293:34 14 (_ #(# #)) In

bug#52375: Both pages load fine for me

Dear guix, As a guix home user on a GNOME guix system, both pages work in epiphany (private mode) for me. My graphics card is reported as "llvmpipe (LLVM 11.0.0, 256 bits)" by GNOME. Vivien signature.asc Description: This is a digitally signed message part

bug#51916: Can’t reconfigure with GNOME on core-updates-frozen

Dear guix, There has been some discussion on IRC about this, but it lacks a formal guix issue. When using the gnome-service-type on core-updates-frozen, I can’t reconfigure my system, because of the following error message: guix system: error: profile contains conflicting entries for

bug#51869: [PATCH] Add emacs-vala-mode

Liliana Marie Prikler writes: > Please avoid pulling home-page up, it's not meant to be used as > git-reference url. OK. >> + (emacs-substitute-sexps "vala-mode.el" >> + (";; Support multiline strings" 'disabled.) >> + ("(defcustom

bug#51869: [PATCH] Add emacs-vala-mode

Liliana Marie Prikler writes: > I'd use our emacs sexp substitution tools to erase these defconsts and > defcustoms rather than a patch. Other than that LGTM. I didn’t know about this great macro! Here is an updated version. Vivien From 759b0437e5016e7c558a5a99e2831f419a3b0802 Mon Sep 17

bug#51879: [PATCH] On core-updates-frozen, deja-dup does not build

Hi guix, deja-dup requires libsoup2 on core-updates-frozen. Best regards, Vivien From c7900fe9eb83f7080008c094d095b9132c198180 Mon Sep 17 00:00:00 2001 From: Vivien Kraus Date: Mon, 15 Nov 2021 21:23:36 + Subject: [PATCH] gnu: deja-dup: Use libsoup 2. * gnu/packages/gnome.scm (deja-dup)

bug#51869: [PATCH] Add emacs-vala-mode

Hi! Liliana Marie Prikler writes: >> Since I don’t have a solution to fix this issue, I went away and >> reverted the multiline support. It builds and is useful enough for >> LSP to kick in, so I consider it fixed. >> >> What do you think? Do you have a better fix? > Given my superior knowledge

bug#51873: [PATCH] Fix gnome-calendar on core-updates-frozen

Dear guix, gnome-calendar also requires meson 0.59 in core-updates-frozen. Best regards, Vivien From a2e4e6ac1d924fc8b95c0ac265f31eca0dbb58e1 Mon Sep 17 00:00:00 2001 From: Vivien Kraus Date: Mon, 15 Nov 2021 15:59:05 + Subject: [PATCH] gnu: gnome-calendar: Fix build. *

bug#51487: The openssh service does not allow multiple authorized key files per user

Ludovic Courtès writes: > I find it a bit hard to read. What I had in mind is along these lines: > > (match (openssh-authorized-keys config) > (((users _ ...) ...) > ;; Build a user/key-list mapping. > (let ((user-keys (fold (lambda (spec table) >

bug#51872: [PATCH] On core-updates-frozen, gnome-mines requires the old meson too

Dear guix, Yet another package that requires the old meson on core-updates-frozen :) Best regards, Vivien From 4bd36cebd69a2695f9b6db108868198aae2f48b9 Mon Sep 17 00:00:00 2001 From: Vivien Kraus Date: Mon, 15 Nov 2021 14:38:29 + Subject: [PATCH] gnu: gnome-mines: Fix build. *

bug#51871: [PATCH] Gnome 2048 does not build on core-updates-frozen

Dear guix, Gnome 2048 requires the old meson too. Best regards, Vivien From c3a77be9eb0673495be9745cfbfc24694b3790ae Mon Sep 17 00:00:00 2001 From: Vivien Kraus Date: Mon, 15 Nov 2021 14:25:20 + Subject: [PATCH] gnu: gnome-2048: Fix build. * gnu/packages/games.scm (gnome-2048)

bug#51869: [PATCH] Add emacs-vala-mode

Dear guix, There’s a vala mode for emacs. It is not very useful, but it registers a major mode that is then used as a placeholder for the Emacs Language Server Protocol client. In fact, it’s not possible to activate Vala support for LSP on emacs without a vala mode, and this is the only

bug#51812: On core-updates-frozen, vala-language-server does not build

Dear guix, vala-language-server (gnu packages gnome-xyz) does not build on core-updates-frozen, but the latest version builds fine. Best regards, Vivien From 782ff398d79f20409ee5561ee284bcd1396b0b07 Mon Sep 17 00:00:00 2001 From: Vivien Kraus Date: Sat, 13 Nov 2021 13:51:58 + Subject:

bug#51805: Don’t upgrade nautilus if you don’t want to

As a precision, the second patch is the only one required, apply the others at your discretion. Vivien signature.asc Description: PGP signature

bug#51808: [PATCH] Devhelp: On core-updates-frozen, upgrade to 41.2 to use webkit2 4.1

Dear guix, devhelp 41 gained support for building against webkit2 4.1. I think we should upgrade, right? Vivien From fadbf75a7667cfb9e2a25024913373a53310d06c Mon Sep 17 00:00:00 2001 From: Vivien Kraus Date: Sat, 13 Nov 2021 10:35:26 + Subject: [PATCH] gnu: devhelp: Upgrade to 41.2. *

bug#51806: Does this work?

I’d like to close 51806 :)

bug#51806: Acknowledgement ([PATCH] Fix dconf-editor)

Please ignore, it has already been fixed, thanks :)

bug#51806: [PATCH] Fix dconf-editor

Dear Guix, dconf-editor needs the old meson to build. Best regards, Vivien From 228729b7bd0bd0bf6249866d691ed8ab1f051a7b Mon Sep 17 00:00:00 2001 From: Vivien Kraus Date: Sat, 13 Nov 2021 09:33:20 + Subject: [PATCH] gnu: dconf-editor: Fix build. * gnu/packages/gnome.scm (dconf-editor)

bug#51731: [PATCH] gnome-tweaks fails to start on core-updates-frozen

Hello! Liliana Marie Prikler writes: >> > > Subject: [PATCH 4/5] gnu: gnome-tweaks: Add bash-minimal as an >> > > input to wrap the program. >> > Split the long line. Also perhaps add a comment in the file itself >> > as to why this is needed if it's not already obvious from best >> >

bug#51805: Update nautilus on core-updates-frozen

Dear guix, If we update gnome-autoar (the tool to manage archives), we can update nautilus. What do you think? Vivien From bcdf96f406b6b108be3cd0e701ad9f08756dd450 Mon Sep 17 00:00:00 2001 From: Vivien Kraus Date: Sat, 13 Nov 2021 08:57:15 + Subject: [PATCH 1/3] gnu: gnome-autoar: Upgrade

bug#51790: [PATCH] Re: bug#51790: Fix it (On core-updates-frozen, tracker-miners can’t find its tracker dependency)

It turns out that tracker-miners wants the same libsoup version as tracker, so we need libsoup-minimal-2. From e76c51853913686234ec008cc9cf6e3117a15fa2 Mon Sep 17 00:00:00 2001 From: Vivien Kraus Date: Sat, 13 Nov 2021 08:19:09 + Subject: [PATCH] gnu: tracker-miners: Require the same

bug#51790: On core-updates-frozen, tracker-miners can’t find its tracker dependency

Dear guix, I can’t build tracker-miners on core-updates-frozen, because it fails its configuration phase not finding tracker-sparql 3.0 (a pkg-config definition installed by tracker, which is a dependency). Best regards, Vivien signature.asc Description: PGP signature

bug#51789: Appstream-glib is broken on core-updates-frozen

Dear guix, Appstream-glib is not ready yet for libsoup 3. I propose that we still use libsoup-minimal-2. Best regards, Vivien From 88cac92aa69022620ff5f7007ef7a76488f2139a Mon Sep 17 00:00:00 2001 From: Vivien Kraus Date: Fri, 12 Nov 2021 12:16:32 + Subject: [PATCH] gnu: appstream-glib:

bug#51746: Ignore the styling commit

The styling commit should be ignored. The styling will happen for all packages at once. signature.asc Description: PGP signature

bug#51731: [PATCH] gnome-tweaks fails to start on core-updates-frozen

Hello, Liliana Marie Prikler writes: > Am Dienstag, den 09.11.2021, 23:10 + schrieb Vivien Kraus: >> I fixed a couple of linter errors, and applied guix style to >> it. However, now the linter complains that we have the "bin" output >> of glib in something that would be called "glib" and not

bug#51746: Gnome Boxes on core-updates-frozen can’t clone VMs

Dear guix, Gnome Boxes 41.1 fixes a regression on core-updates-frozen where if you clone a VM, gnome-boxes won’t be able to restart again, because the clone operation corrupts the new VM description. I propose that we upgrade it, what do you think? Vivien From

bug#51731: [PATCH] gnome-tweaks fails to start on core-updates-frozen

Dear guix, gnome-tweaks does not start on core-updates-frozen, because it needs libhandy 1 and is given libhandy 0.0. Also, it cannot find its own python module, so the python path needs to be wrapped. I fixed a couple of linter errors, and applied guix style to it. However, now the linter

bug#51719: [PATCH] Orbit2 is broken on core-updates-frozen

Dear Guix, orbit2 is a dependency for libreoffice, and it does not build reproducibly on core-updates-frozen (I don’t know on master). The issue is well-known, for instance here on Arch: https://bbs.archlinux.org/viewtopic.php?id=240775 I applied the fix, and it builds with parallel make. What

bug#51487: The openssh service does not allow multiple authorized key files per user

Hello, Ludovic Courtès writes: > Could you write it in functional style using a vhash (info "(guile) > VHashes")? You’ll probably need two list traversals: one to build the > user/key mapping, and one to compute the list of users. I thought that as the vhash data structure inherited the

bug#51435: Fix it (unison does not build on core-updates-frozen)

Rekado on #guix told me that I had to create a simple texlive package for the missing package, that’s what I did. Since I’m not familiar with the texlive way of doing things, I’m not sure the homepage is that of l3backend (and thus, I’m not sure of the license if it’s not), and I need someone to

bug#51435: unison does not build on core-updates-frozen

So, trying to understand why the error happens, I added all the known texlive packages (exported variables in gnu/packages/texlive.scm that start with texlive- and that are packages), and it still fails, but if I just add the full texlive it builds just fine. Vivien >From

bug#51447: More explanations for the fix

I was told that this issues gives headaches, so I added a short comment explaining it. Vivien >From 93224afab672465f3e8e1a6be00def0d5507bb76 Mon Sep 17 00:00:00 2001 From: Vivien Kraus Date: Tue, 2 Nov 2021 18:19:03 +0100 Subject: [PATCH] guile-gi: fix a source code encoding error *

bug#51447: [PATCH] Re: bug#51447: guile-gi source code has a placeholder for a combining character

Vivien Kraus writes: > The string failure is due to a dotted circle as a basis for the > combining character, that may have been inserted by a clever source code > editor. Replacing it with the hex value for the character itself, the > test passes. Sorry, the phase name is not good, because

bug#51447: there’s no other test failing than string.scm

It turns out that the other failures only happen in a guix shell, not as a package build in guix. Vivien

bug#51447: [PATCH] Re: bug#51447: guile-gi source code has a placeholder for a combining character

The string failure is due to a dotted circle as a basis for the combining character, that may have been inserted by a clever source code editor. Replacing it with the hex value for the character itself, the test passes. Vivien >From 308bd116d75861c70f7540890a514b0eb487c2f7 Mon Sep 17 00:00:00

bug#51487: Acknowledgement (The openssh service does not allow multiple authorized key files per user)

After some discussion on #guix, this seems to be the easier way to fix the problem: Vivien From d029179554fc2f9656f708e5315bca52928e9254 Mon Sep 17 00:00:00 2001 From: Vivien Kraus Date: Fri, 29 Oct 2021 18:25:24 +0200 Subject: [PATCH] gnu: openssh-service: Collect all keys for all users. *

bug#51487: Acknowledgement (The openssh service does not allow multiple authorized key files per user)

Le vendredi 29 octobre 2021 à 23:22 +0200, Vivien Kraus a écrit : > After some discussion on #guix, this seems to be the easier way to > fix > the problem: Sorry, I forgot to update the commit message. Vivien From b2f47730a3d9aa97716741134917c340354d9c3a Mon Sep 17 00:00:00 2001 From: Vivien

bug#51487: Acknowledgement (The openssh service does not allow multiple authorized key files per user)

The patch does not seem to get formatted correctly, sorry. Hopefully, this should work. Vivien From 8dcf1a92cb6ebbc537029f88d5c7197cbf4959aa Mon Sep 17 00:00:00 2001 From: Vivien Kraus Date: Fri, 29 Oct 2021 18:25:24 +0200 Subject: [PATCH] gnu: openssh-service: Collect all keys for all users. *

bug#51487: Acknowledgement (The openssh service does not allow multiple authorized key files per user)

Vivien Kraus writes: > I have a patch, what do you think? > > I tested it by building an operating system of the form: > > (operating-system > ... > (services >(append >(list > (service openssh-service-type > (openssh-configuration >

bug#51487: Acknowledgement (The openssh service does not allow multiple authorized key files per user)

I have a patch, what do you think? I tested it by building an operating system of the form: (operating-system ... (services (append (list (service openssh-service-type (openssh-configuration (authorized-keys `(("root"

bug#51487: The openssh service does not allow multiple authorized key files per user

Dear guix, The openssh service is configured with a list of authorized keys, as a list of items, where each item is a list of 2 values, the user name (as a string) and the public key file (a file-like object). The service can be extended with new keys. To have multiple keys per user, we can put

bug#51447: Guile-gi fails a few tests on core-updates-frozen

Dear guix, For my program, I depend on guile-gi. However, the test/string.scm test contains some characters that are not recognized by guile (I suggest using (call-with-input-string "" read-char) instead of #\), and once that’s fixed, more tests fail, for which I have no solution. Best regards,

bug#51439: python-poppler-qt5 fails to build on core-updates-frozen

Dear guix, python-poppler-qt5 (gnu/packages/pdf.scm) fails to build. This is the latest version, and I’m afraid there’s little we can do: sip: poppler-form.sip:152: ::Poppler::FormFieldChoice::choicesWithExportValues() unsupported function return type - provide %MethodCode and a C++ signature

bug#51438: Jami does not start on core-updates-frozen

Dear guix, jami (jami-qt or jami-gnome) can’t start on core-updates-frozen, an error message (jami-gnome) or a console error (jami-qt) says that dring cannot be started. Best regards, Vivien

bug#51436: [PATCH] deja-dup does not build on core-updates-frozen

Dear guix, deja-dup does not build on core-updates-frozen. I think the best way to fix it is upgrade it to 42.8. What do you think? Best regards, Vivien From 92ea987cae3d3558bef30bb70f84e46b68a67d8f Mon Sep 17 00:00:00 2001 From: Vivien Kraus Date: Wed, 27 Oct 2021 12:38:16 + Subject:

bug#51435: unison does not build on core-updates-frozen

Dear guix hackers, unison (gnu/packages/ocaml.scm) does not build (the install-doc phase fails) on core-updates-frozen, because it lacks at least texlive-fonts- ec as an input, and then it fails with: dvips: ! Couldn't find header file: l3backend-dvips.pro I tried to add

bug#51127: Acknowledgement (deja-dup cannot start a backup)

Le jeudi 14 octobre 2021 à 18:56 +0200, Vivien Kraus a écrit : > Le jeudi 14 octobre 2021 à 18:43 +0200, Vivien Kraus a écrit : > > So, I figured out the Gio backends for duplicity need a few tweaks. > > > > You can test it by creating a stupid backup (backup any dir in > > /tmp). > > Now it

bug#51127: Acknowledgement (deja-dup cannot start a backup)

Le jeudi 14 octobre 2021 à 18:43 +0200, Vivien Kraus a écrit : > So, I figured out the Gio backends for duplicity need a few tweaks. > > You can test it by creating a stupid backup (backup any dir in /tmp). > Now it works :) Sorry, I forgot to run guix lint, and it said that I needed bash-

bug#51127: Acknowledgement (deja-dup cannot start a backup)

So, I figured out the Gio backends for duplicity need a few tweaks. You can test it by creating a stupid backup (backup any dir in /tmp). Now it works :) What do you think? Vivien From 429fdb8003a0f39a23749d15c02e2bfca9e96f15 Mon Sep 17 00:00:00 2001 From: Vivien Kraus Date: Thu, 14 Oct 2021

bug#50677: [PATCH] Minetest basic_materials really depends on moreores

Hello Maxime, Le mercredi 22 septembre 2021 à 20:43 +0200, Maxime Devos a écrit : > Vivien Kraus schreef op wo 22-09-2021 om 20:37 [+0200]: > > Le mercredi 22 septembre 2021 à 20:15 +0200, Maxime Devos a écrit : > > > The latest patch you sent looks good to me, but I didn't test ti. > > > > I

bug#51127: deja-dup cannot start a backup

Dear guix, After configuring deja-dup for either SSH storage or local file storage, I try to start the backup, but I get a popup saying: BackendException: Could not initialize backend: No module named 'gi' To me, it looks like a python error, but I could not find any substantial amount of

bug#50677: [PATCH] Minetest basic_materials really depends on moreores

Le mercredi 22 septembre 2021 à 20:15 +0200, Maxime Devos a écrit : > The latest patch you sent looks good to me, but I didn't test ti. I tested it by comparing the build of minetest-moreores when it fails because of the missing file and when it succeeds. Do you think it should be enough if it

bug#50677: [PATCH] Minetest basic_materials really depends on moreores

Le mercredi 22 septembre 2021 à 19:41 +0200, Maxime Devos a écrit : > It would be more convenient > if the output of Minetest was send to current-output-port, OK, so it’s like the existing solution, except it should not stop just at the first error. From ed878447d600aabdfd80073dab4fdb77cef3801d

bug#50677: [PATCH] Minetest basic_materials really depends on moreores

lylip on the #guix chat suggested to save the log to disk, so that the errors can be read in context. I think it is the best thing to do, what do you think? Vivien From f5cafa5aaf26b065f3627d5e013d06c86c251f8f Mon Sep 17 00:00:00 2001 From: Vivien Kraus Date: Sun, 19 Sep 2021 17:00:45 +0200

bug#50677: [PATCH] Minetest basic_materials really depends on moreores

Le dimanche 19 septembre 2021 à 21:11 +0200, Maxime Devos a écrit : > I found a use of "config.txt" ( > https://forum.minetest.net/viewtopic.php?t=2290), > "settingstypes.txt" ( > https://github.com/NathanSalapat/more_fire/blob/master/settingtypes.txt > ) > and another "_config.txt" ( >

bug#50677: [PATCH] Minetest basic_materials really depends on moreores

Le dimanche 19 septembre 2021 à 20:54 +0200, Vivien Kraus a écrit : > I forgot to say, I could not figure out why the package did not > build, > because the check phase in the minetest build system stops after the > first error line of output, which only stated that there was a > problem > with

bug#50677: [PATCH] Minetest basic_materials really depends on moreores

Hello, Le dimanche 19 septembre 2021 à 19:40 +0200, Maxime Devos a écrit : > > + (version "v2.1.0") > > Versions in guix don't use any leading "v" prefix. If I'm not > mistaken, > Ludovic applied the patched to remove them automatically. Right, I just had not guix pulled lately, I confirm it

bug#50677: [PATCH] Minetest basic_materials really depends on moreores

Dear guix, basic_materials actually requires moreores, otherwise some craft recipes are just not possible. For instance, basic_materials:silver_wire can only be crafted with moreores:silver_ingot. This silver wire is actually needed for basic technic machines, such as the LV compressor. So,

bug#49369: Duplicated SSL_CERT_DIR value, and the cuirass service

Dear guix, When I set up the cuirass service, my /run/current- system/profile/etc/profile file goes from: export SSL_CERT_DIR="${GUIX_PROFILE:- /gnu/store/v7yks560hnm9zkjw1ynsavfdgwbvkq9w- profile}/etc/ssl/certs${SSL_CERT_DIR:+:}$SSL_CERT_DIR" to: export SSL_CERT_DIR="${GUIX_PROFILE:-