IRC channel logs


back to list of logs

<civodul>hmm dunno
<Apteryx>Is there a way to simulate booting from raid when using 'guix system vm'?
<reepca>Hm, trying to run with an image file I downloaded and I get "This interpreter (vers. 0) cannot read image file (vers. 68021)." Something seems a bit off there.
<Apteryx>reepca: what is this script?
<sgil>hey guys stupid question.. but how you actually play youtube videos on guix or things like that ?
<civodul>sgil: it "just works" for me with Conkeror and IceCat
<civodul>but otherwise you can also "guix package -i mpv" and run "mpv"
<civodul>or use youtube-dl
<sgil>civodul: thanks.. i finally found the thread about flashplayer :)
<civodul>Flash is dead and burried AFAIK, so you don't need to worry about that
<sgil>but how about spotify?
<sgil>I was wondering how to use it on guix only way i figured i might install wine and then use windows app :D
<sgil>or qemu with random linux
<sgil>or have it on server and run it through ssh
<efraim>sneek: later tell lfam with my gccgo patches syncthing built successfully on aarch64
<sneek>Will do.
<civodul>i've never used Spotify, but i doubt it requires Flash
<efraim>sneek: botsnack
<sgil>civodul: well the web app does
<civodul>well ok, then you might want to package GNU Gnash
<sgil>oh i actually tried that few hours ago
<sgil>i mean install it but packaging it could work too
<civodul>ACTION has to go afk
<sgil>civodul: thanks :)
<efraim>as of evaluation 109772, we have a (actual + dependancy) failure rate of 6.84%
<civodul>efraim: that's better than before, right?
<efraim>civodul: I didn't count the autoconf evaluation since Java failed, but its in the same range
***civodul changes topic to 'GNU Guix | | videos: | bugs: | patches: | paste: | log: | Guix-HPC announced:'
<civodul>efraim: autoconf evaluation?
<civodul>news! :-)
<efraim>109773, with all the changes to when the autoconf phase runs
***Piece_Maker is now known as Acou_Bass
<efraim>civodul: I made it as far as jamvm for java bootstrapping on aarch64, i might need to write some custom assembly to make it work
<rekado>civodul: the MDC version of the press release is out now:
<rekado>They also have a German variant:
<oriansj>nice rekado
<efraim>i'm looking at libdrm on staging on aarch64, looks like i'll need to look a bit more into some of the options there to make it more featurefull
<efraim> who loves architecture specific features?
<Apteryx>rekado: FYI, X.509 certificate has expired for your Elephly site
<Apteryx>civodul: Great news! :) One typo: methodologies for carry out their research --> s/carry/carrying
<efraim>building boost on aarch64 with --cores=1, hopefully this time it doesn't hit load of 25
<Apteryx>guix weather is pretty cool! I wish it would be faster though
<Apteryx>Maybe the serve could precompute the results every hour and return these instantly?
<efraim>i found it tied up my substitute server while I was querying it
<civodul>Apteryx: where's that typo you mentioned?
<civodul>note that i don't have write access to the institutional web sites
<civodul>Apteryx: re 'guix weather', the servers do precompute the results (narinfo URLs)
<civodul>i'm not clear exactly why performance isn't better
<efraim>maybe we should enable "surfaceless" platform for mesa, it enables offscreen-only rendering
<Apteryx>alternatively 'to carry out their research' would work too, I think.
<Apteryx>disclaimer: I'm not a native English speaker ;)
<civodul>Apteryx: indeed, fixed!
<Apteryx>it must be thrilling to know that your paying job (at least part of it?) will be to work on your pet project :)
<efraim>I feel like the xorg-xserver-xwayland package shouldn't be wayland-or-bust, or we should have an xwayland-and-xorg package
<Apteryx>Congrats for the te
<Apteryx>*congrats to you and those who will work on Guix-HPC!
<efraim> mesa has opengl enabled by default
<efraim>... or not
<civodul>Apteryx: thanks Apteryx! that's pretty nice, indeed
<efraim>wow, nvm, opengl is enabled by default, opencl is disabled by default
<civodul>heh, confusing :-)
<cehteh>can package be tagged to be distributed source only? aka that would be a good choice to include zfs
<civodul>efraim: don't forget <> :-)
<cehteh># guix pull
<cehteh>Updating from Git repository at ''...
<cehteh>guix pull: error: Git error: the SSL certificate is invalid
<cehteh>.. oops?
<Apteryx>Where can I find the public key for the server?
<Apteryx>cehteh: yes, it can
<civodul>Apteryx: it's the file called '' in the repo or tarball (do make sure to authenticate it!)
<civodul>cehteh: what version of Guix are you upgrading from?
<Apteryx>civodul: Oh, so it shares the same key as the bayfront machine?
<cehteh>guix (GNU Guix) 9baa969758557857a4c8614278b59db9786ae1eb
<Apteryx>And I think that key is already trusted on GuixSD, is this correct?
<Apteryx>found my answer in %default-authorized-guix-keys: yes!
<Apteryx>thank you.
<cehteh>ACTION gets new server hardware next days, i wonder if i try to start guixsd for real this time, but i guess i am not there yet
<civodul>Apteryx: yeah
<Apteryx>cehteh: I suggest you do. You'll get there faster z)
<civodul>cehteh: you should try, it's really great! :-)
<cehteh>well seen my comment about zfs above .. i want to go with zfs this time
<cehteh>civodul: i have too much troubles with guix still see the ssl error ..
<lrochfort>Hi. I'm trying to install guixSD, but I'm behind an http proxy. How do I configure guix system init to use the proxy?
<civodul>cehteh: could you report the problem to, with the full output of "guix --version" and "guix pull"?
<civodul>lrochfort: unfortunately that's not easily doable, see
<cehteh>there isnt much .. just the lines i've shown
<lrochfort>civodul: Ah, that's a shame. Thanks.
<cehteh>civodul: do you need any more info?
<cehteh>i try to reboot that vm first, was in hibernation for about 2 weeks
<cehteh>civodul: hah reboot solved it, but shall i still report that? that shouldnt happen right?
<civodul>"reboot solved it"?
<civodul>cehteh: report it if you can reproduce it
<cehteh>maybe clock screwd up because vm was hibernated .. when i have that in future i check more careful
<bavier>yay guix-hpc :)
<civodul>hey bavier :-)
<civodul>now we need more people to join!
<bavier>oh, modules ...
<cehteh>root@guixfarm ~# cp
<cehteh>bash: cp: command not found
<bavier>no coreutils?
<cehteh>ah ..
<cehteh>no ..
<cehteh>my fault
<cehteh>sudo su :)
<cehteh>(old habbit)
<cehteh>the haskell boostrapping issues havent resoved meanwhile? ...
<civodul>which issues?
<cehteh>do we have haskell .. no :)
<bavier>cehteh: we have ghc
<cehteh>oh yes? lemme look again
<cehteh>i need git-annex and havent found it
<bavier>and quite a few haskell libraries
<bavier>cehteh: git-annex is still underway
<cehteh>who does it?
<cehteh>and whats blocking?
<bavier>cehteh: I worked on it a while back, and I think someone else was working on it more recently.
<nckx>Hullo all. What are considered the rebuild thresholds for master/staging/core-updates nowadays?
<bavier>the last blocker I recall was related to git-annex's build failing
<cehteh>oops :D
<civodul>isn't git-annex superseded by git-lfs?
<civodul>(not that it really helps but...)
<civodul>heya nckx!
<civodul>nckx: see for the thresholds
<bavier>oh, hadn't heard of git-lfs before. Looks cool. I think it was still pre-1.0 when I was trying to package git-annex ;)
<nckx>civodul: Oh, whoops. I didn't realise it was in the manual now :-)
<nckx>ACTION still had the original list mail from yonks ago bookmarked.
<efraim>we're going to have to package vulkan eventually
<davexunit>vulkan is just part of mesa, no?
<nckx>Now I'm still confused since I remember seeing the number 1,800 somewhere too. Must have been non-authoritative content. Never mind.
<efraim>for us vulkan is essentially an input to mesa, like libdrm
<lfam>sneek: later tell rekado: Nice work with elogind. That was on my long list :)
<sneek>Welcome back lfam, you have 1 message.
<sneek>lfam, efraim says: with my gccgo patches syncthing built successfully on aarch64
<sneek>Will do.
<lfam>efraim: Awesome
<lfam>I improved it a bit last night, reducing the contents of the GOPATH variable to packages whose store names start with 'golang-'. I copied this idea from the emacs-build-system. But it would be better to pass a list of inputs using go-build-system from the host side, but I didn't figure out how to do that yet.
<lfam>I still find the host / build border tricky to navigate
<lfam>Anyways, I force pushed the latest version to my tree on GitHub
<lfam>Once I do that last bit, I think it will be ready
<efraim>i wonder if we can enable opencl for mesa on x86{,_64}
<cehteh>git-lfs is no substitute for git-annex
<cehteh>whatever the marketing department tries to tell you :)
<cehteh>WAA .. guix must hate me:
<cehteh>or i am dumb .. did a pull but as other user :)
<lfam>cehteh: Yes, `guix pull` is per-user
<cehteh>i really want guix for groups
<lfam>You can share it by symlinking ~/.config/guix/latest to the "main" user's copy
<cehteh>well somewhat 'officially' blessed with a configuration and workflow
<cehteh>so that 'root' can install software for all people in group 'office' for example
<cehteh>per group profiles
<cehteh>there was some hack for that
<efraim>mesa-17.2 has asm support for aarch64 and arm
<davexunit>that will have to wait until version 3.11
<davexunit>guix for workgroups
<cehteh>that was my thinking
<cehteh>seriously, i may look by myself into that, if i ever get used to this
<cehteh>i guess a lot people would like that
<davexunit>sounds like guix-hpc will address that
<cehteh>do you think so?
<efraim>shared profiles? makes reproducable science even eaiser
<cehteh>or the year of guix on the desktop
<lfam>I think the year of Guix on the desktop was last year ;)
<cehteh>guix substitute: error: download from '' failed: 410, "Gone"
<cehteh>... fun, building tex locally (download is stalled already)
<lfam>cehteh: That file is something we explicitly chose not to mirror, because it's huge and it's not something we can build more efficiently than on your machine. The fact that Guix tries to get a substitute for it is a bug
<cehteh>ah yes
<cehteh>but .. having some faster download mirrors for the upstream source would be nice
<cehteh>anyway .. i just --do-not-upgrade texlive to continue and now let it upgrade in anoher session where it can take all the time it need
<lfam>I actually keep a custom gcroot of that file, and I update it when we update texlive. Hacky workaround but it helps
<lfam>ls -s /var/guix/gcroots/texlive-20170524-texmf.tar.xz
<lfam>texlive-20170524-texmf.tar.xz -> /gnu/store/5rnvmy02yazy8iwaa91kijbbqp8qmflz-texlive-20170524-texmf.tar.xz
<efraim>it seems everyone can build llvm@3.9.1, and the source for mesa specifies exactly 3.9.0 or 3.9.1, I think we can use it for all architectures
<efraim>llvmpipe failed a test on aarch64
<divansantana>Would anyone have a snippet for configuring a serial tty console (for virsh console access). Bonus points if the snippet includes code for configuring it at grub level too.
<divansantana>eg with grub its =GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8"=, with systemd =systemctl start serial-getty@ttyS0.service=
<rekado>divansantana: see this:
<sneek>Welcome back rekado, you have 1 message.
<sneek>rekado, lfam says: Nice work with elogind. That was on my long list :)
<rekado>divansantana: especially “kernel-arguments” and “bootloader”.
<rekado>divansantana: and the agetty-service
<efraim>rekado: can you try this patch on seek? getengeopt FTBFS on aarch64 so I can't test it
<civodul>i have relatively bad throughput to tonight
<civodul>much worse than usual, weird
<efraim> I have a patch ready for file
<rekado>hmm, I also notice that guix weather is very slow for
<divansantana>rekado: thanks a ton rekado
<rekado>civodul: I’m also unhappy about the availability of i686 substitutes. The build farm does things, but I still can’t upgrade my i686 machines reliably.
<rekado>maybe I should reserve some machines for i686 work only.
<civodul>rekado: you can't upgrade because substitutes are missing?
<rekado>yes, because I can’t compile much on this i686 machine. Not enough memory.
<pmikkelsen>hello guix
<civodul>rekado: FWIW it has 63% of the packages of my profile, for i686
<civodul>and 95% for x86_64
<rekado>guix publish consumes a lot of CPU on berlin.
<rekado>I’m going to restart it.
***fr33domlover1 is now known as fr33domlover
<civodul>rekado: it's at 36M resident in top
<civodul>looks reasonable
<rekado>I just restarted it.
<civodul>the cuirass process eats a lot though
<civodul>i don't think we've had problems with the memory consumption of 'guix publish' before, we should keep an eye on it
<efraim>i'm testing building to hello on core-updates
<rekado>it was at 560% CPU
<rekado>is that normal when it’s busy?
<civodul>'guix publish'? yes
<rekado>we need monitoring to answer questions like this.
<civodul>we run it with --workers=6, which means it'll use up to 6 cores to compress nars
<civodul>so that's consistent
<civodul>efraim: thanks for the fix for 'file'!
<efraim>it went much faster after doing the one for glibc
<efraim>now i'm testing file-5.32 on core-updates