<robimarko>
And indeed we dont check for m4 in prereq nor we add a symlink
<robimarko>
Adding a symlink to m4 makes it compile
<Ansuel>
but that would require additional prereq and stuff... that is the main problem tar is so early that ideally we shouldn't need any tool... also why they need automake and stuff... the release tar should have eveything already init
<Ansuel>
did they changed that?
<robimarko>
Beats me
<robimarko>
It seems that they may have missed the build-aux
<robimarko>
Cause others build without m4
<robimarko>
Adding m4 as a dependency to tar makes it compile
<Ansuel>
we still hope 1.36 reintroduce it... really seems 1.35 was rushed (maybe due to all the cve???)
<robimarko>
Well, its going to be while till 1.36
<robimarko>
Ansuel: Ok, its not the tar release that is faulty
<robimarko>
And since it modifies Makefile.am then automake is required to regenerate the end Makefile
<Ansuel>
ok yes i remember that and at times we end up with the conclusion that it was better to wait for a new release than having to regenerate the makefile
<Ansuel>
and idea might be check what is missing in the generated makefile
<Ansuel>
and patch that instead
<Ansuel>
(patch is similar to my hack of fixing the gnulib library)
<robimarko>
Oh, that might work
<Ansuel>
robimarko if the changes are not that big, it might be a viable solution... can you by chance check that or maybe upload the generated makefile somewhere so i can take a look ?
<robimarko>
Ansuel: Its not big, I am trying it out now
<robimarko>
Yeah, patching Makefile.in works
<Ansuel>
kb of the patch ?
<Ansuel>
should be only a few lines
<robimarko>
Its only 2 lines
<Ansuel>
:D month of having the package not updated for this problem and they were just 2 lines
<robimarko>
Yeah, and its quite literaly the commit after 1.35 was tagged
<slh>
Ansuel: the pool is automatically pruned when no active distribution references that package version anymore (1.29 apparently was only in unstable and testing between oldstable and stable, so it's probably gone for around two years already)
<jakllsch>
meson just creates a bunch of new unsolved problems that autotools already covered
<Mangix>
such as?
<jakllsch>
such as supporting non-linux unix
<jakllsch>
and trying to keep up with Python
<Mangix>
BSDs? meson supports them
<jakllsch>
poorly usually
<Mangix>
supports them fine from what I see.
<Mangix>
actually for OpenWrt that's irrelevant. It's not buildable on the BSDs.
<Ansuel>
Mangix yes currently we have tar and zstd as the very first host tools that doesn't need to require to anything else... also why this autotools problem??? tar release doesn't make use of it as the makefile are already shipped prepared
<Mangix>
they need to be reprepared to fix macOS?
<Mangix>
anyway, meson only needs ninja, which has no dependencies