<sirgazil>It seems bug-guix@gnu.org is having problems. The bug report I sent didn't got through, and I received a "Mail delivery status notification (Delay)": <sirgazil>[Status: Error, Address: <bug-guix@gnu.org>, ResponseCode 421, Host not reachable.] ***Piece_Maker is now known as Acou_Bass
<Apteryx_>what is the recommended way to create a network bridge in Guix, to be used with virtual machine? <CharlieBrown_>Guix recommends setting the X11 font path with xset on foreign distros, but Trisquel does not have xset by default. <CharlieBrown_>Grr... Waiting on Guix to install IceCat so I can use Riot... <aravind>Hi, I installed irssi and use the wee-slack python plugin with arch linux and stuff works fine. The same thing under guix just sits there. I am at a loss as to how to debug this. Regular irc connections work just fine in both of them. <mb[m]1>Apteryx_: I don't know about recommended, but I use the OpenvSwitch service on GuixSD to create arbitrary LAN ports. It can also create TAP interfaces for VMs. <mb[m]1>Note that, if you only have one network interface, there are currently ordering issues at boot. I reboot that particular machine about every two months and haven't bothered fixing it. <mb[m]1>To "plug" an Ethernet adapter into the "switch" (without VLANs), the command is along the lines of `ovs-vsctl add-port br0 enp7s0 vlan_mode=native-untagged` <mb[m]1>And then, to create a regular network interface to have IP addresses etc on: `ovs-vsctl add-port br0 vlan0 vlan_mode=native-untagged -- set interface vlan0 type=internal` <mb[m]1>Where `vlan0` is where you'll have DHCP or static networking for the machine in question (adding IPs on the openvswitch port won't work). <numerobis>Hi! I am a Nix OS and would like to try Guix, for both GNU Guile and software freedom. Since I know that Guix uses Linux Libre, drivers for some of the components of my machine won't be available. This is not a problem, as I'm happy to buy hardware that will work with a fully free operating system, but I was wondering whether there was an easy way to check the compatibility of my current hardware? And, apart <numerobis>from WiFi, what are the other things to watch for? Thanks! <brendyn>numerobis: I think the easiest way is just to test any fully libre distro, since they all use linux-libre. For example, go try running trisquel and see if it words, then GuixSD probably will <brendyn>Otherwise you can check free hardware databases <efraim>there's h-node, which is pretty reliable <numerobis>brendyn,efraim:Thank you for the answers! H-node is very good indeed, but I was wondering whether there was a way around having to manually check the compatibility of each piece of hardware. I'll probably try with Trisquel first :) <rekado>numerobis: In my experience it’s usually just WiFi and non-Intel graphics chips that are problematic. <rekado>trying Trisquel first is a good idea. <rekado>I installed GuixSD on a new Dell server and it just worked. Even the on-board ethernet ports work just fine; it’s great. <rekado>I’m going to add another 8 servers to berlin.guixsd.org in the next few days. <rekado>the new Dell server + the large storage server still need to be configured, so I’m still using the old head node. Once the new server is ready the current head node will be turned into yet another build server. <rekado>then we have 26 build servers, a powerful head node (which could probably also build some stuff), and a couple of TB storage for /gnu/store. <sirgazil>Can I close the bugs I submit to debbugs myself? If so, how? I reported bug 28965, but it is a duplicate of 28956, which is now fixed. <sirgazil>Maybe not, anyone could start messing with bug reports... <ng0>just send an XXXX-done@whateverthe email was to the bug report address <ng0>where XXXX is the id <ng0>cURL 7.56.1 was released yesterday, but we don't need it, nothing grave in the Changelog <rekado>git fails some of its tests on a big server <ng0>it seems random or non-reproducible so far, I've had issues on an T60 Laptop and I was able to "fix" it by just running the build again <rekado>luckily that’s really fast on this machine <rekado>hmm, still fails, trying with “--cores=1” <sirgazil>I think I found another bug. Whenever I start a session as root, guix starts updating lists of substitutes, downloading and buildind stuff. But I haven't run any guix command... <dustyweb>gotta upgrade the wip-certbot branch to latest guix in order to do a server deploy correctly <rekado>sirgazil: are you running any guix command in ~/.bashrc maybe? <rekado>how do you start the root session? <sirgazil>rekado: not that I know of, I just export variables for guix. <lfam>dustyweb: What do you have on wip-certbot? <sirgazil>rekado: There was a "guix package -i guile-git" command mixed with variable exports. Thanks. <dustyweb>which is the branch wingo added certbot/lets encrypt support to <lfam>Well, we should definitely get that merged :) <lfam>dustyweb: Is there a reason besides "not yet confident" that it hasn't been merged? <kevinfish>When I try and install from the manual instructions from a binary tarball onto a ubuntu system (peppermint OS) when I try to do: guix archive --authorize < ~root/.guix-profile/share/guix/hydra.gnu.org.pub I get guile: warning: failed to install locale <kevinfish>warning: failed to install locale: Invalid argument. Help! <lfam>kevinfish: It's just a warning and it's harmless in practice. You can fix it by setting the variable GUIX_LOCPATH correctly in a few environments: 1) Wherever you run Guix from. So, your user's and root's login environments. 2) Where the guix-daemon runs. Presumably to be exported from the systemd service file. <dustyweb>lfam: it was going to be merged but someone said "wait! this is too webroot centric" <dustyweb>but nobody made any progress on it being *less* webroot centric <dustyweb>I think we should merge it and leave open the possibiltiy of adding other methods <lfam>webroot is the best method by far <dustyweb>it prompts you during guix reconfigure, for instance (!!!) <lfam>The others are sort of hacky integrations with the the servers, or require the server to be stopped <dustyweb>I think we shouldn't leave it straggling <lfam>It should be rebased and merged ASAP in my opinion <dustyweb>lfam: could you express support on this bug: <lfam>I guess I should read the old discussion <dustyweb>if you do that I'll get it merged in. It sounded like civodul also wanted it merged. <lfam>I think the comment about webroot being plugin-specific is incorrect, unless I misunderstand <lfam>Well, it means that the service is intended to be used with a running webserver, so that does limit the use case somewhat. However, I think that serving HTTPS is the primary use of TLS in practice, so it's a fine place to start <lfam>Besides, in the long run, there are a million things that can be improved with certbot if you just want a general-purpose ACME client. <ng0>maybe with some hooks into the acme client we can prevent that dialogue or configure what's passed to it in advance <ng0>ACTION just booked their train tickets to 34c3 … anyone else going :)? <dustyweb>rebases after a long bitrot are a real PITA <lfam>Yes, a good reason to merge and push early :) <kevinfish>warning: failed to install locale: Invalid argument <kevinfish>guix package: error: build failed: the group `guixbuild' specified in `build-users-group' does not exist <lfam>kevinfish: It looks like you didn't finish the installation instructions yet. Specifically, step 4, which tells you how to make the build users and their group <kevinfish>lfam: I went down every step even to installing the hello package but several of the steps bombed. What seems to be fixing it is skipping installing the glibc-locales package, setting the GUIX_LOCPATH variable first, then going back to install the glibc-locales package which gave me request to guix pull, etc... first <lfam>kevinfish: What do you mean they "bombed"? <kevinfish>a couple of the steps failed. Unfortunately its scrolled past my xterm scrollback buffer now. I'll have to wait for it to finish the pull, etc... to try and figure out which they were. <rekado>you won’t be able to use the guix-daemon without the guixbuild group <rekado>I’d recommend to set it all up first before running guix pull. <rekado>that’s one of the steps in the instructions. <rekado>I hope you didn’t add your user to that group <kevinfish>I don't see building guixbuild group in the instructions. The only result for searching for that in the page is at the end of step 5 when starting the demon manually (which I didn't do cuz I have systemd) <dustyweb>ACTION nervously crosses fingers and hopes that guix pull works on the server <dustyweb>whew! we really need that memory leak fixing guile-2.2 patch fron civodul! <lfam>kevinfish: Step 4 has a link to Build Environment Setup, which is an important step <rekado>dustyweb: I’m testing these patches in a couple of hours. <kevinfish>ah, I missed that! Got too caught up in copying/pasting into the terminal I guess <dustyweb>I wish I had time to help but I am scrambling <dustyweb>but at least I'm scrambling getting a guile web application deployed with guix right? <lfam>Sorry about that kevinfish. I've wondered how we can highlight that link, since I've seen people skip it before. But those instructions are not specific to installing Guix from the binary, so I think it doesn't make sense to move them into the binary installation section <sirgazil>Question: I ran "guix package --remove hello" and I got this output: https://paste.gnome.org/p0nrjt5rp . Is this normal? I mean updating lists of substitutes and downloading stuff before removing a package? <ng0>sneek: later tell TaoHansen[m]: About pitivi, I've encountered some more dependencies (a new branch of dependencies actually), so I won't be able to finish it as quick as I imagined. <rekado>sirgazil: yes, that’s normal if you have updated guix since the last time your profile was built. <rekado>sirgazil: Guix needs a couple of things to build the next generation of your profile, e.g. to graft packages or to run profile hooks. <lfam>rekado: Do you have an estimate of how long it takes to build all the packages for x86_64 and i686 on berlin? <rekado>sirgazil: it’s certainly counter-intuitive <rekado>it doesn’t help that cuirass is extremely quiet and doesn’t provide stats <lfam>I'm wishing to ungraft glibc sooner than we would have in the past, although in reality we'd have to wait a long time for armhf :( <lfam>Rather than buying more armv7 hardware, I think we should figure out how compile armv7 binaries on more powerful armv8 hardware. I still don't know any reasonably powerful armv7 hardware that we could rely on <rekado>the server for which Ludo shared a link is for armv8. <kevinfish>so now if I erase /var/guix and /gnu I can start over right? <kevinfish>lfam: yeah, it wouldn't make sense to copy the text from section 4, but since its starting the demon part appears to duplicate/conflict with the main page's maybe it would. As much as I like guix, today I'm doing it as a means to an end because it has something packaged that I've been unable to install in peppermint (even from source) so I'm skimming and jamming which made it easy to miss section 4. <kevinfish>lfam: maybe a mention in section for to do everything BUT start the demon from the linked page then come back to the main page for that <ng0>I can't "allocate" any thought power to it atm :) <mb[m]1>lfam: regarding glibc (and other grafts), let's try to get core-updates started ASAP. I'll merge and push an update for 2.26 later. <lfam>ng0: We updated the curl graft yesterday to fix that bug <efraim>Glibc 2.26 also needs the minimum kernel flag bumped to 3.2 I think <lfam>mb[m]1: I'm out of the loop and don't know the status of core-updates. Have we updated all the core and mid-level packages? <ng0>can't read the log all the time. <efraim>I'm not sure how its handled though, it was already higher for armhf <mb[m]1>efraim: I know and have a tested patch for it. <mb[m]1>lfam: there are some updates left still, notably binutils. <lfam>mb[m]1: Okay, I can do that stuff today if people give me a (short) list <efraim>Re building armhf on aarch64, it should work for just about everything other than the thunderX maxhines <mb[m]1>The latest gawk breaks a gettext test, it would be great if you could look into that. <lfam>efraim: What's up with thunderX? They don't support 32-bit? <efraim>Binutils-boot0 built OK, whatever was next didn't compile <efraim>I don't know how they managed it but it cant build armv7 binaries <rekado>oh, these arm servers we’re interested in use ThunderX chips <efraim>Debian has some calxeda server boards that they're retiring, but those don't have neon iirc <lfam>Well, we could always just continue building armv7 on armv7 <mb[m]1>lfam: also FYI, we won't get GCC6 this round because it has a problem with search paths. Don't have the bug URL handy, but it also affects GCC7. <lfam>Considering that you can buy, for a lower price, Cortex A53 hardware that is more powerful than the armv7 hardware we own, we might not see much demand for armv7 substitutes in the future <lfam>Okay mb[m]1, that's fine. It would be nice to have a Guix tracking bug for this issue <efraim>I haven't tried working on the daemon to make aarch64 build armv7 binaries in forever <lfam>efraim: Okay, I think we should not let it delay the 64-bit stuff <efraim>I also wanted to be able to debug the armhf build failures <efraim>Not so powerful, but it seems the debian kernel has support for the odroid-c2 <lfam>It seems like a good baseline, since it came out early and is relatively inexpensive <mb[m]1>I'm currently setting up an armhf chromebook mostly for debugging armhf builds :P <rekado>ACTION still works on saving old patches from bit rot <efraim>I've heard with mainline kernel it can suffer from overheating though, so it would need to be manually downclocked all the way <efraim>But still, with some eMMC for swap and /tmp it should be pretty good <lfam>I think we can't buy hardware with poor thermal design, since we will be running it hard <lfam>It's too bad, that system looks nice, at least for networking and I/O <rekado>efraim: do you think it is bad to buy ThunderX hardware? Or is this only a (potential) concern for building for armhf? <lfam>Is there even a competitor to thunderX at the moment? <efraim>I should find the page where they say what boards they have in profuction <efraim>Debian that is, and other distros <ng0>hm… damn. TESTFAIL: These test cases failed: 1139 ... so I need to fix that testcase in some way, my commit where I removed the removal of it was premature. <ng0>I'll send an update of the gnURL soon, so I'll have either a fix included or a fix in the guix package definition <rekado>efraim: thanks. I guess I’ll just search for distributors then and get some quotes for a thunderX server. <rekado>does anyone else have problems with sending mail to any gnu.org address? <rekado>most of my mails to any gnu.org address (private and mailing list) are delayed. <lfam>rekado: I haven't noticed it lately, but my understanding new senders are moderated. Maybe your email system changed so that you look like a new sender? <bavier>rekado: also be aware that thunderx2 is in the works <rekado>bavier: oh, that’s good to know. <rekado>lfam: that would be weird. I’m now getting delay messages for almost every message I send to gnu; not just for the first message I send to an address. <lfam>rekado: Something's up! My messages are going through right away. <rekado>lfam: hmm, okay. Thanks for the data point :) <CharlieBrown>`guix pull && guix package -u` updates everything, right? <CharlieBrown>I'm trying to install something, and I got a 404, and I saw a recommendation to do `guix pull` and `guix package -u` in the output of an earlier command. <bavier>CharlieBrown: it updates the packages in your profile, yes <bavier>CharlieBrown: what we the 404 from? <lfam>efraim: I saw the binutils update was reverted on core-updates. Can we do the update now? <lfam>noordinaryspider: It will help if you ask a specific question :) <efraim>lfam: it built fine, whatever was after binutils-boot0 didn't build at all <lfam>efraim: Okay, I'll try to fix it <lfam>Long list of emails in my oss-sec mailbox <mb[m]1>Aaaargh, all my three commits on core-updates have errors in the commit message :( <mb[m]1>I only slept four hours tonight, probably should not do much more work today.. <mb[m]1>Also, the glibc kernel version comment should be s/most/all. Oh well. <mb[m]1>The code should be correct, at least. Will continue tomorrow, good night! <mb[m]1>We should also update ICU btw, I can do that tomorrow. Chromium 62 requires 59. <mb[m]1>I have a chromium update btw, but haven't had time to post it -- will commit it in a few days after a cosmetic check. <lfam>mb[m]1: If it's easy, can you send me the chromium update? I'm curious about what sort of changes are required, and I have time today <mb[m]1>lfam: Will do, 62 was actually rather easy (yet it took most of Sunday!). <noordinaryspider>i don't understand how to export GUILE_LOAD_PATH=$HOME/,guix-profile/share/guile/site/2.2:$GUILE_LOAD_PATH <noordinaryspider>Can someone point me in the general direction of where I can find that documentation? <bavier>noordinaryspider: you literally type 'export GUILE_LOAD_PATH=$HOME/,guix-profile/share/guile/site/2.2:$GUILE_LOAD_PATH" into the terminal <ng0>I've seen one patch got applied from the mate series. Is reviewing the rest of it on someones todo list? <rekado>ng0: I’m currently stuck with an old list of patches, or rather a giant patch, that really should have been 50+ patches :-/ <bavier>ergh, this gnulib test-lock hang on my system is really irritating <ng0>oh, okay. I've been rebasing this branch for a while now since I'm using it <rekado>ng0: have you run the commits through “guix lint” yet? <ng0>I thought I have, but it's been to long. I'll do that tomorrow and send an email update if necessary tomorrow night <ng0>*too long ago since I worked on them <rekado>it’s hard to stay on top of all these patches, especially when there are abandoned patches that have started to bit rot. <sirgazil>rekado: fwiw, I've been getting "Mail delivery status notification (delay)" when sending bug reports to gnu.org since yesterday. <rekado>sirgazil: are you per chance also with zoho.com? <ng0>no problem. I'm not completely satisfied with mate yet, I need to learn more about the screen locker problem. the patches work as they are <rekado>sirgazil: maybe it’s a problem on zoho’s end. <ng0>would've been better with a working screen locker, and an (almost) complete mate <ng0>via runbox.com it works <rekado>sirgazil: you also use domain hosting, right? Maybe something with the DNS settings that causes gnu.org to refuse the mail on the first try…? <rekado>oh, okay. Then it’s a problem on their end and there’s nothing we can do about it other than informing them. <sirgazil>rekado: From this message "[Status: Error, Address: <bug-guix@gnu.org>, ResponseCode 421, Host not reachable.] " I would think the problem in on gnu.org... <taohansen>if i run `guix system reconfigure /etc/config.scm --no-bootloader` will it still update the bootloader entries? or does it only update the entry when installing GRUB? <taohansen>i use rEFInd and prefer not to have GRUB re-assert itself as dominant EFI-dog every time i do a reconfigure. <xelxebar>sirgazil: It looks like the gnu.org domain is running exim at eggs.gnu.org. Exim sends 421 back when a client has too many connections open at once. <lfam>Ah, perhaps the SMTP is stuck open