<rekado_>sneek: later tell Helius Are you inside of a “guix environment guix” shell when you get the gnutls error? Or are you using gnutls from the host system? ***jje- is now known as jje
<jje>sawfish no longer loads for me. i can log in but never get a right click menu and its not reading .xinitrc, anyone else notice this? ***jje is now known as Guest41552
***Guest41552 is now known as jje
<geemili>How do I change the shell of a user in the system config? <geemili>The documentation says that the `(user-account (shell ))` takes a g-expression, but I'm not understanding how g-expressions work. <geemili>Would it be something like `(shell '("fish" ,fish))`? <iyzsong>geemili: it should be a file-like object, eg: `(file-append fish "/bin/fish")`. or `#~(string-append #$zsh "/bin/zsh")`, which is the plain 'gexp' way. <geemili>iyzong: Thanks! So I'm basically just passing in the program that it's supposed to execute? And we need the gexp because we don't know at entry time what the full filepath is? <iyzsong>geemili: yes, in gexp we can refer paths that will be built. <iyzsong>yeah, or more correctly, refer to objects that will be built as paths in store. <marusich>What do we do when a Makefile contains logic which breaks when the gnu-build-system cds into the build directory ((chdir "../build") in guix/guix/build/gnu-build-system.scm)? <marusich>I'm packaging asunder, which contains a directory named "syslogng" in its source root directory, but when the build system cds into the "../build" directory and then (apparently) tries to run the makefile from the source dir, it fails because some of the things it needs are not present....... <marusich>specificlaly the directory syslogng/ is missing <jmd>marusich: I thought the build and source directories were one and the same in gnu-build-system by default? <marusich>well...maybe I'm doing something wrong, because that's not what I'm seeing <marusich>I though that was the same, plus some extra phases .. <marusich>it seems there is some logic built into the gnu-build-system which builds differently - in the manner I am seeing - when out-of-source? is true <jmd>Oh I have never used the out-out-source? option. <jmd>But many packages are indeed broken when building out of source. <marusich>Indeed...out-of-source? #t is the default for glib-or-gtk-build-system, but it's #f for the gnu-build-system <marusich>I wonder why it was necessary to add that feature. anyway, I'll try turning it off for this package <rekado_>sneek: later tell civodul When running “make distcheck” I get: “error: /gnu/store/2hd8lixggmfi20v0dj8iqfgdbv94gs2x-make-4.2.1-debug (system: x86_64-linux) has no substitute”, triggered by “assert-final-inputs-self-contained” — when I run “guix build make” I get “/gnu/store/fqih00ppvr0vhqq2yfk9nmdbnlpnrfnh-make-4.2.1-debug”, not the desired hash for make:debug. <roptat>is there a way to create a file in the profile, the same way environment variables are created with native-search-paths? <alezost>roptat: do you mean you want to create a file in a package recipe code? <roptat>what I want to do exactly is to have a file called ld.conf, pointed to by an environment variable so ocaml can find it, that lists all available ocaml modules <roptat>so if I do guix package -i ocaml-module1, it also adds an entry to that file <alezost>files can be created either by packages or by profile hooks. You probably need the latter, see, 'info-dir-file' or other hooks in (guix profiles) module <rekado_>recursive importer with streams: working :) <jmd>rekado_: What's the status of bootstrappable.org ? <rekado_>jmd: the domain was finally registered <rekado_>we also have a git repo on savannah, but I haven’t pushed to it yet <rekado_>not sure about where to host the pages, though. <jmd>Put the pages anywhere for now. I don't expect traffic will be huge. <ng0>in case traffic would get exceptional, the provider IN-berlin doesn't really cap the traffic <rekado_>I’ll first host it on elephly.net (GuixSD netbook in my living room), and then see if we can host it on existing infrastructure elsewhere. <ng0>Ah, okay :) I'd like to see wether I can get GuixSD running at their servers one day. <sneek>Welcome back civodul, you have 1 message. <sneek>civodul, rekado_ says: When running “make distcheck” I get: “error: /gnu/store/2hd8lixggmfi20v0dj8iqfgdbv94gs2x-make-4.2.1-debug (system: x86_64-linux) has no substitute”, triggered by “assert-final-inputs-self-contained” — when I run “guix build make” I get “/gnu/store/fqih00ppvr0vhqq2yfk9nmdbnlpnrfnh-make-4.2.1-debug”, not the desired hash for make:debug. <civodul>rekado_: "guix build make" works for me on x86_64, but "make assert-final-inputs-self-contained" looks at a different 'make' <civodul>the right command is: guix build -e '(car (assoc-ref ((@@ (gnu packages base) %final-inputs)) "make"))' <civodul>rekado_: i've restarted the build of this 'make' on hydra.gnu.org <civodul>i'm looking at other issues i introduced yesterday with the UTF-8 file name story <ng0>did some commit recently touch guix import? <ng0>I wanted to check up on the github to pypi changes I need to make, and I get: <ng0>ERROR: In procedure set-certificate-credentials-x509-trust-file!: <ng0>ERROR: Throw to key `gnutls-error' with args `(#<gnutls-error-enum Error while reading file.> set-certificate-credentials-x509-trust-file!)'. <rekado_>ng0: Helius reported the same issue yesterday. Does your gnutls setup work? <rekado_>nothing touched the importer recently <ng0>so I see no reason why it suddenly should stop working <rekado_>ng0: you could use git bisect if you suspect a bad commit. <ng0>hm... I'll try that on monday, I only have limited time today and none tomorrow <ng0>oh. I do need gnutls in my profile now? <rekado_>the importers need gnutls to verify certs. <ng0>Then I forgot this when I did set up the system again. But it worked for a while here <rekado_>maybe you were in a “guix environment guix” shell then…? <rekado_>or it was before cert verification was added <ng0>okay, even with gnutls in the profile it doesn't work <ng0>well it was 2 days ago <ng0>or whenever I did sent the first patches of pagure <rekado_>the cert stuff is about a month old. <ng0>do you have anything I could use for THE-FILE? <ng0>or do you mean literally THE-FILE <rekado_>(it just downloads the file and adds it to the store; could be anything.) <ng0>ERROR: Throw to key `gnutls-error' with args `(#<gnutls-error-enum Error while reading file.> set-certificate-credentials-x509-trust-file!)'. <ng0>when in doubt, reconfigure the system and update. maybe this fixes it <iyzsong>it should be a nss-certs issue. i can't reproduce it too, with nss-certs-3.27.1. (i'm unable to download the latest 3.27.2 version so far...) <ng0>then again i'm in gnome and I rarely use this <ng0>can't reproduce it or can? <jmd>How often are disk-images created? <iyzsong>ng0: it works for me. can you try `export SSL_CERT_DIR=$(guix build nss-certs)/etc/certs; guix download ...`? <ng0>currently my crowded exports feature this: <ng0>export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs" <ng0>export SSL_CERT_FILE="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt" <Acou_Bass>does anyone use dnscrypt-proxy + dnsmasq in guix? are there services already available? i know there are packages but they dont seem to have the shepherd services listed <ng0>no, no services so far <ng0>shouldn't be too difficult though <rekado_>jmd: creating the images is part of the release process <ng0>iyzsong: now the cert error is different <Acou_Bass>fair enough :D ive got a few services that i want to write so might look into that <ng0>my plan is to get at least a first review on gnunet-service out before the end of the month.. so I should clarify the network problem with `guix system vm` images <iyzsong>ng0: um, recently ludo push a commit (1af0860) to fix some broken certs in profile issue. I'm not sure, but it seems related. <ng0>all my exports are manually in .bashrc, which I learned recently was wrong and I should just source /etc/profile <ng0>ERROR: X.509 certificate of 'github.com' could not be verified: <ng0>that's what I get with yours <iyzsong>ah, I gave a wrong directory.. it should be '$(guix build nss-certs)/etc/ssl/certs'. <ng0>with this I get the same error as I got in the beginning <ng0>the source of /etc/profile was wrong.. but some other file I am supposed to source instead of putting it all in one local file iirc? <iyzsong>ng0: that's werid, may run it with 'strace' can find out the broken cert file? <ng0>I think I can't do this today. I have to do some housework and have plans for tonight aswell <ng0>I hope it's just something done by gnome.. i did not start gnome before here, only used my very manual awesome <ng0>thanks for your help :) <ng0>I think next thursday will the next curl version be released. I still haven't looked into the absolute paths where an environment variable should be. Did someone look into this before? <ng0>I'll be back in some minutes <ng0>I am pretty sure this only happens in GNOME because of GNOME magic <ng0>reconfigured, logged into awesome, problem gone <ng0>weird thought that it worked before <ng0>I really blame gnome <ng0>civodul: do you have any input regarding the curl problem with environment variables? I'd like to understand it (and fix it in gnurl) without reading through all the results I'll get when I search for it in the local archive of guix-devel <ng0>so far I only know it's something about some absolute paths were environment values should be <civodul>ng0: i haven't read about it yet, but i'll tell you when i get there :-) <civodul>i'm busy fixing the mess i created right now <civodul>i'd like to be nice to rekado_ and not make his life harder with the release :-) <ng0>okay. if you get any insight after the release, would be nice to get some explanation.. if I haven't found the problem by then. it seems to be a bug which is spread over many issues and complains, all sharing this root <ng0>I just remembered I have an theoretically working debbugs.. i think my debbugs package will only be useful to merge in when there's a service. <rekado_>ng0: re curl: libcurl (and derivatives) should be patched such that they respect an environment variable. The library has a default path to the system’s certs. This may be set during configuration. <ng0>oh, so it is this variable I once discovered <rekado_>it’s just a matter of finding it in the sources and replacing the #define with something like (getenv(THE_VAR);) <ng0>thanks for refreshing my memory on this :) <ng0>Should be doable with the next release of gnurl <ng0>curl... well, I think they are a *bit* opinionated about gnurl, so when the fix comes from anyone contributing to gnurl I don't think it'll be accepted <rekado_>I don’t think it should be upstreamed <rekado_>the upstream value works; it just fails when there is no global cert store. <ng0>for both? what damage could there be? <ng0>i remember reading the code and thought it wouldn't matter either way <rekado_>IIRC you might even be able to override this with a make flag <ng0>my default is just to do what works for my systems and everyone else can just patch on their systems.. but okay I'll search for the make flag <rekado_>ng0: there’s no predefined make flag <rekado_>ng0: there’s just a #define somewhere in a header. <rekado_>you might be able to just call make with -D followed by the definition <ng0>hm... ok, thanks rekado_ <ng0>I'll ask again when in doubt <ng0>but I think I understood it (again) <rekado_>civodul: I’m aiming for doing the release this Sunday. It freed up unexpectedly and I’d rather not wait until Tuesday (the next free slot). Do you think this is okay? <civodul>there are cpan/pypi/gem test failures, but i think bavier is looking into that <civodul>to be safe, you might want to create a branch <civodul>also, i wanted to add that text about Nix vs. Guix, not sure if i can do that by then <civodul>rekado_: oooh, just saw your message about bootstrappable, woohoo! <OriansJ>My question is there a script or option for someone to build all packages locally and automatically report all deviations from the repo? <jmd>OriansJ: That "script or option" is hydra. <ng0>or cuirass, once functional :) <ng0>it's the CI developed by Nix <OriansJ>also it appears to use hydra.gnu.org and I want it all to be done locally <ng0>what exactly do you mean? like something literally as "guix build *" and get a list of the output directories? <ng0>or --no-substitutes ? <jmd>OriansJ: guix build `guix package -A | awk '{print $1}'` <OriansJ>ng0: something like that, so that I could automatically validate all builds on hydra.gnu.org independently <jmd>And then wait 3 months ... <rekado_>OriansJ: note that this would require that all packages are in fact built bit-for-bit reproducibly. <rekado_>we aren’t there yet, so you will get a number packages that have different hashes. <rekado_>OriansJ: what ng0 and jmd said is that you might be able to simplify the big task of building everything by running a local instance of hydra or cuirass. <rekado_>their user interfaces make it easier to deal with build failures and keep track of progress. <rekado_>building *all available* packages is going to take a long time (and not all packages are currently buildable) <rekado_>but it’s manageable to build all packages that you are using <rekado_>(a much smaller subset of the 4k+ available packages) <OriansJ>rekado_: I know it'll consume much computing time but if I have it available, I might as well make it do some good. <ng0>I think I now understand again why the buildfamr is needed, in addition to individual people building. or at least I see one error in my thoughts I mentioned on monday <rekado_>OriansJ: do you plan on doing this just once or continuously? <mthl>I haven't run "make check" for a while, is it normal that a lot of things fail with "guix: offload: Command not found" error? <rekado_>mthl: when guile-ssh is available when building guix offloading support is enabled <OriansJ>so assuming several servers running continuously but finite storage space what would be the best course of action? <rekado_>mthl: when at runtime guile-ssh is not available you get this error. <rekado_>mthl: easiest fix: install guile-ssh. <mthl>rekado_: thanks for the answer! <rekado_>OriansJ: this sounds like our current hydra situation :) <rekado_>OriansJ: if you’re just building packages from “master” you won’t have to rebuild too much <rekado_>so it’s possible to keep up with changes to master <rekado_>big rebuilds would be required whenever staging or core-updates are merged into master. <rekado_>for continuous building I recommend installing cuirass. <rekado_>hydra might also work (and roel got it working), but afaiu it’s much more complicated. <ng0>is it functional now? i didn't try reconfiguring the system I wanted to test it on after the patches <jmd>I thought that cuirass wasn't yet working? <mthl>rekado_: guile-ssh is now a dependency of Guix? <rekado_>mthl: it’s optional and detected at configure time. <rekado_>mthl: if you configure in an environment where it’s available it will be required at runtime. <rekado_>jmd, ng0: last thing I know is that there was a problem with the service, but that’s been addressed by the latest patches already. <ng0>okay, I'll try when I have time <mthl>jmd, ng0: cuirass "work", however don't expect a pleasant experience. :) <ng0>I expect it to be as pleasant as early use of something can be, so I expect problems <mthl>I am working on it right now, I am adding more documentation and try to move most of the build actions in a pure environment <mthl>rekado_: Something seems to not work properly even after 'make clean' and "rm config.cache; ./configure --localstatedir=/var; make check -j4" the tests still fails <rekado_>(I’m still compiling the Guile modules…) <mthl>builders.scm, grafts.scm, packages.scm, gexp.scm, union.scm, derivations.scm, profiles.scm, publish.scm, graph.scm, size.scm, challenge.scm, pypi.scm ... <mthl>I am trying to remove the spurious go files in the build directory, recompile <rekado_>I see no failures yet, also none in “derivations.scm” <mthl>still failing for me, I am trying "git clean -xdf" to be 100% sure. :) <rekado_>the first failure I get is in tests/hackage.scm <mthl>maybe it is related to the fact I have an old Guix 0.10 installed in /usr/local <ng0>mthl: so it's no longer (#:file . "/.../cuirass/tests/gnu-system.scm") or did you update the example? <ng0>And, what's "/.../" ? I only know . and .. , so I think ... is something specific to cuirass? Well so far I'm just using what you wrote in an email a while ago <ng0>or was this not touched at all? <mthl>oh the "/.../" was only meant to tell this is file doesn't exist <mthl>s/this is file/this file <mthl>I thought the ";; Adapt to a valid absolute file name." comment made this clear <ng0>hiding in clear sight :D <ng0>I could copy the file over into the git of the system config and point the config there <mthl>However you can try with the absolute file name of "tests/gnu-system.scm" from Cuirass repository <mthl>rekado_: failures seems unrelated to the presence of /usr/local/ in GUILE_LOAD[_COMPILED]_PATH <mthl>rekado_: even after unsetting those variables, the failures still happens on my system <mthl>ACTION moves to school work <rekado_>mthl: do the failures have anything in common? <nliadm>so I'm still dusting off my scheme from college, and I don't know what to search for to do what I want: I'd like to define a... procedure? macro? that I can use like: (new-version #:commit "..." #:hash "...") So my question is, what term do I need to search? <rekado_>mthl: have you tried using a more recent version of the daemon? <rekado_>also “guix: offload: commande introuvable” indicates that guile-ssh isn’t available in the daemon’s environment. <rekado_>(and that guix was configured in an environment where guile-ssh is available, e.g. “guix environment guix”) <rekado_>nliadm: define* is used to define a procedure with keyword arguments (that’s the name of the #:foo) <rekado_>mthl: is this a recent daemon, though? <mthl>rekado_: no, but isn't the one from the build dir used by the tests? <rekado_>I don’t understand the failure in tests/pypi. (pypi->guix-package "foo") throws 'quit at some point, but I don’t see why or where. <rekado_>my guess it that it tries to access the network, which is disallowed in the test environment <mthl>this is not generally disallowed but normally the test should be skipped if network is not accessible <rekado_>in my case the procedure triggers (throw 'quit) <rekado_>what you have there in the logs is related to cert validation. <rekado_>in that test no validation should be triggered at all because the response of “url-fetch” has been mocked up. <rekado_>re make distcheck: We’re missing a substitute for “/gnu/store/bx5qywfvd0wn98fdi3a5ak85q9lwyz5m-bash-4.4.0-doc”. How can I find the corresponding build for this in hydra? <rekado_>it’s also a member of the %final-packages in (gnu packages base) <rekado_>the hackage test error is: "Wrong number of arguments to ~A" (#<procedure ___push (delta new-category lvalue tok)>) <ng0>so cuirass started.. and then some output happened and it was stopped. I'll take a look on monday <lfam>“the shoemaker’s child always goes barefoot” ;) <lfam>Wow, it's great to follow the reproducibility bug discussions around the net from our article :) <mthl>ng0: can you provide this output and the job specification you used, maybe I could help interpreting the error <ng0>is it logged somewhere? <lfam>I am surprised that the string 'gcroots' doesn't appear in guix.texi :) <alabd14313>I love linux, but I heard microsoft joined linux foundation. <buenouanq>I recommend the GuixSD distribution of the GNU operating system. <buenouanq>someday they'll have a modern working Hurd port and we can all rejoice and switch over to it <buenouanq>unless of course home 3D printed lisp machines come first <alabd14313>I worry about influence. I thought these influences are usual, but mixing free and non-free gets open. <alabd14313>unfortunately, there are many users who trend to using closed drivers and .net in linux, while at least there is free alternatives for them. <alabd14313>I think FSF gets in trouble because of three reasons : 1- laziness in being up to date (or help new developers continue their revolution) 2- releasing hardware side of computing (hardware is Hardened software) 3- Simplification about influences. <alabd14313>I don't expect from protean users to resist in luxurious world of bad (not good) companies. I expect from experienced users to Clarify in this situations. <alabd14313>This is one consequence of Simplification about influence : <buenouanq>Freedom is more important than capability, comfort, and convenience. <rekado_>I think this is off-topic on this channel. <alabd14313>excuse me rekado_ , I know here is not a good relevant place for these talks : <ng0>lfam: reactions all over the internet? so people/news sites picked up the reproducible builds report? <alabd14313>I spend about 1.5 years for writing 3 books, but these days I want to release them for free. <rekado_>I just pushed the streamified version of the recursive CRAN importer. I did not make it available for other importers yet, because that would require a few more changes. <lfam>ng0: I was exagerrating for comic effect ;) But it was nice to follow the links to various bug discussions and see the work being done! <alabd14313>finally, I have some experiences in compiling/maintaining game engine/ graphics engine. How I can help this repos ? <lfam>Once you've done that, I recommend installing Guix on another distro, or installing GuixSD on a computer, and finding things that you want improve :) <ng0>is someone more interested in (compiling) playing games than I am? I can see that my almost-finished progress with 0ad will be stuck on almost-finished for some time because it's not priority and even low self interest <ng0>I haven't posted my recent progress, so if anyone is interested, I could do it <ng0>no, the only reason that I'm stuck is that my main tasks require more time and patience than getting the game done. I think I would try an updated patch which creates a symlink from our bash package to /bin/sh at compile time and trick their weird build system that way <ng0>I have one hour to spend.. I think I can give it another try <ng0>thing is, I already have a package, and all that's left is getting the symlink, and then someone™ needs to unbundle accordingly to what I commented <ng0>I think I could finish palemoon browser with the symlinking too.. or get some steps forward. And with palemoon we'd get some autotools software from 1999! :D <alabd14313>A good news. I release 3 books about libreoffice 5.2/5.3 (more than 2500 illustrated pages) soon. Follow up libreoffice site. <rekado_>there’s one last package that cannot be substituted: /gnu/store/hld8nbkvi1zksd47aa7wp8m4kjh4gcvi-emacs-25.1 <rekado_>bavier: can we remove the tests "source-url-http" and "source-url-https" from tests/cpan.scm? <rekado_>it looks like they test features that have been removed with ff55fe559951b88bfd691b9dada3a0f26002c4cb <buenouanq>someone please let me know if there's a better way