Hi! On Wed, 2014-12-17 at 22:18:12 +0100, Niels Thykier wrote: > On 2014-12-16 06:22, Guillem Jover wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian....@packages.debian.org > > Usertags: unblock > > Control: block -1 by 770627
> > I'd prefer if 1.17.22 could be unblocked before uploading this, because > > that version is way better than the one currently in testing, and it is > > causing fewer upgrade issues. Otherwise I'll just merge both unblock > > requests. > > Apologies, but I am not entirely convinced here. I would strongly > prefer /not/ having trigger regressions right now. Sorry, it seems there was a communication breakdown somewhere, my fault. As I just mentioned on #771730, once tracked down I always thought this affected all dpkg versions doing trigger dependency checks (although other issues might have shadowed that specific problem), but it seems I thought I mentioned it somewhere but cannot find any reference now :(, and did not actually try to reproduce with older versions because it seemed a bit like a waste of time when the unblock didn't seem to be dependenent on that issue. So, yes, 1.17.22 is really better in any possible way to 1.17.21. But, obviously your call. > In fact, I am honestly considering to request having the trigger change > reverted if 1.17.23 does not solve the issues without introduce another > regression. Ok. I'll do another pass over the code, and then try to improve the functional test suite to see if I catch something else before the upload. > We are one and a half month into the freeze and we still do not have a > clean upgrade path on a package level. I am deeply concerned that we > have been missing out on (e.g.) the systemd upgrade reports because of this. Sorry, I guess I should have tried to push a fix for the RC bug earlier w/o waiting for the translations deadline, but was not entirely clear on whether the disabled unblock was permanent or temporary until clarification on the dbus issue and enabling it back had not happened for unrelated reasons. Also given that #771730 was not a regression, it seemed prudent to let .22 migrate first. > > I've delayed a bit the request because there are still some packages > > with trigger cycles that have not been uploaded yet, I can start taking > > a look on delayed NMUs and wait for those or upload .23 right away and > > possibly prepare a .24 with those additional versioned Breaks, whichever > > you prefer. > > It seems that only gxine and icecc are missing now. If so, please go > ahead with the .23 with versioned breaks for them as well. Worst case, > I will have them removed from testing - best case, they will be fixed. > I will take the political fall-out of this and notify the maintainers > of the affected packages. Let me know if I missed any packages. Unfortunately there's still auctex, gxine, icecc, mcollective, pypy and wordpress. And I'm not sure if the fix for all of them might be a strightforward switch to a -noawait directive. > > I've also not added the --force-configure-any default switch, because we > > don't really know what happened with apt and dbus there, and if apt from > > stable is affected or not. Given the recent dpkg, apt, and dbus changes > > I think I'd rather let this as is, and wait in case it shows up again, > > which should give us more information (due to the new apt not eating > > dpkg's output). > > Noted, though I sincerely hope it is fixed. I /might/ be convinced to > accept a .24 for this particular issue. Just to clarify, if there's still an issue, it's exclusively in apt. The problems with dbus were due to apt trying to configure stuff when libdbus was not yet properly configured (AFAIR). And there was similar issues in apt between 0.9.9 and 1.0.7 (see #767734), but maybe this is something else, although related, but only showing up when trigger states are involved, this might also be a problem in apt in stable or just with newer versions, that might have only emerged due to the recent changes in dpkg. It might be that this only happens when packages break on upgrade as it happened with some of the dbus versions that failed on postinst, etc. Dunno, really. But in any case the --force-configure-any default change would be a workaround in dpkg to cover for the dist-upgrade problem of apt not upgrading itself as the first thing, and reexecuting. I also don't know what's the stance on requiring specific packaging tools to be upgraded first? Which might mean that if the issue is still there it could be fixed in apt proper. > Apologies for the less optimistic view on my end and thanks for your work. Sure, fully understood, no problem. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
