IRC channel logs


back to list of logs

***grant__ is now known as {0}grant
<{0}grant>Is there anything that looks blantantly wrong with, ? I think it's the way I tried to set up my file-system layout.
<{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>{0}grant: the file-systems field is all messed up
<{0}grant>mark_weaver: Mine, or generally?
<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'
<mark_weaver>I have (dbus-service (list avahi wicd))
<{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
<mark_weaver>and you should have (locale "en_US.utf8")
<{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>mark_weaver: Not "en_US.UTF-8" ?
<mark_weaver>it might be that both work, I don't know.
<mark_weaver>but I know that mine works anyway
<{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>e.g. xfce, ratpoison, or windowmaker
<{0}grant>Did I remove ratpoison?
*{0}grant goes to check.
<mark_weaver>ah, you have guile-wm
<mark_weaver>but that's not usable out of the box
<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>it might work, dunno
<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.
<{0}grant>Oh, that's pretty neat.
<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)
<mark_weaver>you don't need (guix monads) either
<{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>put it in also*
<{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/ 11>)'.
<rekado>Is this locale-related?
<rekado>ah, works fine after wrapping in (with-fluids ((%default-port-encoding #f)) ...)
<civodul>Hello Guix!
<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.
<taylanub>it would run lint too
<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
<taylanub>I see
<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>--target implies cross-compilation
<civodul>so you would probably detect other issues, related to cross-compilation
<taylanub>hm, ok
<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>but I won't focus on this for now
<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
<Sleep_Walker>(otherwise I won't know about MIPS failures)
<civodul>there's actually a 'maintainers' field, which is currently unused
<civodul>i've been thinking that we should start using it
<Sleep_Walker>good idea
<Sleep_Walker>I can add myself to the packages I added
<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: 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."
<Sleep_Walker>looks like prank
<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>I can't locate the author among authors
<Sleep_Walker>probably prank
<Sleep_Walker>(and good one if people actually believes that :)
<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>yeah, that is not how RH operates :)
<taylanub>oh, "Gotyaovitch" -> "Got ya" hahaha
*taylanub is naive
<Sleep_Walker>what can I do to help with LVM support?
<civodul>implement it? :-)
<Sleep_Walker>(don't expect the patch is scheme - I'm still on the beginning of The Little Schemer)
<Sleep_Walker>s/patch is/patch in/
<civodul>the first thing would be to think how we'd declare it in the 'operating-system' thing
<Sleep_Walker>like which LVM group to activate
<Sleep_Walker>(vgchange -a y "group")
<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 know the steps I need
<Sleep_Walker>I just can't express it in Scheme
<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/ 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>forget it
<civodul>rekado_: i suspect 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?
<civodul>that may give a clue
<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 './ sh' instead of
<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
<Sleep_Walker>pgrep accepts `-f'
<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 is used against an interpreter name where ps -C only works for the script's name.)
<Sleep_Walker>I do agree that it is not clean solution to any task
<Sleep_Walker>but still improvement over ps | grep :)
<{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:
<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 goes to check.
<{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.
<{0}grant>Should I just make one... or?
<{0}grant>Seemingly worked.
<{0}grant>Rebooting and crossing fingers. :^)
<{[]}grant>And, just wonderful!
<{[]}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 goes afk
<mark_weaver>{[]}grant: do: mount --bind / /mnt
<mark_weaver>your home on the root partition might then be visible in /mnt/home/*
<Sleep_Walker>nice trick
<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, ... )
<Sleep_Walker>or is ext4 clever enough already?
<mark_weaver>Sleep_Walker: why would smaller blocks be appropriate for Guix?
<Sleep_Walker>I'm not sure how symlinks are stored in filesystem
<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>smaller blocks entail other costs
<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>another item to investigate to my TODO list
<Sleep_Walker>ok, on my system is the difference ~700 MB on 14GB of data
<Sleep_Walker>that is not that bad
<taylanub>out of the 3485 symlinks I have in ~/.guix-profile, exactly 1 is 60 bytes, the rest more :-)
<mark_weaver>and what ratio of files on the system are symlinks?
<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
<Sleep_Walker>how to alter configuration to store them efficiently
<mark_weaver>but how many symlinks are there? mostly they are in the profiles
<Sleep_Walker>but it seems that ext4 does good job already by default
<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>but then you're increasing the size of every inode
<mark_weaver>there are tradeoffs to consider
<mark_weaver>that's why I'm curious what percentage of inodes are symlinks
*taylanub runs find /gnu/store -type f | wc -l
*mark_weaver goes afk
<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.
<Sleep_Walker>taylanub: you're not counting symlinks in /gnu/store
<mark_weaver>profiles are in the store
<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
<Sleep_Walker>I have 280k symlinks in /gnu/store
<Sleep_Walker>out of 445k files in /gnu/store
<Sleep_Walker>(I was overwhelmed by number of files in my system)
<mark_weaver>how many profiles do you have? and have you run 'guix gc' to delete those old profiles?
<Sleep_Walker>I usually have ~15 generations
<Sleep_Walker>I should check root as well
<Sleep_Walker>but I'm in the middle of repartitioning...
<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.
<civodul>mark_weaver: BTW, what do you think of ?
<Sleep_Walker>as I said above (21:22) - ext4 seems to be doing quite good job by default
<mark_weaver>Sleep_Walker: indeed you did. apologize
<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 checks
<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>so it may be an issue with cross-compilation
<mark_weaver>(I checked by running 'ldd' on from current master)
<civodul>mark_weaver: good!
<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' ?