<TonyGazelle>guess i could of left off the timestamp, it was just the link that corrected the specific problem i was facing <TonyGazelle>sqlite3 probs during compiling. just had to grab the dev version. <TonyGazelle>easy fix. just so many dependencies it was the last one i had to fix. <TonyGazelle>forgot you were the fellow i was chatting with the other day, good memory <TonyGazelle>i wanted to mess around with openrc on deb so i figured why not test guix on it as well. ***DusXMT_ is now known as DusXMT
<Trent>Where can I get a t-shirt that says I stick Stallman photos in my ass and masterbate <Trent>And take the semen and collect it in a jar and mail it to Stallman <civodul>Trent: sorry, insulting behavior is not acceptable on this channel <jmd>Would it be possible to add a feature to check for possible license conflicts? <jmd>For example if a package is GPLv3 but has an input which is GPLv2 this would be problematic. <jmd>Guix should be able to detect such things. <sneek>Welcome back jmd, you have 1 message. <jmd>You are right that such a feature could not be 100% reliable. But I think it would be a useful tool to catch potential incompatibilities which might otherwise go unnoticed. <jmd>I think the gnulib people have a similar tool. <civodul>Gnulib uses a very small set of licenses, though <civodul>but yeah, we could write such a tool <jmd>I haven't counted them, but I don't know if guix has very many more than gnulib. <civodul>Gnulib basically has LGPL+GPL, v2+ and v3+ <jmd>I think gnulib also has x11 style and simple permissive. <jmd>The only thing I'm not sure about it how to determine what role a native-input might play in the building a package. <civodul>well, if the build results are available, you could look at the references of build results <sirius>Is there an easy way of using an archive on the local filesystem instead of downloading it for testing a package definition? <civodul>sirius: yes, if you initially download it with "guix download", then the local version will be used <civodul>provided the recipe specifies the corresponding sha256 hash <sirius>Yes, I know that. My problem is that I changed the contents of the archive and it therefore has an another hash. <civodul>then you can also write (source "/home/foo/bar") instead of (source (origin ...)) <civodul>that will take the local file directly <civodul>and the hash doesn't even need to be specified <civodul>(because it gets recomputed every time) <civodul>obviously that's only valid for testing purposes <ijp>sorry, fixing up my erc buffers. hi <sneek>Welcome back ijp, you have 1 message. <sneek>ijp, civodul says: make check TESTS=tests/store.scm, for instance <civodul>bavier: i've just created a branch for the GLib split <civodul>if you'd like to upgrade GLib, it would be good to do it there as well <bavier>civodul: great. I'll take a look <bavier>at a first glance, there are some test failures in the 2.40 source that might need to be looked into more. <jmd>Why are we splitting GLib ? <bavier>to avoid pulling in python if it's not absolutely required <jmd>I wish python would just go away. <Steap>Not happening any time soon :) <bavier>is there any way to get a listing of packages that depend on another package? <Steap>bavier: I don't think so, but I might be mistaken