bug#68988: [PATCH] gnu: linux-libre 6.7: Modify .conf files.
On Fri, Feb 09, 2024 at 09:28:14PM +0100, Wilko Meyer wrote: > * gnu/packages/aux-files/linux-libre/6.7-arm.conf, > gnu/packages/aux-files/linux-libre/6.7-arm64.conf: Add platform support. Thanks! Pushed to 'kernel-updates' along with the latest releases.
bug#69258: archivebox: Failed to build
Hi Guix! While reviewing https://issues.guix.gnu.org/68491 and working on minor adjustments in: * 2f1ed825af * gnu: python-simpervisor: Enable tests. * 8cab6bac1c * gnu: python-simpervisor: Update to 1.0.0. * 4da2f179d2 * gnu: python-devtools: Update to 0.12.2, fix build. * ccbf143927 * gnu: python-watchdog: Simplify package. * 18240ae446 * gnu: python-humanize: Update to 4.0.0. * 4daeae8583 * gnu: python-trio-websocket: Simplify package. * 1a2c374c2c * gnu: python-xyzservices: Simplify package. * e355848578 * gnu: python-zeroconf: Simplify package. * eeaad8c906 * gnu: python-crontab: Update to 3.0.0. * 170efe6e68 * gnu: python-crontab: Enable tests. I've found that archivebox is failed to build for a long time due to issue with python-django-3.1.14. https://ci.guix.gnu.org/search?query=archivebox%200.6.2%20spec:master --8<---cut here---start->8--- build of /gnu/store/mcdbyv6vgfxv7ppk1jkcpvrzq6pbfgrr-python-django-3.1.14.drv failed View build log at '/var/log/guix/drvs/mc/dbyv6vgfxv7ppk1jkcpvrzq6pbfgrr-python-django-3.1.14.drv.gz'. cannot build derivation `/gnu/store/n2ja2mmvd2ly0q8qxc3wvcp0qd0xqbvq-archivebox-0.6.2.drv': 1 dependencies couldn't be built --8<---cut here---end--->8--- It was added 2y ago by Pradana AUMARS and never updated since that time. Maybe someone would like to volunteer to fix it ;-). Thanks, Oleg signature.asc Description: PGP signature
bug#69240: [PATCH 00/10] Fix failed builds from evaluation 1123386.
Duplicated https://issues.guix.gnu.org/69238 signature.asc Description: PGP signature
bug#69240: [PATCH 00/10] Fix failed builds from evaluation 1123386.
Hi Guix! After I've pushed https://issues.guix.gnu.org/64916 it introduced some package build regression as seen in https://ci.guix.gnu.org/eval/1123386?status=newly-failed This patch series fixes them. Thanks, Oleg Sharlatan Hellseher (10): gnu: go-github-com-alecthomas-chroma: Move to golang-xyz. gnu: go-github-com-alecthomas-chroma: Update to 0.10.0. gnu: go-github-com-alecthomas-chroma: Remove bundled files. gnu: Add go-github-com-alecthomas-chroma-v2. gnu: go-github-com-alecthomas-assert: Depricate package. gnu: go-github-com-alecthomas-assert-v2: Update to 2.5.0. gnu: go-github-com-songmu-gitconfig: Move to golang-xyz. gnu: go-github-com-songmu-gitconfig: Fix build. gnu: ghq: Remove package labels. gnu: ghq: Fix build. gnu/packages/configuration-management.scm | 1 + gnu/packages/golang-check.scm | 50 - gnu/packages/golang-xyz.scm | 86 ++- gnu/packages/golang.scm | 55 --- gnu/packages/version-control.scm | 52 +++--- 5 files changed, 125 insertions(+), 119 deletions(-) base-commit: 91d80460296e2d5a01704d0f34fb966a45a165ae -- 2.41.0
bug#69209: Extended packaging example from the Guix cookbook produces an error
Hello, I tried to install the package defined in this section of the Guix cookbook : https://guix.gnu.org/cookbook/en/guix-cookbook.html#Extended-example Running `guix package -f example.scm` gives the following error: Backtrace: In guix/store.scm: 2180:25 19 (run-with-store # …) In guix/gexp.scm: 914:13 18 (_ _) In guix/store.scm: 2008:8 17 (_ _) In guix/gexp.scm: 299:22 16 (_ _) In guix/store.scm: 2008:8 15 (_ _) In guix/packages.scm: 1977:11 14 (_ _) In guix/gexp.scm: 1201:2 13 (_ #) 1068:2 12 (_ _) 909:4 11 (_ _) In guix/store.scm: 2065:12 10 (_ #) 1382:11 9 (map/accumulate-builds # …) 1300:8 8 (call-with-build-handler # …) 2180:25 7 (run-with-store # …) In guix/gexp.scm: 914:13 6 (_ _) In guix/store.scm: 2008:13 5 (_ #) In guix/gexp.scm: 299:51 4 (_) In guix/packages.scm: 2081:2 3 Exception thrown while printing backtrace: error: search-patches: unbound variable ice-9/boot-9.scm:1685:16: In procedure raise-exception: error: search-patches: unbound variable
bug#69201: Emacs master-branch renamed comp-write-bytecode-file which emacs-utils depends on
On Emacs' master-branch, the emacs-lisp function comp-write-bytecode-file has been renamed to comp--write-bytecode-file (i.e. to include a double dash) in this commit [1]: faa46eb8667c11a0725500a50e957eb78021c99f Author: Andrea Corallo AuthorDate: Sun Feb 11 12:31:13 2024 +0100 Commit: Andrea Corallo CommitDate: Sun Feb 11 15:26:12 2024 +0100 Rename a number of native compiler functions Guix' function emacs-compile-directory from module (guix build emacs-utils) [2] depends on this emacs-lisp function. Thus, when emacs-next-minimal is build from the above mentioned commit or later, it won't be possible to build packages that use emacs-build-system, when using --with-input=emacs-minimal=emacs-next-minimal, or in Guile code, argument "#:emacs emacs-next-minimal". This might be considered to be a minor issue as of right now. It'll become a more general problem, when Emacs 30 is released. [1] https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=faa46eb8667c11a0725500a50e957eb78021c99f [2] https://git.savannah.gnu.org/cgit/guix.git/tree/guix/build/emacs-utils.scm?h=08ed3ec64ecd571d92d497b2493f5c0225102c99#n153
bug#69182: home-xmodmap-service-type requires restart to work
I recently set up home-xmodmap-service-type so I could change the
PrtSc key on my ThinkPad into a Hyper modifier. This is my
configuration:
(service home-xmodmap-service-type
(home-xmodmap-configuration
(key-map '("clear mod3"
("remove mod4" . "Hyper_L")
("keycode 107" . "Hyper_R")
("add mod3" . "Hyper_L Hyper_R")
However, after logging into an EXWM session, the PrtSc key is a
Super modifier, not Hyper. The service appears to be starting
successfully:
l0p!ieure~$ herd status xmodmap
Status of xmodmap:
It is running since 11:20:59 AM (35 seconds ago).
Running value is #t.
It is enabled.
Provides (xmodmap).
Requires ().
Will be respawned.
The output of `xmodmap -pm' reports:
xmodmap: up to 4 keys per modifier, (keycodes in
parentheses):
shift Shift_L (0x32), Shift_R (0x3e)
lock
control Control_L (0x25), Control_L (0x42), Control_R
(0x69)
mod1Alt_L (0x40), Alt_R (0x6c), Alt_L (0xcc),
Meta_L (0xcd)
mod2Num_Lock (0x4d)
mod3ISO_Level5_Shift (0xcb)
mod4Super_L (0x85), Super_R (0x86), Super_L (0xce),
Hyper_L (0xcf)
mod5ISO_Level3_Shift (0x5c)
Some of my configuration is applied, while other parts are not:
- "clear mod3" isn’t working; mod3 is ISO_Level5_Shift, which is
the default.
- "remove mod4 = Hyper_L" isn’t working. Hyper_L is still on mod4
(which is the super modifier), which is the default.
- "add mod3 = Hyper_L Hyper_R" isn’t working.
- The "keycode 107 = Hyper_R" config *is* working, which is what
makes PrtSc a super modifier.
If I restart the service, the modifiers work as expected:
l0p!ieure~$ herd restart xmodmap
Service xmodmap has been started.
l0p!ieure~$ guix shell xmodmap -- xmodmap -pm
xmodmap: up to 4 keys per modifier, (keycodes in
parentheses):
shift Shift_L (0x32), Shift_R (0x3e)
lock
control Control_L (0x25), Control_L (0x42), Control_R
(0x69)
mod1Alt_L (0x40), Alt_R (0x6c), Alt_L (0xcc),
Meta_L (0xcd)
mod2Num_Lock (0x4d)
mod3Hyper_R (0x6b), Hyper_L (0xcf)
mod4Super_L (0x85), Super_R (0x86), Super_L (0xce)
mod5ISO_Level3_Shift (0x5c)
I haven’t set up anything else that manipulates keymaps, so I’m
not sure why this isn’t working after login.
I had a suspicion that another service might be running after
xmodmap and changing the keymap. The only home service that looks
like it might do that is x11-display. However, copying
`home-xmodmap-service-type' and `my-xmodmap-shepherd-service' into
my home.scm and editing it to add (requirement '(x11-display)) to
the shepherd-service doesn’t fix the issue.
This appears to be a timing problem. If I remove the service from
my home configuration, but manually run `guix shell xmodmap --
xmodmap /gnu/store/g3hgzx8za4qrrdgn5hjqd80gxkb6sifx-config' after
I log in (the file being the xmodmap configuration created by
`serialize-xmodmap-configuration'), the keymap is set up how I
declare it. So *what* home-xmodmap-service-type does is correct;
but *when* it does it is not.
bug#69129: sbcl-mcclim broke on upgrade to sbcl@2.4.0
Hi Carlo,
> I feel like this work was entirely mechanical, so I would have been
> fine without a copyright header, but I appreciate it.
I think it's reasonable to include copyright to highlight the efforts
contributed ;-). If you check the commit history it usually includes
copyright header for package updates and adjustments.
> I'm curious about the version/commit change, though. Given the -yule
> suffix on the tag name changes with each version we will still need to
> manually update the origin's commit. It feels like unnecessary
> indirection to me. What is the benefit to referencing the package's
> version in the origin like this?
I've done some research on how it looks like in scale, trying to stick
to some constancy, which is hard to determine... so I've decided to keep
version following semantic style and commit as combination of semantic
version and suffix.
How commit is compiled:
--8<---cut here---start->8---
grep "commit.*string-append.*version" gnu/packages/*scm | awk -F: '{print $2}'
| sed -e 's/^[ \t]*//' | sort | uniq -c | sort -rn
2780 (commit (string-append "v" version
46 (commit (string-append "v" version))
38 (commit (string-append "release-" version
20 (commit (string-append name "-" version
12 (commit (string-append "V" version
9 (commit (string-append "v." version
9 (commit (string-append "rocm-" version
8 (commit (string-append "version-" version
7 (commit (string-append version
7 (commit (string-append "go" version
6 (commit (string-append "r" version
6 (commit (string-append "android-" version
5 (commit (string-append "release_" version
5 (commit (string-append "releases/" version
4 (commit (string-append "VERSION_" version
4 (commit (string-append "upstream/" version
4 (commit (string-append "Release_" version
3 (commit (string-append "rel-" version
3 (commit (string-append "release/" version
3 (commit (string-append "jb" version
3 (commit (string-append "debian/" version
3 (commit (string-append "apache-arrow-" version
2 (commit (string-append "wsjtx-" version
2 (commit (string-append "v" version "-stable"
2 (commit (string-append "v_" version
2 (commit (string-append "v" upstream-version
2 (commit (string-append "v" (string-join (string-split version #\.)
2 (commit (string-append "ver." version
2 (commit (string-append "version_" version
2 (commit (string-append version "-stable"
2 (commit (string-append "rel" version
2 (commit (string-append "RELEASE_" version
2 (commit (string-append "Release-" version
2 (commit (string-append "release_" version))
2 (commit (string-append "ppp-" version
2 (commit (string-append "plexus-utils-" version
2 (commit (string-append "plexus-containers-" version
2 (commit (string-append "plexus-components-" version
2 (commit (string-append "plexus-cipher-" version
2 (commit (string-append "mbedtls-" version
2 (commit (string-append "llvmorg-" version
2 (commit (string-append "jline-parent-" version
2 (commit (string-append "edk2-stable" version
2 (commit (string-append "easymock-" version
2 (commit (string-append "cling-v" %cling-version
2 (commit (string-append "biojava-" version
2 (commit (string-append "aether-" version
1 (commit (string-append "Zstd-v" version
1 (commit (string-append "Zlib-v" version
1 (commit (string-append "z3-" version
1 (commit (string-append "yosys-" version
1 (commit (string-append "XSLT-v" version
1 (commit (string-append "Xorg_xtrans-v" version
1 (commit (string-append "Xorg_xkeyboard_config-v" version
1 (commit (string-append "Xorg_xkbcomp-v" version
1 (commit (string-append "Xorg_xcb_util_wm-v" version
1 (commit (string-append "Xorg_xcb_util-v" version
1 (commit (string-append "Xorg_xcb_util_renderutil-v" version
1 (commit (string-append "Xorg_xcb_util_keysyms-v" version
1 (commit (string-append "Xorg_xcb_util_image-v" version
1 (commit (string-append "Xorg_libXrender-v" version
1 (commit (string-append "Xorg_libXrandr-v" version
1 (commit (string-append "Xorg_libxkbfile-v" version
1 (commit (string-append "Xorg_libXi-v" version
1 (commit (string-append "Xorg_libXinerama-v" version
1 (commit (string-append "Xorg_libXfixes-v" version
1 (commit (string-append "Xorg_libXext-v" version
1 (commit (string-append "Xorg_libXdmcp-v" version
1 (commit (string-append "Xorg_libXcursor-v" version
1 (commit (string-append "Xorg_li
bug#63250: package dante : socksify: error: dante client not built with preloading support
On 2024-02-15 at 17:18+01:00, Simon Tournier wrote: > On mer., 20 déc. 2023 at 16:18, Nguyễn Gia Phong wrote: > > Could you take a look at https://issues.guix.gnu.org/67675 > > if it fixes it for you? > > Since patch#67675 is merged, is it fixed now? FWIW it is fixed for me d-; signature.asc Description: PGP signature
