<lfam>Is it possible to roll back the Guix source tree? I tried `./bootstrap && ./configure --with-libgcrypt-prefix=/gnu/store/768cgiv2b8lhbx814d8yvsryq39bwjbb-libgcrypt-1.6.3 --localstatedir=/var && make`, but afterwards I get Guile error about the PKG_CONFIG_PATH <lfam>Here's `git status` and `./pre-inst-env guix build hello` <lfam>I suppose I might be going back too far. I want to `git bisect` the failure of python-urwid on x86_64 <lfam>I meant to say that I started with `make clean` <mark_weaver>lfam: as I recall, python-urwid has _never_ built successfully <mark_weaver>but the way to roll-back the source tree is to use git <lfam>I checked out the commit that introduced it, but I can't get the Guix I built from that commit to work <lfam>Can you scroll to the end of my paste? <lfam>I don't understand it yet <lfam>That's after rebuilding Guix from the checkout <mark_weaver>lfam: you probably need to do "make clean-go && make" <mark_weaver>every once in a while, we make changes that "make" by itself won't probably handle, because of missing dependencies in the makefiles. <mark_weaver>also, better make sure that GUIX_PACKAGE_PATH is not set, because it might refer to a directory with packages that depend on some feature in Guix that's not available in the older version. <mark_weaver>lfam: btw, I suspect you'll find that it takes a long time to build packages from such an old version of guix, because the binary substitutes from March are probably no longer available on hydra <lfam>So, you think I should try `unset GUIX_PACKAGE_PATH && guix environment guix && git checkout e99f4211 && make clean-go && make`? <lfam>Oh man, I didn't think about that. Hopefully it's not too much. <mark_weaver>when we replace hydra.gnu.org, we'll have more disk space and won't need to GC it so aggressively. <mark_weaver>depending on how fast your machine is, I guess it'll probably be on the order of 12-24 hours to build those old packages. <mark_weaver>honestly, if it were me, I wouldn't bother with the git bisect, and instead just try to debug the problem. <lfam>Yeah, it would be nice if it worked, but I think in this case it's not going to be worth it <lfam>I bet it was the upgrade to python-3.4.3. That's the only obviously python-related change in the window between the last successful build and the first failing build <mark_weaver>currently, none of our packages depend on python-urwid, and only one package depends on python2-urwid: wicd. it's needed for the wicd-curses client. <lfam>`git log --since=2015-03-20 --before=2015-04-19` <lfam>I am trying to package something with it <mark_weaver>lfam: to be more precise, you can find the commit ids of the two evaluations: the last one that successfully built python-urwid, and the first evaluation where it failed. <mark_weaver>but 'wicd' is abandoned upstream, and maybe we should just drop it now that we have network-manager (although I confess I haven't yet tried our network-manager-service) <jroh>is there a way to blacklist kernel modules through system config? <fps>why does (guix licenses) import freetype? <fps>WARNING: (nonfree packages mozilla): `freetype' imported from both (guix licenses) and (gnu packages fontutils) <fps>it's interesting, cause licenses.scm _exports_ a name freetype <fps>no, it's obvious, i'm just dense <fps>damn germanism sneaking in "imported by" is different from "imported from" :) <fps>actually for distributing builds frrom hydra a torrent would be much simpler :) <fps>instead of getting gnunet running <fps>oh boy, no vnc packaged :) <fps>hmm, i wonder how to setup serial console in guixsd <fps>especially if i can't boot the image right now.. <fps>or i can boot it, but have no way of getting input into it ;_) <fps>damn, oh, xmonad is broken: <digit>i heve gentoo on my kimsufi... guix on kimsufi wud be nice. <fps> fps@cherry 10:25:46 ~ $ xmonad --recompile <fps>xmonad: ghc: runProcess: runInteractiveProcess: exec: does not exist (No such file or directory) <digit>fps, xmonad isnt broken, so long as u dont want any contrib extensions <fps>ghc is not propagated anymore? maybe i need to guix pull ;) <fps>i'm still on 0.9.0 i think on this box <fps>digit: and yes, that's the plan :) get a kimisufi box for my guixsd build box <fps>my xmonad is super vanilla :) <fps>i just set a different terminal :) <fps>cause xterms is a crime against humanity <fps>xfce's click to focus screwed me over there ;) <digit>^_^ xterm i dont mind. i think i care more about my shell than my term (zsh was mildly nicer than bash in some conveniences, but fish takes completion to another level... and some day i'll make xiki my main interface) <digit>terminology's nice, for a feature&graphical heavy term. ^_^ <fps>lxterminal is decent, too <fps>hmm, the guix pull and reconfigure didn't change much <digit>thnx to crunchbang, i used terminator for a while... but that was before i learned the advantages of the likes of screen/tmux. ^_^ <fps>i also love vim and hate emacs, even though emacs is decent <fps>there's a package ghc-xmonad-contrib <fps>let's try that instead of xmonad <fps>maybe at least --recompile works then <fps>emacs is a great tool <fps>it's powerful, etc.. <fps>i just don't like its keyboard handling, default configuration, etc, pp <digit>i have ghx-xmonad-contrib too, n it seems insuficient, at least for my "tabular boonad" config <fps>emacs doesn't even have scrolling in such a way that the cursor returns to where it was before <fps>i guess one could configure it <fps>emacs does all kinds of funky things that are totally weird, but they do have some logic and good reason somewhere <fps>that menu and toolbar? geeze, customize-variable tool-bar-mode and menu-bar-mode and turn them off is the first thing i always do <fps>they are utterly useless <digit>Matt Adereth's talk (the one that inspired me to buy a kinesis advantage, n ponder buying a 3d printer too) showed the keyboard emacs was developed on. ^_^ it made so much more sense for that keyboard. heh <fps>and RMS probably still uses one of those keyboards <taylan>fps: (setq scroll-preserve-screen-position 'keep) <fps>that's why things never change <digit>yep, no menu bars in my emacs ever. ^_^ <fps>taylan: yes, i cannot be bothered to make emacs sane on _every_ system i setup <fps>or have to bother to share the config via some git repo or similar <fps>just because the defaults suck so hard :) <taylan>Vim defaults aren't very great either IIRC. not to say two wrongs make a right. <fps>true, learning to cope with vim is much simpler than learning to cope with emacs though <fps>though that's not saying much <fps>vim is a nightmare, too <taylan>in fact I seem to remember Emacs having more useful features enabled by default, like syntax coloring... <taylan>I don't think learning to use stock Emacs is that difficult <fps>yes and that useful feature of garbling ever source code it touches :) <fps>the auto-indentation, magic fence, or what was it called? <fps>it kind of works for guixsd's scheme files <fps>but it basically destroys everything else unless you stick to gnu's coding conventions <fps>or unless you learn how to write your own major mode <digit>ACTION recalls the learning curves image... emacs starts gentle, then goes loopy, vi starts with a brick wall n stays that rock hard. ^_^ <fps>but don't get me wrong.. emacs is pretty cool <fps>i just hate it with a passion, that's not entirely to be taken seriously <digit>indeed. editor wars are cute these days. <fps>i accepted vim into my life <fps>i have yet to accept emacs ;) <fps>though in guixsd it has a place at least <taylan>fps: that sounds hyperbolic. Emacs doesn't break any indentation; it applies whatever style you choose. in C files this can be changed via M-x c-set-style <fps>ok, take the default config of emacs and open guix/nix/guix-daemon/daemon.cc <fps>and try to change one of the options.. it'll indent-break it to hell <digit>i may yet try evil mode someday. i think it was the modes, n needing to hit i to enter insert mode that most put me off vi. ^_^ <fps>digit: yeah, you either get used to that or don't :) <fps>i don't blame you at all :) <fps>being able to do: 20 x <fps>to delete 20 chars from the cursor is useful though.. <digit>emacs has many such things. heh <fps>or want to paste a line 10 times, 10 p <fps>it does, it's turing complete <taylan>fps: it doesn't indent-break anything for me. <fps>just being turing complete doesn't make a good language though ;) <fps>taylan: then you have changed your config :) <taylan>I'm guessing it was your config that was broken ;) <fps>in libstore/globals.hh <fps>i went to line 18 and pressed tab <fps>this is the 21st century ;) <taylan>the file doesn't specify what style it uses, so Emacs uses its default. what's weird here? <fps>pressing tab kills the indentation.. <taylan>it doesn't kill it, it applies the indentation style in effect <taylan>does vim auto-detect the style of C code? <fps>it just let's me enter characters that i want unless i tell it to do something special <taylan>so, it doesn't do any auto-indentation by default? <fps>and that's an awesome thing :) <taylan>that's not what I expect from a programmers' editor <amz3>in some situations it's useful, but most of the time I want auto-indent <amz3>vim or rather vim is quite good for reading very long files <fps>in the end it comes down to personal taste anyways.... <fps>yeah, i don't use vim to hack c++ code, for example, either.. <fps>most of the time: kate.. <taylan>well I think you shouldn't be so vehement against other peoples' taste :) <fps>like i said: emacs is super cool :) <fps>10:55 < fps> i just hate it with a passion, that's not entirely to be taken seriously <fps>emacs' default style even mixes tabs and spaces iirc <fps>when was that ever a good thing? :) <amz3>yes, it has some beginner flaws, that said programming is very streamlined compared to other editors I tried <amz3>my .emacs is not event 1K LOC <taylan>on one hand you say it's just personal taste, on the other hand you continue to publicly complain about it... <amz3>did some read the article on HN about the subject? <amz3>this sound like emacs-guix somewhat <taylan>fps: what I meant to point out is that this contradicts itself. (it's also off-topic and I feel bad for continuing the discussion.) <fps>heh, i thought it was entertaining and in good spirit <fps>i can shut up as well <fps>i wanted to package a vnc viewer anyways <amz3>anyway, the article question whether there should be more integration between compiler, build systems and packaging <amz3>in the spirit of go and rust. That said, guix goes a step further in the sens that it can integrate many build systems <amz3>there is also, IIRC a hint at how IDEs work hand in hand with the build system <digit>ACTION check his .emacs, n is surprised to see it too is not under 1000 lines (including the vast amounts of it commented out), and wonders if he adds just a couple hundred more lines, he'll no longer be an emacs noob. <digit>oops, edit fail. "it too is under" <fps>hmm, tightvnc has its configure stuff in a subdirectory <fps>is there a way to change into that before the configure phase? <fps>otoh it has an IMakeFile in the toplevel.. <fps>contents of the tarball <anonymiss>I progressed a bit with gnunet-gtk, but I'm unsure if my issues are related to packages not yet existing or the way they were packages/build. in particular gnunet-gtk keeps complaining about gladeui-2.0 >= 3.10.0 not being found and that libunique would be nice to have. <efraim>I took a quick look at gnunet-gtk a month ago or so, and I saw I needed to package glade3 since it was different than glade that we already had <efraim>but maybe with glade and glade3 switched <fps>hmm, my scheme-fu is still too weak <anonymiss>hm.. I'm used to portage, so I need to wrap my head around other systems first. comparing to my existing gnunet-* builds wasn't completely productive. gnunet is sort of pointless currently without gnunet-gtk <fps>anonymiss: are you working from a guix git clone? <fps>and using ./pre-inst-env? <fps>maybe show us your package definition, tell us in what file it lives and the errors you get :) <efraim>fps: after (add-after 'unpack ... you need to name the new phase, so it would be something like (add-after 'unpack 'chdir ...) <fps>efraim: oh ok :) i thouight the ones i saw referred to multiple phases :) <fps>never occurred to me that it was a naming :) <fps>anonymiss: working in a qemu? <fps>efraim: thanks. progress. now i need to get some inputs in order <anonymiss>like, guixsd on an old netbook, and typing this on another computer <fps>anonymiss: install openssh on it, and run your irc client in a tmux.. connect to your main machine from the laptop via ssh and attach to the tmux session :) <fps>but i'm just blabbering. ignore me if too noisy ;) <fps>hmm, i wonder what package has xmkmf <fps>it seems imake, as xfig has that as native input and uses it via system* <anonymiss>might take a bit longer since I forgot to install anything ssh-like on guix, but i'll just post the two files. fps: I use webchat for a reason (and separate machines for tasks), I don't really see much future in irc, but that's another story. could've used tor-laptop > ssh to server > irc-freenode though <fps>anonymiss: no worries, but i thought seeing the code and the error might be useful <fps>and yes, IRC is broken <efraim>what's involved other than downloading it and dropping it into $PATH <fps>getting python into the path :) <fps>guix environment might help though.. <fps>and also having it one guix package -i python-pastee away would be nice :) <fps>anonymiss: openssh has scp <anonymiss>i know about openssh, i just thought lsh, which i didn't use before, had scp as well <fps>maybe it does and the package has a bug. i don't know :( <anonymiss>i can only find results that it was planned in 1999. no idea about where they are now. <anonymiss>I'll be away for a short while because I need to eat, so I'll reply later <fps>i'm at a loss, too, right now. maybe the gurus can take a look <efraim>`guix package -A glade` shows that our glade is only 3.8.4 <fps>oh right. good eyes :) <fps>btw: unrelated question: with many tools i get certificate verification errors, like using git over https <efraim>looks like you'll need a new copy of glade, last I checked glade3 can be upgraded to 3.8.5 but glade is ~3.18 <fps>ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590) <anonymiss>before I'm afk for a while, what about experimental feature builds in gnunet? there's an marked as experimental subset of functions which provide conversation, qr, tex, functions. or maybe it's no longer experimental now. <efraim>fps: if you add [http] sslverify = false <efraim>to .git/configure it won't check ssl <fps>efraim: that works for git, yes.. <efraim>er, right, should reread the question :) <fps>is there maybe something wrong with ssl itself? <fps>i never needed that on other OSs <anonymiss>for now I would be happy if I can finish gnunet-gtk and make it work. okay, afk now. <efraim>I have export SSL_CERT_FILE=/etc/ssl/certs/ca-certificates.crt in my .bashrc <fps>oh ok.. interesting.. <fps>fps@cherry ~$ ls /etc/ssl -l <fps>lrwxrwxrwx 1 root root 35 Dec 8 10:48 /etc/ssl -> /run/current-system/profile/etc/ssl <fps>fps@cherry ~$ ls /run/current-system/profile/etc/ssl <fps>ls: cannot access /run/current-system/profile/etc/ssl: No such file or directory <efraim>I don't have guixsd installed on any machines <fps>ok, changing one line makes pastee.py work <fps>fps@cherry ~$ echo foo| python2 Downloads/pastee.py <davexunit>ACTION tries to find the source of the /bin/sh issues with the node 5 test suite <fps>anyone else running guixsd experience certificate validation problems? <fps>e.g. in git, or pthon apps <fps>davexunit: hmmm, i copied .bashrc and .bash_history over to my home dir from /skel... <fps>davexunit: what's the relevant env var? SSL_CERT_FILE? <anonymiss>efraim: so updating glade is a process which would be doable or are there any possible issues with this? <fps>fps@cherry /var/guix/profiles$ echo $SSL_CERT_DIR <fps>fps@cherry /var/guix/profiles$ echo $SSL_CERT_FILE <fps>/etc/ssl/certs/ca-certificates.crt <fps>but /etc/ssl points into the void <davexunit>fps: which means that you didn't install any certs <fps>davexunit oh, i need to install them manually. ok <davexunit>fps: well, not "manually", but they should be present in your OS config file <fps>i must have removed that package by error at some point in time <fps>davexunit shows up, hydra goes down ;) <davexunit>we really need a new hydra. we can't scale up anymore until we do. <fps>btw: just distributing the substitutes could be done much simpler via bittorrent than going full blown gnunet <fps>every machine that has a package installed would keep seeding it :) <fps>just distributing the binaries, not talking about decentralizing the build yet <anonymiss>fps: distributing through gnunet would have the added bonus that you don't need to rely on anything other than the gnunet-stack if you no longer want to use the old stack when gnunet is operational with applications on top of it. <fps>anonymiss: i agree about a solution on top of gnunet or some other secure cryptographic distributed system would be better <fps>i'm talking about a mid term load easening ad-hoc method :) <anonymiss>so you mean to move from hydra-currently to $something-distributed to gnunet <fps>yes, hydra has several bottlenecks <fps>one of them seems to be just disk io and network bandwidth for delivering built substitutes <fps>hosting the files in a bittorrent swarm would help with that part <fps>and allow it to spend its few io cycles on building <fps>oh ok, so it's overloaded with serving files already ;) <fps>i might be missing quiete a few details though. authentication issues aside what would stop me from uploading an archive of the contents of a gnu store path to a torrent tracker and sharing the .torrent file? <davexunit>whoa whoa whoa, we don't have nethack packaged!? <anonymiss>could I just try and update glade3 for gnunet-gtk? I'm not sure about the outcomes of this. on gentoo/portage there are slots (3 and 3.10 for dev-util/glade).. I'm not yet sure if it would break some packages if I update glade on guix or if I haven't understood the full complexity of guix yet. <davexunit>anonymiss: you can make your own special glade package to see if it works <davexunit>without modifying any of the existing package variables <anonymiss>okay. but just to understand guix a bit more, there aren't any hardcoded dependencies of packages depending on just this one version of glade you use, and by changing the version, one would have to deal with the resulting conflicts which could happen at build time? <davexunit>anonymiss: there might be, which is why I'm suggesting that you instead do not touch the existing glade variable <fps>easiest is probably to inherit frrom the original glade package? <davexunit>yes that's usually what you'd want to do, but if you're just getting started it's OK to just copy/paste the entire thing <anonymiss>I see. okay, I'll try if I can work some more on it later this day. as much as I dislike irc, I should setup weechat again on a laptop which isn't routing everything through tor. issues are solved faster :) <fps>just give it a new name, variable and change the version. then use that as input to gnunet-gtk <davexunit>it's important to understand that packages are nothing more than regular Scheme objects, some of which are bound to variables for us to reference elsewhere. <davexunit>that's how we have packages that share the same dependencies. <davexunit>so it's easy to make your own package objects, and maybe bind them to some other variables of your choosing. <fps>but if you give it the same name, once you use guix package frrom the commandline to install glade you'd have to disambiguate? <fps>sure in the gnunet-gtk package you'd just use the other variable <fps>doesn't guix package -i glade go by the package name? <davexunit>this new glade need not be a public variable <fps>davexunit: ok. got ya <fps>tightvnc is a beast to package. so many references to /bin/sh ;) <anonymiss>hm. interesting. it's interesting to learn a bit of scheme at the same time while packaging, I only learned about scheme because I looked at guix, I like it so much I'll just take my basic python knowledge and learn more about scheme/guile. <davexunit>fps: their configure/makefile does not respect the environment variables we set to specify the shell, apparently. <davexunit>guix is great at exposing terrible assumptions made it all sorts of software. <fps>davexunit: yep. it's quite a mess of make, imake and autotools :) <fps>i should maybe just do a global search and replace of /bin/sh to the right thing ;) <fps>but that would be giving up ;) <davexunit>you'll probably need to do something close to that via 'substitute* <fps>that's a grep for /bin/bash <fps>i'll look for another vnc viewer to package. this is too horrible <fps>maybe that's unnecessary though: i wonder how to enable serial console on a guixsd installation <mark_weaver>fps: do you need to enable the serial console within GRUB, or would it suffice to enable the serial console for linux-libre? if the latter, see section 7.2.2 ('operating-system' reference) of the Guix manual, specifically the 'kernel-arguments' field. <mark_weaver>if you need the serial console within GRUB, then you'll probably need to hack the code that generates the grub.cfg. see 'grub-configuration-file' in gnu/system/grub.scm <fps>mark_weaver: thanks. i was wishing i could get into my guixsd image on a remote server without vnc, since i have no vnc viewer here <fps>mark_weaver: but it seems i'm out of luck and will have to try packaging another vnc viewer later.. <fps>gotta run. thanks for the tips thoug ***digit is now known as Digit
<civodul>pity that ftp.gnome.org doesn't provide signed packages <bavier>I just learned my team has an opening for a builder/integrator <civodul>bavier: what do you mean exactly by "builder/integrator"? <davexunit>ACTION tries to figure out node 5 test failures <bavier>civodul: employee who takes the team's software and preps it for shipping to the customer <bavier>basically means managing buildbot instances, CI services, RPM creation, testing, etc <civodul>so your team develops its own pieces of software? <bavier>civodul: to a degree, optimized versions of foss libraries <bavier>if anyone here is looking for such a job, or knows someone who is, let me know <bavier>the job hasn't been posted yet, but I can share a link when it is. <civodul>mark_weaver: looks like 'security-updates' can be merged now, no? <civodul>everything appears to be built on x86_64 <mark_weaver>civodul: already done, although I cherry-picked instead of merging. <stack>hello, I'm new to guix, even if I saw nix some time ago, I'm searching on the list archives some rationale on why guix exists and the development wasn't focused on nix/nixos alone, was that because of the license, systemd "requirement", conf language or none of the above? I find this project amazing and I would like to give it more attention, maybe even hacking on it a bit, but when I see those <stack>effort separations I need to figure out what is happening , can someone give me some hints? thanks <davexunit>mark_weaver: there's also 'git merge --rebase' that may be useful in this scenario <davexunit>this is how I merge all branches such that the history stays linear. <davexunit>stack: short answer is: we think Scheme + embedded DSLs (macros) are better than a custom DSL, and we are also committed to providing only free software. ***exio4 is now known as hacker
<davexunit>ACTION really wants to package dto's fun common lisp games <stack>davexunit: thanks for the tldr version :) <davexunit>but we need a quicklisp build system probably <stack>davexunit: for the scheme part, wasn't that possible to build that on top of nix/nixos already? <davexunit>stack: well, no, because Nix is its own special language. <df_>ACTION would like a quicklisp build system in order to package stumpwm <davexunit>stack: Guix uses the same low-level utility as Nix: the build daemon <davexunit>stack: Nix expressions are a combination of the custom Nix language and Bash for build scripts. Guix uses Guile for everything instead. <stack>davexunit: so the build daemon is still the same among the two systems? <davexunit>we have diverged to some degree, and I imagine we will continue to do so and eventually we'll have our own daemon written in Guile instead of C++. <civodul>i think we are doing OK for some (most?) of these points <civodul>but it's insightful to seem them listed <davexunit>is there a particular piece of documentation that would be good to show someone that wants to know more about how we isolate builds? ***anonymiss_ is now known as anonymiss
<davexunit>anonymiss: both of those packages provide the same file <anonymiss>in practice i thought this gets pointed out before installing. <anonymiss>so not a real collision as packages are isolated from each other in some way (or what it was)? <davexunit>the collision is during the union of all the selected packages to form your profile <davexunit>a profile is a "symlink forest" to all of those store items <rekado>anonymiss: in many cases you can install packages into different profiles to avoid errors like this. <fps>btw: i have gotten zero feedback on whether adding options like --cache-timeout-failures and --cache-hook-failures are welcome for guix-daemon or not.. <fps>warnings are always ignored ;) that's why i use -Wall -Werror -pedantic on all my C and C++ code usually <fps>warnings are for all intents and purposes not existant <fps>unless treated like errors ***hacker is now known as exio4
<fps>i still get ssl handshake errors <fps>ERROR: Throw to key `gnutls-error' with args `(#<gnutls-error-enum A TLS warning alert has been received.> handshake)'. <fps>even with package nss-certs installed <efraim>wget gave me GnuTLS: received alert [112]: The server name sent was not recognized <civodul>Alert[1|112] - The server name sent was not recognized - was received <efraim>and then redirected to an http address <civodul>(you can uncomment the debugging stuff in (guix build download) to get that) <fps>so it's a problem on their side? <fps>i.e. server config pro <mark_weaver>civodul: btw, it turns out that my video playing problems are kernel-related. it seems that linux-libre-4.2.x on the Libreboot X60 has issues where I often have to reboot to get video working again. <mark_weaver>and the problem I had with "guix system build" was fixed by "make clean-go && make" <mark_weaver>yeah, it may be that we should have some older kernel versions that are still supported upstream. <mark_weaver>it seems that i686 is so seldom used by developers these days that things are often broken there :-( <fps>btw: shouldn't it be easy to make a macro that takes a list '(foo bar baz) and maps it to '(("foo" ,foo) ("bar" ,bar) ("baz" ,baz))? <fps>probably a good exercise for getting into writing macros? :) <anonymiss>rekado: ah, thanks. well that's a thing for me to learn later on. i only started 3 days ago with guixsd, so the more important thing to me is packaging :) <mark_weaver>fps: yes, it can be done fairly easily, but I'm not entirely sure it's a good idea. <fps>i have written the same string twice once too often <mark_weaver>the main issue is that it would obscure the connection between the quoted strings used in 'assoc-ref' calls and the actual inputs. <fps>mark_weaver: i see your point. hmm.. i guess it being well documented in the package definition docs would help then <fps>then the other way around might be more obvious :) <fps>btw: shouldn't it be easy to make a macro that takes a list '("foo" "bar" "baz") and maps it to '(("foo" ,foo) ("bar" ,bar) ("baz" ,baz))? <fps>can't have the cake and eat it? <mark_weaver>bare identifiers like 'foo' are "syntax objects" during macro expansion, and their connection to the associated lexical bindings are kept track of <fps>all right. understood <mark_weaver>converting a string literal to a variable reference that gets the right binding is less robust than going the other way around. <mark_weaver>another issue is that there's another form for inputs that have three elements: ("foo" ,foo "out") <mark_weaver>which causes "foo" to refer to the "out" output of package 'foo'. <fps>those would be special cases. noone's stopping anyone from appending a mapped list to a "bare" list.. <fps>(inputs (append (magic '(foo bar)) ("baz" ,baz "out"))) <mark_weaver>sometimes, we need to include multiple outputs of the same package as inputs. <mark_weaver>so, you might need ("foo" ,foo) ("foo:lib" ,foo "lib") <fps>oops.. got some parans wrong.. <mark_weaver>yeah, it's just that when you need to do that, the code becomes even more obscure <fps>(inputs '(append (magic '(foo bar)) (("baz" ,baz "out")))). don't quote me on the quote though ;) <mark_weaver>the thing is, there's a difference between the quoted string and the variable reference. <mark_weaver>sometimes, we need to include the same package in both 'inputs' and 'native-inputs', for example, and it may be important for them to have different keys (the strings) so that they can be referenced unambiguously. <fps>mark_weaver: yeah, i'm only intending to use this in cases where those special cases do not apply.. <mark_weaver>I guess the thing is, as we add more layers of macro sugar, the connection between what you see and what the resulting code becomes is more complex, and it can seem increasingly like magic. <fps>point taken, it's a fine line.. <fps>but it kind of irks me to type the same string twice over and over.. <davexunit>I've thought this over several times and the only thing that would make sense to me would be to add bare packages to the list if you want to use the package's name verbatim and use the default output <davexunit>the downside there is that there's yet another pattern to match for <civodul>the ("foo" ,foo) form is here just because we needed a way to refer to packages on the build side <fps>by string, yes, though the details elude me still.. <davexunit>civodul: do you think we'll ever be able to switch away from it? <davexunit>given there's ~3000 packages using this style. ;) <fps>well, it's all scheme code <fps>should be easy to transform ;) <fps>ACTION runs and hides.. <Digit>ACTION covers his eyes and counts <mark_weaver>I'm sure the conversion could be automated to some extent, but there are several places where the string key does not match the variable name. <mark_weaver>and also the formatting of comments would get messed up <civodul>that could be done semi-automatically, incrementally <civodul>but at this point it's just speculation :-) <davexunit>I'm curious what you'd think a better syntax would be here <fps>well, about the formatting: load the file in emacs headless and mark the whole buffer and call indent-region? <francis7><mark_weaver> civodul: btw, it turns out that my video playing problems are kernel-related. it seems that linux-libre-4.2.x on the Libreboot X60 has issues where I often have to reboot to get video working again. <civodul>davexunit: just (inputs (list foo bar baz)) and then, say, #~(string-append "--with-foo=" #$foo) <francis7>I need to know what caused the regression. <fps>no? i thought emacs was cool... ;) <civodul>davexunit: though that brings its own challenges <fps>Digit: now is the time to start counting ;) <Digit>ready or not, here i come. ... oh, there u are, fps, found you. <mark_weaver>francis7: mplayer reports "X11 error: BadAlloc (insufficient resources for operation)" <mark_weaver>other video players fail as well, but with no good error reporting. <mark_weaver>my X60 also seems significantly less stable than it was with older kernels. often it seems to just freeze, and I can't get it to do anything at all and must reset it. <mark_weaver>but I suppose the X60 is of less interest given that there's the Libreboot X200 that works much better in almost every respect. the only reason I'm using the X60 now is because of a hardware problem with my X200. <vindarel>Hi all, last time I came here I asked if there is a debian package, and there is not. So I tried, and eventually encountered an error during the compilation which seems more related to guix than to the debian package. Would you like to have a look at it ? https://gitlab.com/vindarel/guix-debian/issues/1 <vindarel>it's somithing like "ice-9/boot-9.scm:106:20: no code for module (json)" <vindarel>thanks for your comments that may help me understand. <fps>btw: general git workflow question: <bavier>vindarel: others may know better, but I think the 'guile-json' package was inadvertently made a required dependency in the 0.9.0 release <fps>do you only ever work on one package at a time? <fps>and git amend your commits to keep a single commit ready for format-patch? <fps>i like feature branches. i have one for redshift, gparted, swh-plugins-lv2, etc.. <bavier>fps: we generally like a single package per commit <fps>i can do git diff master redshift.. <fps>and get something like this: <vindarel>bavier: you mean it's a de facto dependency but they forgot to write it ? <fps>bavier: that's cool. i guess i could then git apply that diff to master and generate a single commit and a format-patch for it <fps>and then revert master ;) <fps>but that sound heavy handed <bavier>vindarel: yes, there was a bug in guix/scripts/refresh.scm that made guile-json a hard dependency, rather than an optional dependency, that was fixed in b58d2db <fps>so my question realy is more about: how do you guys manage working on separate packages? <vindarel>Good to know. I must work with a release tarball, so I'm afraid I can't pull that commit. How shall I do ? I'll try to install guile-json with guix and re-build the package. <fps>especially across machines, etc.. branches are so useful, and fine grained commits, too.. hmm, sure one can squash them down to a single one once one's happy, but it seems to me people here live wihtout feature branches? <davexunit>vindarel: you could apply just the patch that fixes the issue <bavier>fps: I generally `git rebase master` from a package branch once I've got the package working <fps>bavier: ok, interesting. thanks for the hint. will read up on it.. <bavier>fps:I use feature branches locally quite a bit, especially for parking commits that are awaiting review on guix-devel <fps>bavier: and squash commits down to one in the package branch before that? <bavier>fps: yes, if I had several commit to get the package in working order <francis7><mark_weaver> but I suppose the X60 is of less interest given that there's the Libreboot X200 that works much better in almost every respect. the only reason I'm using the X60 now is because of a hardware problem with my X200. <francis7>it's still of interest. I wish to maintain it properly, so regressions like this should be fixed. I'm glad that you brought it to my attention. <francis7>Even if you don't have time to bisect it properly, could you try to submit a full bug report to the libreboot mailing list? <fps>hmm, pavucontrol is missing icons, too.. weird.. <mark_weaver>francis7: I said it was of "less interest", I didn't say it was of no interest :-P <mark_weaver>anyway, I respect that you want to continue supporting it, and I also think it's useful work. <mark_weaver>it's just that I've got more useful work than I can possibly do <mark_weaver>I can sent a message to the mailing list with the information I have, but I'm afraid it won't be a very good bug report. <fps>damn, now i need to try out qtile :) <fps>awesome lightning talk about it ;) <francis7>mark_weaver, a little is better than nothing