IRC channel logs

2014-09-19.log

back to list of logs

<mark_weaver>jgay: I have a correction for guile's page in the free software directory: the license is now LGPLv3-or-later.
<jgay>mark_weaver, ok, cool. http://directory.fsf.org/wiki?title=Guile&action=formedit :-)
<mark_weaver>hmm, yes, delegation is more scalable :)
<jgay>hopefully I got the URL right
<mark_weaver>what's the policy for who belongs in a contributor list? if we included everyone whose ever submitted anything non-trivial, it would be much larger. the current list on that page includes people who we haven't heard a peep from in many many years.
<mark_weaver>s/whose/who's/
<mark_weaver>(some of them haven't contributed anything in 15 years)
*tadni goes to see if guix still fails to build from git.
<jgay>mark_weaver, are you asking me?
<jgay>you don't need to add that to the directory entry
<jgay>it's not required
<jgay>anyhow, I gotta go make dinner. Tomorrow is the Friday Free Software Directory IRC Meeting. Feel free to stop by if you have questions :-)
*mark_weaver hopes he didn't scare jgay away with his difficult question :-/
<tadni>Yeah, guix fails to build from git now for me. Spits out -- "guix/ui.scm:202:11: source expression failed to match any pattern in form (report-error (_ "unknown unit: ~a~%") unit)"
<civodul>Hello Guix!
<Ulrar>ohai
<taylanub>nix/guix can in principle be installed non-root, right? but packages usually have hardcoded pathes to the /nix directory, meaning one couldn't use the substitutes?
<taylanub>(/gnu/store in our case, not /nix)
<civodul>taylanub: right, if you use a store prefix other than /gnu/store, you won't get anything from hydra.gnu.org
<wingo>civodul: http://wingolog.org/pub/guile-charting-0.2.0.tar.gz
<wingo>er, wrong channel :)
<nully>Hi all, @ around 1100 EDT I want to take down hydra to add more memory. Just a heads up.
<davexunit>civodul, mark_weaver: ^
<civodul>nully: yes, noted
<civodul>the guix-sysadmin guild is aware of it ;-)
<civodul>hydra.gnu.org is ready to be taken down
<nully>oh
<nully>well then
<nully>civodul: i'ma go ahead and take it down in a few mins then
<civodul>nully: ok!
<nully>probably at 1100 on the button
<civodul>ok, now is fine too if you want
<nully>still prep'ing on the backend :D
<civodul>np
<nully>civodul: so memory will be doubled then, to 4096M
<nully>does that sound right to you?
<nully>and down it goes :D
<davexunit>it will come back with even more heads than before
<civodul>nully: i think it was going to be 5G in total?
<civodul>and really 6G would be even better :-)
<nully>ya, i'm looking for another gig but i dont think we have it right now
<civodul>ok
<nully>give me a few mins
<nully>i wanna make sure
<civodul>if anyone has a bunch of gigs around, give 'em to nully :-)
<nully>civodul: btw, hydra is going though forced fscks right now
<civodul>oh, ok
<nully>oh right its like a 500gig volume
<nully>so this is going to be a hot second
<nully>i'll hang around, it'll probably be a few mins
<civodul>yes
<nully>heh, i havnt had my morning coffee yet
<RISCi_ATOM>nully: o/
<nully>RISCi_ATOM: :D
<civodul>davexunit: another idea that may be worth stealing: https://github.com/chrisfarms/nixos-shell
<civodul>(see on #nixos)
<mark_weaver>thank you for the memory, nully!
<civodul>yup, that's very cool
<nully>civodul: in the next few months there shoudl be some memory freeing up there. I'll ping this channel/project when that happens.
<davexunit>civodul: so maybe 'guix environment' can optionally create a VM to shell into?
<civodul>nully: excellent, thanks
<civodul>davexunit: could be, yes :-)
<davexunit>so far I've been able to create a new profile in your $PWD and augment the search paths to search that profile first. from there, you can tell 'guix environment' to --exec a command, spawn a new $SHELL with --shell, or print --search-paths
<civodul>sounds cool
<civodul>so you can do "guix environment guile guile-cairo", say?
<davexunit>civodul: can't now, but I will add that feature. right now it *must* read packages from a file.
<civodul>ah, ok
<civodul>well, that's convenient too
<_`_>that nixos-shell… does it use nixos-container (which seems to rely on systemd-nspawn)?
<civodul><chrisfarms> yeah it's using nixos-container for the "create" part ... but
<_`_>ohhh, was on the bottom
<_`_>my bad
<civodul>i confess i'm quite clueless about systemd-nspawn and friends
<_`_>I'm a bit familiar with it, to my own dismay.
<_`_>yeahh src/nixos-shell/main.go L249 tells me all
<civodul>heh
<civodul>oh this one is in Go?
<civodul>damn
<davexunit>civodul: I will add the ability to use packages in (gnu packages ...), but my primary use-case is to take a package definition living in the root of a project's source tree, and create a profile from the dependencies.
<civodul>davexunit: yes, i see
<civodul>like Vagrantfile, IIRC
<davexunit>yes, without the VM part, but maybe the VM part optionally now that you showed me nixos-shell
<davexunit>;)
<civodul>heh
<_`_>I'm guessing since dmd will be init(8) on GNU, looking into systemd-nspawn might be for naught. Perhaps if some container like mechanism is desired, looking into the linux container api itself (what powers LXC) might be preferable.
<davexunit>one thing I haven't settled on is if there should be a distinct option for building the profile, and the other options just check that it has been built before going forward.
<davexunit>right now, I always create the profile and then do the specified action.
<civodul>the store is really a cache, so the profile is created only if it's missing
<davexunit>which is simpler, because I don't have to infer package objects from derivations.
<davexunit>because i need to figure out search paths.
<civodul>yes
<davexunit>civodul: yeah, so creating the profile each time is okay, because if the profile hasn't changed, nothing will happen?
<civodul>yes
<civodul>if it's too slow, it means we should optimize things ;-)
<davexunit>okay :)
<davexunit>that makes my life easier.
<civodul>it's like "guix build emacs && guix build emacs"
<davexunit>yeah
<civodul>the second should be very fast
<civodul>*second one
<davexunit>I create the profile directory in the user's $PWD. is this okay or even necessary?
<civodul>it's necessary to register it as a root, which could mean creating a symlink in $PWD
<civodul>like "guix build -r the-root-symlink foo"
<davexunit>okay, so I'm doing the right thing.
<civodul>nully: i have to go until ~6PM now
<civodul>if needed, maybe mark_weaver can restart the services there
<civodul>otherwise i'll do it when i'm back
<davexunit>see ya, civodul.
<civodul>(6PM being in 35mn here)
<civodul>ttyl
<davexunit>hmm. nix shell creates a chroot in which you have only the build dependencies available. right now, guix environment augments your current environment with that of a new profile, so it isn't 'pure'. but does it really need to be? I want to have my usual software available to me + the dependencies for the software I'm working on.
<davexunit>I guess a --pure option would allow for both use-cases.
<nully>chug chug chug it goes
<RISCi_ATOM>nully: Drinking on the job ?
<davexunit>RISCi_ATOM: glug glug glug
<nully> coffie
<nully>i'm sad, i had to buy coffee today. I forgot to bring more soymilk, and the CVS across the street was out too
<nully>bleh
<nully>hydra still fsck'ing
<nully>this might be multiple hours, i've never done a large fsck on this set of spindles before.
<nully>So sorires, no ETA
<nully>mark_weaver: i'll ping you when its up though.
<RISCi_ATOM>nully: I would not hold my breath on time. I'm sure you'll be waiting quite a few hours.
<RISCi_ATOM>nully: What caused the disks to fsck ?
<mark_weaver>nully: soymilk? have you tried almond milk? I did, and never went back.
<mark_weaver>RISCi_ATOM: presumably it had been long enough since the last fsck that it triggered another.
*civodul is back, late
<civodul>nully: is the machine fscking?
<mark_weaver>the last update was that is still was fsck'ing, and that nully would ping me when it's back up.
<mark_weaver>and that it might be multiple hours
<civodul>ok
<nully>civodul: ya... if it doesnt come up in the next 40mins i'm going to reboot it again
<civodul>ok, we'll see
<nully>it appears to be fsck'ing, the disk pool has about the right IO/s to me really fsck'ing
<nully>i saw some ureadhead errors
<nully>but, those shouldnt stop a boot
<mark_weaver>nully: is there a progress bar on the fsck? I usually pass -C0 to fsck to get one.
<mark_weaver>(I thought that was the default on Debian-derived systems)
<nully>mark_weaver: no, it decided to be quite
<mark_weaver>oh well
<nully>i thought it was hung but it finshed the first volume a while ago
<mark_weaver>hmm, there's only one volume of non-trivial size on hydra, iirc.
<nully>i just fsck'd it recently too
<nully>you have to when you grow/shrink a volume
<mark_weaver>ah yes, so I wonder why it's doing it again so soon.
<mark_weaver>maybe the shutdown wasn't entirely clean.
<nully>i simply issued a poweroff via ssh
<nully>so you'd think it would be clean
<nully>didnt see it hang on the console
<nully>we can always skip fsck to get it up and then do them post boot
<mark_weaver>I usually do "shutdown -h now". I'm not sure if they're equivalent.
<nully>they are
<mark_weaver>okay
<nully>poweroff is just a wrapper
<nully>to be `os sepcific' whatever that means
<mark_weaver>well, thanks for working on it. the extra memory should help us a lot.
<nully>mark_weaver: if its okay with you i'd like to bounce it and boot w/o the fscks
<nully>i think its hung
<civodul>isn't it just taking a lot of time?
<mark_weaver>nully: maybe boot it in single user mode and run the fsck manually with -C0?
<mark_weaver>I'm a bit nervous about skipping the fsck when I don't know if the volume is dirty.
<nully>well
<civodul>yes
<nully>i was going to do them when i got it booted
<civodul>or we could wait whatever it takes
<nully>iotop says the volume is idle
<mark_weaver>and guix probably wouldn't cope well with filesystem damage.
<nully>as of the last 10mins
<nully>and its just sitting there doing nothing
<civodul>nully: we wouldn't be able to fsck the root fs once booted, would we?
<nully>i'll give it another 15 maybe
<nully>ya
<nully>you can mount / as readonly
<nully>i can also fsck both volumes from the dom0
<civodul>ok
<nully>accually lets just do that
<mark_weaver>sounds good to me
<civodul>nully: yes, whatever you think is appropriate
<nully>sorry about the delay
<mark_weaver>no worries
<nully>i really wanted this to be 10mins or so of downtime for you guise
<civodul>np, it's really worth it ;-)
<civodul>mark_weaver: BTW, we should probably use -C0 as well in linux-boot.scm, no?
<nully>fsck'ing
<nully>with stuats this time ffs :D
<nully>cool i'll ping y'all when this finisheds
<mark_weaver>civodul: yes, I think so
<nully>cool, so far so good, probalby another 20mins of fsck left
<mark_weaver>\\o/
<nully>ya i think it was hung
<nully>its going much faster
<nully>and the diskio looks a bit more of what i'd have expecteed
<nully>*sigh* i *love* taking down hosts that havn't been rebooted in a while
<nully>always fun
<civodul>heheh :-)
<nully>and we're back
*mark_weaver tries to get everything started back up on hydra, in civodul's absence.
<mark_weaver>hmm, I'm not sure how to get the web interface back up...
<mark_weaver>civodul: we need you! :)
<davexunit>sudo hydra --do-the-stuff
<mark_weaver>well, it seems to be building stuff again anyway. not sure what's missing from the web interface.
<mark_weaver>well, the web interface is already up on port 3000. not sure what was previously done to listen on port 80.
<davexunit>is there any apache/nginx config to reverse proxy it?
<mark_weaver>I don't think we had that in place yet.
<mark_weaver>but that's certainly an option.
<mark_weaver>well, maybe I did, dunno.
<mark_weaver>*we did
<mark_weaver>nully: btw, we seem to not have as much disk space as we were expecting. we had 400G, and you said we were getting another ~250G, but it seems we have only 482G.
<mark_weaver>(that 482G value has remained constant over the last several days at least)
<davexunit>web interface is up :)
<mark_weaver>civodul to the rescue!
<tadni`>Just bought a domain, going to get hosting on it next week and an updatedish guix vm.
<mark_weaver>we'll have to work on increasing our bus factor :)
<davexunit>I want to know how I can get linode or some other VPS host to use a Guix VM
<tadni`>davexunit: It'll have to have enough users, to validate providing support for it.
<tadni`>Which it probably won't have for some time.
*tadni` is setting up linode probably next week with this domain and might see if he can compile guix on it.
<davexunit>tadni`: cannot I not just say "here's an ISO, use it" ?
<tadni`>davexunit: With Linode? They have custom profiles, I don't think it's that easy.
<tadni`>Also Guix doesn't have an iso yet. :^P
<_`_>They have a rescue mode don't they?
<_`_> https://nixos.org/wiki/Install_NixOS_on_Linode cues from there should get one moving.
<davexunit>_`_: thanks!
<_`_>davexunit: https://www.linode.com/docs/tools-reference/custom-kernels-distros/run-a-custom-compiled-kernel-with-pvgrub you might also want to read that
<_`_>since you'll need a kernel with xenpv support
<davexunit>ohhhh yeah they use xen
<_`_>yeah
<davexunit>should be a simple matter of customizing the linux-libre package I hope
<_`_>you could use their kernel configuration oldconfig'd with linux-libre sources as a base then include that new configuration in the package, or at least the difference.
<RISCi_ATOM>Why would anyone need an iso image? those are so last decade.
<davexunit>okay, iso was a bad example.
<davexunit>s/iso/disk image/
<RISCi_ATOM>No, I am quite serious.
<RISCi_ATOM>Why can't people just use regular disk images ?
<davexunit>I dunno. until using guix, I've always seen iso images.
<RISCi_ATOM>davexunit: I liked the way that guix did things.
<RISCi_ATOM>Sadly, I have not had more time to play with it.
<RISCi_ATOM>I was wanting to bootstrap it into a special version of libreCMC.
<RISCi_ATOM>For ARM / x86
<davexunit>librecmc guix edition
<davexunit>we are still in need of an ARM port.
<mark_weaver>if no one beats me to it, I plan to start on that as soon as my Novena board arrives.
<civodul>that would be neat
<davexunit>civodul: I perused the source of nixos-shell a bit. I know I'm biased, but programming for guix looks so much nicer. Nix is its own language, nixos-shell is written in Go, Nix ships a bunch of scripts written in Perl. The nix expressions within the go source are simply quoted strings. bleh.
<davexunit>mark_weaver: you and I have similar plans.
<mark_weaver>we'll have to decide what subset of ARM processors to support.
<mark_weaver>davexunit: I got only the bare board, so I guess I'll get mine sooner :)
<davexunit>I know nothing about porting though so you'll be infinitely more useful.
<davexunit>I could try to make do with a raspberry pi right now...
<mark_weaver>but it will be great to have more help when yours arrives :)
<mark_weaver>well, there are two problems with using the RPi:
<davexunit>I knew you'd mention problems. :)
<mark_weaver>for one thing, it's *way* too slow and limited to build guix in any reasonable amount of time, if ever.
<civodul>davexunit: there's also bash (notably inlined), and a few other things: https://www.openhub.net/p/nixpkgs/analyses/latest/languages_summary :-)
<mark_weaver>and also, we have to decide which level of ARM architecture to support, and I was thinking of targetting the same as the Debian armhf port
<mark_weaver>but the RPi is actually a bit too old for that one.
<davexunit>ah, I see. I knew about the slowness but not the debian armhf and ARM architecture levels.
<mark_weaver>and given the serious problems with the RPi needing a massive blob to even boot, I'm not inclined to go out of my way to support it.
<mark_weaver>but of course it's something we could discuss, if people disagree.
<civodul>the code could be organized to make it easy to switch from one variant to the other
<civodul>for instance between "hf" and soft float
<davexunit>I was only going to use because I already have it.
<davexunit>I have raspberry piers remorse. :(
<mark_weaver>civodul: hmm, I'm not sure what you mean.
<mark_weaver>it's just a question of which compiler flags we use to build everything.
<civodul>yes, and also things like the libc configure flags
<civodul>oh but i was thinking about cross-compilation mostly
<mark_weaver>sorry, lost my net for a bit.
<mark_weaver>civodul: it would be great if we had a way to support multiple variants of each platform.
*civodul oops
<civodul>mark_weaver: yes
<mark_weaver>but that can wait a bit, I think.
<civodul>sure :-)
<mark_weaver>davexunit: hahah, I have "raspberry piers remorse" too :-/
<mark_weaver>actually, I recieved mine as a gift, but still.
<davexunit>I was under the impression that most of the blobs have been freed at this point, though.
<mark_weaver>davexunit: it's possible that my information is stale, but I'd want confirmation.
<mark_weaver>anyway, it's still too underpowered to build guix.
<davexunit>yes.
<mark_weaver>it makes my YeeLoong seem like a supercomputer.
<davexunit>I'd need a machine that could cross-build for me.
<civodul>i've used Nix on a GuruPlug, which is around as powerful as a RPi, i think
<civodul>may be slightly older, actually
<mark_weaver>I might actually try cross-compiling the bootstrap tarballs from my YeeLoong, since I trust the security of this YeeLoong more than other machines, for various reasons.
<civodul>i suspect toolchain developers don't really test mips -> arm cross-compilation :-)
<jxself>davexunit: Nah, not freed. :(
<mark_weaver>hehe, probably not.
<davexunit>jxself: what was it that I saw awhile ago then? something about the rpi that was nonfree was freed. I just can't remember.
<jxself> http://en.wikipedia.org/wiki/Raspberry_Pi
<jxself>See the Driver APIs section.
<jxself>Some work's been done, yeah, but the blob is still needed.
<davexunit>okay, I knew there was still a blob of some sort.
<jxself>It needs it to even boot still. :(
<davexunit>:(
***ZenWalke1 is now known as ZenWalker
*nully spins
<jxself>Like those HDDs you worked on earlier?
<nully>Ya, sadly those were spinning disks.
*davexunit wonders if creating profiles for 'guix environment' is better than creating chroots (I think) like 'nix shell' does
<davexunit>I just implemented a --pure flag that overwrites relevant environment variables to only contain paths to the environment profile.