***stikonas_ is now known as stikonas
<stikonas>fossy: I'm testing my automake fixes now, it's not too bad, although automake 1.6.3 is now 3 stage process. Also when building automake-1.4 with automake-1.6 there is a non-critical error that I ignored with automake-1.6 || true. Alternatively we can patch out Makefile.am ***ChanServ sets mode: +o rekado_
***scs is now known as Guest72788
<stikonas>fossy: ^^ PR is now ready, it's now like this autoconf-2.52 (manual stage1) -> automake 1.6 (manual aclocal stage; manual automake stage; proper autotools rebuild) -> automake 1.4 -> autoconf-2.52 (proper rebuild with automake-1.4) <Hagfish>the correct response to such a pull request must be: "nice" :) <Hagfish>i am actually reviewing it, just as a learning exercise, though <Hagfish>stikonas: in sysa/automake-1.4-p6/automake-1.4-p6.sh you do "sed -i" then "set -i" <Hagfish>presumably the CI would have picked that up? <stikonas>it might be that the 2nd sed is not necessary... <Hagfish>also in src_configure() i've not seen the syntax/convention of a single ":" before <Hagfish>i'd be interested to learn what that's for <stikonas>I did delete one extra line in previous sed... ***scs is now known as Guest39650
***scs is now known as Guest25016
***ChanServ sets mode: +o rekado
<pder>stikonas: it looks like we can skip sed 4.0.7 and go straight to 4.0.9. I am testing and will create a PR later <stikonas>pder: I think we can also rebuild the same gawk <stikonas>with autotools, then instead of those stupid redirect errors, we get meaningful errors <stikonas>pder: e.g. that bash error that you ignored with || true is "configure:11936: error: possibly undefined macro: AC_FUNC_MBRTOWC" <pder>If possible, it would be nice to try a newer gawk because I was seeing errors from gawk in autoconf that went away with later versions <stikonas>at the moment I locally rebuilt gawk in chroot <pder>Maybe we try building newer gawk with a makefile? <stikonas>well, autoconf 2.53 had two errors, one I get get rid of easily with sed '//d' <pder>Anyway, its a bit fuzzy, but I thought I tried to rebuild our current gawk version with the latest tcc-musl and it didnt help with the error you indicated above <stikonas>configure.ac:86: error: possibly undefined macro: m4_bmatch <stikonas>so maybe I can just rebuild locally for now for debugging purposes <pder>The configure script that is generated works <stikonas>it complains about m4 version being too old <stikonas>I think there were more 2.52 bug fix releases... <pder>git://git.sv.gnu.org/autoconf <pder>there is autoconf-2.52 a-i <stikonas>yeah, that macro m4_bmatch appeared later <stikonas>so I guess they used one or more intermediate versions for bootstrapping it <pder>AUTOCONF-2.52a is newer than AUTOCONF-2.52 in git <stikonas>if we remove the whole m4_bmatch block from configure.ac ***smartineng2 is now known as smartineng
<roptat>hi! I was trying to optimize our python package in guix when I noticed that it contains some bundled binaries and generated files <roptat>for instance, there's a Lib/ensurepip/_bundled/setuptools-41.2.0-py2.py3-none-any.whl that contains some .exe (PE executables for windows), and is itself generated <roptat>it's a zip archive with mostly .py files, so I suppose it's not too bad, but I'd like to get rid of the .exe, so if you know how to do that, it would be very helpful :) <roptat>(just asking in case someone here noticed and already has an easy solution) <roptat>(that file is in the sources of python, and it's uncompressed and its content is part of the resulting package) <civodul>roptat: oh, that doesn't sound great <stikonas>these exe files are indeed part of setup tools installation <stikonas>so looks like those files have to be present for windows users <stikonas>so on non-windows systems they are not needed <stikonas>but I guess they are shipped so that the same package can be uploaded to PyPI <roptat>and the .whl gets installed: /gnu/store/dhs75nz707g1gsm0f2i5rblc5dsj2ixh-python-3.9.1/lib/python3.9/ensurepip/_bundled/setuptools-49.2.1-py3-none-any.whl <stikonas>yes it's installed... but I'm just saying <roptat>there's also a pip-20.2.3-py2.py3-none-any.whl (that also gets installed) in the same directory, that contains a few .exe <stikonas>so if those exes are removed from whl then I don't think it will break anything <stikonas>fossy: maybe merge your PR too? It's just whitespace change now and docs <roptat>except I'd need zip and unzip for that <roptat>oh but they're used for pip I think, so that's fine <roptat>I can simply remove the .whl in the bootstrap python <pder>This drops sed 4.0.7 in favor of sed 4.0.9 eliminating a download <stikonas>I'm now patching autoconf 2.53, hopefully another PR soon too <pder>thanks for all your autotools work, stikonas. I hope you aren't finding it too painful. <stikonas>although less exciting than other binaries <pder>The nice thing Ive found is that once we have more modern versions of autotools, several packages like newest tar and xz compile without issues <stikonas>and I think once I have 2.53, newer autotools will be more compatible <stikonas>2.52->2.53 was a big rewrite (large parts rewritten in perl) <pder>I notice there is xzdec which is a smaller possibly simpler tool to build <stikonas>well, tcc can actually build a lot of things... <stikonas>especially with tools and libc that we have now <pder>I didnt notice my sed branch was behind. Shall I rebase it? <stikonas>pder: I guess I can insert newer autoconfs just before bash? <stikonas>so that eventually we can rebuild gawk there and remove || true workaround <mihi>if not, I'll have to try to debug it myself on the weekend :) <mihi>(or reduce to a more minimal example)