IRC channel logs

2017-07-21.log

back to list of logs

***dshin_ is now known as dshin
<wigust>Hello Guix
<catonano>wigust: hello
<civodul>Hello Guix!
<efraim>civodul: http://odroid.com/dokuwiki/doku.php?id=en:c2_building_u-boot first yellow box, looks like we have to rule out the odroid-c2 as a potential libre build slave
<civodul>efraim: uh, ok
<buenouanq>What about EOMA68 support?
<buenouanq>it's an Allwinner A20
<buenouanq>when they finally ship, my top priority will be installing GuixSD
<buenouanq>hope others with more knowledge of uboot than I [none] is already looking in to this
<civodul>ACTION attempts to write a "weather service" for substitutes
<catonano>I wonder if this can be of interest for guix https://arxiv.org/abs/1707.06552
<civodul>catonano: definitely interesting, i'm adding it to my reading list
<catonano>civodul: ah, glad you liked it. I gotta go again, now. Hear you soon !
<rain1>hi
<civodul>hi rain1!
<efraim>i noticed our make-u-boot-package in bootloaders.scm assumes cross-compiling
<civodul>efraim: does it?
<civodul>might be worth discussing with Danny
<civodul>BTW we can almost cross-compile GuixSD, which is pretty cool
<efraim>I bet I could cross-compile to myself, but its not really the point
<civodul>heh
<civodul>i'd like to be able to have a cross-compiled GuixSD running in QEMU on my machine
<civodul>that i could use as a build machine
<efraim>i added xf86-video-freedreno locally, now i'm trying to make -intel and -freedreno conditional
<efraim>i also built u-boot for the odroid-c2, working on an OS declaration now and i'm going to see what we have for u-boot as a bootloader
<civodul>woow, sounds exciting!
<civodul>how's that blog post going BTW? :-)
<civodul>it could help us recruit new ARM tinkerers
<efraim>that and an actual aarch64 install binary :)
<civodul>yup!
<efraim>oops, messed up my kernel config, this one is missing hid-generic.ko
<efraim>uhh, CONFIG_HID_GENERIC=y
<rekado>davexunit: since your domain cert has expired software from your domain (such as shroud) can no longer be downloaded and built.
<rekado>davexunit: I have had good experiences with the Let’s Encryt certbot
<davexunit>rekado: yeah I know it's expired but let's encrypt fails to renew every time I try so I don't know what to do
<davexunit>I might try to buy a cert from somewhere else if I can't get it to work soon
<civodul>the slowness of hydra.gnu.org is unbelievable
<civodul>31 seconds for a 'rename' call!
<jonsger>civodul: on which hardware does it run?
<civodul>jonsger: it's a Xen thing, so most likely the actual hardware is busy with additional things that we don't control
<ng0>rekado: do you remember if there was a problem or something special needed to get Clojure running properly on Guix? I've thought about our short chat in december about music, and I came to the conclusion that I want to learn more about Clojure, Overtone, and friends.
<ng0>(why dwell into the limitations of Milkytracker when you can take the whole thing to another level)
<rekado>ng0: do you have any problem in particular with Clojure? I haven’t tried it.
<rekado>ACTION takes the train to Prague soon
<rekado>corrupt substitute for phwrd9byxz0i…-linux-libre-4.9.38 (“unexpected end of file”)
<rekado>that’s the kernel for i686
<ng0>I have just read some threads on the mailinglist about it. I thought there was something which needs to be taken care of before it works. I'll just try :) Maybe I never finished the other music program I was working on, so that gets done aswell if it didn#t land in master already
<civodul>hydra.gnu.org has 76.0% of the x86_64 substitutes
<civodul>it can serve 5 narinfo requests per second (not a lot...)
<rekado>ACTION switches to blue for this slide set. Poster is still pink, though.
<civodul>blue? were you pressured? ;-)
<rekado>heh
<civodul>current x86_64 packages represents 43G in store
<ng0>while we're at sizes.. is this how much one would expect for a mirror to keep around, less than 100G? My mirror (cache) experiment is a bit slow because communication with the hoster lags atm
<rekado>the shared store at the MDC is at about 300GB
<jonsger>armhf was the fastest build (for 0xffff) ^^ never tried to build it for armhf...
<efraim>I have 94G on my aarch64 store
<efraim>dealii builds single-threaded
<ng0>efraim: I read something earlier about the odroid.. aren't they in general not very friendly towards free software?
<ng0>I was told so
<efraim>they're not great but they've been getting better I think
<ng0>'cause I considered an odroid a testing target once, and it would've been bad promo
<ng0>ah
<efraim>from their official wiki it needs a blob to boot u-boot to linux, but u-boot upstream supports the odroid-c2 so I'm going to try getting it to run all libre
<efraim>i'm really disapointed by my hikey and pine64, couldn't get either board to even boot up
<efraim>with the odroid actually booting I didn't want to spend too much time working on those
<ng0>oh
<efraim>although the pine64 is an interesting target with their new pinebook
<ng0>I'd be interested if Rutkowska's view on arm changed since the 2015 paper 'state considered harmful'
<efraim> https://linux-sunxi.org/Linux_mainlining_effort pine64 is basically A64, odroid-c2 is basically H5, exciting time
<efraim>s/time/times
<jsierles>is there a userland nfs server packaged anywhere in guix?
<ng0>h5?
<ng0>archh5 or what does that mean?
<efraim>its their code for 4xA53 and mali 450
<efraim>I don't think we currently have a way to set u-boot as bootloader, if I'm understanding gnu/bootloaders and doc/guix.texi correctly
<civodul>ng0: what's the URL of your cache again? i can give you its stats :-)
<ng0>I knew it ran out out space so I had to stop filling it (I started building the whole master locally)
<ng0>25GB, waiting for 50GB or more increase from the hoster
<ng0>oh
<ng0> https://guixmirror.infotropique.org
<ng0>iirc
<ng0>-> https://guix-mirror.infotropique.org
<civodul>ok
<civodul>rekado: berlin.guixsd.org has 6.6% of the x86_64 substitutes (770 MiB in /var/cache/guix/publish)
<civodul>ACTION does statistics today :-)
<jsierles>civodul can you look at https://guix-staging.nextjournal.com? maybe during your investigation something would come to light
<civodul>sure!
<civodul>you'll see an HTTP request storm in a few seconds :-)
<civodul>jsierles: 360 req/sec, but 0.0% of the current x86_64 substitutes, which is weird
<civodul>exactly 0 substitutes, i wonder how that can even be the case
<jsierles>one sec
<jsierles>yup. i dont know. i see the requests coming in
<jsierles>no errors from the daemon
<civodul>are you using a store name other than "/gnu/store"?
<jsierles>civodul nope
<civodul>jsierles: could you explicitly build a bunch of packages?
<jsierles>civodul there's 90GB of stuff in there. you mean something not already built?
<civodul>hmm
<civodul>jsierles: do you have /gnu/store/1lvqx35rm9yqgcjjpy1nr337y9j5582g-coreutils-8.27 ?
<jsierles>yup
<civodul>apparently yes
<civodul>ok
<civodul>indeed i do find substitutes when running things by hand
<jsierles>do you need my signing key?
<civodul>no, not for this
<civodul>do you have nginx in front of it?
<jsierles>nope, just straight up guix publish
<civodul>how do you do https then?
<efraim>do my stats! git.flashner.co.il:8181
<jsierles>civodul oh sorry. it's running through a proxy, i just mean that proxy does no caching
<jsierles>i can try some commands internally to see if i get different results
<civodul>jsierles: i have to go, but i just sent the "weather" program that i used
<civodul>ttyl!
<jsierles>send where?
<jsierles>mystery
<efraim>probably guix-devel
<ng0>yes
<jsierles>the load balancer doesn't support streaming responses by default
<jsierles>also see a crazy number of established connections from the load balancer.
<jsierles>like 5000 connections.
<efraim>Debian is starting their Perl 5.26 transition
<roelj>Does anyone else have any trouble with ssh-agent or SFTP connections in nautilus on GuixSD?
<roelj>Mine doesn't seem to use ~/.ssh/config, and neither uses any of my keys in ~/.ssh
<ng0>ACTION has finished building supercollider \\o/ now I need to test this tomorrow and then unbundle everything
<buenouanq>oh, awesome
<buenouanq>does guix have pd yet?
<ng0>a what?
<buenouanq>puredata
<buenouanq>looks like yes
<ng0>I think I don't need SC to get started with Overtone, but I had this package collecting digital dust :)
<srbaker>Heya folks. I'm having some trouble with networking on guixsd in a VM
<srbaker>It doesn't work, I booted the VM with the qemu command from the docs.
<srbaker>`qemu-system-x86_64 -m 4096 -smp 1 -net user -net nic,model=virtio -boot menu=on -drive file=guixsd-usb-install-0.13.0.x86_64-linux -drive file=guixsd.img`
<lfam>srbaker: In what way does it not work? What did you try?
<srbaker>it gets an IP
<srbaker>oh, hang on. i may have rebooted.
<lfam>FYI, that method of QEMU networking doesn't support ICMP (ping) or inbound connections.
<srbaker>Aha, okay.
<lfam>This is mentioned in the linked manual section 'Running GuixSD in a VM'
<srbaker>Ah, I hadn't got to that part because I'm only on the installation instructions page. :)
<srbaker>Thanks. :)
<lfam>I know the way this information is organized in our manual is a little confusing. I intend to reorganize it soon
<sneek>I'll keep that in mind.
<lfam>sneek: forget it
<sneek>Okay.
<lfam>sneek: forget it
<sneek>Okay.
<lfam>sneek: forget it
<sneek>Okay.
<lfam>Hm...
<srbaker>Okay, next question: what's the config for rmapping capslock to ctrl?
<lfam>That I don't know :)
<srbaker>The intention here is to build a GNUstep based desktop using GuixSD as the base system.
<lfam>My reorganization idea is to consolidate all instructions about GuixSD in QEMU into one section. Then, installation in QEMU will be another section that largely refers to the 'Running' section.
<srbaker>I'm currently writing a GNUstep frontend to parted, so I can build a gui install tool.
<srbaker>lfam, that will be better, I think.
<lfam>Right now, the info about GuixSD in QEMU is split up into multiple sections in a way that's confusing for new users
<srbaker>Yep
<lfam>I hope somebody else can advise you about remapping keys
<lfam>If not, you could also send your questions to <help-guix@gnu.org>
<buenouanq>I can maybe help with that, hold on.
<buenouanq>srbaker: https://rectilinear.xyz/p/efee7a204d
<buenouanq>untested, but you can prolly do something like that
<srbaker>aha, I see how that works. I'll try it.
<srbaker>Thanks
<srbaker>I had a timeout while doing duix system init. I'm *hoping* that I can just re-run guix system init without hurting anything.
<srbaker>It 404'd on make 4.2.1. So I'm running with --fallback, as suggested.
<srbaker>I can't wait to get back from vacation and get this installed on real hardware.
<buenouanq> https://rectilinear.xyz/p/963fa147c1 file might have to be like this actually
<srbaker>Ah. I'll take a look when it boots. Thanks. :)
<buenouanq>so uhh, I just wanted to quickly change my file-systems clause, and now it looks to be rebuilding everything...
<lfam>buenouanq: What kind of change?
<lfam>And, you can use --dry-run to see if it's actually rebuilding everything
<buenouanq>just commenting one of my harddrives out
<lfam>That shouldn't require packages to be rebuilt. Are you sure you haven't run `guix pull` since the last reconfigure?
<buenouanq>I pray this won't happen again when I uncomment it again here in a few minutes(;-___-)
<buenouanq>oh no, I run guix pull out of habit before most anything
<buenouanq>so explain that to me then
<lfam>I assume that since you last ran `guix pull`, some package definitions have changed, requiring new things to be built or downloaded.
<lfam>If the changes are the addition of new grafts, then it may look like you need to build many packages, but really you only need to graft existing packages, which is pretty cheap.
<buenouanq>so, once it does this, it shouldn't happen again?
<buenouanq>yeah, just finished
<buenouanq>brb
<srbaker>so my VM is currently building make-4.2.1. Why isn't there a pre-built one?
<srbaker>Curious, not complaining.
<srbaker>:D
<buenouanq>oh dear, something has gone terribly wrong
<buenouanq>;;; ERROR: In procedure load-thunk-from-memory: not an ELF file
<buenouanq>any guix command now spits out a million of those
<buenouanq>guix pull: error: pcre-CVE-2017-7186.patch: patch not found
<adfeno>?
<lfam>buenouanq: Are you building from a Git checkout?
<buenouanq>I don't know - I've done nothing fancy, just a normal install.
<buenouanq>of guixsd
<lfam>The first message, "... not an ELF file" indicates that part of your system is relatively up to date (using Guile 2.2) and part of it is not (using Guile 2.0). Those messages come from Guile 2.2 when it finds compiled Guile 2.0 objects.
<buenouanq>how do I get it all up to date then?
<buenouanq>I've run guix package -u already I thought.
<lfam>It says ERROR but in practice it's just a warning. Guile will recompile. But, it means that some Guix installation on the system is quite old and contains many vulnerable packages.
<lfam>Remember that Guix is per-user, plus the system-wide Guix on GuixSD.
<lfam>So, per-user: `guix pull && guix package -u`. Also, root must run `guix system reconfigure` after pulling in order to keep the system Guix up to date
<buenouanq>ok, so this will go away if I gpu each user then?
<buenouanq>guix pull is the thing yelling at me though
<lfam>As for the pcre patch, that's confusing to me. I can't find the string 'pcre-CVE-2017-7186.patch' in the current Guix source code.
<buenouanq>it is doing things though
<lfam>It should be totally removed.
<buenouanq>I haven't updated in a while.
<buenouanq>Let me run through all the users and I'll let you know.
<buenouanq>Will this update to GuixSD 0.13 or do I need to do a full reinstall?
<lfam>You only need to do root and the user from which you saw those messages. If there are other users on the system, they aren't interacting in a way that would show those messages.
<buenouanq>root was the one seeing that message
<lfam>If you haven't updated to 0.13.0 yet, `guix pull && guix system reconfigure ...` will update to 0.13.0 and beyond
<lfam>Okay, then you should at least update root's packages *and* the system. That means root should do `guix pull` as well as `guix package -u` and `guix system reconfigure`
<lfam>Remember that root's packages are totally different from the system.
<buenouanq>guix pull fail on root with that pcre thing
<lfam>Hm... what does `guix --version` say?
<buenouanq>;;; ERROR: In procedure load-thunk-from-memory: No such file or directory
<buenouanq>lol
<buenouanq>;;; WARNING: loading compiled file /root/.config/guix/latest/guix/ui.go failed:
<buenouanq>;;; ERROR: In procedure load-thunk-from-memory: not an ELF file
<buenouanq>bunch of things like that again
<lfam>Do you remember how long it has been since you 0) ran `guix pull` as root 1) Updated root's packages 2) reconfigured the system?
<lfam>Roughly...
<buenouanq>few weeks, maybe a couple months
<lfam>For 0, 1, and 2?
<buenouanq>reconfigure for sure it's been quite a while
<buenouanq>the other two maybe like, 5 or 6 weeks
<buenouanq>If a fresh install is going to be the easiest fix of this for me, I might just do it.
<buenouanq>Not like Debian where it takes all day and might not work.
<buenouanq>so when you say update `the system (as opposed to root)', this just means $ guix system reconfigure
<buenouanq>or is there some other user I've never heard of I'm supposed to be updating?
<lfam>The former. However, in order to update along with reconfiguring, root will need to have run `guix pull`
<adfeno>buenouanq: It means: `guix pull && guix system reconfigure` :)
<buenouanq>as root
<lfam>Otherwise, reconfigure will *just* reconfigure things, but you won't get new packages or services
<buenouanq>this is sort of silly though,
<buenouanq>I \\it{should} be able to update everything normally.
<lfam>Yes, although the migration from Guile 2.0 to Guile 2.2 was a little tricky and sort of a special case.
<buenouanq>to just give up and start fresh seems like admitting some kind of defeat
<lfam>I'm not sure what is going wrong for you now :( Maybe somebody else has some ideas for debugging
<buenouanq>ok, I'll have to roll back so I can quickly make a backup
<buenouanq>then I'll reinstall
<buenouanq>wish me luck o/
<buenouanq>\\quit
<buenouanq>(;-___-)
<rekado>sneek: what is I know the way this information
<sneek>I know the way this information is organized in our manual is a little confusing. I intend to reorganize it soon
<rekado>sneek: forget I know the way this information
<sneek>Okay.
<rekado>sneek: what is I know the way this information
<rekado>sneek: silly bot
<oriansj>sneek: later tell sneek that sneek is so sneek
<sneek>You just did.
<rekado>srbaker: oh, GNUstep?
<rekado>Hello from Prague, by the way!
<lfam>rekado: Do you know why sn**k remembered that phrase?
<rekado>“is”
<rekado>something “is” something else
<rekado>Tomorrow I’ll be giving a talk about Guix together with Pjotr.
<adfeno>rekado: Awesome :)
<rekado>would somebody like to critique my slides?
<lfam>rekado: Sure, can you send them to me or share a link?
<rekado> https://elephly.net/downies/bosc-2017-slides.pdf
<rekado>I only have … 10 mins. The talks are scheduled really tightly, which means it’s probably going to be less than 10 mins.
<rekado>No time for questions either.
<rekado>but at least I’ll be presenting a poster on Sunday where I could show the bonus slides and give demos.
<lfam>rekado: For some reason, the slides render as blue for me. Perhaps the pink pixels on my monitor have malfunctioned
<rekado>:D
<rekado>I should make the choice of colour a make flag.
<rekado>blue works better with the recurring whale character.
<lfam>I like the yin and yang design
<lfam>Perhaps it's just the PDF renderer I'm using (whatever comes in Firefox), but slide 15 is huge compared to the others
<rekado>oh, that’s possible
<adfeno>I see it in blue here too...
<rekado>I’m using the PDF reader in Emacs and it scales the slide down.
<adfeno>GNOME Evince.
<rekado>oddly, it’s also blue on my screen.
<lfam>adfeno: It was a joke :) rekado's presentations have previously always been pink
<adfeno>Oh... :)
<lfam>I assume the slides > 23 are intended to be used if anyone sticks around after?
<rekado>yes, they are bonus slides.
<lfam>I think the slideshow is excellent. It may be too long for a <10 minute talk, but that's up to you, really
<rekado>I think they make this whole append-only idea clearer than actual demonstrations
<rekado>thank you!
<rekado>I may have to promote more slides to the bonus section :-/
<lfam>I really like the presentation style and text. The comparison method is great. "100% reproducible
<lfam>We have all the bits!
<lfam>100% stateful
<lfam>We only have the bits!"
<rekado>I really don’t like to spend time talking about Conda, EasyBuild, Spack much, but that was specifically requested by the reviewers.
<rekado>I do like to talk about Docker, though.
<rekado>and I really like their logo. So Q!
<lfam>"All you need is: Guix version + package manifest" Plus, all the source code, which can be a problem. But no need to get bogged down in the details ;)
<rekado>’zactly :)
<lfam>The horned whale is great
<adfeno>Geess... PDFs with bigger pages always make my X server freeze....
<rekado>I’ll try to resize that slide.
<adfeno>Actually... Anything absurdedly bigger than my screen makes my X freeze.
<rekado>It’s the only slide that was not edited in Inkscape. It’s straight from “guix graph”
<lfam>Yes, I recognized that huge format ;)
<adfeno>I have tested once with opening some thing from Guix graph.... with my image viewer (GNOME gthumb), and I got in big trouble (was making an important work).
<adfeno>Of course, I converted the output of guix graph with Graphviz to a png image, but even so I got stuck.
<lfam>I always use SVG, because I also had trouble with the PNG output of Graphviz
<adfeno>Nowadays I tend to use a mix of `guix size` + GNU awk + GNU uniq, to do something similar to `guix graph`, but without the graph. :)
<rekado>I think we should add an interactive d3js graph application.
<rekado>One that allows us to interactively explore the graph without having to generate it all at once.
<adfeno>I wonder what really makes my X.org freeze...
<adfeno>Is it because the png of Graphviz is too big to fit in RAM?
<adfeno>Or something like that....
<rekado>how big is it?
<adfeno>In terms of bytes I don't know,
<adfeno>I would have to ask you :)
<adfeno>(I assume that you generated the Graphviz file)
<rekado>the pdf is just couple of bytes
<rekado>but that doesn’t tell you how hard it will be to render it\\
<rekado>(it’s a PDF, not a raster image)
<adfeno>Don't worry about my X.org freezing though. As far as I know, I'm the only one having this issue with graphviz's output files.
<adfeno>And I'm not using GuixSD, but GNU Guix on top of Trisquel 7, and in an old notebook. So there might be something interfering.
<srbaker>rekado, yes, my intention is to make a usable desktop with GNUstep. Aiming to port some Mac programs over, Adium and Colloquy are the first big ones I'm hoping to do.
<srbaker>And I want to use Guix as the base for various reasons.
<srbaker>I'm in an ocean-boiling mood.
<adfeno>Adium = Pidgin?
<srbaker>More or less, yes. They're both based on libpurple.
<bavier`>rekado: I love the slides