***andschwa_ is now known as andschwa
***g__ is now known as Guest48587
<DusXMT>iyzsong: yup, it's down supposedly <civodul>i can connect to hydra.gnu.org, but not fencepost <civodul>PING git.sv.gnu.org (140.186.70.72) 56(84) bytes of data. <civodul>From FREE-SOFTWA.csw02.bst01.twdx.net (208.118.224.186) icmp_seq=6 Destination Host Unreachable <DusXMT>Well, seems like no freedom for today... :( <mark_weaver>civodul: it turns out that %{pthread:-lgcc_s} doesn't always work. I just hit my first counter-example. The test suite of tcl now prints the following error: "libgcc_s.so.1 must be installed for pthread_cancel to work". <mark_weaver>civodul: it seems that tcl's build system does not pass -pthread by default. it just uses -lpthread <mark_weaver>on some OSes, the tcl build system arranges to use -pthread by default, but not on linux. <mark_weaver>well, for now, I'll try hacking it into the tcl build script and see how far I get otherwise. ***tschwinge is now known as tschwinge_
<davexunit>everything at our colocation facility was inaccessible. <mark_weaver>civodul: removing --mandir=... from the tcl configure flags broke the build. I get "ERROR: In procedure rename-file: Directory not empty" while trying to move /gnu/store/*-tcl-8.6.0/man to /gnu/store/*-tcl-8.6.0/share/man <mark_weaver>civodul: okay, I reverted the %{pthread:-lgcc_s} patch. <civodul>thanks to davexunit, nully and everyone at the FSF for bringing the infrastructure back up! <davexunit>I had nothing to do with it. all praise to the sysadmins. <civodul>mark_weaver: re tcl, could you check if it has things both in man/ and share/man when building without --mandir? <jxself>Yes, all hail nully and marxistvegan. <mark_weaver>(tcl installs some things in /man and others in /share/man) <rekado_>cups-filters wants to place its files into the backend/ directory of the CUPS directory. Without cups-filters CUPS won't work on non-MacOS systems. <rekado_>Is the preferred way to install the backends somewhere in the cups-filters output directory and make CUPS aware of them through environment variables? <rekado_>Or should I try to build cups-filters as if it was part of the CUPS package and thus gain access to its backend directory? <civodul>mark_weaver: bah ok; could you restore the --mandir thing then? <civodul>rekado_: maybe you could make them two separate packages, and hard-code the cups-filters directory in the right place in CUPS? <rekado_>currently they are two separate packages. I just got to a point where the files are to be installed and noticed this. <rekado_>so I'll try to patch CUPS, if needed. <civodul>mark_weaver: we should be able to get hydra to build all of core-updates to look for remaining issues now? <mark_weaver>civodul: almost. there's just one remaining patch to merge from wip-armhf: the last one. <mark_weaver>I sent it to guix-devel, but it didn't go through. maybe because it was large (due to the added bootstrap binaries) <mark_weaver>(the version at wip-armhf is actually a bit out of date) <mark_weaver>also, I think at least one libtool test needs to be disabled on ARM as well. <mark_weaver>I guess I should mail it again, but with those binaries omitted. <civodul>mark_weaver: now libtool is now longer a core package, so we can fix it anytime <civodul>at worst, we may have to duplicate the search-path-spec of perl for both native and target inputs <civodul>at any rate, i would not worry too much about this until someone actually has a need for cross-compiled Perl packages <bavier>I ask because of the cpan importer I'm polishing up. It affects of course how I output the dependent packages <mark_weaver>civodul: the libtool fix for arm would most naturally be incorporated into the existing patch, which affects libltdl and thus core, no? <civodul>mark_weaver: you're right, though if need be, we can still change the definition of libltdl to not have the patch <mark_weaver>civodul: I pushed the gcc/cross-base/utils part of the remaining armhf patch. apart from a possible fix to libtool, that's the last core change I anticipate for armhf. <civodul>do we enable the full build now, or do you want to try to fix libtool? <civodul>there's also the rest of the ARM patch to be committed actually <civodul>iyzsong: would be nice to add an Xfce session to SLiM <mark_weaver>civodul: the rest of the ARM patch shouldn't cause any package rebuilds. <mark_weaver>I would like to wait for libtool results on ARM though, if you don't mind. <mark_weaver>I'll start the full build on hydra once libtool is taken care of. <mark_weaver>it just built libltdl. any way to get it to build a basic libtool with tests at this early stage in bootstrap? <mark_weaver>I tried (package-with-bootstrap-guile libtool) but that still required a lot of prerequisites. <civodul>you could use package-with-explicit-inputs, as in commencement.scm, to use intermediate inputs to speed things up <bavier>does the 'check phase get run during a cross-build? <civodul>yes, but automake-generated makefiles do nothing upon "make check" in that case <mark_weaver>also, the default value of the '#:tests?' argument is false when cross-compiling, so our default 'check' phase will not even run "make check" <bavier>mark_weaver: that's what I was wondering, thanks <civodul>oh i thought it was run, it's better this way <mark_weaver>actually, I know what I can do. I'll run it from my old 'wip-armhf' branch which is all built up already. <civodul>probably more energy-efficient, indeed ;-)