bug#42174: GNU Icecat showing Github Icons?
Yeah, I did.
bug#42174: GNU Icecat showing Github Icons?
Am Freitag, den 03.07.2020, 12:28 -0600 schrieb Pablo Barraza Cornejo: > Leo Prikler writes: > > > It appears icecat is either failing to find or failing to scale > > DejaVu > > Sans. This usually indicates a broken font-config cache, but > > since > > you're on a foreign distro, it may also be, that you need to > > install > > font-dejavu through guix. Does `fc-list | grep DejaVu` produce > > the > > results you'd expect? > > What results should I expect? > I already did as you said, and this is the output of fc-list > > [lots of entries in ~/.guix-profile] > > But it doesn't fix the problem. Okay, so all your DejaVu fonts point towards the Guix profile as they should. I suppose you also already ran `fc-cache -rv` as suggested in the manual, right?
bug#42174: GNU Icecat showing Github Icons?
I've installed font-dejavu and ran fc-cache -rv afterwards. Running fc-list | grep DejaVu gives me this: /home/pablo/.guix-profile/share/fonts/truetype/DejaVuSansMono-BoldOblique.ttf: DejaVu Sans Mono:style=Bold Oblique /home/pablo/.guix-profile/share/fonts/truetype/DejaVuSerif.ttf: DejaVu Serif:style=Book /home/pablo/.guix-profile/share/fonts/truetype/DejaVuSansCondensed-Oblique.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed Oblique,Oblique /home/pablo/.guix-profile/share/fonts/truetype/DejaVuSerifCondensed-Bold.ttf: DejaVu Serif,DejaVu Serif Condensed:style=Condensed Bold,Bold /home/pablo/.guix-profile/share/fonts/truetype/DejaVuSerifCondensed.ttf: DejaVu Serif,DejaVu Serif Condensed:style=Condensed,Book /home/pablo/.guix-profile/share/fonts/truetype/DejaVuSerif-BoldItalic.ttf: DejaVu Serif:style=Bold Italic /home/pablo/.guix-profile/share/fonts/truetype/DejaVuSansMono.ttf: DejaVu Sans Mono:style=Book /home/pablo/.guix-profile/share/fonts/truetype/DejaVuSansCondensed-BoldOblique.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed Bold Oblique,Bold Oblique /home/pablo/.guix-profile/share/fonts/truetype/DejaVuSerif-Bold.ttf: DejaVu Serif:style=Bold /home/pablo/.guix-profile/share/fonts/truetype/DejaVuSerifCondensed-Italic.ttf: DejaVu Serif,DejaVu Serif Condensed:style=Condensed Italic,Italic /home/pablo/.guix-profile/share/fonts/truetype/DejaVuSans-Bold.ttf: DejaVu Sans:style=Bold /home/pablo/.guix-profile/share/fonts/truetype/DejaVuSans-BoldOblique.ttf: DejaVu Sans:style=Bold Oblique /home/pablo/.guix-profile/share/fonts/truetype/DejaVuSansMono-Oblique.ttf: DejaVu Sans Mono:style=Oblique /home/pablo/.guix-profile/share/fonts/truetype/DejaVuSans-ExtraLight.ttf: DejaVu Sans,DejaVu Sans Light:style=ExtraLight /home/pablo/.guix-profile/share/fonts/truetype/DejaVuSansCondensed-Bold.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed Bold,Bold /home/pablo/.guix-profile/share/fonts/truetype/DejaVuSans-Oblique.ttf: DejaVu Sans:style=Oblique /home/pablo/.guix-profile/share/fonts/truetype/DejaVuSans.ttf: DejaVu Sans:style=Book /home/pablo/.guix-profile/share/fonts/truetype/DejaVuSansCondensed.ttf: DejaVu Sans,DejaVu Sans Condensed:style=Condensed,Book /home/pablo/.guix-profile/share/fonts/truetype/DejaVuSansMono-Bold.ttf: DejaVu Sans Mono:style=Bold /home/pablo/.guix-profile/share/fonts/truetype/DejaVuMathTeXGyre.ttf: DejaVu Math TeX Gyre:style=Regular /home/pablo/.guix-profile/share/fonts/truetype/DejaVuSerif-Italic.ttf: DejaVu Serif:style=Italic /home/pablo/.guix-profile/share/fonts/truetype/DejaVuSerifCondensed-BoldItalic.ttf: DejaVu Serif,DejaVu Serif Condensed:style=Condensed Bold Italic,Bold Italic But that didn't solve the problem
bug#42174: GNU Icecat showing Github Icons?
On Fri, Jul 03, 2020 at 01:07:44AM -0600, Pablo Barraza Cornejo wrote: > So, I'm currently trying to install Icecat with the Guix Package manager, > running on Manjaro, and everytime I try to launch it most letters show up as > Github icons. If I launch it from the terminal I get this: > > (/gnu/store/5jxv1hvbz0s41nv5y1ip5kfijskapq3c-icecat-68.10.0-guix0-preview1/lib/icecat/.icecat-real:143036): > Pango-WARNING **: 07:04:07.363: failed to create cairo scaled font, expect > ugly output. the offending font is 'DejaVu Sans 9.9990234375' I wonder if it's related to bug #42006, "Installing font-dejavu breaks other fonts": https://bugs.gnu.org/42006
bug#42151: [PATCH 0/3] offload to Childhurd fails: setting synchronous mode: locking protocol
Ludovic Courtès writes: Hi! >> It seems there is a compatibility bug/problem/thing with the db.sqlite >> that we produce on GNU/Linux. While an unpatched sqlite3 on the Hurd >> can read it, and work with it, the unpatched sqlite has locking >> problems. I found a workaround, though: dumping and loading the >> database file. [..] >> So...about the compatibility problem. I tried to diff the db.sqlite-orig >> db.sqlite-init binary files: they look completely different. Not sure >> how to handle this workaround, maybe we can insert a two system* calls >> somewhere when building the disk image? > > Weird, weird! > > Could you compare ‘db.dump’ created on GNU/Hurd with ‘db.dump’ created > from the same ‘sqlite3 -init’ command on GNU/Linux? Yeah, they are identical. The initial dump can only be created atm on GNU/Linux; the dump can be loaded (obviously) anywhere like so >> $ sqlite3 -init db.dump db.sqlite-init .quit and the resulting initial db.sqlite is the same. Guess we can do that by hand for now... > (Perhaps loading the dump reorders entries or something.) Yes, "or something" certainly! :) I have no clue... If/when we decide to pinpoint this bug, what could be a first step? Who is creating the database right now, is that the C++ daemon or guile-sqlite3. IWBN to have that code create/save a smaller version and see when reading fails. > I think the binary format of the database is supposed to be > architecture-independent and filling it is supposed to be deterministic. Yes, that works. > Congrats for getting this far anyway! Yeah... \o/ Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#34033: Offloading sometimes hangs
Hi! Mathieu Othacehe skribis: >> Something is going wrong here! I'll keep investigating. > > To help us investigate those issues I added a "/status" page, which is > also accessible from a new drop-down menu in the Cuirass navigation bar. > > See, https://ci.guix.gnu.org/status. Nice! So it’s roughly like the info at /api/queue, but filtered to running builds, right? > Hydra has the same interface, but also a "Machine status" page, that > breaks down the running builds machine per machine. I plan to implement > that one next. Reading Hydra code, I also discovered that some part of > the offloading is directly done from Hydra, which talks with the > nix-daemon of the connected build machines, interesting! Yes, Hydra does most of the scheduling by itself. Since this is redundant with what the daemon + offload do, I thought Cuirass shouldn’t do any scheduling at all and instead let the daemon take care of it all. This has advantages (the daemon has a global view and can achieve better scheduling), and drawbacks (the protocol requires us to wait for ‘build-things’ completion before we can queue more builds, and scheduling decisions are almost invisible to Cuirass). > While I'm writing, we have 5 running builds for ~1 hour, and 76040 queued > builds. Given the computing power of Berlin, there must be a bottleneck > somewhere. Yes! I’ve often run “guix processes” on berlin, then stracing the ‘SessionPID’ process. It’s insightful because you sometimes see the daemon is stuck waiting for a machine to offload to, sometimes it’s stuck waiting for a build that will perhaps just eventually timeout… Ludo’.
bug#42151: [PATCH 0/3] offload to Childhurd fails: setting synchronous mode: locking protocol
Hi! Jan Nieuwenhuizen skribis: > Thanks -- it seems that buys us a pretty cheap fix after all, $-wise ;) Heheh. :-) > It turns out that Debian's patch (and thus this patch series) is > probably OK: It fixes the locking problem on the Hurd, while exposing > another bug, apparently: "unable to open database file". > > It seems there is a compatibility bug/problem/thing with the db.sqlite > that we produce on GNU/Linux. While an unpatched sqlite3 on the Hurd > can read it, and work with it, the unpatched sqlite has locking > problems. I found a workaround, though: dumping and loading the > database file. > > Look... > > $ scp childhurd2:/var/guix/db/db.sqlite db.sqlite-orig > db.sqlite > 100% 144KB 5.8MB/s 00:00 > 11:30:37 janneke@dundal:~/tmp [env] > $ sqlite3 db.sqlite-orig .dump > db.dump > 11:30:45 janneke@dundal:~/tmp [env] > $ sqlite3 -init db.dump db.sqlite-init .quit > -- Loading resources from db.dump > 11:30:49 janneke@dundal:~/tmp [env] > $ cmp db.sqlite-orig db.sqlite-init > db.sqlite-orig db.sqlite-init differ: byte 19, line 1 > [1]11:31:11 janneke@dundal:~/tmp [env] > $ scp db.sqlite-init childhurd2:/var/guix/db/db.sqlite > db.sqlite-init > 100% 144KB 7.3MB/s 00:00 > 11:31:21 janneke@dundal:~/tmp [env] > $ guix offload test > guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'... > guix offload: Guix is usable on 'localhost' (test returned > "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test") > guix offload: 'localhost' is running GNU Guile 3.0.4 > sending 1 store item (0 MiB) to 'localhost'... > exporting path `/gnu/store/y6b7bjqsazmm6jsyj5y80dqqajysw64p-export-test' > guix offload: 'localhost' successfully imported > '/gnu/store/y6b7bjqsazmm6jsyj5y80dqqajysw64p-export-test' > retrieving 1 store item from 'localhost'... > guix offload: successfully imported > '/gnu/store/gxz6hzyc1cy3m1w9l7f2dk6rcspvymxf-import-test' from 'localhost' > 11:31:29 janneke@dundal:~/tmp [env] > > So...about the compatibility problem. I tried to diff the db.sqlite-orig > db.sqlite-init binary files: they look completely different. Not sure > how to handle this workaround, maybe we can insert a two system* calls > somewhere when building the disk image? Weird, weird! Could you compare ‘db.dump’ created on GNU/Hurd with ‘db.dump’ created from the same ‘sqlite3 -init’ command on GNU/Linux? (Perhaps loading the dump reorders entries or something.) I think the binary format of the database is supposed to be architecture-independent and filling it is supposed to be deterministic. Congrats for getting this far anyway! Ludo’.
bug#42174: GNU Icecat showing Github Icons?
It appears icecat is either failing to find or failing to scale DejaVu Sans. This usually indicates a broken font-config cache, but since you're on a foreign distro, it may also be, that you need to install font-dejavu through guix. Does `fc-list | grep DejaVu` produce the results you'd expect?
bug#42175: "pulseaudio? #f" setting does not prevent pulseaudio from autostarting
I don't think pulseaudio autostarting is governed by alsa. There are two options you can try. 1. disable autospawning through configuration. For that, try setting the client-conf field of the pulseaudio-configuration to '((autospawn . no)) 2. Removing the pulseaudio package from gnome and anywhere else it might be propagated. (I don't think it is propagated in other services). Regards, Leo
bug#42151: [PATCH 0/3] offload to Childhurd fails: setting synchronous mode: locking protocol
Ludovic Courtès writes: Hi! > "Jan (janneke) Nieuwenhuizen" skribis: > >> $ guix offload test >> guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'... >> guix offload: Guix is usable on 'childhurd' (test returned >> "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test") >> guix offload: 'childhurd' is running GNU Guile 3.0.4 >> guix offload: error: exception occurred on remote host 'localhost': >> (%exception #> "setting synchronous mode: locking protocol" status: 1>>) > Does it help if you set ‘settings.fsyncMetadata = false’ in the daemon? > As a stop-gap, we could add a command-line option if that helps. Tried that, thanks. No, it does not help. (But that's good news, see below!) > The “synchronous = normal” mode translates to ‘fsync’ calls, right? If > you rpctrace sqlite3, do you see ‘file_sync’ calls failing? Tried that before, rpctrace hangs before I see something useful. > Does sqlite pass its tests on GNU/Hurd? That's the (or at least a) right question: YES! > My 2¢! Thanks -- it seems that buys us a pretty cheap fix after all, $-wise ;) It turns out that Debian's patch (and thus this patch series) is probably OK: It fixes the locking problem on the Hurd, while exposing another bug, apparently: "unable to open database file". It seems there is a compatibility bug/problem/thing with the db.sqlite that we produce on GNU/Linux. While an unpatched sqlite3 on the Hurd can read it, and work with it, the unpatched sqlite has locking problems. I found a workaround, though: dumping and loading the database file. Look... --8<---cut here---start->8--- $ scp childhurd2:/var/guix/db/db.sqlite db.sqlite-orig db.sqlite 100% 144KB 5.8MB/s 00:00 11:30:37 janneke@dundal:~/tmp [env] $ sqlite3 db.sqlite-orig .dump > db.dump 11:30:45 janneke@dundal:~/tmp [env] $ sqlite3 -init db.dump db.sqlite-init .quit -- Loading resources from db.dump 11:30:49 janneke@dundal:~/tmp [env] $ cmp db.sqlite-orig db.sqlite-init db.sqlite-orig db.sqlite-init differ: byte 19, line 1 [1]11:31:11 janneke@dundal:~/tmp [env] $ scp db.sqlite-init childhurd2:/var/guix/db/db.sqlite db.sqlite-init 100% 144KB 7.3MB/s 00:00 11:31:21 janneke@dundal:~/tmp [env] $ guix offload test guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'... guix offload: Guix is usable on 'localhost' (test returned "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test") guix offload: 'localhost' is running GNU Guile 3.0.4 sending 1 store item (0 MiB) to 'localhost'... exporting path `/gnu/store/y6b7bjqsazmm6jsyj5y80dqqajysw64p-export-test' guix offload: 'localhost' successfully imported '/gnu/store/y6b7bjqsazmm6jsyj5y80dqqajysw64p-export-test' retrieving 1 store item from 'localhost'... guix offload: successfully imported '/gnu/store/gxz6hzyc1cy3m1w9l7f2dk6rcspvymxf-import-test' from 'localhost' 11:31:29 janneke@dundal:~/tmp [env] --8<---cut here---end--->8--- So...about the compatibility problem. I tried to diff the db.sqlite-orig db.sqlite-init binary files: they look completely different. Not sure how to handle this workaround, maybe we can insert a two system* calls somewhere when building the disk image? Greetings, Janneke -- Jan Nieuwenhuizen | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
bug#42175: "pulseaudio? #f" setting does not prevent pulseaudio from autostarting
https://guix.gnu.org/manual/en/html_node/Sound-Services.html (define %my-services ;; My very own list of services. (modify-services %desktop-services (alsa-service-type config => (alsa-configuration (inherit config) (pulseaudio? #f) reconfigure, reboot, login to gnome, then bash-5.0$ pgrep pulseaudio 517 1261
bug#42174: GNU Icecat showing Github Icons?
So, I'm currently trying to install Icecat with the Guix Package manager, running on Manjaro, and everytime I try to launch it most letters show up as Github icons. If I launch it from the terminal I get this: (/gnu/store/5jxv1hvbz0s41nv5y1ip5kfijskapq3c-icecat-68.10.0-guix0-preview1/lib/icecat/.icecat-real:143036): Pango-WARNING **: 07:04:07.363: failed to create cairo scaled font, expect ugly output. the offending font is 'DejaVu Sans 9.9990234375' (/gnu/store/5jxv1hvbz0s41nv5y1ip5kfijskapq3c-icecat-68.10.0-guix0-preview1/lib/icecat/.icecat-real:143036): Pango-WARN ING **: 07:04:07.363: font_face status is: file not found (/gnu/store/5jxv1hvbz0s41nv5y1ip5kfijskapq3c-icecat-68.10.0-guix0-preview1/lib/icecat/.icecat-real:143036): Pango-WARN ING **: 07:04:07.363: scaled_font status is: file not found (/gnu/store/5jxv1hvbz0s41nv5y1ip5kfijskapq3c-icecat-68.10.0-guix0-preview1/lib/icecat/.icecat-real:143036): Pango-WARN ING **: 07:04:07.368: failed to create cairo scaled font, expect ugly output. the offending font is 'DejaVu Sans 9.895 5078125' (/gnu/store/5jxv1hvbz0s41nv5y1ip5kfijskapq3c-icecat-68.10.0-guix0-preview1/lib/icecat/.icecat-real:143036): Pango-WARN ING **: 07:04:07.368: font_face status is: file not found (/gnu/store/5jxv1hvbz0s41nv5y1ip5kfijskapq3c-icecat-68.10.0-guix0-preview1/lib/icecat/.icecat-real:143036): Pango-WARN ING **: 07:04:07.368: scaled_font status is: file not found JavaScript error: resource:///modules/sessionstore/SessionStore.jsm, line 1325: uncaught exception: 2147746065 (/gnu/store/5jxv1hvbz0s41nv5y1ip5kfijskapq3c-icecat-68.10.0-guix0-preview1/lib/icecat/.icecat-real:143077): Pango-WARN ING **: 07:04:08.322: failed to create cairo scaled font, expect ugly output. the offending font is 'DejaVu Sans 9.999 0234375' (/gnu/store/5jxv1hvbz0s41nv5y1ip5kfijskapq3c-icecat-68.10.0-guix0-preview1/lib/icecat/.icecat-real:143077): Pango-WARN ING **: 07:04:08.322: font_face status is: file not found (/gnu/store/5jxv1hvbz0s41nv5y1ip5kfijskapq3c-icecat-68.10.0-guix0-preview1/lib/icecat/.icecat-real:143077): Pango-WARN ING **: 07:04:08.322: scaled_font status is: file not found (/gnu/store/5jxv1hvbz0s41nv5y1ip5kfijskapq3c-icecat-68.10.0-guix0-preview1/lib/icecat/.icecat-real:143077): Pango-WARN ING **: 07:04:08.338: failed to create cairo scaled font, expect ugly output. the offending font is 'DejaVu Sans 9.895 5078125' (/gnu/store/5jxv1hvbz0s41nv5y1ip5kfijskapq3c-icecat-68.10.0-guix0-preview1/lib/icecat/.icecat-real:143077): Pango-WARN ING **: 07:04:08.338: font_face status is: file not found (/gnu/store/5jxv1hvbz0s41nv5y1ip5kfijskapq3c-icecat-68.10.0-guix0-preview1/lib/icecat/.icecat-real:143077): Pango-WARN ING **: 07:04:08.338: scaled_font status is: file not found Any help would be appreciated.
bug#40626: Poor performance on low-end ARMv7 devices
Hello, > Many ARM Single Board Computers are commonly used with microSD for > storage, and some microSD cards are extremely slow (and sometimes > unreliable when they are old). > > Could the performance issues be related to storage device I/Os? For those ARMv7 devices, which have few substitutes available and not much computation power, an approach is to work from a x86 machine and cross-compile disk-images. We will also have network booting supported soon, which will allow to do the same, but without having to write an SD card. In the meantime I would propose to close this bug, as there's not much that can be done, I think. Thanks, Mathieu
bug#42173: Nix on Guix System: can't update channels
Hi, I tried to set up the Nix package manager on my Guix System following the instructions at http://guix.gnu.org/manual/en/guix.html#index-Nix . Unfortunately, after reconfiguring the system and adding a channel with `nix-channel --add https://nixos.org/channels/nixpkgs-unstable`, when I tried to update the channels (`nix-channel --update`), this is what I got: --8<---cut here---start->8--- [brown@121408 ~]$ nix-channel --update unpacking channels... while setting up the build environment: executing '/gnu/store/pwcp239kjf7lnj5i4lkdzcfcxwcfyk72-bash-minimal-5.0.16/bin/bash': No such file or directory builder for '/nix/store/fqvvrsyznxfzckxbiz6krlykdb6w105n-nixpkgs-20.09pre232864.55668eb671b.drv' failed with exit code 1 error: build of '/nix/store/fqvvrsyznxfzckxbiz6krlykdb6w105n-nixpkgs-20.09pre232864.55668eb671b.drv' failed error: program '/gnu/store/lsixql26nig4v3icn124ja3ivjpgvn99-nix-2.3.6/bin/nix-env' failed with exit code 100 --8<---cut here---end--->8--- Any tips on how to fix this? Cheers, Sergiu
bug#34033: Offloading sometimes hangs
Hey, > Something is going wrong here! I'll keep investigating. To help us investigate those issues I added a "/status" page, which is also accessible from a new drop-down menu in the Cuirass navigation bar. See, https://ci.guix.gnu.org/status. Hydra has the same interface, but also a "Machine status" page, that breaks down the running builds machine per machine. I plan to implement that one next. Reading Hydra code, I also discovered that some part of the offloading is directly done from Hydra, which talks with the nix-daemon of the connected build machines, interesting! While I'm writing, we have 5 running builds for ~1 hour, and 76040 queued builds. Given the computing power of Berlin, there must be a bottleneck somewhere. Thanks, Mathieu
