| 31 May 2023 |
artemis | In reply to @trofi:matrix.org I think we don't expect help2man to be started on libtool and existing manpages should be reused. Could it be that your system clock is way off and make is tricked to see files with wrong timetamps? no, system clock is definitely right | 08:51:17 |
artemis | i can give that PR a try | 08:51:46 |
artemis | kicked off a build, ill see where things land after i get some sleep | 09:03:40 |
trofi | If it does not help try to figure out why libtool build triggers for you (CDPATH="${ZSH_VERSION+.}:" && cd . && /nix/store/7z4pgfv4vqgfi5d894cwzj4jha47vrhr-bash-5.1-p16/bin/bash '/build/libtool-2.4.7/build-aux/missing' autoheader) | 09:17:26 |
trofi | it should not happen | 09:17:52 |
artemis | ok so im not actually sure why the testsuite is running but the coreutils test suite apparently failed overnight on `FAIL: tests/mv/i-1.pl` is what happened which i think is way before the failing libtool so that's probably not useful data for the libtool thing | 19:29:53 |
| 1 Jun 2023 |
artemis | In reply to @trofi:matrix.org If it does not help try to figure out why libtool build triggers for you (CDPATH="${ZSH_VERSION+.}:" && cd . && /nix/store/7z4pgfv4vqgfi5d894cwzj4jha47vrhr-bash-5.1-p16/bin/bash '/build/libtool-2.4.7/build-aux/missing' autoheader) do i need to be using ZSH for this idk what CDPATH is | 00:29:08 |
trofi | No, it's the code from libtool's Makefile.in that runs unexpectedly. | 06:23:41 |
trofi | if you have some familiarity you can investigate why make thinks it needs to run. | 06:24:05 |
trofi | Sometimes it's enough to add "-d" to makeFlags to see why exactly the target needs an update. | 06:24:54 |
artemis | i dont know that im good enough at nix to do that in this context | 06:31:45 |
artemis | i usually work with more traditional package build systems tbh | 06:32:20 |
trofi | If you do something like locally:
--- a/pkgs/development/tools/misc/libtool/libtool2.nix
+++ b/pkgs/development/tools/misc/libtool/libtool2.nix
@@ -53,0 +54 @@ stdenv.mkDerivation rec {
+ makeFlags = [ "-d" ];
you should be able to get libtool build logs with nix build -f. libtool.
| 06:34:51 |
trofi | * If you do something like locally:
--- a/pkgs/development/tools/misc/libtool/libtool2.nix
+++ b/pkgs/development/tools/misc/libtool/libtool2.nix
@@ -53,0 +54 @@ stdenv.mkDerivation rec {
+ makeFlags = [ "-d" ];
you should be able to get libtool build logs with nix build -f. libtool.
| 06:35:11 |
artemis | ty | 06:40:51 |
| raphi changed their display name from raphi to raphi (element unread channel fix when). | 13:03:26 |
artemis | trofi:
libtool-riscv64-unknown-linux-gnu> Prerequisite 'libtoolize.in' is newer than target 'doc/libtoolize.1'.
libtool-riscv64-unknown-linux-gnu> Must remake target 'doc/libtoolize.1'. | 21:32:34 |
artemis | its not regenerating libtoolize.in though it seems like | 21:34:29 |
artemis | libtool-riscv64-unknown-linux-gnu> Finished prerequisites of target file 'libtoolize.in'.
libtool-riscv64-unknown-linux-gnu> No need to remake target 'libtoolize.in'. | 21:34:30 |
artemis | * its not regenerating libtoolize.in though it seems like. from earlier up the log: | 21:34:56 |
trofi | Oh, it's a cross-compilation? | 21:34:58 |
artemis | yeah | 21:35:04 |
artemis | cross compiling from x86_64 to riscv64 | 21:35:41 |
trofi | That I should be able to reproduce locally. Which package do you build? | 21:36:03 |
trofi | (and I would expect libtoolize.in not to require a rebuild, what does log say, what triggers it's rebuild?) | 21:37:11 |
artemis | vi@philomena ~/z/nixpkgs (nixos-22.11)> nix build -f. pkgsCross.riscv64.libtool | 21:37:14 |
artemis | commit 9af373a61647257d16ae6062cddaa9094d24920c to be exact | 21:37:24 |
trofi | nod, i'll try on staging-next first | 21:37:38 |
artemis | In reply to @trofi:matrix.org (and I would expect libtoolize.in not to require a rebuild, what does log say, what triggers it's rebuild?) nothing, it doesnt rebuild | 21:37:43 |
artemis | look up there it says no need to remake target libtoolize.in | 21:37:53 |