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#73700: python-django executable unable to find 'django' module

[Gabriel Wicki]

Running

guix shell python-django -- django-admin

throws a "ModuleNotFoundError: No module named 'django'".

bug#56389: ruby-nokogiri may be non-deterministic

[Żelazny Wiktor via Bug reports for GNU Guix]

On Fri, Oct 07, 2022 at 08:54:25AM +0200, wzela...@vurv.cz wrote:

> The 1.10.9 comes with the TODO
>
>;; TODO: In the next rebuild cycle, provide texlive a version of ruby-hydra
>;; that does not depend on byebug and rspec, so that their dependencies can
>;; be updated more freely.  For now pin this version to avoid rebuilds.

Apparently, this is what happened, as ruby-nokogiri@1.10.9 is not in
Guix, anymore.

Closing.

WŻ

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

[Martin Edström]

On Tue, 08 Oct 2024 06:32:32 +0200, Liliana Marie Prikler 
 wrote:

> 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.

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.

What I'm getting from this is that it might be safer to just compile the object 
into /tmp and use that, regardless of what may already exist.  At the moment, 
that's necessary for keeping the option open of using an .eln on Guix.

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.

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.

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?

bug#73680: privileged-programs: cant set setuid/setgid to new accounts/groups

[Dariqq]

I downloaded the latest iso 
(https://ci.guix.gnu.org/build/6060923/details from yesterday) and tried 
to install opensmtpd in there.


After the reconfigure i got the 'failed to privilege : Success' 
warning but upon reboot things were working.


I think I know what is happening now:

The *first* time we try to privilege something it fails because the 
group does not yet exist. After a reboot it is succeeeding because it is 
using the group info from the previous boot, because that has not been 
recreated yet.


This seems to work for groups because the getgrnam error "group does not 
exist" is a 'system-error being caught by the exception handler, while 
the getpwnam-error "user does not exist" is a 'misc-error instead, 
causing a backtrace which aborts further activation scripts (that would 
create the user)


As a simple workaround we could catch the getpwnam error too but this is 
not really solving anything and relies on previous state which might be 
incorrect. This is also really fragile.



Another idea would be to run the account+user creating scripts as early 
as possible. Or as a more thorough solution model the dependency on 
users/groups directly to enforce the ordering (might be problematic 
because some activation scripts also requrie a user/group to set 
permissions which would make the extension graph not acyclic (accounts 
-> activation -> accounts). Maybe this is doable with a more minimal 
accounts service that only knows about users/group names?


I am surprised this has not been causing issues earlier as also a lot of 
direct activation-extensions set ownership on directories (that this 
works seems like a lucky coincidence in how 
service-extension/service-folding works rather than a design consideration).

bug#73700: Acknowledgement (python-django executable unable to find 'django' module)

[Gabriel Wicki]

The following is an obvious, simple fix.  I am not sure how others
regard the issue at hand i would summarize as usability vs. disk-space.
IMHO usability - or shipping broken executables - should be prioritized
before saving some hundred megabytes.

>From 5601bbf93baf65e1f6902bf678acb9dddb9e98f1 Mon Sep 17 00:00:00 2001
Message-ID: 
<5601bbf93baf65e1f6902bf678acb9dddb9e98f1.1728384174.git.gabr...@erlikon.ch>
From: Gabriel Wicki 
Date: Tue, 8 Oct 2024 12:41:14 +0200
Subject: [PATCH] gnu: python-django: Fix broken django-admin executable.

* gnu/packages/django.scm (python-django) [phases]: Un-delete 'wrap phase.

Change-Id: If8c3c7f7396e7865a7c0ea662845b228984a4789
---
 gnu/packages/django.scm | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/gnu/packages/django.scm b/gnu/packages/django.scm
index 4404c8368d..d0e331e0aa 100644
--- a/gnu/packages/django.scm
+++ b/gnu/packages/django.scm
@@ -98,13 +98,7 @@ (define-public python-django-4.2
;; Tests expect PYTHONPATH to contain the root directory.
(setenv "PYTHONPATH" "..")
(apply invoke "python" "runtests.py" test-flags))
- (format #t "test suite not run~%"
- ;; XXX: The 'wrap' phase adds native inputs as runtime dependencies,
- ;; see .  The django-admin script 
typically
- ;; runs in an environment that has Django and its dependencies on
- ;; PYTHONPATH, so just disable the wrapper to reduce the size from
- ;; ~710 MiB to ~203 MiB.
- (delete 'wrap
+ (format #t "test suite not run~%")))
 ;; TODO: Install extras/django_bash_completion.
 (native-inputs
  (list tzdata-for-tests

base-commit: d44beb9b4ad836781928a0c5667e94c0d6df13f0
-- 
2.45.2