IRC channel logs

<axd-v>Hey, so if I want to replace slim dm with just manually running startx to execute my .xinitrc, how would I go about that? I use EXWM so in order to make things like changing and setting proper xkb layouts and startup items run like redshift and owncloud-client I need to have access to add things to my .xinitrc manually, or how else is it proper to make this work in guix? Maybe creating a herd service.. doesn redshift already have one

<axd-v>predefined for example? Usually these things would be in my .xinitrc or as a systemd service file.

<axd-v>Unrelated: qemu is failing to build on the latest guix commit with these messages:

<axd-v> https://paste.debian.net/1027523/

<pkill9>axd-v: there's an xorg-xinit package with the startx script

<lfam>Thanks axd-v, that's actually a failure of the QEMU dependency, gst-plugins-good. Taking a look...

<axd-v>lfam: thank you very much.

<lfam>axd-v: From the system where you got the failure, can you do `guix --version` for me? I can't reproduce the failure here

<lfam>Also, what CPU architecture are you using? Is it x86_64? And is it on GuixSD or another distro?

<axd-v>lfam: GuixSD, x86_64 (thinkpad x230), guix (GNU Guix) 555ab0853bdd5e226e60c3243f571ef9832c8ac9

<lfam>Heh, I am also using an x230 ;)

<axd-v>lfam: corebooted with libre wifi card?

<axd-v>I love this machine honestly. Been thinking a bit about doing a 1080p mod to the screen and then it would be even more perfect.

<lfam>And I'm at the same Guix version. I think the test failure may be non-deterministic. Can you try again with the '--keep-failed' option? That way, if it fails, we can see exactly which test failed and how and work around or disable the faulty test

<axd-v>I have the info on which test failed since it's only 1 out of 91

<lfam>No, mine is stock, running Debian with Guix. My screen is not very good, really. I've thought about upgrading the screen for better colors

<axd-v>well 92 total, 91 passed and 1 failed

<lfam>Right, if you still had the failed build directory we could read the test logs to figure out which one failed and what the failing result was

<axd-v>lfam: I see well I'm gonna recompile again right then with that flag, but the test that failed is named "elements/imagefreeze"

<lfam>We already identified and disabled some flaky tests in this package, so it's quite possible there are more

<lfam>Ah, thanks

<lfam>Let the chanel know the result, okay? (I might have to go before it's done)

<axd-v>lfam: got you, will do.

<axd-v>Earlier I asked about controlling the slim dm to not startup automatically on boot, does anyone know how to do that? Should I split apart the %desktop-services and leave slim out?

<lfam>Ah, like a `startx` workflow?

<lfam>axd-v ^

<axd-v>lfam: yeah, I'm just not used to using a graphical dm. With slim I would have to inherit the package and change its config in order to change what stuff gets brought up? How would I get slim to make redshift start at login and setxkbmap to run?

<axd-v>with startx workflow I just modify the .xinitrc bash script. Straight forward, but gotta get rid of slim first.

<lfam>I'm not sure. I think other people have discussed it though. I would search the archives of guix-devel and help-guix

<axd-v>haven't thought of that, will try.

<axd-v>lfam: also, once this qemu's dependency fails what should I provide the channel with?

<axd-v>lfam: you mean the mailing list for guix-devel and help-guix?

<lfam>I think it will succeed :) But if it fails, find the log of the failing test and share it using the Debian paste site

<lfam>Yes, the mailing lists

<axd-v>lfam: I don't know guix's build process very well, how would I go about finding the log of the failing test?

<lfam>axd-v: If you use the --keep-failed option, a failing build will tell you the name of the directory where the build took place

<lfam>And as you can see in your earlier paste, gst-plugins-good's build scripts tell you where to look for the build log from there

<lfam>Or rather, the log of the test suite

<axd-v>So I just ran `guix package --keep-failed -u` again, during which a test during compilation of qemu's dependency failed earlier, and nothing came up about qemu, but keepassx failed with this message: "https://paste.debian.net/1027530/"

<axd-v>I still have the build directory thanks to the flag, but I'm not sure where to find a relevant log about this particular failure.

