IRC channel logs


back to list of 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):
<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) ->
<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:
<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
<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!
<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
<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>wm2: Copyright (c) 1996-7 Chris Cannam. Fourth release, March 1997
<ng0> Parts derived from 9wm Copyright (c) 1994-96 David Hogan
<ng0> xvertext routines Copyright (c) 1992 Alan Richardson
<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.
<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
<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?
<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
<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:
<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?
<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
<lfam>Weird behaviour with `guix environment` on NixOS:
<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:
<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:
<g_bor>roptat: Thanks!
<lfam>Another distro preparing to remove Qt 4:
<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>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.
<lfam>civodul: We already have a few of those. But I expect things like "" to have lots of dependencies
<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
<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
<jonsger[m]>lfam: I wanted to update direnv, but it adds a new go dependency. Is this 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.
<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> 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 "" "~/cloned" $5)
<lfam>thorwil: No, we usually just send an email to guix-devel if it seems very important
<catonano>amz3: gave me this #<git-repository 7fe0e0212540>
<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>just as a stepping stone for the pine64 currently
<vagrantc>but that's not armv7
<efraim>but the idea was to create a procedure to easily create other ATF packages, like with u-boot
<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>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 ?
<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?