Re: Bug#773256: pre-approval: unblock: dpkg/1.17.23
On 2014-12-23 04:36, Guillem Jover wrote:
> Hi!
>
Hi,
> On Sun, 2014-12-21 at 09:57:51 +0100, Niels Thykier wrote:
>> It possibly still is since the version that introduced the trigger
>> checks. I hope we can have it resolved shortly.
>
> Yeah, I'm planning to upload tomorrow, sorry about the delay, was not
> feeling quite well the past couple of days.
>
I hope you are feeling better now. :)
TL;DR: Please upload dpkg/1.17.23 with the proposed fix for #771730 at
your earliest convenience - by the looks of it, might fix one or two of
our upgrade tests on jenkins.d.n.
>>> [...]
>>
>> Indeed I missed those. For reference, pypy got fixed and gxine, icecc
>> and mcollective will get auto-removed eventually. My previous remark
>> for gxine plus icecc applies equally to mcollective (and pypy, in case
>> migration is stalled) as well.
>> This leaves auctex as the only remaining blocker auctex.
>
> In the meantime mcollective also got fixed, which leaves auctex, gxine,
> icecc and wordpress. The latter has a fixed package sitting in NEW
> (but I'm not sure it will be accepted and allowed to migrate?).
>
Thanks for the update. I will have a look at poking the remaining packages.
> I've added << versioned Breaks for the packages with fixed versions,
> and <= for the ones with unfixed ones against the version in testing
> (as for auctex it differs against unstable).
>
Ok.
>>> [...]
>
>> @deity/@dpkg: Right now, I am less concerned with "whose fault" it is
>> and vastly more concerned with getting a functional upgrade path.
>> If the correct fix is in APT and it can be provided in a "reviewable"
>> diff in a reasonable time frame, I will happily take that. Otherwise,
>> the "fix" needs to be in dpkg (despite being "wrong" or a revert). At
>> this point in the freeze, we do not have the luxury of finding perfection.
>
> Sorry, my point was that I don't think we know exactly what lead
> to the dbus issue, which apt versions are affected, or if this is
> actually something that showed up due to the trigger changes, dbus
> maintscripts errors and if it was a latent issue that could as well
> show up with a system crash leaving dpkg in a "broken" state, etc.
>
> As I've mentioend before I don't mind at all adding a workaround in
> dpkg if that provides a smooth upgrade path, but I'd like to do that
> understanding what it's working around, and that it actually fixes
> the issue, and not just blindly.
>
Noted. Do we (still?) have a (reliable) way of reproducing the "dbus"
trigger issue?
>> The main issue for me is that besides this trigger issue, we also got
>> the entire init system replacement on upgrades. I fear this is
>> uncharted territories right now because "everybody" is (mostly) stuck
>> behind these trigger issues.
>
> While I think trigger cycles (be them real or bogusly detected as
> the ones in 1.17.22) should be RC, they are actually recoverable
> upgrade errors, as package involved in trigger cycles get reset into
> half-configured, and their pending triggers reset. Which means that
> a subsequent apt invocation should be able to continue from where it
> was left off. So I don't think this has gotten people stuck on upgrade
> problems (at least with dpkg >= 1.17.22).
>
It is not about whether they are recoverable. Most people do not
upgrade systems if they are aware of known unresolved upgrade issues.
The sooner we can say "All of the dpkg and APT issues are now fixed; go
forth and test upgrade into Jessie", the sooner I get to the next level
of issues.
> The dbus problem seemed to be actually more severe, because although
> «dpkg --configure --pending» seemed to be able to recover from the
> situation, apt did not and got stuck there w/o being able to continue,
> at least from the logs and comments in the bug reports, but not many
> people have reported such issue so…
>
Noted.
>>> 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.
>>
>> (@deity: You may want to have a look at this as well)
>>
>> As I recall, it is not a requirement - but I believe we can recommend it
>> in the release-notes. [...]
>
> If it's just a recommendation then I'm not sure that would be
> satisfactory as we cannot rely on it.
Indeed and even then, some people might not read the release notes until
after.
> In any case for apt-based (or
> cupt) frontends the important thing is to get the frontends upgraded
> first, because dpkg ends up being invoked many times, and the new
> version will be picked up once it gets upgraded. Also frontends seem
> to favor Essential packages so they will get upgraded very early and
> on its own dpkg run. But if something got to be added, then I guess
> just requiring to upgrade apt or cupt would be enough.
>
> Thanks,
> Guillem
>
>
If we add something, we might as well add dpkg as well. :)
[From a different mail than the one I am replying to]
> On Tue, 2014-12-23 at 04:36:07 +0100, Guillem Jover wrote:
>> On Sun, 2014-12-21 at 09:57:51 +0100, Niels Thykier wrote:
>>> It possibly still is since the version that introduced the trigger
>>> checks. I hope we can have it resolved shortly.
>>
>> Yeah, I'm planning to upload tomorrow, sorry about the delay, was not
>> feeling quite well the past couple of days.
>
> Actually, I just noticed the bug was not tagged confirmed, so given
> this, the wordpress situation, and the questions you posed in the
> previous email, I'll hold off the upload, which is tested and ready
> for when I get a go.
>From my PoV, please go ahead at your earliest convenience. From the
Jenkins logs, it looks like that version of dpkg will fix some of the
outstanding issues.
Thanks,
~Niels
Reply to: