IRC channel logs

*davexunit sends a patch to the list

<davexunit>sigh, I want to package http://tidy.sourceforge.net but they don't have release tarballs

<davexunit>you have to use the cvs repo...

<davexunit>ooh, I think I can download a tarball. all might not be lost...

<davexunit>hmm, not sure how to get guix to accept URLs with a query string in an origin uri

<davexunit>I guess the nix daemon tries to use the query string in the derivation file name, where characters like '%' and '&' are invalid.

<mark_weaver>davexunit: you can set the file-name explicitly.

<mark_weaver>see the 'libdaemon' package in libdaemon.scm for an example

*mark_weaver is working on packaging icecat 31.1.1

<davexunit>mark_weaver: thanks, I should have mentioned that I discovered that a little while ago.

<davexunit>I have a bigger problem now, heh

<mark_weaver>oooh, I got a working icecat-31 build :)

<zacts>nice mark_weaver

<Ulrar>How do I force it to rebuild a package and not use the existing one ?

<mark_weaver>Ulrar: you have to first delete the built package with "guix gc --delete /gnu/store/..."

<Ulrar>It says it's still alive, won't do it

<mark_weaver>so you have to remove the references to it first. if you installed it in your profile, you need to remove it from your profile and then delete your old profiles, then try again.

<mark_weaver>"guix package -d" deletes all generations of your profile other than your current one.

<Ulrar>That worked, thanks §

<mark_weaver>np!

<Ulrar>Is there a configure phase with cmake ?

<davexunit>Ulrar: yes

<davexunit>Look in guix/build/cmake-build-system.scm

<Ulrar>Mh yeah, I was missing parenthesis, it's my bad

<Ulrar>thanks

<davexunit>yw

<Ulrar>ld: warning: libgcrypt.so.20, needed by /gnu/store/yxpdhbca901564xmq1jf41kmkznbqvc0-libssh2-1.4.3/lib/libssh2.so.1, may conflict with libgcrypt.so.11

<Ulrar>Funny, that's a problem only if I use cmake, the same package using autogen builds fine

<bavier>davexunit: could we add a cvs-fetch method for tidy?

<davexunit>bavier: perhaps, yeah. I don't know cvs very well. is it possible to get a snapshot at a specific revision for the entire repository?

<davexunit>cvs is very primitive.

<bavier>yes, I believe you can request a specific revision number when checking out

<davexunit>okay. I guess that's the best option, then.

<bavier>you'll probably need to do things like the git-fetch method does for removing the cvs metadata

<davexunit>yeah

<davexunit>if anyone else wants to tackle this, feel free, but I will probably do it if no one else gets to it first.

<civodul>Hello Guix!

<civodul>davexunit: just saw your patch: awesome!

<davexunit>civodul: :)

<bavier>fefe```: you mentioned earlier that you're a user of xfig?

<fefe```>bavier: yes, indeed.

<bavier>fefe```: I actually have what I think is a functioning xfig package.

<fefe```>nice!

<bavier>I can take a look at it again, and post it to the list later, if you'd like to give it a try.

<fefe```>I would be very happy to give it a go.

<bavier>great

<fefe```>I use it since too many years to count :-)

<fefe```>I like the nice integration with latex

<fefe```>where you can export text which is processed by latex itself

<bavier>yes

<bavier>I was working on it for dblatex, which can process fig files

<fefe```>interesting

<davexunit>civodul: thanks for the feedback!

<davexunit>especially re: keeping the store open

<davexunit>I originally had it keep the store open and thought that it should be closed before the system call, but I didn't consider the case of a GC run.

<civodul>yeah it's easy to overlook that

*civodul struggles with alezost's circular ref

<civodul>mark_weaver: any suggestions for the module cycle issue?

<jmd>Anyone want to comment on the icu4u patch I posted, or should I just go ahead and push it?

*civodul hasn't seen it yet

<civodul>jmd: you haven't posted anything, have you? http://lists.gnu.org/archive/html/guix-devel/2014-10/threads.html

<jmd>Oh.

<jmd>Looks like git-sendmail messed up.

<jmd>Mailed me, but not the list.

<civodul>heh, ok :-)

<jmd>Ok. I sent it again.

<davexunit>civodul: it seems that NixOS can provision linux containers. will guix be able to do it?

<jmd>What are "linux containers" ?

<davexunit>lxc containers

<jmd>We have lots of bin directories. Do they count as containers??

<davexunit>I used 'linux' because it relies on the kernel.

<davexunit>think docker

<davexunit>I'm not sure how nixos does things

<civodul>systemd, no?

<civodul>i'm not sure

<civodul>to me "containers" mean chroot + separate name spaces, no?

<civodul>alezost: is there a way we can move forward without making big changes?

<civodul>i'd like to better understand the problem we have

<davexunit>civodul: I assumed it was lxc containers... guess that was a bad assumption.

<civodul>maybe it is, i don't know

<civodul>this is relatively new stuff, i think

<civodul>and i'm not too familiar with that

<davexunit>okay

<davexunit>civodul: you had shown me that nixos-shell project before, and it takes advantages of the containers

<davexunit>trying to figure out what the next logical step after 'guix environment' should be

<civodul>heh, i see :-)

<civodul>currently we just have full-blown VMs

<paroneayea>gnutainer

<paroneayea>davexunit: btw, Sazius just ack'ed your tarball request in #pump.io kinda

<paroneayea>if you wanted to ask further

<paroneayea>oh though I think you got stuck on dep hell

<davexunit>paroneayea: I'll be able to get over that soonish

<davexunit>need to add a cvs-fetch method for guix

<paroneayea>davexunit: cool

<mark_weaver>civodul: I think the answer will probably involve supporting phases in our macro expander, as described in section 7.2 of the R6RS, but I'm not entirely sure that will be enough.

<mark_weaver>specifically, I think we need to support _visiting_ a module before _instantiating_ it. right now, when we compile a module, we generate just one piece of code that does both of these things at the same time, iirc. we need to separate them.

<mark_weaver>but I haven't worked out all the details yet

<civodul>right, but that's the long-term answer ;-)

<mark_weaver>right :)

<civodul>everything in R6 was well thought out

<mark_weaver>yes

<civodul>anyway, this thing is like a fly in the ointment

<mark_weaver>I think for now we need to avoid circular dependencies in our modules.

<civodul>until recently, i thought it was a simple matter of discipline

<civodul>but it turns out to be difficult

<paroneayea>dependency loop party

<civodul>yay

<mark_weaver>actually, I think the requirements are slightly weaker than that.

<mark_weaver>I think we can have circular dependencies, as long as none of the modules in a strongly-connected component (SCC) need any bindings from any other modules in the same SCC at module load time.

<mark_weaver>bindings referenced from thunked fields such as 'inputs' are not needed at module load time.

<mark_weaver>so the problem areas are when a dependency involves macros or referenced from unthunked fields.

<mark_weaver>and we need to make sure that when there is such a load-time (or expand-time) dependency A->B, that A and B are never in the same SCC in the use-module graph.

<mark_weaver>since the vast majority of our cross-module dependencies in gnu/packages/ are referenced only from thunked fields, this gives us considerably more latitude.

<mark_weaver>civodul: does that help?

<mark_weaver>so, there are two different kind of edges to consider: load-time-deps, and use-module-deps.

<mark_weaver>we compute the SCCs of the use-module-deps graph.

<mark_weaver>then we make sure that none of the edges A->B in the load-deps-graph are internal to an SCC of the use-module deps graph.

<civodul>mark_weaver: i've used your cycle-detection script to inspect the (guix ...) modules

<civodul>i might have a solution now

<mark_weaver>that would be good!

<mark_weaver>the cycle detection script shows the SCCs, but doesn't yet highlight the edges within them that are part of the load-deps-graph. that would be a nice addition, although it might be hard to implement properly.

<mark_weaver>with such a feature, you could disregard any SCC that doesn't contain such an edge, and if such an edge was present you could try to remove just that edge.

<mark_weaver>(remove it from the load-deps-graph, that is)

<civodul>the current version is conservative, but that's OK

<civodul>at least for the (guix ...) module, we want to be conservative, i think

IRC channel logs

2014-10-09.log