bug#59474: Guix Home generated .profile sets XDG_ vars that break GDM+Gnome login on foreign distros
On 2022-11-21 22:02, Matt Armstrong wrote:
> I am experimenting with Guix Home on Debian Testing, using GDM+Gnome.
> The .profile generated by "guix home reconfigure" broke logging in to
> the Gnome desktop. The gnome session would die, failing to initialize
> what it considered to be essential things, and return to the login
> screen I could log in to a tty, and was able to undo the new .profile
> and get back to a working system.
>
> The home-configuration.scm I used was generated by "guix home import"
> and was quite simple:
>
> --
> (use-modules (gnu home)
> (gnu packages)
> (gnu services)
> (guix gexp)
> (gnu home services shells))
>
> (home-environment
> ;; Below is the list of packages that will show up in your
> ;; Home profile, under ~/.guix-home/profile.
> (packages (specifications->packages (list "glibc-locales")))
>
> ;; Below is the list of Home services. To search for available
> ;; services, run 'guix home search KEYWORD' in a terminal.
> (services
>(list (service home-bash-service-type
> (home-bash-configuration
>(aliases '(("ls" . "ls --color=auto")))
>(bashrc (list (local-file ".bashrc" "bashrc")))
>(bash-logout (list (local-file ".bash_logout"
> "bash_logout"
> --
>
> Note: a stock GDM+Gnome setup runs the user's login shell when logging
> in via the GDM display manager, and this shell execs
> gnome-session-binary. This doesn't necessarily happen with other
> display managers or other desktop environments, so on those systems the
> Guix Home .profile may not even run before the DE is initialized.
> Nearly all of my time debugging this was spent figuring this out! :-)
>
> The .profile file generated by Guix Home is this:
>
> --
> HOME_ENVIRONMENT=$HOME/.guix-home
> . $HOME_ENVIRONMENT/setup-environment
> $HOME_ENVIRONMENT/on-first-login
> --
>
> The first thing I see is that $HOME/.guix-home/seutp-environment is
> modifying various XDG_ variables incorrectly. It prepends new values
> without honor the variable's default value if it doesn't happen to be
> set already.
>
> For example, if XDG_DATA_DIRS is not set its default value is
> "/usr/local/share/:/usr/share/".
>
> But .guix-home/setup-environment will instead prepend a value without
> checking, leaving XDG_DATA_DIRS set incorrectly to
> "$HOME/.guix-home/profile/share:" when it should be
> "$HOME/.guix-home/profile/share:/usr/local/share/:/usr/share/".
>
> See this code in setup-environment:
>
> case $XDG_DATA_DIRS in
> *$HOME_ENVIRONMENT/profile/share*) ;;
> *) export XDG_DATA_DIRS=$HOME_ENVIRONMENT/profile/share:$XDG_DATA_DIRS ;;
> esac
>
> The correct idiom is this:
>
> XDG_DATA_DIRS=PATH_TO_PREPEND:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}
>
> or
>
> XDG_DATA_DIRS=${XDG_DATA_DIRS:-/usr/local/share/:/usr/share/}:PATH_TO_APPEND
>
> The above is what I see in various Nix and Snap configuration files.
>
> Because I have a few other things installed that modify XDG_DATA_DIRS
> before Guix Home does, Guix Home doesn't break that particular variable.
>
> It did break XDG_CONFIG_DIRS, since Guix Home was setting it to
> "$HOME/.guix-home/profile/etc/xdg:". I worked around this problem by
> running this code before Guix Home's .profile:
>
> # Note: when XDG_CONFIG_DIRS is not set Guix home sets
> # XDG_CONFIG_DIRS="$HOME/.guix-home/profile/etc/xdg:", which removes
> # the default "/etc/xdg" value.
> if [[ -z $XDG_CONFIG_DIRS ]]; then
> XDG_CONFIG_DIRS=/etc/xdg
> fi
>
> # Note: when XDG_DATA_DIRS is not set Guix home sets
> # XDG_DATA_DIRS="$HOME/.guix-home/profile/share:", which removes the
> # default "/usr/local/share:/usr/share" value.
> if [[ -z $XDG_DATA_DIRS ]]; then
> XDG_DATA_DIRS="/usr/local/share:/usr/share"
> fi
>
> I have other more minor quibbles about how Guix Home handles XDG values:
>
> XDG_STATE_HOME is set to a non-standard value. In the current XDG Base
> Directory Specification it defaults to "$HOME/.local/state", but Guix
> Home sets it to "$HOME/.local/var/lib". On a foreign distro this is
> going to cause some disruption when a user switches to Guix Home, or
> switches away.
>
> XDG_LOG_HOME is a non-standard variable. The spec suggests that logs
> should go in XDG_STATE_HOME. Why not a establish a GUIX_LOG_HOME
> variable instead? (if it ever does become a standard XDG variable, its
> default may not be the same one picked by Guix Home, causing the same
> issue as above).
>
> Setting XDG_RUNTIME_DIR is not something I would expect Guix Home to do
> -- it is the job of
bug#63202: [PATCH] gnu: git-crypt: Fix build
Hello, this bug is also fixed by Sergey Trofimov in bug#63209 Thanks, Gio' -- Giovanni Biscuolo Xelera IT Infrastructures
bug#63202: [PATCH] gnu: git-crypt: Fix build
Hello, From 09aab815c7b0afddc020fb47e6beca524ea4e886 Mon Sep 17 00:00:00 2001 Message-Id: <09aab815c7b0afddc020fb47e6beca524ea4e886.1682959973.gi...@xelera.eu> From: Giovanni Biscuolo Date: Mon, 1 May 2023 18:34:57 +0200 Subject: [PATCH] gnu: git-crypt: Fix build MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Avoid this compilation warning: warning: ‘int AES_set_encrypt_key(const unsigned char*, int, AES_KEY*)’ is deprecated: Since OpenSSL 3.0 [-Wdeprecated-declarations] Fixes bug#63202 * gnu/packages/version-control.scm: Add CXXFLAGS=-DOPENSSL_API_COMPAT=0x3000L to build environment --- gnu/packages/version-control.scm | 1 + 1 file changed, 1 insertion(+) diff --git a/gnu/packages/version-control.scm b/gnu/packages/version-control.scm index c2ec490383..ba213bafa6 100644 --- a/gnu/packages/version-control.scm +++ b/gnu/packages/version-control.scm @@ -936,6 +936,7 @@ (define-public git-crypt #t)) (replace 'build (lambda _ + (setenv "CXXFLAGS" "-DOPENSSL_API_COMPAT=0x3000L") (invoke "make" "ENABLE_MAN=yes"))) (replace 'install (lambda* (#:key outputs #:allow-other-keys) base-commit: 0c6a7e1045cbd06336ef3699734a803a2e4038e5 -- 2.39.2 Happy hacking! -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
bug#58813: can't substitute etc/teams.scm command as doc suggests
Hi, Josselin Poiret writes: > Hi Maxim, > > Only seeing this patchset now, but it seems great! > > Maxim Cournoyer writes: > >> +[commit] >> +gpgsign = true >> + >> [diff "scheme"] >> xfuncname = "^(\\(define.*)$" >> >> [diff "texinfo"] >> xfuncname = "^@node[[:space:]]+([^,]+).*$" >> + >> +[format] >> +useAutoBase = true >> +thread = shallow >> + >> +[pull] >> +rebase = true >> + >> +[sendemail] >> +to = guix-patc...@gnu.org >> +headerCmd = etc/teams.scm cc-members-header-cmd >> +thread = no > > Could we also consider adding format.forceinbodyfrom=true, so that > contributors whose From: gets rewritten by debbugs/mailman still have > the proper attribution without requiring manual action from committers? Seems reasonable. I've added it in, and have now pushed the series. The upstream git commit hasn't been merged yet, but I've addressed all their comments, and will continue doing so. Closing, finally :-). I'll push an associated news entry shortly. -- Thanks, Maxim
bug#33691: pre-inst-env: "no code for module (gcrypt hash)"
Hi Rostislav, Rostislav Svoboda writes: > I get this error when the order of packages is "wrong". E.g. this fails: > > guix shell --development pwclient guix --pure > ./pre-inst-env guix build pwclient > > but this works: > > guix shell --development guix pwclient --pure > ./pre-inst-env guix build pwclient --development only affects the next package specification, not all of them, hence the behavior you're seeing. HTH, -- Josselin Poiret signature.asc Description: PGP signature
bug#63205: quodlibet fails to build after python 3.10 update
After the core-updates merge (specifically after the bump to python 3.10, I would guess) quodlibet's testsuite has one failing test and therefore the package fails to build: === FAILURES === ___ TCoverManager.test_invalid_glob tests/test_util_cover.py:111: in test_invalid_glob os.path.abspath(self._find_cover(self.song).name), f) E AttributeError: 'NoneType' object has no attribute 'name' === short test summary info FAILED tests/test_util_cover.py::TCoverManager::test_invalid_glob - Attribute... = 1 failed, 3257 passed, 53 skipped, 139 warnings in 90.85s (0:01:30) == Full build log is attached. $ guix describe Generation 19 May 01 2023 08:59:02(current) guix 0c6a7e1 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 0c6a7e1045cbd06336ef3699734a803a2e4038e5 gj1mb1y5bchcq9pm4rsh7x8pyq0fs3-quodlibet-4.5.0.drv.gz Description: application/gzip
bug#63202: git-gcrypt 0.7.0 build fails with OpenSSL 3.0
Giovanni Biscuolo writes: > git-crypt 0.7.0 is failing to build with OpenSSL 3.0 [...] > I'm going to investigate if there's a solution. This is the upstream bug report: https://github.com/AGWA/git-crypt/issues/232 (git-crypt fails to build with openssl 3.0.0) The solution is to add this build flag: CXXFLAGS='-DOPENSSL_API_COMPAT=0x3000L' I'll try and send a patch as soon as I succeed HTH! Gio' -- Giovanni Biscuolo Xelera IT Infrastructures signature.asc Description: PGP signature
bug#33691: pre-inst-env: "no code for module (gcrypt hash)"
I get this error when the order of packages is "wrong". E.g. this fails: guix shell --development pwclient guix --pure ./pre-inst-env guix build pwclient but this works: guix shell --development guix pwclient --pure ./pre-inst-env guix build pwclient Cheers Bost
bug#63202: git-gcrypt 0.7.0 build fails with OpenSSL 3.0
Hello,
git-crypt 0.7.0 is failing to build with OpenSSL 3.0
--8<---cut here---start->8---
g++ -Wall -pedantic -Wno-long-long -O2 -std=c++11 -c -o crypto-openssl-10.o
crypto-openssl-10.cpp
crypto-openssl-10.cpp: In constructor
‘Aes_ecb_encryptor::Aes_ecb_encryptor(const unsigned char*)’:
crypto-openssl-10.cpp:59:32: warning: ‘int AES_set_encrypt_key(const unsigned
char*, int, AES_KEY*)’ is deprecated: Since OpenSSL 3.0
[-Wdeprecated-declarations]
59 | if (AES_set_encrypt_key(raw_key, KEY_LEN * 8, &(impl->key)) !=
0) {
| ~~~^~~~
In file included from crypto-openssl-10.cpp:38:
/gnu/store/69wd3pd1hd3j84xr965jj2fk2qmxn0hl-openssl-3.0.8/include/openssl/aes.h:51:5:
note: declared here
51 | int AES_set_encrypt_key(const unsigned char *userKey, const int bits,
| ^~~
crypto-openssl-10.cpp: In member function ‘void
Aes_ecb_encryptor::encrypt(const unsigned char*, unsigned char*)’:
crypto-openssl-10.cpp:74:20: warning: ‘void AES_encrypt(const unsigned char*,
unsigned char*, const AES_KEY*)’ is deprecated: Since OpenSSL 3.0
[-Wdeprecated-declaratio
ns]
74 | AES_encrypt(plain, cipher, &(impl->key));
| ~~~^
In file included from crypto-openssl-10.cpp:38:
/gnu/store/69wd3pd1hd3j84xr965jj2fk2qmxn0hl-openssl-3.0.8/include/openssl/aes.h:57:6:
note: declared here
57 | void AES_encrypt(const unsigned char *in, unsigned char *out,
| ^~~
crypto-openssl-10.cpp: At global scope:
crypto-openssl-10.cpp:78:18: error: field ‘ctx’ has incomplete type ‘HMAC_CTX’
{aka ‘hmac_ctx_st’}
78 | HMAC_CTX ctx;
| ^~~
In file included from
/gnu/store/69wd3pd1hd3j84xr965jj2fk2qmxn0hl-openssl-3.0.8/include/openssl/evp.h:26,
from
/gnu/store/69wd3pd1hd3j84xr965jj2fk2qmxn0hl-openssl-3.0.8/include/openssl/hmac.h:21,
from crypto-openssl-10.cpp:40:
/gnu/store/69wd3pd1hd3j84xr965jj2fk2qmxn0hl-openssl-3.0.8/include/openssl/types.h:132:16:
note: forward declaration of ‘HMAC_CTX’ {aka ‘struct hmac_ctx_st’}
132 | typedef struct hmac_ctx_st HMAC_CTX;
|^~~
crypto-openssl-10.cpp: In destructor ‘Hmac_sha1_state::~Hmac_sha1_state()’:
crypto-openssl-10.cpp:92:9: error: ‘HMAC_cleanup’ was not declared in this
scope; did you mean ‘EVP_cleanup’?
92 | HMAC_cleanup(&(impl->ctx));
| ^~~~
| EVP_cleanup
make: *** [: crypto-openssl-10.o] Error 1
error: in phase 'build': uncaught exception:
%exception #< program: "make" arguments: ("ENABLE_MAN=yes")
exit-status: 2 term-signal: #f stop-signal: #f>
phase `build' failed after 9.4 seconds
command "make" "ENABLE_MAN=yes" failed with status 2
note: keeping build directory `/tmp/guix-build-git-crypt-0.7.0.drv-0'
builder for `/gnu/store/n16q81snhvc2ikws6pwsysdyxi3shbqp-git-crypt-0.7.0.drv'
failed with exit code 1
build of /gnu/store/n16q81snhvc2ikws6pwsysdyxi3shbqp-git-crypt-0.7.0.drv failed
View build log at
'/var/log/guix/drvs/n1/6q81snhvc2ikws6pwsysdyxi3shbqp-git-crypt-0.7.0.drv.gz'.
guix build: error: build of
`/gnu/store/n16q81snhvc2ikws6pwsysdyxi3shbqp-git-crypt-0.7.0.drv' failed
--8<---cut here---end--->8---
I'm going to investigate if there's a solution.
Happy hacking! Gio'
--
Giovanni Biscuolo
Xelera IT Infrastructures
signature.asc
Description: PGP signature
bug#62984: Nautilus/File Roller cannot password encrypt for zip compression
Hi, Csepp writes: > Maxim Cournoyer writes: > >> Hello, >> >> When selecting a file in Nautilus and clicking right-click -> >> Compress... and selected zip with password, attempting to proceed fails >> with the message "encryption not supported". >> >> The code path this supposedly uses is gnome-autoar, which itself uses >> libarchive. > > AFAIK our libarchive is outdated, it's apparently also why Evince can't > open comics anymore. We're now at 3.6.1, while the latest release is 3.6.2. I still reproduce the problem. It seems there's more to it than that. -- Thanks, Maxim
bug#62985: [GNOME] MTP mounts in Nautilus doesn't work out of the box
Hi, Csepp writes: > Maxim Cournoyer writes: > >> Hi, >> >> Connecting an Android phone via USB to a Guix System that has GNOME >> installed, and selecting the transfer mode to be USB/media, I'd expect >> it to appear in Nautilus, the same it does in other mainstream >> distributions. Instead, nothing happens. >> >> In Fedora, for example, the device appears in the left panel of >> Nautilus, and a 'gvfsd-mtp' process starts running. In Guix System, >> there's no 'gvfsd-mtp' process running, although a >> 'gvfs-mtp-volume-monitor' process is running. >> >> To be investigated. > > I've also experienced this with plain USB block devices like some of my > microSD adapters. No idea what causes it. Sometimes it shows up in > Nautilus for a split second and then disappears. > Weirdly enough, running fdisk -l on the block device makes it show up in > Nautilus. > > But it should be noted that our Nautilus version is behind by two versions. Did you have a chance to update your system following the core-updates merge yet? At least on a fresh install it was working correctly now on one machine, where it wasn't before. -- Thanks, Maxim
bug#63043: texlive-font-maps.drv build failure when profiles lacks texlive-* packages
Hi Ludovic, Ludovic Courtès writes: > Hi, > > Maxim Cournoyer skribis: > >>> There were cases (like GDK pixbuf, GLib schemas, and all that) where the >>> idea >>> was to take whichever glib/GDK we’d find in the dependency graph, and >>> pick the command we need from it. That way, we wouldn’t introduce any >>> additional dependency. That was the reasoning. >>> >>> Thinking about, this particular case might be easier: we can make things >>> consistent like so: > > [...] > >>> +(if (and texlive-base (pair? texlive-inputs)) >>> (gexp->derivation "texlive-font-maps" build >>>#:substitutable? #f >>>#:local-build? #t >>> >>> >>> That way, the hook only fire if we have ‘texlive-base’ (somewhere in the >>> graph) *and* we have texlive-* packages in the manifest. >> >> That is equivalent, but it doesn't address the core problem in my >> opinion. There's no use to run hooks for things which aren't propagated >> at the level of the profile, I think. If texlive-base in is the >> profile, the person wants to use tex and friends. But if it's wrapped >> by some package deep down, we shouldn't care. >> >> I see it the same way as when using libraries and compilers in a >> profile; the compiler (consumer) needs to be present else no search path >> is created. >> >> Does it make sense? > > I agree with the reasoning; I think it doesn’t apply to the GLib schemas > and GDK pixbuf caches though. It does, for the simple reasons that both GDK pixbufs and GLib schemas are collected using manifest-inputs, which means only direct inputs from the profile and the ones they propagate. So if you look deep in the profile graph for the 'glib-compile-schemas' command, there is a chance that it is found while no schemas were collected, and this is the kind of case that'd lead to an empty derivation output (because there's no schema to compile). > For TeX Live font maps, maybe it applies, though I’m not entirely sure > (I wouldn’t be surprised if things other than ‘texlive-base’ are > consumers of font maps). Plus, since the patch I proposed is simple, > I’m inclined to just do that. > > Thoughts? I still think that my proposition is better, but I don't mind if you apply your fix now and we revisit this at a later time. If we get to it, this change could be reverted as it wouldn't be necessary anymore. -- Thanks, Maxim
bug#63173: Epiphany can't play videos
Hi, epiphany doesn't come with any codecs to play YouTube videos. Epiphany is targeted at non-technical users, being able to play videos from YouTube is an essential thing the browser should be capable of. Without the codecs, the package looks like it is broken/not properly cared about. Especially as IceCat can play the videos out-of-the-box. I don't know which package is the best suited, but I know that including either of these as an input to epiphany gets the job done: - gst-libav - libva - libx264 I can imagine that there are other packages that could also be used instead. Regards, Dominik
bug#63173: Correction
Correction: I tested again and it seems that out of the packages I listed only gst-libav works. That is, when you use it as a propagated input.
bug#63154: Settings schema 'org.gnome.nm-applet.eap' is not installed
On 4/28/23 8:10 PM, Steven Roose wrote: Recently did a system upgrade and getting that error now when entering password for a new wifi network. It also kills the networkmanager applet. I experienced a similar issue a month or so ago when trying to connect to my university's wifi network, installing libnma solved it. This recent issue might be related https://issues.guix.gnu.org/62496 I hope this helps -- Mario
bug#63170: Getting error while trying to compile treesitter plugin for neovim.
I'm using the kickstart.nvim configuration, https://github.com/nvim-lua/kickstart.nvim And while it tries to compile the treesitter plugin I am getting an error, ``` nvim-treesitter[python]: Error during compilation In file included from src/scanner.cc:2: In file included from /home/apoorv/.guix-home/profile/include/c++/vector:66: In file included from /home/apoorv/.guix-home/profile/include/c++/bits/refwrap.h:39: /home/apoorv/.guix-home/profile/include/c++/bits/stl_function.h:439:11: error: no member named '__is_constant_evaluated' in namespace 'std' if (std::__is_constant_evaluated()) ~^ /home/apoorv/.guix-home/profile/include/c++/bits/stl_function.h:454:11: error: no member named '__is_constant_evaluated' in namespace 'std' if (std::__is_constant_evaluated()) ~^ /home/apoorv/.guix-home/profile/include/c++/bits/stl_function.h:469:11: error: no member named '__is_constant_evaluated' in namespace 'std' if (std::__is_constant_evaluated()) ~^ /home/apoorv/.guix-home/profile/include/c++/bits/stl_function.h:484:11: error: no member named '__is_constant_evaluated' in namespace 'std' if (std::__is_constant_evaluated()) ~^ 4 errors generated. ```
bug#63171: Telegram fails to compile.
telegram-desktop fails to compile with error,
```
Summary:
rlottie version :0.0.1
Build type :debugoptimized
Thread Support :true
Module Support :true
Cache Support :true
Example :true
Test:true
Prefix :
/gnu/store/zn3jhbfxs4gcxklrmnwb34qw5zaiqw1m-rlottie-0.0.1-678.8c69fc2
Build targets in project: 5
rlottie 0.0.1
User defined options
buildtype: debugoptimized
prefix :
/gnu/store/zn3jhbfxs4gcxklrmnwb34qw5zaiqw1m-rlottie-0.0.1-678.8c69fc2
c_link_args :
-Wl,-rpath=/gnu/store/zn3jhbfxs4gcxklrmnwb34qw5zaiqw1m-rlottie-0.0.1-678.8c69fc2/lib
cpp_link_args:
-Wl,-rpath=/gnu/store/zn3jhbfxs4gcxklrmnwb34qw5zaiqw1m-rlottie-0.0.1-678.8c69fc2/lib
log : true
test : true
Found ninja-1.11.1 at
/gnu/store/7q4crm7s2whyjx0s127p7k43s4fwxzgm-ninja-1.11.1/bin/ninja
phase `configure' succeeded after 1.1 seconds
starting phase `patch-generated-file-shebangs'
phase `patch-generated-file-shebangs' succeeded after 0.0 seconds
starting phase `build'
[1/78] Compiling C++ object
src/librlottie.so.0.0.1.p/vector_vcompositionfunctions.cpp.o
[2/78] Compiling C++ object
src/librlottie.so.0.0.1.p/vector_vdrawhelper_neon.cpp.o
[3/78] Compiling C++ object src/librlottie.so.0.0.1.p/vector_vbrush.cpp.o
[4/78] Compiling C++ object
src/librlottie.so.0.0.1.p/vector_vdrawhelper_sse2.cpp.o
[5/78] Compiling C++ object src/librlottie.so.0.0.1.p/vector_vpainter.cpp.o
[6/78] Compiling C++ object src/librlottie.so.0.0.1.p/vector_vdasher.cpp.o
[7/78] Compiling C++ object src/librlottie.so.0.0.1.p/vector_vbitmap.cpp.o
[8/78] Compiling C++ object src/librlottie.so.0.0.1.p/vector_vrect.cpp.o
[9/78] Compiling C++ object src/librlottie.so.0.0.1.p/vector_vrle.cpp.o
FAILED: src/librlottie.so.0.0.1.p/vector_vrle.cpp.o
c++ -Isrc/librlottie.so.0.0.1.p -Isrc -I../source/src -Iinc -I../source/inc
-I. -I../source -Isrc/vector -I../source/src/vector -Isrc/vector/freetype
-I../source/src/vector/freetype -Isrc/vector/pixman
-I../source/src/vector/pixman -Isrc/lottie -I../source/src/lottie
-Isrc/binding/c -I../source/src/binding/c -fvisibility=hidden
-fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch
-Wextra -Wpedantic -std=c++14 -O2 -g
'-DDEMO_DIR="/tmp/guix-build-rlottie-0.0.1-678.8c69fc2.drv-0/source/example/resource/"'
-fPIC -pthread -DLOT_BUILD -fno-exceptions -fno-rtti -fno-unwind-tables
-fno-asynchronous-unwind-tables -Woverloaded-virtual -Wno-unused-parameter
-MD -MQ src/librlottie.so.0.0.1.p/vector_vrle.cpp.o -MF
src/librlottie.so.0.0.1.p/vector_vrle.cpp.o.d -o
src/librlottie.so.0.0.1.p/vector_vrle.cpp.o -c ../source/src/vector/vrle.cpp
../source/src/vector/vrle.cpp: In member function ‘void
VRle::VRleData::updateBbox() const’:
../source/src/vector/vrle.cpp:129:32: error: ‘numeric_limits’ is not a
member of ‘std’
129 | int l = std::numeric_limits::max();
|^~
../source/src/vector/vrle.cpp:129:47: error: expected primary-expression
before ‘int’
129 | int l = std::numeric_limits::max();
| ^~~
[10/78] Compiling C++ object
src/librlottie.so.0.0.1.p/vector_vpathmesure.cpp.o
[11/78] Compiling C++ object src/librlottie.so.0.0.1.p/vector_vmatrix.cpp.o
[12/78] Compiling C++ object
src/librlottie.so.0.0.1.p/vector_vdrawhelper.cpp.o
[13/78] Compiling C++ object
src/librlottie.so.0.0.1.p/vector_velapsedtimer.cpp.o
[14/78] Compiling C++ object
src/librlottie.so.0.0.1.p/vector_vdrawable.cpp.o
[15/78] Compiling C++ object src/librlottie.so.0.0.1.p/vector_vpath.cpp.o
[16/78] Compiling C++ object
src/vector/stb/librlottie-image-loader.so.p/stb_image.cpp.o
ninja: build stopped: subcommand failed.
error: in phase 'build': uncaught exception:
%exception #< program: "ninja" arguments: ("-j" "8")
exit-status: 1 term-signal: #f stop-signal: #f>
phase `build' failed after 3.1 seconds
command "ninja" "-j" "8" failed with status 1
builder for
`/gnu/store/qiknpnpqma0l3yr7fbv39y7sfxsn59ih-rlottie-0.0.1-678.8c69fc2.drv'
failed with exit code 1
build of
/gnu/store/qiknpnpqma0l3yr7fbv39y7sfxsn59ih-rlottie-0.0.1-678.8c69fc2.drv
failed
View build log at
'/var/log/guix/drvs/qi/knpnpqma0l3yr7fbv39y7sfxsn59ih-rlottie-0.0.1-678.8c69fc2.drv.gz'.
cannot build derivation
`/gnu/store/2s38mjb9ixdbly3kx6dzfbckv6a3almp-telegram-desktop-4.2.2.drv': 1
dependencies couldn't be built
cannot build derivation
`/gnu/store/ny0yxpzpq2d75pxgfdgrh525q3b42p4k-profile.drv': 1 dependencies
couldn't be built
guix shell: error: build of
`/gnu/store/ny0yxpzpq2d75pxgfdgrh525q3b42p4k-profile.drv' failed
```
bug#63082: [PATCH 04/17] services: mpd: Obsolete the 'group' field.
Hi Maxim,
Am Sonntag, dem 30.04.2023 um 21:07 -0400 schrieb Maxim Cournoyer:
> > In the current mpd-configuration, to use my own user, I must also
> > provide the matching group as a record, even if
> > e.g. 'users' is something I've never created myself and don't
> > really
> > have a clue as to how it was defined without looking at the source,
> > yet it's important that it matches the original definition
> > otherwise
> > I'd have two same-named groups differing only subtly, which would
> > introduce issues probably harder to diagnose than "sorry, no such
> > group!"
The "find by name" pattern applies here as well. We could extend the
semantics of group field so that if a string is passed, %base-groups is
searched for a matching name first instead of constructing a new group.
This would allow you to more easily specify (group "users") for
example.
> > One way that seems like it'd solve it is to make the group field of
> > a
> > accept a ; then the user object would be
> > self-contained as far as extending user-accounts goes; the API
> > becomes a bit more obtuse though, especially when you simply want
> > to
> > specify a group known to exist ('users', 'audio', 'netdev', etc.).
Not really. If the allowed for a group, we
could drop the group field in the MPD specification. The semantics for
string groups would remain unchanged, whereas groups would
get added to the accounts service as though they had been specified via
the groups mechanic. We'd only have to twiddle with account service
there and the change would probably benefit every service that requires
an account:group pair.
Cheers
