<nothingmuch>i'm trying to inherit from zlib in order to use guix to build dependencies for an (as of yet) non guix build, substitute-keyword-arguments seems to work in that #:phases is modified, but #:make-flags seems to be ignored
<nothingmuch>i'm not sure how to proceed to verify that i actually constructed the package correctly, i managed to load it in the repl but failed to understand the help for inspect/display
<nothingmuch>if i use guix build -K, running make with the flags i intend works as i expect it too, and i don't see that the standard zlib package overrides anything apart from the configure phase
<rvgn>I have few doubts regarding UEFI. 1) I have read about issues like restricted boot etc. But are the issues related to UEFI specifications itself or related to firmwares that implement them? 2) Are UEFI specifications free software friendly? 3) Is UEFI Forum trying to make UEFI development open and transparent?
<rvgn>I would like to know whether it provides better freedom, modularity, extensibility and security.
<vagrantc>rvgn: there's tianocore, which appears to be a free software implementation at first glance
<vagrantc>some implementations may require signed binaries, but at long as they let you define valid signers, that shouldn't be a problem (some definitely will come with a baked in, unchangeable set of signers)
<vagrantc>the security implications are you essentially have a relatively wide attack vector running the EFI stack that can touch ... lots of things in the running OS
<vagrantc>so on the one hand it can be implemented in a way that improves security, it introduces a lot of room for bugs.
<rvgn>the valied signers are determined by the firmware right?
<arbi>I'm having trouble putting together a Rust development environment in guix... are there any good guides?
<arbi>It doesn't look like there are many rust packages available, so if I want to include "rust-rand" to follow along with the Rust book tutorial, I'm getting stuck importing crate dependencies
***vagrantc_ is now known as vagrantc
***MinceR_ is now known as MinceR
<usney>I tried installing guix and it fails at wifi
<usney>both my wifi internal and wifi doggie can use free software
<usney>I tried doing it twice with each one and still had the same issue
<pkill9>does anyone have jack working in realtime mode on Guix System?
<pkill9>sweet, i can disable realtime mode and it doesn't stutter anyway
<Gamayun>usney: How exactly does the wifi fail? Any error messages? If you are using the installer, you could try the instructions for setting up the network for manual install, see if you can connect that way.
<nly>can i use a 32bit package explicitly in (package ...) definitions? i have a 64bit guix system
<roptat>oh, that's probably because I put stuff in my .bashrc, $PATH is clearly not set correctly
<roptat>it worked in a pure environment, but otherwise, it doesn't set $PATH at all it seems (or it's overridden by something)
***spk121_ is now known as spk121
<pinoaffe>hi! I'm having some issues running adb and fastboot as a user on guixsd, how do I grant permissions to access usb devices to a user? (the equivalent of adding a user to the plugdev group on some other linux distros)
<roptat>pinoaffe, I think we have a adb-udev-rules package that you can use with the udev service
<roptat>pinoaffe, I have this in my services: (modify-services %desktop-services (udev-service-type config => (udev-configuration (inherit config) (rules (cons* android-udev-rules (udev-configuration-rules config)))))
<nckx>minall: Hi! It doesn't really work like that. KDE will be added when somebody decides to add it (KDE is huge, so ‘somebodies’), there's no plan. If you mean a page where people can note ‘I'm working on this’, I don't know of anything like that.
<dongcarl>Hey all, just pushed my first commit to master... Can someone check that I didn't mess up? *crosses fingers*
<nckx>minall: The nature of huge things like KDE is such that nobody is going to package & maintain them for fun, but only because they need them, and I guess nobody using Guix needs KDE (yes, it's a vicious circle).
<minall>nckx: You're right, I'll just install it for test, and then don't use it
<nckx>dongcarl: Nothing horrible jumped out at me 🙂 If you remade & ran tests it should be OK?
<dongcarl>nckx: Yeah I've definitely done that. I'm just anxious cuz sometimes git doesn't do what I think it does and I get yelled at :-)
<minall>If I wan't to replicate a guix system on another pc? how should I do it, I know is possible, maybe making a bootable usb?
<nckx>(If pressed I'd whisper something softly about (not no-cwd?) but that's about it :o)
<minall>If my wifi doesn't work with free drivers, what should I do? is there any other options, so I can remain with free software?
<str1ngs>nly: I'm just looking at this make-trampoline issue. as far as I can see C scheme api is not available at compile time. define-key does some module introspection. my proposal it to have a (browser-init) that is called within (@@ (nomad init) init). I'm still working on it will merge wip-webview-map into feature-emacsy and push my changes soon. I think it's better to call define-key in a procedure either way.
<nckx>minall: Replace your card with an ath9k? :-/
<str1ngs>nly: also I'm adding your keymaps to firefox-webview-map so that the end user can simply do (set! webview-map firefox-webview-map) in ~/.nomad . this should make that keymap extensible. since ~/.nomad is read at the end of (init)
<minall>Well, luckily I haven't had any problems, it was just a question that I had
<minall>So is there a way of replicating the same guix system on another machine?
<minall>Or it would have problems with the drivers?
<nckx>minall: Well, ‘doesn't work’ is pretty categorical. If a card doesn't work with free software, and you want to use free software (yes please), it's not like there's a magical 3rd option…
<nckx>minall: Guix System is deterministic, it doesn't silently install drivers because you happened to install it on certain hardware. Using ‘guix system init /etc/your-old-system.scm’ should reproduce everything your old system had *as far as Guix is concerned*. But there's still a lot of state like passwords, stuff in /var and /home, that Guix doesn't handle and that you must copy yourself.
<minall>For example, I'll copy a guix system from a pc, to a laptop, I have to connect the 2, and then act like my guix system is a usb, and do a system init to my laptop hard drive?
<nckx>minall: It's looking at a system (in this case a wireless card) for which you don't have the source/schematics/full documentation/… and figuring out what it does, when it does it, and how you can make something (in this case: a driver) that emulates that behaviour as closely as possible.
<minall>That's pretty hard to do, is there a tool or something?
<nckx>That ‘guix system init /etc/guix/system.scm’, where /etc/guix/system.scm is the same file, on both a huge 48-core server and a 2010-era laptop will ‘install’ the exact same system. It won't add a wireless driver because your laptop happens to have one, for example.
<minall>I see... so I should install the driver, and in the case there isn't any free driver, do nothing...ç
<nckx>minall: It *is* hard work. I'm sure there are specialised tools, but they are tools, they won't do the work for you.
<mbakke>civodul: Can we remove the time-monotonic workaround in (guix build gnu-build-system)?
<nckx>minall: ‘Wireless driver’ was just an example of something that a 48-core server probably doesn't have, I should have used Bluetooth as an example 🙂 It didn't have anything to do with your other question.
<minall>If it is 'easy' we would have a lot more drivers, since that's not the case... sadly
<minall>Yes, I understood the example, you mean how different they are, being a pc and a laptop, one having bluetooth and the other note, but guix system init installs the same configuration that I point out
<minall>So I can make a new configuration from the old one of my pc, but adapt it to be on a pc, and then guix system init
<nckx>minall: Yes! / other thread: I'm not sure what you mean by ‘act like my guix system is a usb’.
<nckx>You can just use the USB/ISO installer image.
<nckx>You'll have to connect the two systems to copy over your /home etc., but that can be done over the network using scp, or many other different ways.
<minall>nckx: I mean, I'm not pretty sure if it's like this, but I assume that making a USB of guixSD is just like a normal system, and 'guix system init' makes the config.scm that I point out, and then copies it in to the target, in the normal case, /mnt/ which would be the mounted target unit
<minall>nckx: Yes, using the USB/ISo would be the same, so that's the best option
<nckx>Could somebody explain http://paste.debian.net/1090799/, probably due to 0971f8bd884b6e92b77d9e12030cd58279699183? r-biocmanager is in (gnu packages cran) which is imported. Does deprecated-package not work across modules?
<nckx>jje: You wouldn't happen to be using emacs? It's not required, but it has a hand ‘C-M-q’ keybinding that you could use at the first ‘(’ of ‘(services’ that would indent everything for you and often makes such mistakes more obvious.
<bandali>funny the new Debian now ships gnome 3.30 but guix doesn’t (yet) :p
<rekado>bandali: it’s been ready for a *long* time in Guix, but it took forever to get it merged…
<bricewge>I want to post process a vm-image build with `guix system` how can I acheive that in guile only. I have written a guile script with a shebang but it doesn't seems right. Can it be done with `guix build -f`?
<bandali>rekado, i do know that, i’m strictly talking about guix master, and am mostly kidding ;)
<bandali>rvgn, iirc rekado did a lot of work on the upcoming gnome version in core-updates
<rekado>bandali: it’s been a considerable source of frustration :)
<rekado>not gonna touch the next gnome upgrade, that’s certain
<bandali>rekado, haha, i can only imagine… thanks for all your hard work on it
*rvgn thinks who ever is working on gnome 3.30.x could some how integrate with the report #35586
<rekado>zacts_pi: core-updates is a big expensive branch; it contains changes to “core” packages, which is why we freeze it at some point to ensure that we can build it all without having to rebuild everything again, because somebody made a change to GCC.
<rvgn>Is there a TO-DO list for next guix release?
<nckx>zacts_pi: Actually, I have a patch that explicitly calls ‘rfkill unblock’ in the installer sitting unmerged because I can't reproduce a need for it (connman always unblocks the wifi for me on any hardware I test). So I'd actually be interested in your details.
<nckx>rvgn: No, it can be ‘all’, or ‘wifi’ (or ‘bluetooth’) etc.
<rvgn>nckx Oh, in that case then wifi should be fine.
<nckx>In fact I'm not suprised that device names work, too, but I've never tried them myself.
<rvgn>nckx I think "all" would be better since some folks will be using bluetooth input devices??
<nckx>rvgn: Mmm, I tried to be more clever than that, but if there are documented cases of Bluetooth devices not working in the installer then maybe a big stupid unconditional ‘rfkill unblock all’ would be better ☹
<rvgn>Well, it only for installation. Newly installed guix system gonna be based on config anyway.
<nckx>No, but I'd rather not add it if no such system exists. Think about it: that would be a system that can't usably boot GNU/Linux without ‘rfkill unblock my-bluetooth-mouse-and-keyboard’. Do such systems even exist?
*nckx does not know, but I don't like ‘superstitious’ who-knows code like that. 🤷
*rvgn gonna do `guix package -u` and hopes not to get the soul sucked due to building.