IRC channel logs

<IpswichTriptych>Woohoo! I was finally successful in running "guix system reconfigure"!

<IpswichTriptych>I have a desktop environment now :D

<mekeor>cool. does it run nicely? :)

<mekeor>question: i'm trying to package a python-program. i get this error in "check" phase saying "Namespace Gtk not available for version 3.0". how do i fix it? – http://sprunge.us/JJJP

<mekeor>ACTION solved that issue by adding gtk+ as input

<IpswichTriptych>ACTION claps for mekeor

<mekeor>heheh :D

<Apteryx>efraim: gcc build failed with segfault. I guess it ran out of memory. manpages seems to still suffer from the same problem (gcc.1 has for only text "timestamp" in it). Hmm.

<Apteryx>I'm confused... After a failed build with 'guix build --keep-failed', I see in the derivation tree: "build/ environment-variables gcc-5.4.0/". Where are the built artefact? There appear to be both under build/ and gcc-5.4.0/.

<Apteryx>looks like some phase from our build system is corrupting the manual page source file.

<Apteryx>ACTION down the rabbit hole

<Apteryx>haha, I found the problem in the Makefile, although I'm not sure if it's caused by Guix or a bug upstream.

<Apteryx>One of the rule to create the intermediate .pod files that get transformed into the manpages reads like: $(STAMP) $@

<Apteryx>The problem is that STAMP is defined like: STAMP = echo timestamp >

<Apteryx>which means the source file gets overwritten with a literal "timestamp" string. Hmm.

<Apteryx>Yay! It was a bug in upstream gcc's contrib texi2pod.pl script, and it's been fixed in this commit: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=67b56c905078d49d3e4028085e5cb1e1fb87a8aa

<efraim>I suppose leaving it as 'timestamp' helps with reproducability

<efraim>guix build: error: python-nose-timer-drop-ordereddict.patch: patch not found

<Sleep_Walker>hi again

<Sleep_Walker>I managed to revive Guix once again and got bitten by bug#28522 as well

<Sleep_Walker>yet in my case is problem different

<Sleep_Walker>I'll try to describe it - should I continue with the same bug or file new?

<Sleep_Walker>the thing is that I am not able to do `guix pull` after I pull from 0.13.0 snapshot

<Sleep_Walker>always with the same error message

<Sleep_Walker>Your installation is too old and lacks a 'guile2.0-git' package.

<Sleep_Walker>OK, I used https://git.savannah.gnu.org/cgit/guix.git/snapshot/70bc608503f9029a065026a99ec45dbd0ec631c0.tar.gz to get that package and now `guix pull` continues :)

<Sleep_Walker>and it worked :)

<chetrbox>anyone know where i can follow progress on the guile issue that causes guix to be unusable on low memory (512MB ram) systems?

<chetrbox>is there a bugzilla entry somewhere?

<rekado_>chetrbox: it’s an upstream bug that has travelled up to libgc

<rekado_>chetrbox: so far, this is the most likely cause: https://github.com/ivmai/bdwgc/issues/182

<Sleep_Walker>efraim: regarding 285e18e9ae45970c67ec3b35d1d589bed32089f8 - can you scale bitmap fonts with Terminology? it was possible with bundled fonts but not otherwise

<Sleep_Walker>have you found workaround or you are using some scallable fonts instead?

<efraim>I'll have to pull it up on my GuixSD machine, on debian I use the system fonts and they scale

<Sleep_Walker>no rush

<Sleep_Walker>I think I have to figure out how to properly work with fonts on GuixSD

<civodul>Hello Guix!

<efraim>Sleep_Walker: when I use terminus there's no change, when I use any other font, for example dejavu sans mono, it changes when I move the slider

<efraim>this is for terminology on xfce on guixsd

<Sleep_Walker>efraim: and that is the behavior I expected

<Sleep_Walker>it could scale just bundled bitmap fonts

<Sleep_Walker>like always

<Sleep_Walker>that is the reason I keep them there

<Sleep_Walker>raster never seemed to care

<chetrbox>rekado_: thanks. is guile written in c++?

