IRC channel logs

***boegel is now known as boegel|afk

<mark_weaver>davexunit: what was the problem? I see only one commit pushed from you recently, and I don't see how it could have fixed that problem.

<mark_weaver>if you push a change to mesa, it might be better to push it on a different branch and add a jobset to hydra to build it before pushing it to master

<{[]}grant>Racket's Raco complains that it needs 'sslv2-or-v3', only openssl 1.0.2 seems to be available though.

<davexunit>mark_weaver: I didn't push a patch to fix mesa, I haven't figured it out yet.

<davexunit>I did push a patch that was causing 'make' to fail

<davexunit>due to the prior patch by iyzsong, which removed a patch file, but not its reference in Makefile.am

<mark_weaver>ah, okay

<davexunit>our mesa package drops i915 and i965 drivers when building on non-intel platforms, but I fear that it may accidentally be dropping nouveau (and maybe some more?), too

<davexunit>depending upon what the default dri drivers are built

<mark_weaver>well, we explicitly pass 'nouveau' to the list of dri drivers on non-intell

<mark_weaver>*intel

<davexunit>yeah

<davexunit>but is that just because, without explicitly saying what drivers to build, it builds *everything*?

<davexunit>I'll poke at it

<mark_weaver>before I did that, it failed to build on non-intel

<mark_weaver>it tried to build the intel drivers and they failed

<mark_weaver>but the problem you're having is presumably on an intel platform, where we don't pass that argument at all

<mark_weaver>so I'm not sure why you'd be looking at that as a potential problem

<davexunit>mark_weaver: it's just the first place I thought to look. the expected driver .so file just isn't there in our mesa build.

<davexunit>so I thought maybe it's something we must explicitly ask to be built?

<davexunit>there's a nouveau_vieux_dri.so file, but not nouveau_dri.so

<davexunit>and that's the file that libGL complains about not being able to find

<davexunit>do you think I'm looking in the wrong place?

<mark_weaver>honestly, I have no idea. it would require a closer look

<mark_weaver>I just had a video chat over https://hello.firefox.com/ using GNU Icecat on GuixSD, and much to my delight it worked, and worked well! :)

<mark_weaver>my time spent getting WebRTC working on our Icecat was not in vain :)

<jxself>Woot.

<mark_weaver>I have to disable LibreJS to make it work, however. even whitelisting the entire site in LibreJS preferences doesn't work (it's not the first site I've noticed that with)

<jxself>That means the JavaScript is either not properl marked as free, or isn't free. I wonder which it is...

<mark_weaver>yeah, I wonder too.

<mark_weaver>but in any case, LibreJS has a bug with whitelisting that will cause many people to have to disable it entirely, which is too bad.

<mark_weaver>s/have to//

<mark_weaver>at present, this seems to be the only thing with the potential to displace skype

<jxself>You whitelisted Telefonica too?

<mark_weaver>(for people who want to be able to chat with their family and not just other free software folks)

<jxself>I wonder if that's needed, since Hello is "Powered by Telefonica" they say.

<mark_weaver>apparently the URL "about:loopconversation" is involved as well. not sure how to whitelist that one

<mark_weaver>and the URL "wss://media021-sjc.tokbox.com/rumorwebsocketsv2" (or similar) are also involved somehow

<mark_weaver>this is based on logging done by the RequestPolicy extension

