On 13-Nov-2015, James Cowgill wrote: > The package FTBFS when build with dpkg-buildpackage -B: […] > > cd inform-6.31.1/ && ./configure --prefix=/usr […] > > configure: error: cannot run /bin/bash config/config.sub > > debian/rules:49: recipe for target 'build.stamp' failed > > make: *** [build.stamp] Error 1 That's because the ‘config/config.*’ files, supplied in the upstream source, are removed in the “clean” target. I did that in order to not have unwarranted changes in the source files. Maybe I should be using ‘dh_autoreconf’: > Why not use dh_autoreconf? Because I'm not very experienced with GNU Autotools, and wasn't aware of that command. Would that address the above problem as well, do you think? > From the build log for dpkg-buildpackage -b (which does work): > > In file included from linker.c:9:0: > > linker.c: In function ‘write_link_byte’: > > header.h:618:36: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] > > #define subtract_pointers(p1,p2) (((int32) p1)-((int32) p2)) > > ^ > > linker.c:968:9: note: in expansion of macro ‘subtract_pointers’ > > if (subtract_pointers(link_data_top,link_data_holding_area) > > ^ > > This looks pretty bad for any 64-bit architecture to me. My guess is > that it still works due to pure luck that glibc's allocator doesn't > start at an address above 2GB. The code is also wrong for 32-bit since > it could potentially result in signed integer overflow if addresses in > the 2GB-3GB range are used. Okay. That's unchanged (from my perspective) since before I looked at this package. I'll need to learn more about the problem; can you submit a bug report on Debian's BTS against ‘inform’? > debian/Makefile.upstream: > What is the purpose of this file? I'll look into that. It may be a remnant from some earlier change. > debian/rules: > Why not use dh? I'd like to understand the rationales for the current ‘debian/rules’, before replacing it so completely. Certainly migrating to the ‘dh’ command is a medium-term goal. On 13-Nov-2015, Stephen Kitt wrote: > and with dpkg-buildpackage -A (which would be nice to have since the > source package produces an arch-independent binary package alongside > the arch-dependent one). I suspect this is also to be addressed by using ‘dh-autoreconf’, would you agree? > README.Debian-source should be README.source (policy 4.14, > https://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource). Done now. > debian/rules isn't really the place to comment on policy, I'd > suggest filing a bug against policy... You could also just use uscan > and drop the various get-orig-source targets entirely. My intention with those targets is to conform to policy and explain to the reader, not to comment on policy or change it. > Thanks for taking the time to work on this! I'm happy to have interested mentors :-) -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\ Brain, but if it was only supposed to be a three hour tour, why | _o__) did the Howells bring all their money?” —_Pinky and The Brain_ | Ben Finney <ben@benfinney.id.au>
Attachment:
signature.asc
Description: PGP signature