IRC channel logs


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/ or in /doc/guix.html/ ...
<thomassgn>sorry, no idea pkill9
<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
<pkill9>i got openra running with it
<thomassgn>arg! I keep fudging how to send patch lists... well well.
<apteryx1>git send-email?
<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.
<vagrantc>that's been working with me so far
<thomassgn>yes, yes, Thats why I said I fudged it. I made a mistake. :)
<thomassgn>git send-email yes.
<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 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?
<reepca>... sneek?
<reepca>hm. no botsnack for you.
<marusich>Hello Guix!
<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.
<reepca>thanks, I'll try those.
<civodul>Hello Guix!
<cbaines>Morning civodul, how are you?
<civodul>heya cbaines, long time no see!
<civodul>i'm fine, & you?
<cbaines>Good thanks :)
<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>cbaines: cool!
<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>rekado_: nice!
<civodul>we could even organize an on-line activity
<civodul>like have a dedicate week-end or something to all work on that
<civodul>how was your talk BTW?
<rekado_>yes, a little distributed hack event could be nice
<rekado_>the talk was well-received.
<rekado_>the audience was quite diverse in terms of their background; some HPC admins, some data scientists, some biologists, some sales…
<jonsger>is kei kebreau on IRC?
<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
<rekado_>ACTION has to go
<civodul>rekado_: good, nice to have an audience with people from a variety of backgrounds
<civodul>jonsger: you should definitely tell them to have a look at and consider joining us!
<jonsger>civodul: the problem I know we do some HPC stuff (SLES High Performance Computing), but I don't know who makes it :P
<cbaines>hey bzp :)
<IntoxicatedHippo>What could cause this error? guix copy: error: SSH authentication failed for '': Failed to read private key: /home/liam/.ssh/id_rsa
<IntoxicatedHippo>connecting to the machine with opensh using that key works fine
<efraim>What are the permissions on the key file?
<IntoxicatedHippo>600 and I'm the owner
<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
<cbaines>in the (guix profiles) module
<civodul>pkill9: but that 'ca-certificates-bundle' function cannot be used as-is in a manifest
<civodul>we should do something about it
<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
<civodul>mine starts with:
<civodul>-----BEGIN RSA PRIVATE KEY-----
<civodul>Proc-Type: 4,ENCRYPTED
<civodul>DEK-Info: AES-128-CBC…
<civodul>and libssh is happy with it
<IntoxicatedHippo>mine is exactly the same
<civodul>uh, no idea :-/
<IntoxicatedHippo>Do you think running `sudo make install` on guix would have messed up my GuixSD install?
<IntoxicatedHippo>I'm an idiot and forgot what I was doing for a second
<civodul>not sure, i don't know
<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
<civodul>could be :-/
<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 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>oleo: oh too bad
<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.
<civodul>how can a daemon become broken? :-)
<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....
<IntoxicatedHippo>Xen on a laptop: how bad of an idea is it?
<oleo>it's not like kvm not ?
<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 ?
<IntoxicatedHippo>I meant XenServer (also I meant to type that in a different window)
<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
<vagrantcish>using debian's initrd
<bavier`>vagrantcish: probably missing a module for the rootfs storage?
<bavier`> has a "nand" module, I wonder if our linux-libre has it
<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>but debian at least has modprobe in the initrd :)
<bavier`>ohh, that probably helps
<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?
<vagrantcish>and i thought the insmod was basic. :)
<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>hmm it should
<vagrantcish>it didn't even detect sunxi-mmc
<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?
<vagrantcish>civodul: yeah, i've been working on htat
<civodul>ok good :-)
<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
<civodul>makes sense :-)
<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>surely this has been talked about already ...
<vagrantcish>obviously would require rebuilding everything
<bavier`>I don't recall it being discussed
<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>but it still fails to boot:
<vagrantcish>/dev/sda2: clean, 41890/983040 files, 384659/3932160 blocks
<vagrantcish>ERROR: In procedure mount:
<vagrantcish>In procedure mount: No such device
<vagrantcish>but ... it just finished checking the device
<vagrantcish>ACTION is confuzificated
<vagrantcish>not of the /dev/disk/* symlinks are present ...
<vagrantcish>specifying --root=/dev/sda2 doesn't wait long enough for the device to get initialized.
<vagrantcish>so frustratingly close...
<vagrantcish> /o\\
<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
<vagrantcish>civodul: yeah, figured
<civodul>so you have to use actual labels and such
<civodul>ok :-)
<vagrantcish>well, i used 'uuid
<civodul>but --root=THELABEL should work
<Rukako>15:33:43 < civodul> DEK-Info: AES-128-CBC…
<vagrantcish>which has worked for all the others too
<vagrantcish>all the other systems i've installed
<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.
<vagrantcish>guess it's worth trying...
<civodul>Rukako: good point!
<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 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>i don't know
<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.
<rekado_>nckx: oh, pigx is broken?
<pkill9>i just look at examples of how other packages do it
<rekado_>ACTION checks now
<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
<rekado_>I want to be informed as soon as the builds for certain packages fail.
<pkill9>hmm i'm not entirely sure ngz
<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>...and pigx builds \\o/
<nckx>‘Works’ is a matter I'll leave to others.
<rekado_>nckx: thank you!
<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>rekado_: Pushed. It should just work according to upstream <>. I
<nckx>ACTION hopes sneek has found happiness.