6:27 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Can anybody tell me what went wrong with this update? It was submitted
at 15:09 on 06-23, then made it into testing at 16:19 on 06-24 and was
submitted for stable two hours later. Between that submission and the
push to stable (push to stable happened at 18:09 on 06-25) numerous
negative karma came in due to broken deps. The update went out anyway,
and now we have a mess of broken updates on a critical path package, and
have to scramble to fix it with more updates, on a Friday.
Can anybody help me understand the scenario here? Should we start
filtering out push requests that have more than -2 karma?
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkwlO0cACgkQ4v2HLvE71NXVxwCfS59qPC/vUPT1rEIMrhMRijDL
C9gAnj8FKdjdPHqL4lZPFWiAMKWsEXma
=OHPB
-----END PGP SIGNATURE-----
12:33 a.m.
Sounds like it might need to be. Maybe push stable requests with -2 karma to
some list that requires investigation and possibly a +3 (or other agreed
upon number) proventesters karma to go stable?
Just a thought.
-AdamM (From Android)
On Jun 25, 2010 6:27 PM, "Jesse Keating" <jkeating(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Can anybody tell me what went wrong with this update? It was submitted
at 15:09 on 06-23, then made it into testing at 16:19 on 06-24 and was
submitted for stable two hours later. Between that submission and the
push to stable (push to stable happened at 18:09 on 06-25) numerous
negative karma came in due to broken deps. The update went out anyway,
and now we have a mess of broken updates on a critical path package, and
have to scramble to fix it with more updates, on a Friday.
Can anybody help me understand the scenario here? Should we start
filtering out push requests that have more than -2 karma?
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkwlO0cACgkQ4v2HLvE71NXVxwCfS59qPC/vUPT1rEIMrhMRijDL
C9gAnj8FKdjdPHqL4lZPFWiAMKWsEXma
=OHPB
-----END PGP SIGNATURE-----
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
12:53 a.m.
On 06/26/2010 07:33 AM, Adam Miller wrote:
Sounds like it might need to be. Maybe push stable requests with -2
karma to
some list that requires investigation and possibly a +3 (or other agreed
upon number) proventesters karma to go stable?
Would you mind to explain how could have happened:
# yum update
...
---> Package evolution.x86_64 0:2.30.2-1.fc13 set to be updated
--> Processing Dependency: libedataserver-1.2.so.11()(64bit) for
package: gnome-panel-2.30.0-1.fc13.x86_64
--> Processing Dependency: libedataserver-1.2.so.11()(64bit) for
package: glabels-2.2.8-1.fc13.x86_64
---> Package evolution-data-server.x86_64 0:2.30.2-2.fc13 set to be updated
--> Finished Dependency Resolution
Error: Package: glabels-2.2.8-1.fc13.x86_64 (@updates)
Requires: libedataserver-1.2.so.11()(64bit)
Removing: evolution-data-server-2.30.1-2.fc13.x86_64 (@fedora)
Error: Package: gnome-panel-2.30.0-1.fc13.x86_64 (@fedora)
Requires: libedataserver-1.2.so.11()(64bit)
Removing: evolution-data-server-2.30.1-2.fc13.x86_64 (@fedora)
To me this is a clear case of package-push which should not have
happened and is not related to karma votes at all.
Ralf
8:45 p.m.
Ralf Corsepius wrote:
To me this is a clear case of package-push which should not have
happened and is not related to karma votes at all.
+1. The proper solution to prevent this kind of issues 100% reliably is to
implement AutoQA, the only decent part of the Update Proposal and the one
which is still vaporware. Rushing the silly proventesters nonsense is only a
bandaid which is not even guaranteed to prevent all broken dependencies,
automatic enforcement is.
Kevin Kofler
12:50 a.m.
On Fri, 2010-06-25 at 16:27 -0700, Jesse Keating wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Can anybody tell me what went wrong with this update? It was submitted
at 15:09 on 06-23, then made it into testing at 16:19 on 06-24 and was
submitted for stable two hours later. Between that submission and the
push to stable (push to stable happened at 18:09 on 06-25) numerous
negative karma came in due to broken deps. The update went out anyway,
and now we have a mess of broken updates on a critical path package, and
have to scramble to fix it with more updates, on a Friday.
Can anybody help me understand the scenario here? Should we start
filtering out push requests that have more than -2 karma?
I talked to notting &c about this earlier, and we've hit this situation
before. The 'scenario' is simply that there's really no screening
between 'submit' and 'push' for stable updates, and this one was
submitted to stable before any negative karma came in. There's no
reliable process whereby whoever's doing the push to stable actually
looks at feedback before doing it; unless they happen to have been made
aware that a particular package shouldn't be pushed, they just push
everything that's been submitted.
Clearly the maintainer did not allow sufficient time for testing here;
there's a grand 4 hour window between the update being 'pushed to
testing' and 'submitted to stable'. That probably wasn't long enough for
it even to hit any public mirrors.
AutoQA will also help a lot here, obviously, when it's fully
implemented. If implemented as planned, the depcheck tests would have
prevented the update from being pushed.
The requirement for proventester feedback for critpath updates, when we
turn it on, should also catch problems like this in the critpath. Evo
isn't critpath, though, I believe.
Until AutoQA is in place to tackle this, the obvious option is for there
to be a process improvement whereby whoever's doing stable update pushes
at least gets notified if a package has received negative karma since
the submission. I think we discussed something similar on -devel last
time this happened. Not sure if there's a ticket, or how hard that would
be to implement.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:23 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 6/25/10 10:50 PM, Adam Williamson wrote:
Until AutoQA is in place to tackle this, the obvious option is for
there
to be a process improvement whereby whoever's doing stable update pushes
at least gets notified if a package has received negative karma since
the submission. I think we discussed something similar on -devel last
time this happened. Not sure if there's a ticket, or how hard that would
be to implement.
Likely the easiest thing to do is on the client side we use, filter any
update requests that have too negative of karma. It would have caught
this issue. They can be displayed for a releng person to further
investigate.
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkwlnOUACgkQ4v2HLvE71NUVrwCfUw3Ji+33uZk2QwvsfZO1JGeM
jH0An13glytiG7P9a2n7POsdzCqX5MUz
=XHtq
-----END PGP SIGNATURE-----
7:10 a.m.
On Sat, Jun 26, 2010 at 7:23 AM, Jesse Keating <jkeating(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 6/25/10 10:50 PM, Adam Williamson wrote:
> Until AutoQA is in place to tackle this, the obvious option is for there
> to be a process improvement whereby whoever's doing stable update pushes
> at least gets notified if a package has received negative karma since
> the submission. I think we discussed something similar on -devel last
> time this happened. Not sure if there's a ticket, or how hard that would
> be to implement.
Likely the easiest thing to do is on the client side we use, filter any
update requests that have too negative of karma. It would have caught
this issue. They can be displayed for a releng person to further
investigate.
That would only work if the script that does the push to stable (as
opposed to processing the request to push to stable) checks if any
negative karma has appeared since the request has happened.
I believe that a deps autoqa is still a good idea for stable releases.
Peter
1:59 p.m.
On 06/26/2010 05:10 AM, Peter Robinson wrote:
That would only work if the script that does the push to stable (as
opposed to processing the request to push to stable) checks if any
negative karma has appeared since the request has happened.
Well, if there is a update push to stable request that has any amount of
net negative karma, it needs to be looked at and a human should
intercept it.
I believe that a deps autoqa is still a good idea for stable releases.
Correct, this is not a replacement for that, just something we can do
today while AutoQA work continues.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
1:29 a.m.
On 06/26/2010 11:20 AM, Adam Williamson wrote:
Clearly the maintainer did not allow sufficient time for testing here;
there's a grand 4 hour window between the update being 'pushed to
testing' and 'submitted to stable'. That probably wasn't long enough for
it even to hit any public mirrors.
Can the maintainers please explain why they did this? We need that
answer before looking at AutoQA IMO.
Rahul
2:18 p.m.
On Sat, 2010-06-26 at 11:59 +0530, Rahul Sundaram wrote:
On 06/26/2010 11:20 AM, Adam Williamson wrote:
>
> Clearly the maintainer did not allow sufficient time for testing here;
> there's a grand 4 hour window between the update being 'pushed to
> testing' and 'submitted to stable'. That probably wasn't long enough
for
> it even to hit any public mirrors.
>
Can the maintainers please explain why they did this? We need that
answer before looking at AutoQA IMO.
History seems to suggest that maintainers are *always* going to submit
updates that cause dependency problems, so it seems sensible to look at
handling the situation after submission as well as trying to make people
_not_ submit such updates.
I believe the maintainer said in the submission that he simply didn't
catch the ABI change:
"Oh, I see, I didn't notice this change earlier. It was changed in
http://git.gnome.org/browse/evolution-data-
server/commit/?h=gnome-2-30&id=9930a9602 "
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
11:14 a.m.
On Fri, 2010-06-25 at 22:50 -0700, Adam Williamson wrote:
I talked to notting &c about this earlier, and we've hit this
situation
before. The 'scenario' is simply that there's really no screening
between 'submit' and 'push' for stable updates, and this one was
submitted to stable before any negative karma came in. There's no
reliable process whereby whoever's doing the push to stable actually
looks at feedback before doing it; unless they happen to have been made
aware that a particular package shouldn't be pushed, they just push
everything that's been submitted.
There actually is a way to get feedback on updates before pushing.
Bodhi's admin request list interface gives everything in the list headed
to stable a color based on some heuristics. So it's quite easy to scan
the list and look at the red updates, which have negative karma, or
haven't been in testing long. However, I think all of our bodhi admins
who kick off the pushes use the command-line instead.
I think that in this case, the command-line bodhi client could be
improved to make it obvious that they're about to push an update with
negative karma.
[...]
The requirement for proventester feedback for critpath updates, when
we
turn it on, should also catch problems like this in the critpath. Evo
isn't critpath, though, I believe.
evolution-data-server is in the critpath, and having the proventester
feedback policy implemented would have definitely caught this issue.
luke
12:24 p.m.
On Sat, Jun 26, 2010 at 12:14 PM, Luke Macken wrote:
On Fri, 2010-06-25 at 22:50 -0700, Adam Williamson wrote:
> I talked to notting &c about this earlier, and we've hit this situation
> before. The 'scenario' is simply that there's really no screening
> between 'submit' and 'push' for stable updates, and this one was
> submitted to stable before any negative karma came in. There's no
> reliable process whereby whoever's doing the push to stable actually
> looks at feedback before doing it; unless they happen to have been made
> aware that a particular package shouldn't be pushed, they just push
> everything that's been submitted.
There actually is a way to get feedback on updates before pushing.
Bodhi's admin request list interface gives everything in the list headed
to stable a color based on some heuristics. So it's quite easy to scan
the list and look at the red updates, which have negative karma, or
haven't been in testing long. However, I think all of our bodhi admins
who kick off the pushes use the command-line instead.
I think that in this case, the command-line bodhi client could be
improved to make it obvious that they're about to push an update with
negative karma.
Once 2 curious users went and downloaded the package for their
architecture from koji when it was in queue for testing (it wasn't in
the repo yet). They couldn't install the package because they couldn't
figure out that they need to download the noarch subpackage that needs
to be installed simultaneously with the arch-specific one. They gave
me -2 karma for that reason, which means absolutely nothing.
Therefore banning a push because of negative karma can be pointless in
certain cases. Again, my vote goes to leave everything in testing for
336 hours, at least, and proceeding accordingly.
Orcan
Orcan
2:19 p.m.
On Sat, 2010-06-26 at 12:14 -0400, Luke Macken wrote:
> The requirement for proventester feedback for critpath updates,
when we
> turn it on, should also catch problems like this in the critpath. Evo
> isn't critpath, though, I believe.
evolution-data-server is in the critpath, and having the proventester
feedback policy implemented would have definitely caught this issue.
Ah, OK, I didn't check. I believe the policy ought to be implemented
soon. Everything's ready on QA side. I think we have a ticket open for
the Bodhi change, James is taking care of that.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
11:17 p.m.
On Fri, 2010-06-25 at 16:27 -0700, Jesse Keating wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Can anybody tell me what went wrong with this update? It was submitted
at 15:09 on 06-23, then made it into testing at 16:19 on 06-24 and was
submitted for stable two hours later. Between that submission and the
push to stable (push to stable happened at 18:09 on 06-25) numerous
negative karma came in due to broken deps. The update went out anyway,
and now we have a mess of broken updates on a critical path package, and
have to scramble to fix it with more updates, on a Friday.
Can anybody help me understand the scenario here? Should we start
filtering out push requests that have more than -2 karma?
Updating F13 now works; but a yum upgrade from F12 still seems busted.
--
Braden McDaniel <braden(a)endoframe.com>
11:58 p.m.
On 06/29/2010 06:17 AM, Braden McDaniel wrote:
Updating F13 now works;
Does it?
Not for me.
...
Resolving Dependencies
--> Running transaction check
--> Processing Dependency: libedataserver-1.2.so.11 for package:
pidgin-evolution-2.7.1-2.fc13.i686
--> Processing Dependency: libedataserver-1.2.so.11 for package:
nautilus-sendto-2.28.4-1.fc13.i686
--> Processing Dependency: libedataserver-1.2.so.11 for package:
gnome-panel-2.30.0-1.fc13.i686
---> Package evolution-data-server.i686 0:2.30.2-2.fc13 set to be updated
--> Finished Dependency Resolution
Error: Package: gnome-panel-2.30.0-1.fc13.i686 (@fedora)
Requires: libedataserver-1.2.so.11
Removing: evolution-data-server-2.30.1-2.fc13.i686 (@fedora)
Error: Package: pidgin-evolution-2.7.1-2.fc13.i686 (@updates)
Requires: libedataserver-1.2.so.11
Removing: evolution-data-server-2.30.1-2.fc13.i686 (@fedora)
Error: Package: nautilus-sendto-2.28.4-1.fc13.i686 (@fedora)
Requires: libedataserver-1.2.so.11
Removing: evolution-data-server-2.30.1-2.fc13.i686 (@fedora)
Ralf
12:03 a.m.
On Tue, 29 Jun 2010 06:58:54 +0200
Ralf Corsepius <rc040203(a)freenet.de> wrote:
On 06/29/2010 06:17 AM, Braden McDaniel wrote:
> Updating F13 now works;
Does it?
Not for me.
It's only in updates-testing yet.
Also, pidgin needed to be added to it. It failed rebuild due to a new
tcl in the buildroot. This tcl build has been untagged now, so it's
been rebuilt and should be added to the update soon.
https://admin.fedoraproject.org/updates/dates-0.4.11-4.fc13,contacts-0.9-...
Please test.
kevin
11:53 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 6/29/10 3:44 AM, Michael Schwendt wrote:
On Mon, 28 Jun 2010 23:03:23 -0600, Kevin wrote:
> It's only in updates-testing yet.
Gah! :-/
I wonder whether after years the "Fedora N updates-testing report" could
finally be sent to users' list instead of test list? Who can make that
happen?
The bodhi developer could, through a ticket. However a change like that
impacts a lot of people, it should be well thought out. A fesco ticket
perhaps?
- --
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkwqJQkACgkQ4v2HLvE71NVF5ACbBSrI99sF61FxdkkRwRVRciCh
BQYAoLA7mKIoAdGlbLgd/tPo1bDOT5Xd
=a5uF
-----END PGP SIGNATURE-----
12:05 p.m.
On Tue, 2010-06-29 at 12:44 +0200, Michael Schwendt wrote:
On Mon, 28 Jun 2010 23:03:23 -0600, Kevin wrote:
> It's only in updates-testing yet.
Gah! :-/
I wonder whether after years the "Fedora N updates-testing report" could
finally be sent to users' list instead of test list? Who can make that
happen?
Please don't. Update testing is part of QA team's responsibilities, test
list is the appropriate place for it. Regular users aren't supposed to
install test updates.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:01 p.m.
On Tue, 29 Jun 2010 10:05:59 -0700, Adam wrote:
On Tue, 2010-06-29 at 12:44 +0200, Michael Schwendt wrote:
> On Mon, 28 Jun 2010 23:03:23 -0600, Kevin wrote:
>
> > It's only in updates-testing yet.
>
> Gah! :-/
>
> I wonder whether after years the "Fedora N updates-testing report" could
> finally be sent to users' list instead of test list? Who can make that
> happen?
Please don't. Update testing is part of QA team's responsibilities, test
list is the appropriate place for it. Regular users aren't supposed to
install test updates.
A _copy_ to users' list would suffice. Test updates are relevant to the
users - and the build reports are sort of an early warning system about
what updates will likely be unleashed. It's especially relevant to the
users, when the updates aren't tested prior to entering the stable
updates repository. And so far, there is no QA team that tests them.
Once they have entered the updates repo, regular users are supposed to
install them, and then it's too late.
2:28 p.m.
Michael Schwendt wrote:
A_copy_ to users' list would suffice. Test updates are relevant
to the
users - and the build reports are sort of an early warning system about
what updates will likely be unleashed. It's especially relevant to the
users, when the updates aren't tested prior to entering the stable
updates repository. And so far, there is no QA team that tests them.
Once they have entered the updates repo, regular users are supposed to
install them, and then it's too late.
A copy of broken deps should be obsolete when Adam and friends are
allowed to use AutoQA to prevent this sort of thing from hitting stable.
Should you even worry about it?
2:35 p.m.
On Tue, 2010-06-29 at 14:28 -0500, Michael Cronenworth wrote:
Michael Schwendt wrote:
> A_copy_ to users' list would suffice. Test updates are relevant to the
> users - and the build reports are sort of an early warning system about
> what updates will likely be unleashed. It's especially relevant to the
> users, when the updates aren't tested prior to entering the stable
> updates repository. And so far, there is no QA team that tests them.
> Once they have entered the updates repo, regular users are supposed to
> install them, and then it's too late.
A copy of broken deps should be obsolete when Adam and friends are
allowed to use AutoQA to prevent this sort of thing from hitting stable.
Should you even worry about it?
It's not a question of 'allowed', it's a question of when it's
actually
done. =) If you follow the regular AutoQA updates in the QA meetings,
you'll see that the depcheck test is one of the more complex to
implement and requires integration with releng. We also still have a few
hurdles to putting the AutoQA framework in general into full production
- mainly getting gwt properly packaged in a way that's acceptable for
the Fedora repos.
The timescale on AutoQA's depcheck testing going active is still
probably multiple weeks and probably a few months. That's something of a
WAG - wwoods would be able to give a much more reliable prediction - but
I think it's in the ballpark. So I don't think we're yet far enough
along that we can just say 'meh, autoqa will fix it, let's not bother
doing anything else about it'.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
6:08 p.m.
On Tue, 29 Jun 2010 14:28:40 -0500, Michael wrote:
Michael Schwendt wrote:
> A_copy_ to users' list would suffice. Test updates are relevant to the
> users - and the build reports are sort of an early warning system about
> what updates will likely be unleashed. It's especially relevant to the
> users, when the updates aren't tested prior to entering the stable
> updates repository. And so far, there is no QA team that tests them.
> Once they have entered the updates repo, regular users are supposed to
> install them, and then it's too late.
A copy of broken deps should be obsolete when Adam and friends are
allowed to use AutoQA to prevent this sort of thing from hitting stable.
Should you even worry about it?
I refer to the "Fedora N updates-testing report" not the broken deps
report. Test updates are in need of much more testing than just the depcheck.
11:09 p.m.
On Fri, 02 Jul 2010 03:46:29 +0200
Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Kevin Fenzi wrote:
> It's only in updates-testing yet.
Now this is complete nonsense. The update is required to fix broken
dependencies so it should go to stable IMMEDIATELY.
It's in stable now. The time in testing allowed us to fix and add
several more packages to it and confirm that it did indeed fix things.
I know you don't like testing, but IMHO the delay was slight and the
ability to confirm the fixes and add some more made it very much worth
it.
kevin
11:41 a.m.
On 07/02/2010 12:09 AM, Kevin Fenzi wrote:
It's in stable now. The time in testing allowed us to fix and
add
several more packages to it and confirm that it did indeed fix things.
Maybe it's still being propagated, but when I did update --skip-broken
followed by yum update, right now (Fri Jul 2, 0400 GMT) I get
Loaded plugins: auto-update-debuginfo, refresh-packagekit
Found 87 installed debuginfo package(s)
Enabling rpmfusion-free-debuginfo: RPM Fusion for Fedora 13 - Free - Debug
Enabling fedora-debuginfo: Fedora 13 - i386 - Debug
Enabling updates-debuginfo: Fedora 13 - i386 - Updates - Debug
Enabling rpmfusion-free-updates-debuginfo: RPM Fusion for Fedora 13 -
Free - Updates Debug
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package ekiga.i686 0:3.2.7-3.fc13 set to be updated
---> Package empathy.i686 0:2.30.2-3.fc13 set to be updated
---> Package evolution.i686 0:2.30.2-1.fc13 set to be updated
--> Processing Dependency: libedataserver-1.2.so.11 for package:
almanah-0.7.2-1.fc13.i686
---> Package evolution-data-server.i686 0:2.30.2-2.fc13 set to be updated
---> Package evolution-data-server-devel.i686 0:2.30.2-2.fc13 set to be
updated
---> Package evolution-help.noarch 0:2.30.2-1.fc13 set to be updated
---> Package evolution-perl.i686 0:2.30.2-1.fc13 set to be updated
---> Package giggle.i686 0:0.5-2.fc13 set to be updated
---> Package gnome-panel.i686 0:2.30.0-3.fc13 set to be updated
---> Package gnome-panel-devel.i686 0:2.30.0-3.fc13 set to be updated
---> Package gnome-panel-libs.i686 0:2.30.0-3.fc13 set to be updated
---> Package libpurple.i686 0:2.7.1-3.fc13 set to be updated
---> Package nautilus-sendto.i686 0:2.28.4-3.fc13 set to be updated
---> Package pidgin.i686 0:2.7.1-3.fc13 set to be updated
---> Package pidgin-evolution.i686 0:2.7.1-3.fc13 set to be updated
--> Finished Dependency Resolution
Error: Package: almanah-0.7.2-1.fc13.i686
(@anaconda-InstallationRepo-201005130056.i386)
Requires: libedataserver-1.2.so.11
Removing: evolution-data-server-2.30.1-2.fc13.i686
(@anaconda-InstallationRepo-201005130056.i386)
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest
11:47 a.m.
On Fri, 02 Jul 2010 12:41:18 -0400, Przemek wrote:
On 07/02/2010 12:09 AM, Kevin Fenzi wrote:
> It's in stable now. The time in testing allowed us to fix and add
> several more packages to it and confirm that it did indeed fix things.
Maybe it's still being propagated, but when I did update --skip-broken
followed by yum update, right now (Fri Jul 2, 0400 GMT) I get
http://lists.fedoraproject.org/pipermail/test/2010-July/091839.html
12:09 p.m.
On 07/02/2010 12:47 PM, Michael Schwendt wrote:
On Fri, 02 Jul 2010 12:41:18 -0400, Przemek wrote:
> On 07/02/2010 12:09 AM, Kevin Fenzi wrote:
>
>> It's in stable now. The time in testing allowed us to fix and add
>> several more packages to it and confirm that it did indeed fix things.
>
> Maybe it's still being propagated, but when I did update --skip-broken
> followed by yum update, right now (Fri Jul 2, 0400 GMT) I get
http://lists.fedoraproject.org/pipermail/test/2010-July/091839.html
Oh, I get it --- almanah requires old libedataserver which prevents
evolution and all the other packages from updating.
I did rpm -e almanah; yum update and it worked; is there another way?
I suppose it would have to leave both versions of
/usr/lib/libedataserver-1.2.so.{11,13}
1:52 a.m.
On Fri, Jul 02, 2010 at 03:46:29AM +0200, Kevin Kofler wrote:
Kevin Fenzi wrote:
> It's only in updates-testing yet.
Now this is complete nonsense. The update is required to fix broken
dependencies so it should go to stable IMMEDIATELY.
people make mistakes. it happens, no big deal.
pushing it to testing helps to ensure the fix won't be another screwup but
really fixes the issue.
Cheers,
Peter
12:22 a.m.
On Tue, 2010-06-29 at 06:58 +0200, Ralf Corsepius wrote:
On 06/29/2010 06:17 AM, Braden McDaniel wrote:
> Updating F13 now works;
Does it?
Not for me.
Sigh... You're right. Some other updates happened and I thought this
one was included. But it just got skipped.
--
Braden McDaniel <braden(a)endoframe.com>
5046
days inactive
5053
days old
29 comments
16 participants
participants (16)
-
Adam Miller -
Adam Williamson -
Braden McDaniel -
Jesse Keating -
Jesse Keating -
Kevin Fenzi -
Kevin Kofler -
Luke Macken -
Michael Cronenworth -
Michael Schwendt -
Orcan Ogetbil -
Peter Hutterer -
Peter Robinson -
Przemek Klosowski -
Rahul Sundaram -
Ralf Corsepius