<axd-v>I don't know why there is such undeterministic behavior at the moment, using the latest guix commit version, but I'm gonna rerun the command to see if it fails on something else this time.

<axd-v>Now `guix package -u` fails reliably on keepassx compilation with the same message as the one in the above pastebin link.

<axd-v>Trying to install `owncloud-client` and get the following errors. Two logs are included in the same paste further down: https://bin.disroot.org/?d27e228d7d3253f9#xEjqotx6iwNvfgyV36g+CJxAdOsuE/b4orMpcpwlyXg=

<soundtoxin>is there a way to list all games in the guix repos?

<buenouanq>~/.config/guix/latest/gnu/packages/games.scm exists

<buenouanq>but I'm not sure that's \\emph{all} of them

<buenouanq>$ guix package -s game

<buenouanq>will possibly over select though

<buenouanq>what are you actually trying to accomplish soundtoxin?

<soundtoxin>nothing

<soundtoxin>I've noticed some things that come to mind, suvh as openarena, are not packaged, so I jiust wanted to see what was there

<axd-v>So I have found a way to disable slim, just by excluding it from the %desktop-services list, but now startx fails to work. It complains that /gnu/store/*xinit-1.4.0/bin/X doesn't exist so it doesn't know which xorg to use.

<axd-v>The error message before the one I described above is actually about xauth and home there isn't some file in my home directory that's needed for it. Don't know what that's about, maybe it's the culprit since it's the first printed error.

<axd-v>Xauth complained about $HOME/.serverauth.1436 file being missing.

<marusich>axd-v, you might also be interested in this blog post: https://www.gnu.org/software/guix/blog/2018/customize-guixsd-use-stock-ssh-agent-everywhere/

<marusich>It discusses using ~/.xsession. You might find the parts related to that to be interesting.

<axd-v>marusich: oh wow, that's extremely relevant. Now I'm kicking myself for not being thorough enough. Thank you.

<civodul>Hello Guix!

<rekado_>axd-v: here’s my .xsession: https://elephly.net/downies/.xsession

<rekado_>axd-v: and here’s my config.scm: https://elephly.net/downies/config.scm

<marusich>Hi civodul! I think I fixed the tests/pack.scm problem. I'm going to go to sleep, but I sent you (and the bug report) an email about it.

<marusich>See you later!

<civodul>cool

<civodul>hpcguix-web's in the house!

<cbaines>Morning all :)

<cbaines>Is anyone able to interpret this? execve("/bin/sh", ["sh", "-c", "exec /bin/sh -s unix:cmd"], 0x607a10 /* 29 vars */) = -1 ENOENT (No such file or directory)

<efraim>civodul: vagrantc says they installed guixsd on an overdrive1000 with just straight grub-efi-bootloader

<cbaines>I've hit https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29655 (Elixir build has an undeterministic build error), when looking at the RabbitMQ package, as it depends on Elixir

<efraim>is it looking for '/bin/sh' once or twice?

<civodul>efraim: woow! if only the overdrive would resuscitate (that happens these days...), we could do that

<civodul>i think we need a status report for GuixSD on ARM

<civodul>vagrantc, dannym, and you have been doing lots of crazy things!

<civodul>heya cbaines!

<civodul>cbaines: /bin/sh doesn't exist i suppose

<cbaines>this is during building the Elixir package, is /bin/sh meant to exist in the build environment?

<civodul>no it doesn't exist in the build environment

<civodul>so usually programming languages that have functions similar to 'system' in C are patched to refer to the absolute file name of 'sh' instead of '/bin/sh'

<civodul>see for example gawk and Guile

<cbaines>ok, I'll have a look at doing that. I wonder how it's sometimes building if theres an issue like this...

<civodul>indeed

<civodul>it could be that the error is sometimes swallowed, or the test is sometimes skipped

<civodul>which isn't any less weird :-)

<rekado_>other people now also report that qtbase does not build for them.

<rekado_>it builds fine on my laptop, but not on bigger servers.

<civodul>parallel build issue?

<civodul>yesterday you reported that a .so would not be found

