Hi, Andreas, على الخميس 19 كانون الثاني 2017 05:08، كتب Andreas Tille: > On Thu, Jan 19, 2017 at 12:44:31AM -0800, Afif Elghraoui wrote: [...] >> >> I'm fine with the idea, but it's not something I would do. This seems to >> me like something that is better implemented within autopkgtest itself >> (like for tests that don't specify the "breaks-testbed" restriction) or >> something rather than on a per-package basis. > > I fully agree here. > >> I generally prefer to keep >> the packaging simple, which is why I haven't manually set hardening >> flags on every individual package (dpkg-buildflags could globally set it >> if it is appropriate), > > Seems you can read my mind: I was always wondering why hardening=+all > would not be the default and individual maintainers should take some > means if the package does not build with this setting. I admit I took > the wimpy approach to not ask for this since if you ask for such > features it takes some time to discuss and just copying a single line > to the rules file takes less time in the very moment ... >
I think there were two additional flags and one of them has already become default. I was planning to ignore the lintian infos until they went away on their ownl. >> why I don't change default compression methods >> without good reason, > > I think there is no need for this any more (if I get your question > right). > I meant about the upstream tarballs (like when repacking, I use default options unless the package is very big and can benefit from changing it) >> and why I don't put the dummy watch line for >> upstreams that don't tag releases (maybe there is a possibility to have >> uscan not fail if there is no watch line to process) and such. > > I admit when inventing a new watch file version (version=4) it would > have been cheap to define extra metadata to express the upstream status > properly instead of doing dirty tricks like I'm doing currently. The > thing is if you have this kind of "good ideas" you should be up to also > implement these - at least a proof of concept. I did so with the > Files-Excluded feature which I wanted so urgently that I was up to > spending my time on it. I think I have my turn on time investment in > this very topic but I was hesitating with the watch file thingy. For me > its now important to keep my developers dashboard free from noise which > I can approach by some copy-n-pasting - I don't mind whether its a hack > or a field ... as long as I do not need to spend extra time on it. > I guess this uscan exit code doesn't bother since I'm generally checking my own DDPO rather than the developer's dashboard (though I agree the latter is more concise for looking at all Debian Med packages). >> I won't revert this kind of change-- I just won't initiate it or go out >> of my way to maintain it. > > That's perfectly fine. Great > >>> ... >>> 2017-01-18 13:21:44,348[ERROR] Task Node(1-preads_ovl/m_00001) failed with >>> exit-code=256 [...] >>> makefile:21: recipe for target 'full-test' failed >>> >>> >>> Is this the same issue you was talking about? I admit I have no good >>> idea how to fix it but just want to make sure that we are in sync here. >>> >> >> That looks about right. Don't worry about this one. I've requested >> upstream (a while ago) to document how to debug failed runs and they've >> accepted my bug report. I may go back and ask about this specific case, >> though ours is not a supported installation. > > But possibly not for Stretch any more, right? (Which is fine - just > asking whether I can ignore this and focus on other things.) > I might be able to get it figured out in time, but you can feel free to ignore it. regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
