IRC channel logs


back to list of logs

<rekado>Apteryx: jackd is supposed to be run as a user, not system-wide.
<apteryx1>rekado: I see. If the application runs it by itself, does it remove the need to run jackd as a user service?
<balduin>will there be a talk about Guix at LibrePlanet 2018?
<davexunit>balduin: yes
<balduin>@davexunit perfect locking forward to watch the recording. Sadly I can't attend LibrePlanet 2018.
<davexunit>hopefully the stream will work
<davexunit>so you could see it live as well
<davexunit>but the streaming is always hit and miss at libreplanet
<balduin>I am okay with seeing the recording. I am not to much into live streaming, especially not for conferences.
<davexunit>well in that case hopefully they will get the videos up quickly after the conference
<balduin>yes, hopefully.
<balduin>There was no GUIX talk at FOSDEM this year or did I overlook it?
<davexunit>there were a couple but I think they were more focused on certain subsets of guix
<davexunit>for HPC people and stuff
<balduin>@davexunit you are actually right. There are a couple of talks involving Guix at FOSDEM.
<balduin>Is there already a port for Guix on RISC-V or does the Guix community plan to support RISC-V anytime soon?
<davexunit>not sure
<davexunit>I know others have asked but not sure if anyone has worked on a port
<atw>balduin: cbaines gave a very nice introductory talk
<vagrantcish>just ran "guix package -u" and it worked, but now icecat issues an error something along the lines of: unsupported or invalid compression ... with nearly every site i've visited so far
<vagrantcish>switching back to the previous generation, those sites work fine
<vagrantcish>huh. now it's working with the newest generation.
<vagrantcish>maybe i opened the browser before the newest generation went live?
<vagrantcish>is it generally considered ok to backport patches from linux-next to linux-libre?
<Apteryx>vagrantcish: better ask the linux-libre maintainers :)
<vagrantcish>Apteryx: well, i was meaning the linux-libre packages in guix
<vagrantcish>basically, does it just take linux-libre wholesale, or is it ok to add patches coming in newer versions
<vagrantcish>from reading linux.scm's history, looks like extra patching is infrequent
<Apteryx>vagrantcish: we usually package whatever official releases upstream provides, so I
<Apteryx>I would think patching it in custom ways would not be accepted in Guix unless there is a really good reason for it.
<vagrantcish>Apteryx: sure, that's what i figured
<vagrantcish>ACTION waves
<jboy>rekado: here's my config that was leading to the weird backtrace the other day. I can't figure out how to get the text out of my qemu image unfortunately...
<jboy>(sorry, that's reverse order)
<jboy>I cobbled it together from the bare-bones and lightweight-desktop examples.
<rekado>Apteryx: if you’re using Jack 2 applications can autostart it via dbus. I only use jack 1, though, so when I want to do some music-related work I start it myself.
<rekado>the main output of icedtea-8 now builds reproducibly (the “doc” output still does not).
***danialbehzadi1 is now known as danialbehzadi
<Apteryx>rekado: OK! Maybe it's something specific to SuperCollider; it seems able to start jackd (from jack-1) by itself. It needs to be propagated in the PATH though.
<ofosos[m]>Hey Guix, is anyone interested in having kdenlive in guix proper? Otherwise I'd just keep it local.
<pkill9>i would
<wigust>Hey ofosos[m], Of course we would like to have kdenlive in Guix package collection. Does it require a much work on?
<pkill9>how do you work on the Guix package definitions without needing to build everything from source due to using the latest Guix from git?
<rekado>pkill9: you don’t need to build everything from source when using Guix from git.
<rekado>we try to avoid mass rebuilds by making big changes in separate branches.
<ng0>apteryx1: you packaging suppercollider? I've had a package for it for a long time and never got to do proper testing..
<rekado>ACTION imagines what a supper collision would look like
<ofosos[m]>I'm not impressed by kdenlive, it crahed after the first 5 minutes of editing
<ofosos[m]>But there's not too much adaption to make it work, it requires to add qt5 and gtk+-2 and some things to mlt and then it compiles fine. All the dependencies are already packaged
<ofosos[m]>wigust: the mlt patch is sent, I built a profile to support kdenlive, but still need to extract that into a package.
<ng0>speaking of a kdething, do we have enough of kde to get kopquete or whatsitsname, the social media graphical client, building?
<adfeno>Perhaps off-topic: Speaking of mlt, I find it confusing that I can't do a trick similar to `ffmpeg ... -filter:a "atempo=tempo=1.25, asetrate=r=40k" ...' using mlt.
<adfeno>it seems to either: (a) make the audio too slow; (b) the voice/audio sounding stronger than I want, and not allowing finner control/tune; (c) having "pop"/strange sounds together with the original track; (d) or just segfaults when changing rate using sox.rate.
<adfeno>This of course is an issue with mlt itself, not Guix, nor Guix's mlt package.
<efraim>ofosos[m]: I'm interested in kdenlive
<adfeno>ofosos[m]: I wonder if Qt is really needed in mlt, I mean, most Qt stuff take hours to build at least in Intel Core i5-2410M CPU @ 2.30GHz, i686 with 4 GiB RAM and `guix package' set with `-c 1'. And Qt stuff as far as I know must be kept without substitutes due to this issue.
<adfeno>Should'n't Kdenlive's mlt be separated from non-Kdenlive mlt?
<ng0>uh... no? we have substitutes for Qt stuff
<ofosos[m]>adfeno: that's an option, however if you want to use kdenlive you will have to compile mlt with qt support
<ng0>we just separate the output.
<ng0>for a software with just a Qt frontend and nothing else separation makes no sense
<adfeno>ng0: Oh, we have substitutes for Qt stuff? That's awesome :D
<ng0>the things that are not substitutable are small in numbers I think.. grep for "substitutable" in the source
<adfeno>strangely enough I always ended up building the "qt*" stuff for each package that depend on these, for some strange reason. And I only do upgrades or installs after a fresh `guix pull'
<ofosos[m]>Btw, I have the following problem: after successfully building a package, how to I rebuild or challenge it to check for reproducibility? All options I tried end up not rebuilding the package :(
<ofosos[m]>Neat, I'm getting better at this. First try and package does build :)
<rekado>ofosos[m]: “--check --no-grafts”
<ofosos[m]>rekado: thanks :)
<adfeno>Has anyone succeeded on doing PDF export using the Org mode package from GNU Guix?
<adfeno>I mean: the latest one
<adfeno>I'm in #org-mode now discussing this issue, but I want to know if other people are seeing the same problem.
<rekado>adfeno: you need texlive; do you have it?
<ofosos[m]>Ok, for those who want to try kdenlive: 30770 has mlt and 30771 has kdenlive. Please give it a spin. Currently I'm testing for reproducibility.
<pkill9>what are those numbers?
<nckx>Look like bug#s.
<ofosos[m]>They're issues on the guix-patches debbugs tracker.
<ofosos[m]>Looks good.
<adfeno>rekado: Yes, I do have texlive
<adfeno>rekado: texlive@2017, store path: "/gnu/store/fd6g84lr2qnffqf8qhp28k3fb4cbmwq8-texlive-2017", from a `guix pull && guix package -u' made in 2018-03-11.
<ofosos[m]>Ive added mlt as a propagated input to kdenlive, but in theory I could wrap PATH and point it to mlt/bin, any opinions on this?
<nckx>civodul: Small (future) QoLife improvements like the new bootstrap phase are also nice to see. Thanks!
<pkill9>what's the new bootstrap phase?
<civodul>davexunit: thanks for the new releases! :-)
<civodul>nckx: yes, simple things that make our lives better :-)
<mbakke>ofosos: wrapping is better than propagating, but it's even better to make the code use absolute paths, if possible. E.g `(substitute* "foo" (("mlt") (string-append mlt "/bin/mlt")))`.