<civodul>it could be a parallel build issue: the .so may or may not be built at that point

<rekado_>right, that’s what I assumed, but haven’t been able to verify yet.

<civodul>the internet doesn't have much to say about this failure :-/

<rekado_>ACTION builds qtbase with #:parallel-build? #f

<jonsger>efraim: could you have a look at https://build.opensuse.org/request/show/612682

<platoxia>so...I just watched the Fosdem 2017 talk and I just have to ask...on GuixSD what are the alternatives to guix pull for updating the system?

<rekado_>same problem when building with #:parallel-build? #f :(

<civodul>platoxia: there's no alternative, apart from updating your own checkout and running 'make'

<civodul>why do you ask?

<civodul>rekado_: with the same qvkgen binary?

<civodul>could you run "readelf -a /tmp/guix-build-qtbase-5.11.0.drv-0/qtbase-everywhere-src-5.11.0/bin/qvkgen | grep RUNPATH"?

<civodul>Rust takes *ages* to build and it's sequential

<efraim>Yeah, it was about 12 hours for each one on aarch64

<rekado_>ldd shows me that libQt5Core.so.5 is not found.

<rekado_>readelf shows me that this is the RUNPATH: $ORIGIN/../lib:/gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/lib:/gnu/store/vla5j7pbkpcp39lsdfsmz7m9azn48lr4-gcc-5.5.0-lib/lib:/gnu/store/vla5j7pbkpcp39lsdfsmz7m9azn48lr4-gcc-5.5.0-lib/lib/gcc/x86_64-unknown-linux-gnu/5.5.0/../../..

<rekado_>$ORIGIN/../lib

<rekado_>/tmp/guix-build-qtbase-5.11.0.drv-0/qtbase-everywhere-src-5.11.0/lib/libQt5Core.5 exists

<rekado_>does $ORIGIN mean relative to this binary, so this would become “bin/../lib”?

<rekado_>there is a point in the build where this happens, though:

<rekado_>rm -f ../../lib/libQt5DBus.so

<rekado_>for each of the libraries

<rekado_>and after that the libraries are moved again to that same location

<efraim>Didn't trust people to run 'make clean' before building?

<rekado_>the binary is spawned by /tmp/guix-build-qtbase-5.11.0.drv-0/qtbase-everywhere-src-5.11.0/src/gui/qvkgen_wrapper.sh

<rekado_>which sets LD_LIBRARY_PATH first

<rekado_>LD_LIBRARY_PATH=/tmp/guix-build-qtbase-5.11.0.drv-0/qtbase-everywhere-src-5.11.0/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}

<rekado_>it also sets QT_PLUGIN_PATH

<rekado_>when I run that wrapper I get the same error.

<rekado_>I don’t understand this because LD_LIBRARY_PATH is set by the wrapper, and the directory does contain the link to the library (in the same directory).

<rekado_>libQt5Core.so.5 -> libQt5Core.so.5.11.0

<rekado_>when I do LD_PRELOAD=/path/to/libQt5Core.so.5.11.0 I get this:

<rekado_>ERROR: ld.so: object '/tmp/guix-build-qtbase-5.11.0.drv-0/qtbase-everywhere-src-5.11.0/lib/libQt5Core.so.5.11.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

<rekado_>“cannot open shared object file”? That’s not okay

<rekado_>this works though: /gnu/store/l4lr0f5cjd0nbsaaf8b5dmcw1a1yypr3-glibc-2.27/lib/ld-linux-x86-64.so.2 /tmp/guix-build-qtbase-5.11.0.drv-0/qtbase-everywhere-src-5.11.0/lib/libQt5Core.so.5.11.0

<rekado_>strace shows me that the libQt5Core.so.5 link is opened, the target ELF is read, then closed, and the search for the file continues.

<rekado_>it’s possible that this is a kernel problem

<rekado_>I read that Qt 5.10 uses renameat2, which is only available since Linux 3.15

<rekado_>this would explain why it builds fine on my Fedora workstation (4.16.9-300.fc28.x86_64) and on GuixSD, but not on CentOS 7 with 3.10.

