Re: Bug#773256: pre-approval: unblock: dpkg/1.17.23
CC: @deity (look for a couple of "@deity"s below)
On 2014-12-19 20:35, Guillem Jover wrote:
> 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.org@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.
>
Okay, it was not clear to me that dpkg/1.17.21 was also affected by
#771730. That changes it quite a bit as it is no longer a regression
between unstable and testing.
It possibly still is since the version that introduced the trigger
checks. I hope we can have it resolved shortly.
>> 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.
>
Excellent.
>> 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.
>
Okay, I have decided to let dpkg/1.17.22 migrate. I am still not
pleased with the dbus situation - regardless of "whose" fault it is.
@deity/@dpkg: On the "RC bug fixes vs. translations". Given that (one
of?) dpkg and APT is correctly breaking our upgrades, I am much more
interested in the RC bug fixes for these packages.
I do not mind waiting up to 14 days on a "translations only" update
provided that it gets me *working* an upgrade path between Wheezy and
Jessie sooner.
>>> 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.
>
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.
>>> 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.
>
@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.
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.
> 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.
Noted. @deity: Do you have an estimate on when you can have a proposed
fix for your side ready?
> 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. Although, with the Breaks being added to dpkg for
trigger issues, you would quite possibly pull in additional upgrades
along with it.
By upgrading specific packaging tools, I presume you mean something like:
"""
apt install -t jessie dpkg apt
apt-get install -t jessie dpkg apt
aptitude safe-upgrade -t jessie dpkg apt
"""
(Depending on the frontend used). Assuming we add this to the release
notes, is there any other packages you believe should be added to the
list above?
>> Apologies for the less optimistic view on my end and thanks for your work.
>
> Sure, fully understood, no problem.
>
> Thanks,
> Guillem
>
>
~Niels
Reply to: