IRC channel logs


back to list of logs

<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
<lfam>Here is the documentation:
<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
<Common_Era>I'm currently being made crazy by Jungle Love.
<lfam>ng0: That was the last update that worked for you?
<lfam>ng0___ ^
<ng0___>that was the last time I ran reconfigure
<lfam>Oh, and that's the reconfigure that is now not working?
<ng0___>no such device /dev/sda4
<ng0___>that's home..
<ng0___>so it fails to pick up luks
<lfam>Do you know when the last good reconfiguration happened?
<ng0___>yes, 4.8.5
<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?
<ng0___>yes and it didn't work
<lfam>Can you SSH in to the machine?
<ng0___>it has to be booted
<lfam>Oh right, you can't even unlock LUKS
<ng0___>even blind typing doesn't work
<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___>with guix, i have no idea
<ng0___>i'm not sure if this is correct.. grub assumes my root is /dev/sda4
<ng0___>i think my root is one higher
<ng0___>i',m not sure
<ng0___>i changed nothing
<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
<lfam>I see
<ng0___>not even console. the "edit" thing
<Common_Era>The kernel parameter editor?
<Common_Era>I know all about that monstrosity.
<lfam>What a good coincidence!
<Common_Era>At least, I got it to boot on my Mac through a LOT of editing that.
<Common_Era>What is the code currently in the editor?
<Common_Era>Can you link to a paste?
<ng0___>i will not write the full store hashes because i type this by hand
<ng0___>a one liner:
<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.
<Common_Era>Do you have an efi computer?
<Common_Era>Alright, what's your GPU?
<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___>yes, but same broken
<ng0___>i have the grub menu
<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
<ng0___>well that's lovely.
<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"
<paroneayea>cups is in core-updates
<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.
<ng0___>i see no --boot=
<Common_Era>It's the last part of the line that starts with "linux".
<ng0___>there's --load=
<ng0___>and the the last line is initrd
<Common_Era>Oh, right, sorry. It's "--load=". It points to a file called boot.
<ng0___>done, no change
<civodul>ng0___: "search --label --set /dev/sda4" looks wrong: it's looking for a file system whose label is "/dev/sda4"
<ng0___>i've not edited it like this
<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
<ng0___>--label 'root' --set 'root' ?
<ng0___>or is --label --set 'root' it?
<ng0___>Common_Era: ^
<Common_Era>"search --label --set 'root'" and also the --root=/dev/sda4 on the linux line.
<ng0___>ok, i'll try it
<Common_Era>Also, can you get into the grub command line? We could figure which partition the root filesystem is on.
<Common_Era>For sure.
<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___>the "root" fix did not work
<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.
<Common_Era>Albeit with weird names (at least for me)
<ng0___>so far it hangs
<Common_Era>On ls?
<Common_Era>That's strange.
<ng0___>there it is
<Common_Era>What does it list?
<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.
<Common_Era>If none do, then that's beyond me.
<ng0___>this will not list the content though..
<Common_Era>Why's that?
<ng0___>just size, filesystem, start
<Common_Era>Hmm... that's different.
<Common_Era>Different than mine was at least.
<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___>i mean do it again
<Common_Era>Sorry, I've just heard bad things.
<ng0___>it can be hard to discuss in that channel, that's all.
<Common_Era>I'll visit it someday and try to play nice.
<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.
<Common_Era>I hope you get it working.
<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___>still, thanks :)
<ng0___> /dev/sda4 , name "root" in parted. but idk if it's formated with the name
<ng0___> /dev/disk/by-partlabel is relevant?
<ng0___>i think there are no labels
<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___>i'll try..
<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___>nope... -.-
<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>Hm :/
<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___>or coreboot
<ng0___>you can have coreboot in qemu, so i think it should be possible to simulate this...
<ng0___>and write a test for it
<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___>to some degree
<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.
<ng0___>thanks everybody for the help
<paroneayea>if I want to inherit a package just to replace one input, is there a "modify-inputs" type procedure?
<paroneayea>ng0___: do you know what it is?
<ng0___>uhm.. one momnet
<ng0___>oh, replace
<paroneayea>nm :)
<paroneayea>it's not that many inputs
<paroneayea>I'll just copy-pasta and adjust the one
<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>but, it's only a few inputs anyway.
<paroneayea>thanks for looking ng0___
<paroneayea>was just wondering if there was something out of the box to use.
<ng0___>i really wonder what broke
<ng0___>and why it's so darn slow
<ng0___>maybe there's something which needs to be added to the system config because otherwise it defaults to whatever I ran into
<ng0___> this seems like the trigger so far, but i'm getting tired and need to be up again in 4 hours
<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...
<paroneayea>oh well, that's it for tonight.
<lfam>The recent curl update changed a dependency from libidn to libidn2. Now our curl doesn't support internationalized domain names
<lfam>You can see the change in this patch:
<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> kadintrooper Hi! again!
<Apteryx>I think if you are using GPT partition you need a special BIOS partition of 1MB or something like that.
<kadintrooper>That makes sense
<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___>marusich: just woke up. no
<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
<marusich>Have you ever seen that occur?
<rekado>marusich: we have flashrom in Guix, no?
<marusich>we do!
<marusich>I'll try that one.
<rekado>ng0___: re labeled partitions: that depends on your config.
<marusich>rekado, it still segfaults :(
<marusich>wait, no
<marusich>I am probably just confused, let me try again.
<marusich>Nope, it still segfaults.
<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>interestingly, the Throw_2 failures in armhf are not unusual.
<rekado>so maybe I’ll just disable them and we’ll have a working gcj on armhf.
<civodul>'lo Guix!
<ng0___>mark_otaris: see mailinglist archives
<ng0___>marusich: ^
<mark_otaris>what is that a reply t—
<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
<ng0___>marusich: a search for /dev/mem should've given you 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
<ng0___>no, 4
<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___>i can't summarize this
<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
<ng0___>one last try with this bug
<marusich>ng0____, does your grub.cfg actually say 'search --label --set /dev/sda4'?
<marusich>I am reading
<ng0____>and changing /dev/sda4 to "root" (label) changed nothing
<ng0____>this is in all previous generations
<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
<ng0____>uhm... i know
<ng0____>i just reinstall.
<marusich>Do you use custom menu entries?
<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
<civodul>not sure what you mean
<ng0____>my config.scm was using /dev/sd* and not labels for ever
<civodul>my advice is to pay attention to the doc of 'title' at
<ng0____>and it has been working for a very long time
<civodul>and to
<ng0____>like i told you, i never used labels when formating and it always worked
<ng0____>the only labels i set are in parted
<civodul>what does "are in parted" mean?
<civodul>well you don't *have* to use labels
<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____>i have
<ng0____>it's not like I changed anything in the system config
<ng0____>it just broke
<civodul>i think Parted allows you to set partition labels, but not file system labels
<civodul>and these are different
<civodul>(confusing, i know)
<ng0____>i know
<ng0____>i just wanted t o clarify
<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____>buit, no ican't
<ng0____>i'll just see wether it breaks again
<civodul>just trying to help :-)
<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
<ng0____>how did this ever init?
<atheia>Is anyone else having trouble installing a substitute for ghc-filemanip- on i686?
<atheia>Getting the "network issues, try with --fallback" error…
<ng0____>ah, title defaults to 'device
<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____>this is a possibilty
<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
<ng0____>ACTION afk
<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>thanks marusich!
<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
<ng0____>just finished the new system
<ng0____>thanks marusich!
<civodul>ng0____: great, thanks for reporting back!
<ng0____>the patch
<ng0____>this is not related to the patch
<ng0____>which i haven't read yet :)
<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 re-did the system
<ng0____>format C ;)
<marusich>That's one way to do it :)
<ng0____>i know it's the same state because i did guix pull before init
<paroneayea>hello, *
<ng0____>some xorg ftp downloads throw 550 error
<ng0____>ah just mirrors
<ng0____>now it hit a working one
<paroneayea>hey, so here's something I'm confused about
<paroneayea>this looks like it should build a separate package, right?
<ng0____>(offtopic a bit) I'm a bit confused about "fair use" copyright.. so leaving country specific laws aside: when someone takes snippets and pieces from other works and the new creation is like a comment or anything listed there, it is considered fair use?
<paroneayea> so why do I get this?
<paroneayea>nothing new is built...
<paroneayea>ng0____: the answer is "probably?"
<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>but unfortunately, that's how it is.
<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
<ng0____>gnutls has a replacement field?
<paroneayea>ng0____: does on master...
<paroneayea> (replacement gnutls-3.5.4)
<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
<ng0____>without grafts?
<paroneayea>iyzsong: ah yeah, good call
<iyzsong>yeah :-)
<paroneayea>it's tricky anyway because gnutls hardcodes a "/share/guile/site/2.2" path
<ng0____>i'll be back later
<paroneayea>(borrowed from #hy: working on my guile + guix stack: )
<paroneayea>iyzsong: (replacement #f) was what I needed :)
<paroneayea>obvious in retrospect!
<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 we are all guilty of that
<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>civodul: the URL can be recomputed, no?
<davexunit>(string-append "" version ".tar.gz")
<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
<civodul>yes, right
<davexunit>since most package upgrades are just a version/hash update
<civodul>there are some cases where it won't work, though
<civodul>but maybe that's fine
<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
<civodul>or maybe even a newer version
<paroneayea>civodul: yeah seems to require guile 3.5.5
<paroneayea>civodul: that might work.. I'll try using package-with-guile-2.2
<paroneayea>er, require gnutls 3.5.5
<paroneayea>if guile 3.5.5 is out already and nobody told me... ;)
<paroneayea>looks like gnutls-with-guile-next works
<paroneayea>I should be able to proceed with https stuff in guile now!
<civodul>sorry again that i'm not more helpful
<paroneayea>no worries, you're helpful civodul :)
<civodul>rekado: great work on Jupyter BTW!
<civodul>i'm supposed to renew my work laptop, but that suggests i'd be getting an AMT-riddled thing :-/
<davexunit>no real way to avoid it unfortuately
<Apteryx>Sorry, what does AMT stands for?
<davexunit>I heard that a coreboot developer may have made some progress towards disabling it, though.
<civodul>aka. "universal backdoor"
<Apteryx>Oh, that. I see.
<Apteryx>You can always convince your employer to buy a Talos desktop at $ 7500 ;)
<davexunit>we don't have a power-8 port of guix ;)
<Apteryx>With this kind of muscle you could virtualize it though, I guess.
<Apteryx>But yeah ;)
<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>I wish I had access to a power-8 ;)
<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>not exactly #guix related, but wow:
<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>yeah, Eben is incredibly engaging.
<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
<davexunit>Eben vs. Kuhn
<bavier>and the research-funding
<davexunit>Eben presents his case very well
<bavier>that has annoyed me to no end
<davexunit>I wasn't aware of that
<davexunit>very scary
<bavier>university funding too, I suppose, is similar
<Apteryx>davexunit: Nice talk!
<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?
<ng0>no idea
<Apteryx>ng0: Looks reasonable! Thanks for the suggestion.
<Apteryx>kyamashita: Git repo?
<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
<civodul>i can only guess
<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.
<kyamashita>It still didn't work. :-/
<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 {} \\;
<Apteryx>something like that
<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>kyamashita: OK!
<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>Apteryx: Only "apt update"
<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?
<Apteryx>*guix pull
<kyamashita>Not until you run "guix package -u <regular expression>"
<kyamashita>In a loose sense: "guix pull" <--> "apt update"
<Apteryx>kyamashita: Ah, I see.
<kyamashita>"guix package -u." <--> "apt upgrade"
<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.
<sneek>Got it.
<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 "."
<kyamashita>Apteryx: So "guix package -u."
<Apteryx>And the way to upgrade the "global" packages would be... "guix pull && guix reconfigure /etc/myconfig.scm", maybe?
<davexunit>Apteryx: as root, yes.
<davexunit>'guix system reconfigure', that is
<kyamashita>^ davexunit is correct
<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 :)
<davexunit>'guix system reconfigure' would fail
<davexunit>only root can do that
<ng0>you should also read bugs.. in case you run into a bug like I did last night
<ng0>well, reading is optional
<ng0>but it helps
<Apteryx>davexunit: OK, that clears it up!
<kyamashita>ng0: BTW, is the bug fixed yet?
<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
<ng0>that's all
<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>OK. Thanks.
<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>it does
<davexunit>someone may have pushed a commit in between the two 'guix pull' runs
<davexunit>which would cause a new guix to be built
<kyamashita>Apteryx: You are GuixSD as a single user, yes?
<kyamashita>*are on
<Apteryx>kyamashita: Yes!
<Apteryx>Unless my wife would like one... But I don't so :P.
<Apteryx>I doubt*
<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.
<davexunit>it will update the grub menu
<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")))'
<davexunit>it should
<kyamashita>davexunit: ?
<davexunit>replying to Apteryx
<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
<davexunit>yes it's very bad
<rekado>paroneayea: have you tried using the skia backend?
<paroneayea>rekado: no, what's skia
<rekado>hasn’t crashed for me since switching.
<rekado>go to about:config
<paroneayea>rekado: how do I switch?
<rekado>find the keys and
<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.
<kyamashita>Apteryx: Yay!
<paroneayea>rekado: huh, thanks!
<paroneayea>ACTION updates
<Apteryx>kyamashita: :)
<paroneayea>rekado: I guess skia comes bundled?
<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
<paroneayea>thanks for the tip rekado
<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: cool, and agreed
<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
<Apteryx>kyamashita: OK. Thanks
<paroneayea>ng0: yeah I'm using it
<paroneayea>thanks to rekado's advice
<paroneayea>it's working well so far, for these first many minutes at least :)
<kyamashita>Apteryx: Just figured it out. Thank you!
<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.
<Apteryx>kyamashita: OK!Same.
<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?
<alezost>fonts are placed in share/fonts
<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
<kyamashita>alezost: Yes.
<Apteryx>If I do fc-list, fonts under share do not show up until I set manually FONTCONFIG_PATH=.guix-profile/etc/fonts
<Apteryx>Would this be a bug?
<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 :-)
<alezost>/s/uses/use ...sigh
<kyamashita>alezost: heeheehee!
<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.
<Apteryx>(in Xterm)
<ng0>Apteryx: we probably need to include those fontconfig configs other distros have
<ng0>there are per-font configs
<kyamashita>efraim: Indeed. Having a look now.
<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"
<Apteryx>*of not finding
<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.
<efraim>thats always fun :/
<kyamashita>efraim: Presumably I can just switch to Debian Sid's copy of w3m and be done "under the guise" of an update.
<kyamashita>For Lynx, we'll have to wait for a patch.
<paroneayea>rekado: maybe i should send your icecat tip to guix-user?
<paroneayea>it seems to have fixed the issue
<paroneayea>haven't had a crash yet
<paroneayea>and was previously having them every 5-10 min
<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>this looks really bad for me:
<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>“o” looks like “c” then
<rekado>hmm, could be the fonts I have installed
<rekado>when rendered with “Nimbus Sans L” it looks terrible.
<rekado>it’s fine with DejaVu Sans
<paroneayea>rekado: I don't think that's happening to me
<paroneayea>I've had that happen before
<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.
<rekado>(though I’m scared of a crash…)
<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?
<rekado>I cannot reproduce this.
<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>0x00007ffff0042ed0 in g_logv ()
<kyamashita> from /gnu/store/l1s4cw9g58hmcpd2qgbckfl228143qzx-glib-2.48.0/lib/
<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
<civodul>damn, w3m's dead?
<sneek>lfam, you have 2 messages.
<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>ISTR there was some discussion of this patch, but it must have happened somewhere besides guix-devel:
<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.
<civodul>yes, maybe we should!
<Apteryx>The X server seemed like it had an issue with grafts.
<civodul>Apteryx: what problem?
<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>That seems to be the most obvious manifestation of this bug:
<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 :)
<kyamashita>Hello, Common_Era!
<Common_Era>Oh, hi. Are you the one who originally tried to help me out with the Mac?
<Common_Era>I think your's was the name.
<kyamashita>Yes. That was fun. :-P
<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
<Common_Era>Yes sir-ee.
<Common_Era>It's rough to do, but once it works, it works.
<paroneayea>Common_Era: wow nice!
<paroneayea>Common_Era: yes, please document!
<Apteryx>Is IceCat now built using GTK3 instead of GTK2?
<kyamashita>Apteryx: Yes. It's a recent development.
<lfam>Here is the thread:
<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
<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: see also
<civodul>Common_Era: discovering is good :-) find bugs, glitches, etc. and see if you can fix them
<civodul>sounds like a good start
<Apteryx>lfam: Thanks for the link.
<lfam>There is this wishlist. I'm not sure how it's updated:
<civodul>probably not quite up to date
<Common_Era>Thanks, everyone. You're a good group.
<lfam>kyamashita: Based on this bug report, I understand that your recent lynx update fixed the bug in question:
<lfam>Version: 2.8.8pre.4、2.8.9dev.8 and earlier
<lfam>But, I'm not sure. The change is not mentioned in the lynx changelog:
<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?