<rekado_>so…

<rekado_>can we patch Qt?

<rekado_>See https://github.com/qt/qtbase/blob/fd9dd8e95b7563a439b1672fa622729bdcb6f4fc/src/corelib/global/minimum-linux_p.h

<rekado_>- renameat2 3.16 QT_CONFIG(renameat2)

<rekado_>- getrandom 3.17 QT_CONFIG(getentropy)

<rekado_>so, we could disable these with configure flags, I suppose.

<rekado_>disabling these two would mean a minimum version of 2.6.28

<rekado_>building with "-no-feature-getentropy" and "-no-feature-renameat2" now.

<efraim>Getentropy sounds like it could be important, any real downsides to disabling them?

<rekado_>I don’t know.

<rekado_>It loads different headers in that case: https://github.com/qt/qtbase/blob/1ef03f69e8416a70efd14df09e1231ce0bc00ea9/src/corelib/global/qrandom.cpp#L51

<rekado_>if getentropy is disabled it will use qhashfunctions and qdeadlinetimer instead of sys/random.h

<rekado_>In any case they are using qrandom.h and qrandom_p.h, which use <random>

<rekado_>It finished building.

<rekado_>I’ll send the short patch in for review.

<efraim>hmm, I probably shouldn't enable the svga in mesa on aarch64 on core-updates

<efraim>~1000 packages affected

<jonsger>rekado_: Debian Jessie also only have 3.16 kernel and Ubuntu 14.04 has even only 3.13...

<rekado_>efraim: core-updates-next is open

<efraim>rekado_: thanks, i'll see how well it builds first :)

<civodul>rekado_: with commit 5d669883ecc104403c5d3ba7d172e9c02234577c 'guix pull --branch=core-updates' should now work

<IntoxicatedHippo>hello guix

<IntoxicatedHippo>Is there a way to add a second package patk for all users?

<IntoxicatedHippo>s/patk/path

<civodul>i suppose you could extend session-environment

<civodul>though maybe that'd lead you to override PATH entirely

<rekado_>IntoxicatedHippo: is GUIX_PACKAGE_PATH useful?

<rekado_>(I’m not sure I understand the question.)

<rekado_>civodul: thanks! I’ll give it a try on the other laptop tonight.

<IntoxicatedHippo>rekado_: that's what I'm currently doing, I was just wondering if there's another way

<rekado_>do you have problems with GUIX_PACKAGE_PATH?

<IntoxicatedHippo>No, but I'm sure I will eventually when I run stuff that doesn't check environmental variables

<civodul>ACTION probably misunderstood the question

<efraim>can I have GUIX_PACKAGE_PATH=/path/to/repo1:/path/to/repo2 ?

<efraim>randomly checked, in my env I have: MANPATH=/run/current-system/profile/share/man:/home/efraim/.guix-profile/share/man:/run/current-system/profile/share/man

<efraim>probably don't need current-system twice

<civodul>efraim: re GUIX_PACKAGE_PATH, yes you can

<pkill9>how do i use multiple source in a package definition? and how do I refer to them in build phases?

<pkill9>sources*

<rekado_>pkill9: you’d add “origin” expressions to native-inputs.

<rekado_>and then refer to them in build phases via (assoc-ref inputs "whatever")

<pkill9>ah

<bzp>hello

<cbaines>bzp, hey :)

<cbaines>I think I've got this Elixir issue nearly wrapped up! The /bin/sh patches turned out to be needed in the erlang package, all that changes with the elixir package is just removing all the deletion of tests :D

<civodul>cbaines: sounds like a good outcome :-)

<civodul>reepca: i'm happy to say that i finally merged part of your code!

<nee`>cbaines: That sounds great! Congrats to figuring it out.

<cbaines>nee`, this should resolve https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29655

<cbaines>I encountered that yesterday, very confusing

<cbaines>I think there is a race condition, as there is some error handling where the compilation fails

<cbaines>it failed very reproducibly on a single core machine

<cbaines>patches are up here now, if you're interested in taking a look https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31678

