IRC channel logs


back to list of 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
<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> 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
<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.. the ) closes setup()
<ng0>is there a last , missing?
<ng0>no. i don't understand enough of 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
<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>gentoo bugtracker ftw, found this:
<ng0>fixed the build for python2.
<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?
<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
<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>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 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>Apparently *not* fixed in the latest mysql, 5.7.15
<lfam>And yet the 5.7.15 release notes do seem to address it:
<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
<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>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...
<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
<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.