<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. <brendyn>oh, i was thinking of writing that program actually. <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>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
<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). ***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 127.0.0.1 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 ***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 <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>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 ***jonsger1 is now known as jonsger
<efraim1>uh oh, speexdsp doesn't build on aarch64 <efraim1>civodul: it does, but in the configure.ac when it detected neon it defaulted to armv7-a, and only had flags for armv[456] ***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 berlin.guixsd.org 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. <civodul>mkbk: could you email the list about this issue? <civodul>ACTION has Guix installed on the local cluster at work \\o/ <civodul>i provided guidance to the sysadmin who took care of it, but it went rather well <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 mirror.hydra.gnu.org through, we should be able to fetch all the binaries *and* source <bavier>civodul: thanks, I'll get it a try <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 <civodul>bavier: sorry, emacs crash, grrr :-/ <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 <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? <quigonjinn>jonsger[m]: cool! this reminded out version should be updated <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) <bavier>sneek: later tell civodul: GNU Make 4.0 <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. <joshuaBPMan>Hello, odd question...is 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 <jonsger[m]>bavier: yeah found that. but I noticed that cmake!=qmake :P <bavier>jonsger[m]: I think it's in the qtbase package? ***fr33domlover1 is now known as fr33domlover
<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? <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 :( <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>actually we should just talk to the job server, that looks reasonably easy <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>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 <lfam>Well, webkitgtk is expensive to build but not actually used by many packages. So many it's okay to wait <lfam>I wonder, do the Nix people have similar issues? <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 <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>hopefully it'll start building within a few minutes <lfam>I need to add berlin to my substitute-urls, finally <ng0>civodul: yes, I just posted it to guix-devel@gnu.org , 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? <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 <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>i hope we'll have another occasion to use it ;-) <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 :(