<nee`>Thanks, I tried to figure it out myself initialy, but couldn't wrap my head around it. Glad to see it get resolved.

<nee`>Is there a `guix system --remove-generations` command?

<rekado_>I’m going to upgrade R from 3.4.4 to 3.5.0, but this breaks the tests as we don’t build R with the recommended packages.

<rekado_>In order to be able to run the test suite I’ll build r-with-tests, which *does* build the recommended packages.

<rekado_>r-minimal then inherits from r-with-tests, disables the tests and disables the recommended packages.

<rekado_>this isn’t great, but I think it’s slightly better than disabling all those tests that fail when the recommended packages are not there.

<civodul>yeah, no better idea

<rekado_>It’s not easy to fix this because we want to use r-minimal to build the recommended packages, but we can only build r-minimal with the tests once we have built all the recommended packages.

<rekado_>I’ll be monitoring the r-with-tests package to make sure future updates won’t break R.

<rekado_>(r-with-tests does not build reproducibly.)

<rekado_>when the next release candidate is prepared I’ll try again to run the tests without the recommended packages.

<civodul>so, what is the Mastodon, GNU Social or similar instance that people would recommend?

<civodul>i hear they have different policies in terms of code of conduct and things like that

<rekado_>ACTION does not know

<Rukako>my friend uses gnu social, I will ask him once he gets online

<rekado_>“guix package” does not support “--system” — should it?

<rekado_>I can do “guix build --system=i686-linux perl” and install the output, but using “guix package” for this would be nicer.

<civodul>rekado_: yeah it's been discussed some time ago, that's feasible

<rekado_>ok

<jonsger>ACTION recommends diaspora* :)

<pkill9>diaspora is nice

<pkill9>Hubzilla is based on an interesting protocol, but the interface itself is not very nice

<pkill9>a bit glitchy

<uniq10>Hi guix.

<g_bor[m]>Hello guix!

<g_bor[m]>uniq10: hello

<g_bor[m]>uniq10: I've just looked around you github repo. It seems that it was not updated recently. Have the work on the daemon been moved somwhere else?

<g_bor[m]>janneke: where can I find the patches that are used on tcc currently to make it compile using mescc?

<civodul>rekado_: congrats on the qtbase fix!

<civodul>and thank you

<uniq10>g_bor: I haven't pushed the changes since some things are broken. I have sent an update mail on the mailing list.

<rekado_>I used to run a Diaspora server for my family

<rekado_>but maintenance took up a lot of time.

<jonsger>I run still a pod and I wouldn't say it's much maintenance effort...

<rekado_>in the early days there were lots of breaking changes.

<rekado_>regular database migrations that might end up breaking things and often we ended up disconnected from the rest of the network.

<rekado_>but that was years ago.

<rekado_>I’m sure it’s better now.

<jonsger>yes, they improved their code and release quality a lot :)

<Copenhagen_Bram>Hi! What's guixSD like?

<rekado_>Copenhagen_Bram: hi!

<rekado_>it’s great fun, very stable

<Copenhagen_Bram>Hi rekado_

<Copenhagen_Bram>It's stable?? I thought it was experimental

<rekado_>you get the features of Guix (roll-backs, reproducibility, descriptive environments) but at the operating system level.

<rekado_>it can be experimental *and* stable ;)

<Copenhagen_Bram>Hmm.

<Copenhagen_Bram>I'm starting to think of GuixSD as the Gentoo of the FSF world

<rekado_>Guix doesn’t have packages for everything, so it may not be suitable for all use cases.

<rekado_>GuixSD is not an FSF project. It’s part of GNU, though.

<Copenhagen_Bram>At least it has gzdoom

<rekado_>in my opinion, GuixSD is more reliable than Gentoo, because you can always roll back to previous generations of your system.

<rekado_>no more broken system upgrades.

<Copenhagen_Bram>Hmm. I thought portage could downgrade individual files.

<Copenhagen_Bram>Hmm. I thought portage could downgrade individual packages*.

<Copenhagen_Bram>So what packages are missing? Is KDE still missing?

<rekado_>GuixSD is stateless

