Barry Warsaw writes ("Re: Auto reject if autopkgtest of reverse dependencies
fail or cause FTBFS"):
> There are occasionally good reasons why an upstream's test suite can't be run
> at build-time, and in those few cases I will run them in an autopkgtest. But
> g
On Jan 16, 2017, at 05:45 PM, Russ Allbery wrote:
>autopkgtest is useful for adding additional tests of the built binaries,
>but I don't believe it's intended as a replacement for build-time testing.
>Maybe I've missed something?
No, I think you're exactly right. If an upstream provides unit tes
Hi,
On Sun, Jan 15, 2017 at 12:51:51AM +, Simon McVittie wrote:
> If I understand correctly, the objection was to how sysvinit behaves
> (for which I have now opened #851427) - it puts the symlink at /dev/shm and
> the real mount at /run/shm.
That is the correct approach, and IIRC this is ho
Paul Wise writes ("Re: Auto reject if autopkgtest of reverse dependencies fail
or cause FTBFS"):
> On Wed, Jan 18, 2017 at 1:08 AM, Russ Allbery wrote:
> > Oh, sure, I'm in favor of disabling flaky tests if we can't fix them. My
> > experience is usually mor
On Wed, Jan 18, 2017 at 1:08 AM, Russ Allbery wrote:
> Santiago Vila writes:
>> In this context, I refer specifically to flaky tests. What I call
>> questionable is keeping a flaky test making the build to fail when the
>> test fails so much that it's clearly a wrongly designed test.
>
> Oh, sure,
Santiago Vila writes:
> Not exactly. I'm not advocating not failing a build if tests fail
> as a general rule.
> In this context, I refer specifically to flaky tests. What I call
> questionable is keeping a flaky test making the build to fail when the
> test fails so much that it's clearly a wro
On Mon, Jan 16, 2017 at 05:45:19PM -0800, Russ Allbery wrote:
> > Well, maybe what it's excessively aggressive or questionable is to run
> > the tests at build time and making the package build as a whole to fail
> > when any test fails.
>
> *blink*.
>
> I'm quite surprised that you would advoca
Santiago Vila writes:
> No, really it's not. It's already current practice:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=lamby%40debian.org
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=subject%3AFTBFS;submitter=lucas%40debian.org
> https://bugs.deb
On Mon, Jan 16, 2017 at 11:45:42PM +0100, Markus Koschany wrote:
> No, this is not current practice. But you are obviously trying to force
> it this way by all means necessary. Nobody asks you from refraining to
> report those kind of bugs but what I and other people are seriously
> questioning is
Am 16.01.2017 um 23:45 schrieb Markus Koschany:
> No, this is not current practice. But you are obviously trying to force
> it this way by all means necessary. Nobody asks you from refraining to
> report those kind of bugs but what I and other people are seriously
> questioning is your handling of
On 16.01.2017 22:00, Santiago Vila wrote:
> On Mon, Jan 16, 2017 at 12:02:32PM -0800, Russ Allbery wrote:
>> Santiago Vila writes:
>>
>>> Should I ask the Technical Committee to rule out that FTBFS bugs are RC,
>>> even if they did not happen in buildd.debian.org yet?
>>
>> This seems excessively
On Mon, Jan 16, 2017 at 12:02:32PM -0800, Russ Allbery wrote:
> Santiago Vila writes:
>
> > Should I ask the Technical Committee to rule out that FTBFS bugs are RC,
> > even if they did not happen in buildd.debian.org yet?
>
> This seems excessively aggressive.
No, really it's not. It's already
Santiago Vila writes:
> Should I ask the Technical Committee to rule out that FTBFS bugs are RC,
> even if they did not happen in buildd.debian.org yet?
This seems excessively aggressive. I've had FTBFS bugs in my packages
that were due to specific configurations for archive mass rebuilds that
On Jan 16, 2017, at 06:01 PM, Ian Jackson wrote:
>Right now the plan is to have _passing tests_ (well, regressionless
>ones) _reduce_ the migration delay. Failing tests would be the same
>as no tests.
One other important point for the Ubuntu infrastructure is that the
autopkgtests are a ratchet.
On Mon, Jan 16, 2017 at 12:24:08PM -0500, Scott Kitterman wrote:
> The before/after comparison for Debian and Ubuntu is apples and oranges.
> Before Ubuntu had the auto package test migration there we nothing other than
> installability blocking migration, it had (and still doesn't AFAIK) any
>
Scott Kitterman writes ("Re: Auto reject if autopkgtest of reverse dependencies
fail or cause FTBFS"):
> I'm sure it's generally helped, but so far, I've found it mostly a
> nuisance. If Debian started enforcing auto package test pass for
> Testing migrati
Niels Thykier writes ("Re: Auto reject if autopkgtest of reverse dependencies
fail or cause FTBFS"):
> In summary:
>
> * We will introduce it in a non-enforcing mode to see how it works
>(and weed out any "early-implementation bugs")
> * Passing te
Ole Streicher:
>>> >> What is the reason not to use automated bug reports here? This would
>>> >> allow to use all the tools the bug system has: severities, reassigning
>>> >> closing etc.
>> >
>> > [...]
> I already don't understand this with the piuparts blocker: we have an
> established workflow
Ian Jackson:
> Steve Langasek writes ("Re: Auto reject if autopkgtest of reverse
> dependencies fail or cause FTBFS"):
>> [...]
>
> The question is whether marking a test non-blocking should involve the
> release team. I think it should not. It should involve t
On Monday, January 16, 2017 12:09:02 PM Barry Warsaw wrote:
> On Jan 16, 2017, at 10:52 AM, Scott Kitterman wrote:
> >This is going to take a lot of work. I see random failures routinely block
> >migrations in Ubuntu (postfix is a current example - there's two alleged
> >regressions that to the ex
On Jan 16, 2017, at 10:52 AM, Scott Kitterman wrote:
>This is going to take a lot of work. I see random failures routinely block
>migrations in Ubuntu (postfix is a current example - there's two alleged
>regressions that to the extent they are valid are completely unrelated to
>anything that chan
On Monday, January 16, 2017 01:06:19 PM Martin Pitt wrote:
> Hello all,
>
> Scott Kitterman [Fri, 13 Jan 2017 13:54:26 -0500]
>
> > Probably the simplest way to avoid problems with systems like this is to
> > remove any autopkg tests your packages are shipping.
> >
> > P.S. Perverse incentives F
Ole Streicher writes ("Re: Auto reject if autopkgtest of reverse dependencies
fail or cause FTBFS"):
> Ian Jackson writes:
> > * It eliminates a timing problem, where the testing migration
> >infrastructure[1] needs to somehow decide whether the test have
>
Lars Wirzenius writes ("Re: Auto reject if autopkgtest of reverse dependencies
fail or cause FTBFS"):
> Until an unreliable test is fixed, in my opinion it'd be better if the
> test suite didn't fail because of it. Run the test by all means, to
> gather more informa
Santiago Vila writes ("Re: Auto reject if autopkgtest of reverse dependencies
fail or cause FTBFS"):
> Well, it does not work:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843038#10
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841098#78
I agree that there
Steve Langasek writes ("Re: Auto reject if autopkgtest of reverse dependencies
fail or cause FTBFS"):
> If the failure of the test is not critical, then it should not be used as a
> gate for CI. Which means you, as the package maintainer who knows that this
> test failure is n
On Mon, Jan 16, 2017 at 12:17:48PM +0100, Ole Streicher wrote:
> Santiago Vila writes:
> > On Mon, Jan 16, 2017 at 10:24:59AM +0100, Ole Streicher wrote:
> >
> >> IMO, we should trust the maintainer and their decisions until there is
> >> no experience that it doesn't work. Which means: keep the m
On Mon, Jan 16, 2017 at 11:07:11AM +0100, Santiago Vila wrote:
> LOL, but I don't see a lot of social exclusion here:
>
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=sanv...@debian.org;tag=ftbfs-randomly
>
> Sometimes I've seen maintainers downgrade FTBFS bugs to "wishlist"!
>
> Surely I
Hello all,
Scott Kitterman [Fri, 13 Jan 2017 13:54:26 -0500]
> Probably the simplest way to avoid problems with systems like this is to
> remove any autopkg tests your packages are shipping.
>
> P.S. Perverse incentives FTW.
No, that won't work at all. If you upload libfoo which regresses a rev
Hello all,
(I'm not subscribed, thus hand-crafting In-Reply-To:; please keep CC'ing me on
replies).
Ole Streicher [Fri, 13 Jan 2017 15:57:09 +0100]
> Will there be a way to override this for the maintainer? Otherwise I
> would see the danger that a buggy reverse dependency CI test can prevent
> a
Santiago Vila writes:
> On Mon, Jan 16, 2017 at 10:24:59AM +0100, Ole Streicher wrote:
>
>> IMO, we should trust the maintainer and their decisions until there is
>> no experience that it doesn't work. Which means: keep the maintainer
>> fully responsible on the package, including the ability to l
Quoting Santiago Vila (2017-01-16 11:07:11)
> Sometimes I've seen maintainers downgrade FTBFS bugs to "wishlist"!
>
> Surely I will not invite those maintainers to a party, but they are
> still maintaining Debian packages.
>
> Should I ask the Technical Committee to rule out that FTBFS bugs are R
On Mon, Jan 16, 2017 at 10:24:59AM +0100, Ole Streicher wrote:
> IMO, we should trust the maintainer and their decisions until there is
> no experience that it doesn't work. Which means: keep the maintainer
> fully responsible on the package, including the ability to lower
> severity of a CI test
On Mon, Jan 16, 2017 at 10:38:42AM +0200, Lars Wirzenius wrote:
> Picture this: a cocktail party. Many people mingling around, dressed
> up and engaging in smalltalk, sipping colourful drinks. A new couple
> arrives and is immediately surrounded by old fiends. "Hi, Jack and
> Joan, how are you? Ho
Hi Lars,
Lars Wirzenius writes:
> On Mon, Jan 16, 2017 at 08:50:57AM +0100, Ole Streicher wrote:
>> Sean Whitton writes:
>> > I agree with the principle that test failures should be RC by default.
>>
>> This is something which seems to have no disagreement here. My concern
>> is just that I wan
On Mon, 16 Jan 2017 at 10:38:42 +0200, Lars Wirzenius wrote:
> A failing test means there's a bug. It might be in the test itself, or
> in the code being tested. It might be a bug in the test environment.
Nobody is disputing this, but we have bug severities for a reason:
not every bug is release-c
On Mon, Jan 16, 2017 at 08:50:57AM +0100, Ole Streicher wrote:
> Sean Whitton writes:
> > I agree with the principle that test failures should be RC by default.
>
> This is something which seems to have no disagreement here. My concern
> is just that I want to have a simple way to override this,
Sean Whitton writes:
> I agree with the principle that test failures should be RC by default.
This is something which seems to have no disagreement here. My concern
is just that I want to have a simple way to override this, to assign
this to a different package etc. I want to have the same flexib
Hello Steve,
On Sat, Jan 14, 2017 at 10:15:15AM -0800, Steve Langasek wrote:
> If the failure of the test is not critical, then it should not be used
> as a gate for CI. Which means you, as the package maintainer who
> knows that this test failure is not critical, should fix your
> autopkgtest to
Steve Langasek writes:
> On Sat, Jan 14, 2017 at 11:05:48AM +0100, Ole Streicher wrote:
>> > One other thing that I can envision (but maybe to early to agree on or
>> > set in stone) is that we lower the NMU criteria for fixing (or
>> > temporarily disabling) autopkgtest in ones reverse dependenci
On Sun, 15 Jan 2017 at 01:18:00 +0100, Michael Biebl wrote:
> Am 14.01.2017 um 20:00 schrieb Steve Langasek:
> > I recall this being a misguided attempt to move it out of /dev "because it's
> > not a device". The migration did not go well, especially in the face of
> > chroots that need to have it
Am 14.01.2017 um 20:00 schrieb Steve Langasek:
> On Fri, Jan 13, 2017 at 03:54:30PM +, Simon McVittie wrote:
>> If I'm reading the initscripts code correctly, sysvinit does the reverse
>> by default, for some reason (/run/shm is the mount point and /dev/shm the
>> symlink). I think the motivati
On Fri, Jan 13, 2017 at 03:54:30PM +, Simon McVittie wrote:
> If I'm reading the initscripts code correctly, sysvinit does the reverse
> by default, for some reason (/run/shm is the mount point and /dev/shm the
> symlink). I think the motivation might have been to be able to use the
> same tmpf
Hi Ole,
On Sat, Jan 14, 2017 at 11:05:48AM +0100, Ole Streicher wrote:
> > One other thing that I can envision (but maybe to early to agree on or
> > set in stone) is that we lower the NMU criteria for fixing (or
> > temporarily disabling) autopkgtest in ones reverse dependencies. In
> > the end,
Ian Jackson writes:
> Ole Streicher writes ("Re: Auto reject if autopkgtest of reverse
> dependencies fail or cause FTBFS"):
>> I don't see the need to keep things in sync: If a new failure is
>> detected, it creates an RC bug against the migration candidate, wi
Ole Streicher writes ("Re: Auto reject if autopkgtest of reverse dependencies
fail or cause FTBFS"):
> I don't see the need to keep things in sync: If a new failure is
> detected, it creates an RC bug against the migration candidate, with an
> "affects" to th
Paul Gevers writes ("Re: Auto reject if autopkgtest of reverse dependencies
fail or cause FTBFS"):
> On 01/13/17 21:05, Ole Streicher wrote:
> > Simon McVittie writes:
> >> On Fri, 13 Jan 2017 at 18:22:53 +, Ian Jackson wrote:
> >>> Maybe an intermedi
On Sat, 2017-01-14 at 11:05 +0100, Ole Streicher wrote:
> I don't see the need to keep things in sync: If a new failure is
> detected, it creates an RC bug against the migration candidate, with an
> "affects" to the package that failed the test. The maintainer then has
> the possibilities:
>
> *
Colin Watson writes:
> On Fri, Jan 13, 2017 at 07:35:10PM +, Simon McVittie wrote:
>> Possible autopkgtest extension: "Restrictions: unreliable"?
>
> May as well just use "Restrictions: allow-stderr" and "... || true".
> That's easier to do on a more fine-grained level, too.
As on my deprecat
Paul Gevers writes:
> One can always file bug reports against the release.debian.org pseudo
> package to ask for britney to ignore the autopkgtest result.
This would again concentrate work on a relatively small team.
> One other thing that I can envision (but maybe to early to agree on or
> set
On Fri, Jan 13, 2017 at 07:35:10PM +, Simon McVittie wrote:
> On Fri, 13 Jan 2017 at 18:22:53 +, Ian Jackson wrote:
> > Maybe an intermediate position would be to respond to a CI failure by:
> > * Increasing the migration delay for the affecting package
> > * Notifying the affected packag
Hi Ole,
On 01/13/17 21:05, Ole Streicher wrote:
> Simon McVittie writes:
>> On Fri, 13 Jan 2017 at 18:22:53 +, Ian Jackson wrote:
>>> Maybe an intermediate position would be to respond to a CI failure by:
>>> * Increasing the migration delay for the affecting package
I like this and will su
Simon McVittie writes:
> On Fri, 13 Jan 2017 at 18:22:53 +, Ian Jackson wrote:
>> Maybe an intermediate position would be to respond to a CI failure by:
>> * Increasing the migration delay for the affecting package
>> * Notifying the affected package maintainers
>
> I think this makes sense:
On Fri, 13 Jan 2017 at 18:22:53 +, Ian Jackson wrote:
> Maybe an intermediate position would be to respond to a CI failure by:
> * Increasing the migration delay for the affecting package
> * Notifying the affected package maintainers
I think this makes sense: it gives the maintainer and oth
On Friday, January 13, 2017 05:46:41 PM Ole Streicher wrote:
> Antonio Terceiro writes:
> > On Fri, Jan 13, 2017 at 03:57:09PM +0100, Ole Streicher wrote:
> >> Paul Gevers writes:
> >> > I am not sure if you are addressing me or Pirate, but indeed I am
> >> > working on an implementation similar
Ole Streicher writes ("Re: Auto reject if autopkgtest of reverse dependencies
fail or cause FTBFS"):
> Sorry, I don't understand this. How can I get a reverse dependency
> removed (from unstable)?
You wouldn't. You would need to get it removed from testing.
> And
Hi,
2017-01-13 17:47 GMT+01:00 Antonio Terceiro :
> I think you are a little confused. That links to reproducible builds,
> which has nothing to do with debci.
>
yep, sorry for confusion. I assumed that FTBS migration check will use data
from reproducible builds OR will use same system for runni
Antonio Terceiro writes:
> On Fri, Jan 13, 2017 at 03:57:09PM +0100, Ole Streicher wrote:
>> Paul Gevers writes:
>> > I am not sure if you are addressing me or Pirate, but indeed I am
>> > working on an implementation similar to what Ubuntu does (see the link
>> > above about the details) which w
On Fri, Jan 13, 2017 at 02:38:28PM +0100, Ondrej Novy wrote:
> Hi,
>
> 2017-01-13 8:46 GMT+01:00 Pirate Praveen :
>
> > Similar to piuparts auto rejects, I think we should add auto reject when
> > autopkgtest of a reverse dependency or build dependency fails (which was
> > not failing earlier) or
On Fri, Jan 13, 2017 at 03:57:09PM +0100, Ole Streicher wrote:
> Paul Gevers writes:
> > I am not sure if you are addressing me or Pirate, but indeed I am
> > working on an implementation similar to what Ubuntu does (see the link
> > above about the details) which will be used as unstable to testi
On Fri, 2017-01-13 at 15:57 +0100, Ole Streicher wrote:
> Paul Gevers writes:
> > I am not sure if you are addressing me or Pirate, but indeed I am
> > working on an implementation similar to what Ubuntu does (see the link
> > above about the details) which will be used as unstable to testing
> >
On Fri, 13 Jan 2017 at 14:14:09 +, Holger Levsen wrote:
> how should /dev/shm be mounted? and how /run/shm?
I believe the "API" is that /dev/shm is either a tmpfs with
/tmp-like permissions (01777), or a symlink to such a tmpfs.
My understanding is that /run/shm is considered to be an
implemen
Paul Gevers writes:
> I am not sure if you are addressing me or Pirate, but indeed I am
> working on an implementation similar to what Ubuntu does (see the link
> above about the details) which will be used as unstable to testing
> migration blocker. debci is the worker, but all the policy logic w
Hi Scott,
On 13-01-17 14:30, Scott Kitterman wrote:
> On Friday, January 13, 2017 09:03:51 AM Paul Gevers wrote:
>> On 13-01-17 08:46, Pirate Praveen wrote:
>>> Similar to piuparts auto rejects, I think we should add auto reject when
>>> autopkgtest of a reverse dependency or build dependency fail
On Fri, Jan 13, 2017 at 02:38:28PM +0100, Ondrej Novy wrote:
> just be carefull, because there are some packages which FTBFS in debci
> (example:
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/swift.html
> )
> and it's bug in debci. Build works fine in buildd and in my local s
Hi,
2017-01-13 8:46 GMT+01:00 Pirate Praveen :
> Similar to piuparts auto rejects, I think we should add auto reject when
> autopkgtest of a reverse dependency or build dependency fails (which was
> not failing earlier) or cause FTBFS to reverse dependencies.
>
just be carefull, because there ar
On Friday, January 13, 2017 09:03:51 AM Paul Gevers wrote:
> Hi Pirate,
>
> On 13-01-17 08:46, Pirate Praveen wrote:
> > Similar to piuparts auto rejects, I think we should add auto reject when
> > autopkgtest of a reverse dependency or build dependency fails (which was
> > not failing earlier) or
On വെള്ളി 13 ജനുവരി 2017 01:33 വൈകു, Paul Gevers wrote:
> I'm working on that¹ and hope we can enable it soon after Stretch release.
Thanks! I think it will help us in a great way in handling library
transitions.
signature.asc
Description: OpenPGP digital signature
Hi Pirate,
On 13-01-17 08:46, Pirate Praveen wrote:
> Similar to piuparts auto rejects, I think we should add auto reject when
> autopkgtest of a reverse dependency or build dependency fails (which was
> not failing earlier) or cause FTBFS to reverse dependencies. This will
> help us prevent libra
Hi,
Similar to piuparts auto rejects, I think we should add auto reject when
autopkgtest of a reverse dependency or build dependency fails (which was
not failing earlier) or cause FTBFS to reverse dependencies. This will
help us prevent library updates without proper transitions breaking
other pac
70 matches
Mail list logo
