<sneek>romulas, nckx says: So the reason I asked about trying another USB drive is that I had the same problem a while ago. Guix didn't even show up in the UEFI menu. There was no corruption. Wrote it to a different drive, worked fine. I don't think there's much we can do about that without some hint of an error message :-/
<sneek>romulas, nckx says: There are plenty of machines that hard-code something they shouldn't. You could try copying /EFI/Guix/grubx64.efi to EFI/boot/bootx64.efi.
<lispmacs[work]>leoprikler: I'm not sure of the nature of the problem, why mate cannot interact with my gnome keyring. But I'm getting a variety of interesting messages in the logs: http://dpaste.com/3MF5DP1
<ryanprior>jackhill "Most problems are in fact pretty much the same for most projects and the solutions for those are mostly boring."
<ryanprior>This tracks with my experience. I love boring tools that get common problems out of your way.
<Kozo>I have emacs-auto-complete installed but it's not auto completing my operators in emacs for common lisp. Anyone can point me in the right direction please?
<alduin>I've been thinking of trying out GuixSD, because the packagee manager seems interesting. But how does it work when you're regularly compiling and recompiling a binary, such as suckless utilities like st or dwm?
<lfam>alduin: Those are those programs you have to recompile to change a setting?
<alduin>Yes. They're small enough that this takes seconds.
<lfam>You would create a custom package recipe for them and edit that
<semper>Guix package -u keeps trying to redownload Icecat (360mb~) and LaTeX (2.5gb~) despite them being identical to the currently installed packages and not updates at all. Is this a bug? It's hard to tell sometimes.
<arend>and Void's community... is.... drama infested atm
<guix-vits>arend: idk about this matters, but please report the bugs to the developers. Many of them use Guix-on-Another scheme.
<guix-vits>semper: see the Cookbook, about the profiles. Install the Latex in a separate one, and update it not so frequently(?).
<guix-vits>i did similar to "The battle for Wesnoth". Actually packed it with `guix pack`, so no updates ever. Just unpack-n-go.
<semper>guix-vits: I'll look into that, because distro-hopping is not at all an appealing prospect. But I don't know why it's updating something with an exact copy of itself, redownloaded. Is that really not a bug?
<guix-vits>semper: IDK, totally. There are developers around... try ask again later. I'd not yet hit this one, no idea.
<semper>guix-vits: .0% substitutes available (0/1,) 0mb on disk, ending with a gateway timeout from ci.guix.gnu.org. I don't really know how to interpret any of that, but perhaps I misused guix gc.
<guix-vits>semper: i guess (without any proper understandin of things) that some dependencies was changed, or some "graft" (security-update) should be applied.. so (as there is no an ready to use binary substitute) you're downloading the sources to compile the icecat. I REALLY-MAY BE WRONG.
<guix-vits>semper: gateway time out is a bad thing. Though i can access ci.guix.gnu.org from my browser now (via Tor, though).
<guix-vits>Got 502 for `guix weather` too, at the end. Probably known issue.
<reepca>when I run next I can't seem to get M-l to work... it opens the minibuffer and promopts "Open URL in new buffer: " but any keys I press thereafter are ignored. next -v indicates that the keys are going through - it prints debugging info for each one - but somehow they aren't causing anything.
<PurpleSym>Hm, it’s unfortunately very difficult to reproduce the exact environment the guix-daemon uses for building stuff :/
<xelxebar>PurpleSym: AFAICT both --pure and -C are behaving the same. It's crucial to source the `environment-variables' file though.
<PurpleSym>Can you figure out what the failing tests are doing? Network-related stuff almost never works in the build environment.
<xelxebar>PurpleSym: Yeah, I am chatting with the developers on their channel, but we have a large timezone difference, and I'm having a hard time pinning down how to recreate the problem on their end.
<xelxebar>No network stuff. It's a package for an interpreted language. From what I gather, the tests for their jit compiler are working fine but executing the compiled code is what's failing...
<mroh>reepca: I cant reproduce this. what windowmanager do you use? maybe try asking in #next-browser?
<xelxebar>Separate question: When packing a git-revision source, what's a good way to get the sha256? I've been letting build just error out and tell me the correct hash, but running build again with a corrected hash ends up cloning the repo again. For a large repo this is slow and annoying to say the least.
<civodul>mothacehe: ok (i don't think i was particularly helpful tho :-))
<kondor[m]>I'm probably getting this for the n-th time: Unable to find remote helper for 'https' during git clone; apparently, this is connected to git being unable to locate libcurl; I do have libcurl under lib in the profile where git is installed
<civodul>normally the "r" option has it do the right thing
<_pm>Hi, I installed guix on Ubuntu 16.04 and when I do 'guix package -u' I get a warning 'guile: warning: failed to install locale' and then it returns without upgrading anything. I found lots of search hits but none of those helped me.
<sneek>lle-bout, marusich says: I intend to keep poking at this as time goes on. If we can't figure out how to make gcc reproducible, we may want to consider just biting the bullet and getting the bootstrap binaries in, but we can discuss that on guix-devel a bit, too.
<lle-bout>pm: if you want to upgrade packages you need to do: guix pull - then: guix package -u or guix upgrade - if upgrade does nothing then everything is up to date already!
<_pm>thanks for those responses. I know for sure that there is something to upgrade because I have another vm running guixsd and when I ran 'guix package -u' there it did do a lot up upgrades. This Ubuntu machine has not been updated in last 1 month so I am certain that there is some other issue. And yes I did 'guix pull' followed by guix package -u.
<lle-bout>pm: what is the return code of: guix package -u? You can check by running: echo $? - just after that
<lle-bout>If it's non-zero it means there was an error, otherwise everything is fine
<lle-bout>GNU Guix installed over Ubuntu would only update packages that are installed if you use: guix package -u
<civodul>NieDzejkob: do you confirm that nghttp2 1.40.0 and 1.41.0 are ABI-compatible?
<_pm>ll-about echo $? returns 0. So there is nothing to upgrade. Hmm. Okay I will take that for now.
<romulas>critial changes for the latest mesa, yes.
<romulas>Once you get in the latest kernel I mean.
<ryanprior>Guix has said for days that there's a new ungoogled-chromium but weather says it's not available and I refuse to build it on my laptop I'd rather switch to a flatpak or some other distribution mechanism rather than have to build the thing myself to get updates.
<ryanprior>Any other ungoogled-chromium users notice going a long time without substitutes? Are there other substitute servers that provide it more reliably?
<NieDzejkob>I wish we had a way of prioritising CI builds by how "important" a package is.
<jackhill>nckx's substitute server doesn't have it eaither
<jackhill>It does build, as I've built it locally.
<NieDzejkob>(I believe a good proxy for that is either how many times previous builds of the package were downloaded (perhaps corrected for how long a given version was available) or how long a build for a package took last time)
<NieDzejkob>I didn't know nckx runs a substitute server. Where could I read about it?