<mark_weaver>(which I don't use but my friend does and he passed along that info)

<mark_weaver>but when I click on LibreJS's icon in the Icecat toolbar, which shows a report of what JS was blocked, it said that nothing was blocked.

<mark_weaver>if something else is getting blocked that's not listed there, maybe it's just that the report needs to be made more comprehensive somehow

<mark_weaver>but fwiw, when I used NoScript, I never had any trouble getting sites whitelisted

<iyzsong>oops, I wrote a type in commit message (4ec486). sorry >.<

<iyzsong>what can I do now for it?

<mark_weaver>iyzsong: there's no way to fix it now.

<mark_weaver>don't worry about it :)

<mark_weaver>obviously, we should try to be careful, but I've made similar mistakes and so have civodul. life goes on :)

<mark_weaver>s/have/has/

<mark_weaver>iyzsong: git allows rewriting of history, but as a policy decision we don't allow it on the master branch

<mark_weaver>it would cause problems for others who have based work on our repo

<iyzsong>mark_weaver: thanks.

<wingo>hello guix from guix!

<sneek>Welcome back wingo, you have 1 message.

<sneek>wingo, civodul says: re gcc, you need to install "gcc-toolchain" instead of "gcc"

*wingo installed hexchat

<wingo>sneek, later tell civodul i tried that, but somehow i missed the message of the env. variables i would need to set

<sneek>Okay.

<wingo>anyway, on my way. terminal, irc, emacs, web browser -- that's mostly there :)

*wingo didn't realize hexchat was the new xchat

<wingo>i guess i don't understand the meaning of "the following environment variables may be needed"

<wingo>if they are really needed then perhaps there should be some .d directory in the profile that ~/.bash_profile can source

<wingo>otherwise if i uninstall a package i could end up with a stale entry in my .bash_profile

<wingo>is there something special i need to do to get perl modules to work from a user profile?

<wingo>upower's configure balks at a missing perl XML::Parser

<wingo>but i installed it.

<iyzsong>wingo: set PERL5LIB?

<wingo>iyzsong, i guess? i didn't see any recommendation of what to set it to

<wingo>currently looking to find out what that should be

<wingo>the issue might be that perl is from the system install and i am using it as a user

<wingo>er, installing packages as a user

<wingo>perhaps the PERL5LIB question doesn't arise if i install perl as a user

<iyzsong>yes, that's the problem. the search-paths is only for user's profile, will not respect the system one.

<wingo>but i installed XML::Parser as a user

<wingo>actually which perl resolves to a perl in my user's profile

<wingo>so maybe there is no user/system problem then

<iyzsong>wingo: If you have perl in ~/.guix-profile, then 'guix package --search-paths' should get PERL5LIB. But the problem occurs if I have perl in system profile, a module in user profile, no hint from --search-paths.

<wingo>thanks!

<iyzsong>I think it's a bug, will fire it :-)

<wingo>indeed i have nothing in guix package --search-paths

<wingo>well

<wingo>nothing perl-related

<wingo>thanks for the clue about that command too :)

<wingo>and for the excellent feedback on the patches yesterday!

<wingo>i'm still setting up a good dev environment here so i'm a bit slow

<wingo>no main on this machine yet :P

<wingo>*mail

<wingo>yay, configure for upower runs

<wingo>thanks again iyzsong :)

<iyzsong>wingo: NP, I'm happy to help :)

<wingo>how do i convert a base16 sha256sum to a base32 sum?

<wingo>there does not appear to be a base16 operator

<wingo>does everyone just download things twice when making a package -- first time to get the checksum, the second to build?

<alezost>wingo: when you use "guix download ..." the package source is placed in the store and it will not be downloaded the second time

<davexunit> https://savannah.gnu.org/forum/forum.php?forum_id=8248

<davexunit>iyzsong: hey, I saw your libshout patch.

<davexunit>I have an icecast patch ready to go, so I wanted to catch you before you tried to package it. :)

<wingo>alezost, ah, i was just using "guix build"

<wingo>which downloads, then carps that the checksum doesn't match, and so doesn't keep the download

<wingo>tx

<wingo>heya davexunit :)

<davexunit>hey wingo

<iyzsong>davexunit: I won't do icecast. it depends on libshout?

<davexunit>iyzsong: no, I just wanted to make sure you were on better things. :)

<davexunit>I haven't pushed the patch to add icecast yet because I was going to do some major refactoring of libxml2/libxslt stuff.

