<jpnc>is there a cache i need to blow out somehow if it is trying to pull from an invalid url?
<mange>I don't think so. It will only cache it based on its hash, so if the hash in the package definition doesn't match any store entries then you'll be fine.
<jpnc>bzip.org appears to just be a parked domain, so pulling anything from that domain won't work
<mange>Actually, I think it caches based on filename and hash, or something. I can't remember the precise details.
<jpnc>any clues what is telling it to try to pull from bzip.org? this is apparently an issue not affecting everyone, i'm not certain how it could be gentoo specific but that's the foreign distro it is living in
<mange>There's a note in the Guix source: "XXX The bzip.org domain was allowed to expire.".
<mange>Which then uses web.archive.org. See the bzip2 package in compression.scm.
<jpnc>i don't find that file under /gnu or /var/guix, am i missing a location?
<jpnc>the only reference i found to the bzip.org url with grep was in /gnu/store/59pqd1d0ihqxx0i64yxk335vjmw78wmh-bzip2-1.0.6.tar.gz.drv
<mange>Oh okay, that's a different way to do it. :)
<jpnc>well i did the guix edit bzip2 and figured that's what you meant heh
<mange>Yeah. Once "guix pull" finishes, the source that "guix edit" opens will be in the store, so will be read-only. I'm used to not being able to directly change things with "guix edit", so I just gave you instructions as if you couldn't.
<jpnc>so the stuff in /usr/share/guile is basically just used for bootstrapping the guix environment from my host os?
<mange>I don't know how the Gentoo package is set up, but I assume so, yeah.
<montxero>rekado: roptat: Yay!, thanks guys it finally worked
<montxero>I removed guix, rebooted, reinstalled, rebooted, guix pulled, spoke to you guys, and it works! yay
<rekado>oh… reinstallation is a rather drastic measure to take.
<montxero>rekado: yeah, I went nuclear... removed the directories, build group and build users, cleaned systemd... nuked that sucker
<montxero>I made a .guixrc for my other systems. How common is this practice? is there a better way of handling the settings that have to do with guix and its environment variables in a foreign distro? here's my .guixrc: pastebin.com/FxjmwBEH
<Sleep_Walker>it seems that my bluez module of pulseaudio can't connect bluetooth daemon
<Sleep_Walker>and I'm not sure what is the idea how this should work...
<grafoo>has someone tried to create a package for bcc from the iovisor project?
<lfam>grafoo: I started a package for bcc ~2 years ago, but never finished it or got it to build properly. I can share it with you if you want, but it's possible that so much has changed upstream that the patch is not relevant. Let me know if you'd like a copy
<lfam>Looking at my old work-in-progress patch, I think it would be a lot easier to start from scratch. That's what I would do if I was going to try again
<grafoo>lfam: ok thx for the info. do you know if at least all of the dependencies are already available in guix?
<lfam>grafoo: Do you have a list of bcc's current dependencies?
<vagrantc>upgrading u-boot to 2018.09 fails building u-boot-tools ... because it's calling "python-coverage" in some of the tests, and the python-coverage package only provides the "coverage" binary ... how did this ever work? nothing's changed in the u-boot side...
<vagrantc>and apparently, the python-coverage package hasn't changed since late 2017
<vagrantc>maybe those tests were skipped in older versions of u-boot...
<vagrantc>guess i could just patch the source on the fly?
<vagrantc>guess ... something along the lines of (substitute* "tools/patman/test_util.py" (("python-coverage") ("coverage")))) ?