<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? <balduin>@davexunit perfect locking forward to watch the recording. Sadly I can't attend LibrePlanet 2018. <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>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 <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>I know others have asked but not sure if anyone has worked on a port <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>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. <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. <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” <adfeno>Has anyone succeeded on doing PDF export using the Org mode package from GNU Guix? <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. <ofosos[m]>They're issues on the guix-patches debbugs tracker. <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! <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")))`. 
