IRC channel logs

<mark_weaver>civodul: basically, the failures in the libtool test suite on mips are because of references to /usr/bin/file in the generated configure scripts within the test suite.

<mark_weaver>civodul: the 'swig' is broken on core-updates, because its test suite can't find the en_US.utf8 locale.

<mark_weaver>or at least I think it is. I ran into the problem on wip-armhf, but it doesn't look arm-specific.

<mark_weaver>for now, I added a phase that creates a locale directory and runs localedef to create the locale, but I'd prefer a better solution. thoughts?

<rekado_>Hmm, the CUPS test suite probably fails because it needs cups-filters; to build cups-filters, however, I need CUPS.

<mark_weaver>civodul: what's the best way to apply a patch conditionally, based on system?

<mark_weaver>can I consult %current-system and %current-target-system from the 'patches' field of an origin?

<mark_weaver>civodul: I'd be okay with just disabling all libtool tests on mips for now

<mark_weaver>I arranged to patch /usr/bin/file in the tests, but then there were tests that did nested tests. it was quite the rabbit hole.

<civodul>mark_weaver: ok for libtool

<civodul>mark_weaver: the 'patches' field is unconditional, so you would need a separate build phase i'm afraid

<mark_weaver>okay, that's fine.

<mark_weaver>thanks!

<civodul>mark_weaver: for the locale thing, we just need to add a phase as in commit e9bab1df6d4c71f9617362c2bd8babe61dec759d

<civodul>oh you already did it, perfect

<civodul>rekado_: in such situations, we often end up with a minimal intermediate package; that is, you would have cups-minimal, used to build cups-filters, used to build cups

<civodul>(as done for Bison/Flex)

<mark_weaver>civodul: okay, thanks!

<mark_weaver>civodul: what's the story on "en_US.UTF-8" vs "en_US.utf8". It seems that we use .utf8 in some places and .UTF-8 in others.

<mark_weaver>?

<davexunit>good morning.

<mark_weaver>greetings, davexunit!

<mark_weaver>libtool-2.4.4 has problems on arm too

*davexunit sees there's been a new automake release

<civodul>oh?

<civodul>howdy, davexunit!

<davexunit>hey civodul

<civodul>mark_weaver: i think we now use ".utf8" everywhere; the reason is that, AFAICT, this is what libc prefers

<civodul>but we should double-check before making a release, because it can be annoying

<civodul>davexunit: so did you salvage your store?

<davexunit>I'm still having troubles with my store. I gc'd the bad store item, but I still get the "mkdir: file exists" error.

<davexunit>I don't know why, I gave up for now.

<davexunit>I'll try again soon.

<civodul>ok

<davexunit>if I can just figure this part out, the only big feature remaning is bzip2 compression.

<mark_weaver>civodul: any chance you could take a look at the patches in http://git.savannah.gnu.org/cgit/guix.git/log/?h=wip-armhf starting at the first patch "gnu: bootstrap: Add support for snippets to 'package-from-tarball'." and see what prefix of that patch set could go directly into core-updates? or should I post these to guix-devel?

<civodul>mark_weaver: if it's not too much of a burden for you, i prefer if you post them to the list

<mark_weaver>civodul: that's fine, will do!

<civodul>thanks

<rekado_>civodul: ah, this makes sense. I'll try to use an intermediary minimal cups package.

<rekado_>I don't understand this. I want to build ijs (part of ghostscript) by adding a phase that enters the ijs subdirectory, runs autogen.sh, configure, make, and make install.

<rekado_>But I don't get very far.

<rekado_>configure complains about a version difference between libtool macros and libtool.

<bavier>rekado_: is the autogen.sh part necessary?

<rekado_>there is no configure script.

<rekado_>it's only created by autogen.sh

<rekado_>and without configure I don't get a Makefile there.

<bavier>ok

<rekado_>but the version difference doesn't make any sense to me.

<rekado_>The exact error is this: "Version mismatch error. This is libtool 2.4.3, but the definition of this LT_INIT comes from libtool 2.4.2. You should recreate aclocal.m4 with macros from libtool 2.4.3 and run autoconf again."

<rekado_>I wonder how this can be as the version of libtool in guix is 2.4.2, not 2.4.3. How could it have created macros from libtool 2.4.3?

<civodul>rekado_: there's a stale aclocal.m4 here that you should remove before running autogen.sh

<civodul>but it's a shame the thing doesn't come with pre-generated configure and all

<rekado_>civodul: I suspected the same and added a line to remove the file, but apparently there is none.

*civodul gtg

<civodul>or maybe lt*.m4?

<civodul>just look for m4 files around

<civodul>ttyl!

<rekado_>Hmm, still same problem. No m4 files, even removed them from the parent directory.

<rekado_>puzzling.

<bavier>rekado_: could it be pulling in some files from the parent ghostscript directory?

<rekado_>bavier: don't know. I removed the parent directory's m4 files already, but it's the same. There is a rudimentary Makefile ("unix.mak") that I might be able to use instead by running "make -f unix.mak", but this is all a bit weird.

*rekado_ has to go now

<civodul>grr the fact that libtool 2.4.4 depends on automake+autoconf makes it unusable as-is during bootstrap

<mark_weaver>:-(

<civodul>but i found a way!

<civodul>:-)

<civodul>basically making libltdl a separate package

<civodul>which has other advantages

<civodul>anyway, i'll finish that tomorrow

<civodul>good night/day!

IRC channel logs

2015-01-06.log