Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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 > generally, I think the two are

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: how to mount /(dev|run)/shm properly? (was Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS)

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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 more that I'm leaving them on *because*

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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,

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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 migration, Right now the plan is to have

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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 tests will be grounds for reduced age

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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 the package > maintainer (unless

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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 >

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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 information for debugging, but don't

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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 are sometimes problems

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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 not critical, should

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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 >

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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,

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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?

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: how to mount /(dev|run)/shm properly? (was Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS)

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

Re: how to mount /(dev|run)/shm properly? (was Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS)

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

Re: how to mount /(dev|run)/shm properly? (was Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS)

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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,

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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, with

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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 the package that failed the test. I

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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 intermediate position would be to

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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: > > *

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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,

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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 >

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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 why should I get responsible

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: how to mount /(dev|run)/shm properly? (was Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS)

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

how to mount /(dev|run)/shm properly? (was Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS)

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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)

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Re: Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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

Auto reject if autopkgtest of reverse dependencies fail or cause FTBFS

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