IRC channel logs

2015-12-23.log

back to list of logs

<paron_guix>okay I wiped it and all was well.
<civodul>paroneayea: maybe you had to 'guix system reconfigure' processes competing?
<paroneayea>civodul: I think it's that I had done an install, then a reconfigure, and then wiped it with another "guix system install" from the usb key
<civodul>paroneayea: oh, ok
<jlicht>I'm trying to get into working with guix import, but how would one install e.g. the hackage 'network' module using guix package & guix import?
<jlicht>Could someone point out to me where to get the keys I need to setup the relatively fast substitude server I was reading about recently in this channel?
<jlicht>nvm, already found it at http://lists.gnu.org/archive/html/guix-devel/2015-12/msg00471.html
<piyo>jlicht what is this
<piyo>oh
<piyo>So if this a substitute server, can guix prioritize to this faster one?
<fps>piyo: sadly there's still a bug somewhere
<fps> http://lists.gnu.org/archive/html/guix-devel/2015-12/msg00562.html
<fps>using hydra and my little box together still has issues..
<rekado>gah, I again missed the icedtea updates.
<rekado>updating now to 2.6.3 and 1.13.9
<rekado>I should get subscribed to the icedtea release mailing list.
<fps>is there a torrent tracker dedicated to free software?
<fps>or free/libre content in general?
<fps>i wonder how a general tracker will react to me uploading torrents for all packages in /gnu/store [70G or so] from my box :)
<Gottox>fps: rekado: We have a script that pulls new versions: http://repo.voidlinux.eu/void-updates/void-updates.txt | https://github.com/voidlinux/void-updates
<rekado>Gottox: we've got updaters as well, but they don't cover everyhting yet.
<Gottox>ah ok. icedtea is covered as we do most of the stuff automaticly.
<fps>Gottox: huh? what's voidlinux? :)
<fps>reading up on it
<Tsutsukakushi>fps: distro for kids who hate systemd
<fps>why would anyone waste time hating things?
<fps>hmm, reading up on xbps it seems like an interesting effort, but it's not functional :)
<Gottox>fps: it's functional enough for everyday usage since about 2 years on my notebook now :)
<Gottox>Tsutsukakushi: Yea, we have to handle this kids from time to time :)
<Tsutsukakushi>does it even have anything that replaces systemd? like s6 or nosh?
<Gottox>Tsutsukakushi: runit
<Tsutsukakushi>i was gonna try out void like a year ago, but then i saw how many anti-systemd whine babies use it and i was put off
<Gottox>the main reason for us dropping systemd wasn't political.
<rekado>ACTION writes down "whine babies" as a potential band name.
<davexunit>lol
<Gottox>and I still have no hard feelings against systemd... But that said, whining about systemd attracts attention :)
<Tsutsukakushi>i don't think it's the kind of attention you want tho
<davexunit>the whole annoying systemd "debate" has made it so that any distro that doesn't use systemd is portrayed as somehow anti-systemd or backwards
<fps>Gottox: "functional" in the mathematical sense :) not as in "working" :)
<Gottox>ah
<davexunit>the "linux action show" took a look at GNU dmd one episode and the commentary was something like "I don't understand what all of this anti-systemd stuff is about"
<Gottox>yea. but the xbps maintainer is a big fan of nix.
<davexunit>dmd existed *before* systemd!
<Tsutsukakushi>davexunit: yeah, i was fucking mad
<davexunit>you cannot have a rational discussion about init systems anymore
<Tsutsukakushi>chris might know his shit about desktop envrionments and video production and shit, but man is he ignorant about anything else
<davexunit>it's all focused on which side of the fence you are on systemd-wise, and you *must* choose a side, btw.
<fhmgufs>Hi
<fhmgufs>I'am running guix system init on a config file with default content (%base-packages, 5base-services).
<fps>it's a little similar when it comes to free/libre software :) [i will not promote anything nonfree on this channel, but the occasional snide remark is allowed, no?]
<fhmgufs>Why is it downloading gtk+ ...
<rekado>I find this puzzling. I really don't think the init is so very important to deserve so much talk. As with any programme I like it when it does what it should, can be extended, and is small.
<davexunit>fhmgufs: very difficult to say without showing us your actual config
<davexunit>gtk+ is a dependency for a large number of programs
<fhmgufs>But if I only have the %base-packages ...
<Tsutsukakushi>rekado: good point. there are a lot of other things that could use the attention
<fhmgufs>Which of these depends on gtk+?
<davexunit>fhmgufs: so?
<Gottox>rekado: regarding systemd it becomes more and more important if you want to ship gnome.
<davexunit>fhmgufs: the great thing about guix is that you already have all the tools you need to find out
<rekado>Gottox: which is why we have elogind.
<Gottox>yea, that's why I joined this channel in the first place :)
<rekado>:)
<fps>fhmgufs: care to show us your config?
<davexunit>yes, that is the first step towards understanding
<Tsutsukakushi>systemd is really becoming something in between the userland and the kernel...
<davexunit>and then there's GNOME's xdg-app bundles that are coming
<davexunit>bleh
<fps>i guess it fills a void/need, either perceived or real [systemd that is]
<fhmgufs>Yes: https://pastee.org/4ukgy
<fps>fhmgufs: and you run off a 0.9.0 installer image?
<fps>fhmgufs: that's incomplete
<fhmgufs>fps: No, I'm running guix system from my current installation
<fhmgufs>What's incomplete?
<fps>that config has 20 lines only?
<davexunit>fhmgufs: for updating your existing system, use 'guix system reconfigure'
<davexunit>fps: it's complete
<fps>davexunit: ok.. i failed to count parens ;)
<fhmgufs>davexunit: I have mounted something :)
<davexunit>fps: I never count parens
<fhmgufs>So it's not my current system which gets inited
<davexunit>okay
<fhmgufs>None of the packages I found in %base-packages need gtk
<davexunit>fhmgufs: yes but there's more to it than that
<fhmgufs>?
<davexunit>it's very likely that building the system requires a package that depends on gtk+
<fhmgufs>?
<davexunit>for example, I don't know if we still do this, but we were using inkscape to perform some image processing.
<fhmgufs>Oh, thanks.
<rekado>(I don't think we still do this)
<davexunit>for the images that were displayed in the GRUB boot menu
<davexunit>rekado: okay, so it's just an outdated example then
<rekado>(I vaguely remember mark_weaver changing that a while ago)
<davexunit>the point is: initializing the system requires a certain set of software
<davexunit>regardless of your OS config
<fhmgufs>And why is this line included in the messages /gnu/store/zn7rj6nyrin3sal3yrb3rynzinxz7xg1-grub-2.00.drv?
<fhmgufs>I passed --no-grub.
<davexunit>it probably still builds grub
<davexunit>which I believe is a known issue
<fhmgufs>rekado: it is downloading inkscape in the moment.
<davexunit>there we go
<davexunit>that would go it
<davexunit>so I guess we're still using inkscape for vector image processing until we have something more lightweight
<fhmgufs>That's funny: I wanted to install a test system with only the few base packages and I guess it will take me about one hour ...
<davexunit>it will take a lot less time when hydra actually performs adequately
<efraim>or you could use fps's server
<fhmgufs>No, it's ARM.
<efraim>ah, so that won't help
<fhmgufs>I have time.
<efraim>dmd is building for arm now?
<davexunit>fhmgufs: wait
<davexunit>GuixSD isn't supported on ARM
<davexunit>are you aware of this?
<fhmgufs>A few days ago somebody said, it's only because of grub.
<fhmgufs>And I said I'm installing a test system.
<davexunit>okay
<fhmgufs>Not okay: dmd build fails.
<fhmgufs>as efraim said
<fps>regarding using my server. i have a question: if i pass multiple substitute urls it seems a package is considered to be not found at all if it's missing on the first server
<fps>the second server is never checked. i wonder if that's a problem in the guix-daemon or in e.g. guix package?
<rekado>so excited: the axoloti core board (programmable audio board) is finally available for purchase; will have to package the axoloti patcher soon. Unfortunately, it's written in Java.
<fps>rekado: oh, first time i heard of that :) checking it out
<rekado>free hardware design and free software throughout!
<rekado>can't wait to get home and order a batch :)
<fps>looks promising. too bad it's some microcontroller i never heard of ;)
<fps>i took part in the mod duo kickstarter. sadly they still haven't shipped (ca. 8 months overdue now - writing off that money ;))
<rekado>it's ARM (with DSP instructions), as on the cheap STM discovery board.
<rekado>I'm intending to port Faust DSP programmes (e.g. from guitarix) to this chip.
<fps>cool
<fps>very cool
<rekado>I just ran "guix build --check julia" and it told me that "julia" is not deterministic. I'd like to diff the two output directories, but Guix did not retain the newly built output. Should it?
<davexunit>this thread is a good example of why Docker is just completely silly https://news.ycombinator.com/item?id=10782897
<efraim>is our libxml2 "safe" from https://lists.debian.org/debian-security-announce/2015/msg00337.html?
<vinben>Are there any Guix HowTos for newbs like me?
<vinben>I am trying to setup a UK keyboard but I'm completely stuck on how to do it.
<rekado>the info manual that comes with Guix is pretty comprehensive.
<vinben>I will look again. Nothing in the index starting with 'K'
<mark_weaver>vinben: for text console, 'console-keymap-service' is what you need
<vinben>Thnks
<Tsutsukakushi>it would be nice if guix came with a nicer info pager :/ the default one is kind of poopy
<mark_weaver>it's documented as taking a FILE, but you can just pass whatever argument you would pass to 'loadkeys'
<rekado>Tsutsukakushi: Emacs is the best info reader, in my opinion.
<Tsutsukakushi>sure, if you're an emacs user
<Tsutsukakushi>not for the rest of us
<Tsutsukakushi>i like pinfo
<rekado>I found pinfo a little buggy last time I tried it :-/
<rekado>(for a shell course about two months ago)
<mark_weaver>Tsutsukakushi: would you like to package it?
<Tsutsukakushi>rekado: what bugs did you find in it?
<Tsutsukakushi>mark_weaver: i guess i could try
<rekado>Tsutsukakushi: I don't remember, but it misbehaved for too long that I decided not to demo pinfo during the course. I cannot be more specific, I'm afraid. Could have been the particular version I used, or settings on the machine.
<vinben>Is the boot process for an installed GuixSD system documented? I have worked out how to change an installation config but not a running config.
<davexunit>vinben: 'guix system reconfigure'
<vinben>Thanks
<davexunit>the system currently must be rebooted for changes in services to be applied
<fhmgufs>Anybody here knowing what the test in test/respawn.sh for dmd (failing on armhf) tests?
<fhmgufs>Maybe davexunit?
<paroneayea>so having debian and guixsd dual-bootable has been interesting
<paroneayea>there are some noticable rough edges in guixsd that are visible once I boot into debian
<paroneayea>text rendering is really rough in guixsd, and I boot into debian, and everything's much cleaner. I'm not sure why that is.
<paroneayea>icecat takes several seconds to load each page, and this doesn't happen in iceweasel, which is instantaneous.
<paroneayea>well, nealy to my eye :)
<paroneayea>the text one is surely some software configuration, though not sure what
<paroneayea>pango related?
<mark_weaver>paroneayea: regarding text: I noticed that in gnome-shell on GuixSD, the text didn't look good. in XFCE, the text looks fine to me.
<paroneayea>the icecat one, maybe it's all the extensions enabled in icecat? not sure
<paroneayea>mark_weaver: it's also emacs
<mark_weaver>and w.r.t. icecat, yes, I would guess that it's the extensions.
<paroneayea>I'll take some screenshots later, but emacs in guixsd is hard for me to read
<paroneayea>it's just fine in debian
<paroneayea>gotta go for now
<mark_weaver>okay
<mark_weaver>make sure to install the dejavu fonts
<mark_weaver>well, those are my favorite ones anyway
<mark_weaver>ACTION works on updating nss and icecat
<mark_weaver>the nss test suite takes a *long* time to run
***boegel|quassel is now known as boegel
<anonymiss>when the shebang is #!/usr/bin/env python2.7 and it produces the following error: bash: ./bitmessagemain.py: /usr/bin/env: bad interpreter: No such file or directory , is this related to python2.7 not in the guix-profile, or /usr/bin/env being problemativ to guix?
<anonymiss>this is not for building, just running.
<mark_weaver>anonymiss: there's no /usr/bin/env in guix, and it would defeat the features of guix if it were relied upon.
<mark_weaver>we rewrite such shebangs to refer directly to /gnu/store/.../bin/python
<anonymiss>hm. I see. so much for just using pybitmessage from git checkout before I write a package.
<anonymiss>can you name a python package definition which does rewrite shebangs?
<mark_weaver>it's mostly handled automatically by the 'patch-source-shebangs' and 'patch-shebangs' phases, which are part of the 'gnu-build-system' by default. 'python-build-system' is derived from 'gnu-build-system' and inherits those phases.
<mark_weaver>every once in a while, the default phases fail to find them all and we need to do something else
<anonymiss>ah, okay
<mark_weaver>in cases where the default phases fail to get them all, (guix build utils) includes a 'patch-shebang' procedure. (guix build utils) is available by default to all build code.
<anonymiss>I would like to do this now.. But I want to work on subtitles now, and the next 2 days I drive around the state because it's holidays, so I won't have time to apply this and also to test new patch additions for gnunet-gtk wip
<mark_weaver>but it seems to hardly ever be needed
<anonymiss>thanks for your info :)
<mark_weaver>np!
<mark_weaver>ACTION goes afk
<vinben>GuixSD is turning out to be a lot harder to learn for a Debian user than I thought. My learning curve seems to be vertical at the moment.
<vinben>I am trying to install samba 4.3.2 (a listed package on the website) via config.scm which was a modified bare-bones.scm
<amz3>vinben: what are you struggling with?
<vinben>I have inserted the word samba between tcpdump and %base-packages and I get an Unbound variable error when using guix system reconfigure
<jlicht>Looking at https://lists.gnu.org/archive/html/guix-devel/2015-11/msg00158.html seems to imply, that the ghc-* packages are not actually picked up by ghc when compiling my own code. Is there any documentation for having my haskell code be able to import the e.g. Network module (ghc-network package)?
<vinben>At this point I don't care what version gets installed
<amz3>vinben: guix requires to know a bit of scheme :)
<amz3>vinben: did you replace cons with cons*
<amz3>vinben: also you need to import samba
<vinben>OK. Will hit the scheme manual before trying again. I thought I could follow examples desktop.scm and bare-bones.scm trial and error, I guess not.
<amz3>vinben: I can guide you through
<amz3>the configuration requires little knowledge
<amz3>and you will learn a few scheme
<vinben>amz3: That's the missing bit! import samba
<vinben>amz3: Yes, i tried both cons and cons*
<amz3>cons* is an improved version of cons that accept to prepend multiple objects at the front of the last argument
<amz3>(use-modules (foo bar baz)) allows to import all the forms defined in 'foo bar baz'
<amz3>the module of samba is...
<amz3>with guix package -A samba you get something like:
<amz3>samba 3.6.25 out gnu/packages/samba.scm
<amz3>the correct use-modules to do, is (use-modules (gnu packages samba))
<amz3>vinben: that said, I don't know how samba works :/
<amz3>I mean, configuration should be done using guix, and I don't know how samba configuration works in guix
<vinben>I have been wondering about local config changes. In Debian I use Ansible to make changes. I noticed Ansible is also in the list of packages.
<davexunit>vinben: on GuixSD you use Guix for this
<davexunit>which has many significant advantages over ansible and others
<davexunit> http://www.gnu.org/software/guix/manual/html_node/System-Configuration.html#System-Configuration
<amz3>in pratice configuration happens only in the 'config.scm' you pass to 'guix reconfigure'
<amz3>I don't see anyway services for samba, but my knowledge of both samba and services is very limited
<rekado>anonymiss: it is possible to use /usr/bin/env by installing it into a profile with its root at /usr, or to install it in a user's profile and link it to /usr/bin/env.
<rekado>"env" works just fine, but on GuixSD you cannot rely on having it at /usr/bin/env.
<efraim>gstreamer is failing on i686
<rekado>vinben: I tend to add only very few packages to the system configuration. Most of the packages on my system are in a user profile.
<efraim>er, failing on security-updates its failing, not on master
<anonymiss>rekado: okay. I think that's not what I want for my purposes, I wanted to work on pybitmessage as a global package anyway
<fhmgufs>Could somebody help me finding the failure in the make check of dmd finds on arm?
<fhmgufs>It's tests/respawn.sh
<fhmgufs>Here's the script: https://pastee.org/yz9mz
<marxistvegan>ACTION waves to davexunit paroneayea mark_weaver
<fhmgufs>And here's the ouput of it including the log: https://pastee.org/qa3zs
<fhmgufs>I don't know and can't remember wether the last lines were there everytime - I tried it several times, but the rest seems to be reproducable.
<fhmgufs>Ok, no. They also appeared again.
<fhmgufs>I've no ideas.
<fhmgufs>If I test it myself it seems to work correct.
<paroneayea>heya marxistvegan :D
<paroneayea><3
<marxistvegan>hola paroneayea :D
<mark_weaver>hi marxistvegan! good to see you here :)
<marxistvegan>mr mark_weaver it is good to see you here as well sir ;) it would be nice to see you here too ;)
<marxistvegan>mark_weaver: how is the x200 treating you?
<anonymiss>I don't know much about hydra, or the build process on it. But with late gentoo packages I wrote, I started to grab github hosted sources not by branches or snapshots, but by commits the snapshots were created from, to be sure that it actually is the package I wanted and not something somebody pushed my way. does hydra take care of something comparable too, or is grabbing things from git(s) to checkout and build not possible in the
<anonymiss>build process?
<mark_weaver>marxistvegan: actually, some part of its power management circuitry bought the farm a few weeks ago, so I'm back on the X60.
<mark_weaver>it can't charge the battery at all (although other X200 machines can), and also sometimes just loses power while entering/leaving suspend
<marxistvegan>mark_weaver: oh no :(
<marxistvegan>mark_weaver: hmm that is not good, i hear there is someone else that has one that you might be able snag <cough> <cough> paroneayea
<mark_weaver>fhmgufs: fyi, the relevant bug report is here: <https://bugs.gnu.org/22130>. If you learn anything new, please email 22130@debbugs.gnu.org and it will get added to the bug report
<fhmgufs>Thanks.
<mark_weaver>marxistvegan: I imagine that paroneayea wants to keep using his X200
<anonymiss>so I could use https://github.com/Bitmessage/PyBitmessage/archive/v0.4.4.tar.gz or whatever we used with gentoo (git-r3 eclass had a function to do that): 713ed89467b9c766cb22df0cc51415a93fd1801d
<mark_weaver>it's okay, I'll just get another one used. they're pretty cheap
<mark_weaver>anonymiss: hydra just uses guix to build the packages, there's no special magic there that's not available to you. we prefer to use upstream tarball releases where available, but guix supports using VCS checkouts as well.
<anonymiss>Ah, okay.
<fhmgufs>mark_weaver: Is what the dmd check reports true or just a bug in the test itself?
<mark_weaver>fhmgufs: I don't know, I haven't yet investigated.
<mark_weaver>anyway, I have to go afk now. good luck!
<davexunit>hey marxistvegan
<marxistvegan>davexunit: i miss being able to say "I am sorry dave, i cant do that"
<davexunit>:)
<davexunit>you can just come in here and say that
<mark_weaver>haha
<fhmgufs>And what does this test test?
<fhmgufs>Just wether services are respawned?
<efraim>should t-service1-pid and t-service2-pid have different numbers?
<marxistvegan>I am sorry davexunit I dont think i can do that ...
<marxistvegan>nah saying outloud is soo much better
<fhmgufs>efraim: maybe? I think they should ...
<jgay>marxistvegan, it is your own fault, you brought the joke a little too far when you locked davexunit out on the fire escape and jammed the ladder so he couldn't climb down ... he was stuck out there the entire night!
<jgay>maybe if you hadn't done that, davexunit would still be working with us :-P
<marxistvegan>jgay: would've been better if I left him in the 4 feet of snow on the roof last year
<fhmgufs>Maybe I should ask civodul (writer of the script) when he's back.
<davexunit>oh you guys... ;)
<jgay>marxistvegan, well we can always invite him over for lunch sometime in April, "hey davexunit, come check out this new solar array panel we installed, it uses gnu remotecontrol to control defroster so they run all winter!" ... that'll totally be enough to get him up there
<jgay>sorry I meant february ... geez, I hope not April :-)
<marxistvegan>jgay: though april would be more fitting for the fools
<davexunit>the channel rules say to take your FSF fan fiction to the libreplanet wiki ;)
<paroneayea>mark_weaver: oh, hm, makes me wonder if I should bring a spare laptop on my extended trip, just in case...
<fhmgufs>Could sb please build dmd on his none arm machine, run tests/respawn.sh and give me the output of it? (download: ftp://alpha.gnu.org/gnu/dmd/dmd-0.2.tar.gz)
<fhmgufs>Ok, I'll find the bug tomorrow.
<rekado>gah, lilypond's build system is so weird!
<rekado>I did in fact succeed in getting the info pages built with images --- but only when I ran the (failing) tests.
<rekado>so, the remnants of an aborted build of lilypond did contain correct info manuals.
<rekado>when I disable the tests (and change nothing else) the manuals are without images.
<rekado>the reason is this: during the "install" phase the pictures are deleted!
<rekado>failing the tests ensures that the "install" phase isn't reached.