<Apteryx>Is there a way to simulate booting from raid when using 'guix system vm'? <reepca>Hm, trying to run squeak.sh 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 squeak.sh 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 <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>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 <civodul>i've never used Spotify, but i doubt it requires Flash <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 <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 | https://gnu.org/s/guix/ | videos: https://gnu.org/s/guix/help/#talks | bugs: https://bugs.gnu.org/guix | patches: https://bugs.gnu.org/guix-patches | paste: http://paste.lisp.org | log: https://gnunet.org/bot/log/guix | Guix-HPC announced: https://gnu.org/s/guix/news/announcing-guix-hpc.html'
<efraim>109773, with all the changes to when the autoconf phase runs ***Piece_Maker is now known as Acou_Bass
<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 <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 ;) <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 to you and those who will work on Guix-HPC! <civodul>Apteryx: thanks Apteryx! that's pretty nice, indeed <efraim>wow, nvm, opengl is enabled by default, opencl is disabled by default <cehteh>can package be tagged to be distributed source only? aka that would be a good choice to include zfs <cehteh>guix pull: error: Git error: the SSL certificate is invalid <Apteryx>Where can I find the public key for the berlin.guixsd.org server? <civodul>Apteryx: it's the file called 'bayfront.guixsd.org' 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! <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 <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 bug-guix@gnu.org, with the full output of "guix --version" and "guix pull"? <cehteh>there isnt much .. just the lines i've shown <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>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 <cehteh>the haskell boostrapping issues havent resoved meanwhile? ... <cehteh>i need git-annex and havent found it <bavier>and quite a few haskell libraries <bavier>cehteh: git-annex is still underway <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 <civodul>isn't git-annex superseded by git-lfs? <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 <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 <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>or i am dumb .. did a pull but as other user :) <lfam>cehteh: Yes, `guix pull` is per-user <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 <efraim>mesa-17.2 has asm support for aarch64 and arm <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 <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>... 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>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= <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 <civodul>i have relatively bad throughput to berlin.guixsd.org tonight <rekado>hmm, I also notice that guix weather is very slow for berlin.guixsd.org. <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. <civodul>rekado: FWIW it has 63% of the packages of my profile, for i686 <rekado>guix publish consumes a lot of CPU on berlin. ***fr33domlover1 is now known as fr33domlover
<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>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>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