<rekado_>it’s not a matter of downgrading individual packages in a stateful manner.

<Copenhagen_Bram>stateless?

<Copenhagen_Bram>hmm

<rekado_>every time you boot a system it is “checked out” from /gnu/store; /etc is populated, user accounts are created, and so on.

<Copenhagen_Bram>whoah

<rekado_>if you modify files in /etc by hand these changes will be lost upon reboot.

<Copenhagen_Bram>That's different.

<rekado_>you configure the state of the system with a single configuration file.

<rekado_>and then you “instantiate” the system from that description.

<Copenhagen_Bram>What about files in /home/?

<rekado_>they are not touched.

<Copenhagen_Bram>Does guix do the checking out?

<rekado_>(that’s something where the beta label shows, because things like $HOME/.cache might grow stale)

<Copenhagen_Bram>Does guix work differently on GuixSD than on another distro?

<rekado_>it benefits from better integration.

<rekado_>on other distros you need to set up a few environment variables manually.

<Copenhagen_Bram>Ah.

<rekado_>on other distros Guix does not provide setuid binaries.

<rekado_>(On GuixSD the configuration file has a whitelist of setuid binaries)

<rekado_>but other than that there are not many differences.

<rekado_>Guix on any system can generate virtual machines of GuixSD

<rekado_>or it can generate application bundles (“containers”) in various formats.

<rekado_>about checking out the system: Guix installs an entry in GRUB for each system generation.

<rekado_>From GRUB you then boot a particular system using that particular generation’s kernel and custom initrd.

<rekado_>(and system application profile)

<rekado_>ACTION updates to bioconductor 3.7

<Copenhagen_Bram>Oh wow guix even has cataclysm DDA

<Copenhagen_Bram>How long does it take to install guixSD?

<rekado_>Copenhagen_Bram: that depends on your configuration and on availability of binaries.

<rekado_>we recommend installing a minimal system first to reduce the initial setup time.

<rekado_>once you *have* your initial system you can conveniently reconfigure it and benefit from roll-backs.

<rekado_>installing a big system (with desktop environment and so on) right from the start may take a long time and end with errors that you’d have to fix in the uncomfortable environment of the primitive installer system.

<rekado_>civodul: I wanted to merge master into core-updates, but the changes to the tests are not obvious to me.

<Copenhagen_Bram>Oh. So how is GuixSD installation different to an Arch/Parabola installation?

<civodul>rekado_: the changes to tests/pack.scm?

<rekado_>it’s different in that we don’t have a usable installer that would guide you through the steps.

<rekado_>civodul: I think so.

<rekado_>CONFLICT (content): Merge conflict in tests/pack.scm

<rekado_>CONFLICT (content): Merge conflict in guix/gexp.scm

<civodul>oh?

<civodul>i can do the merge if you want

<rekado_>maybe I just did something wrong.

<rekado_>if it’s easy for you, please do it.

<civodul>i'm surprised there are conflicts, but who knows

<civodul>sur

<civodul>*sure

<Copenhagen_Bram>Are you guys improving guix packages?

<rekado_>Copenhagen_Bram: another thing that’s different is that the installation requires you to write a configuration file that describes your system.

<rekado_>many people here improve Guix packages, or add them, or add more features to the package manager itself.

<rekado_>Copenhagen_Bram: the installer live system comes with a copy of the manual, though, so you are not on your own.

<rekado_>you can follow the manual step by step and finally get to your first GuixSD installation.

<Copenhagen_Bram>Alright. You know, Arch/parabola doesn't have an install either, unless you call pacstrap /mnt base an installer

<Copenhagen_Bram>Do you have to compile the kernel or anything?

<rekado_>I remember that my first installation of Arch involved a print-out of some wiki pages ;)

<pkill9>the python{2}-dbus package doesn't contain 'dbus/mainloop/qt.py' in the site-packages, any ideas how to get this?

<rekado_>Copenhagen_Bram: you don’t need to compile the kernel, unless there happen to be no binaries for the particular version you want to install at this moment.

