***grant__ is now known as {0}grant
<{0}grant>I'm trying to "guix system init" that on my laptop, and it's pooping out a complaint about using the wrong type of argument, when exepecting a struct. <mark_weaver>you need to use 'cons*' instead of 'cons', and cons two (file-system ...) forms onto %base-file-systems <mark_weaver>what you've got there is one file-system with duplicate fields. <{0}grant>mark_weaver: Ah, well I had the latter at first. <{0}grant>Then assumed I was tiredly doing something foolish, then said correction looked /way/ off and is/was. <mark_weaver>also, since you are providing devices instead of labels, they should contain (title 'device) instead of (title 'label) <mark_weaver>if you want to use wicd, then you should remove (dhcp-client-service ...) and add (wicd-service) <mark_weaver>and you'll need 'wicd' in the list passed to 'dbus-service' <{0}grant>I really have never used it non-trivialy, bu I might as while try using wicd as is there seems to be decent general automation in-route there. <mark_weaver>also, since you made yourself a group, you probably want (group "grant") instead of (group "users") in your user-account <{0}grant>I might just remove said gorug, I'm not sure why I even had it in there to start besides messing around. <{0}grant>Do we need to specify swap? I didn't see anywhere mentioning this, but I've been trying real hard as of recent to fix my sleep schedule ... so it's probably very possible I was sloppy and missed it. <mark_weaver>yes, add something like (swap-devices '("/dev/sdaX")) <{0}grant>mark_weaver: Ah, yeah, sorry you're correct. <mark_weaver>see section 6.2 of the manual (System Configuration) <mark_weaver>you should probably add one of the packages that provides a SLIM service. <mark_weaver>and almost certainly lacks a session definition for display managers such as SLIM. <{0}grant>Doesn't Windowmaker currently come with the slim-service, or is that some other depend I have? <mark_weaver>the way SLIM sessions were managed was recently changed <{0}grant>In any case, ty mark_weaver. Just started the sys-init and it seems to be chugging along just fine. :^) <{0}grant>Tomorrow, hopefully on a lot more sleep than I've allotted myself today -- I can close to finish up that machine, and do a little on said probable dedicated build-box. <mark_weaver>it used to be that you had to pass the list of sessions to slim-service. now you just add the relevant packages to your system-wide profile and it happens automatically. <mark_weaver>windowmaker still seems to be the default fallback session, but I'm not sure it will work properly if it's not in the system-wide profile. <{0}grant>I don't have enough effort in me tonight to fool around anymore, but yeah, I'll keep an eye out. <mark_weaver>{0}grant: you don't need to import (gnu packages) or (gnu system) <{0}grant>Hm, Guix is warning me that "wicd" is an unbound variable, even though I have it in my (use-package-modules), (packages), and (services). <{0}grant>When I put it in (use-service-modules) that causes a different error. <{0}grant>Hm, took it out of dbus-service and it's seemingly going. <{0}grant>mark_weaver: We have lift-off! Ty, main box is now booting to and connected the internet via Guix. :^) <{0}grant>There seems to be an issue with my home directory on this box, but I'll mess with that tomorrow. <rekado>Since rebasing my solfege package to a more recent version of Guix I get this error whenever I use substitute* in a build phase: <rekado>ice-9/boot-9.scm:106:20: Throw to key `decoding-error' with args `("scm_getc" "input decoding error" 84 #<input: solfege/dataparser.py 11>)'. <rekado>ah, works fine after wrapping in (with-fluids ((%default-port-encoding #f)) ...) <taylanub>can mips problems generally be detected by building with --system=mips64el? if so, perhaps packagers should be encouraged to consistently test this so we don't keep bothering mark_weaver :\\ <taylanub>more generally, one might want to test all possible systems. maybe this and a couple other things (like the -K flag) could be stuffed into a convenient 'guix build --test' command. <civodul>taylanub: --system works only if your system can locally build the thing, or can offload to a machine with the given system type <Sleep_Walker>do we have support for cross copmilations or support for build through qemu? <civodul>so for mips, most of us can't do more than rely on hydra <taylanub>oh, x86_64 being able to build with --system=i686-linux is a special case of sorts? *taylanub knows little about hw architectures <civodul>there's special code in the daemon to use the Linux personality(2) syscall and enter i686 mode <taylanub>would --target work? detect at least some of the errors maybe? <civodul>so you would probably detect other issues, related to cross-compilation <civodul>then in theory, if you manage to cross-compile, you could run the mips binary with qemu <Sleep_Walker>I think there was some support for running transparent architecture emulation through binfmt :) <Sleep_Walker>I think that LVM, encryption, more packages and services is more important now <Sleep_Walker>OTOH we could add packager field in guix package and send e-mail automatically for build failures on hydra <civodul>there's actually a 'maintainers' field, which is currently unused <civodul>i've been thinking that we should start using it <civodul>well, we need to discuss it, and add a (guix maintainers) modules or some such <civodul>similar to (guix licenses) but for people <taylanub>can't wait to have a Scheme object represent me :D <Sleep_Walker>hehe, there will be first variable with underscore in schem ;b <civodul>we all deserve an incarnation in the world of Scheme values, don't we? :-) <taylanub>off-topic/maybe-relevant: http://distrowatch.com/weekly.php?issue=20150330#community systemd intending to keep a fork of Linux for better control. "We will no longer need GNU/udev/ntpd/NetworkManager/syslogd/Linux. Instead we will soon have GNU/systemd, [a] much simpler, unified platform. GNU/systemd will be a better target for third-party developers and easier to support." <taylanub>sounds like an early April Fools joke, but given the reported willingness to stay compatible with upstream Linux it doesn't seem that absurd either <Sleep_Walker>it's not said by Lennart, Kay or Greg (who works for linux foundation and would be against fork) <Sleep_Walker>it's linked to some (to me) unknown guy who doesn't have any other repository on GitHub *taylanub asks in #systemd <Sleep_Walker>it would be also company unwise as systemd is funded by RH and they are big kernel code contributor would maintain also its fork <taylanub>#systemd seems to consider it a prank, the GitHub account of Ivan seems to be a fake, and no other source seems to be available. false alarm I guess. <Sleep_Walker>(don't expect the patch is scheme - I'm still on the beginning of The Little Schemer) <civodul>the first thing would be to think how we'd declare it in the 'operating-system' thing <Sleep_Walker>hmm, maybe I could patch initrd generation and hardcode it for myself for now <civodul>that's another way to approach it, yes <civodul>and then if you can share with us something that works for you, we can try to generalize it <Sleep_Walker>I reached the disk space for GuixSD and can't build packages anymore so I need either repartition whole notebook or add LVM support :b <mark_weaver>ugh, I upgraded tzdata, and just noticed that this will cause a rebuild of glib and everything on top of it, simply because glib uses tzdata to enable one of the tests. <mark_weaver>maybe the tzdata update should go to core-updates instead <Sleep_Walker>if you think that such changes may happen more often we could split the package <mark_weaver>it's not worth it. it can wait for the next core-updates merge <rekado_>I have an error when running a Python-based application: <rekado_>ImportError: /gnu/store/08n65fxky70imkljc422zqc5xh14wiv7-pbtranscript-tofu-0.4.1.c7bbd5472/lib/python2.7/site-packages/pbtools/pbtranscript/findECE.so: undefined symbol: PyUnicodeUCS4_DecodeUTF8 <rekado_>does anyone know what the cause of this might be? <civodul>mark_weaver: oops; alternately, we could have a "stable" tzdata for the purposes of glib <civodul>oh Sleep_Walker already proposed that <civodul>rekado_: i suspect findECE.so lacks the right lib in its RUNPATH <taylanub>'ps -C foo' doesn't seem to work during the ngircd build. anyone know why this might be? 'ps' output shows there's definitely instances of sh running, yet 'ps -C sh -o pid=' doesn't print anything <civodul>taylanub: i don't know about -C, could it be that it wants an absolute file name <taylanub>I tested outside guix by running e.g. /gnu/store/.../bin/display (imagemagick) and 'ps -C display' worked fine, so I don't think it's the absolute and long file names <civodul>apparently 'ps -C' works by browsing /proc/PIDs <civodul>could you try to run it in strace in the build environment? <taylanub>it seems the reason is that running a shebang script will make its name be the file's name and not the interpreter's, even though in full ps output (e.g. 'ps -elfww') the file's name appears as an argument to the interpreter <taylanub>maybe I should just patch the line that calls './getpid.sh sh' instead of getpid.sh <taylanub>hah, I think I know why getpid sometimes fails, and it's pretty horrible: it greps for the given string in 'ps -ax' output (which contains whole command lines with arguments) and tests whether the result is greater than 1 to see if it's a valid PID. in our build environment, PID 1 is guile with an absolute file name including the hash, which may easily (but does not always) contain the string <civodul>ooh, i've seen this kind of issue in some test suite before <civodul>basically sloppy grep over the list of command names <taylanub>Sleep_Walker: that behavior is what we're trying to avoid :-) <taylanub>I guess pgrep can achieve the same result as 'ps -C'. (that's indeed the route I'm taking now, patching the one place where getpid.sh is used against an interpreter name where ps -C only works for the script's name.) <{0}grant>Okay, version 2 of my os-config on this box, and when I try to log in as my user it says it can't cd to /home/grant ... which leaves me to believe my filesystem configuration is still wrong. What I have so far: http://paste.lisp.org/display/146644 <civodul>{0}grant: when you log in as root, does /home/grant exist, and what are its owner/permissions? <{0}grant>civodul: Okay, just logged in as root -- went to ../home/ and didn't see a grant dir generally. <{0}grant>I wonder if it's on sda2, but didn't mount to it? <{0}grant>Nope, sda2 has a lost+found dir ... which looks like it tried to go something, but was unable to make said dir. <{0}grant>Okay, so sda2 /is/ mounted to my root directory. <{0}grant>Just my user doesn't have a home-directory dir. <{[]}grant>Very odd that guix refused to make a home dir for my 'grant' user though, via my os-config file. Could easily be user error on my end though. <atheia>{[]}grant: do you have home on a separate partition by any chance? <{0}grant>atheia: Yeah, root on /dev/sda1 and home on /dev/sda2. <{0}grant>But since this is specified in the configuration -- I don't see how this should/would make a difference though. :^P <civodul>normally the home dir is created along with the user account the first time you boot <atheia>{0}grant: I don't know if this is plausible, but I had similar symptoms when I set up my computer with a separate home partition. <atheia>At the time I thought the issue was that I had not mounted home before issuing the guix system init command from the installation medium. <atheia>Like I say, this may be a red herring. <atheia>especially if, as civodul says, home is normally only set up on first boot, not during system init. <{0}grant>atheia: In any case, it's not a huge concern to me -- it was just very odd and annoying to me last night, after a very long and sleep deprived day. :^P <{0}grant>And it really then not that annoying either, a more of a "screw it" situation that I figured I would figure out the following day in a number of minutes when I got a decent amount of refueling. <{0}grant>Later today, I'll likely said up that buildbox, or rather at least start on it. <{0}grant>The hydra situation that past few days has actually been better than I remember the last time I've checked in with Guix though, which was promising, but may also just of been a fluke. <{0}grant>Either case, I have a spare box and 1tb drive that fits said requirements and a decent enough connection here where I think such an effort on my end would be worthwhile. <{0}grant>Peacing out on this box, staying online on the other. o/ <mark_weaver>{[]}grant: your home directory might be on the root partition, hidden by the /home mount point <mark_weaver>the way to find out is to mount another copy of your root partition somewhere else <mark_weaver>your home on the root partition might then be visible in /mnt/home/* <mark_weaver>then you can umount /mnt and it will unmount /mnt leaving / alone <Sleep_Walker>has anyone give a thought ext* filesystem tunning for use with Guix? <Sleep_Walker>(reducing block size, increasing number of i-nodes, ... ) <mark_weaver>Sleep_Walker: why would smaller blocks be appropriate for Guix? <Sleep_Walker>reducing block size reduces minimal space occupied by file <Sleep_Walker>if we have big difference between ammount of data stored and ammount of disk space occupied, it can be probably improved <mark_weaver>if the target of a symlink is less than 60 bytes, it is stored directly in the inode <mark_weaver>but anyway, I don't think anyone has thought much about how to tune ext4 for Guix. I haven't run out of inodes yet anyway, although I'm perpetually low on disk space. <Sleep_Walker>$ I=0; while read line; do if [ "${#line}" -ge 61 ]; then I=$((I+1)); fi; done < <(ls /gnu/store/*); echo $I <Sleep_Walker>ok, on my system is the difference ~700 MB on 14GB of data <taylanub>out of the 3485 symlinks I have in ~/.guix-profile, exactly 1 is 60 bytes, the rest more :-) <taylanub>the longest is 127. pretty unfortunate that we waste space on almost all symlinks in a profile, but it's probably still a minor thing in total <davexunit>I don't think there's a way to do what we do without symlinks <Sleep_Walker>the topic is filesystem tunning - whether anyone tried to tune store of so many symlinks <mark_weaver>but how many symlinks are there? mostly they are in the profiles <mark_weaver>if you make the block size smaller just to optimize those symlinks, you will pay for it elsewhere <taylanub>if ext4 had a way to easily enlarge the symlink space of an inode, it might had been worth it, but we're splitting hairs anyway. <mark_weaver>that's why I'm curious what percentage of inodes are symlinks *taylanub runs find /gnu/store -type f | wc -l <taylanub>approx. 672.0k files in my store, opposed to 3.5k symlinks in my profile. that's 0.5%. although this is a single-user system and I have a bunch of uninstalled packages due to development. maybe in a system with a dozen users, each with a lot of packages and many of them shared, it might be more... we might want to analyze this better some time in the future. <mark_weaver>anyway, it obviously depends on how many old profiles you have laying around <mark_weaver>but it seems likely that symlinks are a small percentage of files <mark_weaver>how many profiles do you have? and have you run 'guix gc' to delete those old profiles? <mark_weaver>I don't believe Guix contains any code to format filesystems, so the only thing to change would be documentation. if you'd like to propose that we recommend the users choose a smaller block size, it would require some study of how it would affect both the storage efficiency and performance under various loads. <mark_weaver>I suspect that choosing a smaller block size would lead to negative consequences that are more important than storage efficiency, but admittedly it's just a guess. <Sleep_Walker>as I said above (21:22) - ext4 seems to be doing quite good job by default <mark_weaver>civodul: adding a phase to check for missing rpaths sounds very useful! <mark_weaver>civodul: the libunistring thing on mips sounds interesting <mark_weaver>civodul: fwiw, I just checked on librenote, and the natively-built libunistring appears to have all the needed runpaths to find libgcc_s <mark_weaver>(I checked by running 'ldd' on libunistring.so.2.0.0 from current master) <civodul>mark_weaver: the libunistring was a cross-built one, so that's a different issue <civodul>i mean, that's probably an issue with cross builds in general *mark_weaver has 229K symlinks in /gnu/store and 625K normal files <Sleep_Walker>and what about `du -sx /' and `du -sx --apparent-size' ?