bug#54558: mcomix refuses to run, missing GTK libraries

[Liliana Marie Prikler]

Hi Maxim,

Am Freitag, dem 25.03.2022 um 22:57 -0400 schrieb Maxim Cournoyer:
> Hi Liliana,
> 
> Liliana Marie Prikler  writes:
> 
> > [...]
> > +  (let ((p7zip (assoc-ref inputs "p7zip")))
> > +    ;; insert absolute path to 7z executable
> 
> I know it's in the original, but since while we're revamping the
> package, let's make this comment a proper complete sentence.
Thanks, did that.

> > +    (substitute* "mcomix/archive/sevenzip_external.py"
> > +  (("_7z_executable = -1")
> > +   (string-append "_7z_executable = u'" p7zip
> > "/bin/7z'")))
> 
> I'd use something like:
> 
> (format #f "_7z_executable = ~s"
>  (search-input-file inputs "bin/7z"))
> 
> For the replacement.  That unicode string (u"something") is
> obsolete/unnecessary (all strings are unicode in Python 3).
Thanks, did that.

> I haven't tried it, but LGTM with my above comments addressed.
I tried it in a pure shell and apart from the usual missing icons, it
launched fine.  Closing.

Cheers

bug#54631: Unable to determine system origin when configuration stored in guix channel

[Liliana Marie Prikler]

Am Dienstag, dem 29.03.2022 um 22:03 -0400 schrieb Collin J. Doering:
> [...]
> Notice how there is no way to see which configuration was used to
> create the system.
The key here is that you're using a configuration expression rather
than a file.  Were you to write those files to disk in let's say
config-a.scm and config-b.scm respectively and refer to them on the
command line like that, you'd have a configuration file guix could
refer to.

Alternatively, Guix could take the expression specified via -e and
write it to disk.  Note that some configuration files are meaningless
even if written to disk, for example...

> The second issue is that when `-L|--load-path` is used along with
> either a file or expression to specify the operating-system or home-
> configuration, it essentially 'tarnishes' the provenance of the
> system, in that the following deployment is not differentiable from
> the preceding one/s, despite them being different.
> 
> --8<---cut here---start->8---
> sudo -i guix system reconfigure -L my-local-channel-but-with-changes
> -e '(@ (my config system-a) %system)'
> --8<---cut here---end--->8---
> 
> --8<---cut here---start->8---
> ➜ guix system describe    
> Generation 32   Mar 28 2022 23:10:01(current)
>   file name: /var/guix/profiles/system-32-link
>   canonical file name: /gnu/store/s1f82wy0mj1zv3jvrzzc86h86zrdv336-
> system
>   label: GNU with Linux 5.16.16
>   bootloader: grub-efi
>   root device: label: "root"
>   kernel: /gnu/store/s1f82wy0mj1zv3jvrzzc86h86zrdv336-linux-
> 5.16.16/bzImage
>   channels:
>     guix:
>   repository URL: https://git.savannah.gnu.org/git/guix.git
>   branch: master
>   commit: e584a093f943be216fdc93895281fde835836b8d
>     my-config-channel:
>   repository URL: https://not-yet-on-the-internet.com
>   branch: master
>   commit: 918a3bf799038a019c7394cda480ee67db8a0009
> --8<---cut here---end--->8---
LOAD_PATH tweaking should be considered harmful and void your
provenance, at least w.r.t. channels.  There's no sane way for guix to
check whether the load paths you added still exist after
reconfiguration, other than placing the entire directory in the store.

Cheers

bug#54654: libx11 libxcursor handling - Problems with big cursors not working in Java and xterm

[Liliana Marie Prikler]

Am Donnerstag, dem 31.03.2022 um 15:31 +0200 schrieb Danny
Milosavljevic:
> [...]
> Possible fixes:
> 
> a. Patch openjdk and xterm (and who knows what) such that it also
> does the
>    XcursorTryShapeCursor before it calls XCreateFontCursor.
>    That's a lot of work.
>    Note: There are no libxcursor or XLoadFont bindings in openjdk
> yet,
>    and one is not supposed to access Display->cursor_font from
> outside.
>    Note: xterm use libxcursor--but for something else. So it still
>    doesn't work (because it doesn't call XcursorTryShapeCursor).
This solution works short-term and should probably be done in the
meantime while...

> b. Patch guix such that the libx11 package used by libxcursor is one
> without
>    reference to libxcursor, but a new user-visible libx11 package
> actually
>    would just link libxcursor in. Not sure whether that's such a good
>    idea--it could increase the size of everything and have two libx11
>    libraries loaded in the same user process, no?
this is the proper solution, which we would need to deploy on core-
updates first due to the enormous amount of dependents.  As for the two
libx11s being loaded into the same user process, I think there ought to
be a way of making that just one, which would be the big one containing
all the right paths.  I don't think libxcursor should reload libx11 if
there's already a libx11 dynamically loaded.

Cheers

bug#54691: fortune-mod propagates various non-nice things

[Liliana Marie Prikler]

Hi Maxime,

Am Sonntag, dem 03.04.2022 um 15:09 +0200 schrieb Maxime Devos:
> Hi guix,
> 
> fortune-mod currently propagates (in the non-technical sense) various
> non-nice things like objectification, misoginy, religious
> intolerance, anti-mathematician-ism (?) and date rape.  That is not
> an exhaustive list, these are just the first few things I encountered
> with "fortune off".
Well, the purpose of "fortune off" is to provide offensive "jokes".  As
such, if you're offended by them, you're kinda getting what you've
asked for.  If removing them falls under what our CoC states, though,
then so be it, I have no horse in this race.

More importantly...
> There are also a few non-nice things in the non-off set.
I think this should be reported upstream.  From what I could gather in
a short time, upstream appears both active (last commit 18 days ago)
and willing to make adjustments for "political correctness" (some two
years ago, they removed a lot of blonde jokes, though some simply got
demoted to still sexist jokes about women instead, and off is still
fair game for those, so...), so I think talking will get us further
than one-sided deletion here.

> As such, just removing 'off' doesn't seem sufficient.  Unless
> someone™ volunteers to remove the anti-fortunes (*), I would just
> remove 'fortune-mod', given that it seems to serve no practical
> purpose beyond being non-nice.  WDYT?
I don't think practical purpose is a bar we can set.  What should we do
with all of the Rust ecosystem otherwise?
(For Rust fans, who were offended by the above, consider collecting
this and other quotes from yours truly in a new offensive/rust file and
we can both be happy.)

As for being non-nice on purpose, I disagree.  It's rather a shame if
the supposedly inoffensive set is still offensive.  And if lack of
humor is a concern, "A nuclear war can ruin your whole day." from
politics sounds just about fine to me :)

Cheers

bug#54417:

[Liliana Marie Prikler]

Pushed a fix as 99b41ffcbf399b1d51b5f90eaa706c9a05173cb1.

bug#50329: [PATCH] Bundle icons for emacs-lsp-treemacs

[Liliana Marie Prikler]

Hi Roman, hi Maxime,

Am Sonntag, dem 20.03.2022 um 11:35 +0100 schrieb Roman Scherer:
> Hi Maxime,
> 
> ok, I see. Thanks for the explanation. I attached a patch that
> removes the icons from the source as per your suggestion.
> 
> What do you think about this one?
> 
> Thanks, Roman.
The logic behind your patch LGTM, but it lacks an explanatory comment.
Don't worry about resending the patch, though -- I already added the
comment locally and am currently looking to also apply this to emacs-
company-box.  If either of you could check whether those icons are
referred to by name in emacs-lsp-treemacs while I'm working on company-
box, that'd be appreciated.

Cheers

bug#50329: [PATCH] Bundle icons for emacs-lsp-treemacs

[Liliana Marie Prikler]

Hi Roman,

Am Sonntag, dem 20.03.2022 um 12:21 +0100 schrieb Roman Scherer:
> 
> Hi Liliana,
> 
> thanks for adding the comment locally. I just checked the source of
> LSP Treemacs and yes, they are all mentioned by name here:
> 
> https://github.com/emacs-lsp/lsp-treemacs/blob/master/lsp-treemacs-themes.el#L38
> 
> Is this a problem? Should the build script remove them?
> 
> If that's the case, we could remove all those "icon themes" and just
> leave this "Iconless" theme in the file:
> 
> https://github.com/emacs-lsp/lsp-treemacs/blob/master/lsp-treemacs-themes.el#L209
> 
> Roman
Sadly, replacing these in a snippet won't be that easy, given we can't
easily sneak emacs into it.  On the topic of icons to remove, vscode-
icons might actually be okay and are also required by default.

What should we do? 

bug#50329: [PATCH] Bundle icons for emacs-lsp-treemacs

[Liliana Marie Prikler]

Hi Roman,

Am Sonntag, dem 20.03.2022 um 14:58 +0100 schrieb Roman Scherer:
> Hi Liliana and Maxime,
> 
> if the icons are really coming from [1], they seem to be licensed
> under the Creative Commons Attribution 4.0 International Public
> License.
> 
> If it is okay to include them, I could work on a patch that only
> installs the VS Code icons. I think we need to give credit and link
> to the Creative Commons license.  Is it enough to add it to the
> license field and mention/link the VS Code icons in the description
> field?
Adding the license to the field with an appropriate comment would be
enough imho.  If upstream decides to make a new release, we can also
use that -- or alternatively bump to the commit.

> Before doing that, I would wait until someone clarified that the
> icons are really coming from [1] in the upstream issue.
> 
> In the meantime I think it's best to include my patch that removes
> all icons from the source.
> 
> What do you think?
I'm in the "let's wait and do the correct thing" camp.  Having one
commit to restrict the sources to the correct set would be more
justifiable than overreacting, particularly given the FSDG stance on
non-functional data.  That said, long-term this data needs to go :)

Cheers

bug#54607: ncurses attrset colour pair ignored in favour of bkgd

[Liliana Marie Prikler]

Am Montag, dem 28.03.2022 um 15:00 +0300 schrieb Roman Riabenko:
> gcc test.c -lncurses
This is not a sufficient invocation to get ncurses working correctly.

$ ncursesw6-config --cflags
-D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -
I/gnu/store/9rrnm5hdjw7cy96a2a9rfgh6y08wsbmf-ncurses-
6.2.20210619/include

$ ncursesw6-config --libs  
-L/gnu/store/9rrnm5hdjw7cy96a2a9rfgh6y08wsbmf-ncurses-6.2.20210619/lib
-Wl,-rpath=/gnu/store/9rrnm5hdjw7cy96a2a9rfgh6y08wsbmf-ncurses-
6.2.20210619/lib -lncursesw

$ pkg-config --cflags ncurses
-D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -
I/gnu/store/9rrnm5hdjw7cy96a2a9rfgh6y08wsbmf-ncurses-
6.2.20210619/include

$ pkg-config --libs ncurses  
-Wl,-rpath=/gnu/store/9rrnm5hdjw7cy96a2a9rfgh6y08wsbmf-ncurses-
6.2.20210619/lib -lncursesw

Cheers

bug#36924: GDM, GNOME Shell, etc. break when there are stale caches

[Liliana Marie Prikler]

Am Mittwoch, dem 23.03.2022 um 12:28 +0100 schrieb zimoun:
> Hi,
> 
> This old bug [1] is there since a long time.  What is the status?
> 
> 1: 
> 
> [...]
> 
> Is it still an issue?
If I recall correctly, the offending caches have not been updated
since, so the short answer is "we don't know".  The files in my
/var/lib/gdm have some quite old dates, some of them ranging as far
back as 2019, so I suppose there still exists an issue potential.

Cheers

bug#53591: [PATCH] gnu: audacity: Add fallback to locate ffmpeg via pkg-config.

[Liliana Marie Prikler]

* gnu/packages/patches/audacity-ffmpeg-fallback.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it here.
* gnu/packages/audio.scm (audacity)[patches]: Use it here.
[inputs]: Add back ffmpeg.
---
 gnu/local.mk  |  1 +
 gnu/packages/audio.scm|  2 +
 .../patches/audacity-ffmpeg-fallback.patch| 61 +++
 3 files changed, 64 insertions(+)
 create mode 100644 gnu/packages/patches/audacity-ffmpeg-fallback.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 96e6cb08f4..898e8e92e3 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -859,6 +859,7 @@ dist_patch_DATA =   
\
   %D%/packages/patches/ath9k-htc-firmware-gcc-compat.patch \
   %D%/packages/patches/ath9k-htc-firmware-objcopy.patch\
   %D%/packages/patches/atlas-gfortran-compat.patch \
+  %D%/packages/patches/audacity-ffmpeg-fallback.patch  \
   %D%/packages/patches/audiofile-fix-datatypes-in-tests.patch  \
   %D%/packages/patches/audiofile-fix-sign-conversion.patch \
   %D%/packages/patches/audiofile-CVE-2015-7747.patch   \
