IRC channel logs


back to list of logs

<OriansJ>caffe: since shepherd is scriptable in guile you simply program how you want shepherd to behave in regards to the desired services and their initialization. (the manual is unfortunately a little light )
<CharlieBrown>How do I encrypt my disk?
<CharlieBrown>brendyn: Synergy?
<brendyn>CharlieBrown: What?
<CharlieBrown>brendyn: There's an app called Synergy that lets you drag your mouse and keyboard from screen to screen on several computers that are side by side.
<CharlieBrown>Drag your mouse, and your keyboard controls that computer too.
<CharlieBrown>Like a multi-monitor setup.
<brendyn>oh, i was thinking of writing that program actually.
<CharlieBrown>It already exists. It's called Synergy.
<brendyn>CharlieBrown: the program is in guix but the website makes it look like it's a proprietary program, requiring sign up and money
<CharlieBrown>brendyn: I have no problem with their business model, but I want to know what I'm buying.
<ng0>sneek: later tell civodul: wrt the new website discussion, in case you missed it I've posted patches for the wip-website branch on the guix-devel list, subject including [PATCH][website]
<htgoebel>Good morning Guix.
<htgoebel>With a system-description, how can I easily add singe file (shell-script)? Its only for debugging, so a package is overdose.
***Piece_Maker is now known as Acou_Bass
<thomasd>htgoebel: saw your question in the log. You can use “extra-special-file” for that (
<htgoebel>thomasd: Merci. Not exactly what I want since it needs to got into a service (and not into the system declaration), but would be okay – if I'd understand how to use it.
<thomasd>in a service, you can extend special-files-service
<htgoebel>thomasd: Buhh, this sounds complicated. I'll better head towards sharing a folder.
<thomasd>htgoebel: in your service-type definition, add something like (extensions
<thomasd> (list (service-extension special-files-service-type ...))), there's examples in the manual
<thomasd>and replace ... by a list of tuples (file-name file-content), I believe
<htgoebel>Yes, sharing is much easier, just add run "guix system vm --share=$PWD=/exchange" – and I can access the output from the host-machine, too.
<htgoebel>thomasd: Most examples in the manual are quite terse and the learning curve is quite steep for me. For me many examples are only fragments
<thomasd>htgoebel: Yes, I also needed some experimentation. Of course, the code itself contains many examples.
<thomasd>But a more in-depth “tutorial” would be useful. Otherwise, I think GuixSD services are actually pretty great (not much experience writing services on other systems, though, maybe it's just as nice with systemd, or other init systems).
<htgoebel>thomasd: tutorila: Ack
***Piece_Maker is now known as Acou_Bass
<htgoebel>Argl, I can't get the ssh-login on the qemu-vm to work. I'm using the openssh-service-type with (permit-root-login 'without-password), but cant log-in. The connection is closed, I can not even spot a log-entry in the machine.
<efraim>After 'herd start cow-store /mnt' everything is supposed to be downloaded and installed to /mnt/gnu/store?
<efraim>htgoebel: I've found on my current machine ssh is available to but not to 192.168.x.y
<htgoebel>efraim: well, connection is established "Connection reset by peer". So I assume communication basically works. (if the guest is not running, the message is "Connection refused")
<efraim1>now that i've tried ssh-ing into that guixsd box, suddenly nmap shows port 22 open
<efraim1>i'm filing that under WTF
***Piece_Maker is now known as Acou_Bass
<htgoebel>efraim: solved my issue: I was still starting an old machine with openssh not installed :-( So the Connection reset by peer seems to come from qemu
<civodul>Hello Guix!
<sneek>Welcome back civodul, you have 1 message.
<sneek>civodul, ng0 says: wrt the new website discussion, in case you missed it I've posted patches for the wip-website branch on the guix-devel list, subject including [PATCH][website]
<rekado>civodul: I’m glad the JSON importer made someone happy :)
<rekado>I previously played with some code to use the importer transparantly in the background with “guix build”.
<civodul>that would be fun
<civodul>we could have a generic way to do that with *all* the importers
<rekado>I accidentally committed a draft version of that back when I pushed the importer
<rekado>we couldn’t use streams any more
<rekado>and all importers would need to be recursive importers IIUC
<rekado>because their input fields must contain actual package objects
<rekado>so they need to be created or looked up first
<civodul>well, that's the way forward! ;-)
***jonsger1 is now known as jonsger
<efraim1>uh oh, speexdsp doesn't build on aarch64
<efraim1>not bad, just had to disable neon
<civodul>efraim1: good :-)
<civodul>so aarch64 doesn't support neon?
<efraim1>civodul: it does, but in the when it detected neon it defaulted to armv7-a, and only had flags for armv[456]
<civodul>oh i see
***jonsger1 is now known as jonsger
<mkbk>I'm here to talk about an elogind error
<mkbk>I'm using artix. invoking "loginctl --no-ask-password poweroff" gives me: failed to reboot via elogind. message recipient disconnected from message bus without repleying PID1: recieved "reboot" from FIFO ... Staring reboot runlevel *Call to flock failed: Resource temporarily unvailable
<rekado>PSA: On Monday+Tuesday will be undergoing maintenance.
<rekado>need to move servers to different racks and switch the build farm to a new head node.
<rekado>will send mail to guix-devel and sysadmin later.
<rekado>ACTION goes afk
<civodul>mkbk: weird
<civodul>mkbk: could you email the list about this issue?
<civodul>ACTION has Guix installed on the local cluster at work \\o/
<bavier>civodul: cool!
<civodul>i provided guidance to the sysadmin who took care of it, but it went rather well
<jonsger>nice :)
<civodul>also, one of the nice things is that content-addressed mirrors are a perfect match for their host whitelisting policy
<civodul>basically, even if they just let through, we should be able to fetch all the binaries *and* source
<civodul>bavier: i forgot to Cc you, but this is the patch series with the "make -j" fix:
<civodul>let me know what you think
<bavier>civodul: thanks, I'll get it a try
<bavier>civodul: does it work for you?
<bavier>at first glance, I'm expecting it'd always build with (current-processor-count)
<bavier>because MAKEFLAGS never includes the actual number, afaik
<civodul>bavier: for me it includes whatever "-jxxx" flag you passed
<jonsger[m]>nice :)
<bavier>jonjits[m]: yeah cool
<civodul>bavier: sorry, emacs crash, grrr :-/
<civodul>did you get my reply?
<bavier>civodul: yes
<civodul>ok :-)
<bavier>I hope I'm pleasantly surprised when I try
<civodul>now if you run "make -j", it won't behave like -j, but instead like "-jN" where N is the number of procs
<civodul>i think that's acceptable though
<jonsger[m]>I hope using the GuixSD instead of the Guix logo was right...
<quigonjinn>jonsger[m]: did you get in contact with the kicad project for that addition?
<jonsger[m]>quigonjinn: kind of :P
<quigonjinn>jonsger[m]: cool! this reminded out version should be updated
<quigonjinn>s/out/me our/
<jonsger[m]>quigonjinn: maybe I give it a try this weekend. but first have to build other stuff and I have only my laptop with dualcore :(
<bavier>sneek: later tell civodul: e.g. if I put a (pk 'MAKEFLAGS flags) in compile-all.scm and run make with '-j4', I see ";;; (MAKEFLAGS "w -j --jobserver-fds=3,4")", so parallel-job-count returns (current-processor-count)
<sneek>Got it.
<bavier>sneek: later tell civodul: GNU Make 4.0
<sneek>Got it.
<quigonjinn>jonsger[m]: don't bother with it. I plan to do it soon. And add support for ngspice as well, now that we have a package in guix.
<jonsger[m]>quigonjinn: okay :)
<joshuaBPMan>Hello, odd guix becoming a good enough tool that the Hurd developers can start developing the Hurd on guix instead of debian?
<joshuaBPMan>like it would be cool if you could do a "guix system vm --hurd", which would spawn a vm that is using the GNU Hurd.
<jonsger[m]>how can I change the build directory with cmake-build-system? so running cmake in foo/bar instead of foo. When foo is the source directory
<bavier>jonsger[m]: you can add a phase before the configure phase that changes directory
<bavier>jonsger[m]: e.g. search for 'chdir' in gnu/packages/*.scm
<CharlieBrown>joshuaBPMan: Mm...
<jonsger[m]>bavier: yeah found that. but I noticed that cmake!=qmake :P
<bavier>jonsger[m]: indeed :)
<jonsger[m]>we don't have support for qmake yet?
<bavier>jonsger[m]: I think it's in the qtbase package?
***fr33domlover1 is now known as fr33domlover
<jonsger[m]>found it. seems to be fun to use it... ^^
<ng0>we have qmake support as far as I remember
<ng0>before I stack up lots of patches as part of the pitivi series… is anyone up to reviewing gavl, python-pycanberra and gst-transcoder?
<lfam>CVE-2017-1000256 :(
<sneek>lfam, you have 1 message.
<sneek>lfam, efraim1 says: I'm installing guixsd with the store on btrfs, tests/store.scm failed for me twice while building 0.13.0-8
<lfam>Hm, it's not good that test fails like that :(
<jonsger[m]>yeah. it's kind of compiling chdir + qmake...
<lfam>Looks like that test was reported to fail previously:
<civodul>ng0: you mentioned sending something for the new web site but i can't find it at
<sneek>Welcome back civodul, you have 2 messages.
<sneek>civodul, bavier says: e.g. if I put a (pk 'MAKEFLAGS flags) in compile-all.scm and run make with '-j4', I see ";;; (MAKEFLAGS "w -j --jobserver-fds=3,4")", so parallel-job-count returns (current-processor-count)
<sneek>civodul, bavier says: GNU Make 4.0
<civodul>ng0: am i missing something?
<civodul>bavier: oh!
<civodul>i must have overlooked it
<civodul>actually we should just talk to the job server, that looks reasonably easy
<civodul>hmm maybe not
<civodul>well, worth trying
<bavier>civodul: right, that's where I was trying to go while I was looking into it
<civodul>so you actually went further than i did :-)
<bavier>where I got stuck was the threading part.
<civodul>that'd mean we can't allocate all the threads upfront
<bavier>you'd need something like (guix workers) but with a dynamic pool and an execution guard
<lfam>How is Hydra doing nowadays? If there is already a jobset running, can it handle another evaluation now?
<civodul>too complex
<civodul>lfam: we typically have to stop the queue runner while it evaluates
<lfam>I just pushed a webkitgtk update and of course it would be best if people didn't have to build it themselves
<civodul>and evaluations are super slow
<lfam>Hm :(
<civodul>ah yes
<lfam>Well, webkitgtk is expensive to build but not actually used by many packages. So many it's okay to wait
<civodul>yeah just start an evaluation
<lfam>I wonder, do the Nix people have similar issues?
<civodul>with evaluations?
<civodul>first, they have more biffy hardware :-)
<lfam>With scalability and reliability of Hydra, in general
<OriansJ>ironically with better resolution 2+ Million lines per second compiles are possible in C++
<civodul>scalability has always been hard with Hydra in my experience
<civodul>but they addressed it with faster hardware for one part
<jonsger[m]>reading the source code of guix helps understanding how guix works. that's a surprise :P
<lfam>Probably a good use of their resources
<civodul>and also currently we're paying the terrible Guile 2.2 bug
<civodul>it was better with Guile 2.0
<lfam>Okay, I'm going to request a new evaluation
<civodul>i'll put the queue-runner on hold for a while
<lfam>Okay, it's been scheduled
<civodul>queue runner taking a break :-)
<civodul>berlin is already evaluating FWIW
<civodul>hopefully it'll start building within a few minutes
<lfam>I need to add berlin to my substitute-urls, finally
<civodul>i tried again to come up with a reduced test case for but didn't manage yet
<ng0>civodul: yes, I just posted it to , not debbugs.
<civodul>apteryx[m]: i'm testing the github patch right now
<civodul>i had almost forgotten about it, bad bad!
<apteryx>civodul (IRC): Nice! It was done by a script; the hashes were repaired and the content diff'd to make sure it was exactly the same.
<apteryx>so it should work, but it's good that you are testing it.
<lfam>I'm curious, what is the difference that causes the hash to change?
<apteryx>an update to git-archive
<lfam>I mean, in the files themselves something must be different
<apteryx>the difference is only in the tar binary format
<lfam>I remember the GitHub team mentioned the change but I don't remember what it was
<apteryx>not in the contents
<civodul>lfam: it's an obscure thing about tar file name encoding IIRC
<apteryx>yep, it only affected paths longer than 100 chars or so
<lfam>So, the script compares the unpacked old and new tarballs?
<apteryx>so that's why only a few of our packages using github dynamically generated archive got hit
<apteryx>it compares the unpacked current github tarball (that got mutated) with our current binary substitute
<apteryx>it's not fancy but it did the job (fancier would have been to fetch from git, and then use the two git versions that generated the old and new hash to gain trust that this is the only change (git))
<civodul>(fiasco finder) looks nice
<civodul>i hope we'll have another occasion to use it ;-)
<apteryx>I hope not, but we never know!
<civodul>heheh :-)
<civodul>great job anyway
<lfam>I think it's certain we will experience this sort of thing again :)
<lfam>Actually, we already deal with it on a regular basis for linux-libre
<lfam>But since our tree typically only has a handful of linux-libre sources, we usually don't notice
<lfam>I lost track of the conversation about handling sources differently with respect to --no-substitutes, unfortunately :(