<GuixSD_noob_55>Hi, I am trying to install GuixSD for the second time (first time went poorly). How do I specify to not install a bootloader in config.scm. I don't need one b/c I am using libreboot. <rekado_>you’d still need GRUB because GuixSD automatically records boot entries for system generations. <rekado_>you can let the on-chip GRUB forward to the on-disk GRUB. <rekado_>that’s what I did when I had libreboot with GRUB on chip. <GuixSD_noob_55>So you essentially had two GRUBS, one from libreboot and one on disk? <rekado_>the one on disk never changed, the one on disk changed each time I ran “guix system reconfigure …” <snape>rekado_: GuixSD_noob_55: you don't need Grub on your libreboot machine <snape>and libreboot's grub will read it <snape>I just did ln -s /boot/grub.cfg /boot/libreboot_grub.cfg <vagrantc>what are the dangers of using rsync to copy a /gnu/store from one partition to another? <snape>GuixSD_noob_55: you can use this to specify not to install the bootloader: (bootloader (bootloader-configuration (bootloader (bootloader (inherit grub-bootloader) (installer #~(const #t)))))) <snape>(I meant you don't need Grub to be installed on disk) <GuixSD_noob_55>Could I re-init the installation process with that option and everything go smoothly? <snape>GuixSD_noob_55: Having Grub installed won't harm anyway. You can do a reconfigure later on and pass a modifed config.scm as argument. <snape>I use that option mainly because my partitions are formatted in a way that prevents Grub installation. <vagrantc>heh. managed to get guixsd running on the firefly-rk3399 by switching the boot media from the puma-rk3399 ... and some minor tweaks to the config and "guix system reconfigure ..." <vagrantc>don't have a working bootloader, though :/ <lyr3>wow, is there any other tutorial on how install guix in foreign distro?...kinda confused following the main one! <lfam>lyr3: I can answer questions <vagrantc>the really confusing part is that you basically have to jump back and forth between at least two different parts of the manual ... at least to mean <lyr3>lfam: thank you. I will try again, with due patience, next weekend! <vagrantc>can i use "guix pack" to ship the guix produced by "guix pull" ? save myself a pull on a new install? <vagrantc>how much space do the largest builds take <rekado>vagrantcish: one of the largest builds is texlive, which was around 4GB last time I checked. <efraim>Mysql I think I had to budget 6GB between RAM and swap, don't know if that's still true <siraben>Is there a font package that supports hieroglyphs ? <vagrantcish>rekado: i've had linux-libre run out of disk space with 7-8GB free ... <rekado>for core-updates we need to change the r-build-system to throw an exception when the check phase fails. <rekado>currently it prints a warning about the phase ending with #f, but it keeps going. <vagrantcish>i know the debian builds for it it's in the tens of GB <snape`>ERC auto reconnects since Emacs 26, which prevents ghosting ***snape` is now known as snape
<efraim>The last time I built chromium on aarch64 using the firefly it took like 19 hours <IntoxicatedHippo>How can I stop guix from rebuilding a package if the file with the package definition changes but the contents doesn't change? <g_bor_>I've been thinking about a question asked here before, where can one find contributions to make. <g_bor_>One thing I came up with then, is bugs marked as easy. Since then I also came across the limitation section in the manual. <civodul>g_bor_: there are currently too few bugs marked as easy, but that's mostly nobody has taken the time to review them and add the tag <civodul>the usual way to get started is by adding a package that you like and that's missing <civodul>of course it's becoming asymptotically harder :-) <g_bor_>Also it seems that we could use the wishlist items for something like this in the bugtracker, but we should have some method to mark the items there, that should be really implemented. <efraim>I'd like rtv, Reddit terminal viewer, packaged <efraim>Should be straightforward python app <g_bor_>efraim,civodul: so for example in cases like this, we might try to add a bug with wishlist or minor, and also easy, to allow new contributors to pick this task up. We could also have these for upgrades. But this might be an overuse of the bug tracker. WDYT? <civodul>g_bor_: the wishlist items currently in the BT are typically non-trivial things, or things for which we don't have a clear implementation plan <civodul>now i think there are "easy" bugs in the bugs.gnu.org/guix that simply miss the tag <civodul>we could write a section, say "Your First Contribution", in the manual <civodul>that would tell people they can add new packages, upgrade existing packages, or look for "easy" bugs in the BT <rekado>civodul: I always recommend adding R packages because the importer is pretty good. <rekado>(I was under the impression that there are no easy bugs in the bug tracker) <snape>well, fixing a Qt 5.11 build issue is typically an easy task <civodul>i mean the fix may be easy, but understanding the problem requires quite some background <civodul>also, pyqt is not-so-easy apparently ;-) <snape>pyqt is a different story I think <snape>but powertabeditor is a bunch of missing headers. It's time consumming, but easy I believe <snape>well "easy" is a relative notion :=) <snape>also, a wanted package could combine the 'wishlist' and 'easy' tags <snape>not all wishlist bugs have to be complicated <rekado>required adding a bunch of headers. <rekado>I didn’t find it easy, to be honest :-/ <rekado>without the template of other fixes I wouldn’t have known how to approach this. <snape>same for me (I first saw a patch upstream that helped me) <snape>but with the template it becomes easy. And anyway not everybody will agree on what is "easy" <snape>but we've somehow got to mark some bugs as easy so to encourage people <g_bor_>it could also help to point to an example package that had a similar problem, thus making it easy. <snape>ACTION just added a not-so-easy- wish to the bug tracker <snape>rekado: you push your powertabeditor fix to core-updates <rekado>do y’all know of blockers that would speak against merging core-updates? <rekado>I have a patch for the r-build-system on core-updates that I’ll push in a few minutes. <rekado>how many packages does this rebuild? <rekado>(core-updates is frozen and we should only do bug fixes at this point) <rekado>the r-build-system patch is necessary because without it all failing tests are ignored. <efraim>Mariadb failed to build on aarch64 before <efraim>Failure on linux-libre on aarch64, I'll post the log in a bit <siraben>Hmm... guix seems to build packages from source all the time. <siraben>Despite having a substitute server (berlin.guixsd.org) <jlicht>is there still time to push an update to libuv on core-updates, rekado? <jlicht>IntoxicatedHippo: are you running guix from a git checkout? <divansantana_>How can I see why pulseaudio is installed on my system? What package, I have installed, pulled it in? <rekado>jlicht: you can push it to core-updates-next. <siraben>My Guix keeps building packages from source, what configuration do I need to do? <siraben>I already specified the substitutes server. <rekado>siraben: are you using the latest version? <jlicht>rekado: thanks, just wanted to double check. <siraben>rekado: Yes, just did a guix pull && guix package -u <rekado>siraben: we cannot provide substitutes for all past versions of Guix. <siraben>Not since I installed Guix on Debian <roptat>siraben: did you authorize berlin? <rekado>also: do not specify *just* berlin.guixsd.org, because it may not have *all* substitutes. <siraben>rekado: So how do I specify another one? <rekado>just to be clear: you did run “guix archive --authorize < berlin.guixsd.org-export.pub” ? <numerobis>Hi! Is there an easy fix for when guix pull fails with 'invalid build result'? (something like --force or something)? <siraben>It happily proceeds with downloading the source from Berlin <civodul>numerobis: no, that shouldn't happen; could you paste the output? <numerobis> civodul: thank you. Well I haven't updated in quite a long time, so that might be the reason. I'll rerun 'guix pull' and paste the output afterwards. <divansantana_>So I think the question I have is: "Display packages which require X to be installed, aka show reverse dependencies." like apt-cache rdepends <rekado>siraben: do you also get substitutes from mirror.hydra.gnu.org? <pkill9>how could i replace a package in a system service? specifically elogind <rekado>siraben: the manual mentions this in the section on how to install Guix. <pkill9>how could i replace a package in a system service? specifically elogind <rekado>pkill9: could you give more context? <pkill9>I want to set the libdir directory to /run/current-system/profile/... <pkill9>rekado: basically i want to change a configure flag of elogind <pkill9>but i'm not sure how to have everything else use my replacement <pkill9>also elogind is a service so i don't know how to have the service use my replacement package <civodul>pkill9: see modify-services, i think there's an example or two in the manual <pkill9>civodul: i don't think modify-services does what i want, i want to change the build configure flags of the elogind package, and use that package instead of the native one <pkill9>use that package in place of the native one, wherever it's used <rekado>can you tell us the derivation for which there is no substitute? <siraben>It says: Starting download of /gnu/store/pr41yjayvifygmfzh2fgl4jfx5556c0b-file-5.32.tar.gz <siraben>Why is it redownloading a lot of things? <civodul>pkill9: with 'modify-services' you can change the elogind package that's used by the service, and so you can provide your own elogind package <Guest23786>vagrantc: I've rsync an entire system before, including the /gnu/store partition. Worked out fine! <civodul>well, without the modify-services bit <siraben>Why doesn't guix install locales by default? <roptat>whoops, I'm getting the same problem :/ <roptat>trying to update my server, it's downloading the worlld <civodul>there's definitely a substitute for /gnu/store/cx1dhgfa6cn0xq28sv6p8dsbbrdqcs15-gimp-2.10.0 on berlin <roptat>oh that's because I pulled core-updates --' <siraben>Today I built emacs and icecat from source, fun. <siraben>It's not the end of the world, it's just slightly annoying. <civodul>siraben: so for GIMP, there are substitutes for x86_64 on hydra.gnu.org apparently <civodul>i didn't follow the conversation above but basically you need to make sure both servers are authorized <siraben> (q #8D156F295D24B0D9A86FA5741A840FF2D24F60F7B6C4134814AD55625971B394#) <siraben>And it's downloading guile all over again <siraben>Compiling binutils from source, something's definitely wrong. <rekado>can you tell us the *derivation* that it says it will build? <siraben>Wow I can't control-c the output fast enough <rekado>siraben: your acl file does *not* contain the public key for hydra, so it’s expected that you can’t download substitutes from hydra. <rekado>siraben: have you looked at the URL civodul posted? <rekado>“The public key for hydra.gnu.org is installed along with Guix, in prefix/share/guix/hydra.gnu.org.pub, where prefix is the installation prefix of Guix. If you installed Guix from source, make sure you checked the GPG signature of guix-0.14.0.tar.gz, which contains this public key file.” <siraben>And now the binaries are being downloaded from there! <siraben>How do I replace the packages that have already been built from source with the binaries? <siraben>I have a speedup of a factor of 1000x <rekado>siraben: ideally, those packages built from source would be identical to the substitutes. <siraben>Oh my libreoffice was improved because I installed it from guix <siraben>It's amazing just a change from 1.5.2 to 1.5.4 making all the difference. <siraben>Why is symbola not avaliable for guix? <siraben>rekado: Is there a way to replace the currently installed packages? <siraben>Why doesn't guix have incomplete download continuation? <roptat>siraben: because noone has worked on it yet <pkill9>siraben: you could fairly easily make your own package definitions <pkill9>so the designs themselves are non-free? <siraben>I could just go to a pyramid and scan the hieroglyphs <rekado>I’m quietly switching the cluster installation of Guix to core-updates. <Rukako>I never understood why people force restrictive licenses for gratis software and data ***ueno_ is now known as ueno
<siraben>Rukako: The tone of that license is pretty harsh IMO <siraben>Feels like he doesn't want his work "stolen" <snape>I'm writing an email to that guy <civodul>rekado: are you planning to take a day off tomorrow? :-) <rekado>I’m using core-updates only to install new shared profiles. <rekado>the alternative would be to stick to the old rhel6 branch, but I haven’t been able to keep it up-to-date, so this seems like a poor choice for new profiles. <jlicht>rekado: what kind of tools/scripts to do you use to manage guix for your users? And how do you make sure they keep receiving security updates? <rekado>qtbase now fails to build on core-updates <rekado>/tmp/guix-build-qtbase-5.11.0.drv-0/qtbase-everywhere-src-5.11.0/bin/qvkgen: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory <rekado>jlicht: users mostly manage their environments themselves (using “guix pull” as needed) <jlicht>rekado: and you have not had issues with users not doing that, and running vulnerable software? <rekado>jlicht: people need to be able to keep software environments unchanged for certain projects. <rekado>jlicht: this means that some will run software on the cluster that is linked with potentially vulnerable libraries. <rekado>with Guix we can detect cases like this, but we won’t force people to upgrade <efraim>I built qtbase on core-updates on aarch64 after pushing the mariadb patch <rekado>efraim: I’m trying to build it again. <jlicht>rekado: thanks for clarifying. A sysadmin-type coworker asked me how guix deals with that. <jlicht>they'll be happy to know that their job will still be important, even in a A Brave Gnu World based on GuixSD <pkill9>in the Brave Gnu World, proprietary software is soma <rekado>in my talks I usually show that Guix gives sysadmins the tools to know more about the software that users actually use. <rekado>they don’t have to give up power completely. <rekado>I’m running the build in a virtual machine with write access to the NFS store. <rekado>it did build fine on my laptop, though <rekado>+This @code{~/.config/guix/current} profile works like any other profile <rekado>+created by @command{guix package} (@pxref{Invoking guix package}). That <rekado>+is, you can list generations, roll back to the previous <rekado>+generation---i.e., the previous Guix---and so on: <civodul>i heard that rollback is convenient :-) <civodul>IntoxicatedHippo: what issue do you have? <civodul>IntoxicatedHippo: could you paste the contents of /var/guix/profiles/system-3*/parameters ? <pkill9>how do you use a graft to place a file in a package without rebuilding it? or is this not somethign to be done witha graft? <IntoxicatedHippo>civodul: I just found the problem, system-30-... (THE latest one) is empty, that line is from system-3-... <lfam>pkill9: It's not what grafting does. Grafting replaces string references to directories in '/gnu/store/...' with other directories in the store <siraben>Hi I'm getting ERROR: In procedure module-lookup: Unbound variable: python2-numpy-1.8 <siraben>When doing guix pull && guix package -u <IntoxicatedHippo>I did 'cat /var/guix/profiles/system-3*/parameters' and got the line from 3 instead of 30 <IntoxicatedHippo>Is it a bad idea to make the file writable and put the correct contents in? <pkill9>you're not supposed to edit anything in the store <pkill9>also the store is bind-mounted read only so that people don't edit anything in the store :P <lfam>pkill9: If you are more specific about what you're trying to do, people might have some ideas <pkill9>the simplest solution would be for the upstream Guix to set the rootlibexecdir to /run/current-system/profile/... but I don't know if that would be acceptable to hardcode <jlicht>pkill9: you could make a wrapper package, that basically copies all of the already-built elogind + your thing in place. <pkill9>and i just want to have a solution now, and wasn't sure if you can use grafts to put arbitrary files in an output without rebuilding <pkill9>jlicht: i don't think that would work because the elogind will be hardcoded to look in it's own store path for the libexec dir <IntoxicatedHippo>rebooting to an older guix config didn't help, so is there an easy way to fix this? <roptat>pkill9: if you don't want to rebuild, create a package that depends on elogind, copy the output of that package to the new package's output and add your script <roptat>it's not an elegant solution, but it works :p <jlicht>pkill9: I see your issue then :/ <pkill9>roptat: but won't the libexecdir still be hardcoded to the original store path for elogind? <roptat>mh… maybe you can substitute* these binary files? :p <pkill9>it's not a huge problem, to be honest at some point i'm sure it will be modified upstream <roptat>I don't know because substitute* won't work on binary files, but grafts work that way <pkill9>some other package definitions hardcode /run/current-system/profile anyways i think <rekado>Hmm, I keep getting a build failure for qtbase when the store is on NFS <pkill9>hmm i think then i could use a graft to avoid rebuilding <pkill9>and roptat's which are the same i think <jlicht>roptat might have been talking about something similar <pkill9>yep i think it was pretty much the same, except copying instead of using guix-union <IntoxicatedHippo>Lesson of the day: listen to all the warnings about not editing the store <g_bor_>I've just read the limitations section in the manual claiming that we miss KDE. We have some KDE related stuff, what is still missing? Is this a work in progress? <civodul>g_bor: Hartmut did a lot of work in this area, but i don't know what's missing <civodul>i think on guix-devel they even discussed the beginning of a KDE service <g_bor_>civodul: I just asked, because I have a feeling, that this work is somewhere near completion, and it would look really good, if we could remove that from the list of limitations. I guess I will contact Hartmut and ask around. <g_bor_>Now I'm trying to systematically evaluate these limitations, and try to get invoved where I can... I've also seen a graphical installer in development on some wip branch. <civodul>also check the list archive regarding KDE <vagrantcish>does the --cores option to guix build really mean cores? or does it just set the number of build tasks ... e.g. make -jN ? <vagrantcish>as it's sometimes beneficial to set the number of tasks to number of cores +1, as the next task is essentially queued up and ready to go the moment an actual CPU becomes available <efraim>I think its total cores available across all builds <g_bor_>I am going through the list of limitations mentioned in the guix manual about guixsd. I have noticed earlier how lvm does not fit our current mapped device concept, but at first I thought, that this could be mitigated by settign the volume group either as source, or as target. <g_bor_>The problem with that an lvm volume group is neither a source, nor a target in the current sense. The arity of these attributes suggest to choose a vg as a target, but this approach has its problems. <g_bor_>And it is still a problem, that the source would be empty. <rekado>I’m trying “guix pull --branch=core-updates” on another laptop with a somewhat recent Guix, but I get an error: no binding `invoke-error?' in module (guix build utils). <rekado>this has been reported earlier here. <daviid>rekado: is it not just invoke (not invoke-error)? <bavier`>daviid: there is an actual predicate called 'invoke-error?' <rekado>I’m pulling the latest guix from the master branch now; let’s see if that makes a differenc. <divansantana_>since a recent update, or change I made, I'm getting this from amixer: libasound_module_ctl_pulse.so: cannot open shared object file: No such file or directory <roptat>divansantana_: what's the complete error message? <wigust->divansantana_: It should be fixed after merging core-updates. Until this happens you could remove ‘/etc/asound.conf’. <rekado>“guix pull --branch=core-updates” fails even with the latest master version of Guix. <roptat>divansantana_: that's because one of these two files try to use the pulse module for alsa, but that's not possible until we merge core-updates <rekado>(which should happen in a few days) <roptat>is there a way to run a program on the source of some guix packages? <wigust->ACTION found that mysql is dead in core-updates :-( <divansantana_>roptat: wigust- thanks! Moving /etc/asound.conf worked. Great. <bavier`>roptat: there's 'guix build -S the-package' <roptat>I'd like to do it in guile though <divansantana_>ACTION finding it strange that pulseaudio is running again, when guix package -I shows it's not installed. Nor is it supposed to be. <roptat>it's a dependency of most of our packages that can read audio files <divansantana_>roptat: does guix package -I not shows dependencies? How can one see which dependency packages are installed? <bavier`>divansantana: no, and not all dependencies are installed into a profile, some just reside in the store and are referenced from there <roptat>you may have more luck with guix gc -R <divansantana_>roptat: guix-dependent-packages emacs fuction I see is pretty cool too. <efraim>There's guix graph, but you can end up with a giant output <roptat>tried that with my maven package :D <roptat>it's pretty useful to get in what order I need to send patches though <rekado>the d3js backend of guix graph can also be useful <reepca-laptop>haskell-mode build seems to fail with "haskell-process.el:160:1:Error: Unused lexical variable ?move-point-in-windows?" <reepca-laptop>(you'd think something like that should just be a warning...) <rekado>“guix pull --branch=core-updates” fails with /gnu/store/c4xj3lsr2d006…-module-import-compiled-builder <rekado>it loads a variant of build-utils.scm that does not have a definition for invoke-error? <rekado>the derivation is 22wmiw976s9f8j…-module-import-compiled.drv <civodul>rekado: yeah it's on my to-do list :-) <civodul>apparently the wrong guix/build/utils.scm is being picked up <pkill9>how do i change the package used by a service? <pkill9>specifically the elogind service <rekado>pkill9: deja vu? Has this not been answered a few hours ago? <pkill9>yeah, but i couldn't find an example in the manual <rekado><civodul> [13:43:26] pkill9: with 'modify-services' you can change the elogind <rekado> package that's used by the service, and so you can provide your own <rekado>this was the previous message (sorry for the bad formatting) <rekado>have you used “modify-services” before? <roptat>usually services have a "package" field in their configuration, but not elogind it seems <pkill9>yeah i'm using it in my configuration, but I don't know how to change the package used by a service using modify-services <roptat>oh well, it's not documented, but that's the elogind field <civodul>rekado: not sure i actually used it, why? :-) <civodul>oh that question was for pkill9 probably <rekado>civodul: yes, I was just quoting you for pkill9; sorry for the confusion. <civodul>pkill9: the manual has an index, which is how i found the page above <pkill9>i did find that, but the manual doesn't mention the 'packages' field, but apparently it exists <pkill9>it doesn't mention it under the elogind-service part, i mean <roptat>the field is named "elogind", not "package" <roptat>I had to look for the code to find that <rekado>pkill9: yes, it is missing there, so not your fault ;) <rekado>for all services we usually provide a field to override the package that the service uses. <axd>yo, which package can provide me with javac, the java compiler? <pkill9>axd: the "jkd" output of the "icedtea" package <axd>pkill9: icedtea package only provides `java` program that I can use from bask, but not the `javac` compiler. Do you have javac after simply installing the `icedtea` package? <reepca-laptop>axd: specifically the jdk output (packages can have multiple outputs, the default is called "out"). So you'd want "guix package -i icedtea:jdk" <axd>pkill9: that's perfect thank you. I'm still a guix noob, so didn't realize that packages are sometimes like categories. What's a command to be able to see the all of the possible outputs of a specific package? When I use `guix package -s `icedtea`, am I seeing just the "out" output? <reepca-laptop>there should be an "outputs" field (it goes name, version, outputs, ...) <pkill9>axd: there's an 'outputs' part, like reepca-laptop says <pkill9>also `guix package --show=icedtea` for a single package <axd>pkill9: how would I see what's the difference between the out and jdk, outputs for example. In this case I can imagine what jdk means, but what was the default "out" then? <pkill9>i think the only way you can tell is by browsing the output really (the 'ranger' program is great for this, and it's now packaged in guix) <reepca-laptop>also it's quite possible that whoever wrote the package definition made some notes about it. "guix edit icedtea" shows that they did indeed write a comment next to each output. <pkill9>i think the default 'out' output is kinda decided on a case-by-case basis, so if a package is primarily used for libraries at compile time, it will by default have all the libraries in the 'out' output and have binaries provided in a 'bin' output <pkill9>then some other packages have a 'lib' output ***dmc is now known as cmd
<pkill9>so i assume the binaries they create are primarily what that package is used for <vagrantc>heh. forgot about a beast of a machine i *should* have been doing all this arm64 stuff on ... softiron overdrive1000 ... it's big and bulky, but has 16GB of ram, quad-core and SATA ... and now seems to run GuixSD just fine :) <bavier`>vagrantc: that's the machine our build farm uses <vagrantc>they have dimm slots, so i'm sure it's upgradable to whatever you can fit <vagrantc>and the novena boards are building armhf? ... which means these were in active use by guix but nobody enabled support for them all this time? :) <vagrantc>which reminds me, i should tidy up the novena bootloader stuff ... there was an outstanding issue <bavier`>they are probably running guix on top of another OS