<civodul>Copenhagen_Bram: https://www.gnu.org/software/guix/manual/html_node/System-Installation.html should give you a feel of what it's like to install GuixSD

<pkill9>i'm tryign to get qpaeq (part of pulseaudio) to work

<pkill9>which is an equalizer for pulseaudio, it's in the pulseaudio package but doesn't work atm

<Copenhagen_Bram>Do you have to be good at scheme to add or update guix packages?

<pkill9>also it still has an unpatched shebang

<civodul>pkill9: it may be that we build python-dbus without Qt support, dunno

<vagrantcish>Copenhagen_Bram: they've merged a handful of my patches into guix, and i barely know scheme at all.

<Copenhagen_Bram>Hmm.

<Copenhagen_Bram>Good, maybe I can contribute to guix and not feel guilty for being a leech

<pkill9>i often copy parts of package definitions

<civodul>someone who contributes should definitely not feel guilty :-)

<Copenhagen_Bram>Do you have to install GuixSD with a live GuixSD or can you do it fairly easily from any other live distro?

<vagrantcish>Copenhagen_Bram: there is also the option of installing guix on top of some other distro, if you want to get just familiar with using guix before diving in

<Copenhagen_Bram>yeh I'm using parabola and i have guix installed

<rekado_>Copenhagen_Bram: to install GuixSD I strongly recommend using the installer.

<rekado_>Copenhagen_Bram: there is an alternative route, but you need to understand your system well and be able to know some recovery procedures.

<vagrantcish>rekado_: that's the main feature in the installer than makes it any different from just installing from guix on a foreign distro?

<rekado_>not recommended for new GuixSD users.

<pkill9>civodul: from my small amount of research, i think it's PyQt4 that's supposed to provide site-packages/dbus/mainloop/qt.py

<vagrantcish>rekado_: er, what is the main feature...

<pkill9>it says in one of the docs of the python-dbus source "PyQt v4.2 and later includes support for integrating dbus-python with the Qt event loop."

<rekado_>when you replace an existing system you need to be careful about existing files in /etc that GuixSD would want to replace on boot.

<vagrantcish>ACTION has walked through a handful of installs from a foreign distro due to arm* not having an installer yet

<vagrantcish>rekado_: ah, sure, installing directly onto the same system, yeah.

<pkill9>has anyone compared GuixSD with Gentoo?

<rekado_>using the installer image just doesn’t require that much awareness of how things could go wrong.

<rekado_>pkill9: yes, higher up in this conversation :)

<pkill9>ah :)

<Copenhagen_Bram>pkill9: I think GuixSD is like the Gentoo of the FSF-approved world

<pkill9>I thought Gentoo was pretty much FSF-compliant?

<vagrantcish>not quite as likely to have to compile everything with GuixSD unless you want to.

<pkill9>yeah that's what put me off gentoo

<rekado_>frankly, I think it’s nothing like Gentoo.

<civodul>yeah, transactional upgrades and rollback, etc.

<Copenhagen_Bram>pkill9: Well, it *can* be if you make it FSF compiant. Except I bet their minimal live distribution uses Linux with blobs, and I know for a fact because I tried it, the full livedvd gentoo thing uses Linux and Firefox.

<pkill9>oh yeah

<Copenhagen_Bram>And I looked up iceweasel in emerge and got nothing.

<pkill9>i forgot about Linux, lol

<rekado_>even when it comes to compiling from source: you *can* build everything from source with Guix and sometimes you need to let Guix build things for you locally, but the experience really is quite different.

<rekado_>FWIW we also don’t have iceweasel in Guix ;)

<rekado_>(we’ve got icecat)

<vagrantcish>meow

<Copenhagen_Bram>What about abrowser? lol

<Copenhagen_Bram>I read that you didn't have KDE yet, but I did some searching and it looks like you have plenty of KDE stuff now.

<rekado_>correct.

<rekado_>I believe we are still a few libraries short.

<Copenhagen_Bram>So, do I have to use `guix build` to compile a package?

<pkill9>is icecat gonna upgrade to use firefox quantum?

<Copenhagen_Bram>pkill9: Who knows. Schroedinger's Icecat

