<mikadozero>It spits out a bunch of numbers to the screen and ends without puting anything in /tmp/python
<sturm>so that's weird - libcmis built fine for me
<sturm>different hash to what hydra failed to build on 1 Jan, so I guess hydra is just a long way behind?
<bavier>I have enabled binfmt_misc support for guix-daemon, but I cannot get very far with builds; I've run into a test failure for firstname.lastname@example.org when building with --system=aarch64-linux. specifically the test-suite/standalone/test-stack-overflow.go test
<lfam>It's in alsa-lib. It's not always the case that a particular program or library will share the name with its package. When it seems like something is missing from Guix but one is not sure, I recommend googling something like 'what package contains asound' and usually there are useful results
<apteryx>rekado: about libstdc++; thanks for pointing that out! I had misread the code :-)
<apteryx>I've just added libstdc++ for the current "gcc", it'll be interesting to see if it fixes my attempt to package crosstool-ng.
<CornBurglar>JACK Audio Connection Kit seems to not be working properly on GuixSD. When I run jackd in the terminal I recieve: http://0x0.st/ziDq.txt I'm not sure how limits.conf works or how I'm supposed to configure JACK. Any help?
<apteryx>rekado: by the way, the hack to filter out native-inputs from the global "inputs" on the build side works... it's ugly because it's ad-hoc and should be unnecessary IMHO, but it works: https://paste.debian.net/1069536/
<jlicht>Do we have an example of an out-of-tree kernel module among our guix packages?
<jlicht>or alternatively, do we at least have a way to access the 'built' sources of the currently running kernel, so I can at least do some local development?
<ng0>no, at the moment if memory serves me right and nothing changed, we can't access the built sources
<olivuser>Hello everyone. When I tried to install and use stumpwm I always got an error, and it didnt even appear in the wm selection on the login screen. Can anyone tell me how to properly install stumpwm (that is, is there several different packages that need to be installed, in a specific order, with a specific configuration)? Also, is it possible to set the os language pre-login? I mean I set de_DE-utf8 in the config file, yet I always enter user
<mikadozero>I have made progress on providing more information for the `guix challenge` bug I filled. I now have to things I can compare with diffoscope. But when use diffoscope on them I get lots of noise where it is reporting differences of date and permission. Does anyone know of a way to silence the date and permission information?
<kmicu>Anything maintained (and with a bug tracker) - LigthDM, GDM, SDDM, etc (LightDM compilation time is the shortest iirc so I use that.)
<mikadozero>Two commands that are cutting out the noise and giving comparable output are `diff -ur --no-dereference` and `diffoscope --exclude-directory-metadata`. Would the output from one of these provide sufficient supplemental information for the bug report or would they be missing important information?
<roptat>if there's already some changes between the two directories, I think that's good enough :)
<roptat>the number of links and mtime is probably just noise anyway
<mikadozero>roptat: I have checked python-3.7.0 and there were differences. I will submit diffs for some of the packages that `guix challenge` said differ.
<rekado>roptat: there’s a big section in the binary with strings; seems to be the only section that differs. Might be a sort-related difference.
<rekado> roptat: though that would be an odd cause of a segfault. Better to run this in gdb.
<mikadozero>For one of the packages diff says some binary files differ. While diffoscope outputs around 30k lines of binary diff information. Would the diffoscope output be useful to submit as supplemental bug information?
<rekado>the 30k lines are probably not very interesting.
<rekado>it might be a format that diffoscope doesn’t understand out of the box
<mikadozero>rekado: Thanks I was thinking along the same lines.
<rekado>e.g. when the binary section is compressed you would get huge differences out of just a tiny difference in the uncompressed state.
<mikadozero>rekado: I picked python and guile as two examples because they were the only ones that did not have guix in their names. The other 39 that had guix in their name. Are there any particular guix named ones in the bug report I submitted that I should focus on?
<rekado>I’m surprised about Python, because it builds reproducibly when built multiple times on the same machine.
<rekado>all of the guix-related outputs seem to indicate that something systemic is wrong with how they are built. It would be good to see one of them as an example, e.g. guix-cli
<rekado>mikadozero: but I’m actually more interested in the Python differences. They shouldn’t be there.
<apteryx>from what I've read it would point to an error in my environment such as C_INCLUDE_PATH, but I'm carefully setting this variable in my wrapper...
<mikadozero>rekado: Okay I will also submit a diff for guix-cli.
<apteryx>even more weird, is that if I turn my 'inputs' into 'propagated-inputs' and run the tool in a guix environment --pure --ad-hoc crosstool-ng, it can build the x86_64-centos7-linux-gnu toolchain alright!
<apteryx>so definitely environment variable related, but I'm out of ideas.
<ng0>after 0.16, is there a way to not read the channels.scm while pulling from a specified commit? I just had to write an alternative channels.scm I could use with -C
<pkill9>anyone familiar with this build error for a python package?: AttributeError: module 'tests.test' has no attribute 'suite'
<pkill9>hmm might need python-nose2 instead of python-nose
<ng0>you either lack an additional module/input or you need a version of "tests.test" provider which has the attribute
*mikadozero submitted diffs as supplemental information for bug report.
<mikadozero>Thanks to everyone who helped me get the diffs together for my bug report.
<rekado>mikadozero: thank you. The python things look like they might be order-related.
<rekado>the Guix stuff looks like it’s systemic in how “guix pull” works. Worth taking a closer look at the environment in which “guix pull” operates.
<mikadozero>rekado: Is there anything else I can help with in terms of providing additional information for the bug report?
<rekado>mikadozero: no, I think that’s excellent information already.
<rekado>at least for Python it already indicates a way forward
<inquisitiv3_>rekado: Thanks for the answer earlier. Didn't see it until now
<mikadozero>I have just went through the process of diffing packages that `guix challenge` highlights as differing. I think there is some room for improvement in the relevant parts of the manual sections 4.10 Invoking ‘guix archive’ and 7.11 Invoking ‘guix challenge’. Would it be helpful if I shared what I have learn in this process by making improvements to those sections of the manual? I would need to read the docu
<mikadozero>mentation for contributing Guix and also for texinfo which I have not used before.
<phenoble>nckx: right, - the official guix repo is defined as a channel itself, and can be given a commit hash. I see, thanks!
<nckx>phenoble: Hum. I'd be annoyed if a script did that: I use a manifest and those tools would be removed the next time I update. I think the only acceptable way (though it's probably not what you were hoping for) is just telling the user what may be needed and giving them control.
<nckx>And using ‘guix environment’ to provide the script itself with its dependencies.
<nckx>Don't assume you know the user and their environment in shell scripts, unless the user is you. :-)
<nckx>Scripts modify state, and will wreck anything that doesn't use the default profile for example, or manifests, or... So many assumptions.
<phenoble>nckx: But if you can't automate the install of a set of packages in guix/guile (can't you?), and so you have to resort to using the shell interface, .. what else can you do?
<nckx>phenoble: How about a ‘metapackage’ in a custom channel?
<nckx>phenoble: Disregard that. I know far too little about what you're trying to do.
<phenoble>nckx: sounds interesting; I think I was trying to do that before I came here: defining some kind of "empty" package with a list of dependencies, the dependencies being the set of packages i'm actually interested to have installed.
<phenoble>nckx: It's actually very simple: I'd like to create some configuration of binaries, here, right now, to be able to reproduce that same set of binaries somewhere else, e.g. 2 years from now.
<phenoble>I failed writing that "metapackage", because I didn't know what to put into the (source) field; which apparently is kindof required. I felt there must be a better/cleaner way, .... I'd be a bit surprised if there weren't.