<davexunit>but I think I should just push it (after patch review of course)

<iyzsong>davexunit: I'm on the way for a full build of gst-plugins-good. the missing are aalib, libsoup (to my suprised, it use php for testing).

<davexunit>interesting

<davexunit>libsoup is the html parser thing, right?

<iyzsong>no, I think it's a HTTP library for both client and server

<davexunit>oh

<davexunit>I thought BeautifulSoup used it or something

<df_>gnu.org appears to be down, did they annoy the chinese government or something? :(

<freaj>df_: down for me too

<df_>ah well, savannah is ok, guess I can build the docs from source

<davexunit>yeah gnu.org is down, folks.

<davexunit>along with some other services

<davexunit>like our mail server it seems

<davexunit>the fsf sysadmins know

<davexunit>the physical host that a bunch of these VMs live on went down

<davexunit>:(

<mark_weaver>bavier: in f7ee7a9b06, you refer to 'perl-gd-options-passthrough-and-fontconfig.patch' but never added it to either git or gnu-system.am. this is causing hydra evaluations to fail: http://hydra.gnu.org/jobset/gnu/master#tabs-errors

<mark_weaver>can you fix it ASAP?

<mark_weaver>I can't fix it since I don't have the patch

<mark_weaver>(or just give me the patch)

<mark_weaver>hmm

*mark_weaver wonders if he should do something to fix the evaluations in the meantime

<mark_weaver>we need a better way to detect these mistakes somehow

<mark_weaver>bavier: for now, I pushed a commit that creates a stub 'perl-gd-options-passthrough-and-fontconfig.patch' and adds it to gnu-system.am.

<mark_weaver>this should enable hydra evaluations, although that package will fail until that file is replaced with the real patch.

<paroneayea>davexunit: oh shit

<mark_weaver>looks like things are back up now though

<df_>I appear to be intermittently getting this error when attempting to install packages:

<df_>guix/scripts/package.scm:578:4: In procedure #<procedure 2c032c0 at guix/scripts/package.scm:627:17 (expr)>:

<df_>guix/scripts/package.scm:578:4: string contains #\\nul character: "\\x00150 Here comes the directory listing.\\r"

<df_>well, not exactly intermittently

<df_>it was happening consistently for emacs, but then after I installed some other stuff it worked

<wingo>df_: that would seem to indicate that something is trying to compile a regex with an embedded NUL

<wingo>hum perhaps not

<df_>would the rest of the stack trace help? will have to get a web browser installed in order to paste it somewhere...

<wingo>sure

<df_> http://paste.lisp.org/display/146788

*wingo a guix noob but not a guile noob :)

<df_>heh, I am both

<df_>so this is all a bit alien right now

<wingo>what version of guix are you running?

<df_>I am attempting a guix pull to see if that helps but it seems to be taking a very long time to compile

<df_>0.8.1

<davexunit>well, there's a lot of stuff to compile.

<df_>does pull get the latest release or the bleeding edge?

<davexunit>bleeding edge

<davexunit>master branch

<wingo>regarding versions i am not sure but there were a number of commits in february that could have improved this bug

<wingo>so i am going to punt on investigating it

<wingo>fingers crossed for the guix pull!

<df_>k :)

<df_>now I at least have emacs and a browser I can probably have a go at debugging it myself if it persists

<wingo>that's about the point where i'm at :)

<wingo>currently seeing if i can package upower so that i can package gnome-settings-daemon so that my brightness keys work :)

<davexunit>down the rabbit hole!

<df_>hmm, so will running guix pull as a normal user only update it for my profile?

<davexunit>for your user account, yes.

<davexunit>each user may use a different version of the guix client

<df_>and if I want to update globally? just run it as root?

<davexunit>that updates it for the root user

<davexunit>to update the guix in /run/current-system, that takes a call to 'guix system reconfigure'

<df_>after pulling as root?

<davexunit>yeah

