<rekado>Helius: if you use “guix publish” on one host that has built binaries you can download its substitutes (binary packages) from any other host, provided that the host has authorized imports from there. <ng0>rekado: are there notes, logs, or anything from the reproducible builds meeting? <OriansJ>ng0: the real question is if anyone is going to finally do work to create the dependency path from the C tree to bootstrapping Haskell. I can't, since I am still stuck on the hex monitor to guix bootstrap binaries path. Working assembler, utilities and a forth but the Lisp interpreter and the C compiler still need alot more work. <ng0>nice :) I'd be curious if we are on our own with reproducible bootstrap or if others want to go there as well <rekado>OriansJ: that’s what the bootstrappable project is trying find out: can we find enough people to do the work? <rekado>ng0: we had people from different projects, including the BSDs, taking interest in this <OriansJ>rekado: well as long as we catch new languages soon enough, we should be able to sustain a build path [crudely], the problem is that there are a handful of binaries that matter, which we will need to do alot of work to create what we missed. <ng0>thum: what I hope Vikings will do differently in contrast to others who promise and fail at trustable hosting, is transparency. as transparency (in function, what's used, who's involved, partnering, etc) is essential for trust. <rekado>OriansJ: ideally we will create awareness of the bootstrapping problem, so *we* don’t have to catch new languages. <rekado>eventually it would become common knowledge, similar to how reproducibility is moving out of the shadows <geemili>Is there a way to specify optional dependencies? <ng0>usually we include them just like that <geemili>For example, `beet bpd` is an optional plugin that requires `python-pygobject` <buenouanq>`optional dependencies' my new favorite oxymoron <geemili>buenouanq: Perhaps `conditional dependencies` would be better? :P <thum>ng0: there will be an campaign update about what you ask for! your needs will be covered. <thum>ng0: this will remove the need of trust <thum>still, having a provider with a similar mindset is always nice, I think. <ng0>you have to start somewhere though <ng0>hm... I might've underestimated the steps I still need to do for pagure ... we don't have a redis service, right? <ng0>I don't know how redis works, so I have to look at that aswell <lfam>ng0: If there is still a lot of work to do for pagure, then we should add the dependencies now instead of waiting. <sneek>Welcome back lfam, you have 1 message. <sneek>lfam, Petter says: Sure, I'll see if I can set it to -1. <ng0>Yes.. so far I see that a redis-service is required for pagure-service (which might just be an wsgi service). I haven't read all of the documentation so far. I'll send the updated patch series tomorrow <ng0>eh.. well the tomorrow after sunrise <ng0>I can imagine on GuixSD side that the pagure service will be just one service instead of many as in systemd, but I have no idea about non-guixsd systems... should I also install the .service files? <ng0>I have to do some manual installations because the reference is just the rpm of fedora <lfam>ng0: I think it's valuable to include the .service files <ng0>I assume pagure will not start without gitolite (it uses gitolite). Will users install it on their own, or shall I add it just in propagated-inputs, as it can not function without it? <ng0>there's no choice, they are bound to use this.. so I propagate it <lfam>ng0: The best option is to embed the absolute path somehow, and treat it like a plain "input". But we can also wrap pagure or propagate gitolite if necessary <ng0>there's no pagure binary, but I'm still getting to how this works at all <baconicsynergy>I'm receving errors running guix pull on the live media. It's telling me to use --fallback, but it isn't an available option <lfam>baconicsynergy: What are the errors? <lfam>sneek: later ask baconicsynergy: What are the errors you had while trying `guix pull` on the live media? <lfam>sneek: later ask baconicsynergy: What are the errors you had while trying guix pull on the live media? <lfam>sneek: later ask baconicsynergy What are the errors you had while trying guix pull on the live media? <sneek>Welcome back lfam, you have 2 messages. <baconicsynergy>damn! i've been stuck at 4.4 for too long. this makes me very happy :) <lfam>What were those problems you had with `guix pull` in the live media? <baconicsynergy>lfam: I haven't been able to figure that one out yet, that was for my laptop <baconicsynergy>I think I heard someone earlier talking about the exact same issue, I'll check the logs in a quick second <baconicsynergy>The fine work done by the linux graphics driver team and AMD is really kicking into high gear :O <baconicsynergy>holy smokes emacs and guix were just meant to be together. I SEE NOW <paroneayea>sneek: later tell lfam: nice job on updating guile-irregex <Apteryx>How can I play a .wav file with emacs? <jmd>the ./pre-inst-env trick doesn't seem to work as root. <jmd>I dunno. I was hoping someone could tell me. <taylan>jmd: was 'sudo' involved in the command you used? because sudo messes with the environment too... <taylan>if you were fully logged in as root (like via 'sudo -i') and pre-inst-env didn't do its job then I dunno <thomasd>I often have the impression that I'm building stuff for which substitutes actually exist <thomasd>e.g. I was just building xorg-server-1.18.4 (on an x864_64 machine), but hydra tells me that package builds fine? <jmd>thomasd: Are the hashes the same? <thomasd>maybe it's because I'm on the lastest git master, and hydra hasn't evaluated that yet? <civodul>apparently there's a substitute for /gnu/store/q4zbarjj20lq586az13ns9b838aqsd36-xorg-server-1.18.4 <thomasd>I have only a vague understanding of how git commits map to hydra evaluations <thomasd>yes, apparently I needed a /gnu/store/sfbaz7alh466nwfwf4lgnrfqcn37z9ip-xorg-server-1.18.4 <thomasd>so no idea why this hash is different <jmd>thomasd: I have absolutely no understanding. Perhaps it's because you've started to understand it that they have decided to replace it with Cuirass! <jmd>civodul: I have pushed a new branch: wip-installer. Testers welcome! <thomasd>jmd: :-) OK, I'll just let it build and go do something else in the meanwhile <thomasd>Ah yes, i understand. The last build of xorg-server was in gnu:master evaluation 109392, which is for commit 4a99039, after the merge of staging. <thomasd>I just rebased on master (probably shouldn't have), and one of the many commits since probably triggers this rebuild <civodul>jmd: please drop a message on guix-devel to give a bit of context and call for testers! <civodul>maybe include a screenshot in your message :-) <jmd>I'll see what I can do. <civodul>nckx: we shouldn't update kmod in master because 722 packages depend on it <civodul>could you revert it and move it to staging? <civodul>jmd: there's a gnu/system/installer/pipe-subst directory that probably you didn't intend to commit <jmd>civodul: No that was intentional <jmd>(but it can probably be removed at some stage) <roelj>How can I enable gnutls functionality *before* installing guix? <rekado_>you need the Guile bindings for gnutls <ng0>Hurd support on core-updates? so the port is done? :) <ng0>now hurd "just" needs to support amd64 in addition to what it has now <ng0>oh, that was in october. <ng0>well I'm late with catching up on emails <civodul>anyone has experience with these newfangled UEFI laptops? <civodul>i'm trying to boot in legacy mode but that doesn't work <ng0>so please don't remove it <ng0>i'll check if it really was py-bcrypt <roelj>civodul: Do you want to disable UEFI on it? <ng0>+ ("python2-py-bcrypt" ,python2-py-bcrypt) yep.. I need it <ng0>eh, i'll just start notmuch a second time and reply <civodul>roelj: well, i want it to boot and i thought UEFI was the easiest way ;-) <civodul>roelj: what would you suggest? you seemed to know the topic better than i do :-) <roelj>civodul: Would you like to boot GuixSD from UEFI, or from BIOS? For UEFI, Marius Bakke has the recipe. For BIOS, just disable it on the system startup thingy (what used to be the BIOS settings). <roelj>I can also share the snippet needed in the OS declaration when I'm home. <roelj>(I'd try to go for UEFI, but that's just personal preference I guess) <civodul>roelj: yeah that sounds like the goot longer-term thing <civodul>hmm lemme see if i can find Marius' recipe <roelj>civodul: IIRC you need: (bootloader (grub-configuration (grub grub-efi) (device /dev/sda))) <roelj>civodul: And a separate /boot formatted as vfat. <civodul>but we don't have EFI support in GRUB <civodul>that one wasn't committed apparently <mthl>civodul: Santa Inria has given you a gift? <mthl>civodul: a poisoned one... <mthl>civodul: the gift or the trouble ? <civodul>roelj: it's an HP Elitebook something <rekado_>ACTION revisits the recursive CRAN importer once more <rekado_>it's always that one last thing I plan to do every day before I realise that I have run out of time <rekado_>I understand stream-unfold now, but since the "map" step cannot propagate state to the "generator" step we may have to memoize the import operation. <rekado_>both "map" and "generator" need to run the import; the former to produce a package for the stream, the latter to update the state with additional dependencies to process. <rekado_>it seems that there's no purely functional way to do this (without doing the work twice) <civodul>roughly, you could create a closure that closes over the new state, no? <civodul>the problem is that the state is package + next-packages-to-import, whereas each stream item is just package, right? <rekado_>but even if a stream item were "package + list of deps" --- the generator cannot access it. <civodul>by "generator" you mean the stream's cdr? <rekado_>what the "map" step produces cannot be used as an input in any of the other steps. <rekado_>stream-unfold takes three functions and initial state <rekado_>the three functions are "map", "predicate", and "generator" <civodul>how about memoizing the procedure that takes a package and returns its list of direct dependencies? <rekado_>first, predicate runs on the state, then map (which produces one final stream element), then generator <rekado_>right, I think the best is to memoise this <civodul>to put it differently, can we implement something like 'requisites', which does a DAG traversal, in terms of 'stream-unfold'? <rekado_>then we can run it twice (once in "map", another time in "generator") without actually doing the work twice. <civodul>there's a mismatch between streams (list-oriented) and DAG traversal and its associated state <rekado_>would it be too ugly to have an alist in a closure around the call to stream-unfold, which is written to by "map" to store the result of the import? <civodul>i'd think it's nicer and easier to just memoize the import procedure <rekado_>I see we already have a "memoize" procedure. <rekado_>if that could be used it would definitely be much clearer <janneke>when i run: guix archive --export --target=i686-w64-mingw32 guile <civodul>rekado_: it can definitely be used; it's only downside (in most cases) is that it uses 'equal?', not 'eq?' <janneke>i get: configure: error: building Guile 2.0.13 but `/gnu/store/70f2l7892914g6mv0w4hwfcmnd7xg2fs-guile-2.0.12/bin/guile' has version 2.0.12" <janneke>how is guix archive other than guix build, for this to happen? <civodul>janneke: that's because 2.0.13 is a graft to 2.0.12 <civodul>'guix archive' is supposed to do exactly the same as 'guix build' here <civodul>rekado_, jmd: we should write a small report for Guix/GNU folks about the repro summit; want to start or should i start? <janneke>guix build --target=i686-w64-mingw32 guile <janneke>says: /gnu/store/9f6yjg09sj6vx8s3nfp15i52ppv0fcyi-guile-2.0.13 <rekado_>civodul, jmd: it will be hard for me to find time to write a report about the summit before the end of next week, I'm afraid. If someone else gets started I could contribute earlier. <civodul>rekado_: yes, that's what i thought, so i can start it <civodul>janneke: you could file a bug; in the meantime, you can always to "guix archive -r --export $(guix build guile)" <rekado_>Helius: make sure you have the Guile bindings for gnutls and SSL_CERTS_DIR is set to some /etc/ssl/certs directory <Helius>rekado_: what is the Guile bindings for gnutls ? <rekado_>this error means that SSL/TLS certificate verification failed, so you need to tell gnutls where to find certs. <rekado_>what I do is: guix package -i nss-certs <rekado_>and then "export SSL_CERT_DIR=/home/rwurmus/.guix-profile/etc/ssl/certs" <rekado_>Helius: another hint is to run this inside of "guix environment guix", just to be on the safe side. <Helius>rekado_: something like guix environment --fallback --pure --container -N guix --ad-hoc nss-certs -- sh -c "export SSL_CERT_DIR="$HOME/.guix-profile/etc/ssl/certs"; export SSL_CERT_FILE="$HOME/.guix-profile/etc/ssl/certs/ca-certificates.crt"; export GIT_SSL_CAINFO="$SSL_CERT_FILE"; guix import cran --archive=bioconductor scater" <Helius>otherwise I will buld the scm by hand :/ <rekado_>actually I just meant: "guix environment guix", which gives you a shell in which all Guix dependencies are available. <rekado_>Helius: you should remove "r-stats" from the list of inputs. <rekado_>(the new recursive importer takes care of this) <Helius>I would love to have this kind of facility, thanks <rekado_>maybe someone here can help you figure out how to make sure cert validation works out right. <ng0>is there someone who needs redis in their workplace or private? It would help if it wasn't just me working on two more services in addition to the other 3 I'm currently working on. redis is needed for pagure, and for pagure I need to write a service as well if I understand all the individual .service files correctly <davexunit>I don't have time to write a redis service now, though. <ng0>oh, that's good, because I haven't looked at redis so far <civodul>jmd, rekado_: just emailed you a draft, would be nice if you could take a look soonish! <jmd>ACTION has no idea what civodul is talking about. <paroneayea>granted, I'm not using the optimal driver, because we don't have foomatic yet, but even without that it printed just fine on my network printer in b&w <rekado_>civodul: when I do "make distcheck" I get this error: guix-0.11.0/ChangeLog: guix archive --export /gnu/store/5rrsbaghh5ix1vjcicsl60gsxilhjnf2-coreutils-8.25 | dd of=/dev/null <rekado_>error: store file names embedded in the distribution <rekado_>have to go now but I'll revisit this later <rekado_>that's from one of your commit messages <rekado_>civodul: would it be okay to change assert-no-store-file-names to only warn about this and not bail out? <rekado_>or maybe it's better to exclude the changelog <civodul>rekado_: just add "--exclude=ChangeLog" in that target, in Makefile.am <civodul>i prefer a hard error in cases where it's a real issue <jmd>Running guix system disk-image seems to start a repl and expect input from somewhere. <janneke>paroneayea: could you share your config? <janneke>for cups, i tried to enable localhost:631 and do it through there...without luck <civodul>jmd: check the error message above the REPL <paroneayea>janneke: I can share my config, but I just configured everything through localhost:631 <paroneayea>the network printer just showed up, and I selected the laserjet printer driver <janneke>paroneayea: then that would be my question: how did you enable localhost:631? <paroneayea>janneke: set that as the service in your guix config <janneke>paroneayea: thanks...though i have that too <janneke>great to know i need nothing else... <jmd>which module exports %current-system ? <jmd>What's the api to find out the output of a currently installed package? <nliadm>anyone have experience using guix when credentials are needed to grab source? I'm experimenting with code that's store in a github enterprise instance <ng0>there was thing thing for subversion authentication iirc <ng0>couple of months ago.. I don't know who wrote it or if it was added <ng0>depending on how the authentication is done, your use case could create a similar module for git <lfam>Yes, it depends on the authentication method <sneek>lfam, paroneayea says: nice job on updating guile-irregex <nliadm>okay. I'll poke around on the list and see if I can find it <lfam>paroneayea: Now we just have to wait for or write fixes for chez-irregex and chicken <ng0>nliadm: thread:0000000000000d9f 2015-12-16 [1/5] Ricardo Wurmus| Ludovic Courtès; [PATCH] http-client: Support basic authentication. (guix guix::patch unread) <ng0>I have been working on a package for the toxic (curses tox) client, but now that c-toxcore is around, they'll also switch soon, so I just wait for a new release <ng0>hm. my spare laptop just got an kernel panic. maybe it needs the older kernel as well <lfam>Seems funny that we have (gnu packages upnp) and (gnu packages libupnp) <cbaines>Is there any patterns for working with package managers that use paths (e.g. gem with GEM_PATH) when working in the store? I'm trying to run a ruby program, but its looking like I would have to construct the GEM_PATH to make it work? <ng0>why do we have two different modules? <ng0>i wonder what's with 4.9 and 4.8.15 or whatever it was which makes some of my hardware panic and some not <lfam>Good question. Can you trigger the panic on purpose? <ng0>other than that, no idea <lfam>And the 4.4 kernel works? <ng0>on the desktop computer yes, the laptop I think so, I just reconfigured it after a while and discovered that this is happening there too <lfam>I'll see if I can reproduce this <ng0>laptop is one of the t60 generation, desktop is some random AMD based with blob requiring gpu (but works with free drivers aswell) etc.. <jmd>How can I get a variable for the current operating system ? <ng0>I have another one I should reconfigure and see if this is a thing for most of my hardware <ng0>the older boards ('99 / 2000 etc )I have thrown away already. <paroneayea>lfam: I keep thinking I ought to package fmt for guile as well <paroneayea>lfam: maybe I will get to it soon. It could result in a much nicer version of mudsync. <lfam>paroneayea: Made any more progress on the ISO generator? <paroneayea>lfam: nah I've been distracted by the 8sync refactor <paroneayea>I was like "well I guess I ought to kick out a release of 8sync, then poke at how hard it will be to get suspendable ports working, because I need something like this for the standards stuff I'm doing" <ng0>lfam: is this positive reaction on reddit? So far the few posts I've read were mixed with the tendency to bashing. <paroneayea>ng0: tendency to bash is the de-facto nature of reddit/slashdot/hacker news ;) <lfam>This time there is no bashing :) <mthl>In Guix manual in the G-Expressions section some procedure are declared as "declarative counterpart" of XYZ. <mthl>I fail to properly understand what that exactly mean <mthl>would someone be kind enough to explain it to me :) <lfam>mthl: What part don't you understand? Are you familiar with the concepts of "imperative" and "declarative" programming styles? <mthl>I don't understand what the XYZ-objects relate to the Gexp <mthl>since this what is returned by those "declarative" procedure <lfam>Okay, then you already know what I know. Someone with more knowledge will have to help :) ***Guest27213 is now known as sturm