IRC channel logs

<davexunit>so the /dev node that I installed to seems to not correspond to the /dev node that initrd should attempt to mount

<davexunit>I installed to /dev/sda1, but initrd throws an exception that there is nothing there.

<jxself>Hmm.

<davexunit>I want to figure out a guile code snippet that I can use to test with /dev node is the right one

<davexunit>s/with/which/

<davexunit>but right now... indian food time.

<mark_weaver>davexunit: I think you should use volume labels

<mark_weaver>anyway, enjoy the food :)

<davexunit>mark_weaver: yeah, that is what I will do, doing that is just foreign to me. another thing to learn.

<mark_weaver>very simple: e2label /dev/sda1 dave-root

<mark_weaver>and then put "dave-root" in place of "/dev/sda1" in the operating system decl.

<mark_weaver>(or whatever label you choose :)

<mark_weaver>hmm, I wonder if there's a reason we haven't upgraded to gcc-4.9.1, given that it's not the default compiler anyway.

<davexunit>mark_weaver: thank you!

<davexunit>grrr why doesn't my device label work

<davexunit>`e2label /dev/sda1` outputs the correct label

<davexunit>a-ha, I *think* I found the issue.

<davexunit>nope.

<davexunit>(disk-partitions) returns the empty list

<davexunit>I don't understand :(

<davexunit>/proc/partitions is empty... I thought we were past the ahci issues.

<davexunit>gah, I know. bitten by guix 0.6 again. that version doesn't load the ahci modules by default.

<davexunit>I keeping that the version of guix on the disk image is the version of guix that will be installe.d

<civodul>Hello Guix!

<phant0mas>good morning

<phant0mas>for some reason, while I have included flex, the configure script of avrdude cannot find it

<civodul>what does config.log say?

<phant0mas>hello ludo

<phant0mas>configure:4181: checking for flex

<phant0mas>configure:4211: result: no

<phant0mas>and I have flex as a native input

<phant0mas>fixxed it

<civodul>ok :-)

<civodul>our 'man-pages' package does not (no longer has?) section 2 pages

<civodul>any idea why?

<mark_weaver>hmm, for some reason the slim service stopped working for me at some point...

<mark_weaver>though the X server seems to have been started and exited without any error.

<mark_weaver>is there a way to add extra kernel command-line arguments to an operating-system definition?

<civodul>howdy mark_weaver

<civodul>hmm

<civodul>mark_weaver: no, kernel arguments cannot be added currently, see operating-system-grub.cfg

<civodul>but yeah, we must make it possible

<civodul>mark_weaver: how did slim stop working exactly?

<mark_weaver>civodul: well, I just see several messages on the console about the slim service being respawned too fast, and then it gives up. sorry, not much detail yet.

<civodul>could you try "deco enable xorg-server && deco start xorg-server"?

<mark_weaver>ah, I see the error: /dev/fb0, no such file or directory

<mark_weaver>except that it's there

<mark_weaver>oh, wait, this is an old Xorg.0.log

<mark_weaver>civodul: when I do that, I again see entries in the dmd.log about starting the X server and then respawning repeatedly until it gives up.

<mark_weaver>civodul: but there's no recent Xorg.0.log file

<civodul>hmm

<mark_weaver>I see nothing recent in /var/log except for dmd.log

<civodul>could you find dmd.conf, and run the same command manually?

<mark_weaver>civodul: how do I find the correct version of dmd.conf?

<mark_weaver>oh, nevermind, got it.

<mark_weaver>civodul: the error is: ..../slim: invalid option -- '-'

<mark_weaver>maybe it doesn't like the --nodaemon option

<mark_weaver>but if I remove that option, it seems to do nothing at all.

<civodul>hm?

<civodul>that's weird

<civodul>if i build demo-os.scm, it definitely has a working slim

<civodul>oh but -nodaemon isn't in slim(1)

<civodul>damn

<civodul>where did i get it from? :-)

<civodul>oh yes, app.cpp in slim does handle -nodaemon

<civodul>will be back later

<taylanub>can anyone check http://www.libpng.org/pub/png/png-gammatest.html with our IceCat? if color rendering is broken, some boxes will have thick borders in a different shade of the same color, like the topmost example

<atheia>I'm installing guix IceCat now and will test as soon as I've got it.

<taylanub>thanks :)

<atheia>I'm getting some visible borders in the lower rest for both cases.

<atheia>colors:

<atheia>cc99ff cc99cc for sRGB PNG and iCCP PNG images

<atheia>cc9900, faintly for sRGB

<atheia>cc9900 cc9933 cc9966 too faintly for iCCP

<atheia>Hope this helps.

