<mark_weaver>jgay: I have a correction for guile's page in the free software directory: the license is now LGPLv3-or-later. <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>(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>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)" <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? <civodul>taylanub: right, if you use a store prefix other than /gnu/store, you won't get anything from hydra.gnu.org <nully>Hi all, @ around 1100 EDT I want to take down hydra to add more memory. Just a heads up. <civodul>the guix-sysadmin guild is aware of it ;-) <civodul>hydra.gnu.org is ready to be taken down <nully>civodul: i'ma go ahead and take it down in a few mins then <nully>probably at 1100 on the button <nully>still prep'ing on the backend :D <nully>civodul: so memory will be doubled then, to 4096M <nully>does that sound right to you? <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>if anyone has a bunch of gigs around, give 'em to nully :-) <nully>civodul: btw, hydra is going though forced fscks right now <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 <nully>heh, i havnt had my morning coffee yet <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? <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>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. <_`_>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 <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 <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. <davexunit>yes, without the VM part, but maybe the VM part optionally now that you showed me nixos-shell <_`_>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>civodul: yeah, so creating the profile each time is okay, because if the profile hasn't changed, nothing will happen? <civodul>if it's too slow, it means we should optimize things ;-) <civodul>it's like "guix build emacs && guix build emacs" <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" <civodul>if needed, maybe mark_weaver can restart the services there <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>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>this might be multiple hours, i've never done a large fsck on this set of spindles before. <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. <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. <mark_weaver>the last update was that is still was fsck'ing, and that nully would ping me when it's back up. <nully>civodul: ya... if it doesnt come up in the next 40mins i'm going to reboot it again <nully>it appears to be fsck'ing, the disk pool has about the right IO/s to me really fsck'ing <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 <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. <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>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 <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>i was going to do them when i got it booted <nully>iotop says the volume is idle <mark_weaver>and guix probably wouldn't cope well with filesystem damage. <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>i can also fsck both volumes from the dom0 <civodul>nully: yes, whatever you think is appropriate <nully>i really wanted this to be 10mins or so of downtime for you guise <civodul>mark_weaver: BTW, we should probably use -C0 as well in linux-boot.scm, no? <nully>with stuats this time ffs :D <nully>cool i'll ping y'all when this finisheds <nully>cool, so far so good, probalby another 20mins of fsck left <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 *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>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>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) <tadni`>Just bought a domain, going to get hosting on it next week and an updatedish guix vm. <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? <_`_>since you'll need a kernel with xenpv support <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>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. <mark_weaver>if no one beats me to it, I plan to start on that as soon as my Novena board arrives. <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. <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>for one thing, it's *way* too slow and limited to build guix in any reasonable amount of time, if ever. <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 <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. <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>civodul: it would be great if we had a way to support multiple variants of each platform. <mark_weaver>davexunit: hahah, I have "raspberry piers remorse" too :-/ <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. <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 <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 :-) <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>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. :( ***ZenWalke1 is now known as ZenWalker
<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.