Hi,
Beginning of today "package-cleanup --orphans" reports thunderbird-3.1.10-1.fc14.i686 as orphan in F14.
"yum clean all; yum list thunderbird" reports thunderbird-3.1.9-2.fc14 as newest thunderbird package in the repositories. However, at one point in time thunderbird-3.1.10-1.fc14.i686 must have been available in the repos, too (I don't have updates-testing enabled.).
It looks like that the following happened:
There were two updates in bodhi:
1. https://admin.fedoraproject.org/updates/firefox-3.6.17-1.fc14,mozvoikko-1.0-...
which contains thunderbird 3.1.10-1 and which was pushed to stable on 2011-04-29 22:19:33.
2. https://admin.fedoraproject.org/updates/thunderbird-3.1.9-2.fc14,thunderbird...
which contains thunderbird 3.1.9-2 (and thunderbird-lightning) and which was pushed to stable on 2011-04-30 23:21:39.
So the 2nd update has superseded the first update to thunderbird 3.1.10.
For all who have updated to thunderbird 3.1.10 during the small time window when it was available in the mirrors, the thunderbird package is now an "orphan" on their systems.
Please can the maintainers of thunderbird push thunderbird 3.1.10 again? Thanks!
Best regards, Christian
On Sun, 01 May 2011 15:53:10 +0200, CK wrote:
Hi,
Beginning of today "package-cleanup --orphans" reports thunderbird-3.1.10-1.fc14.i686 as orphan in F14.
"yum clean all; yum list thunderbird" reports thunderbird-3.1.9-2.fc14 as newest thunderbird package in the repositories. However, at one point in time thunderbird-3.1.10-1.fc14.i686 must have been available in the repos, too (I don't have updates-testing enabled.).
It looks like that the following happened:
There were two updates in bodhi:
https://admin.fedoraproject.org/updates/firefox-3.6.17-1.fc14,mozvoikko-1.0-...
which contains thunderbird 3.1.10-1 and which was pushed to stable on 2011-04-29 22:19:33.
https://admin.fedoraproject.org/updates/thunderbird-3.1.9-2.fc14,thunderbird...
which contains thunderbird 3.1.9-2 (and thunderbird-lightning) and which was pushed to stable on 2011-04-30 23:21:39.
So the 2nd update has superseded the first update to thunderbird 3.1.10.
For all who have updated to thunderbird 3.1.10 during the small time window when it was available in the mirrors, the thunderbird package is now an "orphan" on their systems.
Please can the maintainers of thunderbird push thunderbird 3.1.10 again?
Rather find and fix the bug that is the cause of this. There have been a few updates like that recently, again.
The 3.1.10-1.fc14 package is tagged dist-f14-updates already: http://koji.fedoraproject.org/koji/buildinfo?buildID=241265
So, during the compose of the updates repo it should be pulled in.
On Sun, 1 May 2011 16:31:29 +0200, me wrote:
Please can the maintainers of thunderbird push thunderbird 3.1.10 again?
Rather find and fix the bug that is the cause of this. There have been a few updates like that recently, again.
The 3.1.10-1.fc14 package is tagged dist-f14-updates already: http://koji.fedoraproject.org/koji/buildinfo?buildID=241265
So, during the compose of the updates repo it should be pulled in.
$ koji list-tag-history --tag=dist-f14-updates --package=thunderbird|tail -2 Fri Apr 29 20:53:33 2011: thunderbird-3.1.10-1.fc14 tagged into dist-f14-updates by bodhi [still active] Sat Apr 30 21:35:18 2011: thunderbird-3.1.9-2.fc14 tagged into dist-f14-updates by bodhi [still active]
The bug here is that bodhi apparently is permitted to "downgrade" a package by tagging a lower version after a higher version.
Michael Schwendt wrote:
Rather find and fix the bug that is the cause of this. There have been a few updates like that recently, again.
The 3.1.10-1.fc14 package is tagged dist-f14-updates already: http://koji.fedoraproject.org/koji/buildinfo?buildID=241265
So, during the compose of the updates repo it should be pulled in.
The problem there is Koji's broken idea of "newest". For Koji, the "newest" package is the latest one which was tagged, not the highest EVR. (In fact, Koji doesn't process Epoch at all, so it can't even compare EVRs.) Unfortunately, the Koji developers refuse to acknowledge that this is even a bug, and have no plans to fix it ever. Fixing it would mean 1. telling Koji about Epoch and 2. using EVR comparisons instead of tagging dates to decide on the latest version.
To fix this particular instance of the problem, rel-eng needs to untag the obsolete 3.1.9 build so the 3.1.10 one becomes the "newest" also for Koji.
Kevin Kofler
Kevin Kofler wrote:
Michael Schwendt wrote:
Rather find and fix the bug that is the cause of this. There have been a few updates like that recently, again.
The 3.1.10-1.fc14 package is tagged dist-f14-updates already: http://koji.fedoraproject.org/koji/buildinfo?buildID=241265
So, during the compose of the updates repo it should be pulled in.
The problem there is Koji's broken idea of "newest". For Koji, the "newest" package is the latest one which was tagged, not the highest EVR. (In fact, Koji doesn't process Epoch at all, so it can't even compare EVRs.) Unfortunately, the Koji developers refuse to acknowledge that this is even a bug, and have no plans to fix it ever. Fixing it would mean 1. telling Koji about Epoch and 2. using EVR comparisons instead of tagging dates to decide on the latest version.
To fix this particular instance of the problem, rel-eng needs to untag the obsolete 3.1.9 build so the 3.1.10 one becomes the "newest" also for Koji.
Kevin Kofler
I've filed multiple bugs in rel-engs Trac over the last few years, and they've always fixed the tagging, but it would be great to have this be fixed in a more long term way.
-J
On 05/01/2011 10:38 PM, Kevin Kofler wrote:
Michael Schwendt wrote:
Rather find and fix the bug that is the cause of this. There have been a few updates like that recently, again.
The 3.1.10-1.fc14 package is tagged dist-f14-updates already: http://koji.fedoraproject.org/koji/buildinfo?buildID=241265
So, during the compose of the updates repo it should be pulled in.
The problem there is Koji's broken idea of "newest". For Koji, the "newest" package is the latest one which was tagged, not the highest EVR. (In fact, Koji doesn't process Epoch at all, so it can't even compare EVRs.) Unfortunately, the Koji developers refuse to acknowledge that this is even a bug, and have no plans to fix it ever. Fixing it would mean 1. telling Koji about Epoch and 2. using EVR comparisons instead of tagging dates to decide on the latest version.
What do you suggest? Should we just create a rel-eng ticket for fixing koji with respect to the sorting algorithm?
To fix this particular instance of the problem, rel-eng needs to untag the obsolete 3.1.9 build so the 3.1.10 one becomes the "newest" also for Koji.
Since the update to 3.1.10 is marked as a security update I suggest that for now we should just use the approach of untagging 3.1.9. I have created: https://fedorahosted.org/rel-eng/ticket/4690
Best regards, Christian
-
Christian Krause -
Jon Ciesla -
Kevin Kofler -
Michael Schwendt