<taylanub>thanks, that seems to correspond to what I also had; some users of Firefox on GNU/Linux systems reported all colors looking fine so this is either in IceCat or precisely our build of IceCat, I'll try to look into it

<jxself>I looked at it, and it's just fine.

<taylanub>jxself: with IceCat from guix?

<jxself>Nope, with the brand spanking new and unreleased IceCat 30 from Trisquel.

<jxself>Helps to show that it's not with IceCat itself though?

<jxself>Since quidam has taken over maintaining IceCat.

<taylanub>I guess so, guess I'll ask around in #parabola and #trisquel and such

<atheia>hmm, I'm getting the same results using Debian Jessie's Iceweasel though.

<atheia>So perhaps local config?

<atheia>(Iceweasel 30)

<taylanub>hrmm, OK. could be about some installed shared libs or some color management daemon or something I guess (I imagine some fancy DEs might be running such a daemon)

<taylanub>anyway, heading home, AFK for a while

<civodul>davexunit: thanks the perfect replies to Adam :-)

<civodul>so the kernel panic you had was due to the missing modules, right?

<mark_weaver>civodul: my problem with slim turned out to be a stale /var/run/slim.lock lying around from a previous crash

<mark_weaver>/var/run needs to be cleared out at boot time, I think.

<civodul>ahh yes, good point

