IRC channel logs


back to list of logs

***andschwa_ is now known as andschwa
***g__ is now known as Guest48587
<civodul>Hello Guix!
<iyzsong>unable to connect to
<iyzsong>anyone have same issue?
<DusXMT>iyzsong: yup, it's down supposedly
<civodul>iyzsong: yes, same here
<iyzsong>ok :(
<civodul>i can connect to, but not fencepost
<civodul>PING ( 56(84) bytes of data.
<civodul>From ( icmp_seq=6 Destination Host Unreachable
<civodul> still down
<DusXMT>Well, seems like no freedom for today... :(
<civodul>not to mention freedom of speech:
<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: " 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_
<Tsutsukakushi> seems to be back up
<davexunit>we had a major server outage over the night
<davexunit>everything at our colocation facility was inaccessible.
<mark_weaver>davexunit: ouch :-(
<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>civodul: yes, that appears to be the case!
<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>i hope it's not too common
<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.
<mark_weaver>civodul: okay
<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>or maybe the message is waiting in moderation.
<mark_weaver>civodul: it's here:
<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
<bavier>according to perl module runtime dependencies are required also at build time. Does that mean we need to list packages in both inputs and native-inputs?
<civodul>i don't think so
<civodul>'inputs' should be enough
<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>civodul: sure
<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>bavier: oooh, that's good news!
<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
<civodul>hint, hint ;-)
<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>ok to wait for libtool
<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 ;-)
<civodul>good night/day