IRC channel logs


back to list of 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
<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
<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 file, but not
<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 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 :)
<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://" (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>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
<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.
<iyzsong>I think it's a bug, will fire it :-)
<wingo>indeed i have nothing in guix package --search-paths
<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>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>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>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>libsoup is the html parser thing, right?
<iyzsong>no, I think it's a HTTP library for both client and server
<davexunit>I thought BeautifulSoup used it or something
<df_> 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 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
<mark_weaver>bavier: in f7ee7a9b06, you refer to 'perl-gd-options-passthrough-and-fontconfig.patch' but never added it to either git or this is causing hydra evaluations to fail:
<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 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
<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 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
<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>the 'guix pull' for root will be super fast because you've already pulled the same version for another user
<df_>still getting the error :(
<mark_weaver>I guess it's a problem in 'check-package-freshness', while trying to ftp to
<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
<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!
<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 with that backtrace? <> ?
<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
<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>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, then i'll read the list via work email
<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>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:
<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?
<wingo>i guess we can make deco create the dir
<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
<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:
<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 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 attempts to build a system with a upower service
<wingo>where does dmd store its stuff?
<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>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
<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>yes, try C-M-1, i think, to get to the qemu montior
<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>in the ideal world, 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
*wingo sent alt-kernel and upower patches
<davexunit>I packaged a neat little Python program called 'livestreamer'
<davexunit>so you can watch live streams from and stuff without using proprietary software
<davexunit>serves the same purpose as youtube-dl does for static videos.
<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>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
<wingo>i hope they don't fail :P
<wingo>passed, yay
*civodul is always afraid when it comes to running those large test suites
<davexunit>me too
<davexunit>what's the easiest way to test new services?
<davexunit>spawn new vms with them?
<wingo>davexunit, guix system vm with a minimal os config
<davexunit>that's what I figured
<wingo>if you don't include x, that's better
<wingo>because you can see the dmd output which goes to tty1
<wingo>without mucking about the the qemu monitor
<civodul>yes, that's what i do as well
<civodul>wingo: re rebuild, we usually use a separate branch and have hydra build that branch
<civodul>and we merge when it's ready
<civodul>that minimizes disruption for users
<wingo>even for minor glib upgrades?
<civodul>probably, because there are 354 packages depending on it per "guix refresh -l glib"
<civodul>enough to be annoying
<wingo>cairo too is annoying in that regard
<wingo>anyway, mailed glib and cairo patches, fwiw
<wingo>i'm not yet subscribed so they might be in the queue
*civodul looks
<civodul>i'm doing terrible profiling in a branch
<wingo>profiling of what?
<civodul>gexps and all that
<civodul>the least i can say is that there is no premature optimization :-)
<wingo>lol that i am rebuilding my x server
<wingo>at least the x server does nothing these days
<wingo>xgettext and expat
<civodul>davexunit: Icecast is GPLv2-only, right?
<wingo>could it be that our xgettext is not actually linked against expat?
<civodul>i think it's only used for tests
<wingo>the new gtk+ build is carping about xml support being unavailable
<civodul>something must be wrong with our gettext recipe
<civodul>it doesn't pick expat apparently
<wingo>i am poking adding a --with-libexpat-prefix
<wingo>dunno if it is necessary tho
<wingo>oh gods this is at the root of everything isn't it
<wingo>it's downloading bootstrap binaries :/
<wingo>on the plus side i'll never need to download anything ever again :)
<civodul>gettext is one of the core things, indeed
<wingo>does rebuilding it rebuild the bootstrap binaries?
<wingo>that would be turrible
<wingo>i think i just rebuilt gettext for nothing
<wingo>wishlist: guix environment that could chdir me into the source
<civodul>uh, that happens sometimes ;-)
<civodul>oh right
<civodul>would be nice
<wingo>how do i get the source for something that built correctly?
<wingo>like gettext
<civodul>"guix build -S gettext"
<civodul>but i'm not sure that's what you meant
<wingo>on linux
<wingo>apparently the default is to attempt to dlopen gettext
<civodul>that vaguely rings a bell
<wingo>that's horrific
<civodul>see commit 0e4e4b1
<wingo>i guess it's to decrease runtime or something...
<civodul>i think we need to reinstall the link-expat phase removed by that commit
<wingo>that sounds about right
<wingo>i'll give it a go overnight