IRC channel logs
2018-05-17.log
back to list of logs
<thomassgn>anyone know how to see changes to texinfo documentation in source tree? running 'make info' looks like it does something, but it doesn't say where it puts the result... <pkill9>don't suppose anyone knows a way to specify a directory for mono to look for a certificates store? I want to wrap it so the user doesn't have to run 'cert-sync --user /etc/ssl/certs/ca-certificates.crt' <thomassgn>derp. Ofcourse, it's all gathered into a file called /doc/guix.info or in /doc/guix.html/ ... <thomassgn>mono, that's the .net thing isn't it? does it work well? <pkill9>yeah it is, and yeah it does as far as i can tell <thomassgn>arg! I keep fudging how to send patch lists... well well. <apteryx1>I reckon it must be detailed in the contribute node of the Guix info manual, as a reference. <vagrantc>if it's a patch series, you need to make sure they all end up in the same bug :) <apteryx1>Yep, it's summarily detailed in the Sending a Patch Series node of the Guix manual. <apteryx1>You can also just send an email with the patches attached. <thomassgn>yes, yes, Thats why I said I fudged it. I made a mistake. :) <thomassgn>going to sleep, way overdue. :P But sent patches for updating and making the code of conduct more prominent. <reepca>sneek: later tell uniq10: sorry for the delay... there's been some family chaos lately and I've been away from my desktop (unfortunately it looks like that's going to continue over the weekend). IIRC, I read a note in the nix source about MS_SHARED and it potentially causing problems (in build.cc I believe). So in my situation I changed mount-file-systems, in call-with-container (specifically in mount-file-systems), to first remount <reepca>everything as MS_PRIVATE when in the new mount namespace (but before running pivot-root). Are you using call-with-container? <marusich>Huh, the ImageMagick source is back for version 6.9.9-43. I guess I don't need to fix it after all. <reepca>so all of a sudden my hard drive performance on my GuixSD laptop has become abysmal... not even a restart or anything noticeable triggering it. What have we got packaged for checking the health of those things? <marusich>That might just tell you what you already know, though. <marusich>Try smartmontools. If your hard drive supports SMART, then it can tell you some interesting things and even run diagnostics. <marusich>Another potentially useful toolkit maybe sg3_utils, but that's a bit lower level. Smartmontools will be easier to use, probably. <cbaines>I'm hoping to make some time in the coming weeks to get back in to some of the Guix related patches I have lying around <civodul>our patch queue has been growing lately :-) <rekado_>civodul: I’ve been planning to reserve some time after my return from Boston for working through the patch queue. <civodul>we could even organize an on-line activity <civodul>like have a dedicate week-end or something to all work on that <rekado_>yes, a little distributed hack event could be nice <rekado_>the audience was quite diverse in terms of their background; some HPC admins, some data scientists, some biologists, some sales… <rekado_>it’s hard to find the right words that work for a mixed audience like that. <rekado_>but judging from the questions I got it does sound like the general ideas came across. <rekado_>I’ve also been “networking” at the expo; talked to “cloud HPC” providers about their software provisioning systems (which appear to be rather primitive on average). <rekado_>some of them might be interested in providing Guix for their products. <rekado_>this expo/conference is saturated with sales reps; the sponsored presentations here are pretty bland and low in information. <jonsger>I should maybe talk with our in house HPC focused devs if they are interested in guix <rekado_>but there are some goodies here and there. <rekado_>jonsger: if they are they are welcome to join the Guix@HPC working group, where we discuss solutions to common HPC problems and how Guix should address them. <rekado_>it’s good to have more people from different HPC environments provide input <civodul>rekado_: good, nice to have an audience with people from a variety of backgrounds <jonsger>civodul: the problem I know we do some HPC stuff (SLES High Performance Computing), but I don't know who makes it :P <IntoxicatedHippo>What could cause this error? guix copy: error: SSH authentication failed for '10.1.1.30': Failed to read private key: /home/liam/.ssh/id_rsa <efraim>What are the permissions on the key file? <efraim>Unfortunately that was my big idea <civodul>IntoxicatedHippo: if you have a checkout of Guix around, could you uncomment the #:log-verbosity thing in guix/ssh.scm and see what it says? <pkill9>how do i make a manifest consisting of a specified package? i want to use the 'ca-certificate-bundle' function (or whatever it's called) from guix/profiles.scm to produce a ca-certificates.crt file using the certificates from the nss-certs package <pkill9>the ca-certificates-bundle function takes one arguments called 'manifest' <cbaines>pkill9, there is a packages->manifest function <civodul>pkill9: but that 'ca-certificates-bundle' function cannot be used as-is in a manifest <pkill9>i think the best workaround would be to generate a profile with the nss-certs input (which will invoke ca-certificates-bundle and create the .crt file) and use that as a package input. How would I go about doing that? <civodul>IntoxicatedHippo: thanks, the libssh messages are not very helpful though :-/ <civodul>i won't ask you to paste your private key ;-) <civodul>but maybe you could check if there's anything "special" about it <civodul>compared to a key created with an older OpenSSH, say <IntoxicatedHippo>Do you think running `sudo make install` on guix would have messed up my GuixSD install? <civodul>you'd have to check where it was installed <civodul>if it was /usr/local, it'll be easy to delete it <civodul>but then there's localstatedir and sysconfdir <IntoxicatedHippo>I also did a `sudo make uninstall` so there's a chance I killed some GuixSD files <oleo>my system reconfigure failed with gst-plugins-good <oleo>and i gave up, since i'm not having an ssd etc... <oleo>it's taking too long, and doing it over vm etc....it sucks... <oleo>the gst-plugins-good failed at the test stuff.... <oleo>so it didn't continue.... <oleo>all the rest seems to have compiled fine tho.... <civodul>perhaps something's wrong with this package <IntoxicatedHippo>So it seems that I've broken the daemon, time to spend a few days rebuilding eveything <davexunit>I have a hopelessly broken daemon on my work machine and I don't know what to do other than delete everything and start over. <thomassgn>question. I see some packages variable names have '-version' at the end, but most don't. Are the version added to the variable name when there are two versions packaged? I mean, do we then change it and add a (define-public package-name package-name-with-version)? <roptat>thomassgn: usually that's when there are more than one version of the package, like python and python-2 <bavier`>thomassgn: the manual discusses this topic <oleo>maybe the testsuite was just not designed to be run in a vm.... <oleo>where some stuff maps directly from the hardware to the vm via the permissal of the kernel <oleo>so xen is always non-kvm ? <oleo>or what is xen actually ? <mbakke>Qubes OS uses Xen (not the proprietary XenServer though) and allegedly works fine on laptop. <vagrantcish>arg. after 3-4 days of guix pull, guix system build, etc. after a few iterations ... a few glitches ... i've got an aarch64-linux guixsd installation on pine64+ ... only problem is i can't figure out the right combination of kernel modules to actually mount the rootfs <vagrantcish>is there a way to just inject all the modules onto the initrd? <vagrantcish>i've booted the guix built kernel on debian, using it's initrd ... so i know the kernel works with the hardware <bavier`>vagrantcish: probably missing a module for the rootfs storage? <vagrantcish>bavier`: it's got sunxi-mmc, which is what the rootfs uses ... but many arm modules require arbitrary regulator and phy modules also <vagrantcish>ACTION plays the module whack-a-mole game with debian when adding support for a new board <vagrantcish>it's also extra-fun because modules may be named foo-module on the filesystem, but when loaded are foo_module ... <vagrantcish>so, somewhat unsurprisingly, the module support in guixsd's initrd loads the kernel modules directly from guile? <civodul>vagrantcish: normally "guix system init" would tell you whether modules are missing <civodul>so even if you don't use it in the end, you could run it just to get the diagnostic <civodul>and then add them to 'initrd-modules' <vagrantcish>civodul: yes, that gets extra complicated with the - and _ <vagrantcish>civodul: but it isn't smart enough to detect these modules <vagrantcish>civodul: i've already added numerous modules to the initrd <civodul>(gnu build linux-modules) "canonicalizes" module names <vagrantcish>and then with arm systems, there are frequently soft module dependencies ... e.g. the module itself doesn't depend on another module, but requires a certain feature to be available, such as a regulator or phy <civodul>maybe for now you could run "lsmod" in Debian on that box, and then add all that to initrd-modules? <civodul>once you have that up and running we can figure out why 'guix system' doesn't do the right thing <vagrantcish>civodul: i've been trying to selectively add a couple at a time ... but now i'm just taking the shotgun approach <vagrantcish>as i'd like to be able to propose a proper patch suggesting the default modules for pine64+ <vagrantcish>i think i saw an extra-modules somewhere for beaglebone black, for example <vagrantcish>i've also run into a problem where i suspect u-boot is having trouble reading files from /gnu/store ... possibly due to the sheer number of entries <vagrantcish>if i copy the same initrd/linux/dtb stuff to a separate partition and boot from that, it reads the files fine <vagrantcish>ACTION really wishes the store used package/version/hash instead of hash-package-version <vagrantcish>would mitigate problems like that, and have numerous other advantages <vagrantcish>tab-completion beginning with a hash is ... not very helpful <vagrantcish>hrm. now i can get the initrd to recognize the rootfs from the initrd when i put the microSD into a USB adapter ... <vagrantcish>/dev/sda2: clean, 41890/983040 files, 384659/3932160 blocks <vagrantcish>specifying --root=/dev/sda2 doesn't wait long enough for the device to get initialized. <nckx>Got to love UNIX error messages. ‘No such device. No, not telling you which. That would be helping.’ <nckx>vagrantcish: The initrd uses filesystem-specific code to read UUIDs and labels straight off the superblock. No /dev/disk/* paths are used (or indeed available at early boot time). <nckx>That's not immediately helpful information but important to keep in mind :-) <vagrantcish>just curious how it could in one second fine the rootfs well enough to fsck it, but then be unable to find it... <nckx>Yeah. That's where actual error reporting would come in quite handy... <vagrantcish>ACTION notes that bad errors messages are not unique to UNIX by any stretch <nckx>I obviously don't use pigx, but it seems to've been broken for some time while being hailed as an example of Guix packaging on our blog. Not ideal. <civodul>vagrantcish: /dev/disk/* is from udev and udev is not running at that point <civodul>so you have to use actual labels and such <Rukako>15:33:43 < civodul> DEK-Info: AES-128-CBC… <Rukako>while it should not really matter, try to select AES-256 if possible <vagrantcish>civodul: you think LABEL would work any better than UUID ? <nckx>vagrantcish: I didn't say that; but there was a concious choice to make them as ‘dumb’ as possible. <civodul>vagrantcish: both should work equally well, but probably better than /dev/sda1 <civodul>ACTION seems to be reading half of the lines in the backlog or something :-) <vagrantcish>civodul: does it require rebuilding the initrd, or should changing --root= from the bootloader work? <civodul>changing --root in the bootloader should be enough <ngz>Hello. I'm trying to package some Python application with trivial-build-system (no setup.py or some such in the package). I add some Python inputs. However, once built, when I try to launch the executable, it doesn't find at least one input library. <ngz>I tried to use (wrap-program executable `("PYTHONPATH" ":" = (,(getenv "PYTHONPATH")))) <ngz>But I get some error. <ngz>I'm not sure what to do next. <pkill9>ngz: i dunno if it works with trivial-build-system, but the 'native-search-paths' and 'search-paths' functiosn do what you're trying to do i think <ngz>Is there some documentation about them? <pkill9>check the gnu/packages/python.scm, there's lots of python packages that use this i think <pkill9>ah it should work with trivial-build-system because it's defined in the package, not the part where you build <pkill9>ngz: there's a small bit of documentation on search paths in section 4.1.1 of the guix manual <ngz>Documentation for native-search-paths in the manual: A list of `search-path-specification' objects describing search-path environment variables honored by the package. <ngz>Then I search for "search-path-specification"... nothing. <pkill9>i just look at examples of how other packages do it <pkill9>and also the definition of the function itself <ngz>pkill9: What is the difference between setting a search path or wrapping a program as some build systems do? <ngz>I'm not sure to even understand what a search-path is. <rekado_>I need to set up some notifications on berlin.guixsd.org <rekado_>I want to be informed as soon as the builds for certain packages fail. <nckx>rekado_: Not directly. Multiqc is. I've relaxed its requirement on an older version of matplotlib and it builds. <nckx>I read that as: I can just patch multiqc to relax the version requirement with no ill effects. <vagrantcish>hrm. exact same behavior using a label instead of uuid ... it finds the device, runs fsck on it, and then can't find it to mount <vagrantcish>since it took a day or two to run guix pull, i haven't updated to the latest and greatest, but didn't seen anything obvious that would be relevent here <nckx>‘Works’ is a matter I'll leave to others. <ngz>pkill9: thank you for the information. It is still quite obscure. I'll try to use that. <nckx>Oh. First time I've seen a ‘(C) <name>, <company name>’ header in Guix. <nckx>ACTION hopes sneek has found happiness.