<jonsger>honr: maybe its still at /etc/config.scm <honr>No, i just searched "config*.scm" in the whole system <honr>and it appears that there isn't a relevant config(uration).scm :( <jonsger>honr: thats maybe an already fixed bug <mroh>honr: this has been added/fixed a week ago or so, see commit 9d0b9c7c6c from ludo. so you might try to recreate the vm with a recent checkout. <mbakke>janneke, civodul: we now have conflicting versions of 'guix' on core-updates and master. Not sure why the snapshot was updated on master, is the snapshot on core-updates recent enough? <janneke>mbakke: hmm, i updated guix on core-updates two days ago, after the (hurd) cross-build fixes <janneke>mbakke: it looks like some Marius person updated guix on master? <janneke>9b42918edd * gnu: guix: Update to 7dd0539. <janneke>7dd05396ef * doc: Ensure guix-daemon is built before creating guix-daemon.1. <janneke>because there was a (parallel?) build fix <civodul>i updated it on master so that i could update guile-json <civodul>namely commit 5dfe02c60767a633c67f7f6fc9557b54b3c99b63 is needed for the new guile-json <civodul>maybe on core-updates you can re-update after the merge? <civodul>or maybe it's enough to keep the master version since it contains the cross-compilation fixes that janneke needs <str1ngs>janneke: do you recall flashing the SPI at all? <str1ngs>janneke: also when you power on, do you get no lights at all? <vagrantc>i don't get LED lights until the kernel loads <vagrantc>with the mainline 2020.04 u-boot + ~6 patches <vagrantc>flashing SPI would make it a lot easier to brick if it goes badly ... then you're into reflashing the spi chip with an external flasher... <vagrantc>primarily running guix on it lately, though <vagrantc>not sure of linux 5.7 will have great support, but the patchsets are shrinking from 5.5, to 5.6 to 5.7-rc* <vagrantc>probably 5.8 or 5.9 from the look of things might actually be viable <guix-ci>Problem: Free disk space is less than 10% on volume / Problem started at 01:25:52 on 2020.04.29 <guix-ci>Problem: Free disk space is less than 10% on volume /gnu/store Problem started at 01:25:53 on 2020.04.29 <bdju>would be really great if the guix-ci bot just stayed connected ***wxie1 is now known as wxie
<guix-ci>Problem: Too many processes on hydra-guix-126 Problem started at 01:41:05 on 2020.04.29 <guix-ci>Resolved: Too many processes on hydra-guix-126 Problem has been resolved at 01:43:04 on 2020.04.29 <pkill9>i would like a ranger-style browser of packages and their dependencies <guix-ci>Problem: Too many processes on hydra-guix-126 Problem started at 01:55:04 on 2020.04.29 <guix-ci>Resolved: Too many processes on hydra-guix-126 Problem has been resolved at 02:02:04 on 2020.04.29 ***jonsger1 is now known as jonsger
<guix-ci>Resolved: Free disk space is less than 10% on volume / Problem has been resolved at 02:51:52 on 2020.04.29 <guix-ci>Resolved: Free disk space is less than 10% on volume /gnu/store Problem has been resolved at 02:51:53 on 2020.04.29 <ryanprior>Looked at packaging mkcert but it's got a number of dependencies that need packaging too so I stalled out. <raghavgururajan>When I packaged linphone, I had package lot of it's dependencies first. <ryanprior>A lot of go tools I use are that way. Super easy to build, since the go build tool handles fetching dependencies for you from github, and super easy to deploy, since you get a static binary. <ryanprior>But I'm not looking forward to packaging a dozen go deps so I can get mkcert. I think I will do it, because mkcert is a great tool that should be in guix. But I don't know when yet. <ryanprior>I still need to look at the importers. I don't know if there's a go importer, but there might not be, because there's no formal go package system. <ryanprior>A go package dependency is just a git ref X.X <lfam>ryanprior: No Go importer yet :( <lfam>It could be done though. The new thing is "Go modules" which do tell us everything we would need to make an importer work <ryanprior>Does it require opt-in by each package or does it provide a way of formalizing all the existing go package structure? <lfam>ryanprior: For now, it's opt-in, and can be disabled at the compiler level (we still do this when building Go packages). In the future it will be mandatory. I've noticed solid uptake, because it does seem to solve the problem nicely, and it's built-in to the language <lfam>Even though we disable it at build-time, we could still write an importer that would parse each package's 'go.mod' file to get the URLs and versions of dependencies <lfam>Recently someone suggested making the importers output "fix output derivations", so in a sense the entire dependency graph would be considered source code, and one would only need to package the one thing you actually needed to use <lfam>I haven't thought about it deeply but it would make dependency-crazy languages like Rust and Go a lot easier to package <ryanprior>Yeah that would be nice. What do you think about a channel of lightly/automation-reviewed library packages from go/rust/node/python/etc ecosystems? <lfam>In case you wanted to look that thing up, I meant to write "fixed output derivation" <lfam>ryanprior: If people want to do it, go for it! I don't really have time or need for it though <Fare>Hi. Is Guix usable on a laptop these days? <lfam>Honestly, it's not really any different from what's happening now. We just added a package for rav1e, and the hundreds of new dependencies were created by a recursive importer <ryanprior>Well, it doesn't seem remotely scalable to use the current process on the scale that these ecosystems operate at. <lfam>No, especially with Rust. I think we could do it for Go <Fare>(I am currently a somewhat satisfied NixOS user, but also a big Lisp fan) <lfam>Rust dependency graphs are at least twice as big from what I've seen <lfam>Fare: Hi! The main sticking point will be wifi, since almost all laptop wifi chips require drivers that aren't freely licensed, and thus not supported in Guix <ryanprior>Fare: definitely, although depending on your laptop you might need some non-free packages which are not included with guix. <lfam>Fare: It's possible (not too hard) to make one's own kernel package but it's not supported by Guix proper <Fare>Why won't Guix, like Debian, have a non-free co-distribution? <lfam>Fare: It's a GNU project, and the mission of GNU is software freedom. Fundamentally, it's something we'll never do <lfam>But, it's simpler to maintain private packages for Guix than for Debian, and that's a first-class use case for Guix <Fare>how do I tell whether my wifi chip has a free driver or not? <Fare>and if not, is there a HOWTO for making my own kernel / firmware package? <lfam>Fare: You can use `lspci` to find out what it's called, and then look it up online, maybe on h-node.org. But I can probably just tell you, because only a handful do <lfam>Yes, easily found on Google :) <Fare>04:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 88) <lfam>Unfortunately none of Intel's wifi chips have freely-licensed drivers <lfam>Like I said, this will be the main problem for Guix on a laptop. If you can use a USB wifi card, or set up a custom kernel, you'll be able to use wifi on Guix System <Fare>Maybe I'll adopt Guix for my *next* laptop, then. Too much trouble for now. <Fare>(un)happily this laptop has 2.5 more years in it (considering I bought an ultra-extended warranty) <Fare>But I'm reminded to go shopping for a free-software-friendly laptop then. <ryanprior>That's where I'm at. My laptop has non-free wifi and a lot of the software I prefer isn't packaged in Guix yet. <lfam>The main wifi chips with freely-licensed drivers are the ones from Atheros using the ath9k driver. I believe there are also some free drivers for some realtek and broadcom chips, but ath9k is the most popular type <ryanprior>So I'm working on packaging the software, and looking forward to installing Guix on a laptop with more respect for user freedom :) <lfam>Also, with some laptops you can even change the wifi card. But some of them don't allow it in the laptop's firmware :( <Fare>Has any of you used Guix as a Qubes virtual machine? <lfam>I haven't. Would that be like a guest process (not sure of the terminology) in Qubes? <ryanprior>I'm interested in the potential integration between Guix and Qubes, or even a Qubes-like swarm manager built around Guix. <Fare>yes (I don't know the terminology either) <ryanprior>lfam: Qubes runs on top of the xen hypervisor, with each app and each piece of hardware running in its own VM. <ryanprior>There is a concept of TemplateVM, which is aware of Qubes APIs and can be easily templated to host an isolated app or workload that can integrate with the Qubes system. <ryanprior>So one way to integrate Guix into Qubes would be to provide a GuixSD TemplateVM image. <Fare>that's what I was thinking of <ryanprior>Right now the only TemplateVMs are based on Debian and Fedora, unless there's new ones I don't know about <Fare>I haven't actually tried Qubes, but that's those I have heard of, too. <ryanprior>There's one special VM in Qubes which hosts the root API server and can spider into ever other VM, so it's super important for it to be minimal, auditable, locked down. <lfam>Interesting. Guix does have a lot integration with QEMU and Linux containerization but nothing with Xen <Fare>I want to try Qubes for my next laptop, and when I do that would be a good time to try Guix in a VM, if supported. <ryanprior>So another way to integrate Guix into Qubes would be to build a GuixSD system capable of acting as that core VM. <lfam>I would say that making a Guix image minimal would require some focused work. Minimalism is definitely not a goal of the project <Fare>maybe even for this laptop, actually, if supported. <lfam>But, it's quite flexible, and a very good framework for making a custom OS image or distro <pkill9>the atheros card only has free drivers because the source was leaked <Fare>of course, a Guix version of the dom0 would be great, but there's a whole lot of security hardening done in Qubes that I don't suppose can be easily reproduced. <lfam>Really? I've never heard that before <Fare>for intel drivers, I suppose the issue is the firmware, not the kernel-side driver, am I correct? <lfam>The thing most distros provide in the 'linux-firmware' package or similar <Fare>are Intel motherboards supported at all? I'm told they have secret NSA backdoors in their monitoring processor firmware. <lfam>I wasn't around when it went down. I just never got that impression <Fare>protected by assassination and torture, not intellectual property, so I suppose not necessarily antonymous with "free software" strictly speaking, I suppose <lfam>Based on how things have gone since then, it doesn't seem impossible pkill9! There aren't any free drivers for 802.11ac <pkill9>no, I'm completely wrong, they willingly provided open source drivers <lfam>Fare: Yes, they are supported, as part of the x86-64 support. Those issues are pretty much universal with high-performance computers, sadly <Fare>I'm told chinese network chips also can be remotely controlled by the ChiCom. <lfam>It's the architecture that's most fully supported, in practice, since most people use it. It includes Intel and AMD and some very minor companies <lfam>Yeah, who knows. I suppose it will all come out in time <lfam>People do dump and decompile the firmware on these things <Fare>sure, but run on board made of more than open source RISCV or SPARC CPUs. (Are there opensource MIPS?) <lfam>I'm not sure about opensource MIPS but MIPS was a preferred platform for people who care about these issues, but like 15 years ago <lfam>Yes, RISC-V could be great, but we don't have any hardware yet <lfam>Nothing you could replace your laptop with <lfam>I think that translating concepts of software freedom to hardware will be very challenging <Fare>I realize that everyone has to draw a line somewhere. I'm just slightly disappointed that Guix doesn't make it easier for those who draw it the same as me. <lfam>Like, what does it take to make a CPU? What needs to be "free" in that toolchain? <lfam>Yeah, we know it's a major stumbling point for people who are interested in Guix <Fare>with more and more government mind control agencies running supply chain attacks on hardware infrastructure, the future is going to be "interesting". <lfam>I wish it wasn't a problem <raghavgururajan>ryanprior I may be can help you with packaging some dependencies. :-) <lfam>The project is committed to free software, though, and part of that is making it possible for people to change Guix, so there are Guix users running their own kernels <Fare>sooner or later, there will be some 3D-printing / FPGA way to bootstrap your own secure hardware... at which point the NSA will have tiny mosquito-sized bots spying on your screen and keyboard. <lfam>It will be a really long road <Fare>or extended Tempest remote electromagnetic spying. <reepca>to be fair, if they can produce a mosquito-sized bot for every keyboard, they can also produce a mosquito-sized bot for every person, so that would mean pencil and paper aren't safe either... <lfam>Going from "sand to silicon" in a genuine way is like... a civilizational project <Fare>lfam: less long than you or I would like. <Fare>lfam: good rehearsal for bootstrapping a Mars colony. <lfam>I meant the road to trustable hardware with a trustable *hardware* toolchain will be long. I hope it's as short as possible <raghavgururajan>lfam I wanted to ask you something. When you fixed seg fault for xfe, you mentioned some bash-completion directory in the package definition. But that directory does not exist. I would like to know what it does. :-) <ryanprior><raghavgururajan "ryanprior I may be can help you "> raghavgururajan that would be great, how do you want to coordinate? <raghavgururajan>ryanprior Cool! We can either communicate here or through XMPP. My JID is raghavgururajan@disroot.org <Fare>reepca: with enhanced AI-based targetting from networks analysis, they only have to produce a mosquito-sized bot per person of interest. No, pencil and paper won't be safe very long, either. <Fare>we're all on the watch list—just not all at the same height in it. <ryanprior>I haven't used XMPP in ages and don't know how to log in any more. You can message me through IRC or I have Wire and Keybase. <ryanprior>I also have Matrix (which is how I access IRC) <Fare>is there a nice free decentralized messaging platform? What's the closest to it? Tox? <reepca>there's Jami, too. Our package is a bit iffy, but about to be updated to a rather less-iffy state <reepca>going from "crashes when you start a call" to "crashes when you end a call" is quite the improvement <raghavgururajan>ryanprior Ah you are matrix person. I use XMPP for everything (IM, IRC and SMS). <ryanprior>I'm a Jami user too but only have one Jami friend, and we use it when we want to feel the pain of freedom <ryanprior>Matrix is free and federated, which I think for most use cases is better than decentralized. I've been quite happy with it. <vagrantc>been meaning to try jami again ... tried ring some years ago <bdju>matrix is decentralized as well, although many people do just use the flagship server <Fare>is there an up-to-date encryption extension for XMPP? I heard the original ones were vulnerable somehow. <ryanprior>But if, like me, you need to feel pain to appreciate what good software ux is like, then we can be Jami friends <Fare>also, I heard that libpurple was horrible from a security standpoint—what does that leave for secure clients? <bdju>pkill9: XMPP has images. it also has the whole extension thing so it can do all sorts of things depending on the client/server used <ryanprior>XMPP is a fragmented inflexible mess and I left it in despair after being a booster and heavy user for years. <ryanprior>Adopt XMPP if you like being surrounded by things that seemed like a good idea once and in theory can work great but practically have no way to ever improve <vagrantc>i use xmpp with omemo support quite a bit the last couple years <pkill9>I want a modern FOSS clone of msn <raghavgururajan>XMPP is designed to be improved because of it's extensible nature. It has been improved a lot over the years. *raghavgururajan remembers Orkut xD <ryanprior>It is highly extensible, and everybody extends it in different ways, which means what you can actually use resembles the lowest common denominator <bdju>I only recently tried out XMPP and I still use it less than IRC and Matrix, but it seems interesting <ryanprior>Facebook used XMPP for a while and had one of the best implementations of it <pkill9>does anyone even use IM anymore? <pkill9>didn't everyone move to social networking sites for messaging? *vagrantc just started getting into secure scuttlebutt ... <vagrantc>would be a bit difficult to package all the nodejs dependencies for guix, though <bdju>I use group chats on Matrix, I would still call it IM <bdju>or maybe it stops being IM when you have offline messages <pkill9>I thought it was cool, but really it was basically email, lol *raghavgururajan thinks matrix should not have been created in first place, as it has reinvented wheel of XMPP. <vagrantc>well, fun ranting about how to communicate with y'all <bdju>I see a lot of people who like XMPP and hate Matrix on fedi, but I don't really hate either of them. They are both lacking good clients, though. <pkill9>the best things are the new things, the things that proprietary software won't do because it's not 'profitable' and there's no 'market' for it <bdju>XMPP at least is like over 20 years old I think, and a lot of proprietary stuff was built on it <pkill9>maybe FOSS is doomed, maybe it should sell out <pkill9>maybe linus should just give up and sneak NSA backdoors into linux <bdju>you see the selling out with distros like ubuntu, manjaro, etc. <pkill9>and guix should spy on users and sell the data <bdju>systemd probably has an nsa backdoor <peanutbutterandc>*ahem* I have a question: I am on a foreign distro. And I've been using sakura - a terminal emulator - from guix. But when I click on the URLs in sakura, and right-click>'copy' and try to paste it, it doesn't work. But highlighting and copying does. I suppose it has something to do with clipboard not being shared or something. Can anybody please give me some pointers regarding that please? <bdju>did you use sakura and have different results before getting it from guix? <peanutbutterandc>bdju, No, sir. I haven't used sakura from outside of guix yet. But the distro-supplied-terminal-emulator works just fine (the copy-paste issue isn't there) <bdju>I just wonder if the right-click copy button works differently from how you expect <bdju>like maybe copying a url isn't a feature <pkill9>i need a better terminal emulator <bdju>pkill9: which one are you using? *raghavgururajan also uses st <bdju>a couple friends of mine are using st. I tried it briefly but it looked awful out of the box and I didn't want to configure it <bdju>I'm pretty happy with termite <pkill9>but i'm using the wrong one for me <pkill9>i want one that's lightweight with basic features, like scrollback <pkill9>nice, i think i will just apply that then <peanutbutterandc>bdju, Sorry I got lost. So I just checked. I have openshot (from guix) as well. And from there right click > copy location does copy the url/whatever. So it seemed to be to be a sakura-specific thing but then I tried it with tilda (from guix, as well) and the same issue <peanutbutterandc>So... I'm beginning to think it is an issue either with the terminal emulator dependency, or, more-likely, with gtk applications (openshot runs off of qt) <bdju>I can't right click and get a menu with my terminal emulator so I would not have assumed you could copy a link that way, that's all. <peanutbutterandc>Also, emacs has been crashing for me for some time now for some reason.... more on that some other time <bdju>Huh. Okay, I tested sakura on a NixOS machine and copying a link with the right click menu (no highlight) does seem to work. <peanutbutterandc>bdju, `guix show sl` and then copy-paste the homepage info, perhaps? URLs do show up as hyperlink <bdju>I installed it via home-manager, putting it in my home.nix <bdju>no worries, I actually don't have my guix machine turned on right now so I was just testing with what I had <bdju>but basically I installed it as my user, not the system, and I put it in a list of packages to be applied instead of installing it via a specific command <bdju>a bit like a guix manifest <peanutbutterandc>I see... interesting. I should probably try out nix, sometime, too... But I haven't even tried guixSD yet. <bdju>I'm only running it on this machine because it came with a wifi card that would need non-free drivers, I'm hoping to put guix system on it soon actually <peanutbutterandc>I just tried copy-pasting from transmission-gtk and it worked. So, it seems the problem lies with terminal emulators - sakura, tilda and friends <bdju>I've actually never used guix (or nix) on a foreign distro, just their native distros, so I'm not sure how to troubleshoot this <bdju>hopefully someone else has an idea <peanutbutterandc>Okay.... so I just installed sakura on debian (not the elementary os machine) and there are no issues. Hmmm.... interesting.... <guix-vits>peanutbutterandc: if that is debian stable, then issue can be new. <peanutbutterandc>guix-vits, It is debian 10 buster... And the elementary os is 5.1.3 Hera, based on Ubuntu 18.04.x series... <peanutbutterandc>Other 'foreigners' could probably confirm the existance of this bug, perhaps? <peanutbutterandc>Emacs (gtk), for instance, crashes for me with "Fatal error 6: Aborterd" and a Backtrace, with an exit code of 134 (on the elementary os machine) <guix-vits>peanutbutterandc: guix in which you've installed sakura aren't based on 18.04, and that can be a new bug in guix-package sakura. No? <peanutbutterandc>guix-vits, I am not sure... it isn't just sakura, it's also tilda. So it seems to be the terminal emulators (libvte based ones) *Kimapr found `~/.config/guix/current`. Realized that you don't have to intercept `guix edit <random package>` with something like `export EDITOR="echo"` to get guix's guile modules <Kimapr>oh. it doesn't have all the modules <guix-vits>Kimapr: why not /var/guix/profiles/per-user/USERNAME/current-guix/share/guile/site/3.0/gnu/ ? <guix-vits>Kimapr: also /var/guix/profiles/per-user/USERNAME/current-guix/share/guile/site/3.0/guix (for build-systems, services) <Kimapr>but its same as ~/.config/guix/current <Kimapr>is there a clean way to get path to guix-module-union? <Kimapr>setting EDITOR to "echo" and then grepping output of `guix edit hello` doesn't seem a clean way to me <guix-vits>cool, i didn't know about ~/.config/guix/current <Kimapr>also guix-current doesn't have lots of the modules guix-module-union has <guix-vits>Kimapr: grep union `EDITOR=echo guix edit hello|grep union` brings string: <rekado>using EDITOR=echo with “guix edit” is bizarre. <guix-vits>Kimapr: cd ~/.config/guix/current/share/guile/site/3.0; for x in `find -type f`;do grep -l guix-module-union $x;done <dissoc3>im trying to set a static ip in my config but i get "error: service 'networking' provided more than once <dissoc3>is that because I use %desktop-services? <reepca>dissoc3: not sure how you're trying to set up a static ip, but %desktop-services can be found in ~/.config/guix/current/share/guile/site/3.0/gnu/services/desktop.scm on line 1204. The relevant service would appear to be network-manager-service-type. There is also a static-networking-service-type instance in %base-services. <dissoc3>reepca: i was just trying to use static-networking-service-type. is there a more full example of this? it seems like it should be something pretty common <reepca>you can see how the service in %base-services is configured in ~/.config/guix/current/share/guile/site/3.0/gnu/services/base.scm. Methinks that to configure it further you'd want to extend that service with another service <dissoc3>my scheme/guile is pretty bad. i dont see how to access or update the data structure <guix-vits>interestiong, can it be this way: (list (static-networking ...) (static-networking ...))? Anyway... <dissoc3>i cant even get my config file to open with a repl <reepca>dissoc3: I'd recommend reading all of section 8.17 "Defining Services" of the manual if you haven't already <dissoc3>i tried writing a service yesterday. never could get it to work <dissoc3>honestly im just an idiot trying to get a static ip to work <dissoc3>i might just get my dhcp server to assign me the ip i want based on my mac address. <reepca>ah, hm. Well basically, when guix system reconfigure processes your <operating-system>, it uses a procedure called fold-services to figure out how they all work together <reepca>so for example, if you want your nginx server to not run as root, it can extend the user-accounts service or something like that IIRC <dissoc3> it makes sense to fold over the sequence of services <reepca>static-networking-service-type can likewise be extended <dissoc3>so like normally with a lisp i could use a repl and see the %desktop-services data structure and then update it. but i dont see how to get that workflow in the config file <dissoc3>i can run geiser and switch to the module but that's as far as i can go <reepca>you can programmatically manipulate it with procedures like "remove". This is commonly done to, for example, remove the GDM service from %desktop-services and then cons a slim-service or sddm-service onto the result <rbonnal>efraim: thanks for the package, so the trick was to hack the `__init__` file setting manually the version? <reepca>the dead-simple answer would be to do something like that and replace it with your own static-networking-service-type instance <reepca>the proper way would probably be to use the static-networking-service from (gnu services base), which appears to set up the necessary extension <rbonnal>efraim: yes, sorry, the sentence was out of context <dissoc3>i just dont understand why I cant repl in my config file. I cant even edit-symbol-at-point <efraim>it also came up in vdirsyncer on core-updates and I'm guessing on other python packages we haven't caught yet <reepca>regarding the REPL, that's a good question. What happens when you try? <dissoc3>reepca: so im using gieser and emacs. i start gieser. and can switch to module. but I cant compile the current buffer. so i'm unable to really do anything <rbonnal>efraim: and a more general question, do you have API documentations for guix, I mean coming from outside and reading your code I discovered the `inherit` function which is very cool, but I can not distinguish if its a proper Guix function or specific by guix. <dissoc3>reepca: maybe i cant use sudo and tramp for it <reepca>dissoc3: yeah, I just tried it with /sudo::/etc/config.scm, and guile complains about being passed a TRAMP filename <dissoc3>yeah. sorry. im kind of brain dead after messing with this stuff for the past few days. it all seems so freaking cool but im too stupid to get any of it to work <dissoc3>i think trying to write my service did me in <rbonnal>then a more general question, when some package has to check remote connection maybe to verify some API, not consuming the data per se, it that possible when building packages ? <reepca>running M-x geiser-load-current-buffer and M-x geiser-compile-file seem to work for me when config.scm is opened over non-tramp <dissoc3>reepca: I guess that makes sense. thanks for trying and letting me know <reepca>(well, I get a deprecation warning that causes the compile log buffer to pop up, but aside from that) <dissoc3>i dont care about that. i just want to jump to definitions <efraim>I picked up most of it by reading the source and modifying as needed <reepca>it makes some sense that telling local guile to compile remote file wouldn't work, but even when I did M-x run-guile from a tramp buffer (so both of those buffers were remote ones), it still gives the remote guile the tramp name. That at least sounds like a bug in geiser <dissoc3>reepca: i've been spoiled by clojure recently <rbonnal>efraim: got it, it is a matter getting skilled. Make sense <dissoc3>i appreciate the help. i will give it another shot <reepca>to any interested, inherit actually isn't a procedure at all. define-record-type* from (guix records) is a macro which defines a so-called "named fields" constructor, which is also a macro, and that constructor interprets the inherit syntax specially. <rekado>raghav-gururajan: I think 39069 looks fine <rekado>I’ll push it after building a few things <Kimapr>how can i display some information from my guix system config? <NieDzejkob>Kimapr: I don't understand what you want to do... <Kimapr>i want to use (display <something>) in /etc/config.scm <rekado>mbakke, efraim: python-hacking in openstack no longer builds. I’d like to upgrade it to 3.x <mbakke>rekado: the whole openstack.scm chain is broken on core-updates, so that would be very welcome <efraim>openstack.scm hasn't been touched in some time <NieDzejkob>Kimapr: ok, so what prevents you from just doing it? <efraim>I have a bunch of packages related to mailman but nothing related to openstack queued up <efraim>in mixed news i'm building llvm-9 on powerpc for mesa, couldn't get it to build without it, and I have the beginnings of a zram service <rbonnal>when you have packages that are testing remote resources such as web api, are you usually disabling those tests or not ? <raghav-gururajan>rbonnal Yes, have to disable those tests. Networking is not available inside build. <rbonnal>raghav-gururajan: good to know thanks. <mbakke>rekado: the newly donated ARM servers are not accessible from Berlin <rekado>I don’t know of any new serverns <zimoun>Trying to set up aspell, I am confused: "guix environment --container --ad-hoc aspell aspell-dict-en" then "aspell dump dicts" shows nothing. I was expecting the list of en_*. What do I miss? <Kimapr>NieDzejkob: i did it but it doesn't print anything <mbakke>zimoun: I think this was fixed on the 'core-updates' branch <Kimapr>alright, i just did it with guix repl <zimoun>mbakke: thanks! I am not following closely 'core-updates' :-) A good opportunity to test the branch. ;-) <NieDzejkob>Kimapr: If you're still interested in figuring it out, could you paste your config, say on paste.debian.net? <rekado>mbakke: as a workaround you could hop on any of the other build nodes / use them as a tunnel <rekado>the firewall rules only apply to the head node… <mbakke>rekado: can you submit a request to update the firewall rules for berlin? <rekado>I really don’t like to work on Python packages in Guix. <rekado>there’s something odd about them <rekado>the importer doesn’t find all dependencies, and the build system usually fails during the check phase when it suddenly tries to find dependencies that it didn’t complain about during the build <rekado>then there’s this weird behaviour of seemingly building things twice between build and install <rekado>it would be nice if we could do better there <rekado>(somebody should tell ng0 that this is a compressed log file, not a derivation, and not a build directory) <nikita`>same difference i mean, it's not a patch <nikita`>which is what schanzenbach was asking for <Kimapr>i have a RTL8723BE wi-fi card in the laptop, but it doesn't seem to work. it is though listed in h-node. any ideas? <Kimapr>(running Guix System with linux-libre kernel) <rekado>nikita`: ah, new name, gotcha :) <nikita`>okay, I'll edit it. compressed logfile was my second guess <Kimapr>> 0a:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe Wireless Network Adapter <rekado>nikita`: what feedback do you need? <nikita`>specifically my 2 last comments. 1) do you observe similiar behavior than Nix? 2. please open a bugreport for my bugreport application so that I can make it less horrible and hacky <NieDzejkob>Kimapr: the description suggests you need an out-of-tree kernel module <rekado>nikita`: re 2: is this not a bug report? <Kimapr>yeah, but obviously i can't use the script from there <nikita`>it seems more like a "does not work" kind of report on the report tool itself, and I'd like to see more details because I don't have enough computers at hand currently to run guix <rekado>nikita`: the report is that the tests fail and it includes a log; I don’t understand what else you want us to provide <nikita`>oh, okay. gnunet-bugreport is a script. and the reporter wrote that the script itself does not really work well on Guix: <nikita`>> I had to complete it manually because gnunet-bugreport does not really work well on Guix System. <sirmacik>just when I thought it's a good time for an update ;f <nikita`>gnunet-bugreport is one of those things which should really be a python or Go application but had to be lots of sh and awk. <nikita`>and I didn't expect a reply before asking here, so I'm now going to read the log. you are faster than I am used to^^ <nikita`>at least you didn't try to patch it, which is good (there is a related bugreport) <nikita`>i never got around to resolve the localhost/127.0.0.1 one because I had to take a long break <NieDzejkob>Kimapr: Looks like you'll need to create a package for this driver, you can take a look at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40568 for inspiration (when you do, please send it to guix-patches@gnu.org :D). Then, you can add it to your operating-system configuration in the kernel-loadable-modules argument <mbakke>well this is new: "guix pull: error: Git error: error inflating zlib stream" <rekado>mbakke: perhaps you got garbage from Savannah <janneke>hmm, it seems magit can't handle bare clones with worktrees :-( <janneke>for a moment i thought i had the perfect setup <zimoun>mbakke: I confirm that aspell is fixed on core-updates. Thank you! <sirmacik>when can we expect upgrade of guix to guile3? <janneke>sirmacik: you can have it now, when you run core-updates :-) <janneke>so, aspell is indeed broken on version-1.1.0? <janneke>running "./pre-inst-env guix environment --container --ad-hoc aspell aspell-dict-en -- aspell dump dicts", yields nothing <sirmacik>janneke: how? after reconfigure I still gave guile 2.2.6 <nikita`>did I help package icecat? I'm really confused by how much I did before my focused shifted elsewhere <Kimapr>afaik Guix had Audacious for a pretty long time <rekado>jonsger: could you please replace “(zero? (system …)…)” with “(invoke …)”? <rekado>a comment above the null-hash thing would be useful too <ruffni>sirmacik: the package is called guile-next <rekado>and perhaps “remove-bundled-libraries” could become a snippet instead of a build phase <rekado>jonsger: the “fix-profile-setting” phase needs to end on #t <rekado>is the RUNPATH problem really about “lib/icecat-…”? Or icedove? <rekado>in any case, checking the actual error would be good <jonsger>rekado: problem is that rebuilding thunderbird takes more then 1,5h. So I did not disabled/checked all the phases because that is enormous time consuming :( <rekado>jonsger: I can take care of this then <rekado>I’ll try to build on one of the new nodes <jonsger>rekado: what would be the advantage of remove-bundled-libraries be a snippet? the source.tar.xz will become smaller? <rekado>yes, the source tarball served by ci.guix.gnu.org will be the unbundled one. <zimoun>janneke: which branch did you use? to run 'aspell dump dicts', because on master nothing happens for me too but not on core-updates. <janneke>it works on core-updates, but that won't be released for at least half a year? <NieDzejkob>Why are we doing releases, anyway? AFAICS we're mostly using a rolling release model <zimoun>janneke, yes it seems broken for Guix version-1.1.0 which is annoying. <mbakke>NieDzejkob: mainly to provide updated installers and manual <mbakke>I'd like to release a 1.1.1 once core-updates is merged <jonsger>NieDzejkob: and generate some press. good and bad :P <rekado>I think that we’ve been relying a bit too much on core-updates <zimoun>NieDzejkob: mainly to communicate to the rest of the world too :-) For example, "publicity" on lwn ;-) <rekado>it doesn’t get merged often enough and accumulates perhaps too many changes. <nikita`>NieDzejkob: also you need an entry point <nikita`>it's better to cut an release once in a while than to just point out git <bandali>i wonder if it'd make sense to automatically regenerate the manuals and the installer image(s) on a regular basis, rather than at release points <rekado>but I wonder if we can have more specific branches for x86_64 <rekado>bandali: the manuals are generated constantly <bandali>rekado, ah, right; i remember there being a separate version regenerated from master. then perhaps replace that with the "stable" ones <bandali>as a way of making releases less technologically special, if that even makes sense <mbakke>NieDzejkob: you mentioned an interest in GCC 9 a while back, would you like to start the porting work for the next core-updates branch? <zimoun>bandali: releasing means tests; especially the installer. And it is not yet automatic,if I understand correctly. <mbakke>zimoun: we do have some installer tests (as of recently), but it's impossible to test all the hardware combinations out there <bandali>right. i think having a solid test suite could certainly help with ease of mind for auto-generated installer images <mbakke>Florian did amazing work for 1.1.0 and found a bunch of issues that could not have been found through the virtual machine tests. <bandali>but yeah, there will probably always be some level of human testing needed <guix-ci>Problem: Too many processes on hydra-guix-126 Problem started at 13:46:04 on 2020.04.29 <guix-ci>Resolved: Too many processes on hydra-guix-126 Problem has been resolved at 13:50:04 on 2020.04.29 <mbakke>NieDzejkob: just changing the 'gcc' variable to point to gcc-9 and try building "hello" :-) *mbakke tries reproducing Leos login failure when switching from master to core-updates <NieDzejkob>mbakke: Huh, sounds computationally intensive ;) Is there some beefy machine shared by Guix developers I could use? <mbakke>NieDzejkob: you could ask for an account on 'bayfront' by emailing guix-sysadmin@ <sirmacik>rekado: will you find few minutes for that stumpwm stuff from yesterday? <sirmacik>rekado: I've got wm in use-modules, add stumpwm follwing the cookbook and still get /etc/config.scm:48:2: error: stumpwm-checkout: unbound variable <mbakke>why are login-service and the related pam services not listed in 'herd status'? <sirmacik>where should I send fixes for cookbook? :o <guix-ci>Problem: Too many processes on hydra-guix-106 Problem started at 14:24:27 on 2020.04.29 <guix-ci>Resolved: Too many processes on hydra-guix-106 Problem has been resolved at 14:29:27 on 2020.04.29 <thecom>hey, can somebody give me some pointers why guix pull fails with this error? <thecom>In procedure canonicalize-path: No such file or directory: "build/utils.scm" <thecom>guix pull: error: You found a bug: the program '/gnu/store/v08659p87j3ma06dw9p <thecom>50haa4r99492x-compute-guix-derivation' <sirmacik>rekado: I cannot find its source code in the website repo :o <bricewge>mbakke: Because they aren't shepherd-services I guess. <bricewge>Anyone has successfully used guix deploy on Digital Ocean droplets? <bricewge>The blog post seems incomplete and contains typo. <guix-vits>thecom: i'm not an developer, but please tell us more about your machine arch, and Guix installation type (System, on-top-of-foreign-distro). <thecom>i think, i've solved my problem. my guix store is located on nfs and nfs has some troubles :-/ sorry, for the noise <sirmacik>rekado: seems that even with cookbook solution I still cannot load any modules <guix-ci>Problem: Too many processes on hydra-guix-127 Problem started at 15:07:47 on 2020.04.29 <sirmacik>rekado: meaning swank, ttf-fonts load as they should <Kimapr>guix build is writing green words on my terminal <Kimapr>> successfully built /gnu/store/irh204hidic0ln9p1b74aix65ncdal4a-rtlwifi-new-linux-module-8e96c279c6e9a9bda7d5f3b523e71d3303f0a952.drv <guix-ci>Resolved: Too many processes on hydra-guix-127 Problem has been resolved at 15:21:47 on 2020.04.29 <guix-ci>Problem: Too many processes on hydra-guix-127 Problem started at 15:22:47 on 2020.04.29 <guix-ci>Resolved: Too many processes on hydra-guix-127 Problem has been resolved at 15:31:47 on 2020.04.29 <raghavgururajan>While building 'audacious-plugins', during install phase, I get the error "PermissionError: [Errno 13] Permission denied: '/gnu/store/2j2ajvz8v9f1kr12f1ys0ikwp14cjh4b-audacious-4.0.3/lib/audacious'". <rekado>I think I’m just used to monitoring systems thinking that everything is a problem <rekado>raghavgururajan: you need to tell it not to copy the plugins to the output of audacious <rekado>there should be a configure flag to override this <civodul>bricewge: i've never "used" Digital Ocean, but i'm curious: what kind of problems did you encounter? <civodul>we should fix the post and make it a section of the cookbook <mbakke>2GB RAM is apparently not enough to build guix-packages-base.drv on armhf :/ <guix-ci>Problem: Too many processes on hydra-guix-127 Problem started at 15:36:47 on 2020.04.29 <bandali>rekado, it's a bit annoying; especially when there are multiple consecutive ones <bandali>i could always /ignore guix-ci i guess <guix-ci>Problem: Too many processes on hydra-guix-125 Problem started at 15:38:21 on 2020.04.29 <rekado>we should increase the threshold for this process warning <rekado>I don’t think these machines are all that busy <rekado>I’d never act on these warnings anyway <guix-ci>Resolved: Too many processes on hydra-guix-127 Problem has been resolved at 15:41:47 on 2020.04.29 <guix-ci>Resolved: Too many processes on hydra-guix-125 Problem has been resolved at 15:42:21 on 2020.04.29 <NieDzejkob>rekado: AFAICS, the warnings are sent to IRC with a 10 minute delay. Often, the problem gets resolved before the warning even gets here <dlowe>maybe another notification channel would be better <bandali>yeah, perhaps #guix-ops or something ("ops" for operations) <rekado>if someone has a better idea how to monitor the build farm: please implement it <bandali>i wasn't *that* annoyed by it, fwiw :-) <dlowe>I mean, people can also /ignore it <dlowe>it seems useful but not for the vast majority of people who have no capacity to respond <dlowe>so maybe an opt-in would be better <mbakke>rekado: let's just increase the threshold to 1200 instead of 1000 processes <mbakke>not sure why it has so many though, there is only 1 running <civodul>mbakke: it's a build machine so i guess there are peaks, for instance when running ./configure <civodul>and perhaps our offloading settings over-commit <bricewge>civodul There was some field missing, typo and such. <bricewge>I'll send a patch to the cookbook if I manage to use it <mbakke>civodul: i looked at the historical data for the build machines and they linger at around ~800 inactive processes, so we should probably increase the threshold quite a bit <rekado>jonsger: the thunderbird sources include a “browser” sub-directory. Is this needed for building thunderbird? <mbakke>I increased the threshold to a whopping 2000 processes and left a comment on the trigger description. <jonsger>rekado: dont know but thunderbird is also a browser as you can open links with it and show websites *guix-vits "just like emacs" <civodul>mbakke: BTW, did the merge to core-updates go well in the end? <mbakke>civodul: I did not merge the guix update yet, but will take the version from 'master' and let janneke handle the rest :P <mbakke>the merge will cause ~6000 rebuilds due to the R upgrade, so I wanted to set the new armhf machines into service first <mbakke>also waiting for lfam's OpenLDAP graft to avoid resolving that conflict twice <rekado>jonsger: this tarball contains half a distribution <civodul>alextee[m]: pulling means fetching data from a channel, so one can only pull from a channel <alextee[m]>civodul: i mean i have 2 channels, and i only want to pull new stuff from one of them (my personal channel) <civodul>alextee[m]: oh sorry :-) then yes, you just set the commit of the channel you want to pin <ennoausberlin>Hello, I need some help to finish the installation of guix sd on an external bootable usb stick. everything went fine, but the last step failed with "could not prepare Boot variable input/output error <jonsger>rekado: I see. Deleting modules/zlib in a snippet breaks the build :( <mothacehe>ennoausberlin: did you use the 1.1.0 release? <rekado>jonsger: this means it didn’t actually use the zlib from Guix <rekado>this is an intricate fractal of packaging beauty: icedove/third-party/ipc/chromuim/src/third_party/… <jonsger>but libxul.so in the end is linked against gnu/store/...zlib <alextee[m]>we really need a guix pull --up-to-where-there's-substitutes-for-my-packages <alextee[m]>everytime i upgrade my system i have to spend 5 hours fetching stuff and building <rekado>haven’t found three nested third_party dirs yet, but I think if I look long enough in these 2.7G of source code I’m sure I’ll find it. <mothacehe>ennoausberlin: if you are using the "manual" installation, you can try the following command before running guix system init: 'mount -t efivarfs none /sys/firmware/efi/efivars'. <rekado>alextee[m]: this doesn’t sound normal <guix-vits>ennoausberlin: are you sure you want Guix on usb-stick? I've 33 packages installed, and do updates rarely, but my / is 19GB busy. <alextee[m]>rekado: 4g connection and not upgrading often can lead to that <ecbrown>alextee[m]: i had this problem recently, it was because i whacked my /etc/guix/acl <alextee[m]>now it wants to build around 100 rust packages from source for example <ennoausberlin>guix-vits: I have GUIX SD sucessfully installed twice - on external hard drive and vmware <rekado>alextee[m]: I don’t know. It’s not normal to have few substitutes. <ecbrown>alextee[m]: sounds like me weekend. i was messing with offload build and messed up acl file <rekado>we’re building all packages continuously on 25+ servers to avoid this <rekado>so either that’s not working or something else is up *jonsger goes picking up his new hard drive for Guix System :) <alextee[m]>what's the acl file for? never knew it existed ecbrown <guix-vits>ennoausberlin: Aren't usb-sticks die fast if written extensively? <ecbrown>it's the certificate that says to trust ci.guix.gnu.info substitutes <alextee[m]>rekado: even then, since guix is git-based, there will always be commits just pushed that haven't finished building yet, no matter how fast the servers are <ecbrown>anyway, could be a different problem <ennoausberlin>Now I use a new Corsair Survivor 256 GB 3.0 stick, but failed <alextee[m]>so i think a built-in command to check if there are substitutes at that commit would be nice <rekado>alextee[m]: /etc/guix/acl is a list of public keys; substitutes signed with the corresponding private key will be accepted by your Guix. <ecbrown>you should have an /etc/guix/acl, or this is the problem <rekado>alextee[m]: sure, but we try to keep the number of builds on master low. <mothacehe>it may be solved by running the command I sent you earlier <alextee[m]>i do have that file. i actually do get substitutes often, just sometimes it seems i hit packages that haven't finished building on the CIs i guess <ennoausberlin>After failure I booted from install stick again, mounted the destination stick and tried to manually run guix system init /mnt/etc/config but init was talking about wrong number of arguments <alextee[m]>maybe there could be a branch that only gets updated when all the substitutes are there? <mbakke>phew, 'guix pull' uses 1400 MiB of resident memory at 80% of guix-packages-base.drv <guix-vits>ennoausberlin: `guix system init CONFIG PLACE_TO_INSTALL` <alextee[m]>not sure if that's possible though, since i think there's always things that fail to build <guix-vits>ennoausberlin: Manual: `guix system init /mnt/etc/config.scm /mnt` <ennoausberlin>guix-vits: yeah I forgot the /mnt in my post here but I used the full command. Sorry <ennoausberlin>mothacehe: The linked post sounds very familiar. I will read this <civodul>mbakke: it's terrible terrible, keeps me awake at night :-/ <ecbrown>alextee[m]: every once in a while i run the command to build all packages and then serve them with guix publish. (i take a few out) full understanding of what's available :-) <civodul>tip of the day: simple build farm: while true; do guix time-machine -- build emacs; sleep 10m; done <alextee[m]>ecbrown: sounds fun, maybe i can try that on a server <ecbrown>yeah it's super easy. probably stupid, but i have some interest in an off-line cache of a guix snapshot. *janneke has a similar tip: guix gc -D /gnu/store/*-image <mbakke>civodul: I noticed wingo was talking about providing facilities for disabling optimizations in the Guile compiler recently, maybe he will save us :-) <guix-vits>janneke: why it isn't aliased: `guix gc :-D /gnu/store/*-image` <rekado>janneke: I’m running a similar command much too often on ci.guix.gnu.org :/ <mbakke>alextee: such a branch has been discussed in the past and we probably should implement something like it eventually <mbakke>it also guards against people accidentally causing thousands of rebuilds on 'master', which happens a couple of times per year <wingo>mbakke: i think i have something that can fix it, maybe 2-3 days work remaining <mbakke>wingo: woooow, that would be terrific :-) <civodul>yup, thanks for your proposal, wingo! <wingo>would be nice if it allowed us to avoid relying on prebuilt .go files <wingo>maybe that is unrealistic, dunno <hulten>How would I go about installing a font, to make available in LibreOffice? <mbakke>hulten: I assume you've tried 'guix install the-font' ? <mbakke>we should team up with NixOS and do something about the fontconfig situation <hulten>Yes, well, I searched for the font 'carlito', but this isn't available as a Guix package. <hulten>But maybe it is in a 'font family'; I don't know how fonts are organised. <mbakke>which suggests that 'font-liberation' should be metric-compatible, whatever that means <mbakke>hulten: also, 'font-google[noto' apparently contains it <mbakke>hulten: it would be good to update the description of that package to mention some of the fonts it contains so it shows up in 'guix search' <guix-vits>is that true that -noto font weight is around 150 Mb? <hulten>font-google-noto-20171025 736.0MiB <mbakke>guix-vits: I thought it was even bigger. <hulten>I actually searched for Calibri, but that's proprietary; and then I found that «Carlito [...] is metric-compatible to Calibri». <hulten>I *suppose* this metric-compatability is associative, so Liberation would be metric-compatible to Calibri as well. <mbakke>hulten: feel free to submit a patch that updates the descriptions to mention that <nikita`>noto could be build from source, but it's an annoying process <jvshahid>Hi everyone. I am trying to use augment-rpath from the (guix build rpath) module inside the copy-build-system phase. When I try to build the package I get the error `Unbound variable: augment-rpath'. I think I need to import the module inside the build-code, but I am not sure how. <NieDzejkob>jvshahid: You'll need to add it to the #:modules argument, and also potentially #:imported-modules <NieDzejkob>(the former is what's in scope, the latter is what's in the build container) <civodul>uh i have 20KiB/s to berlin right now <rekado>jonsger: the good news is: building icedove only takes ~18mins on hydra-guix-129 <jonsger>wasn't there recently a fix about partitions over 1TiB? <rekado>you won’t get a result for ci.guix.gnu.org because the firewall filters pings, but it should show you if there’s any loss on the way to that server <civodul>"mtr ci.guix.gnu.org" says i'm losing 10-25% in .de hops <civodul>not entirely sure how to interpret that <rekado>on this channel I saw other people with a connection from France report similar numbers <jonsger>the installer (1.1.0) just returns to the beginning after the partition step (before the actual partition). Is this because the hard disk is 2TiB? <civodul>jonsger: probably, it's because it crashes without displaying the error message <civodul>jonsger: could you check /var/log/messages? ***swedneck is now known as Guest97271
<civodul>rekado: yeah bricewge reported it earlier, but until now i was fine, so i thought they must have broken wires or something, and now i'm just as unhappy as 'em! ;-) <rekado>I’m going over cr-han2-be6.x-win.dfn.de which has 0% loss <rekado>don’t know if there’s anything we can do here <rekado>but the good news is that it’s not a problem with ci.guix.gnu.org itself :-/ <bricewge>civodul: For the moment we are 4 Free ISP client with this issue and 1 from Mexico <civodul>from a VPN i have 80% loss at prs-bb4-link.telia.net <bricewge>civodul: Try with i.imgur.com or www.ccancients.net <bricewge>civodul: Good new is you can bypass the issue with your new set-http-proxy ;) <jonsger>civodul: we dont have a paste service in our installer? <rekado>jonsger: hmm, not pre-installed. But if you have internet access you can do “guix install wgetpaste” <g_bor[m]>I just wanted to tell that we are all set up for GSoC and Outreachy. Interns are announced on monday. <rekado>g_bor[m]: thanks for taking care of this! <cbaines>I know Outreachy is Monday, but are GSoC interns announced on Monday too? <jonsger>another error while manually installing with grub-efi <civodul>jonsger: something's wrong with your DVD no? <civodul>jonsger: ah ok, there are messages about sr0, that's why i was wondering <civodul>but yeah, the crash could be due to the nvme/>1TiB issue <civodul>it'd be great if you could build an image from master <jonsger>civodul: we dont build installer images on ci? <civodul>we do but they're not easily accessible and there are no substitutes <civodul>so you'll have to build at least the last step locally <civodul>arf, not accessible over Tor this time <jonsger>guix system: error: '/gnu/store/xlcbi7dc89n4wvyz4jk6j0g4590ymi6q-grub-efi-2.04/sbin/grub-install --boot-directory /mnt/boot --bootloader-id=Guix --efi-directory /mnt/boot/efi' exited with status 1; output follows: <jonsger> /gnu/store/xlcbi7dc89n4wvyz4jk6j0g4590ymi6q-grub-efi-2.04/sbin/grub-install: error: /gnu/store/xlcbi7dc89n4wvyz4jk6j0g4590ymi6q-grub-efi-2.04/lib/grub/i386-pc/modinfo.sh doesn't exist. Please specify --target or --directory. <guix-vits>jonsger: is that (bootloader grub-efi-bootloader) in config? <mbakke>jonsger: that error means that GRUB failed to detect a UEFI system, you should use 'grub-bootloader' instead <guix-vits>jonsger: today someone told someone check "If efivarfs is not automatically mounted at /sys/firmware/efi/efivars" <guix-vits>bricewge: strange thing this bug is: i've both vars and efivars, other don't. Good that there is a patch. <raingloom>i think there's a bug in our CUPS package. i can't get a 9-pin Epson printer working, but it works flawlessly when i pass /dev/parport0 to a Lubuntu VM. <raingloom>(not the same setup procedure, but i'm pretty sure i used the same drivers) <grubles>hello. guix noob here. ghostscript-9.27.drv building keeps failing for me. <rekado>grubles: are you building these on purpose? <grubles>after a fresh install using the install script <lfam>grubles: When the command fails, it should print a message saying what the log file is called <lfam>It will be something that ends in '.drv.bz2' <grubles>applying '/gnu/store/szgilk2xjls9ihwmydc23wyca534vdq6-gcc-strmov-store-file-names.patch'... <grubles>applying '/gnu/store/5705r4ajxl8lav1hz9xm19w75zdcz1n2-gcc-5.0-libvtv-runpath.patch'... <lfam>grubles: What is the log file called? <grubles>oh wait sorry that's the wrong log... <lfam>If it's too hard to use the Debian paste site for some reason, you can use pastebin.com <lfam>The excerpt you showed before did not include any errors <lfam>Can you try to find the section with the errors? <lfam>Also, I'm curious, what kind of computer are you using? <grubles>odd, it's too large for pastebin too <rekado>jonsger: I fixed the runpath validation in icedove. <rekado>jonsger: I wonder: is it a problem that the executable is still named “thunderbird”? <jonsger>personal I favour thunderbird because that is widely known <grubles>the machine is a xen VM (i'm running it in a qubes appVM) <lfam>grubles: You still haven't shown the error message, which will be in a log file announced when the command fails <lfam>"View build log at '/var/log/guix/drvs/hf/b2rv1y6brg4bn02c9d6djqc3mxxq62-gcc-mesboot1-4.7.4.drv.bz2'." <lfam>You will find it in that file <lfam>You could also share the entire file with us <grubles>neither paste service would accept the paste or the file because it's too large >_> <grubles>i couldn't find anything obvious in the .drv <lfam>You could use wetransfer grubles <NieDzejkob>grubles: how long does it take? maybe there's a timeout? <lfam>grubles: Can you share it with wetransfer.com? <lfam>Upload it there and share the link here <grubles>oh didn't realize you could choose a download link <bandali>doesn't it require running nonfree js? <lfam>grubles: What log file is that? Is it more than one log file? <lfam>I don't know bandali. I don't really pay attention to non-software issues <lfam>I mean, I don't pay attention to issues about remote services <qyliss>It's not remote if it's running on your computer <lfam>I've heard the arguments, I know how they go <lfam>You don't have to click the link <grubles>no it's just the b2rv1y6brg4bn02c9d6djqc3mxxq62-gcc-mesboot1-4.7.4.drv <lfam>grubles: I'm not sure, I don't see an error. I wonder if maybe something about the Qubes setup is tripping it up, but really have no idea <lfam>If nobody else chimes in, you should send a message to <help-guix@gnu.org> <jonsger>can channels also be added to config.scm or only to channels.scm? <PotentialUser-25>Hi guys, I tired to use guix env. to compile coreboot whit this: "https://paste.debian.net/1143822/" but launching the ./config the prompt sad this: configure: error: "qemu, coreboot and loongson ports need unifont" . Unifont was already on my manifest <lfam>PotentialUser-25: Unifont has multiple "outputs" for different kinds of fonts. Make sure you pick the right output <lfam>PotentialUser-25: You probably need the PSF fonts <lfam>Does anyone know how to specify package outputs in manifests? <lfam>PotentialUser-25: Yes, it's part of the unifont package. The Unifont package has a variety of outputs (seen with `guix show font-gnu-unifont`) <lfam>"The "lib" output of package-3." <lfam>grubles: Sorry I don't have an answer :/ <lfam>Next time, I'll think to suggest the use of the 'magic-wormhole' program instead wetransfer.com, bandali and qyliss. I forgot about it and didn't want to introduce a lot of friction for grubles <lfam>It's a great program that addresses this exact problem of ad-hoc p2p file transfer <grubles>my guess is it's a weird issue with qubes' memory balancing but i don't know <qyliss>I wasn't trying to suggest you do or don't do anything :) <lfam>I appreciate the push-back on wetransfer.com, even though I don't think it's exactly against the rules <bandali>lfam, cheers. anything that doesn't require nonfree software is a potentially good candidate :-) <dissoc3>anyone know what package provides dig? <lfam>grubles: Yeah, I was thinking that it might run out of memory, but I'm not familiar with the details of qubes <lfam>dissoc3: It's in the 'utils' output of bind. So you could do `guix install bind:utils` <dissoc3>lfam: ooh right... i had it installed on my laptop and couldnt remember how i got it. thanks <lfam>Package outputs are valuable but the UI is still a bit obscure <grubles>i'll try with memory balancing for this VM disabled <dissoc3>I was using the guix emacs package which made it more obvious <rekado>bah, this openstack stuff is annoying. They have very strict version requirements and usually they are years behind the latest release. <janneke>since a week or two, offload builds of "guix" hang/fail after the check phase <mbakke>rekado: if it's any consolation, openstack-the-distribution is even more of a mess ... <mbakke>errrh, I get "guix offload: error: corrupt input while restoring archive from #<input: string 7fd4503d1070>" from one of the newly deployed ARM build machines