IRC channel logs

2018-05-11.log

back to list of logs

<vagrantc>i don't know if there's an easier way, but configuring max-jobs=0 seems to cause offload to kick in...
<vagrantc>ok, offloading is pretty cool. it makes it possible to run guixsd on a slow ~1GHz arm board with 512MB of ram. :)
<Apteryx_>vagrantc: interesting! so you had to set that max-jobs=0 in order to offload everything?
<Apteryx_>what is the libexec directory for?
<pkill9>where is the `guix environment` command defined in ~/.config/guix/latest ?
<mange>My guess is something like scripts/environment.scm, but let me check.
<mange>Close! guix/scripts/environment.scm
<vagrantc>Apteryx_: yeah, just ran "guix pull --max-jobs=0" and it started offloading... once i had the configuration set up according to the manual with "guix offload test" and all that
<apteryx__> vagrantc great! I'm trying to accomplish that too.
<apteryx__>:)
<apteryx__>not ARM, but old laptop which struggles just compiling Guix
<vagrantc>apteryx__: well, good luck!
<vagrantc>ACTION waves
<Apteryx_>why do I need sudo to use ping?
<Apteryx_>(on GuixSD)
<mange>You shouldn't. I have never had to do that.
<mange>What does your $PATH look like?
<mange>Actually, more basic question: what happens when you run ping without sudo?
<pkill9>Apteryx_: have you modified your setuid programs list in your system config.scm?
<pkill9>i was poking around the source the other day and by default ping is given setuid bit
<Apteryx_>oh, I see.
<Apteryx_>Yes, I might have done that
<Apteryx_>But I do cons my addition to the usual %setuid-programs... hmm
<Apteryx_>by default do you mean in GuixSD or on other systems?
<Apteryx_>OK, I see in (gnu system) how %setuid-programs is defined. It does contain ping.
<Apteryx_>Could it be that I updated my inetutils package but haven't rebooted yet?
<pkill9>not sure, possibly
<Apteryx_>hmm. I can't seem to see some the hostname of an Ubuntu 16.04 machine I've installed 'avahi-daemon' on. Usually it should be visible through 'hostname.local' on the same network.
<Apteryx_>Ah, I think because I'm connected to a VPN on that machine, and somehow the hostname.local is bound to its IP on the VPN.
***runejuhl1 is now known as runejuhl
<rekado>pkill9: on x86_64 you can build i686 packages with “guix build --system=i686-linux …”.
<civodul>Hello Guix!
<janneke>hey civodul
<civodul>rekado: thanks for your blog post about PiGx!
<civodul>do you want me to do the CVS dance? :-)
<axd-v>Is there a gui client packaged for qemu? Does the qemu package also come with all of the stuff from kvm to make a vm for debian for example? I've never really used kvm because virtualbox was easily available and was familiar, but I gotta get used to better libre tools now.
<civodul>axd-v: i've never used it but perhaps virt-manager is such a GUI
<axd-v>civodul: I'm going to try that, thank you.
<rekado>civodul: I wanted to do the CVS dance earlier but ran out of time :-/
<ng0>hi
<pkill9>rekado: what i mean is, how do i put 32 bit inputs and 64 bit inputs in the same profile/evnironment, orin a package definition? something i'm looking at seems to want 32 bit libraries as well as 64 bit libraries
<roptat>hi guix!
<roptat>I'm not sure about what this sentence means: "guix gc --clear-failures removes store items from the set of cached failures"
<roptat>does it remove items from the store, or does it remove the "failed" flag from failed items?
<ng0>I still fail to see what's so special about some of my modules that they confuse (guix discovery) but others just work
<ng0>I'm going through guile
<ng0> + guix mailinglist archives today, maybe I get an inspiration
<civodul>roptat: it removes the "failed" flag
<civodul>but that's only if you're running "guix-daemon --cache-failures"
<civodul>which is not the default
<roptat>I'm translating the manual, that's why I was asking
<civodul>oh cool
<roptat>I'm at chapter 2.5
<civodul>woow
<roptat>(chapters 7 and 8 are also already translated)
<civodul>impressive
<jonsger>roptat: which language
<roptat>French
<civodul>i wanted to flatten the "GNU Distribution" chapter, basically remove one level
<civodul>well actually someone proposed to do that long ago
<civodul>but that never happened
<roptat>I would be in favor of that
<roptat>the chapter takes more than half of the manual
<ng0>aye
<atw>civodul: that sounds good to me. I've gotten used to the layout of the manual, but initially it was a little confusing. I think the manual could have 3 concerns: GuixSD-only, foreign distro-only, and common concerns
<roptat>isn't it already the case though?
<ng0>civodul: would you happen to know some deeper undocumented guix-specific guile debugging methods? I have to use GUIX_PACKAGE_PATH as a trampoline at the moment, and this one module folder is acting weird, with no weird code in it. used to work even. and (guix discovery) is confused even when the module folder is empty
<roptat>chapter 6 is for guixsd, chapter 2 is for foreign distros. others are common concerns
<ng0>basically still this: https://lists.gnu.org/archive/html/guix-devel/2018-05/msg00013.html
<atw>roptat: yes. I guess what I'm in favor of is for "installation" and "setting up the daemon" to be put under a common heading
<civodul>ng0: try loading the offending module by hand with "guile -l /.../foo.scm"
<civodul>atw: they're already next to each other, no?
<ng0>I went through all the modules yesterday in the directory with primitive-load, on their own they work.
<ng0>works -> the code has no syntax errors
<ng0>or visible ones.. I'll try what you suggested
<ng0>yep. same as yesterday, flawless loading
<ng0>but once I set th eGUIX_PACKAGE_PATH to the directory and want to guix packge --show=foo, I get the error shown
<ng0>oh.. why do we load (gnu packages) twice in gnu/packages/ncurses ? is this fixed in core updates? obviously it did no harm but it's unnecessary
<ng0>on the why: a commit I did in 2016 added it :/
<ng0>`git blame myself`
<atw>Eh, maybe they're less related than I thought
<ng0>hm. already found some new issues I introduced with all this debuggin -.- yet the module I use for testing now triggers the same behavior in guix discovery.
<ng0>and it has 1:1 the essential perl package fro mguix. I hope I'll fix it before summer :/
<roptat>civodul: what's a "live" derivation?
<civodul>roptat: it's a GC term: an item in the store is considered "live" if it is reachable from a "GC root", i.e., it's actually used somewhere
<civodul>otherwise it's considered "dead", meaning that it can be safely removed from the store
<roptat>so what does the --gc-keep-outputs option do?
<roptat>the manual says it removes any derivation output that's no a GC root
<roptat>so by default it removes live items?
<roptat>(chapter 2.5 if you're trying to find it)
<civodul>roptat: it changes the way the daemon determines whether a given item is dead
<civodul>by default, it's what i wrote above
<civodul>but if you say --gc-keep-outputs=yes, then it /gnu/store/foo.drv is live, /gnu/store/foo will be considered live as well
<civodul>does that make sense?
<roptat>kinda
<roptat>but how can a derivation be live?
<civodul>if you added it as a root, or you use --gc-keep-derivations=yes
<civodul>that was going to be your next question :-)
<roptat>hm… I think I understand, thanks :)
<roptat>so with --gc-keep-outputs=no no more output is considered live, bt the GC will still collect only dead items
<roptat>with --gc-keep-outputs=yes, more items are considered live, so the GC may collect less items
<roptat>because it only collects dead items
<roptat>now I need a good translation for "live"…
<bzp>hi all
<bzp>I get this message: http://pasteall.org/957397
<civodul>bzp: could it be that your disk or partition is full?
<bzp>several hours that I try to install and I can not :(
<bzp>I'm with a virtual machine with 80G
<roptat>bzp: what command did you try to run?
<bzp>guix system init /mnt/etc/config.scm /mnt
<civodul>did you run "herd start cow-store /mnt" before?
<bzp>this is my configuration:
<bzp> http://pasteall.org/957406
<roptat>and did you mount the partition?
<bzp>yes
<bzp>and did you mount the partition?
<bzp>herd start cow-store /mnt
<bzp>yes
<bzp>I'm sorry, I'm using a translator
<bzp>:D
<roptat>don't worry :)
<roptat>maybe /tmp gets full during the system init?
<bzp>How can I install in a virtual machine?
<bzp>my configuration is fine?
<roptat>it looks fine
<roptat>actually the UUID is a bit strange :)
<bzp>I want to install the base system with X and 'awesome' twm
<roptat>this part is fine, but the filesystem part looks weird
<roptat>did you create an encrypted partition?
<bzp>yes
<roptat>is its UUID really 12345678-1234-1234-1234-123456789abc?
<bzp>my disk partitions are: / (root 79G) and swap (1G)
<bzp>How do I check if 'UUID' is correct?
<roptat>your config file suggests "cryptsetup luksUUID"
<roptat>so "cryptsetup luksUUID /dev/sda1" should work (if that's where your / partition is)
<roptat>also, what does "df -h" report?
<bzp>What should I configure in 'config.scm', so that I install only the base system with X and awesome?
<bzp> http://pasteall.org/957418
<roptat>bzp: your configuration is fine for that
<roptat>now I wonder, why there is no /tmp
<roptat>oh you have two packages declarations. The first one will be ignored
<bzp>I followed these steps
<bzp> https://www.gnu.org/software/guix/manual/html_node/Proceeding-with-the-Installation.html#Proceeding-with-the-Installation
<ng0> /tmp is automatic if it is not defined as a mount-point. (didn't look at the configs)
<roptat>ng0: that's the installation media
<ng0>ok
<bzp>As I install correctly, please I want to have guixsd :)
<roptat>bzp: what does "mount" say? is /tmp mounted?
<roptat>otherwise try to run "mount /tmp"
<bzp> http://pasteall.org/957424
<bzp>How do I verify if it is mounted / tmp?
<roptat>run "mount" (no argument)
<bzp> http://pasteall.org/957426
<roptat>"/dev/mapper/my-partition on /tmp type ext4 (rw,relatime,data=ordered)" -> this is wrong
<roptat>try running "umount /tmp", then "mount" again to be sure
<bzp> http://pasteall.org/957427
<bzp>and if I install everything again?
<bzp>but they guide me please
<bzp>?
<roptat>try to run guix system init … again
<bzp>how do I do that?
<roptat>the same command that failed before
<roptat>guix system init /mnt/etc/config.scm /mnt
<bzp>ok
<bzp>guix system init /mnt/etc/config.scm /mnt
<bzp>guix system: error: build failed: writing to file: No space left on device
<bzp>:(
<bzp>download this option to install
<bzp> http://pasteall.org/pic/show.php?id=d3c9dc9e7823fa9485d1eb02ff312f8b
<bzp>i686
<roptat>yep that's the correct one
<roptat>how much RAM does your VM have?
<bzp>256 mb
<bzp>and video 32 mb
<bzp>imac, parallels virtual machines
<bzp>:|
<roptat>that's very low, can you try to increase that?
<roptat>2 GB will be more confortable when you try to guix pull
<bzp>first I want to test in a virtual machine then install in my pc
<bzp>assign more ram memory to the machine?
<pkill9>you need at minimum like 1Gb RAM, and preferably atleast 1.5Gb RAM
<bzp>ok
<bzp>I will configure and re-install guix
<pkill9>it is unfortunately quite memory greedy currently
<bzp>is installing the base system.
<bzp>I have questions: how do you install programs in guix?
<bzp>What is the guix philosophy is like emacs?
<bzp>How are the repositories updated?
<roptat>you update your repositories with "guix pull"
<roptat>then you use "guix package" to install packages in your profile
<roptat>or "guix system reconfigure" to update your system's profile
<bzp>can guix be used as a domestic server?
<roptat>yes, I have one running
<bzp>:D
<bzp>What tips and tricks do you recommend?
<roptat>none really
<roptat>some of us have their config online that you can read and get inspiration from
<roptat>but we don't have that much choice when it comes to installing a service on guixsd, so it's pretty straightforward
<bzp>in this part of the configuration I have, where do I get the UUID =?
<roptat>what do you mean?
<bzp>How would I configure, if my disk has 4 partitions ?: boot (sda1), root (sda2), swap (sda3) and home (sda4)
<roptat>is any partition encrypted?
<roptat>if you want to add partitions, you need to add them to the list of "file-systems" in your configuration
<bzp>to the previous question, in the 'encrypted' section UUID =
<bzp> http://pasteall.org/957482
<roptat>the UUID is the result of 'cryptsetup luksUUID /dev/<your encrypted partition>'
<bzp>"file-systems", do you have any configuration file as an example?
<roptat>if you have other encrypted partition, you need to add more mapped-device entries in the list
<roptat>have a look at http://89.234.186.109/config.scm
<roptat>there are two filesystems declared
<roptat>plus the base filesystems
<roptat>you may be starting to see a parttern with these (<field-name> (cons* <things> %base-<something>)) ;)
<bzp>yes :)
<bzp>you may be starting to see a parttern with these (<field-name> (cons*
<bzp> <things> %base-<something>))
<bzp>sorry
<bzp>What are the benefits of having it configured like this?
<bzp>of your configuration file?
<pkill9>as opposed to what?
<roptat>most field require a Scheme list. cons* is the easiest way to get a list (%base-<whatever> is a list)
<pkill9>does it extend the list?
<pkill9>e.g. with %base-whatever
<bzp> http://pasteall.org/957504
<roptat>cons* takes items and a list, and returns a list with these items and the items of the first list
<pkill9>i need to le4arn scheme, there's something i wanna do, i wanna create a package which consists of a bunch of other packages but all with an added argument
<roptat>bzp: that's a desktop configuration. My server has only one filesystem
<pkill9>so it doesn't take multiple lists, just one?
<roptat>just one
<pkill9>why just the one?
<roptat>if you want to make a list from multiple lists, you use append
<roptat>append returns a list that contains all the elements of the lists passed to it
<roptat>pkill9: because you may want to make lists of lists and then it's difficult to know if you pass an element or a list
<bzp>guix install precompiled packages? or compile and install them when downloading?
<pkill9>it installs precompiled if the build server has them
<pkill9>(or whatever build servers you ahve specified)
<pkill9>otherwise guix builds them for you
<roptat>civodul: chapter 2 done! phew
<ngz>Hello. I sometimes encounter the "module not found: PyQt5" when packaging applications, even though python-pyqt is among either inputs or propagated inputs. How could I debug the issue?
<ngz>roptat: You're writing documentation?
<roptat>ngz: translating it into French
<ngz>Ah. Nice.
<ngz>Is there a repository somewhere ?
<roptat>it's in the guix repository, but not with my work from today
<roptat>if you're interested in translating it in another language, you can go to https://translation-project.org where we put the pot file
<ngz>Ah, yes, I assume it's "guix.fr.texi"
<roptat>yes
<ngz>I don't know if you corrected it, but in "les résultats de la construction. C'est-à-dire", you forgot the second space between sentences.
<ngz>Also I think it should be @code{make} => @command{make} and @code{/dev} => @file{/dev}, ditto for @code{/proc}.
<roptat>is it required? it always feels weird to see two spaces
<ngz>Yes, in Texinfo, this is mandatory.
<roptat>it builds fine though
<ngz>But the spacing is probably wrong.
<roptat>for the commands I try to stick with the English version
<ngz>For example, M. Courtès has a single space, because "M." doesn't end a sentence. So it is shorter than a true end of sentence.
<roptat>ngz: I probably made the mistake more than once. Is there a simple way to find them?
<ngz>Probably a regexp search with \\. [^ ]
<bzp>how do you look for packages in guix?
<ngz>bzp: guix package -s REGEXP
<roptat>ngz: do you have an example of what a wrong spacing is?
<ngz>pour le système GNU. Guix facilite
<ngz>roptat: ^
<ngz>capital letter + period + space is not the end of a sentence in Texinfo.
<ngz>Here you probably need to write "pour le système GNU@."
<roptat>ok
<bzp>What is the minimum hardware requirement in the microprocessor for it to work properly?
<ngz>roptat: You can search for "[A-Z][.?!]( |$)" to catch those.
<roptat>thanks
<ngz>Actually, I re-read the Texinfo documentation. If you take care of these cases, you don't need to bother about two consecutive spaces.
<roptat>well I matched a lot of ENglish text that way
<ngz>You'll also need to put "@frenchspacing on" somewhere.
<roptat>ok
<ngz>Yes, people usually do not pay attention to this.
<ngz>See (info "(texinfo) Ending a Sentence") if you're interested
<civodul>roptat: congrats! :-)
<bzp>How do I install openssh in guix?
<bzp>and how do I raise the service or daemon?
<roptat>if you want the client, "guix package -i openssh" will make it available for your user
<roptat>if you want the server, add (service openssh-service-type (openssh-configuration)) to your services declaration and reconfigure
<roptat>you may have to run "guix pull" first to get the latest version
<bzp>ok
<roptat>ngz: what about "X.509" is it OK?
<bzp>finally I install well guix, thanks for the help :D
<roptat>bzp: you're welcome :)
<ngz>ngz: There is no whitespace involved in X.509 so it is fine.
<ngz>oups
<ngz>roptat: ^
<ngz>Talking to myself...
<roptat>:)
<roptat>ok
<roptat>ngz: how do you make sure info inserts an unbreakable space before a colon (so a line doesn't start with a colon)?
<roptat>do I need to put @tie{} everywhere or is there a magic commend like @frenchspacing?
<ngz>Good question. I think you simply add a space
<roptat>no, if I generate the html output and resize the window I can clearly see it doesn't work
<ngz>OK
<ngz>It does work here.
<ngz>Hmm nm it is a regular space.
<ngz>Then I see no other solution than @tie{}
<roptat>:/
<lyr3>Even though Ive installed Gentoo sucessfuly I feel like I am installing a distro for the first time with a non-gui installer. GuixSD give me hope that there is trustable distros!
<axd-v>Does anyone use virt-manager? I have installed that and qemu, but still get `QEMU/KVM not connected` when I launch it. `Unable to connect to libvirt qemu:///system \\ Verify that libvirtd daemon is running.`
<axd-v>Well I don't know anything about emulation with qemu/kvm, but due to a lack of options that what I'm trying to learn. It would make sense to me that such things should be taken care with dependancies. I do happen to have `libvirtd` in my path, so I launch it, it just sits quietly at the prompt since it's a daemon I guess, but that has no effect on virm-manager and it still complains with the same error.
<roptat>axd-v: are you using guix or guixsd?
<roptat>GuixSD has a libvirt service: https://www.gnu.org/software/guix/manual/html_node/Virtualization-Services.html#Virtualization-Services
<catonano`>axd-v: I signaled a bug regarding libvirt-manager. Your user should be in the wheel group, otherwise the connection can't be established.
<catonano`>axd-v: I don't remember if in the elp mailing list or in the dev mailing list
<catonano`>axd-v: also, the libvirtd service must be in your config
<catonano`>as roptat mentioned
<axd-v>roptat: I'm using guixsd. So I should add that to my (services '...)?
<axd-v>catonano`: I am part of wheel, so that's good, but didn't get that service set up, so it must be where I'm getting caught up.
<roptat>axd-v: exactly
<vagrantc>you can also configure which groups are allowed to use libvirtd, if you want a non-wheel user to be able to access libvirt
<vagrantc>we,, single group, i'm guessing
<vagrantc>well ...
<axd-v>roptat: catonano`: thank you for the help, my kernel is recompiling right now heh but in a couple of hours I should have a libvirtd daemon running......... yay. I love the idea of guix, but damn these type of situation are such a meme.. having to wait for a bunch of components to recompile everytime I try to make a tiny change just because the package definition got updated somewhat or something? It's not even a new kernel, same version
<axd-v>and everything. I'm using my own kernel definition so I can see if that's the case or not.
<catonano`>axd-v: good luck
<catonano`>axd-v: using a vanilla kernel would allow you to download a substitute
<axd-v>catonano`: well, I thought that even if you'd built from source (or --fallback) once the package is built once, it won't be rebuilt again.. since it's the same package. Does that not apply to custom package definitions?
<catonano`>axd-v: it does, as far as I understand
<pkill9>yea it does, however if you change anything that affects the output of the package it will rebuild it
<pkill9>axd-v: where/what did you change in your configuration or package definition?
<pkill9>if it was just the system configuration then it should reuse the built kernel
<soundtoxin>any sound experts here? sometimes mpd won't play music for me, it is stuck on paused. I notice if I kill pulseaudio and then try to play it again, it'll work, but then come out of the wrong speakers (internal laptop instead of usb soundcard)
<soundtoxin>playing videos in mpv, I normally get sound out of the right device, but then mpd won't play. after mpd restart pulse, I get an error trying to view pavucontrol
<soundtoxin>if I kill and restart pulseaudio again without using mpd I can see pavucontrol, but then I noticed I don't see my usb soundcard in there
<soundtoxin>I've gotten sound out of my headphones plugged into the usb soundcard, though, in face if I play a video I had open in mpv before messing with all this, it still comes out of my headphones
<soundtoxin>s/face/fact
<axd-v>pkill9: the only thing I really touched was adding a qutebrowser definition after copying it from guix git repo, in order to see how hard it would be to update it to a version that's at least from 2018. However I only got about as far as carbon copying the recipe in there, and then when I later went to system reconfigure, I was obviously met with some error. Then I went to delete anything related to qutebrowser and my config worked for
<axd-v>reconfigure again. As far as I'm aware the qutebrowser recipe didn't really affect the kernel in any way. Second possible thing is that after building my inherited-from-linux-libre custom kernel for the first time, I have ran the `guix pull` command and the libre-linux recipe has slightly changed to more updated libraries or something to that effect, which marked my custom kernel package as needing a rebuild, even though it is the same
<axd-v>linux kernel?
<pkill9>i would say it's likely that the linux-libre kernel got updated and your package definition is inheriting the new one, and thus rebuilding it like you say
<pkill9>if you can find the old guix in you /gnu/store, you could revert to it
<lyr3>soundtoxin: That happens too on Debian
<lyr3>I usually kill and restart pulseaudio to fix that
<pkill9>axd-v: as root, run `readlink ~/.config/guix/latest`, then run `find /gnu/store -maxdepth 1 -type d -name '*-guix-?????????'` and replace the symlink in your root's '~/.config/guix/latest' with one of the others
<axd-v>pkill9: interesting, so it's possible to manually use different versions (commits) of guix, in order to build a system that would be updated up to the date of the guix commit? Kind of like having multiple apt/pacman/dnf (repo?) versions each corresponding to a specific date and therefore letting you build a system that would be the latest at a specific point of time in the past?
<pkill9>yeah axd-v
<pkill9>hopefully it will be implemented in the `guix pull` command at some point, Nix has the ability to roll back the package definitions in it's `nix-channel` command, which is the equivalent of Guix's `guix pull` command
<axd-v>pkill9: very nice, I'm gonna let the kernel finish compiling this time, but this is great to know for the future. Is that in effect making a new "generation"?
<pkill9>you mean when you run `guix pull`?
<axd-v>pkill9: here is where my lack of understanding comes out. So guix creates system-wide and user-specific generations that act like snapshots of installed packages and configuration at a specific point of time. It is then possible to move between these generations to quickly change what packages are "installed". If I run `guix pull` this pulls in new guix version which has the latest recipe definitions coupled with it, because each
<axd-v>version of guix is also the version of the "package database" you have exposed to you. If it builds successfully then the user's guix_profile pointer for a specific generation that they are running gets updated to point to the new guix version and then it's possible to let the new guix update the already installed packages as per the new recipes? Here is where I don't really understand who is managing the updating of guix itself. Does
<axd-v>the old guix just replace the reference to itself with the new one in the path? I guess that would make sense since each user has their own guix version, but I'm not certain. Tell me if my summary is wrong.
<lyr3>Can I trust GuixSD as daily driver for C and Lisp development?
<bavier`>lyr3: I would say it is good
<thomassgn>awh, how do I split a segment/part/chunk when staging in magit?
<thomassgn>anyone remember?
<thomassgn>lyr3: I would.
<lyr3>bavier`: Anyways, I will give it a try, thanks!
<thomassgn>I don't work with either of those, but guixsd is my only OS on my only computer. (disregarding my server and dumbphone
<lyr3>EOMA68 + GuixSD + EXWM = Dream
<bavier`>lyr3: good luck, let us know if you have questions
<lyr3>o/
<bavier`>lyr3: we have some developers making sure guixsd will work for the EOMA68 cards
<davexunit>looks like I'll be able to install guixsd on my novena soon?
<davexunit>might need some sort of tutorial to figure out how to do it right.
<pkill9>axd-v: Preamble: the pointer to guix's package definitions is what gets overwritten (the pointer is in $HOME/.config/guix, called 'latest'), and guix is pretty much hardcoded to look in there for package definitions. The guix-profile is the result of building packages and putting them together into a profile, and guix uses this "package database" in the store path that ~/.config/guix/latest points to to build
<pkill9>the packages (and using substitutes if they're available).
<pkill9>the 'package database'/package definitions aren't the same as the guix-profile
<pkill9>so you have a per-user 'package database' (the recipes to build packages) *and* a per-user guix-profile (a collection of packages that have been built from the recipes, chosen by the user)
<lyr3>NixOS or GuixSD? I know its a delicated question, but I judge that you guys will honest enough
<lyr3>(nowadays)
<pkill9>Guix creates a new link to each guix-profile generation, which you can roll back to previous ones, but it doesn't do the same for the package database/package recipes, it just overwrites the pointer/link to the current package database
<pkill9>i dunno if that helps you understand
<pkill9>lyr3: i think it depends which one you prefer working with when writing your own package recipes
<vagrantc>davexunit: yeah, it basically works on the novena ... only gotcha is needing to copy u-boot.img to the first partition of the microSD card.
<pkill9>i prefer the language Guix's package definitions are written in (Guile) and the Guix package definitions that have already been written
<pkill9>also the command line interface for Guix I prefer
<pkill9>but Guix and Nix have a good relationship so it's all good :P
<lyr3>Guile is indeed a feature that wave me toward GuixSD
<davexunit>vagrantc: I haven't tried installing guixsd on any arm machine yet, so I'm not used to doing stuff with uboot.
<davexunit>but once that stuff is merged I'd like to try
<pkill9>another reason is Systemd, which many do not like :P
<pkill9>but many i guess also like it
<vagrantc>davexunit: it was merged :)
<soundtoxin>anyone know how I can change which browser opens from xdg-open? recently it switched from icecat to qutebrowser
<pkill9>though based on what little I know of it, I do not like it, but then i never used it's more advanced features, i'm not a sysadmin or anything
<vagrantc>davexunit: it isn't very fast, the substitutes tend to be a bit behind ... but it works :)
<vagrantc>davexunit: i haven't had success with video output, though ... or even tried much
<davexunit>vagrantc: okay
<davexunit>I think I'll hold off for a bit :)
<davexunit>thanks, though
<davexunit>this is really great work
<davexunit>it will give my novena new life when I finally get it running
<vagrantc>the LCD video support hasn't been pushed upstream, so unless someone takes initiative there, will likely never happen
<vagrantc>HDMI should work, in theory, maybe
<ngz>I sometimes encounter the "module not found: PyQt5" when packaging applications, even though python-pyqt is among either inputs or propagated inputs. Any pointer on how to debug the issue?
<thomassgn>I'm preparing to send six patches for haskell, but is best practice one patch per mail to guix-patches@gnu.org? Or should I send one mail with all of them - seeing as they are related package definitions/added variables?
<vagrantc>thomassgn: https://www.gnu.org/software/guix/manual/html_node/Submitting-Patches.html#Sending-a-Patch-Series-1
<vagrantc>admittedly, i've been getting away with sending a single mail with all the patches as attachments :)
<vagrantc>maybe the documentation could be a little more clear
<thomassgn>vagrantc: ofcourse the manual has a section about this. I've probably even read it some time... :P Thanks. Yea.
<vagrantc>i have all of 5 patches included in guix, so take what i say with a grain of salt
<thomassgn>done, and as far as I can tell according to best practice. Maybe :P
<rekado>pkill9: for a package definition you can use the #:system build system argument.
<rekado>pkill9: using such a package as an input to another package is no different from adding any other inputs.
<ngz>Hmm I never find any substitute for Lilypond, would it be hydra or berlin.
<rekado>ngz: this has been reported some time ago; there was a bug, but IIRC it has been fixed.
<ngz>But I'm building it right now
<ngz>So I guess it was not really fixed ;)
<thomassgn>debbugs is weird. I send a list of patches to the NNN@debbugs address, and I get back acks for creating X new bugs... Shouldn't it just add the patches to the first bug I got and used the NNN@debbugs adress from?
<rekado>thomassgn: no, that’s exactly how it should behave.
<rekado>thomassgn: our recommendation is to send a single cover letter
<civodul>ngz: the ungrafted lilypond has no substitutes either, AFAICS
<rekado>then wait for the confirmation and send the patches to the bug address.
<civodul>ngz: not that it really helps, but it suggests it's not the same bug :-)
<ngz>Ah, what a relief ! ;)
<civodul>heheh
<thomassgn>wait. I'm such a clutz. I know exactly why this happened. I had guix-patches@gnu.org as a to in the patches before I used 'git send-email -to NNN@debbugs.gnu.org <list of patches>' that was unnecessary.
<ngz>It is a very frustrating package to build, because it stops for long period of times, probably building documentation, so you cannot even look at some text scrolling in a terminal.
<thomassgn>Should I close the extra bugs it created? (and how would I do that?)
<rekado>ngz: yeah, it’s annoying :-(
<rekado>ngz: I wished this could be sped up. Maybe it will be faster once we can use Guile 2.x.
<thomassgn>rekado: that was what I was trying... :)
<thomassgn>with the patches
<rekado>ah!
<ngz>rekado: Lilypond using Guile 2.x. I don't think I will see this happen during my lifetime ;)
<rekado>ngz: it’s very slowly getting there.
<rekado>I think it can already be built with Guile 2 but it has a couple of serious bugs.
<ngz>I thought the effort had stalled somehow.
<rekado>yes, probably
<rekado>my info is a couple of months old already.
<axd-v>I was in here earlier trying to setup QEMU to emulate Debian in GuixSD. So at this point: 1. I've installed the `qemu` and `virt-manager` packages. 2. I've made sure my user is part of `wheel` group. 3. I have added libvirtd to services and can confirm that there is a process named `.libvirtd-real` running. Upon launch virt-manager I still get the message `Unable to connect to libvirt qemu:///system \\n Verify that libvirtd daemon is
<axd-v>running`. Well I feel like the daemon is running, so what now? I'm using the default config for the libvirtd daemon as shown in the manual. Anyone have any ideas?
<vagrantc>axd-v: when i was setting up libvirt, i had to reboot before it allowed me to connect
<vagrantc>axd-v: also, the example in the documentation includes some things not strictly necessary for libvirt
<vagrantc>the tls-port isn't needed, and that suggests to use the "libvirt" group rather than the wheel group
<axd-v>vagrantc: heh, well I was just trying to push and see what comes out so I just literally pasted that in. The unix-sock-group should be "wheel" instead of "libvirt"?
<axd-v>Another question: after a `system reconfigure`, at the very end, guix tells me: `Installing for i386-pc platform.` I'm running x86_64 without a question, 64 bit. Why would it tell me anything about i386?
<rekado>ACTION waits for CVS
<roptat>axd-v: that's a message from grub, it's ok
<axd-v>roptat: I see, thank you
<roptat>I'm not sure why, but I think it's compatible
<vagrantc>axd-v: the unix-sock-group should be whatever group you want to have access to libvirtd
<roptat>or it's the way it boots, using the i386-pc convention or something
<vagrantc>axd-v: but then your user needs to be in that group :)
<axd-v>vagrantc: I see, well at least this time I didn't recompile the kernel :)
<axd-v>roptat: interesting, well it works, so can't complain. Thanks for info.
<vagrantc>axd-v: grub architecture isn't really ...
<vagrantc>oh well
<axd-v>alright so I get a different error now
<rekado>ah, did I break the website?
<rekado>oh no, I did break the website.
<vagrantc>axd-v: let me guess, polkit related?
<axd-v>`authentication unavailable: no polkit agent available to authenticate action 'org.libvirt.unix.manage'`
<axd-v>vagrantc: we got a psychic in here :)
<vagrantc>axd-v: went through this before ...
<vagrantc>axd-v: what i don't remember is how i solved it
<axd-v>vagrantc: I'm not using a DE so that might complicate it.
<vagrantc>axd-v: yeah, i was using i3
<axd-v>vagrantc: did you query about it on here? There are logs that we could check.
<vagrantc>i may have...
<vagrantc>not sure if i just quietly figured it out, though ... don't have the system booted to check easily
<axd-v>vagrantc: I'm using exwm at the moment, but things should work similar to i3.
<axd-v>vagrantc: alright, I'm gonna look around for this error then, thank you for your help so far anyway, very useful.
<rekado>civodul: little help?
<rekado>all relative links are wrong now.
<rekado>e.g. the about link points to gnu.org/about/
<axd-v>vagrantc: is polkit like a service that needs to be added?
<rekado>ACTION rebuilds the website
<rekado>ACTION shakes fist at CVS
<axd-v>vagrantc: well polkitd is running so it's there already
<rekado>ACTION makes a new CVS commit
<rekado>the website is back to normal
<roptat>rekado: the last blog post is a 404