<Blackbeard>that shepherd has services but systemd has units <Blackbeard>that both shepherd and systemd can handle system daemons but also unpriveleged users daemons <Blackbeard>oh I felt you were going to tell me it was the basics <Blackbeard>anyway I am a bit scared because this would be a hard project, so I want to make sure I write a good proposal and that I make it right <Blackbeard>I will try to do it even if I don't get accepted to GSoC :) <nckx>Well, those are the basics, but basics are important. And if you're starting from ‘what is a PID, what is the init process’, a lot. <nckx>It's good that you're reading this now. <Blackbeard>but I read this article about growing mindset and I said, ok I don't know this things yet, but I can learn them <Blackbeard>it feels more like a toy that I am playing with than something "serious" <nckx>That can be interpreted anywhere from very bad to very good 😃 <nckx>Not that I don't agree. Guix is fun. But it also runs all my ‘serious’ computing. It runs all my computing. <leoprikler>Things aren't quite as serious if you can roll back your changes without causing months worth of trouble. <nckx>Sure, Guix is fun during the day, but it also helps me sleep at night. <malaclyps>when I do "guix system reconfigure foo.scm", what user should I be? I've been doing "sudo guix system reconfigure /home/malaclyps/system.scm", but should i precede that with "sudo guix pull; sudo guix package -u"? Will a simple sudo refer to the right installation, or will my user environment variables screw it up? <malaclyps>I'm muddling through right now, but I'm never confident I'm doing it correctly. <Blackbeard>and then sudo guix system reconfigure ~/system.scm <Blackbeard>I think you can do it before or after reconfigure <malaclyps>haha I know how you feel! Thank you for being honest! <guix-vits>malaclyps: when on-top of foreigner distro, use sudo -E <malaclyps>guix-vits, this is from within the Guix system <malaclyps>hmm maybe within the Guix system I don't even need a root guix setup? <leoprikler>It's also sudo -E on guix unless you've pulled once as root ;) <malaclyps>so "sudo -E guix system reconfigure foo.scm"? <leoprikler>You'll use your own guix either way, but without -E you might get a cryptic warning. <guix-vits>malaclyps: using `sudo -E` is just make use of your user's `guix pull`. `sudo -i` need an separate `guix pull` from root. <leoprikler>I think my root might even have a few generations. <malaclyps>I just assumed /root needed one, but that's probably because I'm projecting from when I installed guix on an existing Debian install <malaclyps>I'm currently paranoid about using the wrong guix binary, because I still don't feel super-confident I have my PATHs etc set up correctly <leoprikler>using the wrong binary is really just an initial setup thing <guix-vits>malaclyps: there is only a "system profile" (`guix system reconfigure`), and the "users profiles" -- all independent from each other (root included; `guix pull; guix package -u`). <leoprikler>After your first `guix pull` as user and logging into a new shell, everything should work just fine <leoprikler>Guix is nice enough to tell you what to do, though. <guix-vits>malaclyps: sometimes you'll need to log off and log in (like with a gcc-toolchain package), or reboot (Kernel updates). <malaclyps>Blackbeard, I'm using the Guix system (ie just Guix, no underlying distribution) now <malaclyps>well my current PATH is /home/malaclyps/.local/bin:/run/setuid-programs:/home/malaclyps/.config/guix/current/bin:/home/malaclyps/.guix-profile/bin:/home/malaclyps/.guix-profile/sbin:/run/current-system/profile/bin:/run/current-system/profile/sbin <malaclyps>I'm not sure of the difference between all of those <Blackbeard>malaclyps: yes sorry, for a second I got distracted and your mention about the guix binary made me think of the binary for other distributions <malaclyps>I guess (filter (lambda (x) (access? x X_OK)) (map (lambda (x) (string-append x "/guix")) (string-split (getenv "PATH") #\:))) indicates there's a system guix, and a user guix ... maybe I don't even need the user installation? <nckx>malaclyps: What do ‘guix’ and ‘installation’ mean in that sentence? <nckx>Some truths: - you should never guix pull on Guix System unless you're doing special things and know why; - you should never ‘install guix’ with ‘guix install’. <nckx>Shit. s/never guix pull/never guix pull AS ROOT/ of course. <malaclyps>what's the deal with using installing guix as the root user on non-Guix System distributions? Is that just to bootstrap matters, or should you keep that root guix profile updated and upgraded? <Formbi>he's talking about other distros <Formbi>I think on these it's for the daemon <malaclyps>nckx, to answer your questions, I guess I meant 'guix' == the binary, and installation == copy of that binary in a user or system directory. Here's the result of that scheme fragment on my machine: https://pastebin.com/FadG2Bd9 <nckx>Blackbeard: Shepherd doesn't ‘create root’. When Guix System boots, an activation service does create user entries in /etc/passwd &c., including root's. But that's just a name tag. The actual user called root (UID 0) is a concept built into the kernel, it exists from the start. <nckx>There's no chicken & egg if that's what you mean. <malaclyps>and I guess I'm trying to understand what the difference between all those execution paths are. I have two copies, apparently, of the guix binary (I don't have guix installed with "guix install") -- does it matter which one is used? Why are they both available? <Blackbeard>A special service is root, which is used for controlling the Shepherd itself. You can also reference to this service as shepherd. <nckx>malaclyps: Describing /run/current-system/profile/bin/guix as a read-only bootstrap guix (so you can ‘guix pull’ and create your per-user, writable /home/malaclyps/.config/guix/current/bin/guix) makes sense. <nckx>Blackbeard: Ah, OK, yeah. Two different roots. <nckx>No relation, just named after the same concept (‘root of a tree’). <malaclyps>man, referring to things precisely on IRC in real time is difficult <Blackbeard>i've seen a few configuration files in github for shepherd <nckx>malaclyps: 's Why I often ask things like ‘what do you mean by installed?’. With traditional distros, installed == files on disc and files on disc == installed. With Guix, not at all. I think Guix's separation makes perfect sense but it takes a while to unlearn the simplism. *nckx super tired, sick; → bed. Good night. o/ ***catonano_ is now known as catonano
*vagrantc wonders why guix is still on linux-libre 5.4.x when 5.5.9 is already out <vagrantc>linux-libre 5.5.9 is available ... various 5.5.x have been available for quite a while *vagrantc gives it a whirl to update <drakonis>for some reason fsfla's website doesnt open <vagrantc>working on a minimalist patch to enable pinebook pro on aarch64 ... would be a lot easier on 5.5.x ***jonsger1 is now known as jonsger
<chrislck>guix guys: may I ask a few noob questions here. <chrislck>Is there a difference between a guix user (who wants to run dosbox, mame, libreoffice) and a guix developer (who wants to hack guix) and a regular developer (who wants to hack mame) <chrislck>2) the guix repo has an incredibly high commit rate -- is this the canonical repo reflected in guix pull && guix package -u? <chrislck>3) who has commit rights to the repo? i.e. a package maintainer may be intimately familiar with guile-gtk dev but may be ignoramus on everything else, how do changes go upstream? *chrislck don't mean to be rude, just very confused how information flows here <roptat>2 is yes, guix pull is a bit more complex than that, but it's essentially a wrapper around git pull :) <chrislck>^: ^_^ so someone/somebody/somegroup must be authorising all of these package changes <roptat>yes, there are 5 gnu maintainers and more commiters (not sure how many exactly, I'm one of them) <chrislck>bottom line is: I'm involved in gnucash development, and have no idea how to even start taking care of its guix package <roptat>the manual has good explanations on how to start hacking on guix. If you need to make a change to gnucash, you can follow that, make your change to the repo and send us a patch *chrislck doesn't want to hack guix-core... just possibly the gnucash-package <roptat>yeah but every package is in the same repository as the guix core :) you just need to change one of the many files in there <roptat>we don't really make a distinction between package maintainers, every commiter is allowed to change anything they feel confident in <roptat>of course some of us are taking care of different parts in practice but anyone can chime in <chrislck>so, if i've set up guix locally as a foreign installation, where is the gnucash package exactly? <roptat>you can get that info with "guix show gnucash" it says it's in gnu/packages/gnucash.scm <lfam>The webpage works for me <sneek>Welcome back lfam, you have 1 message! <sneek>lfam, nckx says: How hot does your CPU get at full load without SMT? And do you know how it compares to with? <roptat>you can also access the recipe with "guix edit gnucash" <roptat>(to modify that and send a patch, you'll need a local clone of the repo though, you can't do that with a compiled version of guix) <lfam>sneek: later tell nckx: I don't pay close attention to the temperature but it's usually between 60 and 80 C <seepel>How would I change my default shell to zsh? Looking at the system configuration docs it says something about the shell property being a g-expression, but I'm not sure what it should be. <roptat>chrislck, sorry I'm sick and I need some sleep now, I'm sure others will be happy to help :) <lfam>seepel: Add a line like this to your user-account section: (shell #~(string-append #$zsh "/bin/zsh")) <lfam>And make sure to import the package module that contains zsh in use-package-modules <seepel>lfam: thanks, that worked! Could you explain the expression to me? <lfam>Are you familiar with Lisp / Scheme quoting at all? <lfam>Like, quoting, unquoting, and quasiquoting? <lfam>Cool. These are called G-Expressions and they are similar to that, but specifically for the context of referring to packages in Guix. <lfam>The first one is called 'gexp' and starts the G-expression, the second one is 'ungexp' <lfam>The ungexp expands to a store path (e.g. /gnu/store/deadbeef...-zsh-5) <lfam>So it expands to something like (shell (string-append "/gnu/store/deadbeef...-zsh-5" "/bin/zsh")) <seepel>Ahhh, then in the store path the executable is in /bin/zsh <lfam>It *is* the 'bin/zsh' part <lfam>If you know about Scheme quoting then the manual chapter should not be too obscure <lfam>Otherwise... you can either read up, or copy and paste :) <seepel>I think I didn't quite get that #$ would point to the store <lfam>Yeah, the syntax is super obscure <lfam>There's nothing about #$ that is inherently Guix-y <lfam>It's just what was chosen <seepel>Can I put arbitrary scheme code inside an ungexp? <lfam>I'm hardly a Schemer so I can't say, sorry. Maybe somebody can answer, or wait until the European day for the channel to really perk up <seepel>I now no longer have to remember to type in zsh when I open a new terminal :D <KE0VVT>Is zsh just for people who hate copyleft? <brendyyn>i believe zsh had many fancy features bash didnt <apteryx>hmm, we have a patch for NetworkManager that makes it honor NM_VPN_PLUGINS_DIR, but I don't see that we are using that variable (say, in a search-path specification) ? <vagrantc>so, i've got a single untested patch to apply to add pinebook pro support ... but the linux-libre* packaging does patches differently than most packages i've worked on ... <vagrantc>it seems to download a few patches rather than use patches from gnu/packages/patches <vagrantc>i guess i could just upload my patch somewhere... <vagrantc>it's basically just a cherry-picked patch from linux-next applied to linux 5.5.9 <Kimapr>okay now i'm moving guixsd from flashdrive to usb hdd <Kimapr>interesting thing is that uuids and labels got copied too <Kimapr>so i don't need to change anything in configs <Kimapr>i'm doing this because flashdrive is just tooooooo slow <vagrantc>yeah, that's one reason to use uuids or labels <vagrantc>(although it's trivial to have conflicting labels) <vagrantc>uuids is considerably harder to get conflicts <Kimapr>you just dd partition's contents to another partition <Kimapr>what happens when there is a conflict? <vagrantc>but i'd also say common labels such as "root" are more likely to collide even on independent systems <vagrantc>pretty such it's a race condition ... whichever gets labeled first or last wins! <Kimapr>although i'm copying it right now <vagrantc>though, labels would get copied via dd just as much as uuids would <Kimapr>but i wouldn't boot from that flashdrive again ever <vagrantc>i *think* there's a way to non-destructively reset the uuid <Kimapr>there is an option to reset uuid <Kimapr>but obviously it *is* destructive <vagrantc>well, i mean of the data on the filesystem, not the filesystem metadata :P <Kimapr>okay good. two of partitions got copied <vagrantc>guix-vits: i'd want to apply it only to the specific linux-libre version ... maybe if i just specify the full path to it <vagrantc>in the middle of a long build at the moment ... so not able to test further changes... <guix-vits>it uses `(list some-patch another-patch`, so seems yes, but idk. <vagrantc>probably time i boot up the faster computers <vagrantc>search-patch rather than search-patches ... but yay <Kimapr>i moved guixsd on an external hdd but it doesn't boot <Kimapr>and it seems like it installed grub on the internal hdd <Kimapr>there are no efi files on system partition <Kimapr>also external hdd has mbr partitioning <guix-vits>Kimapr: Try to repeat the installation procedure, but for external hdd? About mbr... <Kimapr>i don't want to repeat the installation procedure <Kimapr>is it possible to boot efi from mbr hdd? <guix-vits>idk. Is this a 'grub-bootloader' targeting '/dev/sdX' in the config? <Kimapr>guixsd config has efi bootloader at a certain uuid <Kimapr>but efi filesystem it points to is empty <guix-vits>Kimapr: idk. How did you copied the flash drive? <iyzsong>MBR can work, depend on the firmware. also it can be convert to GPT. <Kimapr>i created 3 partitions on harddrive with size a bit larger than corresponding partitions on the flashdrive <Kimapr>then dd if=<partition on flashdrive> of=<partition on external hdd> <guix-vits>Kimapr, folks: Why not if=<flashdrive> of=<external_hdd>? afaik it should copy partition table as well. <Kimapr>it has important data on it, and it doesn't belong to me <Kimapr>so if the data is gone, it will be bad <Kimapr>is there a proper way to chroot into a guixsd system and then do guix system reconfigure? <guix-vits>Kimapr: maybe you don't need to chroot: in ex. HDD config only its FSes is being listed. Just change the bootloader section to MBR-compatible stuff, and run the command (should work). <Kimapr>how to change bootloader section? change to what stuff? i'm complete noob in this <guix-vits>`guix system reconfigure config_external_hdd.scm` <guix-vits>Not sure about The Store, though. But maybe it will boot. <Kimapr>wouldn't it reconfigure guix running on the foreign distro? <Kimapr>except maybe from the flashdrive. but this isn't what i want <Kimapr>i want to boot from external hdd <guix-vits>It will reconfigure the foreign distro, but i hope it will install grub to ex. HDD MDR. <guix-vits>There is example of MBR configuration of `(bootloader`. <guix-vits>grub-bootloader is for MBR, and accepts '/dev/sdX' arguments as a `(target`. <guix-vits>Kimapr: but honestly i can't be sure if this is correct way to do things. <Kimapr>i probably should have mount efi partition on /boot/efi/ during install <guix-vits>But your flashdrive booted up successfully before? <Kimapr>it installed efi bootloader on internal hdd <Kimapr>which isn't good for portability <guix-vits>you mean that flash drive has empty efi partition? <Kimapr>how to run guix-daemon on external distro without shepherd? <Kimapr>yes, flashdrive has empty efi partition <Kimapr>guix (not on guixsd) says connection refused when trying to do anything <Kimapr>i want to run guix-daemon but have no idea where does it live <efraim>if you used the install script it's in /var/guix/profiles/per-user/root/current-guix/bin/guix-daemon <Kimapr>the system uses systemd or whatever <Kimapr>okay i'm trying to re`guix system init` guixsd <efraim>guix system init will convert your current system to running Guix System (formerly named GuixSD) <efraim>actually I see you're installing to an external system, so 'guix system init' should be fine *efraim is currently at work, not really focusing on irc <Kimapr>i'm running `guix system init <path/to/config.scm> <path/to/system/root/of/guixsystem>` <Kimapr>oh. cool. initialization runs much faster on this external hdd than on a flashdrive <brendyyn>Is it necessary for the configure phase to fail when there is no configure file. Can't it just skip it like the bootstrap phase? <alextee[m]>oh configure. there's a modify-phases (delete configure) or something <Kimapr>efi partition is no longer empty <abralek>hm, svn under a proxy doesn't work =( <abralek>it disregard the leaking variables we have in svn-download <abralek>does anybody know a workaround for this? <guix-vits>abralek: can you please specify what exactly you're doing? <abralek>guix-vits: guix pull which is breaking on texlive-hyph-utf8 <abralek>I do see the variables via /proc/pid/environ <guix-vits>abralek: is tor blocked by this proxy too (torsocks, maybe)? <hulten>I had some problems to send in this channel (in HexChat), even as I was registered. <abralek>guix-vits: I don't know, but sshuttle do the trick <hulten>I am trying to get OMEMO working with Gajim, but it complains about python-axolotl; <hulten>even though this package is installed: <hulten>$ guix package --list-installed="gajim|axolotl" <hulten>gajim 1.1.3 out /gnu/store/nnyzsrmhya5gjb8ch85f371z163ysn04-gajim-1.1.3 <hulten>python2-axolotl 0.1.39 out /gnu/store/b5i9wyqpxhp1irs9vkx2hyq9dmjd6d37-python2-axolotl-0.1.39 <hulten>Did anyone experience this issue? <abralek>hulten: what is the warning are you getting exactly? <guix-vits>abralek: cool. tor is some sort of duct-tape :) <guix-vits>hulten: try to log-off and log-in. it's helped me once. <abralek>guix-vits: not sure that corporate security will appreciate using tor. <abralek>guix-vits: same with sshuttle though :P <abralek>but that svn:// scheme is not proxy friendly for sure <abralek>it would be cool to have a fallback to http <abralek>and propagate http-proxy using to svn checkout using --config-option <hulten>When going to installed plug-ins, OMEMO is showing this message: <hulten>Warning: You are missing Python-Axolotl or use an outdated version <hulten>(Sorry, abralek, I had some problems with my window manager and then I had to «ghost» my nick—learning every day. :-) <hulten>It would be useful if Gajim would tell me which version of Axolotl I need, and where it is looking for the library. <abralek>hulten: hm looks like python2-axolotl might be in some propagated-inputs <abralek>try to remove it and install the plugin or package -i <plugin> python2-axolotl <hulten>I had to install gajim-omemo with 'guix package' – I could have known that 'guix package' would handle plug-ins as well. :-) <hulten>On other systems one installs the plug-in (only) within Gajim. <abralek>hulten: you are welcome. I try to use guix package for everything, and package everything I need <abralek>python and pip is a good example as well <abralek>pip install - nooo, guix package -i -- yes <hulten>I agree – I have stayed away from Python just because of stupid package managers my collegues use/advice (and pip is not the worst). <hulten>This is a quite stupid reason, maybe. I chose Julia for my (scientific) computing (when I have the choice). <hulten>I have no idea if Julia packages integrate in Guix, but maybe Julia's own package manager is fine. <abralek>Yeah, I don't know about Julia but I've seen some good blog posts on python and jupiter-hub. <abralek>I will try to adopt it our projects later on. <davidl>Im trying to build guix but Im failing the make check stage for a number of tests: builders, build-utils, challenge, channels, containers, cpan, cran and debug-link for commit 6e003bd4ccd7470247b1fdbee3a6c6a0ad8054ac. I was just trying to build it to use ./pre-inst-env guix build some-package to contribute, and not sure if it's important that these tests PASS or not when just contributing some packages? <rekado_>hmm, getting ‘connection refused’ trying to fetch from git.savannah.gnu.org <davidl>abralek: Im in a VM and host-machine has VPN, I guess the host counts as a proxy? <chrislck>does anyone have a skeleton recipe for starting a guile & gtk based app? <rekado_>chrislck: that’s a rather vague request. There are countless package definitions using gtk in (gnu packages *) <abralek>davidl: How do you configure network access to your VM? For instance in virtualbox you can map ports <abralek>davidl: or provide a free access to it <davidl>abralek: my qemu-ifup script just does some NAT actually. <chrislck>thx rekado_ - highlights how steep the learning curve is. if i want to start to develop a small gtk based app, is it possible to do in a foreign installation? <chrislck>IOW would be nice to have a guix tutorial which *removes* all the hyperbole about scheme :) <abralek>davidl: hm I do recall I had to dance with qemu -net thingy. What do you have there? <rekado_>chrislck: I don’t understand how the availability of countless examples indicates that the learning curve is steep. <rekado_>and yes: Guix package definitions are the same no matter if you’re using Guix System or a foreign distribution. <davidl>abralek: the qemu-ifup thing is some pretty old convoluted script but has generally worked well to assign a full network interface not just the user-level networking. <davidl>abralek: I have done that, then guix environment guix, then ./bootstrap, then ./configure --localstatedir=/var, then make, then make check <abralek>davidl: Ok, so I guess it means the network is working fine. I would try to change guix channel to you local repo <abralek>davidl: that is what I am doing in our corporate environment <davidl>abralek: so you mean ~/.config/guix/channels.scm should point to the local repo, say ~/src/guix (to where I did the git clone)? <mbakke>so most things using 'moc' from qtbase are failing spectacularly on the core-updates branch, unless you remove both GCC and glibc from CPLUS_INCLUDE_PATH during the build <brendyyn>i used package-with-python2 the same way as other packages, but the package retains the name without swapping "python" for "python2".... strange <davidl>abralek: Ok I can try that. Im running guix pull now using local repo, then Ill redo the ./bootstrap, ./configure ... steps inside guix environment guix. <brendyyn>Did anyone ever try to build a python2-pyqtwebengine? :/ <rekado_>brendyyn: do you have a package that needs it? <brendyyn>i gotta get past this little hurdle: Error: Unable to import PyQt5.QtCore. Make sure PyQt5 is installed. <rekado_>did they commit to maintaining python 2…? <brendyyn>there is a py3 branch. I think it's moving slowly <brendyyn>personally i don't care if its python 2 3 4 5 6 7.. i just want it to work <rekado_>with Python 2 having reached EOL it doesn’t sound like a good idea to add more python2-* variants. <brendyyn>Realistically what could go wrong? exploits/ <guix-vits>brendyyn: i'm was a brave adventurer like you... then <strike>arrow in knee</strike> i was pwned with colibri. <abralek>guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'... <abralek>guix offload: Guix is usable on 'build-machine' (test returned "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test") <abralek>guix offload: 'build-machine' is running GNU Guile 3.0.0 <abralek>guix offload: error: failed to connect to `#<input-output: channel (open) 7f9fb0927ea0>': Protocol error <brendyyn>Calibre is used by 10+ million people is useful and actively developed. i hope noone will oppose me updating it. <abralek>daemon versions are the same guix-daemon (GNU Guix) 1.0.1-15.0984481, How can I debug that issue? <rekado_>brendyyn: of course we’re not opposed to you updating it! <rekado_>brendyyn: I just think it would be better to switch to the py3 variant if it works. <rekado_>abralek: is the offload target machine using Guix System? <abralek>rekado_: It uses a foreign distro centos 7 <abralek>I do see /var/log/guix/drvs logs on the other side though <rekado_>abralek: in my offload experiments I used to have odd errors due to GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH variables having wrong values (or being unset). Could you check those? <abralek>Hm, ok. Let me check. But quick question does the communication happens in a single connection initiated by the master? <oliverp_>Hm I understand that you was was intrested in doing a GSoC project for guix this summer, is that still the case? <gagbo>Hello, do I need to do the FSF contributor thing to propose a package for guix ? I just built a few guile 3.0 derivations of packages I use and I wonder how I can get guix pull / guix package -u to automatically update those <janneke>how are the per-slide audio files created for our videos? <brendyyn>It compiled @_@. Apparently it needed python2-enum34. I wonder why the python3 version didn't... <janneke>i'm doing something like: ffmpeg -f pulse -i default 1.ogg <janneke>which is kind of clumsy handling: ^C or q RET <oliverp_>guix-vits thanks for link to the log. I must state that it was quite exciting to read a message from someone with interest in doing serious work to improve shepherd <guix-vits>gagbo: anyone can contribute. Contributions are reviewed by crew :) <oliverp_>without sI don't there this an overstatement that an improvement (and more feature complete) shepherd is very exciting promise and something which I assume would prove to be quite beneficial for guix (and gnu in generel) <abralek>rekado_: hm I had to install guile on the remote and it looks better now <abralek>guix offload: error: unknown error while sending files over SSH <abralek>guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'... <abralek>guix offload: Guix is usable on 'odhat100' (test returned "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test") <abralek>guix offload: 'odhat100' is running GNU Guile 3.0.0 <abralek>sending 1 store item (0 MiB) to 'odhat100'... <abralek>exporting path `/gnu/store/nysw1jals3jl8rpbb486g8nnbp3vv9l8-export-test' <abralek>guix offload: error: unknown error while sending files over SSH <rekado_>gagbo: there is no need for copyright assignment for contributions to Guix. <janneke>guix-vits: i need more context to process your question, subtitles for which video? ;) <janneke>guix-vits: questions about the conference are best asked in #libreplanet :-) <brendyyn>calibre runs, suprisingly. it just shows ImportError: No module named QtWebEngineCore <mbakke>brendyyn: I guess qtwebkit needs to be replaced with qtwebengine? yay :) <brendyyn>i've build python2-qtwebengine. it just just doesn't find the python module for some reason <mbakke>brendyyn: can you share the python-qtwebengine definition? <brendyyn>mbakke: yeah, although i just copy-pasted the existing python-qtwebengine, and changed it to python2, and added python2-enum34 <rekado_>brendyyn: can you load the module in a Python 2 session? (Try guix environment.) <mbakke>brendyyn: you are missing the #:python argument <mbakke>setting #:python ,python-2 in arguments should do the trick <rekado_>mbakke: do you have root access on bayfront? Would you be willing to reconfigure it? I added a new sub-domain to the DNS config. <brendyyn>oh this is using the gnu-build-system, so there is no #:python i think <mbakke>rekado_: I do not even have a user account, not sure who to ask. *mbakke has worked on way too many python packages recently <brendyyn>the python repl said it couldn't find sip <rekado_>mbakke: oh, okay. I think you’d ask Andreas or add yourself to maintenance.git. <jsoo>but i got the following build error <jsoo>seems like somewhere in emacs-next or an emacs package, there is a reference to /bin/sh <jsoo>guix-vits: hmm, what do you mean by that? <guix-vits>like all these emacs-xyz is "runtime-dependencies" of your collection. <jsoo>no they would be loaded into the pdmp file <jsoo>emacs 27 has a dumping mechanism that will dump the state of the emacs memory to a file. <jsoo>so it is a further compilation step for emacs. mostly for startup times and to move away from the unexec dumper. <jsoo>guix already makes emacs startup times pretty good but i want to see what else is possible <jsoo>the idea is to load in all those packages to memory and then dump it. then make the `emacs` executable refer to `emacs --dump-file <result of package output>.pdmp` <jsoo>i have yet to experience a successful emacs startup from a dump file, but i understand it is fast. <jsoo>when i do this outside of the guix build environment, i get segfaults <jsoo>i have tried a few times. i hear quite a few success stories, so my theory is there is some unconventional package that i am using that causes the segfaults. <jsoo>I made the package definition to test the less likely theory that there might be something environmental effecting the dump file. <jsoo>then ran into /bin/sh somewhere in the store <mbakke>jsoo: in unrelated news, I recently updated PySide2 and Shiboken, could you check that FreeCAD still works as expected? :) <jsoo>mbakke: sure! thanks a lot for keeping an eye on them. <jsoo>mbakke: are those patches on master? <jsoo>mbakke: thanks. so did the qtbase bug get fixed? <jsoo>mbakke: i don't know if i can summarize quickly. it looks ok though <jsoo>mbakke: the one last thing to do would probably be to update the git refs for pyside and shiboken to branches for qt@5.12.7 <mbakke>jsoo: I switched away from the (defunct) git repo to the official releases <mroh>json: maybe, one of the emacs packages you use misses the /bin/sh substitution we have for lots of emacs-packages. maybe try something like `ag "/bin/sh" /gnu/store/*emacs*` to find it... have you tried dumping w/o magit (as the missing /bin/sh seems to happen there)? <jsoo>mroh: good call. i will try removing magit. i will try searching for that string, too. <jsoo>mbakke: hmm. i am sorry i must be missing something. do you have the commit hash of the change? <mbakke>you'll notice that all three packages share the same source and version, seemed easier that way <jsoo>seems good to me! i was, and remain a total qt ecosystem newbie. <brendyyn>I'm not sure exactly what to run in the repl. i ran from PyQt5.QtWebEngineCore import QWebEngineUrlScheme, and it shows ModuleNotFoundError: No module named 'PyQt5.QtCore' <brendyyn>but it does that for both the origin python3 version too <jsoo>mbakke: ok i see your changes. one moment while i test. <mbakke>brendyyn: I notice most of the qtwebengine users have a wrapper that sets QTWEBENGINEPROCESS_PATH <mbakke>maybe you need something similar? <brendyyn>can that affect python module loading tho? <mbakke>brendyyn: hmm, anki also has a comment that says "qtwebengine must precede python-pyqt in PYTHONPATH" <mroh>jsoo: another try could be, setting $SHELL for the `emacs --batch --eval ...` invoke... <brendyyn>that's the first time i've ever seen input ordering cause a bug. what madness <jsoo>i'm guessing projectile could be at fault? <abralek>rekado_: Thanks for the hint. guix copy doesn't work. Reports guix copy: error: unknown error while sending files over SSH <mroh>jsoo: yeah, saw that too (and lots of tramp). I looked at the source and it uses /bin/sh only, if SHELL isnt set. that leeds me to the $SHELL suggestion... <jsoo>mroh: hmm. i like the thought. i will try setting $SHELL and report back <abralek>rekado_: When you said about GUILE_ vars where exactly I should check? daemon? user bash_profile? Master or remote? <abralek>rekado_: I think I added them everywhere. guix copy check shows the variable <abralek>I think the problem happens on the socat'ing a daemon's socket step <jsoo>mroh: well, setting $SHELL seems to do the trick. thanks! <mbakke>abralek: in my offloading setup, the dedicated user has 'guix' in the profile so that (use-modules (guix)) etc works <mbakke>that's the only thing it has, apart from guile and glibc-locales <mbakke>abralek: it also sources ~/.guix-profile/etc/profile from .bashrc <abralek>mbakke: I do have guix there and it's working <mbakke>rekado_: I got news from #savannah that they apply rate limits on ssh:// connections, do you know if Cuirass is set up with that? <rekado_>mbakke: no, I think cuirass just uses https. <rekado_>also my ‘guix pull’ and ’wget’ attempts all use https. <mbakke>abralek: does ssh user@host guile -c "'(use-modules (guix config))'" work? <mroh>jsoo: hmm, should we at a "(substitute* (find-files "." "\\.el") (("/bin/sh") sh)" to the projectile pkg? <mbakke>rekado_: more news, we are confirmed to be fail2ban'd <mbakke>rekado_: they will whitelist the Berlin IP so it does not happen again :) <mbakke>all credits to bandali and rwp :-) <rekado_>abralek, mbakke this seems to be a common problem; can we produce better error messages here? <abralek>rekado_: we definitely have to. I was poking different commands and args to guix copy and was getting different error mesages <mbakke>abralek: can you file a bug report, with the experience fresh in mind? :) <rekado_>abralek: ‘unknown error’ is barely even an error message :) <abralek>even though my mind is not fresh at the moment =) <jsoo>mbakke: freecad at least starts fine. i wish someone who uses freecad a lot would see if it really functions fully but no regressions i can see. <mbakke>jsoo: excellent, thanks for testing <jsoo>no problem, thank you so much for updating them! <mbakke>apteryx: I've seen jlicht around ocasionally, but not atm it seems <apteryx>OK. Was wondering about the state of the NM_VPN_PLUGIN_DIR environment variable support they added to network-manager last summer. Seems we don't make any use of that. <apteryx>The openvpn plugin of network-manager still doesn't work, I think I can fix this by setting the NM_VPN_PLUGIN_DIR in a search-path specification <apteryx>that search-path should just set the var to lib/NetworkManager/VPN, I think, because: /gnu/store/wxgraqcr3rx6ws4y4k1gwh9cdw892mha-network-manager-openvpn-1.8.10/lib/NetworkManager/VPN/nm-openvpn-service.name <apteryx>likewise, for vpnc plugin: /gnu/store/...-network-manager-vpnc-1.2.6/lib/NetworkManager/VPN/nm-vpnc-service.name :-) <bricewge>Does someone already tried to send a patch series with `git send-email` in one go with the `--no-chain-reply-to`? <bricewge>I was fumbling in the git manual and the debbugs usage page and for what I understand it would allow us to avoid waiting for the debbugs bug number <apteryx>about search-paths; why do we usually encounter them as 'native-search-paths' rather than just 'search-paths' (twice as many hits grepping) ? <apteryx>IIRC, native-search-paths will set the path both at build time and run time, because the default value for the search-paths is native-search-paths. But in my case (and the case of any plugins) I think it doesn't make sense to use native-search-paths :-) <apteryx>(which occur at build time -- native platform) <bricewge>Debbugs would create an issue for the first email received and then put all the subsequent emails under the same issue because their In-Reply-To headers will be set to the first mail. <apteryx>ah, the NM_VPN_PLUGIN_DIR stuff is already in network-manager-shepherd-service <lfam>bricewge: That would be awesome <jsoo>hmm. now the emacs dumping process fails to make any dump file. <Kimapr>is there any API documentation on guix? <Kimapr>i mean, for package defs, system cfgs etc etc <apteryx>I tried to debug network-manager-openvpn plugin as instructed here: https://wiki.gnome.org/Projects/NetworkManager/Debugging, but I get: nm-openvpn[5411] <warn> Failed to initialize a plugin instance: Connection ":1.331" is not allowed to own the service "org.freedesktop.NetworkManager.openvpn" due to security policies in the configuration file. Ideas? <apteryx>Ah! I had to restart the dbus-session service. <apteryx>Strange that reconfiguring my system didn't take care of that alone -- perhaps a dependency missing. <apteryx>well, now in syslog, I see: result="fail" reason="The VPN service 'org.freedesktop.NetworkManager.openvpn' was not installed." upon trying to up my openvpn connection with nmcli. Hmm. <apteryx>I see this kind of error in dbus-monitor, seemingly related to policy-kit: error_name=org.freedesktop.DBus.Error.AccessDenied on the interface interface="org.freedesktop.PolicyKit1.Authority. <sneek>Welcome back civodul, you have 1 message! <sneek>civodul, rlb says: any idea if that bug you just fixed might cause the "Aborted" failures we're seeing? <civodul>apteryx: weird, there's no polkit file in network-manager-openvpn <apteryx>civodul: Before I restarted the dbus-session service manually, I had a different error upon trying to enable my openvpn connection with nmcli: "Timed out waiting for the service to start". <apteryx>Perhaps I should just reboot, a la Windows ;-) <civodul>apteryx: badmouthing! but yeah, why not reboot :-) <apteryx>(what I did was: 1) reconfigure after modifying my network-manager-service-type to add the network-manager-openvpn plugin to its config 2) test 3) sudo herd restart networking 4) test 5) sudo herd restart dbus-session 6) test) <apteryx>civodul: when a services extends another one (such as network-manager extending dbus), is the extended service restarted upon reconfiguring? <apteryx>It seems recently things improved (used to be that nothing would be restarted, IIRC), but that's not true for everything IIUC. <guix-vits>someone possibly should update the online Manual: in info i'm just read: "only supports ext4, btrfs, and JFS file systems." While online version only mention ext4 and btrfs. <civodul>apteryx: what gets restarted has nothing to do with extensions <civodul>quoth the manual: reconfigure "starts system services specified in FILE that are not currently running; if a service is currently running this command will arrange for it to be upgraded the next time it is stopped (e.g. by ‘herd stop X’ or ‘herd restart X’)." <civodul>in general, you wouldn't want reconfigure to unilaterally restart your running X or SSH server :-) <vagrantc>could a service define weather it is safe to automatically restart? <apteryx>I guess this can be improved on Hurd :-) <civodul>"apt-get dist-upgrade" is similar but asks interactively, IIRC <apteryx>I wonder how people patch CVEs on their services... Reboot? <civodul>vagrantc: it's not possible yet, but it's worth considering <civodul>the prime example is nginx, which has a non-stop restart method <civodul>i think there was even a patch for that a year ago or so <vagrantc>right; a lot of services in that category <lfam>guix-vits: In general, the online manual corresponds to the latest release. My guess is that Guix 1.0.1 did not support JFS <rekado_>guix-vits: there are two versions of the manual online. <vagrantc>if this ever finishes compiling... and boots successfully, i might have a pinebook-pro capable kernel to push to master "soon" <vagrantc>managed to cross-compile it ... now compiling in place... <apteryx>it could well be that activating my openvpn connection really fails, because it depends on an interactive user provided username/passphrase. <guix-vits>lfam: oh. thanks, i'd not thought about that. <vagrantc>any comments regarding linux-libre 5.5.9 ? i've verified the upstream tarball and deblob* stuff works. <apteryx>I use the auth-user-pass some-file.txt trick in its config, but perhaps the nm-openvpn plugin disregards that <vagrantc>i haven't taken the time to update all the aux-files/linux-libre/5.* stuff <lfam>vagrantc: I would run it by Mark Weaver <apteryx>civodul: while you are here, do you know if our init RAM disk is network enabled? I guess not? <vagrantc>i was thinking of just adding a patch for 5.5 (for pinebook pro) and just adding all the linux-libre source bits, but not switching any of the existing linux-libre* packages to 5.5.x <lfam>I think he would appreciate some assistance <apteryx>I'm asking this in the context of booting from NFS. I'm still pretty naive about the subject, so the question might not make sense (perhaps GRUB should be network aware for a NFS boot to work). <vagrantc>i find the updating of the kernel configs tedious and have taken a liking to using the defconfig kernel variants :) <vagrantc>i should probably remove the arm-veyron config ... it hasn't worked for me for ages and have been using -arm-generic <vagrantc>and would like to add linux-libre-arm64-generic too <lfam>Are you using the pinebook pro? Does it feel fast enough for Guix? <vagrantc>lfam: it seems reasonable, though i haven't yet tested a GUI yet <vagrantc>mostly just trying to get the kernel and bootloader working out of the box with minimal changes <lfam>I feel like some of the Guix commands are not that quick even on amd64 so I've avoided all the A53 machines, but the pinebook pro has some A72s, so that is nice <vagrantc>i find "guix pull" to be useable ... which is debateable on some of the other arm platforms <vagrantc>yes, the A72 cores make a big difference <lfam>It was really painful using Cortex A7 a few years ago *vagrantc also means to test rockpro64 and rock64 <vagrantc>there's been huge progress with libre graphics on allwinner and rockchip platforms <vagrantc>so they're really starting to get attractice <lfam>That's good. I remember back then the Lima project had totally stalled <vagrantc>kernel compile is definitely still slow :/ <janneke>vagrantc: <might have a pinebook-pro capable kernel to push to master "soon">: amazing! <lfam>I'm hoping for a more powerful Olimex laptop <lfam>Kernel compiles are super slow on my thinkpad too <vagrantc>janneke: we'll see if it's wishful thinking <vagrantc>janneke: the device-tree for pinebook pro landed in linux-next, and applies to 5.4.x and 5.5.x ... no idea if it works :) <janneke>vagrantc: sure; if this step doesn't bring us there, what about the next step? ;-) <vagrantc>janneke: i have high hopes for worst case being "wait for linux-libre 5.7.x" <vagrantc>but if we can get it working sooner, so much the better :) <janneke>ah; so great work is already being done (by the manjaro hacker, i figure?) <vagrantc>there are a few non-device-tree patches in tsys's manjaro linux branches, but i'm hoping it gets some basic functionality with just the device-tree <vagrantc>janneke: i've got more incentive to not boot off the x86 machines since i switch to solar :) <vagrantc>guix-vits: for my day-to-day office stuff, more-or-less ... still can manually plug into the grid <abralek>is there a reason why guix package -i guile doesn't define GUILE_LOAD variables? <abralek>I have to install a guile package in order to get them in ~/guix-profile/etc/profile <rekado_>abralek: that’s because it’s only needed for Guile packages. <lfam>abralek: Are your openjfx patches ready for review? Or are you still working on them? <guix-vits>Blackbeard: yes (currently that bearded-bro) <guix-vits>Trouble that i'm barely understood spoken English. <apteryx>civodul: network-manager-openvpn seems to work after a reboot :-) <apteryx>it nags me with authentication, but that's a good sign. <abralek>lfam: Thanks for asking. I did some changes, but haven't pushed them yet. <abralek>I was going to test openjfx-web part one more time, but because it takes 20+ minutes to build it I decided to try offload <lfam>abralek: Okay, let's close your ticket for now. When you are ready you can open another one. It's more confusing than I remembered because it is spread over several bug ticket numbers <vagrantc>alright ... linux-libre-arm64-generic built ... now for the tricky part ... passing the right modules to the initrd <lfam>abralek: Done. This will make it easier to get the patches into Guix :) *vagrantc tries with empty modules <abralek>Is there any convention where so libs should go? out/lib or out/lib/<arch>? *janneke just finished building new set of bootstrap binaries, reset wip-hurd <vagrantc>lfam: (or anyone) do you know if it's possible to generate extlinux.conf without installing a bootloader? <sneek>nckx, lfam says: I don't pay close attention to the temperature but it's usually between 60 and 80 C <lfam>Unfortunately I don't know about that kind of stuff, vagrantc <nckx>Hm. Mine peaks at 90°C and I'm pretty sure that's a measurement limit. Time to bust out the hoover. <lfam>nckx: Maybe I do hit 90 C <lfam>I have a "warmup" script for the winter <lfam>I did recently clean my fan while reseating the wifi chip <nckx>lfam: Does it use ‘stress’? <lfam>It does `yes > /dev/null`, once per logical core <lfam>It pegs the CPUs until you kill it <lfam>Been going for 5 minutes, the temps are around 85 C <nckx>Ah, OK. Then mine are not too disturbing. <lfam>I started it using when dealing with cold macbook pros at work. They are left in trucks overnight and the metal cases are really uncomfortable in the winter <lfam>Got to warm them up for my hands <nckx>…wait you're serious aren't you. <lfam>Yes, I work for an event production company. I try to convince them not to let the equipment get so cold but it's not a priority <lfam>And, the computers are still working great after 5 years <lfam>I'm out of work for months now, nckx. So, not so cool :/ <nckx>I guess ruggedised macbooks aren't a thing. <lfam>All events are cancelled <nckx>Oh, I'm sorry, silly me. <lfam>You can imagine there is not much help for me, being in the US <lfam>That's why I'm here all day recently :) <nckx>(Same here, both jobs, I feel your pain.) <lfam>Just have to convince the landlord to cancel my rent <Blackbeard>I don't know but I just found out my desktop has a sftp server on <nckx>Blackbeard: ‘Server’ is inaccurate. SFTP is just ‘ssh into this box, run a command to copy files’. <nckx>If you run an SSH server, you run an ‘SFTP server’. <nckx>It has nothing to do with FTP (FTP + TLS = FTPS, I think), if those three letters of disrepute have you worried. <nckx>lfam: But all the freedom, man. <Blackbeard>That's cool. Android VLC recognizes it and I can hear music from my desktop on my phone <Blackbeard>nckx: I am not worried. Is just I was surprised it worked without me doing anything <vagrantc>having two fast cores and 4 slow cores still works well with highly parallelizable tasks (e.g. building linux-libre) <lfam>vagrantc: It uses them wisely? <vagrantc>lfam: it seemed to ... sort of ... e.g. one of the fast cores was at full use, the smaller cores were slightly used ... but the second fast core was very underused <vagrantc>but since the kernel build is many small tasks, having many cores is sometimes better than fast ones <vagrantc>well, first boot failed ... but that might not be the kernel ... will need to plug in serial console and see how far it got <guix-vits>vagrantc: how do you ground yourself (static discharges)? <rekado_>g_bor[m]: you could already play with zabbix. You just need to create your client cert. <alextee[m]>ah sorry i left my patches half-way. i have a few more to send, gonna fix/send all sometime next week <lfam>Any sway users here? What do you think of the proposed sway section for the cookbook? <lfam>I have a couple minor edits in mind but I want to know if the overall thing seems sound <sirgazil>lfam: I'm using sway, and I think a recipe for that fits on the cookbook. <lfam>Do you like that recipe? <guix-vits>lfam: sway's config is already packaged. Maybe better not to download it: ''output * bg /gnu/store/cl77sbf44sa7ji23ydk8q0hvpkhpxn7n-sway-1.2/share/backgrounds/sway/Sway_Wallpaper_Blue_1920x1080.png fill'' <sirgazil>lfam: Oh, I didn't read it. I don't have the time right now. <lfam>guix-vits: I don't think that's the same file. That's just an image file <lfam>You have some pending patches too, right, sirgazil? <guix-vits>got it: it removes gdm, and saves other ones (NetworkManager, elogind and other goodies). <guix-vits>lfam: one thing: please, add (flags '(no-atime)) to btrfs. <lfam>I was going to remove everything except for the services section <lfam>The other stuff is not relevant <lfam>I'm not sure about the suggestion to remove GDM, after saying that "it might work" <guix-vits>lfam: it is in fact an "light verstion of Gnome session". It's beutiful, but fat. <lfam>I feel like cookbook recipes should be clear and easy to follow. Saying that it might work, might not... it needs some more work in my opinion <guix-vits>lfam: what about to "`(define` @with-gdb and @without-gdb, and ;; with-gdb -- uncomment it, if want (untested)"? <rekado_>guix-vits: cookbook recipes should be clear and to the point. <rekado_>experimentation is encouraged but we don’t want a bunch of experiments in the recipe <lfam>I replied to the author asking if they have it working with GDM <guix-vits>lfam: i'm forget: if user has an i3wm config in ~/, then glitches are possible. not mentioned in this patch. <lfam>Does sway read the i3 config? <guix-vits>seems to. deleting of i3 one solved my issues. <seepel>Hi there, I'm trying to run the light weight window manager system configuration from the manual by using guix system vm, when it opens gdm in qemu I only get a blank screen, does anyone have any hints on how I can debug? <aidenholmes>i'm having an issue, it's not system-breaking, just annoying <guix-vits>lfam: How about to add a hint that user read the config (shortcuts are there)? <guix-vits>roptat: are you there? aidenholmes calling :) <seepel>Ohh, I haven't seen that project before, looks neat! <guix-vits>seepel: but according to the creator (above one :P) is yet buggy. <roptat>I use it daily and it's terrible ^^' <roptat>software just don't expect $HOME to be read-only <roptat>so some of them are completely broken, like pulseaudio or libreoffice <roptat>hexchat is annoying but it works (it will tell you "hey your $HOME is read-only" at startup) <lfam>seepel: Are you saying that GDM does not load? Or that after logging in with GDM, you see a blank screen? <seepel>lfam: When I would normally see the GDM login screen, I now only see a black screen in qemu <roptat>libreoffice simply fails with something like "I can't access my config" even if it has a a read-write symlink at the expected location <seepel>Whether it is loading and displaying a black screen itself, vs not loading; I cannot tell the difference <roptat>so it's usable, but not very friendly <aidenholmes>ok i'm back, first order of business: getting bash files working <lfam>seepel: Hm, I would try `guix system vm-image` instead of `guix system vm`. The latter creates a read-only immutable VM and I expect that GDM needs to write some session data <roptat>I'm working on something with maven, os there might be some delay in my answers, but I'll answer eventually ;) <seepel>I suppose I colud also back up and describe what I _actually_ want to do. I'd like to experiment with guile-wm, so I figured the easiest way to do that would be to run it in a vm <seepel>lfam: Good suggestion, I'll give it a shot <lfam>seepel: You will need to copy the image out of /gnu/store and make it writeable <lfam>seepel: Check the manual section Running Guix in a Virtual Machine <aidenholmes>this is difficult because the machine that i have guix on has nothing installed, no irc, no graphics, and i can't install things because of HOME not being writable <aidenholmes>i could make a new user on it and install things as that user so i can use pastebin and things like that <seepel>lfam: Thanks for the heads up! Would probably have struggled with that for a while :D <aidenholmes>it's very difficult to copy all the instructions by hand <roptat>nothing I can do to help there though <aidenholmes>i could just use the root user for this purpose but running things like a window manager as root is probably not recommended <roptat>however, you should be able to run "guix install" and run the software installed by doing something like this: mkdir /tmp/home; HOME=/tmp/home the-software <aidenholmes>i would prefer to have another persistant account and use it while setting things up <seepel>I guess while I'm getting bites, I have another question. I'm also trying to fine tune my trackpad settings using the extra-config field of xorg-configuration. What is the fastest way that I can test my changes? Right now I keep rebooting, is there an easier way? <guix-vits>seepel: try to log-off and go to tty2, and `herd stop gdm` or so, then `herd start` ? <nckx>aidenholmes: The X server is provided by xorg-server. <roptat>if you want a graphical interface though, you should use the desktop services, xorg alone will not do anything <guix-vits>aidenholmes: better go with sway (same with Wayland) <aidenholmes>i would prefer to limit the amount of new things to learn <seepel>guix-vits: Thanks, that seems slightly faster <guix-vits>seepel: slightly? Consider to use sway. Can be started from console, no need for fat gdm. <guix-vits>touchpad, pointer, keyboard, touch, tablet_tool, tablet_pad, switch... no trackpads. strange. <seepel>I'd like to stick with xorg for now because I'd ideally like to play with guile-wm <guix-vits>but then you're better keep gdm (or light-dm). Xorg is better not to touch if it's working :) <seepel>It seems in theory one could do a similar thing to guile-xcb for wayland, which seems eventually interesting <lfam>Sadly someone in the #libreplanet channel is spreading FUD about Guix <lfam>Please don't go there and argue about it <seepel>For now I'd settle for being able to launch guile-wm <lfam>No, leave it alone guix-vits <lfam>Just sad to see in such a prominent channel <lfam>There has already been a lot of arguing, for months <guix-vits>lfam: i'm just have nothing to argue with them, as they are humans and have a reasons, whatsnot it is. <guix-vits>anyone heard something about xtym from Fedora? He's last post is from 7-th February. <aidenholmes>yo imagine if someone tried to use a home manager but also used systemd-homed <nckx>lfam: They're just salty and want attention. Best to ignore them. <civodul>i'm afraid the on-line event risks being more toxic than the in-person event :-/ <nckx>That's usually how it goes. <roptat>I found it pretty good until now, but maybe I was on the nice channels? <lfam>It was basically okay. Just the regular FUD in the main channel <lfam>I tried to push back a bit without starting an argument because it's not fair that we would be maligned in that place during the conference <seepel>What's the TLDR on the FUD? I'm now curious <lfam>Oh my goodness, here we go <roptat>oh right, I was in the channels for the talks, not reading the main one <Blackbeard>How can I configure gdm to automatically boot to my user <lfam>Some people think that Guix is secretly including nonfree software or violating the FSDG somehow, because we don't agree with their assessment of certain packages <lfam>And they also disagree with our adoption of a code of conduct <lfam>Based on these things they claim that we are not inclusive and that Guix is not free software <lfam>Obviously, we disagree with them <nckx>lfam: Having gone back to read the history, I should clarify: I *really* appreciate you sticking your neck out to respond and think that it's important to address such misinfo for the benefit of everyone else. <lfam>It's okay, there are as many opinions and points of view as there are people. It's natural. I hope that eventually Guix takes over the world <Blackbeard>lfam: because of ungoogled-chromium or something ? <Blackbeard>That's insane the FSF certification exists for a reason <lfam>Yeah, that's the main sticking point. They think we did not audit it carefully enough, although I think we audited it extensively <jonsger>one can even present with Google Chrome at Libreplanet, so what :P <seepel>How would I go about installing guile 3? <guix-vits>seepel: guile-next, basically. but someone reported auto-compile clashes. <civodul>so who's in for bug squashing the coming days? :-) <civodul>a good activity if you're confined anyway :-) <seepel>guix-vits: thanks! Is there a way I could've found that package name myself? Also, what's an auto-compile clash? <lfam>civodul: I've been working through some patches :) <Blackbeard>guix-vits: ohh we can even change to slim or sddm. Didn't even think about it <lfam>Unfortunately will probably be around a lot for several weeks <civodul>apteryx: speaking of which, do you have a lead for the btrfs-root-os test failure? <civodul>that's something we could investigate <guix-vits>seepel: afaiu, guile creates an byte-code (ahead of time "compilation"), and guile-3 can do so. But they have the same path to store those artifacts. <cbaines>unfortunately I'm busier at work at the moment it seems, but I'm also up for some bug squashing if I can make the time :) <Blackbeard>civodul: I am :) seems like a nice way to get started <seepel>guix-vits: Ahh, is this the whole 2.9 vs 3.0 version vs effective version thing? <Blackbeard>Although barrage was accepted :D so in a way I started already <guix-vits>civodul: where is the list of tests that should be ran? <lfam>aidenholmes: To change shells on Guix you use the (shells ...) field in (user-accounts ...) in your config.scm <seepel>aidenholms: I think you want to set the shell property in your operating-system definition <seepel>I actually asked about this yesterday and lfam sent me this: Add a line like this to your user-account section: (shell #~(string-append #$zsh "/bin/zsh")) <nckx>aidenholmes: It can be wherever and called whatever you want, but ☝ is the installer default. <seepel>Did you create the user after install or during? <nckx>aidenholmes: Those changes won't be saved. <seepel>Ahh, then it wouldn't be updated. I think the guix way would be to add all your users to config.scm and run sudo guix system reconfigure /etc/config.scm <nckx>You should create users by adding them to your system configuration and then ‘guix system reconfigure’ to apply the changes. <seepel>nckx: I seem to have to use sudo, is that correct? <nckx>You also need to add the name of your system configuration file, that was not a complete command. <seepel>The basic idea of guix is that you can pretty much fully specify your system declaratively via a scheme file. Then rather than having to remember and go through a set of imperitive steps to configure the system, it is all defined in one place. <seepel>I'm sure others can explain that part better than me though :D <aidenholmes>sorry i didn't know that adding users was controlled by that <seepel>aidenholmes: No worries at all! I'm here to learn as well! <nckx>aidenholmes: Yep. Passwords are exempt, though. You probably don't want to specificy those declaratively unless you have a way to keep them encrypted. useradd no, passwd yes. <guix-vits>nckx: but it's not perfect (?): once i'd UID of my user shifted -1 (deleted one user that was created before; also switched generations in GRUB back and forth...) <seepel>I thought I saw that you can specify the uid as well right? <nckx>guix-vits: You can specify UIDs if you want them to be static. <OriansJ>nckx: passwords shouldn't be stored in anything except a password manager, everywhere else use hashes, with salts and public keys; then privacy is less of an issue. <nckx>guix-vits: I've never done anything else so I didn't know that even happened. <nckx>s/encrypted/cryptographically hashed/ then. The point is that the store is world-readable, /etc/shadow isn't, and that's a big difference. <nckx>Whether or not you think shadow is the right approach. <guix-vits>nckx: UID wasn't shown in example, btw; thanks. <OriansJ>ideally if I gave you The hash and the salt for my credentials; it would not matter unless the underlaying crypto or password is weak. <nckx>That's the philosophical discussion I wanted to avoid with my ‘Whether…’. <OriansJ>say sha512 and a 4096character (randomly generated and changed monthly) password <nckx>Someone thought shadow was a good idea, everyone else jumped on board, Guix silently reverting that convention now is not the way to go. <nckx>Personally, I agree with your ‘ideally…’ point btw. <OriansJ>well guix needs a way to leverage secrets in a manner that can't be leveraged by the build process. <nckx>I think we should also utilise them and synergise the results but that might be asking too much. <OriansJ>well symmetric encryption for secrets that require the password to be passed to unlock is not an unreasonable compromise <OriansJ>but such things should never included in the store anyway <jonsger>civodul: I'm happy to join the bug squashing team :) <OriansJ>The problem is because guix does everything in guile (essentially) there is no good way to prevent secrets from being dragged into package build processes. *jonsger wonders if someone tried to run guix on Ubuntu Phone <OriansJ>jonsger: guix doesn't do well on low memory systems *OriansJ thinks it is weird to call systems with 4GB of RAM low meory systems. <jonsger>OriansJ: it has at least 8 times the RAM of my N900 (Fairphone 2) <nckx>I ran a 256 MiB-RAM Guix System in 2015. I know it's ballooned since. What's the current minimum? <nckx>(With swap, of course, but usable.) <OriansJ>nckx: depending on if you are using an SSD or spinning rust; but generally 4GB assuming you don't need things like a modern web-browser (icecat) <nckx>OriansJ: Oh, no, I just mean Guix itself. *OriansJ remembers writing a C compiler in only 14.4KB <nckx>It became impossible to ‘guix pull’ on that headless box, so I got rid of it. <nckx>Browsers are for hipsters and won't last. <OriansJ>I've been having a painful time with 4GB of RAM and 4GB of Swap with guix these days <jonsger>browsers with jited JS are for hipsters :P <guix-vits>OriansJ: try to disable swap. I'm currently use Chromium-based qutebrowser, chat with ERC and have two terminal-emulators opened. But maybe you need more. <nckx>Disabling swap will make your system slower, not faster. <nckx>I'm a big zswap fanboy. zstd + zsmalloc. <nixo_>how are conflicts managed? When two packages in the same profile provide the same library, which one ends up existing? Do I have control over it? <OriansJ>day to day usage guix-vits is only 64MB here; guix is the only resource hog I have to deal with. <nckx>nixo_: Arbitrarily and no, but libraries shouldn't be loaded from your profile anyway. <jonsger>one should not hardcode store links into system.scm configs :P or at least never run `guix gc` :P <OriansJ>heck I finished getting stage0's M0 assembler to run in 12KB of RAM and still compile 4GB input files <nckx>guix-vits: Could you explain? <nckx>I mean, it'll be a tiny difference unless you're low on RAM but keeping unused things in memory will always be slower than putting them to swap for a week. <nckx>guix-vits: <somehow, stright reverse. honestly.> <guix-vits>nckx: it was this way: loop `use laptop for a day, suspend` --> a lot of things in swap. Everything comes to crawl. Without a swap i've no such troubles. IDK why so. <OriansJ>guix-vits: spinning rust instead of an SSD I guess <nckx>That sounds pathological. <nckx>I have an SSD only on my laptop, but it has 16 GiB of RAM and hardly ever swaps. <guix-vits>so, for bug-squashing i'm need to read issues or another site? <seepel>Does anyone have a rough idea of why guix needs so much ram? I have some interest in running guix on a phone. <lfam>Does Guix need more RAM than other distros? <nckx>lfam: Guix needs more RAM than other distros' *package managers* is the point, I think. <nckx>And that is definitely science fact. <OriansJ>it also does alot more than other distros' *package managers* <nckx>OriansJ: It *does*. But that only buys us so many megabytes. <nckx>It does less, too. Gentoo's out there building packages and (ill-advisedly) resolving dependencies with a lot less RAM. <OriansJ>nckx: well that is certainly a problem for guix developers to opt to spend time upon. <OriansJ>break guix into well defined pieces that only do exactly 1 thing <OriansJ>then profile and optimize each for performance/memory usage <OriansJ>aka, apply classic good systems engineering to the problem at hand. <seepel>OriansJ: Are there pieces of guix in particular that you think are prime candidates for separating? <OriansJ>seepel: well ask yourself this; what guix commands feel slowest to you and go from there. <Blackbeard>I've not noticed any RAM problems in my laptop from 2012 with a 1.2 GHz dual core AMD processor