IRC channel logs

<marusich>Tinkering with my computer on the weekend. What's up with you:?

<quiliro>ACTION is wondering if a beagleabone black will be as free and powerful as his centrino duo laptop

<quiliro>marusich: do you use GuixSD?

<marusich>I've heard about beaglebone blacks...are they just some kind of computer? Seems like Libreboot devs use them a lot.

<marusich>I do.

<quiliro>64 bits on GSD?

<marusich>Yeah

<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 :(

<buenouanq>quiliro: get a EOMA68 Libre Tea

<buenouanq>gonna be the first singleboard with an FSF RYF cert

<marusich>I've heard of those. They look cool!

<buenouanq>release was just pushed back 10 weeks (;-___-)

<buenouanq>but I'm super excited for them

<quiliro>buenouanq: i will need to get keyboard, monitor and mouse....anything else?

<buenouanq>for the libre tea?

<buenouanq>a mirco sd card or flash drive if you want extra storage

<buenouanq>the `micro desktop' thing they're offering on this first run might be something to get (I am), otherwise you'll need some cables/adaptors

<marusich>I'm reading the manual for debbugs-ug in emacs, and I don't get how it expects me to specify "guix pacakges".

<marusich>The manual says I can search by attributes including "package" name, but it doesn't seem to explain how I am supposed to specify such attributes.

<marusich>How does one do it?

<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.

<marusich>Neato.

<jmd>Anyone here planning to attend Libreplanet ?

<roelj>Is there a way to run a 32-bit wineserver on a 64-bit installation of GuixSD?

<bombastus>What would be the "correct" method for installing node.js packages on GuixSD? Should a guix package definition be created for each one? Would it be best to add npm to guix-import?

<snape>bombastus: A guix package definition should be created for each one

<snape>Since Guix is a package manager, it wouldn't really make sense to use another one

<snape>that does not solve problems Guix solves

<snape>But I don't know npm (node) enough to answer "how" should guix-import look like

<bombastus>snape: thanks. makes sense

<bombastus>I was just hoping for an easy way :P

<snape>bombastus: np :) What is the state of nodejs in Guix?

<snape>is there any nodejs package packaged?

<bombastus>Yes

<snape>There is node, indeed..

<catonano>snape: as far as I know, there are no new developments after my attempt to report about the query dependency tree

<snape>I see

<catonano>snape: here https://lists.gnu.org/archive/html/guix-devel/2017-01/msg01630.html

<catonano>about the jquery dependencies tree, not query.

<bombastus>catonano: that is a lovely dependency graph... wow

<catonano>bombastus: thanks :-)

<snape>I see you've done a lot of work already :)

<catonano>snape: I've made some work, yes.

<catonano>I'd like to continue it, not sure when

<catonano>right now i'm doing something else

<catonano>the discussion about a build system for pure guile packages would be an important step

<catonano>because I've done what I've done using amz3's library in an improper way. If it was a proper package it would be way better

<catonano>I've tried to make it a proper package with auotoconf

<catonano>I've reached a status where I should make available a module used for tests

<catonano>But I'm not willing to continue that. The autotools are a punishment

<snape>:D

<snape>ok. good luck then.

<catonano>;-)

<clacke[m]>catonano: Wow

<clacke[m]>"47311 vertices and 324569 edges"

<clacke[m]>This is a useful update to paroneayea's Javascript Packaging Dystopia

<catonano>clacke[m]: in fact, their blog post inspired me in chasing the truth about the jquery dependencies tree

<clacke[m]>very cool, glad you did it

<clacke[m]>so much work left to do, but the first step is knowing where to even start and this seems to provide a lot of that

<catonano>clacke[m]: my idea was to try to provide a more complete graphical representatiion of the graph. Not only the jquery graph, but all thhe nodejs thing

<catonano>maybe even woth some iinteractiviity

<catonano>I love the dev environment of neo4j

<catonano>that's realyl cool

<catonano>I don't know, though

<catonano>it's a awful lot of work. We'll see

<catonano>clacke[m]: anyway, if you want to get engaged, the file is online. You can use amz3's library, load the file and query the graph !

<catonano>you can help on the packaging, on the querying, on the GUI, whhatever you want !

<catonano>clacke[m]: it's here http://catonano.altervista.org/npmjsdata.tar.gz

<clacke[m]>thanks! I hope I will. :-)

<efraim>The php tests take a while

<civodul>Hello Guix!

<jmd>civodul: Hi Ludo.

<efraim>Hi!

<efraim>i have substitutes off on my aarch64 board, looks like its time to update the cpan mirrors again

<efraim>hmm, guix-daemon can't find the source for fish, wget gets it just fine

<jmd>efraim: Works fine for me.

<efraim>jmd: thanks for the confirmation, apparently I have something wrong with my environmental variables or something

<jmd>efraim: Or with your ISP?

<efraim>i'm running into issues with certificates and the importers, more likely on my end than the ISP

<efraim>plus I changed my DNS servers to opendns with google as a fallback

<jmd>Would someone with the necessary permissions please put a link from https://lists.gnu.org/mailman/listinfo/guix-patches to https://bugs.gnu.org/guix-patches

<quiliro>i wish Kurso would be included in GuixSD

<jmd>quiliro: Why don't you submit a patch for it?

<quiliro>jmd: i don't even know how to install it

<quiliro>jmd: https://uname.pingveno.net/blog/index.php/post/2013/06/23/How-to-compile-Kurso-de-Esperanto-from-source-with-Debian-and-Ubuntu

<jmd>I'm afraid I don't either. In fact I have no idea what it is.

<quiliro>it was packaged for parabola. but i do not know what are the dependencies for guix

<quiliro>so i could install it from source

<quiliro>for debian and ubuntu it is: sudo apt-get install build-essential qt4-qmake libqt4-dev g++ make libphonon-dev libqt4-xml-dev libqt4-opengl-dev

<efraim>qt4 is monolithic so that's easy, make and g++ are part of the build system

<efraim>and it looks like phonon is in kde-frameworks

<quiliro>efraim: so i need only qt4 and kde-frameworks?

<lfam>efraim: We need to drop qt4 eventually :)

<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 :)

<efraim>always fun times

<lfam>In the case of webkitgtk, the webkitgtk maintainers have resorted to begging and shaming distributions to update their packages

<lfam> https://blogs.gnome.org/mcatanzaro/2017/02/08/an-update-on-webkit-security-updates/

<lfam>So, we are not doing so good right now :/

<efraim>we did get that suprise update to qt4 last year or so

<civodul>those big C/C++ frameworks can be worrisome security-wise

<civodul>lfam: i'm looking at the python-minimal@2 issue on core-updates

<civodul>let's see!

<lfam>I'm writing a bug report about webkitgtk@2.4 which will present the problem and ask for advice

<efraim>from audacity: This is our first release after migrating from wx2.8.12 to wx3.0.2 wxWidgets library.

<efraim>for our currently packaged 2.1.2

<lfam>Yeah, I think there is a path forward for audacity

<efraim>oh, that one is old news

<lfam>Maybe, but we didn't read that section of the newspaper yet ;)

<efraim>kei updated the wxwidgets input in january

<efraim> https://github.com/audacity/audacity/blob/master/configure.ac#L585 i'm going to see if I can build it with gtk3

<lfam>Thanks!

<lfam>civodul: I think we should not let it delay the core-updates cycle too much. If python2-minimal ends up looking like python-minimal until we do python-updates, that's not too bad in my opinion.

<efraim>does anything actually use python2-minimal?

<efraim>i think I fixed the last staging-worthy blocker for aarch64 FTBFS today

<civodul>lfam: sure, i'm trying to fix a "quick fix" ;-)

<civodul>efraim: python2 mostly

<lfam>Cool :)

<civodul>looks like it might be enough to add zlib as an input

<efraim>i thought python2 relied on python3-minimal due to a building quirk and python2-minimal was a "me too" package

<efraim>No dependents other than itself: python-minimal-2.7.12

<efraim>on core-updates i'm still getting python packages that say "ran 0 tests in 0.000 seconds; phase 'check passed"

<civodul>oh right

<civodul>weird

<civodul>i thought it was actually used

<lfam>efraim: That seems _okay_ to me. The earlier problem was that test failures didn't cause the build to fail

<quiliro>so, in summary 'guix package -i qt@4 phonon' is correct?

<efraim>the cycle is python3-minimal -> xorg-server -> python2; theres 3 or 4 libraries that can be built with python2 or 3 so we have python2 depending on python3

<lfam>Python2 depends on python 3? It doesn't look like that in the package definitions

<efraim>quiliro: i'd do it as `guix environment --ad-hoc qt@4 phonon' if you don't want to write a package definition

<efraim>lfam: xcb-proto is one of them

<efraim>also libxcb and xorg-server

<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!

<lfam>For example, here are a variety of python 3 packages: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/python.scm#n318

<efraim>looks like python-lxml looks for python-cython during building

<efraim>ACTION heads off to bed, 11pm here

<civodul>good night, efraim!

<lfam>efraim: I see, python-2 depends on tk which includes python 3 in its graph

<lfam>Tricky!

<lfam>But, that explains the rebuilding behaviour that I saw

<stavreli>yes, how about having python version 3.5 as three different packages?

<lfam>stavreli: Sure, you just need to create package recipes with different variable names.

<lfam>For example, see how those package variables are defined as python-3.5, python-3.4, etc. You could give them any name. For example, python-3.5-with-foo

<stavreli>so depending on build parameters we can have many packages of the same version, e.g. python 3.5

<lfam>Yes

<quiliro>efraim: will `guix environment --ad-hoc qt@4 phonon' install the necessary packages for Kurso?

<quiliro>efraim: has left

<lfam>stavreli: We already have to python 3.5 packages: python-3.5 and python-minimal

<lfam>s/to/two

<catonano>quiliro: it will create an environment with qt4 and phonon in it

<catonano>when you exit that environment, they will be gone

<catonano>in this way you don't clutter your profile with pacages

<catonano>quiliro: did that help ?

<quiliro>catonano: so how can i install Kurso then in that environment

<quiliro>?

<stavreli>for example, OpenSSH can be compiled without support for X11 sharing

<lfam>stavreli: Sure, the sky is the limit when it comes to making custom packages in Guix.

<lfam>For example, I use a custom package of OpenSSH: https://github.com/lfam/pkgs/blob/master/leo/packages/openssh.scm

<catonano>quiliro: you can't install it, you have to use the environment to create a package or Kurso

<catonano>quiliro: I mean a recipe for Kurso

<stavreli>great !

<lfam>stavreli: You can have your own package repo that you use on top of Guix by setting the environment variable GUIX_PACKAGE_PATH (documented in the manual)

<catonano>quiliro: you can build that recipe while inside the environment

<quiliro>catonano: i don't know how to build a recipe

<catonano>when the recipe is ready, you can exit the env and send the patch :-)

<stavreli>Do you think that Guix will be the next Debian?

<catonano>quiliro: wait

<catonano>quiliro: here's the manual chapter for you https://www.gnu.org/software/guix/manual/guix.html#Programming-Interface

<quiliro>i can learn if someone tells me what to investigate

<quiliro>ok

<adfeno>stavreli: I hope it doesn't become patch doll though. Package recipe makers are advised to send patchs upstream.

<lfam>stavreli: No, Debian will adapt to do something Guix-y ;)

<adfeno>Because keeping up with such patches makes up for lots of work.

<CharlieBrown>What adfeno said.

<CharlieBrown>Custom packages suck.

<civodul>lfam: oh i just noticed your emails about python-minimal@2 and had just arrived to the same conclusion :-)

<lfam>Heh

<civodul>so with zlib + libffi, everything is fine

<civodul>that's almost the same as python-minimal@3

<civodul>which i guess means it's ok

<civodul>WDYT?

<adfeno>I'm having this patch-doll issue now with some package recipes I'm working....

<lfam>civodul: I think we might as well use the bundled libffi in python2-minimal

<lfam>civodul: It does seem to work when CONFIG_SHELL is set

<jahboite>adfeno: please, what means "patch doll"?

<civodul>lfam: though it's best not to use the bundled one, no?

<adfeno>jahboite: It's like a ugly doll full of cloths with different colors, figures, and such.

<lfam>civodul: Well, I based that preference on the fact that we used to use it in the minimal variants, and I thought that was on purpose, to keep the graph small

<jahboite>adfeno: ah i see. thank you.

<adfeno>... and some buttoms, but none actually coming from the original doll itself, because they are just "temporary fixes".

<lfam>civodul: But, it seems to work with either copy of libffi, so I don't have a preference one way or the other

<civodul>lfam: i think python-minimal@2 didn't have ctypes (which requires libffi), no?

<civodul>python-minimal@3 uses the system ffi because it requires ctypes

<civodul>anyway, not big deal as you say :-)

<lfam>I found experienced a python2-minimal build failure due to the libffi / ctypes issue when I added zlib and got past that particular problem

<lfam>s/found//

<lfam>ACTION Calls for a Python expert!

<stavreli>if there are recipes for packages, could we have recipe books? ;-)

<civodul>we should :-)

<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.

<adfeno>s/detain/detail/

<lfam>It does seem strange for package A to distribute a patch for package B

<lfam>But, that's one of the main reasons that people bundled libraries: to patch them

<adfeno>Yes, they *do* distribute the complete source of "packages B and C" in their source files (thus, are bundling).

<lfam>Ah. Well, I recommend you continue working on the patches and send them in once they work. It's hard to give specific advice without seeing them

<adfeno>But I somewhat understand why they decided to *keep* the patch files, so that distributor can see the differences.

<lfam>Yes, it's very nice that they include the patches

<lfam>civodul: python-minimal@2.7.13 fails like this if you add zlib but don't address the libffi issue somehow: http://paste.lisp.org/+7BR7

<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

<mbakke>or just leave it broken for now

<lfam>It's an expensive build, so I'd rather remove it than leave it broken on Hydra

<lfam>coreutils is failing on armhf on core-updates: https://hydra.gnu.org/job/gnu/core-updates/coreutils-8.26.armhf-linux

<lfam>I restarted it, but the it looked like something interrupted the build. The log just stopped in the middle of a line

<civodul>lfam: the patch i posted adds libffi as an input, so it works

<civodul>howdy mbakke :-)

<civodul>yeah we could also remove it if it's unused, dunno

<mbakke>sup civodul :)

<lfam>It's funny, I've been running my GuixSD system on core-updates for almost 1 week now. Many of these failures are instances of non-determinism sneaking in

<lfam>Problems due to features of the CPU or kernel

<civodul>when the log stops in the middle, it's typically a transient SSH failure or something

<lfam>The failure of coreutils means that we haven't built much of armhf yet :(

<mbakke>lfam: what other problems are there on core-updates?

<civodul>ACTION looks at elogind: https://hydra.gnu.org/build/1901314/nixlog/4/tail-reload

<civodul>probably causing quite a few failures too

<lfam>civodul: Upstream discussion of the elogind failure: https://github.com/wingo/elogind/issues/8

<civodul>lfam: oh great, thanks!

<lfam>mbakke: Failures in the latest evaluation: https://hydra.gnu.org/eval/109543?full=1#tabs-still-fail

<lfam>mbakke: Graphite2 should be fixed in Git, but that change hasn't been included in an evaluation yet

<lfam>civodul: I think you should push your fix for python2-minimal

<lfam>Hm, I wonder about the failure of qemu-minimal on i686-linux: https://hydra.gnu.org/build/1921356/nixlog/2/raw

<civodul>lfam: ok, will do!

<lfam>Perhaps a non-deterministic failure when the CPU is loaded, so I restarted it: https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg06718.html

<lfam>Hm, I'm not sure what to make of the libressl test failures on x86_64-linux and i686-linux: https://hydra.gnu.org/build/1886437

<lfam>I can't reproduce them locally

<mbakke>ugh, elogind still fails after backporting the upstream patch

<lfam>mbakke: In the same way?

<mbakke>no src/shared/af-list.c gets error: conflicting types for ‘lookup_af’

<mbakke>the file in question is gone in upstream git

<lfam>I guess we need to backport more changes, or build from Git

<civodul>mbakke: i've fixed this one i think

<civodul>the gperf thing

IRC channel logs

2017-03-19.log