IRC channel logs

<ng0>* The COPYRIGHT file contains the EPIC license. EPIC is licensed under the

<ng0> standard three-clause BSD license except that you are not permitted to

<ng0> remove the Redistribution is permitted clause of the license if you

<ng0> distribute binaries. ... can we distribute that?

<ng0>i struggle with licenses sometimes. for me it reads like yes

<edangor>hello everyone! any irc terminal-based client that i can install with guix

<ng0>there's ii, weechat, irssi, etc

<ng0>and atm I'm writing on epic5

<edangor>ok thanks

<ng0>there's even more, but guix package -s irc should turn up some :)

<ng0>wth is this configure script... configure: error: can only configure for one host and one target at a time

<ng0>i even applied the options to disable the triplet

<efraim>lfam: idea for attic, have it superseded by attic-is-borked-switch-to-borg, or by hello :)

<lfam>Maybe we should supersede it with borg in the next release. That way the change could get publicized

<efraim>If people read the release notes :P

<lfam>I just don't want anyone's backup automation to break, although by continuing to make backups, there's a chance they run out of space and then they lose all the backups

<efraim>Yeah

<gnuub1>what is the routine needed to keep guixsd up to date (including security patches) ?

<jmd>I think it's guix pull

<gnuub1>ok, thought so , but just to be sure :)

<brendyn>followed by puix package -u ?

<jmd>puix ?

<brendyn>that's my pixie version of guix

<brendyn>Ok so I honesly have no idea how to take a patch from an email and apply it with emacs 0.o

<wingo>brendyn: do you use gnus?

<brendyn>I'd like to start using it but I haven't as of yet. Thunderbird is really annoying.

<wingo>with thunderbird if you can save an email or a thread as mbox then i think you can apply it on the command line using "git am"

<wingo>git am -3 < foo.mbox

<brendyn>It saves as .eml

<wingo>in emacs and gnus i press '|' to pipe an article, then when it asks me "to what" i do "(cd ~/src/proj && git am -3)"

<wingo>alternately you can select a region in a buffer and pipe the region to git am -3

<wingo>if the region is a format-patch output anyway

<brendyn>Where do i need to start and finish highlighting? this file is full of crap from the email

<jmd>Normally git am is clever enough to ignore the crap.

<brendyn>jmd: Amazing, I never guessed it would have actually worked.

<ng0> https://ptpb.pw/LMDr python2-geventhttpclient is failing to build .. I don't see why it does though..

<rekado>I’m trying to get a substitute for /gnu/store/8flmg6r82sgyr635isjx3z0asl6m7fcs-webkitgtk-2.12.5, which according to hydra has been built.

<rekado>Yet Guix on my machine wants to build it from source.

<rekado>(I’m using latest master)

<ng0>any python experts who want to help with this?

<fps>rekado: do you use several substitute servers?

<fps>rekado: IIRC there was a bug where if a sub wasn't found on the first one it wouldn't look for it on consecutive servers

<rekado>fps: this might be it. Thanks. I’ll try specifying substitution servers explicitly.

<rekado>fps: works!

<fps>i suppose that bug hasn't been fixed then. no idea if it's even filed, but i think i remember seeing it discussed on the ML

<fps>i have an interesting problem myself

<fps>i run a publish service on a guix vm

<fps>and locally i can connect to it fine using e.g. links or wget

<fps>but from a different machine i get connection refused

<fps>it works fine for the ssh service though

<fps>damn, now we have power checks at work.. bbiab

<efraim>ng0: to me it looks like a typo in setup.py

<efraim> install_requires=requirements)

<ng0>huh. ok

<ng0>I'll try it. and if it works i'll send a patch upstream

<ng0>but i wonder, why does it work in python3 and fail in python2?

<ng0>this can't be it.. https://github.com/gwik/geventhttpclient/blob/master/setup.py#L58 the ) closes setup()

<ng0>is there a last , missing?

<ng0>no. i don't understand enough of setup.py to fix this

<gnuub1>how can i find out before running guix system reconfigure which packages are locally build/substitutes?