<davexunit>the 'guix pull' for root will be super fast because you've already pulled the same version for another user

<df_>thanks

<df_>still getting the error :(

<mark_weaver>I guess it's a problem in 'check-package-freshness', while trying to ftp to ftp.gnu.org

<mark_weaver>df_: btw, you probably don't want to actually install 'binutils' directly. instead, we have 'gcc-toolchain' that contains 'gcc', 'binutils', and 'glibc', along with something called 'ld-wrapper' that wraps 'ld' such that rpaths are inserted automatically.

<mark_weaver>I can't reproduce the problem on my system though

<df_>ah... well I don't get the error for that package

<df_>so I guess I've worked around the problem for now...

<mark_weaver>df_: are you behind some kind of transparent proxy for ftp connections, by chance?

<df_>erm, I'm behind NAT

<mark_weaver>well, most of us are behind NAT

<df_>I haven't noticed any problems with it before but I probably don't use ftp a lot

<df_>I'll try ftping in manually and see if anything weird happens

<mark_weaver>I suppose it's possible that your NAT router is doing something unusual

<wingo>good day mark_weaver

<wingo>woo, fixed a distcheck issue in upower

<mark_weaver>yay!

<davexunit>it's great to have wingo on board here :)

<mark_weaver>+1 :)

<wingo>you people are amazing

<wingo>i have a distro on my machine and it just works and when i need to fix it it's all in guile

<wingo>what a pleasure

<davexunit>yeah, it's pretty awesome.

<davexunit>now, to convinve people that aren't guile comaintainers of this!

<davexunit>convince*

<davexunit>:P

<mark_weaver>we seem to have convinced a number of non-guile people :)

<davexunit>yes, that is true.

<davexunit>we are steadily gaining more hackers

<davexunit>and onlookers

<mark_weaver>df_: could you send mail bug-guix@gnu.org with that backtrace? <http://paste.lisp.org/+359G> ?

<mark_weaver>I guess that our little ftp client doesn't cope well with whatever your NAT router is doing

<mark_weaver>(not sure of that, just my first guess)

<df_>I will probably do a little more investigation of my own first

<mark_weaver>df_: well, the problem seems to be that NUL characters are somehow getting in the ftp stream, which our ftp client can't cope with because it uses C-based regex to search for things in that stream. apparently you're the first person to run into this problem, or at least the first to report it.

<mark_weaver>the ftp client code is in guix/ftp-client.scm

<mark_weaver>anyway, I have to go mostly afk for the rest of the day.

<df_>ok, will have a look

<wingo>mark_weaver: upower tests want to connect to the system bus. they work when i run them directly but not from within the build. the build has dbus as an input but i guess that's just the libraries; dunno.

<wingo>should i just not run the test?

<wingo>they look for /var/run/dbus/system_bus_socket

<wingo>which exists in my environment

<wingo>and in "guix environment upower"

<wingo>but i guess not in the build environment

<davexunit>the build environment is far more restricted.

<davexunit>is there any particular reason why we use python 3.3.5 and not a newer version?

<davexunit>I see stable releases for the 3.4.x series on python.org

<mark_weaver>wingo: the build environment is very isolated.

<mark_weaver>I think we normally have to just disable tests that rely on system dbus

<wingo>ok

<wingo>i guess it would be possible in theory to run tests in an environment with a system bus service

<wingo>but no need to poke that now

<mark_weaver>iyzsong might have a better idea, dunno

<mark_weaver>I have a vague recollection that he might have arranged to start dbus from within the build environment in some package, but it might have been a session dbus.

<mark_weaver>(or maybe I'm just misremembering)

<mark_weaver>but we certainly have several packages that just disable tests that need system dbus

<wingo>too bad i spent time making tests work :)

<wingo>oh wells

<mark_weaver>wingo: btw, I notice that I can't change any preferences in gnome-terminal. i guess that's due to the lack of the setting daemon or something?

