IRC channel logs


back to list of logs

<TonyGazelle>^ best thing since sliced bread
<zerwas>Some specific timestamp?
<TonyGazelle>just the irc logs in general
<TonyGazelle>guess i could of left off the timestamp, it was just the link that corrected the specific problem i was facing
<zerwas>which problem was it?
<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.
<zerwas>I see
<zerwas>Still on Slax?
<TonyGazelle>nope this on debian jessie
<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>Windows 8.1 > GUIX
<civodul>Hello Guix!
<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>civodul: Hi Ludo
<civodul>hey, jmd
<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.
<civodul>sneek: later tell jmd re: license compatibility, yes it would be easy, but see
<sneek>Got it.
<civodul>hey, jmd
<sneek>Welcome back jmd, you have 1 message.
<sneek>jmd, civodul says: re: license compatibility, yes it would be easy, but see
<civodul>sneek works like a charm :-)
<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+
<civodul>we have many more
<jmd>I think gnulib also has x11 style and simple permissive.
<civodul>yeah, could be
<civodul>but still ;-)
<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>yes, that's a problem
<civodul>well, if the build results are available, you could look at the references of build results
<civodul>rather than look at inputs
<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
<civodul> has some info
<sirius>Yes, I know that. My problem is that I changed the contents of the archive and it therefore has an another hash.
<civodul>ah, ok
<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
<sirius>thx, that worked.
<civodul>ijp: say hi!
<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
<ijp>ah, thanks
<civodul>you're welcome :-)
<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
<civodul>(despite the branch name...)
<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