Re: Lookaside failure. Check your cert.
(2010/10/05 10:04), KaiGai Kohei wrote: (2010/09/29 2:29), Dennis Gilmore wrote: On Tuesday, September 28, 2010 12:13:49 am Chitlesh GOORAH wrote: Hello there, I'm having the following error with some of my packages (iverilog and perl-Verilog-Perl) since last week, even after updating my certs. $ fedpkg import /home/chitlesh/rpmbuild/SRPMS/iverilog-0.9.20100928-1.el6.src.rpm Uploading: d004408ea595b13780c4c036f8188b66 verilog-0.9.3.tar.gz Could not import srpm: Lookaside failure. Check your cert. However, I managed to build verilator on koji somehow. Can you please tell me what it may cause this ? Chitlesh did you recently get a new cert? if so you may need to update nss. if your using rhel6 you should use fedora or convert the cert to a format nss understands (openssl x509 -in ~/.fedora.cert -text; echo; openssl rsa -in ~/.fedora.cert) fedora.cert.new I also face to same issue, but it is not still solved with the above suggestion. [kai...@saba sepostgresql]$ (openssl x509 -in ~/.fedora.cert -text; echo; openssl rsa -in ~/.fedora.cert) ~/fedora.cert.new writing RSA key [kai...@saba sepostgresql]$ cp ~/fedora.cert.new ~/.fedora.cert [kai...@saba sepostgresql]$ fedpkg new-sources postgresql-9.0.0.tar.gz Uploading: 9443b3b9c95a48d5e0713feafc209adc postgresql-9.0.0.tar.gz Could not upload new sources: Lookaside failure. Check your cert. The original ~/.fedora.cert was generated just a few days ago using FAS. But I've not been able to upload the new source yet. Any ideas? Sorry, it seems to me I missed fedora-cert -n and update several packages into the latest version. http://fedoraproject.org/wiki/PackageMaintainers/UpdatingPackageHowTo I could upload the new source according to the above wikipage. Thanks, -- KaiGai Kohei kai...@ak.jp.nec.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: process to use when missed a patch addition
On 05/10/10 07:27, Jon Ciesla wrote: In my experience, git add the patch, fedpkg commit -p, fedpkg build. The tag is based on the git revision hash, so it's unique, no need to bump the EVR. Cool, thanks, will do. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On 5 October 2010 05:30, Orion Poplawski or...@cora.nwra.com wrote: Are we really stuck with gdm/kdm/lxdm/...dm implementing it? No, I think what we need to do is to teach GPM how to turn off the internal panel when docked and with the lid closed. The only missing piece is for the kernel to export some kind of sysfs boolean saying in-dock. From talks with mjg59, detecting a dock is pretty hard. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On 10/05/2010 10:35 AM, Richard Hughes wrote: No, I think what we need to do is to teach GPM how to turn off the internal panel when docked and with the lid closed. The only missing piece is for the kernel to export some kind of sysfs boolean saying in-dock. From talks with mjg59, detecting a dock is pretty hard. Sorry for my may be naive question: Why do we need to know if we are docked or not. Isn't there exactly the same situation if the external Monitor is directly connected to the laptop? If there is an external monitor and the lid is closed don't we want to switch off the display regardless whether there is a docking station involved or not? Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On 5 October 2010 09:55, FlorianFesti ffe...@redhat.com wrote: Sorry for my may be naive question: Why do we need to know if we are docked or not. Isn't there exactly the same situation if the external Monitor is directly connected to the laptop? If there is an external monitor and the lid is closed don't we want to switch off the display regardless whether there is a docking station involved or not? Well, I guess some people would want the laptop to suspend, but it's a very good question. Now all it needs is someone willing and able to write a little patch for me :-) Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Tue, Oct 5, 2010 at 11:22 AM, Richard Hughes hughsi...@gmail.com wrote: On 5 October 2010 09:55, FlorianFesti ffe...@redhat.com wrote: Sorry for my may be naive question: Why do we need to know if we are docked or not. Isn't there exactly the same situation if the external Monitor is directly connected to the laptop? If there is an external monitor and the lid is closed don't we want to switch off the display regardless whether there is a docking station involved or not? Well, I guess some people would want the laptop to suspend, but it's a very good question. Now all it needs is someone willing and able to write a little patch for me :-) For the Dell docking stations at least there is a power button on the dock and the general way they are used (in that this is the way it works with Windows) is that if the power button on the dock is used and the lid is closed (power button is above the keyboard) it uses the external monitor. I've no idea if its possible to differentiate which botton is used. This is the case in our off with Dell D series and E series Latitude and HP dock capable laptops. Peter -- 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 Tue, Oct 5, 2010 at 12:01 AM, Ralf Corsepius rc040...@freenet.de wrote: On 10/05/2010 12:37 AM, Adam Williamson wrote: On Mon, 2010-10-04 at 11:08 -0400, Brandon Lozza wrote: That's what i've been saying all day. It's only free software if you change the name, in which case you may loose brand recognition. Imagine if Linus forbid people from calling their OS Linux if they didn't use the binaries provided by him. that's the entire point of having trademarks. Free software projects are obliged to allow you to access and modify their code. They are not obliged to allow you to benefit from their reputation. Close source school of thinking - Trademarks exist to protect an enterprise's product and to close out copyiers. FLOSS exists to enable people to share. It doesn't make any sense to say 'I think this product needs to be modified but I wish to be able to represent my modified product as being the same thing as the original product in order to benefit from the reputation attached to the original product'. The overwhelming majority of FLOSS project think differently. They are proud of others picking up their works and to redistribute it. Or differently: GCC, KDE, QT, GNOME etc. all benefit from them not applying trademark restrictions, but from being used (in modified versions) on dozens of OSes, distributions etc. That said, Fedora's leadership is proud of having pushed Fedora into isolation. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Richard Stallman got back to me I think this is a problem, and FSF people are now studying the extent of similar restrictions. -- 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 Mon, Oct 4, 2010 at 6:37 PM, Adam Williamson awill...@redhat.com wrote: that's the entire point of having trademarks. Free software projects are obliged to allow you to access and modify their code. They are not obliged to allow you to benefit from their reputation. It doesn't make any sense to say 'I think this product needs to be modified but I wish to be able to represent my modified product as being the same thing as the original product in order to benefit from the reputation attached to the original product'. -- Trademarks defeat the purpose of it being free software. They impose restrictions. You have to remove MoFo's artwork and perform a name change or you're required to get permission from Mozilla to redistribute a modified binary. That's not free. At the same time does that logically effect the produced binary if we don't use the Firefox branding? I don't think the artwork and branding makes it any faster or more standards compliant or compatible with plugins. It would instantly remove the restrictions that make it unmaintainable. Adam Williamson Looks like RMS agrees too on the trademark issue. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20101005 changes
Compose started at Tue Oct 5 08:15:22 UTC 2010 Broken deps for x86_64 -- antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 bluefish-2.0.2-1.fc15.1.x86_64 requires libgucharmap.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 gambas2-gb-pdf-2.21.0-3.fc15.x86_64 requires libpoppler.so.7()(64bit) gearmand-0.13-2.fc14.x86_64 requires libmemcached.so.5()(64bit) gedit-plugins-2.31.6-1.fc15.x86_64 requires libgucharmap.so.7()(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) 1:gnome-applets-2.32.0-1.fc15.x86_64 requires libgucharmap.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-evince-2.31.1-7.fc14.x86_64 requires libevdocument.so.3()(64bit) gnome-python2-evince-2.31.1-7.fc14.x86_64 requires libevview.so.3()(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) gtranslator-1.9.11-3.fc14.x86_64 requires libgucharmap.so.7()(64bit) gucharmap-devel-2.33.0-1.fc15.i686 requires gtk2-devel = 0:2.91.0 gucharmap-devel-2.33.0-1.fc15.x86_64 requires gtk2-devel = 0:2.91.0 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) mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires mingw32(libpng-3.dll) 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) opensips-memcached-1.6.3-2.fc15.x86_64 requires libmemcached.so.5()(64bit) pdf2djvu-0.7.3-4.fc14.x86_64 requires libpoppler.so.7()(64bit) php-pecl-memcached-1.0.2-1.fc14.x86_64 requires libmemcached.so.5()(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) rakudo-0.0.2010.08_2.7.0-1.fc14.x86_64 requires libparrot.so.2.7.0()(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) spacewalk-certs-tools-1.1.1-2.1.fc15.noarch requires spacewalk-backend-libs = 0:0.8.28 stardict-3.0.1-21.fc13.x86_64 requires libgucharmap.so.7()(64bit) 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 -- antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 bluefish-2.0.2-1.fc15.1.i686 requires libgucharmap.so.7 clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) 0:1.3.0 gambas2-gb-pdf-2.21.0-3.fc15.i686 requires libpoppler.so.7 gearmand-0.13-2.fc14.i686 requires libmemcached.so.5 gedit-plugins-2.31.6-1.fc15.i686 requires libgucharmap.so.7 gloobus-preview-0.4.1-7.fc14.i686 requires libpoppler-glib.so.5 gloobus-preview-0.4.1-7.fc14.i686 requires libpoppler.so.7 1:gnome-applets-2.32.0-1.fc15.i686 requires libgucharmap.so.7 1:gnome-games-extra-2.31.91.1-1.fc15.i686 requires libclutter-gtk-0.10.so.0
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Mon, Oct 4, 2010 at 6:06 PM, Jesse Keating jkeat...@redhat.com wrote: We knew that this would happen. We would lose some people. When a project like us goes basically directionless for years it picks up people who have different ideas about what they want to create and where they want to go with it. When direction starts to happen, some of these people will find that they are not in line with where the project is going. This is one of the reasons why we make it so easy to take what we do and build from it or take it in a different direction. We welcome that. I've thought about it a lot and after looking at the competition i'm probably just going to stick it out and fork what I don't like. Thanks to Git, this will be super easy to maintain in my spare time. -- 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
Kevin Kofler wrote on 02.10.2010 00:56:
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.
Maybe I'm missed something, but there is a (relative) simple question
that always pops up in my head when I read things like this. I never
bothered to ask it in public, but I'll do now:
* Why haven't those that want iceweasel and icedove in Fedora not
simply invested some time and got them integrated into the repository?(¹)
It wouldn't be the first (albeit it likely would be the biggest) fork
where we also still ship the original (dd{,_}rescue comes to my mind),
hence I'd assume the packaging guidelines do not forbid something like
that. Or do they?
CU
knurd
P.S.: No, I'm not trying to shoot down the discussion, as it looks like
it's in its last stages already anyway
(¹) or was I simply to blind to find the review requests in bugzilla
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On 05/10/10 05:00 AM, Peter Robinson wrote: On Tue, Oct 5, 2010 at 11:22 AM, Richard Hughes hughsi...@gmail.com wrote: On 5 October 2010 09:55, FlorianFesti ffe...@redhat.com wrote: Sorry for my may be naive question: Why do we need to know if we are docked or not. Isn't there exactly the same situation if the external Monitor is directly connected to the laptop? If there is an external monitor and the lid is closed don't we want to switch off the display regardless whether there is a docking station involved or not? Well, I guess some people would want the laptop to suspend, but it's a very good question. Now all it needs is someone willing and able to write a little patch for me :-) For the Dell docking stations at least there is a power button on the dock and the general way they are used (in that this is the way it works with Windows) is that if the power button on the dock is used and the lid is closed (power button is above the keyboard) it uses the external monitor. I've no idea if its possible to differentiate which botton is used. This is the case in our off with Dell D series and E series Latitude and HP dock capable laptops. There's also the case used quite often in my company with Dell docking stations, where the lid is open and the user uses both external and internal display in multi-monitor setup. Another case, used more often, is two external monitors connected to the dock and closed lid in multi-monitor setup. Regards, Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On 05/10/10 07:09 AM, Nathaniel McCallum wrote: On 10/05/2010 09:02 AM, Dariusz J. Garbowski wrote: On 05/10/10 05:00 AM, Peter Robinson wrote: On Tue, Oct 5, 2010 at 11:22 AM, Richard Hughes hughsi...@gmail.com wrote: On 5 October 2010 09:55, FlorianFesti ffe...@redhat.com wrote: Sorry for my may be naive question: Why do we need to know if we are docked or not. Isn't there exactly the same situation if the external Monitor is directly connected to the laptop? If there is an external monitor and the lid is closed don't we want to switch off the display regardless whether there is a docking station involved or not? Well, I guess some people would want the laptop to suspend, but it's a very good question. Now all it needs is someone willing and able to write a little patch for me :-) For the Dell docking stations at least there is a power button on the dock and the general way they are used (in that this is the way it works with Windows) is that if the power button on the dock is used and the lid is closed (power button is above the keyboard) it uses the external monitor. I've no idea if its possible to differentiate which botton is used. This is the case in our off with Dell D series and E series Latitude and HP dock capable laptops. There's also the case used quite often in my company with Dell docking stations, where the lid is open and the user uses both external and internal display in multi-monitor setup. Another case, used more often, is two external monitors connected to the dock and closed lid in multi-monitor setup. The good news is that I'm pretty sure the dock is irrelevant (other than are we on battery power) in all those cases. The only thing that matters is which outputs are connected and what happens when the lid is closed. This seems like a cut-and-dry GPM policy issue. What about the case where we are on battery power and a projector or external monitor connected to the VGA port, no dock (with lid either open or closed for single or multi-monitor setup)? Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On 10/05/2010 09:12 AM, Dariusz J. Garbowski wrote: On 05/10/10 07:09 AM, Nathaniel McCallum wrote: On 10/05/2010 09:02 AM, Dariusz J. Garbowski wrote: On 05/10/10 05:00 AM, Peter Robinson wrote: On Tue, Oct 5, 2010 at 11:22 AM, Richard Hughes hughsi...@gmail.com wrote: On 5 October 2010 09:55, FlorianFesti ffe...@redhat.com wrote: Sorry for my may be naive question: Why do we need to know if we are docked or not. Isn't there exactly the same situation if the external Monitor is directly connected to the laptop? If there is an external monitor and the lid is closed don't we want to switch off the display regardless whether there is a docking station involved or not? Well, I guess some people would want the laptop to suspend, but it's a very good question. Now all it needs is someone willing and able to write a little patch for me :-) For the Dell docking stations at least there is a power button on the dock and the general way they are used (in that this is the way it works with Windows) is that if the power button on the dock is used and the lid is closed (power button is above the keyboard) it uses the external monitor. I've no idea if its possible to differentiate which botton is used. This is the case in our off with Dell D series and E series Latitude and HP dock capable laptops. There's also the case used quite often in my company with Dell docking stations, where the lid is open and the user uses both external and internal display in multi-monitor setup. Another case, used more often, is two external monitors connected to the dock and closed lid in multi-monitor setup. The good news is that I'm pretty sure the dock is irrelevant (other than are we on battery power) in all those cases. The only thing that matters is which outputs are connected and what happens when the lid is closed. This seems like a cut-and-dry GPM policy issue. What about the case where we are on battery power and a projector or external monitor connected to the VGA port, no dock (with lid either open or closed for single or multi-monitor setup)? If the lid is open, both output should be enabled by default (you are free to manually disable one). If the lid is closed on battery power the system should suspend (unless you choose otherwise in GPM prefs). Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 637110] perl-HTML-Encoding-0.61 is available
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=637110 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-HTML-Encoding-0.61-1.f ||c14 Resolution||ERRATA Last Closed||2010-10-05 09:16:23 -- 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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Command not found misfeature
On 2 October 2010 11:23, Richard Hughes hughsi...@gmail.com wrote: On 2 October 2010 09:51, Richard W.M. Jones rjo...@redhat.com wrote: ..., then (sometimes, not always) displays some sort of error[1]. Yes, it's fixed upstream, apologies. There's a new release on Monday which will be pushed to F14. https://admin.fedoraproject.org/updates/PackageKit-0.6.9-4.fc14 Please test and give karma. Thanks, Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Moose-1.14.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Moose: 99241b8e7b59e6c020e5f36e083ab23d Moose-1.14.tar.gz -- 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
File Class-MOP-1.08.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Class-MOP: 7d0bf52ba3689d9973f1631d894c83ca Class-MOP-1.08.tar.gz -- 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
[perl-Class-MOP] update to 1.08
commit 3a650b7cd85cf4b25519e4f4b52e30dc164dd649
Author: Iain Arnell iarn...@gmail.com
Date: Tue Oct 5 16:34:59 2010 +0200
update to 1.08
- new BR perl(Test::Requires) = 0.05
- new R/BR perl(Package::DeprecationManager) = 0.04
.gitignore |1 +
perl-Class-MOP.spec | 16 +++-
sources |2 +-
3 files changed, 13 insertions(+), 6 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 0d014c9..27beb0e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Class-MOP-1.03.tar.gz
+/Class-MOP-1.08.tar.gz
diff --git a/perl-Class-MOP.spec b/perl-Class-MOP.spec
index b6c6a47..236e7f5 100644
--- a/perl-Class-MOP.spec
+++ b/perl-Class-MOP.spec
@@ -1,10 +1,10 @@
Name: perl-Class-MOP
-Version:1.03
-Release:2%{?dist}
+Version:1.08
+Release:1%{?dist}
Summary:A Meta Object Protocol for Perl 5
License:GPL+ or Artistic
Group: Development/Libraries
-Source0:
http://search.cpan.org/CPAN/authors/id/F/FL/FLORA/Class-MOP-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/D/DR/DROLSKY/Class-MOP-%{version}.tar.gz
URL:http://search.cpan.org/dist/Class-MOP/
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
@@ -19,6 +19,7 @@ BuildRequires: perl(File::Spec)
BuildRequires: perl(List::MoreUtils) = 0.12
BuildRequires: perl(Module::Build)
BuildRequires: perl(MRO::Compat) = 0.05
+BuildRequires: perl(Package::DeprecationManager) = 0.04
BuildRequires: perl(Package::Stash)
BuildRequires: perl(Scalar::Util) = 1.18
BuildRequires: perl(Sub::Name) = 0.04
@@ -30,11 +31,11 @@ BuildRequires: perl(Test::More) = 0.88
BuildRequires: perl(Test::Output)
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(Test::Requires) = 0.05
BuildRequires: perl(Try::Tiny) = 0.02
-Requires: perl(Carp)
-Requires: perl(Devel::GlobalDestruction)
Requires: perl(MRO::Compat) = 0.05
+Requires: perl(Package::DeprecationManager) = 0.04
Requires: perl(Scalar::Util) = 1.18
Requires: perl(Sub::Name) = 0.04
Requires: perl(Task::Weaken)
@@ -92,6 +93,11 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Tue Oct 05 2010 Iain Arnell iarn...@gmail.com 1.08-1
+- update to latest upstream
+- new BR perl(Test::Requires) = 0.05
+- new R/BR perl(Package::DeprecationManager) = 0.04
+
* Mon Jul 12 2010 Dan Horák dan[at]danny.cz 1.03-2
- disable tests on s390(x)
diff --git a/sources b/sources
index 4a08503..dd41814 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-96b44730ae040c30d5e8e85b48e8cbe7 Class-MOP-1.03.tar.gz
+7d0bf52ba3689d9973f1631d894c83ca Class-MOP-1.08.tar.gz
--
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: Making Fedora work with laptops on docking station with external monitor
On 10/05/2010 03:15 PM, Nathaniel McCallum wrote: If the lid is open, both output should be enabled by default (you are free to manually disable one). If the lid is closed on battery power the system should suspend (unless you choose otherwise in GPM prefs). I wonder if there are latops that can be booted with lid closed and that make a subtle sematic difference between the lid was just being closed and is lid was already closed when we booted up. Florian -- 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 Tue, Oct 5, 2010 at 8:56 AM, Thorsten Leemhuis fed...@leemhuis.info wrote:
Maybe I'm missed something, but there is a (relative) simple question
that always pops up in my head when I read things like this. I never
bothered to ask it in public, but I'll do now:
* Why haven't those that want iceweasel and icedove in Fedora not
simply invested some time and got them integrated into the repository?(¹)
The issue at hand is that Mozilla will not give permission to use
system libs instead of bundled libs while calling it Firefox.
It wouldn't be the first (albeit it likely would be the biggest) fork
where we also still ship the original (dd{,_}rescue comes to my mind),
hence I'd assume the packaging guidelines do not forbid something like
that. Or do they?
It really wouldn't be a fork at all. From what I can tell it's a build
flag that can be enabled or disabled and automatically takes out the
trademark and copyright artwork. People just don't want to remove the
branding because they presume they know how end users think.
knurd
Brandon
--
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 5 October 2010 15:51, Brandon Lozza bran...@pwnage.ca wrote: It really wouldn't be a fork at all. From what I can tell it's a build flag that can be enabled or disabled and automatically takes out the trademark and copyright artwork. People just don't want to remove the branding because they presume they know how end users think. I know _for a fact_ my mum just looks for the orange little swirl. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Class-MOP/f14/master] update to 1.08
Summary of changes: 3a650b7... update to 1.08 (*) (*) 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: xulrunner 2.0 in rawhide (F15) bundles several system libs
On 10/05/2010 06:26 PM, Thorsten Leemhuis wrote:
Maybe I'm missed something, but there is a (relative) simple question
that always pops up in my head when I read things like this. I never
bothered to ask it in public, but I'll do now:
* Why haven't those that want iceweasel and icedove in Fedora not
simply invested some time and got them integrated into the repository?(¹)
It wouldn't be the first (albeit it likely would be the biggest) fork
where we also still ship the original (dd{,_}rescue comes to my mind),
hence I'd assume the packaging guidelines do not forbid something like
that. Or do they?
No but that would involve actual work rather than merely making the
claim that software licensed under GPL/MPL is non-free if it doesn't
allow the use of a name when patches are applied to it.
Rahul
--
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 Tue, Oct 5, 2010 at 2:34 PM, Brandon Lozza bran...@pwnage.ca wrote: On Mon, Oct 4, 2010 at 6:37 PM, Adam Williamson awill...@redhat.com wrote: that's the entire point of having trademarks. Free software projects are obliged to allow you to access and modify their code. They are not obliged to allow you to benefit from their reputation. It doesn't make any sense to say 'I think this product needs to be modified but I wish to be able to represent my modified product as being the same thing as the original product in order to benefit from the reputation attached to the original product'. -- Trademarks defeat the purpose of it being free software. They impose restrictions. You have to remove MoFo's artwork and perform a name change or you're required to get permission from Mozilla to redistribute a modified binary. So? That's not free. It is, as you are _free_ to change the name and artwork anytime you want. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
2010/10/5 Florian Festi: I wonder if there are latops that can be booted with lid closed and that make a subtle sematic difference between the lid was just being closed and is lid was already closed when we booted up. IBM ThinkPad T23. -- 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 Tue, 2010-10-05 at 08:34 -0400, Brandon Lozza wrote: On Mon, Oct 4, 2010 at 6:37 PM, Adam Williamson awill...@redhat.com wrote: that's the entire point of having trademarks. Free software projects are obliged to allow you to access and modify their code. They are not obliged to allow you to benefit from their reputation. It doesn't make any sense to say 'I think this product needs to be modified but I wish to be able to represent my modified product as being the same thing as the original product in order to benefit from the reputation attached to the original product'. -- Trademarks defeat the purpose of it being free software. They impose restrictions. The purpose of free software is not to have no restrictions. You have to remove MoFo's artwork and perform a name change or you're required to get permission from Mozilla to redistribute a modified binary. That's not free. Yes, it is. At the same time does that logically effect the produced binary if we don't use the Firefox branding? I don't think the artwork and branding makes it any faster or more standards compliant or compatible with plugins. It would instantly remove the restrictions that make it unmaintainable. Practically speaking, it would add an extra burden to the maintainers, who already do not have enough resources to deal with all the issues. Again, the reason we don't carry non-upstream patches in Firefox has nothing to do with the branding issue. It's because we don't have the resources to maintain non-upstream patches in Firefox. Looks like RMS agrees too on the trademark issue. It would help if you quoted what he actually wrote, rather than paraphrasing it. (You may also want to note that the GPLv3, whose drafting process happened long after the trademark issue was public currency for debate, places no restrictions on trademarking free software.) -- 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: Making Fedora work with laptops on docking station with external monitor
On 10/05/2010 11:21 AM, Christoph Frieben wrote: 2010/10/5 Florian Festi: I wonder if there are latops that can be booted with lid closed and that make a subtle sematic difference between the lid was just being closed and is lid was already closed when we booted up. IBM ThinkPad T23. Actually, pretty much any laptop in a dock can be booted with the lid down. It doesn't make any difference since the laptop screen should still be off. Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Moose] update to 1.14
commit 41a83cd84e2a800e4e8ef13b1ad98e699ca358b6
Author: Iain Arnell iarn...@gmail.com
Date: Tue Oct 5 17:25:38 2010 +0200
update to 1.14
- update BR perl(Class:MOP) = 1.05
- new BR perl(Test::Requires) = 0.05
- new R/BR perl(Package::DeprecationManager) = 0.04
.gitignore |1 +
perl-Moose.spec | 20
sources |2 +-
3 files changed, 14 insertions(+), 9 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 48f4c54..bfef820 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Moose-1.08.tar.gz
+/Moose-1.14.tar.gz
diff --git a/perl-Moose.spec b/perl-Moose.spec
index 97bcdfc..afcacd6 100644
--- a/perl-Moose.spec
+++ b/perl-Moose.spec
@@ -1,17 +1,17 @@
Name: perl-Moose
Summary:Complete modern object system for Perl 5
-Version:1.08
+Version:1.14
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
-Source0:
http://search.cpan.org/CPAN/authors/id/D/DO/DOY/Moose-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/D/DR/DROLSKY/Moose-%{version}.tar.gz
URL:http://search.cpan.org/dist/
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildRequires: perl(Carp)
#BuildRequires: perl(Class::ISA)
-BuildRequires: perl(Class::MOP) = 1.02
+BuildRequires: perl(Class::MOP) = 1.05
BuildRequires: perl(Data::OptList)
BuildRequires: perl(DateTime::Calendar::Mayan)
BuildRequires: perl(DateTime::Format::MySQL)
@@ -23,6 +23,7 @@ BuildRequires: perl(IO::File)
BuildRequires: perl(IO::String)
BuildRequires: perl(List::MoreUtils) = 0.12
BuildRequires: perl(Module::Refresh)
+BuildRequires: perl(Package::DeprecationManager) = 0.04
BuildRequires: perl(Params::Coerce)
BuildRequires: perl(Scalar::Util) = 1.19
BuildRequires: perl(Sub::Exporter) = 0.980
@@ -32,17 +33,14 @@ BuildRequires: perl(Test::Deep)
BuildRequires: perl(Test::Exception) = 0.27
BuildRequires: perl(Test::More) = 0.88
BuildRequires: perl(Test::Output)
+BuildRequires: perl(Test::Requires) = 0.05
BuildRequires: perl(Test::Warn)
BuildRequires: perl(Try::Tiny) = 0.02
BuildRequires: perl(URI)
-Requires: perl(Carp)
-Requires: perl(Class::MOP) = 0.98
-Requires: perl(Data::OptList)
Requires: perl(List::MoreUtils) = 0.12
+Requires: perl(Package::DeprecationManager) = 0.04
Requires: perl(Scalar::Util) = 1.19
-Requires: perl(Sub::Exporter) = 0.980
-Requires: perl(Sub::Name)
Requires: perl(Task::Weaken)
Requires: perl(Try::Tiny) = 0.02
@@ -113,6 +111,12 @@ rm -rf %{buildroot}
%{_mandir}/man3/Test::Moose*
%changelog
+* Tue Oct 05 2010 Iain Arnell iarn...@gmail.com 1.14-1
+- update to latest upstream version
+- update BR perl(Class:MOP) = 1.05
+- new BR perl(Test::Requires) = 0.05
+- new R/BR perl(Package::DeprecationManager) = 0.04
+
* Sat Jul 03 2010 Iain Arnell iarn...@gmail.com 1.08-1
- update to latest upstream
- update BR perl(Class:MOP) = 1.02
diff --git a/sources b/sources
index 7773670..9cb11a3 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-1718719e7409b6ad16912382b5ea64ae Moose-1.08.tar.gz
+99241b8e7b59e6c020e5f36e083ab23d Moose-1.14.tar.gz
--
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: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Tue, Oct 5, 2010 at 11:22 AM, Adam Williamson awill...@redhat.com wrote: You have to remove MoFo's artwork and perform a name change or you're required to get permission from Mozilla to redistribute a modified binary. That's not free. Yes, it is. In a sense that you're free to do whatever Mozilla says, then yes, it's free. Practically speaking, it would add an extra burden to the maintainers, who already do not have enough resources to deal with all the issues. Again, the reason we don't carry non-upstream patches in Firefox has nothing to do with the branding issue. It's because we don't have the resources to maintain non-upstream patches in Firefox. Extra burden to do their assigned jobs? It's Fedora policy not to include bundled libraries. They should already be removing bundled libraries, and replacing those requirements with system libraries. Just like with ALL OF THE OTHER PACKAGES which do not violate policy. This isn't extra, its minimum. The only extra work they need to do is maybe think of a name to call it instead of Firefox, and then implementing the compile time switch. No forking, and it won't be hard to stay with upstream because you're not forking you're just renaming and making it use system libraries. Spot does this _by himself_ with Chromium, which is a lot more advanced/complex than Firefox (Google is known well for forking and bundling libs). They would then, according to fulfill policy, have to remove the trademark code that is restricting them from using system libs in Firefox instead of bundled libs. Or grant an exceptiion, but why do they get red carpet treatment when they are being so uncooperative? Looks like RMS agrees too on the trademark issue. It would help if you quoted what he actually wrote, rather than paraphrasing it. (You may also want to note that the GPLv3, whose drafting process happened long after the trademark issue was public currency for debate, places no restrictions on trademarking free software.) Sure but I hope its not spam: Delivered-To: bran...@pwnage.ca Received: by 10.239.131.66 with SMTP id 2cs6683hbm; Tue, 5 Oct 2010 02:55:35 -0700 (PDT) Received: by 10.224.45.142 with SMTP id e14mr8020171qaf.117.1286272534057; Tue, 05 Oct 2010 02:55:34 -0700 (PDT) Return-Path: r...@gnu.org Received: from fencepost.gnu.org (fencepost.gnu.org [140.186.70.10]) by mx.google.com with ESMTP id u2si11294263qcq.19.2010.10.05.02.55.33; Tue, 05 Oct 2010 02:55:34 -0700 (PDT) Received-SPF: pass (google.com: domain of r...@gnu.org designates 140.186.70.10 as permitted sender) client-ip=140.186.70.10; Authentication-Results: mx.google.com; spf=pass (google.com: domain of r...@gnu.org designates 140.186.70.10 as permitted sender) smtp.mail=...@gnu.org Received: from rms by fencepost.gnu.org with local (Exim 4.69) (envelope-from r...@gnu.org) id 1P34FB-0003dw-0z; Tue, 05 Oct 2010 05:55:33 -0400 Content-Type: text/plain; charset=ISO-8859-15 From: Richard Stallman r...@gnu.org To: Brandon Lozza bran...@pwnage.ca In-reply-to: aanlkti=whj55xtdwfpfxylzuuccyrgqdjwedlkdsv...@mail.gmail.com (message from Brandon Lozza on Mon, 4 Oct 2010 09:26:34 -0400) Subject: Re: Trademarks make software nonfree? Reply-to: r...@gnu.org References: aanlkti=whj55xtdwfpfxylzuuccyrgqdjwedlkdsv...@mail.gmail.com Message-Id: e1p34fb-0003dw...@fencepost.gnu.org Date: Tue, 05 Oct 2010 05:55:33 -0400 I was wondering if Mozilla's trademark on the name Firefox makes the software non free. According to Mozilla you can't redistribute your own product called Firefox if you make changes to the source code, unless you want to violate trademark law. I think this is a problem, and FSF people are now studying the extent of similar restrictions. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-14 Branched report: 20101005 changes
Compose started at Tue Oct 5 13:15:37 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 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 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) 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 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 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 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.i686 requires libMagickCore.so.3 php-pecl-imagick-3.0.0-7.fc14.i686 requires libMagickWand.so.3 planner-eds-0.14.4-25.fc14.i686 requires libcamel-provider-1.2.so.18 planner-eds-0.14.4-25.fc14.i686 requires libedata-cal-1.2.so.8 planner-eds-0.14.4-25.fc14.i686 requires libcamel-1.2.so.18 qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18 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 wfut-1.1.0-8.fc12.i686 requires libgcj.so.10 New package: gappa-0.13.0-4.fc14 Prove programs with floating-point or fixed-point arithmetic New package: ghc-Boolean-0.0.1-1.fc14 Generalized booleans New package: gnome-video-effects-0.1.0-1.fc14 Collection of GStreamer video effects New package: libmutil-0.8.0-0.3.20100319svn3760.fc14.1 Minisip library providing various C++
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Tue, Oct 5, 2010 at 10:58 AM, Rahul Sundaram methe...@gmail.com wrote:
On 10/05/2010 06:26 PM, Thorsten Leemhuis wrote:
Maybe I'm missed something, but there is a (relative) simple question
that always pops up in my head when I read things like this. I never
bothered to ask it in public, but I'll do now:
* Why haven't those that want iceweasel and icedove in Fedora not
simply invested some time and got them integrated into the repository?(¹)
It wouldn't be the first (albeit it likely would be the biggest) fork
where we also still ship the original (dd{,_}rescue comes to my mind),
hence I'd assume the packaging guidelines do not forbid something like
that. Or do they?
No but that would involve actual work rather than merely making the
claim that software licensed under GPL/MPL is non-free if it doesn't
allow the use of a name when patches are applied to it.
Rahul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
I don't blanket label everything with open code as free software.
Some stuff bundles things which make it non-free. Code open-ness !=
free. You can call Firefox open source if you want, but it's not free
software.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On 10/05/2010 02:35 AM, Richard Hughes wrote: On 5 October 2010 05:30, Orion Poplawskior...@cora.nwra.com wrote: Are we really stuck with gdm/kdm/lxdm/...dm implementing it? No, I think what we need to do is to teach GPM how to turn off the internal panel when docked and with the lid closed. The only missing piece is for the kernel to export some kind of sysfs boolean saying in-dock. From talks with mjg59, detecting a dock is pretty hard. Richard. By GPM I'm guessing you mean gnome-power-manager? So each desktop environment needs to implement this? Does gpm run before login so that it is configured properly at login time? Who's needs handle it for KDE, LXDE, XFCE, etc.? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- 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 Tue, 2010-10-05 at 11:42 -0400, Brandon Lozza wrote: On Tue, Oct 5, 2010 at 11:22 AM, Adam Williamson awill...@redhat.com wrote: You have to remove MoFo's artwork and perform a name change or you're required to get permission from Mozilla to redistribute a modified binary. That's not free. Yes, it is. In a sense that you're free to do whatever Mozilla says, then yes, it's free. No, in the sense that it meets the definition of software freedom. Which is what we ought to be talking about here, as a debate about 'freedom' as a philosophical concept is something I don't have time for this century. Practically speaking, it would add an extra burden to the maintainers, who already do not have enough resources to deal with all the issues. Again, the reason we don't carry non-upstream patches in Firefox has nothing to do with the branding issue. It's because we don't have the resources to maintain non-upstream patches in Firefox. Extra burden to do their assigned jobs? It's Fedora policy not to include bundled libraries. They should already be removing bundled libraries, and replacing those requirements with system libraries. Just like with ALL OF THE OTHER PACKAGES which do not violate policy. This isn't extra, its minimum. The only extra work they need to do is maybe think of a name to call it instead of Firefox, and then implementing the compile time switch. No forking, and it won't be hard to stay with upstream because you're not forking you're just renaming and making it use system libraries. Spot does this _by himself_ with Chromium, which is a lot more advanced/complex than Firefox (Google is known well for forking and bundling libs). I think you're unnecessarily muddying up a simple practical discussion (how do we go about getting these bundled libs removed) with overheated ideological rhetoric, and it really isn't helping anyone get anything done. Sure but I hope its not spam: I was wondering if Mozilla's trademark on the name Firefox makes the software non free. According to Mozilla you can't redistribute your own product called Firefox if you make changes to the source code, unless you want to violate trademark law. I think this is a problem, and FSF people are now studying the extent of similar restrictions. So, he doesn't actually answer the question, there. RH legal has asked the question before and got a direct yes/no answer, and the answer is no, it does not make the software non-free. -- 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: Making Fedora work with laptops on docking station with external monitor
On Tue, 2010-10-05 at 09:35 +0100, Richard Hughes wrote: On 5 October 2010 05:30, Orion Poplawski or...@cora.nwra.com wrote: Are we really stuck with gdm/kdm/lxdm/...dm implementing it? No, I think what we need to do is to teach GPM how to turn off the internal panel when docked and with the lid closed. The only missing piece is for the kernel to export some kind of sysfs boolean saying in-dock. From talks with mjg59, detecting a dock is pretty hard. Maybe just 'lid closed and external monitor connected' would be close enough? Is there a use case where you'd want to have an external monitor connected and the internal system's lid closed, but still have the internal system's display turned on? -- 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: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Tue, Oct 5, 2010 at 9:16 PM, Brandon Lozza wrote: I don't blanket label everything with open code as free software. Some stuff bundles things which make it non-free. Code open-ness != free. You can call Firefox open source if you want, but it's not free software. You claimed that FSF will back your assertions and so far they haven't made any determination. We will revisit this issue when they do. Until then, just move on. You are not going to influence Fedora's policies by repeating yourself endlessly. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On 10/05/2010 11:53 AM, Adam Williamson wrote: On Tue, 2010-10-05 at 09:35 +0100, Richard Hughes wrote: On 5 October 2010 05:30, Orion Poplawski or...@cora.nwra.com wrote: Are we really stuck with gdm/kdm/lxdm/...dm implementing it? No, I think what we need to do is to teach GPM how to turn off the internal panel when docked and with the lid closed. The only missing piece is for the kernel to export some kind of sysfs boolean saying in-dock. From talks with mjg59, detecting a dock is pretty hard. Maybe just 'lid closed and external monitor connected' would be close enough? Is there a use case where you'd want to have an external monitor connected and the internal system's lid closed, but still have the internal system's display turned on? FYI, doing so could damage the laptop. Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On 10/05/2010 09:53 AM, Adam Williamson wrote: On Tue, 2010-10-05 at 09:35 +0100, Richard Hughes wrote: On 5 October 2010 05:30, Orion Poplawskior...@cora.nwra.com wrote: Are we really stuck with gdm/kdm/lxdm/...dm implementing it? No, I think what we need to do is to teach GPM how to turn off the internal panel when docked and with the lid closed. The only missing piece is for the kernel to export some kind of sysfs boolean saying in-dock. From talks with mjg59, detecting a dock is pretty hard. Maybe just 'lid closed and external monitor connected' would be close enough? Is there a use case where you'd want to have an external monitor connected and the internal system's lid closed, but still have the internal system's display turned on? Yeah, I think this is the main issue. It can cause two problems: - The login screen appears on the laptop screen (which is closed) - New windows or the desktop toolbar appear on the laptop screen (which is closed) I think the fun will come from systems that don't properly report their lid status. I think this is one of the complaints from the X developers. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
not sure how to fix locale packaging
mercurial has hard-wired to install .mo files under python_sitearch, and i18n.py has hard-coded to look there. On fedora, find-lang.sh is usually used to find these files, but expects to find them in e.g., /usr/share/locale Not sure what's the best way to fix this. Either leave .mo files where mercurial expects them, and replace find-lang.sh, or move them to /usr/share/locale and patch i18n.py -- 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 Tue, Oct 5, 2010 at 5:42 PM, Brandon Lozza bran...@pwnage.ca wrote: On Tue, Oct 5, 2010 at 11:22 AM, Adam Williamson awill...@redhat.com wrote: You have to remove MoFo's artwork and perform a name change or you're required to get permission from Mozilla to redistribute a modified binary. That's not free. Yes, it is. In a sense that you're free to do whatever Mozilla says, then yes, it's free. By your logic pretty much every software is non free. $insertgplprogramm ... I cannot link it against proprietary software which makes it non free. $randombsdlicensedprogram ... I cannot remove that damned copyright notice ? Thats a restriction its non free. But I digress. (Just wanted to show that the claim it has restrictions and thus is non free is nonsense). But anyway in case you missed it trademarks and copyright are entirely different things. The whole free software concept applies to the _later_ NOT the former. -- 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 Tue, Oct 05, 2010 at 02:56:34PM +0200, Thorsten Leemhuis wrote:
Kevin Kofler wrote on 02.10.2010 00:56:
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.
Maybe I'm missed something, but there is a (relative) simple question
that always pops up in my head when I read things like this. I never
bothered to ask it in public, but I'll do now:
* Why haven't those that want iceweasel and icedove in Fedora not
simply invested some time and got them integrated into the repository?(¹)
It wouldn't be the first (albeit it likely would be the biggest) fork
where we also still ship the original (dd{,_}rescue comes to my mind),
hence I'd assume the packaging guidelines do not forbid something like
that. Or do they?
IIRC this has come up on the mailing lists before and the mozilla
maintainers didn't want to have the fork in Fedora. However, there is no
packaging guideline that would prevent this. As a member of the FPC (but
not FESCo, where a conflict over this might ultimately go), I would be for
allowing such a package if someone wanted to package it for review.
-Toshio
pgphLaOhxMSWW.pgp
Description: PGP signature
--
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 Tue, Oct 05, 2010 at 08:22:57AM -0700, Adam Williamson wrote: On Tue, 2010-10-05 at 08:34 -0400, Brandon Lozza wrote: On Mon, Oct 4, 2010 at 6:37 PM, Adam Williamson awill...@redhat.com wrote: that's the entire point of having trademarks. Free software projects are obliged to allow you to access and modify their code. They are not obliged to allow you to benefit from their reputation. It doesn't make any sense to say 'I think this product needs to be modified but I wish to be able to represent my modified product as being the same thing as the original product in order to benefit from the reputation attached to the original product'. -- Trademarks defeat the purpose of it being free software. They impose restrictions. The purpose of free software is not to have no restrictions. You have to remove MoFo's artwork and perform a name change or you're required to get permission from Mozilla to redistribute a modified binary. That's not free. Yes, it is. At the same time does that logically effect the produced binary if we don't use the Firefox branding? I don't think the artwork and branding makes it any faster or more standards compliant or compatible with plugins. It would instantly remove the restrictions that make it unmaintainable. Practically speaking, it would add an extra burden to the maintainers, who already do not have enough resources to deal with all the issues. Again, the reason we don't carry non-upstream patches in Firefox has nothing to do with the branding issue. It's because we don't have the resources to maintain non-upstream patches in Firefox. I wish people would stop repeating this particular bit of justification for the issue of bundling libraries. I can see it for other suggested patches for firefox but in the case of bundled libraries, this is work that we require of all packages because there's security ramifications for our product, the Fedora distribution by not unbundling. We require other packages to come up with the maintainership resources to unbundle the included libraries if this is found at review otherwise they don't get into Fedora. If this is found post-review, we don't require the maintainer to fix this immediately but we do require them to apply a patch to fix the issue if someone else provides one and we strongly encourage them to fix it themselves if they have the know-how. -Toshio pgpphsJkxsHkc.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Tue, 2010-10-05 at 09:59 -0600, Orion Poplawski wrote: Yeah, I think this is the main issue. It can cause two problems: - The login screen appears on the laptop screen (which is closed) - New windows or the desktop toolbar appear on the laptop screen (which is closed) I think the fun will come from systems that don't properly report their lid status. I think this is one of the complaints from the X developers. *shrug* those are separate bugs we can fix once we make the actual behaviour correct. -- 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: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Tue, 2010-10-05 at 13:14 -0400, Toshio Kuratomi wrote: Practically speaking, it would add an extra burden to the maintainers, who already do not have enough resources to deal with all the issues. Again, the reason we don't carry non-upstream patches in Firefox has nothing to do with the branding issue. It's because we don't have the resources to maintain non-upstream patches in Firefox. I wish people would stop repeating this particular bit of justification for the issue of bundling libraries. I can see it for other suggested patches for firefox but in the case of bundled libraries, this is work that we require of all packages because there's security ramifications for our product, the Fedora distribution by not unbundling. That wasn't my intention. The debate seemed to have broadened from the issue of the bundled libraries out to become the tired old 'Firefox is non-free oh noes' thread again. -- 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: not sure how to fix locale packaging
On Tue, Oct 05, 2010 at 11:59:44AM -0400, Neal Becker wrote: mercurial has hard-wired to install .mo files under python_sitearch, and i18n.py has hard-coded to look there. On fedora, find-lang.sh is usually used to find these files, but expects to find them in e.g., /usr/share/locale Not sure what's the best way to fix this. Either leave .mo files where mercurial expects them, and replace find-lang.sh, or move them to /usr/share/locale and patch i18n.py Move to /usr/share/locale and patch i18n.py. If you make the patch first look in the place that upstream ships them and then in /usr/share/locale if that fails, upstreams have generally been receptive to taking such patches. -Toshio pgpzbDKsCjXzV.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please Review: (625335) default Enable self write for common attributes aci has permission to invalid attribute
https://bugzilla.redhat.com/show_bug.cgi?id=625335 https://bugzilla.redhat.com/attachment.cgi?id=451735action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: xulrunner 2.0 in rawhide (F15) bundles several system libs
On Tue, 2010-10-05 at 11:46 -0400, Brandon Lozza wrote: I don't blanket label everything with open code as free software. Some stuff bundles things which make it non-free. Code open-ness != free. You can call Firefox open source if you want, but it's not free software. You certainly have the right to interpret those words however you like, but over here in consensus reality, that's not what they mean. I would request that you limit your discussions on the development list to topics relevant to Fedora development. You seem instead to be talking about a rather well-hashed point of international trademark law that's not going to get resolved anytime soon, regardless of how fervently you might wish it. - ajax 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: Making Fedora work with laptops on docking station with external monitor
On Tue, Oct 05, 2010 at 08:53:12AM -0700, Adam Williamson wrote: Maybe just 'lid closed and external monitor connected' would be close enough? Is there a use case where you'd want to have an external monitor connected and the internal system's lid closed, but still have the internal system's display turned on? No, but there is a use case where you'd want to have an external monitor connected and the system report that the lid is closed, but still have the internal system's display turned on. Hardware lies. -- 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
On Mon, Oct 4, 2010 at 09:24, Brandon Lozza bran...@pwnage.ca wrote: On Mon, Oct 4, 2010 at 11:14 AM, Rahul Sundaram methe...@gmail.com wrote: I'll refrain from replying further on until I have a reply from Richard, but you're totally wrong and your love for Firefox is blinding your principals (if you have any). You would STILL HAVE the Brandon that was un called for and not excellent to each other. Please take this off list and come back when your temper is under control. -- Stephen J Smoogen. “The core skill of innovators is error recovery, not failure avoidance.” Randy Nelson, President of Pixar University. We have a strategic plan. It's called doing things. — Herb Kelleher, founder Southwest Airlines -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Tue, Oct 05, 2010 at 10:19:04AM -0700, Adam Williamson wrote: On Tue, 2010-10-05 at 09:59 -0600, Orion Poplawski wrote: I think the fun will come from systems that don't properly report their lid status. I think this is one of the complaints from the X developers. *shrug* those are separate bugs we can fix once we make the actual behaviour correct. Bugs where we turn off people's displays when they're trying to use them are things that we should address at the start of the development process, not the end. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Tue, 2010-10-05 at 19:05 +0100, Matthew Garrett wrote: On Tue, Oct 05, 2010 at 08:53:12AM -0700, Adam Williamson wrote: Maybe just 'lid closed and external monitor connected' would be close enough? Is there a use case where you'd want to have an external monitor connected and the internal system's lid closed, but still have the internal system's display turned on? No, but there is a use case where you'd want to have an external monitor connected and the system report that the lid is closed, but still have the internal system's display turned on. Hardware lies. that is a hardware/kernel/acpi bug. The appropriate way to fix it, IMHO, is to have the sensor report the correct information if it's at all possible to fix it in the kernel/acpi layer, or if not, blacklist that specific system so that its lid sensor is completely ignored. -- 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: Making Fedora work with laptops on docking station with external monitor
On 10/05/2010 02:16 PM, Adam Williamson wrote: On Tue, 2010-10-05 at 19:05 +0100, Matthew Garrett wrote: On Tue, Oct 05, 2010 at 08:53:12AM -0700, Adam Williamson wrote: Maybe just 'lid closed and external monitor connected' would be close enough? Is there a use case where you'd want to have an external monitor connected and the internal system's lid closed, but still have the internal system's display turned on? No, but there is a use case where you'd want to have an external monitor connected and the system report that the lid is closed, but still have the internal system's display turned on. Hardware lies. that is a hardware/kernel/acpi bug. The appropriate way to fix it, IMHO, is to have the sensor report the correct information if it's at all possible to fix it in the kernel/acpi layer, or if not, blacklist that specific system so that its lid sensor is completely ignored. Agreed, the hardware may lie, but the kernel is the arbiter of truth, at least in this case. Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Tue, 2010-10-05 at 19:07 +0100, Matthew Garrett wrote: On Tue, Oct 05, 2010 at 10:19:04AM -0700, Adam Williamson wrote: On Tue, 2010-10-05 at 09:59 -0600, Orion Poplawski wrote: I think the fun will come from systems that don't properly report their lid status. I think this is one of the complaints from the X developers. *shrug* those are separate bugs we can fix once we make the actual behaviour correct. Bugs where we turn off people's displays when they're trying to use them are things that we should address at the start of the development process, not the end. don't we already have default behaviours based on the lid switch, anyway? So why don't we have this problem with those? IIRC, we default to suspending the system when the lid is closed on battery power - so are we suspending people's systems at random, if those systems have lying lid switches? -- 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: Making Fedora work with laptops on docking station with external monitor
On Tue, Oct 05, 2010 at 11:16:44AM -0700, Adam Williamson wrote: On Tue, 2010-10-05 at 19:05 +0100, Matthew Garrett wrote: No, but there is a use case where you'd want to have an external monitor connected and the system report that the lid is closed, but still have the internal system's display turned on. Hardware lies. that is a hardware/kernel/acpi bug. The appropriate way to fix it, IMHO, is to have the sensor report the correct information if it's at all possible to fix it in the kernel/acpi layer, or if not, blacklist that specific system so that its lid sensor is completely ignored. I wholeheartedly agree, providing that we can obtain a list of every piece of hardware that has this issue, along with a list of every piece of hardware that will have it in future. If that's not available then userspace is just going to have to deal. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Tue, Oct 05, 2010 at 11:18:32AM -0700, Adam Williamson wrote: don't we already have default behaviours based on the lid switch, anyway? So why don't we have this problem with those? IIRC, we default to suspending the system when the lid is closed on battery power - so are we suspending people's systems at random, if those systems have lying lid switches? Because we only do that on lid state transitions. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On 10/05/2010 12:18 PM, Adam Williamson wrote: On Tue, 2010-10-05 at 19:07 +0100, Matthew Garrett wrote: On Tue, Oct 05, 2010 at 10:19:04AM -0700, Adam Williamson wrote: On Tue, 2010-10-05 at 09:59 -0600, Orion Poplawski wrote: I think the fun will come from systems that don't properly report their lid status. I think this is one of the complaints from the X developers. *shrug* those are separate bugs we can fix once we make the actual behaviour correct. Bugs where we turn off people's displays when they're trying to use them are things that we should address at the start of the development process, not the end. don't we already have default behaviours based on the lid switch, anyway? So why don't we have this problem with those? IIRC, we default to suspending the system when the lid is closed on battery power - so are we suspending people's systems at random, if those systems have lying lid switches? Generally those are based on a change of lid state, which may be different. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 640399] New: Bundled library in mldonkey - ocaml-bitstring
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Bundled library in mldonkey - ocaml-bitstring https://bugzilla.redhat.com/show_bug.cgi?id=640399 Summary: Bundled library in mldonkey - ocaml-bitstring Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: mldonkey AssignedTo: lemen...@gmail.com ReportedBy: lemen...@gmail.com QAContact: extras...@fedoraproject.org CC: rjo...@redhat.com, lemen...@gmail.com, fedora-ocaml-l...@redhat.com Classification: Fedora See src/utils/bitstring -- 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: Making Fedora work with laptops on docking station with external monitor
On Tue, Oct 05, 2010 at 02:18:20PM -0400, Nathaniel McCallum wrote: Agreed, the hardware may lie, but the kernel is the arbiter of truth, at least in this case. The range of ways that lid switches can be broken is large. One machine I've seen tries to read from a GPIO that's off by 16, because Intel's GPIO/GPE numbering is complicated. Another generates an event on lid close and generates a different event on lid open, but there's no handler for the open event and so the state variable never gets updated. The world is full of bad hardware and the kernel can't always be there to shield userspace from reality. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On 10/05/2010 02:25 PM, Matthew Garrett wrote: On Tue, Oct 05, 2010 at 02:18:20PM -0400, Nathaniel McCallum wrote: Agreed, the hardware may lie, but the kernel is the arbiter of truth, at least in this case. The range of ways that lid switches can be broken is large. One machine I've seen tries to read from a GPIO that's off by 16, because Intel's GPIO/GPE numbering is complicated. Another generates an event on lid close and generates a different event on lid open, but there's no handler for the open event and so the state variable never gets updated. The world is full of bad hardware and the kernel can't always be there to shield userspace from reality. Of course, but where possible it should sanitize. Userspace is like a teenager, you expose them to just enough reality to know what's out there, but in general they have no idea just how scary it really is. :) Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Tue, 2010-10-05 at 19:20 +0100, Matthew Garrett wrote: On Tue, Oct 05, 2010 at 11:18:32AM -0700, Adam Williamson wrote: don't we already have default behaviours based on the lid switch, anyway? So why don't we have this problem with those? IIRC, we default to suspending the system when the lid is closed on battery power - so are we suspending people's systems at random, if those systems have lying lid switches? Because we only do that on lid state transitions. So we could at least cover the case where you plug in an external monitor, then close the lid? That would be better than nothing. I assume the problem case is booting with the lid closed and an external monitor connected. -- 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: Making Fedora work with laptops on docking station with external monitor
On Tue, Oct 5, 2010 at 7:28 PM, Adam Williamson awill...@redhat.com wrote: On Tue, 2010-10-05 at 19:20 +0100, Matthew Garrett wrote: On Tue, Oct 05, 2010 at 11:18:32AM -0700, Adam Williamson wrote: don't we already have default behaviours based on the lid switch, anyway? So why don't we have this problem with those? IIRC, we default to suspending the system when the lid is closed on battery power - so are we suspending people's systems at random, if those systems have lying lid switches? Because we only do that on lid state transitions. So we could at least cover the case where you plug in an external monitor, then close the lid? That would be better than nothing. I assume the problem case is booting with the lid closed and an external monitor connected. The BIOS generally manages to get that one correct, can we not query and keep the current state on boot? Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Tue, Oct 05, 2010 at 02:27:27PM -0400, Nathaniel McCallum wrote: On 10/05/2010 02:25 PM, Matthew Garrett wrote: The range of ways that lid switches can be broken is large. One machine I've seen tries to read from a GPIO that's off by 16, because Intel's GPIO/GPE numbering is complicated. Another generates an event on lid close and generates a different event on lid open, but there's no handler for the open event and so the state variable never gets updated. The world is full of bad hardware and the kernel can't always be there to shield userspace from reality. Of course, but where possible it should sanitize. Userspace is like a teenager, you expose them to just enough reality to know what's out there, but in general they have no idea just how scary it really is. :) And it's not possible to sanitise in 100% of cases here, so userspace has to cope with the breakage. And if userspace has to cope, there's no point in sanitising any of it. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Tue, Oct 05, 2010 at 07:31:54PM +0100, Peter Robinson wrote: On Tue, Oct 5, 2010 at 7:28 PM, Adam Williamson awill...@redhat.com wrote: So we could at least cover the case where you plug in an external monitor, then close the lid? That would be better than nothing. I assume the problem case is booting with the lid closed and an external monitor connected. The BIOS generally manages to get that one correct, can we not query and keep the current state on boot? It really doesn't. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Tue, Oct 5, 2010 at 7:36 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Tue, Oct 05, 2010 at 07:31:54PM +0100, Peter Robinson wrote: On Tue, Oct 5, 2010 at 7:28 PM, Adam Williamson awill...@redhat.com wrote: So we could at least cover the case where you plug in an external monitor, then close the lid? That would be better than nothing. I assume the problem case is booting with the lid closed and an external monitor connected. The BIOS generally manages to get that one correct, can we not query and keep the current state on boot? It really doesn't. Seems to work just fine from a user perspective. Not that I ever use it like that as I use my laptop as a second screen but of an office of 100% laptops I would think about 50% of the 100 or so people on my floor use it as such. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Tue, Oct 05, 2010 at 07:53:25PM +0100, Peter Robinson wrote: On Tue, Oct 5, 2010 at 7:36 PM, Matthew Garrett mj...@srcf.ucam.org wrote: The BIOS generally manages to get that one correct, can we not query and keep the current state on boot? It really doesn't. Seems to work just fine from a user perspective. Not that I ever use it like that as I use my laptop as a second screen but of an office of 100% laptops I would think about 50% of the 100 or so people on my floor use it as such. There's a *lot* of machines that consistently report an incorrect state. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making Fedora work with laptops on docking station with external monitor
On Tue, Oct 5, 2010 at 8:00 PM, Matthew Garrett mj...@srcf.ucam.org wrote: On Tue, Oct 05, 2010 at 07:53:25PM +0100, Peter Robinson wrote: On Tue, Oct 5, 2010 at 7:36 PM, Matthew Garrett mj...@srcf.ucam.org wrote: The BIOS generally manages to get that one correct, can we not query and keep the current state on boot? It really doesn't. Seems to work just fine from a user perspective. Not that I ever use it like that as I use my laptop as a second screen but of an office of 100% laptops I would think about 50% of the 100 or so people on my floor use it as such. There's a *lot* of machines that consistently report an incorrect state. That would be about 500 across Europe then :-P unfortunately probably only 5-10% run linux but happily Fedora seems to be the one that people have best luck with over the other alternatives (including using evolution with exchange). Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Quick question on building f14 isos?
For the past year or so I have built private builds of current Fedora install isos on an old test machine running f11 using mock/pungi, and this has generally worked well for me. I use this method to get fully up to date isos for installs that need almost no updates applying for the current stable Fedora version, but also I build my own test isos in the run-up to a new release based on the current packages in the development repo. I know that the machine on which I build should be updated to a newer version - but time is against me due to other commitments (my fault!) Anyway I tried to build f14 isos on this machine which currently runs f11 (shameful I know!), and I got lots of kernel too old lines in the terminal when creating the initial mock area when preparing for the build of f14. I guess I can't use an f11 machine to build f14 DVD install isos? If so do I need to run the mock/pungi build for f14 in an f13 machine, or will a machine running f12 work also? Thanks in advance if you can help me out on this one. -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Quick question on building f14 isos?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/5/10 12:59 PM, mike cloaked wrote: For the past year or so I have built private builds of current Fedora install isos on an old test machine running f11 using mock/pungi, and this has generally worked well for me. I use this method to get fully up to date isos for installs that need almost no updates applying for the current stable Fedora version, but also I build my own test isos in the run-up to a new release based on the current packages in the development repo. I know that the machine on which I build should be updated to a newer version - but time is against me due to other commitments (my fault!) Anyway I tried to build f14 isos on this machine which currently runs f11 (shameful I know!), and I got lots of kernel too old lines in the terminal when creating the initial mock area when preparing for the build of f14. I guess I can't use an f11 machine to build f14 DVD install isos? If so do I need to run the mock/pungi build for f14 in an f13 machine, or will a machine running f12 work also? Thanks in advance if you can help me out on this one. There was a change in glibc during the F14 development cycle that requires running a newer kernel in order to run the f14 binaries. You could probably cheat a new kernel onto F11 and then do the pungi compose in a mock chroot of f14 content (I do all the pungi runs in mock chroots anyway). - -- 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/ iEYEARECAAYFAkyrhxoACgkQ4v2HLvE71NXbgwCeJVLVwS0pkNTAvg74ffkvqUzj Ua8AoIHDSn69GYmih/3gaVypWM2ZTXWL =6EOV -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Chain builds for non-rawhide
Hi, I am maintaining eclipse-egit and eclipse-jgit. Since eclipse-egit depends on eclipse-jgit it makes sense to use chain-builds when building them (this is simply faster than waiting for eclipse-jgit to build, and become available in the repos before eclipse-git can be built). Ok, that works for rawhide. Unfortunately this isn't possible for non-rawhide releases. I could start speculating and think of reasons as to why that's the case, but rather ask the more knowledgeable :) So, what were the reasons for not allowing chain-builds for non-rawhide? Many thanks! Severin P.S.: The error message: Could not initiate build: Packages in destination tag dist-f14-updates-candidate are not inherited bybuild tag dist-f14-build doesn't mean much to me. Perhaps an error message indicating that chain-build is not available would be more meaningful. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Chain builds for non-rawhide
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/5/10 1:36 PM, Severin Gehwolf wrote: Hi, I am maintaining eclipse-egit and eclipse-jgit. Since eclipse-egit depends on eclipse-jgit it makes sense to use chain-builds when building them (this is simply faster than waiting for eclipse-jgit to build, and become available in the repos before eclipse-git can be built). Ok, that works for rawhide. Unfortunately this isn't possible for non-rawhide releases. I could start speculating and think of reasons as to why that's the case, but rather ask the more knowledgeable :) So, what were the reasons for not allowing chain-builds for non-rawhide? Many thanks! Severin P.S.: The error message: Could not initiate build: Packages in destination tag dist-f14-updates-candidate are not inherited bybuild tag dist-f14-build doesn't mean much to me. Perhaps an error message indicating that chain-build is not available would be more meaningful. Sorry that it's terse. Once we branch a release away, we do not have a direct relationship between it built and it will be in the public repo. As such, it is dangerous to allow just-built items into the buildroot for future builds, as this could lead to a package being built against software that is never released. A variety of problems happen in this scenario. As such, we carefully maintain what goes into the buildroots, only by default taking things which have been marked as stable via bodhi, or things we explicitly tag in for a short period of time in order to accomplish a set of builds. The way to chain build for a branch is to request a buildroot override: https://fedoraproject.org/wiki/Package_update_HOWTO#Working_with_packages_in_the_stable_branches That should be easier to find, kudos to anybody that works on making it so. - -- 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/ iEYEARECAAYFAkyrkVgACgkQ4v2HLvE71NWlygCgsDbYjnbb5T9J/5y/LwV70668 ZH8An1V643SryUcDG+QXyQySLbXeFiLW =2UNO -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Quick question on building f14 isos?
On Tue, Oct 5, 2010 at 9:14 PM, Jesse Keating jkeat...@redhat.com wrote: There was a change in glibc during the F14 development cycle that requires running a newer kernel in order to run the f14 binaries. You could probably cheat a new kernel onto F11 and then do the pungi compose in a mock chroot of f14 content (I do all the pungi runs in mock chroots anyway). Thanks Jesse. I could try to put a newer kernel into the machine and see if it works - the machine is only used to do private builds, and yes I use a mock chroot and run pungi inside it. I had already put in place a fedora-14-i386.cfg based on the f14 branched repo into /etc/mock/ and also prepared a .ks file but it was the kernel that stumped me. So it is no loss if I can't do it on that machine until I get time to upgrade it. (Well I do also run f13 builds in it but that will be largely redundant soon, do my main installs with my own builds to save on yum updates once the installs are done.) Oh well... c'est la vie! -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Summary/Minutes for today's FESCo meeting (2010-10-05)
=== #fedora-meeting: FESCO (2010-10-05) === Meeting started by nirik at 19:30:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-10-05/fesco.2010-10-05-19.30.log.html Meeting summary --- * init process (nirik, 19:30:01) * mclasen will not be able to attend today due to a backhoe incident. (nirik, 19:30:48) * cwicket will also be unable to attend. (nirik, 19:30:59) * kylem is also unable to attend. (nirik, 19:31:13) * #473 new meeting time (redux) (nirik, 19:33:54) * LINK: https://fedorahosted.org/fesco/ticket/473 (nirik, 19:33:54) * ACTION: make sure cwickert is updated, revisit next week. (nirik, 19:46:09) * reminder: you can vote in tickets if unable to attend the meeting. (nirik, 19:46:22) * Updates policy / Vision implementation status (nirik, 19:46:48) * ideas wanted to improve stable N-1 wording/distinction. (nirik, 19:57:04) * LINK: http://fedoraproject.org/wiki/Packaging/Guidelines#Changelogs -- only shows formatting rules, so some recommendations for their content might be nice. (gholms, 20:08:46) * AGREED: will asking testers/qa to be on the lookout for things not following the update_policy and notify us via a ticket for further discussion. (nirik, 20:09:54) * AGREED: will see if FPC is willing/able to expand on the changelog guidelines. (nirik, 20:12:47) * #472 About Mozilla's decision to not allow using the system's libvpx (nirik, 20:14:40) * LINK: https://fedorahosted.org/fesco/ticket/472 (nirik, 20:14:40) * LINK: https://fedorahosted.org/fesco/ticket/472 (nirik, 20:30:41) * AGREED: will vote on proposals in ticket. (nirik, 21:05:11) * Open Floor (nirik, 21:05:43) * LINK: https://fedorahosted.org/rel-eng/ticket/4149 (gholms, 21:07:13) Meeting ended at 21:18:39 UTC. Action Items * make sure cwickert is updated, revisit next week. Action Items, by person --- * cwickert * make sure cwickert is updated, revisit next week. * **UNASSIGNED** * (none) People Present (lines said) --- * nirik (145) * pjones (69) * mjg59 (56) * notting (39) * gholms (31) * ajax (23) * hicham (22) * abadger1999 (17) * spot (10) * Oxf13 (10) * zodbot (8) * mdomsch (8) * mcepl (1) * rdieter (1) * SMParrish (0) * kylem (0) * mclasen (0) * cwickert (0) -- 19:30:01 nirik #startmeeting FESCO (2010-10-05) 19:30:01 zodbot Meeting started Tue Oct 5 19:30:01 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:30:01 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:30:01 nirik #meetingname fesco 19:30:01 zodbot The meeting name has been set to 'fesco' 19:30:01 nirik #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59 19:30:01 nirik #topic init process 19:30:01 zodbot Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones 19:30:06 * notting is here 19:30:36 * ajax waves 19:30:48 nirik #info mclasen will not be able to attend today due to a backhoe incident. 19:30:56 * pjones throws a trout at ajax 19:30:59 nirik #info cwicket will also be unable to attend. 19:31:12 gholms A backhoe incident? Ouch. 19:31:13 nirik #info kylem is also unable to attend. 19:31:21 nirik gholms: took out his home internet it seems. 19:31:30 gholms Ok, that's not *so* bad. 19:31:52 notting and kylem will not be here 19:32:19 nirik SMParrish: / mjg59: you guys here? 19:33:15 mjg59 Afternoon 19:33:27 nirik Hello. :) Thats 5. 19:33:45 nirik Shall we start with meeting time? 19:33:54 nirik #topic #473 new meeting time (redux) 19:33:54 nirik https://fedorahosted.org/fesco/ticket/473 19:34:09 nirik has everyone updated their http://whenisgood.net/ee8prq/results/z5binx entry? 19:34:15 ajax i have 19:34:25 * nirik 's didn't really change any 19:35:04 nirik so, currently we have 0 times everyone can attend. ;) 19:35:18 pjones yeah :/ 19:35:22 nirik a few times with 1 person left out, but everyone else... 19:35:31 pjones and excluding one person doesn't really help that much 19:36:11 nirik I guess we need to confirm that everyone updated before we do anything else? 19:36:24 notting although one of the times where mclasen is the only holdout his update info says will become available in a couple of weeks 19:37:01 nirik oh? 19:37:12 mjg59 Wait. I'm suddenly worried by the timezones here. 19:37:15 nirik wed 1-2? 19:37:17 pjones So can we move to that time and then hope that he can make do responding to trac until then? sounds not that great. 19:37:27 nirik mjg59: yeah, the site is confusing. 19:37:28 pjones mjg59: yeah, the site's representation of timezones is weird. 19:37:30 notting nirik: 2-3 your time. unless i'm forgetting what your time is 19:37:31 nirik I think it's in my local time. 19:37:39 pjones nirik: right. 19:37:41 pjones it's in mountain 19:37:49
Re: Chain builds for non-rawhide
Jesse Keating wrote, at 10/06/2010 05:58 AM +9:00: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/5/10 1:36 PM, Severin Gehwolf wrote: Hi, I am maintaining eclipse-egit and eclipse-jgit. Since eclipse-egit depends on eclipse-jgit it makes sense to use chain-builds when building them (this is simply faster than waiting for eclipse-jgit to build, and become available in the repos before eclipse-git can be built). Ok, that works for rawhide. Unfortunately this isn't possible for non-rawhide releases. I could start speculating and think of reasons as to why that's the case, but rather ask the more knowledgeable :) So, what were the reasons for not allowing chain-builds for non-rawhide? Many thanks! Severin P.S.: The error message: Could not initiate build: Packages in destination tag dist-f14-updates-candidate are not inherited bybuild tag dist-f14-build doesn't mean much to me. Perhaps an error message indicating that chain-build is not available would be more meaningful. Sorry that it's terse. Once we branch a release away, we do not have a direct relationship between it built and it will be in the public repo. As such, it is dangerous to allow just-built items into the buildroot for future builds, as this could lead to a package being built against software that is never released. A variety of problems happen in this scenario. As such, we carefully maintain what goes into the buildroots, only by default taking things which have been marked as stable via bodhi, or things we explicitly tag in for a short period of time in order to accomplish a set of builds. The way to chain build for a branch is to request a buildroot override: https://fedoraproject.org/wiki/Package_update_HOWTO#Working_with_packages_in_the_stable_branches That should be easier to find, kudos to anybody that works on making it so. - -- Jesse Keating Well, how about creating dist-f14-for-chainbuild build target and allow people to tag or untag build as/from that tag freely? For example currently http://koji.fedoraproject.org/koji/buildtargetinfo?targetID=67 says that build target dist-f14-kde uses dist-f14-kde tagged packages for buildroot, and built packages are tagged as dist-f14-kde and the destination tag dist-f14-kde is not locked. (and on the other hand build target dist-f14 still exists, using dist-f14-build tagged packages when building but the destination dist-f14 is locked) So as far as I am correct, we can freely do chain-build using dist-f14-kde build target for F-14 packages. And actually this status was used when fixing ImageMagick related dependency breakage on F-14 (see latest ImageMagick group update request on F-14 on bodhi, and tag history on koji for ImageMagick-6.6.4.1-13.fc14, autotrace-0.31.1-24.fc14.1 for example) So creating build target for chain-build purpose only seems reasonable to me. Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2010-09 Graphics Test Week recap
Another Graphics Test Week has gone by, so here's the statistical recap! A foreword - participation was substantially down this year, for which I entirely blame myself; it kind of crept up on me and I didn't get enough advance publicity out there. Most especially I didn't get the word out to Phoronix, which is just dumb, because I think the majority of testers come from there. So I'm sorry about that and I'll try and make sure it doesn't happen for F15. If anyone else wants to take over or help out with Graphics Test Week organization and publicity, btw, please do drop me a line! Here's an updated version of the numbers I came up with for F13: f11 nouveau: 104 tests, 42 bugs - ratio 0.40 f12 nouveau: 53 tests, 34 bugs - ratio 0.64 f13 nouveau: 78 tests, 26 bugs - ratio 0.33 f14 nouveau: 39 tests, 8 bugs - ratio 0.21 f11 radeon: 55 tests, 46 bugs - ratio 0.84 f12 radeon: 61 tests, 81 bugs - ratio 1.33 f13 radeon: 48 tests, 33 bugs - ratio 0.69 f14 radeon: 32 tests, 18 bugs - ratio 0.56 f11 intel: 23 tests, 21 bugs - ratio 0.91 f12 intel: 29 tests, 31 bugs - ratio 1.07 f13 intel: 38 tests, 38 bugs - ratio 1.00 f14 intel: 33 tests, 28 bugs - ratio 0.84 Each driver posted its best ever ratio of bugs to tests, which is great (though I imagine the Phoronix testers may be quite sophisticated and demanding in their use cases, and this may impact the results). The ranking stays the same, with nouveau at number 1, radeon at number 2 and intel at number 3. The same caveats as last time of course apply - different drivers implement different features and may have to deal with more problematic hardware. Here's the other chart I ran last time, tracking how we handle the bugs that are reported - obviously, this time adding the numbers for F13 as we can't see into the future for the F14 bugs... f11 nouveau: 42 bugs, 4 open, 8 closeddupe, 24 closedfixed, 6 closedunfixed - 70.59% f12 nouveau: 34 bugs, 11 open, 8 closeddupe, 14 closedfixed, 1 closedunfixed - 53.85% f13 nouveau: 27 bugs, 17 open, 6 closeddupe, 3 closedfixed, 1 closedunfixed - 14.29% f11 radeon: 46 bugs, 14 open, 10 closeddupe, 19 closedfixed, 3 closedunfixed - 52.78% f12 radeon: 81 bugs, 19 open, 32 closeddupe, 28 closedfixed, 2 closedunfixed - 57.14% f13 radeon: 36 bugs, 28 open, 3 closeddupe, 5 closedfixed, 0 closedunfixed - 15.15% f11 intel: 21 bugs, 7 open, 1 closeddupe, 12 closedfixed, 1 closedunfixed - 60% f12 intel: 31 bugs, 7 open, 12 closeddupe, 12 closedfixed, 0 closedunfixed - 63.16% f13 intel: 42 bugs, 26 open, 4 closeddupe, 11 closedfixed, 1 closedunfixed - 28.95% To refresh your memories, the percentage is 'closedfixed' / (bugs - 'closeddupe') * 100, the intention being to give an indication of what proportion of bug reports wind up in a fix. Full details in my previous recap - http://lists.fedoraproject.org/pipermail/test/2010-April/090271.html . (I know the bug counts for F13 do not match those in the previous table; I took the numbers in the previous table from my last recap, but did these numbers just now, and I suspect further results were added to the F13 pages following my last recap, accounting for the discrepancy). This one's obviously worrying and indicates our rate of closing reported X bugs slowed markedly in F13 for all three drivers (though intel fared noticeably better than the others). I definitely intend to look into this. I don't think we could assume this is down to less development effort; it could well be down to less X triage, I know I have not been able to triage X very often for the last few months. I'll definitely look into this and see if any follow-up action is necessary, however. The raw lists of bugs reported from the F14 Test Days follow. Thanks very much to all testers, and to the wonderful Fedora X.org developers and triagers: Adam Jackson Dave Airlie Jerome Glisse Ben Skeggs Matej Cepl François Cami Chris Campbell Nouveau --- 573096 NEW - NV1f Chipset - Garbled Display. Needs nouveau.tv_disable=1 on boot to work 611059 NEW - Screen artifacts in KDE with nouveau 638317 NEW - Rendercheck is not passed completely 638329 NEW - Resume freezes with nouveau, GeForce 6150 517917 ASSIGNED - NV1f chipset. Screen moved one line down. 638174 CLOSED NOTABUG - F14 graphics test Xorg falls back to VESA instead of Nouveau 638103 CLOSED DUPLICATE - Second monitor not enabled on F14 live CD by default 638258 CLOSED DUPLICATE - garbled video on boot Radeon -- 638646 NEW - [abrt] mesa-demos-7.9-0.8.fc14: Process /usr/lib64/mesa/fbo_firecube was killed by signal 11 (SIGSEGV) 638807 NEW - waiting for X server to shut down gnome-settings-daemon: Fatal IO error 11 638793 NEW - suspend/resume corrupts a compiz enabled desktop (ATI Radeon XPRESS 200M 5955) 638806 NEW - Radeon XPRESS 200M 5955: Corrupted OpenGL images; problem goes away after running an XV program (i.e. Totem) 639660 NEW - Missing resolutions on second monitor (ATI RV730XT [Radeon HD 4670]) 638827 NEW - Suspend/Resume
Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As you might be aware, there was a period of roughly two weeks where a gcc build (gcc-4.5.1-3.fc14) in the buildroots for both Fedora 14 and Fedora 15. Items built with this could have undefined behavior, which could lead to data corruption. Unfortunately I'm told that it is impossible to look at a generated binary and detect whether or not the binary would be effected by this bug. The only reliable way to tell would be to re-create the build environment exactly, except replace GCC with one that will detect the error scenario and print something. As this is a significant amount of work, I decided instead to just rebuild the potential problem builds. I detected all the latest builds of packages that had gcc-4.5.1-3.fc14 in the buildroot, and then further narrowed it down to things which require rtld(GNU_HASH) to find the things that actually used gcc (since gcc gets thrown in every buildroot anyway). For Fedora 15 this was a simple task. Just find the packages where the latest build is bad, bump it and rebuild it. End of story. This work is already done (except that a few have failed, and I need to follow up on those). For Fedora 14 the matter is much more complicated. Builds are spread out across 3 main tags, dist-f14, dist-f14-updates-testing, and dist-f14-updates-candidate. dist-f14 is things that have made it through bodhi as stable. dist-f14-updates-testing is for things which are currently in updates-testing dist-f14-updates-candidate is for things which could potentially become an update should the maintainer decide. To handle the F14 scene I've come up with this strategy: * For things tagged in dist-f14 and no newer build elsewhere, do a bump, build and tag directly into dist-f14. While there is some risk of breakage, it is quite minimal and with discussion from QA we are willing to take that chance. This work is ongoing. * For things tagged in dist-f14-updates-testing, do a bump, build and then edit the bodhi ticket to add the new build, and re-push to updates-testing. This work will begin soon. * for things tagged in dist-f14-updates-candidate, do a bump and build. Then look for an open bodhi ticket for that package, adjusting as needed. If no bodhi ticket is found, do not create a new one, just leave the build as is. This work will begin soon. Using this strategy we should be able to replace potentially bad builds with corrected ones wherever they might have been published (barring the failed builds). This message is mostly a heads up as to what's happening. PS I had a small misfire in some of the F14 builds, I used the wrong input set of packages. There is a chance that some f14 builds were done unnecessarily. The unnecessary builds will just be ignored and left to expire. PPS I did not modify my bump script yet to attempt a commit to master and merge to the f14 branch. In the interest of time, I took the easy route and just did commits to the f14 branch. Maintainers can do a merge and fixup after the builds have been done if they wish to have their branches in sync with master once more. - -- 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/ iEYEARECAAYFAkyrpk4ACgkQ4v2HLvE71NW6IwCbBex8eV/0M2eOmfqTqakx14zC pDMAnA6iBmjaMC+E87fgp6CvLoxEhAiF =GFLf -END PGP SIGNATURE- ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
Hi, 2010/10/6 Jesse Keating jkeat...@redhat.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As you might be aware, there was a period of roughly two weeks where a gcc build (gcc-4.5.1-3.fc14) in the buildroots for both Fedora 14 and Fedora 15. Items built with this could have undefined behavior, which could lead to data corruption. Is there somewhere a list of packages potentially broken on F14? Regards, Michal Unfortunately I'm told that it is impossible to look at a generated binary and detect whether or not the binary would be effected by this bug. The only reliable way to tell would be to re-create the build environment exactly, except replace GCC with one that will detect the error scenario and print something. As this is a significant amount of work, I decided instead to just rebuild the potential problem builds. I detected all the latest builds of packages that had gcc-4.5.1-3.fc14 in the buildroot, and then further narrowed it down to things which require rtld(GNU_HASH) to find the things that actually used gcc (since gcc gets thrown in every buildroot anyway). For Fedora 15 this was a simple task. Just find the packages where the latest build is bad, bump it and rebuild it. End of story. This work is already done (except that a few have failed, and I need to follow up on those). For Fedora 14 the matter is much more complicated. Builds are spread out across 3 main tags, dist-f14, dist-f14-updates-testing, and dist-f14-updates-candidate. dist-f14 is things that have made it through bodhi as stable. dist-f14-updates-testing is for things which are currently in updates-testing dist-f14-updates-candidate is for things which could potentially become an update should the maintainer decide. To handle the F14 scene I've come up with this strategy: * For things tagged in dist-f14 and no newer build elsewhere, do a bump, build and tag directly into dist-f14. While there is some risk of breakage, it is quite minimal and with discussion from QA we are willing to take that chance. This work is ongoing. * For things tagged in dist-f14-updates-testing, do a bump, build and then edit the bodhi ticket to add the new build, and re-push to updates-testing. This work will begin soon. * for things tagged in dist-f14-updates-candidate, do a bump and build. Then look for an open bodhi ticket for that package, adjusting as needed. If no bodhi ticket is found, do not create a new one, just leave the build as is. This work will begin soon. Using this strategy we should be able to replace potentially bad builds with corrected ones wherever they might have been published (barring the failed builds). This message is mostly a heads up as to what's happening. PS I had a small misfire in some of the F14 builds, I used the wrong input set of packages. There is a chance that some f14 builds were done unnecessarily. The unnecessary builds will just be ignored and left to expire. PPS I did not modify my bump script yet to attempt a commit to master and merge to the f14 branch. In the interest of time, I took the easy route and just did commits to the f14 branch. Maintainers can do a merge and fixup after the builds have been done if they wish to have their branches in sync with master once more. - -- 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/ iEYEARECAAYFAkyrpk4ACgkQ4v2HLvE71NW6IwCbBex8eV/0M2eOmfqTqakx14zC pDMAnA6iBmjaMC+E87fgp6CvLoxEhAiF =GFLf -END PGP SIGNATURE- ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- 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
e4defrag support?
Hi, I'm curious why e4defrag isn't enabled in e2fsprogs. Are there any problems with this tool? Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: e4defrag support?
Michał Piotrowski wrote: Hi, I'm curious why e4defrag isn't enabled in e2fsprogs. Are there any problems with this tool? It's had really limited testing, and the kernel interface has had some problems in the past (though I guess that's irrelevant to shipping the userspace) I guess it's a little of a chicken-and-egg problem; no binary, no testing; no testing, I hesitate to unleash the binary, which has serious data integrity implications. I think it's going to need some concentrated development testing love to get to full readiness. -Eric Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
Jesse Keating jkeat...@redhat.com writes: As you might be aware, there was a period of roughly two weeks where a gcc build (gcc-4.5.1-3.fc14) in the buildroots for both Fedora 14 and Fedora 15. Items built with this could have undefined behavior, which could lead to data corruption. ... I detected all the latest builds of packages that had gcc-4.5.1-3.fc14 in the buildroot, and then further narrowed it down to things which require rtld(GNU_HASH) to find the things that actually used gcc (since gcc gets thrown in every buildroot anyway). Could you provide a list of the packages you are intending to rebuild? Or at least the exact dates where the bad gcc was in use? regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
Jesse Keating wrote, at 10/06/2010 07:27 AM +9:00: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As you might be aware, there was a period of roughly two weeks where a gcc build (gcc-4.5.1-3.fc14) in the buildroots for both Fedora 14 and Fedora 15. Items built with this could have undefined behavior, which could lead to data corruption. snip To handle the F14 scene I've come up with this strategy: * For things tagged in dist-f14 and no newer build elsewhere, do a bump, build and tag directly into dist-f14. While there is some risk of breakage, it is quite minimal and with discussion from QA we are willing to take that chance. This work is ongoing. * For things tagged in dist-f14-updates-testing, do a bump, build and then edit the bodhi ticket to add the new build, and re-push to updates-testing. This work will begin soon. * for things tagged in dist-f14-updates-candidate, do a bump and build. Then look for an open bodhi ticket for that package, adjusting as needed. If no bodhi ticket is found, do not create a new one, just leave the build as is. This work will begin soon. How does this strategy go for packages that the latest dist-f14 one was rebuilt using gcc-4.5.1-3.fc14, and there is newer dist-f14-updates-candidate one rebuilt using gcc-4.5.1-3.fc14 but no bodhi submission yet? Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/5/10 3:43 PM, Micha? Piotrowski wrote: Is there somewhere a list of packages potentially broken on F14? http://fpaste.org/7dvk/ is a list of broken F14 builds. The syntax is: packagename : detected bad build : tag that build is in This was generated a few days ago, so many of the packages have had newer builds by now. I'm just using this as a starting point for the scripts which actually execute the bump/build. - -- 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/ iEYEARECAAYFAkyrsFUACgkQ4v2HLvE71NXK8QCfZI4SCJeVZi3oHCXyUV1A0yLe ZTsAnihyUnG8Ea+S+wWbSUzjqmbgQThc =Nuah -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: e4defrag support?
2010/10/6 Eric Sandeen sand...@redhat.com: Michał Piotrowski wrote: Hi, I'm curious why e4defrag isn't enabled in e2fsprogs. Are there any problems with this tool? It's had really limited testing, and the kernel interface has had some problems in the past (though I guess that's irrelevant to shipping the userspace) I guess it's a little of a chicken-and-egg problem; no binary, no testing; no testing, I hesitate to unleash the binary, which has serious data integrity implications. I think it's going to need some concentrated development testing love to get to full readiness. I can help with testing. I have some experience in creating test scripts/cases etc. -Eric Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/5/10 3:56 PM, Tom Lane wrote: Could you provide a list of the packages you are intending to rebuild? See my reply to Michal Or at least the exact dates where the bad gcc was in use? The bad gcc was tagged into dist-f14 on Fri Sep 10 20:24:00 2010. It would have been in the buildroots a short time after, whenever the next newRepo command completed. The fixed gcc was tagged into dist-f14 on Sun Sep 26 20:50:11 2010. It would have been in the buildroots a short time after, whenever the next newRepo command completed. That is your window for when potentially bad builds happened. - -- 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/ iEYEARECAAYFAkyrsfkACgkQ4v2HLvE71NW28ACgsfI9FbLwwOtTpyzrpZHeFlcs mzkAoLutDh5sIvWu+rm9W0K9ESnkrlpj =oatC -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/5/10 3:59 PM, Mamoru Tasaka wrote: To handle the F14 scene I've come up with this strategy: * For things tagged in dist-f14 and no newer build elsewhere, do a bump, build and tag directly into dist-f14. While there is some risk of breakage, it is quite minimal and with discussion from QA we are willing to take that chance. This work is ongoing. * For things tagged in dist-f14-updates-testing, do a bump, build and then edit the bodhi ticket to add the new build, and re-push to updates-testing. This work will begin soon. * for things tagged in dist-f14-updates-candidate, do a bump and build. Then look for an open bodhi ticket for that package, adjusting as needed. If no bodhi ticket is found, do not create a new one, just leave the build as is. This work will begin soon. How does this strategy go for packages that the latest dist-f14 one was rebuilt using gcc-4.5.1-3.fc14, and there is newer dist-f14-updates-candidate one rebuilt using gcc-4.5.1-3.fc14 but no bodhi submission yet? Hrm. I'll have to check for this specific scenario and tease out anything which fits. In these cases I think I'll have to look by hand at what the differences are between the dist-f14 build and the dist-f14-updates-candidate build is, and then work with the maintainer on whether an update should be pushed or a build with the only change being the gcc update done and pushed instead. - -- 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/ iEYEARECAAYFAkyrsn8ACgkQ4v2HLvE71NVhlACfUyXs6f2tP00/cwc6rZkyyaSB F/gAnRHUZ46X9gBDODfTBDCCp+8kcMcs =ffJI -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package rebuilds for gcc bug https://bugzilla.redhat.com/show_bug.cgi?id=634757
2010/10/6 Jesse Keating jkeat...@redhat.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/5/10 3:43 PM, Micha? Piotrowski wrote: Is there somewhere a list of packages potentially broken on F14? http://fpaste.org/7dvk/ is a list of broken F14 builds. The syntax is: Thanks. I hope that all of these packages will soon be rebuilded Regards, Michal packagename : detected bad build : tag that build is in This was generated a few days ago, so many of the packages have had newer builds by now. I'm just using this as a starting point for the scripts which actually execute the bump/build. - -- 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/ iEYEARECAAYFAkyrsFUACgkQ4v2HLvE71NXK8QCfZI4SCJeVZi3oHCXyUV1A0yLe ZTsAnihyUnG8Ea+S+wWbSUzjqmbgQThc =Nuah -END PGP SIGNATURE- -- 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: Making Fedora work with laptops on docking station with external monitor
On 05/10/10 08:40 AM, FlorianFesti wrote: On 10/05/2010 03:15 PM, Nathaniel McCallum wrote: If the lid is open, both output should be enabled by default (you are free to manually disable one). If the lid is closed on battery power the system should suspend (unless you choose otherwise in GPM prefs). I wonder if there are latops that can be booted with lid closed and that make a subtle sematic difference between the lid was just being closed and is lid was already closed when we booted up. Dells can boot with lid closed when connected to dock. I do that every day :-) Dariusz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: e4defrag support?
Michał Piotrowski wrote: 2010/10/6 Eric Sandeen sand...@redhat.com: Michał Piotrowski wrote: Hi, I'm curious why e4defrag isn't enabled in e2fsprogs. Are there any problems with this tool? It's had really limited testing, and the kernel interface has had some problems in the past (though I guess that's irrelevant to shipping the userspace) I guess it's a little of a chicken-and-egg problem; no binary, no testing; no testing, I hesitate to unleash the binary, which has serious data integrity implications. I think it's going to need some concentrated development testing love to get to full readiness. I can help with testing. I have some experience in creating test scripts/cases etc. cool! I suppose I could turn it on in rawhide, or you could just build your own e2fsprogs to get it ... -Eric -Eric Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: e4defrag support?
W dniu 6 października 2010 05:01 użytkownik Eric Sandeen sand...@redhat.com napisał: Michał Piotrowski wrote: 2010/10/6 Eric Sandeen sand...@redhat.com: Michał Piotrowski wrote: Hi, I'm curious why e4defrag isn't enabled in e2fsprogs. Are there any problems with this tool? It's had really limited testing, and the kernel interface has had some problems in the past (though I guess that's irrelevant to shipping the userspace) I guess it's a little of a chicken-and-egg problem; no binary, no testing; no testing, I hesitate to unleash the binary, which has serious data integrity implications. I think it's going to need some concentrated development testing love to get to full readiness. I can help with testing. I have some experience in creating test scripts/cases etc. cool! I suppose I could turn it on in rawhide, or you could just build your own e2fsprogs to get it ... I already built my own version. -Eric Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 637110] perl-HTML-Encoding-0.61 is available
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=637110 --- Comment #3 from Fedora Update System upda...@fedoraproject.org 2010-10-05 09:16:19 EDT --- perl-HTML-Encoding-0.61-1.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. -- 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
File CGI-Application-Plugin-DebugScreen-0.07.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-CGI-Application-Plugin-DebugScreen: da8ceb7bc1a6c5f1490a654518dc50ff CGI-Application-Plugin-DebugScreen-0.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
[Bug 557485] Extra provides need trimming
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=557485 --- Comment #2 from Mike McGrath mmcgr...@redhat.com 2010-10-05 17:47:44 EDT --- (In reply to comment #1) Mike, I can build this as well if you're busy and otherwise happy with this change. Please do, thank you. -- 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
File MojoMojo-1.02.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for mojomojo: 64d87c5bd6ea11526d1fadfc32e3de38 MojoMojo-1.02.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
[Bug 624308] Package pre-dates the discovery of fire.
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=624308 Iain Arnell iarn...@gmail.com changed: What|Removed |Added Depends on||640337(perl-MooseX-NonMoose ||) -- 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
[Bug 624308] Package pre-dates the discovery of fire.
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=624308 --- Comment #5 from Iain Arnell iarn...@gmail.com 2010-10-06 01:08:23 EDT --- Unfortunately, I overlooked the MooseX::NonMoose dependency which is also missing (review pending now though). This is going to require updated MOP/Moose packages too, so I don't think it's wise to push this into f13 just yet. It's still looking promising to make f14, though. -- 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
Moose-related deprecation warnings in rawhide
I've just pushed perl-Moose-1.14 to rawhide (and 1.15 coming soon - I've just noticed they've updated again right after I did). The long-deprecated alias and excludes options for role applications now issue deprecation warnings. They're mostly harmless, but do seem to make a lot of noise. Most affected upstream packages have been updated, but with Chris' absence, some of ours are lagging behind. I'll make the necessary updates as I find them, but if there's anything causing a problem for you, let me know and I'll get right on to it. -- Iain. -- 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
[389-devel] Please review: [Bug 640027] Naming attribute with a special char sequence parsing bug
https://bugzilla.redhat.com/show_bug.cgi?id=640027 https://bugzilla.redhat.com/attachment.cgi?id=451775action=diff https://bugzilla.redhat.com/attachment.cgi?id=451775action=edit Description: When DN is made from RDNs containing escaped plus \+, the dn normalizer considers the value could be nested multi- valued RDNs. (e.g., cn=C\=Z\+A\=X\+B\=Y\,o\=O,o=OO) In that case, multi-valued RDNs are sorted by the normalizer. (== cn=A\=X\+B\=Y\+C\=Z\,o\=O,o=OO) The sample DN provided by Andrey Ivanov contains \+, but that is not a separator for the multi-valued RDNs: cn=mytest\+\=-123'\;456,dc=example,dc=com The dn normalizer should have checked the possibility, as well. The check is added in this patch. Also, sorting was not triggered if multi-valued RDNs are located at the end of the value. (e.g., cn=C\=X\,B\=Y\+A\=Z,o=OO) The bug was fixed, as well. File: ldap/servers/slapd/dn.c -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Fedora mini is now Fedora Mobility!
Hi All, I ran a session with a group of interested people at FUDCon Zurich titled Fedora Mini, Moblin, MeeGo, Sugar. oh my! and there was a great and interesting conversation between a number of parties interested in Fedora on small devices. There were representatives from Fedora people interested in the KDE NetBook spin, Moblin/MeeGo, Sugar, ARM etc. Part of that conversation was around the name of Fedora Mini and it was decided that renaming the project to Mobility would better reflect the interests and direction of the project. I've been meaning to announce this ever since the always awesome FUDCon but $paidjob took control again and I've not had the chance! I've created the following wiki page here https://fedoraproject.org/wiki/Mobility and there is already a #fedora-mobility IRC channel. I'm planning on getting the mailing list migrated (renamed or something!). Look forward to seeing you all there. Regards, Peter ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