*mark_weaver wants black-on-white text

<wingo>mark_weaver, yes when i ran the file in the libexec dir

<wingo>it spewed something about only having a memory backend for gsettings

<wingo>and that profile settings wouldn't be persistent

<wingo>perhaps due to some bug they're not taken at all

<wingo>in any case it's either lack of a dconf service -- i don't know

<wingo>or lack of gnome-settings-daemon

<mark_weaver>wingo: btw, I updated your gnome-terminal patch to take into account the feedback from iyzsong and based on current master.

<wingo>mark_weaver, great, thank you!

<wingo>i don't have mail on this machine yet so i'm a bit slow

<mark_weaver>but I don't know what copyright line to add for you. what email addr do you want to put there?

<wingo>good question, humm

<wingo>let's put wingo@igalia.com, then i'll read the list via work email

<mark_weaver>okay

<mark_weaver>thanks!

<wingo>thank you :)

<wingo>uf, one more hurdle -- installing udev rules..

<mark_weaver>wingo: see the 'udev-service' in %base-services at the end of gnu/services/base.scm

<wingo>tx

<wingo>i am still getting the package to install correctly

<wingo>is setting --localstatedir=/var correct?

<wingo>for var things

<wingo>for udev i am following pulseaudio

<mark_weaver>wingo: yes, probably

<mark_weaver>we set --localstatedir=/var for some daemon packages

<wingo>it tries to mkdir -p /var/lib/upower

<wingo>at build-time

<mark_weaver>btw, here is my OS config: http://paste.lisp.org/+359I

<wingo>er

<wingo>at install-time

<wingo>and fails, obviously

<mark_weaver>wingo: those make rules need to be inhibited somehow

<wingo>what should make /var/lib/upower?

<mark_weaver>the associated service will have to do it

<wingo>when it first runs, you mean?

<mark_weaver>right

<wingo>i guess we can make deco create the dir

<wingo>er

<wingo>dmd

<mark_weaver>some of our services do it at activation time, but that's actually wrong, because at that point only the root filesystem is mounted

<mark_weaver>we'll have to fix those

<mark_weaver>it should be done when the service is started

