IRC channel logs


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
<buenouanq>oh no
<buenouanq>I didn't know it wasn't 2.2 compatible...
<buenouanq>that sucks
<nee`>There is guile-squee for dead simple postgres interaction.
<buenouanq>that might be enough, I'll check it out
<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
<buenouanq>the voice of reason
<adfeno>buenouanq daviid: another possibility would be to use something such as recutils.
<marusich>Hello #guix!
<g_bor>Hello guix!
<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.
<g_bor>Anyone seen that?
<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?
<roptat>ah, thanks
<brendyn>What do they need to be set to?
<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>brendyn: "ibus" I guess?
<brendyn>I found an answer here
<roptat>did it work?
<roptat>should ibus be installed in the system profile or in the user profile?
<brendyn>I'd have to restart Xorg to test it
<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>thank you!
<g_bor>The idea way yours after all, I just wanted to help :)
<janneke>"just" hehe :-)
<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.
<janneke>have you tried yet with clang-gcc?
<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>next step: add clang to the ddc
<janneke>OriansJ: move command?
<g_bor>Ok, next one is clang.
<OriansJ>as in mv foo bar/
<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>ah, that's a nice idea
<g_bor>It would be good to have.
<janneke>however, we chose to build separate packages and compare those
<janneke>the downside of that is: much more work
<OriansJ>single move folder per step?
<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.
<civodul>mb[m]1: no idea yet, let's see
<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>how's it failing?
<civodul>well maybe i should focus on one thing at a time :-)
<mb[m]1>So the culprit is likely one of these:;a=commitdiff;h=665ce88d68fd13c5c4cbaf2808434c618745137c and;a=commitdiff;h=dc258ce62ae0bbb456c6a855dbb6b384ecf7e988
<mb[m]1>civodul: "m4" and a few others fail like this:
<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
<civodul>could you check its encoding?
<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>Anyone seen this?
<g_bor>It's on core-updates:
<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>Can this be locale related?
<g_bor>I have hu_HU.utf8 here.
<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>Ok, then it's not that.
<g_bor>It just seemd to be some character conversion error...
<g_bor>Maybe some invalid charaters leaked in somehow...
<g_bor>Wait a sec...
<g_bor>It seems, that a lot of packages are broken.
<g_bor>I laso got that for gettext.
<mb[m]1>Can it be ncurses related?
<g_bor>Might be...
<g_bor>did not checked that.
<mb[m]1>g_bor: Can you see if reverting 667082d59104d4b964dce878f5e8c0f8ad1be958 makes a difference?
<g_bor>Ok, i will try that
<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>Ok, now it's building.
<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
<efraim>civodul too ^
<g_bor>Oh, well.
<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
<civodul>did you run "make" before?
<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 I get like max 256kbs with that mirror frontend
<lfam>str1ngs: That's the only official mirror, But we do have another substitute server, <>, which is not yet enabled by default.
<str1ngs>ill check that mirror out thanks.
<lfam>str1ngs: It's not a mirror :) It's another build farm that we run. You'll have to authorize its signing key in the normal way. The key is available here:
<str1ngs>also guix pull is recommended right?
<str1ngs> 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
<str1ngs>it's kinda tedious
<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