1:49 p.m.
Compose started at Wed Mar 17 09:15:24 UTC 2010
Broken deps for i386
----------------------------------------------------------
doodle-0.6.7-5.fc12.i686 requires libextractor.so.1
easystroke-0.5.2-1.fc13.i686 requires libboost_serialization-mt.so.5
fedora-easy-karma-0-0.3.20100306git00fc20aa.fc12.noarch requires fedora-packager >=
0:0.4.0
hornsey-1.5.2-0.1.fc13.i686 requires libclutter-gst-0.10.so.0
linphone-2.1.1-4.fc12.i686 requires libortp.so.7
pyclutter-gst-0.9.2-1.fc12.i686 requires libclutter-gst-0.10.so.0
zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2
Broken deps for x86_64
----------------------------------------------------------
doodle-0.6.7-5.fc12.i686 requires libextractor.so.1
doodle-0.6.7-5.fc12.x86_64 requires libextractor.so.1()(64bit)
easystroke-0.5.2-1.fc13.x86_64 requires libboost_serialization-mt.so.5()(64bit)
fedora-easy-karma-0-0.3.20100306git00fc20aa.fc12.noarch requires fedora-packager >=
0:0.4.0
hornsey-1.5.2-0.1.fc13.x86_64 requires libclutter-gst-0.10.so.0()(64bit)
linphone-2.1.1-4.fc12.i686 requires libortp.so.7
linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit)
pyclutter-gst-0.9.2-1.fc12.x86_64 requires libclutter-gst-0.10.so.0()(64bit)
zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2
New package fedora-easy-karma
Fedora update feedback made easy
New package lldpad
Intel LLDP Agent
New package perl-CatalystX-LeakChecker
Debug memory leaks in Catalyst applications
New package perl-Context-Preserve
Run code after a subroutine call, preserving context
New package rubygem-maruku
Maruku is a Markdown-superset interpreter written in Ruby
New package scantailor
An interactive post-processing tool for scanned pages
Updated Packages:
anjal-0.3.2-1.fc13
------------------
* Fri Mar 05 2010 Peter Robinson <pbrobinson(a)gmail.com> 0.3.2-1
- Official upstream 0.3.2 release tarball
- Add patch to fix explicit dso linking. Fixes 564934
audacious-plugins-2.2-25.fc13
-----------------------------
* Thu Mar 04 2010 Michael Schwendt <mschwendt(a)fedoraproject.org> - 2.2-25
- Update icon popup patch for new playlist API to also fix a double-free
(which made the popup crash with streaming audio).
* Tue Mar 02 2010 Michael Schwendt <mschwendt(a)fedoraproject.org> - 2.2-24
- Patch notification area status icon (fix popup and title changes).
clutter-gst-1.0.0-1.fc13
------------------------
* Fri Mar 05 2010 Peter Robinson <pbrobinson(a)gmail.com> 1.0.0-1
- New upstream 1.0.0 stable release
- Enable introspection support
eclipse-rse-3.1.1-3.fc13
------------------------
* Thu Feb 25 2010 Jeff Johnston <jjohnstn(a)redhat.com> 3.1.1-3
- Resolves: #567874
- Remove oro requirement as it is not needed.
embryo-0.9.9.050-3.fc12
-----------------------
ibus-anthy-1.2.0.20100313-1.fc13
--------------------------------
* Fri Mar 12 2010 Takao Fujiwara <takao.fujiwara1(a)gmail.com> - 1.2.0.20100313-1
- Update to 1.2.0.20100313
- Update fr.po
* Fri Mar 12 2010 Takao Fujiwara <takao.fujiwara1(a)gmail.com> - 1.2.0.20100312.1-1
- Update to 1.2.0.20100312.1
- Minor fix for a translation
* Fri Mar 12 2010 Takao Fujiwara <takao.fujiwara1(a)gmail.com> - 1.2.0.20100312-1
- Update to 1.2.0.20100312
- Fix bug 564268 - Crash with enabled global input method
ibus-table-1.2.0.20100111-7.fc13
--------------------------------
* Wed Mar 10 2010 Caius 'kaio' Chance <cchance at redhat.com> -
1.2.0.20100111-7
- Add template.txt in files.
* Wed Mar 10 2010 Caius 'kaio' Chance <cchance at redhat.com> -
1.2.0.20100111-6
- Disable -additional.
* Wed Mar 10 2010 Caius 'kaio' Chance <cchance at redhat.com> -
1.2.0.20100111-5
- Remove -additional for obsoletion by ibus-table-latin and ibus-table-code.
pgadmin3-1.10.2-1.fc13
----------------------
* Mon Mar 15 2010 Devrim GUNDUZ <devrim(a)gunduz.org> 1.10.2-1
- Update to 1.10.2
pgbouncer-1.3.2-1.fc13
----------------------
* Tue Mar 16 2010 Devrim GÜNDÜZ <devrim(a)gunduz.org> - 1.3.2-1
- Update to 1.3.2, per changes described in:
- http://pgfoundry.org/frs/shownotes.php?release_id=1605
python-4Suite-XML-1.0.2-9.fc13
------------------------------
* Fri Feb 26 2010 Miloslav Trmač <mitr(a)redhat.com> - 1.0.2-9
- Don't use "as" identifier in the test suite
Resolves: #564872
- Point URL: to something that doesn't fail with 503
- Update source URL
qemu-0.12.3-6.fc13
------------------
* Mon Mar 15 2010 Justin M. Forbes <jforbes(a)redhat.com> - 2:0.12.3-6
- Detect cdrom via ioctl (#473154)
- re add increased buffer for USB control requests (#546483)
rabbitmq-server-1.7.2-1.fc13
----------------------------
* Mon Feb 15 2010 Matthew Sackman <matthew(a)lshift.net> 1.7.2-1
- New Upstream Release
* Fri Jan 22 2010 Matthew Sackman <matthew(a)lshift.net> 1.7.1-1
- New Upstream Release
shapelib-1.2.10-2.20100216cvs.fc13
----------------------------------
* Fri Feb 19 2010 Lucian Langa <cooly(a)gnome.eu.org> - 1.2.10-2.20100216cvs
- update patch0-3 fix undefined symbols
system-config-printer-1.1.93-6.fc13
-----------------------------------
* Mon Mar 08 2010 Jiri Popelka <jpopelka(a)redhat.com> 1.1.93-6
- Fixed pycups to be more cautious when removing
the Connection object from the list (bug #567386).
* Wed Mar 03 2010 Tim Waugh <twaugh(a)redhat.com> - 1.1.93-5
- Added comments for all sources and patches.
- Ship COPYING files.
* Mon Mar 01 2010 Tim Waugh <twaugh(a)redhat.com> - 1.1.93-4
- Use icon name 'printer' instead of 'gnome-dev-printer'.
* Mon Mar 01 2010 Tim Waugh <twaugh(a)redhat.com> - 1.1.93-3
- Attempt to install drivers in the Device ID checker.
telepathy-salut-0.3.10-2.fc13
-----------------------------
* Fri Mar 05 2010 Peter Robinson <pbrobinson(a)gmail.com> 0.3.10-2
- Fix DSO linking. Fixes 565145
transmission-1.92-1.fc13
------------------------
* Fri Mar 12 2010 Rahul Sundaram <sundaram(a)fedoraproject.org> - 1.92-1
- Some bug fixes
-
http://trac.transmissionbt.com/query?groupdesc=1&group=component&...
twitter-glib-0.9.8-5.fc13
-------------------------
* Fri Mar 05 2010 Peter Robinson <pbrobinson(a)gmail.com> 0.9.8-5
- Fix DSO linking. Fixes 564625
xastir-1.9.6-3.fc13
-------------------
* Fri Feb 26 2010 Lucian Langa <cooly(a)gnome.eu.org> - 1:1.9.6-3
- rebuild against latest shapelib
Summary:
Added Packages: 6
Removed Packages: 0
Modified Packages: 18
3 p.m.
On Wed, 2010-03-17 at 18:49 +0000, Branched Report wrote:
doodle-0.6.7-5.fc12.i686 requires libextractor.so.1
easystroke-0.5.2-1.fc13.i686 requires
libboost_serialization-mt.so.5
fedora-easy-karma-0-0.3.20100306git00fc20aa.fc12.noarch
requires fedora-packager >= 0:0.4.0
hornsey-1.5.2-0.1.fc13.i686 requires libclutter-gst-0.10.so.0
linphone-2.1.1-4.fc12.i686 requires libortp.so.7
pyclutter-gst-0.9.2-1.fc12.i686 requires
libclutter-gst-0.10.so.0
zikula-module-menutree-2.2-1.fc13.noarch requires zikula >=
0:1.2
Is anybody working on these, or should releng be taking a crack at it?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
4:47 p.m.
> hornsey-1.5.2-0.1.fc13.i686 requires
libclutter-gst-0.10.so.0
This is a known issue and should be resolved shortly. Its part of
'Moblin' and well the whole state is in 'flux'..... watch this (well
maybe not this one) space.... basically more will be known soon!
> pyclutter-gst-0.9.2-1.fc12.i686 requires
> libclutter-gst-0.10.so.0
I'll look at this one as well if no one else does.
Is anybody working on these, or should releng be taking a crack at
it?
Peter
3:12 p.m.
On Wed, Mar 17, 2010 at 06:49:41PM +0000, Branched Report wrote:
fedora-easy-karma-0-0.3.20100306git00fc20aa.fc12.noarch requires
fedora-packager >= 0:0.4.0
This is unexpected behaviour of Fedora for me. Why is the package from
F12 automatically added to the F13 repo? The current situation is, that
I did not push fedora-easy-karma from testing to stable in F13, because
fedora-packager >= 0.4.0 is still in testing there, but it is in stable
in F12, which is why I only pushed it to stable for F12 now.
Regards
Till
3:34 p.m.
On Wed, Mar 17, 2010 at 21:12:33 +0100,
Till Maas <opensource(a)till.name> wrote:
On Wed, Mar 17, 2010 at 06:49:41PM +0000, Branched Report wrote:
> fedora-easy-karma-0-0.3.20100306git00fc20aa.fc12.noarch requires fedora-packager
>= 0:0.4.0
This is unexpected behaviour of Fedora for me. Why is the package from
F12 automatically added to the F13 repo? The current situation is, that
I did not push fedora-easy-karma from testing to stable in F13, because
fedora-packager >= 0.4.0 is still in testing there, but it is in stable
in F12, which is why I only pushed it to stable for F12 now.
dist-f13 inherits from dist-f12-updates so once something makes it to
F12 stable it will start showing up in F13.
4:01 p.m.
Bruno Wolff III (bruno(a)wolff.to) said:
> > fedora-easy-karma-0-0.3.20100306git00fc20aa.fc12.noarch
requires fedora-packager >= 0:0.4.0
>
> This is unexpected behaviour of Fedora for me. Why is the package from
> F12 automatically added to the F13 repo? The current situation is, that
> I did not push fedora-easy-karma from testing to stable in F13, because
> fedora-packager >= 0.4.0 is still in testing there, but it is in stable
> in F12, which is why I only pushed it to stable for F12 now.
dist-f13 inherits from dist-f12-updates so once something makes it to
F12 stable it will start showing up in F13.
... although we may be changing this behavior shortly. Jesse?
Bill
4:25 p.m.
On Wed, 2010-03-17 at 17:01 -0400, Bill Nottingham wrote:
Bruno Wolff III (bruno(a)wolff.to) said:
> > > fedora-easy-karma-0-0.3.20100306git00fc20aa.fc12.noarch requires
fedora-packager >= 0:0.4.0
> >
> > This is unexpected behaviour of Fedora for me. Why is the package from
> > F12 automatically added to the F13 repo? The current situation is, that
> > I did not push fedora-easy-karma from testing to stable in F13, because
> > fedora-packager >= 0.4.0 is still in testing there, but it is in stable
> > in F12, which is why I only pushed it to stable for F12 now.
>
> dist-f13 inherits from dist-f12-updates so once something makes it to
> F12 stable it will start showing up in F13.
... although we may be changing this behavior shortly. Jesse?
Bill
ngggh. I killed the inheritance for all the existing packages, but new
packages can still sneak through, as there is nothing already tagged in
dist-f13.
This is something of a difficult problem. We want the packages and
ownership and other info to be inherited forward, just not the build
tags. I'm going to have to think on this for a bit.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
7:36 p.m.
Till Maas wrote:
On Wed, Mar 17, 2010 at 06:49:41PM +0000, Branched Report wrote:
> fedora-easy-karma-0-0.3.20100306git00fc20aa.fc12.noarch requires
> fedora-packager >= 0:0.4.0
This is unexpected behaviour of Fedora for me. Why is the package from
F12 automatically added to the F13 repo? The current situation is, that
I did not push fedora-easy-karma from testing to stable in F13, because
fedora-packager >= 0.4.0 is still in testing there, but it is in stable
in F12, which is why I only pushed it to stable for F12 now.
Both fedora-easy-karma and fedora-packager are breaking upgrade paths, this
inheritance problem is just another side effect of that. The packages have
to be pushed to stable either simultaneously or in decreasing release order.
Both the fedora-packager maintainer and you: please queue your F13 updates
to stable ASAP to fix the upgrade path (which will also fix this inheritance
glitch). (And yes, fedora-packager needs to be pushed first, that's the
first offender here.) And next time please don't push out a F12 update
without pushing out the equivalent update for F13 first or at the same time.
Kevin Kofler
8:32 p.m.
I wrote:
Both fedora-easy-karma and fedora-packager are breaking upgrade
paths,
this inheritance problem is just another side effect of that. The packages
have to be pushed to stable either simultaneously or in decreasing release
order. Both the fedora-packager maintainer and you: please queue your F13
updates to stable ASAP to fix the upgrade path (which will also fix this
inheritance glitch). (And yes, fedora-packager needs to be pushed first,
that's the first offender here.) And next time please don't push out a F12
update without pushing out the equivalent update for F13 first or at the
same time.
PS: The main cause for this kind of problems is people insisting on separate
testing per release. IMHO updates should go out to all releases at the same
time, based on the sum of the testing done for all of them, then we won't
have such upgrade path problems, ever.
Kevin Kofler
9:47 p.m.
Once upon a time, Kevin Kofler <kevin.kofler(a)chello.at> said:
PS: The main cause for this kind of problems is people insisting on
separate
testing per release. IMHO updates should go out to all releases at the same
time, based on the sum of the testing done for all of them, then we won't
have such upgrade path problems, ever.
It shouldn't be based on the sum, as that would mean positives for one
release could override negatives for another. If you want to require
simultaneous pushes, they should only be after testing for each release
is known good. Just because something works on F12 doesn't mean it
doesn't break things on F11.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
12:49 a.m.
Chris Adams wrote:
It shouldn't be based on the sum, as that would mean positives
for one
release could override negatives for another.
That's kinda the whole point. "Kinda" because of course negatives should not
be ignored, but that's always true, even if the positives are for the same
release! They need to be checked for validity (e.g. longstanding breakage
which is not a regression nor the one bug supposed to be fixed is not a
valid reason to reject the update, but I've seen even more blatantly invalid
complaints), and fixed if valid, not outvoted. (This just shows again how
numeric karma is flawed. It's really stupid to rely on that number for
anything serious.) But my point is that lack of positives for some release
should indeed be ignored if there's enough positive feedback for the exact
same update on some other release.
If you want to require simultaneous pushes, they should only be
after
testing for each release is known good.
First of all, I don't want to REQUIRE anything, but RECOMMEND things. We
already have enough rules we're required to follow, and unfortunately more
(and completely unnecessary ones at that) are coming soon. :-(
And secondly, my suggestion is to assume that positive feedback on release n
+ no complaints on release m = the package is fine on release m as well
(which has a probability very close to 1 in practice, especially if it's
built from the same specfile in both cases).
Just because something works on F12 doesn't mean it doesn't
break things
on F11.
Theoretically yes, but in practice it's extremely unlikely.
Kevin Kofler
3:39 a.m.
On Thu, Mar 18, 2010 at 02:32:35AM +0100, Kevin Kofler wrote:
I wrote:
> Both fedora-easy-karma and fedora-packager are breaking upgrade paths,
> this inheritance problem is just another side effect of that. The packages
> have to be pushed to stable either simultaneously or in decreasing release
> order. Both the fedora-packager maintainer and you: please queue your F13
> updates to stable ASAP to fix the upgrade path (which will also fix this
> inheritance glitch). (And yes, fedora-packager needs to be pushed first,
> that's the first offender here.) And next time please don't push out a F12
> update without pushing out the equivalent update for F13 first or at the
> same time.
PS: The main cause for this kind of problems is people insisting on separate
testing per release. IMHO updates should go out to all releases at the same
time, based on the sum of the testing done for all of them, then we won't
have such upgrade path problems, ever.
It would be enough to only push the update that got enough testing and
all updates in newer releases to keep the upgrade path.
Regards
Till
1:35 a.m.
Till Maas wrote:
It would be enough to only push the update that got enough testing
and
all updates in newer releases to keep the upgrade path.
Yes. Pushing stuff to older releases later does not break upgrade paths, it
just annoys and confuses folks. Pushing stuff to older releases first is
what's really broken and what happened here.
Kevin Kofler
11:52 a.m.
On Thu, 2010-03-18 at 02:32 +0100, Kevin Kofler wrote:
I wrote:
> Both fedora-easy-karma and fedora-packager are breaking upgrade paths,
> this inheritance problem is just another side effect of that. The packages
> have to be pushed to stable either simultaneously or in decreasing release
> order. Both the fedora-packager maintainer and you: please queue your F13
> updates to stable ASAP to fix the upgrade path (which will also fix this
> inheritance glitch). (And yes, fedora-packager needs to be pushed first,
> that's the first offender here.) And next time please don't push out a F12
> update without pushing out the equivalent update for F13 first or at the
> same time.
PS: The main cause for this kind of problems is people insisting on separate
testing per release. IMHO updates should go out to all releases at the same
time, based on the sum of the testing done for all of them, then we won't
have such upgrade path problems, ever.
Kevin Kofler
We do separate testing per release, because each release is different.
Different library sets, different kernels, glibc, some different desktop
environments, etc... Assuming that testing on one release means that
it'll work on other releases is grossly irresponsible.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
1:36 a.m.
Jesse Keating wrote:
We do separate testing per release, because each release is
different.
Different library sets, different kernels, glibc, some different desktop
environments, etc... Assuming that testing on one release means that
it'll work on other releases is grossly irresponsible.
In practice it's almost always true, with really extremely rare exceptions,
which are not worth headaches such as broken upgrade paths.
Kevin Kofler
3:35 a.m.
On Thu, Mar 18, 2010 at 01:36:59AM +0100, Kevin Kofler wrote:
Both fedora-easy-karma and fedora-packager are breaking upgrade
paths, this
inheritance problem is just another side effect of that. The packages have
to be pushed to stable either simultaneously or in decreasing release order.
Both the fedora-packager maintainer and you: please queue your F13 updates
to stable ASAP to fix the upgrade path (which will also fix this inheritance
glitch). (And yes, fedora-packager needs to be pushed first, that's the
first offender here.) And next time please don't push out a F12 update
without pushing out the equivalent update for F13 first or at the same time.
These requirements render the karma automatism useless for all branches
except F13, because the fedora-packager package in F12 was iirc pushed
automatically after it received enough testing. If this implies, that
that the package should also be pushed in F13, then this should happen
automatically, too. Automatic default behaviour that leads to failure
should not exist.
Regards
Till
1:38 a.m.
Till Maas wrote:
These requirements render the karma automatism useless for all
branches
except F13, because the fedora-packager package in F12 was iirc pushed
automatically after it received enough testing. If this implies, that
that the package should also be pushed in F13, then this should happen
automatically, too. Automatic default behaviour that leads to failure
should not exist.
Karma automatism is completely broken and useless, how's that news?
It's quite sad that the rest of FESCo wants to rely on such brokenness even
more in the future (with me being the only one who refused to vote for such
a broken plan which just smells of failure). Numeric karma should be
abolished entirely, not made a requirement for anything.
Kevin Kofler
7:14 a.m.
On Sat, Mar 20, 2010 at 07:38:43AM +0100, Kevin Kofler wrote:
Till Maas wrote:
> These requirements render the karma automatism useless for all branches
> except F13, because the fedora-packager package in F12 was iirc pushed
> automatically after it received enough testing. If this implies, that
> that the package should also be pushed in F13, then this should happen
> automatically, too. Automatic default behaviour that leads to failure
> should not exist.
Karma automatism is completely broken and useless, how's that news?
If this is common knowledge, why does it still exist?
It's quite sad that the rest of FESCo wants to rely on such
brokenness even
more in the future (with me being the only one who refused to vote for such
a broken plan which just smells of failure). Numeric karma should be
abolished entirely, not made a requirement for anything.
IMHO numeric karma is better than nothing, but I agree that it can be
improved a lot.
Regards
Till
1 p.m.
On 18 March 2010 00:19, Branched Report wrote:
Compose started at Wed Mar 17 09:15:24 UTC 2010
linphone-2.1.1-4.fc12.i686 requires libortp.so.7
Thanks Quentin for looking into this and Jesse for importing. I have
filled up bodhi update and requested for testing.
--
Rakesh Pandit
https://fedoraproject.org/wiki/User:Rakesh
freedom, friends, features, first
1:25 p.m.
Am Donnerstag, den 18.03.2010, 23:30 +0530 schrieb Rakesh Pandit:
On 18 March 2010 00:19, Branched Report wrote:
> Compose started at Wed Mar 17 09:15:24 UTC 2010
>
> linphone-2.1.1-4.fc12.i686 requires libortp.so.7
Thanks Quentin for looking into this and Jesse for importing. I have
filled up bodhi update and requested for testing.
Why testing?
A "maybe-broken update" is better than a "non-working programm"
isn't
it?
1:34 p.m.
On Fri, Mar 19, 2010 at 1:25 PM, Thomas Spura
<spurath(a)students.uni-mainz.de> wrote:
Why testing?
A "maybe-broken update" is better than a "non-working programm"
isn't
it?
Because there are a significant number of people that will scream
bloody murder if people push packages directly to stable without
having the package spend at least a little time in testing, no matter
what the reason. There have been enough problems with seemingly
"safe" updates that go directly to stable that I have a hard time
disagreeing with them.
--
Jeff Ollie
3:18 p.m.
On Fri, 2010-03-19 at 13:34 -0500, Jeffrey Ollie wrote:
On Fri, Mar 19, 2010 at 1:25 PM, Thomas Spura
<spurath(a)students.uni-mainz.de> wrote:
>
> Why testing?
>
> A "maybe-broken update" is better than a "non-working programm"
isn't
> it?
Because there are a significant number of people that will scream
bloody murder if people push packages directly to stable without
having the package spend at least a little time in testing, no matter
what the reason. There have been enough problems with seemingly
"safe" updates that go directly to stable that I have a hard time
disagreeing with them.
Besides, the principle is not in fact correct. Just for instance, an
installable package which causes massive data corruption is not better
than an uninstallable package...
Not saying that's the case here, just pointing out that 'it's
uninstallable' is not the worst possible flaw a package can have.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
5164
days inactive
5173
days old
23 comments
12 participants
participants (12)
-
Adam Williamson -
Bill Nottingham -
Bruno Wolff III -
Chris Adams -
Fedora compose checker -
Jeffrey Ollie -
Jesse Keating -
Kevin Kofler -
Peter Robinson -
Rakesh Pandit -
Thomas Spura -
Till Maas