<ng0___>Common_Era: everything is slow and no screen and I haven't fed my laptop any drugs <lfam>Common_Era: Grafting is our workaround for the limitations imposed by the functional packaging model when there are urgent security updates to core packages <Common_Era>Interesting. You two gave me both an example and an explanation. Thanks. <ng0___>my last update was 4.8.5 on 2016-10-29 <lfam>ng0: That was the last update that worked for you? <ng0___>that was the last time I ran reconfigure <lfam>Oh, and that's the reconfigure that is now not working? <lfam>Do you know when the last good reconfiguration happened? <ng0___>that worked until like 30 minutes ago <lfam>Well, I'm not using libreboot or LUKS, but I just reconfigured from e681e347c4ed (gnu: Add perl-getopt-long.) and I can boot my x200s <ng0___>but okay, luks should not give me a blank screen <lfam>I wonder... do you have an external monitor you can try connecting to? <lfam>Can you SSH in to the machine? <lfam>Oh right, you can't even unlock LUKS <lfam>Serial console? (long shot) <ng0___>no idea if that would work or how or if guix even enables this <ng0___>with gentoo i would just boot the install disk, chroot, change what I broke, reboot <ng0___>i'm not sure if this is correct.. grub assumes my root is /dev/sda4 <lfam>My (naive) understanding is that it's usually /dev/sda5 with LUKS <ng0___>1: grub_bios 2: boot 3: swap 4: home or root 5: home or root <ng0___>maybe i boot gentoo to see if I've set any labels <lfam>Looking at the commits between linux-libre 4.8.5 -> 4.8.6, the only thing that seems relevant (besides the kernel upgrade) is 1ef8b72a7f (system: Record store file system info in each generation.) <lfam>But, I'm not sure what to do if you can't even get to GRUB <ng0___>you get it wrong. I can get into grub. but, but, it is only popping up after 2 minutes or so and drop me to grub console after 4 minutes <ng0___>not even console. the "edit" thing <lfam>What a good coincidence! <Common_Era>At least, I got it to boot on my Mac through a LOT of editing that. <ng0___>i will not write the full store hashes because i type this by hand <Common_Era>Sorry, you don't really need to write the hashes <Common_Era>Be warned though, I'm no expert on GuixSD, just getting it to boot. Your problem may have nothing to do with the boot entries. Also, I've never used libreboot. <ng0___>"\\" means linebreak here. setparams 'GNU with Linux-Libre 4.8.6 (beta)' \\ search --label --set /dev/sda4 \\ linux /gnu/store/aaaaaaaaaaaaaaaaaa-linux-libre-4.8.6/bzImage --root=/dev/sda4 --system=/gnu/store/aaaaaaaaaaaaaaaaaa-system --load=/gnu/store/aaaaaaaa-system/boot \\n initrd /gnu/store/aaaaaaa-base-initrd/initrd <ng0___>how do you define the graphics mode? <Common_Era>Well, assuming your root is in fact /dev/sda4, this should be okay. <lfam>Is there a way for ng0___ to select the previous GRUB in order to boot the previous GuixSD generation? <lfam>the previous GRUB entry, I mean <ng0___>right now it's total devastation <lfam>ng0___: The prior generations are broken too? <lfam>Then I think it's likely that the problem is that commit I mentioned earlier <ng0___>i wouldn't know because the screen goes black once I select em <lfam>We'll fix it, don't worry :) <ng0___>Common_Era: again the question, how do i add the graphics mode there? I want to use "vga_text" <Common_Era>Alright, for Intel integrated graphics, try adding "i915.modeset=0" after the end of the --boot= statement, on the same line. <Common_Era>I don't think that'll work, but there's no reason not try it while I research. <Common_Era>It's the last part of the line that starts with "linux". <Common_Era>Oh, right, sorry. It's "--load=". It points to a file called boot. <civodul>ng0___: "search --label --set /dev/sda4" looks wrong: it's looking for a file system whose label is "/dev/sda4" <Common_Era>/dev/sda4 isn't the label... is the file system labeled? <ng0___>probably.. maybe.. if it is, i assume it's "root" or "rootfs" <lfam>Our documentation suggests 'my-root' <ng0___>i don't follow the documentation in labels <Common_Era>You could probably try switching both occurrences of /dev/sda4 with whatever you think it might be. <ng0___>always worked up to this point, and i do not think we limit the words you can label <Common_Era>"search --label --set 'root'" and also the --root=/dev/sda4 on the linux line. <Common_Era>Also, can you get into the grub command line? We could figure which partition the root filesystem is on. <ng0___>i can, once i get the next error <Common_Era>Alright. Tell me if the 'root' fix works and then we'll see about the command line. <ng0___>i never tried it, but it would be great if the install medium of guixsd supported chroot to fix something in a broken system <ng0___>search --label --set 'root' \\ --root='root' it failed again <Common_Era>Alright, get into the grub command line and type ls. That should list the partitions. <ng0___>(memdisk) (proc) (cbfsdisk) (ahci0) (ahci0,gpt5) (ahci0,gpt4) (ahci0,gpt3) (ahci0,gpt2) (ahci0,gpt1) (ahci1) <Common_Era>Try ls each of the (ahci0,gpt(number)) ones. Whichever one has the contents of the / directory should be the one. <ng0___>this will not list the content though.. <Common_Era>Does ls /dev/sda4 do anything or does that just not work at all? <ng0___>i'll know as soon as i'm back to console <ng0___>i don't dare to ask in #libreboot if i should update libreboot because i'll very likely just be told to use a real system or whatever by leah. was there a new libreboot release I missed? or is this entirely on guix side, with the commit lfam mentioned? <Common_Era>Oh, right, I forgot that she's a real annoying jerk, right? <lfam>ng0___: *If* you are able to get into your system, I would like to see if you still have this problem after reverting the commit I mentioned and reconfiguring <lfam>And I agree with ng0, it's not necessary to say rude things about other people in this channel. It never helps, anyways <ng0___>I don't run the system from git.. as the data should be unaffected, i would have no problem to just reconfigure this system <ng0___>it can be hard to discuss in that channel, that's all. <ng0___>Common_Era: no, i can not "ls /dev/sd*" <lfam>ng0___: So, you don't run that system from Git? But, can you try it for the sake of debugging? <lfam>Assuming you can get it to boot... <ng0___>i would change it to git if I could <ng0___>I just set this system up 6 days ago <Common_Era>Alright, your problem is beyond me. Sorry, but I really can't think of anything else. <ng0___>all menuentries are now /dev/sda4 instead of a label... haha <ng0___>something really smashed the grub config <ng0___>i'll boot a live-system and look for the labels <ng0___> /dev/sda4 , name "root" in parted. but idk if it's formated with the name <ng0___> /dev/disk/by-partlabel is relevant? <ng0___>and yes, it worked before as this is how i've set the system up <ng0___>(file-system (cons* (file-system (device "/dev/sda4") (mount-point "/") (type "ext4")) is part of the config <ng0___>coming back to one of my questions, i can not chroot into the system and expect guix reconfigure and everything to work, using the guixsd install medium? <lfam>I don't know, I haven't tried it <lfam>I don't have /dev/disk/by-partlabel <ng0___>i think something like: mount -t proc proc /mnt/proc must work for the chroot to work.. but it's just my experience with gentoo. is guixsd doing something special with /dev/ ? <lfam>I have by-id, by-label, by-partuuid, and by-uuid <ng0___>seems like something no one has t hought of before... <ng0___>hope it'll work, as the only shell we have is /bin/sh <ng0___>"guix package: error: profile '/var/guix/profiles/per-user/root/guix-profile' does not exist <ng0___>maybe it's just because no package is in root profile.. swicthing users <ng0___>woops. there can't be no /home when /home is not mounted <ng0___>i think i could get this chroot to work <ng0___>the "user" is still wrong... but theoretically i should be able to copy one of my git checkouts, select the commit before the file-system commit and reconfigure.. but this would require internet connection afaik which i don't have right now <ng0___>i think it's faster to just redo the system at this point <lfam>I sent a message to guix-devel about this, by the way <ng0___>i'll open a bug about fixing from chroot when i'm done <ng0___>i think this is a feature the install medium needs. <ng0___>the chroot i have now is almost functional <lfam>It would be nice if we also had a way to test things on libreboot systems <ng0___>you can have coreboot in qemu, so i think it should be possible to simulate this... <ng0___>if it doesn't require keeping coreboot/libreboot around for it <lfam>That would be a useful test <ng0___>there is a section in either coreboot or libreboot documentation about qemu <ng0___>the chroot loads the wrong user profile it seems <ng0___>even with "chroot --userspec=ng0:users /mnt /bin/sh" and then "source /etc/profile", guix package -l complains about no guix profile, but "id" shows I'm uid=1000(ng0) <ng0___>okay. I will pause this now, and init the system tomorrow morning again, hoping that this bug gets either clearer or solved, and if it happens again I know i can wait until it is fixed. <paroneayea>if I want to inherit a package just to replace one input, is there a "modify-inputs" type procedure? <paroneayea>and if someone gives something better to do in review, I'll do that. <ng0___>i know how to extend, but not how to change <paroneayea>I guess I could just fold over the list and remove the one that has an (eq? (car item) "foo") <paroneayea>was just wondering if there was something out of the box to use. <ng0___>maybe there's something which needs to be added to the system config because otherwise it defaults to whatever I ran into <paroneayea>I inherited a package and changed its inputs but "guix build" is just giving me the same derivation as the package without its inputs changed... <lfam>The recent curl update changed a dependency from libidn to libidn2. Now our curl doesn't support internationalized domain names <lfam>And also check the build log of curl-7.50.1 where it says "configure: WARNING: Cannot find libraries for IDN support: IDN disabled" <Apteryx>I think if you are using GPT partition you need a special BIOS partition of 1MB or something like that. <Apteryx>For your simple Qemu install you might want to stick to old school DOS partitions and GRUB will install itself to the MBR IIRC. <marusich>ng0___, did you figure out why your system could not boot? <marusich>I think lfam was concerned that commit 1ef8b72a7f87afe7cffe52393d99e1b14e4770e1 may have been responsible, but I have reconfigured my own Libreboot system using that change, and I have no trouble booting, so I don't think it's the cause. <marusich>For details, please check the email I just sent to guix-devel with the subject "Re: [PATCH 01/10] * gnu/system.scm (<boot-parameters>): Add 'store-device' and 'store-fs-mount-point'." <Apteryx>Interesting to note that my rtl8169 wifi chipset is working fine even though it attempts to load a blob ;) <ng0___>i'll work on it once i'm back from the appointment <ng0___>marusich: but your libreboot is old <ng0___>marusich: i recommend you update libreboot to at least the last version released in august and tell me if it's still working. <ng0___>do you assume labeled ext* partitions? because i don't have that either, they are just labeled for parted <ng0___>worked for me until the last reconfigure <rekado>after a few days of compiling I finally built gcj on arm … and it failed its test suite. <rekado>but I’m happy that after applying the patch it’s only four tests that fail, not 37 as on master. <rekado>forgot to add -K to the build so it’s gonna be another 3 days until I can check the test failures… <rekado>(the test suite alone took 14357.9 seconds) <marusich>ng0___, the flashrom utility I obtained from the libreboot release segfaults, which will make it difficult to upgrade <rekado>marusich: we have flashrom in Guix, no? <rekado>ng0___: re labeled partitions: that depends on your config. <marusich>I am probably just confused, let me try again. <rekado>the only test failures that remain in the armhf build of gcj are related to catching NullPointerException; not sure how to fix these. <marusich>I just tried the original, statically linked flashrom which prevoiusly worked on GuixSD, which I used previously when upgrading libreboot, and that one segfaults too. Argh <marusich>The exact error is: "/dev/mem mmap failed: Operation not permitted <marusich>Does anyone here have any idea why this might occur on GuixSD, even when running flashrom as root? <marusich>I ran it like this: "sudo ~/Downloads/libreboot_util/flashrom/x86_64/flashrom -p internal -r ~/x200-backup.rom -VV" <rekado>so maybe I’ll just disable them and we’ll have a working gcj on armhf. <ng0___>mark_otaris: see mailinglist archives <ng0___>regarding the /dev/mem protection <ng0___>also, i did not flash from within guixsd ever, i used external systems <marusich>I'm glad to know I'm not the only one who can't run flashrom... I wonder why I was able to do it previously from within GuixSD. <ng0___>you need to set a kernel option for this <marusich>I was reading some references, but that one slipped me by. Thank you <ng0___>ithink we can create a libreboot test <ng0___>the releases include roms for qemu <marusich>ng0___, I've upgraded to the latest Libreboot release (r20160907), and I can still boot into GuixSD. <ng0___>well i'm not imaging problems... <marusich>I think it's unlikely that 1ef8b72a7f87afe7cffe52393d99e1b14e4770e1 caused your system to become un-bootable. Perhaps something else has changed? <marusich>Can you recall what else might have changed? <ng0___>there are 4 commits which I found to be system or grub related recently <marusich>What is the problem you're having, exactly? I've missed some of the details. <ng0___>read the online log, it's easier <ng0___>1ef8b72a7f87afe7cffe52393d99e1b14e4770e1 49baaff4d2995cc4455843d7249894cb7456d8d5 ffde82c9ecf99524220e463055f4f18c8c9e7a81 those seem relevant to me, but i can't tell which of those broke booting for me <ng0___>setting up the system again now, i hope i won't run into this again <marusich>ng0____, does your grub.cfg actually say 'search --label --set /dev/sda4'? <ng0____>and changing /dev/sda4 to "root" (label) changed nothing <ng0____>not only my current gen is failing, all of them <marusich>GRUB expects the value passed to search --label --set to be a file system label <civodul>ng0____: make sure your root file system actually has the label "root" <civodul>you can run "tune2fs -l /dev/whatever" to check its label <ng0____>i'm not doing this. I'm setting up the system new, i've spent too much time on this already <ng0____>the label is in parted, ext i don't know <civodul>ok but you'll have to pay attention to this as well <ng0____>my config.scm was using /dev/sd* and not labels for ever <ng0____>and it has been working for a very long time <ng0____>like i told you, i never used labels when formating and it always worked <civodul>but then make sure to set 'title' to 'device <ng0____>I do set the labels for partition in parted, as in the application parted, that's all <ng0____>it's not like I changed anything in the system config <civodul>i think Parted allows you to set partition labels, but not file system labels <civodul>the doc above suggests 'mkfs.ext4 -L', that's the kind of labels we want <ng0____>if you feel better about checking, I can curl the config.scm <ng0____>i'll just see wether it breaks again <ng0____>i know.. i appreciate it, but i'm just tired and i only have a few days until i'm away for a while to austria <atheia>Is anyone else having trouble installing a substitute for ghc-filemanip-0.3.6.3 on i686? <atheia>Getting the "network issues, try with --fallback" error… <iyzsong>i think i get it.. eg, using (title 'device) with (device "/dev/sda1") for / would lead to a broken grub.cfg (all entries "--search --label --set /dev/sda1"). <ng0____>I think this is exactly what happened <ng0____>i will know when I'm able to boot (the only 'device is now the /dev/mapper/ one) as I'm initing the system with 'label now <ng0____>so if I'm able to boot, i'll email later about this, this is a bug which should not happen, if it is correct what you say <iyzsong>marusich: it seems that, we should pass #f for the 'device' field of entries when the file-system-title is 'device (`operating-system-grub.cfg` of system.scm). <marusich>Yes, I think you are right; I am working on a patch for that but wanted to repro the problem first <marusich>It seems that we are passing a path when we should be passing a label <marusich>It did not occur for me because I do not use device paths; I use labels <iyzsong>yeah, I use label too. maybe we can use (device (by-label "..")) and (device (by-path ".."))? to get rid of the confusing (title 'device).. <marusich>ng0____, civodul, I've sent you and the guix-devel list a patch to fix the problem ng0____ notice.d <marusich>The subject is "Fix a boot problem reported by ng0" <marusich>I need to get some sleep now. I'll check my email later. Thank you for reporting the issue, ng0____. I hope in the future we can add more automated tests to catch these kinds of issues sooner. <civodul>iyzsong: yes, i'd like to have first-class <device> objects or something like this <ng0____>yep, i can confirm that it boots with / having 'label not 'vevice <civodul>iyzsong: though the problem is that file system labels are really file system labels, not partition/device labels <civodul>ng0____: great, thanks for reporting back! <marusich>ng0____, booting should work fine if you stick to labels; once the patch is applied, it should work like it used to. <marusich>i.e. you could go back to using device paths if you wanted, but labels will give you a slightly faster start-up time since GRUB doesn't have to do a file-based search. <ng0____>i know it's the same state because i did guix pull before init <ng0____>some xorg ftp downloads throw 550 error <paroneayea>this looks like it should build a separate package, right? <paroneayea>because nobody ever knows for sure until each case of fair use is tested in court. <paroneayea>it's case by case. you can get a sense of what's ok <paroneayea>I wonder if it's the replacement field that's breaking "inherits" <ng0____>i'll just put it to test with the first stage of experimentation with sampled/collage'd music i'm doing and releasing for free at some point <paroneayea>so I guess, "does having a replacement field break inheriting from that package"? <ng0____>what if you take gnutls-3.5.4 and inehrit that? <iyzsong>i think inherit does work, so your package be replaced too.. <iyzsong>try add '(replacement #f)' or build with --no-graft? <paroneayea>ng0____: I tried that, still didn't build a new package <paroneayea>it's tricky anyway because gnutls hardcodes a "/share/guile/site/2.2" path <paroneayea>confession: sometimes I just change the version number and run "guix build" to find out the new hash rather than download it myself and run "guix hash" <paroneayea>the error message already has it, so much easier! <davexunit>I think 'guix refresh' should support a mode where you specify a package and a version to upgrade to, and it will automatically update the hash <civodul>davexunit: instead of updating to the latest version? <davexunit>civodul: where the latest version can't be automatically determined <civodul>ok, but it would still need to be able to guess the URL? <civodul>sometimes it's trivial, sometimes not <davexunit>and if we can't re-evaluate that code in the context of a new version number, we can just do a naive string substitution and it should work in most cases <davexunit>since most package upgrades are just a version/hash update <civodul>there are some cases where it won't work, though <davexunit>but I think this is probably the most common upgrade done <davexunit>and I confess that I to update the version and let 'guix build foo' fail to see the new hash <paroneayea>civodul: would a gnutls-with-guile-next package be welcome in guix? I ask because I want to get the https support added to guile, and we need the custom binary i/o ports from guile 2.1/2.2 *and* a gnutls built for 2.1/2.2 support <paroneayea>and is there a better name than gnutls-with-guile-next? :) <civodul>paroneayea: sure! maybe you can use 'package-with-guile-2.2' for that? <civodul>probably only works with the GnuTLS version that's in core-updates <paroneayea>civodul: that might work.. I'll try using package-with-guile-2.2 <paroneayea>if guile 3.5.5 is out already and nobody told me... ;) <paroneayea>I should be able to proceed with https stuff in guile now! <civodul>sorry again that i'm not more helpful <civodul>i'm supposed to renew my work laptop, but that suggests i'd be getting an AMT-riddled thing :-/ <davexunit>I heard that a coreboot developer may have made some progress towards disabling it, though. <Apteryx>You can always convince your employer to buy a Talos desktop at $ 7500 ;) <Apteryx>With this kind of muscle you could virtualize it though, I guess. <civodul>davexunit: but csanchezdll is working on it :-) <civodul>Apteryx: my employer wouldn't be happy with that ;-) <nckx>Is Hydra libre(booting) yet? <csanchezdll>actually my efforts are for powerpc32 (i only have my g4) but should be easy enough to add ppc64 support once ppc32 is in place <ng0>i just installed torsocks-2.0.0, seems like my torsocks-2.2.0 pathc wasn#t reviewed yet? <ng0>seems like my package tree was old. <ng0>explains why I've just build so much from source <davexunit>I think "shots fired" is the right phrase here. <ng0>is there a binary substitute for icecat amd64/x86_64 hardware now? <kyamashita>If I push files with DOS line endings to the Hydra, will the line endings remain the same or will they convert to Unix line endings? <kyamashita>The libjxr patch requires that I either convert the patches line endings to CRLF or I convert the entire source's line endings to LF on my machine. <bavier>davexunit: very nice article, thanks for sharing. I love hearing/reading Eben's stuff <davexunit>what's very interesting now is that he's stepped down as the FSF's pro-bono legal person, and opposes Software Freedom Conservancy and FSF in their GPL compliance cases <bavier>I can appreciate the point he makes about not war-mongering <bavier>university funding too, I suppose, is similar <Apteryx>Any recommendation for easy mounting of external USB media without resorting to GVFS/Gnome <Apteryx>Right now I'm thinking just a /etc/fstab entry which would allow mounting /dev/sdb as a normal user. <Apteryx>Command line solution, but that's OK. <Apteryx>ng0: Does it depends on many things? <Apteryx>ng0: Looks reasonable! Thanks for the suggestion. <Apteryx>kyamashita: On top of my head, the Git remote doesn't manipulate the line endings at all. It's all left to your client to decide what to do, and this depends on how it's configured. <Apteryx>If you are on GNU/Linux I think the default is to not interfere, unless some the project uses a .gitattributes file which can enforce line endings. <kyamashita>Git definitely seems to be interfering, and I see no .gitattributes file in the Guix repo. <Apteryx>kyamashita: Do you mean that you pushed CRLF files and when you clone the repo they come back as LF? <civodul>davexunit: great inspiring (and surprising!) talk <kyamashita>I haven't pushed anything yet. I've output a working patch where the patches had CRLF line endings, and upon removing and re-applying the patch the patches have LF instead. <civodul>davexunit: i'm guessing i'm missing some "substitles" though, as to how that relates to Moglen leaving the FSF <Apteryx>Oh, I think the patch tool always use LF, maybe? <kyamashita>Apteryx: I tried telling diff to ignore line endings' whitespace (all whitespace, as a matter of fact) and telling Guix to use patch's '--binary' flag. <Apteryx>kyamashita: And what is your objective? To keep some files as CRLF? All the files of the repo CRLF? <kyamashita>To keep two files in gnu/packages/patches/ as CRLF. <kyamashita>Otherwise I can attempt to convert all of libjxr's source code to LF line endings using sed... <Apteryx>kyamashita: If you must convert line endings I usually use dos2unix or unix2dos. <Apteryx>find -type f -name '*.c' -exec dos2unix {} \\; <kyamashita>Are those utilities packaged in Guix? It would be simpler if so. <Apteryx>kyamashita: Are you sure the produced patch are CRLF? <Apteryx>Have you tried running "file youpatch.diff" <kyamashita>I know that "sed 's/\\r//'" is equivalent to dos2unix. <kyamashita>"file 0001-gnu-Add-libjxr.patch" always has LF line endings. <Apteryx>So your problem is probably caused by the diff tool which looses the CRLF line endings. <Apteryx>If you were to push your CRLF changes, the git repo would contain CRLF. You can try it with a local repo. <kyamashita>Apteryx: Alright. It looks like my CRLF files wouldn't be the first in the repo. I'll push and see what happens. <Apteryx>How often should I do a "guix pull" ? <Apteryx>Is it the equivalent of doing a "sudo apt update && sudo apt upgrade" on Debian? <kyamashita>It syncs the packages and other new features available to you with the latest git commit. <kyamashita>Hm. Bad phrasing. It basically gives you the latest copy of Guix. <Apteryx>But "guix pulls" update my installed packages, right? <kyamashita>Not until you run "guix package -u <regular expression>" <kyamashita>"guix system reconfigure /etc/config.scm" <--very loosely--> "apt dist-upgrade" <ng0>sneek: later tell lfam: I hope the reply I've sent did not happen to be unencrypted, gnupg is always a struggle for me when it comes to email. <ng0>i think this was phrik/limnoria syntax >.< <ng0>sneek: later tell lfam I hope the reply I've sent did not happen to be unencrypted, gnupg is always a struggle for me when it comes to email. <Apteryx>kyamashita: If I do a "guix package --upgrade", am I updating only my profile packages? <kyamashita>Apteryx: Yes. The default regular expression for all packages is "." <Apteryx>And the way to upgrade the "global" packages would be... "guix pull && guix reconfigure /etc/myconfig.scm", maybe? <Apteryx>so, as root, a "guix pull && guix system reconfigure" updates the globally available packages. <Apteryx>So should I be doing this manipulation often, to get possible CVEs patched? <kyamashita>Apteryx: With some frequency, yes. Perhaps once or twice a week if you're on the internet a lot. Being aware of Guix commits helps. <Apteryx>Wait, even if a package is "global" that doesn't stop me from updating it in my personal profile, right? What would a "guix pull && guix system reconfigure" do as when run with my user otherwise? <Apteryx>I think I need to reread the manual :) <ng0>you should also read bugs.. in case you run into a bug like I did last night <ng0>well, reading is optional <ng0>there's a patch out on it <kyamashita>I see. It's lucky that I saw that message in the mailing list before I reconfigured my system. <kyamashita>Then again, your laptop could just be weird. :-P <ng0>no, i used to use no labels <kyamashita>ng0: Oh. Interesting that it would break like that. <ng0>i also found some other bugs/features, i'll look at the irc log this weekend and write to the bugs list <Apteryx>When we say, to run as "root", is sudo sufficient? <kyamashita>Apteryx: I think so. If it isn't, you won't have the proper permissions to harm your system anyway. <Apteryx>If I was to run "guix pull" two times in a row, would it rebuild itself anyway? <ng0>if you do not run from a git checkout which is linked to one location, yes <ng0>if it was run by two users <kyamashita>Apteryx: ng0 is right. Though if you run it twice in a row, you'll probably get the same Guix both times. <Apteryx>kyamashita: OK. I was hoping my previous "guix pull" as a user built placed all the updated components in /gnu/store, and that my second "sudo guix pull" would just notice about that and be done. <Apteryx>(or rather, just update the links to the updated components of the store) <davexunit>someone may have pushed a commit in between the two 'guix pull' runs <Apteryx>Unless my wife would like one... But I don't so :P. <Apteryx>davexunit: Great! Maybe that's what happened. <kyamashita>You can run "sudo ln -sfv /home/k/.config/guix/latest /root/.config/guix/" to link root's guix checkout to yours so you don't have to run two separate "guix pull" commands all the time. It's deep in the Guix manual somewhere... <kyamashita>BTW, the directory /root/.config/guix/ has to exist first. <Apteryx>Does "sudo guix system reconfigure /etc/config.scm" installs grub? I haven't see any grub related output. <Apteryx>What if I changed partition since I last run it? I updated the partition label in my config.scm. Drive is the same. <Apteryx>Will it re-run grub-install with the new information? <kyamashita>If the drive is the same, you shouldn't have to change '(bootloader (grub-configuration (device "/dev/$DEVICE")))' <Apteryx>kyamashita: Yes. Just the label went from guixSD to my-root <Apteryx>"guixSD" --> "my-root". Partition size went from 10 to 30 GB. <kyamashita>Yes, but grub reinstalls if you simply switch around partitions? I thought it only reinstalled if you used another device altogether. <kyamashita>If one changes the device in '(bootloader (grub-configure (device "<device>")))', then GRUB should reinstall. <Apteryx>kyamashita: I can reboot now and tell you ;) <Apteryx>We'll see. I ran "sudo guix pull", then "sudo guix reconfigure /etc/config.scm", with the only change being the partition label. <Apteryx>If it failed I can always edit manually the grub entries and come back here. <paroneayea>not sure why, but icecat seems to be crashing a lot more since the update <rekado>paroneayea: have you tried using the skia backend? <rekado>hasn’t crashed for me since switching. <rekado>find the keys gfx.canvas.azure.backends and gfx.content.azure.backends <rekado>for both change “cairo” to “skia” <rekado>note that for me this results in less readable fonts <Apteryx>Good news, grub did get re-installed with the correct changed label. <Apteryx>Now I need to figure out why fontconfig is throwing errors. <Apteryx>I still get the "Fontconfig error: Cannot load default config fil". <Apteryx>And the fonts rendering is atrocious, at lesat in Xterm. :D <kyamashita>Apteryx: I haven't quite understood how fonts work on GuixSD. <Apteryx>Well, for one thing, dropping new fonts to your ~/.fonts seems to work as expected. <Apteryx>And I could configure things using ~/.config/fontconfig/fonts.conf, such as antialias & default familities. <Apteryx>But some package I installed is causing problems. I'll try bissecting my generations. <rekado>paroneayea: AFAIU skia is an experimental backend that’s included with firefox. <rekado>better experimental than crashing IMO <paroneayea>rekado: looks like it's a library originally started at teh googs <Apteryx>Do you have FONTCONFIG_PATH set on your system? <Apteryx>I found on the web that this could cause fontconfig to throw the error I'm seeing. <kyamashita>I do not. Though in my case, running "guix gc" or starting from a clean GuixSD installation and installing fonts can cause the fonts not to show up automatically. <Apteryx>After I did export FONTCONFIG_PATH=.guix-profile/etc/fonts", I no longer see the error. <ng0>paroneayea: at least in version 49 of firefox skia is an option <ng0>so i assume below it's also somewhat there <paroneayea>it's working well so far, for these first many minutes at least :) <Apteryx>I think we do not need FONTCONFIG_PATH in normal times. I didn't until something got screwed recently. <Apteryx>If I go back in timea bit, I can find that when I run "fc-cache", it fails because of: access("/var/cache/fontconfig", W_OK) = -1 EACCES (Permission denied <Apteryx>So apparently it'd like to write to /var/cache/fontconfig? <kyamashita>That's the global fontconfig cache. We would need superuser permissions. <Apteryx>It used to work fine before... And if I do "guix package -i fontconfig --no-grafts", I don't see this error either. <Apteryx>I'll reupdate all my profile packages, in case. ***jje is now known as Guest79695
***Guest79695 is now known as jje
<Apteryx>Could anyone using GuixSD tell me if they have a file under /etc/fonts? <kyamashita>I have a "fonts.conf" file and "conf.d" directory with a bunch of configuration files under $HOME/.guix-profile/etc/fonts only when fontconfig is installed. <Petter>I don't even have the /etc/fonts directory. <Apteryx>Reading in the manual, there is a section about fonts. <Apteryx>Petter: I don't either. I was wondering if it was normal. Some applications seems to look there. <Petter>Guess it's normal for GuixSD then :) <kyamashita>No /etc/fonts here, either. Those applications are *wrong*. <Apteryx>So,reading the manual, it seems that Guix should already be looking for fonts under my .guix-profile by default. <Apteryx>This doesn't seem to be the case for me, unless I override the location of config files using FONTCONF_PATH. <Apteryx>That is, "export FONTCONF_PATH=$HOME/.guix-profile/etc/fonts" <alezost>Apteryx: guix does look for fonts in a user profile by default, but it is "~/.guix-profile/share/fonts", while you want ~/.guix-profile/etc/fonts. Why "etc"? <alezost>Apteryx: I mean what packages place files in that etc dir? <kyamashita>alezost: I can see my fonts there, but I can't use them. This isn't a problem on my X200. :-( <Apteryx>alezost: It is true that the fonts go there. But most applications rely on fontconfig to find the fonts, and it seems fontconfig is not configured to find them. <alezost>oh, I see, that's 'fontconfig' itself that have etc dir <Apteryx>If I do fc-list, fonts under share do not show up until I set manually FONTCONFIG_PATH=.guix-profile/etc/fonts <Apteryx>It's interesting to note that this behavior changed recently. At first I tould use the font-hack provided Hack font without resorting to this. <Apteryx>brb, will restart X with FONTCONFIG_PATH variable defined in my ~/.bash_profile <alezost>I don't know, "fc-list" lists all installed fonts without any tweaking; but I didn't update for awhile, so if this is some recent change, I may not be influenced yet <alezost>ACTION doesn't even uses a crashy icecat yet :-) <kyamashita>We have three more Firefox versions until ESR 52. <Apteryx>OK, interestingly, when I update fontconfig with "guix package -i fontconfig --no-grapfts", I no longer need to set FONTCONFIG_PATH explicitly, fonts are found. <efraim>cve requests against w3m and lynx <Apteryx>But... font-hack TTFs are not rendered right, for example using XTerm*faceName: Hack:size=10 in my .Xresources file, I get a really bulky, large font which is hardly readable. <ng0>Apteryx: we probably need to include those fontconfig configs other distros have <ng0>there are per-font configs <Apteryx>Maybe fontconfig upstream changed the way this works? It was working without doing anything special last week (TrueType Hack font in Xterm). <Apteryx>lxappearance (or any GTK app) was still complaining of now finding the fontconfig's default fonts.conf until I "guix package -i lxappearance --no-grafts" <kyamashita>efraim: Our version of lynx seems to be affected. The w3m on SourceForge is apparently unmaintained, and Debian's fork is the only active one. <kyamashita>efraim: Presumably I can just switch to Debian Sid's copy of w3m and be done "under the guise" of an update. <paroneayea>rekado: maybe i should send your icecat tip to guix-user? <rekado>do you also see that some fonts are really badly hinted when skia is enabled? <paroneayea>rekado: I'm not noticing it but that doesn't mean it's not true <rekado>it’s only on some pages with some fonts at some font sizes. <rekado>usually zooming in is sufficient <rekado>zooming in three times makes the fonts readable <rekado>with the default size it looks like letters are chopped off to the right <kyamashita>rekado: Huh. It looks fine on my machine with the skia backend. <rekado>hmm, could be the fonts I have installed <rekado>when rendered with “Nimbus Sans L” it looks terrible. <paroneayea>rekado: I wonder, did you run guix gc recently and get hit by the fontconfig issue? <rekado>this only happened after switching to skia. <rekado>going back to cairo I’m pretty sure it looks normal again. <Apteryx>Anyone got a working XTerm*font for the Terminus font (package: font-terminus). <rekado>paroneayea: fonts look fine in Emacs and everywhere else <kyamashita>rekado: I seem to get crashes everytime I open a dialog box, particularly saving a page/file and opening a local html file. <rekado>kyamashita: with the skia backend? <kyamashita>rekado: Just in general. I guess something's up with my copy of IceCat. <rekado>have you tried switching to skia? Restart icecat after changing the setting. <kyamashita>Every time I press Ctrl-s or Ctrl-o to IceCat, it crashes immediately without fail. <kyamashita>Skia stops much of the crashing caused by websites, but not saving or opening things. <rekado>kyamashita: do you have LD_LIBRARY_PATH set or anything weird like that? <rekado>kyamashita: maybe try running icecat inside gdb to see what causes the crash? <kyamashita>Interestingly, I just got "(icecat:2318): GLib-GIO-ERROR **: No GSettings schemas are installed on the system". <kyamashita>I never start IceCat from the terminal nowadays. <kyamashita> from /gnu/store/l1s4cw9g58hmcpd2qgbckfl228143qzx-glib-2.48.0/lib/libglib-2.0.so.0 <kyamashita>After installing gsettings-desktop-schemas, I get the GLib error: "Settings schema 'org.gtk.Settings.FileChooser' is not installed". <kyamashita>Do I just not have the right packages installed? <lfam>Regarding w3m, search the guix-devel and bug-guix archives for prior discussion. I still think we should switch to Debian's fork <lfam>The SourceForge repo is truly dead <sneek>lfam, ng0 says: I hope the reply I've sent did not happen to be unencrypted, gnupg is always a struggle for me when it comes to email. <sneek>lfam, ng0 says: I hope the reply I've sent did not happen to be unencrypted, gnupg is always a struggle for me when it comes to email. <lfam>I wouldn't say that w3m is dead. But there is no real central repository anymore. The most active repo is hosted by Debian. <lfam>The decision was to apply some critical bug fix patches to the Sourceforge code, but not to use Debian's fork. <lfam>Perhaps we can revisit the decision now :) <Apteryx>Yay! Back to where I was; no more fontconfig issue! It seemed there was some problems with grafts. I had to do as root: "guix pull && guix system --no-grafts reconfigure /etc/config.scm", and as my user: guix package -u --no-grafts <lfam>I contacted each of the people listed as administrators of the SourceForge repo. Some never replied, and the ones that did reply said that they had abandoned the project. I asked them to transfer the repo to the Debian developer who is doing all the work, but they did not reply to that. <Apteryx>The X server seemed like it had an issue with grafts. <lfam>Apteryx: Do you understand that by doing that, you are *not* receiving critical security updates to core components of the system? <lfam>We apply those updates with grafts <Apteryx>lfam: OK. I wasn't aware of that. I thought I'd just suffer from slower updates (rebuilding lots of things instead of patching it). <Apteryx>civodul: I had a strang fontconfig issue, where it wouldn't find the fonts installed. <lfam>By using --no-grafts, you simply don't get the security updates to core packages at all. <Apteryx>lfam: I believe this is the bug in question. Now I remember clearly this crept in after my first "guix gc". <lfam>Yeah. The bug is appropriately classified as "serious", because it leads people to try using --no-grafts. In my opinion, that option is only appropriate for testing things during development. <lfam>You could try basing your system on the core-updates branch, which has fewer grafts. But there are still a couple grafts on that branch. <lfam>That would require you to set up a Guix development workflow, which isn't too onerous, but it is extra work <kyamashita>lfam: How does one switch one's system to use core-updates? <Apteryx>lfam: Wouldn't this re-occur only the next time I run "guix gc" ? <Apteryx>And in the meantime I can install all the (grafted) updates I want? <lfam>Apteryx: It depends on whether or not the package in question is grafted on the branch I'm suggesting <kyamashita>Also, I just submitted a patch switching w3m to use Debian's fork. It's a starting point. <lfam>kyamashita: Basically, `git checkout core-updates && ./pre-inst-env guix system reconfigure ...` <lfam>And also `./pre-inst-env guix package -u .` <kyamashita>And I switch back to master to avoid commiting to core-updates? <lfam>Right, if you are trying to work on master <Apteryx>lfam: OK. Might try to look into that. The bug description is very interesting. <kyamashita>Cool! I know what I'm doing after dinner tonight. :) <Apteryx>*Look into setting up guix with the core-updates branch. <lfam>Apteryx: Yes, interesting and a little disappointing... it means that vulnerable packages may still be in use. And also that grafted packages may break after `guix gc`, as you've experienced <lfam>On core-updates, the following packages are grafted: dbus, guile, and curl. <lfam>I believe so, but I could be missing something. <civodul>lfam: yeah that graft bug is serious :-/ <civodul>lfam: i haven't found out the right GCC hack <lfam>Hmm... setting -fno-strcpy is not sufficient? <lfam>Nor the patch you were exploring? <lfam>ISTR mark_weaver thought it could be possible to enhance the reference scanner to account for the chunked paths <lfam>I'm sorry I haven't been around much these past weeks. Work is very busy right now. I'd like to do more patch review to free you up to work on this sort of thing more <lfam>If you wanted to work on it... no obligation :) <Common_Era>Oh, hi. Are you the one who originally tried to help me out with the Mac? <Common_Era>:P You'll be happy to know that it works perfectly now! <Common_Era>And I'm in the process of writing a little guide. <kyamashita>That's great! Now GuixSD can take over Macs, too! >:D <Apteryx>Is IceCat now built using GTK3 instead of GTK2? <Apteryx>kyamashita: I see! That's nice. And it explains why my GTK2 theme is not applied. I need to work on the GTK3 part. When I'm done and satisfied with the look I'll put a small how-to somewhere. <Common_Era>If I want to contribute to the base distribution, what's the best way to do it, briefly? The manual's Contributing section is vague. <lfam>Common_Era: Briefly, send patches to guix-devel@gnu.org <Common_Era>Alright, that'll be a start. Thank you. I do wonder though: is there a list of wanted features or should I go about discovering some of my own? <civodul>Common_Era: discovering is good :-) find bugs, glitches, etc. and see if you can fix them <lfam>Version: 2.8.8pre.4、2.8.9dev.8 and earlier <lfam>Indeed, our lynx package seems to handle the PoC incorrectly <Apteryx>lfam: Suppose I don't run "guix gc" anytime soon, grafted versions fontconfig would work expectedly? I understand that it's the garbage collecting process which is deficient here, and kills things that it sees as no longer used. <lfam>Apteryx: That should help you avoid the font-config issue. But, references to vulnerable packages will not be replaced correctly. I don't know a way to avoid this for now except rebuild your system after manually "ungrafting" <lfam>An example of an "ungrafting" commit can be found in 34708a221aac12f96d0ba2403bb52658c6355536 <lfam>Basically, remove the replacement package and integrate its changes into the previously replaced package <lfam>If you start doing this, you will probably have to build the entire distribution from source. That's why I suggested using the core-updates branch. Most of the grafts are removed and we substitutes for that branch <Apteryx>Hmm... So if I was to run "guix package -u fontconfig" (it was last installed using the --no-grafts option) it would not get the security grafts applied? 