<rekado_>Guix will automatically compile a package if a) you haven’t authorized a build farm, or b) disabled binary substitutes, or c) the build farm doesn’t have a binary.

<rekado_>“guix build” is one way to make a package appear in /gnu/store without linking it to any profile.

<Copenhagen_Bram>Is a build farm like when I made a bunch of guix users to do build jobs?

<rekado_>but it doesn’t cause the package to be built from source, unless the conditions above are true.

<pkill9>lol

<Copenhagen_Bram>Hmm

<pkill9>you're thinking of a soulless corporation Copenhagen_Bram

<rekado_>it’s not far off. We have a number of servers that all act like programmed guix users, if you will.

<rekado_>These servers fetch the latest Guix version and then build all packages that haven’t been built yet.

<Copenhagen_Bram>hmm

<rekado_>They share the result over HTTP

<uniq10>Hi, I have having a little trouble in designing the scheduler/worker for building derivations. The C++ code maintains a lot of state and state updates and I end up passing all of it around. I don't know if that is a good approach. What style would be more appropriate while doing it in scheme?

<rekado_>Copenhagen_Bram: they are not privileged in any way and follow the same process that real users would follow.

<uniq10>* I am having

<rekado_>Copenhagen_Bram: in fact, real users can also share their binaries with “guix publish”.

<Copenhagen_Bram>Hmm.

<rekado_>uniq10: what kind of state?

<rekado_>uniq10: sometimes the most appropriate thing is to use a monad (e.g. the state monad for serializing actions that operate on complex state).

<rekado_>sometimes it is fine to pass around an alist.

<rekado_>yet other circumstances may be best represented with a fold that accumulates state as a composite object.

<rekado_>uniq10: can you describe what the state that needs to be captured looks like?

<rekado_>Copenhagen_Bram: we currently have two build farms. One is the distributed hydra.gnu.org (and a caching mirror at mirror.hydra.gnu.org). The other is a more centralized cluster of 20+ servers at the institute where I roam the corridors during the day.

<Copenhagen_Bram>Ah alright

<uniq10>rekado_: For example when a set of derivations is given to the daemon to build, if the inputs to those derivations are not present they need to be built too. To proceed with the target derivation build I need to keep track of the input derivation build status.

<rekado_>uniq10: can this be determined before the build starts?

<rekado_>I’m imagining a procedure that takes a single derivation (or a set of derivations) and returns all derivations it depends on that haven’t been built yet.

<rekado_>(I think something like this already exists.)

<rekado_>uniq10: we have “derivation-prerequisites-to-build” — does this help at all?

<uniq10>rekado_: Yes we know that before the build starts, but in the C++ code the builders of an input derivation (of a target) check if any of the other input derivations (of the same target) failed and if so they terminate immediately. How will I be able to do this?

<rekado_>(I don’t know)

<rekado_>you can pass around a lookup table of derivations to results

<rekado_>then before attempting to build a derivation you would look up if all of the input derivations have successfully been built.

<rekado_>I don’t know if it would be okay to implement this recursively, but if it is, you could then recurse on all derivations that have not been built yet.

<rekado_>for keeping track of failed derivations you could even use memoization

<rekado_>(we do something like that in the recursive cran importer to avoid importing already imported packages)

<civodul>interesting read for those of us who had a Nix life before: https://gist.github.com/edolstra/29ce9d8ea399b703a7023073b0dbc00d

<civodul>Eelco covered some of these at the pre-FOSDEM workshop

<civodul>i see convergence :-)

<alyssa-->thank you to those who worked on ARM support for GuixSD !

<ngz>bavier`: ping?

<rekado_>civodul: the “package” example looks familiar.

<rekado_>(they would still have fewer parentheses / curly braces, but it’s getting closer :))

<civodul>well it would double the number of braces, so... :-)

<civodul>(i've pushed the master -> core-updates merge)

<rekado_>a step in the right direction :) In the next iteration they could replace the braces with smooth parentheses, and another iteration to distribute them across the package definition…

<rekado_>thanks for the merge!

IRC channel logs

2018-06-01.log