Hi Jörg,
It looks like you forgot to CC me in your response to Mattia.
On Thu, 05 Apr 2018 20:24:55 +0200, Jörg Frings-Fürst wrote:
> Reasons:
> * Use of a directory (tmp/sane-backends) outside the build directory
I don't believe there any policy preventing the use of a external directory.
But it is possible to use the build directory, if a bit more difficult.
> * The announcement of the NMU took place in a Whishlist bug, which has
> nothing to do with the NMU.
You closed the relevant bug (#877691) immediately after it was filed, and
did not respond to my follow-up question. That was five months ago. Given
that #877691 was the third bug filed for the same problem, that should
have signalled a need to upload a new Unstable release at that time.
In any case, opening a new bug for the NMU did not seem appropriate.
When making the decision to NMU, I saw there had been no activity in
the git repository for many months. Also, you had not responded to my
post in the BTS (at that time) or to any other recently filed bugs.
The intent of the NMU was clear, although re-reading it now, I can see
that I wasn't clear about which multi-arch bug I was fixing.
> * In my response[1] I have clearly stated that my version is available
> for review with my mentor.
The NMU was prepared before your response -- and then the Easter
holidays were upon on.
But moving on, I share Mattia's opinion that the transition will take
a long time. And this is assuming your (unreleased) Experimental v4
build is ready.
If it is not, can we at least fix the original (sane.ps) multi-arch bug
in Unstable? We've all been waiting at least five months.
After all, this regression is also blocking other packages.
> * dh_autoreconf is used for update the upstream m4 files with the
> newest one. The "dh_autoreconf -X.m4" command prevents this for all
> upstream data.
You misunderstand how the -X (exclude) option works. The m4 files
*are* updated by autoreconf. You can check yourself by running
md5sum, the same way dh_autoreconf prepares the files
debian/autoreconf.{before, after}.
But to save you some time, here is the comparison:
--- Before dh_autoreconf -X.m4 ---
683cd3c258e06224f678acb0de1bee91 ./aclocal.m4
5d52b79aa623048ec0a6aa07cb6edfa7 m4/libtool.m4
47d420a13f9ba4e171772c3e3eee3e63 m4/lt~obsolete.m4
67d5ebceaac562ddf0dde4e5cdffbe09 m4/ltoptions.m4
bc2f6032c98896249eadb56177c7d357 m4/ltsugar.m4
91dd5e1355d100dbdab7d71244ed2625 m4/ltversion.m4
--- After dh_autoreconf -X.m4 ---
d917e3caafae426a955b49c16738e00f ./aclocal.m4
2cc70ef55adb11e355f6e8c30dcab090 m4/libtool.m4
22aa295bf5320aec7fba6756ff11058a m4/lt~obsolete.m4
064af1799febaa676203302bbf359180 m4/ltoptions.m4
fa2891f9060865871cbbaa1c6e2d96f4 m4/ltsugar.m4
d936fd6b2025c9b5322f826117d7f30c m4/ltversion.m4
The -X option prevents dh_autoreconf from adding the excluded
files (in this case, any filename with '.m4' anywhere in it) to the
debian/autoreconf.{before, after} files.
In turn, this exclusion prevents dh_autoreconf_clean from
removing the altered files when doing a rebuild.
(Due to problems in the upstream source, these files need
to be restored to their original versions, otherwise debhelper
errors out, as the files differ from those in the original source.
This is why we copy the files back.)
--
Hugh McMaster
