IRC channel logs


back to list of logs

<orthogonal>Does guix work on BSD?
<orthogonal>mark_weaver: Ok, that's too bad.
<civodul>Hello Guix!
<taylanub>civodul: hi! I actually got your last e-mail. strange stuff...
<taylanub>I'll get a non-gmail e-mail account eventually
<svetlana>i might suggest fastmail
<civodul>taylanub: oh weird
<civodul>perhaps people at my ISP fixed something
<civodul>but yeah, better get a non-gmail account
<civodul>mark_weaver: what are you thoughts on Libtool/mips: ?
<civodul>simply #:tests? (not (string-prefix? "mips" system)) ?
<civodul>howdy, atheia!
<svetlana>how many people here use gnustep/windowmaker?
<atheia>Morning civodul. How are things? Distro name situation seems to be heading to a close?
<civodul>hopefully, yes!
<mark_weaver>civodul: I'm working on getting libtool-2.4.4 working on mips.
<mark_weaver>civodul: and yes, I was hoping to merge wip-armhf into core-updates before merging core-updates into master
<mark_weaver>I'm making good progress on armhf.
<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.
<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.
<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>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.
<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 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!
<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, 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 part necessary?
<rekado_>there is no configure script.
<rekado_>it's only created by
<rekado_>and without configure I don't get a Makefile there.
<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
<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
<rekado_>Hmm, still same problem. No m4 files, even removed them from the parent directory.
<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
<civodul>but i found a way!
<civodul>basically making libltdl a separate package
<civodul>which has other advantages
<civodul>anyway, i'll finish that tomorrow
<civodul>good night/day!