IRC channel logs


back to list of logs

<Apteryx>Steap: I filter on Return-Path.
<Steap>Apteryx: makes sense
<Apteryx>If you use Gnus I can share a useful splitting rules snippet.
<laertus>when i tried to follow civodul's instructions above to clone then checkout the commit that i found the hash of in "guix edit guile-git", then "rm -fr .git" in that directory and then do a "guix download file:///that/directory"
<laertus>i got: "guix download: error: build failed: regular file expected"
<laertus>what am i doing wrong?
***Piece_Maker is now known as Acou_Bass
<Apteryx>laertus: there's a section in the manual where it is explained how to get the hash of a git checkout
<laertus>i got the hash
<laertus>i'm just having a problem with the "guix download" command
<laertus>i was able to do the git checkout of the right hash just fine
<Apteryx>hm, what are you trying to achieve with the "guix download" command?
<Apteryx>You want to add it to the store?
<laertus>well, i was getting this error from guix pull: "fatal: repository ''; not found"
<laertus>tail end of a log of my guix pull:
<laertus>and civodul said: "the repo has changed URLs, it's now at guile-git/guile-git"
<laertus>"so either you enable substitutes temporarily while you run "guix build -S guile-git""
<laertus>"or you clone the repo and then "guix download" from the local checkout"
<laertus>so i was trying the 2nd option
<laertus>per his instructions, which i mentioned earlier
<Apteryx>I'm not sure if guix download can work on directories. The doc doesn't mention it.
<Apteryx>do you have a copy of guix? You could simply fix the package uri, run ./pre-inst-env guix pull to make sure it works, and then send the patch!
<laertus>well, i can run "guix pull", so i presume i do have guix on my system
<Apteryx>guix pulls gives you a read-only guix copy in the /gnu/store
<laertus>this was the first "guix pull" that i've done
<laertus>and it never completed
<Apteryx>it's nice as a user and prevents breaking it, but when we want to fix a package we need a local guix checkout.
<Apteryx>Let's see if there's a substitute available.
<laertus>i've been wanting to avoid substitutes
<laertus>that's why i've been running guix with --no-substitutes and finding all these lovely errors :)
<Apteryx>OK. No problem then. There are many ways to get passed that problem. I have another idea.
<Apteryx>Hm. The package is already fixed in Guix since the 1st of July.
<laertus>i started with guix 0.13 i think
<laertus>is it part of that?
<Apteryx>0.13.0 was released end of May, so that explains why you don't have that.
<Apteryx>and it seems you now need guile-git to update using guix pull, hmm.
<Apteryx>I also get: guix download: error: build failed: regular file expected when trying to add a directory.
<Apteryx>I think it only works with files. So you need another way.
<laertus>ACTION nods
<laertus>and i expect i can't just tar/gz up that directory and give it to guix download that way?
<Apteryx>I think you need to get it to the store in the exact form it would have been if it would have been fetched from git.
<Apteryx>So probably no.
<Apteryx>I'm looking at my guile-git entries under /gnu/store
<Apteryx>it's not compressed, no.
<Apteryx>Tough luck. I think I'd just use a guix checkout, build it locally, pull from that, and then go on with life.
<Apteryx>It'll have the interesting side effect of having you setup what you'd need to contribute a package or any change to Guix anyway, which comes handy when we find a problem we want to fix ourselves.
<laertus>ok, so you're recommending i just build myself a new version of guix?
<Apteryx>unless someone else knows better, that'd be my suggestion, yes.
<laertus>that sounds like a good plan to me
<laertus>how do i do it?
<Apteryx>Have a look at the "Contributing" chapter of the manual. It covers the basics.
<laertus>ok, cool
<Apteryx>If you have any question, ask away!
<laertus>i actually have one now...
<laertus>i presume the procedure there will also integrate the newly built guix in to /gnu/store somehow, so it's part of my guix install?
<laertus>or is it going to stay separate?
<happy_gnu[m]>Has anyone tried to package gnash?
<happy_gnu[m]>I don't see it in the repos
<happy_gnu[m]>A ver
<happy_gnu[m]>Ve a aquí
<Apteryx>laertus: guix pull always end putting something in your store, no matter what guix was used to run it.
<laertus>ah, ok
<Apteryx>and it will cause your ~/.config/guix/latest symlink to point to that item in the store.
<Apteryx>happy_gnu[m]: indeed, doesn't seem to be packaged.
<happy_gnu[m]>Yes Apteryx I can try to package it :)
<laertus>Apteryx: the "Building from Git" section of the reference manual says "run ./configure as usual. Make sure to pass --localstatedir=directory where directory is the localstatedir value used by your current installation" and points me to "The Store" section of the manual for more info
<laertus>that section says "This database resides in localstatedir/guix/db, where localstatedir is the state directory specified via --localstatedir at configure time, usually /var"
<laertus>how do i know what -localstatedir was at configure time?
<laertus>should i just try --localstatedir=/var ?
<Apteryx>laertus: exactly
<Apteryx>I agree this part is a bit hard to follow...
<Apteryx>It's worded that way because it could differ depending on your distribution (if you were using a foreign distribution instead of GuixSD). On GuixSD, it's /var
<Apteryx>happy_gnu[m]: go for it :)
<happy_gnu[m]>Great :)
<laertus>it'd be nice if it said something to the effect of "if you're using the guix binary that you did not build yourself and you're not on GuixSD, then just use --localstatedir=/var"
<Apteryx>laertus: maybe send this suggestion to guix-users or guix-devel!
<laertus>good idea
<civodul>Hello Guix!
<rekado>ACTION fixes pandas and scipy
<efraim>python-pandas, python-cffi and ruby-concurrent are on my hit list, they don't like building on aarch64
<efraim>configure: error: The current version of Virtuoso Open Source Edition (Column Store) can only be build on 64bit platforms
<efraim>^^ well that's an easy fix
<Sleep_Walker>is it possible to send patches as e-mails directly from magit?
<rekado>Sleep_Walker: afaik it is a planned feature.
<rekado>you can format a patch with magit, however, so it shouldn’t be too hard to write some glue to take that patch file and run git send-email on it.
<rekado>In the future we should upgrade scipy together with numpy whenever possible
<rekado>the scipy developers don’t seem to fix bugs in older versions when building with slightly more recent versions of numpy
<Sleep_Walker>I'm just curious as it is something I'd use heavily
<Sleep_Walker>yay, sending patches to Guix once again :)
<civodul>rekado: someone upgraded numpy recently no?
<civodul>hey, wb Sleep_Walker :-)
<rekado>civodul: on Sept 26 numpy was upgraded to 1.13.1.
<rekado>that seems to have broken a couple of packages.
<civodul>oh, i see
<rekado>for cuirass I’d like to have a way to display build failures that are important to me.
<civodul>rekado: BTW, we need to reconfigure berlin with the latest maintenance.git
<rekado>+ maybe a report email.
<civodul>apparently nginx lacks the thing that redirects /api URLs
<rekado>I’ll reconfigure it today
<civodul>you could "herd stop nginx" just before
<civodul>howdy wigust!
<civodul>wigust: i just saw your subscription request to guix-sysadmin
<civodul>are you sure you want to subscribe? [ ] OK [ ] Cancel
<civodul>(you're welcome to help on that front obviously, just checking)
<wigust>civodul: Hello! [x] OK :-) Yes, I'm interested in.
<civodul>awesome, i've added you :-)
<wigust>Thank you!
<rekado>civodul: berlin has been reconfigured
<efraim>for our next core-update cycle do we want to upgrade our default gcc to gcc-6?
<civodul>efraim: sure
<rekado>civodul: thank you for the weak-table patches!
<rekado>hmm, all packages using the numpy setuptools extensions fail
<rekado>can’t build numexpr either
<rekado>the error is always that some gcc or g++ command fails with error 127
<efraim>Out of memory? Or is that error 4
<rekado>I think it’s “file not found”.
<rekado>the upgrade changed numpy/distutils/
<rekado>it passes -MMD and -MF to the compiler and a “.d” file
<rekado>hmm, that stuff works outside of the build container
<rekado>civodul: I reconfigured berlin (with cuirass and nginx stopped), but /build and /api don’t seem to behave correctly
<rekado>ah, had to remove /var/run/cuirass/cuirass.db
<rekado>argh! numpy uses /bin/sh
<rekado>setting the SHELL environment variable fixes everything
<rekado>so… guess we’ll have to fix this in numpy
<rekado>fixed, but builds are very slow
<civodul>rekado: i must have messed up with the nginx config, dunno
<efraim>i finally realized that gcc-boot0's native-arguments uses alist-remove until its down to an empty list
<efraim>the only thing I can think that might be missing with Apteryx's patch is removing the duplicate man pages from custom-gcc, and that's fine
<rekado>something’s really wrong with pandas
<rekado>30 test failures and 2247 errors :(
<efraim>is it related to the cython update?
<civodul>rekado: trying to be reassuring, but 2K failures is often easier to debug than a single test failure :-)
<rekado>I have an idea about the 2k failures, but the 30 other failures look bad
<rekado>and it’s annoying that I need to recompile numpy and scipy each time I update a package that might fix things
<civodul>dustyweb: hey, Dirvish & co. are pretty much ready to go: :-)
<civodul>ACTION calls for a release \\o/
<rekado>ACTION feels that a lot is broken right now :(
<rekado>the scipy tests take several hours and use a lot of RAM
<rekado>maybe we should switch to the “fast” test set instead of “full”.
<rekado>ACTION tries to build python-pandas again…
<civodul>rekado: yeah i also have that feeling of brokenness
<civodul>what keeps me awake at night are the two compiler/libguile bugs: the one you reported, and the weak-table thing
<rekado>about guix pull: can we revert to using a single guile process for the compilation of each file?
<civodul>hmm yeah
<rekado>it’s going to be slower, but I think that’s better than the current situation where we have a pretty narrow range of machines where it actually works
<civodul>could you try reverting f07041f7d25badb7d74b8fad6ee446a12af04f63 and see how that performs?
<rekado>ACTION still hasn’t succeeded in upgrading guix on the big 1.5TB RAM server
<rekado>civodul: okay, I’ll give that a try tonight on my i686 with 1GB RAM.
<rekado>ACTION goes home
<dustyweb>civodul: you're right!
<dustyweb>ACTION adds to the TODO list
<dustyweb>civodul: kind of a cool aside, I am in a room with Mark Miller of capabilities / erights!
<dustyweb>and he is going to be talking about capabilities things
<dustyweb>actually this is more #guile appropriate :)
<civodul>dustyweb: ooh, i'm a big fan of Mark Miller's work
<civodul>well, from the old days :-)
<laertus>when doing a "guix environment guix" i got a "warning: collision encountered: /gnu/store/ri56wnmzkgzrajdyl5ydc55lrwy1164k-ld-wrapper-0/bin/ld /gnu/store/zq65kpvwwxgc3qqbf9apic8gyss2l0zq-binutils-2.27/bin/ld"
<laertus>"warning: arbitrarily choosing /gnu/store/ri56wnmzkgzrajdyl5ydc55lrwy1164k-ld-wrapper-0/bin/ld"
<laertus>are these benign errors?
<rekado>laertus: these are benign warnings.
<rekado>it means that two packages both provide a file of the same name
<rekado>Guix just picks the first, because in a single profile you can’t have two files of the same name.
<laertus>i see
<rekado>the ld-wrapper’s ld happens to be the better choice here
<rekado>I’m now running “guix pull” after reverting f07041f7d25badb7d74b8fad6ee446a12af04f63
<rekado>it is very slow
<laertus>i'm trying to build guix from scratch, and i'm following the instructions here:
<laertus>i did "guix environment guix"
<laertus>the next step is to "Run ./bootstrap to generate the build system infrastructure using Autoconf and Automake."
<laertus>i don't have a "./bootstrap"
<laertus>i presume they mean the "./bootstrap" from the guix git source code
<laertus>but there's no link to it on that page
<laertus>so i don't have it yet
<laertus>where do i get it?
<bavier>laertus: have you clone the git repo?
<lfam>laertus: This is the canonical Guix source repository:
<laertus>bavier: i haven't because i don't know where it is.. there's no link to it on that "Building from Git" reference manual page
<laertus>lfam: thanks
<bavier>laertus: sorry, I misunderstood what link you were asking about
<jonsger>laertus: yes, there is room for improvement in that part of the documentation :)
<bavier>rekado: is reverting that commit meant as a workaround for the guile memory problem?
<lfam>laertus, jonsger: The latest revision of the manual (in Git) includes instructions about where to get the source code
<laertus>lfam: that's only helpful if you know where to clone the git repo from ;)
<lfam>The web-based manual is kept synchronized with the latest release... I know, it's annoying to not have the latest copy online.
<rekado>bavier: yes. I’d like to be able to run “guix pull” again on systems with very large and very little memory
<lfam>Now you can do `make doc/guix.html` and browse the latest revision of the manual locally :)
<lfam>Also, on GuixSD, `info guix` should show you the manual revision corresponding to `guix --version`
<jonsger>lfam: okay :) thats annoying, we should maybe offer both. the stable and the recent version
<lfam>I agree, it would be an improvement
<lfam>Although... it would cause a different sort of confusion. The situation will never be perfect :)
<rekado>well, we could name it differently
<rekado>but wasn’t the problem that uses CVS and thus makes it harder for us to just publish an up-to-date version of the manual?
<lfam>I actually don't know how the manual is deployed
<laertus>when doing a "./configure --localstatedir=/var" i got a configure error: "No Guile development packages were found."
<lfam>Although I think the default manual should correspond to the latest release, we should be pushing "bug fixes" to it
<lfam>laertus: Are you building Guix from the v0.13.0 release tag, or the latest revision?
<laertus>from git
<rekado>lfam: according to the release documentation it’s generated with gnulib’s gendocs, and then manually deployed to the website
<rekado>(which is under CVS)
<lfam>laertus: Okay, I would start debugging by making sure you are still in the `guix environment guix` (and I recommend adding --pure to that command), and inspecting the result of `env`
<laertus>when i do an "env | grep GUIX" i see "GUIX_ENVIRONMENT=/gnu/store/jqs80jq4j9z06p2vb9f7djv9k7jmc3d4-profile"
<laertus> i don't see that in a fresh shell
<lfam>Right, that's what `guix environment` does: changes the environment variables
<lfam>Go into that profile directory and see if Guile is in there
<laertus> /gnu/store/jqs80jq4j9z06p2vb9f7djv9k7jmc3d4-profile/bin/guile -> /gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guile
<lfam>I *think* the relevant variable is LIBRARY_PATH, which should point to /gnu/store/...-profile/lib
<lfam>Right, check if it contains libguile :)
<lfam>If it does, I would re-try configuring, but with the --pure argument to `guix environment guix`
<laertus> /gnu/store/jqs80jq4j9z06p2vb9f7djv9k7jmc3d4-profile/lib/ -> /gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/lib/
<laertus>what doe --pure do?
<lfam>Try `guix environment --help` :)
<laertus>i see
<lfam>The point is that, without it, there's a chance that extraneous environment variables will effect the build in unexpected ways
<lfam>Or, affect
<laertus>ok, it's failing with the same error even with --pure
<lfam>Can you put the full output of configuring on
<laertus>sure... just a sec
<laertus>dos it have to be that pastebin, or can i use another?
<lfam>You can use another if you prefer
<lfam>Some of them are not accessible for some Guix developers, but I should be able to view any of them
<laertus>oh, wait
<laertus>i think i put the --pure flag in the wrong place
<laertus>i did a "guix environment guix --pure"
<laertus>wheni should have done "guix environment --pure guix"
<lfam>Try it?
<lfam>I don't think that flag is positional, but you might as well
<laertus>actually, i'm pretty sure "guix environment guix --pure" did change my environment, because stuff started to break and i had to fix it
<lfam>It shouldn't affect anything outside of the session in the terminal where you run it
<laertus>but, yeah, i just tried it with "guix environment --pure guix" and got the same error
<lfam>Can you also paste the result of `env` in the environment?
<laertus>it didn't affect anything in the shell that i ran it in, but it did affect the new shell it put me in to
<laertus>it definitely still has a ton of my local enviornment vars there
<laertus>no matter where i put the --pure flag
<lfam>Okay, that's a problem
<lfam>If you're using Bash, I assume your ~/.bashrc is exporting environment variables, which is incorrect. That should only be done in ~/.bash_profile.
<laertus>i'm using zsh
<lfam>Okay, then ~/.zshrc vs ~/.zprofile
<laertus>yeah, i have a lot of stuff in .bashrc
<laertus>i mean .zshrc
<laertus>ok, i'll alter my startup scripts to just use .zprofile
<lfam>I didn't grok the difference between login and interactive shells until I started using `guix environment`. But the point is that environment variables should only be exported in login shells ~/.zprofile. Otherwise it's impossible for applications to launch new interactive shells (~/.zshrc) cleanly
<laertus>i understand the difference
<lfam>Cool, you're ahead of the game
<laertus>and this is going to be inconvenient for me in the long run, because i frequently alter my .zshrc and don't want to have to log out and log back in to get the new changes
<laertus>i'll have to think of a compromise
<laertus>but that can wait
<laertus>i'll just get guix working first, if i can
<lfam>You can use `zsh -l` to launch a new login shell immediately
<laertus>yeah, but then i'll have to do that for every new shell
<laertus>and i spawn shells all the time
<lfam>Yes, inconvenient
<laertus>anyway, i think for just this guix build i can try moving my .zshrc aside and see what happens
<laertus>hmm.. "configure: error: Guile-Git is missing; please install it."
<laertus>i don't think i have guile-git
<laertus>the whole reason i was trying to build guix from source is because "guix pull" was failing for me when it got to guile-git
<laertus>and i couldn't figure out a way to get it except from substitutes, and i don't want to use substitutes
<laertus>but since guix from git seems to depend on guile-git, i don't know what to do
<laertus>lfam: ping
<lfam>The issue with guile-git is that the upstream source URL was changed and there is no redirection from the old URL
<lfam>laertus ^
<laertus>civodul advised me: "so either you enable substitutes temporarily while you run "guix build -S guile-git"
<laertus>"or you clone the repo and then "guix download" from the local checkout"
<lfam>I saw in the logs that you learned you can't `guix download` a directory
<laertus>yeah, exactly
<lfam>I would use our substitute. The SHA256 hash verification is a strong guarantee that it's identical to what you'd get if the old guile-git site was still online
<lfam>Maybe there's a workaround to be found, but I haven't thought of one yet
<laertus>could i alter the guix build scripts to just use my regular system git?
<lfam>Perhaps? This is uncharted territory :)
<laertus>the best kind :)
<laertus>i'm not sure if i'm ready to go there, though...
<laertus>if it's not simple
<laertus>i'm going to peek in the build scripts...
<laertus>oh, btw, i don't need to do a "./bootstrap" every time i get a new shell with "guix environment guix --pure" do i?
<laertus>just the first time, right?
<laertus>ok, cool, thanks
<rekado>bootstrap generates the “configure” script from “”
<rekado>unless you change “” you have no reason to run “bootstrap” again.
<laertus>ACTION nods
<laertus>make sense
<laertus>ok... not easy
<laertus>i'd have to at least reimplement the various guix-git calls that the guix source uses to instead use my system git
<laertus>or change all those calls to use the system git directly
<laertus>definitely not a job i relish doing
<laertus>so how would i use that substitute just for guile-git?
***jonsger1 is now known as jonsger
***jonsger1 is now known as jonsger
<laertus>i think "guix environment guix --pure" should be able to start at least zsh with the -f flag to bypass the user's init files
<laertus>if it does that, there should be no need for me to mess with my .zshrc just to satisfy guix
<laertus>there's probably a corresponding bash flag as well
<laertus>hmm... or maybe not... i think i need to test this more
<laertus>ok, looks like the magic invocation for a zsh that doesn't contain my environment vars or source my zsh init files is: "env -i zsh -f"
<laertus>it's be nice if "guix environment guix --pure" did that
<laertus>actually... it looks like i can just run: "env -i /usr/local/bin/guix environment guix --pure"
<laertus>that works :)
<lfam>laertus: "so how would i use that substitute just for guile-git?"
<lfam>You'd only need to enable substitutes when doing `guix build --source guile-git`
<laertus>it won't use substitutes for any dependencies of guile-git?
<lfam>Assuming you're running the guix-dameon with --no-substitutes, no
<laertus>so i'd do "guix build --substitutes guile-git" ?
<lfam>No, something like `guix build --source --substitute-urls= guile-git`. I don't know whether or not the daemon will respect --substitute-urls if it's launched with --no-substitutes
<laertus>well, one way to find out...
<lfam>This will only use a substitute for the source code of guile-git. You'll still build guile-git locally
<mm__>hi all
<lfam>Hi mm__
<laertus>"fatal: repository '' not found"
<lfam>Okay laertus, I recommend restarting the guix-daemon without --no-substitutes and trying again
<rekado>laertus: have you tried just installing guile-git without guix?
<laertus>i don't think i have
<laertus>though i've tried so many things by now... i'm starting to get a little muddled.. but i'm pretty sure i haven't
<mm__>im trying to compile guix on trisquel 7, and i get this error: "configure: error: 'guild' binary not found; please check your guile-2.x installation." but when i have guild installed
<mm__>"whereis guild" output:"guild: /usr/bin/guild /usr/bin/X11/guild"
<mm__>what can i do?
<laertus>lfam: even when i start guix-daemon without --no-substitutes i still get the same error
<lfam>mm__: I'm not sure. If nobody has any advice here, I recommend emailing your question to <>
<mm__>ok, maybe i will try to write email, but first i will try on some newest system
<Apteryx>laertus: arg, I see that my suggestion to use the latest guix from git was misguided... Sorry!
<alezost>mm__: check "guile --version"
<mm__>alezost, "guile (GNU Guile) 2.0.9"
<laertus>alezost: good call... it looks like it's using my system guile, which is 1.8.8
<laertus>oh, that was to mm.... :)
<Apteryx>laertus: it seems your version of guix won't allow you to move further. Maybe you could try a 'guix pack' of guix itself? I you don't mind putting the trust in one of us, we could provide such an archive to be unpacked in your store... and then you could use that to bootstrap a recent guix.
<alezost>mm__: this version should be enough; I see "whereis" also shows some other "guild"; run "guild" to check it comes from Guile
<Apteryx>laertus: but if you could fetch the fixed-content (source) substitute you need for guile-git, that'd be ideal as you wouldn't need trusting more than that substitute.
<mm__>alezost, "guild (GNU Guile) 2.0.9"
<laertus>Apteryx: how would i do that? (fixed-content)
<alezost>mm__: sorry, I don't know why you get that configure error then :-(
<mm__>ok, thanks for help :)
<laertus>or i guess i could just wait until a new version of guix comes out
<laertus>which has the right guix-guile repo location in it
<laertus>and use that
<Apteryx>laertus: I'm trying to find a mail civodul wrote about downloading substitutes straight from a substitute server (via http)
<Apteryx>It's mentioned in the 'guix publish' node of the manual.
<Apteryx>Example of uri:
<Apteryx>civodul: should this work:
<Apteryx>It returns: Resource not found: /file/1rdw2svz4pyislan7q67mnk70c13sczm-guile-git-0.0-2.06f9fc3-checkout
<Apteryx>oh, I got the URI wrong. Let me try again.
<Apteryx>Same result though:
<thomassgn>anyone using console or emacs mail clients? How do you configure like fetchmail or similar?
<thomassgn>Or, I guess, how do you get mail from the server AND send it out again?
<Apteryx>thomassgn: I use Gnus. Here's an intro guide:
<laertus>thomassgn: i use mbsync from the isync package
<Apteryx>You can probably get the core (imap fetch & smtp) configured with less than 10 lines of config.
<laertus>thomassgn: mbsync is just for getting mail from an IMAP server, to send mail i use msmtp
<laertus>and i use notmuch for mail, but i'm thinking of giving gnus a try
<thomassgn>cool. Apteryx Ye, I assumed it would be short. But I often struggle with email conf. once it is more than what you have in thunderbird and similar
<civodul>Apteryx: /file URLs only work for regular files, not for directories
<Apteryx>thunderbird has lots of knobs to tweak as well ;)
<civodul>we could/should fix that
<Apteryx>civodul: I see! Seems we have one case of guix 0.13.0 not being able to upgrade to latest using guix pull because of guile-git (laertus).
<laertus>i can't build guix from git source either
<Apteryx>laertus: would you like to try a guix pack of guix itself? That'd be easier than a reinstall and would get you going *now* with latest guix.
<laertus>because it can't find guile-git
<Apteryx>Seems we've exhausted the other possible workarounds.
<laertus>Apteryx: is there any way to verify that i'm getting an untampered package?
<Apteryx>I guess you could do 'guix gc --references /gnu/store/hash-guix-latest/' on the guix that was unpacked in your store, and then compare with what's in hydra (on the build farms)...
<Apteryx>or better, run 'guix build --check' on the dependencies to make sure you can reproduce them (with the latest guix).
<laertus>is that a post-hoc check, though?
<laertus>no chance that something naughty might have been done by the package before i check?
<Apteryx>guix derivations are not content addressed, so I don't think you could ensure that it wasn't tempered with. Someone correct me if I'm wrong!
<laertus>could i just look it over visually myself before i applied it?
<Apteryx>I guess you could diff the components of the pack (after extracting them somewhere) against derivations with the same hashes downloaded from the store.
<Apteryx>s/from the store/from one of the substitute servers/
<laertus>so i can look at the contents too
<laertus>and can i then install the pack directly from my filesystem?
<Apteryx>laertus: I'm pretty sure what unpack does is decompress & untar the archive to you store. So you could list the contents of the pack archive, install those to your store, and then inspect them before running that specific guix (it won't override your guix), you'll have to run it with teh full path /gnu/store/...-guix-from-guix-pack/bin/guix or similar.
<lfam>laertus: I just built Guix 0.13.0 and did `./pre-inst-env guix build --source guile-git--substitute-urls=`
<lfam>That worked
<lfam>I recommend trying again. It's possible that when you tried it, our caching server did not have what you were requesting, but it does now
<laertus>ah, but i was using --no-substitutes
<laertus>actually, i did try without the --no-substitutes once too
<laertus>i can try again
<lfam>I had suggested you use a substitute just for the source code of guile-git, and you said it didn't work. But perhaps we misunderstood each other
<laertus>no, no, you're right
<laertus>i was just getting confused with all the different things i tried.. mostly i did use --no-substitutes, but once i had tried without --no-substitutes, just for the "build --source guile-git --subsitute-urls="
<laertus>you are correct
<laertus>i just tried again, with my guix-daemon running without --no-substitutes, and i'm still getting the same error: "fatal: repository '' not found"
<laertus>a full log of the attempt:
<lfam>What is `guix --version`?
<laertus>weird.. it doesn't actually say
<laertus>here's what i get:
<laertus>but "which guix" reports "/usr/local/bin/guix" which is symlinked to /var/guix/profiles/per-user/root/guix-profile/bin/guix
<laertus>and that's symlinked to /gnu/store/vir3lrwqy50pr8fkaf3m091dgbrja2n6-guix-0.13.0/bin/guix
<laertus>the sha256 of that is f27b607de96c1e09c32659c724b5d9627432ea1e6ff6488c1e0f3a780517ce81
<laertus>actually, that's just a shell script that contains
<lfam>laertus: From your earlier paste: substitute: guix substitute: warning: ACL for archive imports seems to be uninitialized,
<lfam>You haven't authorized our substitute signing key, so you can't use substitutes even if you want to
<laertus>ah, yeah, i never did that
<lfam>It's step 7 in Binary Installation:
<lfam>You can authorize them, get the guile-git source code substitute, and then erase /etc/guix/acl to de-authorize the key
<laertus>where is /etc/guix/acl located on a non-GuixSD install?
<laertus>i'm on gentoo
<lfam>I use Guix on Debian and it's at /etc/guix/acl
<laertus>i don't even have an /etc/guix
<lfam>Did you authorize the key yet?
<laertus>working on it...
<laertus>i have to do it as root, right?
<lfam>The directory will be created when you authorize the key
<laertus>ah, ok
<lfam>Yes, as root
<laertus>ok, it did create /etc/guix as you said
<laertus>ok, let me try the guix build again...
<laertus>"@ substituter-succeeded /gnu/store/1rdw2svz4pyislan7q67mnk70c13sczm-guile-git-0.0-2.06f9fc3-checkout" "/gnu/store/1rdw2svz4pyislan7q67mnk70c13sczm-guile-git-0.0-2.06f9fc3-checkout"
<laertus>so should i just try a "guix pull" now? or should i try to continue building guix from git source instead?
<lfam>It's up to you :)
<lfam>Remember to deauthorize the key before going further, if you don't want to use more substitutes
<laertus>i did
<laertus>first thing i did :)
<laertus>i tried continuing the guix source build, but "./configure --localstatedir=/var" is still complaining that "Guile-Git is missing; please install it."
<lfam>Now you need to build guile-git. `guix build guile-git`
<laertus>ah, ok
<lfam>Or, something like that. I don't remember if you are using `guix environment` anymore :p
<laertus>for the attempt at building guix from git source i was under an "env -i guix environment guix --pure"
<laertus>but i have another shell which is just a regular shell, and that's where i just ran the "guix build guile-git"
<laertus>i'm not sure if it's best to always interact with guix under a "env -i guix environment guix --pure" just so my regular environment vars don't mess with it
<laertus>or if normally it shouldn't matter
<laertus>hmm... i'm getting a ton of errors like "ERROR: failed to create path for auto-compiled file "/gnu/store/5zx29y44nrqj0s8h3jlvlj82k8hj4dxs-guile-2.2.2/bin/guild""
<lfam>laertus: Those are harmless, they are really just warnings.
<laertus>ah, ok
<lfam>It's a side-effect of the transition from Guile 2.0 to Guile 2.2. Once your full Guix installation is upgraded to use Guile 2.2, these messages will go away
<laertus>alright, well, i got "@ build-succeeded /gnu/store/qiy2gcrwmfbi73g2c0nl1ibdvbkw5w1k-guile-git-0.0-2.06f9fc3.drv -" "/gnu/store/fs6ism783xcjhsg13s13zkdz7c4cp75d-guile-git-0.0-2.06f9fc3"
<laertus>but i get the same complaint from "./configure --localstatedir=/var" in guix git source: "Guile-Git is missing; please install it."
<lfam>I'd try something like this: `guix environment --pure guix --ad-hoc guile-git`
<laertus>i'm glad you know what you're doing... because with your help i'd be totally lost :)
<lfam>I only sort of know what I'm doing ;)
<laertus>ok, that looks better.. configure is getting a lot further now
<laertus>it's done yay :)
<lfam>I have to admit, this guile-git / gitlab issue has been pretty annoying. And your preference to not use substitutes makes these problems more prominent.
<lfam>We'd prefer if this stuff was easier, of course
<laertus>someone has to test the --no-substitutes option, right? :)
<civodul>as discussed before, the source could be retrieved by temporarily enabling substitutes and running "guix build -S guile-git"
<laertus>it's funny.. i guess i must be the sole person using --no-substitutes
<civodul>it's annoying, but it should work
<civodul>laertus: at least build farms are not using substitutes, and there are users as well
<laertus>i wonder how the build farms worked?
<civodul>but the thing is, they may have fetched that guile-git checkout before
<civodul>they have it in store
<laertus>i guess it might be a good idea to periodically have automated fetches of all the dependencies
<laertus>just to find the broken links
<laertus>and hash check 'em too
<laertus>or you could just wait for me to find them... eventually...
<laertus>anyway... thanks for your help!
<laertus>my guix make is chugging along now...
<laertus>after the make of guix is done, do i just do a "make install" and then a "guix pull"?
<ng0>hey, could anyone test my theory that getmail ~somehow~ broke in the last 3 days due to some package in its graph? I get errors with getmal 5.1 and 5.2 (5.2 is not in tree, been kinda busy fixing stuff)
<ng0>gotta go, I'll check back at around 0600 if there was a reply, otherwise I'll send a bug report
<civodul>rekado: berlin doesn't seem accessible over http
<civodul>for instance, this hangs: wget -O /dev/null
<civodul>whereas the https variant works
<civodul>hmm where was the guile-git issue discussed on the list?
<bavier>civodul: it was discussed on irc earlier
<bavier>idk if it was taken to the list yet
<bavier>the README mentions guile-gnutls as optional, but configure will not continue without them
<civodul>oh right, guix.texi is up-to-date, but README probably not
<civodul>ACTION -> zZz