IRC channel logs
2017-12-02.log
back to list of logs
<mb[m]1>Tangentially, I've started listing popular executables in description to make things more discoverable. <mb[m]1>buenouanq: if you can't find it in `guix package -s` or on the guix-patches bug tracker, the answer is probably "no". <nee`>buenouanq: I had some quick&dirty workaround package for it, but guile-pg only works with guile 2.0. The current code is build around some deprecated guile 1.8 C-api that was removed/changed with 2.2 <nee`>There is guile-squee for dead simple postgres interaction. <mb[m]1>I guess we could still take a "guile2.0" variant FWIW. <mb[m]1>But depending on two different guiles is no fun. <daviid>guile-squee can do much more then 'dead simple' interactions with postgres :), it actually will accept queries of any complexity... and will return the rows ... it is that it has almost no type conversion, ... <daviid>but it is true that it is sort of 'experimental' still. guile-pg is notoriously badely maintained <daviid>buenouanq: what are your needs wrt guile postgres, if I may ask? <nee`>Yes, you should be able to fully use all of postgres features with it, but the interface only does string-in string-out as far as I understand. I haven't used it myself yet, but I was planning to migrate some of my guile-pg dependant software to it. <daviid>nee`: that is correct (str-in str-out) <daviid>nee`: but you still can fully use postgres, as you confirmed <buenouanq>daviid: I have a website I want to rewrite using guile web and sxml. <buenouanq>I just started playing with the guile server today. <daviid>buenouanq: maybe guile-sqlite3 then? <buenouanq>I could prolly move to a different database easy enough. <buenouanq>And if that's all we have right now and for the forseeable future, that's most likely my best option. <daviid>buenouanq: just try guile-squee, then export your data and load them in sqlite, then try guile-sqlite3, then you'll be able to make choice... my 2c <adfeno>buenouanq daviid: another possibility would be to use something such as recutils. <g_bor>I just tried to build something no core-updates and m4 and python-boot0 does not build, I get a message that a decoding error occured in exception dispatcher. It seem like it's locale related, I'm on hu_HU.UTF-8 <g_bor>I'm tring this now on master to see if the problem persists. <roptat>hi, I can't remember how to run a specific system test... I'm trying to finish writing gnu/tests/dns.scm <roptat>now I'd like to setup ibus properly on guixsd, but it doesn't seem to work <roptat>I'm running openbox. ibus is started once I enter openbox, and I can switch between input methods <roptat>but it doesn't seem to do anything <brendyn>same for me. i dont know how to fix it <clacke[m]>I remember hearing somewhere you had to set guix-specific env vars? <clacke[m]>like you had your usual GTK_IM or whatever but now you had to set GUIX_BLAH instead? <rekado_>GUIX_GTK2_IM_MODULE_FILE and GUIX_GTK3_IM_MODULE_FILE <janneke>wip-bootstrap's mes-tcc now includes blood-elf's gdb debug info <janneke>that means that mes-tcc can now be run in gdb and show functions in a backtrace and break on them <roptat>should ibus be installed in the system profile or in the user profile? <brendyn>well the system profile just it will be in ever users profile <janneke>g_bor: congrats on your amazing [gcc-]ddc progress! <g_bor>The idea way yours after all, I just wanted to help :) <g_bor>I think once we have this we could extend this to at least binutils and glibc. <janneke>so, apart from the .la files now gcc-4.7.7 is reproducible?! <janneke>binutils and glibc are "just" source packages, not compilers -- why would we dcc them? <janneke>you mean, compile binutils with gcc and with clang and assert bit-for-bit reproducibility? <g_bor>Apart from the .la files, a compiler checksum that includes the .la files, a shell script and a python script. <g_bor>The two scripts are easy to solve, the checksum can be bypassed, but I don't want to do that, ad I think the libtool thing will do what we want. <g_bor>Yes, you are right in that those are source package, but critical ones. It would be great if we could come up with two different way to get to the same result here. <g_bor>I'm not sure how to do that, though <OriansJ>have the resulting compiler compile itself? <brendyn>Man it's been pouring down rain all day. It rarely rains for so long continuously here, it's making me all gloomy. <janneke>OriansJ: this gcc-ddc effort is gcc-4.7.4 being compiled by itself *twice* <janneke>but in different prefixes, and still be bit-for-bit reproducible <OriansJ>is the use of a move command not an option? <janneke>you mean to abstract away configure --prefix=/gnu/store/foo-gcc-4.7.4 and /gnu/store/bar-gcc-4.7.4? <OriansJ>prevent configure from having unique targets by simply building both steps at the same target but move the result of the first build <g_bor>I also think, that we might try to find out, what causes the problem with gcc 7. <janneke>however, we chose to build separate packages and compare those <janneke>the downside of that is: much more work <janneke>the upside is: truly bit-for-bit reproducible packages irrespective of installataion prefix <g_bor>Another easy option is to build on a symlink. <g_bor>However, I'd prefer these to be usable... <janneke>ACTION needs to run for a bit -- bbl <civodul>mb[m]1: you were right about the failing installation tests <civodul>it did work a couple of days ago though, so there's hope <mb[m]1>civodul: Any idea what caused it? Haven't been paying attention lately. <mb[m]1>I don't understand why core-updates is failing. I've bisected glibc down to the first two commits on the 2.26 branch, and also tried reverting the libatomic-ops update. <civodul>well maybe i should focus on one thing at a time :-) <civodul>you'll find yourself being a libc hacker without noticing <civodul>in this case it's the 'configure' file that leads to a decoding error <mb[m]1>I don't currently have the files. But I had built much further before the glibc update (with the C++ fixes only). <mb[m]1>I unpacked the m4 source and ran `file` on it: <mb[m]1>configure: POSIX shell script, UTF-8 Unicode text executable <civodul>so it could be an issue with iconv in the new libc <g_bor>starting phase `patch-usr-bin-file' Backtrace: 16 (primitive-load "/gnu/store/4jf0jcpvjn6r2warav5xmxhmddf?") In ice-9/eval.scm: 191:35 15 (_ _) In srfi/srfi-1.scm: 863:16 14 (every1 #<procedure 9b0b40 at /gnu/store/yifqwmdxc4pmd?> ?) In /gnu/store/yifqwmdxc4pmdpm73diq03lqkprnrizn-module-import/guix/build/gnu-build-system.scm: 711:27 13 (_ _) 171:4 12 (patch-usr-bin-file #:native-inputs _ #:inputs _ # _) In srfi/srfi <civodul>g_bor: mb[m]1 was just reporting the exact same issue :-) <mb[m]1>g_bor: Yes, I'm currently trying to track it down. <g_bor>I've also seen it on python-boot0, slightly different message. <g_bor>mb[m]1: can I be of assistance? <mb[m]1>g_bor: The failure happens in the build container which uses a fixed locale (C?). <g_bor>It just seemd to be some character conversion error... <g_bor>Maybe some invalid charaters leaked in somehow... <g_bor>It seems, that a lot of packages are broken. <g_bor>I laso got that for gettext. <mb[m]1>g_bor: Can you see if reverting 667082d59104d4b964dce878f5e8c0f8ad1be958 makes a difference? <g_bor>Do we know about what was the last time it was working? <g_bor>We could do a git bisect on core-updates? <g_bor>Do we have a good commit to start from? <atw>It looks like I will be able to attend the hacking session before FOSDEM :D <g_bor>atw: nice, good to hear that <g_bor>I think I will be a bit late, but trying to get there as I can. <g_bor>I think this will take a time... <g_bor>(guile does take some time :) ) <g_bor>I'm trying to help to switch the default icedtea to icedtea-8, and we'd like to that on core-updates... <g_bor>I've just written on the mailing list, that it would be nice if we could have substitutes for the core-updates gnu-build-system. <g_bor>That could speed things like this up. <efraim>mb[m]1: just popped in for a second, core-updates is failing on aarch64 also <g_bor>Do we have a bug report on that already? <g_bor>Now I'm trying what mb[m]1 suggested, by reverting the ncurses commit. <g_bor>It might be easier to track related information in a bug... <g_bor>reverting 667082d59104d4b964dce878f5e8c0f8ad1be958 did not help <nee`>Is there some way I can get a more percise error message out of this: <nee`>./pre-inst-env guix system reconfigure /etc/config.scm <nee`>guix system: error: failed to load '/etc/config.scm': <nee`>ice-9/eval.scm:224:25: ice-9/eval.scm:224:25: Unbound variable: #<variable 3355390 value: #<undefined>> <civodul>nee`: looks like some file are not compiled <nee`>It's in something from my package path I just found the error location. <nee`>Apparently I get better error messages about errors in my package path when I do `guix package -s something` <efraim>who tried to 'procedure the right string'? <str1ngs>is there any other official mirrors than mirror.hydra.gnu.org. I get like max 256kbs with that mirror frontend <lfam>str1ngs: That's the only official mirror, But we do have another substitute server, <https://berlin.guixsd.org>, which is not yet enabled by default. <str1ngs>also guix pull is recommended right? <str1ngs>berlin.guixsd.org is another build farm? <lfam>str1ngs: If you want to update the set of available packages, `guix pull` is the way to do it <lfam>Yes, we have two build farms <str1ngs>my issue with guix pull is that, you run into a chicken/egg problem <str1ngs>it complains guile2.0-git is not installed. I got around this before by building guile by hand along withe some extra depedns <lfam>That shouldn't be necessary. How did you install Guix? <lfam>Oh, no, that's normal. I misread it as 'guile2.0' <str1ngs>Your installation is too old and lacks a 'guile2.0-git' package. <lfam>guile-git is a library for doing Git operations in Guile. <lfam>There are two options here, I think. You could use `guix environment`, or you could install guile-git <lfam>`guix environment --ad-hoc guile2.0-git -- guix pull` <str1ngs>ah that right I installed guile-git by hand last time <lfam>That will make guile2.0-git available for the duration of `guix pull` <lfam>I just installed guile-git on my systems that are not GuixSD <str1ngs>well if guile-git was more readily available I would not be so bothered <str1ngs>or atleast have guix bootstrap that interm <str1ngs>I'm assuming guile-git is use to enhance git introspection. but it's bit of a pain as a dependancy