IRC channel logs


back to list of logs

<jxself>Well, after thinking about it, perhaps I will take a stab at a modified Firefox. Since this is a whole new thing for me, no promises though.
<jxself>tar xf firefox-31.1.1esr.source.tar.bz2
<jxself>Oops; wrong window.
<mark_weaver>jxself: \\o/
<jxself>I'm not sure where I got 8GB of RAM as being needed to build Firefox. The Mozilla documentations says they recommend 4 and you may have problems with less an 2.
<jxself>er; less than
<mark_weaver>ah, that's good to know
<mark_weaver>a while ago I remember reading of problems linking firefox on 32-bit systems, but that have only been on windows and maybe resolved now somehow.
<mark_weaver>*but that _may_ have only been
<civodul>Hello Guix!
<Svetlana>hi there
<kubrick>somebody intersted by a unix
<kubrick>or injecotr??
<davexunit>morning #guix
<Ulrar>afternoon davexunit
***Basstard1 is now known as Basstard`
***nully_ is now known as nully
<civodul>alezost: if i enable pretty-sha-path-mode in a buffer and then disable it, re-enabling it has no effect
<civodul>am i missing something?
<jxself>It was finally idle so I took advantage of the opportunity and rebooted wildebeest to finish the upgrade.
<jxself>Also applied the BASH package uprade that was available.
<civodul>thanks, jxself!
<mthl>hi there
<civodul>hey mthl
<mthl>i'm in trouble right now
<jxself>With the law?
<civodul>or with the Guix?
<mthl>code is law
<mthl>with Guix of cours, because Free Software doesn't work
<mthl>i've tried to guix pull
<mthl>it seems like the bug that someone report on guix-devel
<davexunit>"ERROR: no code for module (json)"
<davexunit>gah, that would be my fault.
<davexunit>though it is fixed in master.
<davexunit>guile-json is intended to be an optional dependency.
<mthl>i've tried to ./pre-inst-env guix pull
<mthl>and get this
<civodul>does "./pre-inst-env guix build hello" or similar works?
<civodul>(BTW, please use for instance, because is inaccessible via Tor)
<civodul>so something's deeply broken here :-)
<civodul>are there any changes in the source tree?
<civodul>is gnu/packages/bootstrap/x86_64-linux/guile-2.0.9.tar.xz present?
<mthl>no it's not
<alezost>civodul: Most likely it's because `pretty-sha-path-flush-function' variable is nil. Emacs 24.3 doesn't have `font-lock-flush' function (Emacs 24.4 has it), so that var is set to nil for the earlier versions.
<alezost>civodul: Could you try again with (setq pretty-sha-path-flush-function 'jit-lock-refontify)
<mthl>maybe it has something to do with the fact i remove quite a lot of packages from apt?
<civodul>alezost: that does the trick, indeed
<civodul>mthl: if the guile-2.0.9.tar.xz file is missing, that cannot work
<civodul>normally, it gets downloaded when typing "make" in the source tree
<civodul>can you check if that works?
<alezost>civodul: ok, thanks for confirming, I'll change the default value for the earlier versions then
<davexunit>civodul: thanks for pointing out the weirdness with ruby-i18n. I'll have to do some thinking about how to track references in ruby packages.
<alezost>civodul: should be fixed now: Thanks again
<davexunit>civodul: looks like Nix removes the .gem file. seems there's no reason to keep it around.
<davexunit>I will also need to introduce a wrap-program step
<davexunit>for executable files
<davexunit>I totally missed this file when I went hunting the first time
<mthl>civodul: configure: error: GNU libgcrypt does not appear to be usable; see `--with-libgcrypt-prefix' and `README'.
<civodul>thanks, alezost
<davexunit>ah, and they just use the .gem files from time to rewrite the build system!
<civodul>davexunit: ISTR something similar about .egg in Python, which are compressed archives
<civodul>uh :-)
<civodul>mthl: if you installed libgcrypt with Guix, use --with-libgcrypt-prefix=~/.guix-profile
<mthl>libgcrypt was install with guix, so i thought sompething was wrong with that version, so i remove to use the debian version but nothing change
<civodul>it's fine to use the Guix version, that's what i do
<civodul>you just need to tell ./configure where to find it
<davexunit>civodul: thanks. I think I have a better understanding of the ruby build system now, thanks to the Nix folks.
<civodul>mthl: see "Installing Guix from Guix" in README :-)
<civodul>davexunit: Nixpkgs is a useful reference ;-)
<davexunit>yeah, I wish I hadn't overlooked this source file before. I got confused because they auto-generate a bunch of the ruby library packages and I wasn't sure what was going on.
<davexunit>civodul: not guix-related, but do you have a workflow for running srfi-64 tests from the REPL?
<mthl>civodul: ok i'm checking
<civodul>davexunit: nothing great; i just C-M-x the define-module form, and then evaluate the test i'm interested in
<civodul>i'm all ears if there's something better
<davexunit>civodul: I find that I have to evaluate the test-begin and test-end first before I can get good output.
<davexunit>I guess I don't know how to distinguish a pass from a fail without doing that and thus enabling the log output
<civodul>oh, ok
<civodul>if i know the body of the test should return #t, it's easy to just evaluate it and see if it does
<davexunit>what about in test-group?
<davexunit>do you ever use those?
<davexunit>okay :)
<davexunit>well thanks for letting me know how you do things
<davexunit>not that srfi-64 is in guile I'm trying to make use of it and be better about unit testing my code.
<civodul>yeah, no excuse now ;-)
<davexunit>my old job was heavy on the TDD which drove me crazy, but unit testing is still important and I should still do it. :)
<mthl>civodul: i think i misunderstood the meaning --localstatedir
<mthl>i have put the value /usr/local/bin but i think i wasn't the right choice
<ecelis>mthl: --localstatedir usually is /var
<ecelis>--prefix=/usr/local maybe is what you want, which is the default value
<mthl> thanks for the explanation
<civodul>mthl: the Autoconf manual describes localstatedir as "The directory for installing modifiable single-machine data."
<civodul>here that's mostly the store's database