bug#68948: temp fix
The following workaround can be used,
```
HLDIRS=$(guix build highlight); # returns two directories
HLDIR="${HLDIRS##*[[:space:]]}"; # returns the second dir, after whitespace
DATADIR="$HLDIR/etc/highlight/";
echo "(highlight (package bug))" | highlight --data-dir=$DATADIR -O xterm256
--syntax lisp
```
Based on my understanding, the current package definition is correct. Possibly
a patch like this could resolve the issue the current package definition seems
correct.
```
diff --git a/gnu/packages/pretty-print.scm b/gnu/packages/pretty-print.scm
index b95f56729a..2a7cf74009 100644
--- a/gnu/packages/pretty-print.scm
+++ b/gnu/packages/pretty-print.scm
@@ -389,7 +389,7 @@ (define-public highlight
(lambda* (#:key inputs outputs #:allow-other-keys)
(let* ((out (assoc-ref outputs "out"))
(data (string-append out
-"/share/highlight/"))
+"/etc/highlight/"))
(conf (string-append out "/etc/highlight/"))
(doc (string-append out
"/share/doc/highlight/"))
```
bug#70021: 6f9d844 causes system hang right before GDM supposed to start
Hi! I recently encountered an issue with my system hanging during the startup process, where it halts just before GDM is supposed to start. Bisect has led to commit 6f9d844 (related issue: https://issues.guix.gnu.org/67649 ) being the culprit. Context/workaround: This appears to be an issue with code relating to mapped drives. Further inspection reveals my `device-mapping-cryptstorage` service fails to start, which is supposed to map my secondary encrypted drive. I currently work around this by commenting out the `file-system` entry that depends on this mapping before mounting it. I managed to find the following line in /var/log/messages, which - if I understand the change correctly - points to `bytevector?` being now unavailable, causing the device mapping service to fail (and take the system with it?): Mar 26 17:50:27 localhost vmunix: [ 24.680761] shepherd[1]: Exception caught while starting device-mapping-cryptstorage: (unbound-variable #f "Unbound variable: ~S" (bytevector?) #f) Best, aurtzy
bug#70026: QtBase 6.5.2: Wrong private header locations
The private header files of QtBase (and probably other Qt packages as well) are placed in the wrong location. In my case, I am trying to use qmetaobjectbuilder_p.h. The path for it is /gnu/store/zywk3i6r200qd0w0fjizg3m5nwpkkzjs-profile/include/qt6/QtCore/6.5.2/QtCore/private/qmetaobjectbuilder_p.h (expected would be /gnu/store/zywk3i6r200qd0w0fjizg3m5nwpkkzjs-profile/include/qt6/QtCore/private/qmetaobjectbuilder_p.h), which leads to issues when compiling, because qmetaobjectbuilder_p.h contains an "#include ", which can then not be found. It also means I cannot use any of the provided include path env variables like C_INCLUDE_PATH.
bug#70034: Hostkey error when pulling or building from private git repository
Hello, I get an error message when trying to `guix pull` a channel from a private git repository or when trying to `guix build` a package from a private git repository Previously it worked great up until a few days ago. I have tested it on multiple machines and get the same error, as well as for private repositories hosted on gitlab and github. This is the error message I get when I pull (for build it is essentially the same) atte@beryllium:~$ guix pull Updating channel 'guix-test' from Git repository at 'g...@github.com:Blixodus/guix-test.git'... guix pull: error: Git error: failed to set hostkey preference: The requested method(s) are not currently supported And this is how I define channels in .config/guix/channels.scm, with a url to a private git repository by ssh (list (channel (name 'guix-test) (url "g...@github.com:Blixodus/guix-test.git") (branch "main"))) Atte Torri
bug#67652: [PATCH] * home/services/shells.scm (add-bash-configuration): reorder aliases (Bug#67652)
Hi everyone, On Thu, 22 Feb 2024 12:10:15 +0800, Jason wrote: > > From: Jason Darby > > Change-Id: I288856bb6befe378ca60ef78578acc069cb18532 > --- > gnu/home/services/shells.scm | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) I have applied Jason's patch as 0b38c9401bebb6b87093555ef3768a8e1855c938, thank you all!
bug#68439: [bug#69793] [PATCH] gnu: icewm: Update to 3.4.6
Andy Tai writes: > * gnu/packages/wm.scm (icewm): Update to 3.4.6 > > Change-Id: Ieff1fc5417cfe164fa7886774e8855fd95248c8f > --- > gnu/packages/wm.scm | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Thanks both, I've pushed this to master as 8cc450e59a4c83fa39097964f62c2b2c84e0aee3. Chris signature.asc Description: PGP signature
bug#69997: Should ‘guix import pypi’ get dependencies from pyproject files?
Hey Ludo, > Should ‘guix import pypi’ attempt to get dependency information from > ‘pyproject.toml’, in addition to ‘requirements.txt’ and wheel ‘METADATA’ > as it already does? yes it should. It’s the next logical step after having a pyproject-build-system. The python-team branch (not sure whether Ricardo had time to merge it yet) adds a TOML parser to Guix as a first step. > It might be more complicated than we’d like: in some cases, that file > seems to be used as a “trampoline” to Poetry. For instance, in > python-pypugjs, the ‘requires’ bit delegates everything to Poetry: The file is always a trampoline to other build systems, like setuptools or poetry. That’s (unfortunately) by design, see the [build-system] section. > [tool.poetry.dependencies] > python = "^3.8" > Jinja2 = "^3.1.1" > Mako = "^1.1.3" > tornado = "^6.0.4" > six = "^1.15.0" > coverage = "^6.3.2" > nose = "^1.3.7" > Flask = "^2.1.1" > charset-normalizer = "^2.1.0" > flake8 = "^4.0.1" That’s unfortunate, because the specification includes a common field for dependencies: https://packaging.python.org/en/latest/specifications/pyproject-toml/#dependencies-optional-dependencies I guess we’ll have to deal with these idiosyncracies as well :( Lars
