IRC channel logs


back to list of logs

<mark_weaver>more icecat security fixes in the works...
<zacts>was it icecat that is the official gnu version of firefox, or was it abrowser?
<zacts>oh cool
<mark_weaver>I just pushed the fixes, although I confess that my own machine hasn't finished building it yet.
<zacts>mark_weaver: did you say you own an x200, or was it just a yeeloong?
<mark_weaver>(the patches are minimal enough that if they applied cleanly and I've gotten this far in the build, I'd be very surprised if it fails to build)
<zacts>(please exuse me if I mispelled the names)
<mark_weaver>I'm using a Libreboot X60
<zacts>oh neat
<mark_weaver>I have an X200, but it has a dead backlight and has not yet been liberated
<mark_weaver>I've mostly stopped using my Yeeloong, although it still has some private keys that I've not yet copied anywhere else.
<civodul>Hello Guix!
<freaj>civodul o/
<wingo>morning guixers :)
*wingo just got a new laptop today, contemplating installing guixsd
<wingo>q: is it possible to build with a mainline kernel?
*wingo queries civodul
<civodul>wingo: mainline as is not linux-libre?
<wingo>civodul: yeah, or if i need to upgrade the kernel or patch it or something
<civodul>the 'operating-system' thing has a 'kernel' field, where one can specify the kernel
<civodul>the kernel package object, that is
<civodul>so if you have a custom kernel, you can always specify it there
<wingo>i see
<civodul>that may be inconvenient to do for the initial installation, but it can be done afterwards
<wingo>yes that is what i was thinking
<wingo>will give the guixsd install image a go, probably it will be fine
*civodul crosses fingers ;-)
<civodul>thanks for trying it out!
<wingo>my pleasure, apologies in advance for the stupid questions :)
<civodul>heh, and apologies for the unsatisfactory answers ;-)
<wingo>the image boots at least
<wingo>that's good :)
<civodul>i'll be back in ~2h
<civodul>and that's not because i don't wanna see the bug reports, i swear!
<wingo>jesus how do i partition this thing :)
***boegel|afk is now known as boegel
<wingo>having to mkdir /etc on the install partition is odd
<wingo>wow, very cool that tty2 has the info page open :)
<wingo>this is very exciting
<mark_weaver>wingo: having to "mkdir /etc" on the install partition? I don't remember doing that myself.
<wingo>mark_weaver: according to the build instructions you are to copy /etc/config-template.scm to /mnt/etc/config.scm
<wingo>but /mnt is a fresh-made file system
<wingo>at least it was for me
<wingo>so no /etc directory
<mark_weaver>ah, right
<mark_weaver>I think I did something else, but it was so long ago I forgot the details :)
<wingo>yeah i didn't know if the file needed to be there or what
*wingo ignorant :)
<mark_weaver>anyway, I'm glad to see you taking the plunge, or at least giving it a spin! :)
<wingo>yay it got to the "initializing operating system" phase
<mark_weaver>it can be anywhere, but it's good advice to make sure to put a copy somewhere it won't be lost
<wingo>this is a fresh laptop; i copied windows to /dev/null :P
<mark_weaver>I just pushed security updates for GNU icecat, and Hydra (our build farm) is about 1.5 hours into building it.
<wingo>so i got an error about not having a bios boot partition
<mark_weaver>if you install icecat before it's done, it'll build it on your system locally
<mark_weaver>ah, a UEFI system?
<wingo>with the compat thing enabled
<wingo>so i guess i have to create a bios boot partition
<mark_weaver>interesting. well, we don't currently generate a grub.elf to put there, I'm afraid.
<mark_weaver>hopefully it won't need that in the compat mode
<mark_weaver>so far, none of our brave users have run into this problem yet
<mark_weaver>(it wouldn't be hard to fix, but personally I don't have a UEFI laptop to play with)
<mark_weaver>I'm a bit surprised that it demands such a partition in compatibility mode
<wingo>that was grub asking for it
<mark_weaver>that's very surprising to me
<mark_weaver>this is the grub installed by our USB installer?
<wingo>now i have weird problems and can't continue
<wingo>yes this is in the grub installation phase
<wingo>unfortunately i don't have it in scrollback any more
<mark_weaver>oh, I see
<mark_weaver>this happened when you ran 'guix system init' ?
<wingo>do you know of a way that i can recover? i could just restart the whole thing
<wingo>i think i probably need to do that
<wingo>because i did a deco stop cow-service or whatever that was
<wingo>in the hopes that i could unmount the drive and try again
<wingo>but i seem to have wedged things, so that now guix system init complains about guile-bootstrap not being in /gnu/store where it expects it
<wingo>and i seem to have two unionfs processes running
<mark_weaver>you might need to clear out the target partition (making sure to keep your OS-config.scm though)
<mark_weaver>hmm, maybe you should restart it
<mark_weaver>I don't know enough details off-hand to know how best to recover.
<wingo>i'll do that.
<wingo>having killed the duplicate unionfs i can't even run mount now :)
<wingo>oh well, this time i have a bios boot partition, maybe it will work
<wingo>tx for the company :)
<mark_weaver>heh :)
*mark_weaver needs to read more of the installer code
<mark_weaver>so I guess that 'grub-install' detected that you have a UEFI system and is trying to do the right thing
<mark_weaver>I don't know if this case has been tested yet
<wingo>i've rebooted and it's trying again
<wingo>so i guess i'll know in 30 minutes or so
<mark_weaver>looking at the install code, installing grub is pretty much the last thing done. in theory, if it fails again, you could just re-run 'grub-install' manually.
<wingo>good to know
<wingo>excited about having guix.el ready-to-go
<wingo>that's great
<mark_weaver>the relevant code is 'install' in guix/scripts/system.scm which calls 'install-grub*' in the same file, which calls 'install-grub' in gnu/build/install.scm
<mark_weaver>the command run is: grub-install --no-floppy --boot-directory /mnt/boot /dev/???
<mark_weaver>(assuming /mnt is your target mount point)
<wingo>it's currently downloading substitutes, should be done shortly
<mark_weaver>after that, it looks like there's just one more thing to do: the (rename temp-gc-root gc-root) in 'install-grub*'
<mark_weaver>but hopefully it'll just work (crosses fingers)
*wingo hopes the same
<wingo>got the the "installing operating system" phase again, so i guess 15 minutes for the downloads then
<wingo>not terrible i suppose
<mark_weaver>we should probably update the docs to recommend using (wicd-service) instead of (dhcp-client-service), and adding 'wicd' to the list of system-wide packages.
<wingo>ok so it says "path /mnt/boot/grub is not readable by GRUB on boot; installation is impossible. aborting"
*mark_weaver looks at grub docs
<mark_weaver>is the new BIOS partition mounted somehwere within /mnt ?
<mark_weaver>not sure where it wants it off hand, but I guess it probably wants it.
<wingo>you think i should mount /mnt/boot in a separate partition, hmm
<mark_weaver>well, I'm not yet sure
<mark_weaver>did you set the partition type of the BIOS partition to 0xEF02 ?
<mark_weaver>(see section 3.4 of the grub manual)
<wingo>not sure, but i did mark it as a bios boot partition in fdisk
<wingo>not sure what constant that corresponds to
<wingo>this is a gpt disk
<wingo>so i think the constants are a little different
<mark_weaver>is parted available in the boot system? if not, you could install it
<wingo>yes parted is available
<mark_weaver>I'm reading the 'GPT' section of that section of the grub manual I just cited.
<mark_weaver>parted /dev/DISK set PARTITION-NUMBER bios_grub on
<mark_weaver>^^ the command it recommends when using parted
<wingo>mark_weaver: i think that is the case
<wingo>it's marked as bios_grub
<wingo>i think parted is not as good as fdisk with gpt disks
<wingo>anyway, i will see if i can arrange for /boot (via /mnt/boot) to be a separate partition
<mark_weaver>hmm. the thing is, I think grub needs to be built differently when used in EFI mode.
<mark_weaver>since your BIOS support compatibility mode, it shouldn't need that.
<mark_weaver>so it's a slight drag that 'grub-install' is apparently trying to be clever about it.
*mark_weaver wishes civodul were here to help
<mark_weaver>oh, looks like grub expects the BIOS boot partition to be mounted at /boot/efi
<mark_weaver>oh, actually....
<mark_weaver>grub-install has a --target option
<mark_weaver>since we don't pass it, it might be trying to guess
<wingo>well this is booting in bios mode i think
<mark_weaver>which is bad in our case
<wingo>later i can switch it to efi
<wingo>if needed or a good idea
*wingo ignorant, again
<mark_weaver>I think we might just need to pass the right --target=
<wingo>i think that's a target architecture, isn't it?
<mark_weaver>it's more than just that
<mark_weaver>it also specifies whether this is for a EFI system or legacy, coreboot or not, etc..
<mark_weaver>I would guess that --target=x86_64-pc might be the thing
<mark_weaver>wingo: can you try running: grub-install --no-floppy --target=x86_64-pc --boot-directory /mnt/boot /dev/??
<wingo>"source_dir doesn't exits. Pleas specify --target or --directory"
<wingo>when i did an install earlier it created a /mnt/boot/grub/i386-pc directory
<wingo>could be that i386-pc is the right target
<mark_weaver>can you "cd $(guix build grub)/lib/grub"
<mark_weaver>and then 'ls' ?
<mark_weaver>you might be right
<mark_weaver>okay, try --target=i386-pc
<wingo>mark_weaver: same error
<wingo>note that it does create the files in /mnt/grub
<wingo>including /mnt/grub/i386-pc
<mark_weaver>okay, can you try passing --directory=$(guix build grub)/lib/grub/i386-pc instead of --target?
<wingo>should i have a /mnt/etc/fstab ?
<wingo>i don't
<wingo>i just have /mnt/etc/config.scm (!)
<wingo>could it be that making the /etc directory in /mnt borked the copy-on-write daemon?
<wingo>does guix install to /etc at all?
<mark_weaver>there's no fstab in guix
<mark_weaver>not yet anyway
<mark_weaver>so the error message actually says "source_dir doesn't exist" ?
<mark_weaver>what is the error?
<wingo>the error message is as the beginning, "/mnt/boot/grub not readable by grub on boot"
<wingo>i only got the error about the dir when specifying x86_64-pc
*mark_weaver looks at the grub-install code
<wingo>and haven't gotten it since
<mark_weaver>what error do you get when passing --directory=$(guix build grub)/lib/grub/i386-pc ?
<mark_weaver>oh, nevermind
<mark_weaver>sorry, was confused..
*mark_weaver looks at the grub-install code.
<wingo>no need to apologize :)
<wingo>i very much appreciate the company :)
<mark_weaver>what filesystem type are you using?
<mark_weaver>it may be that we lack the needed grub module
<mark_weaver>'is_path_readable_by_grub' in grub-mkconfig_lib thinks that this grub will not be able to access that directory at boot time.
<mark_weaver>it is a sanity check
<mark_weaver>also, are you trying to use LVM?
<wingo>not using lvm
<wingo>well given that i can boot from the live disk i gues i can try --force
<mark_weaver>please run: grub-probe -t fs /mnt/boot/grub
<mark_weaver>what does it say?
<wingo>grub-probe: error: failred to get canonical path of unionfs
<mark_weaver>interesting. I wonder why others aren't tripping over this.
<mark_weaver>yeah, maybe try --force
<mark_weaver>and I guess you can omit the --directory option
<mark_weaver>(and --target)
<mark_weaver>those weren't needed after all
<wingo>--force didn't work
<mark_weaver>well, on second thought, better keep the --directory in there
<wingo>so /mnt isn't actually mounted
<wingo>it's just accessed via unionfs i think
<mark_weaver>that doesn't make sense to me
<mark_weaver>did you not mount /mnt ?
<wingo>i guess i missed that step in this go-round
<mark_weaver>bummer :)
<wingo>welp, i'll give it another go :)
<wingo>i guess cow-store should check on that
<mark_weaver>I actually think that the --directory= option is probably important after all
<mark_weaver>grub-install looks for /sys/firmware/efi, and if it's present it uses the x86_64-efi target
<mark_weaver>which we don't yet build
<wingo> /sys/firmware/efi doesn't exist
<wingo>the guix image *won't* boot over efi
<wingo>even having disabled secure boot and all
<wingo>i had to enable legacy support
<wingo>so to this image it booted off of bios
<mark_weaver>well, I'm not sure then why you got the error about a missing bios partition the first time around
<wingo>because it's a gdt drive i think
<mark_weaver>oh, could be
*wingo ignorant
*mark_weaver too :)
<wingo>so i wonder, would there be any problem making /etc on /mnt ?
<wingo>i guess that doesn't pose a copy-on-write problem
<wingo>maybe for now i use a local file tho
<mark_weaver>I think it's probably fine
<mark_weaver>the install docs recommend putting the config file in /mnt/etc, and I haven't seen anyone having problems from that.
<wingo>i'll copy it there when this download is done
<mark_weaver>yeah, make sure not to discard your OS config
<wingo>see you in another 20 minutes :)
<mark_weaver>if civodul were here, he could probably tell you how to recover more efficiently
<wingo>well, need to lunch anyway :)
<wingo>btw i have a really pleasing thing going on with intmaps about to land
<wingo>it has a good threading story
<wingo>yeah, like clojure's transients, but more transparent
<mark_weaver>I don't know what clojure's "transients" are. I need to learn more about clojure to mine it's concurrency ideas.
*mark_weaver has watched a couple of rich hickey talks, but that's it
*mark_weaver looks
<mark_weaver>ah, hydra has finished building the new security-patched 'icecat'.
<mark_weaver>everyone should update their Icecat asap!
<wingo>is icecat the same as iceweasel?
<mark_weaver>not quite
<mark_weaver>but close
*wingo googles
<mark_weaver>it is GNU's version of firefox
<mark_weaver>(as opposed to Debian's)
<wingo>is cacert in the root set of cert providers on icecat?
<mark_weaver>I don't think so
<wingo>wikipedia thinks that is the case
<mark_weaver>actually, we link our icecat to the system NSS, which is directly from mozilla
*mark_weaver looks
<mark_weaver>bah, no way to search in icecat/firefox's certificate manager, but I don't see it
*mark_weaver looks at the script used to create icecat from firefox esr
*mark_weaver thinkw wikipedia is wrong here
<wingo>easy to check -- just to to
<mark_weaver>I see nothing in the script that would do it, and in the changelog I see only this, from 2011: "make.icecat: Document how include the CAcert root certificate"
<wingo>lol that it is 2015 and i am installing windowmaker
<mark_weaver>"This Connection is Untrusted"
<wingo>mark_weaver: good.
<mark_weaver>wingo: we have XFCE now. it's what I'm using until we have GNOME 3
<mark_weaver>I think civodul is still using windowmaker for some reason
<mark_weaver>probably just inertia I would guess
<mark_weaver>I found it rather unpleasant myself, but XFCE is okay once you change the default panel layout
<mark_weaver>wingo: I would recommend adding both xfce and wicd to the 'packages' of your OS config, and replacing (dhcp-client-service) with (wicd-service)
<mark_weaver>we really need to update our sample OS config
<wingo>mark_weaver: ACK
<wingo>i'll do that once i can boot
<wingo>so what's the idea, do most packages go in the user profile or the system profile?
<wingo>or is that even a well-formed question
<mark_weaver>personally, I put most packages in my user profile, but some prefer to put most in the system profile.
<mark_weaver>so it's a matter of preference I guess
<wingo>doing it in the user profile means you don't have to reboot to get new versions
<mark_weaver>you don't have to reboot anyway
<mark_weaver>there's /run/current-system and /run/booted-system
<wingo>welp, it's copying things now, fingers crossed :)
<wingo>no error
<mark_weaver>once you get one working system, guix is very safe to play with, because the GRUB menu contains all the old systems.
<mark_weaver>we'll have to add something to our installation instruction about creating the BIOS partition on GPT systems I guess.
<wingo>error: failed to resolve partition label "root"
<wingo>and now i'm in a guile prompt :)
<mark_weaver>did you give your root partition a label?
<wingo>i thought i labelled it "guix"
<wingo>but maybe i labelled it something else actually
<wingo>that's it.
<mark_weaver>wel, this should be easily fixable
<mark_weaver>so, in your OS config, I guess you put "root" as the label
<mark_weaver>i guess the easiest fix is to relabel it to what the OS config expects for now
<wingo>i think i put 'guix
<wingo>but actually the label is 'clucks
<wingo>it's a symbol, right?
<mark_weaver>no, a string
<mark_weaver>can you paste your OS config?
<wingo>i can't because i forgot to copy it to /mnt :)
<wingo>however :)
<wingo>it's the same as in
<mark_weaver>well, based on the error message, it seems to be looking for a partition labelled "root"
<wingo>but with (title 'guix) (device "root")
<wingo>and the acual label of the partition i think is "clucks"
<mark_weaver>you misinterpreted the meaning of the 'title' field.
<mark_weaver>understandable, it's not a good name for that field.
<mark_weaver>it should be either 'label or 'device
<wingo>yeah i wasn't sure what to change
<mark_weaver>(or 'uuid, but that's not yet implemented)
<wingo>how should i fix that?
*mark_weaver looks at the relevant code...
<mark_weaver>wingo: relabel the partition to "root"
<mark_weaver>for now at least
<mark_weaver>e2label /dev/?? root
<mark_weaver>it should have been (title 'label) (device "clucks")
<mark_weaver>(we really need to change that 'title' field name)
<wingo>wow, an x session :)
<wingo>i never set my password tho
<iyzsong>sound great o.o
<wingo>ah, root has no password
<mark_weaver>I just set my passwords manually the first time I installed
<wingo>yeah i did that too
<mark_weaver>so, the next thing is to make another OS config that you keep this time
<wingo>the mouse isn't working right on this build tho; might need to update the kernel or libxinput
<mark_weaver>I always keep a backup of a known working OS config.
<mark_weaver>any clues in /var/log/Xorg.0.log ?
<wingo>i have heard about this
*mark_weaver looks
<wingo>so i might want to try a 4.0 kernel build
<mark_weaver>so, my recommendation is to build 'guix' from a git checkout
<wingo>via guix pull?
<mark_weaver>I keep a private branch with my own modifications to guix, and periodically rebase on upstream
<mark_weaver>I've never used 'guix pull'.
<mark_weaver>'guix pull' is meant for non-developers, IMO
<mark_weaver>it is much less flexible that using git
<mark_weaver>(some others here might disagree of course)
<mark_weaver>so, 'guix environment guix' will install everything you need to build guix from git, and spawn a shell with environment variables set so that it finds everything it needs.
<mark_weaver>although I guess you'll first need the git checkout itself.
<wingo>this is very exciting
<mark_weaver>if you haven't yet installed 'git', then 'guix package -i git'
<wingo>i think i have git in this base default image
<wingo>no, apparently...
<wingo>ok :)
<mark_weaver>it might be somewhere in /gnu/store, but maybe not in your profile (tree of symlinks that's in your PATH)
<mark_weaver>and then clone our repo
<mark_weaver>I confess I haven't tried using 'guix environment guix' myself. I just have everything I need already in my profile. but by all accounts 'guix environment guix' is the better way now.
<mark_weaver>when you configure guix, it's important to pass --localstatedir=/var
<mark_weaver>and you might also need --with-libgcrypt-prefix=$(guix build libgcrypt | head -1)
<wingo>it's taking a while to install git
<wingo>so it seems that linus's kernel has the patch i need
<wingo>i have built a 4.0 kernel recently actually and it wasn't bad
<mark_weaver>do you know if it's in 3.19.3?
<wingo>i guess i can just change some existing recipe...
<wingo>will look
<mark_weaver>yes, it should be easy
<mark_weaver>once you have guix built from git, it's very easy to change such things.
<wingo>seems the patch is not in 3.19.3
<mark_weaver>okay. it's easy to add patches too
<wingo>i would try to just build the 4.0-rc snapshot
<wingo>i realize that might include some non-libre things
<wingo>which btw i think i need to install some firmware for my wireless (gulp)
<mark_weaver>yeah, probably
<wingo>does that happen in the guix process or do i just download the things and throw them in a directory (ugh)
<mark_weaver>the firmware directory is in an immutable directory in /gnu/store, so it should be built by guix somehow
*mark_weaver looks
<mark_weaver>so, the OS config has a 'firmware' field, with a list of package objects to merge together into the firmware directory
<wingo>ah neat
<mark_weaver>so I guess the thing to do is to create a package in your local branch that just gets the firmware from wherever
<mark_weaver>it's too bad that lenovo bios has a whitelist for the miniPCIe cards, or else you could replace that with an atheros
<mark_weaver>you might be able to hack your BIOS to work around that though. davexunit did so with his X220 (or X230?)
<wingo>so guix environment guix might take a little while too :)
<mark_weaver>no doubt :)
<mark_weaver>have you cloned the repo yet?
<mark_weaver>the package definitions are all in gnu/packages/*.scm
<mark_weaver>the linux-libre package is in gnu/packages/linux.scm
<mark_weaver>most packages a much simpler, but this one is a bit hairy
<mark_weaver>s/a much/are much/
<mark_weaver>one of the items on my TODO list is to generalize our kernel package to make it easier to create variants with different configs, versions, patches, etc.
<mark_weaver>but alas I haven't done it yet.
<mark_weaver>in this case, for now I think I would just copy+paste the whole 'linux-libre' package definition to make a new 'linux' one, and go from there.
<mark_weaver>but first, get it built as-is
<mark_weaver>(guix from git, I mean)
<wingo>still doing guix environment guix
<mark_weaver>wingo: is it building anything from source, or just downloading things?
<wingo>mark_weaver: downloading
<civodul>wingo: did you run "guix archive --authorize ..."?
<mark_weaver>in retrospect, I probably should have said to run 'guix pull' before doing this, but I can't bring myself to do it when 'guix pull' is not yet authenticated in any way
<wingo>civodul: for what purpose? :)
<mark_weaver>wingo: to enable downloading binary substitutes from our build farm, hydra
<wingo>is that not working out of the box with the install image?
<mark_weaver>otherwise you'll have to build a *lot* of stuff from source code
<wingo>i have only built one or two things from source i think
<wingo>so most are coming from the substitutes
<wingo>afaik anyway
<mark_weaver>if you're downloading substitutes, then I guess hydra is authorized.
<mark_weaver>at some point we made it the default, but I don't remember if that was before or after 0.8.1
<wingo>guix environment guix is installing gtk, la la la
<civodul>wingo: ah you're right, substitutes are enabled by default in the image
<civodul>yeah that was done in 0.8.1
<wingo>can i increase the parallellism on fetching things in any way?
<civodul>you could try --max-jobs=42
<wingo>heh, ok
<civodul>but i'm not sure that would help much
<Sleep_Walker> - is it another occurence of 20037? thought it was fixed already...
<mark_weaver>42? where did that number come from? :)
<civodul> isn't blazingly fast as you've noticed
<civodul>heh :-)
<mark_weaver>especially getting these old binaries that might not be in the nginx cache
<davexunit>hey, wingo is in the house!
<civodul>Sleep_Walker: could be; could you reply to that bug address, showing the command and output with and without the .go files?
<wingo>davexunit: i have a guixsd installed on my new laptop :)
<davexunit>did it go somewhat smoothly, all alpha-ness considered?
<mark_weaver>davexunit wrote the 'guix environment' command :)
<wingo>that's the damn thing that is taking so long to run right now ;-)
<Sleep_Walker>civodul: what all I need to wipe? (IOW where all possible locations of .go files?)
<civodul>Sleep_Walker: dunno, you need to describe more precisely what you're doing etc.
<civodul>but regardless, it shouldn't fail like this
<mark_weaver>my recommendation to avoid 'guix pull' and go right for git from the get-go is probably a bit unorthodox, and maybe related to how long it's taking.
<wingo>mark_weaver: it's fine with me
<mark_weaver>because you're downloading software from when 0.8.1 was released
<civodul>mark_weaver: why avoid 'guix pull'?
<wingo>mark_weaver: so how do i build guix in the guix way?
<mark_weaver>because it's not authenticated
<wingo>i am in guix environment guix
<davexunit>oh cool :)
<mark_weaver>wingo: okay, from the git checkout, run ./bootstrap
<civodul>mark_weaver: and how's 'git pull' authenticated, when using git://?
<mark_weaver>civodul: well, at least with git there are those cryptographic hashes that we are in the habit of passing around.
<civodul>mark_weaver: that tells that the clone is not corrupt, not that it is genuine
<mark_weaver>I dare say that raises the risk of detection high enough to discourage mucking with them.
<mark_weaver>also, I don't know that wingo didn't use ssh
<civodul>ah well yes, only the first 'git pull' is risky
<civodul>one of my todo items it to change 'guix pull' to use 'git pull'
<civodul>for efficiency reasons
<wingo>i used the git url because that's the one that was on the web page
<mark_weaver>civodul: I would guess that if the hash is right, then the checkout is genuine, no?
<wingo>mark_weaver: so do you run guix uninstalled then?
<mark_weaver>wingo: yes, always
<wingo>after bootstrapping
<wingo>ah i see
<mark_weaver>for convenience, I put a script in ~/bin/guix that does: exec /home/mhw/guix/pre-inst-env guix "$@"
<mark_weaver>so I'm always running out of my git checkout, which includes my local modifications
<wingo>i get an error at configure-time about libgcrypt not being usable
<civodul>wingo: you probably need --with-libgcrypt-prefix=$HOME/.guix-profile or some such
<mark_weaver>wingo: ./configure --localstatedir=/var --with-libgcrypt-prefix=$(guix build libgcrypt | head -1)
<civodul>even better :-)
<mark_weaver>civodul: why is that --with-libgcrypt-prefix= needed, btw? it's not needed when building in a Debian environment
<mark_weaver>we should probably fix that at some point
<davexunit>are we missing a search path?
<civodul>because it does to do (dynamic-lib "libgcrypt")
<civodul>"it tries to do"
<davexunit>ah yes, that's right.
<wingo>that's the old topic -- we need to junk libltdl
<davexunit>I don't know of any way to make that "just work"
<wingo>or maybe that doesn't solve this problem
<civodul>that would be the same issue without libltdl
<civodul> cannot know where is to be founud
<wingo>humm :)
<civodul>unless LD_LIBRARY_PATH is defined etc.
<davexunit>in my guix environment for Sly, I adjust a package to add a LTDL_LIBRARY_PATH native search path
<davexunit>so that the env "just works"
<davexunit>but it's a hack
<civodul>we should fix libc to allow per-user, maybe
<davexunit>need a better way
<wingo>it's funny that the guix packages are compiled
<wingo>like the scheme files
*wingo amused
<davexunit>for reference:
<mark_weaver>wingo: yeah, occasionally I've wondered if that's a waste, but actually it might be important because so many packages have to be accessed when traversing the entire set of dependencies, etc.
<wingo>mark_weaver: it's a nice way to lint the packages tho
<wingo>checks for typos and such
<civodul>and also because it allows us to make macros arbitrarily expensive
<wingo>heh, that too
<mark_weaver>but it's a lot to compile, so it might be worth investigating whether it would be okay to run gnu/packages/*.scm interpreted.
*wingo doesn't mind the compilation
<davexunit>I'm skeptical that it would be beneficial
<davexunit>the compilation time for guix is getting quite long, but it's not horrible.
<mark_weaver>at least when running from git, you only rarely have to recompile everything.
<davexunit>I have a feeling that my dev environment has some issues, because 'guix pull' on my guixsd system finishes *much* quicker
<wingo>davexunit: do you have to do fresh recompiles frequently?
<mark_weaver>(only when some important macro changes)
<davexunit>wingo: not usually.
<mark_weaver>it's quite rare to need a fresh recompile
<paroneayea>as a fun thought experiment: has anyone thought of having gnu dmd be able to read systemd service files? Might be a fun feature.
<davexunit>sometimes I switch to old dusty branches and rebase them on top of master to continue working on something and suffer a full rebuild.
<davexunit>paroneayea: it's a GSoC project, actually. :)
<davexunit>in other news, xobs and bunnie might be able to donate a pre-production Novena board to us.
<wingo>i have a stale lookup failure for
<wingo>while building guix
<wingo>how do i flush the nscd or whatever is caching the lookup failure?
<mark_weaver>davexunit: sweet! just saw the email
<mark_weaver>wingo: "deco restart nscd" as root
<wingo>mark_weaver: gross :)
<mark_weaver>yeah, maybe there's a better way
*mark_weaver ignorant
<davexunit>yeah what happened to cause that?
<wingo>davexunit: no idea
<mark_weaver>I don't know, but I've had to do that occasionally.
<wingo>was doing a make -j4
<wingo>neat, guix is built
<wingo>mark_weaver: now that i have a guix from git, do i upgrade?
<mark_weaver>so, to run from the git checkout, all commands should be prefixed by /path/to/git/checkout/pre-inst-env guix ...
<mark_weaver>so first: ./pre-inst-env guix system build OS-config.scm
<wingo>where os-config is the new config
<wingo>where is configuration-template.scm
<mark_weaver>wingo: so, recommended changes: (1) add xfce and wicd to 'packages'
<mark_weaver>(2) replace (dhcp-client-service) with (wicd-service)
<mark_weaver>(3) add "netdev" to your supplementary groups
<mark_weaver>you'll need to add xfce and wicd to the 'use-package-modules' form also
<mark_weaver>and also add 'wicd' to the list passed to 'dbus-service'
<wingo>mark_weaver: doing ./pre-inst-env guix build ./os-config.scm
<wingo>it tells me "guix build: error: /.../os-config.scm: unknown package
<mark_weaver>./pre-inst-env guix system build ./os-config.scm
<mark_weaver>you were missing the "system" in there
<wingo>thank you :)
*civodul wonders why is stale
<mark_weaver>civodul: btw, I took the liberty of updating the package count on from 1,000 to 1,500
<civodul>oh sure, thanks
<mark_weaver>we're almost at 1600 if you count python-* and python2-* packages separately, but I chose to fold those together for purposes of the count.
<mark_weaver>yeah, I've noticed the openhub is way behind
<davexunit>bummer :(
<wingo>civodul: using -M is a big improvement for me
<wingo>or at least it seems that way :)
<mark_weaver>btw, everyone should update their 'icecat'. important security updates pushed last night.
*wingo needs mouse buttons working before installing a browser :)
<mark_weaver>wingo: I can help walk you through the process of creating a 'linux' package, when the time comes.
<mark_weaver>did the 'guix system build' finish yet?
<wingo>mark_weaver: thank you very much!
<wingo>the guix system build is still doing its thing
<mark_weaver>okay, let me know when it's done
<wingo>will do. cheers :-))
<mark_weaver>wingo: do you have an external mouse you could use temporarily?
<wingo>mark_weaver: it's a good idea, i do
<wingo>i'm ok to keep working on my desktop while the upgrade is happening tho
<wingo>mark_weaver: i have a new system build. do i reboot?
<iyzsong>wingo: no, i think you need do 'guix system reconfigure the-config.scm'.
<wingo>iyzsong: ok :)
<iyzsong>I mean './pre-inst-env guix system reconfigure' :)
<mark_weaver>wingo: right
<wingo>i guess i need to do that within sudo
<wingo>very interesting that i can do the whole build as root though, and it's just the symlink that fails
<mark_weaver>as root: /path/to/guix-checkout/pre-inst-env guix system reconfigure OS-config.scm
<wingo>the whole build as my user
<wingo>i guess it's the guix daemon doing the build tho
<mark_weaver>wingo: right
<wingo>that's good too
<wingo>what a pleasure :)
<mark_weaver>and the builds are actually done as special unpriviledged build users
<wingo>that's great, works like a charm
<mark_weaver>okay, now you can reboot!
<mark_weaver>with the 'reboot' command as root
<wingo>yeah i did that and all is swell
<mark_weaver>okay, so time to work on 'linux' then!
<wingo>i'm trying to figure out if hidpi is something i need to enable, or if it's something else
<mark_weaver>so first, I would make a private branch for yourself
<mark_weaver>and switch to it
<mark_weaver>and then edit gnu/packages/linux.scm
<mark_weaver>find the definition of 'linux-libre' and duplicate it for now (we'll have a better way later)
<mark_weaver>change the variable name to 'linux', and also the 'name' field in the package definition.
<mark_weaver>replace (linux-libre-urls version) with a URL, as a string literal.
<mark_weaver>and change 'version'
<wingo>lemme enable ssh first so i can work from my main emacs setup...
<wingo>but go ahead if you have instructions, i will follow async
<mark_weaver>at the beginning of the 'build-phase' procedure, remove the bit that applies the freedo patch
<mark_weaver>wingo: you want to enable the ssh daemon, so you can log in from another machine?
<wingo>mark_weaver: yes
<wingo>and edit with tramp
<mark_weaver>so, we have (lsh-service) for that
<mark_weaver>see section (Networking Services) in the manual
<mark_weaver>btw, we have both geiser and paredit in guix as well
<mark_weaver>for now, you'll have to reboot after adding 'lsh-service' to your os-config, I think.
<mark_weaver>obviously we intend to improve that
<mark_weaver>section 6.2.1 (Using the Configuration System) has an example OS config with lsh-service in it.
***boegel is now known as boegel|afk
<wingo>the documentation for lsh-service makes me wonder
<wingo>is it secure out of the box or do i need to do something?
<mark_weaver>I confess I've never used it. what security issue are you thinking of?
<mark_weaver>civodul: can you help answer this?
<wingo>for example, will it create a properly random host key
<wingo>why on earth is it talking about allowing the user to initialize randomness
<wingo>i guess those two are the important questions
<mark_weaver>I seem to recall that lsh stores a random seed that persists across reboots.
<mark_weaver>I guess it's talking about that
<mark_weaver>anyway, it looks like if you pass #:initialize #t that it will take care of it.
<wingo>i do want to help out and such :)
<mark_weaver>I'm not sure why #f is the default. we'd have to ask civodul
<wingo>but i note that as a newb it's all quite confusing
<wingo>and it seems that the defaults should just work
<wingo>i.e. a fresh ssh key is generated when the package is installed
<wingo>but it's hard for me as the newb that i am now to know what's going on
<mark_weaver>yeah, I tend to agree that #:initialize #t should be the default
<wingo>maybe it means that lsh simply won't run until lsh-make-seed is run?
<mark_weaver>dunno, one would hope. but also, it looks like without #:initialize #t, the host key won't be generated either
<mark_weaver>so I would guess (hope?) that lshd would not successfully launch without these things.
<wingo>indeed, lsh just doesn't run until lsh-make-seed is run
<wingo>that's fine i guess
<wingo>w.t.f. "could not create lock file" in ~/.lsh
<wingo>also wtf that i have to type to get entropy
<davexunit>I found that weird, too
<ijp>ideally, you'd wait, and the entropy would just increase itself
<davexunit>iirc it specifically asks you to type
<wingo>like it seems i have to create ~/.lsh
<wingo>what is that about
<davexunit>bad lsh?
<mark_weaver>feedback for niels
*mark_weaver is now limited to one-handed typing for a bit
<wingo>and now "lsh localhost" fails because there is no ~/.lsh/host-acls
<wingo>this is pants
<davexunit>someone should just make openssh-service
<wingo>prolly so. i'm down for trying new things but this is ridics
*mark_weaver uses openssh, but agree that we should promote the use of fellow gnu programs and give them feedback
*wingo firmly in the "just use /dev/urandom" camp
<civodul>mark_weaver, wingo: yeah maybe #:initialize? #t is a better default
<civodul>the reason it's this way is that initializing can take a bit of time
<civodul>which could seem weird to someone who doesn't know what to expect
<mark_weaver>I don't know about using urandom to generate keys
<wingo>mark_weaver: i haven't generated any key :)
<wingo>this is for lsh as a user
<wingo>i just generated a seed for... for what?
<mark_weaver>but I haven't researched it carefully
<wingo>didn't generate an identity or anything
*civodul uses lshd but OpenSSH for the client
<davexunit>you generated a host key for the server?
<mark_weaver>a seed to generate session keys presumably
<wingo>civodul: how did you install openssh?
<civodul>guix package -i openssh :-)
<civodul>i think?
<mark_weaver>we have openssh, and that's what I use, but no openssh-service (yet)
<civodul>yeah we should add it
<wingo>sudo lsh-make-seed --server failed
<davexunit>yeah, we need a service definition
<wingo>ecause creating /var/spool/lsh failed
<wingo>i guess i need lsh-service
<wingo>i just installed lsh
<civodul>ah right, you need lsh-service for the daemon
<civodul>it does (mkdir-p "/var/spool/lsh")
<civodul>wingo: if you could come up with a bullet list of things that were badly documented, didn't work out of the box, or downright buggy, that would be perfect
***boegel|afk is now known as boegel
<civodul>though i guess a large part of it is in this channel's log :-)
<wingo>civodul: ok :) i will dump them in the log if that's ok then pull them together into a mail :)
***boegel is now known as boegel|afk
<civodul>ok :-)
<wingo>hah, error writing .bashrc :)
<wingo>why on earth would that be
<wingo>true it is 444 but is that for a reason?
*wingo would really like "guix install emacs"
<davexunit>the "skeleton" files are marked readonly
<wingo>but maybe that is just "apt-get" in my fingers
<davexunit>I think we agreed it should be fixed awhile ago
<wingo>davexunit: why is that? they are mine and in my dir
<davexunit>wingo: I can't remember why they end up that way
<davexunit>but iirc we agreed that the permissions should change.
*wingo notes that "guix help" would be nice, rather than sending me to guix --help
<civodul>yeah, that's really a bug
<civodul>good idea
<davexunit>wingo: the problem with 'guix install' is that guix is broken into many subcommands, thus 'guix package -i'
<wingo>davexunit: that's what tail calls are there for :)
*davexunit doesn't get it
<wingo>when on the guix web site i expect the link on the red banner to be for guix docs
<wingo>and instead i end up having to actually read the main page ;)
<ijp>wingo: how about aliasing to 'gi', then you can install the Joe editor with GI Joe
<wingo>ijp: and show my patriotism at the same time!
<ijp>.oO(does anyone even still use Joe?)
<wingo>also why does ls -l not show dates according to the french revolutionary calendar
<mark_weaver>we could add a 'guix install' command easily enough. but the thing is, we allow installs, removals, and upgrades as single atomic operations.
<mark_weaver>(well, sort of, don't try to run two on the same profile in parallel)
<wingo>mark_weaver: so there is a bit i don't understand. if i install lsh-service, it's not really available and configured then, is it? i have to do something with guix system, no?
<wingo>and when i make a new system do i then have to reboot?
<mark_weaver>wingo: you put 'lsh-service' in the services section of your OS config
<mark_weaver>and yeah, you have to then './pre-inst-env guix system reconfigure OS-config"
<wingo>mark_weaver: once i've reconfigured though i guess i can deco start lsh-service ?
<mark_weaver>and we intend to make dmd pick up the new services and start/restart them automatically, but that's not yet done.
<wingo>ah ok.
<wingo>no prob
<wingo>it happens rarely enough anyway
<mark_weaver>it's actually possible to run arbitrary code within dmd from user space, so it's doable.
<mark_weaver>however, if you make a mistake you risk borking your live system
<mark_weaver>we need to make this all nicer. lots of work to be done on dmd.
<davexunit>would suck to crash PID 1
<mark_weaver>in the meantime, I recommend just rebooting for now
<mark_weaver>regarding the permissions on .bashrc, I believe the issue is that useradd preserves the permissions from the files in the skeleton directory, which in our case is in the immutable store and thus has 444 permissions
<mark_weaver>it's not clear what's the cleanest best solution to this..
<mark_weaver>btw, I recommend setting environment variables in .bash_profile, but *not* in .bashrc
<wingo>i never know which to use
<mark_weaver>the reason is so that you can launch subshells with different environment variables
<mark_weaver>e.g. when running 'guix environment'
<mark_weaver>.bash_profile is read only from login shells.. .bashrc is run from every interactive shell..
<davexunit>yes, that is important
<davexunit>some peopl (myself included) made that mistake and were confused when 'guix environment' didn't seem to work right
<mark_weaver>because their .bashrc would override the environment settings made by 'guix environment'
<davexunit>upon further inspection you'd realized that you were setting $PATH or something
<davexunit>but yeah, I can never remember which bash file is for which purpose.
<wingo>wtf lsh-service
<wingo>it reads 12 bytes from /dev/random
<wingo>then spelunks around /proc to get additional entropy???
<davexunit>haha nice verb choice
<civodul>i think it actually wants keyboard input or something, no?
<wingo>right now when running as lsh-make-seed --server it's not waiting on keyboard input
<wingo>i didn't pass #:initialize? #t
<civodul>ah ok
<mark_weaver>the advantage of this is that it's bringing our attention to problems in lsh, so we can bug niels to fix them
<taylanub>reminds me of
<wingo>also is there any way to list services?
<wingo>deco status is unhelpful
<mark_weaver>deco status dmd
<wingo>i see
<taylanub>what is this deco by the way? (still using Guix on Debian here)
<davexunit>what does just 'deco status' output? maybe it should do the same as 'deco status dmd'
<civodul>yeah 'deco status' should be made equivalent to 'deco status dmd'
<wingo>davexunit: a generic usage message
<mark_weaver>it prints a usage message; one which fails to mention 'deco status dmd'
<davexunit>I see
<davexunit>well there's an easy patch for someone :)
<wingo>and actually just "deco" might as well do something useful
<davexunit>print out subcommands?
<davexunit>and maybe an example or two?
<wingo>for example, yes
<taylanub>(never mind, found )
<wingo>davexunit: or print a test page, ... ;-))
<mark_weaver>dmd definitely needs a lot of work, but I think it will be nice to have an init based on guile
<davexunit>we benefit greatly from that
<wingo>now i wonder why lsh-make-seed --server isn't asking for keyboard input
<civodul>hmm weird
<wingo>mark_weaver: what do you do when you want to run something as root?
<mark_weaver>maybe it only asks if /dev/random blocks? (total guess)
<wingo>do you use installed guix or run from the ~/src/guix dir?
<wingo>~mhw/src/guix rather
<wingo>and if you use installed guix, does that mean you use different package versions for root?
<mark_weaver>wingo: I use the same guix from my git dir
<mark_weaver>with pre-inst-env
<mark_weaver>wingo: yes, that's right. if you use the installed 'guix', you'll get older package versions.
<mark_weaver>the answer for this for normal users is that the installed 'guix' actually uses the result of the last 'guix pull'.
<mark_weaver>so that's how users keep up to date.
<wingo>mark_weaver: so if you want to use strace as root, you do a guix package -i for root?
<mark_weaver>wingo: yes, that's what I do
<wingo>yay there is an strace package
<davexunit>we've got pretty much all the necessities for hacking
<mark_weaver>since we are developers, such tools were high on our list :)
<wingo>ah weird, if you just sudo you keep the user's path, so you might as well install as user...
<mark_weaver>yeah, I personally don't like sudo because I don't like leaving a window open where any process running under my account can get root.
<davexunit>running as root installs to the root user's profile, not the system.
<mark_weaver>so I don't use 'sudo'
<mark_weaver>but this is another eccentricity of mine :)
<mark_weaver>I leave a text console logged in as root and mostly use that for root things
<wingo>it actually read 30 bytes from /dev/random
<wingo>and did nothing with them
<wingo>it tried to read 40 bytes and got 30
<wingo>instead of trying again it carps
<civodul>i don't remember it being this painful/slow
<wingo>what! now i used --sloppy and it did ask me for keystrokes
<mark_weaver>time to add 'openssh-service', and send some problem reports to niels
<civodul>wingo: i just tried "lsh-make-seed -o t" and it asks for keystrokes, and there's a dot printed for every 10 keystrokes or so
<civodul>so you basically need to leave your finger on RET until it completes :-)
<wingo>and now!!! wtf another problem
<wingo>i deco start it; it says it's disabled
<wingo>so deco enable ssh-daemon
<wingo>re-do with sudo, because as user it doesn't work
<wingo>no output, nothing
<wingo>yet ssh to localhost, and nothing
<wingo>deco status ssh-daemon says disabled
<civodul>"enable" is different from "start"
<civodul>so you also need: deco start ssh-daemon
<wingo>civodul: i did that
<wingo>it ended up disabling it because it respawned too fast
<civodul>basically, when a service fails to start after N respawns, it gets into "disabled" state
<wingo>i cat the dmd log and no useful info
<civodul>could you check tty12?
<mark_weaver>look in tty1
<civodul>or /var/log/messages
<wingo>i cat messages and it says "lshd": failed to open /etc/lsh/host-key
<wingo>and that's it
<wingo>of course i will need to make such a key but grumble grumble
<mark_weaver>#:initialize #t should be the default :)
<wingo>try running lsh-keygen --server
<wingo>you get junk on your console
<wingo>like, i thought that's why i passed --server?
<wingo>at least that's what lsh-make-seed means by --server
<mark_weaver>lsh-keygen writes the generated key to stdout
*civodul concerned about wingo doing a dog food overdose already ;-)
<mark_weaver>--server means "Use the server's seed file"
<civodul>it's "lsh-keygen --server | lsh-writekey --server"
<civodul>not particularly intuitive indeed
*wingo just did that now and it printed out "xxxxxx" twice on the console
<wingo>restarted, still nothing :)
<wingo>there is no /etc/lsh directory
<wingo>it expects me to craft it
<wingo>lovely hand-crafted by our mkdir artisans
<mark_weaver>wingo: that's another thing that #:initialize #t would have taken care of.
<wingo>and yet! it placed some keys in /etc/lsh_host_key
<mark_weaver>(mkdir-p (dirname #$host-key))
<wingo>and yet! it placed some keys in and /etc/
<wingo>but it's looking for the key in /etc/lsh/host-key
<wingo>oh dearie me
<mark_weaver>#:initialize #t passes "-o /etc/lsh/host-key" to lsh-writekey
<wingo>wow :)
<mark_weaver>I wonder if the better thing is for our lsh to be configured differently
<civodul>who needs an SSH daemon anyway?
*civodul hides
<mark_weaver>wingo: so the thing is, our 'lsh-service' also passes --host-key=/etc/lsh/host-key to lshd
<wingo>welp, i have an ssh server now, that's nice
<wingo>and avahi just works
<wingo>so all that is good
<mark_weaver>well, more generally, there is a keyword argument to lsh-service that says where the host key lives, defaulting to "/etc/lsh/host-key", and it arranges to pass the necessary arguments when launching the daemon and generating the key
<wingo>mark_weaver: and yet, #:initialize is false by default
<mark_weaver>I think we can all agree that's a bad default :)
<mark_weaver>I'll post a patch to fix that
<wingo>tramp doesn't work; carps about "couldn't find a proper `ls' command"
<wingo>indeed, command not found
<davexunit>wrong $PATH somehow??
<mark_weaver>it might be that when sshing in, .bash_profile is not read, or something.
<wingo>could be
<mark_weaver>I remember similar issues when setting up a build slave for guix, which is itself a guix system.
<wingo>i haven't modified my .bash_profile
<wingo>or .bashrc
<mark_weaver>the ssh daemon just set a standard PATH=/usr/bin:/bin kind of thing
<wingo>that is it
<mark_weaver>(when used to run a command directory, as opposed to running an interactive shell)
<wingo> /bin:/usr/bin
<wingo>mark_weaver: how did you fix it? :)
<mark_weaver>well, on that machine I'm actually running sshd, because it's guix on top of a debian system.
<mark_weaver>as I recall, I configured sshd_config to "PermitUserEnvironment yes" and then set some environment variables in ~/.ssh/??
<mark_weaver>not sure how to do it with lsh
<wingo>i guess for the moment i could just tunnel out with ssh instead of tunneling in
<mark_weaver>I could expedite the addition of 'openssh-service' sometime today
<wingo>well really, no pressure mark
<wingo>you've helped a lot today and i'm really grateful :) i'm sure you have other things to do tho ;)
<mark_weaver>getting new potential guix contributors is a high priority for me :)
<davexunit>yes! we need more folks helping us get rid of warts
<wingo>how does one swap control and caps lock in xfce?
<wingo>or specify shortcuts for changing desktops?
<wingo>ah, window manager -> keyboard for desktops
<mark_weaver>there might be a GUI thing, but I do this: setxkbmap -layout us -option ctrl:nocaps
<wingo>normally there is an xsettings thing for it or something
<mark_weaver>I have ~/.xsession which does that and some other things and then 'exec startxfce4'
<mark_weaver>(remember to put a shebang on top and make it executable)
<wingo>mark_weaver: how do you not get mixed up with system-installed guix?
<wingo>mark_weaver: did you remove guix from your default profile?
<wingo>maybe this is just that i don't have my .bash* foo set up right yet
<mark_weaver>I put ~/bin in my path, and have ~/bin/guix that does exec /home/mhw/guix/pre-inst-env "$@"
<mark_weaver>so I just run 'guix' without the pre-inst-env, and it picks up that one
<mark_weaver>the only issue I'm run into sometimes is if my git checkout is in a strange state and I want to use 'guix' for something.
<wingo>aaah, with control in the right place this laptop is becoming home
<wingo>yeah i wonder, i don't have guile installed on my systems in the default path
<mark_weaver>yeah, I find it intolerable to have caps lock there for even a few minutes...
<wingo>i wonder what it will be like having a guile there
<mark_weaver>there's no requirement that it be there
<mark_weaver>however, it's in %base-packages, so it's a slight pain to remove it from there.
<mark_weaver>but %base-packages is just for convenience; you needn't use it
<wingo>probably better to learn to live with it
<roelj>window 10
<wingo>aah, and i finally have good fonts now
<wingo>you know, the default xfce thing just looks terrible
<mark_weaver>ah yes, after installing font packages you need to run fc-cache -f
<wingo>like the monochrome font is badness
<wingo>mark_weaver: ok
<wingo>but now it is nice
<wingo>so just as a data point, would be nice to include nice fonts in some kind of base set
<wingo>just so the thing looks nice when you first use it :)
<mark_weaver>yeah, we need a better example OS configuration
<mark_weaver>and maybe some more fonts added to the xfce package (which is a meta-package of sorts)
<mark_weaver>I have these fonts: font-dejavu font-gnu-freefont-ttf font-adobe-source-han-sans:cn font-adobe-source-han-sans:jp font-adobe-source-han-sans:kr font-adobe-source-han-sans:tw
<mark_weaver>(the latter ones I added because one of our contributors, iyzsong, has a name with glyphs that's not in the other fonts)
<mark_weaver>his name is actually 宋文武
<mark_weaver>(well, I pasted that through an xterm to a crufty debian squeeze server, not sure if it came through correctly)
<wingo>i see it fine
<wingo>i think?
<wingo>hard to know :)
<wingo>three characters
<mark_weaver>ah, I guess it did, since it's okay at
<mark_weaver>iyzsong was the hero who gave us xfce and thus liberated me from windowmaker :)
<wingo>mark_weaver: sooo
<wingo>if you have time for help regarding linux, i'm interested to hear how that would go
<wingo>i guess make a local branch of guix?
<wingo>great :)
<mark_weaver>yes, that's the first step I think
<mark_weaver>and I wrote some of the steps earlier in the log here
*wingo looks
<wingo>i have local diffs
<wingo>.po files
<wingo>what do i do with those?
<wingo>i would like "guix search" to search for packages
<wingo>maybe that is apt-cache in my fingers tho
<wingo>for some reason the info that i installed is not understanding C-n
<wingo>but it does get C-p
<wingo>and C-f etc
<mark_weaver>guix package -A <regexp>
<wingo>i was using -s
<mark_weaver>or guix package -s <regexp> to output full package descriptions
<wingo>i wondered how to do that
<mark_weaver>not sure about the .po files, civodul?
<mark_weaver>there's also a nice emacs mode which I confess I haven't played with much yet
<mark_weaver>but by all accounts it is very nice
<mark_weaver>you use standalone the 'info' reader?
<mark_weaver>s/standalone the/the standalone/
<mark_weaver>(not sure why I'm making so many typos these days)
<wingo>i use both it and the one in emacs
<wingo>yeah the bug was in standalone "info"
<wingo>though perhaps it's something about my keyboard
<mark_weaver>interesting, I see the same issue with C-n not being recognized.
<civodul>wingo: you can ignore the .po file changes
<civodul>we get po files from the TP
<mark_weaver>civodul: do you periodically commit those changes?
<civodul>i commit updates we receive from the TP
<wingo>mark_weaver: did you have to do anything to make alt be meta?
<civodul>when we get notifications on guix-devel
<mark_weaver>wingo: no
<mark_weaver>well, xev sees it as Alt, but emacs and the other things I use see it as meta I guess, or anyway things work for me.
<wingo>i guess that's working for me for standalone emacs
<wingo>but in the xfce terminal if i run emacs -nw
<wingo>then alt-w gets processed as just w
<civodul>in xterm i can run Zile (Emacs clone) and M-x works
<civodul>but xfce-terminal probably uses GTK+ for input
<wingo>for me it doesn't
<mark_weaver>wingo: I have the same issue with xfce-terminal. I use xterm.
<wingo>ah right!
<wingo>ok :)
<wingo>silly of me to expect a terminal to just work ;-)
<mark_weaver>heh :)
<civodul>indeed, xfce-terminal has that issue for me too
<mark_weaver>I have a number of settings in my .Xresources for xterm, which I remember being important.
<mark_weaver>(and I run "xrdb .Xresources" from my .xsession)
<mark_weaver>here's what I have for XTerm resources:
<mark_weaver>the defaults are not good for running emacs
<mark_weaver>as I recall, the default sends C-h for backspace and thus C-h doesn't work from emacs, among other things.
<mark_weaver>it's good to have new users remind me of the things that don't work out of the box, but that I patched up long ago and forgot about
*mark_weaver files some bug reports
*civodul found re meta/alt but fails to make sense out of it
<wingo>i guess we could have gnome-terminal already
<wingo>it looks like we have all the packages
*wingo gives that a go
<mark_weaver>yeah, it might be fairly easy. the only question is how much it depends on dbus services started by gnome-session
*mark_weaver needs to learn more about GNOME
<mark_weaver>I would certainly prefer GNOME terminal
<wingo>well in debian it doesn't depend on gnome-settings-daemon or anything, it seems
<civodul>iyzsong: any idea regarding alt vs. meta in xfce-terminal?
*civodul tries just in case :-)
<mark_weaver>wingo: btw, now that you have an updated guix, you should run "./pre-inst-env package -u" to update the packages in your local profile, e.g. git, to the latest versions.
<mark_weaver>(and using the latest libraries, e.g. openssl fixes)
<wingo>mark_weaver: will do
<wingo>mark_weaver: that didn't do anything, maybe i was already up to date
<mark_weaver>oops, I meant "./pre-inst-env guix package -u", is that what you did?
<wingo>mark_weaver: yes
<mark_weaver>okay, I guess you were already up-to-date then!
<mark_weaver>you ran that as your normal user, right?
<wingo>mark_weaver: yes
<wingo>but now that i do a "guix environment guix" it's downloading stuff
<wingo>maybe that's because the last "guix environment guix" i did was using the outer guix
<mark_weaver>wingo: right, before it was downloading older software from 0.8.1
<mark_weaver>and actually, because of the large gap between 0.8.1 and now, I would recommend rerunning ./configure --localstatedir=/var --with-libgcrypt-prefix=$(guix build libgcrypt | head -1) and make
<mark_weaver>it will pick up a different libgcrypt this time
<mark_weaver>most of the time, 'guix environment guix' should be much faster, once you have everything it needs in /gnu/store
<mark_weaver>at some point, it might make more sense to just install all the packages you need to build guix and guile from git in your personal profile.
<mark_weaver>that's how I do it, although it took a few iterations to install everything I needed. surely there's a better way.
<mark_weaver>btw, for a compiler toolchain, you should install 'gcc-toolchain' instead of 'gcc', 'binutils', and 'glibc' separately.
<mark_weaver>the main reason is that 'gcc-toolchain' also includes something called 'ld-wrapper' that arranges to embed rpaths when linking so that the built things can find the libraries they need.
<wingo>this is neat :)
<mark_weaver>obviously there are tradeoffs involved here, but the big win is that rollbacks are quite reliable
<wingo>so the only missing build-dep is libuuid
<wingo>is that in e2fsprogs?
*wingo looks
<mark_weaver>wingo: it's in util-linux
<wingo>mark_weaver: thanks!
<wingo>should i make (gnu packages gnome) import (gnu packages linux) ?
<mark_weaver>guix package -A helpfully tells you where the package is defined
<wingo>oh hey there's a package
<wingo>this guix thing is great
<mark_weaver>so, when building a new package for the first time, I recommend running ./pre-inst-env guix build -K <package-name>
<mark_weaver>the -K means to keep the build directory if the build fails
<wingo>i am using guix build without k
<wingo>ah great
<mark_weaver>it will be in /tmp/nix-*
<mark_weaver>btw, *never* delete anything from /gnu/store manually
<wingo>aye aye capn
<mark_weaver>you can use 'guix gc -d /gnu/store/...' to ask it to delete specific directories, which will make sure there are no references to it and update the sqlite database accordingly
<mark_weaver>and don't mutate anything in /gnu/store either :)
<wingo>i have no temptation :)
<wingo>there was a utility that the 3.14 version used that was unpackaged, so i upgraded to 3.16
<wingo>so i had to upgrade vte too
<wingo>but that seemed to go well
<wingo>mark_weaver: what should delete files in /tmp/nix-build-*?
<mark_weaver>you can just do that as root
<mark_weaver>with rm -rf
<wingo>marvellous, i have a gnome-terminal
<wingo>humm :)
<wingo>doesn't run due to lacking dbus things
<mark_weaver>ah, as I feared
<wingo>it runs at the console but probably wants to activate an instance of a service
<wingo>do i need an explicit dbus dependency?
<mark_weaver>startxfce4 launches a user dbus, but I don't know much about dbus
<mark_weaver>iyzsong: can you offer any clues?
<mark_weaver>wingo: there might be issues with where dbus looks for service definitions
<wingo>that's what i was thinking
<mark_weaver>notice in our OS configuration, we need to pass dbus-service a list of packages to get service files from
<mark_weaver>I'm not sure how this is supposed to work for the per-user dbus
<wingo>i guess it should do something with the .guix-profile...
<mark_weaver>yeah, makes sense
<mark_weaver>this is a good example of the kind of difficulty we face with some packages, which are designed around the idea of a system-wide directory that other packages put files into
<mark_weaver>wingo: can you find out the details of what it's trying to do? maybe with strace?
<wingo>symptoms are much like
<wingo>same error
<wingo>bah, not a real fix
<wingo>is there any equivalent of ~/.xsession-errors
<mark_weaver>there's ~/.xfce4-session.verbose-log
<mark_weaver>not sure if it's the same or not
<wingo>does not seem the same
<wingo>anyway it seems signal 5 is sigtrap
<mark_weaver>at one point I tried redirecting the output of startxfce4 to .xsession-errors, and found that it had almost nothing, because xfce4 was already directing stuff to its own log
<wingo>something is making an error but i don't know where the error is going
<mark_weaver>I've found that daemons run by dmd tend to output stuff to tty1
<mark_weaver>but that's system-wide stuff, not the user dbus
<wingo>nothing there
<wingo>could it be that the dbus session process is running somewhere there is no DISPLAY, i wonder...
<wingo>could be anything really :/
*mark_weaver digs into startxfce4
<wingo>could it be that XDG_DATA_DIRS should really point to somewhere in the path?
<wingo>er, i mean into the profile
<mark_weaver>ah, it's redirecting the output of xfce4-session to /dev/null :-(
<mark_weaver>oh, no it's not.. sorry
<wingo>booooooooo :)
<mark_weaver>false alarm
<wingo>ok :)
<mark_weaver>but it's probably just going to whereever startxfce4 is outputting
<wingo>anyway, it seems XDG_DATA_DIRS is the thing
<wingo>it can't find the service files
<mark_weaver>so I'd try launching startxfce4 from .xsession with output redirected somewhere
<mark_weaver>back in a couple of minutes...
<mark_weaver>wingo: ah, so you might need a wrapper
<mark_weaver>we have a tool for that, 'wrap-program'. search in gnu/packages/*.scm for examples
<wingo>doesn't work
<wingo>or at least, setting the env var and running the program doesn't work
<wingo>probably because the env var applies to the dbus process
<mark_weaver>ah, could be
<mark_weaver>iyzsong is one of our more knowledgable contributors about these issues
<mark_weaver>iyzsong: can you help?
<mark_weaver>I guess it's the middle of the night where he lives though
<mark_weaver>wingo: if your theory is correct, for now it might be sufficient to set XDG_DATA_DIRS to include $HOME/.guix-profile/share before launching startxfce4
<mark_weaver>(assuming that gnome-terminal is in your user profile)
<mark_weaver>it may be that we should modify our xfce to add that automatically.
<wingo>i will try
<davexunit>getting guixsd to work nicely generally involves tweaking all sorts of load paths
<wingo>without editing /gnu/store :)
<wingo>how do i start x from the console?
<mark_weaver>I also see that if DBUS_SESSION_BUS_ADDRESS is set, startxfce4 will just use that instead of starting a new one
<wingo>with the extra environment variable
<mark_weaver>a new session dbus, that is
<mark_weaver>wingo: well, first of all, SLIM runs ~/.xsession if it exists, so you can do things from there
<mark_weaver>startxfce4 will also run xinit if DISPLAY is not set
<wingo>interestingly from the console i have an XDG_DATA_DIRS
<mark_weaver>but you probably need to have xinit installed in your path to do that
<wingo>which points to my ~/.share
<wingo>or the .share from my profile
<wingo>but this is not the case in x
<mark_weaver>wingo: ah right, that's set from /etc/profile
<mark_weaver>hmm, I wonder where it gets cleared
<wingo>i take that back
<mark_weaver>maybe one of the wrappers sets it, dumping the old value
<wingo>now i do see ~/.guix-profile/share in my XDG_DATA_DIRS
<wingo>as should you
<mark_weaver>oh yes, I see it there too
<mark_weaver>wingo: so you installed gnome-terminal in your user profile? (guix package -i gnome-terminal) ?
<wingo>and i see an org.gnome.Terminal.service
<wingo>mark_weaver: yes
<wingo>i actually don't know how to install to the system profile :P
<mark_weaver>wingo: installing in the system profile requires adding it to the packages field of your OS config and running 'guix system reconfigure <osconfig>"
<wingo>i see the error now
<wingo>looking at the service file i see the thing that is being run
<wingo>now i see that it's trapping after not finding the schema for org.gnome.system.proxy
<wingo>which it seems to look for in all the XDG_DATA_DIRS with the suffix glib-2.0/schemas/gschemas.compiled
<wingo>so maybe there is some post-compiling thing that is not being run
<mark_weaver>ah, which build-system did you use for your package?
<wingo>copy/pasted from gnome-mines
<mark_weaver>ah, okay.
<mark_weaver>glib-or-gtk-build-system then
<wingo>if i install gsettings-desktop-schemas into my user profile
<wingo>then i get farther
<wingo>as that package does provide a gschemas.compiled file
<wingo>but then it errors on org.gnome.Terminal.Legacy,Settings schema is not installed
<wingo>which says to me that it is finding compiled schemas from one package before finding the schemas from gnome-terminal
<mark_weaver>does it only use the first gschemas.compiled that it finds in XDG_DATA_DIRS ?
<mark_weaver>in some cases, we need to do special actions to merge files from several packages together when we build a profile, for example share/info/dir
<mark_weaver>I wonder if we need to do something like that here too
<mark_weaver>it is sometimes helpful to look into how NixOS handled the same issue
<wingo>glib-compile-schemas apparently is the thing...
<wingo>will do
<mark_weaver>wingo: searching for glib-compile-schemas in gnu/packages/*.scm, I see several references to it.
<mark_weaver>is ("glib" ,glib "bin") in your native-inputs ?
*wingo looks
<mark_weaver>is there a gschemas.compiled file in your gnome-terminal package output?
<wingo>glib bin is in the native-inputs
<wingo>i don't know about the outputs; how can i tell?
<mark_weaver>'guix build' prints the name of the output directory(s)
<wingo>ooh there are docs mentioning compile-schemas
<mark_weaver>or you can find it by looking at "ls -l $(which gnome-terminal)"
<mark_weaver>and then looking in that directory in /gnu/store
<mark_weaver>wingo: I see that 'glib-or-gtk-build-system' has a phase called 'compile-glib-schemas'
<mark_weaver>see guix/build/glib-or-gtk-build-system.scm
<wingo>there is a gschemas.compiled in the output
<mark_weaver>so, it should be running 'glib-compile-schemas /gnu/store/.../share/glib-2.0/schemas after make install
<wingo>yes i would think so
<wingo>given that there is a compiled schemas file there
<mark_weaver>so it's just not finding it for some reason.
<mark_weaver>then there's the 'wrap-all-programs' phase in the same file
<wingo>i am going to have to knock off
<wingo>has been a long day :)
<mark_weaver>okay, thanks for the hacking!
<wingo>thank you again for the help mark; happy hacking!
<mark_weaver>can you send me what you have so far?
<wingo>if ssh works
<mark_weaver>openssh client works fine for me, no issues
<wingo>but mdns not working
<mark_weaver>yeah, that requires some extra configuration currently, a slight pain
<mark_weaver>if you install icecat you could just paste it somewhere
<mark_weaver>or copy it off via USB stick or something
<wingo>thank you!
<Sleep_Walker>chm, I get missing gnutls again
<Sleep_Walker>;;; Failed to autoload make-session in (gnutls):
<Sleep_Walker>can I miss something in my environment? what is proper way to initialize _everything_?
<civodul>normally just "guix package -i gnutls" and then set GUILE_LOAD_PATH as it says
<civodul>but are you seeing a hard error or a warning?
<Sleep_Walker>I'm still in chroot
<bavier>does anyone here have any comment on the "happy bunny" license that GLM (guix package --show=glm) is licensed under?
<mark_weaver>bavier: happy bunny license? it says expat in the package definition
<bavier>mark_weaver: need to look in the license file
<bavier>sorry, copying.txt
<civodul>"By making use of the Software for military purposes, you choose to make a Bunny unhappy."
<bavier>I suppose the license is disjunctive
<civodul>yes, it's a choice
<jxself>Bunny can be as unhappy as they want as long as they don't limit freedom 0.
<civodul>i guess they wanted to take an anti-militarian stance, yet keep the software free
<civodul>hence this no-op statement about the bunny
*taylanub is amused
<bavier>yes, but the ambiguity is still unsettling
<civodul>well, it's doubly a no-op because one can choose the Expat license anyway
<taylanub>bavier: I don't think any court would take that serious :P by the way says one can choose the expat license as well.
<bavier>taylanub: right, I think the last I looked, previous version maybe, the text said "happy bunny license *and* expat"
<civodul>the one we have says: "GLM can be distributed and/or modified under the terms of either a) The Happy Bunny License, or b) the MIT License."
<civodul>but i think even the Happy Bunny License would qualify as free, as jxself notes :-)
<bavier>ah, yes, the version had a conjunctive license, btw
<bavier>thanks for the comments