<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. <paroneayea>Apteryx: heya! So you can use "guix environment" <paroneayea>$ guix environment --ad-hoc python python-requests <paroneayea>but, what you probably want to define is a guix.scm file you can check into your repository <paroneayea>you can look at haunt, sly, 8sync, and pubstrate as some repositories that do this. <Apteryx>paroneayea: OK, pretty cool! For packages not yet in the guix repo, I have to resort to do a 'pip install 'missing-package' --user', I guess? <paroneayea>Apteryx: right, you could do that, or even better, you could package them :) <paroneayea>you can submit packages upstream, or even better <paroneayea>but what's nice for "in the meanwhile" is you can put package definitions for *not yet* in upstream guix in your guix.scm <paroneayea>and those will work until you get them contributed :) <paroneayea>Apteryx: check out the pypi importer in the guix manual if you haven't yet. It's pretty cool! <Apteryx>paroneayea: OK! Thanks for the pointers. I'll work my way into that slowly. <Apteryx>Ouch, just noticed that if I install ipython it will pull texlive-2016 which weights 4.4 GiB! <Apteryx>Using pip I know I can install ipython[terminal] which from what I understand is a metapackage for ipython without all the notebook stuff. Would be nice to have a package equivalent in Guix. <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 <Apteryx>/gnu/store/yvfq8kwg2fpyjmipcnrix73vsy842024-python2-jedi-0.9.0/lib/python2.7/site-packages/site.pyc <Apteryx>warning: arbitrarily choosing /gnu/store/glhwhxnbbg55jfw7lp55ki9siw3yvsnb-python2-pip-8.0.2/lib/python2.7/site-packages/site.pyc <ng0>Apteryx: the collisions are worth reporting in any case. I mostly ignore the collisions I get for now as nothing is really broken in practice for me <jin>I added 'networking' to my config file! <jin>i'm testing the network-manager-service, recently updated. <Apteryx>ng0: Any pointer to the "marche-a-suivre" to report such issue? Is it the mailing-list, or should I file a bug? <ng0>jin: i tried that aswell, but i didn't put so much effort into testing it. i think you could ask some of the people involved in the network-manager service thread <ng0>Apteryx: possibly file a bug directly, but you could also try guix-devel depending on wether you are already subscribed or not. If you aren't, try a bug and not guix-devel <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 guix-devel@gnu.org ***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 sometimes feel like reviewing is not so effective when I do it because I can just review, but someone else with push access has to go through it again to finally sign it off and push <jmd>I certainly think that our review process could be made a little easier somehow. <jmd>Maybe we should switch to using aegis? <jmd>or some similar tool. <ng0>it would be nice if at some point we could integrate something modeled on liquid democracy tools in the work <ng0>I have no concrete plan, but it's certainly possible <ng0>let me dig up a text on that (as the wiki text is not very good, at least the german one).. pirate party uses this for consent finding for example. <ng0>ah, the text i have is not translated aswell <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? <ng0>s/subject to/included in/ <Acou_Bass>is it possible to set a swapfile in guixSD using the configuration.scm? or should i create the file manually then add it to the swap section of the configuration? <ng0>i created it manually, I think this is assumed by the system config. <Acou_Bass>so create /swap manually like i would in any other distro but the add it to (swap-devices)? <Acou_Bass>sounds good to me, ill do that :D thanks (yes i forgot to create a swap partition upon install and cant be bothered rejigging my drive) :D <ng0>instead of "/dev/sda5" you can also use "/swapfile", yes <ng0>like: (swap-devices '("/swapfile")) <quigonjinn>there's en error in commit dbf8f84f. The patch file introduced is gcj-arm-mode.patch, and we do (search-patch "gcj-arm-mode.diff"). Do I need to post on bug-guix? <paroneayea>speaking of, we need to get that npm tooling merged... aaah! <lfam>That response reads like "our tools are at their limit" <paroneayea>lfam: yeah they're discussing that later in the thread <lfam>I really don't like the suggestion to bundle the upstream packages together <lfam>Okay, I'll keep reading :) <paroneayea>russ mentions texlive as something where the upstream has pleasantly done the aggregation for us ;) <paroneayea>seems like we're stuck where we don't want packages that are too small or too big <lfam>quigonjinn: I fixed that issue in cd569f0d298. But there is another problem. There is a source hash mismatch for the compiler used by GCJ <lfam>paroneayea: Who, us? I don't think we reject small packages :) <lfam>Hm, there's something very unsatisfying about having to add comments that say "Remember to update the hash of foo when updating bar!" <quigonjinn>lfam: sorry for not catching that. I didn't try the fix myself, just reported the error <lfam>quigonjinn: I wasn't suggesting you should have caught it. The problem doesn't manifest if the GCJ patch fails to apply :) <lfam>Thank you very much for reporting the bug <dvc>anyone tried installing guixsd with encrypted root yet? I'm getting an error from grub-install... :/ <dvc>/dev/sda1 is encrypted, so it should still be able to grub-install to /dev/sda? <rekado>quigonjinn, lfam: Oh, I’m sorry about this! <lfam>rekado: About to push a fix :) <paroneayea>lfam: yeah we don't reject small packages, but if we did get enough npm stuff packaged, I do think it would be a bit of a pain <lfam>rekado I'll make it use (package-source gcc) and then add the GCJ patches to that. What do you think? <lfam>paroneayea: How do you think it would be painful? <paroneayea>when a program is composed of tons of libraries whose source code are shorter than the package definition <lfam>I don't see how the libraries being small makes a difference. If a package depended on 1000 ten-thousand line libraries, it would still be a pain :) <lfam>It's just very unsatisfying when the "libraries" are so trivial <lfam>One starts to question their purpose :) <lfam>We will probably need to improve the import and refresh tooling <lfam>Go has this issue too. I've been lazy about packaging Syncthing because I don't want to deal with the dozens of bundled code snippets <lfam>I just build it using the bundled crap <lfam>rekado: The gcj-arm-mode.patch applies to GCC 4.9.3 instead of 4.9.4 (the mismatched hash is of 4.9.3). Can you take a look? <rekado>huh? I wonder how this could be so borked given that I built this all before :-/ <lfam>rekado: You probably still had the 4.9.3 source code in your /gnu/store <lfam>The version / hash mismatch doesn't cause a problem in that case <ng0>dvc: yes, here, successful <dvc>ng0: any ideas what could be the problem? <ng0>oh.. I have an grub_bios partition in both cases <dvc>something about lvm/cryptroot not found <ng0>what are your relevant config.scm parts? <dvc>so you made two partitions and only encrypted the second? <ng0>grub_bios is a very small partition grub needs, or so I was told over the years <dvc>this is my config.scm file <dvc>I'm probably missing a grub_bios partition, I've been using efi for a while now, it's an old laptop... <ng0>efi.. i have no idea about that <ng0>i had one computer with efi, and I sold it a year ago <ng0>i know efi needs some other partition, at least according to gentoo handbook <dvc>yes fat32 partition and copy paste your kernel to it is what I've been doing so far. need to figure out how the "old" way of doing things is :) <ng0>if you can figure out what's needed, you could document it <efraim>`guix offload: warning: failed to obtain load of '192.168.1.221': SSH client exited with 127' any quick suggestions before I actually try myself ;) <lfam>I wonder what 127 means in this context <ng0> "command not found" illegal_command Possible problem with $PATH or a typo <efraim>Putting the kids to sleep ATM, maybe the remote daemon needs updating <lfam>efraim: Is it lsh or OpenSSH? <rekado>lfam: I know what’s wrong with gcj: I used the wrong patch. I had an older version of the patch on my laptop and took that instead of the modified patch I used inside the ARM VM. <rekado>this explains why the patch doesn’t apply and why it had the wrong name. <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 <OriansJ>ng0: I honestly don't know if it is an openssh option, since I have not looked into that yet <lfam>Nmap is a package with a build system that supports this <lfam>Is there a special vulnerability regarding OpenSSH? Or is it just one thing an attacker could do if they could execute code on a target machine? <ng0>OriansJ: it's not obvious to me how they create it <rekado>looking through openssh’s configure.ac I couldn’t find any flag that would allow disabling the build of server or client. Splitting outputs would be the only option. <ng0>that's what the .install of debian looks like <lfam>My opinion is that we shouldn't do it if it's just to try blocking one particular action for an attack who can execute code on my machine <lfam>If they can do that, all bets are off <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. <lfam>efraim: The keys are different formats and can't be used interchangeably without conversion. So if you get the same error, it must be something else <Apteryx>I was wondering; if my ~/.config/guix/latest is pointing to my Git checkout, is the Guix (texinfo) manual used from there? <Apteryx>It seems the info manuals are loaded from: /run/current-system/profile/share/info/ <lfam>I think there is an environment variable for that <lfam>I usually just specify the path "by hand" when testing changes to the docs. `info ./path/to/file` <Apteryx>Currently mine is defined (default) to: /home/maxim/.guix-profile/share/info:/run/current-system/profile/share/info:/home/maxim/.guix-profile/share/info:/run/current-system/profile/share/info <lfam>Not sure about your use case <Apteryx>lfam: OK, well I found a small issue in the manual and wanted to be sure I was looking at the most up-to-date version (ideally from my Git checkout). <Apteryx>I guess I can load it from the path directly as you proposed. <lfam>Sure, send in that patch :) <lfam>Mention this hiccup and maybe you'll get some good advice :) <lfam>AppAraat: That happens. Hopefully soon it will not be the case. <lfam>You are talking about the web page, right? <lfam>We have a new server currently being set up for hydra.gnu.org ***Guest30178 is now known as sturm
<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 <lfam>Apteryx: Yes, if you symlinked your Git repo to ~/.config/guix/latest, that makes sense <lfam>Specifically the last two CVE-2016-* patches. Maybe they came from ICU's SVN. I'll dig in... later <nmp>hi, just installed guix following the instructions in manual, but guix pull is failing <nmp>ERROR: In procedure dynamic-link: file: "libguile-ssh", message: "file not found" <nckx>Hey lfam! Any reason I should be less enthusiastic about libjpeg-zomg? Now you've got my whateversenses whatevering. <jin>civodul: this error appears in the installation using the tarball <nmp>jin: ah, do i have to install from source instead? <nmp>jin: or can i fix it somehow? <jin>nmp: I do not know yet <nckx>sneek: later tell lfam: Hey lfam! Any reason I should be less enthusiastic about libjpeg-zomg? Now you've got my whateversenses whatevering. <civodul>jin, nmp: i see, iyzsong mentioned it on the list <Apteryx>Any idea how to start emacs GTK from the command line? For some reason it's always starting in console mode if I just type "emacs" <Apteryx>jin: And it gets you the GUI version? <Apteryx>That's what happens for me too usually. Strange. <buenouanq>do you have emacs -nw in an alias or something? <Apteryx>Ah. Just found it. I was in a guix environment. <Apteryx>Not sure why the behaviour changes that way! <Apteryx>In "guix environment guix", to be more specific. <Apteryx>Is the reference " (*note (standards)Change Logs::)" at Section 8.5 in the Guix info manual working for someone? <Apteryx>It doesn't work for me, and the makeinfo command doesn't spit any error, even in verbose mode. <Apteryx>"info file standards does not exist" <efraim>on aarch64 libstdc++ keeps using lib64 instead of lib, should I try to force lib or have gcc look in lib64? <rekado>Apteryx: the guix package has “emacs-minimal” as an input, so you’ll find the non-graphical emacs first in your PATH. <efraim>based on the build errors, it looks like gcc-boot0 checks lib64 but gcc-final doesn't <Apteryx>rekado: I see :) Thanks for the explanation. <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 <lfam>And now Jasper is actively maintained again, and has just hit a major milestone release! <Apteryx>How do people reply to the guix-* mailing list? Reply All?