Hi Michael, > 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?
Please feel free to undo my latest change introducing 'kmod' to Build-Depends. Initially I thought I already fixed #674391 but today when I was building in pbuilder there were FTBFS. I did not tracked it to your change and thought that I could have been wrong regarding diagnosis of reported FTBFS' cause and that it was related to recent changes in 'sid'. (It would be nice if you try to avoid breaking master with incomplete commits or mark them as such) I realised that this change was unrelated from one of your earlier emails and since I already mentioned to you what I did I thought you would realise what's happened. > 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. Yes, sorry. Somehow we're collided with our changes to the package. :( > > I reverted this whole commit. Great. ### > And second, the more serious change, which actually tries to > fix the FTBFS mentioned in #674391. Not 'tries' - it fixes it. > 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). Wait a sec., before criticising, consider that we don't have to patch with pristine patches. I'm not sure why do you call it 'unverifiable' - I'm quite concerned regarding not having hack-ish workaround for upstream mess. Removing junk from upstream patches reduces the size of archive and allows us to have nice and tidy packaging. I was experimenting with different approaches for hours and what I did is the clean and nice alternative to some other things I tried. Why do you protect those junky hunks in upstream patches?? > 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. We can do it, but it would be nice to discuss why it is better (if it is). At the moment I do not like this approach. dh-autoreconf is great and I use it in some of my packages but here it looks like it would be unnecessary overkill just for the sake of having dirty patches for generated files. > 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. I'm not against dh-autoreconf where appropriate, but here we will be misusing it for moving stuff out of the way... It doesn't feels right. > I'm reverting this change too, Too bad, I wish you didn't do it. > because it is just the wrong thing to go. To me such claim appears as unsubstantiated. No it is not the wrong thing to do! It is right thing to do. You did not demonstrated convincing evidence that what I did was wrong, but that's not the point. It is wrong to redo the elegant solution without discussion and substitute it with something which is not necessarily nicer. If we want to release soon we need to keep re-factoring for later time and settle our disagreements first. Now it is more important to avoid making too many changes at once. > 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. Certainly we need to notify upstream that they should not patch generated files. Would you be able to carry out that message? > Dmitrijs: #674391 contains another change which everyone > missed now, about gold and --no-as-needed, which should be > incorporated too, I think. Please excuse my ignorance but what 'gold' has to do with it? '--no-as-needed' is for Ubuntu because they use '--as-needed' by default, right? Perhaps we can try introducing '--as-needed' and see if it works, but I'd rather do it later, after migration to testing. Regards, Dmitry. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
