<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>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!
<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.
<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>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.
<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.
<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>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
<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
<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?
<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>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 :)
<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.
<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 :-)
<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.
<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>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