IRC channel logs


back to list of logs

<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
<str1ngs>vagrantc: nice
<rvgn>Hello Guix!
<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>or rather, tianocore's edk2 is
<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
<rvgn>Okay ;)
<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>some make it configurable, some do not
<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
<vagrantc>there's no vendor lock-in there
<rvgn>Thanks for your input :)
<vagrantc>or if you can turn it off altogether
<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
<rvgn>I see.
<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>hi guix!
<civodul>Hello Guix!
<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>(define (my-func . args) args)
<roptat>I think you were missing a "." :)
<civodul>equivalent to (define my-func (lambda args args))
<roptat>or not?
<pkill9>that would work? wouldn't it take only two arguments?
<roptat>it works
<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
<pkill9>cool thanks
<pkill9>if anyone's curious, i was making a (channels <channel> <channel>) function for channels.scm that appends those channels to %default-channels:
<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)
<civodul>that should give you a clearer idea
<mfg>Thx civodul. this is indeed MUCH better :D
<civodul>heh :-)
<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
<jlicht>hey guix
<pkill9>the config is the same as i3's config i think
<roptat>what package provides autoreconf?
<pkill9>roptat: autoconf i think
<roptat>I thought it would be autoconf or automake, but apparently in my guix environment --ad-hoc automake autoconf, I don't have it
<pkill9>oh, maybe it's in autogen
<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)))))
<minall>Hello guix!
<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?
<str1ngs>nly: o/
<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>Oh I see!
<minall>Because I saw some KDE aplication, but not KDE
<nckx>minall: could be used to discuss/‘claim’ packages but doesn't seem to be. Have you searched the ML archives?
<minall>nckx: thanks!
<minall>ML archives?
<nckx>Mailing list.
<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.)
<nly>str1ngs hi
<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>How is thatd?
<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
<lupaa>Hello folks, I want to share something weird that happens when I ran guix installation script: something in my gpg ring get broken and I lost access to my keys. This script:
<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
*nckx AFK.
<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
<jonsger>dongcarl: nice :)
<mbakke>dongcarl: Excellent, reading your reply now.
<dongcarl>mbakke: Cool, happy to discuss here too
<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.
<dongcarl>mbakke: It's based on the master branch, see
<lupaa>mbakke: I think was a week ago
<mbakke>lupaa: Then I'm afraid your keyring might have become corrupted :/
<zacts>hi #guix
<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
<dongcarl>zacts: :-)
<dongcarl>zacts: Are you using substitutes?
<zacts>dongcarl: yes
<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>oh could be
<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>on the same laptop
<dongcarl>NixOS on the same machine?
<zacts>dongcarl: I have tried both distros separately on this laptop
<zacts>I first had NixOS -> I tried Guix System -> back to NixOS
<dongcarl>Hmmm that's weird
<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
<dongcarl>zacts: ^
<zacts>dongcarl: sure
<zacts>I'll try to do this
<zacts>also, I want to help improve the installer
<zacts>the installer totally didn't work for me
<zacts>I had to manually install
<zacts>it was an issue with needing to rfkill on my wifi
<zacts>I have an ath wifi device
<jonsger>meta-bug for librem 5:
<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>Oh, it's a telephone.
<nckx>Could somebody explain, 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>But I don't want it.
*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?
<efraim>No idea
<nckx>Saluton, quiliro.
<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.
<quiliro>nckx: kio vi faras?
<mbakke>At least, sqlite3.h is identical between the packages, and contains sqlite3_column_database_name() & co.
*nckx faras kafon 🙂
<nckx>(quiliro: kaj lernas Esperanton, sed malrapide.)
<quiliro>nckx: Kial 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>la Esperanto kaj en la Guix-o.
<nckx>Mi konsentas.
<quiliro>-vortaro lastempe
<quiliro>--vortaro lastempe
<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 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>quiliro: Dankon 😊
<quiliro>Dankon al vi! :-D
<nckx>Mi lernas lastempe, mi skribas malrapide. ;-)
<quiliro>nckx: Jes, mi ne volas uzi la Guglon Tradukigon.
<nckx>(Guglon = Google?)
*nckx ne voles uzi Guglon.
<quiliro> nckx: Jes!
<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.
<quiliro>nckx: s/voles/volas/
<quiliro>nckx ne volas uzi Guglon.
<nckx>quiliro: Jes. Dankon. /me estas ne /mi…
<nckx>*ne estas? 🤷
<quiliro>nckx: Kiel ni komenzos? Mi volas uzi la Emacs-on. Mi vidas ke Emacs havas po-mode_on.
<quiliro>nckx: ne estas = is not / am not
<quiliro>ne = not
<nckx>Bone, /me ne estas /mi.
<quiliro>Mi ne komprenas
<quiliro>mi = me
<quiliro>mi (Esperanto) = me (English)
<quiliro>= I (english)
<quiliro>pardonu min...
<quiliro>ĝi estas "off topic"
<nckx>Jes, jes. But—no, no English. Pff 😃 Eh: la IRC ‘/me’ ne estas ‘mi’ por verboj. ‘/me xxx’ = ‘he xxx’, ne ‘I ...’.
<nckx>Jes, tre.
<quiliro>Ni povos paroli en ##esperanto
<nckx>quiliro: Por Guix: /me neniam tradukis .po dosiero kun ‘specialised software’. Emacs estas bona.
<quiliro>Mi skribis vin en ##esperanto
<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>quiliro: ne sperta.
<quiliro>nckx: Ĉu vi uas po-mode_on?
<quiliro>en Emacs-o.
<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.
<nckx>quiliro: EoBot ;-)
<quiliro>nckx: Mi kelkefoje preferas la vortaron....ha!
<nckx>Ah, po-mode estas en gettext…
<jje>i am attempting to remove gdm and use sddm with the following configuration but it keeps telling me invalid field specifier. what am i doing wrong?
<quiliro>jje: check your parenthesis!
<nckx>jje: For one, (service sddm-service (sddm-configuration (display-server wayland))) in inserted somewhat randomly in a place where it can never work.
<quiliro>jje: Mi pensas ke tio estas ĉio.
<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 …).
<jje>ah i see ok
<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.
<jje>i will do that
<quiliro>nckx: Mi ne sciis C-M-q . Dankon.
<nckx>quiliro: Ne vere, syntax-o estas ankau malbona.
<nckx>Ne dankon 🙂
<nckx>*Ne dankinde.
*nckx for de klavaro.
<rvgn>Hello Guix!
<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.
<rvgn>nckx Thanks!
***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 :)
<bandali>no problem ^^
***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>what is the freeze for?
<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.
<zacts_pi>ah cool
<nckx>Sneek also noticed that weird laggy glitch.
<dongcarl>nckx: wut
<nckx>dongcarl: wat
<dongcarl>Sneek is a bot no?
<Guest30806>is it normal for guix to take a long time to install?
<dongcarl>sneek: bot snack
<nckx>sneek: botsnack
<nckx>Sneek is very particular.
<dongcarl>Guest30806: did you enable substitutes?
<dongcarl>Guest30806: How are you installing?
<Guest30806>I did the guided graphical install
<mbakke>sneek: What is sneek?
<Guest30806>now it is initializing operating system to /mnt
<Guest30806>this part is taking the longest
<dongcarl>Guest30806: Oh, don't know much about the graphical install...
<nckx>sneek --version
<sneek>Sneeky bot running on Guile version 2.0.11 using bobot++ 2.3.0-darcs
<nckx>sneek --botsnack
<dongcarl>sneek --selfdestruct
<nckx>Ominous silence.
<dongcarl><- sneek left
*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.
<Guest30806>not from the gnu store?
<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
<dongcarl>Idk if graphical offers that option
<quiliro>Guest30806: how long has it been?
<rekado>and either method is going to be slow if you’re building things locally instead of downloading binaries from our substitute servers.
<Guest30806>I am installing it on to a usb
<rekado>hours is not normal
<dongcarl>usb tho...
<quiliro>for me, barebones install is 30 minutes and desktop install can be up to 2 days
<Guest30806>I installed xfce
<quiliro>i have a core 2 duo
<Guest30806>me too
<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?
<Guest30806>it appeared like it was though in the setup
<Guest30806>because it said "building"
<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?
<rekado>jonsger: freeze is tomorrow
<zacts_pi>I had a good network connection too
<rekado>then we’ll build it all
<Guest30806>no I am using a home wired connection
<zacts_pi>rekado: what is the freeze for, a new release? :-)
<rekado>zacts_pi: no.
<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
<Guest30806>I see
<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.
<Guest30806>well it hasn't stopped working
<rvgn>rekado Ah I see. I would have over-looked.
<Guest30806>it is continuing to install
<Guest30806>just taking forever
<zacts_pi>oh I see nice
<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.
<Guest30806>it is copying files to /mnt for some reason
<rekado>Guest30806: the reason is to install the system.
<Guest30806>yes I guessed that
<rvgn>Guest30806 If you are at that stage, then you are almost done :)
<Guest30806>since it says "initializing operating system in /mnt"
<Guest30806>My nick is usney by the way
<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>but I don't know my login info
<Guest30806>I have it setup to autolog me in
<rvgn>great! :P
<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.
<Guest30806>no DRM
<Guest30806>going to reboot
<Guest30806>new system upgrades for debian
<Guest30806>buster has released
<Guest30806>be back
<zacts_pi>I had an rfkill issue with the installer
<zacts_pi>I wonder how to debug and PR this
<rvgn>zacts_pi I had the same issue. nckx found out that it was an issue with linux-libre upstream.
<tux_>I am back
***tux_ is now known as usney4
<usney4>aka guestuser
<rvgn>zacts_pi The command `rfkill unblock all` worked for me to overcome the issue.
<zacts_pi>yeah, I got it to work
<zacts_pi>but I didn't know how to properly report this bug to the ML
<zacts_pi>I need to learn how to use ML again :-)
<dongcarl>usney4: hi
<rvgn>zacts_pi I thought of reporting it, but since it is related to upstream, there is nothing much guix folks can do.
<zacts_pi>ah yeah
<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 :-/
<zacts_pi>I'll put Guix on my current laptop
<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?
<rvgn>Ah I see.
<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>Ah I see
<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.
<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>rvgn: it's part of the effort :)
<rvgn>jonsger Ah I see. But it will also be useful for as well :)
<jonsger>of course :) for the mobile UI we would need a newer version or even a fork, but it's a good first step
<rvgn>Yep :-)
<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'
<rvgn>I see.
<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.
<quiliro>kiu uzas emacs-guix?