<vagrantcish>well, after stumbling through guix packaging, i come to find that python-pyelftools isn't in guix yet, and is a dependency for what i've been working on all day :) <siraben>What environment variable do I set so that Guix always builds my packages from sources? <vagrantcish>wow... i've just kind of been tinkering with guix for months now ... but to finally try and do something with it ... really amazing! <vagrantcish>learning guile is a bit of a steep learning curve still... <siraben>vagrantcish: What resources helped you out? I've just started using Guix for the past three weeks <siraben>I have the "failed to install locale" warning every time I invoke Guix package <siraben>Despite having installed glibc-locales <siraben>vagrantcish: Learning Scheme helps a lot with Guile <siraben>vagrantcish: I found Guile really nice as a language. <siraben>which part do you have trouble understanding in Guile? <vagrantcish>so far, i've pretty much exclusively been looking at guix packaging ... sometimes hard to know what's guile and what's guix and what's just a particular package <vagrantcish>siraben: honestly, i've mostly just done guix pull && guix package -u && guix system reconfigure ... up till today <vagrantcish>reported bugs and feature requests when i found them <siraben>What hardware are you running it on? <vagrantcish>siraben: not as my primary os .. the lack of a integrated verification chain for the builds kind of stops me from using it for many things <siraben>I thought the builds were reproducible because all the hashes of their dependencies are checked as well? <siraben>I need to get a model other than my current MacBook Pro, maybe a Thinkpad X200 <vagrantcish>siraben: they are, but the the git repository which tells you what the right outputs are, while signed commits, is not checked in any integrated way <vagrantcish>siraben: haven't tried the built-in wireless, i did have luck with a usb wireless adapter i have <siraben>vagrantcish: The commit aren't signed? How big of an issue is that? <vagrantcish>siraben: the commits are signed, but nothing checks them <vagrantcish>siraben: well, it kind of goes back to "can you make a computer that if you put the wrong numbers into it, the right ones will come out?" problem. <siraben>vagrantcish: How is there no trust path to the signers? Don't people cross-sign their GPG keys? <vagrantcish>and even if it was, if the tools don't check, are you going to check each and every commit message manually? <vagrantcish>siraben: even if a small pool of people were cross-signed, how can an outider verify the trust path? <siraben>Right so the issue is an automated system to check commit messages and find trust paths <vagrantcish>at this point, seeing how awesome the build system is, that's about the only thing blockinng me from using this on more serious things <vagrantcish>is there a mechanism to verify upstream gpg signatures on imported tarballs? <siraben>vagrantcish: How do I set it to build everything from source by default? <siraben>0ad is taking a long time to compile... <siraben>But building from source always seems more reliable <zybell>git by itself checks the repository, git tag -v checks the tag signature, gpg gives you the fingerprint of the key, the manual sows you what the fp should be. <siraben>How do I resolve the "failed to install locale" issue? <zybell>siraben:glibc changed file format for locale data. <siraben>Wow this isn't documented in the manual then <vagrantcish>well, after all that, the firefly-rk3399 still had the same problem i had with debian builds. <zybell>you will need to change the recipe for glibc a little <zybell>the locales cant be installed because they are in old format <siraben>Can you pastebin what it's supposed to look like? <zybell>I think at least, could be the other way round <zybell>the problem is a bug in the recipe <zybell>normally guix -i glibc had to run a recompile of glibc-locale because of deps <zybell>that didnt work because glibc-locale is strictly seen optional <zybell>that should get you a binary substitute <siraben>Right but I didn't authorize binaries <zybell>if not for special circumstances <zybell>there is a default key. idk if activated <vagrantcish>since most guix builds are reproducible, building locally seems like a very expensive version of rsync <vagrantcish>on the other hand, it's good to be able to run guix challenge <zybell>that is the idea! try guix challenge glibc <siraben>guix challenge: error: glibc-locale: unknown package <siraben>I got an inconclusive result for guix challenge glibc ***mteufel is now known as mt
<vagrantcish>is 32-bit x86 on guix i386-linux-gnu or i686-linux-gnu or ?? <efraim>i686-linux-gnu, unless it gets identified as i686-unknown-linux-gnu <rekado_>(the package is called “glibc-locales”, with a trailing “s”) <g_bor>Is there anything we need to do now regarding GSoC? <g_bor>What is the current stand on updating ant build system? Our whole java ecosystem is less than 300 packages, which branch should be targeted? <efraim>did we merge the update to java 8? <siraben>I have 1600 packages that reported no substitutes when running "guix challenge" <roptat>g_bor: did you see my reply to your patches? <rekado_>siraben: what do you mean by “reinstall”? <rekado_>g_bor: AFAIK there’s nothing to be done for GSoC. <g_bor>roptat: not yet I will have a look now <g_bor>efraim: not yet, it is still wip, just sent a few patches, but it is almost finished <g_bor>roptat: you are right, they don't need to be public. <siraben>rekado_: As in remove and then install using the binary substitutes again <siraben>Those 1600 packages were built from source <siraben>Doesn't have to be a fast operation, I can leave it running overnight <g_bor>Should I send an updated patch, or could you push with the proposed modification? This is actually the full bootstrap chain, I've just left it open, because we have a lot of dependencies on java-asm and java-jarjar (about 180 packages). <efraim>i forgot how long the rust test suite is <roptat>g_bor: under 300 packages it's fine to push to master <roptat>g_bor: pushed as bfb4004d3463a6857ff0aaeb9513a55c262970f0 <siraben>Anyone know how to reinstall the packages I have installed? <siraben>e.g. as if I removed all of them and installed all of them again <efraim>Did you install them or are they just available in your /gnu/store? <siraben>efraim: Most of them are dependencies for the 17 packages or so I installed. <siraben>But I want to reinstall all of them to run "guix challenge" because I was building from source previously <roptat>siraben: does "guix package --roll-back" work? <roptat>so you're on the previous generation, before the last guix package command <siraben>Right, but I want to reinstall all my packages <roptat>guix package --list-generations should show you all available generations <roptat>if you install a package say "guix package -i emacs" and then remove it ("guix package -r emacs"), after a roll-back, you're back at the generation where emacs was installed <roptat>if you ran other commands after that, you can still switch to a specific generation <siraben>Ok so what I could is roll all the way back then install my 17 packages, right? <siraben>How do I check that binary substitutes are enabled? <roptat>guix command --switch-generation 17 will get you back to generation 17 <roptat>you had them installed at some point, right? <roptat>so just switch to a generation where you have them installed <siraben>Ah, Guix provides such a nice capability <siraben>If I uninstall Emacs while its running, is that going to cause an issue? <roptat>it's going to create a new generation 25 that's based on the generation you've rolled back to <siraben>So nothing is really erased from the past <roptat>guix never removes a generation unless you tell it to <roptat>it removes anything that's not pointed to by a gc root (a generation of a user or system) <roptat>so you can always roll back to any generation even after a gc <siraben>Has anyone here managed to get GuixSD working on a MacBook Pro? <roptat>you can remove a generation with guix package --delete-generations <roptat>then it will be garbage-collected <roptat>because I tend to build things that are not in any gc root <siraben>What does guix pack do? Allow a package to run on a different machine without any dependencies? <roptat>when I create a package definition, I build it and test it, then to the next until the application I actually want to install <roptat>so in the meantime, I have a few packages I don't want to gc, but nothing I want to install either <roptat>guix pack just gets the package and all its dependencies (recursively) and put them all in a single pack <siraben>Yeah, so then any Linux distribution can run them? <siraben>If I wanted to pack that so I could compile with a garbage collector on a different machine <siraben>e.g. guix pack libgc gcc-toolchain gcc emacs <siraben>Environment variables, that's what I meant <roptat>I don't use guix pack, but I think you should just adjust your environment <siraben>Oh no that's fine, my environment works <roptat>anyway I need to go, see you later :) <pkill9>i get a lot of warnigns of possibly unbound variables when running guix pull <siraben>Afterwards, make sure you run "guix package -i guix" and also "guix package -u" <pkill9>do i have to run `guix package -i guix` for every user? <pkill9>i'm running `guix pull && guxi system reconfigure config.scm` <pkill9>surely that will install guix automatically? <rekado_>you don’t need to run “guix package -i guix”. <pkill9>warning: '.desktop' file refers to '', which cannot be found <pkill9>second question, how do i wrap a binary such that it adds flags to the executable, e.g. `executeable --flag value` <efraim>Probably that the EXEC path is 'foo' and not '/path/in/the/store/foo' <buenouanq>I'm trying to run the nginx service with an existing nginx config file - It successfully reads the file, but it's still doing strange unwanted redirects and I can't figure it out. <pkill9>what package is the archiving binary 'ar' in? <ryanprior>How do you find out what package owns a given file? <efraim>apt-file search on a debian box or 'find /gnu/store -name foo' <verisimilitude>/gnu/store/xlwzwcgmqb2z4n36rr5wh9l6xc7yp976-ccl-1.11/lib/x86-headers/libc/constants.cdb <rekado_>verisimilitude: could you please report this as a bug by sending a description of the problem to bug-guix@gnu.org? <verisimilitude>I'll make certain to watch the archive until I'm certain it was properly sent. <vagrantc>ok, after one day of building software with guix, my debian package build environment feels slow and cumbersome <pkill9>does `guix build` not take particular outputs, for example `guix build gcc:lib`?