<Apteryx>Hm, what's the recommended way to use Python with guix, especially in regards to pip?
<Apteryx>I'm thinking, a base of python, ipython, basic tools that elpy requires either with "guix package -i", and the rest in a specific virtualenv?
<Apteryx>This is the usual way I do things, but using Guix, I guess I could setup a complete Guix "profile" per project, and have everything sandboxed that way? Seems a bit overkill for he task at hand though.
<Apteryx>It seems that python2-pip and python2-jedi collide on the .../site-package/site.pyc file: warning: collision encountered: /gnu/store/glhwhxnbbg55jfw7lp55ki9siw3yvsnb-python2-pip-8.0.2/lib/python2.7/site-packages/site.pyc /gnu/store/jv8qh0fkljm3zdxsspxlp71b6r2m4qbf-python2-flake8-2.5.4/lib/python2.7/site-packages/site.pyc
<ng0>i don't encourage subscribing to guix-devel unless you know what you run into and are prepared to filter and deal with the amount of emails per month
<Apteryx>ng0: I'll get there, still not satisfied with my Gnus config yet though.
<Apteryx>Excuse me again, how can a force a rebuild of a package? I want to see what the build log is like. "guix build --log-file udisks" only shows two graft lines.
<Apteryx>Just sent a small patch to email@example.com
***Guest91772 is now known as sturm
***sturm is now known as Guest30178
<efraim>Apteryx: if you add --no-grafts it'll show the useful build log
<buenouanq>suggestion to make install guide more accessible to casuals and normal people:
<buenouanq>give an example basic partition scheme with a partition for grub, a swap, and what will become root and suggested sizes for each
<jmi2k_>How can I set the device in grub-configuration in a permanent way? I'm going to install GuixSD in a USB, and the device path changes depending on the computer
<jmi2k_>I can do it with partitions using its part-uuid, but I don't know if something similar can be done with the grub device
<iyzsong>jmi2k_: you can write a proceduce (using popen, etc.) to compute the device value at runtime.
<iyzsong>something like `blkid -U <UUID>` then strip the number suffix.
<ng0>When the python branch is merged, will python contributions be welcome then again? No one has checked my kallithea dependencies iirc, and I also kept back the dependencies for searx because of this, and pagure was the same I think.
<ng0>i'm also working on something to translate called convivenza (pirate party italy), in combination i see a potential, but I need to explain what I want to achieve.. for that I need the translation of this article i'm working on
<ng0>i hope to get this wrapped up on the next long journey with a bus, so that I can work on the explanation referencing this text in january
<ng0>I'd like to translate it to french and spanish as well, but it's all so dried up and used so rarely that I'm mostly stuck with english and german because I rarely need to speak other languages
<ng0>gogs tries very much to stick very close to github (github doesn't have it? we won't implement that feature), so if we ever check something else out (for issues etc whatever, yeah I don't think that issue is done with 'but linux uses whatever so it must be good and we must be doing something wrong'), it should be pagure or kallithea.. i'll try pagure as soon as I have it packaged. Not just for guix, but for
<ng0>another project where we currently try out integrated solutions. but maybe i'm in the minority position and i'll just test it for the other project and not guix.
<ng0>I have a question regarding our (tor-hidden-service) service: /var/lib/ is currently not subject to any system rollbacks or similar stuff, right? So if I exchange the generated content in /var/lib/tor/hidden-service/$name with files I used before, those will not disappear when I `guix system reconfigure` or something similar, correct?
<OriansJ>I honestly wish that the OpenSSH package was split into two pieces, the client and the server because most of the time my systems only need the client and only the servers need the OpenSSH server
<lfam>Does the OpenSSH build system support this distinction?
<lfam>Otherwise, I think we should refrain from customizing builds unless there is a compelling reason. It's a lot of human work
<lfam>Are you concerned about the unneeded components being used maliciously?
<OriansJ>lfam: yes, also it is the standard for debian based distros as well
<lfam>Your first point is valid, but I don't think we should emulate Debian just because. Many of their packaging choices are a consequence of their tooling, and we have different tools.
<ng0>OriansJ: do they split it, or is this an openssh option?
<ng0>if it's just spitting, we could split the outputs maybe
<lfam>But, if there's something about how the client and server interact that allows a component to be invoked in a surprising way, maybe it's worth it
<rekado>personally, I don’t see a good reason to split the packages.
<rekado>installing the openssh package doesn’t start the server automatically.
<OriansJ>rekado: Does it really require to split the packages? couldn't a client-only install just be a derivative of the regular openssh package, that simply throws away one of the outputs?
<OriansJ>Or perhaps simply turns off the server's execution bit
<lfam>Can you elaborate on the attack scenario? By the way, I'm not trying to shut you down for no reason; I just think that every thing we add to an (arguments) field represents another $time of human work when upgrading
<lfam>And very few people work on package *maintenance*
<lfam>But if there is a vulnerability, we need to address it
<rekado>OriansJ: splitting outputs is easy, no need to even create a new package definition.
<efraim>lfam: just got back from putting the kids down, it should be openssh, I passed it an ssh key
<rekado>OriansJ: instead you’d just add a new output and make sure some of the executables end up in the additional output.
<Apteryx>lfam: I figured out the manual is built using "makeinfo guix/doc/guix.texi", and output goes to guix/doc/guix.info (and nowhere else). So it seems if I always want to see the most up-to-date (git) info I should prepend $USER/src/guix/doc to my INFOPATH envar.
<lfam>Apparently these ICU bug reports are still not disclosed by ICU. I wonder where Debian's patches came from
<sneek>lfam, nckx says: Hey lfam! Any reason I should be less enthusiastic about libjpeg-zomg? Now you've got my whateversenses whatevering.
<lfam>sneek: later tell nckx: No, nothing in particular. I just wanted to be sure we weren't missing any important bug fixes. Sometimes projects see no official activity for years while the distros patch critical bugs. So you get something like Jasper, which we added the latest release of before realizing there were many unpatched bugs