Control: clone -1 -2 Control: retitle -2 missing source for configure Control: severity -2 serious Control: submitter -2 !
Hi Nilesh, On Tue, Sep 23, 2025 at 08:33:07PM +0530, Nilesh Patra wrote: > Right, but as you did say below that the configure is not getting generated > during the build, since d/rules has `dh $@ --without=autoreconf` and so > patching > configure.in does not solve the problem on at least debian side. Arguably, we do want to run autoreconf eventually. Otherwise, we incur an rc bug once autoconf2.69 gets removed from unstable. Sometimes making autoreconf work is part of the solution. > Enabling autoreconf does not help either since there's no Makefile.am and > there are other messy > things in the codebase that I don't think can be fixed with the corresponding > build files. You can run autoconf without automake. More precisely, running "autoconf2.69 -f -i" actually succeeds for xmlrpc-c. It just so happens that Debian's autoconf2.69 has no clue about --runstatedir yet, so dh_auto_configure then fails as it passes that. The configure script at hand claims to be generated using 2.69, so this is a fairly strong clue that a different (patched) autoconf2.69 was used for generating this script. That autoconf is not part of Debian and therefore the source code for the configure script is actually missing from Debian right now. That's a DFSG item 2 violation and an rc bug. > So I am a bit confused on what exactly you think should be done here. Are you > asking > me to come up with a patch get it merged upstream so when the configure file > is generated > in their next release, it is more cross-friendly? Mostly yes. > If so, and if I were to be honest with you, looking at (seemingly tedious > process at) https://xmlrpc-c.sourceforge.io/techsupp.php and seeing there are > development releases that have > moved forward (wrt current patch), it very much makes me not want to > jump through the upstreaming hoop. I agree that going through such hoops is not pleasant, but I still think that providing a sensible patch and mailing it to the maintainer is a reasonable thing to do. If they reject such a patch, it's too bad but then Debian may still use it once autoreconf is working again. Helmut
