<mark_weaver>a_e: btw, while you're here, I wanted to re-raise my proposal to configure gnutls to support a system-wide trust store in /etc <mark_weaver>I think you're the only person who didn't like it, and I've been carrying the patch in my own tree ever since. <a_e>Maybe I did not like it because it would not work with Guix on another system. <a_e>Apart from that, I do not remember the details. <a_e>How about you send (or resend?) the patch to the mailing list? <a_e>Okay, I will have a look at it llater. Time to go now and dream for real... <kete>I agree with Ludo; "Colemak" should stay as upstream "en-latin9". <Sleep_Walker>civodul: the /homeless-shelter problem was all my fault - please ignore <mark_weaver>jgrant: I have a working libffcall package now. I fixed the problem by disabling parallel-build <Sleep_Walker>civodul: about the Savannah account - my login is 'Sleep_Walker' but give me access only if it helps you lower the load <civodul>everyone has been so active over the last few days that there's indeed a huge load ;-) <civodul>i need to catch up, and i'm glad that review is getting more distributed <rekado_>when sharing a read-only store from a central NFS share among different machines is it enough to mount /gnu/store or would the localstatedir also have to be mounted by all users? <rekado_>I want to make the store and the profiles available on cluster nodes. The store and the profiles are managed on a separate machine, the only one to have write permissions on /gnu/store <rekado_>the daemon is only running on that management machine, not on any cluster node. <rekado_>to install new software into user profiles we would use the management machine only. <rekado_>are there any obvious problems with this approach? <rekado_>Is anyone here familiar with Sphinx? I have python2-sphinx as an input to a library and one test fails because of an error in using sphinx. <rekado_>says: "ImportError: No module named sphinx_rtd_theme" <rekado_>(it's the penultimate test of 140 tests after a very lengthy build process of a couple of hours on my machine) <iyzsong>civodul: I'll look into xfce (alrealy works IMO) again when I finish the sawfish session. And the xfce meta package have to be contained in 'packages' field to make SLiM session work. Is this acceptable? <civodul>iyzsong: i was actually referring to the xfce meta-package that you submitted but did not commit, IIRC <rekado_>re sphinx: sphinx_rtd_theme is a third-party module, so I'll just need to package that. <rekado_>(I find it annoying that checking for dependencies before building/testing is still not commonly done.) <rekado_>oh, offloading works! Just recompiled guix on my workstation. <rekado_>I didn't have to edit the machine.scm configuration file. <rekado_>hmm, actually, it doesn't seem to work right. <rekado_>I see this message again and again: process 23211 acquired build slot '/var/guix/offload/my-remote-build-host/0' <davexunit>I might have an unexpected day of free time to hack on guix. <davexunit>public transit in boston is completely busted, basically. <rekado_>I even see it when my-remote-build-host does not have a running daemon. <rekado_>The "bad qstring header component" error struck again. This time when downloading a tarball from pypi.python.org. <rekado_>oh, that's not good: "ValueError: ZIP does not support timestamps before 1980" <rekado_>I guess that's because guix sets file timestamps to the beginning of the epoch? <bavier`>rekado_: yes, but zip is used elsewhere for unpacking. <rekado_>I see that elib.intl had the same issue <rekado_>passing configure flags apparently fixes this. <bavier`>I thought that error seemed familiar (I packaged elib.intl) <rekado_>hehe. Thanks for solving it for me :) <mark_weaver>rekado_: localstatedir is not needed to run the software in /gnu/store. it's only needed by guix-daemon, I believe. <mark_weaver>their ETags are supposed to be in double quotes, but aren't. <mark_weaver>"wget -S" can be used to see that pypi.python.org violates the spec, with an ETag header that has no quotes. <phant0mas>DusXMT: the diff is based on wip-hurd HEAD, right? <DusXMT>There are two of them. Well, three, but the first one can be safely ignored <rekado_>mark_weaver: I'll contact them about this etag header issue. <DusXMT>phant0mas: Are you applying both of them? Since there's two of them, and they build on each other <DusXMT>phant0mas: If you want to try building coreutils: acl needs to be patched, you can find the needed patch in debian's source package, the name should be obvious <jgrant>mark_weaver: Sorry was afk most of yesterday, just saw your libffcall news. Very nice, ty! <davexunit>mark_weaver: thanks for writing the CVS download method! *jgrant is slowly starting work on kodi. <davexunit>heh, I think I attempted that at one point... *phant0mas started the build, will take some time :-/ <davexunit>jgrant: I could give you what I have so far, maybe there's something salvagable. <jgrant>I have a dedicated HTPC on Parabola in the meantime, but I'd love to go full GSD. <jgrant>davexunit: I'll take anything you're willing to give me. :^) <davexunit>that I also would like to convert to a GuixSD system. <jgrant>davexunit: Better than nothing, man, ty. <davexunit>the most annoying thing so far is that the source releases don't come with configure/Makefile/etc, you have to use autotools and run the bootstrap script. <jgrant>davexunit: Want me to add your name to the license header? <davexunit>you will likely have to change that package a lot before you get a working build. <davexunit>I was just slowly adding inputs until I could get configure to complete <davexunit>and then worry about all the optional stuff. <jgrant>That's now 6 packages to work on: clisp, font-league, icecast, rtorrent (which I have about half of the depends done for), rust, and st. <jgrant>St, I'd suspect to be the easiest. <jgrant>Font-league, thereafter if/when I figure out what is needed for such things. <davexunit>I will definitely migrate my HTPC if Kodi gets packaged. the only real important thing that machine runs is the transmission daemon and web interface. <jgrant>That is on my backburner, but on my radar. Stumpwm via Clisp is my main focus right now. <jgrant>Kodi is certainly up there though. <davexunit>one of us (or someone else) will get it done eventually. <davexunit>it will be cool to create an OS config for HTPCs. forget openelec and those other special distros, all we need is a config file! <jgrant>Yeah, kodiak.scm or similar. :^) *davexunit hacks on a functional reactive UI prototype for 'guix web' <rekado_>hmm, I can't get offloading to work. I get "process 7331 acquired build slot '/var/guix/offload/my-build-host/0'" in regular intervals, but on the build host I don't see any activity on SSH. <rekado_>The user specified in /etc/guix/machines.scm should log on via SSH using the specified public key, no? <rekado_>hmm, the machine load is reported as +inf.0, so I guess remote-pipe to the machine fails for some reason. <rekado_>(this happens for a real, existing machine and for a bogus machine) <rekado_>remote-pipe uses lsh, which I don't have. I also didn't see it mentioned in the manual. <rekado_>now that's better. ---> (define %lsh-command "ssh") <rekado_>it complains about permissions to the private key now, but that's okay. <rigelk>mark_weaver, sure, I didn’t know <rigelk>tail contains the wicd.scm used by the current build <mark_weaver>I'm fairly ignorant of python, but if you think it's a python 3 problem (certainly sounds plausible to me), then add this: (arguments `(#:python ,python-2)) <mark_weaver>also, based on what I've heard elsewhere, if you want the wicd curses interface, you should add: (inputs `(("python2-urwid" ,python2-urwid))) <mark_weaver>home-page should be a proper URL, i.e. starting with "http://" or "https://" <mark_weaver>also, 'synopsis' shouldn't include the package name (by our convention), the description (not but the synopsis) should end with a period, and lines should be kept < 80 columns. <mark_weaver>you might (or might not) also need to add (native-inputs `(("python2-setuptools" ,python2-setuptools))) <mark_weaver>rekado_: thanks very much for filing the report with the pypi folks <rekado_>I think offloading needs a little more documentation. If I get around to it I might suggest a few changes on the ML. <mark_weaver>I know that the machine load is reported as +inf.0 when it's unable to make a connection. <rekado_>it works now that I replaced "lsh" with "ssh" <rekado_>I also needed to create a new key pair and it seems that it needs to be readable by root (not just the guix-builder group) <rigelk>thanks mark_weaver for the help ! I’m working on your suggestions :) <mark_weaver>davexunit: oooh, functional reactive UI in a web app. sounds cool! <rekado_>bah: guix offload: error: failed to register GC root for '/gnu/store/byc....-python-sphinx-rtd-theme-0.1.6.drv' on '#<<build-machine> name: "my-build-host" port: 22 system: "x86_64-linux" user: "rwurmus" private-key: "/etc/guix/guix-builder-identity-rsa" parallel-builds: 1 speed: 2.0 features: ()>' (status: 256) <rigelk>mark_weaver, python-2 throws an ERROR: Unbound variable: python-2. <davexunit>mark_weaver: yes, it pretty much eliminates callback hell which is a big win. though, I find the JS FRP libraries to be lacking in one way or another. <mark_weaver>rigelk: add #:use-modules (gnu packages python) near the top <rigelk>oh. ça a l’air de marcher. je regarde du côté de urwid alors <rigelk>sorry, I switched to french ^^ | is the previous warning standard behaviour or is it due to a misconfiguration from <bavier`>rigelk: "standard behavior". It just means hydra is bogged down (again). <mark_weaver>hydra is running on a terribly performing VM, unfortunately. <mark_weaver>negotiations to improve this situation are in progress <rigelk>I wonder if passing « --distro or --init and --initfile » might be of any help <mark_weaver>rigelk: based on the message, it looks like you should pass --init <???> or --initfile <???> to configure <mark_weaver>unfortunately, it is unlikely to know about our distro or our init system. I'd better take a look. <mark_weaver>rigelk: --initfile looks like the best bet. it wants to know where to put an init file, like /etc/init.d/wicd <mark_weaver>although not great, an okay way to find things out is to look at other packages in gnu/packages/*.scm <mark_weaver>but give me a few minutes to figure out what to pass to --initfile <mark_weaver>Sleep_Walker: it looks like the connection got reset part way through. not a great way to report the error though :-/ <mark_weaver>rigelk: I would try passing --distro=guixsd to configure. it might work. the way you do that is by adding this inside the 'arguments' list: #:configure-flags '("--distro=guixsd") <mark_weaver>so, within the same set of parentheses as the #:python ,python-2 <mark_weaver>but on the next line (by our formatting conventions) <mark_weaver>(wicd doesn't know about guixsd, but if I'm reading the code correctly, it will simply not install an init file, which is appropriate for us anyway) <mark_weaver>rigelk: can you show me the package definition that generated that error? <Sleep_Walker>220 packets transmitted, 118 received, 46% packet loss, time 219011ms <Sleep_Walker>rtt min/avg/max/mdev = 86.201/40246.038/90643.973/29954.078 ms, pipe 91 <Sleep_Walker>but yes, that was my point - handle such error more user friendly <mark_weaver>fwiw, my pings to hydra.gnu.org are getting through without problems, although admittedly I live in the same town where hydra is located. <mark_weaver>but the problem is not specific to hydra or its nearby network, anyway. <mark_weaver>the value associated with #:configure-flags needs to be an expression that returns a list of strings. <mark_weaver>your expression returns a string, not a list of strings. <mark_weaver>clearly, we should improve the error detection and reporting in guix, but there's a lot to do :) <mark_weaver>rigelk: also, the "in Linux" part of that description has got to go. it propagates the confusion that "Linux" is the name of the operating system. <Sleep_Walker>but on the other hand this is hardly readable even for me and I don't get scared easily <Sleep_Walker>with human readable error messages it will be user friendlier <mark_weaver>Sleep_Walker: mailing bug-guix@gnu.org about specific cases of bad error reporting would be helpful <mark_weaver>(a general "improve error reporting" bug report wouldn't be very useful) <Sleep_Walker>agreed, I just don't want to discourage you with bombing all the usability bugs <mark_weaver>rigelk: looks like you missed the apostrophe in the bit I pasted <rigelk>yes, I tried with the apostrophe and it shows the same errors as with no configue-flags at all <fchmmr>I think guix is going to become the de-facto distro in the future, like trisquel is <fchmmr>I've read about how the package manager works, and it looks much better than apt-get or pacman <fchmmr>Is there an easy guide for installing guix? <fchmmr>Actually, "easy" is relative. I find installing Parabola easy. Some people don't. <mark_weaver>heh, yeah, guix is not ready for newbies yet, but we'll get there eventually. <mark_weaver>fchmmr: yes, I recently bootstrapped Guix for ARMv7. <fchmmr>This is one of the major issues for Trisquel. <mark_weaver>the core system works anyway. we support Loongson 2F also. <fchmmr>The only ARM system that I have is a beaglebone black, though. <fchmmr>(I use it for flashing libreboot ROM images, if external flashing is needed. Right now it's running the Debian distro that it came with. I'd love to put something FSDG on there) <yang>Congratulations for the FSF endorsement ! <mark_weaver>fchmmr: our armhf port should work on the BBB, but we don't yet have any build slaves for our build farm, so no pre-compiled binaries yet, and the BBB probably doesn't have enough RAM to bootstrap our system from scratch from sources. <fchmmr>mark_weaver, core system is probably fine. All I really need is flashrom, and I can build that and its dependencies from source. <fchmmr>mark_weaver, so with limited RAM, I guess the only option is to cross-compile. <mark_weaver>fchmmr: we have a build farm, hydra.gnu.org, that automatically builds pre-compiled binaries for all of our packages. <mark_weaver>well, hydra.gnu.org is the master of the farm. there are several other machines elsewhere that do the actual compiling. <fchmmr>yes, hence hydra. multiple independent "slaves" (heads) to do the job. <mark_weaver>jxself: no, for now you have to host it within another distro. <fchmmr>cut one head off, and the others still work. <mark_weaver>fchmmr: a better bet might be to set up a virtual ARM machine with qemu and use it to compile the arm packages. <fchmmr>quote: " Support for the Logical Volume Manager (LVM) is missing. " <mark_weaver>I don't remember yet if I've tried compiling flashrom On ARM. <fchmmr>That means I can't do an encryption guide yet, then. <fchmmr>That's actually one of the main reasons I want to try guix. <fchmmr>I'll do one for gnewsense aswell, once 4.0 is out <fchmmr>mark_weaver, I've built flashrom in ARM (in debian, on the bbb) and used it. <mark_weaver>fchmmr: our initramfs uses guile instead of the usual set of shell scripts and busybox, so the usual recipes won't work for us. <mark_weaver>fchmmr: we need to implement the needed functionality as guile code <mark_weaver>rigelk: the apostrophe is definitely needed. if it still doesn't work, I guess that means that --distro=guixsd is not enough to placate their configure script. I'll take a look. <mark_weaver>rigelk: btw, I stand corrected about the home-page. indeed, it seems that they've adopted launchpad as their new official home. that's sad :-( <mark_weaver>(or has launchpad been liberated since I last checked?) <fchmmr>guile homepage uses presentational html <mark_weaver>well, it's okay either way, we don't require projects added to Guix to be hosted on sites run on free software <Gabou>Is there any video record or something? <mark_weaver>Gabou: unfortunately, it seems that the video recording was botched. <mark_weaver>but most of the talk was apparently demos that aren't in the slides. <mark_weaver>rigelk: it seems to be a bug in the setup script, such that it doesn't work the way it's supposed to. we'll probably have to patch it. <mark_weaver>there's logic in distro_check to set self.no_install_init = True, which is what we need <mark_weaver>and it seems that the variable is not set from the user-provided options until after that check is done <mark_weaver>I was hoping to find a way, via configure-flags, to get the code on lines 321-322 of setup.py to run, but I don't see how :-( <Gabou>Can I use guix for daily usage? (with a WM, my programs I currently have on Parabola)? Is it a rolling distro or I'll have to reinstall on each big update? <bavier`>Gabou: you can run guix on top of another OS. <bavier`>so you can have guix augment you current system with its packages <Gabou>Oh right, what about GSD then? <bavier`>Guix and its distro are current alpha <bavier`>disclaimer aside, there are a few who do use it daily <Gabou>I'll wait until giving a try then, thanks <mark_weaver>Gabou: it depends what software you use. it has what I need, and I run GuixSD on my primary machines, but we are missing many packages that you might want. <DusXMT>But it's not that difficult to package them. For example, I use nvi to edit text, Abiword to edit documents, mupdf to view PDFs, and none of that was packages when I came; I just tried my best at packaging them, submitted patches, and they're now in, so I'd say: If you're up for doing some work for yourself, it can be pretty neat <mark_weaver>davexunit: yep, fchmmr brought it to our attention in the last hour or so <davexunit>mark_weaver: ah, I didn't read the backlog well enough. <mark_weaver>rigelk: I worked around that problem, but then found that there are several other problems. <Gabou>Is it like gentoo where I need to compile everything or can I just have binaries? <DusXMT>Gabou: It's both, you get to choose whether you trust our build farm, or whether you'd rather build everything yourself <mark_weaver>rigelk: I'm afraid you've picked a difficult package to start with. I'm working on it now, but would like you credit you as co-author of the commit. is that okay? <mark_weaver>hmm, looks like wicd needs python-dbus, which we don't yet have <rigelk>mark_weaver, I’m willing to keep working on it with you, if I may be of any help. :) <mark_weaver>rigelk: I might very well pass it back to you, since it is a bigger job than I thought. <mark_weaver>but let me try to work through some of the trickier problems. <mark_weaver>rigelk: python-dbus is a prerequisite though. would you like to try packaging it? iirc, "guix import pypi python-dbus" will get you started. <rigelk>well, I have time to spend on it : as Omar R. pointed on the mailing-list, wicd is yet easier than networkmanager and one of them is required for ease of use. <mark_weaver>rigelk: yes, wicd would be a great contribution to guix <mark_weaver>and I suspect it is easier to package than network-manager <rigelk>mark_weaver, networkmanager needs a modified version of systemd (nm’s source is bound to it) as systemd uses udev and we use eudev. <rigelk>at least that’s roughly what i recall of a talk with civodul at Fosdem :) <Sleep_Walker>there is also connman available which is not bad solution <Gabou>also, connman is what I currently use. <Sleep_Walker>I have already made package for that for openSUSE and it wasn't hard <rigelk>might be added to the «wanted» packages list, Gabou <Sleep_Walker>wicd was considered dead by its developers years ago but there are still some new commits from time to time <mark_weaver>rigelk: yeah, I'm going to pass this back to you soon. give me a few minutes to finish up the bits I'm working on . <mark_weaver>there's zillions of hardcoded paths, and no simple PREFIX argument that I can easily find :-( <DusXMT>mark_weaver: I'd consider writing an actual patch by that point, to decrease the complexity of the package definition <DusXMT>to fix all the hardcoded paths, that is <rigelk>okay mark_weaver, I’m taking a look on gnutls as it is required to do `guix import pypi dbus-python` and I get : ;;; Failed to autoload make-session in (gnutls) <sneek>Welcome back civodul, you have 1 message. <civodul>rigelk: you need to make sure the Guile bindings for GnuTLS are installed, and that they are in $GUILE_LOAD_PATH <jgay>civodul, it was m pleasure. I'm happy we could finally make the announcement and that you were able to reach an amicable agreement with RMS on naming <mark_weaver>rigelk: hmm, sounds like you lack guile-gnutls bindings on your system <mark_weaver>rigelk: for now, you could use wget to download the package and then "guix download file:///absolute/path/to/tarball" <mark_weaver>jgay: thanks so much for all your work on this (and the Libreboot X200 too :) <civodul>right, it's always pleasant to read about all these achievements <mark_weaver>DusXMT: the workarounds may end up being much less code than a patch, I suspect. <mark_weaver>although getting an improved build system upstream would be welcome <jgay>mark_weaver, oh no problem, the Guix stuff took very little time because I basically just skimmed over things to make sure that stuff was in order and assumed I could just trust a GNU project to DTRT :-) <jgay>RYF certification for the X200 was a lot of work *civodul adds a news entry at gnu.org/s/guix ***civodul changes topic to 'GNU Guix | http://gnu.org/s/guix/ | 0.8.1 is out! | http://www.fsf.org/news/fsf-adds-guix-system-distribution-to-list-of-endorsed-distributions | This channel is logged, see <https://gnunet.org/bot/log/guix>.'
<mark_weaver>rigelk: the 'guix' and 'gnutls' built from within guix works out of the box. <mark_weaver>but if you build guix within another distro, it depends on the guile bindings in gnutls being set up, and GUILE_LOAD_PATH pointing to them. <rigelk>thanks for your help mark_weaver, I’ll have that figured out <mark_weaver>rigelk: so, for python packages, we generally provide versions for both python 2 and python 3, and you can look at python-urwid and pyhon2-urwid near the end of python.scm for an example <rigelk>does it mean I should provide both v2 and v3 of dbus-python ? <mark_weaver>hmm, and we probably want to name them python-dbus and python2-dbus, because otherwise 'package-with-python2' won't work right. <mark_weaver>and then any other python packages that depend on python-dbus won't be converted to python-2 automatically. <Sleep_Walker>it seems that I'll be able to build things faster than just download from hydra... <rigelk>mark_weaver, you advised me to do `guix import pypi …`. Of course without gnutls it isn’t of any use anymore right ? <rekado>re etag issue on pypi: "We think we fixed it. Can you check and see if things work for you?" <Sebboh>FYI, Fortinet firewall products block gnunet.org for reason "p2p". Which just means I can't view the log link in the topic, but that's no big deal. :) <davexunit>recompiling atm, but once it's done I will test. <davexunit>Sebboh: ask whoever is in charge of that firewall to unblock gnunet! <Sebboh>OT: davexunit, fortinet products don't work like that. The hardware manufacture controls the list. ...Which is considered a feature, I guess. <Sebboh>I have a question about the origin of guix. Is it a fork of nix? nix seems pretty new, and gpl (v2+?). Is there something wrong with it? <davexunit>Sebboh: it's not a fork, but we use some of the Nix components. <davexunit>but it's only recently that it's gotten a lot of attention. <davexunit>the underlying theory behind the Nix tools is great, but we don't care for some aspects of its implementation. <davexunit>for example, Nix uses a mix of Bash and a custom programming language (also called Nix) for describing packages and build scripts. <davexunit>we think that it's better to use an existing general-purpose programming language that supports embedded domain specific languages (EDSLs), like Scheme. <davexunit>we are also dedicated to providing a fully free OS. <davexunit>and improving the integration and workflow for GNU software packages. <Sebboh>I support those goals as well :), though I don't own any hardware that the libre kernel works with. But, fine, I'll use guix, not nix. Thanks for the guidance. <davexunit>that said, Nix is really cool. I don't see us as a Nix competitor, but rather as another option for people with different priorities. <davexunit>both options will save you from the world of weak package managers and bad configuration management tools. :) <Sebboh>I've been a Debian man for a few years. Being familiar with apt, I find guix attractive. <jgrant>Evidently if you build Kodi with SDL 1.2 over SDL 2.0, screen tearing is not rare. <jgrant>At least with some videocards, certainly with this poor old video-card. <jgrant>Sebboh: Nix is great from the little I've seen and played with, is great, but yeah -- if Scheme is your thing, Guix is fantastic. <jgrant>It's also generally a lot nicer to have a unified lang, whether it be Scheme or otherwise, rather than doing configuration in tandem with Sh. <rigelk>does someone know how to specify a version (ver2) for python in a gnu build-system context ? I’m having trouble with this in this package desc : http://paste.lisp.org/+34CC <bavier`>rigelk: does it not use python-build-system? <bavier`>gnu-build-system doesn't recognize the #:python argument <rigelk>thanks, I was gonna try the input-way <mark_weaver>rekado: wow, they already fixed it. I'm impressed and pleased! thanks again :) <mark_weaver>rigelk: python-dbus uses the expat license, not gpl2 <rigelk>it does. I was just bumping on the default error for a missing python input (as using autotools rather than setup.py). the default calls for python 2… ^^' <rigelk>mark_weaver, I have forgotten to change the license, thanks ! <rekado>mark_weaver: yeah, I was very surprised to see so fast a response and resolution. <mark_weaver>rigelk: we should have versions for both python 2 and python 3. normally we do this by making the default package for python 3 (named python-dbus in this case), and then use 'package-with-python2' to automatically make a variant for python 2. <rigelk>now that the input of python is properly stated, I bump into the following : configure: error: The pkg-config script could not be found or is too old. <mark_weaver>rigelk: you should put this in python.scm instead of a new file <mark_weaver>the apostrophe in the commented-out 'inputs' in that paste is not right. it needs to be a backquote instead. <rigelk>mark_weaver, I am making the move accordingly <rigelk>mark_weaver, yes, I corrected the apostrophe ;) <mark_weaver>python-dbus should be for python 3, and python2-dbus will be the variant for python 2, per our usual conventions. <mark_weaver>the URI should be computed based on the 'version' variable instead of having the 1.2.0 hard-coded <rigelk>and missing the #:use-module (gnu packages pkg-config) <rigelk>everything is now okay, and just cries for dbus :-> configure: error: Package requirements (dbus-1 >= 1.6) were not met <mark_weaver>yes. and "guix package -A dbus" will tell you what module dbus is in, so you know which module to import with #:use-modules <mark_weaver>however, this will have to end up in python.scm eventually 