Re: More trigger cycles

2015-02-23 Thread Holger Levsen
Hi Niels,

On Sonntag, 22. Februar 2015, Niels Thykier wrote:
 I admit I would (also?) have preferred that we did not depend on a
 missing error check in dpkg.  If the automatic check on jenkins.d.n is
 extended early in the stretch cycle, I suspect we have a pretty good
 chance at getting most of them done.

is there anything you'd like to see done except s#jessie#stretch#g then? 
Adding more jobs is rather trivial... (and hw ressources are available.)

   My major concern right now is that we are still blind to the actual
 number of remaining issues.  We only learn of them by getting occasional
 upgrade is broken reports - this way, we are never really sure when we
 have fixed the last one.

If there are any jobs you could imagine to help finding these issues on 
jenkins.d.n before users report them, I'd be curious to hear (and quite very 
probably happy to implement them)!

Andreas has also added a new suite to his (private) piuparts configuration, 
wheezy2jessie-apt1st/main, which upgrades apt first and then lets the new apt 
compute the upgrade path for the remaining packages, do you think that would 
be interesting to run piuparts.d.o?


cheers,
Holger, still+again happy to see jenkins.d.n being so useful!




signature.asc
Description: This is a digitally signed message part.


Re: More trigger cycles

2015-02-22 Thread Johannes Schauer
Hi,

Quoting Niels Thykier (2015-02-22 09:43:00)
 I admit I would (also?) have preferred that we did not depend on a missing
 error check in dpkg.  If the automatic check on jenkins.d.n is extended early
 in the stretch cycle, I suspect we have a pretty good chance at getting most
 of them done.  My major concern right now is that we are still blind to the
 actual number of remaining issues.  We only learn of them by getting
 occasional upgrade is broken reports - this way, we are never really sure
 when we have fixed the last one.

even with an extension of the automatic check you could not be sure to have
caught all issues because any extension on top of the existing checks would
only be a heuristic and will thus miss some cases.

The fix for this would be to have a declarative way to express those trigger
activations which are currently done in maintainer scripts so that it is not
needed to try to parse maintainer scripts with a regex.

cheers, josch


signature.asc
Description: signature


Re: More trigger cycles

2015-02-22 Thread Niels Thykier
On 2015-02-20 17:42, Guillem Jover wrote:
 Hi!
 
 On Wed, 2015-02-18 at 19:00:23 +0100, Niels Thykier wrote:
 [...]
 @dpkg maintainers: Please make the necessary changes to revert the
 trigger cycle error or have dpkg recover from it automatically
 immediately without aborting the upgrade.
 
 Sure, I've now disabled the dependency checks and will proceed with a
 full test suite run, will update the pre-approval request later today.
 

Thanks.

 From my part, sorry for the trouble, I guess I didn't anticipate the
 archive would be in such a bad state regarding the trigger cycles. :/
 
 Thanks,
 Guillem
 
 

I admit I would (also?) have preferred that we did not depend on a
missing error check in dpkg.  If the automatic check on jenkins.d.n is
extended early in the stretch cycle, I suspect we have a pretty good
chance at getting most of them done.
  My major concern right now is that we are still blind to the actual
number of remaining issues.  We only learn of them by getting occasional
upgrade is broken reports - this way, we are never really sure when we
have fixed the last one.

Thanks,
~Niels



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e99694.7070...@thykier.net



Re: More trigger cycles

2015-02-20 Thread Guillem Jover
Hi!

On Wed, 2015-02-18 at 19:00:23 +0100, Niels Thykier wrote:
 Based on #778695, it seems like we still have trigger cycles.  At this
 point in the freeze, I am afraid it is too late to fix the remaining cycles.
 
 I have asked Johannes if this kind of trigger cycles can be found via
 his script.  If so, hopefully we can have them eliminated for Stretch,
 but as said - we are over 3 months into the freeze and these trigger
 cycles are still biting us.

Ok. I'll take a look at those anyway to see what's going on.

 @dpkg maintainers: Please make the necessary changes to revert the
 trigger cycle error or have dpkg recover from it automatically
 immediately without aborting the upgrade.

Sure, I've now disabled the dependency checks and will proceed with a
full test suite run, will update the pre-approval request later today.

From my part, sorry for the trouble, I guess I didn't anticipate the
archive would be in such a bad state regarding the trigger cycles. :/

Thanks,
Guillem


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150220164238.ga17...@gaara.hadrons.org



More trigger cycles

2015-02-18 Thread Niels Thykier
Hi,

Based on #778695, it seems like we still have trigger cycles.  At this
point in the freeze, I am afraid it is too late to fix the remaining cycles.

I have asked Johannes if this kind of trigger cycles can be found via
his script.  If so, hopefully we can have them eliminated for Stretch,
but as said - we are over 3 months into the freeze and these trigger
cycles are still biting us.

@dpkg maintainers: Please make the necessary changes to revert the
trigger cycle error or have dpkg recover from it automatically
immediately without aborting the upgrade.

Thanks,
~Niels


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e4d337.8020...@thykier.net