<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 <rvgn>vagrantc So no issues with uefi itself right? <rvgn>Which firmware is the factor? <vagrantc>i'm not deep enough in to categorically answer that :P <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? <vagrantc>that's where you get into the restricted boot issues <rvgn>Ah I see. So if the firmware allow users to define the valid signers, restricted boot is not an issue right? <vagrantc>i would say not ; if i can define which keys i trust to sign my binaries, that's a pretty big security gain <rvgn>Thanks for your input :) <vagrantc>it does make it possible to accidentally brick a machine, though, e.g. by specifyin keys that you loose access to, etc. <vagrantc>but that's just about proper backups and not really a freedom issue <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 <pkill9>how can i create a guile function that puts an arbitrary number of arguments into a list, e.g. (my-function 1 2 3) letting me use (list 1 2 3)? <civodul>pkill9: you'd create a function that takes an arbitrary number of arguments and simply returns it <civodul>the syntax for that is: (lambda args args) <pkill9>civodul: what i mean is, without any limit on the number of arguments, e.g. (my-func 1 2) would return (list 1 2), and (my-funct 1 2 3) would return (list 1 2 3) <roptat>I think you were missing a "." :) <civodul>equivalent to (define my-func (lambda args args)) <pkill9>that would work? wouldn't it take only two arguments? <pkill9>or does it take unlimited if two arguments with the same name are defined? <rain1>(lambda (x y) body) takes 2 args <rain1>(lambda (x y . z) body) takes 2 or more args <rain1>(lambda z body) takes 0 or more args <pkill9>oh, i want to do something with it, not just return it, that was for an example <rain1>you can do (lambda args (f args)) then <nly>i have a package that only builds on x86 GCC-toolchain <nly>but i guess most amd64 systems can still run the 32bit binaries <efraim>I messed up my dovecot sieve rules and now my inbox is being spammed <mfg>How do i format the output of %desktop-service nicely in the repl? it is completely unreadable, because it's too much text :D <mfg>Where do i find some advanced guix config examples? <civodul>mfg: if you use Emacs with guix.el, try M-x guix-default-services <civodul>as for displaying at the REPL, i think you can do (map (compose service-type-name service-kind) %desktop-service) <mfg>Thx civodul. this is indeed MUCH better :D <mfg>does anybody use sway? how does the config look like? i'm trying to get rid of gnome and need some examples :( <nly>do you have a packages field in your operating system declaration? well you probably have to add sway to that packages list <nly>(operating-system (packages (cons sway %base-packages))) or similar <nly>at the login screen you should then be able to switch to sway wm, using some F1-F12 key <pkill9>the config is the same as i3's config i think <roptat>what package provides autoreconf? <roptat>I thought it would be autoconf or automake, but apparently in my guix environment --ad-hoc automake autoconf, I don't have it <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) <str1ngs>pinoaffe: adb usually needs udev rules <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))))) <roptat>and I added myself to the adbusers group (and created the group) <minall>Where can I see when KDE is gonna get added, is there a page or something? <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. <minall>Because I saw some KDE aplication, but not KDE <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>(Guixers yelling? Unthinkable.) <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? :-/ <minall>nckx: That's the only option :( >.< <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… <minall>I have heard of 'reverse engineering' <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>What do you mean by deterministic? <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 <minall>btw What are the difference between using sheperd or systemd? I don't see the difference yet <mbakke>uh,oh, ant-bootstrap is failing on core-updates <dongcarl>mbakke: If there are any `gnu/{build/cross-toolchain,packages/{gcc,base,cross-base,commencement}}.scm` changes you'd like to see/review, lmk! *dongcarl literally runs `git log origin/core-updates -- gnu/{build/cross-toolchain,packages/{gcc,base,cross-base,commencement}}.scm` every morning <mbakke>dongcarl: Excellent, reading your reply now. <lupaa>Nobody experiment nothing similar to me ? <mbakke>dongcarl: Are you using the master or core-updates branch for the bitcoin builds? <mbakke>lupaa: When did you try it? The script was updated a few days ago to mitigate the ongoing attack on the PGP keyserver network. <lupaa>mbakke: I think was a week ago <mbakke>lupaa: Then I'm afraid your keyring might have become corrupted :/ <zacts>I love guix, but I'm keeping it on a second laptop for now <zacts>it's just too slow to do package operations for now. I'm still learning how to use it though. <zacts>I really love the philosophy behind this project though <zacts>I'm not building from source <zacts>I'm on an older laptop though <dongcarl>zacts: Oh I see, yeah having substitutes should make the experience closer to something like `apt-get` <zacts>dongcarl: it might be because I'm doing a `guix system rebuild ...` each time <zacts>I need to modularize my system recipes <dongcarl>zacts: Ah perhaps the guile eval is what's slowing you down <zacts>I'm coming from NixOS though, and a full system upgrade on there takes less than a minute, on Guix this takes at least 5-10 minutes it seems. <zacts>dongcarl: I have tried both distros separately on this laptop <zacts>I first had NixOS -> I tried Guix System -> back to NixOS <zacts>I'm getting a new laptop of the same model this week <zacts>so I'll be able to tinker with both systems <mbakke>dongcarl: On an unrelated note, do you think we can get Bitcoin 0.18 in Guix? :-) <dongcarl>mbakke: For sure. that seems quick and easy! <zacts>I could dual-boot too I guess <zacts>but I just happen to be getting a new laptop <dongcarl>zacts: I think it is worthwhile (for software freedom's sake) to be performant even on older machines <dongcarl>If you could post to the mailing list some comparisons of comparable changes in Nix and Guix configs and their `reconfigure` runtimes, that'd be very helpful <zacts>also, I want to help improve the installer <zacts>the installer totally didn't work for me <zacts>it was an issue with needing to rfkill on my wifi <str1ngs>nly: merged your changes along with make-trampoline fixes. not ideal, but I have added FIXME's for how to improve on this in the future. <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? <mbakke>nckx: Maybe a stale bioinformatics.go? <nckx>mbakke: That's what I thought at first, but that log is from my substitute server, so mild panic. If it's not broken elsewhere: good. <mbakke>Errh, didn't realize the change was in bioinformatics.scm. <nckx>OK, quick scriptaroo reveals that *every single* use of deprecated-package is intra-module… except mine ;-) Problem found. <nckx>mbakke: Does ‘Errh’ mean ‘oh, then I indeed expect it to break’? <mbakke>nckx: It means I have no idea :P but I guess you found the problem. *nckx tests whether expressing dep-pkg ‘manually’ fixes it. <mbakke>Is mothacehe around? I wonder if we should take the cross-system patches for this core-updates. <efraim>mbakke also do we want to merge the different sqlite packages? <mbakke>efraim: Is there a discussion about it somewhere? <mbakke>efraim: I suspect sqlite-with-column-metadata can be removed entirely; IIUC the APIs enabled by it is part of our regular sqlite package. <quiliro>Mi volas traduki la lernolibron Guix-an. Mi ne estas esperantisto sperta, sed mi povas korekti la erarojn en sekvaj verioj. <mbakke>At least, sqlite3.h is identical between the packages, and contains sqlite3_column_database_name() & co. <nckx>(quiliro: kaj lernas Esperanton, sed malrapide.) <quiliro>Mi pensas ke traduki la lernolibron plibonigos mian sperton en Esperanto kaj en Guix-o. <nckx>quiliro: Pli bona: s/malrapide/lastatempe/. <quiliro>pardonu min...mi ne komprenas lastatempe <nckx>Kiam mi skribas pli bone (kaj ropide), mi povas helpi. <nckx>quiliro: Eh, mallonga tempo? <quiliro>nckx: Ĉu vi volas traduki la lernolibron de Guix-o ankaŭ? <quiliro>nckx: Ho! Mi komprenas....vi kunlaboras por traduki en mallonga tempo. <nckx>Jes, sed unue uzu Guix-on per eo_XX. Ĉu vi povas? <quiliro>nckx: Mi pensas ke tio estas bone. :-) <nckx>Mi lernas lastempe, mi skribas malrapide. ;-) <quiliro>nckx: Jes, mi ne volas uzi la Guglon Tradukigon. *nckx ne voles uzi Guglon. <quiliro>"Mi ne volas uzi la Guglon Tradukigon ankaŭ ne." estas pli korekta. <mbakke>efraim: Derp, nvm: qtbase failed to link against the normal sqlite. <nckx>quiliro: Jes. Dankon. /me estas ne /mi… <quiliro>nckx: Kiel ni komenzos? Mi volas uzi la Emacs-on. Mi vidas ke Emacs havas po-mode_on. <nckx>Jes, jes. But—no, no English. Pff 😃 Eh: la IRC ‘/me’ ne estas ‘mi’ por verboj. ‘/me xxx’ = ‘he xxx’, ne ‘I ...’. <nckx>quiliro: Por Guix: /me neniam tradukis .po dosiero kun ‘specialised software’. Emacs estas bona. <quiliro>‘specialised software’ = 'specialiga programo' <quiliro>nckx: Mi ne trovas la po-mode_on en Emacs-o. Ĉu vi konas manieron de traduki kun Emacs-o? <dongcarl>mbakke: Just saw your email, thanks for the review! I'll put the comment in! <nckx>Eble mi povas paki po-mode? <quiliro>ho! paki! jes....mi serĉis "paki" en la vortaro kaj mi trovis ĝin. ho! <quiliro>nckx: Jes. Mi petas ke vi pakas la po-mode_on. <quiliro>nckx: Mi kelkefoje preferas la vortaron....ha! <nckx>Ah, po-mode estas en gettext… <nckx>jje: For one, (service sddm-service (sddm-configuration (display-server wayland))) in inserted somewhat randomly in a place where it can never work. <nckx>And as quiliro implies, your indentation is misleading which is seldom a good sign. 🙂 I'm guessing in this case you intended (service sddm (…(…))) to be between (service gnome-…) and (remove …). <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. <nckx>quiliro: Ne vere, syntax-o estas ankau malbona. <dongcarl>Is there a convention for whether to inherit from newer packages or older ones? I see that the gcc's all inherit from older, while bdb inherif from newer <mbakke>dongcarl: I don't there is an established pattern. I prefer inheriting from the newer, but there are situations where that does not work (e.g. due to rebuilds). <dongcarl>mbakke: Ah, for `bdb` the older package definition works for newer ones as well, but not the other way around, so I think I'll inherit from older to keep things succinct <dongcarl>Also the change doesn't trigger rebuilds, so that's good *dongcarl is thankful for guile ***jonsger1 is now known as jonsger
*rekado tries the new doc/build.scm script <rvgn>Is linux-libre 5.2.x in yet? <nckx>rvgn: Not in master yet; still on the kernel-updates branch. ***zacts is now known as zacts_pi
<rvgn>Any update on gnome 3.30.x ? <rvgn>It appears it was realsed long ago in upstream. <dongcarl>mbakke: Thanks for the review on `make-gcc-toolchain`, I replied to the thread with an updated patch. Will wait until next Monday to push to master (it shouldn't trigger any rebuilds). ***jonsger1 is now known as jonsger
<mbakke>rvgn: GNOME 3.30 is on the core-updates branch, but won't it master until a few more weeks at least. <mbakke>You should be able to try it out in a week or two. <rvgn>mbakke That's nice to hear :) <rvgn>mbakke Do you know who is maintainer if gnome in guix? <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 <rvgn>bandali Oh, i did not know that. Thanks! <rvgn>rekado Thanks for you work :) ***zacts is now known as zacts_pi
<dongcarl>Are pushes to `core-updates` still okay right now? I know the freeze is tomorrow... <zacts_pi>is there going to be another version of guix soon? <sneek>Sneeky bot running on Guile version 2.0.11 using bobot++ 2.3.0-darcs <nckx>zacts_pi: Building everything & then merging into master. <nckx>zacts_pi: Ah, I don't know. <nckx>Sneek also noticed that weird laggy glitch. <Guest30806>is it normal for guix to take a long time to install? <nckx>Sneek is very particular. <dongcarl>Guest30806: Oh, don't know much about the graphical install... <sneek>Sneeky bot running on Guile version 2.0.11 using bobot++ 2.3.0-darcs *rekado takes off hat and shakes head in silence <Guest30806>how do I next time make the install fast via manual install? dongcarl <dongcarl>Guest30806: Make sure you're downloading from substitute servers <rekado>Guest30806: no need to use the manual installation method. <rekado>in any case you’ll end up with a configuration file and Guix will try to turn it into an actual system. <dongcarl>As long as you're using substitute servers, it doesn't matter which method you use, graphical or manual <rekado>and either method is going to be slow if you’re building things locally instead of downloading binaries from our substitute servers. <quiliro>for me, barebones install is 30 minutes and desktop install can be up to 2 days <rekado>you can also make that three weeks if you’re building everything from source… <rekado>so these times really are not comparable <Guest30806>how do I know if it is building everything from source? <jonsger>rekado: on which branch is the update of gnome-3.30 happing? the wip-gnome3.30 one <rekado>jonsger: no, wip-gnome-3.30 has already been merged into core-updates. <rvgn>Guest30806 Are you using public WiFi hotspots? I faced the same issue due to poor network. <zacts_pi>I had sluggish performance even with the substitutes <jonsger>ah oke, but core-updates will be merged soon? <zacts_pi>rekado: what is the freeze for, a new release? :-) <rekado>Guest30806: I recommend to build a small system first, so that you can get binaries for most if not all needed packages. <rvgn>Guest30806 I see. May be the I/O speed is low due to USB? <rekado>Guest30806: if you add big packages to your system configuration that have not been built on our servers yet (or whose builds failed) then you would end up building them locally. <rvgn>rekado But graphical install does not allow to edit config.scm during installtion to include custom system packages !? <rekado>rvgn: it allows you to add packages, of course <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>rekado Ah I see. I would have over-looked. <rekado>zacts_pi: the freeze is just so that we can merge it into the master branch (and thus make the changes available to all users) without subjecting users to a lack of substitutes. <rekado>Guest30806: the reason is to install the system. <rvgn>Guest30806 If you are at that stage, then you are almost done :) <Guest30806>since it says "initializing operating system in /mnt" <Guest30806>I am just not using my login creds cause it is on my computer when I am installing guix on a usb stick <rvgn>Guest30806 You could do "/nick usney" <Guest30806>no problem I think I can just copy the hexchat config to this computer <Guest30806>btw I bought some books from sites recommended by defective by design. <zacts_pi>I had an rfkill issue with the installer <rvgn>zacts_pi I had the same issue. nckx found out that it was an issue with linux-libre upstream. ***tux_ is now known as usney4
<rvgn>zacts_pi The command `rfkill unblock all` worked for me to overcome the issue. <zacts_pi>but I didn't know how to properly report this bug to the ML <rvgn>zacts_pi I thought of reporting it, but since it is related to upstream, there is nothing much guix folks can do. <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>So wifi doesn't work; ‘rfkill unblock wifi’; wifi works? <nckx>(‘all’ is a nice shortcut but I'm curious whether ‘wifi’ suffices.) <zacts_pi>nckx: I'll have to get back with you by the end of the week <zacts_pi>I will be installing Guix again on Wednesday after I get a new laptop <nckx>What's strange is that connman calls rfkill itself but it sometimes seems to fail when a manual invocation works just fine :-/ <nckx>zacts_pi: Oh, take your time. Thank you! <rvgn>nckx `rfkill unblock wlp2s0` worked for me though. *zacts_pi makes a note in my Todo <nckx>rvgn: As in, just ‘wifi’ doesn't? <nckx>I'd rather keep it at that level, not per-interface. <nckx>(One of my laptops has 2 wifi cards for example, and I'd rather not enumerate all interfaces when rfkill already handles that for us.) <rvgn>nckx I haven't tried "wifi" since the syntax should contain device name right? <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>nckx Better safe than sorry :P <nckx>☹ because it might drain a bit more power than necessary during the installation. <rvgn>no downsides of using all anyway right <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 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. <rvgn>nckx Oh your messages reached me late <rvgn>nckx just "wifi" is better then. *jonsger still works on gnome-contacts... <nckx>rvgn: Yeah, Freenode is glitchy for me as well. <rvgn>jonsger Oh I am glad you are working on it. Wanted it so badly. <jonsger>of course :) for the mobile UI we would need a newer version or even a fork, but it's a good first step <nckx>jonsger: …it runs a forked Gnome? ☹ *rvgn had shortest `guix package -u` experience for the first time. Yay! <jonsger>nckx: some parts maybe forked, but they try to upstream everything. The development happens mostly at their forks... <nckx>jonsger: Oh, OK. But they're in good standing with upstream? I'm cautiously optimistic then. <jonsger>nckx: I have some critics with them, but the upstream is super fine. They have also a lot of developers working upstream or being maintainer... <jonsger>also they have some completely new software like Calls, Chatty or Phosh. Things a desktop doesn't need... <rvgn>nckx Is there a way to view list of new packages added to core-updates branch?? <nckx>rvgn: Er, ‘new packages’ hardly ever get added to core-updates so I'm not sure you mean what I think you mean. <rvgn>nckx Oh I meant list of packages that got updated/upgraded/improved? <nckx>Hm, actually, the new MES stuff did get added only to core-updates, it seems, but it's special. <nckx>rvgn: I don't know; I don't think there's an in-Guix way to do that (well, you could probably write some code yourself to compare two inferiors, but that's not what you mean). <nckx>rvgn: What I just did was: git log --format=oneline upstream/master..upstream/core-updates | grep ': Add' <nckx>(Your remote is probably called ‘origin’, not ‘upstream’, that's what I call it.) <nckx>That's at the commit level, not the package level, so not great.