IRC channel logs

2019-02-22.log

back to list of logs

<sturm>is it just me, or does libreoffice always require building?
<sturm>oh, libcmis is failing its tests
*vagrantc dreads qtwebkit
<mikadozero>rekado_: So I tried this from the manual: `wget -q -O - https://ci.guix.info/nar/...-python-3.7.0 | guix archive -x /tmp/python` But it does not output anything to /tmp/
<mikadozero>Maybe I should do `mkdir python` in /tmp/
<mikadozero>No the mkdir idea did not fix it.
<sturm>mikadozero: you're aware that that URL isn't valid right? It has the "..." placeholder in it that should be a long hash value.
<mikadozero>sturm: Yes thanks I am using a complete url when actually executing the command.
<sturm>good just checking :)
<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 guile@2.2.4 when building with --system=aarch64-linux. specifically the test-suite/standalone/test-stack-overflow.go test
<Copenhagen_Bram>does ffmpeg for guix not support alsa?
<lfam>I can do `vim $(guix build --log-file foo)` with Hydra but not the Berlin build farm
<lfam>With Berlin it ends up trying to read the compressed log file without decompressing it
<lfam>I wonder if some MIME types need to be communicated? Not sure how vim does it with Hydra
<lfam>Also, I'm trying to build tinyssh but the build fails when it can't find 'libutil.h'. Where does this header come from?
<lfam>Copenhagen_Bram: Dunno, why do you ask?
<Copenhagen_Bram>lfam: because https://termbin.com/eidz
<lfam>Copenhagen_Bram: I'm not sure what they mean by 'configuration' (build or run time?) but this might help debug: https://www.ffmpeg.org/ffmpeg-devices.html#alsa
<Copenhagen_Bram>lfam: but it seems asound hasn't been packaged for guix
<lfam>Copenhagen_Bram: Why do you think that?
<Copenhagen_Bram>because guix package --search=asound comes up empty
<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
<Copenhagen_Bram>thanks
<Copenhagen_Bram>after installing alsa-lib I still get the same error in ffmpeg
<Copenhagen_Bram>even after opening a new terminal
<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/
<CornBurglar>Same error comes up with QJackCtl
<bavier>nckx: why no NAMEs in source uris?
<bavier>just curious
<apteryx>CornBurglar: in the info manual, type 'i' for index, then 'realtime'.
<apteryx>Make sure the snippet in the example is part of your Guix System OS configuration.
<apteryx>then you need to also add a system group "realtime" to your "groups" field, and add your user to it (using the `supplementary-groups' field of your 'user-account' record).
<CornBurglar>Thank you
<apteryx>yw!
<inquisitiv3>The installation script is failing because it seems that it can't find the PGP key
<inquisitiv3>I've downloaded the key that it says I should do, but the problem persists.
<inquisitiv3>Is it just me or do you people have the same problem?
<jonsger>installing ungoogled-chromium takes quite some time
<Sleep_Walker>no prebuilt binraries, right?
<jonsger>ah yes, but with the new view you only get this progress bar
<pkill9>:O chromium got added!
<pkill9>well done to all who worked on it
<pkill9>does this mean all the FSF approved distros agreed that the chromium source licenses are free?
<roptat>hi guix!
<janneke>hi roptat!
<pkill9>hey
<roptat>so they won't fix the issue with the svn download :/
<roptat>I guess I'll have to use the git mirror
<rekado>CornBurglar: JACK works fine. You may need to add the pam-limits-service.
<rekado>(pam-limits-service (list (pam-limits-entry "@realtime" 'both 'rtprio 99) (pam-limits-entry "@realtime" 'both 'memlock 'unlimited)))
***ng0_ is now known as ng0
<pkill9>that's what i had to do to get JACK working
<bendersteed>so i'm trying to start contributing to guix, so for a first try I updated projectile to the newest v2.0.0 tag
<bendersteed>when running ./pre-inst-env projectile-2.0.0 ends up in my store
<bendersteed>is this normal?
<bendersteed>build*
<pkill9>yeah that's normal
<inquisitiv3>Do you guys know if there's any known problems installing Guix with the installation script?
<rekado>inquisitiv3: no problems. Sometimes people can’t download the public key; in that case you’ll have to fetch it from another key server.
<bendersteed>pkill9: ok, so if I just want to check if the package build correctly without polluting my store, what's the procedure?
<rekado>you cannot circumvent the store
<rekado>but you can remove things from it with “guix gc -d /gnu/store/the-thing-i-dont-want”
<rekado>bavier: what do you think about building openmpi with hwloc-2.0 instead of just hwloc?
<rekado>I’m doing that locally right now because we’re having a problem with the OpenMPI from Guix with orte.
<rekado>(it’s fine with smp, but not with orte + infiniband)
<pkill9>why is it that when i run `guix build ungoogle-chromium --dry-run` it says it will download the package, but when i run `guix build ungoogled-chromium` it downloads the source?
<efraim>Try with '--no-grafts'
<rekado>I see a bunch of ungoogled-chromium items up in berlin’s store.
<rekado>it’s not impossible that something’s wrong with “guix publish”, but it does seem to serve other substitutes at this point.
<rekado>I have just restarted guix publish to rule out a problem with it.
<rekado>try again in maybe 5 mins
<pkill9>ok, thanks
<roptat>the source code is very big, so maybe it's taking time to be cooked
<pkill9>roptat: i don't think --dry-run would say that it will be downloaded if that was the case
<pkill9>s/it/the package
<pkill9>it would say it will donwload the source
<pkill9>download*
<jlicht>hey guix
<pkill9>hey jlicht
<jlicht>o/
<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
<olivuser>name/pw in the us layout on login.
<ng0>nix does something to achieve this, but I think we discussed this in the past and it was considered a bad idea. might be wrong
<ng0>jlicht: ^
<jlicht>ng0: I was afraid this was the case :/
<ng0>for nix it's just around 10 or 20 lines after the build
<jlicht>I probably could just inherit from `linux-libre', and add another output + phase to simply copy over the sources I guess
<jlicht>thanks for the pointers, ng0
<rain1>is guix bootstrapping java from jikes?
<ng0>maybe search the archives for what was considered "bad".. I think it was keeping the build + sources together
<rekado>rain1: yes.
<jlicht>ng0: yeah, I had found that as well, but I had hoped someone somewhere had reconsidered :-)
<rain1>where can I learn more about the details of that?
<rekado>rain1: near the top of gnu/packages/java.scm
<rekado>I started and stopped work on splitting up the icedtea6 package to reduce the bootstrap complexity, but that’s for later.
<rain1>thanks!
<olivuser>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)?
<ng0>usually just include it in the system profile
<ng0>I'm no stumpwm user, others should know
<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?
<g_bor>hello guix!
<g_bor>mikadozero: what exactly differs?
<g_bor>You can get rid of the link counts by something like exclude-directory-metadata.
<g_bor>However date differences on files are real reproducibility issues, so those are reported rightfully.
<roptat>mikadozero, you can run something like "find . -exec touch -mtime 197001010101 {} \;"
<roptat>it takes some time, but resets every timestamp
<roptat>g_bor, the date is different is this case because they come from archives that were decompressed outside of the store
<roptat>decompressing changes the mtime :/
<g_bor>roptat:ok, then your soulution is fine. I was assuming that store items are compared.
<roptat>I think one of them is a store item, but it's hard to check, because it's one of the items produced by guix pull...
<roptat>mh... smtpd is complaining that the permissions for the private keys generated by the certbot service is too lax
<roptat>and indeed the secret keys are world-readable :/
<g_bor>roptat: I belive this too lax permissions on secret things are not unique to smtpd.
<g_bor>It would be nice to have some way to manage secrets...
<g_bor>Any idea?
<g_bor>I mean something more uniform, these seem to be handled in a quite ad-hoc way now.
<mikadozero>g_bor: It is showing for many files that on has user write while the other does not and that one has a current date while the other has something like 1970.
<roptat>mikadozero, so the find/touch thing should work
<roptat>although it's not the right date
<roptat>I'm not sure which date is the right one
<mikadozero>roptat: I will try the find/touch.
<roptat>and find/chmod (on the local directory, not in the store!)
<g_bor>It seems that the 1970 one comes from a store item, so you should set to that. I belive that the date roptat gave you will work. When applied to the diretory that has the current time.
<mikadozero>roptat: I will also try the find/chmod.
<roptat>g_bor, but that's not a secret in the store, it's stored in /etc/letsencrypt
<roptat>so there's not reason why it should be world-readable
<roptat>I agree we need some sort of secret management, but I don't think it's the same issue here
<g_bor>roptat: yes, I know. How is it generated?
<g_bor>I belive that we might have some issue with the service generating the file here.
<roptat>by certbot, from the certbot service
<roptat> http://guix.info/manual/fr/Services-de-certificats.html#Services-de-certificats
<roptat>ah, that's the French one :p
<g_bor>What I meant in this case, is that the ad-hoc solutions might also get hard to maintain...
<roptat> http://guix.info/manual/en/Certificate-Services.html#Certificate-Services
<roptat>actually, the directory containing the key is not accessible to anyone except root, so it's still secure, but smtpd complains anyway
<roptat>and it seems that certbot has no way to configure that
<roptat>I think I can fix that with a deploy-hook
<roptat>I use one for reloading nginx, as demonstrated in the manual
<roptat>I could improve it to chmod the certificate
<g_bor>roptat: yes, I was also about to recommend a deploy-hook.
<g_bor>It seems like the way to go.
<roptat>do you know how to chmod the file pointed to by a symlink?
<g_bor>I believe that chmoding the symlink traverses seamlessly to the target.
<jlicht>How do people run ssh-agent on Guix System?
<roptat>g_bor, you're right!
<bgardner>jlicht: I just messes with this last week, I believe I ended up activating it in .xsession
<bgardner>*messed
<g_bor>jlicht: I belive that user-services would help here :)
<g_bor>Hope to get to that point soon.
<jlicht>g_bor: not yet, sadly; one needs to expose the SSH_* environment variables as well then :/
<jlicht>bgardner: yeah, that seems like it'll do for now ;-)
<g_bor>I use a shell startup file for that right now, I belive...
<g_bor>jlicht: I just had a look around, and it seems that gpg-agent can be used as an ssh-agent if you already have that working...
<g_bor>It seems like a good solution...
<g_bor>and there is also this: https://www.funtoo.org/Keychain
<jlicht>I was struggling to follow along to https://www.gnu.org/software/guix/blog/2018/customize-guixsd-use-stock-ssh-agent-everywhere/, but finally got it to work
<jlicht>using slim with `auto-login?' set to #t somehow got me stuck in a loop where xorg-server never started up properly, crashed, and was subsequently restarted by herd
<jlicht>%s/herd/shepherd
<pkill9>slim is slightly annoying because when you logout it logs you back in on autologin
<pkill9>but ah well, it's a solid login manager
<pkill9>one of those things that doesn't get updated because it does one thing well
<jlicht>somehow it dislikes running an .xsession with ssh-agent in there though, at least in my case
<bendersteed>if you are using gnome and want to disable gnome-keyring you can also follow the instructions here: https://wiki.archlinux.org/index.php/GNOME/Keyring#Disable_keyring_daemon_components
<jlicht>I consider myself more of an EXWM person, but thanks anyway :-)
<bendersteed>jlicht: oh i thought that GNOME was the problem because of the article
<kmicu>pkill9: SLiM is not get updated cuz it’s not maintained not cuz it’s ‘solid’ ;)
<pkill9>oh ok lol
<kmicu>(There is also no issue tracker so if you have some strange Xorg/GPG/ssh issues (happend on NixOS a lot) then better switch to something which had updates in last 3 years ;)
<pkill9>which do you use kmicu?
<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.
<roptat>thank you!
<rekado>bah, CVS…
<roptat>ah, nvim is not deterministic :/
<rekado>?
<rekado>New blog post: https://www.gnu.org/software/guix/blog/2019/guix-days-bootstrapping-arm/
<roptat>I mean reproducible
<rekado>I can’t reproduce the nvim segfault. I’ve never used it before.
<rekado>is it loading session state in your case?
<roptat>not on the guixsd system
<roptat>did you rebuild nvim yourself or did you get a binary from berlin?
<rekado>I built it locally.
<roptat>so maybe berlin built it in a bad way
<rekado>roptat: could you tell me the store path?
<roptat>/gnu/store/d8ibld5vpsgq7is3k3sf5gqj0i7sgmbh-neovim-0.3.4
<roptat>building it locally doesn't help me :/
<rekado>this one does indeed segfault
<roptat>how do you get another one if you're on the same commit?
<rekado>on berlin
<roptat>ah
<rekado>I’ve got both binaries here now. They differ.
<polezaivsani>Guix, what sbc's can i run guixsd on? I've read about bbb, anything else, plans maybe?
<rekado>what’s an “sbc”?
<polezaivsani>oh, sorry - single board computer, raspberries, beaglebones, etc
*rekado doesn’t know
<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.
<rekado>what package is this?
<mikadozero>rekado: guile-2.2.4
<rekado>oh.
<rekado>and the file is libguile?
<rekado>if you have a place to upload the binaries that would be good supplementary information.
<mikadozero>rekado: Three binary files: /gnu/store/9alic3caqhay3h8mx4iihpmyj6ymqpcx-guile-2.2.4/lib/guile/2.2/ccache/ice-9/suspendable-ports.go
<mikadozero>rekado: I do not have a place to upload the binaries. Any suggestions?
<rekado>that’s fine. Just mention the file names then.
<mikadozero>rekado: Okay
<rekado>thank you!
<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>what about those with “guix” in the name?
<mikadozero>rekado: Any specific packages that would be particularly interesting for me to submit diffs for? Otherwise I will pick at random.
<rekado>could you please tell me the bug number again?
<mikadozero>rekado: 34597
<rekado>thanks
<apteryx>I have a weird problem with my package definition: https://paste.debian.net/1069675/: At runtime, when building a cross toolchain, g++ errors with: g++: fatal error: unknown spec function 'gt'. I've included lots of debug info here: https://paste.debian.net/1069676/
<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
<pkill9>ah ok, i'm likely missing an input
*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.
<nckx>mikadozero: That's always helpful. Please do!
<phenoble>Hi #guix
<nckx>o/
<phenoble>Hm, is there a way to install a specific version of a package?
<phenoble>guix package --help suggests: no
<nckx>phenoble: If that version is packaged, yes (e.g. guix package -i gcc@5 gcc@6 gcc@7 gcc@8). If it isn't… maybe. See --with-source=.
<phenoble>nckx: I see, thanks.
<phenoble>What I'm essentially trying to do, is "archive" a certain guix configuration as running on a system, to have it reconstructed somewhere else at a later time.
<phenoble>I see there's also the possibility to "guix pull --commit=".
<nckx>phenoble: Exactly.
<phenoble>nckx: Excellent, so that covers the versioning part of what I'm trying to do.
<phenoble>nckx, if I may: what would you use to define a set of packages you'd like to preserve i.e. quick-install somewhere else?
<phenoble>I see perl scripts in the wild that'd just call "guix package -i" under the hood. But I wonder if there's a more guix-y way?
<nckx>phenoble: No idea if it would fit into your desired 'flow but channels also allow you to pin a specific commit.
<kmicu>mikadozero: thank you!
<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>s/shell //
<phenoble>nckx: Oh, the user would (most likely) just be me, for now .)
<phenoble>nckx: Oh, I think I wasn't quite clear what I meant by "script". I was thinking about an install script to install a set of software packages via guix on some other system.
<nckx>phenoble: Then it's fine, of course.
<nckx>^ if it's you.
<nckx>phenoble: Install scripts and guix don't go together IMO.
<phenoble>nckx: hmm
<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.
<nckx>phenoble: (source #f) should work.
*nckx has to go.
<phenoble>nckx: thank you!
<nckx>phenoble: Sending a more detailed write-up to help-guix might reach a larger audience.
<phenoble>nckx: I'll consider it o/
<nckx>phenoble: Also, before I go: the ‘Metapackage’ approach is probably better done through a manifest if it doesn't have to be a package. Since that's all it really is.
<phenoble>nckx: that, together with versioning via a commit has in channels, is just what i was looking for
*nckx helped someone \o/
<phenoble>So I'm trying to build emacs from source using a package that more-or-less mirrors the original emacs.scm in the guix repo.
<phenoble>This checks out, configures and build correctly, but during the install phase errors with: "ERROR: In procedure open: In procedure open-fdes: Permission denied".
<phenoble>I'm a bit puzzled by this; has anyone seen this before?
<phenoble>Ah, actually, that's not during install, but during 'reset-gzip-timestamps'
<rekado>phenoble: are you getting the sources from git?
<rekado>you may need to make the source files writeable.
<phenoble>rekado: yes
<nckx>phenoble: grep for make-git-checkout-writable in gnu/packages/.
<phenoble>nckx: thank you, got it
<phenoble>Let's see, on to build number 748...
<phenoble>rekado/nckx: Yay that did it, thank you.
<phenoble>But the built emacs is missing libpcre.so.3 now, though I just installed pcre via 'guix package -i pcre'?
<phenoble>fixed: wrong version got picked up...
<sykloid>Has anyone tried calling `guix pack --relocatable` on a manifest created using inferiors? I'm getting guile errors: https://paste.debian.net/1069738/