bug#73681: Maybe partly undo the patch on Elisp comp-el-to-eln-filename

[Liliana Marie Prikler]

Am Mittwoch, dem 09.10.2024 um 17:15 +0200 schrieb Martin Edström:
> Hi, thanks for info! This email will be a bit long because I'm quite
> confused and thinking aloud, so no need to reply to all of it.  But I
> appreciate any attempt to shed clarity!
> 
> 
> On Tue, 08 Oct 2024 19:33:06 +0200, Liliana Marie Prikler
>  wrote:
> 
> > > It comes as part of the package. I don't want to assume that it
> > > has been compiled, since it's fairly performance-sensitive.
> > > That's why I'll either use a previously existing compiled object
> > > or make a new one.
> > Could you leave that decision to the user?
> 
> I'm considering it, but ran into essentially the same problem.  I
> need a way to tell which one was loaded, of the .elc, .eln or .el.
> 
> This takes the thread a bit off-topic but ... Do you know how?
> 
> Currently I'm leaning towards an algorithm like
> 
> #+begin_src elisp
> (defun guess-loaded-lib (basename)
>   (let* ((el (locate-library (concat basename ".el")))
>  (elc (locate-library (concat basename ".elc")))
>  (eln (comp-el-to-eln-filename el)))
>     (if load-prefer-newer
>     (car (sort (delq 'nil (list el elc eln)) #'file-newer-than-
> file-p))
>   (if (and (file-newer-than-file-p elc el)
>    (file-newer-than-file-p eln el))
>   ;; If elc is newer than el, assume it was compiled from el,
> and
>   ;; therefore is safe to replace with eln
>   eln
>     elc
> #+end_src
> 
> I don't know how to "leave it to the user" any better than that.  
The user can just use the output of the help function, it will tell
them whether a function is natively-compiled, byte-compiled, or just
interpreted.  Emacs 30 even gives you `native-comp-function-p'.  See
`gnu/packages/aux-files/emacs/comp-integrity[-next].el' for how we
assert that our Emacs loads natively-compiled libraries.

> On Guix, even in the future when we re-enable JIT compilation, this
> algorithm could never return an .eln, since =file-newer-than-file-p=
> returns nil when both paths have identical timestamps from 1970.
> 
> I found a pretty neat built-in: 
> 
>  (symbol-file 'SOME-FUNCTION-FROM-THE-LIB nil t)
> 
> but its internals also use =file-newer-than-file-p= and =comp-el-to-
> eln-rel-filename=, so not sure it is any more reliable than what I
> have above.
I'm not sure these things work the way you think.  IIUC, `load-prefer-
newer' should guard against the case where the .el is newer than the
.el[cn], not the other way round, so it should still load the
compiled/native-compiled variant if they have the same stamp.

> > There is a separate load path for natively compiled files, called
> > `native-comp-eln-load-path'.
> 
> Good to know! I don't know how Emacs consults it though.  I can't
> e.g. locate an .eln of a given library by calling something like
> 
> #+begin_src elisp
> (locate-eln-file "org-node-parser")
> #+end_src
> 
> so it seems I must simply do:
> 
> #+begin_src elisp
> (let ((el (locate-library "org-node-parser.el")))
>   (when el
>     (locate-eln-file (comp-el-to-eln-rel-filename el
> #+end_src
> 
> which is functionally equivalent to:
> 
> #+begin_src elisp
> (let ((eln (comp-el-to-eln-filename (locate-library "org-node-
> parser.el"
>   (when (file-exists-p eln)
>     eln))
> #+end_src
I mean, the C code is there to read (along with the patch we've made),
but I can't fault you for not going that deep.  

> > > I infer that Emacs starts with finding a library in load-path,
> > > then converts the path with `comp-el-to-eln-filename`, and checks
> > > if that file exists, then loads it.
> > > 
> > > And crucially, it is not just about the filepath, the function
> > > hashes the file contents as well. That ensures that the output
> > > path is always different if the source file changes.
> > I think relying on such implementation details is perhaps permitted
> > if it's inside of Emacs itself, but even then it clashes with our
> > expectation that Emacs be graftable.
> 
> OK, so if passing "file.el" to =comp-el-to-eln-filename= produces a
> path with a hash of the content, like:
> 
>     .../eln-cache/29.4-HASH/module/file-HASH-BASED-ON-CONTENT.eln
> 
> this would make Emacs non-graftable.  Because the hash would change
> after file.el is upgraded.  I suppose that makes sense, thanks!
> 
> Maybe, as a hack, the graft process could symlink the pre-graft
> filename to the post-graft filename...

bug#73681: Maybe partly undo the patch on Elisp comp-el-to-eln-filename

[Liliana Marie Prikler]

Am Dienstag, dem 08.10.2024 um 12:41 +0200 schrieb Martin Edström:
> It comes as part of the package. I don't want to assume that it has
> been compiled, since it's fairly performance-sensitive. That's why
> I'll either use a previously existing compiled object or make a new
> one.
Could you leave that decision to the user?

> […]
> 
> So let's ignore my package, it is just an example of a downstream use
> of `comp-el-to-eln-filename` that relied on its hashing
> functionality.
> 
> Let's just discuss that function.
> 
> I have to point out that the emacs `load-path` does not include any
> native paths.  When I inspect the value on my non-Guix emacs, I see
> no references to .../eln-cache/..., just references to directories
> where there are .elc and .el files.
There is a separate load path for natively compiled files, called
`native-comp-eln-load-path'.

> I infer that Emacs starts with finding a library in load-path, then
> converts the path with `comp-el-to-eln-filename`, and checks if that
> file exists, then loads it.
> 
> And crucially, it is not just about the filepath, the function hashes
> the file contents as well. That ensures that the output path is
> always different if the source file changes.
I think relying on such implementation details is perhaps permitted if
it's inside of Emacs itself, but even then it clashes with our
expectation that Emacs be graftable.

> Since Guix has a patch that removes this effect, it seems like a
> package could be upgraded many, many times, without the .eln path
> ever changing, and so the user would stay on that very outdated file.
> 
> Is that not a regression/bug?
The way our load paths are set up, it is actually the opposite (which
still is a bug, just not the one reported).  While `guix upgrade` or a
command to the similar effect will swap out the .eln under the hood,
the `.el` and `.elc` files stay stable – remember what I wrote in the
previous message about that having caused issues with byte compilation?

We also get a similar-looking bug if our packages aren't actually
native-compiled, but Emacs itself vendors them.  That is resolved by
dropping those .eln-files from the Emacs package.

Cheers

bug#73681: Maybe partly undo the patch on Elisp comp-el-to-eln-filename

[Liliana Marie Prikler]

Am Montag, dem 07.10.2024 um 22:46 +0200 schrieb Martin Edström:
> In my package, the use case is instead that it starts sub-processes,
> each of which should load a file "org-node-parser.eln".  I could ahve
> made them just load the output of (locate-library "org-node-parser"),
> but for unrelated reasons, that seems it would only ever locate an
> .elc and not an .eln.
Could you keep track of modifications to org-node-parser and recompile
that on change?  Or is it part of your package already – if the latter,
then we should already have it compiled as a package.

> So I need to use `comp-el-to-eln-filename` to find the up-to-date
> .eln (or force it to be compiled).  Regardless of whether or not the
> rest of the package has already been native-compiled.
> 
> The worst-case scenario is using package version 1.4.1 in the main
> Emacs process, but 1.4.0 of org-node-parser.eln in the subprocesses. 
> That leads to unintended bugs.
> 
> I suppose the other way around could also happen - using package
> version 1.4.0 but 1.4.1 in the subprocesses - but that'll be my own
> mess to figure out :)
I think it's your own mess either way – can't you downgrade to a model
where you just ask for "org-node-parser" to be loaded, regardless of
compilation?  Then, you wouldn't have to native-compile it. 

> > We write store paths to a subdirs.el – unless specifically prompted
> > to reload that, Emacs will keep using old libraries.  This is by
> > design, so that updating Emacs does not cause any issues with
> > (byte) compiled files.
> 
> Let me know if I understand this correctly: updating a package
> compiles it at the same time, so we can have store paths like
> 
> /gnu/store/package-1.4.0/...{.elc,.el,.eln}
> /gnu/store/package-1.4.1/...{.elc,.el,.eln}
> 
> which sounds like it will be all consistent.  An .eln in the second
> directory would never secretly be 1.4.0, for example.
> 
> But since you said we disabled the JIT compilation, and store dirs
> are read-only, where do the .eln actually end up, after the user
> starts Emacs and it does its async-native-compile thing?
> 
> (or does it not do any JIT compilation at all?)
We don't do JIT, but even if we did, we should find the one in the
store (and the correct one, as per Emacs load paths).

> I don't have a Guix machine at the moment, but is it a deterministic
> path like ~/.emacs.d/eln-cache/29.4-HASH/package-HASH.eln ?  The user
> in my GitHub issue gets no such path from running `comp-el-to-eln-
> filename`, but maybe they're on an old Guix Emacs.
It's `~/.emacs.d/eln-cache/29.4-HASH/some/module.eln`, with some/module
being the module that you'd load.

Cheers

bug#73681: Maybe partly undo the patch on Elisp comp-el-to-eln-filename

[Liliana Marie Prikler]

Am Montag, dem 07.10.2024 um 16:56 +0200 schrieb Martin Edström:
> Hi, I suggest to maybe amend one of the things done by this
> patchset:  https://issues.guix.gnu.org/67260
> 
> It undoes the hashing effect of the Elisp function `comp-el-to-eln-
> filename`, and that seems likely to cause issues downstream, for
> example in my Emacs package:
> https://github.com/meedstrom/org-node/issues/60.
> 
> To summarize: that function is supposed to generate a filename with a
> hash based not only the filename but the contents of the file.  While
> it makes sense in Guix to ignore the contribution of the filename, I
> believe it should still output a new filename when the contents
> change.
There are opposite goals to "make sure that the file hasn't been
tampered with" (upstream) and "to keep files patchable" (Guix).  I
don't think we can easily satisfy both.  Perhaps we could use the
original store path as some kind of key to match the files (since we
compile them in-store IIRC), but that wouldn't work for the "let's
compile our init.el" use case.

As a matter of fact, we've disabled JIT compilation for the very reason
that stuff can break ;)

> Otherwise there seems to be no way for a downstream package to ensure
> that it is using an up-to-date .eln variant of an .el file.
What about aggressive-recompilation-on-write?  

> I may have missed something though.  Can someone in the know tell me
> what happens if you have not updated Emacs (which if I understand
> correctly, means ELN-DIR does not change), but you do update an Elisp
> package, whether through Guix or through Emacs' own package managers.
> Will Emacs then possibly load an old .eln?  
We write store paths to a subdirs.el – unless specifically prompted to
reload that, Emacs will keep using old libraries.  This is by design,
so that updating Emacs does not cause any issues with (byte) compiled
files.

> I do not believe that user options like `load-prefer-newer` would
> affect it. It would just rely on running the aforementioned function
> and counting on it to output an .eln filename that does not exist if
> the source is newer.
Since all timestamps point to 1970, you are right, `load-prefer-newer'
does nothing.

Cheers

bug#73381: Wayland leaves core dump in $HOME

[Liliana Marie Prikler]

Hi Guix,

I've been having a weird experience for some while now.  Whenever I
reboot my system, I find a `core' file in my $HOME, which after some
while I found out to belong to XWayland 


$ file ~/core 
~/core: ELF 64-bit LSB core file, x86-64, version 1 (SYSV), SVR4-style, 
  from 
'/gnu/store/9hvjn76prgj2z4014q5b4z8l7z83yqsc-xorg-server-xwayland-23.2.5/bin/Xwa',
 
  real uid: 1000, effective uid: 1000, real gid: 998, effective gid: 998, 
  execfn: 
'/gnu/store/9hvjn76prgj2z4014q5b4z8l7z83yqsc-xorg-server-xwayland-23.2.5/bin/Xwayland',
 
  platform: 'x86_64'

Anyone have an idea as to what is happening here?  (On that note, which
team handles Mesa stuff?)

Cheers

bug#72333: Magit/Transient error message

[Liliana Marie Prikler]

Am Samstag, dem 14.09.2024 um 17:53 + schrieb Rutherther:
> 
> From Liliana dmarie Prikler:
> > It is a bug unique to our handling in Guix – upstream uses hashes
> > to guard against it, but those break grafts.
> 
> Do we need to remove the whole hash? The path hash would definitely
> break grafts, but why should the content hash break grafts? Having
> the content hash would also solve this issue.
> 
> Here is the upstream explanation for the hash
> https://git.savannah.gnu.org/cgit/emacs.git/tree/src/comp.c?h=194a8f5c1406dd7e762376bdfde78d1b7d01b6b1#n4433
> having two parts, path and content hash.
Because the content hash also refers to stuff that we're grafting, e.g.
program names that get compiled to store paths.  It's sadly not that
easy.

Cheers

bug#73233: [gnome-team] qtbase fails to build

[Liliana Marie Prikler]

Locally (with glib 2.80):

--8<---cut here---start->8---
* Start testing of tst_QBuffer *
Config: Using QtTest library 6.6.3, Qt 6.6.3 (x86_64-little_endian-lp64 shared 
(dynamic) release build; by GCC 11.4.0), unknown unknown
PASS   : tst_QBuffer::initTestCase()
PASS   : tst_QBuffer::open()
PASS   : tst_QBuffer::openWriteOnlyDoesNotTruncate()
PASS   : tst_QBuffer::getSetCheck()
QWARN  : tst_QBuffer::readBlock() QIODevice::read (QBuffer): device not open
PASS   : tst_QBuffer::readBlock()
PASS   : tst_QBuffer::readBlockPastEnd()
PASS   : tst_QBuffer::writeBlock(small_bytearray)
PASS   : tst_QBuffer::writeBlock(large_bytearray)
PASS   : tst_QBuffer::seek()
SKIP   : tst_QBuffer::invalidSeeks() This is a 32-bit-only test.
   Loc: 
[/tmp/guix-build-qtbase-6.6.3.drv-0/qtbase-everywhere-src-6.6.3/tests/auto/corelib/io/qbuffer/tst_qbuffer.cpp(298)]
PASS   : tst_QBuffer::seekTest(small_bytearray)
PASS   : tst_QBuffer::seekTest(large_bytearray)
PASS   : tst_QBuffer::read_rawdata()
PASS   : tst_QBuffer::isSequential()
PASS   : tst_QBuffer::signalTest(empty)
PASS   : tst_QBuffer::signalTest(size 1)
PASS   : tst_QBuffer::signalTest(size 2)
PASS   : tst_QBuffer::signalTest(size 100)
PASS   : tst_QBuffer::isClosedAfterClose()
PASS   : tst_QBuffer::readLine(1)
PASS   : tst_QBuffer::readLine(2)
PASS   : tst_QBuffer::readLine(3)
PASS   : tst_QBuffer::readLine(4)
PASS   : tst_QBuffer::canReadLine(1)
PASS   : tst_QBuffer::canReadLine(2)
PASS   : tst_QBuffer::canReadLine(3)
PASS   : tst_QBuffer::canReadLine(4)
PASS   : tst_QBuffer::atEnd()
PASS   : tst_QBuffer::readLineBoundaries()
PASS   : tst_QBuffer::getAndUngetChar()
PASS   : tst_QBuffer::writeAfterQByteArrayResize()
QDEBUG : tst_QBuffer::writeOfMoreThan2GiB() created dataset in 3578 ms
QDEBUG : tst_QBuffer::writeOfMoreThan2GiB() performed write in 77428 ms

 writeOfMoreThan2GiB function time: 30ms, total time: 38ms
QFATAL : tst_QBuffer::writeOfMoreThan2GiB() Test function timed out
FAIL!  : tst_QBuffer::writeOfMoreThan2GiB() Received a fatal error.
Totals: 30 passed, 1 failed, 1 skipped, 0 blacklisted, 300020ms
* Finished testing of tst_QBuffer *
Received signal 6 (SIGABRT)
 writeOfMoreThan2GiB function time: 300012ms, total time: 300020ms
CMake Error at tst_qbufferWrapperRelWithDebInfo.cmake:18 (message):
  
  
/tmp/guix-build-qtbase-6.6.3.drv-0/build/tests/auto/corelib/io/qbuffer/tst_qbuffer
  execution failed with exit code Subprocess aborted.
--8<---cut here---end--->8---

On CI [1]:

--8<---cut here---start->8---
The following tests FAILED:
 74 - tst_qsharedmemory (Failed)

QWARN  : tst_QSharedMemory::useTooMuchMemory(SystemV-Q) QStandardPaths: 
XDG_RUNTIME_DIR not set, defaulting to 
'/tmp/guix-build-qtbase-6.6.3.drv-0/runtime-nixbld'
[…
QWARN  : tst_QSharedMemory::useTooMuchMemory(SystemV-Q) QStandardPaths: 
XDG_RUNTIME_DIR not set, defaulting to 
'/tmp/guix-build-qtbase-6.6.3.drv-0/runtime-nixbld'
WARNING: tst_QSharedMemory::useTooMuchMemory(SystemV-Q) Maximum amount of 
warnings exceeded. Use -maxwarnings to override.
FAIL!  : tst_QSharedMemory::useTooMuchMemory(SystemV-Q) 'sm->error() == 
QSharedMemory::OutOfResources || sm->error() == QSharedMemory::LockError' 
returned FALSE. ()
   Loc: 
[/tmp/guix-build-qtbase-6.6.3.drv-0/qtbase-everywhere-src-6.6.3/tests/auto/corelib/ipc/qsharedmemory/tst_qsharedmemory.cpp(612)]
FAIL!  : tst_QSharedMemory::useTooMuchMemory(SystemV-T) 'sm->error() == 
QSharedMemory::OutOfResources || sm->error() == QSharedMemory::LockError' 
returned FALSE. ()
   Loc: 
[/tmp/guix-build-qtbase-6.6.3.drv-0/qtbase-everywhere-src-6.6.3/tests/auto/corelib/ipc/qsharedmemory/tst_qsharedmemory.cpp(612)]
SKIP   : tst_QSharedMemory::attachTooMuch(POSIX) disabled
   Loc: 
[/tmp/guix-build-qtbase-6.6.3.drv-0/qtbase-everywhere-src-6.6.3/tests/auto/corelib/ipc/qsharedmemory/tst_qsharedmemory.cpp(630)]
SKIP   : tst_QSharedMemory::attachTooMuch(SystemV-Q) disabled
   Loc: 
[/tmp/guix-build-qtbase-6.6.3.drv-0/qtbase-everywhere-src-6.6.3/tests/auto/corelib/ipc/qsharedmemory/tst_qsharedmemory.cpp(630)]
SKIP   : tst_QSharedMemory::attachTooMuch(SystemV-T) disabled
   Loc: 
[/tmp/guix-build-qtbase-6.6.3.drv-0/qtbase-everywhere-src-6.6.3/tests/auto/corelib/ipc/qsharedmemory/tst_qsharedmemory.cpp(630)]
--8<---cut here---end--->8---

[1] https://ci.guix.gnu.org/build/5695717/log/raw

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

[Liliana Marie Prikler]

Am Mittwoch, dem 11.09.2024 um 09:29 +0200 schrieb Remco van 't Veer:
> Hi Maxim,
> 
> 2024/09/11, Maxim Cournoyer:
> 
> > It's nice that this fixes the package build, but propagating
> > various version of Python libraries a road that to leads to
> > problems.  Currently it's important that propagated things are all
> > compatible together.
> > 
> > I'd suggest trying to update python-gst to see if it works with the
> > newer python-pygobject instead.
> 
> It does because this is the newer version.  I proposed to do a graft
> or
> just go for the upgrade[1] but python-pygobject has a lot of
> dependent
> packages.
> 
>   $ guix refresh --list-dependent python-pygobject
>   Building the following 2015 packages would ensure 4466 dependent
> packages are rebuilt: ..
> 
> Should I provide a patch to just go for the newer version?
How many dependents does python-gst have?
Can we patch it to work with the current version?
If not, can sneak in python-gobject-3.48 as a regular input instead of
propagating it?

Perhaps we could even delay this for gnome-team, where massive rebuilds
are less of an issue.

Cheers

bug#72976: [PATCH] gnu: lxc: Update to 6.0.1

[Liliana Marie Prikler]

Am Samstag, dem 07.09.2024 um 18:57 +0200 schrieb Jakob Kirsch:
> * gnu/packages/virtualization.scm (lxc): Update to 6.0.1
Note: The ChangeLog is still incomplete, it's missing the change to
meson-build-system, etc, discussed below.  I'll indent the parts you
should add with spaces.

> Change-Id: I089d53611a996e44cb9a92986c2b8de9cb69634f
> ---
>  gnu/packages/virtualization.scm | 30 +-
>  1 file changed, 13 insertions(+), 17 deletions(-)
> 
> diff --git a/gnu/packages/virtualization.scm
> b/gnu/packages/virtualization.scm
> index b076d49985..a5790482a2 100644
> --- a/gnu/packages/virtualization.scm
> +++ b/gnu/packages/virtualization.scm
> @@ -36,6 +36,7 @@
>  ;;; Copyright © 2024 Raven Hallsby 
>  ;;; Copyright © 2024 jgart 
>  ;;; Copyright © 2024 Ashish SHUKLA 
> +;;; Copyright © 2024 Jakob Kirsch 
>  ;;;
>  ;;; This file is part of GNU Guix.
>  ;;;
> @@ -1350,7 +1351,7 @@ (define-public libosinfo
>  (define-public lxc
>    (package
>  (name "lxc")
> -    (version "4.0.12")
> +    (version "6.0.1")
>  (source (origin
>    (method url-fetch)
>    (uri (string-append
> @@ -1358,30 +1359,25 @@ (define-public lxc
>  version ".tar.gz"))
>    (sha256
>     (base32
> -   
> "1vyk2j5w9gfyh23w3ar09cycyws16mxh3clbb33yhqzwcs1jy96v"
> -    (build-system gnu-build-system)
> +   
> "1q3p3zzm338pmc97z6ly8cjginkyljxqbk1c37l2xa46vfy8zcyc"
> +    (build-system meson-build-system)
  [build-system]: Change to meson-build-system.

>  (native-inputs
>   (list pkg-config docbook2x))
>  (inputs
> - (list gnutls libcap libseccomp libselinux))
> + (list gnutls libcap libseccomp libselinux dbus))
  [inputs]: Add dbus.

>  (arguments
>   (list #:configure-flags
> -   #~(list (string-append "--docdir=" #$output "/share/doc/"
> +   #~(list (string-append "-Ddoc-path=" #$output
> "/share/doc/"
>    #$name "-" #$version)
> -   "--sysconfdir=/etc"
> -   "--localstatedir=/var")
> +   "-Ddistrosysconfdir=/etc"
> +   "-Dinit-script=sysvinit"
> +   "-Dinstall-state-dirs=false"
> +   "-Dinstall-init-files=false"
> +   "-Dspecfile=false"
> +   "-Db_lto=false")
  [arguments]: Replace "--docdir=..." with "-Ddoc-path=..."
  Replace "--sysconfdir=/etc" with "-Ddistrosysconfdir=/etc".
  Remove "--localstatedir=/var"
  Add [all the things that are added].
>     #:phases
>     #~(modify-phases %standard-phases
> -   (replace 'install
> - (lambda _
> -   (invoke "make" "install"
> -   (string-append "bashcompdir=" #$output
> -  "/etc/bash_completion.d")
> -   ;; Don't install files into /var and
> /etc.
> -   "LXCPATH=/tmp/var/lib/lxc"
> -   "localstatedir=/tmp/var"
> -   "sysconfdir=/tmp/etc"
> -   "sysconfigdir=/tmp/etc/default"))
> +   (delete 'shrink-runpath
  <#:phases>: No longer replace 'install.
  Delete 'shrink-runpath.
The latter isn't something you should do willy-nilly btw.  Is there a
good reason to do so?  It should be commented in the code.
>  (synopsis "Linux container tools")
>  (home-page "https://linuxcontainers.org/";)
>  (description

Cheers

bug#72333: [PATCH] gnu: emacs-minimal: Do not native-compile lisp/transient.el.

[Liliana Marie Prikler]

Am Dienstag, dem 03.09.2024 um 18:49 +0200 schrieb Liliana Marie
Prikler:
> Am Dienstag, dem 03.09.2024 um 16:57 +0200 schrieb Simon Tournier:
> > Fixes <https://issues.guix.gnu.org/72333>.
> > Reported by daniel szmulewicz .
> I think those belong in the trailer, but I can fix that myself.
Pushed with the mentioned fixes.

> > […]
> Should we do this in a snippet instead?  Otherwise LGTM.
I left it as a phase, so that Emacsen with modified source also
benefit.

Cheers

bug#72333: [PATCH] gnu: emacs-minimal: Do not native-compile lisp/transient.el.

[Liliana Marie Prikler]

Am Dienstag, dem 03.09.2024 um 16:57 +0200 schrieb Simon Tournier:
> Fixes .
> Reported by daniel szmulewicz .
I think those belong in the trailer, but I can fix that myself.

> * gnu/packages/emacs.scm (emacs-minimal)[arguments]: Turn off
> native-compilation for the file lisp/transient.el.
> 
> Change-Id: I27c9d660cbad46be66df641816e4596346969dfc
> ---
>  gnu/packages/emacs.scm | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
> index f1ea4fe061..c555ca09f7 100644
> --- a/gnu/packages/emacs.scm
> +++ b/gnu/packages/emacs.scm
> @@ -233,6 +233,16 @@ (define-public emacs-minimal
>  (("\\(tramp-compat-process-running-p \"(.*)\"\\)"
> all process)
>   (format #f "(or ~a (tramp-compat-process-running-p
> ~s))"
>   all (string-append "." process "-
> real"))
> +  (add-after 'unpack 'do-not-native-compile
> +    (lambda _
> +  ;; Fixes . 
> Temporary
> +  ;; workaround for native-compilation bug of
> transient.el.
> +  ;; Please remove once the native-compilation for Emacs
> packages
> +  ;; is fully supported.
> +  (substitute* "lisp/transient.el"
> +    ((";; End:")
> + ";; no-native-compile: t
> +;; End:"
Should we do this in a snippet instead?  Otherwise LGTM.

Cheers

bug#72333: builtin native-compiled is loaded instead of emacs-packages

[Liliana Marie Prikler]

Hi Simon

Am Montag, dem 02.09.2024 um 20:55 +0200 schrieb Simon Tournier:
> […]
> Well, maybe that’s a bug known upstream (I have not checked) and
> maybe this behaviour has already been reported for Guix.  In both
> cases, that’s annoying because it means that emacs-packages are
> useless as dependencies since builtin is always used instead.
It is a bug unique to our handling in Guix – upstream uses hashes to
guard against it, but those break grafts.  In any case, builtin
packages are only used instead if the dependency isn't natively
compiled with a compatible Emacs (sadly the current default!) – I've
started a WIP series at [1], but we're still looking for solutions that
scale better in terms of what we need to declare for our packages (and
CI integration).

> Somehow, one solution would to not provide native-compilation of
> source code that is developed outside the Emacs tree (transient,
> Magit, etc.) and let user locally native-compile them.
I'm not sure that'd work.  Even if you byte-compile that code, you are
still loading the natively-compiled stuff from the Emacs tree.  You
could disable native compilation for the Emacs package itself, but
that'd kinda defeat the purpose of bundling these things with Emacs
(which tbf is an upstream thing).

> Or another solution would to split ’native-comp-eln-load-path’.  Say
> one folder for builtin code that we know is developed outside Emacs
> tree, e.g., transient, Org, etc. And append them in
> EMACSNATIVELOADPATH by default.  When a known package is provided by
> the user, the builtin path is removed from EMACSNATIVELOADPATH (and
> the package path could be added if emacs-build-system native-compile
> them).
This already happens.  The bug is not that built-in stuff is found
prior to non-builtin stuff, it's that it is found *at all*.  Since we
don't do native compilation for packages at the moment, most folks only
get Emacs itself natively compiled.

Cheers

[1] https://issues.guix.gnu.org/72406

bug#72921: Building emacs-yaml with emacs takes approximately eternity

[Liliana Marie Prikler]

Am Samstag, dem 31.08.2024 um 23:01 +0200 schrieb Tomas Volf:
> The emacs-yaml package is configured to build against emacs-minimal,
> which seems to work.  When you however switch to emacs package, it
> takes way to long to build, much longer than compiling for example
> firefox package.  That feels off.
> 
> --8<---cut here---start->8---
> $ time guix time-machine -q --
> commit=b8327cb31199fb9f4ebed6c53a59601d41def5a1 -- build --check --
> no-grafts -q --with-input=emacs-minimal=emacs-minimal emacs-yaml
> /gnu/store/8lqdd8yna92zqgsgip396a1wbyhr5pfn-emacs-yaml-0.5.5
> 12.573 secs
> $ time guix time-machine -q --
> commit=b8327cb31199fb9f4ebed6c53a59601d41def5a1 -- build --check --
> no-grafts -q --with-input=emacs-minimal=emacs emacs-yaml
> /gnu/store/ja9xfndhfafjczp6n7qfy1h21hvdpd5j-emacs-yaml-0.5.5
> 2869.878 secs
> --8<---cut here---end--->8---
> 
> The difference is huge.  The process taking vast majority of the time
> (in the emacs version) is this one:
> 
> --8<---cut here---start->8---
> 32393 guixbuil 47:10 {.emacs-29.4-rea}
> /gnu/store/y7yhpgi48klqpadrmfknl4bln9c4n05y-emacs-29.4/bin/emacs -no-
> comp-spawn -Q --batch -l /tmp/guix-build-emacs-yaml-0.5.5.drv-
> 0/emacs-int-comp-yaml-pbHFU3.el
> --8<---cut here---end--->8---
> 
> I do not know enough to even guess what could be the problem, but it
> was suggested I should bug-report this.
This issue has already been reported updstream [1], but not addressed
yet: What takes so long between emacs-minimal and plain emacs is the
fact that plain emacs does native compilation.  

emacs-build-system currently uses native compilation whenever that is
supported by the emacs used to build.  Perhaps we should allow for some
choice here – ideas welcome.

Cheers

[1] https://github.com/zkry/yaml.el/issues/53

bug#72333: [PATCH] gnu: emacs-transient: Prioritise loading over built-in.

[Liliana Marie Prikler]

Am Samstag, dem 17.08.2024 um 11:26 +0200 schrieb Tomas Volf:
> On 2024-07-31 19:10:03 +0200, Liliana Marie Prikler wrote:
> > The other (recommended at the moment) would be to use the proper
> > transformation to natively compile your emacs packages.
> 
> So just to make sure I understand correctly what is the correct work
> around here.  Let us assume I install emacs and emacs-magit into my
> home environment. So until now I have (leaving everything else out)
> this:
> 
>     (home-environment
>  (packages (list emacs emacs-magit )))
> 
> Assuming I want to follow the recommendation above, I should turn it
> into something like this:
> 
>     (home-environment
>  (packages (map (package-input-rewriting `((,emacs-minimal .
> ,emacs)))
>     (list emacs emacs-magit 
> 
> Did I get it right?  Are there any downsides to doing this (except
> compute)?
Yep, that's the low-level way of achieving this (more or less – emacs-
minimal isn't always the only package to replace).  On a higher level,
you can bind (package-input-rewriting …) to a name and use that.  I
personally prefer the (options->transformation …)¹ variant, though,
which is nearly identical and compiles to this.

Cheers

> Side note: I am surprised how long emacs-yaml takes to build on my
> ~5.5 GHz build machine.  I compile whole of firefox faster.
That sounds concerning.  We might want to look into individual bugs
such as this.

¹ the argument is '((with-input . "emacs-minimal=")),
  which imho, reads nicer.   could be emacs, emacs-pgtk,
  etc.

bug#72448: "xdg-mime query filetype" fails silently on many filetypes (with fixes I see)

[Liliana Marie Prikler]

Am Samstag, dem 03.08.2024 um 20:33 +0200 schrieb Sébastien Lerique:
> Ahoy Guix!
> 
> "xdg-mime query filetype a-book.epub" or "whatever.pdf" returns
> nothing, which is both puzzling and limiting as it blocks "xdg-open"
> to work for many files.
> 
> My case was opening pdf or epub files from Emacs, which "xdg-open"
> always sends to the browser, whatever my config (instead of e.g.
> evince or Foliate).
> 
> So debugging shows that:
> in ".xdg-mime-real",
> (/gnu/store/06ll0ydqsf4bjxwpwsi68dmn2cg0biy6-xdg-utils-1.1.3/bin/xdg-
> mime
> points there),
> l.673-684 in "info_gnome()",
> even if the "if ... elif ... elif ... fi" fails
> (i.e. none of "gio", "gvfs-info", or "gnomevfs-info" are available),
> then l.696 "if [ $? -eq 0 ]" gives always true.
> 
> Why? I don't know. I guess having a "case ..." instead of "if ... fi"
> would solve this.
Could you prepare a patch to do so?  Or has one already been proposed
upstream?

> But the result is "exit_success" gets called whatever the situation,
> and xdg-mime often gives no output, which then bugs "xdg-open".
> 
> Running this in "guix shell gnome-vfs" solves it, but what should be
> done to fix? And how did this not appear earlier? (is xdg* new?)
> 
> The options I see are adding the "gnome-vfs" dependency ("gvfs"
> doesn't provide "gvfs-info", and "gio" is not a package), or
> proposing "case" instead of "if" upstream.
Note: In GNOME, prefer `gio open', it's part of glib:bin.  
On other desktops, I don't know what the preferred solution would be.

Cheers

bug#72333: [PATCH] gnu: emacs-transient: Prioritise loading over built-in.

[Liliana Marie Prikler]

Am Mittwoch, dem 31.07.2024 um 21:04 +0900 schrieb gemmaro:
> * gnu/packages/emacs-xyz.scm (emacs-transient)[arguments]<#:emacs>:
> Use the full emacs package.
> 
> Change-Id: Id6277f365ae0a780469658818872b7277de20135
> ---
> Hello,
> 
> I hope this fixes the problem.
> 
> I found out the followings:
> * Native compiled files (.eln) might be loaded first.
> * The built-in Transient has an eln version and lacks transient-
> prefix-object.
> * Using the full emacs generates the eln and now it is prioritised.
This won't work if you use any other Emacs (e.g. emacs-pgtk).

Try for example: 
  guix shell emacs-magit emacs-pgtk \
--with-input=emacs-minimal=emacs --pure -- emacs

One workaround would be to check the symbol in magit and other packages
that rely on this symbol, but I hazard a guess that there's a reason
why they require the newer magit.

The other (recommended at the moment) would be to use the proper
transformation to natively compile your emacs packages.

We could also, for the time being, offer an Emacs without native
compilation – YMMV on how well liked that'd be.

The proper fix would be to build Emacs packages for the various
variants directly with emacs-build-system.  I have an as-of-yet
incomplete patch set to do exactly that.

Cheers

bug#72045: [PATCH v3 2/2] gnu: emacs-minimal: Ungraft.

[Liliana Marie Prikler]

Am Samstag, dem 20.07.2024 um 12:34 -0400 schrieb Suhail Singh:
> However, for the purposes of #72045 I believe v3 looks good.
For the purposes of #72045, I'm marking it as done.

Cheers

bug#72045: [PATCH v3 2/2] gnu: emacs-minimal: Ungraft.

[Liliana Marie Prikler]

Am Samstag, dem 20.07.2024 um 11:25 -0400 schrieb Suhail Singh:
> Liliana Marie Prikler  writes:
> 
> > Selected 1 system tests...
> 
> I get this line as well early on.  However, after that lots more
> things happen.

> 
> Could you please confirm the guix checkout commit you're applying
> your patch on?
Commit 9724e61cda80e4c59a2eb419a453887ecc551b9a, plus some very
unrelated stuff I have lying locally on master.  Particularly, commits
to sign off.

Cheers

bug#72045: [PATCH v3 2/2] gnu: emacs-minimal: Ungraft.

[Liliana Marie Prikler]

Am Samstag, dem 20.07.2024 um 10:31 -0400 schrieb Suhail Singh:
> Liliana Marie Prikler  writes:
> 
> > +    ;; Run `make check-system TESTS=emacs-native-comp' to ensure
> > that grafts
> > +    ;; can meaningfully be applied.
> 
> Either this isn't the correct invocation or I am doing something
> wrong.  Running that command in guix checkout seems to run many tests
> (possibly all of them?).  After applying this patch I get the
> following test suite summary:
> 
> #+begin_quote
>   ...
>  
> =
>   Testsuite summary for GNU Guix 1.4.0-23.843b85c
> =
>   # TOTAL: 2451
>   # PASS:  2341
>   # SKIP:  86
>   # XFAIL: 2
>   # FAIL:  22
>   # XPASS: 0
>   # ERROR: 0
>  
> =
>   See ./test-suite.log
>   Please report to bug-guix@gnu.org
> =
>   ...
> #+end_quote
Well, I get

#+begin_quote
Selected 1 system tests...
/gnu/store/rszxrbzryn0cwmdq5mppr7yqqgij4gzd-emacs-native-comp-
compatible
#+end_quote

That's quite strange.

bug#72045: [PATCH v2 1/2] gnu: Add system test for Emacs.

[Liliana Marie Prikler]

* gnu/tests/emacs.scm: New file.
---
Hi Guix,

this series adds a system test to ensure that Emacs grafts are meaningful.
With this, we can make safe decisions as to whether or not place
(replacement …)

Cheers

 gnu/tests/emacs.scm | 100 
 1 file changed, 100 insertions(+)
 create mode 100644 gnu/tests/emacs.scm

diff --git a/gnu/tests/emacs.scm b/gnu/tests/emacs.scm
new file mode 100644
index 00..fba27cefd8
--- /dev/null
+++ b/gnu/tests/emacs.scm
@@ -0,0 +1,100 @@
+;;; GNU Guix --- Functional package management for GNU
+;;; Copyright © 2024 Liliana Marie Prikler 
+;;;
+;;; This file is part of GNU Guix.
+;;;
+;;; GNU Guix is free software; you can redistribute it and/or modify it
+;;; under the terms of the GNU General Public License as published by
+;;; the Free Software Foundation; either version 3 of the License, or (at
+;;; your option) any later version.
+;;;
+;;; GNU Guix is distributed in the hope that it will be useful, but
+;;; WITHOUT ANY WARRANTY; without even the implied warranty of
+;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+;;; GNU General Public License for more details.
+;;;
+;;; You should have received a copy of the GNU General Public License
+;;; along with GNU Guix.  If not, see <http://www.gnu.org/licenses/>.
+
+(define-module (gnu tests emacs)
+  #:use-module (gnu tests)
+  #:use-module (gnu packages emacs)
+  #:use-module (gnu packages vim)
+  #:use-module (gnu services)
+  #:use-module (gnu system)
+  #:use-module (gnu system vm)
+  #:use-module (guix packages)
+  #:use-module (guix gexp)
+  #:use-module (srfi srfi-1)
+  #:export (%test-emacs-native-comp-replacable))
+
+(define (run-native-comp-replacable-test old-emacs new-emacs)
+  (define vm (virtual-machine (marionette-operating-system %simple-os)))
+
+  (define test
+(with-imported-modules '((gnu build marionette))
+  #~(begin
+  (use-modules (gnu build marionette)
+   (srfi srfi-1)
+   (srfi srfi-64))
+
+  (define marionette (make-marionette (list #$vm)))
+  (define (emacs-native-comp-dir emacs)
+(marionette-eval
+ `(begin
+(use-modules (ice-9 rdelim) (ice-9 popen))
+(read-line
+ (open-pipe*
+  OPEN_READ
+  ,emacs "--batch"
+  "--eval=(princ comp-native-version-dir)")))
+ marionette))
+  (define (emacs-effective-version emacs)
+(marionette-eval
+ `(begin
+(use-modules (ice-9 rdelim) (ice-9 popen))
+(read-line
+ (open-pipe*
+  OPEN_READ
+  ,emacs "--batch"
+  "--eval=(princ (format \"%s.%s\" \
+   emacs-major-version emacs-minor-version))")))
+ marionette))
+  (define old-emacs-bin #$(file-append old-emacs "/bin/emacs"))
+  (define new-emacs-bin #$(file-append new-emacs "/bin/emacs"))
+
+  (test-runner-current (system-test-runner #$output))
+  (test-begin "emacs-native-comp-replacable")
+  (test-equal "native-comp-dir"
+(emacs-native-comp-dir
+ #$(file-append old-emacs "/bin/emacs"))
+(emacs-native-comp-dir
+ #$(file-append new-emacs "/bin/emacs")))
+  (test-assert "old emacs has hierarchical layout"
+(file-exists?
+ (string-append #$new-emacs "/lib/emacs/"
+(emacs-effective-version old-emacs-bin)
+"/native-lisp/"
+(emacs-native-comp-dir old-emacs-bin)
+"/preloaded/emacs-lisp/comp.eln")))
+  (test-assert "new emacs has hierarchical layout"
+(file-exists?
+ (string-append #$new-emacs "/lib/emacs/"
+(emacs-effective-version new-emacs-bin)
+"/native-lisp/"
+(emacs-native-comp-dir new-emacs-bin)
+"/preloaded/emacs-lisp/comp.eln")))
+  (test-end
+
+  (gexp->derivation "emacs-native-comp-compatible" test))
+
+(define (package-without-replacement pkg)
+  (package (inherit pkg) (replacement #f)))
+
+(define %test-emacs-native-comp-replacable
+  (system-test
+   (name "emacs-native-comp")
+   (description "Test whether an emacs replacement (if any) is valid.")
+   (value (run-native-comp-replacable-test
+   (package-without-replacement emacs)
+   emacs

base-commit: e3dfed59d39ac60dd2e2b9ef9f4ef63a2a081f41
-- 
2.45.2

bug#72045: [PATCH v2 1/2] gnu: Add system test for Emacs.

[Liliana Marie Prikler]

Am Freitag, dem 19.07.2024 um 11:23 -0400 schrieb Suhail Singh:
> Liliana Marie Prikler  writes:
> 
> > +  (test-equal "native-comp-dir"
> > +    (emacs-native-comp-dir
> > + #$(file-append old-emacs "/bin/emacs"))
> > +    (emacs-native-comp-dir
> > + #$(file-append new-emacs "/bin/emacs")))
> 
> I like that there is a test that focuses on the native-comp-dir
> directly.  Having only a test that focuses on ABI_VERSION wouldn't
> have been sufficient IMO.
> 
> Minor nitpick: However, there may still be some utility in either
> having an additional test for ABI_VERSION or adding a comment that a
> successful evaluation of the above test also implies that the
> ABI_VERSION matches.
We can test `comp-abi-hash` as well, should be no biggie.

> > +  (test-assert "old emacs has hierarchical layout"
> > +    (file-exists?
> > + (string-append #$new-emacs "/lib/emacs/"
> > +    (emacs-effective-version old-emacs-
> > bin)
> > +    "/native-lisp/"
> > +    (emacs-native-comp-dir old-emacs-bin)
> > +    "/preloaded/emacs-lisp/comp.eln")))
> 
> Should that say #$old-emacs instead of #$new-emacs ?
Yes, it should.

> > +  (test-assert "new emacs has hierarchical layout"
> > +    (file-exists?
> > + (string-append #$new-emacs "/lib/emacs/"
> > +    (emacs-effective-version new-emacs-
> > bin)
> > +    "/native-lisp/"
> > +    (emacs-native-comp-dir new-emacs-bin)
> > +    "/preloaded/emacs-lisp/comp.eln")))
> 
> Do we need to additionally ensure that the new emacs' "hierarchical
> layout" matches the old emacs' "hierarchical layout" in some way
> (over and above both having them)?
We could do so, but that'd be an expensive test.  In practice, we
assume the same layout and just poke a single file.

> > +(define %test-emacs-native-comp-replacable
> > +  (system-test
> > +   (name "emacs-native-comp")
> > +   (description "Test whether an emacs replacement (if any) is
> > valid.")
> > +   (value (run-native-comp-replacable-test
> > +   (package-without-replacement emacs)
> > +   emacs
> 
> Ah!  So that's how it's done.  I am not qualified to review this
> part, but this looks to be in the right spirit.  Hoping this is
> merged soon.™
You can verify this part by running "make check-system TESTS=emacs-
native-comp" and seeing that it fails for this commit but succeeds on
the next.  That's TDD :D

Cheers

bug#72172: Text is missing from main title bar and tabs in Gnome Console

[Liliana Marie Prikler]

Am Mittwoch, dem 17.07.2024 um 20:07 + schrieb Oleander:
> Hello everyone!
> 
> I installed Gnome recently and I noticed that text is missing from
> main title bar and tabs in Gnome Console. 
> 
> This bug has been confirmed by another user in the Guix Help mailing
> list:
> https://lists.gnu.org/archive/html/help-guix/2024-07/msg00038.html
That is an upstream bug, which will be fixed once we update to a newer
version.  I'll publish a first series towards GNOME 46 soon™, and it
will have gnome-console 46, in which you get some default text. 

Cheers

bug#72045: Emacs graft lookup still fails

[Liliana Marie Prikler]

Am Sonntag, dem 14.07.2024 um 12:27 -0400 schrieb Suhail Singh:
> However, perhaps there is a way to ensure that the proposed
> replacement doesn't have a different ABI_VERSION.  Could this be
> caught by a test or "sanity checker" of some kind?
You could just print the value of comp-native-version-dir.  If that
changes between ungrafted and grafted emacs, then the graft is NG (no
good).

Cheers
> > 

bug#72045: Emacs graft lookup still fails

[Liliana Marie Prikler]

Am Samstag, dem 13.07.2024 um 19:22 -0400 schrieb Suhail Singh:
> Liliana Marie Prikler  writes:
> 
> > with the grafting of Emacs 29.3 to 29.4, we see that Emacs itself
> > is still correctly loaded, but Emacs libraries (e.g. dash) aren't.
> > 
> > (comp-el-to-eln-filename (expand-file-name "…/dash.el"))
> > => $HOME/.config/emacs/eln-cache/29.4-46e5bcbe/dash-2.19.1/dash.eln
> > 
> > find $(guix build emacs-dash --with-input=…) -name 'dash.eln'
> > => $PREFIX/lib/emacs/native-site-lisp/29.3-62809b9a/dash.eln
> > 
> > It seems that we might have to rebuild emacs native-compiled
> > packages even if emacs itself is grafted.
> 
> I had missed this message, previously.
> 
> IIUC, the issue is that replacement packages are grafted post-build.
> This means that when emacs-dash is built, its AOT native-compilation
> happens with Emacs 29.3.  However, at run-time Emacs 29.4 gets
> grafted in.
Nitpick: Emacs 29.4 gets grafted in at profile-building time.

> There are at least two possible ways (ignoring feasibility) to
> resolve this:
> 
> 1. When emacs-dash etc. is being built we use Emacs 29.4 for native
>    compilation.
That kinda defeats the point of grafting, though.  At this point,
rebuilding with newer Emacs makes more sense.

> 2. When emacs-dash etc. is being built we use Emacs 29.3 for native
>    compilation, but ensure that said files are transferred to a
>location where Emacs 29.4 is able to find them.
Given that the ABI hash is used to guard against loading outdated
libraries like this, I'm not sure whether this makes too much sense.  I
think what we would need is something like 

3. Accurately capture the compatibility between Emacs-used-to-compile
   and Emacs-used-to-run.  I.e. find a way to enable Emacs cross
   compilation.

Perhaps upstream already has some ideas on this, perhaps not.

> Which do we desire?  My belief is that 1 is what we need, and that
> doing 2 may be inadequate for ensuring that appropriate security
> fixes are deployed (consider the case where the bug is in a macro in
> Emacs core).
I think 1 could be accomplished with a build system hack, but see
above.

Cheers

bug#72045: [PATCH RFC 1/2] gnu: emacs: Compute ABI hash and native version dir without version.

[Liliana Marie Prikler]

Am Samstag, dem 13.07.2024 um 12:08 -0400 schrieb Suhail Singh:
> Liliana Marie Prikler  writes:
> 
> > this is a somewhat experimental patch, which reduces
> > Vcomp_native_version_dir to simply Vcomp_abi_hash.  Note, that this
> > is not enough to address the issues currently noticed with Emacs
> > native compilation, as Vcomp_abi_hash is unstable between 29.3 and
> > 29.4.  These hashes are probably unlikely to stay the same between
> > minor releases even when dropping the version.
> 
> I am confused as to what this change is intended to accomplish in
> that case.  Specifically, while this patch may be _necessary_ to
> allow both grafts and native-compilation to work since it isn't
> _sufficient_ to accomplish that, it may be better to withhold the
> patch till a later time when an appropriate fix for dealing with
> grafts has been found.
It could possibly allow us some flexibility in future changes, but at
the very least it doesn't work right now.  Hence why it's RFC while the
other patch isn't.

Cheers

bug#72045: [PATCH 2/2] gnu: emacs-minimal: Ungraft.

[Liliana Marie Prikler]

Am Samstag, dem 13.07.2024 um 12:14 -0400 schrieb Suhail Singh:
> Liliana Marie Prikler  writes:
> 
> > +    ;; Note: When using (replacement …), ensure that comp-native-
> > version-dir
> > +    ;; stays the same across grafts.
> 
> Perhaps an acknowledgment that we don't yet know how to accomplish
> that would be helpful?  Unless I have misunderstood the current state
> and am mistaken.
I think as long as the package version and function signatures remain
unchanged, we can graft Emacs itself.  But it is limited to minor
patches; no version bumps.

Cheers

bug#72045: [PATCH RFC 1/2] gnu: emacs: Compute ABI hash and native version dir without version.

[Liliana Marie Prikler]

* gnu/packages/patches/emacs-native-comp-fix-filenames.patch: Drop
emacs_version from Vcomp_abi_hash.
Make Vcomp_native_version_dir equal to Vcomp_abi_hash.
---
Hi Guix,

this is a somewhat experimental patch, which reduces Vcomp_native_version_dir
to simply Vcomp_abi_hash.  Note, that this is not enough to address the
issues currently noticed with Emacs native compilation, as Vcomp_abi_hash
is unstable between 29.3 and 29.4.  These hashes are probably unlikely
to stay the same between minor releases even when dropping the version.

Cheers

 .../emacs-native-comp-fix-filenames.patch | 27 ---
 1 file changed, 23 insertions(+), 4 deletions(-)

diff --git a/gnu/packages/patches/emacs-native-comp-fix-filenames.patch 
b/gnu/packages/patches/emacs-native-comp-fix-filenames.patch
index 169323f290..6c81d7c28c 100644
--- a/gnu/packages/patches/emacs-native-comp-fix-filenames.patch
+++ b/gnu/packages/patches/emacs-native-comp-fix-filenames.patch
@@ -12,11 +12,30 @@ way into the actual variable despite attempts to remove it 
by calling
 The user-visible procedure ‘startup-redirect-eln-cache’ is kept, as
 packages may require it, but only pushes the new value now.
 
-Index: emacs-29.2/src/comp.c
+Index: emacs-29.3/src/comp.c
 ===
 emacs-29.2.orig/src/comp.c
-+++ emacs-29.2/src/comp.c
-@@ -4396,26 +4396,17 @@ DEFUN ("comp-el-to-eln-rel-filename", Fc
+--- emacs-29.3.orig/src/comp.c
 emacs-29.3/src/comp.c
+@@ -805,7 +805,7 @@ hash_native_abi (void)
+   Vcomp_abi_hash =
+ comp_hash_string (
+   concat3 (build_string (ABI_VERSION),
+- concat3 (Vemacs_version, Vsystem_configuration,
++ concat2 (Vsystem_configuration,
+   Vsystem_configuration_options),
+  Fmapconcat (intern_c_string ("comp--subr-signature"),
+  Vcomp_subr_list, build_string ("";
+@@ -835,8 +835,7 @@ hash_native_abi (void)
+ }
+ #endif
+ 
+-  Vcomp_native_version_dir =
+-concat3 (version, build_string ("-"), Vcomp_abi_hash);
++  Vcomp_native_version_dir = Vcomp_abi_hash;
+ }
+ 
+ static void
+@@ -4396,26 +4395,17 @@ DEFUN ("comp-el-to-eln-rel-filename", Fc
 Scomp_el_to_eln_rel_filename, 1, 1, 0,
 doc: /* Return the relative name of the .eln file for FILENAME.
  FILENAME must exist, and if it's a symlink, the target must exist.

base-commit: a1e6ac72fd88faf20c26e235f5c8222881b2b450
-- 
2.45.2

bug#72045: [PATCH 2/2] gnu: emacs-minimal: Ungraft.

[Liliana Marie Prikler]

The current graft breaks native compilation and would do so even if reduced to
an ABI hash.  Thus remove it, and rebuild all Emacsen.

* gnu/packages/emacs.scm (emacs-minimal): Update to 29.4.
[replacement]: Remove.  Add note for future replacements.
(emacs-minimal/fixed): Remove variable.

Fixes: Emacs native compilation across grafts 
---
 gnu/packages/emacs.scm | 19 ---
 1 file changed, 4 insertions(+), 15 deletions(-)

diff --git a/gnu/packages/emacs.scm b/gnu/packages/emacs.scm
index ed186d221c..33bb0dd542 100644
--- a/gnu/packages/emacs.scm
+++ b/gnu/packages/emacs.scm
@@ -100,15 +100,16 @@ (define (%emacs-modules build-system)
 (define-public emacs-minimal
   (package
 (name "emacs-minimal")
-(version "29.3")
-(replacement emacs-minimal/fixed)
+(version "29.4")
+;; Note: When using (replacement …), ensure that comp-native-version-dir
+;; stays the same across grafts.
 (source (origin
   (method url-fetch)
   (uri (string-append "mirror://gnu/emacs/emacs-"
   version ".tar.xz"))
   (sha256
(base32
-"1822swrk4ifmkd4h9l0h37zifcpa1w3sy3vsgyffsrp6mk9hak63"))
+"0dd2mh6maa7dc5f49qdzj7bi4hda4wfm1cvvgq560djcz537k2ds"))
   (patches (search-patches "emacs-disable-jit-compilation.patch"
"emacs-exec-path.patch"
"emacs-fix-scheme-indent-function.patch"
@@ -335,18 +336,6 @@ (define-public emacs-minimal
 (files '("lib/tree-sitter")
 (properties `((upstream-name . "emacs")
 
-(define emacs-minimal/fixed
-  (package
-(inherit emacs-minimal)
-(version "29.4")
-(source
- (origin (inherit (package-source emacs-minimal))
- (uri (string-append "mirror://gnu/emacs/emacs-"
- version ".tar.xz"))
- (sha256
-  (base32
-   "0dd2mh6maa7dc5f49qdzj7bi4hda4wfm1cvvgq560djcz537k2ds"))
-
 (define-public emacs-no-x
   (package/inherit emacs-minimal
 (name "emacs-no-x")
-- 
2.45.2

bug#72045: Emacs graft lookup still fails

[Liliana Marie Prikler]

Hi Guix,

this got reported in the XMPP chat already, but the basic gist is this:
with the grafting of Emacs 29.3 to 29.4, we see that Emacs itself is
still correctly loaded, but Emacs libraries (e.g. dash) aren't.

(comp-el-to-eln-filename (expand-file-name "…/dash.el"))
=> $HOME/.config/emacs/eln-cache/29.4-46e5bcbe/dash-2.19.1/dash.eln

find $(guix build emacs-dash --with-input=…) -name 'dash.eln'
=> $PREFIX/lib/emacs/native-site-lisp/29.3-62809b9a/dash.eln

It seems that we might have to rebuild emacs native-compiled packages
even if emacs itself is grafted.  Do we have any pointers on how to
correctly process this graft?

Cheers

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

[Liliana Marie Prikler]

Am Sonntag, dem 08.10.2023 um 14:21 +0400 schrieb Andrew Tropin:
> On 2023-10-08 08:55, Liliana Marie Prikler wrote:
> 
> > 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).
> 
> Cool!  Thank you very much, appreciate your work!
It seem, that there hasn't been a complaint about this one for a while
since the fix was applied, so I'll close it as done.

Cheers

bug#71730: [PATCH] doc: Update note on Emacs packages.

[Liliana Marie Prikler]

Am Donnerstag, dem 27.06.2024 um 09:00 -0500 schrieb Adam Porter:
> Hi Liliana,
> 
> On 6/23/24 08:17, Liliana Marie Prikler wrote:
> > * doc/guix.texi ("Emacs packages"): Expand note to talk about
> > differences
> > between native compilation upstream and as used in Guix.
> > ---
> >   doc/guix.texi | 31 ++-
> >   1 file changed, 22 insertions(+), 9 deletions(-)
> 
> Thanks, I think that is a great addition to the manual.
Pushed now.

Cheers

bug#71816: Emacs as build tool fails to launch after update

[Liliana Marie Prikler]

Hi Arne,

Am Freitag, dem 28.06.2024 um 09:38 +0200 schrieb Dr. Arne
Babenhauserheide:
> To do a clean run:
> 
> sudo mkdir -p /home/arne/eigenes/Webseiten/
> sudo chmod a+rwx /home/arne/eigenes/Webseiten/
> hg clone
> https://hg.sr.ht/~arnebab/draketo /home/arne/eigenes/Webseiten/arneba
> b-org
> cd /home/arne/eigenes/Webseiten/arnebab-org
> echo -e "utf-8\n" | HOME="/home/arne/eigenes/Webseiten/arnebab-org"
> emacs --batch --load .emacs.d/init.el --load setup.el "setup.el" -f
> org-feed-update-all -f kill-emacs && touch "external-rss.org.in"
> 
> 
> Since I updated Guix, it is broken for me:
> 
> echo -e "utf-8\n" | HOME="/home/arne/eigenes/Webseiten/arnebab-org"
> emacs --batch --load .emacs.d/init.el --load setup.el "setup.el" -f
> org-feed-update-all -f kill-emacs && touch "external-rss.org.in" #
> the
> echo is a hack to work around broken encoding -> no longer empty, but
> still broken
> Loading ido (native compiled elisp)...
> 
> Error: error ("Recursive ‘require’ for feature ‘ox’")
> […]
> How can I help track this down?
With PWD="/home/arne/eigenes/Webseiten/", I can run 
  guix shell coreutils mercurial emacs emacs-ox-rss --pure

followed by 
  HOME="$PWD" emacs --batch --load .emacs.d/init.el --load setup.el
"setup.el" -f org-feed-update-all -f kill-emacs

and it gives me the following:

--8<---cut here---start->8---
.emacs.d/lisp/key-chord.el: Warning: Obsolete calling convention for
'sit-for'
Contacting host: rollenspiel.social:443
Mark set
Replaced 1 occurrence
Mark set
Replaced 3 occurrences
Mark set
Replaced 2 occurrences
Mark set
Replaced 2 occurrences
Mark set
Replaced 1 occurrence
Mark set
Replaced 3 occurrences
Mark set
Replaced 2 occurrences
Mark set
Replaced 4 occurrences
Mark set
Replaced 4 occurrences
Mark set
Replaced 7 occurrences
Mark set
Replaced 1 occurrence
Mark set
Replaced 33 occurrences
Clipboard pasted as level 2 subtree
Position saved to mark ring, go back with `C-c &'.
Added 1 new item from feed rollenspiel.social/@ArneBab to file
external-rss.org.in, heading rollenspiel.social
Contacting host: sn.1w6.org:80
No new items in feed sn.1w6.org
Contacting host: www.1w6.org:80
uncompressing publicsuffix.txt.gz...
uncompressing publicsuffix.txt.gz...done
No new items in feed 1w6
No new items in feed Weltenwald, alt
1 new entry from 5 feeds (unavailable feeds: 1)
--8<---cut here---end--->8---

Thus, at the very least with a pure environment, you shouldn't
encounter this.  I'm not sure, what's in your profile, but you might
want to use pure environments to encapsulate them, then file bugs
against broken combinations that you encounter.

Cheers

bug#71729: Emacs 29.4 emergency bugfix release

[Liliana Marie Prikler]

Hi Adam,

Am Donnerstag, dem 27.06.2024 um 08:57 -0500 schrieb Adam Porter:
> Thanks.
> 
> If I may ask here, as it seems relevant and might help other users in
> the future:
> 
> A few minutes ago I ran "guix pull", but after it finished, "guix
> show emacs" still shows:
> 
>    name: emacs
>    version: 29.3
> 
> Am I missing something?  e.g. the equivalents in Debian, like "apt
> show emacs" or "apt policy emacs", show both installed and available
> versions.
You're missing the graft, which apparently does not show up in "guix
show".  

> So as a user, how am I to know whether I'm using the latest version
> of a package?  I also tried "guix upgrade -n" (which updates
> substitute lists from the network, which can significantly delay its
> finishing for a simple check like this), and it shows:
> 
>    The following packages would be upgraded:
>     emacs (dependencies or package changed)
> 
> But maybe that's affected by the workaround I'm using (see below).
FWIW, with emacs you can check (emacs-version).  More generally, this
is a bug – replacements ought to be announced somehow.

> > > FWIW, I had hoped that I could install it by running:
> > > 
> > >     guix install --with-version=emacs=29.4 emacs
> > > 
> > > But that fails the validate-comp-integrity phase, showing that
> > > all of
> > > its tests fail, with every function being loaded in byte-compiled
> > > form instead of native-compiled.
> 
> > Ah, yes, that is not something you can do with --with-version, as
> > it
> > disregards our patches and everything.
> 
> Ah, I wish I had known that.  FWIW, looking at 
> <
> https://guix.gnu.org/manual/en/html_node/Package-Transformation-Option
> s.html>, I can't even find "--with-version" documented at all.  But
> besides that, none of them seem to explain that such options may
> discard parts of the package definition, such as patches (if any of
> those other options do--is it only "--with-version" that does?). 
> Does a documentation bug need to be filed about this?
The info manual (which you can read locally) has both, as well as the
warning you seek.

> > As for how to work around this, you can do a more elaborate package
> > definition:
> > 
> >    (package
> >  (inherit emacs)
> >  (version NEW_VERSION)
> >  (source (origin (inherit (package-source emacs))
> >  (uri NEW_URI
> > 
> > This should automatically apply our patches.  Or, you can locally
> > run `guix refresh -u emacs'.
> 
> Thanks for the pointer.  I defined a package called "emacs-jit" (and
> a corresponding "emacs-minimal-jit") that comments out the
> JIT-disabling patches, so that I can still JIT-compile packages
> installed through Emacs, and it seems to be working fine.
> 
> Would you be willing to accept some kind of package definition like
> that being added to Guix, as an alternative to the main "emacs"
> package? (I won't quibble over the name.)  I think that there are a
> significant number of users who would like to use Guix to keep Emacs
> up-to-date without sacrificing the ability to native-compile packages
> installed from within Emacs.  It would be nice to have this in Guix
> so that I wouldn't have to manually update the package definition
> according to upstream changes.
But then you'd be shifting the maintenance burden to us Guix.  We
already have enough Emacs variants to keep track of as-is, and adding
yet another orthogonal angle is not going to scale well.  Plus, for
this variant you'd lose all the benefits that Guix provides – I don't
see this as a reasonable thing to ship, to be honest.

Cheers

bug#71730: [PATCH] doc: Update note on Emacs packages.

[Liliana Marie Prikler]

* doc/guix.texi ("Emacs packages"): Expand note to talk about differences
between native compilation upstream and as used in Guix.
---
 doc/guix.texi | 31 ++-
 1 file changed, 22 insertions(+), 9 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 9bbf85e32b..67c5cef757 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -1878,15 +1878,28 @@ Application Setup
 File,,, emacs, The GNU Emacs Manual}).
 
 @quotation Note
-Emacs can now compile packages natively.  Under the default
-configuration, this means that Emacs packages will now be
-just-in-time (JIT) compiled as you use them, and the results
-stored in a subdirectory of your @code{user-emacs-directory}.
-
-Furthermore, the build system for Emacs packages transparently
-supports native compilation, but note, that
-@code{emacs-minimal}---the default Emacs for building
-packages---has been configured without native compilation.
+Most Emacs variants are now capable of doing native compilation.
+The approach taken by Guix Emacs however differs greatly
+from the approach taken upstream.
+
+Upstream Emacs compiles packages just-in-time and typically places
+shared object files  in a special folder within your
+@code{user-emacs-directory}.
+These shared objects within said folder are organized in a
+flat hierarchy, and their file names contain two hashes to
+verify the original file name and contents of the source code.
+
+Guix Emacs on the other hand prefers to compile packages ahead-of-time.
+Shared objects retain much of the original file name and no hashes
+are added to verify the original file name or the contents of the file.
+Crucially, this allows Guix Emacs and packages built against it
+to be grafted (@pxref{Security Updates, grafts}), but at the same time,
+Guix Emacs lacks the hash-based verification of source code baked
+into upstream Emacs.  As this naming schema is trivial to exploit,
+we disable just-in-time compilation.
+
+Further note, that @code{emacs-minimal}---the default Emacs
+for building packages---has been configured without native compilation.
 To natively compile your emacs packages ahead of time, use a
 transformation like @option{--with-input=emacs-minimal=emacs}.
 @end quotation

base-commit: 11c403ec0554be0e1c888ec6f8147a232e09adbd
-- 
2.45.1

bug#71725: Emacs emacs-disable-jit-compilation.patch prevents native compilation of packages installed outside of Guix?

[Liliana Marie Prikler]

Hello,

Am Samstag, dem 22.06.2024 um 18:31 -0500 schrieb Adam Porter:
> […T]he patch file "emacs-disable-jit-compilation.patch" […] 
> disables the option `native-comp-jit-compilation' by default [and]
> includes this warning in the docstring:
> 
> "Notably, Guix removes the hashes that prevent inadvertent shadowing
> frm the file names of compiled libraries in order to facilitate
> grafts. Enable at your own risk!"
Well, that's a typo I didn't notice before.

> So, 1. I would ask that this warning be expanded and clarified.  For 
> those of us users who aren't experts in all aspects of Guix, I don't 
> understand exactly what this means.  (I do understand what grafts
> are, and I understand how Emacs's ELN files are named to facilitate
> loading correct libraries, but I don't know what Guix is doing with
> the filenames, and I don't know the implications of that.)
> 
> For example, if I enable this variable in my configuration so that 
> packages not installed through Guix are native-compiled, is that now 
> expected to break something?  Before the patch and accompanying
> changes were added, I experienced no problems using native-
> compilation, including making use of built-in, ahead-of-time native-
> compiled libraries, as well as JIT native-compiled libraries
> installed with Emacs's package system.
Well, the short answer is "I don't know".  The long answer is "Even
without disabling this flag, we use the fact that the same file name
points somewhere else for security updates.  Thus, there is a
legitimate use case, but I don't know what specific mess you sign
yourself up to if you do enable this flag on your machine."  In short,
enable this at your own risk.

> While I admire Guix's end goal of encompassing everything, I don't
> want to install Elisp packages via Guix.  (For one, being a developer
> of them, it would be impractical.  Even otherwise, not every library
> is going to be available or up-to-date in Guix, and I don't want to
> have to give up native-compilation for them.)  I also don't want to
> be restricted from using native compilation for non-built-in
> libraries.
That's understandable, but why do you then need Emacs itself from
Guix?🤔️
If you want to do traditional package management, there ought to be
enough to serve your purpose, perhaps even on your foreign distro.  If
not, you can use an .scm file to define an Emacs without this patch.  I
don't know whether that's desirable for your use case – for us as Guix
the expectation is rather that our own packages work as expected, i.e.
with graftable native-compilation.

> Also, 2. I would ask, if indeed enabling that option is now expected
> to break something, that this be remedied in some way.  To expect
> Guix Emacs users to forego native compilation for Elisp packages
> installed from within Emacs would be...well, it would simply be
> impractical, because, as I said, it's not practical (or even
> desirable) to install all Elisp packages with Guix.
> 
> To impose such a limitation on users would be reason enough to
> abandon installing Emacs through Guix, even for serious Guix users. 
> And that would be a shame, because this is one of Guix's great
> strengths, to provide up-to-date software, regardless of the
> underlying system, with simplicity and reliability.  If I were to
> have to go back to building and installing Emacs manually, what a
> regression that would be.
Sorry, but none of that follows.  We have an importer and updater for
Elisp, so even the packages that are not yet in Guix or out-of-date
ought to be easy to use regardless.  Even outside of Emacs, we have
this whole "Build it with Guix" thing going on – you might want to
consider using a guix.scm for your Emacs packages, particularly if you
need newer versions of things that are not yet in Guix.  Or
contributing.

Cheers

bug#71729: Emacs 29.4 emergency bugfix release

[Liliana Marie Prikler]

Am Samstag, dem 22.06.2024 um 19:52 -0500 schrieb Adam Porter:
> Hello,
> 
> Today an emergency bugfix release was made of Emacs v29.4.  It fixes
> an important security vulnerability.
Note: Security bugs should go to guix-security instead.  But thanks for
pointing out the new Emacs release, I've pushed an update. (Thus
marking this done)

> FWIW, I had hoped that I could install it by running:
> 
>    guix install --with-version=emacs=29.4 emacs
> 
> But that fails the validate-comp-integrity phase, showing that all of
> its tests fail, with every function being loaded in byte-compiled
> form instead of native-compiled.
Ah, yes, that is not something you can do with --with-version, as it
disregards our patches and everything.

> And despite my best efforts at comparing the emacs.git tags for 29.3
> and 29.4 to look for any relevant changes, and digging through the
> relevant source code, and scanning through the build logs, I can't
> find a cause for this problem.
> 
> Is this failure expected?  If so, is it something unique to the Emacs
> packaging, and could it be fixed?  (Before Emacs 28 was released, I
> was able to use a similar "--with-commit" option to build and install
> what was then the emacs-next package to get native-compilation
> support, keeping it updated with Emacs's master branch at the time. 
> It would be helpful if that could still be used by users rather than
> having to wait for an update to the package definition, especially in
> a case like this.)
I understand your pain, but I doubt there is a reasonable fix to this.
Perhaps the check should honour tests?, but then you'd disable all the
other tests as well as part of the build.  Maybe a --without-phase
option to the Guix CLI would be better?

As for how to work around this, you can do a more elaborate package
definition:

  (package
(inherit emacs)
(version NEW_VERSION)
(source (origin (inherit (package-source emacs))
(uri NEW_URI

This should automatically apply our patches.  Or, you can locally run
`guix refresh -u emacs'.

Cheers

bug#71556: GNOME Konsol crashes

[Liliana Marie Prikler]

Am Freitag, dem 14.06.2024 um 18:34 +0200 schrieb Simon Josefsson:
> Hi.
> 
> GNOME Konsol has crashed for me, bringing down all 10+ windows I had
> open (and plenty of ongoing work halted...).  I've now seen this
> twice, so I suppose it counts as reproducible, even though I don't
> know how to trigger it.  I recall that it happened when I used the
> mouse to maybe resize windows or switch workspace somehow.
> 
> This is guix v1.3.0-60008-g7e00fb9f31 with a fairly normal system
> configuration [1] on a fairly ordinary amd64 desktop (MSI Z790P).
> Syslog has these two crashes:
… and a fairly normal GPU?

The crash indicates some driver issue, probably in Mesa.  Since GNOME
is increasingly hardware accelerated, you tend to notice them in a lot
of places.  You can twiddle the GSK_RENDERER environment variable to
something less buggy, potentially at the cost of performance. 
Particularly the cairo one ought to do slow, but correct CPU rendering.


Cheers

bug#70349: Clang fails to communicate RUNPATH?

[Liliana Marie Prikler]

Hi Ludo,

Am Samstag, dem 25.05.2024 um 11:26 +0200 schrieb Ludovic Courtès:
> Could this be an issue specific to ‘meson-build-system’?
> 
> For instance, this works fine (both mpfr and mpc use
> ‘gnu-build-system’):
> 
>   guix build mpc --with-c-toolchain=mpfr=clang-toolchain
> 
> If we add this to the example you posted:
> 
>    (arguments
>     (list #:phases #~(modify-phases %standard-phases
>    (add-after 'unpack 'debug-ld-wrapper
>  (lambda _
>    (setenv "GUIX_LD_WRAPPER_DEBUG"
> "yes"))
> 
> … we see:
> 
> --8<---cut here---start->8---
> ld-wrapper: library search path:
> ("/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-
> lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0"
> "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib"
> "/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-
> lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../.."
> "/gnu/store/inpy5mz35fwvclynpag5gsp6d1hflfsz-meson-1.1.0/lib"
> "/gnu/store/qhz8n6mxzalifcrml6fwsvnxw92bk7n0-fmt-9.1.0/lib"
> "/gnu/store/j8wlfmlmfvpbza6is9wv9xsd8psrxn00-bzip2-1.0.8/lib"
> "/gnu/store/gr0sy0m1mv36qv54idm6cn10l3mngshq-file-5.44/lib"
> "/gnu/store/hc05d76f1j3iz3v2bs5jz4fpljl1r4dj-gawk-5.2.1/lib"
> "/gnu/store/6k1yys9wqrfn4y41ic1win8gpnimncwj-xz-5.2.8/lib"
> "/gnu/store/visfdda934gvivwihwhlm63fdqhhcc8a-glibc-utf8-locales-
> 2.35/lib" "/gnu/store/0irvg0gvvfwagdjckigvr4g8xap94y1j-clang-
> toolchain-18.1.5/lib")
> ld-wrapper: libraries linked:
> ("/gnu/store/qhz8n6mxzalifcrml6fwsvnxw92bk7n0-fmt-
> 9.1.0/lib/libfmt.so" "/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-
> gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-
> gnu/11.3.0/../../../libstdc++.so"
> "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libm.so"
> "/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-
> lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../../libgcc_s.so"
> "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/libc.so"
> "/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-
> lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../../libgcc_s.so")
> ld-wrapper: invoking `/gnu/store/zh4x65snfis7svs6906gj1z8i7dx2j3m-
> binutils-2.38/bin/ld' with ("--eh-frame-hdr" "-m" "elf_x86_64" "-pie"
> "-dynamic-linker" "//gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-
> glibc-2.35/lib/ld-linux-x86-64.so.2" "-o" "hello"
> "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/Scrt1.o"
> "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/crti.o"
> "/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-
> lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/crtbeginS.o" "-
> L/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-
> lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0" "-
> L/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib" "-
> L/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-
> lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../.." "-
> L/gnu/store/inpy5mz35fwvclynpag5gsp6d1hflfsz-meson-1.1.0/lib" "-
> L/gnu/store/qhz8n6mxzalifcrml6fwsvnxw92bk7n0-fmt-9.1.0/lib" "-
> L/gnu/store/j8wlfmlmfvpbza6is9wv9xsd8psrxn00-bzip2-1.0.8/lib" "-
> L/gnu/store/gr0sy0m1mv36qv54idm6cn10l3mngshq-file-5.44/lib" "-
> L/gnu/store/hc05d76f1j3iz3v2bs5jz4fpljl1r4dj-gawk-5.2.1/lib" "-
> L/gnu/store/6k1yys9wqrfn4y41ic1win8gpnimncwj-xz-5.2.8/lib" "-
> L/gnu/store/visfdda934gvivwihwhlm63fdqhhcc8a-glibc-utf8-locales-
> 2.35/lib" "-L/gnu/store/0irvg0gvvfwagdjckigvr4g8xap94y1j-clang-
> toolchain-18.1.5/lib" "hello.p/hello.cpp.o" "--as-needed" "--no-
> undefined" "-rpath=/gnu/store/g9wxj9a27jhnxa40zafh0ff33dd8906y-why-
> hello-0/lib" "-rpath" "/gnu/store/qhz8n6mxzalifcrml6fwsvnxw92bk7n0-
> fmt-9.1.0/lib" "-rpath-link"
> "/gnu/store/qhz8n6mxzalifcrml6fwsvnxw92bk7n0-fmt-9.1.0/lib" "--start-
> group" "/gnu/store/qhz8n6mxzalifcrml6fwsvnxw92bk7n0-fmt-
> 9.1.0/lib/libfmt.so" "--end-group" "-lstdc++" "-lm" "-lgcc_s" "-lgcc"
> "-lc" "-lgcc_s" "-lgcc" "/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-
> gcc-11.3.0-lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/crtendS.o"
> "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib/crtn.o"
> "-rpath" "/gnu/store/qhz8n6mxzalifcrml6fwsvnxw92bk7n0-fmt-9.1.0/lib"
> "-rpath" "/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-
> lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../.." "-rpath"
> "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib" "-rpath"
> "/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-
> lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../.." "-rpath"
> "/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib" "-rpath"
> "/gnu/store/l684qgqlrqkbsh8jffp9d8ag6vrpcwgs-gcc-11.3.0-
> lib/lib/gcc/x86_64-unknown-linux-gnu/11.3.0/../../..")
> 
> […]
> 
> starting phase `shrink-runpath'
> /gnu/store/g9wxj9a27jhnxa40zafh0ff33dd8906y-why-hello-0/bin/hello:
> stripping RUNPATH to ("/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-
> glibc-2.35/lib") (removed
> ("/gnu/store/g9wxj9a27jhnxa40zafh0ff33dd8906y-why-hello-0

bug#70926: Having default nss-certs plus nss-certs in operating-system packages causes problems

[Liliana Marie Prikler]

Am Montag, dem 13.05.2024 um 22:38 +0100 schrieb Christopher Baines:
> I've seen this when updating systems, but it seems like something is
> wrong with the handling of nss-certs.
> 
> I'm on a guix revision with nss-certs by default, and when I add
> nss-certs to my system packages (to simulate not removing it when
> upgrading), it breaks certificates (e.g. wget https://guix.gnu.org/
> doesn't work).
I can confirm this on three machines (two of my own, one from a
relative): Having nss-certs in the packages field unexpectedly breaks
all known certificates.

> My reading of the operating-system-packages code suggests that adding
> nss-certs shouldn't have any effect, but this doesn't seem to be
> working.
It would be really nice to detect the mismatching versions if it's
based on that.  IIUC we graft nss-certs now, so that we can hot-swap
stuff like pythons certifi package.  Is this use case broken by any
chance?

Cheers

bug#70581: PHP, glibc, and CVE-2024-2961

[Liliana Marie Prikler]

Hi McSinyx,

security-relevant bugs ought to go to , see [1].
Since a patch exists for glibc all the way back to 2.30, I suppose a
graft can be used and should be performed timely. 

Cheers

[1] https://guix.gnu.org/en/security/

bug#70349: Clang fails to communicate RUNPATH?

[Liliana Marie Prikler]

Hi Guix,

I've noticed a strange error when attempting to build my software
against clang-toolchain.  I've attached a minimally breaking example,
but the gist of it is that RUNPATH validation fails as shown below.

  starting phase `validate-runpath'
  validating RUNPATH of 1 binaries in
  "/gnu/store/sd1zjjf13mi448qbqaphhcvf9ap5jxji-why-hello-0/bin"...
  /gnu/store/sd1zjjf13mi448qbqaphhcvf9ap5jxji-why-hello-0/bin/hello:
  error: depends on 'libfmt.so.9', which cannot be found in RUNPATH
  ("/gnu/store/gsjczqir1wbz8p770zndrpw4rnppmxi3-glibc-2.35/lib")

Is this expected?  I know that the -for-system have historically
disregarded the existence of clang-toolchain and hence led to issues,
but I think this is something else…

Cheers
(use-modules (gnu packages pretty-print)
 (gnu packages pkg-config)
 (guix packages)
 (guix gexp)
 (guix transformations)
 (guix build-system meson)
 ((guix licenses) #:select (gpl3+))
 ((guix git-download) #:select (git-file-name))
 (srfi srfi-26))

(define why-hello
  (package
   (name "why-hello")
   (version "0")
   (source (file-union (git-file-name name version)
`(("hello.cpp" ,(plain-file "hello.cpp"
   "\
#include 

int
main()
{
  fmt::print (\"{}\\n\", \"Hello, world\");
  return 0;
}
"))
  ("meson.build" ,(plain-file "meson.build"
  "\
project('hello', 'cpp', default_options: ['cpp_std=c++20'])
executable('hello', files('hello.cpp'), install: true,
   dependencies: [dependency('fmt')])
")
   (build-system meson-build-system)
   (inputs (list fmt))
   (native-inputs (list pkg-config))
   (home-page (and=> (current-filename)
 (cute string-append "file://" <>)))
   (synopsis "Hello world")
   (description "This package provides a simple program that builds with
GCC/G++ normally, but fails miserably when the clang-toolchain is used.")
   (license gpl3+)))

(define why-hello-clang
  ((options->transformation
'((with-c-toolchain . "why-hello=clang-toolchain")))
   why-hello))

why-hello-clang

bug#70278: udevd[87]: specified group 'sgx' unknown

[Liliana Marie Prikler]

Am Donnerstag, dem 11.04.2024 um 09:58 +0200 schrieb Ludovic Courtès:
> Ludovic Courtès  skribis:
> 
> > Since the recent ‘gnome-team’ merge, we get this message at boot
> > time:
> > 
> >   udevd[87]: specified group 'sgx' unknown
> > 
> > Should we add ‘sgx’ to ‘%base-groups’?  (What is it for?)
> 
> Cc’ing Vivien & Liliana who might know more about this.
This seems related to Intel's Software Guard eXtensions, or, as we in
the free world like to call them Security paper Generator eXtensions. 
As far as I'm aware, these ought to be disabled anyway, and we might
want to drop the offending lines.  According to [1], there's only two
of them anyway.

Cheers

[1] https://wiki.linuxfromscratch.org/lfs/ticket/5265

bug#70165: D-Bus system service breaks reconfiguration when /var/run/dbus is present + /run and /var/run are on separate file systems.

[Liliana Marie Prikler]

Am Freitag, dem 05.04.2024 um 09:53 +0800 schrieb Hilton Chain:
> [H]ere's a reproducer:
> 
> --8<---cut here---start->8---
> test_dir="$(mktemp --directory)"
> 
> sudo mount --type tmpfs none "$test_dir"
> touch "$test_dir/test"
> 
> guile -c "(rename-file \"$test_dir/test\" \"/tmp/test\")"
> 
> sudo umount "$test_dir"
> rmdir "$test_dir"
> --8<---cut here---end--->8---
> 
> --8<---cut here---start->8---
> Backtrace:
> In ice-9/boot-9.scm:
>   1752:10  6 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
>    5 (apply-smob/0 #)
> In ice-9/boot-9.scm:
>     724:2  4 (call-with-prompt ("prompt") #
> …)
> In ice-9/eval.scm:
>     619:8  3 (_ #(#(#)))
> In ice-9/command-line.scm:
>    185:19  2 (_ #)
> In unknown file:
>    1 (eval (rename-file "/tmp/tmp.9wyzRfQ28l/test" "/tmp/…")
> #)
>    0 (rename-file "/tmp/tmp.9wyzRfQ28l/test" "/tmp/test")
> 
> ERROR: In procedure rename-file:
> In procedure rename-file: Invalid cross-device link
> --8<---cut here---end--->8---
If I understand this reproducer correctly, there aren't even symbolic
links involved, are there?

Adding Ludo to CC, because this looks like a Guile bug to me.

Cheers

bug#70111: [PATCH] gnu: gnome-essential-extras: Propagate xdg-desktop-portal.

[Liliana Marie Prikler]

Am Mittwoch, dem 03.04.2024 um 14:11 -0400 schrieb Maxim Cournoyer:
> Hello,
> 
> Dariqq  writes:
> 
> > xdg-desktop-portal (and xdg-desktop-portal-gnome) is needed for the
> > dark theme in Gnome 44 to work properly.
> > 
> > * gnu/packages/gnome.scm (gnome-essential-extras)[propagated-
> > inputs]: Add xdg-desktop-portal.
> > 
> > Change-Id: Id84626e6bc404e9607ee7f8f299ac90f24323081
> 
> Reviewed-by: Maxim Cournoyer 
> 
> Haven't tested it myself, but I trust the findings of Dariqq.
The desktop portal seems like a harmless propagation, so I trust your
trust.

Pushed.

bug#70165: D-Bus system service breaks reconfiguration when /var/run/dbus is present + /run and /var/run are on separate file systems.

[Liliana Marie Prikler]

Am Donnerstag, dem 04.04.2024 um 00:36 +0800 schrieb Hilton Chain:
> Hi,
> 
> I have /var/run and /run on separate file systems, recently I noticed
> system reconfiguration stopped with "guix system: error: rename-file:
> Invalid cross-device link":
> 
> --8<---cut here---start->8---
> newfstatat(AT_FDCWD, "/run", {st_mode=S_IFDIR|0755, st_size=440,
> ...}, AT_SYMLINK_NOFOLLOW) = 0
> newfstatat(AT_FDCWD, "/run/dbus", {st_mode=S_IFDIR|0700, st_size=40,
> ...}, AT_SYMLINK_NOFOLLOW) = 0
> mkdir("/run", 0777) = -1 EEXIST (File exists)
> mkdir("/run/dbus", 0777)    = -1 EEXIST (File exists)
> chown("/run/dbus", 988, 983)    = 0
> chmod("/run/dbus", 0755)    = 0
> symlink("/run/dbus", "/var/run/dbus")   = -1 EEXIST (File exists)
> readlink("/var/run/dbus", 0x1634730, 100) = -1 EINVAL (Invalid
> argument)
> openat(AT_FDCWD, "/var/run/dbus",
> O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 17
> newfstatat(17, "", {st_mode=S_IFDIR|0755, st_size=80, ...},
> AT_EMPTY_PATH) = 0
> getdents64(17, 0x16dfe10 /* 4 entries */, 32768) = 112
> rename("/var/run/dbus/system_bus_socket",
> "/run/dbus/system_bus_socket") = -1 EXDEV (Invalid cross-device link)
> close(13)   = 0
> write(2, "\33[1m\33[0mguix system: error: rena"..., 67guix
> system: error: rename-file: Invalid cross-device link
> ) = 67
> exit_group(1)   = ?
> +++ exited with 1 +++
> --8<---cut here---end--->8---
> 
> It's because /var/run/dbus was used for dbus service before, and now
> migration to /run/dbus is done with ‘rename-file’:
> 
> --8<---cut here---start->8---
> (rename-file (string-append "/var/run/dbus/" next)
>  (string-append "/run/dbus/" next))
> --8<---cut here---end--->8---
> 
> I think the logic can be improved for this case, but not sure how at
> the moment.
> What do you think?
Is there a *good* reason to have those be separate file systems? :D
What does the FHS say?

Anyhow, cross-fs symlinks and rename-file ought to work assuming that
both file-systems are already mounted.  Is one of them not needed for
boot?

Cheers

bug#70121: [PATCH] gnu: emacs-magit: Fix generation of autoloads.

[Liliana Marie Prikler]

* gnu/packages/emacs-xyz.scm (emacs-magit)[#:phases]: Replace ‘make-autoloads’
like the others.

Fixes: Magit autoloads are missing 
---
 gnu/packages/emacs-xyz.scm | 4 
 1 file changed, 4 insertions(+)

diff --git a/gnu/packages/emacs-xyz.scm b/gnu/packages/emacs-xyz.scm
index 975b26813a..f47f5fcb8a 100644
--- a/gnu/packages/emacs-xyz.scm
+++ b/gnu/packages/emacs-xyz.scm
@@ -1668,6 +1668,10 @@ (define-public emacs-magit
   (lambda args
 (with-directory-excursion "lisp"
   (apply (assoc-ref %standard-phases 'expand-load-path) 
args
+(replace 'make-autoloads
+  (lambda args
+(with-directory-excursion "lisp"
+  (apply (assoc-ref %standard-phases 'make-autoloads) args
 (replace 'install
   (lambda args
 (with-directory-excursion "lisp"

base-commit: 4d79a9cd6b5f0d8c5afbab0c6b70ae42740d5470
prerequisite-patch-id: c275e4e44896c8ab96e5cc9557ec5dc522d62fd0
prerequisite-patch-id: 1675bb658c90730025a744f7869a3566fb5cf41a
prerequisite-patch-id: 9c02fe03b70a5312cc982fd4b48e73e889a9afdf
-- 
2.41.0

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

[Liliana Marie Prikler]

Am Samstag, dem 23.03.2024 um 11:15 +0100 schrieb Liliana Marie
Prikler:
> Am Samstag, dem 23.03.2024 um 10:07 +0100 schrieb Vivien Kraus:
> > * gnu/packages/kde-frameworks.scm (kcalendarcore) [#:phases]: Add
> > 'disable-failing-test.
> > 
> > Change-Id: Ia0a5828b032d1940f30a7d38ebd276e60929c310
> > ---
> LGTM
Also LGT cbaines on IRC, so pushed.

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

[Liliana Marie Prikler]

Am Samstag, dem 23.03.2024 um 10:07 +0100 schrieb Vivien Kraus:
> * gnu/packages/kde-frameworks.scm (kcalendarcore) [#:phases]: Add
> 'disable-failing-test.
> 
> Change-Id: Ia0a5828b032d1940f30a7d38ebd276e60929c310
> ---
LGTM

bug#59489: [PATCH v3] gnu: gdm: Enable accessibility settings.

[Liliana Marie Prikler]

Am Dienstag, dem 20.02.2024 um 19:58 + schrieb Dariqq:
> gdm needs the "/share" subdirectory of these packages present in
> XDG_DATA_DIRS
> such that the accessibility settings work:
> - at-spi2-core: contains accessibility dbus service.
> - dconf: To be able to change settings.
> - gnome-control-center: icon.
> 
> * gnu/packages/gnome.scm (gdm)[inputs]: Add at-spi2-core, dconf,
> gnome-control-center.
> [phases]: Add wrap-accessibility-dependencies phase.
> 
> Change-Id: Ibfe8f1aee9c8fe0c06f895de121f0f84defe4773
> ---
I've rewritten the commit message slightly and pushed this to gnome-
team.  Thus closing.

Cheers

bug#69201: Emacs master-branch renamed comp-write-bytecode-file which emacs-utils depends on

[Liliana Marie Prikler]

Am Donnerstag, dem 15.02.2024 um 22:23 + schrieb Mekeor Melire:
> On Emacs' master-branch, the emacs-lisp function
> comp-write-bytecode-file has been renamed to comp--write-bytecode-
> file (i.e. to include a double dash) in this commit [1]:
> 
>     faa46eb8667c11a0725500a50e957eb78021c99f
>     Author: Andrea Corallo 
>     AuthorDate: Sun Feb 11 12:31:13 2024 +0100
>     Commit: Andrea Corallo 
>     CommitDate: Sun Feb 11 15:26:12 2024 +0100
> 
>     Rename a number of native compiler functions
> 
> Guix' function emacs-compile-directory from module (guix build
> emacs-utils) [2] depends on this emacs-lisp function.
> 
> Thus, when emacs-next-minimal is build from the above mentioned
> commit or later, it won't be possible to build packages that use
> emacs-build-system, when using
> --with-input=emacs-minimal=emacs-next-minimal, or in Guile code,
> argument "#:emacs emacs-next-minimal". This might be considered to be
> a minor issue as of right now.
> 
> It'll become a more general problem, when Emacs 30 is released.
Thanks for the heads-up.  Assuming the calling convention stays the
same, this should be easy to work around (using fboundp and resolving
to the right symbol).  Unfortunately, I have other work to experiment
on emacs-team right now, so if you find this pressing, I encourage you
to submit your own patch (against emacs-team, for the particular
procedure in emacs-utils).

Cheers

bug#59489: bug#57292: [PATCH] WIP: gnu: propagate inputs for gdm and rework gdm-service-type.

[Liliana Marie Prikler]

Am Freitag, dem 09.02.2024 um 22:06 -0500 schrieb Maxim Cournoyer:
> Could someone confirm whether GDM is configurable when it comes to
> icons and fonts?
Without the context of Guix, it is.  Within the context of Guix, we'd
have to make gsettings functional for most (all?) changes to have an
effect.

Cheers

bug#68961: ASLR seems to be partially broken

[Liliana Marie Prikler]

Am Dienstag, dem 06.02.2024 um 23:57 +0100 schrieb Jonathan Brielmaier:
> Hi,
> 
> I found today an interesting blog post about broken ASLR (Address
> Space
> Layout Randomization) on Linux:
> https://zolutal.github.io/aslrnt/
> 
> Curious if this is also a problem on Guix System I did a quick test.
> 
> ```
> $ cat aslr.py
> from subprocess import check_output
> result = 0x0
> for _ in range(0,1000):
>  out = check_output("cat /proc/self/maps | grep libc | head -n1",
> shell=True).decode()
>  base_address = int(out.split('-')[0], 16)
>  result |= base_address
> print('libc: ' + hex(result))
> 
> resultld = 0x0
> for _ in range(0,1000):
>  out = check_output("cat /proc/self/maps | grep ld-linux | head
> -n1", shell=True).decode()
>  base_address = int(out.split('-')[0], 16)
>  resultld |= base_address
> print('ld-linux: ' + hex(resultld))
> ```
> 
> Running this on x86_64 system of mine results on two systems in:
> libc: 0x7ffa9000
> ld-linux: 0x7000
> 
> On the third system it prints:
> libc: 0x7000
> ld-linux: 0x7000
On my machine, this also prints 0x7000.  Perhaps 1000 runs are
not good enough to get truly random results with some RNGs.  Note that
we do have 51 bits of randomness here – perhaps not ideal, but afaik
the best we can do without breaking alignment.

> For 32bit it looks even worse (not sure if it's correct to test it
> like
> this):
> $ guix shell --system=i686-linux coreutils python -- python3 aslr.py
> libc: 0xf780
> ld-linux: 0xf7fff000
> 
> Not sure what we should do here. There seem to be some a kernel patch
> for Ubuntu available:
For 32 bit, try 
```
from subprocess import check_output
result = 0x
for _ in range(0,1000):
 out = check_output("cat /proc/self/maps | grep libc | head -n1",
shell=True).decode()
 base_address = int(out.split('-')[0], 16)
 result &= base_address
print('libc: ' + hex(result))

resultld = 0x
for _ in range(0,1000):
 out = check_output("cat /proc/self/maps | grep ld-linux | head -
n1", shell=True).decode()
 base_address = int(out.split('-')[0], 16)
 resultld &= base_address
print('ld-linux: ' + hex(resultld))
from subprocess import check_output
result = 0x
for _ in range(0,1000):
 out = check_output("cat /proc/self/maps | grep libc | head -n1",
shell=True).decode()
 base_address = int(out.split('-')[0], 16)
 result &= base_address
print('libc: ' + hex(result))

resultld = 0x
for _ in range(0,1000):
 out = check_output("cat /proc/self/maps | grep ld-linux | head -
n1", shell=True).decode()
 base_address = int(out.split('-')[0], 16)
 resultld &= base_address
print('ld-linux: ' + hex(resultld))
```
instead.  I get 0xf7c0 for libc and 0xf7e0 – meaning that the
first nibble is always the same, but more importantly, these are also
the addresses you'd get on each run.  So I'm pretty sure that ASLR'nt
applies to our 32 bit builds.

Since this is a known bug in the Linux kernel, I'd like to check
whether there's a fix we can backport.  We could of course also patch
our config aux-files like Ubuntu does in the meantime.

Cheers

bug#68912: Guix-home search paths shadow .config/guix/current

[Liliana Marie Prikler]

Am Samstag, dem 03.02.2024 um 13:12 + schrieb Christina O'Donnell:
> This leads to unexpected results if you have Guix inside your home 
> package list. (Which you might desire if you wanted to use Guix in a 
> home container.)
The wisdom "One does not simply 'guix install guix'" has been passed
around for ages.  Same applies to home configurations, which merely
mimic that aspect.  There are valid reasons for using Guix in temporary
shells (or home containers), but also many pathological uses.

> [T]he situation is preventable and undesirable and there's several
> possible solutions:
> 
>   1. Reorder the paths by default, keeping ~/.config/guix in front of
> ~/.guix-home
As far as I know, this requires changing the order in which files are
sourced, and it's not clearly desirable that ~/.config/guix ought to
shadow ~/.guix-home or ~/.guix-profile.  In particular, whenever you
use `guix shell` or similar, you will shadow that anyway.

>   2. Have `guix home` warn when 'guix' is included as a package
This might be fine, but what about the home container use-case then? 
I'm not sure whether having no guix in containers is preferable over
having a slightly outdated one – at the very least, my personal usage
of GWL through `guix shell' is enough reason to keep guix visible as a
package.

>   3. Have `guix pull` warn when Guix is shadowed and unable to be
> updated
This would (at least in a naive version) print a weird warning on fresh
setups, where the not yet created local ~/.config/guix is not yet on
PATH.  As far as I know, this would be doable, though, if you're smart
enough about it.

> (Incidentally, how did gzip and coreutils get in there? I didn't put
> it there.)
These might have been added by the home container for reason
unbeknownst to me.

> hint: After setting `PATH', run `hash guix' to make sure your shell 
> refers to `/home/cdo/.config/guix/current/bin/guix'.
Hint: this is the warning you're looking for.  It's phrased as a hint,
because people typically only encounter it once during setup.

Cheers

bug#68982: Ren'py 8.2.0 Crash on startup

[Liliana Marie Prikler]

Am Mittwoch, dem 07.02.2024 um 14:38 -0600 schrieb msglm:
> When starting the ren'py launcher on version Ren'Py 8.2.0.24012702,
> currently my guix channel is on commit
> 5d2302a1959d09e6d5a5f02ac199458095847a82, the program crashes with
> the following error:
> 
> Full traceback:
>   File "/gnu/store/2m851i42kc8i929rfhrn6w545w6a94lz-python-renpy-
> 8.2.0/lib/python3.10/site-packages/renpy/bootstrap.py", line 354, in
> bootstrap
>     renpy.config.logdir = renpy.__main__.path_to_logdir(basedir)
> AttributeError: module '__main__' has no attribute 'path_to_logdir'
If you have a local guix checkout, try adding the following lines to
gnu/packages/aux-file/renpy.in:

  def path_to_logdir(basedir):
  return basedir

However, it seems upstream also has a predefined_searchpath added in
8.2, and changed the semantics of path_to_saves.  I think we might want
to revert to 8.1 to deal with all those changes properly.

Cheers 

bug#59489: bug#57292: [PATCH] WIP: gnu: propagate inputs for gdm and rework gdm-service-type.

[Liliana Marie Prikler]

Am Montag, dem 05.02.2024 um 16:08 + schrieb Dariqq:
> 
> On 04.02.24 20:26, Liliana Marie Prikler wrote:
> 
> > Yes, it seems Maxim and I have conflicting goals.  Maxim wants to
> > avoid "abusing" gnome-shell-assets whereas I want to avoid
> > propagation, as it pollutes profiles.  Perhaps Maxim and I can
> > agree on how to interpret gnome-shell-assets, as IIUC even with
> > packages that aren't "pure data" only the data portion of it ought
> > to be relevant, no?
> > 
> > We should do so especially because the newly propagated variables
> > are anyhow propagated by gnome-desktop-service, which could
> > constitute weird behaviour all around.
> > 
> > Cheers
> 
> What would you think of the wrap-program solution which would avoid 
> propagating pacakges?
> 
> I currently have something like
> 
> #+BEGIN_SRC scheme
> (add-after 'install 'wrap-gdm
>  (lambda* (#:key inputs outputs #:allow-other-keys)
>    (wrap-program (string-append #$output "/bin/gdm")
>  `("XDG_DATA_DIRS" ":" prefix
>    #$(map (lambda (input)
>    (file-append (this-package-input input) 
> "/share"))
>  '("at-spi2-core"
>    "dconf"
>    "gnome-control-center"))
> #+END_SRC
> 
> Also this way the assets (adwaita and cantarell) should be kept in
> the gdm-configuration as when I tested this I had a white box as a
> cursor.
That SGTM, but we do need a more descriptive phase name.  The question
is whether we should inline the gnome-shell assets this way as well or
not.

Maxim, WDYT?

bug#59489: bug#57292: [PATCH] WIP: gnu: propagate inputs for gdm and rework gdm-service-type.

[Liliana Marie Prikler]

Am Sonntag, dem 04.02.2024 um 08:53 + schrieb Dariqq:
> 
> On 30.01.24 06:27, Liliana Marie Prikler wrote:
> 
> > In my opinion, adding gnome-shell and gnome-control-center to gdm-
> > configuration-gnome-shell-assets would be preferable to propagating
> > inputs.
> > 
> > WDYT?
> 
> 
> This is basically my original patch in
> https://issues.guix.gnu.org/57292#3.
> 
> If i understand it correctly Maxim wants gdm to take care of all of 
> dependencies providing functionality and handcrafting the environment
> with gdm-shepherd-service and gdm-configuration-gnome-shell-assets
> feels like a hacky workaround.
Yes, it seems Maxim and I have conflicting goals.  Maxim wants to avoid
"abusing" gnome-shell-assets whereas I want to avoid propagation, as it
pollutes profiles.  Perhaps Maxim and I can agree on how to interpret
gnome-shell-assets, as IIUC even with packages that aren't "pure data"
only the data portion of it ought to be relevant, no?

We should do so especially because the newly propagated variables are
anyhow propagated by gnome-desktop-service, which could constitute
weird behaviour all around.

Cheers

bug#57292: [PATCH] WIP: gnu: propagate inputs for gdm and rework gdm-service-type.

[Liliana Marie Prikler]

Am Montag, dem 29.01.2024 um 21:31 + schrieb Dariqq:
> * gnu/packages/gnome.scm (gdm)[propagated inputs]: Add adwaita-icon-
> theme,
> dconf, font-abattis-cantarell, gnome-control-center.
> * gnu/services/xorg.scm (gdm-shepherd-service): Set XDG_DATA_DIR to
> run/current-system/profile/share.
> (gdm-profile-service): New variable.
> (gdm-service-type): Use gdm-profile-service.
> (gdm-configuration-gnome-shell-assets): Set default to gnome-shell.
> 
> Change-Id: I870206a9ee6a7481d19e6b38b6a3ee72b5801c6a
> ---
> Hi Maxim and others,
> This is not quite the explicit wrapper we talked about on IRC but
> something similiar.
> 
> The gdm package now propagates the packages from gnome-shell-assets
> and I added dconf and gnome-control-center for basic accessibility
> settings functionality + icon. Does this introduce a problem as dconf
> is already a natice input?
> Maybe also some other packages can be added like  at-spi2-core, orca,
> ... or is this something the user should add to the system profile
> themselves?
> 
> In order for the gdm-shepherd-service to find the propagated packages
> I changed the XDG_DATA_DIR of the service to the system profile and
> added a gdm-profile-service to add gdm and gnome-shell to the system
> profile. Probably the gnome-shell-assets name should now also be
> changed as is is now only the gnome-shell package.
> 
> What do you think?
In my opinion, adding gnome-shell and gnome-control-center to gdm-
configuration-gnome-shell-assets would be preferable to propagating
inputs.

WDYT?

bug#68231: Frei?

[Liliana Marie Prikler]

close 68231
thanks

Hallo, Enzo

Am Dienstag, dem 02.01.2024 um 23:11 +0100 schrieb Enzo Brandsch:
> ich bin leider aus Gründen „gezwungen“ unfreie Software auf meinem
> Laptop zu nutzen. Würde aber sehr sehr gerne Guix als daily-driver
> nutzen. [...]
> PS: Mein Problem ist ein Intel Wifi Treiber. Laptop ist ein ThinkPad
> Yoga. Ich habe bis jetzt immer Arch benutzt werde aber nun bis Guix
> meine WLAN-Karte erkennt Clear nutzen.
Es ist meines Wissens (und leider auch Erfahrung) nach möglich, einen
Laptop ohne WLAN-Karte zu betreiben.  Freilich ist das etwas
umständlicher, weil du dich dann nach herumliegenden Ethernet-Kabeln
umsehen musst, aber je nachdem wofür du diesen Laptop verwendest,
sollte es möglich sein, eine Kabelverbindung z.B. zum Betriebsnetz
aufzubauen.

Du könntest auch, so dein Laptop es zulässt, eine freie WLAN-Karte oder
einen Adapter benutzen.  Generell empfehlenswert ist RYF-zertifizierte
Hardware, z.B. [1], aber auch andere Seiten können dir helfen, in
Erfahrung zu bringen, wie gut bestimmte Komponenten mit freier Software
funktionieren. 

> Wäre es für solche Fälle möglich auch unfreie Software zuzulassen?
> Ich kenne mich etwas mit Linux aus habe mir aber noch nie Lizenzen
> angesehen und werde vermutlich in naher Zukunft auch kein Auge darauf
> werfen.
Die GNU FSDG [2], an der wir uns orientieren, ist diesbezüglich sehr
eindeutig: 
  A free system distribution must not steer users towards obtaining any
  nonfree information for practical use, or encourage them to do so.
Zu Deutsch:
  Eine freie Systemdistribution darf Nutzer·innen weder dazu verleiten,
  unfreie Information für den praktischen Gebrauch zu erhalten, noch 
  sie darin unterstützen.

Zum Punkt WLAN-Karte weiters
  Some applications and drivers require firmware to function, 
  and sometimes that firmware is distributed only in object code 
  form, under a nonfree license. [...] [N]o matter how it's encoded,
  any nonfree firmware needs to be removed from a free system.

Zu Deutsch:
  Einige Anwendungen oder Treiber benötigen „Firmware“, um   
  zu funktionieren, und diese Firmware ist manchmal nur als Objekt-Code
  unter einer nichtfreien Lizenz vorhanden.  [...] [A]ber egal, in
  welcher Form diese nichtfreie Firmware aufliegt, sie muss von einem
  freien System entfernt werden.

> Als Kompromiss könnte man ja zum installieren von unfreier Software
> mehrere Schritte hinzufügen welche sicherstellen das man unfreie
> Software installieren möchte/muss.
Dieser Kompromiss gilt tatsächlich auf Festen zur Installierung von
Linux-Distributionen [3], nicht aber (wie hier) auf zum GNU-Projekt
gehörenden öffentlichen Mailing-Listen, oder IRC-Kanälen.  Auf solchen
Plattformen sind Diskussionen über nichtfreie Software zu unterlassen.

Liebe Grüße,
Liliana

[1] https://ryf.fsf.org/categories/wireless-adapters
[2] https://www.gnu.org/distros/free-system-distribution-guidelines.html
[3] https://www.gnu.org/philosophy/install-fest-devil.html

bug#66173: Package unknown-horizons fails during build process

[Liliana Marie Prikler]

Am Samstag, dem 13.01.2024 um 10:50 -0500 schrieb Simon South:
> Liliana, 宋文武:
> 
> Are you interested in reviewing these patches?  Unfortunately I
> neglected to CC the games team when posting them.
> 
> They fix the build of Unknown Horizons in master.
> 
> https://issues.guix.gnu.org/66173
> 
> -- 
I came, saw, and pushed.

Sorry for not coming earlier.

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

[Liliana Marie Prikler]

Am Dienstag, dem 09.01.2024 um 12:10 +0100 schrieb Vivien Kraus:
> Dear Guix,
> 
> [...]
I know that a bunch of packages have reasons not to exist in Guix, I
simply wanted to point out that we don't have them.

> > I think we should settle on what to do with the gnome package soon
> > to not stall the branch even further.  We can already start working
> > towards GNOME 46 after the merge :)
> In my opinion, we should have atkmm:2.28.3, but I see atkmm-2.28
> being used as a propagated-inputs for gtkmm-3, and gtkmm-3 is an
> input for inkscape. That’s a world rebuild…
> 
> For Cantarell fonts, maybe we should point to the latest commit?
> That’s another world rebuild though, and for very little gain as of
> now.
> 
> I’m not sure a flatpak-only gnome software is a hard requirement. It
> would be most confusing. Gnome-tour is nice, but I think we can live
> without it until we figure out this “rust” stuff.
With "the gnome package" I mean the gnome metapackage that made you
raise this issue.

> > There is some gnome-adjacent software (particularly extensions, I
> > don't want all of them to break like they did the last time and the
> > time before) to have a look at as well before the merge
> 
> You mean, the gnome-shell-extension-* in (gnu packages gnome-xyz)? I
> don’t use them (I was told they were frequently broken so I never
> bothered to try them!) so I’m not sure I can reliably tell whether
> they work correctly.
They tend to get broken with each gnome update, but I'm here to change
that.  Testing them is actually quite simple: construct a guix system
vm with a gnome that has all the extensions, run it, then enable all of
them one by one in the GUI.  If there's a version incompatibility, you
will notice.

Cheers

bug#68243: alacritty segmentation fault

[Liliana Marie Prikler]

Am Donnerstag, dem 04.01.2024 um 15:32 + schrieb Steven Roose:
> I've been using alacritty as my default terminal for about a year 
> without much issues. I'm currently on v0.12.3 of alacritty and use it
> with i3 and Xorg. A month or two ago I noticed that upgrading GuixSD 
> broke alacritty. Since it's my main terminal and I didn't have any
> other terminals installed, I was forced to rollback my system through
> GRUB because I couldn't literally not even open a terminal to
> investigate or roll-back by CLI. I was trying another system upgrade
> now and noticed the issue is still not fixed. When running alacritty
> from an already-open alacritty only shows me "segmentation fault".
> The working and broken version is both 0.12.3, so I think it might
> not be an alacritty issue but more a linking/build issue. I'm
> basically stuck on a months-old Guix until this is fixed.
> 
> If there is any way I can be of use by providing debug/log files of
> some kind, please let me know.
I suppose this might be related to the mesa update we had some while
ago.  I myself noticed that GNOME 4 apps stopped working due to some
very, very weird behaviour of the driver that I still don't comprehend.
Anyway, switching to the cairo renderer per environment variable worked
for me.  Perhaps there's something similar you can do for alacritty (or
otherwise switch back to the older mesa with an inferior/use any other
VTE for the time being).

Cheers

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

[Liliana Marie Prikler]

Am Dienstag, dem 05.12.2023 um 21:55 +0100 schrieb Vivien Kraus:
> Dear guix,
> 
> On the one hand, we have this list of packages:
> https://ftp2.nluug.nl/windowing/gnome/teams/releng/44.6/versions
For the record, we have a new 44 release:
https://ftp2.nluug.nl/windowing/gnome/teams/releng/44.7/versions

I've summarised our TODOs below: Each commented line (preceded by #)
denotes a package that doesn't exist on the gnome-team branch yet.

core:atkmm:2.28.3:
#core:calls:44.2:
core:font-abattis-cantarell:0.303.1:
core:epiphany:44.7:
#core:gnome-logs:43.0:
#core:gnome-software:44.5:
#core:gnome-tour:44.0:

I think we should settle on what to do with the gnome package soon to
not stall the branch even further.  We can already start working
towards GNOME 46 after the merge :)

There is some gnome-adjacent software (particularly extensions, I don't
want all of them to break like they did the last time and the time
before) to have a look at as well before the merge, but it looks like a
nice road ahead.

We can do this!

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

[Liliana Marie Prikler]

Hi Vivien,

Am Dienstag, dem 05.12.2023 um 21:55 +0100 schrieb Vivien Kraus:
> Dear guix,
> 
> On the one hand, we have this list of packages:
> https://ftp2.nluug.nl/windowing/gnome/teams/releng/44.6/versions
> 
> On the other hand, we have the propagated-inputs of the gnome
> package.
> 
> Should we update the latter so that it contains everything from the
> former? 
No.

> What should we do about the comments dividing the propagated-
> inputs into categories? Where do these categories come from? 
The categories are roughly inferred from a previous categorisation of
GNOME Apps.  It is a little arcane and should probably be updated to
reflect  (roughly).  Note that we'll
still be using the Core Apps from GNOME 44, which are listed in [1].
 
> Should we preserve them? How do we know which package goes to which
> category?
We should try to update them and better keep with upstream terms.  I
think it also makes sense to split the gnome meta-package into multiple
meta packages and adjust the gnome-desktop service accordingly.  For
one, we do need a gnome-shell-meta that has everything required to get
a running gnome-shell, even without any of the other core applications.
Then, gnome-core-main, gnome-core-mobile and gnome-core-tools could
hold the main, mobile and developer tools in the core apps
respectively.

> The gnome package disables eog on 32-bit machines because it depends
> on librsvg-next. It seems a bit outdated to me, as most of gnome
> won’t work on 32-bit machines, not only eog. Should we try and find
> which ones work on 32-bit systems?
Seeing how GNOME 45 deprecates eog in favour of loupe, yet another
bootstrap and build system nightmare, we should anyhow look into what's
buildable on 32-bit machines and offer suitable replacements.  I'm very
much a proponent of reducing the amount of software on our GNOME stack,
not piling yet another heap of checksums onto it and calling dependency
management done.

Cheers

[1] https://blogs.gnome.org/mcatanzaro/2023/05/10/gnome-core-apps-update/

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#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 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#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#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#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#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 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 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 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 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#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#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#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#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#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: e863274e67e2242b970845783172c9f4

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: [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#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#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#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 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#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#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]

* 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 ha

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 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#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 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#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 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#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 (&optional 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 (&optional 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#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 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 (&optional reload)
  "..."
  (interactive "P")
  (when reload (mapc #'load-file (guix-emacs--subdirs-files)))
  ...)

WDYT?

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#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&id=e43498b32dcbbf055d72339086213cd60c336acf