<lfam>Oh, you have the key but there is some other issue <lfam>CharlieBrown: I see you downloaded the file 'guix-binary-0.11.0.x86_64-linux.tar.xz.sig' <lfam>But you then do `gpg --verify guix-binary-0.11.0.system.tar.xz.sig` <lfam>Isn't that the wrong filename? <lfam>Bah, I spent all day working on an xorg-server update to learn that there are still several drivers that aren't compatible with the new version. <CharlieBrown>Why does Guix's download page say "Linux-based system"? That sounds like some troll's way of getting out of the requirement to say GNU+Linux. <lfam>CharlieBrown: You should either chain the commands together with && or do each one by hand. That way you can check if each one succeeded before continuing <lfam>But, the output shown seems reasonable <lfam>I'd use `guix build hello` to test it <Apteryx>lfam: sorry I was afk for a couple hours, now I have a couple hours to look at the udisks problem. It seems the strings in the sources are all starting with "cryptsetup ...", which would suggest it *should* find it, no? Since "cryptsetup" is in the path upon installing the "cryptsetup" package. <lfam>Apteryx: Okay, but it's not working, right? <lfam>I would just try replacing that string. If that works, then at least we have a successful case <lfam>If cryptsetup is on the PATH of the user that runs udisksctl, and it still isn't working, then I guess that udisksctl doesn't respect PATH <Apteryx>lfam: My guess right now is that the error message is not very accurate... and that the real issue is that I don't have a polkit rule to allow cryptsetup running as a user. <Apteryx>lfam: I don't see to what I would rewrite the crypsetup string? To the exact store location? <lfam>I've found that "file not found" errors are often used misleading ways <lfam>Yes, the absolute path of the cryptsetup binary <lfam>But, if you think it's a spurious error, you should pursue the other thing instead <Apteryx>I'd much prefer it looks the one from the path. That way the user can always override the binary for experimenting. <lfam>Sure, but it breaks the functional package model <lfam>We do have some packages that find their optional dependencies on PATH, like rsync with ssh. I don't know enough about udisksctl to have an opinion :) <lfam>Yes in the default case, because the cryptsetup binary could be garbage collected due udisks not containing a reference to it <lfam>But like I said, I don't know enough about this case to know if that's a realistic problem <Apteryx>I would think that packages that depend on other binaries being in the path should simply have those packages as propagated-inputs? <Apteryx>That way they don't get garbaged collected, even if they don't have to directly link to the dependencies in the store (unless I'm missing something) <lfam>It depends. There are drawbacks to propagated-inputs that are avoided when using a direct reference <Apteryx>OK. I don't know enough about Guix yet to know what those drawbacks could be. <lfam>"Lastly, propagated-inputs is similar to inputs, but the specified packages will be automatically installed alongside the package they belong to" <lfam>So, you can only have one propagated cryptsetup in a profile. <Apteryx>Yes, if I understand correctly propagated-inputs are "persisted" inputs, or "run-time dependencies". <lfam>But things in your profile can refer to as many cryptsetup store paths as you need <lfam>It depends, but inputs are typically run-time dependencies, and propagated-inputs are used for special cases of run-time dependencies <Apteryx>I guess the limitation would be when dealing with software wanting their own version of a propagated-inputs... If they search the PATH for it, they'll use whatever version was installed in the profile. <Apteryx>Intead of the exact version the package was built for? <lfam>You couldn't propagate cryptsetup and install cryptsetup without one of the two being overridden by the other <lfam>It gets messy and starts to break the functional packaging model <lfam>Anyways, maybe it's a problem with your polkit rule, like you said :) <lfam>I have to go. Good luck with your investigation! <geemili>Are there any pip packages I can see as an example? <Apteryx>geemili: You could use the pipy importer, which will do most of the job for you. <Apteryx>geemili: hundreds of them. If you have the guix git checkout, just look at the file guix/gnu/packages/python.scm <Apteryx>Sorry, more like "guix edit python-pip" <geemili>Okay, I'll check out the pipy importer <Apteryx>geemili: Example: guix import pypi pylint <Apteryx>It'll spit out a complete (but maybe rough) package definition for pylint. <geemili>Apteryx: Thanks! I think I got the package working. <geemili>If the pip package is an application, should I remove the `python-` prefix? <lfam>I decided not to go to the thing I was going to, so let me know if you more questions Apteryx <baconicsynergy>I'm still patiently waiting for usb, sata, and sound support though :3 <buenouanq>I really need ispell - Will someone competent please package it for me ( ._.) <lfam>buenouanq: How about aspell? Does that meet your needs? <lfam>Based on the list of patches applied by Debian to ispell, I think it might not so easy to package this program which is apparently no longer maintained upstream <lfam>The first URL has a typo, sorry <Apteryx>lfam: What's the easiest way to test the string substitution solution for udisks? Do it by hand in the sources, or alterate the Scheme package definition? And why wouldn't it find it in the PATH if me as a user can? Is Guix doing something special with the PATHS? <lfam>Apteryx: I don't know why it wouldn't find cryptsetup on PATH. Maybe that's not the real problem, like you suggested. <lfam>I think the easiest way is to create a new build phase 'patch-paths' in the package definition. Commit 7c1a7bf484cb6078798e132f16d1600b9a36349f shows an example of how that would work <Apteryx>OK. I still want to test your suggestion of substituting the "crypsetup" calls to "/gnu/store.../cryptsetup" to see if it makes any difference. <Apteryx>lfam: OK! Thanks for the commit-example :) <lfam>You can give (substitute*) a list of file-names. It's documented in (guix build utils). That is, guix/build/utils.scm <Apteryx>Is there a way to see a specific commit in magit? Using git itself is easy: "git show ref" <CharlieBrown>ArneBab_: Should I learn Python before Guile? I ask because Guile has a dearth of libraries. <buenouanq>only thing you'll learn from python how to google for libraries that already do what you want <CharlieBrown>buenouanq: But with Guile, I'll have to just look for C libraries and use those. <buenouanq>well wait, what's the goal here? is this going to be your first expedition into programming? <CharlieBrown>buenouanq: I just... I can never write anything that actually DOES anything. <CharlieBrown>I want shit to WORK. With Guile, it's like you have to reinvent the wheel because the library isn't there. <buenouanq>I started with python and I feel it impeeded my learning and progress - Once I watched the SICP lectures and started playing with Scheme is when things finally got super fun and I felt I was actually learning. <buenouanq>my opinion is that python is horrible and crippling and shouldn't exist <buenouanq>I've found I'm a very small minority in this though. <buenouanq>I don't understand your saying that Guile will be bad because of the libs, because doesn't Python have countlessly more? <buenouanq>you mentioned that guile has a dearth of libraries <buenouanq>but I believe that python has many many more <CharlieBrown>buenouanq: I don't want to have to make things from scratch, as I'd have to do with Guile. I just want to combine things to create something new. <CharlieBrown>buenouanq: Python has a library for everything. Compared to it, Scheme has none. <buenouanq>I was mixing up the meanings of dearth and glut <CharlieBrown>buenouanq: I just realized that uanq is bueno written upside-down. Cool! <CharlieBrown>And your name is funny, because "uanq" looks like "wank", so your name looks like "good wank." <buenouanq>The draw to Scheme for me is indeed largely because of how minimal it is - That said, Guile has amassed many libs making it more than usable for whatever modern application you might imagine. The `reinvent the wheel' line is misplaced. <geemili>I have a package that depends on `python-dateutil`, and it's using version `1.5`, while I want it to use version `2.5.2` <geemili>buenouanq: Where would I put the @2.5.2 part? <buenouanq>you could leave it less specified with just an @2 though I think <geemili>The `@2` made it not build, `unbound variable: python-dateutil@2` <geemili>Every time I run a command in `./pre-inst-env`, it rebuilds everything. Is there a way to make it cache the files? <Apteryx>lfam: What's the difference between substitute and substitute* ? What does a trailing '*' stands for in general in Scheme? <geemili>Apteryx: I think it indicates a macro <lfam>Apteryx: I'm not much of Schemer yet, but it seems that that it indicates the procedure can take a list. It seems similar to the difference between cons and cons* <Apteryx>It seems substitute will call a PROC while substitute* does more of a straight-forward match and replace job. <Apteryx>Where PROC could do anything you might want to do with the input it gets (the line string and the matched expressions). I guess most of the time in Guix substitute* is what we want. <Apteryx>lfam: OK. That's a good reference. I'll look there first for my next Scheme question. <Apteryx>Also, if anyone knows of a good Scheme/Guile book just in time for some Christmas reading, I'd be happy to know about it. <geemili>Assuming that `substitute*` is using the same conventions, `substitute*` just allows for optional and/or named parameters <Apteryx>The only example I know is let vs let*, where let* is recursive in that you can reuse whatever binding you've done so far. <Apteryx>Maybe * just stands for "a variant of" after all. <buenouanq>more general than maybe you're looking for though, it's not specifically about Scheme, they just happen to use it <Apteryx>Wow, there's a couple hours of material there. <geemili>Also, are you sure that the `package@version` syntax is right? It gives me `unbound variable` when I do that. <geemili>And I don't see a way to "import" a different version <Apteryx>Did you import the "package" symbol? <geemili>I'm importing `(gnu packages python)` and want to use `python-dateutil` from it. <geemili>Do I need to do this? `(gnu packages python python-dateutil)`? <Apteryx>geemili: Let me try some things in the interpreter <geemili>Apteryx: Did some of my own research in the interpreter. Looks like `python-dateutil-2` is the way to go <Apteryx>geemili: OK. I thought this was the old fashion way, but maybe this only applies to arguments passed to the Guix command line tool. <Apteryx>This is the way fixed version are defined, such as "define-public python2-dateutil-2" <geemili>Anyway, I got the package I was making work! At least, as far as I can tell. <geemili>I just found out about this wonderful thing command-line accounting today, and `beancount` looked cool. <geemili>s/command-line accounting/plaintext accounting/ <Apteryx>You can send it to guix-devel to have some feedback about it and make it available to all! <rekado_>wow, ever since registering bootstrappable.org targeted email spam is out of control… ***jz is now known as Guest45138
<ng0>I can 100% reproduce the gnutls error in GNOME every time, it could be though that I just have to source .bashrc for a second time there... <ng0>ah.. correction, after a reboot it persists in awesome-wm <ng0>well i can work without import for a while <jmd>How do people normally cope with guile modules which require a .so file? <jmd>Should we set LD_LIBRARY_PATH manually or is there a better way? <rekado_>jmd: we normally patch the sources to have an exact reference to the .so file, I think. <rekado_>ng0: could you please double check your environment? It takes both SSL_CERT_DIR and gnutls to work. <ng0>i can paste the relevant parts <rekado_>ng0: to test if gnutls works you can start "guile" and then ",use (gnutls)" <rekado_>if that's without errors that's good <ng0>this works without erros <jmd>rekado_: But the "source" which would have to be patched would be guile. We can't have one package patching another. <jmd>Well in the case which is causing me grief right now its libguile-ncurses.so <rekado_>jmd: hmm, the file "curses.scm" of "guile-ncurses" is patched such that "load-extension" is given the full store path to libguile-ncurses. <ng0>but the weird thing is, it works, just occasionally it breaks. every time I launch gnome i think, and afterwards until I recofigure the system <rekado_>ng0: and you have nss-certs installed in your profile? <ng0>the last change i see with grep is: <ng0> + nss-certs 3.27.2 out /gnu/store/c7kr9pdni867k2778pykh16sw003kl1s-nss-certs-3.27.2 <ng0> - nss-certs 3.27.1 out /gnu/store/nd946vlingp0ff63y18sqmv823cday9w-nss-certs-3.27.1 <rekado_>BTW: I would not set so many variables manually. I just "source $HOME/.guix-profile/etc/profile" <jmd>rekado_: Is that wrong? <rekado_>jmd: no, it seems right to me, so I don't understand why LD_LIBRARY_PATH would be needed in this case :-/ <ng0>yeah, I only noticed this at the weekend.. I'll change it some day <rekado_>ng0: is your system time correct? (That can screw with cert validation.) <ng0>if anything it's off some miliseconds <rekado_>ng0: is there anything else in your shell init files that might modify the environment? <rekado_>ng0: I suggest using "env" to determine the effective environment. <ng0>there are aliases, but all in the my.* namespace, and I export some GPG variables <ng0>also a merge of .Xresources <ng0>in the environment i get the same error, I'll paste it <jmd>rekado_: Maybe civodul will know? <jmd>Do you know why guile-ncurses requires LD_LIBRARY_PATH to be set? <jmd>rekado_: One reason perhaps, the Guile manual says that load-extension should not specify directory components. <civodul>jmd: it shouldn't; the guile-ncurses recipe puts an absolute file name in there <jmd>civodul: But that is wrong? <ng0>civodul: didn't you fix that in a recent commit? <ng0>I think I reconfigured yesterday <ng0>with HEAD from yesterday morning <rekado_>ng0: I get "guix import: error: no source release for pypi package pypi 2005-08-01" when doing "guix import pypi pypi"; there's no gnutls error. <ng0>i get the same for kitchen <ng0>pypi pypi was just an example <rekado_>ng0: did you really mean "guix environment" without arguments? <ng0>it used to work after reconfigure, then I started gnome, encountered the error, switched to awesome, problem was back in awesome. it was gone when I reconfigured the system yesterday <rekado_>ng0: what is the desired effect of using "guix environment" without arguments? <civodul>jmd: load-extension is fine with absolute file names <ng0>ERROR: Throw to key `gnutls-error' with args `(#<gnutls-error-enum Error while reading file.> set-certificate-credentials-x509-trust-file!)'. <jmd>So why is it necessary to set LD_LIBRARY_PATH ? <ng0>idk.. i haven't used environment so often <ng0>i could do with --pure <rekado_>jmd: FWIW I also get "ERROR: In procedure dynamic-link: file: "libguile-ncurses", message: "file not found"" when doing ",use (ncurses curses)" <rekado_>ng0: guix environment expects an argument <rekado_>ng0: "guix environment guix" gets you the environment for the "guix" package. <rekado_>"guix environment --ad-hoc guix" gets you an environment with just "guix" <jmd>I wonder if it's because libguile-ncurses.so is a symlink to an non-absolute pathname? <rekado_>adding '--pure' clears your environment variables (or at least some of them) <ng0>my .bashrc includes some commands which are automatically run every time the shell is started, but this was never a problem in one year and even before that <ng0>with --pure --ad-hoc guix it works <rekado_>ng0: it's just a debugging measure. It's just easier to reason about the problem when there are fewer things in the environment. <ng0>maybe I should clean up the env exports <rekado_>ng0: okay! Well, then I'd suggest running "env" in both environments and looking at the diff. <ng0>xrdb is automatically run, and the last 3 not found are from the GPG part in the .bashrc <ng0>which package provides "env"? I have it in my profile but the pure environment needs something else <rekado_>ng0: you can just give the full path to env <rekado_>the pure environment still has access to the full file system <ng0>i'll take a look later today and compare the results. thanks for your help <rekado_>civodul: I see that we have a version of texinfo.tex in build-aux; I'll update this to a later version from gnulib. <jmd>rekado_: What about (use-module (guile ssh)) ? <civodul>(guile ssh) doesn't exist; rather (ssh keys), etc. <civodul>rekado_: right, but note that this file is not under version control currently <CharlieBrown>I want to package Mumble but I know I suck at packaging and that packaging Mumble is even harder. <jmd>CharlieBrown: I'm not sure that all of Mumble's dependencies have been packaged yet. <CharlieBrown>jmd: Good point. I should probably look at that situation first. <jmd>In fact, I think some might be proprietary, in which case we would not have them. <jmd>Ahh well there we are. Problem solved. I should stop mumbling. <ng0>I packaged it last month :) <ng0>yes :) but if you want to work on it, there are some bundled dependencies which need to get removed with the next major version of it <ng0>I think it's inline commented, or in one of the threads for it <CharlieBrown>you said deps had to be removed, like its becoming nonfree orsomething <ng0>bundled dependencies are ones we like to avoid here if possible. mumble upstream said to remove some more bundled ones when they release the next version, if i understood the comments correctly <ng0>does anyone know which timezone christ (marusich) lives in? <ng0>but gnu.org list server doesn#t chnage the timezone.. so I think i have the zone <jmd>Is there any way we can debug what load-extension is doing? <civodul>jmd: i would use 'strace', like: strace guile -c '(use-modules (ncurses))' <jmd>The only interesting thing is that it attempts to load from /lib/libguile-ncurses.so and /usr/lib/libguile-ncurses.so <jmd>So why is load-extension ignored? <civodul>jmd: does the load-extension substitution in the guile-ncurses recipe work? <civodul>if it did, the search path would be ignored, i think <jmd>civodul: When you say "work", you mean did it prepend the "/gnu/store/..." ? <ng0>maybe I have a gnunet-service now.. I revisited what I started in september, simplified it a bit.. because I would have to wait for help from chris for the vm, I'll just do it "yolo" and reconfigure one of my systems with the patch :) <ng0>it's not as extensive as my first (third? fourth? who knows..) version, but in theory it does the job <ng0>it helps that I understand some terminology better now <jmd>It seems that GUILE_LOAD_COMPILE_PATH is the culprit. Having that set to anything that contains ncurses/curses.go causes things to break. <jmd>OK. I think I know why now ... ***jonsger1 is now known as jonsger
<jmd>Is there a way to patch .go files after they are created? <ng0>looks like I might have an almost working gnunet-service now. I need to monitor it a bit and debug (also because the version guix ships is a bit old, but I've started a conversation on this issue) <jmd>ng0: That sounds good. <civodul>jmd: re patching .go files, it's not easily feasible nor desirable ("yes" was for a previous question :-)) <ng0>jmd: optimistic case scenario I can tick off the "basic gnunet-service" item from my road map at the end of the year :) <ng0>I think this old version needs setuids <jmd>civodul: Well here's the problem (I think): guile-ncurses correctly patches the load-extensions path. But it does that AFTER the .go files have been created. It cannot do so before, because at that time the output path does not exist and the .go files will fail to build. <civodul>jmd: oooh, got it! i made the same mistake in Guile-SSH some time ago <civodul>jmd: see commit 92b725829bb8597a5828f1892812aa32620203c9 <civodul>you should be able to do something similar <jmd>I will have a look thanks. <jmd>rekado_: BTW That trusting-trust annecdote I was looking for last week: Google for "A coders worst nightmare subliminal" <jmd>civodul: I was thinking of something similar. But I'm not sure if the makefile for guile-ncurses is so kind :( <civodul>i don't know if that's because libahci.ko is problematic, or a bug on our side <civodul>[ 6.085552] libahci: disagrees about version of symbol mcount <civodul>[ 6.085978] libahci: Unknown symbol mcount (err -22) <lfam>ACTION downloads the samba security update <jmd>civodul: I got those errors too when trying to do guix system disk-image <jmd>No. I was cross building targeting i686 ***jonsger1 is now known as jonsger
<jmd>Well isn't 4.9.0 a test version anyway? <lfam>I don't think it's a test version, but rather the "mainline" version. <jmd>Well I always understood that kernel versions where the middle field was odd were not recommended for general use. <lfam>I don't think that's the case. The 4.9 kernel has been selected as the next version to receive long-term support <newdan>If I do `guix pull` does that try and install GuixSD? I'm running Guix on top of Ubuntu and just wanted to do the equivalent of 'apt-get update', i.e. just make sure I have the most recent defs for all the packages <newdan>But I ran `guix pull` and it is taking an awfully long time and seems like it is doing a lot of things <lfam>newdan: `guix pull` is how you update the Guix you've installed. This is similar to `apt-get update` <newdan>lfam: Interesting. The terminal window seems to indicate it has installed X11 <lfam>It takes a little while to build Guix, and it will install any packages that are necessary to build Guix <lfam>Well, "install" is the wrong word. It will put the packages in your /gnu/store, but it won't install them into your user's profile <newdan>lfam: Is it normal that it will want to install X11? All I have in my profile is ruby and recutils... <newdan>The initial install went so quickly, something seems wrong that `guix pull` is taking over half an hour <jmd>ruby has a huge number of dependencies. <lfam>`guix pull` isn't upgrading the packages in your profile. It upgrades Guix itself <lfam>So it's not affected by what's in your profile. <lfam>Sometimes building Guix requires new versions of its dependencies, and so I bet it's making those for you <newdan>lfam: But it's still the equivalent of apt-get update? Which just updates the packages available in apt? <newdan>Oh... Updating the guix command itself? <lfam>Yes, you can think of it like `apt-get update`. For `apt-get upgrade`, you'd want `guix package --upgrade .` <lfam>The '.' is a regex that matches all the packages in your profile <newdan>So it's normal that if I just want to see if a newer version of Python is available, that to do that would take over half an hour? I haven't run the wrong command? <newdan>I don't totally understand why it has to build anything <newdan>`guix pull` will update package lists *and* update the guix command itself? <jmd>It depends. If something deep in the bowels of guix has changes since the last time you pulled, then yes, it'll take a while. <lfam>Because to build Guix you need to also have built Guix's dependencies. If you don't have the current versions of those dependencies, Guix will try to get binaries of them, and if it can't, it will build them from source. Did you say it was building libx11? We have a binary for that available. <newdan>And updating the guix command involves isntalling X11 and Perl? <jmd>newdan: Perl is very pervasive. <jmd>What exactly do you mean by X11 ? <newdan>jmd: I'm not 100% sure, but it was either building X11 or libX11. I saw a bunch of references to x11 on my Terminal a few minutes ago. Now it appears to be building cmake <lfam>newdan: It shouldn't need to build cmake from source; it should be downloading binary substitutes from our servers, assuming you authorized our substitutes servers when you installed Guix. <lfam>Hm, is this your first time running `guix pull` after intalling the Guix 0.11.0? <lfam>civodul: If newdan is running `guix pull` the first time since installing Guix 0.11.0, will they suffer from the lack of substitutes corresponding to the 0.11.0 release tag? They find themselves building cmake, which I can get a substitute for. <civodul>lfam: yes, you're right; though i wonder how guix ends up depending on cmake <lfam>It's not in `guix graph guix` <lfam>newdan: libx11 comes via the dependency on graphviz <lfam>newdan: Due to a lack of disk space, we deleted the substitutes corresponding to the 0.11.0 release tag. So, you'll need to build from source what is missing, which could be a lot, or a little. I'm not sure. If it's too much, you can work around it by building from Git, which is documented in the manual, section 8.1 Building from Git. Sorry for the inconvenience; we are actively working to improve our infrastructure so we can avoid issues like this in the future <nliadm>I'm trying to make multiple versions of a package via (define-public (gensym) (new-version ...)) where "new-version" returns a package, and they don't show up when I look in guix package. This seems like it should work, what am I missing? <lfam>How are you making your new packages available to Guix? <newdan>lfam: Oh I see! Thanks for the help and information, I appreciate it <lfam>For example, are you using GUIX_PACKAGE_PATH? <nliadm>other, hand-written packages are showing up <nliadm>it works if I don't use gensym and instead use a random name <lfam>I see. I'm not the best person to give advice about this, but I'd make sure that gensym was a package. That is, I'd make sure that (new-version) returns a package. Beyond that, hope for a real expert to show up :) <lfam>Well, I'm going in a tunnel so I have to go! Good luck <civodul>Apteryx: you should use "later tell ng0 blah blah" :-) <civodul>mark_weaver: did you have success with linux-libre 4.9 on i686? <nliadm>so I guess "symbol" isn't what I want? <Helius>is it posible to perform the import procedure if I have the original source archive, so that guix does not download it. <sneek>Helius, rekado_ says: Are you inside of a “guix environment guix” shell when you get the gnutls error? Or are you using gnutls from the host system? <Apteryx>How can I give substitute* the pattern to match? I want it to match '"cryptsetup '. Would I then need \\"\\\\"cryptsetup \\"? Or is "\\\\"cryptsetup " sufficient ? <civodul>Apteryx: you need to escape double quotes within strings, and you need to escape backslashes within regexps <civodul>so that would be three backslashes followed by one double-quote <civodul>wait, i'm saying nonsense is double-quote is not special in a regexp <Apteryx>So like my 2nd example? ("\\\\"cryptsetup ") <Apteryx>civodul: Ah, no, sorry I understand now. <Apteryx>The backslash is for the parser of the string, not for the regexp. <Apteryx>Oh. No more gunzip in my PATH. Could this be a garbage collection issue? I ran it yesterday. Now guix lint throws: filtered-port: failed to execute '/gnu/store/3crmayabzcg97rdp8v0hbnqw3ip8s2cl-profile/bin/gzip -dc ': No such file or directory <Apteryx>Or maybe we always have to install gzip ourselves and somehow had removed it from my profile? <civodul>Apteryx: if that's in a build tree where you were using 'guix environment guix', and that 'guix environment' process was not running at the time of 'guix gc', then gzip can have been reclaimed <Apteryx>Ok. So since I build my "guix" using "guix environment guix" I should always run the gc from that same environment to prevent this kind of thing from happening? <davexunit>no, but the environment needs to be running. <Apteryx>davexunit: OK. I'm not aware of another mean of having an environment run but to "guix environment that-environment"? <davexunit>Apteryx: you said "always run the gc from that same environment" <davexunit>it doesn't matter where you run the gc from, is what I'm saying. <davexunit>all that matters is that your 'guix environment' process is stil running <davexunit>otherwise that stuff is free to be reclaimed <Apteryx>I could have multiple terms with one of those in "guix environment guix", and run "guix gc" in another, and it'd then preserve whatever is used in the guix environment. <davexunit>'guix gc' doesn't have to be run from within a 'guix environment' <Apteryx>Yes, got that :). Thanks for the explanation. <davexunit>it's a global effect on the system, running it from within any environment will produce the same result. <davexunit>since we're on the subject: who wants to implement 'guix environment --save' or whatever? <davexunit>it's just a matter of registering the generated profile as a gc root <Apteryx>davexunit: This would prevent it from being garbage collected without having it run, right? <Apteryx>And we'd have to implement a --load or --reload as well I guess? <davexunit>they all use the same stuff under the hood, but 'guix environment' doesn't expose the things that 'guix package' does <davexunit>I would like 'guix environment' with no arguments to load a profile from the current directory, if available. <davexunit>civodul: I think we're in a much better position than debian for this. <Apteryx>davexunit: Hmm. Maybe it could read from any file "guix environment ./my-environment" <davexunit>Apteryx: I don't follow, but my point is to have some conventional profile name that 'guix environment' can look for. <civodul>davexunit: yes; the comments about restarting services apply both to Debian and GuixSD <davexunit>civodul: I think we would need a way to do unattended rollback as well! <Apteryx>Or resolve the environment name in the current directory at first, then look for it in the conventional dir (/var/guix/...) <civodul>davexunit: sounds like an interesting concept :-) <davexunit>civodul: if I wasn't around to update the machine (say this was at work and I was off the clock) then I would like automated test that can determine if the upgrade is good or has broken my machine. <Helius>sneek: yes, running import from guix environment guix <civodul>right, though it seems difficult to answer the "is it broken?" question :-) <davexunit>sneek: later tell civodul in the case of a web application server, I'd like a test that would hit an endpoint on the local web server to see if it still returns a 200 <Apteryx>Yikes, my guix environment is broken from yesterdays garbage collection: No Guile development packages were found. When I run the ./bootstrap script. <Apteryx>Interestingly if I run "guile" in the environment it starts. <davexunit>a lot of the problems people mention in this LWN article are problems that GuixSD simply doesn't have <davexunit>so I think unattended upgrades will work well for us if we build in ways to minimize risk <davexunit>I really think we'll need a way to rollback without rebooting <Apteryx>davexunit: If the upgrade required rebooting it seems logical the downgrade would have to go through that as well (assuming you are talking about rolling back from say, a kernel upgrade). <Apteryx>Although it would be awesome to not have to. <davexunit>the only reason to reboot a guixsd machine is for a kernel update <Apteryx>Agreed. For the other use cases isn't it not already working without having to reboot? <davexunit>there are some tricky problems about how to deal with service upgrades <Apteryx>Tricky as in requiring something more involved than simply restarting them? <davexunit>sure, you can restart them, but if that's all we need I would never use guixsd on a production server. <Apteryx>I guess some services upon which guix depend (guix-daemon) must be carefully cared for. <davexunit>nginx can update configuration without restarting, absolutely crucial for production machines. <davexunit>you can also upgrade nginx binaries without downtime, also crucial. <Apteryx>That's neat. Didn't know about that. <davexunit>I should be able to run 'guix system reconfigure' and have the nginx service dealt with in the proper way. <Apteryx>I see. Lots of special cases to write. <davexunit>there's generic logic missing from shepherd and/or 'guix system reconfigure' <davexunit>there needs to be some hook that lets the people who writes services to specify what happens when the machine is reconfigured while the service is running. <Apteryx>Isn't it? Every application such as nginx might require its own special treatment when doing an upgrade to allow it to continue it to run without any interruption. <davexunit>but currently it's not possible to even do that <Apteryx>Agreed that guix should provide some hooks to accomodate for doing so. <davexunit>there's a generalized facility here that is missing <Apteryx>Any idea how to repair my semi-garbaged collected Guix environment? It still has links to store items which don't exist anymore. I can run ./bootstrap fine, but when I attempt make it screems that Guile is missing although it seems to be on my PATH. <Apteryx>Ah. Yes. with the localstatedir thingy. <Apteryx>What's the best way to try my newly complied package definition? I'm already in a "guix environment guix" env, can I simlpy layer on top "guix environment --ad-hoc my-package" ? ***jonsger1 is now known as jonsger
***jonsger1 is now known as jonsger
<Apteryx>Also, I'd be interested to see the sources after my substitute* rules have been applied. Any idea how to do this? <sneek>Welcome back ng0, you have 1 message. <ng0>is anyone interested in the progress with gnunet-service? as it's filebased now (like gnunet itself), I'm just trying to figure out how to deal with this old revision (0.10.1) again <ng0>I know there's this chmod_execbin function we use in the gentoo openrc service.. I only have it halfway replicated in shepherd <ng0>the current status is it bails out before it can start and shepherd isn't verbose enough to tell me why <ng0>so it's hard to figure out wether it's gnunet or shepherd <ng0>yeah.. I think I'll copy the current state back here and sent it, so someone can review the current state <geemili>The ConTeXt that is shipped with texlive has a shebang that isn't patched. <geemili>Specifically, `/gnu/store/.../share/texmf-dist/scripts/context/stubs/unix/mtxrun` <ng0>okay, email sent. I appreciate any testers and reviewers. <buenouanq>Anyone here figured out how to get spellcheck working in Claws-mail in GuixSD. <buenouanq>The error message is super helpful: Spell checker could not be started. Couldn't initialize None dictionary: (null) Couldn't initialize None speller. <geemili>Apteryx: There's a `--keep-failed` flag, but I don't think that's exactly what you want. <buenouanq>well, in ~/.claws-mail/clawsrc there's dictionary=None <buenouanq>I'm cautious to change these things manually, but maybe it's as simple as just putting the right path there <buenouanq>now the issue is that I can't find where aspell-dict-en is or what it's saved as <geemili>buenouanq: Does it have a command associated with it? <geemili>buenouanq: Can you use `which` to locate it? <NodeGuy>Hi. I'm new to GuixSD and would like to modify the xorg.scm package in order to add the VirtualBox video driver. Can someone give me a quick hint about how to find and modify the package? <cbaines>NodeGuy, the guix edit command might come in handy <buenouanq> found this: export ASPELL_CONF="${ASPELL_CONF:-"dict-dir ${GUIX_PROFILE:-$HOME/.guix-profile}/lib/aspell"}" <newdan>Is there a Nix expression for Guix? Having trouble getting configure to find libgcrypt on Ubuntu <civodul>newdan: perhaps you could use the binary installation method? <newdan>I already have 0.11.0 and that was the link I found on gnu.org <newdan>So if I download that and do `guix pull` it'll trigger the same very long update process? <civodul>oh, right, lfam mentioned it earlier <civodul>newdan: do you know exactly what's taking long, like what things are being built? <newdan>civodul: No, I'm not familiar enough with Guix and/or Guile (and/or building software, really) to say what was happening. But it was building a huge number of packages. I intended to just let it finished but it appeared to freeze after a while <civodul>coupld you paste the list of packages being built that appears just after you typed "guix pull"? <newdan>I'll let it run again, but I think it might be crashing trying to run tests for guile-ssh. Right now it's hung on the output "key.scm" but it could just be a slow test <civodul>and nothing after "phase `install-locale' succeeded after 0.0 seconds"? <newdan>I think it isn't building so much since I already had let it run for an hour or so, but I wouldn't be surprised if it was also building all the stuff listed in PATH <newdan>Oh no it keeps going on from there for a little bit, I assume with output from the guile-ssh build <newdan>Want me to copy the whole thing? <civodul>newdan: so it's really guile-ssh failing one of its tests here <civodul>unfortunately i don't have any simple workaround to offer <taylan>jeebus. I think the leptonica test failures expose a really weird bug in leptonica. some magic in leptonica turns "/tmp/..." into $TMPDIR/..., so when $TMPDIR starts with /tmp (but goes longer, like /tmp/foo), said magic effectively duplicates part of it; /tmp/foo/... becomes /tmp/foo/foo/... <taylan>just terrible, though strangely entertaining to discover <nliadm>I think this library's use of __DATE__ is my problem