diff --git a/gnu/packages/audio.scm b/gnu/packages/audio.scm
index feccf662b0..22dd88ef0c 100644
--- a/gnu/packages/audio.scm
+++ b/gnu/packages/audio.scm
@@ -738,6 +738,7 @@ (define-public audacity
(sha256
 (base32
  "189agx11361k9j958s6q5bngnnfx0rwaf0dwbjxy6fwvsb1wv3px"))
+   (patches (search-patches "audacity-ffmpeg-fallback.patch"))
(modules '((guix build utils)))
(snippet
 ;; Remove bundled libraries.
@@ -768,6 +769,7 @@ (define-public audacity
lame
linux-libre-headers
flac
+   ffmpeg
libid3tag
libjpeg-turbo
libmad
diff --git a/gnu/packages/patches/audacity-ffmpeg-fallback.patch 
b/gnu/packages/patches/audacity-ffmpeg-fallback.patch
new file mode 100644
index 00..9e88973241
--- /dev/null
+++ b/gnu/packages/patches/audacity-ffmpeg-fallback.patch
@@ -0,0 +1,61 @@
+From 3c20057d0cbbbed453a692d4dd4589d865808024 Mon Sep 17 00:00:00 2001
+From: Liliana Marie Prikler 
+Date: Sat, 29 Jan 2022 10:44:44 +0100
+Subject: [PATCH] Add pkg-config fallback for locating ffmpeg.
+
+---
+ libraries/lib-ffmpeg-support/CMakeLists.txt  |  8 
+ libraries/lib-ffmpeg-support/FFmpegFunctions.cpp | 12 
+ 2 files changed, 20 insertions(+)
+
+diff --git a/libraries/lib-ffmpeg-support/CMakeLists.txt 
b/libraries/lib-ffmpeg-support/CMakeLists.txt
+index 8c5f06d7c..00810e4d0 100644
+--- a/libraries/lib-ffmpeg-support/CMakeLists.txt
 b/libraries/lib-ffmpeg-support/CMakeLists.txt
+@@ -1,5 +1,7 @@
+ 
+ if (${_OPT}use_ffmpeg)
++   pkg_check_modules(FFMPEG libavcodec libavformat libavutil)
++
+set( SOURCES
+   FFmpegTypes.h
+ 
+@@ -100,6 +102,12 @@ if (${_OPT}use_ffmpeg)
+   list(APPEND DEFINITIONS PRIVATE _DARWIN_C_SOURCE )
+endif()
+ 
++   if (FFMPEG_FOUND)
++  pkg_get_variable(LIBAVCODEC_LIBDIR libavcodec libdir)
++  list(APPEND DEFINITIONS PRIVATE
++  "-DFFMPEG_PC_LIBDIR=L\"${LIBAVCODEC_LIBDIR}\"")
++   endif()
++
+audacity_library( lib-ffmpeg-support "${SOURCES}" "${LIBRARIES}"
+   "${DEFINITIONS}" ""
+)
+diff --git a/libraries/lib-ffmpeg-support/FFmpegFunctions.cpp 
b/libraries/lib-ffmpeg-support/FFmpegFunctions.cpp
+index 66d085a0b..4eeb4aed3 100644
+--- a/libraries/lib-ffmpeg-support/FFmpegFunctions.cpp
 b/libraries/lib-ffmpeg-support/FFmpegFunctions.cpp
+@@ -238,6 +238,18 @@ struct FFmpegFunctions::Private final
+   if (library->IsLoaded())
+  return library;
+ 
++#if defined(FFMPEG_PC_LIBDIR)
++  {
++ static const wxString libdir{FFMPEG_PC_LIBDIR};
++ const wxString fullName = wxFileName(libdir, 
libraryName).GetFullPath();
++
++ auto library = std::make_shared(fullName);
++
++ if (library->IsLoaded())
++return library;
++  }
++#endif
++
+   // Loading has failed.
+   // wxLogSysError doesn't report errors correctly on *NIX
+ #if defined(_WIN32)
+-- 
+2.34.0
+
-- 
2.34.0

bug#53696: Integer overflow on Guix GC size calculation

[Liliana Marie Prikler]

Am Dienstag, dem 01.02.2022 um 14:06 + schrieb Ekaitz Zarraga:
> Hi,
> 
> I noticed there's some kind of a wierd integer overflow on the size
> calculation on `guix gc`:
> 
> [17592186042896 MiB] deleting
> '/gnu/store/j2s6kva8l20m6rjj10bnknq99jc9rg6w-ghc-random-1.2.0-
> builder'
> [17592186042896 MiB] deleting
> '/gnu/store/8nx7zzj629qvv1533c48bl19wrkwcjh2-curl-7.79.1-doc'
> [17592186042897 MiB] deleting
> '/gnu/store/dcsi13588yyjws76s1wjc7h5spnjd2vn-ghc-kan-extensions-
> 5.2.3-builder'
> [17592186042897 MiB] deleting
> '/gnu/store/5zrhw6kvb8wd3n6lazpblqzsg92y320b-ghc-sop-core-0.5.0.1-
> builder'
> [17592186042897 MiB] deleting
> '/gnu/store/l2ya1z3la9qfdj9139f09q3djs36lw3l-ghc-aeson-pretty-0.8.9-
> builder'
> [17592186042897 MiB] deleting
> '/gnu/store/8a8nbfxq508r7qywkhaw8jj8hicpfjh8-ghc-prelude-extras-
> 0.4.0.3-builder'
> [17592186042897 MiB] deleting
> '/gnu/store/wbz6vkiz7cq8c531xvb31lxm28nz332i-ghc-8.10.7'
> [19 MiB] deleting '/gnu/store/i5np7ifiabg333g2l8ycmvbhimnrrx8k-ghc-
> 8.10.7-doc'
> [170 MiB] deleting '/gnu/store/yx9zjw9118gzfcx33adfwy6kghrzxkys-ghc-
> pem-0.2.4-builder'
> [170 MiB] deleting '/gnu/store/pinvkg1x5rpsgm95zhn50l6xq7rly43f-perl-
> test-output-1.033.drv'
> [170 MiB] deleting '/gnu/store/k1bdc950d62g1pw4yw1khgmfr32m3rpm-perl-
> sub-exporter-0.988.drv'
I find it somewhat concerning that you've accumulated more than 2^64
bytes of garbage.  Are some items counted double here?
Other than that, that's pretty normal size_t wraparound semantics.  I
don't think that number is used for anything other than displaying.

Cheers

bug#53696: Integer overflow on Guix GC size calculation

[Liliana Marie Prikler]

Hi,

Am Mittwoch, dem 02.02.2022 um 19:51 + schrieb Ekaitz Zarraga:
> I mean something like:
> 
> 0
> 1
> 2
> 4
> 8
> 10
> 12
> HUGE_NUMBER
> HUGE_NUMBER
> ...
> HUGE_NUMBER
> 15
> 20
> ...
> 
> It's like it corrected itself. It happened in "low numbers" (less
> than a
> hundred).
> 
> I just say this if it helps in the correction. It's very funny, still
> :3
Thanks, that wasn't clear from your original report.  As I hinted at in
my previous message, I think you'd get such results through well-placed
bit flips.  I'm not aware of Guix itself intentionally or otherwise
causing those, but bit flips are a problem on any modern hardware and
thus I'm sure such glitches will be encountered.

bug#53696: Integer overflow on Guix GC size calculation

[Liliana Marie Prikler]

Hi,

Am Dienstag, dem 01.02.2022 um 21:54 + schrieb Ekaitz Zarraga:
> 
> Hi,
> 
> ‐‐‐ Original Message ‐‐‐
> 
> On Tuesday, February 1st, 2022 at 10:20 PM, Liliana Marie Prikler
>  wrote:
> > 
> > I find it somewhat concerning that you've accumulated more than
> > 2^64 bytes of garbage.
> 
> I'm a dirty boy.
> 
> > Are some items counted double here?
> 
> The number started growing from 0 and then that appeared and it
> continued smoothly from the previous. It's like something went bad in
> the middle.
WDYM by the middle?  Do you mean the jump back to 0 or do you mean
something before those lines?  If you did encounter a "self-correcting"
bit-flip that'd be one thing, but to me it appears as though you have
some very large storage on your hands.  Would you mind me asking where
you purchased that disk 

> > Other than that, that's pretty normal size_t wraparound semantics.
> > I don't think that number is used for anything other than
> > displaying.
> 
> Showing wrong information to the people that use the program is
> pretty weird. The program still works but showing wrong data is worse
> than not showing it in my opinion.
> I'll take a look and try to see if I can fix it.
I mean we could switch to GMP for those numbers, but it doesn't make
sense.  Ext4 volume size is capped at 2^60, which is still pretty well
below 2^64.  Even BTRFS can't get larger than that.  So unless you have
a distributed store, I'd hazard a guess that such numbers ought not to
even appear.

Cheers

bug#53752: guix home symlink permissions

[Liliana Marie Prikler]

Am Donnerstag, dem 03.02.2022 um 13:08 -0500 schrieb Zacchaeus
Scheffer:
> I finally migrated my home configuration to guix home.  However, it
> seems guix home creates all symlinks with 777 permissions.  This causes
> problems with openssh as it will not recognize my
> ~/.ssh/authorized_keys.  It seems the directories have reasonable
> permissions (maybe because they already existed?), but it seems like
> someone could in theory edit the symlinks in-place (though I wasn't
> able to figure that out).
Instead of using symllinks for ~/.ssh/authorized_keys, you could try to
write a home-activation-service, which

1. creates ~/.ssh with chmod 700
1a. if it already existed, enforces chmod 700 anyways
2. creates authorized_keys with chmod 600 if it doesn't exist
3. writes the authorized keys.

I would strongly advise against that however.  While user homes are by
default 700 in Guix, the store is world readable and so are your
authorized keys if you put them there.  A malicious user can't
necessarily change them, but they can spy on you.

Guix currently has no way of securely storing your data in the store
(in a cryptographic sense).  This is exacerbated by the fact that such
files aren't well-encrypted by default -- user read-only is "good
enough" in many cases, e.g. gnome-keyring does encrypt passwords, but
stores metadata in plain.  Emacs plstores and Recfiles likewise support
partial encryption based on GPG.

This issue has been known since June 2020 [1].  While there would in
theory exist solutions that can work for (guix home) but not (guix
system), I can not yet make any statements regarding their quality. 
Indeed, storing secrets with Guix is an open issue, that will likely be
given some attention during the upcoming Guix Days.

Cheers

[1] https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00091.html

bug#53790: Audacity has extraneous binary at directory root

[Liliana Marie Prikler]

Hi Leo,

Am Freitag, dem 04.02.2022 um 17:03 -0500 schrieb Leo Famulari:
> Our Audacity package creates an extraneous "audacity" binary in the
> root of the store item:
> 
> --
> $ git describe   
> v1.3.0-15695-gba60aede97 
> $ ls -la $(./pre-inst-env guix build audacity)    
> total 49012    
> dr-xr-xr-x    6 root root  4096 Dec 31  1969 .
> drwxrwxr-t 3440 root guixbuild 50139136 Feb  4 17:00 ..
> -r-xr-xr-x    1 root root   337 Dec 31  1969 audacity
> dr-xr-xr-x    2 root root  4096 Dec 31  1969 bin
> dr-xr-xr-x    2 root root  4096 Dec 31  1969 etc
> dr-xr-xr-x    3 root root  4096 Dec 31  1969 lib
> dr-xr-xr-x   11 root root  4096 Dec 31  1969 share
> $ ls -la $(./pre-inst-env guix build audacity)/bin
> total 18404
> dr-xr-xr-x 2 root root 4096 Dec 31  1969 .
> dr-xr-xr-x 6 root root 4096 Dec 31  1969 ..
> -r-xr-xr-x 1 root root  600 Dec 31  1969 audacity
> -r-xr-xr-x 2 root root 18827912 Dec 31  1969 .audacity-real
> --
Looking at the size of this thing compared to our audacity, I thought
to myself "hmm, that's a shell script" and sure enough

--8<---cut here---start->8---
#!/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/sh

lib="${0%/*}/lib/audacity"
share="${0%/*}/share/audacity"

export LD_LIBRARY_PATH="${lib}:${LD_LIBRARY_PATH}"
export AUDACITY_MODULES_PATH="${AUDACITY_MODULES_PATH}:${lib}/modules"
export AUDACITY_PATH="${AUDACITY_PATH}:${share}"

exec "${0%/*}/bin/audacity" "$@"
--8<---cut here---end--->8---
At the time of writing none of these appear particularly needed, though
if the time comes we might just port over the 'wrap-emacs-paths phase.

We can try searching for the bits in CMakeLists that install this
wrapper or we can simply drop the file.  WDYT?

bug#53559: [PATCH] gnu: mutter: Disable timeline tests.

[Liliana Marie Prikler]

* gnu/packages/gnome.scm (mutter)[disable-problematic-tests]: Also disable
timeline tests.
---
 gnu/packages/gnome.scm | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/gnome.scm b/gnu/packages/gnome.scm
index e3fac534c4..b341fb4c97 100644
--- a/gnu/packages/gnome.scm
+++ b/gnu/packages/gnome.scm
@@ -7477,7 +7477,11 @@ (define-public mutter
  ;; expression paragraph.  For an explanation, see: info '(sed)
  ;; Multiline techniques'.
  (invoke "sed" "/./{H;$!d} ; x ; s/^.*native-headless.*$//"
- "-i" "src/tests/meson.build")))
+ "-i" "src/tests/meson.build")
+ ;; Timeline tests may unexpectedly fail on missed frames, so
+ ;; let's disable them as well.
+ (substitute* "src/tests/clutter/conform/meson.build"
+   (("'timeline.*',") ""
  (replace 'check
(lambda* (#:key tests? test-options parallel-tests?
  #:allow-other-keys)
-- 
2.34.0

bug#53591: [PATCH] gnu: audacity: Add fallback to locate ffmpeg via pkg-config.

[Liliana Marie Prikler]

Am Samstag, dem 29.01.2022 um 14:53 -0500 schrieb Leo Famulari:
> On Sat, Jan 29, 2022 at 06:54:54PM +0100, Liliana Marie Prikler
> wrote:
> > * gnu/packages/patches/audacity-ffmpeg-fallback.patch: New file.
> > * gnu/local.mk (dist_patch_DATA): Add it here.
> > * gnu/packages/audio.scm (audacity)[patches]: Use it here.
> > [inputs]: Add back ffmpeg.
> 
> Well, this is fantastic Liliana! It works great.
> 
> Can you add a comment to 'audacity-ffmpeg-fallback.patch' with a link
> to <https://issues.guix.gnu.org/53591>?
Done and pushed.

bug#53790: Audacity has extraneous binary at directory root

[Liliana Marie Prikler]

Hi,

Am Samstag, dem 05.02.2022 um 13:52 -0500 schrieb Leo Famulari:
> On Sat, Feb 05, 2022 at 08:22:32AM +0100, Liliana Marie Prikler
> wrote:
> > Looking at the size of this thing compared to our audacity, I
> > thought to myself "hmm, that's a shell script" and sure enough
> > 
> > --8<---cut here---start->8---
> > #!/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-
> > 5.1.8/bin/sh
> > 
> > lib="${0%/*}/lib/audacity"
> > share="${0%/*}/share/audacity"
> > 
> > export LD_LIBRARY_PATH="${lib}:${LD_LIBRARY_PATH}"
> > export
> > AUDACITY_MODULES_PATH="${AUDACITY_MODULES_PATH}:${lib}/modules"
> > export AUDACITY_PATH="${AUDACITY_PATH}:${share}"
> > 
> > exec "${0%/*}/bin/audacity" "$@"
> > --8<---cut here---end--->8---
> 
> Interesting...
> 
> > At the time of writing none of these appear particularly needed,
> > though
> > if the time comes we might just port over the 'wrap-emacs-paths
> > phase.
> 
> I figure it's there for a reason. Maybe we just need to make sure it
> ends up in 'bin/'? But, it's weird that the build scripts create
> multiple executables with the same name in these different
> directories.
I don't think it should be in bin/. Looking at the script, it appears
to be written for the install root, which... eh...

> > We can try searching for the bits in CMakeLists that install this
> > wrapper or we can simply drop the file.  WDYT?
> 
> I don't know... I wonder if Audacity is worse for Guix users since
> this shell script doesn't end up in $PATH.
Concerning LD_LIBRARY_PATH, that probably has no effect on Guix users.
AUDACITY_MODULES_PATH and AUDACITY_PATH could bug them, but only if run
through the store – I already added search-path specifications for
them. The question therefore really is whether to extend our wrapper or
not.

   1. Cheers

bug#53752: guix home symlink permissions

[Liliana Marie Prikler]

Am Montag, dem 07.02.2022 um 22:02 +0100 schrieb Maxime Devos:
> Zacchaeus Scheffer schreef op ma 07-02-2022 om 14:47 [-0500]:
> > I was able create the desired effect with the following service
> > definition:
> > (simple-service
> >  'my-activation-service
> >  home-activation-service-type
> >  (gexp
> >   (begin
> >     (chdir (ungexp user-home))
> >     (if (not (file-exists? ".ssh"))
> >         (mkdir ".ssh"))
> >     (chmod ".ssh" #o700)
> >     (chdir ".ssh")
> >     (let ((port (open-output-file "authorized_keys")))
> >       (display (ungexp authorized-keys) port)
> >       (close-port port))
> >     (chmod "authorized_keys" #o600)
> >     (chdir ".."
> > where 'user-home and 'authorized-keys are appropriate strings
> > defined earlier in the file.
> > 
> > I believe that resolves the issue,
> 
> Users shouldn't have to do this (relatively) huge block of relatively
> inscrutable code though, I believe something along these lines (or a
> different solution) needs to be implemented in Guix itself somewhere
> before the issue is resolved.
I'll again be pointing at the "don't put secrets into your store"
shield.  We'd have to find a reasonable way of encrypting sensitive
data before we can do a home-ssh-service-type.

@Zacchaeus, your code can likely be simplified to
#~(with-directory-excursion #$user-home
(mkdir-p ".ssh")
(chmod ".ssh" #o700)
(with-directory-excursion ".ssh"
  (copy-file #$authorized-keys "authorized_keys")
  (chmod "authorized_keys" #o600)))
though perhaps there's some magic incantation to import (guix build
utils) for mkdir-p and with-directory-excursion that I'm missing here.

Cheers

bug#53857: telegram-desktop: fails to build

[Liliana Marie Prikler]

Hi Christopher,

Am Montag, dem 07.02.2022 um 09:32 -0900 schrieb Christopher Howard:
> {standard input}:1918775: Warning: end of file not at end of a line;
> newline inserted
> {standard input}: Error: open CFI at the end of file; missing
> .cfi_endproc directive
> c++: fatal error: Killed signal terminated program cc1plus
> compilation terminated.
> make[2]: *** [Telegram/CMakeFiles/td_scheme.dir/build.make:79:
> Telegram/CMakeFiles/td_scheme.dir/gen/scheme.cpp.o] Error 1
> make[2]: Leaving directory '/tmp/guix-build-telegram-desktop-2.9.3.drv-
> 0/build'
> make[1]: *** [CMakeFiles/Makefile2:1618:
> Telegram/CMakeFiles/td_scheme.dir/all] Error 2
> make[1]: *** Waiting for unfinished jobs
> ```
According to [1], this happens when GCC runs out of memory.  You could
try decreasing parallelism to see how that goes, but I'd hazard a guess
that telegram-desktop is too large for measly 12 gigs of RAM+swap.

> I will attached the build log. Here is my system information:
> 
> ```
> christopher@theoden ~$ guix describe
> Generation 31   Feb 04 2022 09:30:14(current)
>   guix 8391a99
>     repository URL: https://git.savannah.gnu.org/git/guix.git
>     branch: master
>     commit: 8391a99d089322a39cbacb1e6dc2979d8b2ef7c9
Note that the last build of telegram-desktop succeeded in the
evaluation of commit 11590bff50fe0244e66c11d995aa5301c8965959 [2],
which admittedly is newer than February 4th, but the recipe hasn't
changed in between as far as I'm aware.  I therefore don't think that
the package itself is broken.

Cheers


[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67571
[2] https://ci.guix.gnu.org/build/467392/log/raw

bug#53873: False flag

[Liliana Marie Prikler]

Am Dienstag, dem 08.02.2022 um 11:48 +0100 schrieb Rovanion Luckey:
> Never mind, it was a networking error and `guix pull` worked fine on
> a rerun.
Flagging it done then ️

bug#53915: No way of replacing an input in modify-input syntax structure but keep all the outputs

[Liliana Marie Prikler]

Am Donnerstag, dem 10.02.2022 um 10:09 + schrieb Gordon Quad:
> poppler package include glib as a native-input with "bin" output.
> 
> If I am doing the following:
> 
> (package/inherit poppler
>     (native-inputs
>     (modify-inputs (package-native-inputs poppler)
>     (replace "glib" my-glib
> 
> poppler's build will fail becuase replace syntax will replace "glib"
> package erasing its outputs. I can specify output explicitly by doing
> (replace "glib" (my-glib "bin")) in this case, but that makes mass
> input modification difficult (e.g. if i want to replace all instances
> of glib to my-glib).
I think the problem here is that "glib" serves double duty as both
"glib:out" and "glib:bin".  IMHO we should probably add the output
argument to the label (with a colon separator, of course) if one is
given.

I'm CC'ing Ludo because he implemented the feature and might know more
than me regarding its design.

Cheers

bug#53840: The current bitlbee-discord@0.4.3 does not work with glib@2.70.2

[Liliana Marie Prikler]

Hi,

Am Montag, dem 07.02.2022 um 09:44 +0100 schrieb Adam Maleszka:
> I'm trying to configure bitlbee-discord in order to write on Discord
> using ERC in Emacs. Unfortunately, every time I open connection to
> Discord, this error is thrown:
> 
> [...]
> I see three solutions.

> * The third solution --- patching current release
> 
> Last but not least, what about writing a patch for the current release?
> The mentioned commit does not seem complicated. I think it is the best
> solution, because it gives us more control while preserving the
> stability of the release. However, it is always extra work.
If the patch applies cleanly on 0.4.3, this is to be preferred.

> * The second solution --- requesting a new release
> 
> That said, I think it would be a good idea to request a new release
> from the author, particularly as glib@2.70.X is becoming more common.
> 
> However, there is no certainty that the new release would be stable,
> though.
Upstreams decide what they consider stable enough to tag as release.  I
don't think pinging them would be too bad, considering they have a
history of tagging patch releases :)

> * The first solution --- upgrade bitlbee-discord
> 
> This solution involves upgrading bitlbee-discord to the specified
> commit. I don't think it will make the package more unstable,
> especially after this post:
> https://github.com/sm00th/bitlbee-discord/issues/118#issuecomment-606856620
> 
> However, it would be good to stick to convention and only introduce
> "stable" release versions.
If all else fails, this would count as an "exceptional case" to use
commit versioning -- see `info "(guix)Version Numbers"' for more
context.  Don't forget to clearly explain the reason for the commit you
picked in a comment preceding the let-binding, i.e. as in

(define bitlbee-discord
  ;; We use this commit, because ...
  (let ((commit "deadbeef")
(revision "1"))
(package 
   ...
   (version (git-version "0.4.3" revision commit))
   ...)))

Of course, instead of deadbeef, use the full commit hash.

Cheers

bug#53857: telegram-desktop: fails to build

[Liliana Marie Prikler]

Am Mittwoch, dem 09.02.2022 um 11:18 -0900 schrieb Christopher Howard:
> Hi, when I try to build with `guix build -M 1 -c 1 telegram-desktop`
> I seem to be getting the same error. I can believe what you say about
> the ram, as I've run into that problem before with other packages,
> though it seems frustrating I can't use some kind of command line
> option or something to tell the linker/compiler/assembler to use less
> ram. Seems strange that any package should need more than a GB or two
> of ram to build (*end rant*).
> 
> One thing though: using the above command-line options, I see that
> the last message in the build log is:
> 
> ```
> error: in phase 'build': uncaught exception:
> %exception #< program: "make" arguments: ("-j" "4")
> exit-status: 2 term-signal: #f stop-signal: #f> 
> phase `build' failed after 254.0 seconds
> command "make" "-j" "4" failed with status 2
> ```
> 
> Isn't using -M 1 in the guix build options supposed to translate to
> "make -j 1", or do I misunderstand?
-M 1 tells *guix* how many jobs it should use in parallel.  What you're
aiming fore is probably -c 1.

bug#48300: closed (Re: Emacs cursor theme is not inherited from the OS when using foreign Guix)

[Liliana Marie Prikler]

Am Donnerstag, dem 20.01.2022 um 09:29 -0300 schrieb Jorge P.de Morais
Neto:
> I have defined TZDIR on ~/.profile and so far it's working.  Let's
> see if it continues to work well.
> 
> And how will other users know how to fix the problem?  Will Guix's
> manual be updated?  There could also be a message in the Emacs
> package description.
By reading the manual (or cookbook).  Updating package descriptions
with a list of quirky annoyances on foreign distros is surely overkill.
We don't even put CVEs in there, instead describing those to ignore in
a property.

I'll write up an appropriate entry once I've figured out how I want to
word it.  However, I'd like to also state for the record, that a lack
of such is not really a bug in Guix.  Applications packaged in Guix not
only honour the environment variables they're supposed to honour, they
sometimes even have more of them.  The trouble comes from implicit
defaults being assumed (and therefore not set) by the foreign distro.

Cheers

bug#53407: libfuse 3 can't find fusermount

[Liliana Marie Prikler]

Hi Leo,

Am Freitag, dem 21.01.2022 um 02:41 -0500 schrieb Leo Famulari:
> While testing a Borg update (patch attached), I noticed that the
> FUSERMOUNT_DIR hack in Fuse 3 doesn't seem to work like it does with
> Fuse 2.
> 
> The 1.2.0b3 beta of the upcoming Borg release can use either Fuse 2
> (with python-llfuse) or Fuse 3 (with python-pyfuse3).
> 
> The `borg mount` command works as expected with Fuse 2 / llfuse.
> 
> But, with Fuse 3 / pyfuse3, it fails with:
> 
> fuse: failed to exec fusermount3: No such file or directory
> 
> When I commented out the FUSERMOUNT_DIR [0] substitution in the fuse-
> 3 package and rebuilt Borg, `borg mount` instead gives us this, which
> is expected, because this system does not have a setuid fusermount3:
> 
> fusermount3: mount failed: Operation not permitted
> 
> So, the substitution doesn't seem to help with Fuse 3: it just breaks
> the lookup.
> 
> You can apply the patch and test it out. And you can also observe the
> optimal behaviour if you switch the borg package's fuse
> implementation from pyfuse3 to llfuse / Fuse 2.
> 
> Should we just remove the substitution in fuse-3?
What is the behaviour if you have fusermount3 setuid?  I know from gvfs
(which also depends on Fuse 3), that adding the setuid binary *does*
make gvfsd-fuse work again, so it'd be good to know if this works for
borg as well.  If not, we'd have to be careful not to introduce a
regression. 


Cheers

bug#53127: [PATCH RFC] Turning Rust/Cargo inputs into “regular” inputs?

[Liliana Marie Prikler]

Am Samstag, dem 08.01.2022 um 18:57 +0100 schrieb Ludovic Courtès:
> Hello!
> 
> I’m opening this issue to discuss the possibility of changing
> #:cargo-inputs and #:cargo-development-inputs to regular inputs, as a
> followup to:
> 
>   https://issues.guix.gnu.org/51845#10
> 
> I have a preliminary patch for ‘guix style’ and (guix build-system
> cargo), but there’s a couple of stumbling blocks.
> 
> First, after the hacky patch in the discussion above, I attempted to
> turn #:cargo-inputs into ‘propagated-inputs’ (instead of ‘inputs’),
> because that seemed to be somewhat more logical.  That cannot work
> though, because then those packages would propagate to non-Rust
> packages; for example, librsvg would depend on the “build output” of
> rust-* instead of just depending on its source.  Anyway, I’m back to
> ‘inputs’.
> 
> Second, until now, these two things would have a different meaning:
> 
>   #:cargo-inputs (list rust-cargo)
> 
> vs.
> 
>   (inputs (list rust-cargo))
> 
> In the latter case, the package depends on the build result of
> ‘rust-cargo’; in the former case, the package depends on the source
> of ‘rust-cargo’.  (See ‘rav1e’ for an example where this happens.)
I suppose adding (package-source rust-cargo) to inputs to preserve the
old meaning would not make much sense?  If so, what about having a
source output and using (list `(,rust-cargo "source") ...)?

> Last, the change to ‘inputs’ would introduce a few cycles at the
>  level.  Those cycles vanish when we lower to bags and
> derivations.  However, because of these cycles, things like ‘guix
> refresh -l’ may not work; there might be other unexpected and
> undesired side effects.
What about making the change incrementally, so that outer layers can
start adopting the new style while inner layers are being
rebootstrapped.  I also think it'd make sense to see how we could
detect cycles through static analysis.

> Some of these cycles could in theory be removed.  For instance,
> ‘rust-cfg-if’ has an optional dependency on ‘rust-compiler-builtins’,
> which leads to a cycle, but Cargo won’t let us actually remove that
> dependency, even though it’s optional.
Could we rewrite the toml file to tell Cargo it has no power over us? 
Could we define bootstrap mockups?

> PS: I guess you already knew all this Efraim but I’m kinda
>     (re)discovering it and now experiencing frustration firsthand. 
> :-)
Let's hope at least someone in our team has overcome Rust fatigue by
the time the GCC frontend for it lands.  Rust is an incredibly good
language, all it needs is a reasonable compiler and build system.

Cheers

bug#53043: Dash To Dock 71 not working properly with Gnome Shell 41

[Liliana Marie Prikler]

Hi,

Am Freitag, dem 07.01.2022 um 03:56 + schrieb raid5atemyhomework:
> Hello Liliana,
> 
> [...]
> 
> 
> It may be a *related* bug, but this may also be unique to how Guix
> packages both programs.  So I want to know if other users on Guix are
> seeing the same thing as well.
We don't do rigorous integration tests for GNOME Shell extensions and
to my knowledge you are the first one to report that bug.

> Given the default `(service gnome-desktop-service-type)`, where does
> `gnome-shell` put its logs?
> There are no logs for Gnome Shell specifically on `/var/log`, it does
> not print anything in `/var/log/Xorg.0.log`, and `info guix` does not
> describe any log output directory for `gnome-desktop-configuration`,
> so I don't know where Gnome Shell on Guix puts its logs.  Does it
> just get printed to console?
There's your ~/.local/share/xorg logs that you haven't mentioned yet,
but I doubt something like an extension misbehaving (i.e. not even
raising an error that GNOME Shell detects) would end up there.  I'm not
aware of any other GNOME-specific logs and their locations, but since
it's either /var/log or somewhere in your $HOME/.something, I don't
think Guix would do anything to manipulate the output path.  You could
try checking for logs in GDM's home as well, which requires sudo to ls.

Cheers

bug#53379: Emacs cursor theme is not inherited from the OS when using foreign Guix

[Liliana Marie Prikler]

Am Donnerstag, dem 20.01.2022 um 09:03 + schrieb John Hamelink:
> Hi Liliana,
> 
> Liliana Marie Prikler  writes:
> 
> > It turns out this issue is actually related to another issue of
> > Guix' Emacs on foreign distros, which is it not finding timezones. 
> > Since I've found a permanent solution to both, I will close that
> > bug and pat myself on the back for doing so.
> 
> Allow me to join in! That worked perfectly for me. Thank you :)
Good to hear.  Note that you can also write to bug-d...@debbugs.gnu.org
yourself, you don't need my permission to do so ;)  Anyway, done.

In order to avoid future instances of this issue, we should probably
drop a paragraph or two about it in the manual or (more likely) the
cookbook.  I'll get to that when I do.

Cheers

bug#53379: Emacs cursor theme is not inherited from the OS when using foreign Guix

[Liliana Marie Prikler]

Hi

Am Donnerstag, dem 20.01.2022 um 00:03 + schrieb John Hamelink:
> Hi there,
> 
> I'm experiencing an issue with the emacs-next package on my Guix
> foreign setup where the cursor (*not* Emacs point) is very dark. It's
> perfectly legible against the default Emacs theme, but nonetheless it
> is not respecting the settings of the rest of my system. To make
> things worse, I'm currently using (and enjoying!) the modus-vivendi
> theme.
> 
> My host machine is running Arch GNU/Linux with a tiling window
> manager. I set my cursor style using xsetroot like so:
> 
> xsetroot -xcf /usr/share/icons/Adwaita/cursors/left_ptr 16
Corrected your xsetroot invocation there :P

> I tried installing the adwaita-icon-theme, gnome-themes-standard, and
> gnome-themes-extra packages in an attempt at installing the correct
> theme, but that didn't help.
> 
> I'm not entirely sure what the issue is, but after speaking with some
> folks at #guix, it was suggested to me that this may in fact be a
> bug. The other option discussed is that Guix needs its own cursor
> settings, but I'm too early on in my journey with Guix (maybe 2 hours
> of experience using the Guix binary) to know how set that up - if that
> is indeed the case, some pointers on what to read would be very
> warmly received!
It turns out this issue is actually related to another issue of Guix'
Emacs on foreign distros, which is it not finding timezones.  Since
I've found a permanent solution to both, I will close that bug and pat
myself on the back for doing so.

The main issue here is that foreign distros with systemd really cut
down on their use of environment variables, whereas Guix (System) makes
prominent use of them.  In the case of the other bug, TZDIR was unset,
in the case of yours it was XCURSOR_PATH.

Writing an override configuration file with the following contents

--8<---cut here---start->8---
# ~/.config/systemd/user/gnome-shell-x11.service.d/override.conf
[Service]
Environment=TZDIR='/usr/share/zoneinfo'
Environment=XCURSOR_PATH='/usr/share/icons'
--8<---cut here---end--->8---

fixed this for me, although I should specify that I previously only had
TZDIR set and bound XCURSOR_PATH interactively in the shell (I am
typing this just as I found the fix and haven't yet had the opportunity
to restart my X session).

Now one thing I don't quite get is the interaction with GNOME Shell. 
With my current setup as detailed above, Emacs inherits whichever
cursor was set in GNOME at the time of launch for the entire process
duration -- i.e. even if the corresponding GNOME setting changes.  
I'm pretty sure in your setup with xsetroot there's nothing else
setting the cursor, so it ought to be displayed correctly after that. 
If not, you might have to play around with cursor themes in other ways
(refer to [1]).

Cheers


[1] https://wiki.archlinux.org/title/Cursor_themes

bug#48300: closed (Re: Emacs cursor theme is not inherited from the OS when using foreign Guix)

[Liliana Marie Prikler]

Am Donnerstag, dem 20.01.2022 um 08:27 -0300 schrieb Jorge P.de Morais
Neto:
> Hello.  So the solution to the bug is for the user to manually write
> the file ~/.config/systemd/user/gnome-shell-
> x11.service.d/override.conf ?
> 
> I would like to know a little more about that.  What is the advantage
> of specifying the environment variables on that file instead of
> ~/.profile?
> 
> Kind regards,
>   Jorge
In my personal experience, the value did not get sourced correctly when
I put it into .bash_profile.  I do not know about .profile, but I guess
you'll run into similar issues.  In either case, evaluation order is
something you might want to consider.

Now the advantage of doing this at all is that you get finer control
over which environment variables are set when.  It doesn't really make
sense to e.g. set the font path when you're in a terminal.  The
disadvantage is that it's obscure and brittle -- the value TZDIR will
only be correctly set inside GNOME in this example, for other desktop
environments you'd have to copy the definitions.  What if you're
launching just a terminal session?  Don't ask me.

I'm pretty sure there's some systemd file where you can put these
instead, but in the years of using it up to encountering Guix I've
never needed such a thing and now that I do use Guix, I'm quite content
with Shepherd as my PID 1.  I still remember some of systemd's major
features that I miss from shepherd, like socket activation or the
ability to control GNOME Shell at all, but ask me about some incredibly
mundane task like setting a timer and I'll have to consult a manual on
that.

Cheers

bug#53514: Guix should not set global variables that may affect host

[Liliana Marie Prikler]

Hi,

Am Montag, dem 24.01.2022 um 17:24 -0500 schrieb Maxim Cournoyer:
> Hello!
> 
> There are multiple reports about the negative effects of Guix setting
> variables such as XDG_DATA_DIRS on foreign distributions, that may
> cause problems a severe as locking users out of their graphical
> session [0].
> 
> In my opinion, we should pursue patching every application/library to
> use a Guix-specific variant, e.g. GUIX_XDG_DATA_DIRS instead of
> XDG_DATA_DIRS, to avoid interfering with the host system, as was done
> for GUIX_PYTHONPATH.
> 
> This is a big task in itself; we can open more focused/actionable
> tasks for each environment variable, starting with those causing the
> most serious issues.
> 
> Any takers?
I'm not convinced that patching XDG_DATA_DIRS is a good solution here.
Even if we go forward and implement this for each and every
library/application, (it would be reasonably simple to do so for glib
and qt at least, but there's many more consumers, including Guix
itself), we'd just force users on foreign distros to set up their
XDG_DATA_DIRS for us if they e.g. want to have desktop icons available,
so they'd quickly encounter the same issue on their own.

I see two ways forward for this:  First, "ignore it" and just document
the behaviour.  This isn't just a bug Guix is suffering from, it also
affects other third-party package installers like Flatpak and Snap. 
Since distros increasingly become aware of them, this will soon no
longer be an issue for most our users.  Second, extend search-paths
with a way of enforcing a default value when none is set.  This way,
Guix will still override XDG_DATA_DIRS, but since
$HOME/.local/share:/usr/share is set as the default as per spec, it
will do what the distro expected.

WDYT?

bug#53559: Mutter test-suite is flaky

[Liliana Marie Prikler]

Hi Guix,

ever since the merge of core-updates-frozen, I've been unable to build
mutter locally, while fetching it from CI is usually fine.  Attached is
a build log -- note, that the traceback is generated by me killing the
process with a SIGSEGV, it would otherwise go on for several days.

Cheers


nx8rx7gy5xbra7060arkwmwks5lpw3-mutter-41.0.drv.bz2
Description: application/bzip

bug#53197: [PATCH 0/3] Update WPEWebkit to 2.34.3

[Liliana Marie Prikler]

Hi,

Am Sonntag, dem 16.01.2022 um 13:30 -0500 schrieb Leo Famulari:
> I noticed that GTK 4 depends on wpebackend-fdo. For now, we can
> change GTK 4 on the master branch, but eventually wpebackend-fdo will
> be a package that requires grafting to keep up to date.
I'm fine with turning the wpebackend-fdo patch into a graft, I just
didn't notice the dependency.

> With these patches applied, Epiphany still works in the same way as
> before.
Great, so we got WebkitGTK working, meaning we only need to disable
SSE2 outside of x86-64.  I checked the file mentioned in webkitgtk's
disable-sse2 phase, and it seems wpewebkit mirrors that.  So if I read
this correctly you only need to copypasta your old code.

Anything else I'm missing?

bug#54893: guix-daemon, locale, LANG, and unicode in git tag names

[Liliana Marie Prikler]

Am Mittwoch, dem 13.04.2022 um 10:22 +0200 schrieb Maxime Devos:
> [...]
> Let's test this (in a new REPL with an UTF-8 locale):
> 
> ((@ (ice-9 iconv) string->bytevector) "é" "ANSI_X3.4-1968")
> ice-9/boot-9.scm:1669:16: In procedure raise-exception:
> Throw to key `encoding-error' with args `("put-char" "conversion to
> port encoding failed" 84 # #\é)'.
> 
> ((@ (ice-9 iconv) string->bytevector) "é" "ANSI_X3.4-1968" 'substitute)
> $2 = #vu8(63)
> ((@ (rnrs bytevectors) utf8->string) #vu8(63))
> $3 = "?"
> 
> and the other direction:
> 
> ((@ (ice-9 iconv) bytevector->string) #vu8(128) "ANSI_X3.4-1968"
> 'substitute)
> $5 = "�" ;; why #\� and not #\?? I don't know, I guess Guile is
> inconsistent
You are first encoding a non-ASCII byte to ASCII, which has no glyph
for "I have no idea what this is", so a question mark (#\?) is used. 
When converting from invalid ASCII to UTF-8 on the other hand, you do
have #\� as the WTF character, so that is used instead.  This is
entirely consistent :)

Cheers

bug#54607: ncurses attrset colour pair ignored in favour of bkgd

[Liliana Marie Prikler]

Am Donnerstag, dem 07.04.2022 um 15:50 +0300 schrieb Roman Riabenko:
> I believe that the above is enough to close this issue.
Consider it closed.

bug#54928: Libtool 2.4.6 vs. 2.4.7

[Liliana Marie Prikler]

Am Donnerstag, dem 14.04.2022 um 14:07 +0200 schrieb Andreas Enge:
> > > I have installed libtool@2.4.7 into my profile
> > That is a mistake.
> > 
> > > as well as a number of other development tools
> > Probably also a mistake.
> 
> Could you elaborate why? If you work on a project, it seems necessary
> to install development tools (gcc-toolchain, autoconf, automake,
> make, texinfo, ...).
True, but to keep adverse effects resulting from environment mixing to
a minimum, you would typically only use those inside ‘guix environment’
(now ‘guix shell’) and refrain from global installation.  See also a
number of talks suggesting you put a ‘guix.scm’ file into the project
root directory for this very purpose.

> > I think the problem is caused in the ../libtool symlink, which is
> > probably not updated to reflect your installation.  This is a known
> > issue with stale build files, which also happens if you garbage-
> > collect stuff.  distclean or maintainerclean should solve your
> > issue.  Or you might just as well delete the symlink manually :)
> 
> I had already removed it, and the problem persisted. I suppose that
> autoreconf or configure created it again in version 2.4.6, and during
> make my version 2.4.7 was used instead.
I'm not sitting in front of your computer, so I can hardly estimate
what has already been expanded where.  However, the typical flow should
go like this: 
1. autoreconf pulls missing files from your libtool into the auxiliary
directory (typically build-aux).
2. configure detects your libtool and configures it according to the
configuration options you pass.
3. make invokes libtool -- if make detects the Makefile itself to be
old, it might restart from 2.
In any case, the error points towards autoreconf not using 2.4.6, but
2.4.7 as base, i.e. an error in step (1).  Maybe you forgot to run it?
Also, never run autoreconf without -v, it stands for "very important".

As a general rule, the GNU build system does not provide a tooclean
target for make.

Cheers

bug#54928: Libtool 2.4.6 vs. 2.4.7

[Liliana Marie Prikler]

Am Donnerstag, dem 14.04.2022 um 11:53 +0200 schrieb Andreas Enge:
> Hello,
> 
> is there a good reason to have added libtool-2.4.7 without it
> replacing the libtool variable (at version 2.4.6)? 
libtool causes at least 13802 (mere two thirds of all our packages), so
one might want to ensure that there are no gratuitous bumps when making
new versions of it available :)

> I have installed libtool@2.4.7 into my profile
That is a mistake.

> as well as a number of other development tools
Probably also a mistake.

> [A]pparently both libtool versions are now used
> and are colliding when
> doing
>    autoreconf -vf && ./configure && make
> in my project:
> 
> make[2]: Verzeichnis „/home/enge/Programme/paritwine/git/src“ wird
> betreten
> /bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -
> I. -g -O2 -MT conversions.lo -MD -MP -MF .deps/conversions.Tpo -c
> -o conversions.lo conversions.c
> libtool: Version mismatch error.  This is libtool 2.4.6, but the
> libtool: definition of this LT_INIT comes from libtool 2.4.7.
> libtool: You should recreate aclocal.m4 with macros from libtool
> 2.4.6
> libtool: and run autoconf again.
> 
> I can solve the problem by downgrading to libtool@2.4.6 in my
> profile, but would argue that this defeats the purpose of adding the
> new variable at all.
I think the problem is caused in the ../libtool symlink, which is
probably not updated to reflect your installation.  This is a known
issue with stale build files, which also happens if you garbage-collect
stuff.  distclean or maintainerclean should solve your issue.  Or you
might just as well delete the symlink manually :)

Cheers

bug#65306: [shepherd] ntpd throws shepherd out of the loop

[Liliana Marie Prikler]

Am Samstag, dem 02.09.2023 um 22:44 +0200 schrieb Ludovic Courtès:
> Hi,
> 
> Timotej Lazar  skribis:
> 
> > Liliana Marie Prikler  [2023-08-15
> > 07:18:02+0200]:
> > > As of recently (maybe it dates back longer, but I first
> > > experienced it two weeks ago and just now got to debugging it a
> > > little), Shepherd gets stuck at 100% CPU usage "early" on first
> > > boot.
> > 
> > I have this issue on all Guix systems without a (working) RTC. It
> > seems to be caused by a recentish update to guile-fibers:
> > 
> > https://github.com/wingo/fibers/issues/89
> 
> Yeah, that’s the one.
> 
> Liliana, Timotej: could you try the Guix patch I posted at
> <https://issues.guix.gnu.org/64966>?
Do we have a guide on how to swap out shepherd from the config.scm? 
The machine that experiences this fault isn't set up for Guix hacking.

Cheers

bug#65575: [PATCH v3 4/4] gnu: emacs: Reload subdirs.el files in 'guix-emacs-autoload-packages'.

[Liliana Marie Prikler]

Am Sonntag, dem 03.09.2023 um 10:51 -0400 schrieb Maxim Cournoyer:
> Hi Liliana,
> 
> Liliana Marie Prikler  writes:
> 
> [...]
> 
> > Thanks, LGTM.  I've tested this by dropping almost all parts of
> > load-path and calling (guix-emacs-autoload-packages), it appears to
> > do what's promised.  Queued locally for emacs-next and followed up
s/emacs-next/emacs-team/

Sorry for the confusion.
> > with a patch that fixes the compilation warnings coming from the
> > docstrings.
> 
> Sounds good, thank you for testing it!
> 
> About warnings, when I byte compile guix-emacs.el, all I see is:
> 
> --8<---cut here---start->8---
> 
> Compiling file /home/maxim/src/guix/gnu/packages/aux-
> files/emacs/guix-emacs.el at Sun Sep  3 10:50:19 2023
> guix-emacs.el:83:39: Warning: reference to free variable
>     ‘treesit-extra-load-path’
> guix-emacs.el:83:39: Warning: assignment to free variable
>     ‘treesit-extra-load-path’
> --8<---cut here---end--->8---
> 
> I don't know how to fix those; they seem harmless since their use is
> enclosed in a (with-eval-after-load 'treesit ...) expression.
Yeah, I'm on Emacs 29 with tree-sitter baked in, so I see another set
of warnings (emacs-team vs master strikes again, it seems)

Cheers

bug#66015: [PATCH] gnu: python-pyxel: Update to 1.4.3-2.be75b72.

[Liliana Marie Prikler]

* gnu/packages/game-development.scm (python-pyxel): Update to 1.4.3-2.be75b72.
[version]: Use git-version even though it is a release.
[source]: Use commit.
: Adjust accordingly.
---
Hi Simon

Am Freitag, dem 15.09.2023 um 21:09 +0200 schrieb Simon Tournier:
> Upstream is managing using the worse workflow I have seen.
> 
> Here is the history of tag v1.4.3 replacement:
> 
>   v1.4.3 8bcb6f04eb184876d7807b89b34057ca0897b392  07 August 2021
>   v1.4.3 8bcb6f04eb184876d7807b89b34057ca0897b392  09 December 2021
>   v1.4.3 7d27898e218d6b4cb62779dc22b409d02860f155  27 December 2021
>   v1.4.3 be75b724cae9e10e56a82a5421f9dd65390f1a06  22 September 2022
>   v1.4.3 be75b724cae9e10e56a82a5421f9dd65390f1a06  today
>   
> And surprise surprise:
> 
> --8<---cut here---start->8---
> $ git clone https://github.com/kitao/pyxel
> 
> $ git -C pyxel show 8bcb6f04eb184876d7807b89b34057ca0897b392
> fatal: bad object 8bcb6f04eb184876d7807b89b34057ca0897b392
> 
> $ git -C pyxel show 7d27898e218d6b4cb62779dc22b409d02860f155
> fatal: bad object 7d27898e218d6b4cb62779dc22b409d02860f155
Ouch.

> I am proposing to remove the package python-pyxel.  The rationale is:
> 
>  + Broken [1] since months
>  + Update needs “some” work
>  + Two years without an update
>  + An issue about upstream source
> 
> Therefore, if someone is interested, please update it.  Else I will
> remove it.
Well, I did “some” work, but I only got to update it to the new 1.4.3.
Refering to things by commit ought to be fine since we have SWH as an
additional buffer.  As for newer versions, that requires an ugly hack
to get Rust and Python into a single build system and the last time
I tried to do something non-standard with Cargo has left deep emotional
scars.

Cheers

 gnu/packages/game-development.scm | 96 +--
 1 file changed, 52 insertions(+), 44 deletions(-)

diff --git a/gnu/packages/game-development.scm 
b/gnu/packages/game-development.scm
index c25dadb39e..215c12e2d9 100644
--- a/gnu/packages/game-development.scm
+++ b/gnu/packages/game-development.scm
@@ -1646,53 +1646,61 @@ (define-public renpy
 (license license:expat)))
 
 (define-public python-pyxel
-  (package
-(name "python-pyxel")
-(version "1.4.3")
-(source
- (origin
-   (method git-fetch)
-   (uri
-(git-reference
- (url "https://github.com/kitao/pyxel;)
- (commit (string-append "v" version
-   (file-name (git-file-name name version))
-   (sha256
-(base32
- "0bwsgb5yq5s479cnf046v379zsn5ybp5195kbfvzr9l11qbaicm9"))
-   (modules '((guix build utils)))
-   (snippet
-'(begin
-   (delete-file-recursively "pyxel/core/bin")
-(build-system python-build-system)
-(arguments
- `(#:tests? #f ; "Tests" are actually example programs that never halt.
-   #:phases
-   (modify-phases %standard-phases
- (add-after 'unpack 'patch-build-files
-   (lambda* (#:key inputs #:allow-other-keys)
- (substitute* "setup.py"
-   (("\"pyxel\\.core\\.bin\\.(.*)\"," all arch)
-(if (string=? arch "linux")
-all
-"")))
- (substitute* "pyxel/core/Makefile"
-   (("`sdl2-config")
-(string-append "`sdl2-config --prefix="
-   (assoc-ref inputs "sdl2"))
- (add-before 'build 'prebuild
-   (lambda _
- (invoke "make" "-C" "pyxel/core"))
-(inputs
- `(("gifsicle" ,gifsicle)
-   ("sdl2" ,(sdl-union (list sdl2 sdl2-image)
-(home-page "https://github.com/kitao/pyxel;)
-(synopsis "Retro game engine for Python")
-(description "Pyxel is a game engine inspired by retro gaming consoles.
+  ;; Note to updaters: Use commit and revision even if you're bumping
+  ;; to a release, as upstream is known to "reuse" tags.
+  ;; See  for more information.
+  (let ((commit "be75b724cae9e10e56a82a5421f9dd65390f1a06")
+(revision "2"))
+(package
+  (name "python-pyxel")
+  ;; This is the latest version to not require Rust…
+  (version (git-version "1.4.3" revision commit))
+  (source
+   (origin
+ (method git-fetch)
+ (uri
+  (git-reference
+   (url "https://github.com/kitao/pyxel;)
+   (commit commit)))
+ (file-name (git-file-name name version))
+ (sha256
+  (base32
+   "03ch79cmh9fxvq6c2f3zc2snzczhqi2n01f254lsigckc7d5wz08"))
+ (modules '((guix build utils)))
+ (snippet
+  #~(begin
+  (substitute* "pyxel/__init__.py"
+(("from collections import MutableSequence")
+ "from collections.abc import MutableSequence"))
+  (build-system python-build-system)
+  (arguments
+   `(#:tests? #f ; "Tests" are actually example programs that never 

bug#63687: [bug#66031] [PATCH] gnu: Patch gnome-dictionary meson configs, fixes 63687.

[Liliana Marie Prikler]

Am Samstag, dem 16.09.2023 um 14:03 +0200 schrieb raingloom:
> * gnu/packages/gnome.scm (gnome-dictionary): Apply patch.
> * gnu/packages/patches/gnome-dictionary-meson-i18n.patch: New file.
> * gnu/local.mk: Add it.
> ---
Reworded slightly and applied.

Thanks

PS: Don't worry about the semantics of the Fixes: line that I added; we
aren't parsing them yet.

bug#66015: [PATCH] gnu: python-pyxel: Update to 1.4.3-2.be75b72.

[Liliana Marie Prikler]

Am Samstag, dem 16.09.2023 um 10:46 +0200 schrieb Simon Tournier:
> Hi Liliana,
> 
> Oh, cool!  That was fast. :-)  Thank you.
> 
> On Fri, 15 Sep 2023 at 21:53, Liliana Marie Prikler
>  wrote:
> > * gnu/packages/game-development.scm (python-pyxel): Update to
> > 1.4.3-2.be75b72.
> > [version]: Use git-version even though it is a release.
> > [source]: Use commit.
> > : Adjust accordingly.
> 
> I have not tried the patch but LGTM.  If it builds fine for you, feel
> free to push… and close. :-)
I only rarely submit patches that don't at least build for myself.
Pushed and done.

> > Refering to things by commit ought to be fine since we have SWH as
> > an additional buffer.
> 
> If upstream removes Git commit
> be75b724cae9e10e56a82a5421f9dd65390f1a06
> then it is an interesting use-case for testing Guix robustness when
> fallbacking to SWH. :-)
> 
> I expect that it just works™ but I am not aware of any real world
> test about this very same use-case.  Wait and see.
Yeah, I doubt that they'll reuse it this late in the game, but you're
right that we're basically walking on dreams rn.

Cheers

bug#65575: [PATCH v2 4/4] gnu: emacs: Reload subdirs.el files in 'guix-emacs-autoload-packages'.

[Liliana Marie Prikler]

Am Montag, dem 28.08.2023 um 11:16 -0400 schrieb Maxim Cournoyer:
> This fixes a regression introduced with 79cfe30f3 ("build-system:
> emacs: Use subdirectories again.") which caused the
> 'guix-emacs-autoload-packages' to no longer be able to autoload all
> packages.
> 
> * gnu/packages/aux-files/emacs/guix-emacs.el
> (guix-emacs-autoload-packages-called): New variable.
> (guix-emacs-autoload-packages): Reload subdirs.el files on all but
> the first call of this procedure, or when a prefix argument is
> provided.
What's the reason to still keep the variable?   Even if we call load-
file with 'noerror, the way in which it is set is quite weird and imho,
it would keep things simpler if we had the clear semantics of
  universal-argument → reload
  no universal-argument → no reload
or the other way round.

bug#65575: [PATCH v3 4/4] gnu: emacs: Reload subdirs.el files in 'guix-emacs-autoload-packages'.

[Liliana Marie Prikler]

Am Freitag, dem 01.09.2023 um 00:53 -0400 schrieb Maxim Cournoyer:
> This fixes a regression introduced with 79cfe30f3 ("build-system:
> emacs: Use subdirectories again.") which caused the
> 'guix-emacs-autoload-packages' to no longer be able to autoload all
> packages.
> 
> * gnu/packages/aux-files/emacs/guix-emacs.el
> (guix-emacs-autoload-packages): Reload subdirs.el files unless NO-
> RELOAD is provided.  Update doc.
> * doc/guix.texi (Application Setup): Document that
> 'guix-emacs-autoload-packages' can be invoked interactively to auto-
> reload newly installed Emacs packages.
> * gnu/packages/emacs.scm (emacs) [arguments] : Call
> guix-emacs-autoload-packages with an argument in the site-start.el
> file.
> 
> ---
> 
> Changes in v3:
> - Invert argument logic of guix-emacs-autoload-packages
> - Drop the guix-emacs-autoload-packages-called state variable
> - Adjust site-start.el file in Emacs package
> 
> Changes in v2:
> - Safely load subdirs.el files
> - Add 'reload' prefix argument as override for guix-emacs-autoload-
> packages
> 
>  doc/guix.texi  | 11 +++
>  gnu/packages/aux-files/emacs/guix-emacs.el | 15 ---
>  gnu/packages/emacs.scm |  2 +-
>  3 files changed, 20 insertions(+), 8 deletions(-)
Thanks, LGTM.  I've tested this by dropping almost all parts of load-
path and calling (guix-emacs-autoload-packages), it appears to do
what's promised.  Queued locally for emacs-next and followed up with a
patch that fixes the compilation warnings coming from the docstrings.

Cheers

bug#62784: drascula, lure, lure-de, lure-es, lure-fr, lure-it, sky: non-commercial license

[Liliana Marie Prikler]

Am Mittwoch, dem 12.04.2023 um 11:35 +0200 schrieb Liliana Marie
Prikler:
> Hi Denis,
> 
> [...] We have been aware of this for about half a year now (see the
> thread in guix-devel following [1]), but as other FSDG-abiding
> distributions still include these games (or at least did back then)
> we postponed their removal.

We now ship none of these games as well as a fully bootstrapped
scummvm-based game.  This ought to make everyone happy.

Cheers

bug#65575: [PATCH v3 4/4] gnu: emacs: Reload subdirs.el files in 'guix-emacs-autoload-packages'.

[Liliana Marie Prikler]

Am Sonntag, dem 03.09.2023 um 21:59 +0200 schrieb Liliana Marie
Prikler:
> Am Sonntag, dem 03.09.2023 um 10:51 -0400 schrieb Maxim Cournoyer:
> > Hi Liliana,
> > 
> > Liliana Marie Prikler  writes:
> > 
> > [...]
> > 
> > > Queued locally for emacs-next and followed up
> s/emacs-next/emacs-team/
s/Queued locally/Pushed/

Cheers

bug#65846: Request to merge emacs-team branch

[Liliana Marie Prikler]

Hi Guix,

what's been promised some while ago in another thread is finally close™
to becoming reality: Emacs 29 on Guix with tree-sitter and all that
stuff.  I expect to merge the branch onto master within next week or
the week after that.  In the meantime, please use this thread to mark
bugs and patches that you would like to see applied before that.

Cheers

bug#65575: [PATCH 3/3] gnu: emacs: Reload subdirs.el files in 'guix-emacs-autoload-packages'.

[Liliana Marie Prikler]

Am Montag, dem 28.08.2023 um 11:20 -0400 schrieb Maxim Cournoyer:
> > e.g. 
> > (defun guix-emacs-autoload-packages ( reload)
> >   "..."
> >   (interactive "P")
> >   (when reload (mapc #'load-file (guix-emacs--subdirs-files)))
> >   ...)
> > 
> > WDYT?
> 
> The reason for avoiding loading the subdirs.el files on the first
> call is just an optimization, since it would at this time duplicate
> work already done by Emacs itself when it first executes.  This
> shouldn't fail; I've now employed the same 'noerror strategy as used
> for autoloads to ensure that.
> 
> There's one edge case I've just thought though, which is if a user
> invoked emacs with the documented '--no-site-file' option disabling
> loading autoloads; this would cause guix-emacs-autoload-packages-
> called to be nil.
> 
> To balance between making things both convenient and flexible, I've
> preserved the tracking but also added the reload override you
> suggested.  Let me know what you think.
Assuming convenience equates to not needing to type C-u, we can also
achieve that without tracking:

(defun guix-emacs-autoload-packages ( noexpand)
  "Autoload Emacs packages found in EMACSLOADPATH.

'Autoload' means to load the 'autoloads' files matching 
`guix-emacs-autoloads-regexp'.  Before doing so, expand load-path by
loading subdirs.el files found in it, unless NOEXPAND is given."
  (interactive "P")
  (unless noexpand (mapc #'load-file (guix-emacs--subdirs-files)))
  ...)

In our own init code, we should simply call it as 
  (guix-emacs-autoload-packages 'noexpand)
then, since this expansion is already done earlier by Emacs.

Cheers

bug#66864: emacs-build-system builds .eln-files with mismatching path-hashes

[Liliana Marie Prikler]

Am Dienstag, dem 31.10.2023 um 23:49 + schrieb Mekeor Melire:
> BUG EXPLANATION
> 
> Emacs's natively-compiled .eln-files have a basename following the
> pattern "{feature-name}-{path-hash}-{content-hash}.eln". [0]
> 
> Guix' emacs-build-system is used to build Emacs-related packages. By 
>  default, it uses the "emacs-minimal" package during build, which 
>  does not support native-compilation. But if you replace the 
>  "emacs-minimal" input with "emacs-no-x", e.g. by using 
>  --with-input=emacs-minimal=emacs-no-x, then emacs-build-system 
>  will make use of emacs-no-x' support of native-compilation [1]: 
>  The build will contain .eln-files.
> 
> Hereby I'd like to report the bug that consists of mismatched path-
> hashes in the .eln-files that builds of Emacs-related packages
> contain when build with emacs-no-x (or any other Emacs that supports
> native compilation).
> 
> BUG REPRODUCTION
> 
> To reproduce this bug follow the following steps. Please note that
> guix-shell seems to leak .eln-files. (This should be reported as 
> another bug.)
What do you mean by "leaks .eln-files"?

> That why the reproduction steps avoid guix-shell.  Instead, we'll
> work with the current user profile.
> 
> Delete Emacs' eln-cache (so that we can later see if new 
> .eln-files have been generated):
> 
> rm -rf ~/.emacs.d/eln-cache
> 
> Remove all Emacs- and Emacs-related packages from Guix profile:
> 
> guix package -I | cut -f 4 | grep emacs | xargs guix remove
> 
> Install Emacs and emacs-unfill, as exemplary package, while 
> replacing input "emacs-minimal" with "emacs", so that .eln-files 
> are generated during the build:
> 
> guix install emacs emacs-unfill 
> --with-input=emacs-minimal=emacs
Just deleting the eln-cache should be enough for a MWE.  When doing an
MWE, make sure that its actually minimal :)

> Launch the freshly installed Emacs and load the "unfill" package. 
> If the .eln-files that the emacs-unfill package provides match 
> Emacs' expectations (path- and content-hash), it'll use it; 
> otherwise, Emacs will compile a new .eln-file and save it into 
> ~/.emacs.d/eln-cache/*/unfill-{path-hash}-{content-hash}.eln.
> 
> emacs -q --eval "(require 'unfill)"
> 
> Close Emacs after some seconds. Now determine the path-hash from 
> Guix' build:
> 
> basename 
> ~/.guix-profile/lib/emacs/native-site-lisp/*/unfill-*.eln \
>   | cut -d - -f 2
> 
> Determine the path-hash from Emacs' native-compilation, which 
> apparently has happened:
> 
> basename ~/.emacs.d/eln-cache/*/unfill*.eln \
>   | cut -d - -f 2
This is already the bug.  There should not be a file written to the
eln-cache (save for the trampolines that we still write there, which is
also a known bug among those who care).

> The path-hashes from the last two steps are not equal.
> 
> BUG SOLUTION HINTS
> 
> In the #guix:libera.chat IRC channel, jpoiret pointed out: "the .eln
> file hash problem is due to grafts, grafts change the 
> final output name, but they can't also update the file hashes... 
> we'd need to modify emacs' behavior for this to work".
As jpoiret points out, this has to do with the file naming choices of
Emacs, not with emacs-build-system per se.  We would need to get rid of
a lot of hashes if we wanted interoperable native-compiled Emacs
libraries.  I wonder what upstream has to say about this.

Cheers

bug#66864: emacs-build-system builds .eln-files with mismatching path-hashes

[Liliana Marie Prikler]

Am Mittwoch, dem 01.11.2023 um 13:03 + schrieb Mekeor Melire:
> The problem is that the .el-file-path that is passed to the Emacs
> function comp-el-to-eln-filename during build [1] does not equal to
> the .el-file-path when Emacs is invoked. Personally, I do not 
> understand how grafting causes this. But I can confirm that when 
> --no-grafts is passed to "guix install emacs emacs-unfill 
> --with-input=emacs-minimal=emacs", then no eln-cache is created.
I think Emacs might be calculating its own hash at runtime rather than
baking in the value at build time.  I would need to investigate this,
however.

Cheers

bug#66762: emacs-ess test fails

[Liliana Marie Prikler]

Am Freitag, dem 27.10.2023 um 11:22 +0200 schrieb Simon Tournier:
> Well, I fixed the build of emacs-julia-mode.  See attached.
Pushed attached with slight rewordings.

> But emacs-ess is not passing.  I have updated ESS to the most recent
> revision, added phases for skipping the tests requiring network but
> it still fails:
> 
> [...]
> 
> To be continued…
Leaving this open for whoever wishes to continue.

Cheers

bug#66169: guix reconfigure error no match for id 4f35ff1275e05be31f5d41464ccf147e9dbfd016

[Liliana Marie Prikler]

Am Samstag, dem 23.09.2023 um 22:02 +0300 schrieb Roman Riabenko:
> I am trying to upgrade my guix systems. I ran guix pull and now I am
> trying to run guix system reconfigure. It failed on two different
> machines with the same backtrace. Please see the full backtrace
> attached. The error message from it:
> 
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Git error: object not found - no match for id
> (4f35ff1275e05be31f5d41464ccf147e9dbfd016)
> 
> 
> $ guix describe
> Generation 28   Sep 23 2023 19:30:36(current)
>   guix 4f35ff1
>     repository URL: https://git.savannah.gnu.org/git/guix.git
>     branch: master
>     commit: 4f35ff1275e05be31f5d41464ccf147e9dbfd016
> 
> Considering that I experience it on two guix machines with different
> system configurations, I assume that there is some bug somewhere.
Experiencing the same for commit
35fd25af9bbcce84908101a9f487ba106a8d6df7.  I would hazard a guess that
it's due to them being merge commits.  Interestingly, allow-downgrades
does not have an effect on this message.

Cheers

bug#66169: guix reconfigure error no match for id 4f35ff1275e05be31f5d41464ccf147e9dbfd016

[Liliana Marie Prikler]

Am Sonntag, dem 24.09.2023 um 08:49 + schrieb Guillaume Le
Vaillant:
> Liliana Marie Prikler  skribis:
> 
> > Am Samstag, dem 23.09.2023 um 22:02 +0300 schrieb Roman Riabenko:
> > > I am trying to upgrade my guix systems. I ran guix pull and now I
> > > am
> > > trying to run guix system reconfigure. It failed on two different
> > > machines with the same backtrace. Please see the full backtrace
> > > attached. The error message from it:
> > > 
> > > ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> > > Git error: object not found - no match for id
> > > (4f35ff1275e05be31f5d41464ccf147e9dbfd016)
> > > 
> > > 
> > > $ guix describe
> > > Generation 28   Sep 23 2023 19:30:36(current)
> > >   guix 4f35ff1
> > >     repository URL: https://git.savannah.gnu.org/git/guix.git
> > >     branch: master
> > >     commit: 4f35ff1275e05be31f5d41464ccf147e9dbfd016
> > > 
> > > Considering that I experience it on two guix machines with
> > > different
> > > system configurations, I assume that there is some bug somewhere.
> > Experiencing the same for commit
> > 35fd25af9bbcce84908101a9f487ba106a8d6df7.  I would hazard a guess
> > that it's due to them being merge commits.  Interestingly,
> > allow-downgrades does not have an effect on this message.
> > 
> > Cheers
> 
> I reconfigured two machines using commit
> 4f35ff1275e05be31f5d41464ccf147e9dbfd016, and it succeeded on both
> machines, I didn't get this "no match for id" issue.
> That's strange...
Do you have provenance tracking on your machines (the default)?

bug#66169: guix reconfigure error no match for id 4f35ff1275e05be31f5d41464ccf147e9dbfd016

[Liliana Marie Prikler]

Am Sonntag, dem 24.09.2023 um 10:37 +0200 schrieb Liliana Marie
Prikler:
> Am Samstag, dem 23.09.2023 um 22:02 +0300 schrieb Roman Riabenko:
> > ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> > Git error: object not found - no match for id
> > (4f35ff1275e05be31f5d41464ccf147e9dbfd016)
> Experiencing the same for commit
> 35fd25af9bbcce84908101a9f487ba106a8d6df7.

Am Sonntag, dem 24.09.2023 um 08:49 + schrieb Guillaume Le
Vaillant:
> I reconfigured two machines using commit
> 4f35ff1275e05be31f5d41464ccf147e9dbfd016, and it succeeded on both
> machines[.]

I now have a workaround that looks quite odd.  If you 
  $ sudo rm -rf /root/.cache/guix
guix system will rerun the indexing and thus pick up the new commits. 
I will dub this "advanced cache invalidation" since it appears as
though we are looking up commits in the wrong cache.

Cheers

bug#56376: emacs-guix missing from package-activated-list

[Liliana Marie Prikler]

Am Dienstag, dem 03.10.2023 um 23:12 -0400 schrieb Maxim Cournoyer:
> Hi,
> 
> Liliana Marie Prikler  writes:
> 
> > Am Sonntag, dem 03.07.2022 um 21:33 -0400 schrieb Philip McGrath:
> > > Hi,
> > > 
> > > I've been looking into managing my Emacs packages with Guix. I
> > > found that the `emacs-guix` package doesn't seem to show up in
> > > the `package-activated-list`, even though its dependencies do,
> > > which seems like a bug.
> > This might be related to the fact that Emacs doesn't see guix as a
> > package.  I think the recipe might be missing the -pkg.el
> > autogeneration we added to emacs-build-system.
> 
> We could workaround the problem using the ensure-package-description
> of the emacs-build-system phase, but since the emacs-guix package
> uses the gnu-build-system, we'd also need to manually install the -
> pkg.el file generated by the phase.
> 
> Since we maintain the package in Savannah, it seems it'd be more
> elegant to have an emacs-guix-pkg.el file templated by the GNU build
> system and installed by it.
Indeed, maintaining a proper package description upstream is the
preferable option.

Cheers

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

[Liliana Marie Prikler]

Am Mittwoch, dem 04.10.2023 um 12:47 +0200 schrieb Vivien Kraus:
> * 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
> @@ -187,6 +187,7 @@ (define (dbus-activation config)
>    ;; This directory contains the daemon's socket so it must
> be
>    ;; world-readable.
>    (mkdir-p/perms "/var/run/dbus" user #o755))
> +    (symlink "/var/run/dbus" "/run/dbus")
>From [1]:
> As documented in the NEWS file in
> https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/209, it’s
> only valid to use /run – rather than /var/run – for D-Bus if the two
> paths are interoperable. i.e. /var/run should be a symlink to /run,
> and the D-Bus daemon should be configured to put its socket there.

Thus, the order of the two ought to be reversed.  Alternatively, we
could add '-Druntime_dir=/var/run' to glib.  WDYT?

[1]: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3101

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

[Liliana Marie Prikler]

Am Mittwoch, dem 04.10.2023 um 12:47 +0200 schrieb Vivien Kraus:
> 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.
> 
> * gnu/services/dbus.scm (dbus-activation): Symlink /run/dbus to
> /var/run/dbus.
> (%dbus-accounts): Run dbus in /run/dbus.
> (dbus-root-service-type): Save the pid file in /run/dbus.
> ---
> 
> Le mercredi 04 octobre 2023 à 20:30 +0200, Liliana Marie Prikler a
> écrit :
> > Am Mittwoch, dem 04.10.2023 um 12:47 +0200 schrieb Vivien Kraus:
> > > * 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
> > > @@ -187,6 +187,7 @@ (define (dbus-activation config)
> > >    ;; This directory contains the daemon's socket so it
> > > must
> > > be
> > >    ;; world-readable.
> > >    (mkdir-p/perms "/var/run/dbus" user #o755))
> > > +    (symlink "/var/run/dbus" "/run/dbus")
> > From [1]:
> > > As documented in the NEWS file in
> > > https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/209,
> > > it’s only valid to use /run – rather than /var/run – for D-Bus if
> > > the two paths are interoperable. i.e. /var/run should be a
> > > symlink to /run, and the D-Bus daemon should be configured to put
> > > its socket there.
> > 
> > Thus, the order of the two ought to be reversed.  Alternatively, we
> > could add '-Druntime_dir=/var/run' to glib.  WDYT?
> > 
> > [1]: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3101
> 
> Thank you for finding this information. I think we should follow
> glib, and have the socket in /run/dbus, with the symlink for standard
> interoperability.
> 
> I’m still concerned about doing a symlink in the activation function.
> What if we activate a new system from an existing one? Won’t the
> symlink fail? I think we should preemptively delete /var/run/dbus and
> make a new symlink every time. But I could be wrong, maybe this is
> not needed.
> 
> What do you think?
If we go this route, I think we should first check whether
/var/run/dbus is indeed a symlink to /run/dbus and move the existing
files if not before deleting the directory and creating the symlink. 
But before that, we should try to symlink, which will fail with EEXIST
if the file already exists, regardless of whether it's a symlink –
thereafter you can check the cause of this failure through lstat.

> Best regards,
> 
> Vivien
> 
>  gnu/services/dbus.scm | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/gnu/services/dbus.scm b/gnu/services/dbus.scm
> index 5a0c634393..53efa7adea 100644
> --- a/gnu/services/dbus.scm
> +++ b/gnu/services/dbus.scm
> @@ -163,7 +163,7 @@ (define %dbus-accounts
>   (group "messagebus")
>   (system? #t)
>   (comment "D-Bus system bus user")
> - (home-directory "/var/run/dbus")
> + (home-directory "/run/dbus")
>   (shell (file-append shadow "/sbin/nologin")
>  
>  (define dbus-setuid-programs
> @@ -186,7 +186,11 @@ (define (dbus-activation config)
>  (let ((user (getpwnam "messagebus")))
>    ;; This directory contains the daemon's socket so it must
> be
>    ;; world-readable.
> -  (mkdir-p/perms "/var/run/dbus" user #o755))
> +  (mkdir-p/perms "/run/dbus" user #o755))
> +
> +    (when (file-exists? "/var/run/dbus")
> +  (delete-file "/var/run/dbus"))
This assumes "/var/run/dbus" to be a regular file or symlink, which
it's not on reconfiguration IIUC.
> +    (symlink "/run/dbus" "/var/run/dbus")
>  
>  (unless (file-exists? "/etc/machine-id")
>    (format #t "creating /etc/machine-id...~%")
> @@ -210,7 +214,7 @@ (define dbus-shepherd-service
>   '(#:environment-variables
> '("DBUS_VERBOSE=1")
>     #:log-file "/var/log/dbus-
> daemon.log")
>   '())
> -  #:pid-file "/var/run/dbus/pid"))
> +  #:pid-file "/run/dbus/pid"))
>  (stop #~(make-kill-destructor)))
>  
>  (define dbus-root-service-type
> 
> base-commit: b18b2d13488f2a92331ccad2dc8cbb54ee15582f

Cheers

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

[Liliana Marie Prikler]

Am Mittwoch, dem 04.10.2023 um 12:47 +0200 schrieb Vivien Kraus:
> 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.
> 
> * gnu/services/dbus.scm (dbus-activation): Symlink /run/dbus to
> /var/run/dbus.
> (%dbus-accounts): Run dbus in /run/dbus.
> (dbus-root-service-type): Save the pid file in /run/dbus.
> ---
> 
> Hello,
> 
> I changed my mind back to a previous mind change, so: the socket
> should be
> installed in /run.  I believe that the code moves the content of the
> existing
> /var/run/dbus to /run/dbus before trying the symlink again, if
> /var/run/dbus
> exists and is not a symlink to /run/dbus.  I don’t really have a way
> to check
> the interesting case where existing files need to be moved.  However,
> the
> gnome-team-configured VM works.
> 
> Best regards,
> 
> Vivien
> 
>  gnu/services/dbus.scm | 39 ---
>  1 file changed, 36 insertions(+), 3 deletions(-)
> 
> diff --git a/gnu/services/dbus.scm b/gnu/services/dbus.scm
> index 5a0c634393..aa9ce0720c 100644
> --- a/gnu/services/dbus.scm
> +++ b/gnu/services/dbus.scm
> @@ -163,7 +163,7 @@ (define %dbus-accounts
>   (group "messagebus")
>   (system? #t)
>   (comment "D-Bus system bus user")
> - (home-directory "/var/run/dbus")
> + (home-directory "/run/dbus")
>   (shell (file-append shadow "/sbin/nologin")
>  
>  (define dbus-setuid-programs
> @@ -186,7 +186,40 @@ (define (dbus-activation config)
>  (let ((user (getpwnam "messagebus")))
>    ;; This directory contains the daemon's socket so it must
> be
>    ;; world-readable.
> -  (mkdir-p/perms "/var/run/dbus" user #o755))
> +  (mkdir-p/perms "/run/dbus" user #o755))
> +
> +    (catch 'system-error
> +  (lambda ()
> +    (symlink "/run/dbus" "/var/run/dbus"))
> +  (lambda args
> +    (let ((errno (system-error-errno args)))
> +  (cond
> +   ((= errno EEXIST)
> +    (let ((existing-name
> +   (false-if-exception
> +    (readlink "/var/run/dbus"
> +  (unless (equal? existing-name "/run/dbus")
> +    ;; Move the content of /var/run/dbus to
> /run/dbus, and
> +    ;; retry.
> +    (let ((dir (opendir "/var/run/dbus")))
> +  (let move-to-/run/dbus ((next (readdir dir)))
> +    (cond
> + ((eof-object? next)
> +  (closedir dir))
> + ((member next '("." ".."))
> +  (move-to-/run/dbus (readdir dir)))
> + (else
> +  (begin
> +    (rename-file (string-append
> "/var/run/dbus/" next)
> + (string-append "/run/dbus/"
> next))
> +    (move-to-/run/dbus (readdir dir
I'd rename "move-to-/run/dbus" to the boring but more idiomatic "loop".
This saves us some horizontal real-estate that'd allow us to squash
some lines.
> +  (rmdir "/var/run/dbus")
> +  (symlink "/run/dbus" "/var/run/dbus")))
> +   (else
> +    (format (current-error-port)
> +    "Failed to symlink /run/dbus to
> /var/run/dbus: ~s~%"
> +    (strerror errno))
> +    (error "cannot create /var/run/dbus"))
>  
>  (unless (file-exists? "/etc/machine-id")
>    (format #t "creating /etc/machine-id...~%")
> @@ -210,7 +243,7 @@ (define dbus-shepherd-service
>   '(#:environment-variables
> '("DBUS_VERBOSE=1")
>     #:log-file "/var/log/dbus-
> daemon.log")
>   '())
> -  #:pid-file "/var/run/dbus/pid"))
> +  #:pid-file "/run/dbus/pid"))
>  (stop #~(make-kill-destructor)))
>  
>  (define dbus-root-service-type
> 
> base-commit: b18b2d13488f2a92331ccad2dc8cbb54ee15582f
Otherwise LGTM.  I'd commit it, but my machine is currently busy
building half of core-updates for no reason.

Cheers

bug#66227: [PATCH v3] gnu: emacs-next-minimal: Apply Guix patches.

[Liliana Marie Prikler]

* gnu/packages/patches/emacs-next-native-comp-driver-options.patch: Add file.
* gnu/packages/patches/emacs-next-exec-path.patch: Add file.
* gnu/local.mk (dist_patch_DATA): Register them here.
* gnu/packages/emacs.scm (emacs-next-minimal)[origin](patches): Include the
same patches as emacs-minimal, save for the variants specific to emacs-next
introduced above.

Co-Authored-By: Nicolas Graves 
Fixes: ‘emacs-next’ is almost unusable 
---
Hi Guix,

this bug was independently discovered in two locations, so I wanted to
inform both.  A fix has already been proposed, but is not yet complete.
Here's to finally cover everything we need to have an Emacs as expected
by Guix.

Feel free to bikeshed.

Happy hacking

 gnu/local.mk   |  2 ++
 gnu/packages/emacs.scm |  7 ++-
 .../patches/emacs-next-exec-path.patch | 18 ++
 ...emacs-next-native-comp-driver-options.patch | 18 ++
 4 files changed, 44 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/patches/emacs-next-exec-path.patch
 create mode 100644 
gnu/packages/patches/emacs-next-native-comp-driver-options.patch

diff --git a/gnu/local.mk b/gnu/local.mk
index 65d50abc71..43a528e937 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1110,6 +1110,8 @@ dist_patch_DATA = 
\
   %D%/packages/patches/emacs-highlight-stages-add-gexp.patch   \
   %D%/packages/patches/emacs-lispy-fix-thread-last-test.patch   \
   %D%/packages/patches/emacs-native-comp-driver-options.patch   \
+  %D%/packages/patches/emacs-next-exec-path.patch   \
+  %D%/packages/patches/emacs-next-native-comp-driver-options.patch   \
   %D%/packages/patches/emacs-pasp-mode-quote-file-names.patch  \
   %D%/packages/patches/emacs-polymode-fix-lexical-variable-error.patch  \
   %D%/packages/patches/emacs-telega-path-placeholder.patch \
diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index 72b2c7795e..b9d9e2b891 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -498,7 +498,12 @@ (define-public emacs-next-minimal
  (commit commit)))
(file-name (git-file-name name version))
(sha256
-(base32 "00mwpq1msr3jij281w5piqmbwq968xr8dn9hqbf4r947ck754kn9")))
+(base32 "00mwpq1msr3jij281w5piqmbwq968xr8dn9hqbf4r947ck754kn9"))
+   (patches
+(search-patches "emacs-next-exec-path.patch"
+"emacs-fix-scheme-indent-function.patch"
+"emacs-next-native-comp-driver-options.patch"
+"emacs-pgtk-super-key-fix.patch")))
 
 (define* (emacs->emacs-next emacs #:optional name
 #:key (version (package-version 
emacs-next-minimal))
diff --git a/gnu/packages/patches/emacs-next-exec-path.patch 
b/gnu/packages/patches/emacs-next-exec-path.patch
new file mode 100644
index 00..6e33e25258
--- /dev/null
+++ b/gnu/packages/patches/emacs-next-exec-path.patch
@@ -0,0 +1,18 @@
+Do not capture the build-time value of $PATH in the 'emacs' executable
+since this can noticeably increase the size of the closure of Emacs
+with things like GCC being referenced.
+
+Index: emacs-next/lisp/loadup.el
+===
+--- emacs-next.orig/lisp/loadup.el
 emacs-next/lisp/loadup.el
+@@ -599,7 +599,8 @@ lost after dumping")))
+   ((equal dump-mode "dump") "emacs")
+   ((equal dump-mode "bootstrap") "emacs")
+   ((equal dump-mode "pbootstrap") 
"bootstrap-emacs.pdmp")
+-  (t (error "Unrecognized dump mode %s" dump-mode)
++  (t (error "Unrecognized dump mode %s" dump-mode
++(exec-path nil))
+ (when (and (featurep 'native-compile)
+(equal dump-mode "pdump"))
+   ;; Don't enable this before bootstrap is completed, as the
diff --git a/gnu/packages/patches/emacs-next-native-comp-driver-options.patch 
b/gnu/packages/patches/emacs-next-native-comp-driver-options.patch
new file mode 100644
index 00..e4ed5a48f1
--- /dev/null
+++ b/gnu/packages/patches/emacs-next-native-comp-driver-options.patch
@@ -0,0 +1,18 @@
+We substitute this anyway, so let's make it easier to substitute.
+
+--- a/lisp/emacs-lisp/comp.el
 b/lisp/emacs-lisp/comp.el
+@@ -203,9 +203,7 @@ and above."
+   :type '(repeat string)
+   :version "28.1")
+ 
+-(defcustom native-comp-driver-options
+-  (cond ((eq system-type 'darwin) '("-Wl,-w"))
+-((eq system-type 'cygwin) '("-Wl,-dynamicbase")))
++(defcustom native-comp-driver-options nil
+   "Options passed verbatim to the native compiler's back-end driver.
+ Note that not all options are meaningful; typically only the options
+ affecting the assembler and linker are likely to be useful.
+-- 
+2.38.0
+

base-commit: 

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

[Liliana Marie Prikler]

Am Mittwoch, dem 04.10.2023 um 12:47 +0200 schrieb Vivien Kraus:
> 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.
> 
> * gnu/services/dbus.scm (dbus-activation): Symlink /run/dbus to
> /var/run/dbus.
> (%dbus-accounts): Run dbus in /run/dbus.
> (dbus-root-service-type): Save the pid file in /run/dbus.
> ---
> 
> Le jeudi 05 octobre 2023 à 06:41 +0200, Liliana Marie Prikler a écrit
> :
> > > I’m still concerned about doing a symlink in the activation
> > > function.
> > > What if we activate a new system from an existing one? Won’t the
> > > symlink
> > > fail? I think we should preemptively delete /var/run/dbus and
> > > make a new
> > > symlink every time. But I could be wrong, maybe this is not
> > > needed.
> > > 
> > > What do you think?
> > If we go this route, I think we should first check whether
> > /var/run/dbus is indeed a symlink to /run/dbus and move the
> > existing files if not before deleting the directory and creating
> > the symlink.  But before that, we should try to symlink, which will
> > fail with EEXIST if the file already exists, regardless of whether
> > it's a symlink – thereafter you can check the cause of this failure
> > through lstat.
> 
> I changed my mind! I now think it is OK for the system reconfigure to
> fail if a different symlink already exists.
Perhaps, but it's not okay to fail if it's a regular directory.  We
should move those!


Cheers

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

[Liliana Marie Prikler]

Am Mittwoch, dem 04.10.2023 um 12:47 +0200 schrieb Vivien Kraus:
> 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.
> 
> * gnu/services/dbus.scm (dbus-activation): Symlink /run/dbus to
> /var/run/dbus.
> (%dbus-accounts): Run dbus in /run/dbus.
> (dbus-root-service-type): Save the pid file in /run/dbus.
> ---
> 
> > Perhaps, but it's not okay to fail if it's a regular directory.  We
> > should
> > move those!
> 
> I’m not sure I understand.  What comes to my mind is:
> 
> 1. Try to make the symlink. If it fails with EEXIST:
> 2. Try to read /var/run/dbus as a symlink. If it points to /run/dbus
> already,
>    stop. Otherwise:
> 3. Move everything in /var/run/dbus to /run/dbus.
> 4. Delete the now-empty /var/run/dbus.
> 5. Symlink /run/dbus to /var/run/dbus.
> 
> Is it what you meant?
Yep, that's what I meant.

> Best regards,
> 
> Vivien
> 
>  gnu/services/dbus.scm | 38 +++---
>  1 file changed, 35 insertions(+), 3 deletions(-)
> 
> diff --git a/gnu/services/dbus.scm b/gnu/services/dbus.scm
> index 5a0c634393..44bf0c910b 100644
> --- a/gnu/services/dbus.scm
> +++ b/gnu/services/dbus.scm
> @@ -163,7 +163,7 @@ (define %dbus-accounts
>   (group "messagebus")
>   (system? #t)
>   (comment "D-Bus system bus user")
> - (home-directory "/var/run/dbus")
> + (home-directory "/run/dbus")
>   (shell (file-append shadow "/sbin/nologin")
>  
>  (define dbus-setuid-programs
> @@ -186,7 +186,39 @@ (define (dbus-activation config)
>  (let ((user (getpwnam "messagebus")))
>    ;; This directory contains the daemon's socket so it must
> be
>    ;; world-readable.
> -  (mkdir-p/perms "/var/run/dbus" user #o755))
> +  (mkdir-p/perms "/run/dbus" user #o755))
> +
> +    (catch 'system-error
> +  (lambda ()
> +    (symlink "/run/dbus" "/var/run/dbus"))
> +  (lambda args
> +    (let ((errno (system-error-errno args)))
> +  (cond
> +   ((= errno EEXIST)
> +    (let ((existing-name
> +   (false-if-exception
> +    (readlink "/var/run/dbus"
> +  (unless (equal? existing-name "/run/dbus")
> +    ;; Move the content of /var/run/dbus to
> /run/dbus, and
> +    ;; retry.
> +    (let ((dir (opendir "/var/run/dbus")))
> +  (let move-to-/run/dbus ()
> +    (let ((next (readdir dir)))
> +  (unless (or (equal? next ".")
> +  (equal? next "..")
> +  (eof-object? next))
> +    (rename-file (string-append
> "/var/run/dbus/" next)
> + (string-append "/run/dbus/"
> next)))
> +  (unless (eof-object? next)
> +    (move-to-/run/dbus
> +  (closedir dir)
> +  (rmdir "/var/run/dbus")
> +  (symlink "/run/dbus" "/var/run/dbus")
You might want to express this in terms of a function similar to copy-
recursively, or at the very least a let loop.
  (let loop ((next (readdir dir)))
(cond
  ((eof-object? next) (closedir dir))
  ((member next "." "..") (loop (readdir dir)))
  (else (rename-file …) (loop (readdir dir)
> +   (else
> +    (format (current-error-port)
> +    "Failed to symlink /run/dbus to
> /var/run/dbus: ~s~%"
> +    (strerror errno))
> +    (error "cannot create /var/run/dbus"))
>  
>  (unless (file-exists? "/etc/machine-id")
>    (format #t "creating /etc/machine-id...~%")
> @@ -210,7 +242,7 @@ (define dbus-shepherd-service
>   '(#:environment-variables
> '("DBUS_VERBOSE=1")
>     #:log-file "/var/log/dbus-
> daemon.log")
>   '())
> -  #:pid-file "/var/run/dbus/pid"))
> +  #:pid-file "/run/dbus/pid"))
>  (stop #~(make-kill-destructor)))
>  
>  (define dbus-root-service-type
> 
> base-commit: b18b2d13488f2a92331ccad2dc8cbb54ee15582f
Cheers

bug#65924: git searches coreutils and util-linux commands in PATH

[Liliana Marie Prikler]

Am Montag, dem 09.10.2023 um 10:21 -0400 schrieb Maxim Cournoyer:
> Hi Liliana :-)
> 
> Liliana Marie Prikler  writes:
> 
> > Am Samstag, dem 07.10.2023 um 23:18 -0400 schrieb Maxim Cournoyer:
> > > It's simpler to add features on top of a minimal variant than to
> > > remove them, and helps avoiding mistakenly changing git-minimal,
> > > which has many dependents.
> > > 
> > > * gnu/packages/version-control.scm (git-minimal): Move above git
> > > and severe inheritance.  Remove input label.  Repatriate most
> > > fields from...
> > > (git): ... here.  Define as package/inherit to inherit from git-
> > > minimal.
> > > Extend minimal values instead of overriding them whole.
> > > ---
> > Having done the same to Emacs recently, I fully agree with this
> > move.
> 
> Great; does this mean a LGTM on your side for this one?  Please be
> explicit :-).
If you need me to reduce it to four letters, yes, LGTM.

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

[Liliana Marie Prikler]

Am Sonntag, dem 08.10.2023 um 16:53 +0200 schrieb Liliana Marie
Prikler:
> [...]
> Otherwise LGTM.  I'd commit it, but my machine is currently busy
> building half of core-updates for no reason.
No longer busy, time to commit.

Thanks

bug#65924: git searches coreutils and util-linux commands in PATH

[Liliana Marie Prikler]

Am Montag, dem 09.10.2023 um 14:21 -0400 schrieb Maxim Cournoyer:
> Hello,
> 
> Liliana Marie Prikler  writes:
> 
> > [...]
> > If you need me to reduce it to four letters, yes, LGTM.
> 
> Explicit is better than implicit.  I've been thinking to document
> this in our contributing section; e.g. a reviewed commit must have
> the 'LGTM' from the reviewer.  If a series is LGTM, it needs to be
> implicitly mentioned with 'this series LGTM'.  That may sound silly,
> but I think it'd simplify reviewer/submitters interactions.
s/implicitly/explicitly/?

I don't necessarily agree, but it's not a hard disagree either.  I'll
try to keep that in mind at least when reviewing your patches to not
cause confusion.

Cheers

bug#65924: git searches coreutils and util-linux commands in PATH

[Liliana Marie Prikler]

Am Montag, dem 09.10.2023 um 15:25 -0400 schrieb Maxim Cournoyer:
> Hi Liliana,
> 
> Liliana Marie Prikler  writes:
> 
> > Am Montag, dem 09.10.2023 um 14:21 -0400 schrieb Maxim Cournoyer:
> > > Hello,
> > > 
> > > Liliana Marie Prikler  writes:
> > > 
> > > > [...]
> > > > If you need me to reduce it to four letters, yes, LGTM.
> > > 
> > > Explicit is better than implicit.  I've been thinking to document
> > > this in our contributing section; e.g. a reviewed commit must
> > > have the 'LGTM' from the reviewer.  If a series is LGTM, it needs
> > > to be implicitly mentioned with 'this series LGTM'.  That may
> > > sound silly, but I think it'd simplify reviewer/submitters
> > > interactions.
> > s/implicitly/explicitly/?
> 
> Explicit, indeed.
> 
> > I don't necessarily agree, but it's not a hard disagree either. 
> > I'll try to keep that in mind at least when reviewing your patches
> > to not cause confusion.
> 
> OK.  One place where this becomes more important is when the send-
> email cc hook includes people partially to a series. A LGTM on a
> single message in this case could be misinterpreted for the whole
> series.  It's best to document the expectations and codify these
> often used signals, in my opinion.
I personally prefer to comment to all individual patches or use the
series starter for "this series LGTM", but to recap; 1 and 2 L'd GTM
(with a small caveat for 1) already and we discussed 3 in IRC, so LGTM
for the series.

Cheers

bug#65924: git searches coreutils and util-linux commands in PATH

[Liliana Marie Prikler]

Am Montag, dem 09.10.2023 um 23:03 +0200 schrieb b...@bokr.com:
> Hi,
> 
> On +2023-10-09 20:33:38 +0200, Liliana Marie Prikler wrote:
> > I don't necessarily agree, but it's not a hard disagree either. 
> > I'll try to keep that in mind at least when reviewing your patches
> > to not cause confusion.
> > 
> > Cheers
> > 
> 
> TL;DR: Would it make sense to anticipate that LLM-bots will be used
> to automate gathering of info for reviewers?
> 
> If so, what would a style guide for english in posts (like
> a coding style guide, but for LLM-bot consumption) look like?
> Some kind of literate programming for LLM-bot and human use?
Let's not rely on large language models.  If we are going to automate
this, it ought to be through interpretable, "rule-based" systems. 
Like, imagine that on top of telling debbugs to close a bug etc., you
could tell debbugs (or some other tool) that some patch or a series
looks good to you.  We could then add an interface to allow filtering
for "looks good" series for quick patch application, the rationale
being that committers have to do less or no review of their own as they
commit to a patch or series.*

Cheers

* They should still check that the series actually looks good to enough
folks.

bug#66227: [bug#66225] [PATCH v3] gnu: emacs-next-minimal: Apply Guix patches.

[Liliana Marie Prikler]

Am Samstag, dem 07.10.2023 um 09:56 +0400 schrieb Andrew Tropin:
> On 2023-10-06 17:58, Liliana Marie Prikler wrote:
> 
> > * gnu/packages/patches/emacs-next-native-comp-driver-options.patch:
> > Add file.
> > * gnu/packages/patches/emacs-next-exec-path.patch: Add file.
> > * gnu/local.mk (dist_patch_DATA): Register them here.
> > * gnu/packages/emacs.scm (emacs-next-minimal)[origin](patches):
> > Include the same patches as emacs-minimal, save for the variants
> > specific to emacs-next introduced above.
> > 
> > Co-Authored-By: Nicolas Graves 
> > Fixes: ‘emacs-next’ is almost unusable <https://bugs.gnu.org/66227>
> > […]
> 
> Hi Liliana and Nicolas, the fixes looks good to me.
Thanks for checking.  I pushed it now (perhaps a bit too hasty, but
it's been a problem for some while).

Cheers

bug#65924: [PATCH core-updates 1/3] gnu: git: Remove labels and use gexps.

[Liliana Marie Prikler]

Am Samstag, dem 07.10.2023 um 23:18 -0400 schrieb Maxim Cournoyer:
> * gnu/packages/version-control.scm (git)
> [native-inputs, inputs]: Remove labels.
> [arguments]: Use gexps.  Use gexp variables input searching
> procedures where it makes sense.
> ---
Heads-up, the additional completions I'm installing in 66171 will cause
a merge conflict here (they need to go to core-updates due to git being
git and git-minimal still changes accordingly on master).  IIUC it
should be easier to apply your changes first and then mine.  IMHO,
completions shouldn't go to git-minimal, but reading 2/3 (i.e. reading
without applying) I'm not quite sure where they end up atm.

Cheers

bug#65924: [PATCH core-updates 2/3] gnu: git: Invert inheritance relationship.

[Liliana Marie Prikler]

Am Samstag, dem 07.10.2023 um 23:18 -0400 schrieb Maxim Cournoyer:
> It's simpler to add features on top of a minimal variant than to
> remove them, and helps avoiding mistakenly changing git-minimal,
> which has many dependents.
> 
> * gnu/packages/version-control.scm (git-minimal): Move above git and
> severe inheritance.  Remove input label.  Repatriate most fields
> from...
> (git): ... here.  Define as package/inherit to inherit from git-
> minimal.
> Extend minimal values instead of overriding them whole.
> ---
Having done the same to Emacs recently, I fully agree with this move.

bug#65383: [gnome-team] Nothing is reproducible anymore

[Liliana Marie Prikler]

The culprit has been found [1] and arrested [2].  It turns out that the
ungexp Bruno used at the time was "too wide", resulting in a new .drv
for shared-mime-info each time.  This wasn't caught during review,
because who has time to build things twice?

What are the lessons learned from this?
1. Closely look at when and how you use ungexp.
2. Actually build things multiple times ;)
Perhaps we can also add this to the things to check in continuous
integration, though with the fair amount of known unreproducible
packages, I'm not so sure of how great this will go.

Anyway, thanks for your attention.

Cheers

[1] http://logs.guix.gnu.org/guix/2023-08-19.log#184540
[2] 
http://git.savannah.gnu.org/cgit/guix.git/commit/?h=gnome-team=e43498b32dcbbf055d72339086213cd60c336acf

bug#64586: Emacs-Packages should contain native-compiled files

[Liliana Marie Prikler]

Hi,

Am Mittwoch, dem 23.08.2023 um 17:37 +0200 schrieb Simon Tournier:
> Hi,
> 
> On Wed, 12 Jul 2023 at 21:36, Liliana Marie Prikler
>  wrote:
> 
> > You are correct, but unlike other language ecosystems (e.g. Python
> > or Common Lisp), we don't have a convenient "package-with-emacs" as
> > of yet.  This is basically step 3 of <
> > https://issues.guix.gnu.org/63984#0>
> > of which only step 1 has been concluded so far.  (In fact, I need
> > to merge 29.0.92 into emacs-team, but that shouldn't be as
> > difficult as the rest in there.)  If you want things to happen
> > faster, just tag your patches with emacs-team and we will review
> > them :)
> 
> Just to point that a kind of ’package-with-emacs’ had been discussed
> in #41732 [1] and my current understanding is that some corner cases
> are annoying.
The plan would have been to address those, but we were caught with our
panties down and are behind the latest Emacs release.  Oh well, guess
those nice things have to be delayed a little longer.

> Emacs packages use 3 variants for “compiling“: emacs-minimal, emacs-
> no-x and emacs; see #:emacs in arguments field.
> 
> (And I let aside emacs-no-x-toolkit. :-))
> 
> Therefore, it does not appear to me easy to have some generic
> package-with-emacs for rewriting the “compiler” of the Emacs
> packages.  Somehow, a profile containing Emacs packages has these
> packages not necessary built with the same Emacs build-system
> compiler but still work together; contrary to Python, Common Lisp,
> OCaml or others.
I don't think there'd be that many cases to consider.  You can either
adjust #:emacs (when using emacs-build-system) or you have it as
native-input (when using any other build system).  For both cases, you
can add some logic to make that emacs the one used as the argument to
the hypothetical package-with-emacs function.

> And I do not know what could be an handy way to declare Emacs package
> variants.  Any idea?
I'd have to investigate that myself.  My basic idea would have been to
copy what Common Lisp is doing and introduce consistent naming, i.e.
have emacs-minimal-org, emacs-no-x-toolkit-org, etc.  That being said,
I consider some variants to be more important than others, particularly
regular emacs-PACKAGE > emacs-any-other-variant-PACKAGE.  Which ones to
build on CI will imho be much rather a political discussion than a
technical one.

Cheers

bug#65306: [shepherd] ntpd throws shepherd out of the loop

[Liliana Marie Prikler]

Hi Guix,

I have a laptop that's a little stuck in the past… more accurately
January of 2020 thanks to what I believe to be an empty CMOS battery. 
As of recently (maybe it dates back longer, but I first experienced it
two weeks ago and just now got to debugging it a little), Shepherd gets
stuck at 100% CPU usage "early" on first boot.  I can prevent this
issue by getting the system time "close enough" to the actual time
before the NTP sync, but see the first sentence.  Not having a network
connection also works, but that's somewhat unpractical.  Also, the high
CPU usage still occurs if a sync is done later.  I have yet to
encounter the bug post hibernation, but I also wish not to.  There
doesn't appear to be anything particular interesting in the logs
either.

Cheers

bug#65383: [gnome-team] Nothing is reproducible anymore

[Liliana Marie Prikler]

I have absolutely no idea how this came to be:

sh-5.1$ ./pre-inst-env guix build gdk-pixbuf --dry-run
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird
aktualisiert … 100.0%
substitute: Liste der Substitute von „https://bordeaux.guix.gnu.org“
wird aktualisiert … 100.0%
The following derivations would be built:
  /gnu/store/sn4avcl518i75r6595ns5k1w22m1h93z-gdk-pixbuf-2.42.8.drv
  /gnu/store/z359nfywzyhbfydbnv05h1cc3av2fqbc-shared-mime-info-2.2.drv
sh-5.1$ ./pre-inst-env guix build gdk-pixbuf --dry-run
substitute: Liste der Substitute von „https://ci.guix.gnu.org“ wird
aktualisiert … 100.0%
substitute: Liste der Substitute von „https://bordeaux.guix.gnu.org“
wird aktualisiert … 100.0%
The following derivations would be built:
  /gnu/store/50pk294x08jpgzpag8z4877pa6s5bc8h-gdk-pixbuf-2.42.8.drv
  /gnu/store/5375hf13vnxab7lyrbxqg3ss7q39lxml-shared-mime-info-2.2.drv

The hash changes with each run.  What the hell is going on?

bug#65575: [PATCH 3/3] gnu: emacs: Reload subdirs.el files in 'guix-emacs-autoload-packages'.

[Liliana Marie Prikler]

Hi Maxim,

Am Montag, dem 28.08.2023 um 01:11 -0400 schrieb Maxim Cournoyer:
> This fixes a regression introduced with 79cfe30f3 ("build-system:
> emacs: Use subdirectories again.") which caused the
> 'guix-emacs-autoload-packages' to no
> longer be able to autoload all packages.
> 
> * gnu/packages/aux-files/emacs/guix-emacs.el
> (guix-emacs-autoload-packages-called): New variable.
> (guix-emacs-autoload-packages): Reload subdirs.el files an all but
> the first call of this procedure.
> * doc/guix.texi (Application Setup): Document that
> 'guix-emacs-autoload-packages' can be invoked interactively to auto-
> reload newly installed Emacs packages.
> 
> ---
Thank you for looking at this.  I agree that even if we don't want to
generally load new packages into existing Emacs processes for the
breakages they might induce, not being able to do so at all is also not
a great option.  However, I don't think that tracking is the right
solution here, see below.

>  doc/guix.texi  | 11 +++
>  gnu/packages/aux-files/emacs/guix-emacs.el | 12 
>  2 files changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/doc/guix.texi b/doc/guix.texi
> index f82bb99069..66da4f9cd4 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -2167,12 +2167,15 @@ Application Setup
>  Emacs through the @env{EMACSLOADPATH} environment variable, which is
>  set when installing Emacs itself.
>  
> +@cindex guix-emacs-autoload-packages, refreshing Emacs packages
>  Additionally, autoload definitions are automatically evaluated at
> the
>  initialization of Emacs, by the Guix-specific
> -@code{guix-emacs-autoload-packages} procedure.  If, for some reason,
> you
> -want to avoid auto-loading the Emacs packages installed with Guix,
> you
> -can do so by running Emacs with the @option{--no-site-file} option
> -(@pxref{Init File,,, emacs, The GNU Emacs Manual}).
> +@code{guix-emacs-autoload-packages} procedure.  This procedure can
> be
> +interactively invoked to have newly installed Emacs packages
> discovered,
> +without having to restart Emacs.  If, for some reason, you want to
> avoid
> +auto-loading the Emacs packages installed with Guix, you can do so
> by
> +running Emacs with the @option{--no-site-file} option (@pxref{Init
> +File,,, emacs, The GNU Emacs Manual}).
>  
>  @quotation Note
>  Emacs can now compile packages natively.  Under the default
> diff --git a/gnu/packages/aux-files/emacs/guix-emacs.el
> b/gnu/packages/aux-files/emacs/guix-emacs.el
> index ed0c913163..b4a4fd1d91 100644
> --- a/gnu/packages/aux-files/emacs/guix-emacs.el
> +++ b/gnu/packages/aux-files/emacs/guix-emacs.el
> @@ -54,6 +54,9 @@ The files in the list do not have extensions (.el,
> .elc)."
>  (expand-file-name "subdirs.el" dir))
>    (guix-emacs--non-core-load-path
>  
> +(defvar guix-emacs-autoload-packages-called nil
> +  "True if `guix-emacs-autoload-packages' was already run.")
> +
>  ;;;###autoload
>  (defun guix-emacs-autoload-packages ()
>    "Autoload Emacs packages found in EMACSLOADPATH.
> @@ -61,6 +64,15 @@ The files in the list do not have extensions (.el,
> .elc)."
>  'Autoload' means to load the 'autoloads' files matching
>  `guix-emacs-autoloads-regexp'."
>    (interactive)
> +  ;; Reload the subdirs.el files such as the one generated by the
> Guix profile
> +  ;; hook, so that newly installed Emacs packages located under
> +  ;; sub-directories are put on the load-path without having to
> restart Emacs.
> +  (if guix-emacs-autoload-packages-called
> +  (progn
> +    (mapc #'load-file (guix-emacs--subdirs-files))
> +    (setq load-path (delete-dups load-path)))
> +    (setq guix-emacs-autoload-packages-called t))
> +
Rather than keeping track of whether the function was already called
(which would make debugging more tedious if you also have e.g. broken
packages from another source on your EMACSLOADPATH), I think the user
ought to signal their intent to reload the subdirs files via the
universal argument.

e.g. 
(defun guix-emacs-autoload-packages ( reload)
  "..."
  (interactive "P")
  (when reload (mapc #'load-file (guix-emacs--subdirs-files)))
  ...)

WDYT?

bug#55043: Some packages depend on nss-certs, some bundle it.

[Liliana Marie Prikler]

Am Mittwoch, dem 20.04.2022 um 17:22 +0200 schrieb Maxime Devos:
> X-Debbugs-CC: Hartmut Goebel 
> 
> Hi,
> 
> There are some packages bundling CA certificates:
> 
>  * nss-certs / le-certs (this one is not a problem)
>  * python-certifi
>  * perl-mozilla-ca
>  * rust-webpki-roots
>  * erlang-certifi (not yet, see
> )
>  * go-github-com-certifi-gocertifi
> 
> Worse, these packages have many dependencies!
> 
> $ guix refresh -l nss-certs le-certs python-certifi perl-mozilla-ca
> rust-webpki-roots 
> Het bouwen van het volgende 534 pakketten zorgt ervoor dat 1575
> afhankelijke pakketten opnieuw worden gebouwd: ...
This is only if you update all of them at once.  An update to any one
of them might go to staging instead, which for the record I don't see
merged too often in recent times.  Also, with the exception of our
snowflake static linkers Rust and Go, we should be able to graft them
on master.

> Why is this a problem?
> 
>  * I don't think that anybody is actually looking into keeping
>    python-certifi / perl-mozilla-ca / rust-webpki-roots / ...
>    up to date.  Security problems!
>  * Even so, this seems a waste of time to me, why not just use
>    $SSL_CERT_DIR / $SSL_CERT_FILE instead?
Point taken, I think these might just be different programming language
implementation that essentially store the same certificate in a known
location and then refer to it.  Which Guix can already do by specifying
SSL_CERT_DIR or SSL_CERT_FILE in a wrapper script.
>  * Lots of rebuilds to update things.
>  * (relatively minir) Allowing overriding the certificates trusted
> with
>    $SSL_CERT_DIR / $SSL_CERT_FILE would be nice.
I don't think SSL_CERT_DIR and SSL_CERT_FILE customization is useful in
all apps however.  I think there is a legitimate concern, that users
could be tricked into downloading a malicious certificate chain and
then running their instant messaging app with that, enabling a man in
the middle attack.  Again, Guix could solve this by hardcoding
SSL_CERT_*, but...

> Also relevant to the third point: some packages depend on nss-certs.
We'd be increasing this number if instead of language-specific certifi
packages, we consolidated them into nss-certs.  On the other hand, we
would be reducing the number of dependents in libraries that don't need
to hardcode certs for security reasons, so perhaps life will become
easier at some point.

Also, w.r.t. updating nss-certs, since we do have grafts, security
updates should not be a concern in my opinion.  Making sure that all
our security-critical instant messaging applications use our trusted
bundle rather than their own very curated set is of higher priority in
my opinion.

> I've heard an argument in favour of just using the certifi packages
> instead of using our own certificates:
> 
> > (from Hartmut Goebel, at )
> > Neither python-certifi nor gocertifi build on nss-cert. Addind some
> > update mechanism into the Guix package is not a good idea IMO: This
> > would make “erlang-certif@2.9.0“ contain different certificates
> > than the release 2.9.0, making debugging a hell.
> 
> ... but I don't follow, it's just a different set of certificates,
> could you elaborate? 
>From a library/app developer's point of view, you can't rely on the
system certificate store if your system's vendor starts with M, ends
with t and has 7 letters in between.  I'm not sure how missing erlang-
certif would impact building any of its packages, but perhaps they
found a way to break builds if some certificate is missing.

> Proposal:
> 
>  * eventually remove python-certifi, perl-mozilla-ca, ... because
>nobody appears to be keeping them up-to-date and for security it
>is important for them to be up to date.
Sure.  In the meantime, however, I'd suggest mocking them by having
them simply return nss-certs or whatever else we have for a trusted
certificate bundle.

>  * likewise, forbid new packages from being included as-is if they
>depend on a certifi package or nss-certs.
See above.

>  * Look into removing the certifi packages from the inputs of
>packages, submitting patches to upstream for using $SSL_CERT_... /
>/etc/ssl/certs ... as appropriate.
That I agree with.


Cheers

bug#55011: let user drop into REPL from installer

[Liliana Marie Prikler]

Am Dienstag, dem 19.04.2022 um 01:23 +0200 schrieb raingloom:
> I tried installing Guix with the installer, mostly to give LUKS a try
> in a low effort way, but also to hopefully find some bugs. I
> succeeded in the latter so far. :)
> 
> I did a manual partitioning, with an encrypted BTRFS root and an ext4
> /boot. The layout was left over from a previous failed encrypted
> install with automatic partitioning.
> 
> Long story short I got an error related to mkfs.btrfs, this I think
> has already been reported, but Mumi's search is not great so I
> haven't verified that yet.
> 
> The important thing is that I'd like not to reboot or start the
> installation from scratch. Scheme has call/cc and continuable
> exceptions and whatever, so could we let users at least attempt to
> fix these errors manually?
> 
> At the very least it would let them gather more info for debugging.
As far as I'm aware you still have four open terminals after things go
wrong in the graphical installer.  I'm not sure how much of the
automatic process actually mirrors the manual – we could aim for 100%
surely – but let's say you encounter an issue during mkfs as above,
then it'd be nice if Guix could just catch that error, check where we
are according to the manual, print out the backtrace and a nice message
"You can attempt to fix this by switching to manual installation and
continuing from SECTION/SUBSECTION."  Perhaps add a "fix manually"
button that switches to VT3, as well as your typical "Redo
installation".

Cheers

bug#55003: emacs-dash test failing,

[Liliana Marie Prikler]

Am Montag, dem 18.04.2022 um 06:23 -0500 schrieb Bryan Paronto:
> Hello Guixers
Hi Bryan

> I’ll prefacing by saying I’m still rather green to Guix System and
> Home, but am loving every minute of hacking, even when things dont
> immediate go according to plan.
> 
> This morning I’m attempting to use Guix for all of my Emacs package
> management needs, however one package, emacs-dash-2.19.1 seems to be
> failing to build. According to the logs, this is due to a long-than-
> 80-character doctring. According to their repository, this issue has
> been address, but a new release has not yet been cut containing the
> fix.
That's rather peculiar given that emacs-dash builds fine in CI as far
as I am aware.  I also have a build locally cached.

/gnu/store/63r1i2mpgivb2f99h2dscmrymcv9n257-emacs-dash-2.19.1

On which Guix commit are you currently?  Do you perhaps use a channel,
that provides its own definition of emacs-dash?

> What is the prescribed way of addressing such an issue, where emacs-
> dash is an input on one or more of the packages I’m attempting to
> install as part of my reconfigure.
The short fix would be to cut out emacs-dash from your config for now.
Use `guix graph' to find out what pulls it in.  The long fix would be
to find out what makes emacs-dash fail and repair that.

> I’ve run `guix pull' and `guix package -u' . I’m uncertain of
> creating a new package definition with tests disabled would be the
> solution, but I’ve yet to try.
You can use a transformation for that, it's called --without-tests. 
Using it does not guarantee a successful build, though.

Cheers

bug#66864: emacs-build-system builds .eln-files with mismatching path-hashes

[Liliana Marie Prikler]

Am Donnerstag, dem 02.11.2023 um 08:13 + schrieb Mekeor Melire:
> 
> 2023-11-01 15:16 liliana.prik...@gmail.com:
> 
> > I think Emacs might be calculating its own hash at runtime 
> > rather than baking in the value at build time.
> 
> Exactly. That's what I was trying to express.
I'm not sure whether this is reproducible.  On my system
  $ guix build emacs-dash --with-input=emacs-minimal=emacs
  /gnu/store/zr16hd25338imljqxxfsf07smbfv3wxd-emacs-dash-2.19.1
  $ ls 
/gnu/store/zr16hd25338imljqxxfsf07smbfv3wxd-emacs-dash-2.19.1/lib/emacs/native-site-lisp
  29.1-e9e5c1ce
  $ emacs --batch --eval='(message "%s" comp-abi-hash)'
  e9e5c1ce
Looks like everything's alright?

Cheers

bug#66864: emacs-build-system builds .eln-files with mismatching path-hashes

[Liliana Marie Prikler]

Am Donnerstag, dem 09.11.2023 um 12:21 +0100 schrieb Josselin Poiret:
> Hi,
> 
> Liliana Marie Prikler  writes:
> 
> > Am Donnerstag, dem 02.11.2023 um 08:13 + schrieb Mekeor Melire:
> > > 
> > > 2023-11-01 15:16 liliana.prik...@gmail.com:
> > > 
> > > > I think Emacs might be calculating its own hash at runtime 
> > > > rather than baking in the value at build time.
> > > 
> > > Exactly. That's what I was trying to express.
> > I'm not sure whether this is reproducible.  On my system
> >   $ guix build emacs-dash --with-input=emacs-minimal=emacs
> >   /gnu/store/zr16hd25338imljqxxfsf07smbfv3wxd-emacs-dash-2.19.1
> >   $ ls /gnu/store/zr16hd25338imljqxxfsf07smbfv3wxd-emacs-dash-
> > 2.19.1/lib/emacs/native-site-lisp
> >   29.1-e9e5c1ce
> >   $ emacs --batch --eval='(message "%s" comp-abi-hash)'
> >   e9e5c1ce
> > Looks like everything's alright?
> 
> It's the .eln file itself that has the hash of the .el's path in its
> name.  That's computed by `comp-el-to-eln-filename`.
Does this still occur on the emacs-team branch, where we compile
everything from the build directory?

Cheers

bug#55427: emacs-libgit tests are broken

[Liliana Marie Prikler]

With the update to Emacs 28, emacs-libgit (a requirement for emacs-
magit) fails to build with the following test error:

Test project /tmp/guix-build-emacs-libgit-20200515-1.0ef8b13.drv-
0/build
  Start  1: libegit2_annotated-commit
 1/29 Test  #1: libegit2_annotated-commit    Passed0.38 sec
  Start  2: libegit2_blame
 2/29 Test  #2: libegit2_blame ...   Passed0.39 sec
  Start  3: libegit2_blob
 3/29 Test  #3: libegit2_blob ***Failed0.43 sec
Running 4 tests (2022-05-15 07:25:56+, selector ‘t’)
Test blob-binary backtrace:
  signal(wrong-type-argument (utf-8-string-p "\177ELF\2\1\1\0\0\0\0\0\
  apply(signal (wrong-type-argument (utf-8-string-p "\177ELF\2\1\1\0\0
  (setq value-42 (apply fn-40 args-41))
  (unwind-protect (setq value-42 (apply fn-40 args-41)) (setq form-des
  (if (unwind-protect (setq value-42 (apply fn-40 args-41)) (setq form
  (let (form-description-44) (if (unwind-protect (setq value-42 (apply
  (let ((value-42 'ert-form-evaluation-aborted-43)) (let (form-descrip
  (let* ((fn-40 #'string=) (args-41 (condition-case err (let ((signal-
  (let* ((repo (libgit-repository-open path)) (blob (libgit-revparse-s
  (let ((default-directory path)) (init) (commit-change "filename" str
  (progn (make-directory path 'parents) (let ((default-directory path)
  (unwind-protect (progn (make-directory path 'parents) (let ((default
  (let ((path "/tmp/guix-build-emacs-libgit-20200515-1.0ef8b13.dr...")
  (let* ((str (unibyte-string 127 69 76 70 2 1 1 0 0 0 0 0 0 0 0 0 3 0
  (let ((lexical-binding nil)) (let* ((str (unibyte-string 127 69 76 7
  (lambda nil (let ((lexical-binding nil)) (let* ((str (unibyte-string
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name blob-binary :documentation nil :body 
  ert-run-or-rerun-test(#s(ert--stats :selector t :tests [#s(ert-test 
  ert-run-tests(t #f(compiled-function (event-type  event-args) #
  ert-run-tests-batch(nil)
  ert-run-tests-batch-and-exit()
  command-line-1(("-L" "/tmp/guix-build-emacs-libgit-20200515-1.0ef8b1
  command-line()
  normal-top-level()
Test blob-binary condition:
(wrong-type-argument utf-8-string-p
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\7\0\0\0\0\0\0@\0\0\
0\0\0\0\0\270\33\0\0\0\0\0\0\0\0\0\0@\08\0\11\0@\0\35\0\34\0\6\0\0\0\5\
0\0\0@\0\0\0\0\0\0\0")
   FAILED  1/4  blob-binary (0.041795 sec)
   passed  2/4  blob-create-fromdisk (0.023014 sec)
   passed  3/4  blob-create-fromstring (0.022546 sec)
   passed  4/4  blob-text (0.044085 sec)

Ran 4 tests, 3 results as expected, 1 unexpected (2022-05-15
07:25:56+, 0.301178 sec)

1 unexpected results:
   FAILED  blob-binary
[...]

I have no idea what causes it or where utf-8-string-p even comes from,
but the implementation of string= appears to have changed.  When
running the build locally another test also appears flaky due to weird
time stamp conversions.

Cheers

bug#55495: emacs-haskell-mode build fails

[Liliana Marie Prikler]

Hi Taiju,

Am Mittwoch, dem 18.05.2022 um 17:30 +0900 schrieb Taiju HIGASHI:
> Hi,
> 
> emacs-haskell-mode build fails.
> 
> [...]
> In toplevel form:
> haskell-customize.el:173:1: Error: custom-declare-variable `haskell-
> process-do-cabal-format-string' docstring wider than 80 characters
> make: *** [Makefile:80: build-28.1/haskell-customize.elc] Error 1
> make: *** Waiting for unfinished jobs
> 
> In toplevel form:
> haskell-cabal.el:363:8: Error:  docstring wider than 80 characters
> make: *** [Makefile:80: build-28.1/haskell-cabal.elc] Error 1
> 
> In toplevel form:
> haskell-compile.el:42:1: Error: custom-declare-variable `haskell-
> compile-cabal-build-command' docstring wider than 80 characters
> make: *** [Makefile:80: build-28.1/haskell-compile.elc] Error 1
> 
> In toplevel form:
> haskell.el:448:8: Error:  docstring wider than 80 characters
> make: *** [Makefile:80: build-28.1/haskell.elc] Error 1
> error: in phase 'build': uncaught exception:
> %exception #< program: "make" arguments: ("-j" "16"
> "EMACS=/gnu/store/ad4gg34q1dnkvdblrl2f1svcv84bvbgs-emacs-minimal-
> 28.1/bin/emacs") exit-status: 2 term-signal: #f stop-signal: #f>
> phase `build' failed after 0.4 seconds
> command "make" "-j" "16"
> "EMACS=/gnu/store/ad4gg34q1dnkvdblrl2f1svcv84bvbgs-emacs-minimal-
> 28.1/bin/emacs" failed with status 2
We already have a few packages that disable the byte-compilation-
warnings to errors conversion due to this docstring thing.  Note that a
better alternative to this would be setting byte-compile-warnings to
(not docstrings).

> I believe the problem will be resolved when the following pull
> request I submitted is merged and the next version is released.
> https://github.com/haskell/haskell-mode/pull/1780
> 
> I will submit a patch once the release is complete.
Is a release imminent?  If not, you could apply your patch to the Guix
package first.  Given that you've already made a pull request upstream
there should be little in the way of pushing it here other than normal
review work :)

Cheers

bug#55501: [PACTH] emacs-evil fails compilation by emacs-28.1, but upstream has newer commits which should compile

[Liliana Marie Prikler]

Applied with some cosmetic changes in commit message and patch itself.

Am Donnerstag, dem 19.05.2022 um 01:25 +0800 schrieb Maze:
> Below a patch for emacs-evil.
> 
> Since upstream declared the new version 1.15.0 in a commit message
> without creating a tag, I have to git-reference to a commit. I tried
> to reproduce the way it's done on other emacs extensions.
> 
> Other than this, it should be just bumping the upstream version so
> that it gets byte compiled succesfully with emacs 28.
> 
> I tested that it builds and installs on a private channel local to my
> machine.
For the record, this should go below the --- line.  Use git format-
patch instead of manually annotating a git diff.

> * gnu/packages/emacs-xyz.scm
>   Bump emacs-evil to versions 1.15.0
>   So that it can be built by emacs-28
>  1 file changed, 33 insertions(+), 36 deletions(-)
YMMV but I adapted this to the actual ChangeLog format.

> diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
> index c43fa5a..9423441 100644
> --- a/gnu/packages/emacs-xyz.scm
> +++ b/gnu/packages/emacs-xyz.scm
> @@ -12073,41 +12073,44 @@ news items, openrc and runscripts.")
>  (license license:gpl2+)))
>  
>  (define-public emacs-evil
> -  (package
> -    (name "emacs-evil")
> -    (version "1.14.2")
> -    (source
> - (origin
> -   (method git-fetch)
> -   (uri (git-reference
> - (url "https://github.com/emacs-evil/evil;)
> - (commit version)))
> -   (file-name (git-file-name name version))
> -   (sha256
> -    (base32
> - "1mhm1hd6gzxc2vvihh1w1j8f30xp0ssqcxnp8fx22niz04fk5df8"
> -    (arguments
> - (list
> -  #:phases
> -  #~(modify-phases %standard-phases
> -  (add-before 'check 'fix-test-helpers
> -    (lambda _
> -  (substitute* "evil-test-helpers.el"
> -    (("\\(undo-tree-mode 1\\)") ""
> -  (add-before 'install 'make-info
> -    (lambda _
> -  (with-directory-excursion "doc/build/texinfo"
> -    (invoke "makeinfo" "--no-split"
> -    "-o" "evil.info" "evil.texi")))
> -    (build-system emacs-build-system)
> -    (native-inputs (list texinfo))
> -    (home-page "https://github.com/emacs-evil/evil;)
> -    (synopsis "Extensible Vi layer for Emacs")
> -    (description
> - "Evil is an extensible vi layer for Emacs.  It emulates the
> +  (let ((commit "008a6cdb12f15e748979a7d1c2f26c34c84dedbf")
> +    (version "1.15.0") ; not tagged upstream, but see commit
> message
> +    (revision "0"))
> +    (package
> +  (name "emacs-evil")
> +  (version (git-version version revision commit))
Made it so that version is not inadvertently let-bound.  Expanded
comment.


Cheers

bug#55495: [PATCH] gnu: emacs-haskell-mode: Fix build.

[Liliana Marie Prikler]

Am Samstag, dem 21.05.2022 um 05:59 +0900 schrieb Taiju HIGASHI:
> Hi Liliana,
> > > > +-  "Generate a regex for searching for any occurrence of the
> > > > prompt\
> > > > ++  "Generate a regex for searching for any occurrence of the
> > > > prompt
> > > LGTM, but you might want to shorten the docstring so that the
> > > first line is a synopsis.  This would make it easier for upstream
> > > to accept.
> > 
> > > > +-  "Run a loading-ish COMMAND that wants to pick up type
> > > > errors\
> > > > ++  "Run a loading-ish COMMAND that wants to pick up type
> > > > errors
> > > As above, what is "loading-ish", are "things like that" relevant,
> > > etc.
> > 
> > I decided not to make these corrections. Because I am not familiar
> > with Haskell and am just one learner, and am not good at English.
> 
> Hmmm, you were right.
> https://github.com/haskell/haskell-mode/pull/1780#issuecomment-1133107992
> 
> I will try, but I am a little apprehensive.
> Is it possible for you to continue to review it here? Or should I
> just change the fix to change the parameters to suppress the error
> and resolve this issue?
I can review it here, but my own criteria might be weaker than
upstream's.  While I'm confident in my English, I'm less well read on
the operations of haskell-mode, I must admit :)

Cheers

bug#55504: Test suite of emacs-deferred does not progress

[Liliana Marie Prikler]

Am Mittwoch, dem 25.05.2022 um 19:09 +0200 schrieb Giovanni Biscuolo:
> I'm not able to find what's the call with the wrong number of
> arguments but what about to (temporary) disable the failing tests
> like for example in 0ae9e75c31b22ea55093f4cd05954f366b1f8bcc (emacs-
> eply)?
That's unlikely to work as it'll just bring dependent packages to hang.
Anyway, I fixed the actual bug, so it's no longer necessary to debate
workarounds.

Cheers

bug#55657: libgccjit is unusable

[Liliana Marie Prikler]

Hi Guix,

with the release of Emacs 28.1, there has been some demand to enable
native-compilation.  While trying to set that up, I've come to realize
that no matter how I slice it, I can't make libgccjit usable.

My test:

$ cd /tmp
$ # fetch the "Hello World" [1] and insert it into gccjit-test.c
$ guix shell --pure gcc-toolchain@9 libgccjit@9 -- \
  gcc gccjit-test.c -o gccjit-test -lgccjit
$ ./gccjit-test
x86_64-unknown-linux-gnu-gcc-9.4.0: fatal error: cannot execute 'as':
execvp: No such file or directory
compilation terminated.

Welp, okay, so maybe testing gccjit outside of its installation does
not work.  What if we try it inside the shell (we can always propagate
libgccjit, no?)

guix shell gcc-toolchain@9 libgccjit@9 -- ./gccjit-test
ld: cannot find crtbeginS.o: Datei oder Verzeichnis nicht gefunden
ld: cannot find -lgcc
ld: cannot find -lgcc
collect2: Fehler: ld gab 1 als Ende-Status zurück
libgccjit.so: error: error invoking gcc driver
NULL result

For the record, Emacs 28 fails with a different error during
configuration, though interestingly they use a smaller program and
appear to omit -lgccjit.
./conftest: error while loading shared libraries: libgccjit.so.0:
cannot open shared object file: No such file or directory

I'm at a loss.  Is there any way to make libgccjit actually usable?

[1] https://gcc.gnu.org/onlinedocs/jit/intro/tutorial01.html

bug#55709: R texinfo documents are not showing up for me

[Liliana Marie Prikler]

Am Dienstag, dem 31.05.2022 um 10:37 +0200 schrieb Maxime Devos:
> (Is there a method to verify and repair a _single_ store item instead
> of the whole store?).
I think the syntax for that'd be ‘[sudo] guix build --repair
STORE_ITEM’.

Cheers

bug#55444: elogind startup race between shepherd and dbus-daemon

[Liliana Marie Prikler]

Hi,

Am Montag, dem 16.05.2022 um 10:26 +0200 schrieb Ludovic Courtès:
> [...]
> So it would seem that the solution to this is to prevent dbus-daemon
> from starting elogind.  We can do that by changing
> org.freedesktop.login1.service so that it has “Exec=true” instead of
> “Exec=elogind --daemon”.
> 
> “Exec=true” is a bit crude because it doesn’t guarantee that elogind
> is really started; if that isn’t good enough, we could instead wait
> for the PID file or something (as of Shepherd 0.9.0, invoking ‘herd
> start elogind’ potentially leads shepherd to start a second instance
> if the first one is still being started, so we can’t really do that).
Why does shepherd race with itself here?  That sounds like a very evil
bug.  Rather than waiting for a log file, I'd suggest writing an ad-hoc
Guile script that communicates with shepherd and blocks until shepherd
signals that elogind has been started, but this script too would have
to work around shepherd racing against itself.

> Depending on what we end up with, we might also revisit whether
> xorg-server needs to explicitly depend on elogind.
At least in the case of GDM I think it does heavily depend on elogind.
For the future, I think we also should take over dbus-daemon's
autostart in the same way systemd already has.

Cheers

bug#55618: Allow patching from mummi issues

[Liliana Marie Prikler]

Am Mittwoch, dem 25.05.2022 um 13:06 +0200 schrieb Maxime Devos:
> is text;charset=utf-8 actually valid?
Not as far as I'm aware.  The first part should be a proper MIME type,
which ought to be registered by the IANA [1].

> That page sets
> 
>  Content-Type text;charset=utf-8
> 
> which apperently Guile's HTTP parser doesn't like.
> Maybe it can be changed to text/patch (*) or text/diff (*) (or
> text/plain) instead?
> 
> (*) x- prefixes are deprecated
As fate would have it, neither text/patch nor text/diff are registered
over at the IANA [1].  As far as I'm aware, both (Linux/GNU)
applications and browsers should understand the x- notation.

Cheers


[1] https://www.iana.org/assignments/media-types/media-types.xhtml

bug#55504: Test suite of emacs-deferred does not progress

[Liliana Marie Prikler]

Am Mittwoch, dem 18.05.2022 um 13:19 -0300 schrieb Jorge P. de Morais
Neto:
> The log file [1] is empty.
> 
> 1: /var/log/guix/drvs/7r/bhrk48qvqhgix5c33yh9m3nq5crzny-emacs-
> deferred-
> 0.5.1.drv.gz
emacs-deferred also times out on CI [2].

[2] https://ci.guix.gnu.org/build/820992/log/raw

bug#55427: emacs-libgit tests are broken

[Liliana Marie Prikler]

Am Dienstag, dem 17.05.2022 um 23:14 +0800 schrieb Zhu Zihao:
> Due to the inactive status of upstream. I'm planning to remove the
> emacs-libgit input of emacs-magit.
I don't think we need measures quite as drastic as this.  A hotfix for
emacs-libgit was pushed to master, which causes builds to succeed again
(see e.g. [1]).  Since we're talking about free software here, it would
be more constructive to work on a proper patch – if upstream won't take
it, one can always fork it.

> magit will still work with the git executable if there's no
> emacs-libgit.
> 
> Any thoughts?
I don't see any benefits in this approach, do you?

[1] http://ci.guix.gnu.org/build/859957/details

bug#55449: recutils cross-compilation "fix" breaks bash builtins

[Liliana Marie Prikler]

Hi Guix,

The fix in commit 20fbd870938e239c038d8524a56729f123f19f80, which lets
recutils cross-compile unfortunately omits support for the bash
builtins in all build modes, as recutils can't actually detect bash
headers there.

Unfortunately, recutils' configure.ac silently swallows this error in
the following check.
  AM_CONDITIONAL([BASH_BUILTINS],
 [test "x$bash_headers_available" = "xyes" && 
  test "x$bash_builtins_enabled" = "xyes"])
I only noticed, because I symlink the builtins to lib/bash, where
they're actually needed, which causes runpath validation to fail
because the symlink points to a file that doesn't exist.  I fixed this
locally, but still wanted y'all to know.

Is there a way we can support bash headers in cross-compilation
contexts?  I don't think having bash:include as a native input is even
helpful here, is it?  WDYT?

bug#55495: [PATCH] gnu: emacs-haskell-mode: Fix build.

[Liliana Marie Prikler]

Hi,

Am Mittwoch, dem 18.05.2022 um 23:31 +0900 schrieb Taiju HIGASHI:
> * gnu/packages/emacs-xyz.scm (emacs-haskell-mode): Fix build.
> ---
>  gnu/packages/emacs-xyz.scm    |   9 +-
>  .../emacs-haskell-mode-fix-tests.patch    | 282
> ++
>  2 files changed, 289 insertions(+), 2 deletions(-)
>  create mode 100644 gnu/packages/patches/emacs-haskell-mode-fix-
> tests.patch
> 
> diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
> index 529e9329d6..9d9669f383 100644
> --- a/gnu/packages/emacs-xyz.scm
> +++ b/gnu/packages/emacs-xyz.scm
> @@ -1553,11 +1553,16 @@ (define-public emacs-haskell-mode
>   (commit version)))
>     (file-name (git-file-name name version))
>     (sha256
> -    (base32
> "0zxbacqzr84krmhqpvzndnvlcjh1gs1x20ys0dykgd7chyhci5j5"
> +    (base32
> "0zxbacqzr84krmhqpvzndnvlcjh1gs1x20ys0dykgd7chyhci5j5"))
> +    ;; Submitted for inclusion upstream.
> +    ;; Not identical patches due to different target versions.
> +    ;; (see: https://github.com/haskell/haskell-mode/pull/1780)
> +   (patches
> +    (search-patches "emacs-haskell-mode-fix-tests.patch"
>  (propagated-inputs
>   (list emacs-dash))
>  (native-inputs
> - (list emacs-minimal emacs-el-search emacs-stream texinfo))
> + (list emacs-minimal emacs-el-search emacs-stream texinfo git))
There are other ways of suppressing errors caused by git.  One of them
would be to set vc-handled-backends to nil for the tests.

> +-  "Classify the current line into 'section-header 'subsection-
> header 'section-data 'comment and 'empty '"
> ++  "Classify the current line into 'section-header 'subsection-
> header
> ++'section-data 'comment and 'empty '"
LGTM.
> +-  "Enumerate .cabal targets. PROCESS-TYPE determines the format of
> the returned target."
> ++  "Enumerate .cabal targets. PROCESS-TYPE determines the format of
> the
> ++returned target."
LGTM.

> +-Module names in exposed-modules and other-modules are expanded by
> replacing each dot (.) in the module name with a forward slash (/)
> and appending \".hs\"
> ++Module names in exposed-modules and other-modules are expanded by
> ++replacing each dot (.) in the module name with a forward slash (/)
> and
> ++appending \".hs\"
LGTM.

> +-  "Default build command to use for `haskell-cabal-build' when a
> cabal file is detected.
> ++  "Default build command to use for `haskell-cabal-build' when a
> cabal
> ++file is detected.
LGTM.

> +-  "Alternative build command to use when `haskell-cabal-build' is
> called with a negative prefix argument.
> ++  "Alternative build command to use when `haskell-cabal-build' is
> ++called with a negative prefix argument.
LGTM.

> +-  "Default build command to use for `haskell-stack-build' when a
> stack file is detected.
> ++  "Default build command to use for `haskell-stack-build' when a
> stack
> ++file is detected.x
Additional x.

> +-  "Alternative build command to use when `haskell-stack-build' is
> called with a negative prefix argument.
> ++  "Alternative build command to use when `haskell-stack-build' is
> ++called with a negative prefix argument.
LGTM.

> +-  "Default build command to use for `haskell-cabal-build' when no
> cabal or stack file is detected.
> ++  "Default build command to use for `haskell-cabal-build' when no
> ++cabal or stack file is detected.
LGTM.

> +-  "Controls whether to use cabal, stack, or ghc to compile.
> +-   Auto (the default) means infer from the presence of a cabal or
> stack spec file,
> +-   following same rules as haskell-process-type."
> ++  "Controls whether to use cabal, stack, or ghc to compile.  Auto
> (the
> ++   default) means infer from the presence of a cabal or stack spec
> ++   file, following same rules as haskell-process-type."
LGTM.

> +-  (let (htype dir)  
> ++  (let (htype dir)
Indentation change?  Suppress those, you want to make the diff as small
as possible.

> +-  "The way to run cabal comands. It takes two arguments -- the
> directory and the command.
> ++  "The way to run cabal comands. It takes two arguments -- the
> ++directory and the command.
LGTM.

> +-  "Suggest adding OverloadedStrings pragma to file when getting
> type mismatches with [Char]."
> ++  "Suggest adding OverloadedStrings pragma to file when getting
> type
> ++mismatches with [Char]."
LGTM.

> +-  "Looks for cabal and stack spec files. 
> +-   When found, returns a pair (TAG . DIR) 
> +-   where TAG is 'cabal-project, 'cabal-sandbox. 'cabal, or 'stack; 
> ++  "Looks for cabal and stack spec files.
> ++   When found, returns a pair (TAG . DIR)
> ++   where TAG is 'cabal-project, 'cabal-sandbox. 'cabal, or 'stack;
LGTM.

> +-  "Puts point to the next following symbol, or to end if there are
> no more symbols in the sexp."
> ++  "Puts point to the next following symbol, or to end if there are
> no
> ++more symbols in the sexp."
LGTM.

> +-  "Generate a regex for searching for any 

bug#56376: emacs-guix missing from package-activated-list

[Liliana Marie Prikler]

Am Sonntag, dem 03.07.2022 um 21:33 -0400 schrieb Philip McGrath:
> Hi,
> 
> I've been looking into managing my Emacs packages with Guix. I found
> that the `emacs-guix` package doesn't seem to show up in the
> `package-activated-list`, even though its dependencies do, which
> seems like a bug.
This might be related to the fact that Emacs doesn't see guix as a
package.  I think the recipe might be missing the -pkg.el
autogeneration we added to emacs-build-system.

bug#56383: Neither Gnome nor udisksctl can mount an nfs filesystem

[Liliana Marie Prikler]

Am Montag, dem 04.07.2022 um 16:03 +0200 schrieb Alexandre Hannud Abdo:
> Ni! Connecting an external USB hard drive with an NTFS partition
> fails to mount it on both Gnome (Nautilus) and manually through
> udisksctl.
Note that NTFS != NFS.  But to solve your problem, simply add ntfs-3g
to your operating-system's packages field.

bug#56289: "guix shell -f guix2.scm" fails always

[Liliana Marie Prikler]

Am Mittwoch, dem 29.06.2022 um 11:10 +0200 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op wo 29-06-2022 om 08:19 [+0200]:
> > > Looks like "-f" is ignored entirely?
> > Have you tried specifying a file that actually contains a package
> > (not a manifest)?
> 
> None of the examples contain a manifest, oops-guix.scm actually
> contains a list of packages as mentioned previously (*).
My bad, I read that as specifications->manifest.  Note that for
specifications->package, you could simply specify hello on the command
line.

Having tested your file now, I can say that guix shell builds hello as
expected, whereas with specifications->manifest, it produces a lovely
backtrace (which is more or less what one ought to expect).

> And the exact same thing happens if a package is used instead of a
> list of packages.
One thing to check here is whether a cache might be interfering.  I
think it is an already known bug, that the file itself is not key in
the cache, which you can work around by specifying --rebuild-cache.

Cheers

bug#56289: "guix shell -f guix2.scm" fails always

[Liliana Marie Prikler]

Am Mittwoch, dem 29.06.2022 um 11:40 +0200 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op wo 29-06-2022 om 11:22 [+0200]:
> > > And the exact same thing happens if a package is used instead of
> > > a list of packages.
> > One thing to check here is whether a cache might be interfering.  I
> > think it is an already known bug, that the file itself is not key
> > in the cache, which you can work around by specifying --rebuild-
> > cache.
> 
> Whatever non-existent file name I use, I don't get an error message
> but the warning ‘guix shell: warning: no packages specified; creating
> an empty environment’, so this doesn't look like a cache issue to me.
That is exactly the cache issue, though.  Once ‘guix shell -f’
“succeeds” (even with an empty environment), subsequent invocations
lacking ‘--rebuild-cache’ ignore the file completely and serve from
cache.


Cheers

bug#56297: Guix style imperfections

[Liliana Marie Prikler]

Am Mittwoch, dem 29.06.2022 um 11:33 +0200 schrieb Maxime Devos:
> Hi,
> 
> "guix style" occasionally makes some decision that seem a bit
> questionable to me.  More concretely, copy the definition of guile-
> next, put it in a .scm and rename it, and run
> "guix style -L . guile-next-styleme".  I get:
Before commenting on the individual points, I do think in general guix
style needs to have a "lax" mode and a "strict" mode where the latter
is enabled via "--strict" and keeps certain snippets as-is.  All
elements that save vertical space at the cost of horizontal space
should be disabled in strict mode, whereas they might be acceptable in
lax mode.

> > (define-module (test))
> > (use-modules (guix packages) (guix git-download) (gnu packages
> > autotools) (gnu packages guile) (guix utils)
> > (define-public guile-next
> >  (let ((version "3.0.7") (revision "0")
> >    (commit "d70c1dbebf9ac0fd45af4578c23983ec4a7da535"))
> 
> Conventionally 'revision' is put on another line -- for these kind of
> let bindings, (maybe all?), I would recommend to put all of them on
> separate lines.
Agree.

> >    (package
> >  (inherit guile-3.0)
> >  (name "guile-next-styleme")
> >  (version (git-version version revision commit))
> >  (source [snip, LGTM])
> >  (arguments
> >   (substitute-keyword-arguments (package-arguments guile-3.0)
> >     ((#:phases phases
> >   '%standard-phases) `(modify-phases ,phases
> 
> Put %standard-phases on the same line ad #:phases phases and `(modify-
> phases ,phases on a new line
Agree.  What's even the point the current style tries to make?

> >     (add-before 'check 'skip-failing-
> > tests
> >   (lambda _
> >     (substitute* "test-
> > suite/standalone/test-out-of-memory"
> >   (("!#") "!#
> > 
> > (exit 77)
> > "))
> 
> I'd prefer the original "!#\n\n(exit 77)\n" here, but I don't know if
> that's something 'Guix style' could feasibly do (there might be
> situations where a newline might be appropriate, how could "guix style"
> which is the case?).
I'd prefer if strict mode typed those out, but we can keep strings "as-
is" in lax mode, supposing they don't grow beyond the horizontal limit.

> >     (delete-file
> >  "test-suite/tests/version.test")
> > #t))
> 
> (Would be nice if "guix style" could be taught to remove those #t, but
> that seems more a feature limitation than a bug to me.)
It can still do better by not contracting them imho.

> >  (native-inputs (modify-inputs (package-native-inputs guile-3.0)
> >   (prepend autoconf
> >    automake
> >    libtool
> >    flex
> >    gnu-gettext
> >    texinfo
> >    gperf)))
> 
> I'd consider it tidier to put (modify-inputs ...) on a new line
Here, it depends.  I think I'd write this as 

 (native-inputs 
   (modify-inputs (package-native-inputs guile-3.0)
 (prepend autoconf automake libtool
  flex gperf
  gnu-gettext texinfo)))

> >     (synopsis "Development version of GNU Guile"
> 
> Question: do people agree with these style choices?
I think some people might actually be okay with a few or even all of
them (juding by how many submit collapsed lets), but I'd like to point
out that they break with Lisp coding guidelines for no good reason.

Regarding the optimization of vertical space, I do think that guix
lacks semantic information to make meaningful choices and thus ought to
either step back when an "informed" user invokes the tool or strictly
take the "least optimal, but correct" approach in strict mode.

Cheers

bug#56289: "guix shell -f guix2.scm" fails always

[Liliana Marie Prikler]

Am Dienstag, dem 28.06.2022 um 22:47 +0200 schrieb Maxime Devos:
> Put the folllowing in "oops-guix.scm":
> 
> (use-modules (gnu packages))
> (specifications->packages '("hello"))
> 
> then do: "guix shell -f oops-guix.scm" to make an environment
> with "hello".  I get:
> 
> > guix shell: warning: no packages specified; creating an empty
> > environment
> $ which hello
> > /home/regulator/.guix-profile/bin/hello # <-- not from the new
> > environment!
> 
> Or even simpler: do "guix shell -f non-existing-file.scm":
> > guix shell: warning: no packages specified; creating an empty
> > environment
> 
> Looks like "-f" is ignored entirely?
Have you tried specifying a file that actually contains a package (not
a manifest)?  That being said, the error reporting could be better :)