IRC channel logs
2017-07-17.log
back to list of logs
<ng0>battery is getting empty.. have to go <reepca>quiliro: run a non-interactive ssh command that just displays the value of PATH <reepca>ssh [options] myuser@myserver "echo '$PATH'" <Apteryx>Nevermind, it was just my system running low on memory and the c++ compiler getting killed by the kernel. <Apteryx>I'm retrying with a single job and a single core. <reepca>quiliro: after you do that, comment out the part of .bashrc that sources /etc/profile and run it again. <reepca>I'm wondering what PATH looks like by default over non-interactive ssh. <reepca>quiliro: actually, the command should be 'echo $PATH' <Apteryx>Wow, building that "vigra" dependency is using 1.56g with the cc1plus process. <Apteryx>No wonder it bugged my system down when it was trying using multiple cores earlier! <nckx>quiliro: Dit my suggestion to add ‘openssh’ to your system packages solve anything? <nckx>(I haven't read the entire backlog.) <quiliro>reepca: before commenting out source /etc/profile: $ ssh -p2222 quiliro@192.168.100.102 'echo $PATH' <quiliro>/home/quiliro/.guix-profile/bin:/home/quiliro/.guix-profile/sbin:/run/setuid-programs:/run/current-system/profile/bin:/run/current-system/profile/sbin <quiliro>reepca: after commenting out source /etc/profile: <quiliro>$ ssh -p2222 quiliro@192.168.100.102 'echo $PATH' <quiliro>/home/quiliro/.bashrc: línea 17: error sintáctico cerca del elemento inesperado `fi' <quiliro>/home/quiliro/.bashrc: línea 17: `fi' <reepca>quiliro: comment out the entire region, from "if" to "fi". <quiliro>nckx: i am testing with reepca if replacing with: if [ -n "$SSH_CLIENT" ] <quiliro>the line that reads: if [ -n "$SSH_CLIENT" -a -z "`type -P cat`" ] . It in fact worked <quiliro>reepca: $ ssh -p2222 quiliro@192.168.100.102 'echo $PATH' <quiliro>what will happen if i uncomment everything back? <nckx>Why not try the generally accepted method before hacking around configuration files like this? <nckx>Seems like a lot less work... <Apteryx>Finally resized all of my hd to guix. Was about time. <quiliro>nckx: please tell me how to do the ‘(operating-system (packages (list openssh ; for scp...’ thing <reepca>quiliro: Oh, I didn't realize you didn't have that in there yet. <reepca>basically, find the part of your operating-system declaration that says "packages" and change what is currently there to include openssh. If it's of the form (cons* somepackage1 somepackage2 ... %base-packages) then just add openssh in among the "somepackage" parts. If it's just %base-packages, change it to (cons* openssh %base-packages) <quiliro>(packages (cons tcpdump %base-packages)) <quiliro>(packages (cons* openssh tcpdump %base-packages)) <quiliro>rekado: could you pass me the config to openmolar? <reepca>quiliro: the last thing you put should work, but make sure you have (use-modules (gnu packages ssh)) at the top of your config.scm <reepca>cons* can add multiple things to the front of a list, cons can only add one. That's the easy explanation, anyway. <quiliro> (use-service-modules networking ssh) <quiliro>is it necesary to put (use-modules (gnu packages ssh)) <reepca>yeah, because the service doesn't export openssh, it just exports the related services. <reepca>or you could use (use-package-modules ssh) <quiliro>reepca: i dont undestand your first sentence <reepca>(use-service-modules ssh) will get you openssh-configuration, openssh-service-type, stuff like that. Stuff related to the openssh service, but not the actual openssh package. <quiliro>(use-service-modules networking ssh) <reepca>alright, you should be able to guix system reconfigure now and openssh and its binaries should become available systemwide <quiliro>reepca: i have to return .bashrc to its original now? <reepca>it'd probably make sense, so that we can tell if this solves the problem <quiliro>reepca: i am copying with scp... must i wait until it finishes? or may i do it without disturbing scp? <reepca>in short, yes, you should be able to do that without disturbing scp. <quiliro>reepca: why did i get: shepherd: Service user-homes could not be started. <reepca>quiliro: I'm not sure. I would guess it has something to do with .bashrc. <quiliro>reepca: but .bashrc is back to normal <reepca>I'm not even sure that that message doesn't appear when normally reconfiguring. On startup that service tries to ensure that your home directory exists, and always returns #f (signalling failure and termination). I wouldn't worry about it. sorry, I need to get some sleep pretty badly. <quiliro>reepca: rebooted and connected beautifully! <quiliro>now i want to make that machine a substitute server...a hydra mirror...how can i do that? <quiliro>so i can experiment with guix without being online <rekado>I just finished reinstalling GuixSD and restoring /home from backup. <rekado>took me a lot longer than I hoped <efraim>idea i'm toying with for if/when I set up cuirass on my odroid, a set of packages that I want substitutes for first, and then after that it can try to build the rest <efraim>I have in my list gtk+, gtk+@2, guix, webkitgtk, nss, python-cython, python2-cython <quiliro>rekado: i am glad you could recover your files <civodul>rekado: you had problems with your laptop? <civodul>efraim: m-o submitted the idea to pass Cuirass a manifest of things to build <civodul>maybe it was a patch rather than an idea, i'm not sure :-) <civodul>so not exactly what you're suggesting, but close to it <rekado>civodul: yeah, on Saturday morning my laptop crashed and corrupted the disk. Couldn’t boot anymore. <rekado>took me until today to back up, verify the backup, install GuixSD but failing to install GRUB, reformat the disk, install GuixSD, install the manifest, restore the backup <nckx>quiliro: glad to hear it. <nckx>It's a one-line addition that eludes a lot of people the first time, including me. Would make a good patch to the manual. <civodul>rekado: uh indeed, glad it eventually worked <jsierles>rekado: hey, do you know by chance if your NFS cluster is using linux fscache on the clients? <sneek>jsierles, you have 1 message. <sneek>jsierles, rekado says: Yes, I have built julia 0.6 at least once before pushing the update. Haven’t tried recently, though. <jsierles>rekado: would have the 'fsc' option in the nfs mount <jsierles>i guess if you're on a high speed network though, it wouldn't provide much <jsierles>now i'm trying to use NFS over the internet to provide a distributed store to developers. but of course the idea is to enable aggressive client side caching <rekado>jsierles: we aren’t using the fsc option. <rekado>NFS over internet sounds … terrifying <rekado>quiliro: hey, sorry for not being able to send the latest package definitions earlier <rekado>quiliro: I’ll upload them in a moment <jsierles>rekado: nfsv4 uses TCP. not a big deal if indeed your intent is to cache <jsierles>not ideal of course. but it would probably be faster than everyone running their own guix installation <rekado>jsierles: at Siemens they had the R&D team in China connect to an NFS share in Germany. It was a great source of frustration, not least because it was all snappy for the Germans, so they didn’t see any reason why it should be changed :) <jsierles>rekado: sure, china is a showstopper for many tech projects :) <jsierles>there aren't great alternatives. distributing files is a hard problem in general <jsierles>CERNFS so far has had the best performance I've seen, but only works for the 'single writer' scenario <jsierles>that fits with guix, but having to perform transactions for every change to the store is cumbersome. <jsierles>though that does some safety and protection from store/db corruption. do you backup your store rekado? <rekado>jsierles: we have the store on ZFS and keep some snapshots for emergencies, but there’s no backup to tapes <efraim>I guess the question is really 'one /GNU/STORE OF TRUTH' or one master store/cache and many individual stores <jsierles>right now, trying to keep dev environments in sync with production is a hassle. because 'guix pull' is really slow, and my substitute server does not work properly for some reason <jsierles>i build something there, but locally it still has to be compiled <efraim>i didn't realize CERN had their own top domain <janneke>can i get guix graph to output an sexp of package dependencies? <quiliro>reepca: were you able to recover your files? <rekado>quiliro: I think you meant rekado <rekado>quiliro: yes, I was able to recover them <efraim>rekado: that was a lot of TeX work that you didn't need for sooperloopers <rekado_>quiliro: what email address and name would you like me to use for your copyright line? <civodul>janneke: no, but the perhaps the opencypher backend can be useful to you? <civodul>or you can add your own backend, of course :-) <civodul>janneke: just tested the sink.flush() thing i proposed, and it works as expected <civodul>thanks for the investigation, a tricky bug! <janneke>is opencypher somethihng different from cypher? --that still needs some parsing <janneke>civodul: oh, great -- i didn't get round to testing that yet <janneke>civodul: we scripted our `hasslefree' offloading feature and setup some 16 core hosts <janneke>then spent two days finding the permissions on the secret key... <janneke>civodul: while i was happy with this fix, i was wondering if we could look for a pattern <civodul>janneke: the bug is really related to the BufferedSink thing, which was introduced only recently <janneke>civodul: a la checkSecrecy that throws -- do we need more try/catch blocks? <civodul>throws to 'Error' and subclasses thereof are gracefully handled (the client gets an error and the connection isn't lost) <janneke>civodul: ah, okay great -- also, reepca is going to help us make all this obsolete rsn, right? <civodul>you mean reepca is going to remove all the bugs at once? ;-) <janneke>civodul: so please just fix and push my patch! <janneke>they may come up with some new and original ones... ;-) <civodul>it's great when new bugs subsume old-fashioned bugs :-) <quiliro>rekado: i am so happy that openmolar is comming to the repo! thank you very much :-) i may i ask how the process was done when you commit the changes? i will learn by analysing your proceedure <quiliro>going to electronics clases! i want to redesign ronja.twibright.com <quiliro>never thought of going to university again..haha <joshuaBPMan_>I am currently trying to set up dual booting between guix and parabola. Ideally, I would specify in guix's configuration, how to boot Parabola. <joshuaBPMan_>my question is: is it ok for guix and Parabola to both use the same /boot partition? <joshuaBPMan_>I've already got parabola booting uefi. So my /boot partition is a fat32 filesystem of about 537MB. <joshuaBPMan_>according to df /dev/sda1 (my boot partition) has only used about 7%. So I'm going to guess that there is enough room to share them, but I'm not sure if I'm supossed to share them.... <joshuaBPMan_>I probably can share the /boot partition with both guixSD and parabola? <efraim>Probably OK to share /boot for uefi <efraim>/boot/efi is almost definately ok <efraim>I'm not in front of my computer ATM to see what's in /boot on my Debian machine <joshuaBPMan_>efraim. Ok thanks. My laptop dual boots guixSD and Parabola, so I know it's possible. But they boot using the old fashioned way. <efraim>But I'd look at 'ls /boot' and 'tree -d /boot' to see if the files look generic or OS specific <joshuaBPMan_>I'm just thinking out loud now...I'll have to make guixSD handle updating grub, and make sure that Parabola does not update the grub menu. <rekado>PyQt5 only looks in one directory for modules. <rekado>That’s why the PyQt bindings for Qscintilla are only found when using an environment <rekado>Either we patch PyQt to respect an environment variable, or we change packages to use profiles instead of trying to tie everything together with environment variables. <rekado>I actually think it would be prettier to use unions / profiles <joshuaBPMan_>hello, I'm reading the guix documentation about how to install via uefi. I guess in the grub configuration you need to specify which grub package to use... <joshuaBPMan_>I can keep trying variations on that, but I keep getting an error: wrong type argumenti s position 1 (expecting struct): ("grub-efi") <joshuaBPMan_>The documentation says to do (grub grub-efi), which doesn't work.... <joshuaBPMan_>I might have fixed it actually. I did not put in (use-package-modules bootloaders) .... <joshuaBPMan_>well it failed... failed to install GRUB on device /dev/sda1 <joshuaBPMan_>admitedly I was not able to boot the the thumbdrive via uefi, so that may be why.... <jsierles>trying to `guix pull` and getting: x86_64-guix-linux-gnu-ld: cannot find -lstdc++ <lfam>jsierles: Trying to reproduce... <jsierles>lfam: i'm running guix pull against this commit: df08f385705dad9f342e7d1f51407d6207d8b557 <lfam>jsierles: Are you using the guix-daemon in the "regular" way or is it a special set-up? <lfam>Okay, I'll let this pull finish but I don't think I'll be able to reproduce the failure <jsierles>i'm just wondering why there are no substitutes available for the packages it's building <lfam>I can think of two potential reasons. Perhaps we haven't built those packages yet. Or, they might be built but not yet requested from the mirror. The first request to the mirror always gets a 404 response, and then hydra starts packing and sending the substitute to the mirror. So, after a few minutes the substitute would be on the mirror. <lfam>A third reason could be some bug in the substitution mechanism <lfam>Finally, when Guix prints the "report" on what will be built (I don't remember if this is shown for `guix pull`), grafting derivations are shown as "to be built". They can make the list look very long, but they are pretty cheap to build. <jsierles>lfam: a better question, is there a way to see if a package is available as a substitute? <lfam>I *think* so but I'm not sure how. But, there is `guix substitute`. I think you have to compose it with other commands to give it an argument <jsierles>i'm just seeing, for example, guile 2.0 being built, libtool 2.4.6, etc <jsierles>seems like those should already be there. i thought maybe it's due to grafts or something. <jsierles>has anyone setup a substitute server besides hydra? <lfam>I don't know of any public servers. Public are announced on the mailing list sometimes <lfam>I mean, public mirrors are announced... <jsierles>yeah. i don't mean mirrors. in general i've found just a ton of compiling is going on locally, all the time. so trying to get down to the bottom of that by: <jsierles>2. running 'guix pull' there and building a bunch of stuff <jsierles>3. trying to build those things on another host, with my subtitute server set on the daemon <jsierles>in theory, this process should work right? if I build a core package in one place with the same guix version, it should be picked as a valid substitute. <lfam>Good idea. If it were me, I'd first try to reproduce without --disable-chroot and then with it. <jsierles>lfam: yeah, --disable-chroot is separate problem <jsierles>i can't do what i want without it, unfortunately <jsierles>interestingly, the substitute server throws a ton of errors. <jsierles>lfam: so with the daemon running normally, i'm just trying 'guix build -n' to see what would be substituted <efraim>not too helpful in this case, but I have an aarch64 substitute server <efraim1>hmm, can't find (guix git) from cuirass head <grillon>what's the difference between guix 0.12 and 0.13? <jsierles>efraim: in general you don't see issues with the server? <jsierles>i'm concerned i have a corrupt store/db, but don't know I could find that out <efraim>my most recent copy of webkitgtk seems to be corrupted, but thats it <jsierles>efraim: i see. so in general you don't see local compilation on your other servers? <efraim>i try to use the slower board as a compile server to see what builds, and i use the faster board to actually fix the issues, so I keep the two pretty much in sync <jsierles>i see. so you might not notice if the sub server is not serving up files correctly <efraim>i noticed because it kept on getting stuck, but generally it either has it or it doesnt <jsierles>i see. now if i just install a stock 0.13.0, run the daemon and run 'guix build grep', i get a list of 130 derivations that need building. <jsierles>that's using mirror.hydra.gnu.org as the sub server. <efraim1>guix is rolling, if you've just installed 0.13.0 you'll need to run 'guix pull' before running 'guix build grep' <efraim1>hydra has limited storage space, and while we try to keep it stocked with substitutes from 0.13.0 they sometimes get purged <efraim1>there's a constant stream of security fixes and package updates and upgrades to guix itself <jsierles>ok fair enough. so running 'guix pull' from 0.13 also requires a long list of compilations <jsierles>I've never wiped my store since 0.13 was installed, though, and using my sub server i see the same deps being compiled. <jsierles>sure, i understand. i'm just trying to see if it's possible to avoid yet, or if that's just not supported yet by the guix tools <reepca>jsierles: you mentioned that you were using --disable-chroot, do you have the store in a place other than /gnu/store? <jsierles>reepca: nope. I didn't know that was possible. but currently i'm not using that option, for testing <jsierles>OK, i discovered the source of one issue - not having authorized the sub server before running 'guix pull'. <jsierles>sorry for the noise :) let's see how far I can get now. <lfam>jsierles: To me, having used Guix for a while, the instructions in the manual are very clear. But it's important to get the perspective of beginners. Could the instructions about authorizing the server be more clear? <jsierles>lfam: it's clear, i actually did this by accident a few times already <jsierles>i would say the default should be to stop building if a server isn't authorized. if you really intended to not use substitutes, you would use --no-substitutes <jsierles>but not a big deal - guess it's just my lack of attention. <jsierles>bigger concern now is why my substitute server does not show some packages being available. <lfam>I'd argue for the current default, since Guix is really a build-from-source distro, not a binary distro ;) <hellcode>it's just so different from traditional Unix style systems... <joshuaBPMan_>hello, I'm having trouble getting guixSD to install grub on my fat32 filesystem. (I'm trying to boot using UEFI). <jsierles>this is the path for guix-latest i'm seeing using a specific guix git hash : /gnu/store/k0v196lq02bb48cdri5p44c4qgy6zfjy-guix-latest <joshuaBPMan_>after running guix system init /mnt/etc/config.scm /mnt; It seems like GuixSD is installed, but grub fails to install. I get a grub-install error. modinfo.sh doesn't exist. Please specify target or directory. <jsierles>is this hash reproducible, given the specific guix git hash? <joshuaBPMan_>I believe that I booted using a usb stick via the bios option. I don't believe that I booted the usb stick the uefi way. If that changes anything. <jsierles>will 'guix-daemon' look for ~/.config/guix/latest and run from there? <hellcode>If you don't mind me asking a silly question, where is the place to put what keyboard layout I want? <jsierles>not clear if i have to run 'guix package -i guix' to execute the latest version of the daemon <rekado_>hellcode: much of the system is configured via services <rekado_>hellcode: to use dvorak on the console, for example, you would add (console-keymap-service "dvorak") to the list of services. <hellcode>hmm so it /etc/shepherd.scm is a good place? <rekado_>hellcode: you are using GuixSD, aren’t you? <rekado_>hellcode: in that case you should have a system configuration file. <rekado_>hellcode: if you followed the manual then it will probably be named /etc/config.scm <rekado_>hellcode: the file should contain an “operating-system” record with a “services” field. <jsierles>`guix-daemon --version` doesn't mention a specific version number like 'guix --version' does. <rekado_>that field contains a list of services (e.g. %default-services) <rekado_>you can add services to that field or modify the services <hellcode>rekado_: and then it'll be read at boot time? <samplet>hellcode: Look especially at the first two subsections. <quiliro>i sent my first small help on the mailing list....that means i have learned something <quiliro>rekado_: did you commit openmolar yet? <rekado_>hellcode: the operating system configuration is not read at boot time. It is read and instantiated when you do “guix system reconfigure /etc/config.scm” <rekado_>that command will build a new system based on that configuration and register it with Grub. <rekado_>quiliro: I have not committed it yet, because there’s a problem. <rekado_>quiliro: it’s a problem with PyQt, actually <rekado_>PyQt only looks for modules in *one* directory, namely the directory that’s part of the python-pyqt package. <rekado_>that’s a problem because it won’t see the files that python-qscintilla provides <rekado_>I could only make it work when I ran openmolar inside of “guix environment openmolar” <rekado_>and that’s because “guix environment” creates a union of all the inputs and then sets PYTHONPATH to that single union directory <rekado_>the python-build-system on the other hand just wraps executables in a PYTHONPATH with as many entries as there are Python packages. <rekado_>to make a long story short: we need to change the openmolar package to make it use a special union of python-pyqt with python-qscintilla <rekado_>this hasn’t come up so far because we don’t seem to have packages that provide extra pyqt modules. <quiliro>rekado_: i spoke with the director of a technical school (small universtity) that teaches computer science. he said he could include collaboration in free software projects part of the syllabus for the students. i can ask them to contribute to Guix. what tasks should i ask them to do? <rekado_>quiliro: oof, I don’t know what part of Guix would be suitable for contributions from newcomers while also being interesting enough for students of computer science. <quiliro>they must collaborate between 80, 120 and 800 hours before graduating, depending on the area <quiliro>perhaps they can add the descriptions to the packages <rekado_>maybe editorial contributions to the manual? Or contributing to the translations. <rekado_>all packages in Guix already have descriptions (they are mandatory). <quiliro>even more, it guix could allow, the descriptions could be translated to spanish....so if the user wants them in another language, guix would provide that <quiliro>i read somewhere, that some packages do not have good description <quiliro>also, we could ask them to have a hydra mirror or other server <rekado_>quiliro: descriptions could indeed be translated <rekado_>quiliro: LANG=fr_FR.utf-8 guix package --show=hello <rekado_>quiliro: this will show you that the “hello” package’s description has been translated to French. <rekado_>we don’t seem to have Spanish translations yet <rekado_>nicorikken[m]: you can add (arguments `(#:python ,python-2)) <rekado_>the #:python keyword argument to the python-build-system is specifically intended for this purpose <catonano>quiliro: please, write a note on the mailing list about this computer science schhool of yours. The devaze will be wider. <catonano>depending on the skills level of such students, some proposals could be envisioned <rekado_>nicorikken[m]: “python-2” is the name of a variable which currently holds the package definition for Python 2.7. <nicorikken[m]>rekado_: this results in a 'Unbound variable: python-2' error. what should I import? <rekado_>nicorikken[m]: it is defined in (gnu packages python) <catonano>thhe first thing that comes to my mind is pacaging a lot of stuff. Another one is writing services <rekado_>catonano, quiliro: and for language students it may be good to work on translations from English to Spanish. <catonano>Thhey could even try to reproduce some scientific result arranging some pipeline as it was shown in a talk at the Fosdem (I don't remember the speaker's name. I apologize) <nicorikken[m]>rekado_: thanks for the help, now I'm running into a new bug, deeper in the code this time. I'll see if I can solve it myself. <rekado_>catonano: that seems a little too advanced to me. I think you meant Roel’s talk on the workflow language <catonano>rekado_: yes, Roel. Thank you. I was impressed by that <jsierles>hydra's mirror frequently returns 504 gateway timeouts. is there a way to continue with builds even when that happens? <jsierles>lfam: when i use that, guix goes into an endless 504-timeout loop <jsierles>this stuff is not stable enough to use this way I think. <quiliro>rekado_: LANG=fr_FR.utf-8 guix package --show=hello <quiliro>guix is impressive! i asked for a feature and guix has it already! <quiliro>it would be nice to default to Esperanto instead of English <rekado_>quiliro: we also have an Esperanto translation, but I don’t know how to enable it. <rekado_>LANG=eo_EO.utf-8 doesn’t seem to work <quiliro>what mailing list should i send the contribution possibility <civodul>quiliro: glibc doesn't have a proper eo locale <civodul>the workaround is to use LANGUAGE=eo <lfam>Hm, the setting of XDG_DATA_DIRS from ~/.guix-profile/etc/profile causes my Debian firefox to crash whenever the file-chooser dialog window is opened <lfam>It prints this as it crashes: (firefox-esr:1066): GLib-GIO-ERROR **: Settings schema 'org.gtk.Settings.FileChooser' is not installed <quiliro>description: GNU Hello montras la mesaĝon "Hello, world!" kaj finiĝas. Ĝi funkcias kiel ekzemplo de norma kodumada tradicio de GNU. Tiel, ĝi subtenas <quiliro>+ komand-liniajn argumentojn, plurajn lingvojn, kaj tiel plu.