<gnuub1>(will be)

<ng0>i think: install_requires=[requirements])

<ng0>gnuub1: guix package -n -u can show the dry run if that's what you want

<gnuub1>thx

<ng0>it also fails the python2 with install_requires=[requirements])

<gnuub1>is there a significant time span between guix package updates and the hydra builds?

<gnuub1>nvm , there is the emacs guix-hydra interface to query that...

<ng0>ha!

<ng0>gentoo bugtracker ftw, found this: https://github.com/gwik/geventhttpclient/pull/82

<ng0>fixed the build for python2.

<efraim>yay!

<ng0>dulwich: name it python-dulwich or just dulwich? It's a library but names itself dulwich.

<jmd>ng0: Why does it call itself that?

<ng0> http://dulwich.io

<jmd>Is there also a python-peckham-rye ?

<ng0>it produces 3 binaries.. i will drop the python- prefix.

<ng0>but then the problem is once the python3 port is functional, do we have to rename it?

<ng0>sorry, i mean when the tests are fixed. eh.. i mean in general. what about python2 vs python3?

<ng0>is it okay to name applications, not libraries, with the prefixes?

<ng0>babel does it like this too.. right?

<ng0>wat. package builds okay when it is build alone. fails when it is called as a dependency and needs to be build again because of this

<davexunit>rekado: oooooh, extempore!

<efraim>ng0: that's where the properties python2-variant stuff came from

<ng0>the delay things?

<efraim>Once you do it once you have to do it all the way up the dependency chain

<efraim>Yeah

<ng0>do i set this only in the affected package or in package and dependencies?

<ng0>oh i c how it works

<davexunit>ACTION updates guile-next to 2.1.4.

<rekado>davexunit: thanks!

<rekado>ACTION uses guile-next in “production”

<davexunit>ooh :)

<davexunit>trivial updates like this are about all I have time for these days

<rekado>it’s getting difficult for me to find time :-/ There’s a couple of things I do on my short commute, others at work, but there isn’t much time to think.

<rekado>I did all the R package updates at a conference in between talks…

<davexunit>I find myself doing similar things

<davexunit>stuffing a package update in between other work

<ng0>why is "Paste" gone?

<ng0>even with fallback it is gone

<rekado>looks like there’s a problem with hydra right now

<ng0>thanks

<ng0>2/3 of kallithea is packaged now :)

<taylan>I'm getting "@ substituter-failed /gnu/store/hzlzcvzrlc0k182l3hw6wq6mpr5m4wjy-module-import-compiled 0 hash mismatch in downloaded path `/gnu/store/hzlzcvzrlc0k182l3hw6wq6mpr5m4wjy-module-import-compiled': expected 20423864494b5bf917e08cc31bdab29ca6ac9b167050b2dee341fac9bc1f9865, got 2365767178e89da79df9ff6490bedfbc34afa9b4dd5eeec14ecf8a7d0d977613"

<taylan>while trying to build some package (updating the Nintendo emulator higan, testing if it still builds). don't know what to make of this.

<aggelos_>hey all

<aggelos_>quick question: is it possible to bootstrap to any historical version of the packages w/o having an external checkout? (I haven't checked if even *that* is possible)

<aggelos_>I mean, I want others to be able to reproduce my setup N years from now

<aggelos_>is that even a goal?

<taylan>aggelos_: just note which release / git commit of guix you used and it should work, though you won't get substitute binaries from hydra for old things of course

<bavier>aggelos_: it is a goal

<aggelos_>taylan: that's ok... but can I even get the release/git commit of my current guix setup?

<taylan>aggelos_: hm, dunno how to get the current version if you used 'guix pull', though it should certainly be possible

<janneke>i'm fighting with substitute*'ing a block that includes newlines...is it perhaps line-based only?

<bavier>janneke: it is

<bavier>substitute* applies the supplied regex's on a line-by-line basis

<janneke>bavier: thanks, then i can stop fighting :-)

<lfam>CVE-2016-6662: http://seclists.org/oss-sec/2016/q3/481