<Sleep_Walker>looks like C

<Sleep_Walker>can I somehow find latest generated grub.cfg?

<Sleep_Walker>I have grub which works and I'd like to add some static source of guix's grub.cfg to be able to boot these items from menu

<efraim>Clisp@2.49-60 keeps on freezing on a socket test for me

<roptat>hi, I'm trying to use guix's gcc to compile something for 32 bits on a 64 bits fedora

<roptat>I did gcc -m32 -c test.c -o test.o

<roptat>and got /gnu/store/rsw7c3iz4jwjfv5vwngm5fjzz44nxacn-profile/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-32.h: No such file or directory

<roptat>am I missing a package? is it not supported?

<efraim>our gcc isn't built with multiarch support, you'll have to use the i686 gcc[-toolchain]

<roptat>how do I use it?

<roptat>oh, I think I found it: guix environment -s i686-linux ...

<efraim>that was going to be my guess

<roptat>ok, it's going to build a few things first

<roptat>thank you :)

<roptat>I'm using a git checkout to update guix, but I get "guix package: warning: Your Guix installation is xxx days old." everytime I run a guix command

<civodul>roptat: there's a cheat code: the GUIX_DISTRO_AGE_WARNING environment variable

<roptat>is it documented?

<civodul>roptat: like all good cheat codes, it's undocumented :-)

<NullConstant>cheat codes in non-game software? seems a lil' ridiculous, don't you think

<Sleep_Walker>they are ridiculous in game software as well

<civodul>roptat: congrats on the Java patch series! :-)

<efraim>Which Java patches?

<mekeor>there's no substitute for latest texlive? or am i doing something wrong? – `guix package -i texlive` → http://sprunge.us/XWcZ

<efraim>Texlive-texmf is unsubstitutable

<mekeor>oh, i see, alright, thanks

<efraim>I actually had to manually transfer it from one aarch64 box to the slow one

<roptat>civodul: thank you :)

<Jackneill>why did guix choose guile instead?

<Jackneill>instead of the default nix lang?

<Jackneill>why was a rewrite necessary?

<kmicu>Jackneill: did you use Nix expression language?

<Jackneill>no

<Jackneill>i havent used guix/guile either

<kmicu>Writing Nix is terrible experience b/c Nix DSL has 0 tools. Guix by embedding DSL in Guile has plenty of them. That’s the one reason. There is more but I cannot find civodul’s mails about the topic at the moment.

<kmicu>ACTION should also add a poor joke “What you’re referring to as Nix lang, is in fact, Nix/Bash, or as I’ve recently taken to calling it, Nix plus ton of Bash.”.

<civodul>Jackneill: at https://www.gnu.org/software/guix/help/#papers you can learn more about the rationale

<Jackneill>thanks

<Jackneill>thansk for the joke as well

<civodul>but yeah, kmicu gave a good summary ;-)

