IRC channel logs

2014-11-09.log

back to list of logs

<davexunit> https://gitorious.org/sly/sly/source/dbd9a0c81bebbd424a1d5635f72b48271c4e6c76:package.scm
<davexunit>development environments made easy, with guix!
*davexunit thinks about write a guix environment for guix :P
<davexunit>I've been using this channel as my personal microblog today, apparently
<davexunit>so here's more: I was able to use guix environment to debug test suite issues with guile-sdl :)
<Steap>davexunit: looks cool
<Steap>must be even better than guix build -K
<davexunit>Steap: yes, I found it to be.
<davexunit>helped me track down the problem pretty quick :)
<davexunit>funny, I didn't even think of this use-case when I wrote it.
<davexunit>if anyone is interested, I decided to write a new blog post to elaborate on why guix environment is cool: http://dthompson.us/reproducible-development-environments-with-gnu-guix.html
<jmd>What does and=> mean ?
<jmd>I can't find a mention of it in any Guix, Guile or Scheme manual.
<alezost>jmd: it is documented in Guile manual: (info "(guile) Higher-Order Functions")
<alezost> -- Scheme Procedure: and=> value proc When VALUE is ‘#f’, return ‘#f’. Otherwise, return ‘(PROC VALUE)’.
<jmd>So its the same as (and value (proc value)) then?
<alezost>jmd: almost, it's just a sugar. If VALUE is an expression, you'll have to do (let ((v (<some-expr>))) (and v (proc v))) or just (and=> (<some-expr>) proc)
<jmd>ok.
<jmd>Another scheme question: If I do (and expr1 expr2) is there any particular order in which expr1 and expr2 are evaluated?
<alezost>jmd: expressions in ‘and’ are evaluated consecutively (expr1 first) and if one is failed then the rest are not evaluated
<jmd>ok thanks.
<roptat>hello again! I would like to modify /etc/profile to have some system-wide configuration there. Can I go ahead and edit the file it points to, or is there another prefered way?
<alezost>roptat: If it's a link to /gnu/store/…, then you shouldn't modify that file. (I don't know about the preferable way though)
<roptat>yes, it is a link to /gnu/store/*-bashrc
<alezost>roptat: everything that is placed in the store should be untouched
<roptat>I thought so...
<alezost>roptat: I can't help with your question as I hadn't tried a stand alone system yet. You may ask later on this channel or ask at <guix-devel@gnu.org>
<roptat>sure
<roptat>have to go. Bye :)
***tschwing_ is now known as tschwinge
*davexunit is brainstorming titles for his libreplanet talk proposal
<davexunit>"gnu guix - blanky blank blank"
<agumonkey>hello
<agumonkey>I got gnu-usb-install-0.7.x86_64.xz and thought that the decompressed data would be an .iso image
<agumonkey>to be fed to virtualbox as a bootable device
<agumonkey>I was wondering if you knew a way to convert
<davexunit>it's a raw disk image. can virtualbox not handle that?
<davexunit>people occasionally ask about isos, but we can't see a good reason for them as they are quite outdated.
<agumonkey>davexunit: it seems that vbox needs explicit conversion
<agumonkey>unfortunately a typo under the wrong account erased the vbox convert tool. #fail
<davexunit>you could use qemu instead, if that's an option for you.
<agumonkey>Ill try that as a fallback thanks. Reboot time
<davexunit>there are some caveats that come with the 0.7 release image, fyi. our upcoming 0.8 release should have less gotchas.
<agumonkey>hi back
<agumonkey>ok, dd image converted into vbox .vdi, and running. Time for install/rtfm
<davexunit>woo!
<davexunit>one important thing to note is that the 0.7 installer will install guix 0.6
<agumonkey>the host system is pretty .. raw
<davexunit>yes it is
<agumonkey>it needs to have emacs-nox with geiser mode
<agumonkey>that's the least it can do
<davexunit>you can install that
<agumonkey>ha
<davexunit>and you can easily tweak the install os to have that.
<agumonkey>guix build $pkg right ?
<davexunit>guix package -i emacs
<agumonkey>ha
<davexunit>guix package -i emacs geiser
<davexunit>it would of course be better to write your own os config with these packages so that you don't have to install to ramdisk each time
<agumonkey>agreed
<davexunit>we opted to ship a very minimal image to conserve resources
<agumonkey>I understand
<davexunit>it's also the first bootable image for real hardware
<agumonkey>but a guile based system needs a paredit-like editor
<davexunit>guix package -i paredit # :P
<davexunit>the system is what you make of it :)
<davexunit>it's super easy to roll your own OS config
<agumonkey>I'm about to do that
<davexunit>cool!
<agumonkey>you're running a guix based system ?
<davexunit>running debian right now
<agumonkey>(shame (on you))
<davexunit>:P
<davexunit>I test full systems sometimes.
<davexunit>I don't really have hardware to spare for an experimental system.
<agumonkey>not long ago I used an archlinux script to compile a livecd with base, emacs, guile and such
<agumonkey>arch is great, but nix is pretty awesome so Ill redo that in guix
<agumonkey>aight
<davexunit>cool, that would be fun.
<davexunit>I hope that we'll have an ARM port soon enough, and then I'll have a system to run guix standalone.
<davexunit>I've focused a lot of my time working on development workflows using guix
<davexunit>which doesn't require the full system, it's easy to run guix on any distro.
<davexunit>now, I want to make it easy to hack on guix... when using guix.
<agumonkey>you're speaking about arm based single board computer ?
<agumonkey>I have two, a rpi and a parallela, the former is too slow, the latter might be able to run guix normally
<davexunit>the novena, actually.
<agumonkey>you have one ?
<agumonkey>you're part of the team ?
<davexunit>I ordered one.
<agumonkey>oh ok
<agumonkey>I wasn't sure the project was finished
<davexunit>I want it to run guix
<agumonkey>awesome work
<agumonkey>yeah that would fit the spirit
<agumonkey>I don't have a novena, but I have the thinkpad keyboard bunnie uses for it's prototype :D
<davexunit>:)
<agumonkey>aight, after some parenthesis balancing
<agumonkey>guix system init is filling the guest FS
<davexunit>woohoo!
<davexunit>if it installs successfully, you'll want to update guix on the new system by using a fresh git checkout of master
<agumonkey>editing s-exps outside of emacs really is a challenge
<davexunit>paredit is amazing
<agumonkey>it is, I was recently browsing it's author just because I never really read about him even though paredit is one of my favorite things ever
<agumonkey> http://mumble.net/~campbell/emacs/
<agumonkey>ha.. rebooted the new system but I don't have a NIC (ifconfig -a only lists localhost)
<davexunit>if you can figure out the kernel module you need, then you can add that to your initrd, I think.
<davexunit>someone else could probably help you better than that.
<agumonkey>aight
*davexunit has to go
<alirio>agumonkey: I have some links about adding modules to initrd: https://lists.gnu.org/archive/html/guix-devel/2014-07/msg00163.html, https://lists.gnu.org/archive/html/guix-devel/2014-07/msg00165.html, https://lists.gnu.org/archive/html/guix-devel/2014-07/msg00167.html, https://gnunet.org/bot/log/guix/2014-07-18#T431909, https://lists.gnu.org/archive/html/guix-devel/2014-07/msg00284.html
<agumonkey>alirio: just when I need it
<agumonkey>I'm having unbound variable issues, the docs are fairly light
<agumonkey>oh cut is from srfi
<agumonkey>trying (initrd (cut base-initrd <> #:extra-modules '("libahci.ko" "ahci.ko" "e1000.ko" "e1000e.ko")))
<civodul>Hello Guix!
<alirio>civodul: about https://lists.gnu.org/archive/html/guix-devel/2014-10/msg00182.html, .bashrc is executed when you launch a new shell, .bash_profile is executed when you make login so if you use a dm, .bash_profile is useless
<agumonkey>damn base-initrd.drv fails
<agumonkey>guix is cute but as cryptic as standard gnu tools ~_~
<civodul>:-)
<civodul>agumonkey: how does it fail exactly?
<civodul>alirio: so would it help to move env var definitions to /etc/profile?
<alirio>civodul: if using dm, no; .bash_profile and /etc/profile are a user/system distinction
<civodul>ok
<civodul>i've read that section of the Bash manual a couple of times, but somehow i fail to "integrate" it
<alirio>civodul: we can use $SHLVL for conditional setting...
<alirio>civodul: 'bash --norc' instead of 'sh' would be another option
<civodul>right
<civodul>alirio: SHVL?
<civodul>oh SHLVL, i see
<civodul>didn't know that one!
<alirio>I cloned the repository yesterday, 'make check' pass all tests, but I get this: '/gnu/store/j0wn0gqqjrxfmgi9416y89yijy0qlnid-build-bootstrap-guile.sh: line 8: 5 Segmentation fault $out/bin/guile --version', executing manually: '/gnu/store/jfahjwwad516il2bdycw0zfygskvfdrc-guile-bootstrap-2.0/bin/guile --version' works as it should
<civodul>ouch
<civodul>alirio: that's on i686?
<civodul>and you get this while trying to build something, like "guix build hello"?
<alirio>yes, and './pre-inst-env guix package --no-substitutes -i hello'
<civodul>hmm
<civodul>does "env -i /gnu/store/jfahjwwad516il2bdycw0zfygskvfdrc-guile-bootstrap-2.0/bin/guile --version" work?
<alirio>yes
<civodul>and "chroot /gnu/store/jfahjwwad516il2bdycw0zfygskvfdrc-guile-bootstrap-2.0 /bin/guile --version"?
<alirio>it gives 'GC Warning: pthread_getattr_np or pthread_attr_getstack failed for main thread
<alirio>GC Warning: Couldn't read /proc/stat' above the normal output
<civodul>and does it segfault?
<civodul>these warnings are fine
<alirio>no
<civodul>uh
<civodul>"./pre-inst-env guix build guile-bootstrap -s i686-linux --no-substitutes" on my x86_64 box
<civodul>it's the same binary, running in 32-bit mode, but then it's not a "real" 32-bit box
<civodul>*works
<civodul>i'll try on a real one
<civodul>i've copied the tree to a real i686 machine, and "sudo env -i /usr/sbin/chroot ./jfahjwwad516il2bdycw0zfygskvfdrc-guile-bootstrap-2.0 /bin/guile --version" runs well there
<civodul>alirio: is it 100% reproducible?
<civodul>nothing special about the guix-daemon setup?
<alirio>'sudo env -i /usr/sbin/chroot /gnu/store/jfahjwwad516il2bdycw0zfygskvfdrc-guile-bootstrap-2.0 /bin/guile --version' works here too
<civodul>weird
<alirio>I'm using trisquel 7 liveiso, and I have the script to reproduce it...
*jmd officially gives up trying to get an arm compiler working
<civodul>jmd: please post your findings/issues!
<civodul>jmd: are you on i686, BTW?
<jmd>No.
<civodul>too bad
<jmd>Actually it seems to be an issue with gcc-4.9
<civodul>alirio: "liveiso" means it's a live distro?
*civodul goes afk for a moment
<jmd>I keep getting warnings, and then "Warnings treated as errors" even though I have passes --disable-werror
<alirio>yes, and grub is booting directly from the iso
<DusXMT>jmd: Hmm, I also had problems with compiling gcc (was attempting to do an arm LFS) on my phone with gcc...
<DusXMT>4.9
<mark_weaver>alirio, civodul: regarding .bash_profile not being sourced when using a window manager: my solution to that is to source .bash_profile from .xsessionrc or whatever it's called (I don't have that computer in front of me right now)
<mark_weaver>jmd: I'll work on the
<mark_weaver>jmd: I'll work on the ARM port for Guix when my Novena board arrives. I should have it within a month or so.
<jmd>The thing is, gcc 4.8.3 doesn't seem to support my CPU
<mark_weaver>doesn't support what CPU? the ARM?
<jmd>Well not with the options I wanted. The hard-float particularly.
<mark_weaver>hmm, that's surprising.
<mark_weaver>I would look at Debian's toolchain packages for armhf, especially the way they configure gcc/binutils/glibc and any patches they've applied.
<jmd>The annoying thing about Guix, is that if you have to touch something that low in the dependency tree, then building takes about 19 hours then you get an error, saying that this set of options is unsupported, try a different set.
<mark_weaver>hehe
<mark_weaver>sometimes, with difficult packages on a minority architecture, I've started by building the software "manually".
<mark_weaver>"guix environment" might be helpful for setting up a semi-restricted build environment when doing those tests.
<mark_weaver>civodul: maybe it's time to update the "800+ packages" on http://gnu.org/s/guix ?
<alirio>mark_weaver: from gnu/services/xorg.scm, seem slim calls .xinitrc which calls .xsession
<mark_weaver>alirio: ah yes, .xsession is the one I meant
<mark_weaver>I have a vague recollection that, at least on Debian, some display managers don't call .xinitrc but do call .xsession.
<mark_weaver>but I might be misremembering
<jmd>Do we have R packaged ??
<jmd>mark_weaver: .xinitrc is called only when you select "System Default" as the session type.
<alirio>mark_weaver, jmd: there's a executable called xinit, .xinitrc is it's configuration file, display managers shouldn't use it
<jmd>alirio: I guess that is an opinion which is not universally accepted then.
<agumonkey>hey back
<agumonkey>emacs/znc crapped on me
<agumonkey>is 1GB too short to use guix ?
<jmd>I don't see much sense in guix package --list-available=regexp having rexep match the package name.
<jmd>The description might be more useful.
*alezost uses both variants: "M-x guix-search-by-regexp" (bound to a key) to search by regexp in "name+synopsis+description" and another command based on ‘guix-search-by-regexp’ to search by regexp in "name" only
<civodul>hey, mark_weaver
<mark_weaver>hi civodul!
<civodul>mark_weaver: i've updated the number of packages in guix.html \\o/
<mark_weaver>excellent, thanks!
<civodul>jmd: you can use --search, then
<jmd>civodul: That option produces an ERROR:
<jmd>ERROR: In procedure gettext:
<jmd>ERROR: Wrong type (expecting string): #<<license> name: "X11-style" uri: "http://scripts.sil.org/cms/scripts/page.php?item_id=OFL_web" comment: "This is an X11-style, non-copyleft free software license. Check the URI for details. ">
<mark_weaver>jmd: what's the exact command that produced that error?
<mark_weaver>guix package --search=emacs works for me.
<jmd>Maybe I messed something up then. I have some local hacks ATM.
<civodul>jmd: you mean need to recompile, due to the ABI change last week or so
<mark_weaver>or maybe it's specific to the search you did
<civodul>either "make clean-go && make", or rebuild .go files from $GUIX_PACKAGE_PATH
<jmd>I probably need to do "git reset --hard" too.
<ph4nt0mas>jmd: it's the same problem I was telling civodul somedays ago
<ph4nt0mas>make clean-go doesn't seem to fix it
<mark_weaver>it would be nice if we had a specific example of a command that produces that error
<ph4nt0mas>guix package -s "anything"
<ph4nt0mas>if I try to search any package I just get the error
<jmd>"./pre-inst-env guix package --search=pdf"
<mark_weaver>jmd: thanks. alas, the command works for me.
<mark_weaver>although I'm testing on a machine that's not quite up to date. let me try updating.
<civodul>ph4nt0mas: did you try "rm -rf ~/.cache/guile" or similar?
<civodul>it's clearly an ABI issue, and that can happen if there are stale .go files
<ph4nt0mas>just tried, still the same
<ph4nt0mas>well everything else works , tomorrow I will find some time to investigate and see where those .go files are hiding from me
<civodul>could you try "strace -o log guix package -s foo"?
<civodul>to see which .go file is loaded last
<ph4nt0mas>/usr/lib/guile/2.0/ccache/system/base/target.go
<ph4nt0mas>deleted ccache there
<jmd>I think we should remove all the superlative adjectives (such as "powerful") from package descriptions.
<alirio>jmd: a superlative would be "most powerful"
<jmd>removing all .go files and running "make" seemed to do the trcik for me.
<ijp>powerfullest
<civodul>jmd: agreed!
<ijp>I call them "manipulative names"
<civodul>yeah it's subjective and vague
<civodul>of course it's hard to determine the degree of objectivity of any given phrase
<jmd>true. But some are blatently POV.
<civodul>yes, definitely
<civodul>i'm not sure if this can be formalized as a lint rule :-)
<alirio>a check for "most" or "est" doesn't seem hard
<mark_weaver>yeah, but I don't think superlatives are the thing we should be checking for
<mark_weaver>rather, we should be looking for "marketing-speak", or something to that effect
<jmd>but a quick grep for some buzzwords will pick out some of them.
<mark_weaver>e.g. suppose there's a package that computes shortest paths through a graph.
<civodul>alirio: "most" can be used in other contexts, like "most of the time", etc.
<mark_weaver>hmm, guix.texi now requires texinfo 5, because of the use of indentedblock.
<mark_weaver>(or that's my guess. anyway, it now fails to work with texinfo 4)
<civodul>oh, i didn't know it was new
<civodul>could be that
<mark_weaver>civodul: attempting to compile guix with texinfo 4.13 now fails with the message: "./doc/guix.texi:4332: Unknown command `indentedblock'."
<mark_weaver>I'm using texinfo 4.13 on my Yeeloong, because texinfo 5 takes over 10 minutes to compile guile.texi
<mark_weaver>(where texinfo 4 takes on the order of tens of seconds)
<mark_weaver>yeeloong users aren't numerous enough to cater to, but it'll be a while before texinfo 5 is widely available among users of debian derivatives, anyway.
<alirio>mark_weaver: trisquel 7 has it: http://packages.trisquel.info/search?keywords=texinfo
<mark_weaver>alirio: ah, okay. well, debian wheezy doesn't, anyway
<mark_weaver>anyway, I don't feel strongly about it.
<civodul>okay, we can try to avoid @indentedblock, lemme see
<civodul>mark_weaver: does @quotation work with Texinfo 4?
*mark_weaver tries
<mark_weaver>civodul: yes, it does
<civodul>great
*civodul patches
<mark_weaver>thanks!
<civodul>good night/day!