IRC channel logs
2018-03-22.log
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>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? <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>hmm.. i did most of that minus having compiled guix <Cthulhux>ok, different errors now. so something probably broke during the ebuild... <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.. ) <efraim>Updating packages is always an option, and it gets you familiar with some of the peculiarities of some packages <thorwil>how to construct an appropriate service to wrap (mkdir-p "/tmp/.X11-uni")? <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.. <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.. <janneke> linux-libre-4.15.8 64.6MiB 5KiB/s 47:57 [#### ] 23.2% <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 <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 <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. <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>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>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, 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 <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. <lfam>civodul: No ~/.bashrc or ~/.bash_profile on this account <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 wonder if this ever worked, maybe I didn't try it before <lfam>I must not have used --pure <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 <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 <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>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 "k8s.io/kubernetes" to have lots of dependencies <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 <lfam>There are a few tools for managing the dependencies <civodul>it'd be too easy if there was just one tool <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 <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>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 <lfam>It's a possibility every time a package is upgraded <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. <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: maybe ask on #guile there is less chat <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>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 <efraim>but the idea was to create a procedure to easily create other ATF packages, like with u-boot <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>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 <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>it's when I'm a simple user that it breaks <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 <cbaines>Ah, I forgot to try the "fix for everything" for Guile... rm -r ~/.cache/guile/ccache/ anyway, I've got readline back! :D <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 ? <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 <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?