<mark_weaver>service definitions are in gnu/services/*.scm

<wingo>ok

<mark_weaver>wingo: btw, you were asking about resolution of .local names. here's what civodul wrote on the subject, although it doesn't work for me: https://lists.gnu.org/archive/html/guix-devel/2015-02/msg00109.html

<wingo>mark_weaver, yes i found that, thank you

<mark_weaver>more work needs to be done there to make it easier to set up, or perhaps we should just make it the default which would avoid the issues for now.

<mark_weaver>anyway, I gotta go. happy hacking all!

<wingo>was talking about that with civodul yesterday and he found a bug with it

<wingo>ciao :)

<wingo>i wonder how best to make a patch with immutable dirs owned by some other user

<wingo>previous things have been hacky

<davexunit>pushing a trivial patch to upgrade node

<df_>any idea why I'd get this: tcpdump: live packet capture not supported on this system ?

<df_>missing a kernel module or something?

<df_>and am I right in thinking that if guix goes looking for packages at ftp.gnu.org it's because they're not available on hydra?

<df_>anyway, it looks like my router is doing something dodgy because I see a zero byte in the stream from any computer on this network but not from elsewhere

*davexunit pushes initial 'guix publish' patches, finally

<davexunit>a lot of work left to make it actually useful, but it's a start.

<wingo>sweet!

*wingo attempts to build a system with a upower service

<wingo>where does dmd store its stuff?

<wingo>humm

<civodul>Hello Guix!

<sneek>Welcome back civodul, you have 1 message.

<sneek>civodul, wingo says: i tried that, but somehow i missed the message of the env. variables i would need to set

<wingo>hi civodul :)

<civodul>hey!

<civodul>so did 'gcc-toolchain' eventually did the trick?

<wingo>civodul, yes, though i misunderstood the bit about the env variables

<wingo>it would be nice if there were a directory of things to source in the profile

<wingo>for sourcing environment variables

<wingo>anyway, all fine

<civodul>ah yeah

<wingo>eventually i will go over this log and send you things

<civodul>excellent

<wingo>s/you/the list/

<civodul>there's 'guix package --search-paths', but i imagine it's not something one immediately finds

<wingo>currently i have a building upower package and service, trying to get a system working with a upower system service

<wingo>only missing one bit i think, though hampered by lack of logs in qemu

<wingo>is there a way to get to tty1 in qemu?

<civodul>nice!

<civodul>yes, try C-M-1, i think, to get to the qemu montior

<civodul>*monitor

<wingo>tx!

<civodul>from there, you can try "sendkey ctrl-alt-f1"

<civodul>and then C-M-1 again to get to the actual system screen

<civodul>(it's muscle memory though, so i'm not sure about the key bindings)

<wingo>C-M-S-2 apparently

<wingo>and C-M-S-1 to get back

<davexunit>civodul: does our /etc/profile or whatever automagically take care to eval the result of 'guix pacakge --search-paths' ?

<wingo>i guess #:initialize was defaulting to #f because qemu images now ask for keyboard input at startup

<wingo>excellent, it works!

<wingo>gnome-settings-daemon here i come

<civodul>davexunit: no, but it should do something like that i guess

<wingo>does hydra have a privacy policy?

<wingo>it gets hit every time a guix user does anything, almost...

<civodul>it's has improved lately, but that's not perfect

<civodul>and no, there's no privacy policy

<civodul>the thing is, when packaging something, it checks on hydra whether it's available there

<civodul>but by definition, in that case it cannot be available there

<civodul>so the best is to use --no-substitutes here

<wingo>given that hydra has to be used at least guix can get the benefit of knowing how many users it has

<wingo>kindof an anti-feature for some but it's interesting from the project's perspective

<wingo>s/has to be used/is very convenient to use/

<civodul>yeah

<civodul>in the ideal world, hydra.gnu.org will no longer be a central point

<civodul>davexunit: BTW, any reason why you didn't push 'guix publish'? :-)

<davexunit>civodul: hm? I just pushed it!

<davexunit>if you mean why it took me so long, it's because I was too busy to address your final patch review.

<civodul>ah ok, i hadn't seen it

<civodul>perfect!

*wingo sent alt-kernel and upower patches

<davexunit>cool!

<civodul>+1

<davexunit>I packaged a neat little Python program called 'livestreamer'

<davexunit>so you can watch live streams from twitch.tv and stuff without using proprietary software

<davexunit>serves the same purpose as youtube-dl does for static videos.

<wingo>nice!

<wingo>la la la to build the latest gnome-settings-daemon i have to upgrade gtk+ and glib and cairo, whee

<{[]}grant>davexunit: Oh yeah, that's a nice bit of software. I've used it to stream from ustream for a podcast or two a few times. :^)

<wingo>painless so far tho

<civodul>dependency hell :-)

*{[]}grant is repurposing the defunct/non-applicable 'buildbox', into just a general Guix(SD) development box. He really wants to get into at least package contributing again relatively soon.

<{[]}grant>I have a list of like 10 things I want done, only about 3 started, and 3 that will surely have amazingly long '

<{[]}grant>recipies'.

<{[]}grant>ie, Kodi.

*{[]}grant really needs into learning how to write a dmd-service; It amazes me that we don't have an openssh service yet.

<wingo>it's not so bad

<wingo>you just look at another service and monkey-type

<davexunit>I have yet to write a service definition

<davexunit>been meaning to

<{[]}grant>wingo: Well I'm in a perpetual state of "monkey-type".

<davexunit>for httpd, nginx, postgresql, mysql, etc.

<wingo>{[]}grant, me too :)

<wingo>glib tests take a while to run