Java Bindings for libnotify
Hi all, I can't find the Java bindings for libnotify -- I thought they would be in libgnome-java, but I guess not. So a couple of questions for the Gnome Desktop team: And are there plans to package java-gnome? If not and I were to package it myself, should java-gnome obsolete libgnome-java? >From the website I get the impression that java-gnome supersedes libgnome-java entirely. Thanks for any insight. Mat -- Mat Booth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Dne 14.3.2010 19:29, Kevin Kofler napsal(a): > Nonsense. There ARE users who want this kind of updates. Please don't > generalize your own opinion to ALL users in that way. "no" is a strong word! And yes, these are users who have subscribed to updates-testing. My wife bitterly complains about the amount of updates she is getting through F12/updates already, so I will have to switch her to something more reasonable for normal users (probably CentOS 6, when it will become available). Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC He uses statistics as a drunken man uses lamp-posts... for support, rather than illumination. -- Andrew Lang -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Dne 15.3.2010 01:59, Kevin Kofler napsal(a): > Where's the evidence for that? I haven't noticed anything like that at all! Isn't it because KDE was always pushing huge amounts of updates, so there is no change for you? Just asking ... I (and especially my wife who started to bitterly copmlain about this to me to the level I plan to switch her to something more stable) certainly see this. Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC He uses statistics as a drunken man uses lamp-posts... for support, rather than illumination. -- Andrew Lang -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On 03/15/2010 12:54 PM, Matěj Cepl wrote: > Dne 14.3.2010 19:29, Kevin Kofler napsal(a): >> Nonsense. There ARE users who want this kind of updates. Please don't >> generalize your own opinion to ALL users in that way. "no" is a strong word! > > And yes, these are users who have subscribed to updates-testing. My wife > bitterly complains about the amount of updates she is getting through > F12/updates already, And she doesn't complain about the unfixed bugs she is suffering from? This is what I am actually complaining about and what hinders me to switch my wife's personal machine to Fedora. > so I will have to switch her to something more > reasonable for normal users If Fedora KDE updates are a problem to here: Simply don't install it and these won't be an issue to her. > (probably CentOS 6, when it will become > available). LOL, ... I am expecting Fedora to experience a significant reductions of contributors, when CentOS6 will become available, because Fedora contributors will switch away from using Fedora. Cause: The current buggyness of Fedora. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Dne 14.3.2010 09:59, Jon Masters napsal(a): > Somewhat shockingly, some people do use Fedora for day to day stuff. Don't worry they will stop soon. After all (quoting one post which I am sorry got burried somewhere down the thread leaves): $ Contributors are what makes Fedora grow and advance as a project. $ Users are only benefitting from our (the contributors') work as a $ side effect. We should all think about this sentence and its consequences. Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC He uses statistics as a drunken man uses lamp-posts... for support, rather than illumination. -- Andrew Lang -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding two packages to comps
Dne 14.3.2010 01:56, Hicham Haouari napsal(a): > I want to add two packages to comps in F-13 and devel: > - ueagle-atm4-firmware to hardware-support group as default > - linux-atm to dial-up group as default And both of the are in agreement with our licensing policies, right? https://fedoraproject.org/wiki/Packaging/LicensingGuidelines -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC He uses statistics as a drunken man uses lamp-posts... for support, rather than illumination. -- Andrew Lang -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Java Bindings for libnotify
> On Monday 15 March 2010, Mat Booth wrote: > Hi all, > > I can't find the Java bindings for libnotify -- I thought they would > be in libgnome-java, but I guess not. > > So a couple of questions for the Gnome Desktop team: > > And are there plans to package java-gnome? Hi Mat, I'm not in the Gnome Desktop team but: There have been several attempts to package java-gnome. Latest one is pending review https://bugzilla.redhat.com/show_bug.cgi?id=551587 . Previous one is https://bugzilla.redhat.com/show_bug.cgi?id=438452 . I think that this is long enough period it hasn't received any attention so just go on review it and get it included in fedora. > > If not and I were to package it myself, should java-gnome obsolete > libgnome-java? According to the rhbz#438452 there shouldn't be any conflicts between the old one and java-gnome but if there is nothing in Fedora that requires libgnome- java and doesn't work with the new java-gnome we should obsolete it. Alex > > >From the website I get the impression that java-gnome supersedes > > libgnome-java entirely. > > Thanks for any insight. > Mat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Java Bindings for libnotify
Dne 15.3.2010 13:43, Alexander Kurtakov napsal(a): > According to the rhbz#438452 there shouldn't be any conflicts between the old > one and java-gnome but if there is nothing in Fedora that requires libgnome- > java and doesn't work with the new java-gnome we should obsolete it. java-gnome 2.* used to be packaged even officially by a Red Hat employee as a part of Frysk project. Since then Frysk has been abandoned (or whatever is its current official status) and I believe nobody seriously touched any java-gnome stuff at all, and nobody seems to require it. Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC He uses statistics as a drunken man uses lamp-posts... for support, rather than illumination. -- Andrew Lang -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PyGame
Christopher Stone wrote: > Can someone update pygame for me? I don't have time and several people > have been complaining. > > TIA > Done. -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gold timings
- "Michal Nowak" wrote: > - "Ian Lance Taylor" wrote: > > > Hi, Tom Tromey pointed me at your message > > > http://lists.fedoraproject.org/pipermail/devel/2010-March/133039.html > > Hi Ian. > > > I was curious what you are timing when you compare ld and gold. Is > > that the total time that it takes to build the package, or just the > > time that the linker runs? > > You may be familiar with Mock which builds source RPMs in chroot. Mock > > prepares build root (e.g. fedora-12-x86_64), installs BuildRequires, > and builds given SRPM. Such a build should be repeatable. What is > done > is that run of this `mock' process is timed -- bad thing obviously > here > is that the build time includes part which is not related to build > itself > (i.e. build root preparation, package installation), however good is > that > the unrelated time is pretty much constant among runs. > > If anyone knows hot to measure just the build time, I'd be glad to > know. > > > As you mention, xulrunner and thunderbird are much slower, which is > > rather odd and completely contrary to my own testing. Do you know > if > > those builds use linker scripts? Do you have the build logs? > > Unfortunately logs are gone with my yesterday's reinstall. However I > am > building xulrunner and thunderbird right now on different box. Will > let > you know till Monday. > > No idea about the linking script since logs are gone. > > > Also, what sort of machine were you running this on, and how much > RAM > > did it have? > > Dualcore, Intel(R) Xeon(R) CPU 5110 @ 1.60GHz, 2GB RAM, 4GB swap. > Ian - > > I'd certainly like to get to the bottom of any cases where gold is > > significantly slower than GNU ld. > > > > I'm not on the devel@lists.fedoraproject.org mailing list. Run with gold was run first, build root was cleared afterwards and run with ld was run then. gold seems to be way slower. GNU GOLD [ PACKAGES xulrunner thunderbird REBUILD ] ld: CVS snapshot from date: 20100312 gcc:gcc-4.4.3-4.fc12 (likely, just a guess) kernel: Linux 2.6.32.9-70.fc12.x86_64 #1 SMP Wed Mar 3 04:40:41 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux (from this machine) [1/2] Package: xulrunner-1.9.1.8-1.fc12 Time: 18:27.26 Size: 67M Status:PASS [2/2] Package: thunderbird-3.0.3-1.fc12 Time: 15:55.48 Size: 89M Status:PASS == TOTAL: 2 PASS: 2 FAIL: 0 GNU ld == [ PACKAGES xulrunner thunderbird REBUILD ] ld: binutils-2.19.51.0.14-37.fc12 (likely, just a guess) gcc:gcc-4.4.3-4.fc12 (likely, just a guess) kernel: Linux 2.6.32.9-70.fc12.x86_64 #1 SMP Wed Mar 3 04:40:41 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux (from this machine) [1/2] Package: xulrunner-1.9.1.8-1.fc12 Time: 10:00.12 Size: 66M Status:PASS [2/2] Package: thunderbird-3.0.3-1.fc12 Time: 9:37.08 Size: 87M Status:PASS == TOTAL: 2 PASS: 2 FAIL: 0 Here are the logs: http://people.redhat.com/psklenar/pub/ Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gold timings
On Mon, Mar 15, 2010 at 13:40, Michal Nowak wrote: > Run with gold was run first, build root was cleared afterwards and > run with ld was run then. gold seems to be way slower. May seem silly but where does the ccache live for mock builds and if it is outside the buildroot was it cleared too? -- There are 10 kinds of people in the world: Those who understand binary and those who don't... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On Mon, Mar 15, 2010 at 12:54 PM, Matěj Cepl wrote: > Dne 14.3.2010 19:29, Kevin Kofler napsal(a): >> Nonsense. There ARE users who want this kind of updates. Please don't >> generalize your own opinion to ALL users in that way. "no" is a strong word! > > And yes, these are users who have subscribed to updates-testing. My wife > bitterly complains about the amount of updates she is getting through > F12/updates already, so I will have to switch her to something more > reasonable for normal users (probably CentOS 6, when it will become > available). Would it be ok for your wife to run Fedora N-1 with only security- and small bugfix-updates? That would mean, Fedora N-current has the updates people like me loves and Fedora N-1 (right now F-11) has only small updates like your wife loves. Would also mean to be one release behind (nothing bad for people who want less updates IMO). -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Desktop app maintainers: Please check for StartupNotify=true
On Sun, Mar 14, 2010 at 5:40 PM, Ville Skyttä wrote: > > If an app uses GTK+ or Qt, does that alone always imply that it satisfies the > desktop entry spec's requirements for StartupNotify=true, i.e. no further > examination of the app's behavior is necessary? The main tricky situation comes when the app implements single-instance behavior internally, and does some sort of IPC (dbus, whatever) to talk to an existing instance. In GNOME 3 this doesn't matter as much because we do single-instance by default, but otherwise it's definitely possible to get the stale "Starting foo..." until it times out. Actually handling this correctly is tricky[1], and I just noticed one of my apps doesn't. Maybe I should really take the plunge and backport app tracking to GNOME 2 which would obviate this. But as a general rule: add it. Even for the IPC case, it only occurs if the user tries to relaunch an existing app, which (albeit without data, but with some educated background) is unusual. Without IPC, having it has a 99.9% chance of being correct. [1] libunique handles this, but see also my fix for my app here: http://git.gnome.org/browse/hotssh/commit/?id=57c43b39413c5128983286f5c09cbaba6b397103 We have plans to basically make all this work out of the box when using GTK+ but it blocks on gdbus. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dual lived modules
- "Marcela Maslanova" wrote: > - "Iain Arnell" wrote: > > > On Fri, Mar 12, 2010 at 9:42 PM, Paul Howarth > > wrote: > > > On Fri, 12 Mar 2010 17:33:31 +0100 > > > Iain Arnell wrote: > > >> On Fri, Mar 12, 2010 at 3:22 PM, Marcela Maslanova > > >> wrote: > > >> > This should test whether yum can handle lower version in main > and > > >> > higher in separated package (Module::Build). The update of > > packages > > >> > went fine if 'Obsoletes' is used in new package [2]. > > >> > > >> Aha. Of course - 'Obsoletes' is necessary, but not why you think. > > The > > >> problem here is that we may be moving from arch-dependent > packages > > >> (i.e. 1:perl-Module-Build-0.3500-110.fc13.x86_64) to noarch > > packages > > >> (i.e. 1:perl-Module-Build-0.3603-1.perltestrepo.noarch). Even > > though > > >> ENVR is higher in the noarch package, yum wont automatically > update > > >> from arch-dependant to noarch. > > > > > > That shouldn't be the case any more: > > > https://bugzilla.redhat.com/show_bug.cgi?id=502401 > > > (fixed in F-11, at least it's supposed to be) > > > > Hmmn. Confirmed - I have no problem with yum updating from current > > 1:perl-Pod-Simple-3.07-87.fc12.x86_64 in F12 to locally built > > 1:perl-Pod-Simple-3.13-1.fc12.noarch. Are you running some old > version > > of yum Marcela? > > > On F-13? No, I have yum-3.2.26-4.fc13.noarch. Maybe that's some side > effect > of my previous experiments. I'll try package more modules and check it > on clean install. Pod::Simple passed even without 'Obsoletes' so > that's probably > not needed at all. Not sure what was wrong with yum. Now are these updates working. > > Also I'll try to fix 'noarch' in perl.spec. Fixed. So, if anyone is willing to start with reviews of sub-packages... I've added into Draft that I should be co-maintainer, therefore feel free to take any sub-package you want :) I suppose we should be careful and don't update in all releases all modules because of ugly build issues like #564836 and #555420. I suppose this happened because of changes in Module::Build, but I could be wrong. Hopefully at least these two will be fixed by update to the latest release. > > Also ;-) If anyone want add/fix something on Drafts below, please do > so. > > > > -- > > Iain. > > -- > > Fedora Extras Perl SIG > > http://www.fedoraproject.org/wiki/Extras/SIGs/Perl > > perl-devel mailing list > > perl-de...@lists.fedoraproject.org > > https://admin.fedoraproject.org/mailman/listinfo/perl-devel > -- > Fedora Extras Perl SIG > http://www.fedoraproject.org/wiki/Extras/SIGs/Perl > perl-devel mailing list > perl-de...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/perl-devel -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re:Re: Desktop app maintainers: Please check for StartupNotify=true
Should we also add StartupWMClass=someting if StartupNotify=true doesn't work? 在2010-03-15 22:33:58，"Colin Walters" 写道： >On Sun, Mar 14, 2010 at 5:40 PM, Ville Skyttä wrote: >> >> If an app uses GTK+ or Qt, does that alone always imply that it satisfies the >> desktop entry spec's requirements for StartupNotify=true, i.e. no further >> examination of the app's behavior is necessary? > >The main tricky situation comes when the app implements >single-instance behavior internally, and does some sort of IPC (dbus, >whatever) to talk to an existing instance. In GNOME 3 this doesn't >matter as much because we do single-instance by default, but otherwise >it's definitely possible to get the stale "Starting foo..." until it >times out. Actually handling this correctly is tricky[1], and I just >noticed one of my apps doesn't. Maybe I should really take the plunge >and backport app tracking to GNOME 2 which would obviate this. > >But as a general rule: add it. Even for the IPC case, it only occurs >if the user tries to relaunch an existing app, which (albeit without >data, but with some educated background) is unusual. Without IPC, >having it has a 99.9% chance of being correct. > >[1] libunique handles this, but see also my fix for my app here: >http://git.gnome.org/browse/hotssh/commit/?id=57c43b39413c5128983286f5c09cbaba6b397103 > >We have plans to basically make all this work out of the box when >using GTK+ but it blocks on gdbus. >-- >devel mailing list >devel@lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 564999] FTBFS mldonkey-3.0.0-3.fc12: ImplicitDSOLinking
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=564999 Peter Lemenkov changed: What|Removed |Added Status|NEW |ASSIGNED -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: Gold timings
- "John5342" wrote: > On Mon, Mar 15, 2010 at 13:40, Michal Nowak > wrote: > > Run with gold was run first, build root was cleared afterwards and > > run with ld was run then. gold seems to be way slower. > > May seem silly but where does the ccache live for mock builds and if > it is outside the buildroot was it cleared too? Good point. /var/cache/mock/fedora-12-x86_64/ccache/ holds some data. So I guess it's *the* (c)cache. And I was not cleaning it... Perhaps there's option to clean ccache in Mock? Will re-run the tests. Michal > > -- > There are 10 kinds of people in the world: Those who understand > binary > and those who don't... > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Desktop app maintainers: Please check for StartupNotify=true
On Mon, Mar 15, 2010 at 10:44 AM, Chen Lei wrote: > Should we also add StartupWMClass=someting if StartupNotify=true doesn't > work? You're going to need to elaborate on "doesn't work". * You don't see a "Starting..." notification in the tasklist in GNOME 2? * You do, but it times out instead of disappearing when the app window comes up? * Something else? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Desktop app maintainers: Please check for StartupNotify=true
On 15 March 2010 15:07, Colin Walters wrote: > On Mon, Mar 15, 2010 at 10:44 AM, Chen Lei wrote: >> Should we also add StartupWMClass=someting if StartupNotify=true doesn't >> work? > > You're going to need to elaborate on "doesn't work". > > * You don't see a "Starting..." notification in the tasklist in GNOME 2? > * You do, but it times out instead of disappearing when the app window comes > up? > * Something else? Well, for Firefox at least, it's option 2 and has been for a while (at least under KDE): https://bugzilla.redhat.com/show_bug.cgi?id=445543 :), MEF -- Mary Ellen Foster -- http://www.macs.hw.ac.uk/~mef3/ Interaction Lab -- http://www.macs.hw.ac.uk/InteractionLab School of Mathematical and Computer Sciences, Heriot-Watt University Heriot-Watt University is a Scottish charity registered under charity number SC000278 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
DeviceKit-power has been renamed to upower
As some of you may know, DeviceKit-power has been renamed to upower. If you depend on the former, you need to change your rawhide spec files to depend on the latter. DeviceKit-power will cease to be a package in devel in a few minutes. I've not made any changes to F13 branches, as it's too close to release time for this sort of change. If your project is using devkit-power-gobject, you can still keep using this, although upower will only provide this compatibility library for another few months, and applications are urged to move to libupower as soon as possible. Thanks, Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-File-ChangeNotify
perl-File-ChangeNotify has broken dependencies in the rawhide tree: On x86_64: perl-File-ChangeNotify-0.12-1.fc14.noarch requires perl(IO::KQueue) On i386: perl-File-ChangeNotify-0.12-1.fc14.noarch requires perl(IO::KQueue) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Java Bindings for libnotify
On 15 March 2010 12:43, Alexander Kurtakov wrote: >> On Monday 15 March 2010, Mat Booth wrote: >> Hi all, >> >> I can't find the Java bindings for libnotify -- I thought they would >> be in libgnome-java, but I guess not. >> >> So a couple of questions for the Gnome Desktop team: >> >> And are there plans to package java-gnome? > Hi Mat, > I'm not in the Gnome Desktop team but: > There have been several attempts to package java-gnome. Latest one is pending > review https://bugzilla.redhat.com/show_bug.cgi?id=551587 . > Previous one is https://bugzilla.redhat.com/show_bug.cgi?id=438452 . > I think that this is long enough period it hasn't received any attention so > just go on review it and get it included in fedora. > > Thanks for the links Alex. The ticket blocks FE-NEEDSPONSOR, so I will need a promotion first. I have asked on the ticket if he is still interested in continuing the review. >> >> If not and I were to package it myself, should java-gnome obsolete >> libgnome-java? > According to the rhbz#438452 there shouldn't be any conflicts between the old > one and java-gnome but if there is nothing in Fedora that requires libgnome- > java and doesn't work with the new java-gnome we should obsolete it. > > Alex > As Matěj points out, it would seem that Frysk still needs it. I would would very much like to use java-gnome's libnotify API for a proprietary app and this got me thinking, why isn't OpenJDK's java.awt.SystemTray and java.awt.TrayIcon API implemented using libnotify? I don't mean to be rude to whoever wrote the current java.awt.SystemTray and java.awt.TrayIcon implementations for X, but it isn't at all integrated into the default desktop's look and feel and presumably looks just as bad in KDE. -- Mat Booth -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Java Bindings for libnotify
frysk is long dead (and who was using it anyway ?), frysk developers are working on gdb/Archer now. http://sources.redhat.com/frysk/ I suggest that both frysk and old gnome java wrappers to be dropped from packages collection. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gold timings
- "Michal Nowak" wrote: > - "John5342" wrote: > > > On Mon, Mar 15, 2010 at 13:40, Michal Nowak > > wrote: > > > Run with gold was run first, build root was cleared afterwards > and > > > run with ld was run then. gold seems to be way slower. > > > > May seem silly but where does the ccache live for mock builds and > if > > it is outside the buildroot was it cleared too? > > Good point. /var/cache/mock/fedora-12-x86_64/ccache/ holds some data. > So I guess it's *the* (c)cache. And I was not cleaning it... Perhaps > there's option to clean ccache in Mock? > > Will re-run the tests. So, ld and gold are comparable regarding timing. [ PACKAGES xulrunner thunderbird REBUILD ] ld: binutils-2.19.51.0.14-37.fc12 (likely, just a guess) gcc:gcc-4.4.3-4.fc12 (likely, just a guess) kernel: Linux intel-sdp-01.rhts.englab.brq.redhat.com 2.6.32.9-70.fc12.x86_64 #1 SMP Wed Mar 3 04:40:41 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux (from this machine) [1/2] Package: xulrunner-1.9.1.8-1.fc12 Time: 18:50.61 Size: 66M Status:PASS [2/2] Package: thunderbird-3.0.3-1.fc12 Time: 15:23.98 Size: 87M Status:PASS == TOTAL: 2 PASS: 2 FAIL: 0 Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DeviceKit-power has been renamed to upower
On Mon, Mar 15, 2010 at 15:17:20 +, Richard Hughes wrote: > As some of you may know, DeviceKit-power has been renamed to upower. > If you depend on the former, you need to change your rawhide spec > files to depend on the latter. DeviceKit-power will cease to be a > package in devel in a few minutes. Is there some reason you aren't doing a provides for the old name so that things still work? (And presumably an obsoletes as well.) See: http://fedoraproject.org/wiki/PackageNamingGuidelines#Renaming.2Freplacing_existing_packages -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100315 changes
Compose started at Mon Mar 15 08:15:09 UTC 2010 Broken deps for i386 -- easystroke-0.5.2-1.fc13.i686 requires libboost_serialization-mt.so.5 emotion-0.1.0.042-5.fc12.i686 requires libecore_job.so.0 emotion-0.1.0.042-5.fc12.i686 requires libevas.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_fb.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_x.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_txt.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_job.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libevas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_fb.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libefreet.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_file.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libefreet_mime.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_con.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_ipc.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libedbus.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libehal.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_x.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libedje.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_evas.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_file.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_con.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_x.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libedje.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_file.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_con.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_x.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0 evolution-couchdb-0.3.2-2.fc13.i686 requires libcouchdb-glib-1.0.so.1 ewl-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0 ewl-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore.so.0 ewl-0.5.2.042-12.fc12.i686 requires libefreet.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore_file.so.0 ewl-0.5.2.042-12.fc12.i686 requires libefreet_mime.so.0 ewl-0.5.2.042-12.fc12.i686 requires libedje.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_file.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libedje.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_evas.so.0 freehoo-3.5.3-3.fc12.i686 requires libyahoo2.so.10 hornsey-1.5.2-0.1.fc13.i686 requires libclutter-gst-0.10.so.0 inkscape-0.47-6.fc13.i686 requires libMagickCore.so.2 inkscape-0.47-6.fc13.i686 requires libMagick++.so.2 inkscape-view-0.47-6.fc13.i686 requires libMagick++.so.2 inkscape-view-0.47-6.fc13.i686 requires libMagickCore.so.2 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 murmur-1.1.8-15.fc12.i686 requires libIce.so.33 murmur-1.1.8-15.fc12.i686 requires libIceUtil.so.33 openvas-libnasl-2.0.2-3.fc13.i686 requires libopenvas_hg.so.2 openvas-libnasl-2.0.2-3.fc13.i686 requires libopenvas.so.2 paperbox-0.4.4-2.fc12.i686 requires libtrackerclient.so.0 perl-File-ChangeNotify-0.12-1.fc14.noarch requires perl(IO::KQueue) php-pecl-imagick-2.2.2-4.fc12.i686 requires libMagickWand.so.2 php-pecl-imagick-2.2.2-4.fc12.i686 requires libMagickCore.so.2 pyclutter-gst-0.9.2-1.fc12.i686 requires libclutter-gst-0.10.so.0 q-magick-7.11-6.fc12.i686 requires libMagickCore.so.2 rss-glx-0.9.1.p-2.fc13.i686 requires libM
kernel bug or coincidence
hello, I have experienced a failure like this twice on same day and once in another day Call Trace: ... [] kernel_thread_helper+0x7 ... I have scrolled up and found that there is some sata errors ata1: limiting speed to ata1.00: SATA link up ... ... this happened twice and it happened only with the updated kernel my yum logs shows Feb 15 00:35:35 Installed: kernel-PAE-2.6.30.10-105.2.23.fc11.i686 I'm now using the previous kernel for days and I've not encountered that error and DeviceKit does not report any problem my current kernel is uname -r 2.6.30.10-105.2.16.fc11.i686.PAE here are images of the problem http://uppix.net/d/d/a/c4f09aa4209ac30230080fa5aa52d.jpg http://uppix.net/b/8/1/e1a430ab2a3e0bb7478feed74eb53.jpg http://uppix.net/0/0/c/667ca14c8b0da542cd92986de1cf7.jpg -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Rahul Sundaram wrote: > How many contributors are interested in only serving themselves? Is that > what we want to encourage? I'm going to hazard a guess and say "all of them". It's basic psychology; people don't do things that have no (perceived) benefit to them. At most ephemeral, that benefit is "karma". Usually it is more tangible (money, happiness from helping others, etc and in the Free Software world, often "scratching one's own itch"). > By losing users, you lose the > opportunity for that to even happen or atleast make it significantly > less likely. So you prefer to throw our current contributors under the bus in the *hope* that by increasing users in general you see an increase in contributors? Okay. Points for long-term thinking. Not so much for watering down Fedora into another Ubuntu. Fedora currently is progressive and aggressive. Maybe moving to progressive and conservative will work, but the question I have is how effectively can you be progressive without also being aggressive? I think there is a danger that development will either falter to follow the slowed pace of release, or else have to move to rawhide, which means more pain for developers and ergo fewer developers. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Time to get out the marshmallows... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding two packages to comps
On 03/15/2010 08:15 AM, Matěj Cepl wrote: > Dne 14.3.2010 01:56, Hicham Haouari napsal(a): >> I want to add two packages to comps in F-13 and devel: >> - ueagle-atm4-firmware to hardware-support group as default >> - linux-atm to dial-up group as default > > And both of the are in agreement with our licensing policies, right? > https://fedoraproject.org/wiki/Packaging/LicensingGuidelines I cleared the firmware in the first package, at a minimum. ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Desktop app maintainers: Please check for StartupNotify=true
On Mon, Mar 15, 2010 at 1:07 AM, Colin Walters wrote: > Hi, > > For GNOME 3 to more reliably do application tracking, we will be > associating through startup-notification. Some background here: > > http://lists.freedesktop.org/archives/xdg/2010-February/011321.html > > However for startup notification to work, for compatibility reasons, > the upstream .desktop file must have StartupNotify=true. It's come to > my attention that a lot of .desktop files are missing this, even > though they use GTK+. I've written a quick script which heuristically > examines installed apps (attached); if someone writes the script which > checks the whole repository, that'd be cool. > > If you maintain a desktop app, please check for StartupNotify=true, > and if your app uses GTK+ or Qt, then please submit a patch *upstream* > to add it, and at your option apply that patch in Fedora. > > Here's sample output from the script on my workstation, which shows a > vast swath of system-config-* missing it; others of these are false > positives since they're not user-visible apps. Upstream just accepted the patch for Meiga : http://git.igalia.com/cgi-bin/gitweb.cgi?p=meiga.git;a=commitdiff;h=5359f57e2b7d269d860cc4af55b39e07c3b08b5f > > [walt...@megatron gtk+ (master)]$ ~/bin/verify-startupnotify.py > '/usr/share/applications/system-config-date.desktop' probably needs > StartupNotify=true > '/usr/share/applications/nm-pptp.desktop' probably needs StartupNotify=true > '/usr/share/applications/emacs.desktop' probably needs StartupNotify=true > '/usr/share/applications/nm-openvpn.desktop' probably needs StartupNotify=true > '/usr/share/applications/mimeinfo.cache' probably needs StartupNotify=true > '/usr/share/applications/system-config-boot.desktop' probably needs > StartupNotify=true > '/usr/share/applications/redhat-userinfo.desktop' probably needs > StartupNotify=true > '/usr/share/applications/livna-config-display.desktop' probably needs > StartupNotify=true > '/usr/share/applications/redhat-authconfig.desktop' probably needs > StartupNotify=true > '/usr/share/applications/mount-archive.desktop' probably needs > StartupNotify=true > '/usr/share/applications/fedora-liveusb-creator.desktop' probably > needs StartupNotify=true > '/usr/share/applications/virt-manager.desktop' probably needs > StartupNotify=true > '/usr/share/applications/mutter.desktop' probably needs StartupNotify=true > '/usr/share/applications/palimpsest.desktop' probably needs StartupNotify=true > '/usr/share/applications/redhat-userpasswd.desktop' probably needs > StartupNotify=true > '/usr/share/applications/gnome-shell.desktop' probably needs > StartupNotify=true > '/usr/share/applications/spring-installer.desktop' probably needs > StartupNotify=true > '/usr/share/applications/redhat-system-control-network.desktop' > probably needs StartupNotify=true > '/usr/share/applications/fedora-empathy.desktop' probably needs > StartupNotify=true > '/usr/share/applications/ca-installer.desktop' probably needs > StartupNotify=true > '/usr/share/applications/jpackage-logfactor5.desktop' probably needs > StartupNotify=true > '/usr/share/applications/redhat-email.desktop' probably needs > StartupNotify=true > '/usr/share/applications/paperbox.desktop' probably needs StartupNotify=true > '/usr/share/applications/fedora-vagalume.desktop' probably needs > StartupNotify=true > '/usr/share/applications/eclipse.desktop' probably needs StartupNotify=true > '/usr/share/applications/javaws.desktop' probably needs StartupNotify=true > '/usr/share/applications/redhat-web.desktop' probably needs StartupNotify=true > '/usr/share/applications/my-default-printer.desktop' probably needs > StartupNotify=true > '/usr/share/applications/system-config-users.desktop' probably needs > StartupNotify=true > '/usr/share/applications/transmission.desktop' probably needs > StartupNotify=true > '/usr/share/applications/nvidia-settings.desktop' probably needs > StartupNotify=true > '/usr/share/applications/springlobby.desktop' probably needs > StartupNotify=true > '/usr/share/applications/redhat-system-config-network.desktop' > probably needs StartupNotify=true > '/usr/share/applications/metacity.desktop' probably needs StartupNotify=true > '/usr/share/applications/qt4-qtconfig.desktop' probably needs > StartupNotify=true > '/usr/share/applications/gnome-glade-2.desktop' probably needs > StartupNotify=true > '/usr/share/applications/spring.desktop' probably needs StartupNotify=true > '/usr/share/applications/compiz-gtk.desktop' probably needs StartupNotify=true > '/usr/share/applications/jpackage-chainsaw.desktop' probably needs > StartupNotify=true > '/usr/share/applications/mozilla-thunderbird.desktop' probably needs > StartupNotify=true > '/usr/share/applications/nm-connection-editor.desktop' probably needs > StartupNotify=true > '/usr/share/applications/alacarte.desktop' probably needs StartupNotify=true > '/usr/share/applications/nm-vpnc.desktop' probably needs StartupNotify=true > '/usr/
rpms/perl-File-ChangeNotify/devel auto.ini, NONE, 1.1 perl-File-ChangeNotify.spec, 1.5, 1.6
Author: cweyl
Update of /cvs/extras/rpms/perl-File-ChangeNotify/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv3312
Modified Files:
perl-File-ChangeNotify.spec
Added Files:
auto.ini
Log Message:
* Mon Mar 15 2010 Chris Weyl 0.12-2
- update by Fedora::App::MaintainerTools 0.006
--- NEW FILE auto.ini ---
[metadata_filtering]
filter_from_requires=/^perl(IO::KQueue)/
Index: perl-File-ChangeNotify.spec
===
RCS file:
/cvs/extras/rpms/perl-File-ChangeNotify/devel/perl-File-ChangeNotify.spec,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- perl-File-ChangeNotify.spec 13 Mar 2010 20:07:06 - 1.5
+++ perl-File-ChangeNotify.spec 15 Mar 2010 16:34:13 - 1.6
@@ -1,7 +1,7 @@
Name: perl-File-ChangeNotify
Summary:Watch for changes to files, cross-platform style
Version:0.12
-Release:1%{?dist}
+Release:2%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/D/DR/DROLSKY/File-ChangeNotify-%{version}.tar.gz
@@ -36,6 +36,7 @@ Requires: perl(MooseX::SemiAfforda
Requires: perl(Time::HiRes)
+%{?filter_from_requires: %filter_from_requires /^perl(IO::KQueue)/ }
%{?perl_default_filter}
%{?perl_default_subpackage_tests}
@@ -72,6 +73,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*.3*
%changelog
+* Mon Mar 15 2010 Chris Weyl 0.12-2
+- update by Fedora::App::MaintainerTools 0.006
+
* Sat Mar 13 2010 Chris Weyl 0.12-1
- update by Fedora::App::MaintainerTools 0.006
- PERL_INSTALL_ROOT => DESTDIR
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-File-ChangeNotify/F-13 perl-File-ChangeNotify.spec,1.5,1.6
Author: cweyl
Update of /cvs/extras/rpms/perl-File-ChangeNotify/F-13
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv3608
Modified Files:
perl-File-ChangeNotify.spec
Log Message:
* Mon Mar 15 2010 Chris Weyl 0.12-2
- update by Fedora::App::MaintainerTools 0.006
Index: perl-File-ChangeNotify.spec
===
RCS file:
/cvs/extras/rpms/perl-File-ChangeNotify/F-13/perl-File-ChangeNotify.spec,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- perl-File-ChangeNotify.spec 13 Mar 2010 20:10:32 - 1.5
+++ perl-File-ChangeNotify.spec 15 Mar 2010 16:35:05 - 1.6
@@ -1,7 +1,7 @@
Name: perl-File-ChangeNotify
Summary:Watch for changes to files, cross-platform style
Version:0.12
-Release:1%{?dist}
+Release:2%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/D/DR/DROLSKY/File-ChangeNotify-%{version}.tar.gz
@@ -36,6 +36,7 @@ Requires: perl(MooseX::SemiAfforda
Requires: perl(Time::HiRes)
+%{?filter_from_requires: %filter_from_requires /^perl(IO::KQueue)/ }
%{?perl_default_filter}
%{?perl_default_subpackage_tests}
@@ -72,6 +73,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*.3*
%changelog
+* Mon Mar 15 2010 Chris Weyl 0.12-2
+- update by Fedora::App::MaintainerTools 0.006
+
* Sat Mar 13 2010 Chris Weyl 0.12-1
- update by Fedora::App::MaintainerTools 0.006
- PERL_INSTALL_ROOT => DESTDIR
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-File-ChangeNotify/F-12 perl-File-ChangeNotify.spec,1.4,1.5
Author: cweyl
Update of /cvs/extras/rpms/perl-File-ChangeNotify/F-12
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv3764
Modified Files:
perl-File-ChangeNotify.spec
Log Message:
* Mon Mar 15 2010 Chris Weyl 0.12-2
- update by Fedora::App::MaintainerTools 0.006
Index: perl-File-ChangeNotify.spec
===
RCS file:
/cvs/extras/rpms/perl-File-ChangeNotify/F-12/perl-File-ChangeNotify.spec,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- perl-File-ChangeNotify.spec 13 Mar 2010 20:10:45 - 1.4
+++ perl-File-ChangeNotify.spec 15 Mar 2010 16:35:30 - 1.5
@@ -1,7 +1,7 @@
Name: perl-File-ChangeNotify
Summary:Watch for changes to files, cross-platform style
Version:0.12
-Release:1%{?dist}
+Release:2%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/D/DR/DROLSKY/File-ChangeNotify-%{version}.tar.gz
@@ -36,6 +36,7 @@ Requires: perl(MooseX::SemiAfforda
Requires: perl(Time::HiRes)
+%{?filter_from_requires: %filter_from_requires /^perl(IO::KQueue)/ }
%{?perl_default_filter}
%{?perl_default_subpackage_tests}
@@ -72,6 +73,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*.3*
%changelog
+* Mon Mar 15 2010 Chris Weyl 0.12-2
+- update by Fedora::App::MaintainerTools 0.006
+
* Sat Mar 13 2010 Chris Weyl 0.12-1
- update by Fedora::App::MaintainerTools 0.006
- PERL_INSTALL_ROOT => DESTDIR
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On 03/15/2010 09:43 PM, Matthew Woehlke wrote: > Rahul Sundaram wrote: > >> How many contributors are interested in only serving themselves? Is that >> what we want to encourage? >> > I'm going to hazard a guess and say "all of them". It's basic > psychology; people don't do things that have no (perceived) benefit to > them. At most ephemeral, that benefit is "karma". > Well, people can serve themselves but they need to care about more than *only* that. > So you prefer to throw our current contributors under the bus in the > *hope* that by increasing users in general you see an increase in > contributors? > Nope. I haven't said anything along those lines. > Okay. Points for long-term thinking. Not so much for watering down > Fedora into another Ubuntu. > Fedora is inherently different because of several major reasons ( free software focus, upstream contributions etc) so I don't feel any insecurity about all this. > Fedora currently is progressive and aggressive. Maybe moving to > progressive and conservative will work, but the question I have is how > effectively can you be progressive without also being aggressive > Fedora is currently disjoint and acts differently based on which set of packages you are talking about ( KDE vs GNOME, Firefox et all). Progressive and aggressive is all fine as part of development branches as far as I am concerned. Several other distributions take care of this disjoint nature by splitting up the repository and having two different update streams. With a smaller amount of additional maintenance burden, we can do this as well. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DeviceKit-power has been renamed to upower
On 15 March 2010 15:38, Bruno Wolff III wrote: > On Mon, Mar 15, 2010 at 15:17:20 +, > Richard Hughes wrote: >> As some of you may know, DeviceKit-power has been renamed to upower. >> If you depend on the former, you need to change your rawhide spec >> files to depend on the latter. DeviceKit-power will cease to be a >> package in devel in a few minutes. > > Is there some reason you aren't doing a provides for the old name so that > things still work? (And presumably an obsoletes as well.) I'm doing an obsoletes, but I would rather people feel the pain of having to update the spec files now (early in the F14 cycle) rather than when we remove the compatibility provides in over a years time, and when nobody remembers what the new name is. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adventurous updates?
Michael Schwendt wrote: > But that high-impact bugs in some Fedora Updates have slipped > through, because their package maintainers had been willing to take > the risk, and that has prompted some people to try to change that > part of Fedora. That's *exactly* what I am afraid of... that Fedora is going to get turned into a distribution that is afraid to take risks. We have plenty of those already. We NEED a distribution willing to take risks, because that is how progress happens. (Or at least, how it happens at a non-glacial pace.) -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Time to get out the marshmallows... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-File-ChangeNotify/devel auto.ini,1.1,1.2
Author: cweyl Update of /cvs/extras/rpms/perl-File-ChangeNotify/devel In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv9087 Modified Files: auto.ini Log Message: * Mon Mar 15 2010 Chris Weyl 0.12-2 - update by Fedora::App::MaintainerTools 0.006 Index: auto.ini === RCS file: /cvs/extras/rpms/perl-File-ChangeNotify/devel/auto.ini,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- auto.ini15 Mar 2010 16:34:13 - 1.1 +++ auto.ini15 Mar 2010 17:06:51 - 1.2 @@ -1,3 +1,4 @@ [metadata_filtering] +; IO::KQueue is only useful under BSD :) filter_from_requires=/^perl(IO::KQueue)/ -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On 03/15/2010 05:36 PM, Rahul Sundaram wrote: > Progressive and aggressive is all fine as part of development branches > as far as I am concerned. Several other distributions take care of this > disjoint nature by splitting up the repository and having two different > update streams. With a smaller amount of additional maintenance burden, > we can do this as well. Your claim is self-contradictory: Additional repos mean additional maintenance burden and additional complexity. Or did I read your request incorrectly and you are proposing to reintroduce a Core+Extra's split? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On 03/15/2010 10:37 PM, Ralf Corsepius wrote: > On 03/15/2010 05:36 PM, Rahul Sundaram wrote: > > >> Progressive and aggressive is all fine as part of development branches >> as far as I am concerned. Several other distributions take care of this >> disjoint nature by splitting up the repository and having two different >> update streams. With a smaller amount of additional maintenance burden, >> we can do this as well. >> > Your claim is self-contradictory: Additional repos mean additional > maintenance burden and additional complexity. > Err, where is the contradiction? I did clear point out that there is a additional maintenance burden involved in this but if there is a necessity for faster updates, it will happen anyway and it already has elsewhere for various reasons. > Or did I read your request incorrectly and you are proposing to > reintroduce a Core+Extra's split? > You did read it incorrectly. Splitting up the update stream doesn't involve going back to core+extras at all. KDE has a additional repo already in kde-redhat.sf.net where they have first builds before they get into the official updates repo.. Accommodating such workflows within the Fedora infrastructure would allow people who want to move a newer KDE in older versions, the choice to do so more easily. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-13 Branched report: 20100315 changes
Compose started at Mon Mar 15 09:15:27 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 edje-0.9.9.050-6.fc12.i686 requires libembryo.so.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libntfs-3g.so.74.0.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgthread-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgcc_s-4.4.3-20100211.so.1 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libntfs-3g.so.74 1:libguestfs-1.0.84-2.fc13.i686 requires /usr/lib/libply-splash-core.so.2.0.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libglib-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgobject-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgio-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /usr/lib/libply-splash-core.so.2 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgmodule-2.0.so.0.2303.0 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 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) edje-0.9.9.050-6.fc12.i686 requires libembryo.so.0 edje-0.9.9.050-6.fc12.x86_64 requires libembryo.so.0()(64bit) 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libntfs-3g.so.74.0.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgthread-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgcc_s-4.4.3-20100211.so.1 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libntfs-3g.so.74 1:libguestfs-1.0.84-2.fc13.i686 requires /usr/lib/libply-splash-core.so.2.0.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libglib-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgobject-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgio-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /usr/lib/libply-splash-core.so.2 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgmodule-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libgthread-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libgio-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /usr/lib64/libply-splash-core.so.2.0.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libgmodule-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libgobject-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libglib-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /usr/lib64/libply-splash-core.so.2 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libgcc_s-4.4.3-20100211.so.1 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libntfs-3g.so.74.0.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libntfs-3g.so.74 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula >= 0:1.2 New package aduna-commons-concurrent Extensions to the Java Concurrency package New package aduna-commons-text Manipulate/transform/parse text in various ways New package libucil Library to render text and graphic overlays onto video images New package libunicap Library to access different kinds of (video) capture devices New package libunicapgtk Library to build graphical widgets for the unicap library New package python-gudev Python (PyGObject) bindings to the GUDev library Updated Packages: R-hdf5-1.6.9-7.fc13 --- * Tue Mar 02 2010 Orion Poplawski - 1.6.9-7 - Rebuild for hdf5-1.8.4.patch1 anki-0.9.9.8.6-2.fc13 - * Sun Feb 28 2010 Christian Krause - 0.9.9.8.6-2 - Add a patch to fix a crash when sys tray icon is enabled (BZ 567672) * Fri Feb 19 2010 Christian Krause - 0.9.9.8.6-1 - Update to new upstream version - Remove example files from upstream tarball due to unknown license - Updated noupdate patch anyremote-5.1.2-1.fc13 -- * Sat Mar 13 2010 Mikhail Fedotov - 5.1.2 - Some configuration files and documentation were corrected. bittorrent-4.4.0-14.fc13 * Thu Feb 25 2010 Paul Howarth 4.4.0-14 - Fix deprecation warnings by using hashlib instead of sha when possible - Update fastresume patch for additional fix bluez-4.62-1.fc13 - * Mon Mar 08 2010 Bastien Nocera 4.62-1 - Update to 4.61
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Kevin Kofler wrote: > Stephen John Smoogen wrote: >> Here is where we have a definition problem. To me, unbaked stuff is >> things that haven't had a good month of testing if its a large change >> (a couple of days if its a small one). > > If you count all the testing done on prereleases, KDE 4.4.0 actually had > much MORE than a month of testing before being pushed. Even if you count > only the stable release, it got more than 2 weeks of total testing before > the stable push. But the changes between the RCs and the final were fairly > small. > > So please don't overgeneralize claiming all the feature updates which are > getting pushed are "unbaked". Kevin, please calm down. You aren't helping yourself - and by extension, your constituents (/me waves) - by treating everything said by someone not obviously "on your side" as a personal attack. I don't see anywhere that Stephen was calling current updates "unbaked". Stephen is trying to throw some water on the fire /without/ taking sides. I can't, unfortunately, say he is succeeding; not because of his own efforts - which I find to be of very high quality - but... well, because certain parts of the fire just seem to burn hotter no matter what. So, please, take a step back, and try seeing if maybe, just maybe, your views aren't as incompatible as you think. -- Matthew Please do not quote my e-mail address unobfuscated in message bodies. -- Time to get out the marshmallows... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding two packages to comps
Hicham Haouari (hicham.haou...@gmail.com) said: > Hi Everybody, > > I want to add two packages to comps in F-13 and devel: > - ueagle-atm4-firmware to hardware-support group as default Sure. > - linux-atm to dial-up group as default What specific cases does this allow access for that we don't already cover? I don't see PPPoA there, for example, although I could be missing something. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 15.03.2010 18:15, schrieb Rahul Sundaram: > > You did read it incorrectly. Splitting up the update stream doesn't > involve going back to core+extras at all. KDE has a additional repo > already in kde-redhat.sf.net where they have first builds before they > get into the official updates repo.. Sorry, from my point of view this is not a solution for KDE. If you may take an update on KDE, this may indicate an update of Qt which cause additionally depended updates on other packages like stellarium or luma. So the main issue is to coordinate the updates of all of this packages to avoid failing applications by the end-user. Best Regards: Jochen Schmitt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iJwEAQECAAYFAkuehDAACgkQZLAIBz9lVu+/7AQAiKU/GNV9Tx610KNVWamUtuXs HtjKLTIXCY7yJ7ysOcA5lUkb2zHHqQ7MkExGh36laVi0I1fh96KUGG4khVOoaUC6 p18xWCDX3TWYFSGq9x3OmgvurF/vYXMkTuRR4VQcbbcbUaCxNE/m7/WpxYl5DdbO aOL6oWywKfU5zXXSf1U= =bcOt -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Re: Desktop app maintainers: Please check for StartupNotify=true
Hi Mary, On Mon, Mar 15, 2010 at 11:14 AM, Mary Ellen Foster wrote: > > Well, for Firefox at least, it's option 2 and has been for a while (at > least under KDE): > https://bugzilla.redhat.com/show_bug.cgi?id=445543 I guess I should take some time to fix the most important app, yes. This turned out to be a Fedora bug; we had a BuildRequires on libstartup-notification, but didn't enable it in our mozconfig. The attached patch works for me, I'll add it to the bug too. ? .build-1.9.1.8-2.fc12.log ? i386 ? xulrunner-1.9.1.8 ? xulrunner-1.9.1.8-2.fc12.src.rpm Index: xulrunner-mozconfig === RCS file: /cvs/pkgs/rpms/xulrunner/F-12/xulrunner-mozconfig,v retrieving revision 1.28 diff -u -r1.28 xulrunner-mozconfig --- xulrunner-mozconfig 21 Aug 2009 13:40:34 - 1.28 +++ xulrunner-mozconfig 15 Mar 2010 19:02:44 - @@ -29,6 +29,7 @@ ac_add_options --enable-safe-browsing ac_add_options --enable-extensions=default,python/xpcom ac_add_options --enable-libnotify +ac_add_options --enable-startup-notification export BUILD_OFFICIAL=1 export MOZILLA_OFFICIAL=1 Index: xulrunner.spec === RCS file: /cvs/pkgs/rpms/xulrunner/F-12/xulrunner.spec,v retrieving revision 1.183 diff -u -r1.183 xulrunner.spec --- xulrunner.spec 17 Feb 2010 14:30:57 - 1.183 +++ xulrunner.spec 15 Mar 2010 19:02:44 - @@ -471,6 +471,9 @@ #- %changelog +* Mon Mar 15 2010 Colin Walters +- Reenable startup notification support, closes #445543 + * Wed Feb 17 2010 Martin Stransky - 1.9.1.8-2 - Added fix for #564184 - xulrunner-devel multilib conflict -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adventurous updates?
On Mon, Mar 15, 2010 at 10:56 AM, Matthew Woehlke wrote: > Michael Schwendt wrote: >> But that high-impact bugs in some Fedora Updates have slipped >> through, because their package maintainers had been willing to take >> the risk, and that has prompted some people to try to change that >> part of Fedora. > > That's *exactly* what I am afraid of... that Fedora is going to get > turned into a distribution that is afraid to take risks. > > We have plenty of those already. We NEED a distribution willing to take > risks, because that is how progress happens. (Or at least, how it > happens at a non-glacial pace.) Managing risk does not mean running away from it. The problem with many in the conversation is an implicit assumption that people are wanting that by default. There could be multiple ways to manage risk.. its a matter of finding out if a method is a good one, a bad one, can be improved, or can be thrown away. So some people would like the quality of updates to go up, some people would like to have what they consider un-needed bureaucracy go away, and there may be ways to do both... but first people have to sit down and listen to each other versus throwing emails back and forth about how horrible someone else is. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Plan for tomorrow's (2010-03-16) FESCo meeting (note new DST meeting time)
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 19:00UTC (3pm EDT) in #fedora-meeting on irc.freenode.net. NOTE: The Meeting Time has CHANGED. See above. Followups: #351 Create a policy for updates New Business: #353 provenpackager request for walters #352 Proposal: Fesco should have a procedure for removing members of fesco. #354 Desktop Spin size change should get a feature page #346 Drop LSB package #347 tor is not compliant with Fedora guidelines #355 Let rel-eng untag embryo from F-13 because it breaks the chain and upgrade path #348 Fedora Packaging Committee items for ratification (2010-02-24): Complex Font Template fix: https://fedoraproject.org/wiki/Fix_Complex_Font_Template%28draft%29 Which files to include in python modules: https://fedoraproject.org/wiki/No_py_removal%28draft%29 - Fedora Engineering Services Tickets/Updates. https://fedorahosted.org/fedora-engineering-services/ assigned tickets / status update: #2 SIGs roundup and pinging - jds2001 #5 Fix broken dependencies - itmarjp #6 Fix packages that fail to build from source - bruno #7 spec cleanup task: fix the need for perl (etc) in scriptlets - mmcgrath #8 Document Fedora as android devel platform - stickster unassigned tickets: #4 tool idea: script to evaluate buildroot poisoning Open Floor For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's (2010-03-16) FESCo meeting (note new DST meeting time)
On Mon, 2010-03-15 at 14:14 -0600, Kevin Fenzi wrote: > #355 Let rel-eng untag embryo from F-13 because it breaks the chain > and upgrade path Does this one really have to wait for a meeting? It's a pretty straight forward case, deps are broken, it couldn't have been installed anywhere to begin with. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding two packages to comps
On Sun, 2010-03-14 at 14:31 +, Hicham Haouari wrote: > Hi Rex, > > - ueagle-atm4-firmware, is a firmware for ADSL USB Modems used by a > lot of countries in Europe and Africa; adding it to the livecd and > installation dvd will make installation easier for those people. Shouldn't it be in the kernel firmware package, then? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's (2010-03-16) FESCo meeting (note new DST meeting time)
On Mon, 15 Mar 2010 13:20:09 -0700 Jesse Keating wrote: > On Mon, 2010-03-15 at 14:14 -0600, Kevin Fenzi wrote: > > #355 Let rel-eng untag embryo from F-13 because it breaks the chain > > and upgrade path > > Does this one really have to wait for a meeting? It's a pretty > straight forward case, deps are broken, it couldn't have been > installed anywhere to begin with. oh? I'm a bit confused there...you can install the package just fine by itself. It's just if you try and install enlightment or have enlightenment's stack installed that it fails. So, most people wouldn't have it installed due to the broken dep, but you can indeed install it by itself ok. [r...@ohm ~]# yum install embryo Loaded plugins: changelog, presto, refresh-packagekit, security Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package embryo.x86_64 0:0.9.9.063-1.fc13 set to be updated --> Finished Dependency Resolution Dependencies Resolved == Package Arch Version Repository Size == Installing: embryox86_640.9.9.063-1.fc13 fedora 88 k Transaction Summary == Install 1 Package(s) Upgrade 0 Package(s) Total download size: 88 k Installed size: 199 k Is this ok [y/N]: y Downloading Packages: Setting up and reading Presto delta metadata fedora/prestodelta | 46 kB 00:00 Processing delta metadata Package(s) data still to download: 88 k embryo-0.9.9.063-1.fc13.x86_64.rpm | 88 kB 00:00 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Installing : embryo-0.9.9.063-1.fc13.x86_64 1/1 Installed: embryo.x86_64 0:0.9.9.063-1.fc13 Complete! [r...@ohm ~]# yum install enlightenment Loaded plugins: changelog, presto, refresh-packagekit, security Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package enlightenment.x86_64 0:0.16.999.050-5.fc12 set to be updated --> Processing Dependency: libefreet.so.0()(64bit) for package: enlightenment-0.16.999.050-5.fc12.x86_64 --> Processing Dependency: libecore_evas.so.0()(64bit) for package: enlightenment-0.16.999.050-5.fc12.x86_64 --> Processing Dependency: libecore.so.0()(64bit) for package: enlightenment-0.16.999.050-5.fc12.x86_64 --> Processing Dependency: libecore_x.so.0()(64bit) for package: enlightenment-0.16.999.050-5.fc12.x86_64 --> Processing Dependency: libecore_imf.so.0()(64bit) for package: enlightenment-0.16.999.050-5.fc12.x86_64 --> Processing Dependency: libecore_txt.so.0()(64bit) for package: enlightenment-0.16.999.050-5.fc12.x86_64 --> Processing Dependency: libecore_ipc.so.0()(64bit) for package: enlightenment-0.16.999.050-5.fc12.x86_64 --> Processing Dependency: libehal.so.0()(64bit) for package: enlightenment-0.16.999.050-5.fc12.x86_64 --> Processing Dependency: libecore_file.so.0()(64bit) for package: enlightenment-0.16.999.050-5.fc12.x86_64 --> Processing Dependency: libefreet_mime.so.0()(64bit) for package: enlightenment-0.16.999.050-5.fc12.x86_64 --> Processing Dependency: libedbus.so.0()(64bit) for package: enlightenment-0.16.999.050-5.fc12.x86_64 --> Processing Dependency: libecore_imf_evas.so.0()(64bit) for package: enlightenment-0.16.999.050-5.fc12.x86_64 --> Processing Dependency: libecore_job.so.0()(64bit) for package: enlightenment-0.16.999.050-5.fc12.x86_64 --> Processing Dependency: libevas.so.0()(64bit) for package: enlightenment-0.16.999.050-5.fc12.x86_64 --> Processing Dependency: libedje.so.0()(64bit) for package: enlightenment-0.16.999.050-5.fc12.x86_64 --> Processing Dependency: libecore_con.so.0()(64bit) for package: enlightenment-0.16.999.050-5.fc12.x86_64 --> Processing Dependency: libecore_fb.so.0()(64bit) for package: enlightenment-0.16.999.050-5.fc12.x86_64 --> Running transaction check ---> Package e_dbus.x86_64 0:0.5.0.050-3.fc12 set to be updated ---> Package ecore.x86_64 0:0.9.9.050-7.fc12 set to be updated ---> Package edje.x86_64 0:0.9.9.050-6.fc12 set to be updated --> Processing Dependency: libembryo.so.0()(64bit) for package: edje-0.9.9.050-6.fc12.x86_64 ---> Package efreet.x86_64 0:0.5.0.050-5.fc12 set to be updated ---> Package evas.x86_64 0:0.9.9.050-3.fc12 set to be updated --> Finished Dependency Resolution Error: Package: edje-0.9.9.050-6.fc12.x86_64 (fedora) Requires: libembryo.so.0()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest signature.asc Des
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On Sun, 2010-03-14 at 21:23 -0600, Stephen John Smoogen wrote: > > If we assumed that the people who had been registered in FAS for over > 6 months and had signed the CLA met the first two definitions, you > would need to randomly select about 3000 of them and have at least 600 > answer the poll to have (i think) a 90% confidence level in the poll. > I think the questions need to be simple yes/no ones to qualify for the > 'easiest' tests, multiple choice results require something like > multiple asking worded slightly different or some such thing. Again > this is from a class I took 20 years ago so a real mathematician, > psychologist, etc would know better. > > This unfortunately would also be a very selective set of folks, as it wouldn't include any of our pure users, who aren't contributors via FAS. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's (2010-03-16) FESCo meeting (note new DST meeting time)
On Mon, Mar 15, 2010 at 9:26 PM, Kevin Fenzi wrote: > On Mon, 15 Mar 2010 13:20:09 -0700 > Jesse Keating wrote: > >> On Mon, 2010-03-15 at 14:14 -0600, Kevin Fenzi wrote: >> > #355 Let rel-eng untag embryo from F-13 because it breaks the chain >> > and upgrade path >> >> Does this one really have to wait for a meeting? It's a pretty >> straight forward case, deps are broken, it couldn't have been >> installed anywhere to begin with. > > oh? I'm a bit confused there...you can install the package just fine by > itself. It's just if you try and install enlightment or have > enlightenment's stack installed that it fails. So, most people wouldn't > have it installed due to the broken dep, but you can indeed install it > by itself ok. That's right, you could install it by itself. It's just nobody would install it alone. It's only used with enlightenment. -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Linker weirdness: "could not read symbols: Invalid operation"
Hitting an odd error during a build that I've never seen before today, looks like something to do with recent linker changes. I maintain a side repo with an mplayer build with VA-API support, so I rebuild that quite often. If I try and build it on F13 currently, I get this when linking: /usr/bin/ld: libvo/vo_vaapi.o: undefined reference to symbol 'vaGetConfigAttributes' /usr/bin/ld: note: 'vaGetConfigAttributes' is defined in DSO /usr/lib64/libva-0.31.0.5.so.1 so try adding it to the linker command line /usr/lib64/libva-0.31.0.5.so.1: could not read symbols: Invalid operation Left out the cc command as it's *huge*, but it does include -lva . Building the same .src.rpm for F12, using mock, works fine. The libva used in both cases is the same code, built from the same .src.rpm . What's different in F13 that causes this to fail? How do I fix it? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linker weirdness: "could not read symbols: Invalid operation"
>/usr/bin/ld: libvo/vo_vaapi.o: undefined reference to symbol >'vaGetConfigAttributes' >/usr/bin/ld: note: 'vaGetConfigAttributes' is defined in DSO >/usr/lib64/libva-0.31.0.5.so.1 so try adding it to the linker command line >/usr/lib64/libva-0.31.0.5.so.1: could not read symbols: Invalid operation >What's different in F13 that causes this to fail? How do I fix it? This is due to a fix in the way ld does linking which is outlined here : https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking There's an example of how to go about fixing this here : https://fedoraproject.org/wiki/UnderstandingDSOLinkChange In your case the solution would be to add libva to the linker line. -- Roland Grunberg -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On Mon, Mar 15, 2010 at 2:27 PM, Jesse Keating wrote: > On Sun, 2010-03-14 at 21:23 -0600, Stephen John Smoogen wrote: >> >> If we assumed that the people who had been registered in FAS for over >> 6 months and had signed the CLA met the first two definitions, you >> would need to randomly select about 3000 of them and have at least 600 >> answer the poll to have (i think) a 90% confidence level in the poll. >> I think the questions need to be simple yes/no ones to qualify for the >> 'easiest' tests, multiple choice results require something like >> multiple asking worded slightly different or some such thing. Again >> this is from a class I took 20 years ago so a real mathematician, >> psychologist, etc would know better. >> >> > > This unfortunately would also be a very selective set of folks, as it > wouldn't include any of our pure users, who aren't contributors via FAS. > You are correct, a survey of them would not be possible to extend to an entire population unless the survey was larger. However one could consider it a poll survey of people who have shown an strong interest in Fedora. Survey's are in the end only good for certain things.. figuring out what kinds of groups you are attracting is something a survey can help answer. However deciding which elevator algorithm to use in the kernel.. they are not. -- Stephen J Smoogen. Ah, but a man's reach should exceed his grasp. Or what's a heaven for? -- Robert Browning -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linker weirdness: "could not read symbols: Invalid operation"
On Mon, 2010-03-15 at 17:45 -0400, Roland Grunberg wrote: > >/usr/bin/ld: libvo/vo_vaapi.o: undefined reference to symbol > >'vaGetConfigAttributes' > >/usr/bin/ld: note: 'vaGetConfigAttributes' is defined in DSO > >/usr/lib64/libva-0.31.0.5.so.1 so try adding it to the linker command line > >/usr/lib64/libva-0.31.0.5.so.1: could not read symbols: Invalid operation > > >What's different in F13 that causes this to fail? How do I fix it? > > This is due to a fix in the way ld does linking which is outlined > here : https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking > > There's an example of how to go about fixing this here : > https://fedoraproject.org/wiki/UnderstandingDSOLinkChange > > In your case the solution would be to add libva to the linker line. Um. As I said in my email, it's already *in* the linker line. That's why I say it's weird. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linker weirdness: "could not read symbols: Invalid operation"
On Mon, 2010-03-15 at 14:51 -0700, Adam Williamson wrote: > On Mon, 2010-03-15 at 17:45 -0400, Roland Grunberg wrote: > > >/usr/bin/ld: libvo/vo_vaapi.o: undefined reference to symbol > > >'vaGetConfigAttributes' > > >/usr/bin/ld: note: 'vaGetConfigAttributes' is defined in DSO > > >/usr/lib64/libva-0.31.0.5.so.1 so try adding it to the linker command line > > >/usr/lib64/libva-0.31.0.5.so.1: could not read symbols: Invalid operation > > > > >What's different in F13 that causes this to fail? How do I fix it? > > > > This is due to a fix in the way ld does linking which is outlined > > here : https://fedoraproject.org/wiki/Features/ChangeInImplicitDSOLinking > > > > There's an example of how to go about fixing this here : > > https://fedoraproject.org/wiki/UnderstandingDSOLinkChange > > > > In your case the solution would be to add libva to the linker line. > > Um. As I said in my email, it's already *in* the linker line. That's why > I say it's weird. Also, the "undefined reference to symbol" error is typical for the 'you left it out of the linker line' situation, but "could not read symbols: Invalid operation" is not, I've never seen that error before. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-App-cpanminus - New directory
Author: spot Update of /cvs/pkgs/rpms/perl-App-cpanminus In directory cvs1.fedora.phx.redhat.com:/home/fedora/spot/CVSROOT/admin/tmpcvsO20298/rpms/perl-App-cpanminus Log Message: Directory /cvs/pkgs/rpms/perl-App-cpanminus added to the repository -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-App-cpanminus/devel - New directory
Author: spot Update of /cvs/pkgs/rpms/perl-App-cpanminus/devel In directory cvs1.fedora.phx.redhat.com:/home/fedora/spot/CVSROOT/admin/tmpcvsO20298/rpms/perl-App-cpanminus/devel Log Message: Directory /cvs/pkgs/rpms/perl-App-cpanminus/devel added to the repository -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-App-cpanminus/devel .cvsignore, NONE, 1.1 Makefile, NONE, 1.1 sources, NONE, 1.1
Author: spot
Update of /cvs/pkgs/rpms/perl-App-cpanminus/devel
In directory
cvs1.fedora.phx.redhat.com:/home/fedora/spot/CVSROOT/admin/tmpcvsO20298/rpms/perl-App-cpanminus/devel
Added Files:
.cvsignore Makefile sources
Log Message:
Setup of module perl-App-cpanminus
--- NEW FILE .cvsignore ---
--- NEW FILE Makefile ---
# Makefile for source rpm: perl-App-cpanminus
# $Id: Makefile,v 1.1 2010/03/15 22:07:37 spot Exp $
NAME := perl-App-cpanminus
SPECFILE = $(firstword $(wildcard *.spec))
define find-makefile-common
for d in common ../common ../../common ; do if [ -f $$d/Makefile.common ] ;
then if [ -f $$d/CVS/Root -a -w $$d/Makefile.common ] ; then cd $$d ; cvs -Q
update ; fi ; echo "$$d/Makefile.common" ; break ; fi ; done
endef
MAKEFILE_COMMON := $(shell $(find-makefile-common))
ifeq ($(MAKEFILE_COMMON),)
# attept a checkout
define checkout-makefile-common
test -f CVS/Root && { cvs -Q -d $$(cat CVS/Root) checkout common && echo
"common/Makefile.common" ; } || { echo "ERROR: I can't figure out how to
checkout the 'common' module." ; exit -1 ; } >&2
endef
MAKEFILE_COMMON := $(shell $(checkout-makefile-common))
endif
include $(MAKEFILE_COMMON)
--- NEW FILE sources ---
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-App-cpanminus Makefile,NONE,1.1
Author: spot
Update of /cvs/pkgs/rpms/perl-App-cpanminus
In directory
cvs1.fedora.phx.redhat.com:/home/fedora/spot/CVSROOT/admin/tmpcvsO20298/rpms/perl-App-cpanminus
Added Files:
Makefile
Log Message:
Setup of module perl-App-cpanminus
--- NEW FILE Makefile ---
# Top level Makefile for module perl-App-cpanminus
all : CVS/Root common-update
@cvs update
common-update : common
@cd common && cvs update
common : CVS/Root
@cvs checkout common
CVS/Root :
@echo "ERROR: This does not look like a CVS checkout" && exit 1
clean :
@find . -type f -name *~ -exec rm -fv {} \;
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Context-Preserve/devel - New directory
Author: spot Update of /cvs/pkgs/rpms/perl-Context-Preserve/devel In directory cvs1.fedora.phx.redhat.com:/home/fedora/spot/CVSROOT/admin/tmpcvsH20439/rpms/perl-Context-Preserve/devel Log Message: Directory /cvs/pkgs/rpms/perl-Context-Preserve/devel added to the repository -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Context-Preserve - New directory
Author: spot Update of /cvs/pkgs/rpms/perl-Context-Preserve In directory cvs1.fedora.phx.redhat.com:/home/fedora/spot/CVSROOT/admin/tmpcvsH20439/rpms/perl-Context-Preserve Log Message: Directory /cvs/pkgs/rpms/perl-Context-Preserve added to the repository -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Context-Preserve/devel .cvsignore, NONE, 1.1 Makefile, NONE, 1.1 sources, NONE, 1.1
Author: spot
Update of /cvs/pkgs/rpms/perl-Context-Preserve/devel
In directory
cvs1.fedora.phx.redhat.com:/home/fedora/spot/CVSROOT/admin/tmpcvsH20439/rpms/perl-Context-Preserve/devel
Added Files:
.cvsignore Makefile sources
Log Message:
Setup of module perl-Context-Preserve
--- NEW FILE .cvsignore ---
--- NEW FILE Makefile ---
# Makefile for source rpm: perl-Context-Preserve
# $Id: Makefile,v 1.1 2010/03/15 22:07:55 spot Exp $
NAME := perl-Context-Preserve
SPECFILE = $(firstword $(wildcard *.spec))
define find-makefile-common
for d in common ../common ../../common ; do if [ -f $$d/Makefile.common ] ;
then if [ -f $$d/CVS/Root -a -w $$d/Makefile.common ] ; then cd $$d ; cvs -Q
update ; fi ; echo "$$d/Makefile.common" ; break ; fi ; done
endef
MAKEFILE_COMMON := $(shell $(find-makefile-common))
ifeq ($(MAKEFILE_COMMON),)
# attept a checkout
define checkout-makefile-common
test -f CVS/Root && { cvs -Q -d $$(cat CVS/Root) checkout common && echo
"common/Makefile.common" ; } || { echo "ERROR: I can't figure out how to
checkout the 'common' module." ; exit -1 ; } >&2
endef
MAKEFILE_COMMON := $(shell $(checkout-makefile-common))
endif
include $(MAKEFILE_COMMON)
--- NEW FILE sources ---
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Context-Preserve Makefile,NONE,1.1
Author: spot
Update of /cvs/pkgs/rpms/perl-Context-Preserve
In directory
cvs1.fedora.phx.redhat.com:/home/fedora/spot/CVSROOT/admin/tmpcvsH20439/rpms/perl-Context-Preserve
Added Files:
Makefile
Log Message:
Setup of module perl-Context-Preserve
--- NEW FILE Makefile ---
# Top level Makefile for module perl-Context-Preserve
all : CVS/Root common-update
@cvs update
common-update : common
@cd common && cvs update
common : CVS/Root
@cvs checkout common
CVS/Root :
@echo "ERROR: This does not look like a CVS checkout" && exit 1
clean :
@find . -type f -name *~ -exec rm -fv {} \;
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-CatalystX-LeakChecker - New directory
Author: spot Update of /cvs/pkgs/rpms/perl-CatalystX-LeakChecker In directory cvs1.fedora.phx.redhat.com:/home/fedora/spot/CVSROOT/admin/tmpcvsQ20688/rpms/perl-CatalystX-LeakChecker Log Message: Directory /cvs/pkgs/rpms/perl-CatalystX-LeakChecker added to the repository -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-CatalystX-LeakChecker/devel - New directory
Author: spot Update of /cvs/pkgs/rpms/perl-CatalystX-LeakChecker/devel In directory cvs1.fedora.phx.redhat.com:/home/fedora/spot/CVSROOT/admin/tmpcvsQ20688/rpms/perl-CatalystX-LeakChecker/devel Log Message: Directory /cvs/pkgs/rpms/perl-CatalystX-LeakChecker/devel added to the repository -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-CatalystX-LeakChecker Makefile,NONE,1.1
Author: spot
Update of /cvs/pkgs/rpms/perl-CatalystX-LeakChecker
In directory
cvs1.fedora.phx.redhat.com:/home/fedora/spot/CVSROOT/admin/tmpcvsQ20688/rpms/perl-CatalystX-LeakChecker
Added Files:
Makefile
Log Message:
Setup of module perl-CatalystX-LeakChecker
--- NEW FILE Makefile ---
# Top level Makefile for module perl-CatalystX-LeakChecker
all : CVS/Root common-update
@cvs update
common-update : common
@cd common && cvs update
common : CVS/Root
@cvs checkout common
CVS/Root :
@echo "ERROR: This does not look like a CVS checkout" && exit 1
clean :
@find . -type f -name *~ -exec rm -fv {} \;
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-CatalystX-LeakChecker/devel .cvsignore, NONE, 1.1 Makefile, NONE, 1.1 sources, NONE, 1.1
Author: spot
Update of /cvs/pkgs/rpms/perl-CatalystX-LeakChecker/devel
In directory
cvs1.fedora.phx.redhat.com:/home/fedora/spot/CVSROOT/admin/tmpcvsQ20688/rpms/perl-CatalystX-LeakChecker/devel
Added Files:
.cvsignore Makefile sources
Log Message:
Setup of module perl-CatalystX-LeakChecker
--- NEW FILE .cvsignore ---
--- NEW FILE Makefile ---
# Makefile for source rpm: perl-CatalystX-LeakChecker
# $Id: Makefile,v 1.1 2010/03/15 22:08:16 spot Exp $
NAME := perl-CatalystX-LeakChecker
SPECFILE = $(firstword $(wildcard *.spec))
define find-makefile-common
for d in common ../common ../../common ; do if [ -f $$d/Makefile.common ] ;
then if [ -f $$d/CVS/Root -a -w $$d/Makefile.common ] ; then cd $$d ; cvs -Q
update ; fi ; echo "$$d/Makefile.common" ; break ; fi ; done
endef
MAKEFILE_COMMON := $(shell $(find-makefile-common))
ifeq ($(MAKEFILE_COMMON),)
# attept a checkout
define checkout-makefile-common
test -f CVS/Root && { cvs -Q -d $$(cat CVS/Root) checkout common && echo
"common/Makefile.common" ; } || { echo "ERROR: I can't figure out how to
checkout the 'common' module." ; exit -1 ; } >&2
endef
MAKEFILE_COMMON := $(shell $(checkout-makefile-common))
endif
include $(MAKEFILE_COMMON)
--- NEW FILE sources ---
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Sub-Prototype - New directory
Author: spot Update of /cvs/pkgs/rpms/perl-Sub-Prototype In directory cvs1.fedora.phx.redhat.com:/home/fedora/spot/CVSROOT/admin/tmpcvsK21191/rpms/perl-Sub-Prototype Log Message: Directory /cvs/pkgs/rpms/perl-Sub-Prototype added to the repository -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Sub-Prototype/devel - New directory
Author: spot Update of /cvs/pkgs/rpms/perl-Sub-Prototype/devel In directory cvs1.fedora.phx.redhat.com:/home/fedora/spot/CVSROOT/admin/tmpcvsK21191/rpms/perl-Sub-Prototype/devel Log Message: Directory /cvs/pkgs/rpms/perl-Sub-Prototype/devel added to the repository -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Sub-Prototype/devel .cvsignore, NONE, 1.1 Makefile, NONE, 1.1 sources, NONE, 1.1
Author: spot
Update of /cvs/pkgs/rpms/perl-Sub-Prototype/devel
In directory
cvs1.fedora.phx.redhat.com:/home/fedora/spot/CVSROOT/admin/tmpcvsK21191/rpms/perl-Sub-Prototype/devel
Added Files:
.cvsignore Makefile sources
Log Message:
Setup of module perl-Sub-Prototype
--- NEW FILE .cvsignore ---
--- NEW FILE Makefile ---
# Makefile for source rpm: perl-Sub-Prototype
# $Id: Makefile,v 1.1 2010/03/15 22:09:12 spot Exp $
NAME := perl-Sub-Prototype
SPECFILE = $(firstword $(wildcard *.spec))
define find-makefile-common
for d in common ../common ../../common ; do if [ -f $$d/Makefile.common ] ;
then if [ -f $$d/CVS/Root -a -w $$d/Makefile.common ] ; then cd $$d ; cvs -Q
update ; fi ; echo "$$d/Makefile.common" ; break ; fi ; done
endef
MAKEFILE_COMMON := $(shell $(find-makefile-common))
ifeq ($(MAKEFILE_COMMON),)
# attept a checkout
define checkout-makefile-common
test -f CVS/Root && { cvs -Q -d $$(cat CVS/Root) checkout common && echo
"common/Makefile.common" ; } || { echo "ERROR: I can't figure out how to
checkout the 'common' module." ; exit -1 ; } >&2
endef
MAKEFILE_COMMON := $(shell $(checkout-makefile-common))
endif
include $(MAKEFILE_COMMON)
--- NEW FILE sources ---
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Sub-Prototype Makefile,NONE,1.1
Author: spot
Update of /cvs/pkgs/rpms/perl-Sub-Prototype
In directory
cvs1.fedora.phx.redhat.com:/home/fedora/spot/CVSROOT/admin/tmpcvsK21191/rpms/perl-Sub-Prototype
Added Files:
Makefile
Log Message:
Setup of module perl-Sub-Prototype
--- NEW FILE Makefile ---
# Top level Makefile for module perl-Sub-Prototype
all : CVS/Root common-update
@cvs update
common-update : common
@cd common && cvs update
common : CVS/Root
@cvs checkout common
CVS/Root :
@echo "ERROR: This does not look like a CVS checkout" && exit 1
clean :
@find . -type f -name *~ -exec rm -fv {} \;
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Devel-Caller-IgnoreNamespaces - New directory
Author: spot Update of /cvs/pkgs/rpms/perl-Devel-Caller-IgnoreNamespaces In directory cvs1.fedora.phx.redhat.com:/home/fedora/spot/CVSROOT/admin/tmpcvsP21408/rpms/perl-Devel-Caller-IgnoreNamespaces Log Message: Directory /cvs/pkgs/rpms/perl-Devel-Caller-IgnoreNamespaces added to the repository -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Devel-Caller-IgnoreNamespaces/devel - New directory
Author: spot Update of /cvs/pkgs/rpms/perl-Devel-Caller-IgnoreNamespaces/devel In directory cvs1.fedora.phx.redhat.com:/home/fedora/spot/CVSROOT/admin/tmpcvsP21408/rpms/perl-Devel-Caller-IgnoreNamespaces/devel Log Message: Directory /cvs/pkgs/rpms/perl-Devel-Caller-IgnoreNamespaces/devel added to the repository -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Devel-Caller-IgnoreNamespaces/devel .cvsignore, NONE, 1.1 Makefile, NONE, 1.1 sources, NONE, 1.1
Author: spot
Update of /cvs/pkgs/rpms/perl-Devel-Caller-IgnoreNamespaces/devel
In directory
cvs1.fedora.phx.redhat.com:/home/fedora/spot/CVSROOT/admin/tmpcvsP21408/rpms/perl-Devel-Caller-IgnoreNamespaces/devel
Added Files:
.cvsignore Makefile sources
Log Message:
Setup of module perl-Devel-Caller-IgnoreNamespaces
--- NEW FILE .cvsignore ---
--- NEW FILE Makefile ---
# Makefile for source rpm: perl-Devel-Caller-IgnoreNamespaces
# $Id: Makefile,v 1.1 2010/03/15 22:09:32 spot Exp $
NAME := perl-Devel-Caller-IgnoreNamespaces
SPECFILE = $(firstword $(wildcard *.spec))
define find-makefile-common
for d in common ../common ../../common ; do if [ -f $$d/Makefile.common ] ;
then if [ -f $$d/CVS/Root -a -w $$d/Makefile.common ] ; then cd $$d ; cvs -Q
update ; fi ; echo "$$d/Makefile.common" ; break ; fi ; done
endef
MAKEFILE_COMMON := $(shell $(find-makefile-common))
ifeq ($(MAKEFILE_COMMON),)
# attept a checkout
define checkout-makefile-common
test -f CVS/Root && { cvs -Q -d $$(cat CVS/Root) checkout common && echo
"common/Makefile.common" ; } || { echo "ERROR: I can't figure out how to
checkout the 'common' module." ; exit -1 ; } >&2
endef
MAKEFILE_COMMON := $(shell $(checkout-makefile-common))
endif
include $(MAKEFILE_COMMON)
--- NEW FILE sources ---
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rpms/perl-Devel-Caller-IgnoreNamespaces Makefile,NONE,1.1
Author: spot
Update of /cvs/pkgs/rpms/perl-Devel-Caller-IgnoreNamespaces
In directory
cvs1.fedora.phx.redhat.com:/home/fedora/spot/CVSROOT/admin/tmpcvsP21408/rpms/perl-Devel-Caller-IgnoreNamespaces
Added Files:
Makefile
Log Message:
Setup of module perl-Devel-Caller-IgnoreNamespaces
--- NEW FILE Makefile ---
# Top level Makefile for module perl-Devel-Caller-IgnoreNamespaces
all : CVS/Root common-update
@cvs update
common-update : common
@cd common && cvs update
common : CVS/Root
@cvs checkout common
CVS/Root :
@echo "ERROR: This does not look like a CVS checkout" && exit 1
clean :
@find . -type f -name *~ -exec rm -fv {} \;
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Linker weirdness: "could not read symbols: Invalid operation"
> "could not read symbols: Invalid operation" Could "Invalid operation" be an error message that corresponds to an error from a system call? Apply 'strace' to the link step to see what happens shortly before the write() to stderr. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linker weirdness: "could not read symbols: Invalid operation"
> Also, the "undefined reference to symbol" error is typical for the 'you > left it out of the linker line' situation, but "could not read symbols: > Invalid operation" is not, I've never seen that error before. This and several other odd-looking things are "normal" cascade errors from an undefined symbol in various circumstances. If there are other error messages first, don't worry about the incomprehensible ones until you've resolved the earlier ones. > Um. As I said in my email, it's already *in* the linker line. That's why > I say it's weird. Show the linking command line in question. (As with all requests for help, showing the complete command line and all error messages in the very first report is always the best policy.) It's possible to have this problem by having the libraries in the wrong order relative to each other or to .o files that refer to them. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linker weirdness: "could not read symbols: Invalid operation"
On Mon, 2010-03-15 at 15:48 -0700, John Reiser wrote: > > "could not read symbols: Invalid operation" > > Could "Invalid operation" be an error message that corresponds to > an error from a system call? Apply 'strace' to the link step > to see what happens shortly before the write() to stderr. Huh. That's odd. When I run the exact command that was run during the compile (copy/paste), it succeeds. Makes doing the above a bit hard :) Gonna run the build through mock and see what happens... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linker weirdness: "could not read symbols: Invalid operation"
On Mon, 2010-03-15 at 16:22 -0700, Roland McGrath wrote: > > Also, the "undefined reference to symbol" error is typical for the 'you > > left it out of the linker line' situation, but "could not read symbols: > > Invalid operation" is not, I've never seen that error before. > > This and several other odd-looking things are "normal" cascade errors from > an undefined symbol in various circumstances. If there are other error > messages first, don't worry about the incomprehensible ones until you've > resolved the earlier ones. I understand that principle, however, I've hit this situation literally dozens and dozens of times (I used to package for Mandriva, which made a very similar linker migration several releases ago) and have seen 'undefined reference to symbol' messages always, but have never seen the 'could not read symbols' error before. Which is why I felt it was unusual. > > Um. As I said in my email, it's already *in* the linker line. That's why > > I say it's weird. > > Show the linking command line in question. (As with all requests for help, > showing the complete command line and all error messages in the very first > report is always the best policy.) Knock yourself out: http://fpaste.org/FnFc/ as I replied to John, though, oddly enough when I re-ran the command manually, it succeeded. Trying to see if it builds through mock now. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linker weirdness: "could not read symbols: Invalid operation"
On Mon, 2010-03-15 at 17:27 -0700, Adam Williamson wrote: > On Mon, 2010-03-15 at 15:48 -0700, John Reiser wrote: > > > "could not read symbols: Invalid operation" > > > > Could "Invalid operation" be an error message that corresponds to > > an error from a system call? Apply 'strace' to the link step > > to see what happens shortly before the write() to stderr. > > Huh. That's odd. When I run the exact command that was run during the > compile (copy/paste), it succeeds. Makes doing the above a bit hard :) > > Gonna run the build through mock and see what happens... Guh. Same. The build fails, but if I go into the appropriate directory in the mock buildroot and run the command, it succeeds. I suppose the build process must be setting some kind of problematic env var or something along those lines...that doesn't show up in the command...jeez. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linker weirdness: "could not read symbols: Invalid operation"
On Mon, Mar 15, 2010 at 05:27:55PM -0700, Adam Williamson wrote: > On Mon, 2010-03-15 at 15:48 -0700, John Reiser wrote: > > > "could not read symbols: Invalid operation" > > > > Could "Invalid operation" be an error message that corresponds to > > an error from a system call? Apply 'strace' to the link step > > to see what happens shortly before the write() to stderr. > > Huh. That's odd. When I run the exact command that was run during the > compile (copy/paste), it succeeds. Makes doing the above a bit hard :) > > Gonna run the build through mock and see what happens... That sounds like a SELinux policy issue. Are you getting any AVCs? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linker weirdness: "could not read symbols: Invalid operation"
> Knock yourself out: > > http://fpaste.org/FnFc/ > > as I replied to John, though, oddly enough when I re-ran the command > manually, it succeeded. Trying to see if it builds through mock now. Are you sure that's the right command? The ld error mentions libvo/vo_vaapi.o, but that file name does not appear in the command line. Also, try adding -v -Wl,-t,-y,vaGetConfigAttributes to the cc command--but of course that's really only useful when you're modifying a command line that is verified to reproduce the error. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning qpxtool
Hi, I am going to orphan qpxtool (http://qpxtool.sourceforge.net/) for various reasons: 1) I have not used it for a long time and neither do use the hardware that supports it (it is collecting dust) 2) I lost interests in optical media in general (and as such I don't have much use for it) 3) There is a new upstream version that I have not updated to, due to lack of time. 4) I was working on a kernel patch that should make it work without consolhelper / root privileges but had to stop that for time issues (well the code is in the kernel just the user space interface commented out due to some interaction issues with MDT devices). So in other words it needs more love, so I am willing to pass it on to someone else ;) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linker weirdness: "could not read symbols: Invalid operation"
On Mon, 2010-03-15 at 21:05 -0400, i.g...@comcast.net wrote: > On Mon, Mar 15, 2010 at 05:27:55PM -0700, Adam Williamson wrote: > > On Mon, 2010-03-15 at 15:48 -0700, John Reiser wrote: > > > > "could not read symbols: Invalid operation" > > > > > > Could "Invalid operation" be an error message that corresponds to > > > an error from a system call? Apply 'strace' to the link step > > > to see what happens shortly before the write() to stderr. > > > > Huh. That's odd. When I run the exact command that was run during the > > compile (copy/paste), it succeeds. Makes doing the above a bit hard :) > > > > Gonna run the build through mock and see what happens... > > That sounds like a SELinux policy issue. Are you getting any AVCs? Nope, nothing pops up. I'll try it with permissive, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linker weirdness: "could not read symbols: Invalid operation"
On Mon, 2010-03-15 at 18:31 -0700, Roland McGrath wrote: > > Knock yourself out: > > > > http://fpaste.org/FnFc/ > > > > as I replied to John, though, oddly enough when I re-ran the command > > manually, it succeeded. Trying to see if it builds through mock now. > > Are you sure that's the right command? The ld error mentions > libvo/vo_vaapi.o, but that file name does not appear in the command line. Erf. You may be onto something there. It's the command that comes right before the error, but of course it's a parallel build. I'll check. > Also, try adding -v -Wl,-t,-y,vaGetConfigAttributes to the cc command--but > of course that's really only useful when you're modifying a command line > that is verified to reproduce the error. Will do, thanks. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linker weirdness: "could not read symbols: Invalid operation"
On Mon, 2010-03-15 at 19:24 -0700, Adam Williamson wrote: > On Mon, 2010-03-15 at 18:31 -0700, Roland McGrath wrote: > > > Knock yourself out: > > > > > > http://fpaste.org/FnFc/ > > > > > > as I replied to John, though, oddly enough when I re-ran the command > > > manually, it succeeded. Trying to see if it builds through mock now. > > > > Are you sure that's the right command? The ld error mentions > > libvo/vo_vaapi.o, but that file name does not appear in the command line. > > Erf. You may be onto something there. It's the command that comes right > before the error, but of course it's a parallel build. I'll check. Gack, well I feel dumb - I just forgot it was a parallel build and it might actually be an error from a different command. Doing the build without -j shows it's a different command failing, that one has -lva-x11 and -lva-glx but not -lva . With all three, the command succeeds. D'oh! Thanks for the reminder. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Linker weirdness: "could not read symbols: Invalid operation"
>>/usr/lib64/libva-0.31.0.5.so.1: could not read symbols: Invalid operation > It's a different command failing, that one has -lva-x11 > and -lva-glx but not -lva . With all three, the command succeeds. D'oh! Please remember to file a bug report against binutils. You've identified a reproducible error in /usr/bin/ld: "could not read symbols: Invalid operation" that may well confound someone else soon. Yes, that error may occur during what already is "error recovery", but such cascaded errors often reveal significant holes in application logic. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Bugzappers Meeting Agenda for 2010-03-16
Event: Fedora Bug Triage Meeting Date: 2010-03-16 Time: 15:00 UTC Location: #fedora-meeting on irc.freenode.net ** NOTE ** : Many places have gone through daylight savings time change this week: if your clock changed over the weekend, since the meeting is set according to UTC, the meeting time will have changed for you. It will be one hour later than last week. For instance, it's now 11am Eastern time and 8am Pacific time. Additions or corrections to the agenda? Reply to this email. = Agenda = * follow ups from last meeting * your item here! (let us know before the meeting) * open floor Nothing much on the agenda this week, but I'll be there in case anyone has topics to bring up. Please do come out for the meeting - it'd be great to see more faces, and we don't bite, we promise! It's a great opportunity to raise any issues you've come across while bugzapping, or ask any questions you might have. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
There is one "good" update of gstreamer with include gstreamer-bad-free. And it has file conflict with gstreamer-bad of rpm-fusion and with gstreamer-good It seem to me that fedora needs a stable update policy. Go ahead Jesse Oscar Bacho P.D. I'm a user -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Desktop app maintainers: Please check for StartupNotify=true
Could you help me to fix qtiplot? After I add StartupNotify=true to qtiplot.desktop, it times out instead of disappearing when the app window comes up under gnome2. Regards, Chen Lei On 2010-03-15 23:07:02，"Colin Walters" wrote： >On Mon, Mar 15, 2010 at 10:44 AM, Chen Lei wrote: >> Should we also add StartupWMClass=someting if StartupNotify=true doesn't >> work? > >You're going to need to elaborate on "doesn't work". > >* You don't see a "Starting..." notification in the tasklist in GNOME 2? >* You do, but it times out instead of disappearing when the app window comes >up? >* Something else? >-- >devel mailing list >devel@lists.fedoraproject.org >https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
2010/3/16 Oscar Bacho > There is one "good" update of gstreamer with include gstreamer-bad-free. > > And it has file conflict with gstreamer-bad of rpm-fusion and with > gstreamer-good > > It seem to me that fedora needs a stable update policy. > > > Go ahead Jesse > > > Oscar Bacho > > P.D. I'm a user > I'm on "stable F12" -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On 03/16/2010 11:54 AM, Oscar Bacho wrote: > > > 2010/3/16 Oscar Bacho mailto:ob.sys...@gmail.com>> > > There is one "good" update of gstreamer with include > gstreamer-bad-free. > > And it has file conflict with gstreamer-bad of rpm-fusion and with > gstreamer-good > > It seem to me that fedora needs a stable update policy. > > > Go ahead Jesse > > > Oscar Bacho > > P.D. I'm a user > > > I'm on "stable F12" Updates policy won't necessarily help in this case. AutoQA might but then cross repo coordination is at times tricky esp with much less people taking care of administration of third party repos. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Conflicts in latest update
hey, Trying a "yum update" gives me this. Broken update? Transaction Check Error: file /usr/lib64/gstreamer-0.10/libgstshapewipe.so from install of gstreamer-plugins-good-0.10.21-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/bin/gst-camera from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/bin/gst-camera-perf from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstadpcmdec.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstaiff.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstalsaspdif.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstapexsink.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstassrender.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstbayer.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstbz2.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstcamerabin.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstcdaudio.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstcdxaparse.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstcelt.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstdc1394.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstdccp.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstdebugutilsbad.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstdirac.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstdvb.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstfestival.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstfreeze.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstfrei0r.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstgsm.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgsth264parse.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgsthdvparse.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstid3tag.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-