<civodul>is it safe to just rm -rf /var/run/* ?

<civodul>actually the spine needs to remain there

<civodul>hm

<mark_weaver>right, any subdirs need to remain. hmm.

<civodul>for now i'll just rm that file specifically in the slim service

<civodul>seems safer

<mark_weaver>okay

<mark_weaver>does slim load any files in the user's home directory? like .xsessionrc or something? I forget.

<mark_weaver>I want to initialize environment variables and run xmodmap

<civodul>unfortunately no

<civodul>see 'xinitrc' in services/xorg.scm

<davexunit>civodul: yw! and yes, that was why the kernel panic occurred.

<mark_weaver>hmm. on debian at least, the display managers arrange to load a per-user file. it might be done from the system-level session file.

<davexunit>it's just counter-intuitive to me that the guix on the install image is not the same as the guix that is installed.

<civodul>mark_weaver: yes i know, but i haven't taken the time to do it yet

<mark_weaver>okay

<civodul>davexunit: it definitely is ;-)

<mark_weaver>it's amazing how much nicer everything looks in the X session after installing ttf-dejavu

*davexunit needs to get xorg up and running on his x60s

<davexunit>mark_weaver: after installation, do you compile the latest guix and run `./pre-inst-env guix system reconfigure` or something?

<mark_weaver>davexunit: exactly

<civodul>you could run "guix pull" and then reconfigure, it should be equivalent

<mark_weaver>guix pull didn't work for me, and also I'm not going to do that until guix pull is authenticated somehow.

<civodul>git isn't authenticated either

<civodul>that's the whole problem

<civodul>i think we want to (1) rewrite "guix pull" to use git, and (2) sign each commit

<civodul>but i'm not sure about the implications of (2)

<mark_weaver>sounds good to me

<mark_weaver>hmm, librejs seems to be blocking the proper use of hydra.gnu.org, and when I ask to pop up the window from the librejs icon in the bottom right corner, the window is empty.

<davexunit>yeah, hydra doesn't have the proper metadata for librejs to validate that it's free

<davexunit>on my list of things to fix. I've done a good amount of librejs fixes like this at the FSF.

<civodul>oh cool

<mark_weaver>oh, or maybe it's requestpolicy that's blocking things..

<jmd>davexunit: I'm glad of that.

<mark_weaver>"allow requests from gnu.org to ajax.googleapis.com" :-(

<davexunit>getting mediawiki librejs compliant is one of my projects, that will be tough.

<jmd>I discovered that if you turn off history in Firefox, librejs doesn't block anything.

<jmd>civodul: Did you have any more comments on the untested-gzip patch?

<mark_weaver>gcc-4.9.1 is still broken on mips. oh well

<davexunit>librejs leaves much to be desired in the usability department.

<davexunit>but I recognize that it's a hard problem.

<jmd>We should invent a replacement for javascript, based on scheme.

<mark_weaver>yes, librejs is blocking some of the code on hydra.gnu.org

<davexunit>jmd: that would take a decade or more to distribute amongst internet users.

<jmd>*shrug* it took a couple of decades for gcc to become prevelant.

<mark_weaver>gccgo fails to build on all platforms with an interesting error about finding a cycle in the dependency graph.

<mark_weaver>"cycle detected in the references of `/gnu/store/*-gccgo-4.8.3-lib'

<mark_weaver>hmm, I wonder if this happened when -lib was split off in the gcc builds

<mark_weaver>heh, on hydra, 'strace' builds properly on MIPS but not on the intel platforms.

<mark_weaver>that's unusual :)

<davexunit>heh

<mark_weaver>okay, hydra is in pretty good shape now. after clicking literally hundreds of buttons to restart things, I think we have substitutes for just about everything that's not really broken, even on MIPS.

*Mathnerd314 keeps confusing mark_weaver with Marc Weber

<davexunit>how I get SSL certs to work in guix?

<davexunit>trying to run ./bootstrap and build guix

<civodul>davexunit: you mean when getting things from github.com?

<civodul>there's the possibility of doing "export GIT_SSL_NO_VERIFY=true"

<mark_weaver>davexunit: we don't yet have a package with SSL CA certificates. you can copy /etc/ssl from a debian box, and then set some environment variables

<mark_weaver>SSL_CERT_FILE="/etc/ssl/certs/ca-certificates.crt"

<mark_weaver>SSL_CERT_DIR="/etc/ssl/certs"

<mark_weaver>GIT_SSL_CAINFO="/etc/ssl/certs/ca-certificates.crt"

<mark_weaver>and I think wget needs a config file

<mark_weaver>on my own system I have gnutls patched to make things a bit easier, but that's not in guix git yet.

<davexunit>mark_weaver, civodul: thanks

<civodul>seems like we're all set for this release

<davexunit>releasing tomorrow?

<civodul>yes, sounds like a plan

<civodul>preparing everything tonight so it can be done easily tomorrow morning

<Steap>Is there a way to do https-get easily in Guix ? I'd need to do a REST request

<civodul>Steap: quite easily, using GnuTLS

<civodul>see guix/download.scm

<civodul>well, guix/build/download.scm

<mark_weaver>it would be good to change the group ids to lower numbers before the release, so they don't get persistently hardcoded into people's installs.

<mark_weaver>maybe we should just add --system to the groupadd calls during activation.

<mark_weaver>and also to change the hardcoded tty group number to a smaller number

<civodul>oh, right

<civodul>--system would give us lower numbers, right?

<mark_weaver>right

<Steap>Well, I'm trying to use http-fetch, but I get "ERROR: In procedure memoize-variable-access!:

<Steap>ERROR: Unbound variable: http-fetch

<Steap>"

<Steap>even though I use the guix/build/download module

<civodul>this module only exports 'url-fetch'

<civodul>see #:export at the top

<Steap>oh, ofc

<davexunit>trying to figure out how to get an ssh server running...

<davexunit>I guess I need to write a dmd service

<Steap>Is hydra down or anything ?

<Steap>I keep compiling everything

<jxself>Hydra often seems to have problems...

<mark_weaver>it's been working for me lately

<civodul>davexunit: there's lsh-service

<davexunit>civodul: okay, now how to start that up...

<davexunit>reading through the dmd manual

<mark_weaver>there's also a section of the guix manual about writing services

<davexunit>okay

<davexunit>hmm, guix modules aren't in guile's load path by default.

<Steap>;;; Failed to autoload make-session in (gnutls):

<Steap>;;; ERROR: missing interface for module (gnutls)

<Steap>Damn, I've just installed gnutls

<civodul>davexunit: just add it to the 'services' part of the configuration

<mark_weaver>well, you could add the service to your operating-system configuration and then run 'guix system reconfigure'

<davexunit>I'll try, but I remember reconfigure failing with the guix that was installed. I was hoping to upgrade before that.

<mark_weaver>yes, there were problems with reconfigure. I built guix from git within the standalone guix system, and then was able to reconfigure

<davexunit>I was trying to copy my /etc/ssl via ssh, but I'll just go find a flash drive and make this easier.

<mark_weaver>davexunit: FYI, I had to manually load the nls_iso8859_1 module to mount my flash drive. YMMV of course

<mark_weaver>I suspect that something in broken w.r.t. module autoloading.

<civodul>yes, that part is weird

<davexunit>I realize how much I take for granted on other GNU/Linux systems :)

<Steap>why is gnutls in ~//.guix-profile/share/guile/site rather than ~/.guix-profile/share/guile/site/2.0 ?

<civodul>Steap: probably a bug

<civodul>is it really the case

<civodul>?

<Steap>well it looks like it

<Steap>if I add .../site in GUILE_LOAD_PATH, I get no more complaints

<civodul>yes, ok

<civodul>could you file it?

<civodul>we'll fix it probably after the releas

<civodul>+e

<Steap>k

<Steap>how the fuck do we use the BTS again ? :p

<civodul>just email bug-guix@gnu.org

<tadni`>civodul: Wait, so is ratpoison now the default session?

IRC channel logs

2014-07-24.log