bug#39324: GNOME Weather doesn't start
I can reproduce. Note that from GNOME, running "gnome-weather" in a shell works. However the icon does not work either. I noticed that the desktop file executes --8<---cut here---start->8--- gapplication launch org.gnome.Weather --8<---cut here---end--->8--- Does any one know how this is supposed to work? If not, as a workaround I suggest we replace this line with "gnome-weather". -- Pierre Neidhardt https://ambrevar.xyz/
bug#39117: GNOME Files: No file thumbnails
I can reproduce. Note that I've managed to get _some_ thumbnails when I first logged in. Now the thumbnail generation seems to be completely gone. Any clue what's happening, anyone? Has this ever worked before? -- Pierre Neidhardt https://ambrevar.xyz/
bug#30435: libreoffice: Fonts don't show up after install
I can reproduce this on guix ce226e9d8d52d2530f057f2000d36c0d55380ade. But libreoffice is not the only victim: it seems that most applications fail to see the fonts installed in the user profile (on Guix System). Emacs is one example. Running --8<---cut here---start->8--- fc-cache -fv --8<---cut here---end--->8--- fixes the issue. Should we run this command in a profile hook? -- Pierre Neidhardt https://ambrevar.xyz/
bug#30435: libreoffice: Fonts don't show up after install
Pierre Neidhardt writes: Hi, I wanted to add that the opposite is also true: removing a font without running fc-cache always makes my emacs die on start, so I agree that running the command automatically makes sense. Are there any unwanted side-effects? Thanks, Nicolò > I can reproduce this on guix ce226e9d8d52d2530f057f2000d36c0d55380ade. > > But libreoffice is not the only victim: it seems that most applications > fail to see the fonts installed in the user profile (on Guix System). > Emacs is one example. > > Running > > --8<---cut here---start->8--- > fc-cache -fv > --8<---cut here---end--->8--- > > fixes the issue. > > Should we run this command in a profile hook? > > -- > Pierre Neidhardt > https://ambrevar.xyz/
bug#30435: libreoffice: Fonts don't show up after install
Hi there, I think this is the same issue as 26877. Can font information be compiled into a fonts.conf? - John
bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts
Hello Florian,
"pelzflorian (Florian Pelz)" skribis:
> works, but I have no idea how to turn that into a keyboard-layout.
> I tried setting in /etc/config.scm
>
> (keyboard-layout
> (keyboard-layout "ar,fr" "azerty" #:options '("grp:alt_shift_toggle")))
>
> but it threw an error.
The attached patch fixes that. I’ve confirmed that it works as intended
in Xorg and in the console (I’m not sure it works in GDM, but it
definitely works in an xterm in ratpoison, for instance.)
I was wondering whether to push the patch as-is or to require people to
write:
(keyboard-layout '("ar" "fr") …)
instead. Maybe it’s OK to leave the comma here.
However, I noticed that this doesn’t work in GRUB. Actually, even
(keyboard-layout "fr") doesn’t work in GRUB (at the command line after
the boot menu), which seems like a regression.
Thanks,
Ludo’.
diff --git a/gnu/bootloader/grub.scm b/gnu/bootloader/grub.scm
index 28e6cb1f5f..190b717163 100644
--- a/gnu/bootloader/grub.scm
+++ b/gnu/bootloader/grub.scm
@@ -240,7 +240,11 @@ the 'share/X11/xkb/symbols/' directory of 'xkeyboard-config'."
"-i" #+(keyboard-layout->console-keymap layout)
"-o" #$output
- (computed-file (string-append "grub-keymap." (keyboard-layout-name layout))
+ (computed-file (string-append "grub-keymap."
+(string-map (match-lambda
+ (#\, #\-)
+ (chr chr))
+(keyboard-layout-name layout)))
builder))
(define (grub-setup-io config)
diff --git a/gnu/system/keyboard.scm b/gnu/system/keyboard.scm
index cd3ab37b27..5bd13a44be 100644
--- a/gnu/system/keyboard.scm
+++ b/gnu/system/keyboard.scm
@@ -1,5 +1,5 @@
;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2019 Ludovic Courtès
+;;; Copyright © 2019, 2020 Ludovic Courtès
;;;
;;; This file is part of GNU Guix.
;;;
@@ -94,5 +94,8 @@ Layout information is taken from the XKEYBOARD-CONFIG package."
#$(keyboard-layout-name layout))
(computed-file (string-append "console-keymap."
-(keyboard-layout-name layout))
+(string-map (match-lambda
+ (#\, #\-)
+ (chr chr))
+(keyboard-layout-name layout)))
build))
bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts
Hi, Mathieu Othacehe skribis: >> That’s exactly what it does, see (shepherd comm). >> >> Perhaps we just need to have the installer service depend on ‘syslogd’, >> at which point nothing goes to /dev/console? > > Heh, I read it too fast, sorry :) The issue was in fact that we are > calling `start-service' and `stop-service' from `apply-locale' in (gnu > installer), and printing shepherd messages to shepherd-message-port > which is stderr by default. > > Fixed on wip-installer-help. Awesome. Do you think that branch is ready for a merge? Or did you want to further discuss some of the changes? Florian seemed to agree that it’s a good thing. Ludo’.
bug#40361: Shepherd Git repo web-page still says 'GNU dmd'
Hi, Leo Famulari skribis: > The Shepherd's Git hosting (cgit and gitweb) still calls the project > 'GNU dmd': > > https://git.savannah.gnu.org/cgit/shepherd.git > > Is this something we can fix ourselves or should ask the Savannah admins > for assistance? We need to find a “support request” on Savannah for this. Ludo’.
bug#40369: guix environment messed up shell
Hi, "Alexandru-Sergiu Marton" skribis: > Whenever I run `guix environment `, the shell I get has > problems when I write commands that span multiple lines. The most basic > glitch is that when I get to the end of the first line, the next > characters end up at the beginning of the same line, overwriting > everything I wrote so far. One of the wilder scenarios is the one where > each new character is added on a new line, _on top_ of the one I'm > currently writing. > > Steps to reproduce: > 1. $ guix environment neovim > 2. Write stuff that is longer than a single line. What shell do you use? Could you check if this is somehow due to PS1? For instance run: guix environment neovim export PS1='\u\$ ' write a lng line Thanks in advance, Ludo’.
bug#40142: (guix cve) discards configuration "vendor", leading to false positives
Hi, Brice Waegeneire skribis: > It looks like, for most free software the name of the software is used > as > the vendor too, but I'm guessing that's not always the case in > particular > when two project are using the same name. So we can't just filter the > entries where the vendor name isn't the name of the package or we could > end up with false negatives which seems worse than false positive for a > vulnerability checker. Yeah. > One solution would be to display the name of the vendor when it doesn't > correspond to the name of the package. Such solution would still output > false positives but at least it will be quicker to identify then as > such, > compared to looking up and reading trough each CVE. Yes, though I think that (guix cve) should simply preserve the vendor part, and leave it up to its user, ‘guix lint’, to display vendor mismatches. Thanks, Ludo’.
bug#40381: Guix shouldn't request substitutes for profile derivations
Hi, pkill9 skribis: > I see that Guix is requesting substitutes from the build servers before > it builds a profile derivation. Can you show more precisely what you mean by pasting a command and its output? With the recent changes in the implementation of grafts, what happens is usually this: $ guix build foo updating the list of substitutes… The following things will be built/downloaded: … updating the list of substitutes… The following things will be built/downloaded: … The second stage here typically includes profile.drv as well as grafts. All this is expected behavior. Detailed behavior depends on what’s in /gnu/store, the freshness of substitute info in /var/guix/substitute/cache, and applicable grafts for the package(s) at hand. Thanks, Ludo’.
bug#40368: Docker server version is "dev" (should be a version number)
Hi Pierre, thanks for the report! Fixed in guix master in commit 451c38b7d6017434a2a06646f1da6ef1e6ca4614. pgpNg9kE0WiZk.pgp Description: OpenPGP digital signature
bug#40386: guix system init can't find file system by UUID, workaround results in broken boot
Hi, raingloom skribis: > Trying to install Guix System onto an SSD using an UltraBay dock. > Config is the attached file (with slight variations in the obvious > places) > > `readlink /dev/disk/by-uuid/643a215d-a30e-473b-826e-5c35de29e38f` gives > me /dev/sdb1 > > Yet using (uuid "643a215d-a30e-473b-826e-5c35de29e38f") results in: > > ``` > sudo -E guix system init --no-bootloader > Configs/Guix/desktop-parametric.scm /mnt > :( /home/raingloom/Configs/Guix/desktop-parametric.scm:50:26: error: > file system with UUID '643a215d-a30e-473b-826e-5c35de29e38f' not found > ``` > > Switching the UUID to uppercase as in the example (thankfully) doesn't > change anything, not even the error message. > > I tried using a label, same result. What file system is on /dev/sdb1? The code responsible for that is in (gnu build file-systems). It currently recognizes only some file system types: ISO9660, ext2/3/4, Btrfs, FAT32, FAT16, and JFS. Can you try: sudo guix repl ,use(gnu build file-systems) (find-partition-by-uuid (uuid "643a215d-a30e-473b-826e-5c35de29e38f")) ? > I ended up using the /dev/disk/by-uuid and /dev/disk/by-id paths for > the root file system and the bootloader respectively, and that resulted > in a succesful system init, but upon trying to boot the SSD with the > other machine, I got thrown into a rescue shell, because it couldn't > find the root using that path. Yes, because /dev/disk is not accessible early on. That’s why the manual recommends using ‘uuid’ or ‘file-system-label’. > **(Quick aside: there really should be a guide for using that rescue > shell. I can get around in a /bin/sh one, but this is nearly unusable. > At least autocompletion should be supported.)** Yes, that reminds me someone reported a serious Bournish bug on IRC. Thanks, Ludo’.
bug#40369: guix environment messed up shell
> What shell do you use? bash > Could you check if this is somehow due to PS1? For instance run: > > guix environment neovim > export PS1='\u\$ ' > write a lng line That fixed it, so it isn't a Guix bug. Thanks a lot! It was something wrong with how I set the colors with tput that only manifested when I entered an environment cause that appends a colored "[env]" to my PS1.
bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts
Hello, > Do you think that branch is ready for a merge? Or did you want to > further discuss some of the changes? Florian seemed to agree that it’s > a good thing. Yes, for me it's ready. If you are ok I can check that our new fancy tests are still passing and merge it :) Now, there are other locale related issues we may want to address before the release: * The keyboard layout issue in Grub console you reported here[1]. * The keyboard layout issue during hard drive decryption in Grub[2]. I had a quick look to the second one and using `grub-mkstandalone' seems to be the right move but it would then require extensive testing on real hardware. Mathieu [1]: https://lists.gnu.org/archive/html/bug-guix/2020-04/msg00024.html [2]: https://lists.gnu.org/archive/html/bug-guix/2020-01/msg00350.html
bug#39117: GNOME Files: No file thumbnails
On Thu, 02 Apr 2020 02:55:34 -0500 Pierre Neidhardt wrote > I can reproduce. > > Note that I've managed to get _some_ thumbnails when I first logged in. > Now the thumbnail generation seems to be completely gone. > > Any clue what's happening, anyone? Has this ever worked before? I've been using GNOME in the Guix System since I installed it (almost a year ago), and this have never worked for me. Also, opening the files with some applications will make the thumbnails work for these particular files. For example, opening images in the GIMP or browsing files with file managers like Thunar and Caja (if I recall correctly).
bug#40388: Calibre test suite fails
Hi, Both on my local machine and on the CI[0], the Calibre test suite has been failing with the following error: == ERROR: test_msgpack (calibre.test_build.BuildTest) -- Traceback (most recent call last): File "/tmp/guix-build-calibre-3.42.0.drv-0/calibre-3.42.0/src/calibre/test_build.py", line 124, in test_msgpack self.assertEqual(obj, msgpack_loads(s)) File "/tmp/guix-build-calibre-3.42.0.drv-0/calibre-3.42.0/src/calibre/utils/serialize.py", line 113, in msgpack_loads return msgpack.unpackb(dump, ext_hook=msgpack_decoder, raw=False, use_list=use_list) File "/gnu/store/z7dz4iiaivmadhk0x50qs5zv3rwykrmd-python2-msgpack-1.0.0/lib/python2.7/site-packages/msgpack/fallback.py", line 129, in unpackb ret = unpacker._unpack() File "/gnu/store/z7dz4iiaivmadhk0x50qs5zv3rwykrmd-python2-msgpack-1.0.0/lib/python2.7/site-packages/msgpack/fallback.py", line 666, in _unpack "%s is not allowed for map key" % str(type(key)) ValueError: is not allowed for map key -- This is happening on both staging and master. There have been no changes to the calibre package itself since January. I have run a git bisect and the offending change appears to be in commit 66ab2f5e3a0df665f6e39203aedd2bf4812e6a71, when python-msgpack was updated to version 1.0.0. [0]: e.g. http://ci.guix.gnu.org/build/2485977/details -- Josh Holland
bug#40327: [MATE] shutdown and reboot not possible from UI
Hi, Jonathan Brielmaier skribis: > MATE 1.24 (1.22) as well doesn't have a shutdown and reboot button in > the UI. You can either logout and shutdown/reboot from GDM or > shutdown/reboot via terminal. Fixed in a1a9d3848c4197f0e711e1d675771c82aa4dc200. The good news is that mate-control-center now has first-class support for elogind! Ludo’.
bug#30435: libreoffice: Fonts don't show up after install
Hi, Pierre Neidhardt skribis: > Running > > fc-cache -fv > > fixes the issue. > > Should we run this command in a profile hook? Profile hooks are normal derivations; as such, they don’t have access to anything but their dependencies and their output(s). There’s currently no infrastructure to run arbitrary code upon package installation (which I think is a feature more than a bug :-)). We could make an exception, but it’s kinda ugly. I wonder if, instead, we could have Fontconfig realize that the cache is stale somehow. Alternately, we could generate the cache in a profile hook and have Fontconfig use that cache instead of the one in ~/.cache. However, Fontconfig would need to be able to: 1. Be told which cache to use, not just the one from ~/.guix-profile, so that it works equally well with other profiles. 2. Merge several caches, so it can also account for fonts installed in /run/current-system/profile. We discussed all this several times in the past but I don’t think it went further. Ludo’.
bug#30435: libreoffice: Fonts don't show up after install
Hi Nicolò, Nicolò Balzarotti skribis: > Hi, I wanted to add that the opposite is also true: removing a font > without running fc-cache always makes my emacs die on start, so I agree > that running the command automatically makes sense. Actually, if you can capture a stack trace of Emacs, that may tell us what part of Fontconfig to look at if we want to change it to gracefully handle stale cache entries. Ludo’.
bug#40361: Shepherd Git repo web-page still says 'GNU dmd'
On Thu, Apr 02, 2020 at 12:27:42PM +0200, Ludovic Courtès wrote: > Hi, > > Leo Famulari skribis: > > > The Shepherd's Git hosting (cgit and gitweb) still calls the project > > 'GNU dmd': > > > > https://git.savannah.gnu.org/cgit/shepherd.git > > > > Is this something we can fix ourselves or should ask the Savannah admins > > for assistance? > > We need to find a “support request” on Savannah for this. I've reached out to rwp about this.
bug#40369: guix environment messed up shell
"Alexandru-Sergiu Marton" skribis: >> What shell do you use? > > bash > >> Could you check if this is somehow due to PS1? For instance run: >> >> guix environment neovim >> export PS1='\u\$ ' >> write a lng line > > That fixed it, so it isn't a Guix bug. Thanks a lot! > > It was something wrong with how I set the colors with tput that only > manifested when I entered an environment cause that appends a colored > "[env]" to my PS1. Cool, thanks for letting us know! Ludo’.
bug#40277: murmur-configuration missing newline in config file
Simon Mages via Bug reports for GNU Guix writes: > Hi, > > i am using guix on my server and i want to use mumble. > I found that it is working fine so far, but there is this one bug. > The config file generated is missing a newline. > > The following patch fixes the issue: Nice find, applied! PS: In the future, please send git-style patches created with 'git format-patch' to make merging easier. signature.asc Description: PGP signature
bug#40361: Shepherd Git repo web-page still says 'GNU dmd'
On Thu, Apr 02, 2020 at 12:27:42PM +0200, Ludovic Courtès wrote: > Hi, > > Leo Famulari skribis: > > > The Shepherd's Git hosting (cgit and gitweb) still calls the project > > 'GNU dmd': > > > > https://git.savannah.gnu.org/cgit/shepherd.git > > > > Is this something we can fix ourselves or should ask the Savannah admins > > for assistance? > > We need to find a “support request” on Savannah for this. Done!
bug#40390: Rendering problems when using fonts from Guix on foreign distro
Hello all, I have Guix installed on a foreign distro (Ubuntu 19.10) as a package manager, and I am attempting to use fonts installed through Guix for applications installed from Guix, such as Emacs and keepassxc. I have installed fontconfig and a few font packages. However, I am noticing that these fonts seem to be interfering with fonts installed via the system's package manager (APT) and are causing rendering problems in non-Guix applications such as evince. The font packages I have installed from Guix are as follows: --8<---cut here---start->8--- evan@virtualplaza:~$ guix package --list-installed | grep font font-ubuntu 0.83out /gnu/store/6ydn8a96n2zmmrhjckqklfmg83frwl9w-font-ubuntu-0.83 font-gnu-freefont-ttf 20120503out /gnu/store/bp0hagiy6j8r0x11r4arsyv7k61lyqfk-font-gnu-freefont-ttf-20120503 font-dejavu 2.37out /gnu/store/yr42nyxrqkh89fanvii82br6qil4zcbx-font-dejavu-2.37 gs-fonts8.11out /gnu/store/8ppj83wc1mmrdydh9cy7vqvg0bym8l0q-gs-fonts-8.11 font-adobe-source-han-sans 1.004 jp /gnu/store/z9mgamhzwnh73w3y7q9flg54gmzr9kx7-font-adobe-source-han-sans-1.004-jp fontconfig 2.13.1 out /gnu/store/rkq6ipys8hf5hw66jkzzw4nfr6ncq96a-fontconfig-2.13.1 font-abattis-cantarell 0.111 out /gnu/store/l0h8n4jn0xhj942gdh28i3rvbbywi613-font-abattis-cantarell-0.111 --8<---cut here---end--->8--- However, when I open a document in evince, the terminal spits out the following errors about "cairo scaled fonts": --8<---cut here---start->8--- (evince:19449): Pango-WARNING **: 10:28:58.135: failed to create cairo scaled font, expect ugly output. the offending font is 'Ubuntu 11' (evince:19449): Pango-WARNING **: 10:28:58.135: font_face status is: (evince:19449): Pango-WARNING **: 10:28:58.135: scaled_font status is: out of memory (evince:19449): Pango-WARNING **: 10:28:58.135: shaping failure, expect ugly output. shape-engine='PangoFcShapeEngine', font='Ubuntu 11', text='●' (evince:19449): Pango-WARNING **: 10:28:58.142: failed to create cairo scaled font, expect ugly output. the offending font is 'Ubuntu 10.5595703125' (evince:19449): Pango-WARNING **: 10:28:58.142: font_face status is: (evince:19449): Pango-WARNING **: 10:28:58.142: scaled_font status is: out of memory (evince:19449): Pango-WARNING **: 10:28:58.142: shaping failure, expect ugly output. shape-engine='PangoFcShapeEngine', font='Ubuntu 10.5595703125', text='The quick brown fox jumps over the lazy dog.' (evince:19449): Pango-WARNING **: 10:28:58.408: failed to create cairo scaled font, expect ugly output. the offending font is 'Ubuntu Italic 11' (evince:19449): Pango-WARNING **: 10:28:58.408: font_face status is: (evince:19449): Pango-WARNING **: 10:28:58.408: scaled_font status is: out of memory (evince:19449): Pango-WARNING **: 10:28:58.408: shaping failure, expect ugly output. shape-engine='PangoFcShapeEngine', font='Ubuntu Italic 11', text='3' (evince:19449): Pango-WARNING **: 10:28:58.414: failed to create cairo scaled font, expect ugly output. the offending font is 'Ubuntu Italic 13.1982421875' (evince:19449): Pango-WARNING **: 10:28:58.414: font_face status is: (evince:19449): Pango-WARNING **: 10:28:58.414: scaled_font status is: out of memory (evince:19449): Pango-WARNING **: 10:28:58.414: shaping failure, expect ugly output. shape-engine='PangoFcShapeEngine', font='Ubuntu Italic 13.1982421875', text='Document contains no annotations' --8<---cut here---end--->8--- When viewing the application window, all text is replaced by empty white boxes, as shown in the attached screenshot. Is this a bug, or am I simply doing something wrong here? Is there any additional configuration I need to do to get fonts from the system and Guix to cooperate with each other? Any help would be appreciated. Please also let me know if there's any needed but missing information and I'll be happy to provide it. Thanks, -- Evan signature.asc Description: PGP signature
bug#39949: [core-updates] rust@1.20 fails tests
Bengt Richter writes: > Hi Marius, > > On +2020-03-31 16:04:03 +0200, Marius Bakke wrote: >> Marius Bakke writes: >> >> > Rust 1.20 fails a test on core-updates, possibly because of the new >> > version of GNU Make (4.3). >> > >> > I suppose we can disable that test for the bootstrap builds as long as >> > it works for the latest version of Rust. >> >> Fixed by giving Rust an earlier version of GNU Make in commit >> 47cd0febe957b698cc2ae28978bdc3bc89e787f9. > > ISTM this kind of "fixed" is not the same as e.g. an upstream upgrade that > "fixes" "the problem" -- so I'm wondering if work-flow-wise > you have a way to tell some upgrade-watching robot to notify you (or your > s/w[1]) > when the inevitable revision to your "fix" should be done. I don't know of any such service, but would probably use it if it exists! Often fixes are already available in upstream repositories, so it's a matter of locating it and checking the log on the file in question. In this case I was too lazy as Rust 1.20 is already ancient and there is work on bootstrapping 1.29 directly in another issue. > Are there any general standards for subscribing interest in being notified > when a particular package or file gets upgraded/revised/etc in any "distro" > your package may be dependent on? I do subscribe to a bunch of mailing lists and Atom feeds to get notified of new releases and encourage others to do the same for packages they care about. Pro tip: both GitLab and GitHub offers release feeds on these URLs: https://gitlab.com/project/package/tags?format=atom https://github.com/project/package/releases.atom > [1] Is there such a thing as a derivation/service that sits and waits for such > a notification, and maybe sends you a patch when it does get notified? > > Just curious how the world works :) IME best way to learn how something works is to take part in it! I have learned a whole lot since I got involved with Guix, both personally and professionally, and don't intend to stop any time soon! :-) signature.asc Description: PGP signature
bug#40377: guix build --with-commit is broken
Hi, Brice Waegeneire skribis: > $ guix build mlt --with-commit=mlt=v6.18.0 > updating checkout of 'https://github.com/mltframework/mlt.git'... > guix build: error: Git failure while fetching > https://github.com/mltframework/mlt.git: the requested type does not > match the type in the ODB [...] > $ guix build picom --with-commit=picom=vNext > updating checkout of 'https://github.com/yshui/picom.git'... > guix build: error: Git failure while fetching > https://github.com/yshui/picom.git: the requested type does not match > the type in the ODB Interestingly, guix build guile-gcrypt --with-commit=guile-gcrypt=v0.2.0 would work just fine. This is because the tags in the above examples actually point to a “commit” object instead of pointing to a “tag” object as in the guile-gcrypt case. Weird. Fixed with commit efa578ecaece67366b4b0e2266de7c2faaa4ae54. Thanks, Ludo’.
bug#39301: imported module (guix build utils) overrides core binding `delete'
Hi, Ludovic Courtès skribis: > strypst...@posteo.net skribis: > >> Whenever running "sudo guix system reconfigure /path/to/config.scm I >> get the following warnings: >> >> building >> /gnu/store/vpazjd711byj3jszh7jrk5d8lq51077g-switch-to-system.scm.drv... >> ;;; WARNING: loading compiled file >> /gnu/store/5bd6ywmfcxxa4gvpzg0pdbjwmf24cxkl-module-import-compiled/gnu/build/activation.go >> failed: >> ;;; In procedure load-thunk-from-memory: incompatible bytecode kind >> ;;; compiling [...] > All these warnings are harmless and stem from the Guile 2.2/3.0 > transition. Specifically, it comes from the fact that ‘guix system > reconfigure’ evaluates this code with the host Guile (in this case 3.0), > whereas the modules are built for 2.2, which is what the Shepherd > depends on. > > The culprit is ‘local-eval’ in (guix scripts system), which simply uses > ‘primitive-eval’ to evaluate the code, thus disregarding the Guile > version that should be used. > > One possibility would be to instead evaluate the expression in a > separate Guile process for the intended Guile version. It turns out to be easy to implement, and better than let people be confused when they install the new release. Done in commit 5517750344be05c91bc2979c1a0e2348a9ae902d. Thanks, Ludo’.
bug#40392: [core-updates] pack vs. build discrepancy with --target=i586-pc-gnu
On current ‘wip-hurd-vm’ (very close to ‘core-updates’), there’s this discrepancy between ‘pack’ and ‘build’: --8<---cut here---start->8--- $ ./pre-inst-env guix build hurd --target=i586-pc-gnu -d --no-grafts /gnu/store/m8gvpjh1dlgx8v3dbvkpqw17k00h9hv3-hurd-0.9-1.91a5167.drv $ ./pre-inst-env guix pack hurd --target=i586-pc-gnu -n --no-grafts The following derivations would be built: /gnu/store/1vq3dzc74afy34i6ylymlqqw8hmxvrc8-tarball-pack.tar.gz.drv /gnu/store/bzxr1n7z5rkksavql1nckyri4qdslrms-profile.drv /gnu/store/gs1zz38m5vvm6fy3nh1jv3fj4vikzmhf-hurd-0.9-1.91a5167.drv /gnu/store/17m76zz1nia4mxafh5bzcjlcgf631pzq-glibc-hurd-headers-2.31.drv The following profile hooks would be built: /gnu/store/0sk6qm07y32gf3ljxk718d2g7c0nnh8m-manual-database.drv /gnu/store/61qr5qwryi3k1vwbi2ddhy24qy7ld4di-fonts-dir.drv /gnu/store/ahcfp2f1ddnym4sw4j8c23mz64mkzvid-info-dir.drv /gnu/store/iw2hzd7fsl62a7y2nj577bg89cys0i3q-ca-certificate-bundle.drv $ git log |head commit b61467c0c813e65ed86d9b1b8ba1187f117751b9 Author: Ludovic Courtès Date: Thu Apr 2 16:47:40 2020 +0200 gnu: cross-libc: Add patch to add 'mach_print' symbol on GNU/Hurd. * gnu/packages/patches/glibc-hurd-mach-print.patch: New file. * gnu/local.mk (dist_patch_DATA): Add it. * gnu/packages/cross-base.scm (cross-libc): Add 'patch-libc/hurd' phase when 'hurd-target?' is true. --8<---cut here---end--->8--- ‘guix pack’ would build a different hurd derivation, one that actually fails to build. The difference here is that the “wrong” hurd derivation depends on a glibc-hurd-headers-2.31.drv that lacks MiG as an input, which suggests that the (if (hurd-target?) …) conditional in ‘glibc’ is not working as expected. Ludo’.
bug#40393: Use ngettext to internationalize plural in guix/lint.scm
In the check-description-style function in guix/lint.scm, the string "sentences in description should be followed ..." should be pluralized using ngettext, not ~p as it is now. ~p only adds an 's' if the corresponding argument is greater than 1. Needless to say, there are many languages that don't follow this pattern. signature.asc Description: PGP signature
bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts
Hi all, On +2020-04-02 12:25:37 +0200, Ludovic Courtès wrote: > Hi, > > Mathieu Othacehe skribis: > > >> That’s exactly what it does, see (shepherd comm). > >> > >> Perhaps we just need to have the installer service depend on ‘syslogd’, > >> at which point nothing goes to /dev/console? > > > > Heh, I read it too fast, sorry :) The issue was in fact that we are > > calling `start-service' and `stop-service' from `apply-locale' in (gnu > > installer), and printing shepherd messages to shepherd-message-port > > which is stderr by default. > > > > Fixed on wip-installer-help. > > Awesome. > > Do you think that branch is ready for a merge? Or did you want to > further discuss some of the changes? Florian seemed to agree that it’s > a good thing. > I am wondering about hot-plugged keyboards, whether plugged in before power-up or late, after login and GUI terminal activation. I see/imagine several issues. 1) Legacy unices seem just to have accepted any usb device identifying itself as key event generator and merged the events indiscriminately into existing key-event streams, with security issues ignored, and alternate layouts ignored :-/ What I'm writing on now [1] has a US keyboard (which is annoying if I am trying to write swedish, or embarrass myself with my French :), so I am recharging the batteries for an old swedish Logitech kb that has a wireless connection to a USB receiver. (I'll return to report how that worked out -- I think I saw that PureOS was able to handle different-layout keyboards in different concurrent sessions -- different keyboards and displays can be attached to different "seats" -- or something like that, I obviously don't know much yet ;-) Anyway, to the point: even if I'm wrong about PureOS handling concurrent different-layout keyboards, I think that would be a good goal for GuixOS/Hurd/Shepherd to implement. So WDYT about a little kb experimenting to expose potential issues before final decisions? 2) Another issue is that with hot-plugging and booting from external media, keyboard layouts are unknowable ahead of time (except by humans deciding they will only boot from media they know carry KB layout info matching the booting host's KB). So who/what is the first user of keyboard layout info? I think probably the OEM who decided which key should interrupt booting to go into BIOS setup, since the BIOS has to continue with some assumption of keyboard layout. Probably matches the BIOS-developer's kb, hard coded ;-) But consider a "NUC" box, with no predetermined peripherals, just sockets. Plug in the right keyboard or keep rebooting and hitting Esc or Del or F11 and hope you don't trigger anything disastrous. Or get online with another machine and search for how someone succeeded. Filter bad advice. How many times have you gone through that ? ;-) Ok, next user after BIOS, probably some boot loader. Its image can not contain knowledge of what keyboard is the source of key-codes, so it must either receive converted key codes or be able to get the right layout info to do the conversion itself -- or punt, using a US layout for anything and everything. ... Let's see, '-' is '/' and '+' is '-' and ... argh. (recognize install iso experience? setfont sun12x22 helps :) So anyway, eliding, the boot loader gets the root file system loaded and pivots to it and the kernel can figure out keyboards again for itself, maybe. Is this really a good design for gnu guix systems? All that Mach stuff I read April 1st sounded really neat ;-) (I regret having pointed out the date and not letting it run. I apologize for interrupting the fun "joke" ;-/ ) Logitech KB batteries still charging, will have to try that later ... HTH make multiple concurrent different-layout keyboards be part of the future :) > Ludo’. > > > [1] Purism Librem13v4 laptop: an emergency-prompted purchase when my swedish laptop died in US) -- Regards, Bengt Richter
bug#40396: linux-libre - BUG: Bad page state in process
Hello, I've been seeing many of those: > BUG: Bad page state in process in my `dmesg` logs. After few of them, my whole machine freezes and I need to reboot. RAM is not faulty, but other hardware could be, not sure. I'm confused what the cause of this bug is, all information I could find online does not mention causes or is about all sort of causes, for the same bug message. `dmesg` log : [ 595.520589] BUG: Bad page state in process Chrome_IOThread pfn:2b5cd [ 595.520600] page:eac980ad7340 count:0 mapcount:0 mapping: index:0x1 [ 595.520605] flags: 0x000200(owner_priv_1) [ 595.520611] raw: 00000200 dead0100 dead0200 [ 595.520615] raw: 0001 [ 595.520618] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set [ 595.520621] bad because of flags: 0x200(owner_priv_1) [ 595.520623] Modules linked in: fuse ccm joydev iTCO_wdt iTCO_vendor_support coretemp kvm_intel arc4 kvm irqbypass ath9k uvcvideo ath9k_common snd_hda_codec_conexant snd_hda_codec_generic videobuf2_vmalloc input_leds ath9k_hw videobuf2_memops videobuf2_v4l2 psmouse ath videobuf2_common serio_raw pcspkr videodev mac80211 media i2c_i801 btusb cfg80211 lpc_ich btrtl btbcm btintel i915 bluetooth ecdh_generic cec snd_hda_intel drm_kms_helper thinkpad_acpi snd_hda_codec nvram snd_hda_core drm snd_hwdep snd_pcm i2c_algo_bit fb_sys_fops syscopyarea snd_timer sysfillrect snd e1000e soundcore sysimgblt video ptp pps_core mac_hid virtio_rng virtio_console virtio_net virtio_blk virtio_balloon virtio_pci virtio virtio_ring isci libsas scsi_transport_sas pata_atiixp pata_acpi nls_iso8859_1 wp512 serpent_generic [ 595.520626] xts dm_crypt hid_apple hid_generic usbhid hid uas usb_storage ahci libahci [ 595.520626] CPU: 1 PID: 717 Comm: Chrome_IOThread Tainted: G I 4.19.109-gnu #1 [ 595.520626] Hardware name: LENOVO 4057D67/4057D67, BIOS CBET4000 3774c98 09/07/2016 [ 595.520626] Call Trace: [ 595.520626] dump_stack+0x6d/0x95 [ 595.520626] bad_page+0xcb/0x120 [ 595.520626] check_new_page_bad+0x67/0x80 [ 595.520626] get_page_from_freelist+0xe65/0x1400 [ 595.520626] __alloc_pages_nodemask+0x125/0x2c0 [ 595.520626] alloc_pages_vma+0x88/0x1f0 [ 595.520626] shmem_alloc_page+0x4b/0x90 [ 595.520626] shmem_alloc_and_acct_page+0x75/0x1b0 [ 595.520626] shmem_getpage_gfp+0x174/0xc20 [ 595.520626] shmem_fallocate+0x373/0x4c0 [ 595.520626] vfs_fallocate+0x144/0x280 [ 595.520626] ksys_fallocate+0x41/0x70 [ 595.520626] __x64_sys_fallocate+0x1e/0x30 [ 595.520626] do_syscall_64+0x5a/0x120 [ 595.520626] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 595.520626] RIP: 0033:0x7f543d065325 [ 595.520626] Code: 54 49 89 cd 55 53 49 89 d4 89 f5 89 fb 48 83 ec 18 e8 df 64 01 00 4d 89 ea 41 89 c0 4c 89 e2 89 ee 89 df b8 1d 01 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 17 65 01 00 8b 44 [ 595.520626] RSP: 002b:7f5423ffdcc0 EFLAGS: 0293 ORIG_RAX: 011d [ 595.520626] RAX: ffda RBX: 0176 RCX: 7f543d065325 [ 595.520626] RDX: RSI: RDI: 0176 [ 595.520626] RBP: R08: R09: 0005 [ 595.520626] R10: 0020 R11: 0293 R12: [ 595.520626] R13: 0020 R14: 7f5423ffe120 R15: [ 595.520626] Disabling lock debugging due to kernel taint Another.. : [0.00] Linux version 4.19.112-gnu (nixbld@) (gcc version 7.4.0 (GCC)) #1 SMP 1 [0.00] Command line: BOOT_IMAGE=/gnu/store/zsa1aq6211pch0v1bn9pd7mi27l8rglg-linux-libre-4.19.112/bzImage --root=/dev/mapper/cryptroot --system=/gnu/store/86g310fsadj0waipwqbhlsw09di1x2zc-system --load=/gnu/store/86g310fsadj0waipwqbhlsw09di1x2zc-system/boot quiet [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Enabled xstate features 0x3, context size is 576 bytes, using 'standard' format. [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0fff] type 16 [0.00] BIOS-e820: [mem 0x1000-0x0009] usable [0.00] BIOS-e820: [mem 0x000c-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xbfa9] usable [0.00] BIOS-e820: [mem 0xbfaa-0xbfbf] type 16 [0.00] BIOS-e820: [mem 0xbfc0-0xcfff] reserved [0.00] BIOS-e820: [mem 0xf000-0xf3ff] reserved [0.00] BIOS-e820: [mem 0x0001-0x00012fff] usable [
bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts
On Thu, Apr 02, 2020 at 11:45:01AM +0200, Ludovic Courtès wrote:
> The attached patch fixes that. I’ve confirmed that it works as intended
> in Xorg and in the console
Thank you, it works fine, even for entering the LUKS passphrase after
GRUB in the Linux kernel. Only GRUB uses U.S. QWERTY layout.
> (I’m not sure it works in GDM, but it
> definitely works in an xterm in ratpoison, for instance.)
GDM retains my U.S. English layout even after herd stop xorg-server
and deleting all files in /var/lib/gdm. Deleting all files also made
my fonts different in gnome-terminal, Icecat, Emacs, also
gnome-initial-setup got run again, but these issues are unrelated to
this bug and do not happen if one does not “sudo rm -rf
/var/lib/gdm/.*”.
> I was wondering whether to push the patch as-is or to require people to
> write:
>
> (keyboard-layout '("ar" "fr") …)
>
> instead. Maybe it’s OK to leave the comma here.
Lists seem more consistent with the Scheme syntax.
>
> However, I noticed that this doesn’t work in GRUB. Actually, even
> (keyboard-layout "fr") doesn’t work in GRUB (at the command line after
> the boot menu), which seems like a regression.
I suppose on GRUB using at_keyboard it worked in the past?
For me there’s no regression because keyboard layouts never worked
(using usb keyboard rather than at keyboard), see
.
Back then I was told to open a bug at GRUB, which I have not done.
There are other old bugs on keyboard layouts and bugs on USB keyboards
among the GRUB bugs at Savannah though. I find an e-mail to bug-grub
concerning the same issue
,
but no bug at Savannah. I will not open a bug I suppose, also the
GRUB manual says many keymaps don’t work well.
https://www.gnu.org/software/grub/manual/grub/html_node/Internationalisation.html#Input-terminal
It says “Own keyboard implementations (at_keyboard and usb_keyboard)
supports any key but work on one-char-per-keystroke. So no dead keys
or advanced input method. Also there is no keymap change hotkey. In
practice it makes difficult to enter any text using non-Latin
alphabet. Moreover all current input consumers are limited to ASCII.”
f5961dd5854cec1ed9a41365836d63aa15256642 for usb keyboard was a bad
commit (passphrase input was QWERTY, back then usb keyboard did not
work at all in GRUB menu).
Regards,
Florian
bug#40273: installer: No way to input Latin characters with non-Latin keyboard layouts
On Fri, Apr 03, 2020 at 02:38:16AM +0200, pelzflorian (Florian Pelz) wrote: > For me there’s no regression because keyboard layouts never worked Maybe there is a regression for at_keyboard users. For usb_keyboard: I believe it would be easier to ignore the wrong keyboard layout for the GRUB command-line and to resolve the layout issue for the passphrase by not requiring one. That is (as a default) installing GRUB on the unencrypted EFI System Partition. AFAIK this is currently not possible. It would require copying all references of grub.cfg to the EFI System Partition instead of the encrypted Store. On non-EFI systems, this would make it necessary to have a separate boot partition when using encryption. Regards, Florian
