<marusich>I have 3 machines I tinker with. One is my main laptop, which is a Lenovo X200 using Libreboot. Another is an old Dell laptop with Ubuntu, where Guix is installed as "just" a package manager. And another is an Amazon EC2 instance, which is what I'm tinkering with now; that's GuixSD.
<marusich>My laptop is pretty darn slow for development :(
<marusich>I see. The manual says "further filtering is possible when called with a prefix," so I need to type C-u M-x debbugs-gnu, and then it will ask me for filtering options, including "pacakges".
<marusich>I see. And for debbugs-gnu-search, the unspoken expectation is that I am supposed to type "package" when asked for "attribute" and then after that type in a package name. Well, at least now I know.
<efraim>quiliro: phonon is a package located in kde-frameworks.scm, but yes, based on that list you should only need qt@4 and phonon
<efraim>lfam: agreed, but we need kurso to drop it, not for us to hack it together
<lfam>Or, we could exclude packages that depend on unmaintained frameworks. Other distros do choose this option sometimes
<lfam>A similar problem is found in webkitgtk@2. I'd estimate it contains at least 10 vulnerabilities allowing attackers to execute arbitrary code. That's based on the number of bugs fixed in webkitgtk@3
<efraim>we could, but its not quiliro's fault its qt4, if we're going to penalize people somehow i'd rather say "we'll include the recipe, but no substitutes for those packages"
<lfam>Mistake, it's not webkitgtk@2 vs @3, but @2.4 vs @2.14
<lfam>efraim: I agree it's not quiliro's fault. It will be our fault for distributing software that we know is not safe to use
<lfam>And it's also the fault of the upstream maintainers of kurso for not maintaining their program
<efraim>and if we sent a friendly email to the developers saying "hey, we want to include your software, but not if its relying on unmaintained and vulernable code" they might get the message that no one will have their software easily available
<lfam>I think this is a use case for "channels". There is already tension between those of us who want to create an operating system distribution and those of us who want to use Guix to distribute software that is not really excellent, like some of the scientific programs
<lfam>The scientists want it to be easier to package their software, but some of us are wary. Similar situation for things that depend on old frameworks
<lfam>In some cases, upstream has already ported their program but our packages need to be adjusted. For example, audacity
<lfam>IIRC, we need to update wxwidgets to use the newer webkitgtk
<lfam>Probably we should have a big discussion on the mailing list :)
<lfam>I noticed those being rebuilt as I tested changes
<stavreli>Hi I Hi, I have a question about packages. Packages are build using so called "recipies". Is it possible for a linux distribution to have two-three packages of e.g. python3 that are built from different recepies ?
<lfam>stavreli: Yes, that's possible, and we actually do it!
<adfeno>Also, I'm somewhat worried now, because I'm about to make a recipe for two other packages required by a third one (which I also have to make), but this third one requires patches to the other two, and I don't think this sounds reasonable to do.
<adfeno>In more detain: The third one distributes patches that need to be applied to the others.
<mbakke>lfam: AFAICT nothing is using python-minimal@2, can it be removed instead?
<lfam>Hm, I don't know. Maybe some person is using it?
<lfam>OTOH, that person hasn't offered to help maintain it :)
<lfam>IMO it would really be perverse for some upstream software to introduce a new dependency on python 2. But, if they did, keeping the minimal variant around will make it easier to avoid cyclic bootstrapping issues.
<lfam>However, we are spending lots of time on this package that may not be used by anyone at all
<mbakke>it could be re-added if something needs it later