<mbakke>(I'm about to break all the TeX Live stuff again) <sneek>lfam, dftxbs3e says: removing that third-party channel fixes that gcrypt bug <lfam>dftxbs3e: It might help to reply to the bug tracker <45294@debbugs.gnu.org> saying that removing the channel worked around that bug. It might help other people who are stuck <ngz>I had a great idea today. It struck me that our Rust modules (crates-io.scm, crates-graphics.scm and crates-gtk.scm) are not optimal. <lfam>I hope you were wearing a helmet when that thought struck you ;) <ngz>I think that we should split them alphabetically instead: crates-a-f.scm, crates-g-l.scm, crates-m-r.scm, and crates-s-z.scm <ngz>lfam: my tin foil hat, of course. <lfam>Now there is a modest proposal! <lfam>Is this because they are too large and take a long time to build? <ngz>Yes, crates-io.scm is too large (soon 40k), and crates-graphics.scm require you to *think* about it. <ngz>I mean, when I'm in my 100ish packaged dependency, I don't even want to think about where it should go. <lfam>I see you were CC-ed on the rust packaging thread by Hartmut <lfam>ngz: I think you should work with them (and whoever else appears often in the git log for those files) and handle it in the way you think is best <lfam>I know that Guile has been making a lot of improvements in compile times for these sorts of things <lfam>I wonder if there are more improvements on the way <lfam>It shouldn't really matter how large these files are... <ngz>It could be interesting to know why crates-gtk.scm and crates-graphics.scm appeared in the first place. <lfam>ngz: I don't recall, but it's likely that the module was taking way too long to build <lfam>It's the same reason that other languages have the "xyz" modules as well as other topical modules <civodul>profmakx: it could be that "guix system build" gives what lxc expects, then? <PotentialUser-45>Hello, I installed the Xen hypervisor via package manager. However, I am unable to boot into it. How do I update the grub entries to include Xen? *xelxebar is interested as well <bdju>anyone have experience changing system-wide date/time format via locale stuff? I am in the US but I want Y-M-D dates and 24 hour time. *some* programs don't let you configure these directly and just use your locale settings apparently. <bdju>okay, I think en.SE.utf8 is what I wanted <bdju>how do I permanently set my LC_TIME without changing the other locale stuff? I see in the operating-system definition there's just a single (locale "foo") line <bdju>is ~/.profile an okay place to declare a different LC_TIME or should that be in the system config? <raghavgururajan>On a foreign distro, is it possible to bootstrap guix (after git clone) without having guix installed in the foreign distro? <ryanprior>Yes, you need to manually install all the dependencies and then run ./bootstrap, ./configure, make <ryanprior>Having Guix makes it convenient to install all the deps, but it is not at all necessary <guix-vits>bdju: i never ran into such app. what about wrapper: `export LC_TIME=en_en.en; exec app` <guix-vits>with symlinks like ~/bin/partisan -> ~/bin/wrapper <raghavgururajan>After installing guix on foreign distro via script, does application setup step has to be done as root user or regular user? <mbakke>brettgilio: I don't know either, you'll have to try it and find out :) <mbakke>in the worst case, you can always wrap the executable with PATH <brettgilio>Alright i'm going to bookmark that and i'll give it a go in the morning :) ***sorki is now known as srk
***iyzsong-- is now known as iyzsong-w
<sneek>Welcome back civodul, you have 1 message! <sneek>civodul, daviid says: that define-method creates a generic if it does not exist is part of the (clos) protocol, changing that would be a very serious break (in the protocol) - also note that it is an error to redefine a generic, and unfortunately guile did break the protocol wrt that, guile does not raise an exception if one redefines a generic (very unfortunately, I have no idea why it breaks that fundamental part of the protocol) <efraim>how can I pass text to guix repl? I know I can do this for guile. guile -c '(use-modules (guix scripts build)) (guix-build "hello")' <civodul>efraim: there's no -c flag (unfortunately) <cbaines>efraim, this works at least: guix repl -- <(echo "(display \"hello\")") <efraim>looks like the easiest might be to write to a temporary buffer in vim and then pass that to guix repl, if I want to go that route <cbaines>guix-user, I believe so, at least guix show gcc-toolchain@10 shows something <guix-user>The reason I ask is, #debian-devel mentions "Bloated: gcc-10 (will be reverted)" in their channel message. <efraim>perhaps they didn't like their update from 10.1.1-26(ish) to 10.2.1-1 ***thelounge5756 is now known as us-nigga
***us-nigga is now known as ripe-cu-nt
*raghavgururajan thinks the person is troll ***ChanServ sets mode: +o civodul
*janneke resets wip-arm-bootstrap ***ripe-cu-nt was kicked by civodul (Kicked by civodul)
<janneke>tcc-boot now builds on ARM in the beggings of a reduced binary seed bootstrap <profmakx>ok, so more n00b quesions: if I do guix system init my-host.scm /mnt it populates that directory with *stuff* <profmakx>mhm. maybe i just need to look at guix system containr <civodul>if you run "guix system build", you can check the "boot-paramaters" file <profmakx>(I am not so much interested in "boot" but still in the container stuff adn try to find a way to make containers that I can use so i am trying to understand how to start a guix system) <profmakx>that boot script looks very similar to what the container script doees, right? *ripe-cu-nt has some loonies ***ripe-cu-nt was kicked by civodul (Kicked by civodul)
<profmakx>(I also seem to have installed guix-sd on a rockpro eMMC last night, so there's that) <wehlutyk>Does `guix build --rounds=2 --check <package>` automatically report non-determinism in builds or should I manually check the hashes? (the second build is soon over but the logs of the first one were too long to still have them in the terminal window, and I didn't store them on files. Each build takes 2 days so I'd like to avoid starting again) <civodul>profmakx: the "boot" script (1) runs service "activation snippets", and (2) spawns shepherd <civodul>wehlutyk: it automatically errors out if the two attempts didn't yield the same output <wehlutyk>that would be worth adding in the manpage <civodul>wehlutyk: it's written in the manual <civodul>note that man pages for Guix are just stubs; run "info guix" for the real thing :-) <wehlutyk>yes, I found it in "info guix" too (which obviously is the same content). I'll be using that instead of man pages then 🙂 <sneek>Welcome back dannym, you have 1 message! <sneek>dannym, raghavgururajan says: Would you be able to push the #44957 v4 patch-set without cosmetic changes patch? <dannym>janneke: About the setjmp--the only "problem", if you can call it that, in implementing setjmp is that the ABI used determines which registers you have to save (... and know that exist in the first place) <dannym>janneke: Otherwise it's easy to implement; but every time we switch from ABI to EABI or from EABI to EABI with VFP or whatever, the set of registers changes <dannym>It's just a matter of having the right #if or something <dannym>Also, if one forgets to save some registers, that will lead to some spooky bugs, far from the setjmp <janneke>dannym: possibly we can do without setjmp, we'll know once we manage/fail to build our first glibc <dannym>Yeah, I'd say let's add it when we need it <dannym>and then just be overly save-happy <dannym>But there is a potential compilation error waiting with being overly save-happy: Maybe the compiler in that mode doesn't *have* those registers in the inline assembly <janneke>i'm just planning to postpone releasing mes 0.23 until we know -- eh, if that's within a reasonable time frame <dannym>I think if we know which gcc and which tcc and which mescc is used with our respective setjmp implementation, then we could just check their source code for setjmp <dannym>But I was hoping that later stages don't use our setjmp in the first place <dannym>The only reason our setjmp supports gcc *at all* is for us to be able to verify-compile program A using gcc, and program A using mescc, and compare <dannym>Otherwise our setjmp wouldn't do even the little gcc it can do <dannym>Isn't tcc's setjmp added eventually when doing the bootstrap chain ? <janneke>the mes c library is used until we build glibc-2.2.5 <dannym>So we are using mes libc with tcc-compiled programs ? <janneke>that's why libc (for self hosting mes), libc+tcc (for running tcc), libc+gnu (for building gcc-core+glibc) <janneke>then, mes-tcc compiles libc+gnu for boot0-tcc and onwards <dannym>Looking at mes wip's include/setjmp.h, I'm pretty sure the x86 case would also need to #if __GNUC__ <dannym>It's basically just luck that works with so few registers <dannym>In any case, one would just have to add some #if __TINYC__ in there and then add an lib/arm-mes-tcc directory <dannym>But there's no lib/x86-mes-tcc directory O_o ... how does that work ? <dannym>An on #if __TINYC__ in lib/x86-mes-* <janneke>i didn't feel like cleaning that up/changing that yet <dannym>I've checked tcc's arm-gen.c, and it has these registers: r0 r1 r2 r3 r12 f0 f1 f2 f3; and if TCC_ARM_VFP, additionally: d4/s8 d5/s10 d6/s12 d7/s14 <dannym>Probably don't need to actually *save* all of those--but if we do, we are safe :) <dannym>In any case, once you need this stuff, I can add it :) <dannym>janneke: Our novena is online btw. It has 4 GiB of RAM and 4 GiB of swap and a 1.3 TiB SATA HDD. In case you need to build big stuff... <janneke>i've been switching to overdrive1 because it's sooo much faster <janneke>...but it didn't build 100% correctly until yesterday (aarch64/vs ARM) <dannym>Yeah, I requisited the novena exactly because it is 32 bit arm <dannym>aarch64 is one more step to get right :) <dannym>But it's nice that mes on overdrive now also works! <janneke>indeed and it's a step that i'm not comfortable with <janneke>getting tcc to write an ELF header that works involved faking 'eabi' <janneke>we use tcc's lib/armeabi, but building with TCC_ARM_EABI fails terribly <dannym>Huh, we might want to look at why one day <dannym>I mean in the long run probably 32 bit arm is going to be rare, and people are gonna bootstrap mes from aarch64; and we probably can use a similar contraption as the one we use on x86_64 <dannym>I mean there's some weird stuff in EABI, like on each function call the stack has to be aligned to 16 (I think) Byte <dannym>And the specified syscall interface is slightly different <dannym>But I think I'm already using the EABI syscall interface <dannym>*shrugs* I guess--but for our (mes bootstrapping) purposes, that's exactly what we want. <dannym>janneke: If you should have logs of the terrible build failure, please send them to me. I'm curious what it's doing <janneke>Program received signal SIGILL, Illegal instruction. <profmakx>dannym sorry, I didn't mean to sound too dismissive <dannym>"bt" info probably not that great either? <janneke>bash is compiled without debug info...let's fix that first <PotentialUser-41>Hey ! I destroyed my bootloader due to false usage of guix init (I thought I could initialize a system on a external HD that I intended to use in another machine, but it overrode my current bootloader). Now I cannot boot anymore. How do I restore it ? I booted from a guix install usb ... is there something like guix init --bootloader-only or some s <civodul>PotentialUser-41: hi! what exactly is broken? perhaps you can edit the GRUB command line at boot time? <civodul>perhaps you could boot from an ISO like the installation ISO <civodul>and from there, mount your root partition to /mnt, and run "guix system init /mnt/etc/config.scm /mnt" <PotentialUser-41>yea, like i said .. i did that :) now i just need a way to basically do a guix init, without the copying part .. just have it reinstall the bootloader given my config.scm <civodul>"guix system init" will still copy the whole thing <civodul>and actually it'll wipe your original store <civodul>you could look for /mnt/gnu/store/*-install-bootloader <user_oreloznog>@civodul: Hi :-) I started proofreading guix-manual and I can happily test my changes with my 'guix environment guix' on po/doc/guix-manual.fr.po :-) <user_oreloznog>Said that, I have made (among others) 2 translations noted below, one where I am not sure of myself and another about the distinction between "mot-clef" and "mot-clé": <civodul>user_oreloznog: nice! i could take a look later, but perhaps that's more a question for roptat though <roptat>user_oreloznog, that's guix system, not guixSD :p <roptat>user_oreloznog, les ";; TRANSLATORS:" sont des commentaires qui n'ont pas besoin d'être traduits, c'est juste pour les traducteurs :) <roptat>quant à mot-clé vs mot-clef, c'est juste que j'utilise plus courament l'orthographe pré-1990, mais pas pour tout, donc c'est pas plus mal de tout harmoniser <roptat>comme j'ai toujours pas le projet séparé sur savannah, on utilise un dépôt à moi sur framagit en attendant *roptat didn't notice he switched to French ^^' <user_oreloznog>roptat: merci ;-) je pense aussi que c'est pas plus mal d'utiliser la post-1990 <civodul>perhaps we should give up on Savannah <roptat>civodul, if we give up on Savannah, then we still need something else, because I don't want to be the only one having access to that repo <roptat>user_oreloznog, est-ce que tu veux t'en occuper ? je crois que j'ai déjà fait une passe sur les accents circonflexes par exemple, mais pas sur des mots en particulier, comme clef -> clé *mroh loves --with-patch transformation! <roptat>(la partie sur les règles commence page 11) <apteryx>is it expected that 'guix describe' says "guix describe: error: failed to determine origin" following a 'guix pull -C channels.cm' ? <apteryx>as channels.scm is used to explicitly control where Guix came from... I'm guessing not. <civodul>apteryx: hi! the message means you're using 'guix' from the 'guix' package, not from 'guix pull' <civodul>roptat: do you have a link to the Savannah support request? <civodul>Ineiev is one of the people who takes care of it <civodul>doing a great job, but unfortunately they're also often displaying unhelpful behavior <user_oreloznog>roptat: par où dois-je commencer ? Il faut que j'apprenne à utiliser savannah ? <civodul>hi bandali! apparently roptat can't get a repo to host Guix translations <roptat>weird it's on nongnu, but that's the link I get <apteryx>civodul: interesting, I've already Guix pulled. I'm testing Guix on a VM, and just installed it using the install shell script. <roptat>user_oreloznog, il suffit simplement de récupérer le fichier po et de corriger <bandali>civodul, roptat, right :-) has there been any update since roptat's last reply there? <apteryx>seems I need to add ~/.config/guix/current/bin to my PATH <bandali>roptat, so there have been no changes/fixes for the current languages? <bandali>isn't that sort of a precursor for going forward with that request? <roptat>wait, I thought I sent a reply after that <apteryx>hmm, nevermind, it's there after a relogin, I think. <civodul>apteryx: perhaps you're missing "hash guix"? <roptat>bandali, we actually fixed the copyright issues, and I thought I sent an updated tarball, but apparently the message doesn't show, so I must have done something wrong <apteryx>civodul: I was missing a logout/login to refresh the environment. Its configured (from the install script) in /etc/profile.d/guix.sh. <bandali>roptat, hmm, i wonder if you sent it via email to the mailing list side? let me check <apteryx>civodul: but, I'm still getting the "Pensez à installer le paquet `glibc-utf8-locales'" hint, although I've installed that package. <user_oreloznog>roptat: j'ai trouvé le fichier, c'est bien le po/doc/guix-manual.fr.po (du tar.gz de la page savannah ?) <bandali>roptat, i don't seem to be able to find anything newer than your last reply in the savannah-register-public list's archives <civodul>apteryx: could it be that you're using a locale that's not in that package? like fr_CA? :-) <apteryx>perhaps en_CA.UTF-8 is not in it. I'll try just glibc-locales <roptat>user_oreloznog, ça devrait être ça <apteryx>civodul: it'd be nice if the hint was smarter: e.g. look at the locale in use, suggest the correct package :-) <roptat>bandali, you know what, I think I clicked "preview" and never clicked "submit changes" or something like that ^^' <civodul>apteryx: or maybe print "Aren't you happy with English after all? Try LC_ALL=en_US." ;-) <apteryx>yes, the US variant is very important. <roptat>bandali, I sent a short message to say we fixed the copyright/license issues <bandali>roptat, great, got it! i'll try to set aside some time over the next few days on the task. for future cases, please feel free to double check and/or followup either on the tracker or via direct email if you don't end up hearing from any of the savannah hackers :-) <apteryx>perhaps we should just ship the locales out of the box and get done with it <bandali>apteryx, oh yeah :-( i too recall wishing that en_CA.UTF-8 was part of the smaller package so i didn't have to pull/install all of glibc-locales <apteryx>en_US.utf-8 doesn't require any locale package to be intalled, correct? <bandali>i think you'd still need the smaller glibc-utf8-locales package, no? <maav>apteryx: on guix system the configured locale should be already available, on guix itself you always need at least one locale installed to change from LC_ALL=C <apteryx>although the systemd installed service from the install script sets the environment with: "Environment='GUIX_LOCPATH=/var/guix/profiles/per-user/root/guix-profile/lib/locale' LC_ALL=en_US.utf8", the daemon would still complain about locale, I reckon because the lib/locale directory specified did not exist until installing a locale package. <apteryx>maav: so the C locale != en_US.utf-8 ? <maav>exactly, C locale is a separate locale, the one loaded by default (unlike in guile programs, btw) <maav>(guile programs set up gettext automatically, that's the reason) <apteryx>I always thought of it as an alias, for some reason :-). Thanks for fixing that misconception of mine. <apteryx>In any case, the install script should install the glibc-utf8-locales to the root user Guix profile, since it already hard-codes the profile to en_US.utf-8. <maav>it should be utf8 being picky ;-) <maav>but yes, the locale has to be installed on the profile to be usable <civodul>apteryx: 'guix' already ships glibc-utf8-locales <civodul>roughly, glibc-utf8-locales is guaranteed to always be visible to the 'guix' command <PotentialUser-41>I suppose the bootloader is the most vulnerable part of guix system ... I find myself reinstalling the whole system after breaking (just) the bootloader :( <civodul>well, you ran "guix system init" with a different config, didn't you? :-) <maav>PotentialUser-41: grub-install works as with any other distro, but there are no quick way to do it "just that step" as grub.cfg generation depends on the system generation itself <cbaines>a nice step forward would be for the system profile to include a script to install the bootloader, and documentation to exist for running this from the installation system <PotentialUser-41>civodul: Well, yes. It was a misunderstanding. I thought I could use it to prepare the harddrive for another computer. This certainly won't happen again :D <apteryx>civodul: good to know! Perhaps it's a problem with the systemd init script config. It was set to use en_US.utf-8 but printing locale hints. <apteryx>err, I meant 'systemd guix-daemon service definition'. <apteryx>another thing: entering a pure environment on that VM causes "lesspipe: command not found" to be printed (along other explanation lines). <apteryx>that seems to be Debian's doing when attempting to run a missing command <cbaines>apteryx, to be printed from the guix environment command? <apteryx>I guess guix is attempting a 'lesspipe' invocation somehow, and it doesn't exist, and on Debian this causes a hint to be printed. <apteryx>so if Guix is doing the equivalent of 'lesspipe || fallback' it should rather do somethnig like '(command -v lesspipe && lesspipe) || fallback', in shell pseudo code. <cbaines>how sure are you that it's the guix environment command that's running lesspipe, could it be something in your shell? <cbaines>When I run guix environment --pure I get bash: sed: command not found and bash: direnv: command not found <cbaines>but that's because bash is trying to run those things <apteryx>OK, from that system's .bashrc: [ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)" :-) <cbaines>Ok, I'm not quite sure what that does, but I guess it's not going to do that in a pure environment, unless you include /usr/bin/lesspipe <apteryx>-x just checks if the file exists and is executable, which it does (I'm not using a container) <apteryx>so it executes the later (which is more perplexing indeed :-)). <cbaines>ah yeah, I was thinking about --container, but the issue will be that it's not on your $PATH <cbaines>Replacing the 2nd lesspipe with /usr/bin/lesspipe would probably help here <cbaines>maybe you could try that, and if it works, suggest that change to whoever maintains the bashrc file <maav>apteryx: i think the issue is the expansion order: "$(shell command)" always expand before the current execution as it is part of parameter expansion step, not of execution sequencing <maav>my bad, that isn't true (why did i think it?) <maav>at least bash agrees that false && : $(echo) doesn't emit a thing... <civodul>mbakke: "ungrafting" is at 48% on x86_64 <civodul>it looks like it's not making progress anymore :-/ <mbakke>civodul: bah, I think we need help from mothacehe, seems like something is wrong with cuirass <ride>I sent an email to help-guix@gnu.org and it does not appear on the mailing list. Are certain domains blocked or is there another reason that it would not be accepted? <vagrantc>ride: first mail to the list might need to be moderated <ride>That makes sense. Thank you! <cbaines>Good news though, the initial implementation of build cancelation seems to be working, and the script I've got for building branches now cancels builds for previous revisions of that branch <cbaines>So when you push to core-updates, it'll start building things from that new revision, and cancel builds for the previous revision <cbaines>I could also get it to reduce the priority, but canceling seems fine for now <vagrantc>janneke: nice to hear about wip-arm-bootstrap! <aecepoglu[m]>Under which .scm file should I add a new podcast client? There is a gpodder.scm <rekado>aecepoglu[m]: sounds like a good place to add it. The module can be renamed later. <aecepoglu[m]>Do people prefer shell scripts in guix or has guile become the go-to language? <rekado>aecepoglu[m]: what do you mean with “in guix”? As part of the Guix code base? Or when using Guix System? <rekado>for anything non-trivial that uses Guix I prefer to use the Scheme API. <rekado>but for any odd task I still use Bash <rekado>while there are modules to make shell-like scripting simpler in Scheme, out of the box Guile doesn’t have any special features for quickly composing pipelines. <rekado>“this | that > there” is still easier in a shell script than the equivalent Guile expression. <aecepoglu[m]>true, I remember that being the case but I thought maybe people preferred guile regardless since Guile is more respected in this ecosystem than it is others <rekado>this may be different with Gash, but I haven’t used it for that purpose <civodul>dongcarl: ah yes, i've been meaning to take a look but haven't got around to it yet, thanks for the reminder! <civodul>i'm currently pulling my hair on a Guile-GnuTLS issue <vagrantc>civodul: thanks for pulling your hair :) <civodul>i thought i was done 5mn ago but now i'm back into despair <dongcarl>civodul: :-) Let me know if I can do any reviews/bug-hunting for you in exchange! <vagrantc>civodul: you have a working reproducer for it? <civodul>just enabling debugging logs allows me to reproduce it <ezioauditore[m]>Can i run guux-system-vm-image-1.2.0 qemu image in virtualbox ? I'm stuck at a error... <civodul>i did find an issue, but apparently that's not the root cause <vagrantc>that's better than the opposite ... working when you enable debugging <vagrantc>the labrynthian build in /dev/shm with a symlink to /tmp worked for me to reproduce ... but seemed almost beyond belief <civodul>yeah, it may be chance more than /dev/shm, but who knows <ride> ezioauditore[m]: That is a qemu image. It is possible to convert it but you first must install qemu and use one of their utilities, but at that point you might as well use KVM + qemu :) <ride>What is the difference between `cons` and `cons*` ? <cbaines>ride, cons takes two arguments, cons* can take two or more <madage>or cons creates pairs and cons* creates lists ***sturm is now known as Guest80688
<ride>madage: Is that just another way to phrase it or is there a difference between pairs and lists? <cbaines>some pairs are lists as well, so the distinction is blured <cbaines>'(1 2 3 4) is equivalent to '(1 . (2 . (3 . (4 . ())))) <madage>yeap, lists are constructed from pairs <madage>'(1 . (2 . (3 . (4 . ())))) is a pair whose first element is "1' <cbaines>so when you say cons creates pairs, and cons* creates lists, (list? (cons 1 '(2 3))) => #t and (pair? (cons* 1 2 '(3))) <ride>I'm putting all this stuff in a repl to see what you both are saying <cbaines>I think what I'm getting at here is saying cons creates pairs and cons* creates lists is a little misleading <madage>cbaines: ok, I'll appologise if I'm spreading confusion <madage>but for me it clears the picture <madage>a pair is a list of two elements <ride>It is certainly a bit confusing. How have you two learned scheme? <cbaines>no need to apologise, I'm glad the discussion is helpful <madage>if I remember correctly it should be on this first lesson ***av0idr is now known as avoidr
*civodul wishes lists were disjoint from pairs <Noisytoot>I have installed GNU IceCat from Guix (as Debian does not have IceCat) but all of the text is written in an icon font, how can I change it to use a normal font (like Liberation Sans) <Noisytoot>It could be to do with the fact that all of the fonts in ~/.local/share/fonts are icon fonts <Noisytoot>I tried installing font-liberation but that did not work <civodul>Noisytoot: perhaps you need to run "fc-cache -fv" to force an update of the Fontconfig cache? <Noisytoot>civodul: I tried that but it did not work, it might be because I was using fc-cache from Debian instead of from Guix <ride>madage: Thanks, I did not know there were video lectures to go along with the book. <madage>ride: IMO they are very helpful since they focus on the most important points <madage>but they do not cover everything that is in the book <Noisytoot>The application setup mentions "font-gnu-freefont", which does not exist, although there is a "font-gnu-freefont-ttf" <Noisytoot>s/application setup/Application Setup section of the manual/ <Noisytoot>civodul: In other graphical programs installed with Guix (DrRacket) the fonts work fine, just not in IceCat <pinoaffe>Noisytoot: I've also had a couple of font issues with icecat in guix (and I recall several others coming to this channel with issues), but I don't recall any magic incantation that can be used to fix it <leoprikler>There is no single magic incantation, it actually consists of installing a font with good Unicode coverage (any will do), plus refreshing the cache. <leoprikler>I believe numbers where buggy at some point, but no longer are (hopefully?). ***bkv is now known as bqv
<civodul>Noisytoot: could it be that you need 'font-dejavu'? <dannym>dongcarl: I can only suggest strace and/or gdb to find out what it does. I've debugged my fair share of weird issues, and that's what I usually use. <civodul>hmm did "fc-cache -rv" actually pick fonts from ~/.guix-profile? <civodul>if you ran fc-cache from the host distro, it probably didn't <Noisytoot>civodul: It mentioned them in the output, but it said "skipping, looped directory detected" <Noisytoot>civodul: Initially I ran Debian's fc-cache, but then I switched to Guix's fc-cache, but it still did not work <apfel>on three of my machines, guix system reconfigure failes the same way, trying to build module-import-compiled, the logfile looks like this: https://pastebin.com/4ccyLd6T - any ideas? <atomsk298[m]>Hello. Will using noatime as a mount option break guix in anyway, or is it safe to use? <jonsger>apfel: thats a know issue caused by changes in 6a060ff27ff68384d7c90076baa36c349fff689d. It only happens when you have some channels enabled... <pinoaffe>leoprikler: yeah on several occasions all numbers were replaced by whitespace in my icecat, but that's at least several months ago <apfel>jonsger: ok, thanks for the info <raghavgururajan>Did something happen with Savannah? May be we can move to FSF's Forge when it is ready? <qyliss>It seemed like it was having some load issues yesterday <bandali>raghavgururajan, it was about the request for a new repository for guix translations <bandali>turned out to be kind of a misunderstanding