On 01.06.2012 16:23, Michael Tokarev wrote: > On 01.06.2012 16:15, Dmitry Smirnov wrote: >> Hi Michael and William >> >> Dmitrijs called off his NMU and expressed his interest to join our team >> while I updated repository with more changes. > > I'm doing some last-minute changes too, which we discussed > before (namely, including the initscript). > > The ftbfs with kmod/module-init-tools is due to my change, > I removed the ugly config.h patching in > 450dfb2c4fc1d6caf7653a3bef33c2aa5e897361. > In order to fix the issue right, the easiest solution is > to set ac_cv_path_MODPROBE=/sbin/modprobe before invoking > ./configure. Ditto for the related test which I also removed > in the same commit, for linux /proc filesystem (HAVE_LINUX_PROCFS).
Ok. This is just too much wrong. Dmitry, your two changes, both marked as fixing #674391, are wrong and needs revered. First, a small thing, the kmod change, c6ac061e12208cdf32291223b27caeefec6ce241. Here's the changelog difference from it: [Dmitry Smirnov] - * update upstream patches to avoid patching 'configure' (Closes: #674391) + * added 'kmod' to Build-Depends to fix FTBFS (Closes: #674391) + * update upstream patches to avoid patching 'configure' * use 'autoconf' to regenerate 'configure' Now please tell me how this kmod thing is relevant for #674391? It is wrong, and it is very confusing, since I started thinking about entirely different thing and not about the real problem. The change itself is right, well, sort of, -- it fixes the issue as the package isn't built correctly without /sbin/modprobe (even if it never uses /sbin/modprobe to start with, which is a different issue). But the misplacing of the Closes/FTBFS line is troubling. I reverted this whole commit. And second, the more serious change, which actually tries to fix the FTBFS mentioned in #674391. You took a wrong approach with this, by taking patches from upstream and removing patching of configure. This way, we're patching upstream patches, the result is a unverifiable mess. (Why upstream keeps configure in git is another question, to which there's no sane answer). The proposed by Dmitrijs approach -- using dh-autoreconf or similar, plus maybe patching Makefile to not remade configure.in (which is another strange thing to do) -- is the way to go here. dh-autoreconf will save all autoconf-related files and will restore them in `clean' target, making whole thing working. Alternatively, if you think dh_autoreconf is too heavy somehow, it is possible to save configure.in and configure in debian/rules "configure" step and restore them in "clean" target without using helpers/addons, it is just as easy. Now, we need to re-run autoconf anyway. I'm reverting this change too, because it is just the wrong thing to go. I'll try to fix this mess in a most accurate way, but we have more and more work to resolve with upstream, the package (upstream code) is in rather bad state. Dmitrijs: #674391 contains another change which everyone missed now, about gold and --no-as-needed, which should be incorporated too, I think. Oh well. /mjt -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
