I sent a patch to this ticket yesterday, before remembering this morning
that y'all probably weren't auto-Cc'd on it by debbugs.
Please have a look over it, especially the tests, in case I missed some
functionality or misinterpreted some requirements.
This will probably be deserving of a news
This patch reverts the behavior introduced in
181951207339508789b28ba7cb914f983319920f which caused ‘modify-services’
clauses to only match a single instance of a service.
We will now match all service instances when doing a deletion or update, while
still raising an exception when trying to
Ludovic Courtès writes:
> It wasn’t really intended, more a side effect of the implementation, and
> I agree it should be fixed.
There have been a number of complaints about the behavior change, and I
think the patch should probably be reverted. My only intention was to
raise an error for the
Jelle Licht writes:
Thanks for the workaround! Is this "thou shall delete N times,
and
_exactly_ N times" effect of the recently pushed change
functioning as
intended? It imho seems pretty brittle and verbose compared to
how
things were before.
We could add a ‘delete-all’ in addition
Attila Lendvai writes:
it doesn't seem to be an insurmontable task to make sure that
guile
can safely unlink a module from its heap, check if there are any
references into the module to be dropped, and then reload this
module
from disk.
the already runing fibers would keep the required
librt and libpthread were merged into libc with glibc 2.34, however, for
compatibility, there exist empty .a files to satisfy the linker. But
because Guix has a separate output for the static libraries, they need
to be explicitly installed from ‘glibc:static’, which allows Cargo to do
its thing.
Ludovic Courtès writes:
(Whether that leads to a deadlock depends; at first sight, I’d
say
there’s no reason for this to deadlock in general, but you can
of course
end up with a logic bug like A starts B, which spawns a client
to start
A, which doesn’t start because it’s waiting for B.)
I've run into two issues with the recent changes to git config
integration:
1) All commits must now be signed, even if you're not a
committer. This breaks just tons of things, including
rebasing. I'm not sure how to fix this without just disabling that
configuration line altogether.
2)
Maxim Cournoyer writes:
Thanks for finding the problem. Should we leave this bug open
until
specification->package+output is properly documented in our
manual, with
an example? If yes, would you like to try your hand at adding
it?
I've looked at this briefly, and can't figure out a
Josselin Poiret writes:
Ran into this problem myself, here's the reason and the fix:
We build a modified `guile` executable in the source tree (for
reasons),
and use that to run guix. Note that it is only added to PATH by
./pre-inst-env! That guile executable is linked against glibc,
I did a full rebuild before submitting this bug: bootstrap -> configure
-> make clean -> make.
FWIW, I still have the issue with ‘pre-inst-env’ when not run from
within ‘guix shell -D guix’, which is a step I have never previously
needed. As I just explained on IRC:
--8<---cut
Ludovic Courtès writes:
Make sure everything is in sync, and use ‘guix shell -D guix -C’
to
avoid interference!
This has made the glibc locale error and the libgit2 bindings to
work. Thank you!
However, I'm not sure how this happened in the first place. The
system I'm running on is
Simon Tournier writes:
~/src/guix-core-updates $ ./pre-inst-env -- guix build zsh
Are you sure about the dash-dash (--) with ./pre-inst-env?
I get this:
$ ./pre-inst-env guix describe
Git checkout:
repository: /home/simon/src/guix/wk/core-updates/
branch: core-updates
commit:
After re-configuring my system with core updates and rebooting,
I'm no longer able to use Guix' ‘pre-inst-env’ command to do
testing:
--8<---cut here---start->8---
~/src/guix-core-updates $ ./pre-inst-env -- guix build zsh
hint: Consider installing the
When loading Emacs from core-updates, I get a bunch of warnings
from native-comp that make me think it's not working at all:
--8<---cut here---start->8---
[...]
Warning (comp): libgccjit.so: error: error invoking gcc driver
Disable showing Disable
It appears as though core-updates isn't installing locales
correctly, as I'm getting warnings all over the place about
unsupported locales:
--8<---cut here---start->8---
~/src/guix-core-updates $ echo $LANG
en_US.utf8
--8<---cut
Looks like something changed between 2.34 (on master) and 2.36 (on
core-updates) which caused ‘share/X11/rules/base’ to generate
improperly.
On core-updates:
--8<---cut here---start->8---
~/src/guix-core-updates $ ./pre-inst-env guix build
This appears to have been fixed, or at least I'm no longer getting this
error.
Αντώνιος Τσώλης writes:
Well, I use this:
(packages
(append
(map specification->package+output
'("bind:utils" ... ))
%base-packages))
But I am new to scheme/guile/guix, so maybe I do something
wrong. Anyway, thanks for confirming that it works on your
side.
There is currently no way to ensure that an account exists before
creating /run/setuid-programs, which means a setuid-program which
uses a custom user or group will fail to be created if setuid
activation happens before account activation.
As an example, here's a system config where I'm
With the config below, I have ‘host’, ‘dig’, and ‘nslookup’ in my
path. Note that I'm using the ‘(compose list
specification->package+output)’ form, though. If you're not using that,
you may be accidentally loading the ‘bind’ package with the default
‘out’ output, instead of the ‘utils’ one. If
They are included for me:
--8<---cut here---start->8---
bjc@psyduck:~/.config/emacs% for i in dig host nslookup; do which $i; done
/net/snorlax/home/bjc/.guix-home/profile/bin/dig
/net/snorlax/home/bjc/.guix-home/profile/bin/host
Maxime Devos writes:
Create a file /gnu/store/case-sensitivity-test (if it doesn't
already
exist). Open /gnu/store/CASE-SENSITIVITY-TEST. If it succeeds,
you
have a case-sensitive file system.
Hah. I was so wrapped up in thinking about kernel or POSIX APIs I
missed the obvious thing.
Maxime Devos writes:
Not sure how a case-insensitivity would cause this, but I think
we
can keep this open -- wouldn't it be better if "guix-daemon"
just says
‘nope, case-sensitivity is required (*), not continuing)?
(*) For reproducible builds, and apparently for substitution.
The issue
This bug was caused by having my Guix filesystem mounted on a
case-insensitive file system. Re-running pull within the Docker
container mounted on a case-sensitive file system works correctly.
This bug can be closed. Sorry for the noise.
-bjc
Maxime Devos writes:
The relevant store item name has been truncated, could you run
"echo /gnu/store/8v8y8rc4rwd*" in a shell and report the output?
⇒
/gnu/store/8v8y8rc4rwdwx5kbkfr1w1rl8g3dxsa3-guile-avahi-0.4.0-1.6d43caf.drv
In case it matters, here’s its contents:
Got here trying to compile perl with:
--8<---cut here---start->8---
% guix shell -D perl --no-substitutes --pure
--8<---cut here---end--->8---
and failed here:
--8<---cut
I’m getting an error when trying to pull inside a docker
container:
--8<---cut here---start->8---
guix# guix pull
substitute: updating substitutes from
'https://ci.guix.gnu.org'... 100.0%
0.0 MB will be downloaded
le-certs-1 5KiB
552KiB/s 00:00
28 matches
Mail list logo