<lfam>Apparently *not* fixed in the latest mysql, 5.7.15

<lfam>And yet the 5.7.15 release notes do seem to address it: https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-15.html

<lfam>And Red Hat and Debian both seem to think it's fixed in 5.7.15

<lfam>The bug reporter has chosen not to respond to somebody asking for clarification about this... sigh

<efraim>debian only issues a DSA number after they have a fix/patch for the issue

<lfam>efraim: Interesting, I did not know that policy

<efraim>i guessed it after watching you patch CVEs that I didn't see them list for several days

<lfam>You mean after we pushed bug fixes earlier than them? ;)

<lfam>BTW efraim, I noticed that you sent a message with k9 where you did *not* top post. Is there a setting for that? I can't figure out how to do it easily

<efraim>after the top-post spot there's two boxes on the right, a pencil for 'edit' and an X. if you hit the pencil then you can post inline

<efraim>debian is also a binary distro, after they patch it they have to build it for ~22 architectures before releasing it

<dvc>seems like my kernel patches broke something else

<lfam>Yes, I was facetious about Debian. Updating packages requires way less work for us. I'm sure they also do more testing as well

<efraim>probably ;p

<dvc>what are your opinions, should the a function that returns a kernel configuration file take an arch (kernel specific) or a system (guix specific)

<lfam>My opinion is that somebody else has a more informed opinion ;)

<dvc>civodul: ?

<dvc>mark_weaver: ?

<dvc>who else knows about kernel stuff?

<efraim>how would adding i686-gnu affect the options?

<lfam>dvc: Them, maybe some others, and hopefully the numbers keeps growing.

<dvc>not sure about the intel stuff - I know a little about arm and riscv

<dvc>I can go and read about it, but I was hoping we had an expert...

<lfam>We have to grow our own experts ;)

<taylan>passing --fallback to guix build "solved" my strange hash mismatch issue. *shrug*

<lfam>taylan: Hash mismatches for a module import?

<taylan>lfam: yeah

<bavier>taylan: I'm guessing the download was corrupted in some way, or hydra has a corrupt cache

<lfam>taylan: That's been happening pretty often for me. I pass --fallback more often than not lately

<taylan>interesting

<lfam>Btw, I run my own mirror, so I haven't tried to diagnose or report it. I just figure something is bad in the cache

<dvc>I think it makes sense to revert to taking a system. Since we are interested getting a kernel configuration for a system, so the arch details of the kernel build should be abstracted/aren't relevant

<dvc>but there is still a problem with cross-compilation if we take a system we have to determine the system from the cross-compilation-target-triplet

<taylan>does anyone know where <gdk/gdkwayland.h> comes from?

<dvc>or we can assume that no one in their right mind will try to cross-compile for x86 or x86_64 from arm or mips

<dvc>:)

<dvc>I'm still indecisive, someone make a decision - I'm tired =P

<dvc>renaming the config files would fix the problem and if someone does port guixsd to i386 it's their problem...

<dvc>too tired - I can either fix it today by renaming the files or tomorrow morning by submiting a patch to ML

<lfam>dvc: I forwarded that bug report to bug-guix while you must have been composing a response :)

<dvc>sorry I'm not of any use today...

<dvc>:)

<janneke>lfam: looking at the diff, esp. commit messages of hydra patch set

<janneke>thanks again for the changes!

<lfam>I hope the changes are correct!

<nckx>Sorry if I'm the tenth person to ask, but: is something currently broken in the kernel config area?

<janneke>lfam: i hope so too :-)

<lfam>nckx: Yes, see http://debbugs.gnu.org/cgi/bugreport.cgi?bug=24440

<janneke>it all makes sense

<lfam>Okay, good :) I tried to make them "standard"

<nckx>lfam: thanks. Happy to hear I won't be up late hunting obscure local bugs. :-)

<lfam>nckx: Feel free to stay up late fixing the bug :)

<nckx>ACTION would like to go to bed before 3 at least once this week, thank you very much.

IRC channel logs

2016-09-14.log