<cbaines>Ended up starting again, as I messed up the partitioning, but I managed to successfully install :D <davexunit>hmmm, why doesn't lsh-authorize allow me to login with my ssh key... grr <lfam>We really got tangled up with some of these special python-2 variants we created ;) <lfam>I'm cleaning up the ones that are touched by python2-cryptography <dmarinoj>How does the nix importer work? I downloaded nixpkgs from the git repo and tried guix "import nix ~/path/to/nixpkgs libreoffice" but I got an error <dmarinoj>I know but just to test if it works, I tried stumpwm <mark_weaver>dmarinoj: I don't know any details of the nix important. I don't understand how it could ever work well, and I haven't heard of it being used in a long time. <davexunit>I wrote a program that runs on the remote machine that forwards stdin to the guix-daemon socket, and forwards output from that socket to stdout. an ssh session starts this program and reads/writes from/to the pipe, but the connection always fails. <davexunit>I mean, the connection is established, but the nix protocol handshake fails. <Jookia>Should Guix be compiling icecat? <Jookia>How would I match over an ADT in Guile? match() doesn't seem to really work for it, and case errors <davexunit>you can additionally match based on a predicate <Jookia>my matching just breaks the function <davexunit>(match some-record-type (($ <foo> x y z) ...)) <Jookia>is there a 'match all' that i can use <Jookia>i'm matching on a field of the record, trying to see if it's equal to 'test <Jookia>should i be putting something else? <davexunit>though using pattern matching for this is arguably not a great idea <lfam>sneek: later tell dmarinoj I think you need a working installation of the Nix package manager in order to use the nix importer. I've used it a couple times. It can only do the basic stuff. For complicated Nix package expressions you have to do the complicated stuff yourself. <Jookia>Building qemu seems to fail with "Could not open 'tests/acpi-test-disk.raw': No such file or directory" <Jookia>civodul: I've almost finished a patch series (need to clean it up) to add a (platform) field to <grub-configuration> that supports 'bios and 'libreboot, and some refactoring to be able to pass grub-configuration to install-grub directly <xd1le>civodul: just watched your fosdem talk. congratulations on another great presentation! :D <Jookia>It's frustrating that 'make check' doesn't work from an environment <Jookia>it seems to be broken due to a custom tmpdir <Jookia>Is there a way to use containers for building? <Sleep_Walker>(in scenario where Guix is on top of another distribution) <civodul>i'll see whether there's something that can be done about it <civodul>sounds like they didn't use the microphone's channel or something <Jookia>qemu gives me consistent test fails :( <xd1le>i listened on headphones from the link i gave, and it seemed fine to me <civodul>the link you gave is a different devroom, and sound is fine there <civodul>the distro devroom videos above have a lot of ambient noise <Jookia>Okay, so the test only fails when building <Jookia>I keep getting bitten by unreproducible build environments :( <xd1le>civodul: no i mean the first link with your talk <civodul>Jookia: non-determinic tests, i guess <Jookia>civodul: they're deterministic in that they fail when building but not afterwards <xd1le>civodul: i guess? but what i'm saying is i watched the same video without noticing too much <xd1le>but maybe it's because of headphones <xd1le>civodul: ah actually i agree <xd1le>i guess i was just too excited to notice with the distro devroom talk <boegel>civodul: what's the issue exactly? missing sound? <civodul>boegel: there's ambient noise on these videos <xd1le>sucks though about the talks they lost in k3201 <xd1le>i would have watched all of those lost ones <civodul>they lost talks in all the devrooms before 12:20 :-( <boegel>civodul: there's nothing much we can do about the abient noise <boegel>civodul: it's the mic cam, which is the only reason they have sound, I think <civodul>boegel: but we were wearing a mic like in the Guile devroom, do you think it was lost? <civodul>or are they just using the wrong channel? <civodul>i remember we changed the battery of the mic just before my talk <Jookia>[insert complaint about guix debugging support] <civodul>Jookia: to debug QEMU's failed tests? <Jookia>civodul: Yeah- All the debug methods I've been suggested, such as using keep-failed, stepping in to guix environment, sourcing the environment variables, running the commands the GNU system does (ie 'make check') are unable to reproduce the error and furthermore it uses a test framework that i have no idea how to use <civodul>the test framework is QEMU's though, none of Guix's business ;-) <Jookia>civodul: I can't build the package manually either as there's Guile code to modify/add phases that I can't translate in to Bash <Jookia>it's become my business since i can't get guix to run it :( <civodul>Jookia: so if you do "guix build qemu -K ; cd /tmp/guix-build-qemu* ; source environment-variables ; cd qemu-* ; make check -j4", it passes? <civodul>we've discussed it before, but running phases wouldn't buy you much in such a case <Jookia>I think so, but I'll test again to make sure <civodul>if tests pass when run this way, it could mean two things: <Jookia>oh look running it with -j2 fails it <civodul>1. tests are non-deterministic, no luck <Jookia>i forgot to add the -j and i guess multiple jobs break it <civodul>2. the chroot environment has something different that makes those tests fail <civodul>for instance, the chroot environment lacks /bin/s <Jookia>3. jookia forgot to add -j flags <civodul>you can tests hypothesis #2 using "guix environment --container" <civodul>it could be that tests randomly fail when run in parallel <Jookia>They consistently fail on-my-machine(tm) in parallel I think. --container gave me errors when trying to run 'make check' in it <civodul>and they consistently pass with "-j1" <Jookia>Does --container mount tmpdir at /tmp? Because I found that was an annoyance in guix environment <Jookia>I'm running it without -j2 now, perhaps -j1 will fail it somehow <civodul>maybe that's better discussed on the mailing list at this point :-) <Jookia>It probably is, and I apologize for being perhaps a bit ... I can't think of the word, but it's that behaviour you get when something doesn't work so you write 'X doesn't work' and then a dozen people prove you wrong and you get your solution finally. A bad feedback loop in FOSS <taylan>Jookia: cond is indeed the right thing to use in place of if/else-if chains in lisp/scheme, re. your question in #guile earlier <boegel>soooo many stuff fails when you try to build it in parallel <Jookia>civodul: I can confirm that parallel tests cause an error with building qemu on my system <civodul>Jookia: can you try #:parallel-tests? #f and run it with --rounds=3? <Jookia>civodul: I'll run it without the patch first then with it, both with --rounds=3 <Jookia>the change to parallel-tests i mean <Sleep_Walker>civodul: so, wouldn't be better for native package distribution of Guix to prepare the build tools during package build? (./configure && make && make install && systemctl start guix-daemon && guix build gcc-toolchain tar xz coreutils) <civodul>Sleep_Walker: starting the daemon would be nice, building stuff could take too long <Sleep_Walker>2] it is build once per release for whole distribution (unless dependencies change) <boegel>civodul: only one channel has sound for the distro devroom <Jookia>Sleep_Walker: I don't think GuixSD has a stable release yet <boegel>civodul: so, it's either sound with (a little bit, imho) ambient noise, or no sound, pick one! <Sleep_Walker>Jookia: I'm working on passing Guix RPM package to openSUSE Tumbleweed distribution <Sleep_Walker>Jookia: I'm trying to eliminate foreign binaries from the RPM <Sleep_Walker>Jookia: why to create Guix RPM package or why to install to system binary of unknown origin? :) <Jookia>Sleep_Walker: Why to not build the bootstrap binaries yourself <Sleep_Walker>Jookia: well, my first intention was to use binaries from system but davexunit was concerned by invalidating build <Jookia>I think the Guix binaries are reproducible <Jookia>So you could always build Guix using system binaries, then build Guix binaries, then ship those <Jookia>But if the binaries are identical, why bother? :P <Sleep_Walker>(which mates that lime with starting guix-daemon and building tools) <Sleep_Walker>(which matches that line with starting guix-daemon and building tools) <Jookia>Sleep_Walker: maybe it'd be worth just verifying the bootstrap binaries yourself then packaging them <Jookia>civodul: One round with parallel tests fails, Three rounds wtihout succeeds every time <civodul>Jookia: excellent, that's rather convincing evidence <civodul>i would expect the 3 rounds to take more time, but maybe you have a powerful machine ;-) <civodul>qemu-minimal is more reasonable, indeed <Jookia>I need KVM to create a VM image? <Jookia>Someone else will have to test my patch in an actual VM then <Jookia>I wonder why I need a running VM just to create an image <efraim>python-cython really does take forever to build <efraim>I wanted to see if sqlite-3.10.2 worked with python-sqlalchemy if we had to rebuild a lot, any python-cython is a beast to build <phant0mas>hey mark_weaver I noticed that setns in the (guix build syscalls) module uses (false-if-exception ...) which could be used for the other syscalls as well <phant0mas>does this introduce any per-call overhead as well? <NiAsterisk>regarding the thread about lispf4 on the devel list.. how do I know if what I push will work, when it works inside guix environment but does not work (permission levels?) outside of it? executable works fine, but for example SYSATOMS I can't access <NiAsterisk>not that I want to be pushy about this, but I am curious <civodul>phant0mas: i think the approach that mark_weaver proposed is better than wrapping the whole thing in false-if-exception <rekado>hmm, I cannot get guix web to work anymore <rekado>when I do "guix web" it complain about the command "web". <rekado>even though it does look in the directory where guix-web is installed. <rekado>(maybe it's a failure to load some dependency) <phant0mas>civodul: then maybe I should change setns to use mark's solution as well, WDYT? <civodul>phant0mas: maybe not; probably there's code that checks whether setns is #f <civodul>rekado: try "guile -c '(use-modules (guix scripts web))'" <rekado>civodul: ah, that helped: "ERROR: no code for module (json)" <rekado>ouch, now I get compilation errors: "ERROR: no such language tree-il" <rekado>and "ERROR: no such language bytecode" <rekado>guess it was a bad idea to install guile into that profile <Steap>DO we care about SOURCE_DATE_EPOCH? <civodul>that would allow non-root users to run their own guix-daemon etc. <davexunit>civodul: provided they can make a user namespace! <davexunit>except there are additional restrictions from unpriviliged namespaces, such as only being able to use a single UID/GID. <davexunit>I need to wrap my head around how to deal with uid/gid ranges <davexunit>I *think* there may be a way for an unprivileged user to map many uids <davexunit>provided that the sysadmin allows it in the first place <davexunit>civodul: this nix-user-chroot program must require root privileges. <davexunit>the name just says "chroot" so I didn't expect namespaces to be involved <civodul>yes, but i i think it's designed to use Nix without its daemon and thus without chroot builds & co. <civodul>yeah i don't think it's much used, but it's supported <civodul>no we don't, but i'm fine with that ;-) <civodul>basically all the Nix command-line tools are linked against libstore <civodul>so they can directly fiddle with the store and everything <davexunit>ACTION upgraded to shepherd for user service manager <myglc2>Has anyone seen problems with man pages being truncated? <Phlogistique>civodul | yeah i don't think it's much used, but it's supported <- well, the default nixpkgs install is nix without its daemon <Phlogistique>so I think it's the probably the most widely used configuration <Phlogistique>although prolly not among the devs as they tend to run NixOS <davexunit>waaat. people actualy use nix without a daemon? <Phlogistique>but when they do, well, /nix is just chown'd to their user <davexunit>another good example of the differences between nix and guix. <Phlogistique>in fact, the multi-user nixpkgs usecase is not used a lot outside of NixOS afaik <Phlogistique>davexunit: you mean that Guix does not support a single-user mode? <davexunit>you could run that daemon as an unprivileged user and forfeit the build isolation <civodul>Phlogistique: however, Nix outside of NixOS is really the case where the chroot env is important <civodul>otherwise there are lots of interference from the outside world <myglc2>I have emacs installed, which uses ncurses. Is there any way to read the ncurses man? <myglc2>Oh, DUH, I found Guix Package info page and clicked on "doc Install" <pecg>So far, so good, I've backed up all the important files, and in a moment I will start installing guixsd <CompanionCube>ACTION will try out guixsd on a partition/subvolume when it has btrfs support <myglc2>'git clone git://git.savannah.gnu.org/guix.git' is not working? <civodul>there's an FSF status stream somewhere, i always forget where <avoine>CompanionCube: do it on a partition because with subvolume you will get your fs tree corrupted <myglc2>Hey! A man page is truncated ~ 250 lines when it should be ~2500. Is there an easy way to tell if it was built on my machine or downloaded from hydra? (Note: I am messing with the recipe, but I think I rolled back to the stock version) <pecg>CompanionCube: I feel a little change resistance to btrfs <pecg>CompanionCube: I don't know, I sincerely don't have any arguments at all <pecg>I promise to look at the documentation and see if it fits my needs <avoine>CompanionCube: I wanted to do a patch for btrfs but my root file system got corrupted so I gave up on btrfs <pecg>B-tree stands for binary-tree in btrfs? <pecg>I ignore the advantages of filesystems. <pecg>Ext4 has worked good for me <pecg>that OS theory hasn't hit me yet. I will read about <avoine>CompanionCube: I would not wait for btrfs to try guix, its so much fun! <pecg>avoine: I won't wait, I'm eager to try it, ever since I heard the announcement <pecg>In fact it will be the default OS beginning today <pecg>mordocai: Are you there? <dannym>pecg: (B-Tree is not a binary tree. A binary tree node has (at most) two child nodes. A B tree node has (at most) hundreds of child nodes) <pecg>dannym: I didn't know that <myglc2>Is there a way to ask the daemon to remove a package from the store? <rekado>myglc2: you can use "guix gc -d /path/to/store/item" <rekado>if it is no longer referenced by anything else in the store it will be deleted. <davexunit>myglc2: if I may be a bit pedantic, there are no packages in the store. <davexunit>packages are a high-level Guix concept that the daemon/store has no knowledge of. <myglc2>Still trying to get my head wrapped around this universe. Cool though! <davexunit>packages are lowered to "derivations", which describe how to build them. <pecg>davexunit: makes them more flexible <davexunit>the derivation produces 1 or more store items which are the outputs of the build. <pecg>I've been thinking about guixsd and guix the whole week <pecg>davexunit: instead of 'produces' I would say 'returns' since it is the functional approach of guix <davexunit>I guess I'm speaking about the lower-level mechanism, rather than the higher-level semantics. <davexunit>under the hood, we're writing to an append-only database. <myglc2>This is a very beautiful approach, but the indirection is taking a while to absorb <davexunit>I think an infographic or something could go a long way in showing the various layers <myglc2>I think graphically and something like that would really help. <efraim>after 7.5 hours of compiling, I can say that updating sqlite to 3.10.2 and python-sqlalchemy to 1.0.11 doesn't fix the python-sqlalchemy problem <alezost>myglc2: re truncated man pages: sometimes I see this too, I just update a page in such a case. I think it's an Emacs issue rather then the Guix one <efraim>although I do have to mention that the tests for python-cython took 3 hours, and another 3 for python2-cython <pecg>efraim: 7.5 hours for compiling that? <alezost>myglc2: with 'Man-update-manpage' which is on "u" by default <myglc2>alezost: update a page? how? -???- Oh Duh 'u' Thanks <myglc2>davexunit: dynamically slithering pancakes. Hard to catch them in the act. <davexunit>for packages, the basic hierarchy is package -> "bag" -> derivation <myglc2>Didn't know about "bag". Is that the reduction of package.scm given to the deamon? <efraim>pecg: I'm running on a really slow computer <davexunit>myglc2: no, the derivation is the thing the daemon works with <davexunit>the "bag" is an intermediate representation of a package in which all "implicit inputs" provided by a package's build system are made explicit. <myglc2>Oh yeah there it is in your doc. Your doc is awesome. It is hard to figure out where to start eating. <myglc2>davexunit: So, if I make cosmetic changes to a .scm (e.g. comment or argument order) but the package is not rebuilt, is that because the "bag" has not changed? <davexunit>myglc2: comments and whitespace do not alter the object <myglc2>by "object" do you mean "bag", or something else? <davexunit>we can compute a hash for a package object based on its name, version, inputs, etc. <davexunit>and we wouldn't be able to do anything cool. <myglc2>davexunit: Yes, sure. I'm just curious about details that, as you say, don't really matter. <davexunit>myglc2: the bag discussion didn't matter to the discussion of reading source code, they do matter. <davexunit>but we were beginning to mix several things together <jlicht>I'm having some issues compiling libreCMC using the toolchain installed via guix (package manager) on 64-bit Ubuntu. Is there any way in which to have guix provide a <gnu/stubs-32.h> file? <myglc2>davexunit: guix uses indirection to do great magic. But things are not where you expect. I am testing guixSD which was not working at first, due to a couple bugs. Trying to figure out how guix works (or will when bugs are fixed) and/or what I am doing wrong or misunderstanding is like living in a wild house of curved mirrors. 'M-x guix-mind-expansion'. <paroneayea>myglc2: some of the mirrors may be curved in reflecting your profile, but Guix is like a funhouse run by Bill Nye and Neil Degrasse Tyson, handing out pamphlets explaining that none of it is in fact magic and we'd be more than happy to explain the science to you, look you can reproduce it yourself! <myglc2>davexunit: guix does not use magic to reproduce magical results :o) <myglc2>guix does not use magic so the user can reproduce magical results :o) <efraim>completely OT, but I have an arm board that I must've messed up the debootstrap, and I don't have ifconfig, ip, dhclient, vim, nano, etc. <efraim>luckily I do have dpkg, so time to get out the usb stick <dannym>efraim: it's in package "procps" <paroneayea>rekado: I don't have any useful input on your "leaky pipelines" email to put on list, but I do find it intersting and look forward to seeing where it goes <paroneayea>rekado: I had discussed with some blender users about using guix as a rendering pipeline system in a very similar fashion <paroneayea>davexunit: want to do a quick review so I can push up a security fix? <davexunit>paroneayea: could you check how many packages would have to be rebuilt? <paroneayea>Building the following 632 packages would ensure 1815 dependent packages are reb <davexunit>paroneayea: alright, I was anticipating something like that. <davexunit>this patch will have to go into a security updates branch and merged after we rebuild <paroneayea>I know how to push to security updates I mean... <davexunit>someone that can create new jobsets in hydra <paroneayea>messengers carrying patches don't get shot, right??? <paroneayea>davexunit: my favorite part of this security vulnerability page is that it points to links with file:/// <a_e>What a nightmare! The branch actually is around right now. <a_e>I suppose we will merge it tomorrow. <a_e>Now if we start from scratch now, it will take us another week. <paroneayea>in the meanwhile, be wary of people holding weird recording instruments! <paroneayea>is it just me or are we seeing vulnerabilities being churned out like crazy lately <mordocai>Yeah, I think it is partially due to more people starting to take a serious look at things. <paroneayea>guix is simultaneously easiser to deal with with all this security vulnerability stuff <paroneayea>maybe in the future where we all concurrently put our build resources in via peer to peer building... ;) <mordocai>So i've been having trouble where on my debian testing + guix box I can't connect to the guix daemon with any guix commands. I'm not overly familiar with how linux sockets are actually implemented, but the guix command complains connection refused on /var/guix/daemon-socket/socket. When I checked into this fuser claims no process is using that file and the /proc/{PID}/fd folder for the daemon shows: http://lpaste.net/151971. Can anyone <mordocai>tell from this what is going on, or give me further troubleshooting steps? <mordocai>paroneayea: So I started out with the binary installation but then at least attempted to migrate it to one based off the git source. Very possible I messed that up. <mordocai>Unfortunately it is hard to mess with at this point since I can't do guix environment guix anymore. <paroneayea>mordocai: ok, I don't know how the git install one works. ./configure && make will by default set up a different directory by default than it will in guixsd <paroneayea>mordocai: I'm not sure this will fix it, but maybe it will: <paroneayea>make clean && ./configure --localstatedir=/var && make <paroneayea>the challenge here is: I don't know where the tarball install puts things <mordocai>The tarball has you put the store in /gnu/ and the rest in /var/guix <mordocai>Alright, I'll have to get the dependencies to build guix through debian first <mordocai>I was building guix with guix but now guix is broken so... :( <paroneayea>so.... you might want to look at the patch I shot to the list <paroneayea>civodul: I guess for the next week we need to watch out for spooks carrying cool-looking equipment? :) <a_e>Indeed. It is known for quite a while now, actually. I think we could postpone it to the next core-updates cycle. <lfam>civodul, paroneayea: Whenever that patch gets pushed to security-updates, can you be sure to mention in the commit message the ID of the fixed CVE? <lfam>Or core-updates, wherever <civodul>i wonder if ECDH is widely used with OpenPGP <a_e>Only in the 2.1 version. <lfam>Off-topic, but is anyone having trouble reaching freenode and GNU servers (I know they aren't related)? I'm in the freenode webchat ATM. <a_e>I get a bit fed up with waiting for garbage collections, hydra evaluations and security update builds. <mordocai>thank goodness debian doesn't hate guile like gentoo <lfam>For example, I can't reach the gnupg keyserver ATM to verify the hash in your patch, paroneayea <a_e>More or less. I do not know about this concrete attack; the papers are not the same. <civodul>anyway, this team makes scary findings <a_e>So the general method is known since last year. <NiAsterisk>mordocai: offtopic and not promoting it, but i think some people who run a git with gentoo ebuilds where I contributed to on .onion have written a non-system breaking guile2 ebuild for gentoo <mordocai>Oh, versions hmm... i'm on debian testing <mordocai>Maybe? Idk. On my box libgcrypt20 is the package <mordocai>Yeah, i'm on debian testing though so a bit newer <mordocai>Ah, nevermind. I was just using guix but I needed to be using ./pre-inst-env guix <mordocai>And make install appears to have fixed that. Everything seems to be working now <lfam>Steap: I noticed your question about SOURCE_DATE_EPOCH. I believe we do care about it since it goes a long way towards achieving reproducible builds. <lfam>I wonder, is it causing a problem for you? <Steap>I thought just setting all timestamps to 0 was enough <Steap>using SOURCE_DATE_EPOCH means that the upstream devs have to make sure their build envs work properly <lfam>At the very least, we currently rely on it when building python-2 packages. It did not require any changes from upstream AFAIK. <lfam>It requires a little more work on our side, but I don't see a problem with that. <lfam>We patched the python-2 bytecode compiler to respect it if it's present, so that the bytecode does not contain timestamps in its headers. It seems like an easy win. <lfam>We have an open bug about doing the same for python-3, and we also need to figure out a way to apply it to python-2 itself. <civodul>rekado, iyzsong: thoughts about the GTK_DATA_PREFIX patch fhmgufs posted? <civodul>Steap: also, outside of the build env, those timestamps might actually be useful <lfam>Steap: Do you have an example of a situation where it interferes with upstream? <lfam>civodul: BTW, I'm really stumped on that python-3 bytecode patch. It's beyond my level of skill :-( <Steap>lfam: that is just what I understood from the talk about reproducible builds on FreeBSD <Steap>like, if the project ignores this environment variable, the timestamp wont be properly set <lfam>That's why we patched our python-2 compiler ;) <lfam>If we can make changes like that, that are internal to Guix and require no effort from upstream, then we should. Otherwise, upstream should really consider the benefits of their software building reproducibly. <Steap>yeah, I'm just wondering why it is suddenly needed <lfam>Because everyone suddenly realized the security implications of reproducible builds :) <Steap>we did not use this variable before <rekado>civodul: the GTK_DATA_PREFIX thing looks okay to me. <rekado>I didn't reply to the patch but on the discussion before that. <lfam>Steap: Have you tested the determinism of many packages? At the moment, most if not all of our python-3 packages are unreproducible due to timestamps in the bytecode headers. <rekado>It doesn't seem to have any negative effects on unrelated parts. (I only looked at the GTK3 sources, but the treatment of GTK_DATA_PREFIX hasn't changed according to the docs) <lfam>It's a real problem, and solving it will allow us to do very cool stuff with binary substitution. <lfam>Steap, yes, the .pyc and I think also the .pyo files <Steap>so that's what the FreeBSD guy was talking about <Steap>aren't we compiling these ourselves ? <lfam>Steap, we compile them at install time, which in Guix is basically indistinguishable from build time. The python bytecode compiler embeds the timestamp of the corresponding .py file. Since we don't want to reset all the source timestamps, we make the bytecode compiler respect SOURCE_DATE_EPOCH if it is set. <lfam>And it seems that the environment variable SOURCE_DATE_EPOCH was not used for anything in the past, so having it in the environment doesn't seem to break anything for build mechanisms that don't respect it. <lfam>I learned all this in the past two weeks, so I'm no expert ;) I'm happy to hear about improvements. ***wgreenhouse is now known as greenwasa
***greenwasa is now known as wgreenhouse
<dannym>hmm... does newest gcc and binutils work for anyone? I get "/home/dannym/.guix-profile/bin/ld: cannot find crt1.o: No such file or directory" for compiling a tiny example... <civodul>lfam: still, looks like you've become our reproducibility expert! :-) <civodul>dannym: instead of install binutils/gcc/libc in your profile, you need to install the 'gcc-toolchain' package <civodul>it includes 'ld-wrapper', which solves this problem <dannym>civodul: ah ok. Do I need to remove something from my profile first? Which ones? <lfam>civodul: Heh, I'm just trying to help where I can. <civodul>dannym: yes, you should remove binutils/gcc/libc (assuming that's what you had installed) <dannym>civodul: did that and guix package -i gcc-toolchain; error message is unchanged. <paroneayea>davexunit: I wrote up a draft of the talk description for the talk I'm hoping to make to various orgs here <paroneayea>You know that feeling: you want to upgrade your server, but you remember the last time you did it you had to stay up all weekend fixing all the things that break. Enter Guix and GuixSD: the package manager and distribution that put you in control! Fearlessly upgrade, and if something goes wrong, time travel back to a prior point (like git, for your whole operating system!). Additional features include per-user packaging (no need to <paroneayea>beg that sysadmin to install the latest version of GCC, you can install it yourself and affect nobody else), effortlessly support different versions of programs (that legacy application needs that old version of some library while the rest of the system needs to move on... no problem!), completely reproducible deployments, declarative configuration, container support, and much more. Guix(SD) is also the world's most scriptable package <paroneayea>management / distribution, making building new tooling easy. Come see live demonstrations of Guix and GuixSD in action, and a roadmap of the future to come! <civodul>dannym: uh, weird; did you do ". ~/.guix-profile/etc/profile"? <dannym>hmmm if I want to adapt source code (to fix bugs etc) of packages (I mean the actual client program), how do I do that? (a la "apt-get source") <lfam>dannym: Do you have Guix working from a Git checkout of the Guix source code? <lfam>That is really the best way to make changes of packages managed by Guix <lfam>In that case, you'll go into the Guix source tree, and do `tar xf $(./pre-inst-env guix build --source foo)`, where foo's source code is distributed as a tarball. If they use some other archive format, substitute that for tar. <mordocai>Btw, I posted a bug, but i've noticed that for some reason with sbcl installed on debian through guix (and not installed through apt) $SBCL_HOME is set to '/usr/lib/sbcl' which should be set to a guix directory. I can just unset it to fix this, but i haven't been able to figure out what is setting it. It is set both in zsh and bash but I can't find where it is being set. <dannym>lfam: I'm on a fresh install of guixsd... <lfam>mordocai: The string /usr/lib/sbcl, or the components of that string, must be in the source code somewhere. <lfam>It will explain how to build Guix from a Git checkout, which is a prerequisite to getting your changes into Guix. If the bug is not Guix specific and you want to get your fix upstream, it's still an easy way to build and test your changes using Guix. <lfam>Also, the dependencies described in 8.1 are all provided by `guix environment guix`. You don't need to install them into your profile. <lfam>And make sure that when you configure, you provide the right localstatedir. `./configure --localstatedir=/var` <mordocai>lfam: So `strings -n 3 .guix-profile/bin/sbcl | grep -i usr` gives nothing. Doesn't appear to be in the binary <mordocai>It isn't in .guix-profile/etc/profile either, and i'm not sourcing that currently <lfam>mordocai: Look in the package's source tarball <lfam>It is probably configurable in the build system <lfam>Or some hardcoded string that we can patch at build time <dannym>lfam: (In the Contributing document, there's only a placeholder "the Git repository" but it doesn't say where that is. Elsewhere for "guix build" it does.) <lfam>dannym: Are you familiar with using git? <dannym>lfam: yes, I'm using it daily. Also found the git URL. But I mean the docs don't say either the url nor the git clone command in the Contributing section <lfam>I think that section should be overhauled <mordocai>I just thought of an idea of what i might be. <dannym>lfam: ok, so I should do git clone ..., guix environment guix, then ./bootstrap as regular non-root user ? <lfam>dannym: clone, `guix environment guix`, ./bootstrap && ./configure --localstatedir=/var && make check <lfam>Then, you can use the Guix you have built by prefixing your commands with the ./pre-inst-env file in the Guix source tree. It will set your environment to use the compiled package definitions and tools in the source tree. <lfam>So, if I am testing a new package foo, I do `./pre-inst-env guix build foo` <lfam>You only need to be in the `guix environment guix` while you are building the source checkout, BTW. It's not necessary when you are doing things with ./pre-inst-env <mordocai>If I get an error like "ld-wrapper: error: attempt to use impure library "/usr/lib/x86_64-linux-gnu/libc.so"" should I guix package -i glibc? <mordocai>I'm trying to do some ruby stuff that ends up compiling c extensions <mordocai>I can paste the whole thing if it is important <lfam>I've never looked at Ruby :/ <lfam>Most software lets you configure the paths to things like that at build time <fhmgufs>How can I make 'guix' build rebuilding things and not to use the already built ones? <lfam>But I have no idea how Ruby software gets built <lfam>Assuming you are looking for nondeterminism. Otherwise, there's no point. <lfam>If it is reusing what's in the store, it's because your package definitions are exactly the same as before <lfam>Or rather, the package definitions may appear different, but they result in the same derivation, or something like that ;) Best someone else explains that part of it <mordocai>I may have to avoid using guix stuff for my ruby stuff for work <a_e>mordocai: Pjotr Prins is very interested in ruby. Maybe you should get in contact with him via the mailing list. <lfam>There are some Guix people working with Ruby. If you `git blame` those packages you will know who to ask ;) <mordocai>Well atm I just need to return to my work :P <a_e>Also davexunit has worked a lot on ruby. <fhmgufs>lfam: Thanks, I know, but I think only different inputs result in a different derivation. <a_e>mordocai: Maybe you can work on ruby for guix at work ;-) <lfam>a_e: That's the dream isn't it? ;) <mordocai>a_e: Maybe under the table. For now my work wouldn't be interested. <a_e>Well, if it helps your workflow at work, why not! <lfam>I would be thrilled to do this professionally <mordocai>What would be my easiest way to start a "guix free" shell? <mordocai>Well, currently both my shells are setup to use guix environment variables(PATH, LIBRARY_PATH, etc). I need a shell that isn't and would prefer not to have to change my config, start shell, change it back. <lfam>fhmgufs: There are also arguments, build-system, properties (I think), and probably some other things <rekado>mordocai: we have a couple of Ruby packages that build "native extensions", so this should work. <rekado>the build process generally does respect the usual environment variables. <mordocai>rekado: I believe you, I just have spent enough time on this for now. <rekado>sure. Just read the log and thought I'd comment. <mordocai>I managed to get a shell that seems to work for now, i'll work on my guix + ruby problems later. <mordocai>lfam: I think my sbcl problems were due to me running stumpwm and all my processes being children of that process that had SBCL_HOME set to /usr/lib/sbcl sense the process was pre-guix. Hopefully I restart will fix it. <lfam>Ah, that makes (an annoying kind of) sense. <mordocai>Yeah, we'll see if I can confirm by it going away now that i've compiled it with guix sbcl <dannym>lfam: (git guix's make check said "FAIL: tests/syscalls.scm", tests/syscalls.scm:220: FAIL network-interfaces returns one or more interfaces. Others seem to have passed so far.) <alezost>mordocai: install gcc-toolchain instead of installing libc and gcc <mordocai>I don't have time to debug it more atm, but i'll play with it at home later <lfam>dannym: The test output should have some instructions about sending a bug report about that. Can you do that? <alezost>mordocai: ah ok, I don't know then :-) 