Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Thu, Sep 30, 2010 at 7:25 AM, Orcan Ogetbil wrote: It shouldn't be. Never be afraid of learning, even in the tightest of situations. It is good for your brain. It helps with analytical thinking. Once constant learning becomes part of your life, you really don't get bothered with UI changes. Promoting not learning will drive the community lazy. I think the educational system all over the world forces people to acknowledge learning as burden. This is not good for humanity. I don't believe that Fedora should follow this road of lazyness. I don't know if you are serious but it is not a question of lazyness. Users don't want to be disrupted to what they are used to, just because they did a few updates. New release can introduce major changes and users will be more tolerant of that. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Need proventester karma for firstboot-1.113-4.fc14 (was: Re: bodhi v0.7.9 deployed)
Adam Williamson wrote: Again, you're extrapolating way too far from a single problem case. The problem is simply that we have the xorg-x11-drivers metapackage which requires every single X driver and is in the critpath. There's various ways we could adjust this so it's no longer the case. It's hardly something that renders an entire policy invalid. Another example for how the critical path policy breaks things: https://admin.fedoraproject.org/updates/firstboot-1.113-4.fc14 This update adds support for xfwm4 and openbox to the firstboot code. Updates for those 2 window managers: https://admin.fedoraproject.org/updates/xfwm4-4.6.2-2.fc14 https://admin.fedoraproject.org/updates/openbox-3.4.11.2-4.fc14 which add the virtual firstboot(windowmanager) Provides have already been pushed to stable! So now we have 2 WMs satisfying firstboot's dependencies, but not actually supported by its code. The result: the Xfce and LXDE spins will be outright BROKEN. (And it's not my fault, I only did the firstboot build and update requests, the other 2 packages were pushed by cwickert.) I CANNOT push the firstboot update which UNBREAKS those 2 spins because of the update policy. So instead of preventing breakage, the policy CAUSES breakage! How can it fail more spectacularly for you to finally realize it's a failure? To all proventesters: please +1 that update, EVEN IF YOU HAVEN'T TESTED IT, we need to get out of this impasse! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review request please (required for PackageKit)
Could someone please review this package please: https://bugzilla.redhat.com/show_bug.cgi?id=631763 I need it as a dependency in the next version of PackageKit. I can bribe with beer if required. Thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review request please (required for PackageKit)
On Fri, 1 Oct 2010 12:47:50 +0100 Richard Hughes wrote: Could someone please review this package please: https://bugzilla.redhat.com/show_bug.cgi?id=631763 I need it as a dependency in the next version of PackageKit. I can bribe with beer if required. Thanks. I've taken it for review. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Fri, Oct 1, 2010 at 6:01 AM, Rahul Sundaram methe...@gmail.com wrote: On Thu, Sep 30, 2010 at 7:25 AM, Orcan Ogetbil wrote: It shouldn't be. Never be afraid of learning, even in the tightest of situations. It is good for your brain. It helps with analytical thinking. Once constant learning becomes part of your life, you really don't get bothered with UI changes. Promoting not learning will drive the community lazy. I think the educational system all over the world forces people to acknowledge learning as burden. This is not good for humanity. I don't believe that Fedora should follow this road of lazyness. I don't know if you are serious but it is not a question of lazyness. Users don't want to be disrupted to what they are used to, just because they did a few updates. New release can introduce major changes and users will be more tolerant of that. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel The user has to tolerate some change. We can't cater to people who never upgrade which seems to be what is taking place. Especially with the fact that our end of life happens sooner, users must already expect a constant stream of updates. If they want more stability they should be using RHEL, CentOS or Scientific Linux, Debian Stable, Ubuntu LTS which do put the focus on non disruptiveness. Each release of KDE comes with bug fixes, security fixes and new features. Plus combine the fact that KDE right now is evolving at a rapid rate thanks to all of the new developers that the 4.x series has attracted. Not having the latest makes it difficult for a KDE developer to test their stuff and make sure it keeps working with the latest KDE. Fedora isn't just a home to Gnome development, which as a framework never seems to change so they won't have the same opinion as the KDE people. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need proventester karma for firstboot-1.113-4.fc14 (was: Re: bodhi v0.7.9 deployed)
On Fri, Oct 01, 2010 at 12:36:13PM +0200, Kevin Kofler wrote: I CANNOT push the firstboot update which UNBREAKS those 2 spins because of the update policy. So instead of preventing breakage, the policy CAUSES breakage! How can it fail more spectacularly for you to finally realize it's a failure? Some packages were pushed to stable before they should have been, therefore we need to make it easier to push packages to stable? -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101001 changes
Compose started at Fri Oct 1 08:15:23 UTC 2010 Broken deps for x86_64 -- almanah-0.7.3-3.fc14.x86_64 requires libedataserverui-1.2.so.10()(64bit) antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 calibre-0.7.20-2.fc15.x86_64 requires libpoppler.so.7()(64bit) clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) 0:1.3.0 clutter-gst-devel-1.2.0-1.fc15.x86_64 requires pkgconfig(clutter-1.0) 0:1.3.0 evince-libs-2.32.0-1.fc15.i686 requires libpoppler.so.7 evince-libs-2.32.0-1.fc15.i686 requires libpoppler-glib.so.5 evince-libs-2.32.0-1.fc15.x86_64 requires libpoppler-glib.so.5()(64bit) evince-libs-2.32.0-1.fc15.x86_64 requires libpoppler.so.7()(64bit) gambas2-gb-pdf-2.21.0-3.fc15.x86_64 requires libpoppler.so.7()(64bit) 2:gimp-2.6.10-5.fc15.x86_64 requires libpoppler.so.7()(64bit) 2:gimp-2.6.10-5.fc15.x86_64 requires libpoppler-glib.so.5()(64bit) gloobus-preview-0.4.1-7.fc14.x86_64 requires libpoppler.so.7()(64bit) gloobus-preview-0.4.1-7.fc14.x86_64 requires libpoppler-glib.so.5()(64bit) 3:gnome-commander-1.2.8.8-2.fc14.x86_64 requires libpoppler.so.7()(64bit) 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-python2-brasero-2.31.1-7.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-brasero-2.31.1-7.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-totem-2.31.1-7.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) inkscape-0.48.0-4.fc15.x86_64 requires libpoppler.so.7()(64bit) inkscape-view-0.48.0-4.fc15.x86_64 requires libpoppler.so.7()(64bit) libextractor-plugins-pdf-0.6.2-1500.fc15.x86_64 requires libpoppler.so.7()(64bit) mail-notification-evolution-plugin-5.4-22.fc14.x86_64 requires libcamel-1.2.so.18()(64bit) mail-notification-evolution-plugin-5.4-22.fc14.x86_64 requires libcamel-provider-1.2.so.18()(64bit) meego-panel-devices-0.2.4-2.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) meego-panel-zones-0.2.0-0.1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires mingw32(libpng-3.dll) moblin-app-installer-0.4.0-0.9.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) moblin-panel-status-0.1.21-5.fc14.x86_64 requires libsocialweb-client.so.1()(64bit) moblin-panel-status-0.1.21-5.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) moblin-panel-status-0.1.21-5.fc14.x86_64 requires libchamplain-0.6.so.0()(64bit) 1:openoffice.org-pdfimport-3.3.0-9.1.fc15.x86_64 requires libpoppler.so.7()(64bit) pdf2djvu-0.7.3-4.fc14.x86_64 requires libpoppler.so.7()(64bit) pypoppler-0.12.1-4.fc14.x86_64 requires libpoppler.so.7()(64bit) pypoppler-0.12.1-4.fc14.x86_64 requires libpoppler-glib.so.5()(64bit) qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) referencer-1.1.6-6.fc15.x86_64 requires libpoppler.so.7()(64bit) referencer-1.1.6-6.fc15.x86_64 requires libpoppler-glib.so.5()(64bit) ruby-RMagick-2.13.1-4.fc15.1.x86_64 requires ImageMagick = 0:6.6.4.1 ruby-poppler-0.19.4-3.fc14.1.x86_64 requires libpoppler.so.7()(64bit) ruby-poppler-0.19.4-3.fc14.1.x86_64 requires libpoppler-glib.so.5()(64bit) spacewalk-certs-tools-1.1.1-2.1.fc15.noarch requires spacewalk-backend-libs = 0:0.8.28 totem-2.90.5-5.fc15.i686 requires libpeasui-1.0.so.0 totem-2.90.5-5.fc15.x86_64 requires libpeasui-1.0.so.0()(64bit) tracker-0.8.17-2.fc15.i686 requires libpoppler.so.7 tracker-0.8.17-2.fc15.i686 requires libpoppler-glib.so.5 tracker-0.8.17-2.fc15.x86_64 requires libpoppler-glib.so.5()(64bit) tracker-0.8.17-2.fc15.x86_64 requires libpoppler.so.7()(64bit) xournal-0.4.5-6.fc14.x86_64 requires libpoppler.so.7()(64bit) xournal-0.4.5-6.fc14.x86_64 requires libpoppler-glib.so.5()(64bit) zathura-0.0.8.1-6.fc15.x86_64 requires libpoppler.so.7()(64bit) zathura-0.0.8.1-6.fc15.x86_64 requires libpoppler-glib.so.5()(64bit) Broken deps for i386 -- almanah-0.7.3-3.fc14.i686 requires libedataserverui-1.2.so.10 antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 calibre-0.7.20-2.fc15.i686 requires libpoppler.so.7 clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0)
Firewall settings unworkable
There are several protocols used for discovery of network services that currently cannot be made to work on Fedora simply due to the restrictive firewall we use by default. For example, a broadcast SNMP query to discover network printers is sent as a UDP packet from an unprivileged local port to SNMP port of the broadcast address. Network printers respond by sending a UDP packet in response, from the SNMP port back to the local unprivileged port. The default firewall drops these packets. However, there is no canned firewall setting to allow these packets in. No checkbox or on/off switch will do it except Disable Firewall. In system-config-printer I try to get it to modify the firewall to allow in the various network query responses that we expect, but I find it cannot be done for SNMP or NetBIOS (which works in a similar way). There is an open bug against the kernel for general broadcast query response tracking: https://bugzilla.redhat.com/show_bug.cgi?id=538675 In the mean time, I'm left wondering whether I ought to teach system-config-printer how to temporarily insert a rule to allow in all UDP packets from source port SNMP and with destination port 1024... Until then people will end up just turning off their firewalls altogether in order to get things to work. Tim. */ 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: Firewall settings unworkable
On Fri, Oct 01, 2010 at 02:00:46PM +0100, Tim Waugh wrote: There are several protocols used for discovery of network services that currently cannot be made to work on Fedora simply due to the restrictive firewall we use by default. For example, a broadcast SNMP query to discover network printers is sent as a UDP packet from an unprivileged local port to SNMP port of the broadcast address. Network printers respond by sending a UDP packet in response, from the SNMP port back to the local unprivileged port. ZeroConf discovery (port 5353) is denied by default also :( -- Tomasz TorczTo co nierealne -- tutaj jest normalne. xmpp: zdzich...@chrome.pl Ziomale na życie mają tu patenty specjalne. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review request please (required for PackageKit)
On 1 October 2010 13:24, Michal Schmidt mschm...@redhat.com wrote: I've taken it for review. Thanks dude. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Fri, Oct 1, 2010 at 6:05 PM, Brandon Lozza wrote: The user has to tolerate some change. We can't cater to people who never upgrade which seems to be what is taking place. Especially with the fact that our end of life happens sooner, users must already expect a constant stream of updates. If they want more stability they should be using RHEL, CentOS or Scientific Linux, Debian Stable, Ubuntu LTS which do put the focus on non disruptiveness. People who don't update are not doing so precisely because there was too much disruption. Mocking them as lazy is just dismissing valid concerns probably because those who do so have never worked on a large scale deployment on the client side. We will have to have to cut down on that post release. Obviously cutting it off entirely is not possible but updates shouldn't change the behaviour of software to the extend that the users feel alienated. CentOS is too old for desktops and certainly doesn't support any recent hardware. So it is not a option for a lot of users. The other end being Rawhide. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Data-Visitor/el6/master] (7 commits) ...Update to latest version prior to RHEL6 GA
Summary of changes: 7c65fc2... Fix typo that causes a failure to update the common directo (*) 4c2c63f... - rebuild against perl 5.10.1 (*) c2d5831... - update to latest upstream version - BR perl(Moose), not p (*) 9a5da88... - Mass rebuild with perl-5.12.0 (*) ab46fbc... - update (*) ac4c26a... dist-git conversion (*) ce13907... Update to latest version prior to RHEL6 GA (*) This commit already existed in another branch; no separate mail sent -- 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: Firewall settings unworkable
The following works for UDP too: -A INCOMING -m state --state RELATED,ESTABLISHED -j ACCEPT Leastways, I can do AFS through my firewall with it. David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Data-Visitor/el6/master: 7/7] Update to latest version prior to RHEL6 GA
commit ce1390740aa75fbc7ac9dfd08966a52757f6d112 Merge: 30e2103 ac4c26a Author: Mark Chappell trem...@fedoraproject.org Date: Fri Oct 1 16:07:35 2010 +0200 Update to latest version prior to RHEL6 GA .gitignore |2 +- perl-Data-Visitor.spec | 24 +--- sources|2 +- 3 files changed, 19 insertions(+), 9 deletions(-) --- -- 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: Firewall settings unworkable
On Fri, 2010-10-01 at 15:23 +0200, Tomasz Torcz wrote: ZeroConf discovery (port 5353) is denied by default also :( But that can be enabled with a single checkbox (Multicast DNS (mDNS)), and that can also be done programmatically using system-config-firewall's D-Bus interface, such as it is. In fact, system-config-printer does just that. Tim. */ 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: Firewall settings unworkable
On Fri, 2010-10-01 at 15:07 +0100, David Howells wrote: The following works for UDP too: -A INCOMING -m state --state RELATED,ESTABLISHED -j ACCEPT Leastways, I can do AFS through my firewall with it. Does that work for unicast replies to broadcast queries though? e.g. IP 10.1.1.8.33353 10.1.1.255.snmp: GetRequest(28) .1.3.6.1.2.1.25.3.2.1.2.1 IP 10.1.1.7.snmp 10.1.1.8.33353: GetResponse(37) .1.3.6.1.2.1.25.3.2.1.2.1=.1.3.6.1.2.1.25.3.1.5 Tim. */ 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: Need proventester karma for firstboot-1.113-4.fc14 (was: Re: bodhi v0.7.9 deployed)
On Fri, 2010-10-01 at 12:36 +0200, Kevin Kofler wrote: Adam Williamson wrote: Again, you're extrapolating way too far from a single problem case. The problem is simply that we have the xorg-x11-drivers metapackage which requires every single X driver and is in the critpath. There's various ways we could adjust this so it's no longer the case. It's hardly something that renders an entire policy invalid. Another example for how the critical path policy breaks things: https://admin.fedoraproject.org/updates/firstboot-1.113-4.fc14 This update adds support for xfwm4 and openbox to the firstboot code. Updates for those 2 window managers: https://admin.fedoraproject.org/updates/xfwm4-4.6.2-2.fc14 https://admin.fedoraproject.org/updates/openbox-3.4.11.2-4.fc14 which add the virtual firstboot(windowmanager) Provides have already been pushed to stable! So now we have 2 WMs satisfying firstboot's dependencies, but not actually supported by its code. The result: the Xfce and LXDE spins will be outright BROKEN. (And it's not my fault, I only did the firstboot build and update requests, the other 2 packages were pushed by cwickert.) I CANNOT push the firstboot update which UNBREAKS those 2 spins because of the update policy. So instead of preventing breakage, the policy CAUSES breakage! How can it fail more spectacularly for you to finally realize it's a failure? To all proventesters: please +1 that update, EVEN IF YOU HAVEN'T TESTED IT, we need to get out of this impasse! This is a bad idea. I don't advocate supplying positive karma feedback without following basic test procedures to verify the update is sane. I understand that sometimes things are out of ones' control, but lowering quality standards to resolve this issue isn't a precedent I support. In retrospect, if the three updates you list were in fact interdependent, should they have been submitted and tested as a group to avoid the current situation? Thanks, James 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: Firewall settings unworkable
On Fri, 2010-10-01 at 15:19 +0100, David Howells wrote: Good question; I don't know. netfil...@vger.kernel.org is probably the place to ask. I did ask about this issue on netfilter, last year (look for SNMP conntrack module a la netbios_ns, Dec 4th 2009). That's where the idea for a general broadcast query response tracking module came from. Tim. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Need new package reviews for Banshee iPhone support
gudev-sharp: https://bugzilla.redhat.com/show_bug.cgi?id=639346 gkeyfile-sharp: https://bugzilla.redhat.com/show_bug.cgi?id=639348 gio-sharp: https://bugzilla.redhat.com/show_bug.cgi?id=639350 gtk-sharp-beans: https://bugzilla.redhat.com/show_bug.cgi?id=639351 Thanks! Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
openjpeg non-responsive maintainer
It's been since July, https://bugzilla.redhat.com/show_bug.cgi?id=492218 ( and recently, https://bugzilla.redhat.com/show_bug.cgi?id=579548#c12 ) and previously, https://www.redhat.com/archives/fedora-devel-list/2009-September/msg01223.html where Callum suggested dropping his maintainer duties (but seemed to not have followed through). Can any FESCo member ACK this? -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-14 Branched report: 20101001 changes
Compose started at Fri Oct 1 13:15:21 UTC 2010 Broken deps for x86_64 -- almanah-0.7.3-3.fc14.x86_64 requires libedataserverui-1.2.so.10()(64bit) antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 evolution-couchdb-0.4.92-1.fc14.x86_64 requires libedata-book-1.2.so.2()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-1.2.so.17()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-provider-1.2.so.17()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgtkjava-2.8.so frysk-devel-0.4-26.fc14.i386 requires libglibjava-0.2.so frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.x86_64 requires libglibjava-0.2.so()(64bit) frysk-devel-0.4-26.fc14.x86_64 requires libgtkjava-2.8.so()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libglibjava-0.2.so()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgtkjava-2.8.so()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples jana-0.4.5-0.7.20100520gitacd72f2.fc14.i686 requires libedataserverui-1.2.so.10 jana-0.4.5-0.7.20100520gitacd72f2.fc14.x86_64 requires libedataserverui-1.2.so.10()(64bit) libgconf-java-2.12.4-15.fc14.i686 requires libgtkjava-2.8.so libgconf-java-2.12.4-15.fc14.i686 requires libgtkjni-2.8.so libgconf-java-2.12.4-15.fc14.i686 requires libglibjni-0.2.so libgconf-java-2.12.4-15.fc14.i686 requires libglibjava-0.2.so libgconf-java-2.12.4-15.fc14.x86_64 requires libglibjni-0.2.so()(64bit) libgconf-java-2.12.4-15.fc14.x86_64 requires libgtkjni-2.8.so()(64bit) libgconf-java-2.12.4-15.fc14.x86_64 requires libglibjava-0.2.so()(64bit) libgconf-java-2.12.4-15.fc14.x86_64 requires libgtkjava-2.8.so()(64bit) mail-notification-evolution-plugin-5.4-22.fc14.x86_64 requires libcamel-1.2.so.18()(64bit) mail-notification-evolution-plugin-5.4-22.fc14.x86_64 requires libcamel-provider-1.2.so.18()(64bit) mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires mingw32(libpng-3.dll) ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc php-pecl-imagick-3.0.0-7.fc14.x86_64 requires libMagickWand.so.3()(64bit) php-pecl-imagick-3.0.0-7.fc14.x86_64 requires libMagickCore.so.3()(64bit) planner-eds-0.14.4-25.fc14.x86_64 requires libcamel-1.2.so.18()(64bit) planner-eds-0.14.4-25.fc14.x86_64 requires libedata-cal-1.2.so.8()(64bit) planner-eds-0.14.4-25.fc14.x86_64 requires libcamel-provider-1.2.so.18()(64bit) qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires spacewalk-backend-libs = 0:0.8.28 valide-0.6.1-0.22.20103003svn511.fc14.i686 requires libvala.so.0 valide-0.6.1-0.22.20103003svn511.fc14.x86_64 requires libvala.so.0()(64bit) wfut-1.1.0-8.fc12.x86_64 requires libgcj.so.10()(64bit) Broken deps for i386 -- almanah-0.7.3-3.fc14.i686 requires libedataserverui-1.2.so.10 antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 evolution-couchdb-0.4.92-1.fc14.i686 requires libcamel-provider-1.2.so.17 evolution-couchdb-0.4.92-1.fc14.i686 requires libebook-1.2.so.9 evolution-couchdb-0.4.92-1.fc14.i686 requires libgtkhtml-editor.so.0 evolution-couchdb-0.4.92-1.fc14.i686 requires libedata-book-1.2.so.2 evolution-couchdb-0.4.92-1.fc14.i686 requires libcamel-1.2.so.17 frysk-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.i386 requires libgtkjava-2.8.so frysk-devel-0.4-26.fc14.i386 requires libglibjava-0.2.so frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-gnome-0.4-26.fc14.i386 requires libgtkjava-2.8.so frysk-gnome-0.4-26.fc14.i386 requires libglibjava-0.2.so frysk-gnome-0.4-26.fc14.i386 requires libgcj.so.10 gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-gtk-0.4.so.0 gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-0.4.so.0 intellij-idea-9.0.1.94.399-11.fc14.i686 requires jna-examples jana-0.4.5-0.7.20100520gitacd72f2.fc14.i686 requires libedataserverui-1.2.so.10
Re: Need proventester karma for firstboot-1.113-4.fc14 (was: Re: bodhi v0.7.9 deployed)
On Fri, 01 Oct 2010 12:36:13 +0200 Kevin Kofler kevin.kof...@chello.at wrote: Adam Williamson wrote: Again, you're extrapolating way too far from a single problem case. The problem is simply that we have the xorg-x11-drivers metapackage which requires every single X driver and is in the critpath. There's various ways we could adjust this so it's no longer the case. It's hardly something that renders an entire policy invalid. Another example for how the critical path policy breaks things: https://admin.fedoraproject.org/updates/firstboot-1.113-4.fc14 This update adds support for xfwm4 and openbox to the firstboot code. Updates for those 2 window managers: https://admin.fedoraproject.org/updates/xfwm4-4.6.2-2.fc14 https://admin.fedoraproject.org/updates/openbox-3.4.11.2-4.fc14 which add the virtual firstboot(windowmanager) Provides have already been pushed to stable! So now we have 2 WMs satisfying firstboot's dependencies, but not actually supported by its code. The result: the Xfce and LXDE spins will be outright BROKEN. (And it's not my fault, I only did the firstboot build and update requests, the other 2 packages were pushed by cwickert.) Xfce at least will not be. ;) I have not been able to do an install and test firstboot here yet, but I can over the weekend. The Xfce update does not much in the end though, so I don't think it's at all urgent. I CANNOT push the firstboot update which UNBREAKS those 2 spins because of the update policy. So instead of preventing breakage, the policy CAUSES breakage! How can it fail more spectacularly for you to finally realize it's a failure? Is there any way you could try to not be such a negative ball of energy? I suppose not. To all proventesters: please +1 that update, EVEN IF YOU HAVEN'T TESTED IT, we need to get out of this impasse! Please don't. Please test the updates properly and add karma when you have. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need proventester karma for firstboot-1.113-4.fc14 (was: Re: bodhi v0.7.9 deployed)
James Laska wrote: On Fri, 2010-10-01 at 12:36 +0200, Kevin Kofler wrote: Adam Williamson wrote: Again, you're extrapolating way too far from a single problem case. The problem is simply that we have the xorg-x11-drivers metapackage which requires every single X driver and is in the critpath. There's various ways we could adjust this so it's no longer the case. It's hardly something that renders an entire policy invalid. Another example for how the critical path policy breaks things: https://admin.fedoraproject.org/updates/firstboot-1.113-4.fc14 This update adds support for xfwm4 and openbox to the firstboot code. Updates for those 2 window managers: https://admin.fedoraproject.org/updates/xfwm4-4.6.2-2.fc14 https://admin.fedoraproject.org/updates/openbox-3.4.11.2-4.fc14 ... I CANNOT push the firstboot update which UNBREAKS those 2 spins because of the update policy. So instead of preventing breakage, the policy CAUSES breakage! How can it fail more spectacularly for you to finally realize it's a failure? In retrospect, if the three updates you list were in fact interdependent, should they have been submitted and tested as a group to avoid the current situation? Yes. -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Fri, Oct 1, 2010 at 6:01 AM, Rahul Sundaram wrote: On Thu, Sep 30, 2010 at 7:25 AM, Orcan Ogetbil wrote: It shouldn't be. Never be afraid of learning, even in the tightest of situations. It is good for your brain. It helps with analytical thinking. Once constant learning becomes part of your life, you really don't get bothered with UI changes. Promoting not learning will drive the community lazy. I think the educational system all over the world forces people to acknowledge learning as burden. This is not good for humanity. I don't believe that Fedora should follow this road of lazyness. I don't know if you are serious but it is not a question of lazyness. Users don't want to be disrupted to what they are used to, just because they did a few updates. New release can introduce major changes and users will be more tolerant of that. What I am trying to say is, a redesign of an interface _usually_ have valid reasons. Those users who don't want their menu items moving around want to live like automated machines. Forbidding such changes promotes lazyness. If the update removes features that existed in previous version, that is another story. I support you forbidding this type of change. But I really don't buy this users shouldn't be disturbed by moving a button from left to right. If the user is disrupted to what they are used to, he needs to learn not to (be disrupted). Do we really want to serve a closed-for-learning community? :( Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Please Help Test 389 Directory Server 1.2.6.1
389-ds-base-1.2.6.1-2 is now in Testing. This release fixes the crashing problems seen with Windows Sync, and fixes some other crashing problems usually seen with deletion operations. Please help us test. The sooner we can get this release tested, the sooner we can push it to Stable and make it generally available. Installation yum install 389-ds --enablerepo=updates-testing # or for EPEL yum install 389-ds --enablerepo=epel-testing setup-ds-admin.pl Upgrade yum upgrade --enablerepo=updates-testing 389-ds-base # or for EPEL yum upgrade --enablerepo=epel-testing 389-ds-base setup-ds-admin.pl -u How to Give Feedback The best way to provide feedback is via the Fedora Update system. Each update is broken down by package and platform. For example, if you are using Fedora 12, and you have successfully installed or upgraded all of the packages, and the console and etc. works, then go to the links below for Fedora 12 and provide feedback. * 389-ds-base-1.2.6.1-2 ** EL-5 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.6.1-2.el5 ** Fedora 12 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.6.1-2.fc12 ** Fedora 13 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.6.1-2.fc13 ** Fedora 14 - https://admin.fedoraproject.org/updates/389-ds-base-1.2.6.1-2.fc14 scroll down to the bottom of the page, and click on the Add a comment link * select one of the Works for me or Does not work radio buttons, add text, and click on the Add Comment button If you are using a build on another platform, just send us an email to 389-us...@lists.fedoraproject.org Reporting Bugs If you find a bug, or would like to see a new feature, you can enter it here - https://bugzilla.redhat.com/enter_bug.cgi?product=389 More Information * Release Notes - http://port389.org/wiki/Release_Notes * Install_Guide - http://port389.org/wiki/Install_Guide * Download - http://port389.org/wiki/Download ___ 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: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
Orcan Ogetbil (oget.fed...@gmail.com) said: What I am trying to say is, a redesign of an interface _usually_ have valid reasons. Those users who don't want their menu items moving around want to live like automated machines. Forbidding such changes promotes lazyness. If the update removes features that existed in previous version, that is another story. I support you forbidding this type of change. But I really don't buy this users shouldn't be disturbed by moving a button from left to right. If the user is disrupted to what they are used to, he needs to learn not to (be disrupted). Do we really want to serve a closed-for-learning community? :( It's restricting the arbitrary application of change to the user to times when they are well able to deal with it. If I'm running F-13 and trying to create a slide deck, and run into a crash, I want the update for the crash to just fix that crash. Not fix that crash and reorganize the slide interface so I need to relearn it for the slides I'm in the middle of. If this change is restricted to the next major release, I'm expecting some amount of change, and therefore are better able to process it, we're better able to document it, and so on. Taking your suggestion to its extreme, we should promote learning and resist automaton behavior by randomizing the menus at each click, changing the default MTA once per release, and so on. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Fri, Oct 01, 2010 at 01:21:29PM -0400, Orcan Ogetbil wrote: What I am trying to say is, a redesign of an interface _usually_ have valid reasons. Those users who don't want their menu items moving around want to live like automated machines. Forbidding such changes promotes lazyness. If the update removes features that existed in previous version, that is another story. I support you forbidding this type of change. But I really don't buy this users shouldn't be disturbed by moving a button from left to right. If the user is disrupted to what they are used to, he needs to learn not to (be disrupted). Do we really want to serve a closed-for-learning community? :( How would you like it if you drove into work, parked your car, and when you went out to your car at the end of the day to commute home you found that the left-hand-drive changed to a right-hand-drive? Or the fuel fill moved to the other side? Or the transmission shift pattern changed? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/1/10 10:41 AM, Chuck Anderson wrote: How would you like it if you drove into work, parked your car, and when you went out to your car at the end of the day to commute home you found that the left-hand-drive changed to a right-hand-drive? Or the fuel fill moved to the other side? Or the transmission shift pattern changed? Or the car was moved to a different parking spot, the roads were changed on the way home, and your garage was re-organized so that you have to park somewhere differently within it. Not all that inaccurate when describing the difference between say F12 GA and current F12... - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkymH1sACgkQ4v2HLvE71NX0HwCeMf1nmo3arZ1Yr54pK1Be223L PPIAoKNNBHjP8oySj9rSBpasuxoD8/+9 =NNpZ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On 1 October 2010 19:21, Orcan Ogetbil oget.fed...@gmail.com wrote: What I am trying to say is, a redesign of an interface _usually_ have valid reasons. Those users who don't want their menu items moving around want to live like automated machines. Forbidding such changes promotes lazyness. No, they don't want to live like machines, they just don't want to have to spend 5 minutes hunting for that blasted option that just moved to a new menu somewhere. Yes, the developers usually have good reasons changing things, but if buttons and menu options are shifting all over the place underneath people it wastes their time and annoys them. It takes time to *learn* where something has moved to, and some of us have better things to do than relearning where the ticky box has moved to this time. We'll learn, but we don't want to have to learn something new when there's a deadline looming on us. Mark -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide buildtree broken with the newest perl
Hello. Currently rawhide buildtree seems broken with the newest perl: http://koji.fedoraproject.org/koji/taskinfo?taskID=2506686 http://koji.fedoraproject.org/koji/getfile?taskID=2506686name=root.log DEBUG util.py:260: Error: Package: 4:perl-5.12.2-137.fc15.x86_64 (build) DEBUG util.py:260: Requires: libperl.so()(64bit) DEBUG util.py:260: You could try using --skip-broken to work around the problem DEBUG util.py:260: You could try running: rpm -Va --nofiles --nodigest Would someone untag this build? Thank you. Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
FAILED: BuildrootError: could not init mock buildroot
FAILED: BuildrootError: could not init mock buildroot, mock exited with status 30; see root.log for more information http://koji.fedoraproject.org/koji/taskinfo?taskID=2506706 DEBUG util.py:260: Error: Package: 4:perl-5.12.2-137.fc15.x86_64 (build) DEBUG util.py:260: Requires: libperl.so()(64bit) DEBUG util.py:260: You could try using --skip-broken to work around the problem DEBUG util.py:260: You could try running: rpm -Va --nofiles --nodigest -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide buildtree broken with the newest perl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/1/10 11:11 AM, Mamoru Tasaka wrote: Hello. Currently rawhide buildtree seems broken with the newest perl: http://koji.fedoraproject.org/koji/taskinfo?taskID=2506686 http://koji.fedoraproject.org/koji/getfile?taskID=2506686name=root.log DEBUG util.py:260: Error: Package: 4:perl-5.12.2-137.fc15.x86_64 (build) DEBUG util.py:260: Requires: libperl.so()(64bit) DEBUG util.py:260: You could try using --skip-broken to work around the problem DEBUG util.py:260: You could try running: rpm -Va --nofiles --nodigest Would someone untag this build? Thank you. Regards, Mamoru I've untagged this. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkymJesACgkQ4v2HLvE71NUf7gCgtD4g3r4CasnXSmWcgnOErcBz bgwAnj8/ZYPjK8F02VwpG2tEZYsmkTnX =9cub -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FAILED: BuildrootError: could not init mock buildroot
Neal Becker (ndbeck...@gmail.com) said: FAILED: BuildrootError: could not init mock buildroot, mock exited with status 30; see root.log for more information http://koji.fedoraproject.org/koji/taskinfo?taskID=2506706 DEBUG util.py:260: Error: Package: 4:perl-5.12.2-137.fc15.x86_64 (build) DEBUG util.py:260: Requires: libperl.so()(64bit) DEBUG util.py:260: You could try using --skip-broken to work around the problem DEBUG util.py:260: You could try running: rpm -Va --nofiles --nodigest Untagged. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Fri, 1 Oct 2010 08:35:45 -0400, you wrote: The user has to tolerate some change. We can't cater to people who never upgrade which seems to be what is taking place. Especially with the fact that our end of life happens sooner, users must already expect a constant stream of updates. Yes, running a Linux distribution like Fedora involves change - but that change can be made manageable by only requiring disruptive changes every 6 months (if the user follows each release) or 12 months if the user is alternating releases. If they want more stability they should be using RHEL, CentOS or Scientific Linux, Debian Stable, Ubuntu LTS which do put the focus on non disruptiveness. Are you really saying that a KDE user should be stuck with KDE 3.5.4 (which is what is in CentOS 5) if they want some stability? Those versions of Linux have their place, but using them on the desktop can be problematic given the rate of change in the Linux desktop environments. There is simply too much desktop software that requires newer versions of libraries than are shipped with the long term releases. Which is why a more stable Fedora is desired. Each release of KDE comes with bug fixes, security fixes and new features. True of most software. Plus combine the fact that KDE right now is evolving at a rapid rate thanks to all of the new developers that the 4.x series has attracted. All the more reason to restrict disruptive updates to a new Fedora release. Certainly as a prospective KDE user (I have not liked the new gnome-shell the couple of times I have tried it in the past) I expect the KDE included with Fedora to allow me to do what I need to do with the least amount of disruption possible. While I appreciate new versions of software that brings new features, I don't want that to occur when I am trying to get other things done. Not having the latest makes it difficult for a KDE developer to test their stuff and make sure it keeps working with the latest KDE. Fedora isn't just a home to Gnome development, which as a framework never seems to change so they won't have the same opinion as the KDE people. I hate to disappoint you but no distribution, and this includes rawhide, is great for bleeding edge. Like it or not but if you as a developer need the absolute latest in development version of something you need to package or otherwise compile it yourself. This is why developers working on Gnome itself use jhbuild, to automate this for them, because the distributions themselves can't do it. Given that you have researched how other distributions handle KDE, it is apparent the same is true for developers working on KDE. Look, I realise you are passionate about KDE, and want the best KDE experience in Fedora. But most people are not developers, they instead are using their desktop environment of choice to get regular, everyday things done with office software, web browsers, email, and sometime even custom software. They want predictability, which means only having to make changes to how they do things when they are prepared for the changes, which occurs when they upgrade Fedora. Thus the best KDE experience you can give them is one of stability, where KDE helps them do their work instead of being work. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FAILED: BuildrootError: could not init mock buildroot
Bill Nottingham wrote: Neal Becker (ndbeck...@gmail.com) said: FAILED: BuildrootError: could not init mock buildroot, mock exited with status 30; see root.log for more information http://koji.fedoraproject.org/koji/taskinfo?taskID=2506706 DEBUG util.py:260: Error: Package: 4:perl-5.12.2-137.fc15.x86_64 (build) DEBUG util.py:260: Requires: libperl.so()(64bit) DEBUG util.py:260: You could try using --skip-broken to work around the problem DEBUG util.py:260: You could try running: rpm -Va --nofiles --nodigest Untagged. Bill Thanks, what should I do next? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: FAILED: BuildrootError: could not init mock buildroot
Neal Becker (ndbeck...@gmail.com) said: Thanks, what should I do next? Wait for the build repo to regenerate and then resubmit. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Fri, Oct 1, 2010 at 1:50 PM, Jesse Keating wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/1/10 10:41 AM, Chuck Anderson wrote: How would you like it if you drove into work, parked your car, and when you went out to your car at the end of the day to commute home you found that the left-hand-drive changed to a right-hand-drive? Or the fuel fill moved to the other side? Or the transmission shift pattern changed? Or the car was moved to a different parking spot, the roads were changed on the way home, and your garage was re-organized so that you have to park somewhere differently within it. Such things happen in life. - Roads get closed and you need to take an alternate path. - My friend's transmission broke once, he couldn't shift to 2. He had to shift from 1 to 3 all the time, but this wasn't too hard to learn. - My wife takes my car. But I need a car urgent. I borrowed my friend's car and the fuel fill is on the different side with respect to my car. But I learned it. Learning such stuff does not bother me in my daily workflow. But I guess I am alone here. Sad :( Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Fri, Oct 1, 2010 at 1:28 PM, Bill Nottingham wrote: Orcan Ogetbil (oget.fed...@gmail.com) said: What I am trying to say is, a redesign of an interface _usually_ have valid reasons. Those users who don't want their menu items moving around want to live like automated machines. Forbidding such changes promotes lazyness. If the update removes features that existed in previous version, that is another story. I support you forbidding this type of change. But I really don't buy this users shouldn't be disturbed by moving a button from left to right. If the user is disrupted to what they are used to, he needs to learn not to (be disrupted). Do we really want to serve a closed-for-learning community? :( It's restricting the arbitrary application of change to the user to times when they are well able to deal with it. If I'm running F-13 and trying to create a slide deck, and run into a crash, I want the update for the crash to just fix that crash. Not fix that crash and reorganize the slide interface so I need to relearn it for the slides I'm in the middle of. If this change is restricted to the next major release, I'm expecting some amount of change, and therefore are better able to process it, we're better able to document it, and so on. Taking your suggestion to its extreme, we should promote learning and resist automaton behavior by randomizing the menus at each click, changing the default MTA once per release, and so on. Random changes are different than planned-by-upstream changes. I don't think I would like to have randomized changes. But I am all in for planned changes that people thought about. Our views are very very different. But I don't need to reiterate my opinions. I am sure you got them. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
On Fri, Oct 01, 2010 at 02:00:46PM +0100, Tim Waugh wrote: In system-config-printer I try to get it to modify the firewall to allow in the various network query responses that we expect, [...] I should note, although it's not your fault, that this breaks libvirt networking. libvirt needs to add its own firewall rules too, and restarting the firewall breaks these rules until you restart the libvirt network and all your VMs. The root problem here is that our firewall rules aren't composable. As you can tell by the bug #, this issue has been around for quite a long time ... https://bugzilla.redhat.com/show_bug.cgi?id=227011 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ssh agent issue
https://bugzilla.redhat.com/show_bug.cgi?id=626209 Reported against F13, but I've encountered it in F14 Beta. Seems like more folks ought to be impacted by this bug that seem to be, so I wonder what is going on here. Do less folks use ssh-add that I imagine, or is some factor limiting this bug? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ssh agent issue
On Fri, Oct 1, 2010 at 12:44 PM, Mike McLean mikem@gmail.com wrote: https://bugzilla.redhat.com/show_bug.cgi?id=626209 Reported against F13, but I've encountered it in F14 Beta. Seems like more folks ought to be impacted by this bug that seem to be, so I wonder what is going on here. Do less folks use ssh-add that I imagine, or is some factor limiting this bug? I'm not seeing this on my F13 systems and I use ssh all the time. First I've heard of the problem. I've commented on the bug report. It looks like a gnome keyring daemon initilization problem..but not one I'm experiencing and I use ssh in a terminal every day with agent functionality just fine. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ssh agent issue
On 10/01/2010 04:44 PM, Mike McLean wrote: https://bugzilla.redhat.com/show_bug.cgi?id=626209 Reported against F13, but I've encountered it in F14 Beta. Seems like more folks ought to be impacted by this bug that seem to be, so I wonder what is going on here. Do less folks use ssh-add that I imagine, or is some factor limiting this bug? I use ssh-add all the time - but not the gnome agent - i use ssh-agent. (I'm esp. not fond of it's mouse focus grabbing) A few others I know also use ssh-agent .. so that may be a part of it too ... Tho it may not hit everyone ... bugs have that habit :-) g/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Is this (broken keyboard layouts) a Fedora 14 Blocker bug?!
Hi, I've tried testing Fedora 14 Beta (RC3, but updated), and soon I come across this bug[1]. I could discover the initial cause and propose a fix (which, after reporting to freedesktop bugzilla, I found that is already fixed in xkbconfig git (but still should be pushed to F14)). Then, I came across another bug (which is detailed in the end of [1], and is followed at [2] and [3]) which will affect a number of keyboard layouts in F14. In brief, this bug will cause some keyboard layouts to be broken in F14, which IMHO should not go in Fedora 14 Final. I wonder if it can be qualified as a blocker bug. Thanks, Hedayat [1] https://bugzilla.redhat.com/show_bug.cgi?id=638244 [2] https://bugs.freedesktop.org/show_bug.cgi?id=30548 [3] https://bugs.freedesktop.org/show_bug.cgi?id=30549 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need proventester karma for firstboot-1.113-4.fc14 (was: Re: bodhi v0.7.9 deployed)
James Laska wrote: In retrospect, if the three updates you list were in fact interdependent, should they have been submitted and tested as a group to avoid the current situation? Yes, of course. But it's not my fault that cwickert filed those 2 updates without the required matching firstboot update. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
Takanori MATSUURA wrote: For modules/libimg/png, mozilla products use aPNG which was rejected by upstream. http://en.wikipedia.org/wiki/APNG So we have to use internal png. But this is against our packaging guidelines. There are only 2 solutions to this: a. apply the Debian patch which removes APNG support from xulrunner OR b. apply the Mozilla patch which adds APNG support to libpng. The current solution is NOT acceptable. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need proventester karma for firstboot-1.113-4.fc14 (was: Re: bodhi v0.7.9 deployed)
Matthew Garrett wrote: Some packages were pushed to stable before they should have been, therefore we need to make it easier to push packages to stable? Yes! Sure, this sounds paradoxical, but my premise is that NO MATTER how strict you make the requirement for pushes to stable, there will ALWAYS be the possibility that sh*t happens and thus a need to be able to rush out fixes to stable as quickly as possible. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Need proventester karma for firstboot-1.113-4.fc14 (was: Re: bodhi v0.7.9 deployed)
On Sat, Oct 02, 2010 at 12:45:14AM +0200, Kevin Kofler wrote: Matthew Garrett wrote: Some packages were pushed to stable before they should have been, therefore we need to make it easier to push packages to stable? Yes! Sure, this sounds paradoxical, but my premise is that NO MATTER how strict you make the requirement for pushes to stable, there will ALWAYS be the possibility that sh*t happens and thus a need to be able to rush out fixes to stable as quickly as possible. And my premise is that we should be making harder for shit to happen, and the cases where it *does* should be examined carefully to determine the best way forwards. Force this untested package into stable isn't the best way to do things. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
Sven Lankes wrote: https://bugzilla.mozilla.org/show_bug.cgi?id=577653 Looking at how rigorous new packages with bundled libs are fought we should really stop shipping firefox and start shipping Iceweasel. +1 I really don't see why the Firefox stack keeps getting a free ride around our packaging guidelines. Firefox is a package like any others, it MUST respect our packaging guidelines, and that means NO bundled libraries, PERIOD. If that's not possible while still calling it Firefox, it MUST be renamed. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
Gregory Maxwell wrote: I yelled pretty loudly when Fedora first packaged libvpx because fedora took a _known vulnerable_ version which Mozilla and opera were patching around but where the upstream hadn't yet merged the fixes. Things are more mature now but there are still somewhat scary fixes happening, at least with the platform dependant code: https://review.webmproject.org/#change,603 Mozilla being a vector for the widescale exploitation would be terrible for their image— and also terrible for Fedora's, we really don't want to create our own version of the debian openssl rng bug. If libvpx is vulnerable, this MUST be fixed in our system version, otherwise ALL THE OTHER SOFTWARE WE SHIP using libvpx can be exploited! Fixing only the Mozilla stack does NOT solve the problem. Fixing the system library does, for EVERYONE, INCLUDING Firefox. There really is a common interest here and the folks on the Mozilla side are better informed about the risks. There is NO common interest. Our interest is to have ONE copy of the library (for the ENTIRE distribution) in which to apply security fixes. The patches mozilla is carrying are visible as files in the respective directories here: http://mxr.mozilla.org/mozilla-central/source/media/ I'd suggest that fedora folks interested in the bundling help by making sure that the applicable fixes make it upstream. Even if Fedora were to ditch the trademarks you couldn't escape doing this work. Sure we could. We'd just apply the patches to our libvpx package. That's what SRPMs are for. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On 10/01/2010 03:49 PM, Kevin Kofler wrote: Takanori MATSUURA wrote: For modules/libimg/png, mozilla products use aPNG which was rejected by upstream. http://en.wikipedia.org/wiki/APNG So we have to use internal png. But this is against our packaging guidelines. There are only 2 solutions to this: a. apply the Debian patch which removes APNG support from xulrunner OR b. apply the Mozilla patch which adds APNG support to libpng. c. help create a real project out of http://littlesvr.ca/apng/ with tarballs instead of just patchsets, possibly renaming it to something else, and ship that so we can build against it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
Christopher Aillon wrote: I personally don't care what we call it. I'm not going to start breaking funny cat videos You shouldn't break the videos, you should apply the Debian patch to use the system libvpx, then the videos will just work. just to meet packaging ideals on a deadline. I'd rather deal with all you guys complaining on fedora-devel and in fesco tickets than the influx of bugs if I started breaking shit. It's bad enough that there are more bugs than we can handle. Then you should be replaced by a maintainer who actually cares about our packaging guidelines. Besides, Mozilla has a good track record of allowing system libs after things settle down, and I have no doubt that we'll get these at some point. That's too late. The libraries MUST NEVER be bundled, at NO point in time. From Mozilla's perspective, they could: 1. Do what they are doing now, temporarily not allow a few new system libs, waiting until they get banged into shape and *then* enable system libs (down the road). 2. Bang on the code in private and wait until it meets every Fedora packaging guideline, etc, until committing to the upstream repository, so we all get to wait for all of the cool shit that's happening. 3. Just allow distributors to build against the system libraries and trust them to know what they're doing! They're the ONLY upstream which makes it such a PITA to ship their project. Please note that we're talking about pre-release versions of Firefox in a pre-release version of Fedora anyway, so a lot of churn is to be expected. We're almost certainly going to have to temporarily disable and reenable a lot of other system libs during the beta cycles to get builds out the door, just like we always do in rawhide. This is not acceptable. Not that I can guarantee that the release version will have all the above system libs enabled, but we'll know a lot more closer to FF4 and F15 release time. And neither is this. We have policies for a reason, Firefox must stop being special and start following the same rules as everyone else. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Saturday 02 October 2010, Christopher Aillon wrote: c. help create a real project out of http://littlesvr.ca/apng/ with tarballs instead of just patchsets, possibly renaming it to something else, and ship that so we can build against it. How is shipping a redundant copy of essentially the same code better than just applying the patch to our libpng package? There's even an upstream for those patchsets, I really don't see why it can't just be applied to our libpng. I know that it's a nonstandard extension for PNG. In fact, I'm really angry at Mozilla for having come up with that instead of promoting the already existing MNG! But given the situation we have now, it's in the best interest of Fedora as a distribution to ship an APNG-enabled libpng. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
Sven Lankes wrote: I'm not worried too much about a library being system or not. What I'm worried about is twofold: 1. Established packagers of high-profile packages get to do what they want with fedora packages while small-scale packagers of low-profile packages get told to bugger off if they cannot make their packages use system libs (zsync anyone?). +1 I really don't see why we keep exempting Firefox from our rules. Correct me if I'm wrong but as far as I can see none of the chosen ff comitters has actually asked fesco to grant an exception for libvpx, right? Now that the topic has come up there is talk in the ticket that the exception should be granted but that cannot feel right to anyone, can it? And indeed, the fact that this is only being brought to the responsible committee (FESCo) after the fact is also unacceptable. 2. The combination of the Mozilla Trademark issue combined with the strict handling of patches by (corporate|distro)-maintainers (I don't think that this is a RH/Fedora issue - same with Canonical/Ubuntu) makes me feel uneasy about ff being called Free sofware. Indeed, Firefox is effectively non-Free for Fedora, since we're being kept hostage of their patch approval processes, and since our maintainer has a conflict of interest and values Mozilla's policies above Fedora's. (And yes - I am aware that the other relevant floss-browser is much worse than mozilla wrt. bundling libs and using forked libs). (Hey, don't insinuate that Konqueror is irrelevant!) Chromium is not in Fedora for exactly that reason. Why does Firefox get a free pass? Also the bug is not about _using_ the system lib it's just about allowing the user to build against it. Indeed. And this is a core part of freedom. Plus, the end user isn't going to build Firefox himself. It's going to be built by a packager who knows what he's doing when building against the system library, and the distribution also controls that library. So I really don't see why Mozilla refuses to allow it. From Mozilla's perspective, they could: 1. Do what they are doing now, temporarily not allow a few new system libs, waiting until they get banged into shape and *then* enable system libs (down the road). 2. Bang on the code in private and wait until it meets every Fedora packaging guideline, etc, until committing to the upstream repository, so we all get to wait for all of the cool shit that's happening. 3. Add the patch to their system that would allow people to build against a system lib. +1 Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Fri, 2010-10-01 at 14:51 -0400, Orcan Ogetbil wrote: On Fri, Oct 1, 2010 at 1:28 PM, Bill Nottingham wrote: Orcan Ogetbil (oget.fed...@gmail.com) said: What I am trying to say is, a redesign of an interface _usually_ have valid reasons. Those users who don't want their menu items moving around want to live like automated machines. Forbidding such changes promotes lazyness. If the update removes features that existed in previous version, that is another story. I support you forbidding this type of change. But I really don't buy this users shouldn't be disturbed by moving a button from left to right. If the user is disrupted to what they are used to, he needs to learn not to (be disrupted). Do we really want to serve a closed-for-learning community? :( It's restricting the arbitrary application of change to the user to times when they are well able to deal with it. If I'm running F-13 and trying to create a slide deck, and run into a crash, I want the update for the crash to just fix that crash. Not fix that crash and reorganize the slide interface so I need to relearn it for the slides I'm in the middle of. If this change is restricted to the next major release, I'm expecting some amount of change, and therefore are better able to process it, we're better able to document it, and so on. Taking your suggestion to its extreme, we should promote learning and resist automaton behavior by randomizing the menus at each click, changing the default MTA once per release, and so on. Random changes are different than planned-by-upstream changes. I don't think I would like to have randomized changes. But I am all in for planned changes that people thought about. Our views are very very different. But I don't need to reiterate my opinions. I am sure you got them. +1 Usually upstream does not push random changes - usually the changes are useful in some way and improving user experience. If the upstream is so stupid to push really random changes in their minor releases (I do not advocate here major releases updates from upstream in released Fedoras) then probably the package should not be part of the Fedora at all or the package maintainer in Fedora should be able to backport individual patches for bug fixes. But disallowing any changes in user experience and minor updates from upstream in released Fedoras is unreasonably strict. Also when getting back to the infamous KDE 4.0 in Fedora 9 - when the decision was made to ship KDE 4.0 (regardless of whether it was bad or not) in the final release - it would be really stupid to disallow updating KDE packages to new upstream versions that changed user experience (mostly by improving it). -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Fri, Oct 01, 2010 at 02:47:23PM -0400, Orcan Ogetbil wrote: On Fri, Oct 1, 2010 at 1:50 PM, Jesse Keating wrote: On 10/1/10 10:41 AM, Chuck Anderson wrote: How would you like it if you drove into work, parked your car, and when you went out to your car at the end of the day to commute home you found that the left-hand-drive changed to a right-hand-drive? Or the fuel fill moved to the other side? Or the transmission shift pattern changed? Or the car was moved to a different parking spot, the roads were changed on the way home, and your garage was re-organized so that you have to park somewhere differently within it. Such things happen in life. - Roads get closed and you need to take an alternate path. - My friend's transmission broke once, he couldn't shift to 2. He had to shift from 1 to 3 all the time, but this wasn't too hard to learn. - My wife takes my car. But I need a car urgent. I borrowed my friend's car and the fuel fill is on the different side with respect to my car. But I learned it. Learning such stuff does not bother me in my daily workflow. But I guess I am alone here. Sad :( Yes, but those are exceptional cases. The comparison with computers would be if your hard drive died and you needed to borrow your friend's computer which might run a different operating system or version. You try to avoid those cases normally. Most people don't choose a car that might morph unexpectedly out from under them as a part of its normal, expected routine. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firewall settings unworkable
On 10/01/2010 10:36 PM, Richard W.M. Jones wrote: On Fri, Oct 01, 2010 at 02:00:46PM +0100, Tim Waugh wrote: In system-config-printer I try to get it to modify the firewall to allow in the various network query responses that we expect, [...] I should note, although it's not your fault, that this breaks libvirt networking. libvirt needs to add its own firewall rules too, and restarting the firewall breaks these rules until you restart the libvirt network and all your VMs. The root problem here is that our firewall rules aren't composable. As you can tell by the bug #, this issue has been around for quite a long time ... https://bugzilla.redhat.com/show_bug.cgi?id=227011 I'm wondering what the actual requirements are in order to make it possible for a service to add rules to the firewall. The discussion in the bug mixes general requirements for such a feature with current iptables limitations which makes it difficult to understand the problem fully. In a first step it would probably be best to create a layer on top of iptables that manages the addition and removal of rules that can be independently configured. That way you don't have to find quirky hacks for iptables. service iptables save for would then call the save function of that management layer which in turn could save the iptables rules to a temporary file, filter out the service rules and then save the standard/global/default rules in /etc/sysconfig/iptables and the service rules it filterd out into /etc/sysconfig/iptables.d/service. When loading the whole thing is executed in reverse. Once workable semantics are found for such a management layer the second step could be to move these features into iptables itself if possible. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F14 libgdl 2.31.x broken
Any application that uses libgdl on F14 segfaults on startup. I had to downgrade libgdl to 2.30.x in order to get applications using libgdl to work. Quoting from an upstream bug report filed against Anjuta for the same issue I'm seeing on F14 Anyway, gdl 2.31.x is broken and gnome-2-32 will ship gdl 2.30.x. Actually the gdl 2.31.x was superseeded with gdl 2.90.x which will ship with GNOME 3.0 and uses gtk+-3.0 but won't work with anjuta yet as we don't use gtk+-3.0. So please use gdl 2.30.x for now. I filed a Fedora bug report over two weeks ago, but have had no response from the Fedora maintainer for libgdl. If someone else has the time, can we please get this issue fixed. Upstream Anjuta bug report I found about the same issue. https://bugzilla.gnome.org/show_bug.cgi?id=627463 Fedora bug I filed against libgdl. https://bugzilla.redhat.com/show_bug.cgi?id=635333 Regards, Jim H -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2010-10-01 - F14-Blocker meeting recap
== #fedora-bugzappers: F14 Blocker Bug Review == Meeting started by jlaska at 16:00:07 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-bugzappers/2010-10-01/f-14-blocker-review.2010-10-01-16.00.log.html . Meeting summary --- * Gathering critical mass (jlaska, 16:00:27) * The basics ... (jlaska, 16:04:55) * LINK: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting (jlaska, 16:05:31) * LINK: http://tinyurl.com/2fqpazy (jlaska, 16:06:10) * LINK: https://fedoraproject.org/wiki/Fedora_14_Final_Release_Criteria (jlaska, 16:08:20) * https://bugzilla.redhat.com/show_bug.cgi?id=584328 (jlaska, 16:08:33) * AGREED: 584328 - tentatively accepted as a valid release blocker. Impacts dmraid installation using custom partitioning on at least 1 system (unknown if more) (jlaska, 16:20:15) * https://bugzilla.redhat.com/show_bug.cgi?id=636621 (jlaska, 16:20:26) * https://bugzilla.redhat.com/show_bug.cgi?id=584328 (jlaska, 16:21:01) * ACTION: 584328 - dlehman has a fix inprogress, may require additional access to the affected system to test, will follow-up in bug (jlaska, 16:26:31) * https://bugzilla.redhat.com/show_bug.cgi?id=636621 (jlaska, 16:26:52) * AGREED: 636621 - No criteria for loglevel= boot parameter, agreed to move to nice-to-have list (jlaska, 16:36:38) * ACTION: dlehman - patch in hand for 636621, will cherry-pick from master before next build (jlaska, 16:38:20) * IDEA: think about installer boot option loglevel= and if criteria need adjustment (jlaska, 16:39:17) * https://bugzilla.redhat.com/show_bug.cgi?id=627388 (jlaska, 16:39:55) * AGREED: 627388 - unclear whether the reported problem still exists, awaiting feedback from reporter. May remove from list next meeting if no changes (jlaska, 16:43:20) * Leave in needinfo? requesting feedback from reporter (jlaska, 16:43:40) * Outstanding question for msivak in bug to address a new issue related to VNC prompt on text-mode installs (jlaska, 16:44:11) * LINK: http://tinyurl.com/2drr5rs (jlaska, 16:44:53) * https://bugzilla.redhat.com/show_bug.cgi?id=635778 (jlaska, 16:45:03) * 635778 - currently in MODIFIED, fix available in 14.18, awaiting anaconda build to test (jlaska, 16:47:13) * https://bugzilla.redhat.com/show_bug.cgi?id=627789 (jlaska, 16:48:05) * 627789 - currently in MODIFIED, fix available in 14.18, awaiting anaconda build to test (jlaska, 16:49:06) * https://bugzilla.redhat.com/show_bug.cgi?id=621685 (jlaska, 16:49:36) * 621685 included and tested in F-14-Beta, moved to CLOSED ERRATA (jlaska, 16:50:06) * https://bugzilla.redhat.com/show_bug.cgi?id=621469 (jlaska, 16:50:26) * 621469 included and tested in F-14-Beta, moved to CLOSED ERRATA (jlaska, 16:50:59) * https://bugzilla.redhat.com/show_bug.cgi?id=631987 (jlaska, 16:52:51) * AGREED: 631987 is a valid release blocker per criteria that all applications listed under the Applications menu must withstand a basic functionality test and not crash after [...] normal use (jlaska, 16:55:37) * mclasen notes a fix is available upstream and should be included when brasero is bumped to 2.32 (jlaska, 16:57:15) * https://bugzilla.redhat.com/show_bug.cgi?id=637339 (jlaska, 16:59:00) * All applications listed under the Applications menu must withstand a basic functionality test (jlaska, 17:00:37) * AGREED: 637339 - accepted as release blocker, appears to affect basic empathy functionality (connecting to yahoo) and is covered by final release criteria (jlaska, 17:02:10) * (Meeting topic: F14 Blocker Bug Review) (jlaska, 17:02:18) * 637339 - a fix is pending submissino to stable, selinux-policy -7 has passed critpath requirements (jlaska, 17:02:57) * https://bugzilla.redhat.com/show_bug.cgi?id=636118 (jlaska, 17:03:13) * AGREED: 636118 - accepted as release blocker, affects basic functionality of swell-foop (included on Live image) and is covered by final release criteria (jlaska, 17:07:14) * ACTION: 636118 - halfline (or someone from desktop) needed to investigate problem (jlaska, 17:08:51) * https://bugzilla.redhat.com/show_bug.cgi?id=639130 (jlaska, 17:09:18) * AGREED: 639130 - not a release blocker or nice-to-have. gnome-games-extra is not provided on the Live image or DVD, does not meet release criteria (jlaska, 17:14:54) * https://bugzilla.redhat.com/show_bug.cgi?id=623824 (jlaska, 17:15:18) * AGREED: 623824 - not a release blocker, no criteria exist to cover display to external monitors (jlaska, 17:21:49) * ACTION: ajax and reporter continue to triage the issue with F14 test results (jlaska, 17:22:07) * https://bugzilla.redhat.com/show_bug.cgi?id=636585 (jlaska, 17:22:48) * AGREED: 636585 - not enough information to determine impacted
[perl-Math-Pari/el6/master] (13 commits) ...Update prior to RHEL6 GA, and make sure that we've been built against the CORRECT pari version
Summary of changes: b70c245... Update to 2.010802 Use system pari library (version 2.3.4) (*) 42d16a5... Update to 2.010804 (*) 18326b4... Update to 2.010805 (*) 600f0a2... Update to 2.010806 (*) e3ce52c... Update to 2.01080602 (see Changes for details) No longer ne (*) 0d70084... Fix typo that causes a failure to update the common directo (*) a781ae0... Update to 2.01080603 (see Changes for details) (*) 960d534... Update to 2.01080604 (*) 9b8f1b9... - Mass rebuild with perl-5.12.0 (*) db19b3a... - Make stack size bigger for intnum test to avoid test fail (*) 9d7eefb... - Rebuild with pari 2.3.5 - Tweak application of intnum tes (*) eab9c5d... dist-git conversion (*) 07bb6c0... Update prior to RHEL6 GA, and make sure that we've been bui (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Math-Pari/el6/master: 13/13] Update prior to RHEL6 GA, and make sure that we've been built against the CORRECT pari version
commit 07bb6c0f4dbdba85c53e677dfb3f77ccbfd8cb06 Merge: 67f2739 eab9c5d Author: Mark Chappell trem...@fedoraproject.org Date: Fri Oct 1 13:14:16 2010 +0200 Update prior to RHEL6 GA, and make sure that we've been built against the CORRECT pari version .gitignore |4 +- perl-Math-Pari-2.010802-docs-and-testsuite.patch | 20 perl-Math-Pari-2.010802-no-fake-version.patch | 11 ++ ...Math-Pari-2.01080604-extra-stack-for-test.patch | 25 + perl-Math-Pari.spec| 101 +++- sources|4 +- 6 files changed, 135 insertions(+), 30 deletions(-) --- -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File MailTools-2.07.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-MailTools: df861e05cbcf3a336ecebfb2c42529d0 MailTools-2.07.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-MailTools] Update to 2.07
commit 1016564d74ecb3bb2c7b19d9ba51c377b077ae2e
Author: Paul Howarth p...@city-fan.org
Date: Fri Oct 1 21:10:14 2010 +0100
Update to 2.07
- New upstream release 2.07:
- Document perl 5.8.1 requirement in README (CPAN RT#61753)
- Add MAIL FROM to Mail::Mailer::smtp
.gitignore |2 +-
perl-MailTools.spec |9 +++--
sources |2 +-
3 files changed, 9 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e363f5b..eae87af 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-MailTools-2.06.tar.gz
+/MailTools-2.07.tar.gz
diff --git a/perl-MailTools.spec b/perl-MailTools.spec
index 26b5abb..515fedb 100644
--- a/perl-MailTools.spec
+++ b/perl-MailTools.spec
@@ -1,7 +1,7 @@
Summary: Various mail-related perl modules
Name: perl-MailTools
-Version: 2.06
-Release: 2%{?dist}
+Version: 2.07
+Release: 1%{?dist}
License: GPL+ or Artistic
Group: Development/Libraries
URL: http://search.cpan.org/dist/MailTools/
@@ -100,6 +100,11 @@ cd -
%{_mandir}/man3/Mail::Util.3pm*
%changelog
+* Fri Oct 1 2010 Paul Howarth p...@city-fan.org 2.07-1
+- Update to 2.07
+ - Document perl 5.8.1 requirement in README (CPAN RT#61753)
+ - Add MAIL FROM to Mail::Mailer::smtp
+
* Mon May 03 2010 Marcela Maslanova mmasl...@redhat.com - 2.06-2
- Mass rebuild with perl-5.12.0
diff --git a/sources b/sources
index c86a371..32a206d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-3f90297c7f566cc0cc9c89ee47906abf MailTools-2.06.tar.gz
+df861e05cbcf3a336ecebfb2c42529d0 MailTools-2.07.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-MailTools] Created tag perl-MailTools-2.07-1.fc15
The lightweight tag 'perl-MailTools-2.07-1.fc15' was created pointing to: 1016564... Update to 2.07 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-MailTools/f14/master] Update to 2.07
Summary of changes: 1016564... Update to 2.07 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-MailTools] Created tag perl-MailTools-2.07-1.fc14
The lightweight tag 'perl-MailTools-2.07-1.fc14' was created pointing to: 1016564... Update to 2.07 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 639523] New: missing dependency
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: missing dependency https://bugzilla.redhat.com/show_bug.cgi?id=639523 Summary: missing dependency Product: Fedora EPEL Version: el6 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: high Component: perl-Mail-Box AssignedTo: tcall...@redhat.com ReportedBy: florian.laro...@gmx.net QAContact: extras...@fedoraproject.org CC: tcall...@redhat.com, fedora-perl-devel-l...@redhat.com Classification: Fedora Description of problem: If you try to install perl-Mail-Box on rhel6beta, if fails with: Error: Package: perl-Mail-IMAPClient-3.25-1.el6.noarch (rhel6-beta-epel) Requires: perl(Mozilla::LDAP::Conn) Error: Package: perl-Mail-Box-2.095-1.el6.2.noarch (rhel6-beta-epel) Requires: perl(MIME::Entity) Error: Package: perl-Mail-Box-2.095-1.el6.2.noarch (rhel6-beta-epel) Requires: perl(MIME::Parser) You could try using --skip-broken to work around the problem Version-Release number of selected component (if applicable): How reproducible: yum install perl-Mail-Box Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: -- 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. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [389-devel] Please review: openldap ber_init will assert if the bv-bv_val is NULL
ack. Rich Megginson wrote: -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
