| 31 May 2023 |
 @trofi:matrix.org | 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:matrix.org | No, it's the code from libtool's Makefile.in that runs unexpectedly. | 06:23:41 |
| @trofi:matrix.org | if you have some familiarity you can investigate why make thinks it needs to run. | 06:24:05 |
| @trofi:matrix.org | 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:matrix.org | 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:matrix.org | * 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:matrix.org | 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:matrix.org | That I should be able to reproduce locally. Which package do you build? | 21:36:03 |
| @trofi:matrix.org | (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:matrix.org | 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 |
| artemis | so libtoolize.in is not rebuilt. but it is newer than doc/libtoolize.1 which does rebuild | 21:38:21 |
| @trofi:matrix.org | Aha. Then some other prerequisite is stale if it still wants to rebuild doc/libtoolize.1. Maybe a few lines earlier. | 21:38:39 |
| artemis | hmm? no it says that libtoolize.in is newer | 21:39:01 |
| artemis | and is the reason for the rebuild | 21:39:09 |
