IRC channel logs


back to list of logs

<mark_weaver>sounds reasonable
<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.
<mark_weaver>how do you feel about it now?
<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?
<mark_weaver>a_e: okay
<mark_weaver>a_e: sent
<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".
<civodul>Hello Guix!
<mark_weaver>hi civodul!
<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
<mark_weaver>will post soon
<civodul>Sleep_Walker: good
<civodul>hey, mark_weaver!
<Sleep_Walker>civodul: about the Savannah account - my login is 'Sleep_Walker' but give me access only if it helps you lower the load
<Sleep_Walker>I don't feel like experienced schemer yet ;)
<civodul>heh, ok!
<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
<Sleep_Walker>that is good indeed
<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: probably
<civodul>iyzsong: i was actually referring to the xfce meta-package that you submitted but did not commit, IIRC
*civodul has to rush
<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>morning #guix
<jxself>Ahoy there Mr. Unit.
<davexunit>I might have an unexpected day of free time to hack on guix.
<jxself>Too much snow?
<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
<rekado_>oh, that's not good: "ValueError: ZIP does not support timestamps before 1980"
<rekado_>(when installing sphinx-rtd-theme)
<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.
<rekado_>works now.
<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>the bad ETag headers generated by is indeed a major problem for us. I wonder if they care about their violations of
<mark_weaver>someone(TM) should talk to them about it.
<mark_weaver>their ETags are supposed to be in double quotes, but aren't.
<mark_weaver>well, looks like RFC2616 has been obsoleted. Now it's that we should be citing on this issue.
<mark_weaver>"wget -S" can be used to see that violates the spec, with an ETag header that has no quotes.
<mark_weaver>e.g. wget -S
<phant0mas>DusXMT: the diff is based on wip-hurd HEAD, right?
<DusXMT>phant0mas: yup
<DusXMT>There are two of them. Well, three, but the first one can be safely ignored
<phant0mas>I am just asking because it fails to apply
<phant0mas>well will work around that
<rekado_>mark_weaver: I'll contact them about this etag header issue.
<davexunit>thanks rekado_
<mark_weaver>rekado_: thanks!
<DusXMT>phant0mas: strange...
<DusXMT>phant0mas: Are you applying both of them? Since there's two of them, and they build on each other
<phant0mas>will do a git clean -dfx and try again
<phant0mas>and a git reset
<phant0mas>DusXMT: it's ok now
<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!
<davexunit>I can package libtidy now
*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 :-/
<jgrant>It's such a mammoth...
<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>I have an HTPC running Debian.
<davexunit>that I also would like to convert to a GuixSD system.
<davexunit>jgrant: so, I didn't get very far, but here it is:
<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>I'm already there.
<davexunit>don't worry about it.
<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.
<rigelk>jgrant, need a hand for rust?
<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>that's fine. :)
<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_>bug report has been created after I sent an email to -->
<davexunit>cool. fast response.
<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?
<rigelk>hi all, I am having the python SyntaxError on the wicd package recipe as shown in the following output : any ideas ?
<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.
<mark_weaver>rigelk: blocks tor users, so I can't view that paste. could you paste it somewhere else? one option is
<rigelk>mark_weaver, sure, I didn’t know
<rigelk>I suspect the python version to be the main problem though :
*mark_weaver looks
<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>thanks for working on it!
<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>(but don't include it unless it's actually needed)
<mark_weaver>rekado_: thanks very much for filing the report with the pypi folks
<rekado_>mark_weaver: no problem.
<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"
<mark_weaver>ah, good!
<mark_weaver>better docs sound good to me :)
<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)
<rekado_>I've had enough for today.
<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>question : à quoi est due l’erreur guix substitute-binary: warning: while fetching server is somewhat slow ?
<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>okay, good to know.
<rigelk>I bumped into wicd’s distro detection :
*mark_weaver looks
<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.
<rigelk>mark_weaver, how to pass arguments to configure ? looking at the doc doesn’t help much :
<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
<Sleep_Walker>does this backtrace makes any sense to you?
<Sleep_Walker>is it just not handled connection issue?
<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>Sleep_Walker: what happens if you try again?
<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: ^^
<rigelk>^^ first try :
<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>right now is not the right moment for retry
<Sleep_Walker>Deutsche Bahn
<Sleep_Walker>but yes, that was my point - handle such error more user friendly
<mark_weaver>fwiw, my pings to 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.
<rigelk>mark_weaver, latest wicd.scm is here
<mark_weaver>rigelk: you miscopied what I wrote.
<mark_weaver>#:configure-flags '("--distro=guixsd")
<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 :)
<Sleep_Walker>I know
<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.
<mark_weaver>it's probably best to just remove the "in Linux"
<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 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
<Sleep_Walker>I'll prepare bug report
<mark_weaver>Sleep_Walker: thanks!
<mark_weaver>include the backtrace pleaes
<mark_weaver>rigelk: looks like is the real home-page for wicd.
<rigelk>new try
<mark_weaver>rigelk: looks like you missed the apostrophe in the bit I pasted
<mark_weaver>again: #:configure-flags '("--distro=guixsd")
<mark_weaver>rigelk: and the license is gpl2+ not gpl2
<fchmmr>I just saw the news.
<rigelk>yes, I tried with the apostrophe and it shows the same errors as with no configue-flags at all
<mark_weaver>fchmmr: ah! thanks for pointing that out :)
<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
<jxself>It is pretty neat. :)
<fchmmr>Is there an easy guide for installing guix?
<fchmmr>I want to try it.
<mark_weaver>sneek: later tell civodul:
<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.
<fchmmr>Are there plans to support ARM?
<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 !
<davexunit>thanks yang!
<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>hopefully we'll have some ARM build slaves soon.
<fchmmr>build slaves?
<fchmmr>like a build bot
<mark_weaver>fchmmr: we have a build farm,, that automatically builds pre-compiled binaries for all of our packages.
<fchmmr>"hyrda" is a good name.
<mark_weaver>well, is the master of the farm. there are several other machines elsewhere that do the actual compiling.
<jxself>armhf is bootable yet?
<mark_weaver>it has a web interface
<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>same for mips/loongson.
<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.
<mark_weaver>fchmmr: yes, we have a lot still left to do.
<fchmmr>^ I could do guides like those.
<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
<fchmmr> "insidious cunning in attaining a goal; crafty or artful deception; duplicity. "
<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
<rigelk>okay mark_weaver , I might try other options ( )
*mark_weaver looks
<rigelk>as for launchpad, mark_weaver , don’t know about recent updates but lanchpad opened its code in 2009 :
<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>there are these slides:
<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>but this depends on checking self.distro first
<mark_weaver>and it seems that the variable is not set from the user-provided options until after that check is done
<mark_weaver>what a pain :-(
<mark_weaver>well, whatever, we can patch it if needed
<mark_weaver>I was hoping to find a way, via configure-flags, to get the code on lines 321-322 of to run, but I don't see how :-(
*mark_weaver works on it
<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.
<davexunit>FSF press release about guix:
<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.
<davexunit>sorry for the noise!
<mark_weaver>not a problem :)
<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?
<Gabou>DusXMT: okay I see
<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.
<Sleep_Walker>yay, FSF acknowledged Guix System Distribution!
<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
<mark_weaver>(though unsure)
<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>wicd is abandonned no?
<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>ugh, this is a *terrible* build system :-(
<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)
<civodul>hey, rigelk
<sneek>Welcome back civodul, you have 1 message.
<sneek>civodul, mark_weaver says:
<civodul>yaaay \\o/
*civodul parties
<civodul>a big thanks to jgay!
<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"
<civodul>jgay: yes, this is all good news
<mark_weaver>jgay: thanks so much for all your work on this (and the Libreboot X200 too :)
<mark_weaver>with the certifications and announcements, I mean
<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>(and more resilient to future changes)
<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
<mark_weaver>I can imagine!
<rigelk>mark_weaver, I this the only way to get a working gnutls in guix ?
***civodul changes topic to 'GNU Guix | | 0.8.1 is out! | | This channel is logged, see <>.'
<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.
<mark_weaver>I have to go afk for while.
<rigelk>thanks for your help mark_weaver, I’ll have that figured out
<mark_weaver>rigelk: excellent!
<mark_weaver>rigelk: here's what I've got so far, but it needs python2-dbus, and I suspect there will be other problems as well.
<mark_weaver>most packages are easier than this, fortunately
<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>mark_weaver, thanks !
<rigelk>does it mean I should provide both v2 and v3 of dbus-python ?
<mark_weaver>rigelk: yes
<mark_weaver>hmm, and we probably want to name them python-dbus and python2-dbus, because otherwise 'package-with-python2' won't work right.
<rigelk>seems legit
<mark_weaver>and then any other python packages that depend on python-dbus won't be converted to python-2 automatically.
<Sleep_Walker>hydra is unusable
<Sleep_Walker>it seems that I'll be able to build things faster than just download from hydra...
<jgrant> Sleep_Walker What's new? :^)
<Sleep_Walker>jgrant: new is that it applies on whole distribution ;b
<rigelk>mark_weaver, you advised me to do `guix import pypi …`. Of course without gnutls it isn’t of any use anymore right ?
<civodul>rigelk: correct
<Sebboh>Greetings from Nebraska.
<davexunit>hello Sebboh!
<rekado>re etag issue on pypi: "We think we fixed it. Can you check and see if things work for you?"
<rekado>I can't check right now.
<davexunit>rekado: I will test.
<Sebboh>FYI, Fortinet firewall products block 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.
<rekado>davexunit: thanks!
<davexunit>Sebboh: ask whoever is in charge of that firewall to unblock gnunet!
<davexunit>rekado: what was a problematic URL?
<davexunit>ah, nvm.
<davexunit>rekado: problem is fixed!
<Sebboh>OT: davexunit, fortinet products don't work like that. The hardware manufacture controls the list. ...Which is considered a feature, I guess.
<davexunit>wow, that sounds horrible.
<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>Nix is almost a decade old project, btw.
<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.
<Sebboh>guix uses Guile, right?
<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>yes, Guile.
<Sebboh>I concur.
<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 :
<bavier`>rigelk: does it not use python-build-system?
<bavier`>oh, nvm, I see the comment now
<bavier`>make python an input.
<bavier`>gnu-build-system doesn't recognize the #:python argument
<rigelk>indeed, i’ve seen that
<rigelk>thanks, I was gonna try the input-way
<bavier`>see e.g. python2-pygobject-2
<mark_weaver>rekado: wow, they already fixed it. I'm impressed and pleased! thanks again :)
<mark_weaver>(the pypi problem, that is)
<mark_weaver>rigelk: does dbus-python not work with python 3?
<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 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>add (native-inputs `(("pkg-config" ,pkg-config)))
<mark_weaver>you'll certainly need dbus as an input as well
<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.
<rigelk>now making a fresher paste :
<mark_weaver>(also needed for 'package-with-python2' to work)
<mark_weaver>no need for the comment after the #:use-module line
<mark_weaver>the URI should be computed based on the 'version' variable instead of having the 1.2.0 hard-coded
<mark_weaver>the hash should be on the same line as the 'base32'
<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
<rigelk>guess I have to add that :-)
<mark_weaver>yep :)
<rigelk>as a regular input ?
<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