IRC channel logs


back to list of logs

*davexunit thinks about how to package generic r6rs scheme libraries for guile
<davexunit>mark_weaver: I happened to see your OS config on
<davexunit>it's really nice!
<davexunit>I like how easy guix makes it to define your own unique services
*davexunit struggles to get httpd to run
<wingo>any reason not to upgrade the linux-libre headers along with linux-libre?
<wingo>whee, i have a libepoxy package too
<wingo>yay gtk+ 3.16.0
<wingo>ok, just colord, gweather, geoclue needed for gnome-settings-daemon
*wingo built colord package and service, now to see if colord service works...
<davexunit>good morning, guix
<davexunit>poking at mesa a bit. can't seem to figure out why it doesn't build
<davexunit>but it does build something called
<mark_weaver>wingo: updating linux-libre-headers entails a full rebuild of everything
<mark_weaver>but yeah, we were talking about updating it to the most recent LTS linux-libre (3.14) in core-updates
<mark_weaver>davexunit: thanks for looking into it!
<mark_weaver>something that changed in my system recently seems to have broken icecat (from my user profile) in a strange way
<mark_weaver>there's a big grey band at the bottom of every window with red text that appears to be showing an error message
<mark_weaver>the error message is this:
<mark_weaver><menuitem id="abp-status-slowcollapse" label="&hideplaceholders.label;" type="checkbox" command="abp-command-togglecollapse"/>
<davexunit>icecat updates keep wiping out my saved tabs and extensions
<mark_weaver>and the next line points up to the "<" (first character) of that line
<davexunit>I don't think I've seen that
<davexunit>I see "abp" in there, which I guess is "ad-block plus"
<mark_weaver>and more troubling, the window doesn't properly resize its contents to the window size
<mark_weaver>well, it tries to, but if the window is too small to fix all my tabs at full size, it just gives up and stops shrinking
<mark_weaver>and in my case, the entire width of my screen is too small
<davexunit>I'll see what my icecat does when I boot my guixsd machine later
<mark_weaver>so I lose the scroll bar and many of my toolbar icons on the right
<mark_weaver>if I boot into some versions of my system, this icecat in my user profile works properly. boot into other systems and it fails in this strange way.
<davexunit>I need to look at icecat anyway, webgl has never worked in it.
<mark_weaver>of course, it shouldn't be sensitive to anything in my system profile anyway
<davexunit>yeah, that's strange.
<mark_weaver>I'm updating my user profile now to see if that fixes it...
<mark_weaver>well, that did indeed fix it.
<mark_weaver>unsettling though
*davexunit sees 4 patches from wingo come in
<mark_weaver>yeah! exciting work from wingo. I feel us getting closer to having GNOME with every patch :)
*mark_weaver looks at the emails more closely...
<davexunit>if GDM is the only thing blocked by systemd, we can just use slim in the meantime
<davexunit>and still enjoy our gnome shell
<mark_weaver>does GDM really have a hard requirement on systemd?
<mark_weaver>I thought I remember the GNOME folks saying that some things might not work quite right without systemd, but that it would still work, but maybe I'm out-of-date.
<davexunit>I don't know the specifics
<davexunit>just heard that there was some dependence there. perhaps easily worked around.
<davexunit>mark_weaver: after seeing your OS config, and now wingo's upower email, about expanding out %base-services, I feel like maybe we could write a procedure that generates the base services list with a few keyword args to tweak the result
<davexunit>motd, dbus stuff, etc.
<davexunit>so that common changes don't require a copy/paste of everything in %base-services
<iyzsong>I wonder whether we can use the customization system of Emacs to generate a os-config.scm for GuixSD ;-)
<davexunit>an OS config builder for guix-web would be cool, too.
<davexunit>that would be a task for when we want to tackle usability for non-hackers
<mark_weaver>davexunit: I think the idea we had is that services should be able to declare what things should be added to the default 'udev-service', 'dbus-service', etc.
<mark_weaver>obviously this would entail some different handling of %base-services
<davexunit>ah I see
<davexunit>that works, too
<davexunit>just like services can declare users and groups
<davexunit>(which I just learned from wingo's patch
<davexunit>I'm trying to write services for nginx and httpd but have failed thus far
<mark_weaver>wingo: I just pushed your glib and cairo updates to the 'glib-rebuild' branch, and started hydra building it.
<davexunit>I wonder how much snappier guix runs on guile master. has anyone tried?
<mark_weaver>wingo: in your upower patch, you need to add the patch to dist_patch_DATA in
<davexunit>ah, good catch! forgot about that
<mark_weaver>davexunit: what difficulties are you running into?
<iyzsong>mark_weaver: Hi, I have a glib patch to add a search-path-specification here,
<davexunit>mark_weaver: in the case of nginx, it tries to call mkdir within /gnu/store
<mark_weaver>iyzsong: oh, maybe we should include that in the glib-rebuild branch ASAP!
<davexunit>and I haven't been able to get it to not do that
<mark_weaver>davexunit: on Hydra, which uses nginx from guix, I had to specify the location of the log files iirc
<mark_weaver>it may be that the package itself should be tweaked somehow to make that nicer
<davexunit>I specified the error log and access log, but...
<iyzsong>mark_weaver: done!
<davexunit>mkdir() "/gnu/store/cqgb5apnyn5jmki7xj90d45q8cmwjj6p-nginx-1.6.2/client_body_temp" failed (13: Permission denied)
<davexunit>I haven't looked into this yet
<davexunit>I just moved onto something else for now.
<davexunit>trying my hand at a postgresql service
<mark_weaver>iyzsong: thanks!
<mark_weaver>davexunit: ah, right, this sounds familiar
<davexunit>oh? cool. maybe I can get past it then
<mark_weaver>davexunit: the answers are to be found in hydra's nginx config
<mark_weaver>time to boot up my Yeeloong, which is the only machine I have with the keys needed to log into hydra
<davexunit>is that file available somewhere I can read it?
<davexunit>oh okay
<davexunit>I'm going to go afk for a bit, I'll check it out when I get back.
<mark_weaver>davexunit: when running nginx, I had to pass "-p /var/lib/nginx" to nginx
<mark_weaver>and I had to populate that directory iirc
<mark_weaver>the "-p" option specifies the "prefix path"
<mark_weaver>I also ended up making /var/lib/nginx/logs a symlink to /var/log/nginx which is an ugly hack
<mark_weaver>it turns out that even when I specify the location of the log files in nginx.conf to point to /var/log/nginx, it still tried to put log files in <prefix-path>/logs initially. I guess maybe that's to allow errors to be logged before the configuration is read, or something.
<mark_weaver>so, here are some things I put in nginx.conf: "user www-data;" "error_log /var/log/nginx/error.log error;" "pid /var/run/;" "lock_file /var/lock/nginx.lock;"
<mark_weaver>and then in the "http" section, I have this: "include /etc/nginx/mime.types;" "client_body_temp_path /var/lib/nginx/body;" "proxy_temp_path /var/lib/nginx/proxy;" "access_log /var/log/nginx/access.log;"
<mark_weaver>obviously this could all be nicer
<mark_weaver>I also had to add "-c /etc/nginx/nginx.conf" when running the daemon, in addition to the aforementioned -p option
<wingo>tx for the patch review davexunit and mark_weaver
<wingo>unfortunately i have another rebuild-the-world patch coming :(
<wingo>the gettext one
<davexunit>wingo: best to get 'em in now while we're rebuilding the world anyway
<davexunit>mark_weaver: thanks for that
<wingo>i guess :)
<davexunit>mark_weaver: I also noticed that nginx's 'make install' does some gross stuff, it makes the root directories 'conf', 'html', and 'logs'
<davexunit>httpd makes similar offenses
<davexunit>oh cool, a glib-networking patch. I tried and failed to package that close to a year ago, I think.
<mark_weaver>wingo: the gettext one will have to go to core-updates
<wingo>mark_weaver, that means the gtk one should go there too
<wingo>or something
<wingo>dunno :)
<mark_weaver>wingo: ah, right.
<wingo>yeah, bit of a bummer
<mark_weaver>so, I wonder if there's any point to building the glib/cairo updates in a separate branch
<mark_weaver>maybe not
<mark_weaver>the purpose of these updates is to enable something that will also require the gettext update, is that right?
<wingo>i am trying to get gnome-settings-daemon 3.16.0
<wingo>that requires gtk+ 3.16.0
<wingo>which requires a newer glib and cairo
<wingo>and also an xgettext that knows xml
<mark_weaver>I see
<mark_weaver>well, there are a few options here
<mark_weaver>we could have two gettext packages
<mark_weaver>although maybe that's too gross
<wingo>i have bitten the bullet already and am on my own branch
<mark_weaver>maybe we should just push to get core-updates merged into master asap
<wingo>would be nice to work off master but it's not strictly necessary, i can merge in master as needed
<mark_weaver>although core-updates has another change that is requiring some work
<mark_weaver>wingo: yeah, I do the same thing myself
<mark_weaver>although my branch doesn't diverge from master in the core components
<wingo>what's the other change in core-updates needing some work?
*wingo curious
<mark_weaver>wingo: we have a number of packages that produce ELF files with missing rpaths
<mark_weaver>so in core-updates, civodul added a phase after install that checks for those problems
<mark_weaver>and make the builds fail in that case
<wingo>so failing builds precludes any kind of merge :)
<mark_weaver>so now we really have to fix all those problems. see the "Dangling .so references" bugs in
<wingo>glad to see guix is getting some mileage out of that elf parser :)
<davexunit>a lot of mileage
<davexunit>mark_weaver: do you think we should move those nginx root dirs to share/nginx?
<davexunit>it just seems like pollution otherwise
<mark_weaver>davexunit: dunno, I haven't looked closely in a while and have forgotten the details
<davexunit>'ls -la $(guix build nginx)' if you get curious
<mark_weaver>davexunit: but it definitely seems like our nginx package could use some improvements.
<mark_weaver>I confess it was a rush job, to get nginx running on hyrda
<davexunit>it doesn't help that it's build system is a special snowflake
<mark_weaver>heh :)
<mark_weaver>davexunit: oh, you're right. I didn't realize all that stuff was in the root of the output dir
<mark_weaver>davexunit: yes, I think 'conf' and 'html' should go into share/nginx
<davexunit>what about logs? it's an empty dir.
<mark_weaver>I guess the empty 'logs' directory is pointless and should just be inhibited
<davexunit>it looks like the least intrusive fix is a post-install phase
<davexunit>I'll delete logs and move the other two dirs.
<davexunit>and see how that goes
<mark_weaver>thanks for working on it!
<davexunit>just another step on the path to automated web application deployment
<mark_weaver>indeed, and it would be nice to run on GuixSD
<davexunit>the mediagoblin community started this discussion about "userops", which is like "devops", but focusing on making it easy to for users to deploy things, not just software engineering teams.
<davexunit>and I'd like to point people towards guix
<davexunit>and have an example or two to show
<mark_weaver>hopefully we will have a new physical machine for it within the next month or so
<davexunit>oh really? exciting!
<mark_weaver>the main holdup has been choosing hardware that is both fast and can run coreboot without blobs.
<davexunit>yeah, that's tricky
<mark_weaver>I think I finally have a promising candidate motherboard, although we'll have to verify that it runs without blobs.
<mark_weaver>davexunit: the "userops" idea sounds good to me! guix definitely seems well positioned to do it.
<davexunit>it's been hard to get people warmed up to the idea of using guix, though. I think if I had some working example systems it would help a lot.
<mark_weaver>davexunit: it's understandable, given that we haven't yet put much focus on building servers with GuixSD. obviously we need more services, and we probably need a stable branch, an LTS version of linux (3.14), etc.
<davexunit>in due time
<davexunit>but the people I'm talking to are developers, so if I can just give them an idea of what guix is capable of, maybe it would convince some of them to contribute.
<mark_weaver>wingo: what's the status of your gettext patch?
<wingo>mark_weaver, works for me, it builds gtk+
<wingo>it's mostly a reversion of another patch
<wingo>so it seems low-risk to me; best to check with ludo i would imagine
<mark_weaver>wingo: can you paste it?
<wingo>mark_weaver, i mailed it to the list
<wingo>i think
<wingo>just half an hour ago
<mark_weaver>ah yes, thanks!
<wingo>ok i seem to have gotten myself into a situation that guix won't build :(
<wingo>it's an error building the daemon
<wingo>some carp from gcc
<wingo>maybe it's an environment problem...
<mark_weaver>so, one thing that can happen is that you build against one libc, and then you rebuild the world and then you need to link against a new C library
<mark_weaver>so you might need to make clean
<davexunit>mark_weaver: while I'm tweaking nginx, should /sbin be moved to /bin?
<davexunit>seems weird for nginx to be in sbin
<davexunit>the nix recipe moves it
<mark_weaver>(and probably rerun configure as well)
<wingo>mark_weaver, that could be
<mark_weaver>wingo: to sidestep this issue, you could configure with --disable-daemon, since you don't run the daemon from your git checkout anyway on guixsd
<wingo>but gcc is ice'ing
<wingo>i don't know how it got this way :(
<wingo>i don't remember doing anything stupid
<mark_weaver>unfortunately I need to go afk for a long while now...
<mark_weaver>good luck!
<wingo>tx :)
*wingo reboots
*wingo built a new gcc to fix the ICE
<wingo>hopefully this is the bottom of the rabbit-hole!
<wingo>davexunit, does "make check" work for you in guix?
<wingo>i get an error somehow in gnu/packages/sdl.scm
<wingo>that fonts:freetype doesn't exit
<wingo>and indeed that would seem to be the case
*wingo confused
<wingo>i can reproduce the issue via "guix package --search="
<davexunit>wingo: is this for current master?
<wingo>davexunit, yes i think so
<wingo>i am on my branch, but it is very close to master
<wingo>maybe i caused the problem tho...
<wingo>i don't show any changes that could affect this
<davexunit>I use guix's SDL to hack on Sly so I know I've seen it work
<davexunit>wingo: does a particular test fail?
<davexunit>or does the build as a whole fail?
<wingo>"make check" fails
<wingo>one particular test fails
<davexunit>k, running the whole suite for fun
<wingo>and the way it fails is the same way that "guix package --search=" fails
<mark_weaver>wingo: it might be due to a cycle in the module dependency graph
<wingo>mark_weaver, ah.
<mark_weaver>(the fonts:freetype not existing issue)
<wingo>good point.
*wingo checks
<mark_weaver>we have a lot of such cycles, but in most cases its okay because the references are not resolved until later
<mark_weaver>but if A actually executes a reference to a binding from B, and there is a cycle involving A and B in the dependency graph, then there will be trouble depending on which module is loaded first.
<mark_weaver>if A actually executes a reference to a binding from B at module load time, I mean.
<mark_weaver>the 'inputs' and 'native-inputs' fields of packages are "thunked" fields, which means that the body is actually put into a thunk that's evaluated later
<mark_weaver>and there are several other thunked fields. see guix/packages.scm
<mark_weaver>(search for "thunked" in that file)
<wingo>i made gtk depend on gl
<wingo>but gl depends on fontutils
<wingo>which depends on gtk.
<wingo>probably there is a better ordering but for now i will put libepoxy in gnome
<wingo>in gtk
<davexunit>wingo: fwiw, all tests pass for me on master
<wingo>does that actually fix anythin
<mark_weaver>we need better tooling to detect and debug these issues. they are a pain
<wingo>i guess i would need to take out the bit from fontutils that depends on gtk
<mark_weaver>I hacked up a little script to find the SCCs and draw graphs with graphviz, but it's very primitive
<wingo>so i think fontforge should probably go to its own module
<wingo>i can hack it up unless you want to make a quick fix
<mark_weaver>inheriting from another package is an example of a reference that must be resolved at module load time, iirc.
<wingo>i should go ahead i guess
<mark_weaver>that's probably the most common case that causes problems
<wingo>see if it fixes my thing
<mark_weaver>wingo: does fontforge need to reference a binding from another module in the cycle at module load time? or does some other module in the cycle need to reference fontforge at module load time?
<mark_weaver>if not, I suspect the problem lies elsewhere
<mark_weaver>the missing piece to the tooling I started to write is a way to detect which package modules need to reference variables defined in other modules at module load time.
<mark_weaver>if I had that missing piece, my tool could pinpoint these problems
<mark_weaver>there are two kinds of module dependencies. for now, I'll call them "import" dependencies and "load time" dependencies.
<wingo>it's not fontforge
<mark_weaver>find the SCCs of the "import" dependency graph, and then if there's any "load time" dependency among modules within a single SCC, that's a problem.
<wingo>it's that fontforge, an app that depends on gtk, is in a module that should probably be at a lower level
<wingo>perhaps one variable is the use of #:prefix in the using module
<wingo>i don't know if that affects the laziness/eagerness of binding resolution
<mark_weaver>last I checked, we had only one non-trivial SCC, which was rather large.
<mark_weaver>wingo: oh yes, I think that does cause problems.
<mark_weaver>I vaguely remember civodul removing some of those #:prefix things to solve circularity issues.
<mark_weaver>#:select might also be a problem, dunno
<mark_weaver>yeah, guix has shown several inadequacies in guile's module system
<davexunit>do you think that the issues could be addressed before 2.2?
<mark_weaver>although part of the problem is that I'm not sure how to address all of the issues, even in theory.
<mark_weaver>circular dependencies among modules is trouble, no matter how you dice it.
<wingo>indeed, removing the #:prefix font: fixes it for me :(
<mark_weaver>R6RS doesn't permit circular dependencies at all, iirc, and I suspect the same is true of R7RS.
<mark_weaver>wingo: okay
<wingo>i'll submit a patch and you can see
<mark_weaver>wingo: what else did you have to change? were you able to determine the purpose of that prefix?
<wingo>pretty weird that it's just me, but i guess that adding the gtk+ -> gl edge perturbed the equilibrium enough to be necessary
<wingo>mark_weaver, i'll past it
<mark_weaver>wingo: this happens every once in a while. someone makes a patch and it causes these problems that can take some time to debug.
*mark_weaver looks
<wingo>terrible stuff
<mark_weaver>wingo: looks good to me.
<mark_weaver>I have to go afk again for a while...
<mark_weaver>good luck!
<wingo>i'll commit it locally and submit when i can
*wingo continues with gettext-induced system rebuild
<wingo>this damn circularity prevents me from rebuilding guix
<wingo>and it looks for a particular commit in savannah, so to rebuild i have to land the commit first
*wingo #:tests? #f in the meanwhile :/
<mark_weaver>wingo: didn't you fix the problem by removing the #:prefix'ed import?
<mark_weaver>or is there another circularity issue?
<wingo>that's it
<wingo>but building guix is building guix-devel
<wingo>which is a particular commit in savannah
<wingo>very strange
<mark_weaver>I've never tried it, but I guess you should be able to use a 'file:' URI for the source
<wingo>interesting idea
<wingo>i didn't think it would work but maybe you are right
<mark_weaver>periodically we update 'guix-devel' to a recent commit, but I agree it's too bad that the commit has to be in a publicly accessible repo
<mark_weaver>but maybe it doesn't
*mark_weaver looks
<wingo>all these warnings about failing to auto-compile 'guild' are pretty sad :P
<mark_weaver>heh, yeah
<mark_weaver>wingo: so, the 'url' passed to 'git-reference' is simply passed on to 'git clone' afaict.
<mark_weaver>although it's done in the fixed-output build environment, which is less restricted than the non-fixed-output build environment.
<mark_weaver>fixed-output derivations are derivations where the hash of the outputs is known in advance.
<mark_weaver>such derivations have access to the network, whereas normal derivations do not.
<mark_weaver>however, I suspect they are still done in a chroot.
<wingo>i hate it when a build fails and then deletes the test-suite.log
<mark_weaver>yeah, that's a drag
<wingo>a tests/syscalls.scm failure
<mark_weaver>wingo: oh, I've already figured that one out
<wingo>oh i'm glad i mentioned it then :)
*mark_weaver digs up url
<mark_weaver>basically, "/" is not listed in the mount points within our build container in linux-3.19 or later
<mark_weaver>I guess it's a linux bug
<wingo>i'm running 4.0-rc6
<wingo>and get the same issue
<mark_weaver>I ran the same test within 3.18.10 and "/" was listed, twice even :)
<mark_weaver>for now, I suggest you just disable tests on guix-devel
<wingo>i just tried that
<wingo>but spelled it #:test?
<wingo>instead of #:tests?
<mark_weaver>heh :)
<wingo>i always get that wrong, in path names and in kwards
<mark_weaver>those arguments are passed to all build phases, so users could add their own in theory
<mark_weaver>and we occasionally add new ones when we add new phases
<mark_weaver>so we can't really do proper error checking for bad keywords.
<wingo>too bad
<mark_weaver>although I suppose we could issue warnings for common mispellings like #:test? or #:tests
<mark_weaver>wingo: btw, if you ever want to understand guix in greater depth, this paper is recommended:
<mark_weaver>it's slightly out of date, but mostly relevant
<mark_weaver>(it's linked from the "Documentation" section of
<mark_weaver>otoh, I didn't read it until a month or two ago, so such in depth knowledge is not needed to do lots of hacking on guix
<civodul>Hey hey!
<wingo>managed to somehow misspell #:tests? again, ffs
<wingo>hello civodul :)
***boegel|afk is now known as boegel
<civodul>hey, wingo
<mark_weaver>aalib is yet another package whose config.guess doesn't know about mips64el
<mark_weaver>civodul: are you still opposed to passing --build=<triplet> by default in gnu-build-system ?
<mark_weaver>I think it will be important on some systems, e.g. armhf, that choose a triplet based on the CPU in the build machine.
*mark_weaver goes afk for a bit
<civodul>mark_weaver: i'm not really "opposed", only slightly concerned this is necessary and that always passing --build might sometimes break as well
<civodul>do you know why it fails?
<civodul>script too old?
<rekado>FYI: the julia devs say that julia is only known to work on i686 and x86_64, not mips or arm.
<civodul>rekado: could you add a 'supported-systems' field accordingly, with a comment explaining it?
<rekado>civodul: sure.
<civodul>thanks :-)