*davexunit thinks about how to package generic r6rs scheme libraries for guile <davexunit>mark_weaver: I happened to see your OS config on paste.lisp.org <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>ok, just colord, gweather, geoclue needed for gnome-settings-daemon *wingo built colord package and service, now to see if colord service works... <davexunit>poking at mesa a bit. can't seem to figure out why it doesn't build nouveau_dri.so <davexunit>but it does build something called nouveau_vieux_dri.so <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>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><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 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 <mark_weaver>I'm updating my user profile now to see if that fixes it... *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 <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>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>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>just like services can declare users and groups <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 gnu-system.am <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... <davexunit>mkdir() "/gnu/store/cqgb5apnyn5jmki7xj90d45q8cmwjj6p-nginx-1.6.2/client_body_temp" failed (13: Permission denied) <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>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>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/nginx.pid;" "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>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 :( <davexunit>wingo: best to get 'em in now while we're rebuilding the world anyway <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>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 <mark_weaver>so, I wonder if there's any point to building the glib/cairo updates in a separate branch <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>which requires a newer glib and cairo <wingo>and also an xgettext that knows xml <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>although my branch doesn't diverge from master in the core components <wingo>what's the other change in core-updates needing some work? <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 <wingo>so failing builds precludes any kind of merge :) <wingo>glad to see guix is getting some mileage out of that elf parser :) <davexunit>mark_weaver: do you think we should move those nginx root dirs to share/nginx? <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>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 <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>just another step on the path to automated web application deployment <mark_weaver>indeed, and it would be nice to run hydra.gnu.org 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. <mark_weaver>hopefully we will have a new physical machine for it within the next month or so <mark_weaver>the main holdup has been choosing hardware that is both fast and can run coreboot without blobs. <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>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. <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 <wingo>mark_weaver, i mailed it to the list <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>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 <davexunit>mark_weaver: while I'm tweaking nginx, should /sbin be moved to /bin? <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>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... *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>i can reproduce the issue via "guix package --search=" <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 <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 <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 <wingo>probably there is a better ordering but for now i will put libepoxy in gnome <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. <mark_weaver>that's probably the most common case that causes problems <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>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. <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>I vaguely remember civodul removing some of those #:prefix things to solve circularity issues. <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. <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 <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. <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? <wingo>but building guix is building guix-devel <wingo>which is a particular commit in savannah <mark_weaver>I've never tried it, but I guess you should be able to use a 'file:' URI for the source <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 <wingo>all these warnings about failing to auto-compile 'guild' are pretty sad :P <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. <wingo>i hate it when a build fails and then deletes the test-suite.log <wingo>a tests/syscalls.scm failure <wingo>oh i'm glad i mentioned it then :) <mark_weaver>basically, "/" is not listed in the mount points within our build container in linux-3.19 or later <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 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. <mark_weaver>although I suppose we could issue warnings for common mispellings like #:test? or #:tests <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 <wingo>managed to somehow misspell #:tests? again, ffs ***boegel|afk is now known as boegel
<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 <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?