IRC channel logs

2014-04-01.log

back to list of logs

<civodul>problem is that i can't reproduce it locally
<mark_weaver>As I recall, the thread test took on the order of tens of seconds on the YeeLoong.
<civodul>could you try with just (setenv "CK_DEFAULT_TIMEOUT" "120") in a phase?
<mark_weaver>will do.
<civodul>ok, no rush though
<mark_weaver>thanks for looking into it.
<civodul>you're welcome!
<mark_weaver>that's good, because it will take my YeeLoong a while to rebuild pulseaudio :)
<civodul>ahah :-)
<civodul>BTW, it seems that davexunit & you annihilated each other's motivation regarding the Levenshtein thing :-)
<zacts>I want to get one of those GLUG fsf endorsed laptops
<zacts>the IBM thinkpad with a free coreboot
<mark_weaver>cool!
<zacts>I hope they don't sell out..
<zacts>I can't afford one for a while.
<mark_weaver>civodul: heh.
<zacts>I need to upgrade my guix.
<zacts>I want to contribute.
<mark_weaver>civodul: well, the main thing is that it was more complicated than he expected.
<mark_weaver>first of all, there's the fact that he has to deal with a regexp provided by the user, not just a fixed string.
<mark_weaver>and the other thing is making is reasonably efficient when there are a large number of packages to check against the user's regexp.
<civodul>yeah right
<mark_weaver>if you want an easy solution, we could make TRE <http://laurikari.net/tre/about/> an optional dependency and use it to do the job.
<civodul>i was just kidding ;-)
<mark_weaver>:)
<civodul>it'd be nice, but it's not this high-priority either :-)
<mark_weaver>I figured you weren't entirely serious, but at the same time I thought you might be interested in a possible solution :)
<civodul>:-)
<civodul>anyway, good night/day!
<mark_weaver>night!
<davexunit>I see that one of the fsf staff has opened tickets about adding a nix/guix backend for packagekit and gnome software.
<davexunit>does anyone have an idea about how difficult it would be? can the backend API even support something like guix/nix?
<davexunit>oh, just seeing civodul's mail now.
<davexunit>seems very difficult. the packagekit maintainers will need to be convinced to make big changes to support per-user installs.
<mark_weaver>hmm, I don't see why it would be that difficult, but admittedly I don't know much about PackageKit.
<davexunit>I don't either, but I anticipate possible cultural challenges in addition to the technical ones.
<davexunit>but maybe I'm just a pessimist.
<mark_weaver>I don't expect any technical challenges, but I also tend to expect cultural ones.
<py1hon>is there anything like a reference manual for making guix packages?
<mark_weaver>not really. we are a young project, and the language in which our recipes is written is still evolving.
*py1hon nods
<mark_weaver>here's a fairly recent intro though: http://www.gnu.org/software/guix/guix-ghm-andreas-20130823.pdf
<py1hon>just trying to get up to speed on it
<mark_weaver>on the plus side, you'll find that questions on the guix-devel mailing list are answered promptly, and there's help here on #guix as well.
<py1hon>cool :)
<py1hon>for the package source - is it possible to pull from git, or just tarballs?
<mark_weaver>it is possible to pull from git, but generally we prefer to use tarballs as a matter of policy.
<py1hon>how come?
<py1hon>if you just want to point at a specific version, you can just point it at a specific revision (which is what i was planning on doing anyways)
<mark_weaver>well, civodul is the main architect of guix so far, and I'm not sure of his exact reasoning, but for one thing building from git usually requires more prerequisite packages, and often very specific versions of those packages, e.g. autoconf, automake, documentation builders, etc.
<py1hon>oh - well, that's just autoconf brokenness
<mark_weaver>also, tarballs tend to be more widely tested.
<py1hon>anyways - if i want to package, say, bcache-tools for guix - suppose you could tell me where to get started?
<mark_weaver>I'm not sure I agree with that. there are significant costs to maintaining perfect compatibility, and advantages to allowing some flexibility in evolving. for example, linux (the kernel) has benefitted enormously from refusing to maintain compatibility in its internal interfaces (used by device drivers, for example).
<mark_weaver>py1hon: I'd start by looking over the pdf file I cited.
<py1hon>that's not exactly the type of brokenness i meant, but no worries :P
<py1hon>yeah, i am
<mark_weaver>py1hon: well, first of all, do you have a working guix installation?
<mark_weaver>if you're going to write packages, you should get guix working from a git checkout. that's step one.
<py1hon>possibly i'm missing it but i'm not sure like... where to stick this package description and what to do with it
<py1hon>yeah, i have it installed and guix pull is running
<py1hon>seems to be doing stuff, /gnu/store is getting bigger
<mark_weaver>put it in a file in gnu/packages/
<mark_weaver>if the file is in gnu/packages/foo.scm then it should have (define-module (gnu packages foo) ...
<mark_weaver>at the top.
<py1hon>will the other package descriptions be there when guix pull finishes?
<py1hon>err, is that /gnu/packages?
<py1hon>i just have /gnu/store
<mark_weaver>and then, from the top-level git checkout, run "./pre-inst-env guix build -K <package-name>" to try building it.
<py1hon>oh, within the guix git tree, i see
<mark_weaver>if you want to contribute your own packages, you should run guix out of a git checkout, so that means using "git pull" and "make", not "guix pull".
<py1hon>ok, knowing where to find all the existing packages will help greatly
<py1hon>guix pull giving you the latest tagged release, i take it?
<mark_weaver>and then using "./pre-inst-env guix ..." so you use the copy of guix in the git checkout as opposed to the "installed" version. in fact, there's no need to do "make install" at all in this mode.
<mark_weaver>the existing packages are all in gnu/packages/*.scm in the git checkout.
<py1hon>yeah, just found them
<mark_weaver>no, "guix pull" gives you much more recent snapshots of the master branch of git.
<py1hon>ok
<mark_weaver>but if you're adding packages, it's better to just "git pull" and then use ./pre-inst-env, in which case the stuff downloaded by "guix pull" will be ignored anyway.
<mark_weaver>"guix pull" is aimed more at end users who don't contribute packages.
<py1hon>i suppose i'll figure it out.
<civodul>Hello Guix!
<atheia>Morning!
<phant0mas>good morning guix
<phant0mas>civodul: I sent an email to bug-hurd yesterday, and I am working on the last issue I had,so I think I will find a solution to it today
<civodul>cool!
<gal_bolle>for french speakers: j'ai commencé une dépêche linuxfr sur nix ici: http://linuxfr.org/redaction/news/nix-nixpkgs-et-nixos-14-04; la partie guix est à l'image des connaissances que j'en ai (minimales), toute aide sera la bienvenue
<civodul>ooh, nice :-)
<civodul>oh but i need to log in?
<gal_bolle>yes
<gal_bolle>sorry about that, you can get an account at linuxfr.org
<civodul>ok
***teythoon_ is now known as teythoon
<civodul>phant0mas: please don't use HTML email on public lists
<civodul>this is generally frowned upon
<phant0mas>I didn't
<phant0mas>let me check
<phant0mas>I sent plain text
<civodul>hmm i see a text/html part on bug-hurd
<phant0mas>you mean the ">" ?
<civodul>anyway, free advice :-)
<phant0mas>civodul: thank you for pointing it out
<phant0mas>I will be extra carefull next time
<phant0mas>other that plain text I used the ">"
<civodul>no: the message contains two MIME parts, one of which is text/html
<civodul>so the mail client must be configured to not provide a text/html part
<phant0mas>I will change that right away
<civodul>don't worry
<civodul>it's no big deal, but it's better to avoid it
<phant0mas>of course, I will make sure to change my email configurations
<phant0mas>btw I kept the email as clear as I could to bug-hurd so as not to disturbe them, I hope I get an answer
<civodul>yes, that's great
<civodul>BTW, don't miss the latest road map: https://lists.gnu.org/archive/html/guix-devel/2014-04/msg00000.html
<civodul>gal_bolle: i managed to access the news page
<civodul>there are a couple of types: s/gnu/GNU/, s/guix/Guix/, s/guile/Guile/
<civodul>i would say that Guix is a package manager used as the basis of the GNU system
<civodul>gNewSense itself is "friends of GNU", but not part of the GNU project
<civodul>regarding the kernel, Linux-Libre is the main target, but we plan to also offer the Hurd
<civodul>phant0mas is working on it, and will probably do a GSoC
<civodul>regarding the technical motivations, what you wrote is OK, but maybe a bit vague ;-)
<civodul>please see http://arxiv.org/abs/1305.4584 for more details on that
<civodul>specifically, for the discussion of using an embedded DSL (as in Guix) vs. using a separate DSL (like the Nix language)
<civodul>also i'm a bit jealous that Guix isn't mentioned in the title and summary ;-)
<gal_bolle>civodul: i'll probably change the title and summary, but changing the title means changing the url for the draft so i'll do it when i submit
<gal_bolle>so Guix is currently the sole GNU distribution, right
<civodul>yes, although it's work in progress, so it cannot be used as a stand-alone distro yet
<gal_bolle>ok
<gal_bolle>i read in the Guix manual (I think) a part about booting to lisp, is that supposed to become the default at some point (or is it already)?
<civodul>yes there's support for booting a Linux initrd that runs Guile
<civodul>that's definitely going to stick
<civodul>and we can build VMs that run all the stuff
<civodul>but at the moment it wouldn't be reasonable to run on real hardware ;-)
<civodul>but we're getting there!
<civodul> https://lists.gnu.org/archive/html/guix-devel/2013-12/msg00120.html
<civodul>BTW, do not post it today! :-)
<gal_bolle>i think I'll post it whenever nixpkgs 14.04 is released
<civodul>ok
<dfsdfs>civodul: ping
<dfsdfs>civodul: re my yesterday question: should I try the current master?
<dfsdfs>civodul: (see https://gnunet.org/bot/log/guix/2014-03-31#T376995)
<davexunit>morning #guix.
<davexunit>I must say that I am _delighted_ to see that we're going to rewrite Guix in ECMAScript.
<davexunit>I couldn't think of a better language to use for writing a package manager.
<ArneBab>davexunit: not in the least! I violently disagree! http://draketo.de/proj/guix-js-wisp/
<dfsdfs>And curly brackets are nicer than parens.
<civodul>dfsdfs: pong
<civodul>dfsdfs: yes, try master, it should be fixed
<civodul>davexunit: aah, glad you like it
<civodul>interestingly, a Nix friend takes a similar approach: http://sandervanderburg.blogspot.com/2014/04/asynchronous-package-management-with.html
<davexunit>civodul: glad to see the nix/guix community realize that javascript is the future.
<civodul>indeed!