<vagrantc>if a package update requires new inputs, should i file separate bugs for those inputs, or just submit patches for each new input as part of a bug updating a package? <ArneBab>civodul: did my patches for ffmpeg with AV1 and for emacs-xwidgets reach youp <ArneBab>rekado: yes, but I didn’t receive the replies <ArneBab>I did find substitute-keyword-argument myself, but I don’t know how I missed the replies <ArneBab>the most recent version now works for both ffmpeg with AV1 and mplayer (without, since it uses ffmpeg-3.4) <reepca>civodul: regarding warn-about-old-distro, it uses %profile-directory instead of config-directory. %profile-directory only uses $USER and $LOGNAME. Perhaps it should be using config-directory instead? <civodul>config-directory wouldn't work since it's not in ~/.config <civodul>but yeah, it could check for SUDO_USER or similar <civodul>would you like to take a stab at it? <OriansJ>what do you mean? It is a public paste bin that anyone can paste to <OriansJ>dongcarl: the number of guixbuilders is relative to your number of CPU cores if you wish to optimize your build times <OriansJ>then fell free to up the numbers to 2 x #cores <reepca>In general, is the overall goal of warn-about-old-distro to warn about the age of the current user's profile's guix, or of the currently-running guix? <dongcarl>OriansJ: seems like the symlink should point to /var/guix/profiles/per-user/root/current-guix/bin/guix instead <OriansJ>dongcarl: if you do ls -hal ~/.guix-profile you'll see why I selected guix-profile over current-guix <dongcarl>Hmmm... Right guix-profile exists for my user but it doesn't for root? <OriansJ>dongcarl: possibly I need to update my script <dongcarl>OriansJ: it indeed is building everything from source! <dongcarl>makes good use of my new 48 thread workstation haha <dongcarl>Question for people here, I know that reproducible builds is a goal for guix and it has largely achieved it... Is cross-distro reproducible builds a goal? <OriansJ>dongcarl: lots of sweat, blood and tears were shed on the road of making guix a reality and I personally am grateful for all of the efforts of the many great people here. <dongcarl>Anything I can do to speed up these builds other than number of users? <OriansJ>dongcarl: faster processors, general overclocking or if you really want faster you can use prebuilt binaries <dongcarl>OriansJ: hmmm but the prebuilt binaries are only of those that they've verified will build reproducibly? <dongcarl>(which is a good restriction don't get me wrong) <vagrantc>i don't think substitutes require reproducibility <OriansJ>dongcarl: the prebuilt binaries are the results of the build servers you have selected to trust doing the very builds that are slow on your current machine. Essentially, they did the same thing you are doing only they started earlier <OriansJ>And it is possible for one to get different results than the prebuilt binaries if the package has reproducability issues <OriansJ>It is a way of allowing users to get binaries for the programs they need, while work is done to get those packages more reproducible if possible. Fortunately the Debian project is doing alot of heavy lift for us in that regard. <OriansJ>It only comes up when someone runs guix challenge on a non-reproducible package which doesn't even produce the same results on their own machine over multiple rounds <YJSNPI>GNOME here on GuixSD seems to be a mix of packages from GNOME 3.24, 3.26 and 3.28 ??? <efraim>looks like the beaglebone-black.tmpl doesn't work anymore <asterope>I have a software that has beta, alpha and stable releases - should i split them into separate packages packae{,-alpha,-beta}? <pkill9>guix typically only has stable releases, blende ris an exception though since the latest official stable release of blender doesn't work since a merg eof core-updates <pkill9>if you're intending to submit them to be part of guix i mean, otherwise you can do what you want <pkill9>how would you put them all in the same package anyway? <pkill9>ah ok, yeah you want to split them into spearate packages <pkill9>outputs are generally used to split up a single release of a software <pkill9>when parts of it are large and not neccessarily needed by people, e.g. docs, java's development kit vs it's runtime, etc <pkill9>but beta/alpha/stable are different versions <asterope>Ok, I'll do the stable for now. I think it'd fit the official distribution <asterope>the repo says "source code is published under GPLv3 with OpenSSL exception" <pkill9>maybe it just means the openssl part isn't gplv3 <tune>could not do a system profile guix pull from my normal user with sudo, but switching to root it worked fine. so does this mean something is wrong in my $PATH of my user? <tune>I have "/root/.config/guix/current/bin" at the start of my PATH and I'm using sudo -E <grafoo>i'd send in a patch to add iozone as a package. <roptat>grafoo, this looks like an expat or x11 license, so yes <wigust>tune: Probably PATH. Why do you think your PATH is wrong with ‘-E’ flag? According to ‘sudo’ man page it preserve the environment. You could compare environment with ‘diff -u <(sudo -i env) <(sudo -E env)’. <tune>wigust: I get the classic error of "migrating profile generations" and then a file exists errors, but it didn't have from root itself <tune>although then the build failed for a different reason so I just deleted the file and updated with sudo like usual <tune>I just thought I had finally fixed this the other day <tune>my symlink for ~root/.config/guix/current-guix seems fine and I have ~root/.config/guix/current-guix/bin in my user's .profile PATH <apteryx>hello! can I add a function to (guix build utils) without having to rebuild the world? I thought if the function isn't used by the build system, I should be OK, but it seems it computes the hash for the utils module as a whole? <atw>I am trying to install GuixSD on a https://prgmr.com/ host. My current approach is to install Debian on the host, download the GuixSD iso, then try to boot it with something like https://paste.debian.net/1061526/ at the GRUB command line, but doing that and then "boot" doesn't print anything and doesn't boot GuixSD. <atw>Should I be doing this another way? <apteryx>atw: eh, interesting approach, my grub-foo is not strong enough to advise unfortunatly <apteryx>have you tried a blunt guix system reconfigure on top of the debian install, to replace it with GuixSD directly? <apteryx>This should take care of configuring a working grub that'll take you to GuixSD <pkill9>could it be possible to specify a user's package profile manifest in the system configuration? <atw>apteryx: my grub isn't great either, those commands are adapted from grub.cfg in the iso. I will try your idea next. <pkill9>so basically the equivalent of automatically running `guix package -m <manifest>` right after running `guix system reconfigure ...` for the specified user <apteryx>pkill9: you could read your manifest, extract the package names, and splice it into your system's list of packages? <pkill9>apteryx: i mean, still keeping it separate from the system's list of packages <pkill9>even if it 'overwrites' the user's package manifest <pkill9>e.g. like `guix packag e-m <manifest>` does <apteryx>oh... Hmm, I'm not sure. User profile management is not something guix system has catered for until now. <atw>"until now"? is there some new feature of guix system? <pkill9>but thinking aobut it, it may be possible to effectively run `guix package -p /var/guix/per-user/<user> -m <manifest>` using scheme <pkill9>not that exact command, but the functions and such in scheme that that CLI command uses <dongcarl>If I'm understanding this correctly, since bitcoin depends on qtbase, which depends on nss, and nss wasn't able to be built deterministically, the check failed <dongcarl>I'm wondering what the easiest way is to mess around with the build files of these packages, and if, after messing with them, it makes sense for me to be doing `guix build --cores=0 --rounds=2 --check nss` <pkill9>it doesn't even build twice for me when i run `guix build --rounds=2 --check hello` <civodul>pkill9: right, --rounds is ignored when using --check <civodul>dongcarl: --check cannot be used for something that has not been built yet <civodul>in this case you caught an non-determinism issue in 'nss' <civodul>you can ignore it by first running "guix build bitcoin-core" <civodul>and once it's done, run "guix build bitcoin-core --check --no-grafts --keep-failed" <civodul>that'll allow you to dismiss the nss issue <civodul>(unless you want to fix it, which would be nice too :-)) <another-user>i'm trying to install guixsd and `guix system init` fails with "Python 3.7.0 failed to produce output path/build failed" <eubarbosa>usually when failing guix generate a log file, that is a good clue <pkill9>it doesn't build when i run `guix build --rounds=3 hello`, it just returns the built substitute, am i using it wrong? <eubarbosa>why, just before saying python xxx ... failed..., <eubarbosa>Ofc, you can read it and debug it yourself if not that hard <serichsen>I have a problem when trying to boot my new system (after guix system init): it hangs in the middle of booting, but I can't find any logs. /mnt/var/log/ is empty (seen from the installation boot). <dongcarl>civodul: If I understand you correctly... `guix build bitcoin-core --check --no-grafts --keep-failed` would let me know the determinism of bitcoin-core relative to a specific state of dependencies, as in, it ignores the non-determinism of bitcoin-core's dependencies by pinning them to a specific hash/build, and builds bitcoin-core on top of those fixed dependencies several times to check that bitcoin-core itself is detemrinisti <janneke>dongcarl: we think so too, tell your friends ;-) <dongcarl>janneke: I've been telling my Bitcoin Core Dev friends and they really like this. Reproducibility and bootstrappability are things we take seriously, which is why we made gitian, but this is just... Much better tooling... <civodul>dongcarl: also, maybe 'guix pack' can be useful to you if you want to distribute known-good builds of bitcoin-core to non-Guix users :-) <dongcarl>janneke: were you the one who gave a talk on GNU Mes? <dongcarl>janneke: I want to say that ever since learning SICP and seeing the Maxwell equations in college I've wondered how they could be applied, watching your talk really made my day :-) <eubarbosa>serichsen: As GuixSD boots it says why its unable to load the system, is there any info on that you can share? <serichsen>eubarbosa: Oh, it does load the system, it just hangs afterwards in the middle of it. I can tell you the last success messages on the terminal. <another-user>janneke: dongcarl is there recording of this talk somewhere? <serichsen>eubarbosa: yeah, just have to copy it from there. Is there a preferred paste service here? <janneke>there will be a followup talk @fosdem19 <serichsen>eubarbosa: it should be added that I manually prefixed the btrfs subvolume for the root directory in grub.cfg. <serichsen>eubarbosa: my question is mainly where the boot log might be found. <serichsen>eubarbosa: hrm, one thing I found now is that the generated fstab seems to be missing the root filesystem. <eubarbosa>I dont know much about btrfs, but it seems to be just that, not having the root partition on its path! <serichsen>eubarbosa: I looked at other fstabs, and it seems that this is normal <serichsen>I really hoped to find the system logs somewhere <eubarbosa>someone here with btrfs knowledge might help you better <tune>I heard you could get a plugin or something to browse gopher sites in firefox. does this work with icecat as well? does anyone know where to find it? <eubarbosa>Icecat is just firefox without drm and JS turned off, just enable those features again and voila, firefox <tune>yeah I don't need to do any of that, was more focused on the gopher thing and was thinking maybe it was a built-in that icecat lacked <tune>but looks like firefox removed it ages ago and you need an addon now <tune>there's one called overbitewx but apparently it just uses a web proxy <tune>it may be cool/useful for it to be packaged on guix <tune>I'm not seeing any gopher browsers on guix so far except for lynx. would be neat to have options ***rekado_ is now known as rekado
<rekado>tune: would you like to try to package it? <tune>I have never packaged something before and I don't use emacs very much (yet)... <tune>I know I should really learn to package things but it seems overwhelming <ArneBab>tune: just look into one of the scm-files in gnu/packages and copy from a similar package <ArneBab>tune: you can test your packaging via `guix environment guix && ./pre-inst-env guix package -i YOUR_PACKAGE` <tune>thank you for the information. I will give it a try in a bit I guess <dongcarl>Is this a problem with the mariadb package? <dongcarl>I keep getting the "failed to install locale" error even though I've installed `glibc-utf8-locales` and set `$GUIX_LOCPATH` <dongcarl>I believe the test that the mariadb package failed for was related to localet <dongcarl>so I'm wondering if someone can help me with this <rekado>dongcarl: GUIX_LOCPATH needs to be set in the *daemon’s* environment as well. <dongcarl>rekado: So if I'm using the systemd unit file I need to override the environment there? <rekado>The unit file should already set GUIX_LOCPATH. <rekado>could be that it looks for the locales package elsewhere <dongcarl>rekado: Right it sets it to /var/guix/profiles/per-user/root/guix-profile/lib/locale <divansantana>Guessing I missed a change. Do we have to specify the version now? Or can we do icedtea@latest ? <dongcarl>Which means I should install `glibc-utf8-locales` as root? <rekado>dongcarl: okay, then you need to install glibc-locales (or glibc-utf8-locales) as the root user into the root user’s default profile. <rekado>divansantana: the default is always the latest version of the package. <dongcarl>rekado: I'm not too familiar with profiles... Would `sudo guix package -i glibc-utf8-locales` work? <rekado>I’d do “sudo -i” to get a root shell and then “guix package -i …” as root. <divansantana>rekado: oh, yeah I know that but found it weird to see the new message which said *warning* "ambiguous package specification `icedtea'" <dongcarl>A little bit confused about current-guix vs guix-profile <civodul>"current-guix" contains Guix alone; it's populated by 'guix pull' <vagrantc>current-guix is the "guix" command's profile, and should just have itself. <civodul>and "guix-profile" contains the user's packages, it's populated with 'guix package' <vagrantc>it is admittedly a bit confusing namespace <dongcarl>As in, do I need to add this to my root's `.profile`? *dongcarl waits patiently <eubarbosa>a scheme book teaching me what is a term used by Emacs Lisp... lol <rekado>dongcarl: yes, you only do this once. <rekado>dongcarl: BTW, you can use the installer script to perform these steps automaticalyl. <dongcarl>rekado: well I already installed everything... I just wanted to understand the internals <dongcarl>I like how everything integrates with UNIX concepts really well <dongcarl>I can run `guix pull` from any user, correct? <dongcarl>only packages are separated per user into profiles? <eubarbosa>dongcarl: every user and root has its own packages definitions... <eubarbosa>dongcarl: guix pull refers to what user/root you are asking to pull <eubarbosa>Thus, `sudo guix pull` update guix update to root, `guix-pull` update definitions of users <dongcarl>eubarbosa: Sorry I'm a little confused. You're saying `sudo guix pull` updates guix for root, I don't even see a `guix-pull`... <dongcarl>I only get the warning that my guix is old when I run it as root <eubarbosa>dongcarl: Its not the same database as USER. <eubarbosa>dongcarl: If the ROOT install firefox, users wont be able to run firefox because its a ROOT package. <dongcarl>eubarbosa: And the guix database is a database of what the latest packages are and what guix itself is? <dongcarl>eubarbosa: Ah I'm beginning to understand... <dongcarl>eubarbosa: It's more than a git pull tho right? It starts building things for me <eubarbosa>dongcarl: If a user wish to run firefox, it must install it too. <eubarbosa>dongcarl: If you want to install global packages, then `guix system reconfigure` is the correct one... <dongcarl>So what exactly does `guix pull` do? It does a git pull... then starts building guix (if updated) and updated packages but only for the current user? <eubarbosa>eg: I just `sudo guix pull` and its say that new packages have been added to GUIX. If I `guix package -i emacs-anaphora` GUIX wont find it because only ROOT knows its existence <dongcarl>civodul: Watching your talk right now btw haha <rekado>dongcarl: “guix pull” installs a new version of Guix into “$HOME/.config/guix/current” <rekado>(what used to be “current” is still available under a differently named link) <dongcarl>rekado: but it doesn't update any packages, it is ONLY for guix itself? <rekado>eubarbosa: I would not use the term “database”. It’s confusing. <rekado>Guix is not just a command line tool; it is also a library of package definitions. Updating Guix means updating that library as well. <dongcarl>Okay, so a more involved question from me: I know that when I build something as my `dongcarl` user, it makes use of the `guix-daemon.service` systemd service to do the builds, correct? <rekado>when you use “guix” it talks to the “guix-daemon”, which in your case is started via systemd. <rekado>(this is a bad regular expression ;)) <dongcarl>Okay, but in my `guix-daemon.service`, it specifically calls `ExecStart=/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon` <rekado>the daemon doesn’t care about user accounts. <rekado>all builds are performed using special build users. <dongcarl>But you guys said that root and the user can have different versions of guix right? <rekado>the daemon doesn’t care much about the version of Guix you use. <rekado>it is a pretty low-level component. <rekado>it is given so-called derivations and builds those. <rekado>you use Guix to create those derivations. <dongcarl>And the syntax/format for these derivations are fixed so it doesn't change across versions? <rekado>the daemon has no knowledge of packages. <dongcarl>Okay good, thanks for satisfying my curiosity <rekado>there has been a small number of backwards compatible changes since Guix first adopted the Nix daemon. <rekado>The derivation format is still the same as that in Nix, but our daemon supports a few extra features. <dongcarl>Another question: I have 48 threads on my machine, anything I should be doing to speed up my builds? <dongcarl>(other than creating the 48 users of course) <rekado>dongcarl: I think you should also tell the daemon to allow more simultaneous builds. <rekado>eubarbosa: 48 users means that you can have 48 simultaneous builds. <dongcarl>eubarbosa: I created guixbuilder1 thru guixbuilder48 <rekado>vagrantc: what is “it” that needs doing, though? Packaging for Debian or creating a request…? <civodul>this reply is very encouraging indeed! <dongcarl>rekado: And this sets the number of jobs for each guixbuilder user? <rekado>dongcarl: IIUC you would want to set this to a number <= 48 <janneke>vagrantc: wow, that's very good news <rekado>(consider jobs that consume lots of RAM) <dongcarl>I guess I'm wondering about the interaction between `--max-jobs` and the number of users <dongcarl>Since it seems without setting `--max-jobs` I'm already getting a lot of workers when building <rekado>I’d have to look it up myself :) I just looked at the help output. <vagrantc>rekado: yeah, actually package up guix for debian, and a few of it's build dependencies mainly <vagrantc>rekado: detrout's packaging was of an old version, and needed quite a bit of adjustment to comply with current debian packaging standards <vagrantc>the lazy option, of course, would be to either packaging the installer script and/or re-implement it as a debian package... <vagrantc>that would avoid having to package up the build dependencies ... <dongcarl>I should be running `guix pull` frequently to get the latest library of package definitions, correct? <dongcarl>`which guix` on my normal user says `/usr/local/bin/guix`, is that correct? Do I need to add something to my path to point it to the guix specifically for my user? <dongcarl>of course /usr/local/bin/guix points to /var/guix/profiles/per-user/root/current-guix/bin/guix <eubarbosa>yep, once install package at the end of its installation you get HINTS to what env variables you need to add <eubarbosa>as where the packages binaries are installed... <eubarbosa>eg: export GUIX_LOCPATH=$HOME/.guix-profile/lib/locale <rekado>dongcarl: when you run “guix pull” for the first time (on a foreign distro) it tells you to put ~/.config/guix/current/bin first in PATH. <vagrantc>on my recent debian systems, i've just been symlinking ~/bin/guix to ~/.config/guix/current/bin/guix and it seems to work fine, and ~/bin/ gets added to PATH by default on login <vagrantc>not sure if there are drawbacks to that method <rekado>dongcarl: that’s for installed packages. Since you don’t install the “guix” package with Guix (you use “guix pull” instead) you still need to add ~/.config/guix/current/bin as the first directory in PATH. <dongcarl>rekado: I see, perhaps that should be added to the installation documentation? (or have I missed that?) <dongcarl>Odd thing: it would appear that ~/.config/guix/current is a symlink to a directory that doesn't exist...