<Jackneill>can i just add a pkg but not install it? (install it but no profile use it?

<Jackneill>like guix pkg -a

<civodul>"guix build" may be what you want?

<Jackneill>it seems to me 1 cmd doesnt just do 1 thing and 1 thing well

<Jackneill>if thats what i want

<Jackneill>poorly named and does too much, at a quick glance

<civodul>suggestions are welcome! (once you've gone beyond a quick glance, though)

<Jackneill>civodul, thanks, will read the manual, and get into this

<Jackneill>why is guix package 'package' instead of 'pkg'?

<Jackneill>seems more reasonable to me to use shorter version of the word when its completely talks for itself

<civodul>for consistency

<bavier>we try to avoid abbreviations in most places in guix

<civodul>but i don't feel like arguing on this, TBH :-)

<Jackneill>right

<Apteryx>civodul: thanks for looking at some of my patches!

<Apteryx>I will prepare an update for the texi manual with an example using the android-udev-rules package.

<Apteryx>Also, I'm trying to test a new patch for building the man pages of gcc, but when I run it with ./pre-inst-env guix build -K -c 1 gcc@4.7.4, it goes on to rebuild all the guix dependencies (it's a world rebuild inducing change). Anyway to take guix out of the loop? Building gcc itself is long enough as it stands.

<Apteryx>Maybe I could use my non-dev guix (from guix pull), and combine the "--file" and "--expression" flags of its build subcommand to tell it to use gcc@4.7.4 from ~/src/guix/gnu/packages/gcc.scm ?

<civodul>Apteryx: that's because everything depends on gcc@5, and gcc@5 is defined as (package (inherit gcc-4.7) ...)

<civodul>for testing purposes, you could define a GCC variant that inherits from gcc@5

<civodul>so you don't have to rebuild everything

<Apteryx>OK, good idea. What about the "--file" and "--expresion" options; can they be combined?

<Apteryx>I guess it'd still trigger a rebuild since the carefully selected gcc would override the gcc definition of the non-dev guix?

<civodul>correct

<Sleep_Walker>what is easiest way to write some contents to file during the build phase?

<Sleep_Walker>call-with-output-file ? which function will fill that output?

<civodul>i'd say call-with-output-file

<civodul>(call-with-output-file (lambda (port) (display "hi!" port)))

<Sleep_Walker>perfect!

<Sleep_Walker>thanks

<civodul>efraim: when reverting an upgrade, could you leave a note in the commit log explaining why?

<civodul>(thinking of binutils on core-updates)

<efraim>sure

<civodul>otherwise one might be tempted to re-upgrade :-)

<civodul>ACTION has to go

<civodul>later!

<efraim>i was tempted after running `guix refresh -t gnu'

<Sleep_Walker>does anyone have example of how to work with plugins?

<Sleep_Walker>(need to be installed into same path in profile)

<efraim>it looks like sbcl is our only user of clisp

<Sleep_Walker>telegram-purple works \\o/

<Sleep_Walker>what is correct way to create /var/lib/... directory?

<efraim>a service i believe

<Sleep_Walker>that actually makes quite sense :)

<civodul>hey rekado_!

<civodul>rekado_: i suspect berlin hasn't been building much since the last reconfigure

<civodul>oh there's actually an error: python-nose-timer-drop-ordereddict.patch: patch not found

<civodul>Steap: looks like you forgot to commit this patch for python-nose-timer

<civodul>could you take a look? :-)

<Steap>oh fuck

<Steap>see, that's why I stayed away

<Steap>from Guix

<civodul>heheh

<Steap>civodul: I should add it to gnu/local.mk as well?

<Steap>I'll push the patch directly, if it's OK with you

<civodul>yes, it should be in gnu/local.mk as well

<civodul>and sure, you can push it right away :-)

<Steap>this should be OK

<civodul>cool, thanks!

<civodul>berlin is already doing stuff

<Steap>btw, mails don't appear to be sent to guix-patches@gnu.org, do people filter on *@debbugs.gnu.org in their mail clients?

<civodul>yes, or based on the 'Sender' field

<laertus>i'm getting a failure from "guix pull": "fatal: repository 'https://gitlab.com/amirouche/guile-git/'; not found"

<laertus>tail end of a log of my guix pull: https://paste.pound-python.org/show/GB7ZFy6GE58ng09NL7Mx/

<civodul>laertus: that's without substitutes, right?

<laertus>yes

<civodul>the repo has changed URLs, it's now at guile-git/guile-git

<civodul>so either you enable substitutes temporarily while you run "guix build -S guile-git"

<civodul>or you clone the repo and then "guix download" from the local checkout

<laertus>does the second method do any kind of verification to make sure i'm not getting malware?

<civodul>yes, you need to do a checkout of the exact same commit

<civodul>and then "rm -rf .git" in that checkout

<civodul>and finally "guix download file:///that/directory"

<laertus>how do i know which commit to check out?

<civodul>it will work if and only if the content are as expected

<civodul>the commit appears in the 'guile-git' package definition

<laertus>where is that?

<laertus>sorry, i'm new to guix

<civodul>try "guix package --show=guile-git"

<civodul>or "guix edit guile-git"

<laertus>thanks

<civodul>clearly something we need to fix

IRC channel logs

2017-10-03.log