bug#57374: transmission non-gui output still pulls in GTK+

[Csepp]

like the subject says, i noticed it when running `guix shell
transmission` on a server.

bug#56444: Patch to fix Gitolite home directory permissions

[Thompson, David]

Hi Maxime,

On Tue, Aug 23, 2022, 8:41 AM Maxime Devos  wrote:

>
> During "guix system reconfigure", there is now window where the
> directory temporarily has incorrect bits and hence if gitolite is
> restarted during that time it will presumably fail.  Could a
> 'home-permission-bits' or such field be added instead to 
> to make things atomic?
>

That would be a nice improvement to backlog now that such a use case has
emerged. However, I think for our immediate needs this one line patch,
while imperfect, solves a longstanding problem adequately. So how about
merging it, closing this bug, and opening a new bug for the system level
improvement?

- Dave

>

bug#57356: libtool-2.4.7 removed as a "duplicate"?

[Michael Ford]

In commit 5b6b731c7d8ecbae0ead1600b4cd2f70c66d51ca, the libtool-2.4.7
package was removed as a "duplicate". The commit message doesn't explain at
all why libtool 2.4.7 was being removed, or what it was a duplicate of? As
of latest master, libtool is still version 2.4.6.

Thanks.

bug#56444: Patch to fix Gitolite home directory permissions

[Maxime Devos]

On 19-08-2022 15:32, Thompson, David wrote:

Hi Evgeny and whoever wants to do some code review,

I have been experiencing this same issue for years now and have been 
manually chmod'ing /var/lib/gitolite every time I upgraded because I 
didn't understand what was happening.  All this time I thought I had 
gitolite misconfigured, that maybe I didn't have its umask config set 
properly, but it was Guix all along! In this case that's great, 
because it makes the problem easy for me to fix.  Patch attached.  It 
works like a charm for my personal git server 
(https://git.dthompson.us), /var/lib/gitolite was 700 before a system 
reconfigure, and 750 afterwards.


Big thanks to Evgeny for making a bug report and doing the research to 
identify the root cause!


- Dave


During "guix system reconfigure", there is now window where the 
directory temporarily has incorrect bits and hence if gitolite is 
restarted during that time it will presumably fail.  Could a 
'home-permission-bits' or such field be added instead to  
to make things atomic?


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57352: emacs-guix: Requires GUILE_LOAD_(COMPILED_)PATH env vars (or "guile" package)

[Ivan Vilata i Balaguer]

Hi!  I have `emacs-guix` in a separate Guix profile with all Emacs stuff,
running on a foreign distro.  I noticed that removing the `guile` package
(from all profiles) broke `emacs-guix` after a session restart, and that
restoring the `guile` package or just Guile's environment variables fixed the
issue:

```
$ nog  # a script of mine running a distro shell with no Guix variables
$ . ~/env/guix/ivan/emacs/etc/profile  # from profile with Emacs stuff
$ . ~/.config/guix/current/etc/profile
$ command -v guile || echo missing
missing
$ emacs

Running M-x guix then v yields this error:

Starting Guix REPL ... [5 times]
guix-geiser-eval: Error in evaluating guile expression: 
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Unbound variable: %max-returned-list-size

$ realpath ~/env/guix/ivan/emacs
/gnu/store/ahq…-profile
$ export GUILE_LOAD_PATH=/gnu/store/ahq…-profile/share/guile/site/3.0
$ export 
GUILE_LOAD_COMPILED_PATH=/gnu/store/ahq…-profile/lib/guile/3.0/site-ccache:/gnu/store/ahq…-profile/share/guile/site/3.0
$ emacs

Running M-x guix works successfully.

$ exit
```

I'm no Guix packaging expert, but it looks like `emacs-guix` should either
have `guile` as propagated input, or somehow add `GUILE_LOAD_PATH` and
`GUILE_LOAD_COMPILED_PATH` to the profile's search paths.

Thank you very much!

-- 
Ivan Vilata i Balaguer -- https://elvil.net/


signature.asc
Description: PGP signature

bug#57159: rust-gmp-mpfr-sys bundles gmp, mpc and mpfr

[Attila Lendvai]

> unless some new rust packages were added that depend on rust-gmp-mpfr-sys, 
> there's probably no dependant of it, and in that case it can be safely 
> removed.

i can't deal with this, lacking time and rust knowledge.

i suggest the removal of this package.

$ ./pre-inst-env guix refresh --list-dependent rust-gmp-mpfr-sys
No dependents other than itself: rust-gmp-mpfr-sys@1.4.7

apologies for the inconvenience,

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Desire is a contract you make with yourself to be unhappy until you get what 
you want.”
— Naval Ravikant

bug#57303: powerpc64le: rust build failure is bottleneck for many packages

[Marcel van der Boom]

[Marcel van der Boom]:

[Efraim Flashner]:
About 2 months ago I spent some time and got the rust bootstrap 
working
for riscv64-linux. I would suggest looking at the staging 
branch since

there the rust bootstrap version is at 1.54.



Ah, I didn't even think of that, thanks! Will try that.


Unfortunately, it fails with the exact same error

bug#57121: clojure-build-system fails to compile -- backtrace from language/tree-il/peval.scm

[Maxime Devos]

On 23-08-2022 06:06, Maxim Cournoyer wrote:

Hi Maxime,

Maxime Devos  writes:


On 22-08-2022 17:32, Maxim Cournoyer wrote:

These patches are for Guix' build system.  I don't see anything that
could be done on the Guile side, except for eventually migrating some
dependency tracking stuff over to Guile

If a module imports a different module, and that module changes, even if
it's macro, Guile should not blindly reuse the stale .go like it
currently does.  It should complain and evaluate from source instead.

That would cover the base and avoid breakage.  After, if it known how to
do that, yes, it seems it'd be useful to have something similar to 'gcc
-M' to provide the needed intelligence to the build system.

Does that make sense?

Sounds reasonable, though we could go for something less general in
Guix first.

I'd rather avoiding adding more complexity in Guix if it can be fixed
upstream; where it'd benefit everyone most.


It cannot be solved upstream, this is not a pure Guile matter but also a 
build system matter. Even if this the 'if that module changes, it ... 
should evaluate from source' was implemented, the build system still 
needs to know to compile the module.


More concretely, build-aux/compile-all.scm uses the following to 
determine what needs to be recompiled:



(define (file-needs-compilation? file)
  (let ((go (scm->go file)))
    (or (not (file-exists? go))
    (file-mtime--- just interpreting imported modules that have changed doesn't cause 
the importing module to be recompiled.


Also, at least one Guile maintainer wants dependency tracking to be 
orthogonal:




I guess I could live with an 80% dependency tracking solution. However,
my criteria for it would be that (1) it should be orthogonal (e.g., not
requiring explicit calls to ‘notice-dependency’ in many places), and (2)
it should be self-contained and reasonably small. Perhaps having
‘load*’ or similar instrument ‘open-file’ or similar could help achieve
that?


Your proposal to do in Guile does not appear to match that criterium.

The notice-dependency could be eventually upstreamed, but the issue does 
not appear to be fixable upstream.


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature