IRC channel logs

<rekado>bavier`: the glibc thing is probably just because of the obsolete graft. It will disappear when core-updates is merged.

<rekado>efraim: I’m not going to touch glibc for a while :)

<rekado>davexunit: sorry, I don’t know of a screenshot of that, but I agree with nckx that having that instead of (or in addition to) the login screenshot on the website would be very useful.

<mbakke>This is a pretty good article about build flags (mainly hardening related): https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/

<mbakke>It would be great to have a "#:hardening?" option with additional provisions for specific flags.

<nckx>Wasn't ng0 working on/suggesting such a thing?

<Cthulhux>so... guix is not really working on gentoo (0.14.0) -> https://paste.pound-python.org/show/KMtPu39FsqhSLfG1zxnz/

<Cthulhux>known problem?

<iyzsong>Cthulhux: i don't know. but if you're using system's guile and compile guix from source, you may want to try the binary install method.

<Cthulhux>all i did was "emerge guix", guile came with it.

<Cthulhux>binary install method?

<iyzsong>yes, See: https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html#Binary-Installation

<Cthulhux>hmm.. i did most of that minus having compiled guix

<Cthulhux>ACTION tries

<Cthulhux>ok, different errors now. so something probably broke during the ebuild...

<Cthulhux>thank you

<Cthulhux>i'll investigate from here .)

<bytes83>What are the technical prerequisites for GSoC 2018 with respect to the Guix projects ?

<bytes83>I recently started exploring Guix and some of the GSoC projects are interesting, but I am not very experienced with Guix and Scheme.

<bytes83>Are there any beginner friendly TODOs that I can start working on to get started with contributing to guix. (Not just for gsoc.. )

<janneke>bytes83: have you seen https://www.gnu.org/software/guix/manual/html_node/Contributing.html

<bytes83>janneke, yes i have.

<efraim>Updating packages is always an option, and it gets you familiar with some of the peculiarities of some packages

<civodul>Hello Guix!

<efraim>Hi!

<thorwil>'lo

<thorwil>how to construct an appropriate service to wrap (mkdir-p "/tmp/.X11-uni")?

<civodul>the Shepherd 0.4.0 is out!

<janneke>civodul: yay!

<mange>civodul: Oh, yay!

<wigust>What does mean “Add native language support (5 languages currently supported)” in https://git.savannah.gnu.org/cgit/shepherd.git/tree/NEWS?h=master#n18

<rekado>wigust: translation support?

<wigust>rekado: Thanks for clear it. I thought about translation support or programming languages :-)

<mange>civodul: What is the minimum version of Guile that we require for the Shepherd? In the README we just say "2.x", but could we bring it in-line with Guix (which is "2.2.x" or "2.0.13 or later")? The main thing I want is to remove the EINTR-safe function, which requires 2.0.10.

<mange>Also, unrelatedly and unimportantly, should I be using a "the" before "Shepherd" all the time? I feel more natural just calling it "Shepherd" (like "Guix"), but others seem to like the definite article.

<ng0>sneek: later tell lfam: I thought I catched every header.. Thanks for the commit :) So many files I worked in..

<sneek>Will do.

<civodul>mange: you should use the definite article, just like for "the Hurd" :-)

<civodul>regarding Guile requirements, we can align with Guix as you say

<civodul>and remove EINTR-safe and other workarounds for old versions

<ng0>this wm has no copyright headers and I have the hunch that the copyright of where it derives from (9wm) is not compatible to what we allow. There's a note on the xvertext routines in the sourcecode itself and this note upon running wm2 in the terminal:

<ng0> Copying and redistribution encouraged. No warranty.

<ng0>just checking if it's something to keep in my repos or if we could make use of it proper included in Guix master.

<ng0>it's very old and hardly has any functionality and can't even be configured (by design), but modification is as easy as modifying suckless software in Guix :)

<mange>civodul: Okay, I'll put together some commits to update the README and remove some of the workarounds in the next few days.

<civodul>awesome

<ng0>oh. 9wm is (!sic) MIT license. So depending on what xvertext is licensed as this part is okay. The part that should be verified is the license 9wm itself has..

<ng0>*wm2 has

<ng0>too many windows.

<janneke>i keep getting: Downloading http://mirror.hydra.gnu.org/guix/nar/gzip/33rw5iqpnnvf5xl0y55w5f64ngva5fnm-linux-libre-4.15.8...

<janneke> linux-libre-4.15.8 64.6MiB 5KiB/s 47:57 [#### ] 23.2%

<janneke>gzip: stdin: unexpected end of file

<ng0>have you trued with fallback?

<janneke>no...

<ng0>4.15.8 is old, 4.15.12 is newer

<janneke>okay, tnx...but serving a broken nar is not so nice, right?

<ng0>most recent version that should be on hydra is .15.12, but .15.10 should still be there

<ng0>indeed

<janneke>ACTION rebases on latest master

<ng0>mbakke: I found your comment from yesterday. would be great to keep this on the mailinglist, trying to track possible solutions.

<ng0>So far I just managed to get to wrecked bootstrap binaries ;)

<ng0>maybe next month when I have time to look into that

<efraim>does anyone else's rotlog complain about not finding sendmail?

<castilma>hey guys, how do you reconfigure your system directly after a guix pull that contains a new linux version? do you build linux? or do you wait until there are substitutes? or how do you tell guix to stick to the current kernel?

<efraim>i just reconfigured one of my systems, I run guix from a git checkout so I rolled back to just before the latest kernel bump and then reconfigured

<mbakke>efraim: rottlog has complained about sendmail for a while. Should we give it one?

<efraim>it looks like we do have a sendmail package

<efraim>as long as the logs rotate I don't have a strong preference

<efraim>they do seem to rotate

<castilma>can someone tell me, what GUIX_PROFILE is for? on my system, it is set only in login shells(from /etc/profile).

<castilma>and it is not exported. I ask, because $ source my-env-root/etc/profile; doesn't work, if GUIX_PROFILE is set.

<mbakke>Wait, what? The new PyPi interface "Warehouse" is purposedly not showing PGP signatures: https://github.com/pypa/warehouse/issues/3356

<efraim>Purposely?

<rekado>“While we support uploading them still and they're still a part of the API, we're not exposing them to the user in the UI.”

<efraim>Then what's the point?

<rekado>¯\\_(ツ)_/¯

<efraim>It'd be like if you told me that github let you download signatures and not jsut tarballs or commits

<efraim>'Verified commit', verified by github

<efraim>I wish syncthing had a good CLI interface for the fingerprint exchange

<efraim>I want to add a machine to my circle but don't want to fire up X

<g_bor>Hello guix!

<g_bor>I've now merged master into my wip-change-default-java8 branch. I'm checking my remaining two issues. I also feel, that #29893 should be safe to push now. Could you have a look at that?

<roptat>g_bor: I'll have a look at #29893 this evening

<lfam>`guix environment` stopped working on NixOS for me

<sneek>lfam, you have 1 message.

<sneek>lfam, ng0 says: I thought I catched every header.. Thanks for the commit :) So many files I worked in..

<lfam>sneek: later tell ng0: It was my mistake, I accidentally reverted your change in my commit

<sneek>Okay.

<lfam>Weird behaviour with `guix environment` on NixOS: https://paste.debian.net/1016033/

<roptat>guix environment guix gives every tool to build guix, but not guix itself

<roptat>but having nix-profile in the PATH is weird

<lfam>The $PATH after entering the pure environment should only include paths in the guix store

<lfam>Either there was a regression in `guix environment` or something changed in NixOS

<lfam>That errant `guix --version` is confusing, sorry. It's not the point of my paste :)

<lfam>`guix environment --ad-hoc` does work

<lfam>And so does regular `guix environment`, without --pure.

<mbakke>Is Danny around here? The Ghostscript patches fail to apply on 9.23.

<civodul>lfam: bogus bashrc no?

<lfam>civodul: No ~/.bashrc or ~/.bash_profile on this account

<civodul>or /etc/bashrc

<civodul>or /etc/profile

<civodul>one of these :-)

<lfam>Yes, they must have changed bashrc recently

<civodul>try "guix environment --pure whatever -- $SHELL -x"

<lfam>I don't know anything about NixOS, not even where the responsible code is stored

<lfam>I guess this part of /etc/bashrc could do it: https://paste.debian.net/1016035/

<lfam>Yes, that's the culprit

<lfam>I wonder if this ever worked, maybe I didn't try it before

<lfam>I must not have used --pure

<civodul>$__ETC_PROFILE_DONE, argh

<civodul>lfam: how did you create those Go packages we have, BTW? we don't have an importer, right?

<civodul>i'm asking because i'll need to package gitlab-runner for work

<lfam>I made them by hand, but we need an importer. Go software tends to have beaucoup dependencies

<lfam>I wonder if you will find yourself wanting something like what I described here: https://lists.gnu.org/archive/html/guix-devel/2017-10/msg00030.html

<g_bor>roptat: Thanks!

<lfam>Another distro preparing to remove Qt 4: https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/1757320

<g_bor>What is the policy about bootstrap packages? Add the minimal amount of bootstrap packages, or make sure that the leaf packages are build by tools that have their test working?

<g_bor>I'm now bootstrapping the java test frameworks, and I have the minimal amount of bootstrap packages at the moment.

<civodul>lfam: ooh! i had forgotten that message of yours

<civodul>not very encouraging :-/

<lfam>No worries... I've been waiting to hear others' experiences

<lfam>I think that Go resists packaging, but does not make it impossible

<civodul>nicely put :-)

<civodul> https://gitlab.com/gitlab-org/gitlab-runner/blob/master/Gopkg.toml

<civodul>it could keep me busy for a while...

<mbakke>DNSCrypt has been rewritten in Go, but I haven't mustered the courage to try updating it.

<civodul>uh

<lfam>civodul: We already have a few of those. But I expect things like "k8s.io/kubernetes" to have lots of dependencies

<lfam>Oof: https://github.com/kubernetes/kubernetes/blob/master/Godeps/Godeps.jsonhttps://github.com/kubernetes/kubernetes/blob/master/Godeps/Godeps.json

<lfam>You'll want an importer

<civodul>ACTION forgets about Go, looks at the sunshine

<lfam>Honestly, I don't know how critical Go software is built. Every organization must have hacked something up

<civodul>oh why is that one JSON?

<lfam>There are a few tools for managing the dependencies

<lfam>E.G. https://github.com/tools/godep

<civodul>it'd be too easy if there was just one tool

<lfam>There will be: Guix

<lfam>Actually, the latest version of Go builds a memoized cached into the Go compiler

<lfam>I haven't taken the time to figure out how to make use of it while building within Guix, though

<lfam>mbakke: I skimmed the dependencies of the new dnscrypt. It doesn't look *too* bad

<mbakke>lfam: Thanks, I hadn't even checked that yet. I'll give it a go once I have some spare time and a bottle of scotch.

<lfam>Yes, you'll need some supplies

<civodul>:-)

<jonsger[m]>lfam: I wanted to update direnv, but it adds a new go dependency. Is this https://gitlab.com/jonsger/Guix/commit/b6608b8f1ff2072cd8ced2c4e0383fed69ef25a9#d8d029a547598a800065293e1bf19f03c98a1faa_115_117 a proper way to include such a go package to native-inputs of a "normal" guix package?

<lfam>jonsger[m]: Overall looks good to me. Remember to se the file-name of the source code. Also, where does that version "1.19.1" come from?

<lfam>I mean, remember to set the file-name

<jonsger[m]>lfam: I don't know. Some weeks ago. I think it was for testing purposes. But otherwise thanks for the feedback, I'll prepare a patch at the week end :)

<rekado>I have another glibc / linux 2.6.32 (RHEL6) problem.

<rekado>Java no longer works :(

<rekado>it makes a syscall prlimits64 and the return value is ENOSYS (Function not implemented). The result is that Java crashes with an OOM error.

<rekado>sorry, the syscall is called “prlimit64”.

<rekado>I checked the sources for the current RHEL6 kernel, and the syscall is in fact not implemented.

<efraim>ouch

<thorwil>lfam: is it trivial to keep both krita 3 and 4 around?

<lfam>thorwil: Yeah, we could offer both

<thorwil>how are homedir .config files handled in such a case?

<lfam>They wouldn't be handled by Guix

<lfam>And you probably wouldn't be able to have both installed in the same profile. But you could keep separate profiles for them or use guix environment

<thorwil>so it would be fine for a project that versions its config files, but could be trouble for those who don't

<g_bor>rekado: can we help somehow? It seems that this was implemented in upstream linux on v3.4-rc1.

<lfam>thorwil: Yes, but the issue is not specific to krita

<g_bor>It does not seem a trivial commit.

<thorwil>lfam: seems it's mainly an issue of informing the user, then

<thorwil>lfam: sure, while the number of krita users on guix actually affected might be zero, it's still an example of something that might happen repeatedly

<efraim> https://fedora.juszkiewicz.com.pl/syscalls.html is the closest I have to knowing things about syscalls

<lfam>It's a possibility every time a package is upgraded

<catonano>amz3: are you here ?

<amz3>catonano: yes

<rekado>g_bor: no, I think I’m out of luck here.

<thorwil>lfam: there's no channel for presenting such messages to users right on an update, yet, right?

<catonano>I am trying to get my feet wet with guile-git

<rekado>g_bor: I have already asked IT to please upgrade the cluster nodes.

<catonano>amz3: this (clone "https://gitlab.com/humanitiesNerd/tributi.git" "~/cloned" $5)

<lfam>thorwil: No, we usually just send an email to guix-devel if it seems very important

<rekado>at least this gives me even more reason to add a section to the paper to talk about the impact of Linux on reproducibility.

<amz3>catonano: yes

<amz3>catonano: maybe ask on #guile there is less chat

<catonano>amz3: ah right

<catonano>amz3: sorry

<g_bor>rekado: sorry to hear that, I've checked when the change was introduced to glibc, it is Tue, 9 May 2017 14:05:09 +0000 (14:05 +0000)

<g_bor>Actually if it comes to patching, this is the better candidate, I think.

<efraim>hmm, looks like arm trusted firmware now supports armv7 also

<vagrantc>think it always has

<vagrantc>but not a lot of hardware makes use of it

<efraim>the readme finally mentioned it, now to change the logic in my package to allow for it also

<vagrantc>do you have any platforms where it's actually used?

<efraim>nope

<efraim>just as a stepping stone for the pine64 currently

<vagrantc>but that's not armv7

<efraim>right

<efraim>but the idea was to create a procedure to easily create other ATF packages, like with u-boot

<efraim> https://gitlab.com/Efraim/guix/commit/6302eb4b9852f022d1d169000e0d2508e3116888

<efraim> https://gitlab.com/Efraim/guix/commit/dddcf60edef828ef88eab3a0a1177420eb8397e1

<vagrantc>got it

<mbakke>efraim: The meson armhf patch still needs (guix utils) in the builder inputs (try building json-glib on any arch).

<efraim>mbakke: i tried building libmpdclient and saw the error

<slim404>hello

<slim404>so I have this problem with guixSD

<slim404>when I guix pull it fails to buils guile 2.2.2 it seems

<slim404>whereas when I do the same thing as root, it works perfectly

<slim404>It looks like it simply downloads a derivation

<slim404>I don't know why on my session as a user, it tries to build guile

<slim404>maybe I messed some config

<oreloznog>slim404: Hello :) Did you make '# guix package -u' ? and also '$ guix package -u' ? (After the guix pull) It's for updates

<oreloznog>slim404: I'm a newbie in guixsd, so i don't know if i can really help... :)

<cbaines>Readline no longer seems to work for me with Guile on GuixSD... makes using Guile quite painful, is this a problem for anyone else?

<slim404>oreloznog: yes, thanks :)

<oreloznog>cbaines: Hello :) No idea...

<slim404>as root everything works fine

<oreloznog>slim404: :)

<oreloznog>and in $ guix package -u ?

<slim404>it's when I'm a simple user that it breaks

<slim404>oreloznog: checking...

<oreloznog>the attempt of updating in single user fails ? No idea...

<slim404>oreloznog: it starts building things... I must have messed with some parameters and now it builds everything from source

<oreloznog>slim404: Hope it will be good :)

<cbaines>Ah, I forgot to try the "fix for everything" for Guile... rm -r ~/.cache/guile/ccache/ anyway, I've got readline back! :D

<slim404>cbaines: looks good, I'll try it

<cbaines>that wasn't meant as a suggestion, but it shouldn't do any harm

<oreloznog>A little experience of my own installation of GuixSD on a laptop. (from an end user's like :) Maybe helpfull for beginners ?

<oreloznog> https://www.hubert-lombard.website/GuixSD/html/installation-de-GuixSD-sur-laptop-hp-probook-6460b.html

<slim404>oreloznog: helpful

<oreloznog>slim404: \\(^o^)/

<terpri>slim404, i think i've run into a similar issue, where guix was unnecessarily building guile for 'guix environment' but not for other commands

<slim404>terpri: how did you solve it?

<terpri>slim404, does the behavior change if you use --bootstrap with guix pull? (which should use a different guile derivation for building packages)

<terpri>slim404, i didn't :) it still worked for me, it was just a lot slower

<slim404>terpri: is it safe to use --botstrap ?

<terpri>slim404, hm, the manual says it's "only useful to guix developers", but i don't see how using the prebuilt guile package could hurt anything (assuming you trust the binaries from guix)

<slim404>terpri: thanks, will try it next (when it will fail building guile after deleting the cache)

<jboy>can anybody point me in the right direction for getting a yubikey working under guixsd?

IRC channel logs

2018-03-22.log