[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


>>> ...
>>> 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.


Afif Elghraoui | عفيف الغراوي

Reply to: