<retroj2>should i make a guix package, or is it possible to do this ad hoc? i only need the program once
<retroj2>efraim: i think i see what you mean. the package will need a 'wrap-program clause to set PYTHONPATH, yes?
<retroj2>it might be good to have some kind of package request place, where people could name programs that they want packaged, and it would aggregate the data so that the guix community would know what is missing but in high demand
<davexunit>I just made a page on the libreplanet wiki years ago
<dvc>ng0: there already is documentation about how to start a vm with the -net user flag...
<dvc>I'll add a note that the run-vm script doesn't add the flag by default and that ping doesn't work inside a vm
***[0xAA] is now known as Zer0Pings
<dvc>so submitted a patch to ML for some additional documentation on using qemu with guix. ng0: can you let me know if this would have helped you?
<ng0>sigh. why does everyone assume I follow this with eagle eyes. okay, let me try to respond to what I can respond to.
<ng0>dvc: network does not work *at all* in the vm for me, that's my current problem. i add ntp to that mix and for a short moment it works a bit, then it dies again
<ng0>it was never exclusively about ping, ping is just a side problem i have
<ng0>I will try to read through the patch you've sent. thanks
<lfam>Huh, that's weird that it works sporadically
<lfam>I wonder, does it work reliably when you are connecting to an IP address rather than a DNS name?
<ng0>well sporadically: ntp starts yelling at me like I try to start a revolution in a dictatorship. for some time I can resolve gnu.org to an IP, then ping becomes unavailable again. I wished I could paste output.
<ng0>I think I'll switch my Guix to build from a stable git checkout where I can create branches for such experiments.. I can rollback like always.
<ng0>I'm working on this bigger project, and well I want to work, not debug ping when I don't need to.
<ng0>David Craven (whatever the nick is here): many thanks for the work on cargo build system :) I've been hoping and whishing and partly working on this since february.
<lfam>Hey jmd, I saw your comment about anti-features. Although we shouldn't have any packages with those f-droid antifeatures, I wonder about software that's abandonded upstream for so long that it's not safe to use.
<jmd>lfam: That's a possibility. Although calling that an "anti-feature" is a bit harsh I think.
<ng0>i wonder if this pcre bundle comment is really necessary. I'm not a neutral party in this, but I don't understand what pcre does in psyclpc. we have the meeting tonight and I try to get more information. I know we'll work on this, but channel was rather silent the last days when I tried to get information.
<ng0>only downside: with the service you still have 30 minutes shutdown .
<dvc>I can think of a few packages that are missing... but we are getting there quickly
<ng0>the psyced suite and secure_delete (targeted around spring next year) and for me personally palemoon will be my last contributions in packages i think.. what I need afterwards are services I work on and core contributions/extensions.
<ng0>like erase ram on shutdown (secure_delete) etc
<lfam>dvc: I don't get it, but that's okay :) To me, unstable ABIs don't matter in Guix (except when grafting), because everything dependent on foo is rebuilt when foo changes
<dvc>lfam: that's right - but if cargo and rustc don't respect an LD_LIBRARY_PATH because of it, it doesn't matter that it wouldn't be an issue
<dvc>it's a feature that hasn't been implemented yet because of this - that's all
<lfam>My quandary with Go is mostly how to programmatically determine where to unpack the source code. It seems that each upstream's build scripts require it to go in some path that is a paraphrase of the source URL. For example, syncthing must be unpacked into 'src/github.com/syncthing/'
<lfam>All the dependencies go into some path relative to 'src/'
<lfam>I guess I can't send my Syncthing package in as-is, since Syncthing bundles the source of several dozen dependencies. It would probably be faster to make the go-build-system than all those package definitions, and the transitive dependencies thereof
<lfam>I may have been around Guix for longer than you, but it's clear to me that you are a much better Scheme programmer. I'd love to "pick someone's brain" without the friction and latency of going through a computer
<lfam>In the meantime, I will keep polishing the wall with my head :)
<dvc>I think a hackathon would be cool, but the real life thing could be hard...
<lfam>Yeah, we are quite a distributed group, which *is* cool
<lfam>Okay, so Hydra can use CAPTCHA's via perl-catalyst-plugin-captcha, which depends on imagemagick transitively. Hydra also depends on imagemagick via dblatex
<lfam>Seems like dblatex should not be accessible via the web interface, but who knows
<lfam>I haven't noticed any CAPTCHA's while using Hydra so far. The question would be, "Where does the CAPTCHA image come from? Who controls the image?"
<efraim>interesting bug: I changed the flann version to 1.9.1 but forgot to update the hash. guix found the hash using nix's content-addressed-mirror, and it downloaded flann-1.8.4 and set about using that
<ng0>(without seeing this channel) lfam: I don't have much further insight as lynX is not present this night, but our pcre in addition to old is also stripped down. I'll put updating it on the project roadmap.
<ng0>psyclpc/src/pcre/README.LDMUD in case you have the tarball extracted.