<pkill9>i may be jailing myself in closed drivers, but i'm freeing myself from the burden of buying new hardware :) <quiliro>pkill9: buying new hardware might be a smaller sacrifice <quiliro>why doesn't nouveau work? what chipset do you have? <quiliro>pkill9: i had similar problems with geforce 9800gt <pkill9>nouveau works, it's just some software only works with proprietary nvidia drivers, plus i want to play some games and nouveau is too slow on this hardware <quiliro>but i know emulatorman from parabola could <pkill9>they've worked pretty well for me so far, but as always it's always a weight that you have to work around <quiliro>he told me he tested a bunch of xorg.conf settings <pkill9>if i build a pc i'll deffo make sure to get AMD video card with open source drivers <quiliro>in my son's machine i could never conf it so he moved to non'free drivers <quiliro>pkill9: maybe you could buy used hardware <dustyweb>this comes around a time where I'm considering whether or not I should get a "newer" computer than this x200 sometime this year <dustyweb>already a hard decision on what a libre-conscious computer user can do <dustyweb>and it's not getting any easier, especially if you're also security-conscious <daviid>dustyweb: why not a laptop from purism? <dustyweb>daviid: that may indeed be the best option <daviid>i think thy have a dock station too, not sure <CompanionCube>hey, when I try to do a package update of my user profile on a server (using guix as a foreign package manager) all I get is this <CompanionCube>'killing process 22504 guix package: error: build failed: some substitutes for the outputs of derivation `/gnu/store/xh6rwmiw24nn9fq9vz31l6d6nbkp37i0-nss-certs-3.34.1.drv' failed (usually happens due to networking issues); try `--fallback' to build derivation from source' <Guest31815>I'm working on adding PostGIS and GDAL to Guix, just hitting a problem with a missing "json_object_private.h" when building postgis. That header is part of gdal. Is there something special I need to do to make the gdal build include the extra header file? ***pksadiq_ is now known as pksadiq
***pksadiq_ is now known as pksadiq
<Apteryx>amz3: I'll just keep guix build tools for environment or non-user profiles ;) <buenouanq>are pulling with sudo and pulling as root perfectly equivalent? <str1ngs>generally you want to do sudo -i guix pull <str1ngs>sudo guix pull . will break $HOME permissions in most cases <str1ngs>guix pull might not document sudo at all, not sure <quiliro>wht is the recommended proceedure to run 'guix system reconfigure config.scm'? <str1ngs>guix pull does document what guix pull does <Apteryx>I'm pretty sure that 'sudo guix pull' is fine on GuixSD <str1ngs>sudo guix pull . basically says run guix pull as root but use my $HOME. which is pointless <Apteryx>Ah, maybe your right, I never do this on GuixSD actually. What I do is 'sudo guix system reconfigure' ;) <str1ngs>sudo -i guix pull. means run guix pull as root and use root $HOME. which is what you want <quiliro>is 'sudo -i guix pull' recommended before 'sudo guix system reconfigure config.scm' <Apteryx>quiliro: on GuixSD, the 'system' profile is managed entirely by 'guix system' IIUC. <str1ngs>I think you can do guix pull as normal user. and then sudo guix system reconfigure <str1ngs>with reconfigure you don't need to use -i since it's not writing to $HOME <str1ngs>if though you are not sure. sudo -i in both instances will do what you want. <quiliro>is it even necessary to run 'sudo -i guix pull'? <str1ngs>though I like to pull as normal user and not use sudo -i on reconfigure <quiliro>is it recommended to 'sudo guix gc'? <str1ngs>most cases you never need to use sudo <str1ngs>only when you init and reconfigure really <quiliro>how can i remove system generations? <str1ngs>sudo -i guix pull is simply a shortcut to updates roots guix to latest <quiliro>wouldn't it be necessary to sudo to remove system generations? <str1ngs>not sure, I don't bother to remove my generations. maybe gc handles that? <buenouanq>quiliro: it's high time you discovered the wonders of the su command <str1ngs>huh sudo is almost always better then su <str1ngs>also su requires root passwords. sudo does not <str1ngs>which means you can granular provide root access to multiple admins, without providing root password <buenouanq>I guess I think about things differently because I've never done the whole shared unix thing. <str1ngs>I mean don't get me wring su still works. but I personally don't think su is more secure <buenouanq>I just prefer to do admin things directly as root. <buenouanq>if this is deeply frowned upon or something, do let me know <quiliro>i would like to know how to remove system generations like user generations is done with ' guix package-d' <wigust_>CompanionCube: It's a network problem, but probably from substitutes server. So as suggested, you could try to ignore substitutes server and build from source with passing a --fallback option. <quiliro>in what section of the manual can i red about deleting system generations? <efraim>We don't have anything special for removing old generations, you just delete the symlink <Guest31815>efraim: can you delete the symlinks if you're on GuixSD? <efraim>Guest31815: yes, right now in /var/guix/profiles i have per-user, system and system-[20..30]-link <efraim>in general I delete them when they're about a month old, same as per-user generations <efraim>i figure that if something's not working and it's been more than a month I probably didn't need it <Guest31815>efraim: that's good to know, thanks. Will GuixSD renumber the system profiles, or will the numbers just keep going up? <Guest31815>wow, after a "guix gc" this is freeing up a heap of space for me, thanks efraim <wigust_>Guest31815: You could use 'find /var/guix/profiles/* -maxdepth 0 -mtime +14 -not -name per-user -exec sudo unlink {} \\;' to simulate 'guix package --delete-generations=2w' for system profiles. ***MiR is now known as Guest820
<roelj>I think our icedtea:jdk hardcodes /bin/sh somewhere.. <amz3>I think it doesn't, but I'd like to be sure <amz3>actually, I'd like to retrieve the absolute path to a shared library in guix <roelj>Is there some way to have /bin/sh available in the build environment? <snape>roelj: can't you substitute it with the /gnu/store one? <roelj>snape: I cannot find the occurrence in the icedtea package.. <civodul>grr alignment in org-table is all broken for me, with org-mode 9.1.5 ***civodul changes topic to 'GNU Guix | https://gnu.org/s/guix/ | 0.14.0 is out! https://gnu.org/s/guix/blog/2017/gnu-guix-and-guixsd-0.14.0-released/ | videos: https://gnu.org/s/guix/help/#talks | bugs: https://bugs.gnu.org/guix | patches: https://bugs.gnu.org/guix-patches | paste: https://paste.debian.net | log: https://gnunet.org/bot/log/guix | Guix in high-performance computing: https://hpc.guixsd.org'
<rekado_>Does anyone here remember the paper in which they reviewed scientific software and checked how many of them were actually installable? <roelj>rekado_: I can't find that paper anymore. ***north1 is now known as kittybearwolf
<str1ngs>roelj: you can use the special-files-service for /bin/sh <str1ngs>roelj: actually (extra-special-file) is easier to use <str1ngs>(extra-special-file "/bin/sh" (file-append bash "/bin/sh")) <str1ngs>just add that to you service section <roelj>str1ngs: Thanks! But I think this doesn't work for the environment in which a package is being built. So if I do: guix build my-package, I want to have the chroot environment that guix-daemon creates to include /bin/sh. <str1ngs>roelj: is this an autotools project? <str1ngs>if so I think it should patch-shebang automatically <ng0>so I might or might not have a way to install weechat scripts via Guix now… I had a couple of months break on that branch. Now I just need to figure out scripts in general in weechat <roelj>str1ngs: Yes, but it's a Java package, so I don't use Autotools, so I cannot configure anything. <ng0>ever since using Guix I'm fascinated by the idea that declaring (almost) independence from external Addon/Plugin stores is in reach <str1ngs>roelj: you need to use patch-shebang. I just don't know how to use it in this context <str1ngs>or maybe substitute. not sure. maybe someone else had done this before <roelj>str1ngs: Thanks for your help though :) <str1ngs>roelj: I thing substitute is the way to go. I'm just trying to find a trivial example <str1ngs>roelj: actually you have a substitute in your package file. does that not work? <ng0>since weechat is wrapped, how can I check if native-search-paths in it works? <str1ngs>you don't want to substitute to /bin/sh . you want it to goto /gnu/store/*/bin/sh <ng0>would it be in the wrapped file? <ng0>or is it just a "memo"? <ng0>I still don't grok native-search-paths beyond they set env vars, and they get added to the etc/profile <ng0>weechat is looking for WEECHAT_EXTRA_LIBDIR, so I guess it just works when the env var is exported <pkill9>is software built by Guix compiled to point to the exact derivation of libraries, or to the symlink locations in .guix-profile? <amz3>I think they are compiled againstthe derivation <ng0>ah, debian to the rescue. that'll help. nix is cheating on plugins via symlinks <str1ngs>pkill9: it's linked into the store. you can see with readelf -ld $(which <bin>) <str1ngs>that assumes binutils is in PATH though <pkill9>what's the purpose of adding symlinks to libraries in .guix-profile/lib then? <pkill9>is it for software that has paths hardcoded? <str1ngs>that just to manage a profile. it's like gnu stow in away <str1ngs>also easier to setup env variables, such as PATH <pkill9>oh i suppose it provides a record of which libraries a profile is using, so when you remove symlink to a profile the garbage collector deletes the right packages <str1ngs>and you get generations, aka roolback mechanism. also symlinks are rather atomic. so package installation can be be transactional <str1ngs>right runpath gets hardcoded as you can see <str1ngs>also if you run readelf with -l you'll notice it uses the dynamic linker in the store <amz3>pkill9: I don't see the point of creating symlinks to .guile-profile/lib except if you want to try to compile something using the usual cli dance ./configure && make && make install <str1ngs>gcc-toolchain handles the autotools song and dance <pkill9>yeah i don't think any benefits of creating symlinks in .guix-profile/lib are in building the software, i think it's all for managing what to remove with the garbage colelctor, and for environment variables <str1ngs>.guix-profile/lib would break. since you'd have to use something like LD_LIBRARY_PATH which would be problematic on foreign distro <str1ngs>runpath works with with guix because it ensure only the native import is used <str1ngs>if you use ldd it will show a better example. I think it comes with glibc-locales <str1ngs>nope it comes with gcc-toolchain sorry <roelj>str1ngs: Well, the problem is that the /bin/sh thing is not inside any file in the source code. It's either in one of the maven dependencies, of it's on icedtea itself. So substitute, or any other way of patching the source code of that package will not work, because /bin/sh is not in there. <str1ngs>roelj: that would be a bug either in maven or icetea then <roelj>str1ngs: Yes :) Thanks for your help, but I don't think it's worth solving. I looked into our icedtea source code, but I cannot find any occurrence of /bin/sh that isn't patched out already. So it's probably the maven dependency, which is not in Guix anyway. <str1ngs>roelj: ahh are you building maven by hand? <str1ngs>hmm dunno know enough about maven. I guess you are saying the maven dependency is calling /bin/sh? <roelj>str1ngs: And then get all dependencies by hand, bundle them in a tarball, and add it as a native-input to the specific package. :) <roelj>str1ngs: Yes, something Maven downloads uses /bin/sh indeed. Oh well <str1ngs>roelj: maybe send a mail to guix ML. someone more knowledgeable can help <pkill9>does `guix pull` get the latest package recipes even before they've been built by the build server? <pkill9>cos when i then run `guix package -u` it tries to build qt <Rnytom[m]>I'm having the same problem as pkill9 , guix is trying to compile webkitgtk, can I force it to use a substitute ? (even outdated ? ) <str1ngs>pkill9: guix pull download latest package recipes yes. guix package -u may need to build packages that that have not been built on the substitute server <str1ngs>pkill9: also the substitute cache can get confused <str1ngs>some times invalidating /var/guix/substitute/cache/<hash> can resolve that <str1ngs>I'm not sure how to do that with guix program. sometimes I do it by hand. <ng0>also --do-not-update=NAME is something you can use. <str1ngs>generally, if you do not want to build something huge after a pull, give it sometime. hydra will catch up eventually <str1ngs>is there a way to properly invalidate the substitute cache? <Rnytom[m]>I deleted everything under /var/guix/substitute/cache/, and even imported webkitgtk (same version) from another guix machine, but it still tries to compile it :/ <pkill9>Rnytom[m]: the webkitgtk you imported from another machine may have been built with different inputs, for example a different version of a dependency, and thus the hash would be different I think, so maybe it gets rejected as a substitute <roelj>Rnytom[m]: Is one grafted, and the other one not? <Rnytom[m]>pkill9: ok I see, maybe I'll have to wait for hydra to build it after all <Rnytom[m]>I imported it with guix archive --import < webkitgtk.nar <Rnytom[m]>But in fact I don't know if it really got installed or not. I can't see it with --list-installed, and if I try to install it, it tries to compile it (and fail at some point) <pkill9>you could check if my theory is right by using `guix graph`, which generates a dependency graph, though I dunno how to use that comand <pkill9>i think you have to open it in a browser <roelj>Rnytom[m]: Does the store path exist? /gnu/store/...? If you run 'guix build webkitgtk' on the machine that already has it, then you can see which path it is. <pkill9>you can use `guix build --dry-run webkitgtk` as well so it doesn't actually try to build it <roelj>pkill9: Well, that might give a different store path. <roelj>And double check whether you are using the exact same version of Guix on both machines. <pkill9>it normally just says 'building <package> would build these derivations:' <roelj>pkill9: And the derivations it would build are dependent on the package recipes. <Rnytom[m]>guix build on the machine that have it gives: /gnu/store/cqw2pia1vqsfb9qa39phvldxb7d4xl0c-webkitgtk-2.18.4 <Rnytom[m]>and I think guix versions are different, as I run guix pull on one and not the other <roelj>To get the same version for webkitgtk, yes. <roelj>Good chance that indeed the dependency graph is different. <roelj>If anything in the graph (view it with: guix graph webkitgtk | dot -Tpdf -o webkitgtk-graph.pdf) changed, then webkitgtk will be different -> needs a rebuild. <clacke[m]>the way I have done it is to build the user environment on another machine, then import that, and rejigger my symlinks manually <str1ngs>Rnytom[m]: make sure guix -version match. do guix pull --commit=<hash> <str1ngs>also you can offload which is the easiest way, but more work to setup <str1ngs>alternative if your guix version match you can use guix build. and then use that server as a substitutes/publish server <clacke[m]>I don't see that there's another way to install something using another machine, short of doing guix pull from a specific snapshot on both <str1ngs>yes it important that --version hash match <str1ngs>you can even have guix use substitutes with pull this way. so you only ever have to build with guix pull once <str1ngs>requires setting up your build machine as a substitutes server though <Rnytom[m]>roelj: well the dependency graphs are huuuge.. and I can't spot any difference, but there might well be one that I didn't spot <pkill9>does the official build server rebuild all packages against the latest guix commit, and keep all the previously built packages that have been built against older guix commits? <Rnytom[m]>str1ngs: the thing is I'm scared to update the machine that has the working webkigtk, as if the new version of guix also want to recompile webkitgtk, I won't be able to install anything that depends on it <rekado>pkill9: yes, but we do throw away older packages when space gets tight. <davexunit>every time I do a system update I have to build almost all of gnome from scratch. gave up after I saw it try to build webkitgtk <Rnytom[m]>str1ngs: I wouldn't mind compiling webkitgtk locally, but although it takes hours it fails at some point <rekado>davexunit: are you fetching substitutes from berlin.guixsd.org? <str1ngs>Rnytom[m]: are we talking webkitgtk? <rekado>davexunit: consider adding berlin.guixsd.org to the list of substitute servers. <rekado>that’s the 20+ server build farm here at the institute. <pkill9>you add that at the command line don't you? <davexunit>oh and that builds everything? I'll try it, thanks <pkill9>or is there a config file to add it to? <Rnytom[m]>is there a way to know which version of guix a particular machine has ? that way I could revert one to the specific commit that has the substitute I need available <rekado>well, hydra should also build everything, but hydra is a little smaller. <rekado>Rnytom[m]: have you tried “guix --version”? <rekado>pkill9: you can tell the daemon to use a list of substitute servers by default. <Rnytom[m]>Oh... it can be so simple sometimes :P I'll try pulling the older version <pkill9>i guess traditionally the package manager isn't seen as a dependency of the packages it manages :P <pkill9>also this is a one-liner i just came up with to instantly look at a dependency graph: `guix graph qutebrowser | dot -Tjpg | feh -` <davexunit>I don't know how to make the daemon always use it but you can just pass --substitute-urls every time <rekado>the daemon takes the same option. <davexunit>yeah but when you use guixsd you don't have access to touch it <davexunit>you have to fiddle with the source to use it <rekado>you can override the guix-configuration <davexunit>the operating-system record type has no field for it <str1ngs>hmm I modifier-service %desktop-services I guess the effect is the same? <pkill9>does anyone know of a way to apply certain environment variables to only files from a certain directory that are executed? <rekado>the snippet just shows how to modify the service with the guix-service-type <pkill9>specifically, to specify SSL certs to only Guix applications <pkill9>ah nvm i'm probably just overocmplicating things <rekado>did you authorize berlin’s pubkey? <rekado>(I don’t know if a substitute for webkitgtk is available via berlin yet.) <rekado>I think we should print a warning if a substitute url is requested but the key is not authorized. <pkill9>yeah that caught me out a hwile back <pkill9>does '--substitute-urls' append to official list or replace all? <davexunit>rekado: that sounds like a good UX improvement <davexunit>well, I'm sure berlin will improve things elsewhere, but looks like I'm out of luck wrt webkitgtk <bavier>my netbook just spent almost 24hours building webkitgtk <pkill9>do the build servers ever provide build substitutes for guix itself? <bavier>I've been meaning to setup offloading to my more powerful desktop <str1ngs>pkill9: yes, but not in the context of guix pull <adamvy>It would be nice if guix pull had an option to pull the latest revision evaluated by hydra, rather than latest master, then you're much more likely to have substitutes available. <davexunit>because you can only request a substitute for something you have the hash of <davexunit>an old guix can't possibly know what a newer guix derivation's hash is <myglc2`>I have a question about spice. Is anyone here using it? <adamvy>davexunit: I'm not sure I follow. Right now guix pull checks git.savannah.gnu.org for the latest commit on the master branch. I'm saying what if hydra had a suitable API and that logic was updated to ask hydra for the latest commit that has been evaluated. <wingo>civodul: it's neat stuff but ultimately surfaces a lot of detail that it would be nice if we could avoid. i sympathize with sam tobin-hochstadt when he says "i either want my abstractions back, or my money back!" <ijp>the coq processor stuff is really interesting <adamvy>davexunit: unless you were talking to pkill9 about substitutes for guix itself ;) <civodul>hopefully QEMU doesn't implement these side channels ;-) <roptat>after using "guix pack", how do I import it on another machine? I transfered the tar.gz by ssh, but I don't know what to do with it <Tirifto>I just downloaded Guix 0.14.0 Binary for x86_64. After trying to verify the tarball with its associated signature (following the instructions), gpg reports that the key used for signing (of Ludovic Courtès) is no longer valid. Would anyone know if that's a problem on my side, devs' side, or not a problem at all? <roptat>I don't know what's the status of Ludovic's key, but try to run gpg --refresh-keys <Tirifto>roptat: Thank you! That seems to have worked. (It now reports unknown format and uncertain ownership, but those look safe to me.) <pkill9>what directory is Guix-packaged software compiled to look for SSL certificates in? I can set it with the SSL_CERT_DIR, etc environment variables to look for my native distribution's SSL certificate store in /etc/ssl/certs (and it works :) ), but since that's the default why do I need to specify it? <pkill9>(i know there's nss-certs but i'll probably set my distro's certificates store so it's more consistent with my native distro) <rekado>pkill9: we don’t configure software to look at /etc/ssl/certs. <pkill9>rekado: is it configured to look anywhere else? <g_bor>Can I inherit from a package defined in another file? <bavier>as long as the package is visible in the current module you can use "(inherit <package>)" <amz3>there is small mistakes but I should be useful <nckx>Yo Guix. So what are the drawbacks of using package/inherit? <nckx>grep doesn't seem to know. <nckx>ACTION is guessing: slow. <rekado>the same problems apply as to inheritance in other languages: changing the parent changes the child. You may not want that. <rekado>e.g. when the parent package version is updated and a build phase is removed, but the child package uses an older version of the sources where that build phase is required. <efraim>nckx: did you mean using 'package/inherit' specifically vs '(package (inherit foo)...' <nckx>Right. Thanks, rekado. I meant the package/inherit macro instead of (i—yep, that. :-) <nckx>Nah, I could have been more clear. <nckx>Not that I'd not still like to know. <catonano>rekado: I rememer you explaining how to check if the substute for some binary is available <catonano>I tried to reconfigure and there was webgtkk to recompile <catonano>dry run could be a good idea, I never tried it <bavier>efraim: I'm glad it works with qemu-minimal now <efraim>it was CLI anyway, so it does decrease the inputs quite a bit :) <efraim>finally added 20 more guixbuild users to my aarch64 box, shouldn't stop as soon when builds time out <lfam>Oh yes! Thank you for fixing afl and removing that stray qemu :) <civodul>we have fontforge failing one test due to an invalid free that glibc detects <civodul>it's clearly a bug but i didn't find anything upstream <civodul>ACTION tempted to just skip the test <lfam>Best of both worlds: skip the test and file send a bug report :) <bavier>civodul: is it a recent failure? <lfam>Also, the invalid free is part of the test suite, right? Maybe that indicates similar problems in the actual codebase, but on its own it's not really a problem for using fontforge <civodul>well i think the test suite excercises a buggy part of the code <nckx>lfam: Wow, the isc-dhcp situation is... suboptimal. I had no idea. <lfam>nckx: Heh, I tried pushing my patch for isc-bind and you'd already updated it <lfam>I don't know if we still need the older bind there or not.