Re: Autopkgtest for falcon
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
Reply to: