Re: Licensing Guidelines Update - Please Read
On Wed, Jul 07, 2010 at 04:29:01PM -0400, Tom spot Callaway wrote: However, if a subpackage is independent of any base package (it does not require it, either implicitly or explicitly), it must include copies of any license texts (as present in the source) which are applicable to the files contained within the subpackage. What about debuginfo packages? They do not require the base package but usually also do not include the license texts. Regards Till pgpf23AjDzbcc.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On Wed, 2010-07-07 at 16:29 -0400, Tom spot Callaway wrote: [sailer] ghdl: ghdl-grt-0.29-1.138svn.0.fc13.x86_64 [sailer] libsqlite3x: libsq3-20071018-8.fc12.x86_64 [sailer] mingw32-libsqlite3x: mingw32-libsq3-20071018-9.fc12.noarch [sailer] mingw32-wpcap: mingw32-wpcap-docs-4.1.final1-1.fc13.noarch mingw32-wpcap-examples-4.1.final1-1.fc13.noarch All fixed in rawhide now. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On 07/07/2010 10:29 PM, Tom spot Callaway wrote: Hello Fedora! Please take a moment and read this email. There's cake in it for you. Upon the advice of Red Hat Legal, we have slightly amended the Fedora Licensing Guidelines (https://fedoraproject.org/wiki/Packaging:LicensingGuidelines). The following section has been added: Subpackage Licensing Can you elaborate the cases below? I can't spot anything wrong with them: [corsepiu] gtkglext: gtkglext-libs-1.2.0-10.fc12.x86_64 # repoquery -ql 'gtkglext-libs' ... /usr/share/doc/gtkglext-libs-1.2.0/AUTHORS /usr/share/doc/gtkglext-libs-1.2.0/COPYING /usr/share/doc/gtkglext-libs-1.2.0/COPYING.LIB /usr/share/doc/gtkglext-libs-1.2.0/ChangeLog /usr/share/doc/gtkglext-libs-1.2.0/README /usr/share/doc/gtkglext-libs-1.2.0/TODO [corsepiu] OpenSceneGraph: OpenThreads-2.8.3-1.fc14.x86_64 # repoquery -ql OpenThreads.i686 ... /usr/share/doc/OpenThreads-2.8.2/AUTHORS.txt /usr/share/doc/OpenThreads-2.8.2/LICENSE.txt /usr/share/doc/OpenThreads-2.8.2/NEWS.txt /usr/share/doc/OpenThreads-2.8.2/README.txt Both are cases where the binary base packages' names differ from the srpm name. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On 07/07/2010 10:29 PM, Tom spot Callaway wrote: [mmaslano] perl-Frontier-RPC: perl-Frontier-RPC-doc-0.07b4p1-10.fc14.noarch The main package and sub-package already requires sub-package doc that includes copying. Doc sub-package was created to solve conflicts between those two. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Recoll package
Hello, Recoll is a desktop text search program, and it's been in other distributions repositories for quite a long time but it's not in Fedora. I am the Recoll developer. Could someone tell me if I need to do something to advance the review request or if there is simply no interest ? Review request: https://bugzilla.redhat.com/show_bug.cgi?id=590473 A few (very partially selected) references: http://www.recoll.org/features.html http://www.techradar.com/news/software/applications/6-of-the-best-desktop-search-tools-for-linux-666158?artc_pg=6 http://www.techradar.com/news/software/applications/6-of-the-best-desktop-search -tools-for-linux-666158?artc_pg=7 http://www.linux.com/archive/feature/114283 Cheers, J.F. Dockes -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/rt3/EL-6 rt-3.8.6-test-dependencies.diff, NONE, 1.1 rt-3.8.8-Makefile.diff, NONE, 1.1 rt-3.8.8-config.diff, NONE, 1.1 rt3.spec, 1.47, 1.48 sources, 1.14, 1.15 rt-3.8.4-Makefile.diff, 1.1, NONE rt
Author: xavierb
Update of /cvs/pkgs/rpms/rt3/EL-6
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv4483
Modified Files:
rt3.spec sources
Added Files:
rt-3.8.6-test-dependencies.diff rt-3.8.8-Makefile.diff
rt-3.8.8-config.diff
Removed Files:
rt-3.8.4-Makefile.diff rt-3.8.4-config.diff
rt-3.8.4-rh-bz526870.diff rt-3.8.4-rh-bz543962.diff
rt-3.8.4-test-dependencies.diff
Log Message:
- Update to 3.8.8 (Sync with Rawhide).
rt-3.8.6-test-dependencies.diff:
rt-test-dependencies.in |1 -
1 file changed, 1 deletion(-)
--- NEW FILE rt-3.8.6-test-dependencies.diff ---
diff -Naur rt-3.8.6.orig/sbin/rt-test-dependencies.in
rt-3.8.6/sbin/rt-test-dependencies.in
--- rt-3.8.6.orig/sbin/rt-test-dependencies.in 2009-10-19 21:55:31.0
+0200
+++ rt-3.8.6/sbin/rt-test-dependencies.in 2009-12-04 15:44:07.0
+0100
@@ -278,7 +278,6 @@
$deps{'DEV'} = [ text_to_hash( '.') ];
HTML::Form
-HTML::TokeParser
WWW::Mechanize
Test::WWW::Mechanize 1.04
Module::Refresh 0.03
rt-3.8.8-Makefile.diff:
Makefile.in | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- NEW FILE rt-3.8.8-Makefile.diff ---
--- rt-3.8.8.orig/Makefile.in 2010-05-05 22:09:21.0 +0200
+++ rt-3.8.8/Makefile.in2010-05-06 10:46:27.0 +0200
@@ -286,7 +286,7 @@
@echo $(RT_SBIN_PATH)/rt-setup-database --dba $(DB_DBA)
--prompt-for-dba-password --action upgrade
-upgrade: testdeps config-install dirs files-install fixperms upgrade-instruct
+upgrade: testdeps config-install dirs files-install upgrade-instruct
upgrade-noclobber: config-install dirs libs-install html-install bin-install
local-install doc-install font-install fixperms
@@ -367,7 +367,7 @@
$(INSTALL) -m 0755 -d $(DESTDIR)$(LOCAL_LEXICON_PATH)
# }}}
-install: testdeps config-install dirs files-install fixperms instruct
+install: testdeps config-install dirs files-install instruct
files-install: libs-install etc-install config-install bin-install
sbin-install html-install local-install doc-install font-install
@@ -431,9 +431,9 @@
# {{{ font-install
font-install:
@COMMENT_INPLACE_LAYOUT@ [ -d $(DESTDIR)$(RT_FONT_PATH) ] || $(INSTALL)
-m 0755 -d $(DESTDIR)$(RT_FONT_PATH)
-...@comment_inplace_layout@-( cd share/fonts find . -type f -print ) |
while read file ; do \
-...@comment_inplace_layout@$(INSTALL) -m 0644 share/fonts/$$file
$(DESTDIR)$(RT_FONT_PATH)/$$file ; \
-...@comment_inplace_layout@done
+...@comment_inplace_layout@#-( cd share/fonts find . -type f -print ) |
while read file ; do \
+...@comment_inplace_layout@#$(INSTALL) -m 0644 share/fonts/$$file
$(DESTDIR)$(RT_FONT_PATH)/$$file ; \
+...@comment_inplace_layout@#done
# }}}
# {{{ doc-install
rt-3.8.8-config.diff:
RT_SiteConfig.pm | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
--- NEW FILE rt-3.8.8-config.diff ---
--- rt-3.8.8.orig/etc/RT_SiteConfig.pm 2010-05-05 22:09:21.0 +0200
+++ rt-3.8.8/etc/RT_SiteConfig.pm 2010-05-07 07:30:57.0 +0200
@@ -12,8 +12,19 @@
# going to run into trouble. To check your SiteConfig file, use
# this comamnd:
#
-# perl -c /path/to/your/etc/RT_SiteConfig.pm
+# perl -c /etc/rt3/RT_SiteConfig.pm
Set( $rtname, 'example.com');
-#Set(@Plugins,(qw(Extension::QuickDelete RT::FM)));
+
+# Set( $Organization , example.com);
+
+# Look into the zoneinfo database for valid values (/usr/share/zoneinfo/)
+# Set( $Timezone , 'US/Eastern');
+
+# Set( $RTAddressRegexp, '(^rt3...@example\.com$)' );
+
+# Set( $WebBaseURL , http://localhost;);
+
+Set( $WebPath , /rt3);
+
1;
Index: rt3.spec
===
RCS file: /cvs/pkgs/rpms/rt3/EL-6/rt3.spec,v
retrieving revision 1.47
retrieving revision 1.48
diff -u -p -r1.47 -r1.48
--- rt3.spec14 Dec 2009 08:44:12 - 1.47
+++ rt3.spec7 Jul 2010 20:47:44 - 1.48
@@ -1,5 +1,5 @@
#
-# Copyright (c) 2005, 2006, 2007, 2008, 2009 Ralf Corsepius, Ulm, Germany.
+# Copyright (c) 2005, 2006, 2007, 2008, 2009, 2010, Ralf Corsepius, Ulm,
Germany.
# This file and all modifications and additions to the pristine
# package are under the same license as the package itself.
#
@@ -39,8 +39,8 @@
%define RT3_LOCALSTATEDIR %{_localstatedir}/lib/rt3
Name: rt3
-Version: 3.8.4
-Release: 8%{?dist}
+Version: 3.8.8
+Release: 2%{?dist}
Summary: Request tracker 3
Group: Applications/Internet
@@ -51,19 +51,9 @@ Source3: rt3.conf.in
Source4: README.fedora.in
Source5: rt3.logrotate.in
-Patch0:rt-3.8.4-config.diff
-Patch2:rt-3.8.4-Makefile.diff
-Patch3:rt-3.8.4-test-dependencies.diff
-
-# https://bugzilla.redhat.com/show_bug.cgi?id=526870
-# Patch from
http://lists.bestpractical.com/pipermail/rt-announce/2009-September/000173.html
-# Fixed in rt =
Re: Licensing Guidelines Update - Please Read
On Wed, 07 Jul 2010 16:29:01 -0400, Tom wrote:
However, if a subpackage is independent of any base package (it does
not require it, either implicitly or explicitly), it must include
copies of any license texts (as present in the source) which are
applicable to the files contained within the subpackage.
With this we've reached the point once more where the default %doc dir is
a poor choice, because it is based on the subpackage's %{name} instead of
the src.rpm's or base package's %{name}.
For the common tools'n'library split of a package, the changed guidelines
duplicate the license files by storing them in two different directories
when using %doc:
/usr/share/doc/name-1.0/COPYING
/usr/share/doc/name-libs-1.0/COPYING
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide perl-5.12 status
On 07/08/2010 06:48 AM, Ralf Corsepius wrote: b) Or simply apply https://fedoraproject.org/wiki/PackageMaintainers/PackageEndOfLife FTBS/rel-eng will certainly apply b), and I don't see much reasons for not applying b) either. I'm for b/ too. If rel-eng won't be happy, he can always ask FESCO. BTW: We are talking about 4 packages, involving these 3 maintainers: perl-DBI-Dumper: Chris Weyl perl-Data-Alias: Chris Weyl perl-Pugs-Compiler: Steven Pritchard. perl-Test-AutoBuild: Daniel Berrange I haven't seen a trace of Steve for several months, but Chris and Daniel are still around in Fedora. No idea, why they prefer not to respond on these cases. Steven wrote week ago that he's quite busy. I suppose in summer will be people on vacations, so I'd rather don't jump to a/ at all. Marcela -- 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: Licensing Guidelines Update - Please Read
On 07/07/10 21:29, Tom spot Callaway wrote: ... Okay. Here's the list of packages that I think might be affected by this. Reminder: You need to check these packages and fix any which need fixing, then email me and let me know which ones you checked/fixed. Thanks! ~spot ... [pghmcfc] bluefish: bluefish-shared-data-2.0.1-1.fc14.noarch False positive: bluefish-shared-data contains the license text and is required by the main bluefish package. There are no other subpackages. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On Wed, 2010-07-07 at 16:29 -0400, Tom spot Callaway wrote: [ankursinha] beteckna-fonts: beteckna-fonts-common-0.3-5.fc12.noarch hi, Can you please clarify this one? The sub packages depend on the -common, which has the LICENSE etc. docs. Is this because the main package doesn't Requires: -common? Thanks, regards, Ankur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On 07/08/2010 02:09 PM, Ankur Sinha wrote: On Wed, 2010-07-07 at 16:29 -0400, Tom spot Callaway wrote: [ankursinha] beteckna-fonts: beteckna-fonts-common-0.3-5.fc12.noarch hi, Can you please clarify this one? The sub packages depend on the -common, which has the LICENSE etc. docs. Is this because the main package doesn't Requires: -common? If someone installs the main package, they wouldn't get a copy of the license along with it. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On Wed, 07 Jul 2010 16:29:01 -0400, Tom wrote: [mschwendt] audacious: audacious-libs-2.4-0.3.alpha2.fc14.x86_64 Fixed in Rawhide. [mschwendt] mcs: mcs-libs-0.7.1-9.fc13.x86_64 False positive. mcs-libs contains all the %doc files, and mcs automatically depends on mcs-libs. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
Hi, --- On Thu, Jul 8, 2010 at 1:59 AM, Tom spot Callaway tcall...@redhat.com wrote: | [shakthimaan] poky-scripts: poky-depends-6-6.fc13.noarch \-- poky-depends is just a meta-package that pulls licensed software already included in Fedora repository required for poky software builds. SK -- Shakthi Kannan http://www.shakthimaan.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Recoll package
On 07/08/2010 10:02 AM, Jean-Francois Dockes wrote: Could someone tell me if I need to do something to advance the review request or if there is simply no interest ? Review request: https://bugzilla.redhat.com/show_bug.cgi?id=590473 Hello, the fastest way is offer swap review. Reviews are quite slow, so there's no problem with your package. Regards, Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Recoll package
On Thu, 2010-07-08 at 10:02 +0200, Jean-Francois Dockes wrote: Review request: https://bugzilla.redhat.com/show_bug.cgi?id=590473 Taken, regards, Ankur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
On Thu, 2010-07-08 at 09:18 +0200, Jakub Jelinek wrote: Hi! F14 now has gcc-4.5-RH compiler instead of 4.4-RH. icu test-suite fails in koji with 4.5.0, but passes locally with 4.4.4. If I get a chance after fiddling with all the licence foo I'll see if its truly gcc related or some specific icu bustage. C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
[sharkcz] ann: ann-libs-1.1.1-4.fc12.x86_64 = already in -libs [sharkcz] codeblocks: codeblocks-libs-10.05-1.fc14.x86_64 = fixed in CVS [sharkcz] openhpi: openhpi-libs-2.14.1-3.fc14.x86_64 = fixed in CVS [sharkcz] podofo: podofo-libs-0.8.1-2.fc14.x86_64 = correct in actual pkgs [sharkcz] sg3_utils: sg3_utils-libs-1.29-1.fc14.x86_64 = fixed in CVS [sharkcz] ski: ski-libs-1.3.2-8.fc12.x86_64 = already in -libs [sharkcz] squirrel: squirrel-libs-2.2.4-1.fc13.x86_64 = already in -libs [sharkcz] tailor: python-vcpx-0.9.35-8.fc14.noarch = fixed in CVS [sharkcz] tinyerp: tinyerp-server-4.2.3.4-6.fc12.noarch = correct in actual pkgs [sharkcz] wxGTK: wxBase-2.8.11-1.fc14.x86_64 = correct in actual pkgs [sharkcz] zabbix: zabbix-docs-1.8.2-1.fc14.noarch = no real content here since zabbix 1.8, only pointer to www -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Recoll package
Hello again, I am told that I need to add the FE-NEEDSPONSOR to the blocked bugs list for the review request. If I understand well, this is so that I can find a sponsor to become a Fedora package maintainer. Maybe I'm being a bit dense here, and not doing it the right way, but my primary hope was to find a good soul, Fedora package maintainer, to adopt this package on which there is quite probably little remaining work to do (as it builds, installs and has been looked at by without major objections). As a secondary option, I can follow the process to become a package maintainer, but doesn't this imply maintaining/reviewing multiple packages ? My apologies for bothering the list with the newbie questions, maybe I should have asked this first before creating the bugzilla entry. Regards, jfd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On Wed, 07 Jul 2010 16:29:01 -0400 Tom spot Callaway wrote: [michich] opencryptoki: opencryptoki-libs-2.3.1-6.fc14.x86_64 [michich] tpm-tools: tpm-tools-pkcs11-1.3.5-2.fc13.x86_64 Fixed and built for Rawhide. Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
[jskarvad] sendmail: sendmail-milter-8.14.4-8.fc14.x86_64 license added to sendmail-milter-8.14.4-9.fc14 regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On 07/07/2010 10:29 PM, Tom spot Callaway wrote: [jsafrane] net-snmp: 1:net-snmp-libs-5.5-16.fc14.x86_64 False positive, net-snmp-libs already contains COPYING in %doc [jsafrane] OpenIPMI: OpenIPMI-libs-2.0.18-2.fc14.x86_64 Fixed, OpenIPMI-2.0.18-3.fc14 Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/07/2010 04:29 PM, Tom spot Callaway wrote: [sgallagh] sssd: libcollection-0.4.0-15.fc14.x86_64 libpath_utils-0.2.0-15.fc14.x86_64 libref_array-0.1.0-15.fc14.x86_64 libdhash-0.4.0-15.fc14.x86_64 sssd-client-1.2.1-15.fc14.x86_64 All of these subpackages are in compliance. They have always carried all of the appropriate COPYING and COPYING.LESSER files. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkw1vhIACgkQeiVVYja6o6OmtwCeMEVW0Pc/DhhJ+zG4VdkYnQPW zCUAnRNJT8FKfTIdtb2ADM9ezLlmcC0F =TBoO -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Recoll package
On Thu, 2010-07-08 at 13:45 +0200, Jean-Francois Dockes wrote: Hello again, I am told that I need to add the FE-NEEDSPONSOR to the blocked bugs list for the review request. If I understand well, this is so that I can find a sponsor to become a Fedora package maintainer. Maybe I'm being a bit dense here, and not doing it the right way, but my primary hope was to find a good soul, Fedora package maintainer, to adopt this package on which there is quite probably little remaining work to do (as it builds, installs and has been looked at by without major objections). As a secondary option, I can follow the process to become a package maintainer, but doesn't this imply maintaining/reviewing multiple packages ? My apologies for bothering the list with the newbie questions, maybe I should have asked this first before creating the bugzilla entry. Regards, jfd hey, Becoming a package maintainer will need you to go through the links that Stanislav has provided. I guess you can ask Terje Røsten , who submitted the spec etc. to take over the review and package it (if you don't want to do it yourself) regards, Ankur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the rawhide tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires perl(:MODULE_COMPAT_5.10.1) On i386: perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires perl(:MODULE_COMPAT_5.10.1) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Data-Alias
perl-Data-Alias has broken dependencies in the rawhide tree: On x86_64: perl-Data-Alias-1.07-6.fc13.x86_64 requires perl(:MODULE_COMPAT_5.10.1) On i386: perl-Data-Alias-1.07-6.fc13.i686 requires perl(:MODULE_COMPAT_5.10.1) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Recoll package
Ankur Sinha writes: Becoming a package maintainer will need you to go through the links that Stanislav has provided. I guess you can ask Terje Røsten , who submitted the spec etc. to take over the review and package it (if you don't want to do it yourself) Thanks, I'll try this, then, if Terje Rosten is too busy already, will dance the sponsor dance ... Cheers, jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
[psabata] iproute: iproute-doc-2.6.34-3.fc14.x86_64 Should be fixed. Both iproute and iproute-doc now install the COPYING file. iproute-2.6.34-5.fc14 iproute-doc-2.6.34-5.fc14 -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100708 changes
Compose started at Thu Jul 8 08:15:12 UTC 2010 Broken deps for i386 -- BackupPC-3.1.0-14.fc14.noarch requires perl-suidperl GtkAda-devel-2.14.0-5.fc14.i686 requires libgnat-4.4.so PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2 cairo-java-1.0.5-12.fc12.i686 requires libgcj.so.10 claws-mail-plugins-geolocation-3.7.6-3.fc14.i686 requires libchamplain-gtk-0.4.so.0 claws-mail-plugins-geolocation-3.7.6-3.fc14.i686 requires libchamplain-0.4.so.0 compat-gcc-34-c++-3.4.6-18.i686 requires libstdc++ 0:4.5.0 dates-0.4.11-3.fc14.i686 requires libedataserver-1.2.so.11 deskbar-applet-2.30.0-1.1.fc14.i686 requires libedataserver-1.2.so.12 emerillon-0.1.1-2.fc13.i686 requires libchamplain-0.4.so.0 emerillon-0.1.1-2.fc13.i686 requires libchamplain-gtk-0.4.so.0 emerillon-devel-0.1.1-2.fc13.i686 requires pkgconfig(champlain-0.4) empathy-2.31.3-3.fc14.i686 requires libchamplain-gtk-0.4.so.0 empathy-2.31.3-3.fc14.i686 requires libchamplain-0.4.so.0 evolution-rss-0.1.9-7.20100525git.fc14.i686 requires libwebkit-1.0.so.2 fmt-ptrn-java-1.3.20-5.fc13.i686 requires libgcj.so.10 frysk-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-gnome-0.4-26.fc14.i386 requires libgcj.so.10 glib-java-0.2.6-16.fc12.i686 requires libgcj.so.10 gmpc-0.19.1-3.fc14.i686 requires libwebkit-1.0.so.2 gnome-phone-manager-0.65-6.fc14.i686 requires libgnome-bluetooth.so.7 gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-0.4.so.0 gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-gtk-0.4.so.0 kst-fits-1.8.0-7.fc14.i686 requires cfitsio = 0:3.240 lekhonee-gnome-0.11-2.fc14.i686 requires libwebkit-1.0.so.2 libgconf-java-2.12.4-14.fc12.i686 requires libgcj.so.10 libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10 libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10 libgtk-java-2.8.7-13.fc13.i686 requires libgcj.so.10 libpeas-0.5.1-1.fc14.i686 requires libgdk_pixbuf-3.0.so.0 libpeas-devel-0.5.1-1.fc14.i686 requires libgdk_pixbuf-3.0.so.0 libvte-java-0.12.1-15.fc12.i686 requires libgcj.so.10 merkaartor-0.16.1-1.fc13.i686 requires libexiv2.so.6 mine_detector-6.0-3.fc13.i686 requires libgnat-4.4.so mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires mingw32(libpng-3.dll) moblin-panel-status-0.1.21-3.fc14.i686 requires libchamplain-0.4.so.0 perl-DBI-Dumper-2.01-8.fc12.i686 requires perl(:MODULE_COMPAT_5.10.0) perl-Data-Alias-1.07-6.fc13.i686 requires perl(:MODULE_COMPAT_5.10.1) perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires perl(:MODULE_COMPAT_5.10.1) perl-Test-AutoBuild-1.2.2-9.fc12.i686 requires perl(:MODULE_COMPAT_5.10.0) plexus-containers-component-annotations-javadoc-1.0-0.1.a34.7.fc12.noarch requires jakarta-commons-logging-javadoc plplot-ada-5.9.6-1.fc14.i686 requires libgnat-4.4.so python3-beaker-1.5.3-4.fc14.noarch requires python3-paste qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18 shotwell-0.5.2-1.fc14.i686 requires libwebkit-1.0.so.2 skyviewer-1.0.0-4.fc14.i686 requires libQGLViewer.so.2.3.5 spacewalk-certs-tools-1.1.1-1.fc14.noarch requires spacewalk-backend-libs = 0:0.8.28 themonospot-gui-qt-0.1.3-6.fc14.i686 requires mono(qt-dotnet) = 0:4.5.0.0 themonospot-gui-qt-0.1.3-6.fc14.i686 requires libqyotoshared.so.1 vfrnav-0.4-1.fc13.i686 requires libgps.so.18 viking-0.9.91-3.fc13.i686 requires libgps.so.18 wfut-1.1.0-8.fc12.i686 requires libgcj.so.10 xcf-pixbuf-loader-0.0.1-3.8af913d1.fc14.i686 requires /usr/lib/gtk-2.0/2.10.0/loaders xenner-0.48-1.fc14.i386 requires libxenguest.so.3.4 Broken deps for x86_64 -- BackupPC-3.1.0-14.fc14.noarch requires perl-suidperl GtkAda-devel-2.14.0-5.fc14.i686 requires libgnat-4.4.so GtkAda-devel-2.14.0-5.fc14.x86_64 requires libgnat-4.4.so()(64bit) PragmARC-20060427-6.fc13.i686 requires libgnarl-4.4.so PragmARC-20060427-6.fc13.i686 requires libgnat-4.4.so PragmARC-20060427-6.fc13.x86_64 requires libgnat-4.4.so()(64bit) PragmARC-20060427-6.fc13.x86_64 requires libgnarl-4.4.so()(64bit) 1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9 1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2 1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit) 1:anjuta-2.30.0.0-2.fc14.x86_64 requires
Re: Licensing Guidelines Update - Please Read
On 07/07/2010 10:29 PM, Tom spot Callaway wrote: [plautrba] finger: finger-server-0.17-39.fc12.x86_64 Fixed and built for Rawhide. Petr -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On Wednesday, July 07, 2010 10:29:01 pm Tom spot Callaway wrote: file-libs-5.04-10.fc14.x86_64 Fixed in rawhide devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce Jan Kaluza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On 07/07/2010 06:08 PM, Matt Domsch wrote: cim-schema-docs has no license file packaged with it. /me blames the DMTF. The content is a separate tarball. I suppose we could suck the license file out of the other content zip (the MOF files) and include here. Thoughts? If the appropriate license is included in another source tarball which is already part of the SRPM, please use it to meet this requirement. If not, you do not need to do anything. mirrormanager-client and gpxe* are false positives - all subpackages include the licenses in %doc. Thanks! ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On 07/07/2010 10:49 PM, Juan Rodriguez wrote: On Wed, Jul 7, 2010 at 3:29 PM, Tom spot Callaway tcall...@redhat.com mailto:tcall...@redhat.com wrote: [nushio] rabbitvcs: rabbitvcs-core-0.13.3-1.fc14.noarch I'm not very well versed in legalese, but rabbitvcs-core does include the following files: /usr/share/doc/rabbitvcs-core-0.13.3/AUTHORS /usr/share/doc/rabbitvcs-core-0.13.3/COPYING /usr/share/doc/rabbitvcs-core-0.13.3/MAINTAINERS The rest of the subpackages require explicitly installing rabbitvcs-core, so copying COPYING into them is unnecessary. So, if I understood correctly, it's a false positive for rabbitvcs-core too. (There's no rabbitvcs package btw, that might have triggered it?) That's right, this is a false positive, and it was triggered because the subpackage base name did not exactly match the source package base name. :) Thanks for checking! ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On 07/08/2010 03:07 AM, Till Maas wrote: On Wed, Jul 07, 2010 at 04:29:01PM -0400, Tom spot Callaway wrote: However, if a subpackage is independent of any base package (it does not require it, either implicitly or explicitly), it must include copies of any license texts (as present in the source) which are applicable to the files contained within the subpackage. What about debuginfo packages? They do not require the base package but usually also do not include the license texts. A great question. Debuginfo packages are special. IMHO, there are multiple ways that we could improve debuginfo packages, specifically: - Generating debuginfo packages that match up to subpackages as opposed to being catch-all super packages. - Having subpackage specific debuginfo packages depend upon the files for which they provide debuginfo (or simply dependent on the subpackage that they match up to) If those items came to pass, then we would not have licensing concerns with debuginfo packages. (Adding Roland to the explicit CC here, because this hadn't really occurred to me before, but would be another great reason to make these changes.) However, because of how the debuginfo packages are generated (in the common case at least), maintainers do not need to worry about adding license texts to them at this time, as that would add significant complexity. ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On 07/08/2010 03:44 AM, Caolán McNamara wrote: On Wed, 2010-07-07 at 16:29 -0400, Tom spot Callaway wrote: Basically, what this means is this: If you maintain a package, and that package generates subpackages, then each subpackage must either include a copy of the appropriate licensing texts (as available in the source), or it must Require (either implicitly or explicitly) another subpackage which does include the appropriate licensing texts. Is there any point in say, splitting a package into an additional -licence/-doc subpackage and adding Requires on that from the other subpackages ? That is certainly your choice as a package maintainer, but I'm not going to say that you _MUST_ do that. I'm not advocating making the dependency chain any longer or more complex. :) ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On 07/08/2010 03:52 AM, Ralf Corsepius wrote: Can you elaborate the cases below? I can't spot anything wrong with them: [corsepiu] gtkglext: gtkglext-libs-1.2.0-10.fc12.x86_64 # repoquery -ql 'gtkglext-libs' ... /usr/share/doc/gtkglext-libs-1.2.0/AUTHORS /usr/share/doc/gtkglext-libs-1.2.0/COPYING /usr/share/doc/gtkglext-libs-1.2.0/COPYING.LIB /usr/share/doc/gtkglext-libs-1.2.0/ChangeLog /usr/share/doc/gtkglext-libs-1.2.0/README /usr/share/doc/gtkglext-libs-1.2.0/TODO [corsepiu] OpenSceneGraph: OpenThreads-2.8.3-1.fc14.x86_64 # repoquery -ql OpenThreads.i686 ... /usr/share/doc/OpenThreads-2.8.2/AUTHORS.txt /usr/share/doc/OpenThreads-2.8.2/LICENSE.txt /usr/share/doc/OpenThreads-2.8.2/NEWS.txt /usr/share/doc/OpenThreads-2.8.2/README.txt Both are cases where the binary base packages' names differ from the srpm name. This fact is why they got flagged. Both of these are clearly false positives, thank you for checking them. ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On 07/08/2010 04:12 AM, Michael Schwendt wrote:
On Wed, 07 Jul 2010 16:29:01 -0400, Tom wrote:
However, if a subpackage is independent of any base package (it does
not require it, either implicitly or explicitly), it must include
copies of any license texts (as present in the source) which are
applicable to the files contained within the subpackage.
With this we've reached the point once more where the default %doc dir is
a poor choice, because it is based on the subpackage's %{name} instead of
the src.rpm's or base package's %{name}.
For the common tools'n'library split of a package, the changed guidelines
duplicate the license files by storing them in two different directories
when using %doc:
/usr/share/doc/name-1.0/COPYING
/usr/share/doc/name-libs-1.0/COPYING
Yes, I absolutely understand that. The intent is to minimize this by
leveraging dependencies (tools depends on libs). A common, system-wide
directory for license files to be dropped into is a recipe for disaster
(COPYING conflicts with COPYING).
http://rpm.org/ticket/116, if it were implemented as I've proposed,
attempts to address this by setting up a common license dir, then
comparing the license text payload against existant files in that
license dir, and if a match occurs (not just a filename match), the file
would become a hard link to the file in the common license dir.
If no match is found, the file is written into the docdir.
This allows for us to make a common-licenses package that is default
installed as part of Fedora and minimize license text duplication.
Although, as James Antill pointed out on that ticket, license text
duplication doesn't really account for too much disk space. They're
small to begin with.
There is actually a benefit to having the subpackage name be part of the
license location, in situations where the independent subpackage name
significantly differs from the basename of the source package, it is
easier for someone not versed in RPM to locate the applicable license
texts while traversing /usr/share/doc/ .
~spot
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On 07/08/2010 04:39 AM, Ankur Sinha wrote: Can you please clarify this one? The sub packages depend on the -common, which has the LICENSE etc. docs. Is this because the main package doesn't Requires: -common? Caveat: I have not looked at your specific spec, so I am hypothesizing here. Lets say that your beteckna-fonts SRPM generates these binary RPMS: - beteckna-fonts - beteckna-fonts-common - beteckna-fonts-shiny If both beteckna-fonts and beteckna-fonts-shiny depend (either implicitly or explicitly) on beteckna-fonts-common, and beteckna-fonts-common has the license texts in it, you do not need to do anything. If beteckna-fonts (or beteckna-fonts-shiny) does not depend (either implicitly or explicitly) on beteckna-fonts-common, then you will need to add copies of the license text to that package. ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On Wednesday, July 07, 2010 10:29:01 pm Tom spot Callaway wrote: Hello Fedora! Please take a moment and read this email. There's cake in it for you. [jreznik] leonidas-kde-theme: leonidas-kde-theme-lion-11.0.3-1.fc12.noarch leonidas-kde-theme-landscape-11.0.3-1.fc12.noarch rpmls leonidas-kde-theme-lion-11.0.3-1.fc14.noarch.rpm | grep COPYING -rw-r--r-- /usr/share/doc/leonidas-kde-theme-lion-11.0.3/COPYING.CC-BY-SA -rw-r--r-- /usr/share/doc/leonidas-kde-theme-lion-11.0.3/COPYING.GPLv2 rpmls leonidas-kde-theme-landscape-11.0.3-1.fc14.noarch.rpm | grep COPYING -rw-r--r-- /usr/share/doc/leonidas-kde-theme-landscape-11.0.3/COPYING.CC-BY- SA -rw-r--r-- /usr/share/doc/leonidas-kde-theme-landscape-11.0.3/COPYING.GPLv2 [jreznik] system-config-netboot: system-config-netboot-cmd-0.1.45.4-8.fc13.noarch Fixed in system-config-netboot-cmd-0.1.45.4-9.fc14, building right now but probably it would be better to eol this package. No cake from me... R. -- Jaroslav Řezník jrez...@redhat.com Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
2010/7/8 Tom spot Callaway tcall...@redhat.com:
On 07/08/2010 04:12 AM, Michael Schwendt wrote:
On Wed, 07 Jul 2010 16:29:01 -0400, Tom wrote:
However, if a subpackage is independent of any base package (it does
not require it, either implicitly or explicitly), it must include
copies of any license texts (as present in the source) which are
applicable to the files contained within the subpackage.
With this we've reached the point once more where the default %doc dir is
a poor choice, because it is based on the subpackage's %{name} instead of
the src.rpm's or base package's %{name}.
For the common tools'n'library split of a package, the changed guidelines
duplicate the license files by storing them in two different directories
when using %doc:
/usr/share/doc/name-1.0/COPYING
/usr/share/doc/name-libs-1.0/COPYING
Yes, I absolutely understand that. The intent is to minimize this by
leveraging dependencies (tools depends on libs). A common, system-wide
directory for license files to be dropped into is a recipe for disaster
(COPYING conflicts with COPYING).
Dose this mean we only need to add license text to -libs subpackage
instead of base package if we assume the base package depends on -libs
subpackage?
Chen Lei
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On 07/07/2010 04:29 PM, Tom spot Callaway wrote: [omajid] dbus-java: dbus-java-javadoc-2.7-3.fc13.noarch [omajid] libmatthew-java: libmatthew-java-javadoc-0.7.2-2.fc13.x86_64 Fixed in rawhide. Cheers, Omair -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On Thu, 2010-07-08 at 10:00 -0400, Tom spot Callaway wrote: On 07/08/2010 04:39 AM, Ankur Sinha wrote: Can you please clarify this one? The sub packages depend on the -common, which has the LICENSE etc. docs. Is this because the main package doesn't Requires: -common? Caveat: I have not looked at your specific spec, so I am hypothesizing here. Lets say that your beteckna-fonts SRPM generates these binary RPMS: - beteckna-fonts - beteckna-fonts-common - beteckna-fonts-shiny If both beteckna-fonts and beteckna-fonts-shiny depend (either implicitly or explicitly) on beteckna-fonts-common, and beteckna-fonts-common has the license texts in it, you do not need to do anything. If beteckna-fonts (or beteckna-fonts-shiny) does not depend (either implicitly or explicitly) on beteckna-fonts-common, then you will need to add copies of the license text to that package. ~spot okay, got it. thanks!! Ankur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On 07/08/2010 10:37 AM, Chen Lei wrote: Dose this mean we only need to add license text to -libs subpackage instead of base package if we assume the base package depends on -libs subpackage? If the base package depends on -libs subpackage, then you can only put the license text in -libs. ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Test-Differences/devel perl-Test-Differences.spec, 1.13, 1.14
Author: iarnell
Update of /cvs/pkgs/rpms/perl-Test-Differences/devel
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv30625
Modified Files:
perl-Test-Differences.spec
Log Message:
* Thu Jul 08 2010 Iain Arnell iarn...@gmail.com 0.500-2
- explicitly require perl(Text::Diff)
Index: perl-Test-Differences.spec
===
RCS file:
/cvs/pkgs/rpms/perl-Test-Differences/devel/perl-Test-Differences.spec,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -p -r1.13 -r1.14
--- perl-Test-Differences.spec 1 Jul 2010 09:15:24 - 1.13
+++ perl-Test-Differences.spec 8 Jul 2010 14:49:10 - 1.14
@@ -4,7 +4,7 @@
Name: perl-Test-Differences
Version:%{RPM_version}
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Test strings and data structures and show differences if not OK
Group: Development/Libraries
@@ -19,6 +19,8 @@ BuildRequires: perl(ExtUtils::MakeMaker
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
+# not detected
+Requires: perl(Text::Diff) = 0.35
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
@@ -60,6 +62,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Jul 08 2010 Iain Arnell iarn...@gmail.com 0.500-2
+- explicitly require perl(Text::Diff)
+
* Tue Jun 29 2010 Paul Howarth p...@city-fan.org - 0.5000-1
- Update to 0.500
- Add support for all diff styles supplied by Text::Diff (CPAN RT#23579)
--
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: Licensing Guidelines Update - Please Read
On 07/07/2010 10:29 PM, Tom spot Callaway wrote: [kklic] emacs: 1:emacs-common-23.2-5.fc14.x86_64 1:emacs-el-23.2-5.fc14.x86_64 Fixed in rawhide. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 612583] New: perl-PadWalker request for EL-6 branch
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-PadWalker request for EL-6 branch https://bugzilla.redhat.com/show_bug.cgi?id=612583 Summary: perl-PadWalker request for EL-6 branch Product: Fedora EPEL Version: el5 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: perl-PadWalker AssignedTo: rob.my...@gtri.gatech.edu ReportedBy: iarn...@gmail.com QAContact: extras...@fedoraproject.org CC: rob.my...@gtri.gatech.edu, fedora-perl-devel-l...@redhat.com Classification: Fedora perl-PadWalker made it's way into *some* arches for RHEL-6, the decision in the last EPEL meeting was that we'd rebuild the RH packages and distribute them where there was a desire for the package. As such, please could we have an EL-6 branch built using the RH src.rpm -- 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
please discuss: sane naming of critical path comps groups
Hiyas, currently the critical path comps groups are named like this: core critical-path-base critical-path-gnome critical-path-apps critical-path-kde critical-path-lxde critical-path-xfce Since these groups do not share a common prefix unique to all critical path comps groups, I want to propose to change this. E.g. there could be a) a critical-path-core group with the same contents as core b) or with only a groupreq on core c) or the critical-path-base group could get a groupreq on core. I would welcome any of these solutions or any other that makes it possible to easily identify all critical path comps groups with a simple pattern like critical-path-*, so one can easily benefit from these groups using yum with the group filter plugin. Reference: https://fedoraproject.org/wiki/Talk:Critical_path_package Regards Till pgpJZhzjYXzRB.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On Wed, 2010-07-07 at 16:29 -0400, Tom spot Callaway wrote: [ankursinha] beteckna-fonts: beteckna-fonts-common-0.3-5.fc12.noarch built in rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=2305148 regards, Ankur -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
A mass rebuild would be recommended as the new compiler will produce faster code. I believe everything will benefit and it's worth looking into. For example I noticed a significant difference on the OpenSUSE distro when GCC was upgraded and they repackaged their software with it in their development version 11.3. Anecdotal for sure but everything seemed faster than the build before that change. Phoronix has also done some benchmarks with the Ubuntu distro to determine that GCC 4.5 produces faster code (in some areas). On Thu, Jul 8, 2010 at 3:43 AM, Jakub Jelinek ja...@redhat.com wrote: On Thu, Jul 08, 2010 at 12:54:35PM +0530, Rahul Sundaram wrote: On 07/08/2010 12:48 PM, Jakub Jelinek wrote: F14 now has gcc-4.5-RH compiler instead of 4.4-RH. For the changes (especially user visible ones), see http://gcc.gnu.org/gcc-4.5/changes.html Do you plan on doing a mass rebuild? I don't think it is necessary, at least not for the reason of a compiler upgrade. The mass rebuilds are usually done when we have some toolchain or rpm feature that we want to push into all packages. Jakub -- 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: please discuss: sane naming of critical path comps groups
Till Maas (opensou...@till.name) said: Since these groups do not share a common prefix unique to all critical path comps groups, I want to propose to change this. E.g. there could be a) a critical-path-core group with the same contents as core b) or with only a groupreq on core c) or the critical-path-base group could get a groupreq on core. groupreqs are not a functional item. If we assume that 'core' is the only exception, is it really that bad? Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hey Presto!
On Mon, Jun 14, 2010 at 10:24:13AM +0200, Michael Schroeder wrote:
It's not that hard to fix, there's no need to keep the target
rpm in memory at all. The source rpm can be limited to some
max size with the down side that the end of the target rpm
cannot match the start of the source rpm anymore. This shouldn't
do much harm in the real world.
I've already looked at the code, it shouldn't be much work to
implement. I'll try to do it this or next week.
Ok, the current git version now understands a '-m mbytes'
option that limits the memory usage.
The downside is that now the deltarpm must be held in memory,
but it should be small in most cases.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: please discuss: sane naming of critical path comps groups
On Thu, Jul 08, 2010 at 11:34:25AM -0400, Bill Nottingham wrote: Till Maas (opensou...@till.name) said: Since these groups do not share a common prefix unique to all critical path comps groups, I want to propose to change this. E.g. there could be a) a critical-path-core group with the same contents as core b) or with only a groupreq on core c) or the critical-path-base group could get a groupreq on core. groupreqs are not a functional item. If we assume that 'core' is the only exception, is it really that bad? Yes, it makes it easier to make mistakes if people assume that these commands affect all critical path updates: yum groupinfo -v critical-path\* yum --filter-groups=critical-path\* (requires yum-filter-data plugin) Which people do, because these commands have been posted on this list and nobody objected that the group core is missing. Also with the group core, the command line for the second comamnd will become nearly twice as long and everything is more complicated for everyone everytime instead of the few times the comps groups are edited. Regards Till pgpyyVS5uPgyY.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
On Thu, 2010-07-08 at 11:31 -0400, Brandon Lozza wrote: A mass rebuild would be recommended as the new compiler will produce faster code. I believe everything will benefit and it's worth looking into. For example I noticed a significant difference on the OpenSUSE distro when GCC was upgraded and they repackaged their software with it in their development version 11.3. Anecdotal for sure but everything seemed faster than the build before that change. Phoronix has also done some benchmarks with the Ubuntu distro to determine that GCC 4.5 produces faster code (in some areas). Anecdotal. Seemed. In some areas. This is not a compelling argument. - 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: rpms/perl/devel perl.spec,1.273,1.274
On 07/08/2010 05:07 PM, Marcela Mašláňová wrote:
Author: mmaslano
Index: perl.spec
===
RCS file: /cvs/pkgs/rpms/perl/devel/perl.spec,v
retrieving revision 1.273
retrieving revision 1.274
diff -u -p -r1.273 -r1.274
--- perl.spec 28 Jun 2010 06:21:07 - 1.273
+++ perl.spec 8 Jul 2010 15:07:23 - 1.274
@@ -12,7 +12,7 @@ Name: perl
Version:%{perl_version}
# DON'T BUILD NOW in rawhide, only into scratch or test buildroot
# release number must be even higher, becase dual-lived modules will be
broken otherwise
Marcela, could you elaborate this comment? Is it still valid?
Ralf
--
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: gcc-4.5-RH in F14
2010/7/8 Jakub Jelinek ja...@redhat.com: Generally, much better speedup can be achieved by using PGO (-fprofile-generate, run on some testsuite, -fprofile-use). GCC itself is built that way for several years, but it would be useful if other performance sensitive packages were built that way too, assuming they have some testsuite which resembles common use. E.g. bash can be easily trained on some configure or some other large shell scripts, similarly for python, perl, ... The speedups from this can go up to say 30% or so. Jakub -- It seems MeeGo builds core packages by using PGO already. Is there anyone who would like to volunteer to write a packaging guideline about using PGO? Regards, Chen Lei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On Wed, 2010-07-07 at 16:29 -0400, Tom spot Callaway wrote: Q. I thought duplicating files in a spec was forbidden? A. This is a permitted exception to that. Can we get this new exception reflected in the packaging and review guidelines, please ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
Le 07/07/2010 22:29, Tom spot Callaway a écrit : [remi] mysql++: mysql++-manuals-3.1.0-1.fc14.x86_64 done [remi] ocsinventory: ocsinventory-reports-1.3.2-3.fc14.noarch false positive Regards -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-GnuPG-Interface/EL-6 .cvsignore, 1.4, 1.5 perl-GnuPG-Interface.spec, 1.11, 1.12 sources, 1.4, 1.5
Author: mdomsch
Update of /cvs/extras/rpms/perl-GnuPG-Interface/EL-6
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv28707
Modified Files:
.cvsignore perl-GnuPG-Interface.spec sources
Log Message:
update to match devel branch
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-GnuPG-Interface/EL-6/.cvsignore,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- .cvsignore 21 May 2008 00:32:59 - 1.4
+++ .cvsignore 8 Jul 2010 16:31:35 - 1.5
@@ -1 +1 @@
-GnuPG-Interface-0.36.tar.gz
+GnuPG-Interface-0.42.tar.gz
Index: perl-GnuPG-Interface.spec
===
RCS file: /cvs/extras/rpms/perl-GnuPG-Interface/EL-6/perl-GnuPG-Interface.spec,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -p -r1.11 -r1.12
--- perl-GnuPG-Interface.spec 26 Jul 2009 06:18:18 - 1.11
+++ perl-GnuPG-Interface.spec 8 Jul 2010 16:31:35 - 1.12
@@ -1,6 +1,6 @@
Name: perl-GnuPG-Interface
-Version:0.36
-Release: 3%{?dist}
+Version:0.42
+Release:4%{?dist}
Summary:Perl interface to GnuPG
Group: Development/Libraries
License:GPLv2+ or Artistic
@@ -8,9 +8,9 @@ URL:http://search.cpan.org/d
Source0:
http://cpan.org/modules/by-module/GnuPG/GnuPG-Interface-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
-BuildRequires: gpg, perl(Class::MethodMaker), perl(ExtUtils::MakeMaker)
+BuildRequires: gpg, perl(Any::Moose), perl(ExtUtils::MakeMaker)
Requires: gpg, perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-Requires: perl(Class::MethodMaker)
+Requires: perl(Any::Moose)
%description
@@ -35,7 +35,8 @@ chmod -R u+w $RPM_BUILD_ROOT/*
%check
chmod 0700 test
-make test
+# GnuPG-Interface needs to read from /dev/tty to run its tests.
+# make test
%clean
rm -rf $RPM_BUILD_ROOT
@@ -44,11 +45,26 @@ rm -rf $RPM_BUILD_ROOT
%defattr(-,root,root,-)
%doc ChangeLog README NEWS THANKS COPYING GPL Artistic
%{perl_vendorlib}/GnuPG
-%{perl_vendorlib}/auto/GnuPG
%{_mandir}/man3/*.3*
%changelog
+* Thu Jul 8 2010 Matt Domsch mdom...@fedoraproject.org - 0.42-4.el6
+- rebuild for RHEL 6
+
+* Sun May 02 2010 Marcela Maslanova mmasl...@redhat.com - 0.42-4
+- Mass rebuild with perl-5.12.0
+
+* Mon Dec 7 2009 Stepan Kasal ska...@redhat.com - 0.42-3
+- rebuild against perl 5.10.1
+
+* Sun Oct 04 2009 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 0.42-2
+- Disable tests because they need /dev/tty to run
+
+* Fri Oct 02 2009 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 0.42-1
+- Update to 0.42
+- Fix rpmlint errors
+
* Sat Jul 25 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.36-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
@@ -82,7 +98,7 @@ rm -rf $RPM_BUILD_ROOT
- FC-3 doesn't use the patch1
* Sun Sep 11 2005 Matt Domsch m...@domsch.com 0.33-3
-- use perldoc -t and %_smp_mflags
+- use perldoc -t and the _smp_mflags macro
* Sun Aug 28 2005 Matt Domsch m...@domsch.com 0.33-2
- add Requires: gpg, always apply secret-key-output-1.patch, as it works on
Index: sources
===
RCS file: /cvs/extras/rpms/perl-GnuPG-Interface/EL-6/sources,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -r1.4 -r1.5
--- sources 21 May 2008 00:32:59 - 1.4
+++ sources 8 Jul 2010 16:31:35 - 1.5
@@ -1 +1 @@
-6f097d3076b3311e8ef20ce3c2865c66 GnuPG-Interface-0.36.tar.gz
+c5cc5426c02b93900cb96f4879c9be28 GnuPG-Interface-0.42.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: Hey Presto!
On Thu, 2010-07-08 at 17:33 +0200, Michael Schroeder wrote: On Mon, Jun 14, 2010 at 10:24:13AM +0200, Michael Schroeder wrote: It's not that hard to fix, there's no need to keep the target rpm in memory at all. The source rpm can be limited to some max size with the down side that the end of the target rpm cannot match the start of the source rpm anymore. This shouldn't do much harm in the real world. I've already looked at the code, it shouldn't be much work to implement. I'll try to do it this or next week. Ok, the current git version now understands a '-m mbytes' option that limits the memory usage. The downside is that now the deltarpm must be held in memory, but it should be small in most cases. Built for Rawhide and available at http://koji.fedoraproject.org/koji/buildinfo?buildID=182465 until it gets pushed. Jonathan signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Glib/EL-5 perl-Glib.spec,1.20,1.21 sources,1.14,1.15
Author: spot
Update of /cvs/pkgs/rpms/perl-Glib/EL-5
In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv17302
Modified Files:
perl-Glib.spec sources
Log Message:
disable tests
Index: perl-Glib.spec
===
RCS file: /cvs/pkgs/rpms/perl-Glib/EL-5/perl-Glib.spec,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -p -r1.20 -r1.21
--- perl-Glib.spec 16 Oct 2007 17:03:05 - 1.20
+++ perl-Glib.spec 8 Jul 2010 17:34:50 - 1.21
@@ -1,6 +1,6 @@
Name: perl-Glib
-Version:1.143
-Release:1%{?dist}
+Version:1.223
+Release:1%{?dist}.1
Summary:Perl interface to GLib
Group: Development/Libraries
@@ -12,16 +12,26 @@ BuildRoot: %{_tmppath}/%{name}-%{ve
BuildRequires: perl = 2:5.8.0
BuildRequires: glib2-devel
BuildRequires: perl(ExtUtils::Depends), perl(ExtUtils::PkgConfig)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
-This module provides perl access to Glib and GLib's GObject libraries.
+This module provides perl access to GLib and GLib's GObject libraries.
GLib is a portability and utility library; GObject provides a generic
type system with inheritance and a powerful signal system. Together
these libraries are used as the foundation for many of the libraries
that make up the Gnome environment, and are used in many unrelated
projects.
+%package devel
+Summary: Development part of Perl interface to GLib
+Group: Development/Libraries
+Requires: %{name} = %{version}-%{release}
+
+%description devel
+Development part of package perl-Glib, the Perl module providing interface
+to GLib and GObject libraries.
%prep
%setup -q -n Glib-%{version}
@@ -34,11 +44,9 @@ __EOF__
%define __perl_provides %{_builddir}/Glib-%{version}/%{name}-perl.prov
chmod +x %{__perl_provides}
-
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
-make %{?_smp_mflags}
-
+make
%install
rm -rf $RPM_BUILD_ROOT
@@ -48,24 +56,93 @@ find $RPM_BUILD_ROOT -type f -name '*.bs
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null ';'
chmod -R u+w $RPM_BUILD_ROOT/*
-
%check
-make test
-
+# make test
%clean
rm -rf $RPM_BUILD_ROOT
-
%files
%defattr(-,root,root,-)
-%doc AUTHORS ChangeLog LICENSE NEWS README TODO
+%doc AUTHORS ChangeLog.pre-git LICENSE NEWS README TODO
%{perl_vendorarch}/auto/Glib/
%{perl_vendorarch}/Glib*
%{_mandir}/man3/*.3pm*
+%exclude %{perl_vendorarch}/Glib/*/*.h
+%exclude %{perl_vendorarch}/Glib/MakeHelper.pm
+%exclude %{perl_vendorarch}/Glib/devel.pod
+%exclude %{perl_vendorarch}/Glib/xsapi.pod
+%exclude %{_mandir}/man3/Glib::MakeHelper.3pm.gz
+%exclude %{_mandir}/man3/Glib::devel.3pm.gz
+%exclude %{_mandir}/man3/Glib::xsapi.3pm.gz
+
+
+%files devel
+%defattr(-,root,root,-)
+%{perl_vendorarch}/Glib/*/*.h
+%{perl_vendorarch}/Glib/MakeHelper.pm
+%{perl_vendorarch}/Glib/devel.pod
+%{perl_vendorarch}/Glib/xsapi.pod
+%{_mandir}/man3/Glib::MakeHelper.3pm.gz
+%{_mandir}/man3/Glib::devel.3pm.gz
+%{_mandir}/man3/Glib::xsapi.3pm.gz
%changelog
+* Thu Jul 8 2010 Tom spot Callaway tcall...@redhat.com - 1.223-1.1
+- disable tests on EL-5, they fail oddly on i386
+ WARNING: If this package breaks, you get to keep all the pieces.
+
+* Thu Jul 01 2010 Tom spot Callaway tcall...@redhat.com - 1.223-1
+- update to 1.223
+
+* Sun May 02 2010 Marcela Maslanova mmasl...@redhat.com - 1.201-5
+- Mass rebuild with perl-5.12.0
+
+* Sat Jul 25 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.201-4
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
+
+* Fri Jul 17 2009 Stepan Kasal ska...@redhat.com - 1.201-3
+- create devel subpackage, so that the main one does not require
+ the whole perl-devel (#509419)
+
+* Fri Mar 13 2009 Tom spot Callaway tcall...@redhat.com - 1.201-2
+- dont run the tests on ppc
+
+* Fri Mar 13 2009 Tom spot Callaway tcall...@redhat.com - 1.201-1
+- update to 1.201
+
+* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.183-2
+- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
+
+* Thu Sep 11 2008 Tom spot Callaway tcall...@redhat.com - 1.183-1
+- update to 1.183
+
+* Wed Feb 27 2008 Tom spot Callaway tcall...@redhat.com - 1.162-5
+- Rebuild for perl 5.10 (again)
+
+* Tue Feb 19 2008 Fedora Release Engineering rel-...@fedoraproject.org -
1.162-4
+- Autorebuild for GCC 4.3
+
+* Tue Feb 5 2008 Tom spot Callaway tcall...@redhat.com - 1.162-3
+- rebuild for new perl
+
+* Tue Jan 15 2008 Tom spot Callaway tcall...@redhat.com - 1.162-2
+- disable smp_mflags, they break on massively SMP boxes (bz 428911)
+
+* Mon Dec 17 2007 Tom spot Callaway tcall...@redhat.com - 1.162-1
+- 1.162
+
+* Tue Oct 16 2007 Tom spot Callaway tcall...@redhat.com - 1.144-1.2
+- add BR:
Take over of libart_lgpl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, I will inform you, that I have take ownership of the libart_lgpl package. Best Regards: Jochen Schmitt -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iJwEAQECAAYFAkw2DmcACgkQZLAIBz9lVu87FQP/ZCNombs2DIb04u07L+GLnH/G E8XG7Jj8UyIZRi824sLg1Chgoz74CNOkhGh3oRygUQcRrj9Ej+y6qRsFnQhWFlA1 ph15B3eHzR04pFvjuWu+MdHJNjLX+eNZ+CzRMKBfHj6PA1ivt0D4eIWn59rcZoaU VqdvrhfgLo1oTi+G9/0= =Efp3 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 552616] branch perl-Glib for EPEL-5 please
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=552616 Tom spot Callaway tcall...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from Tom spot Callaway tcall...@redhat.com 2010-07-08 13:44:20 EDT --- Built in EL-5. Tests disabled due to the fact that they're acting VERY weird on i386. It would not surprise me to find that there are bugs in this code somewhere. -- 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
[Bug 552616] branch perl-Glib for EPEL-5 please
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=552616 --- Comment #6 from Fedora Update System upda...@fedoraproject.org 2010-07-08 13:45:23 EDT --- perl-Glib-1.223-1.el5.1 has been submitted as an update for Fedora EPEL 5. http://admin.fedoraproject.org/updates/perl-Glib-1.223-1.el5.1 -- 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: Licensing Guidelines Update - Please Read
On 07/08/2010 12:09 PM, Matthias Clasen wrote: On Wed, 2010-07-07 at 16:29 -0400, Tom spot Callaway wrote: Q. I thought duplicating files in a spec was forbidden? A. This is a permitted exception to that. Can we get this new exception reflected in the packaging and review guidelines, please ? Well, the Packaging:LicensingGuidelines are part of the packaging guidelines, so the first half is technically done, but it could be made more clear in the main Guidelines section. I've made those changes now. Thanks, ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Hey Presto!
On 8 July 2010 18:04, Jonathan Dieter jdie...@lesbg.com wrote: On Thu, 2010-07-08 at 17:33 +0200, Michael Schroeder wrote: On Mon, Jun 14, 2010 at 10:24:13AM +0200, Michael Schroeder wrote: It's not that hard to fix, there's no need to keep the target rpm in memory at all. The source rpm can be limited to some max size with the down side that the end of the target rpm cannot match the start of the source rpm anymore. This shouldn't do much harm in the real world. I've already looked at the code, it shouldn't be much work to implement. I'll try to do it this or next week. Ok, the current git version now understands a '-m mbytes' option that limits the memory usage. The downside is that now the deltarpm must be held in memory, but it should be small in most cases. Built for Rawhide and available at http://koji.fedoraproject.org/koji/buildinfo?buildID=182465 until it gets pushed. FWIW, this now appears fixed for me. The entire latest push came down in deltas so thanks to whoever sorted this (Jonathan?) -- Christopher Brown -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Outage: PHX2 outage - 2010-07-05 01:00 UTC
On Tue, Jul 6, 2010 at 6:02 PM, Mike McGrath mmcgr...@redhat.com wrote: There is an ongoing outage at this time in PHX2. The exact start time is not yet known and the ETA to be fixed is not yet known. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2010-07-05 01:00' Reason for outage: Several people are experiencing issues connecting to various Fedora services (see below). The cause for these issues seems to be network related and it is impacting different people differently. Some see packet loss, other see complete connectivity loss and other still aren't having any issues at all. Some services listed as unaffected would have been impacted previously to this announcement but as we became aware of the issue have made some changes to bring those services back online. Those services include bodhi, the account system, pkgdb, main website/wiki, community and mirrormanager. Affected Services: Bodhi - https://admin.fedoraproject.org/updates/ Buildsystem - http://koji.fedoraproject.org/ CVS / Source Control DNS - ns1.fedoraproject.org, ns2.fedoraproject.org Wouldn't having the two only primary DNS servers involved in the outage affect the services below as well? Is there a reason both DNS servers are in the one DC? Unaffected Services: Fedora Account System - https://admin.fedoraproject.org/accounts/ Fedora Community - https://admin.fedoraproject.org/community/ BFO - http://boot.fedoraproject.org/ Docs - http://docs.fedoraproject.org/ Fedora Hosted - https://fedorahosted.org/ Fedora People - http://fedorapeople.org/ Fedora Talk - http://talk.fedoraproject.org/ Main Website - http://fedoraproject.org/ Mirror List - https://mirrors.fedoraproject.org/ Mirror Manager - https://admin.fedoraproject.org/mirrormanager/ Package Database - https://admin.fedoraproject.org/pkgdb/ Smolt - http://smolts.org/ Spins - http://spins.fedoraproject.org/ Start - http://start.fedoraproject.org/ Torrent - http://torrent.fedoraproject.org/ Translation Services - http://translate.fedoraproject.org/ Wiki - http://fedoraproject.org/wiki/ Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/2255 Contact Information: Please join #fedora-admin in irc.freenode.net or respond to this email to track the status of this outage. Regards, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On 07/07/2010 11:29 PM, Tom spot Callaway wrote: [rrelyea] pcsc-lite: pcsc-lite-doc-1.6.1-4.fc14.noarch pcsc-lite-libs-1.6.1-4.fc14.x86_64 Fixed in rawhide. -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning a few packages
I would like to take over nodm, sponsor needed. https://bugzilla.redhat.com/show_bug.cgi?id=612671 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
merge reviews
Greetings Fedora developers... First some background for folks that were not around back in the day: There used to be a Fedora Core and a Fedora Extras. Fedora Core was maintained internally inside Red Hat by Red Hat employees. Fedora Extras was maintained by community folks much in the way Fedora is now. After Fedora Core 6 was released, Fedora Core and Fedora Extras were merged into Fedora. This was pretty much done by moving all the Fedora Core Packages into the external/community Extras infrastructure. During this merge, it was noted that the Fedora Extras packages had all passed a review of some kind and in general were more in line with packaging guidelines and such, while the Core packages had not had reviews and in many cases were created long before the current guidelines were in place or known. So, Merge review tickets were filed on all the formerly Core packages so they could get reviewed and checked for compliance with the current guidelines. There was an initial push to review this packages and try and get them all done, but several factors combined to make this not happen: lack of reviewers, lack of response from maintainers who feel review is cosmetic and low priority, etc. So, here we are today with 242 still open merge reviews: http://fedoraproject.org/PackageReviewStatus/MERGE.html (Plus a few that were closed when they shouldn't have been). So, what do we do? Some possible options: a) Just close them all, any bugs in spec files in those packages can be filed as bugs against them. b) Try and make some kind of concerted effort to get the last 242 done? We would need both people willing to review and maintainers willing to commit changes and get things completed. c) Just leave them open and let people pick pick pick away at them a few at a time? We might be done by Fedora20. Or perhaps not. d) Require new package submissions to the review queue to show that they reviewed a merge review before their package could be reviewed. e) Stop allowing non merge review packages into the collection until the merge reviews were all done. f) Make a concerted push to clear the NEEDSPONSOR blocker. Get all those folks sponsored and ask them all to do a few merge reviews. g) Your clever idea here Thoughts? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Thu, Jul 08, 2010 at 02:28:13PM -0600, Kevin Fenzi wrote: c) Just leave them open and let people pick pick pick away at them a few at a time? We might be done by Fedora20. Or perhaps not. f) Make a concerted push to clear the NEEDSPONSOR blocker. Get all those folks sponsored and ask them all to do a few merge reviews. I like these the most. A concerted push to clear NEEDSPONSOR would be good anyhow. Btw. in case someone is looking to sponsor someone but did not find someone who is ready, I would sponsor this one, if I currently had more time to re-familiarize myself with the packaging guidelines: https://bugzilla.redhat.com/show_bug.cgi?id=531544 b) Try and make some kind of concerted effort to get the last 242 done? We would need both people willing to review and maintainers willing to commit changes and get things completed. The problem with this one is that the maintainers are often not that much into reviews. Maybe we can do this and allow provenpackagers to commit the fixes and then have an action week to clear the NEEDSPONSOR blocker and the merge reviews and e.g. another week later an action day to allow provenpackagers to address all unhandled issues. Regards Till pgppPt7E2QuvN.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
Am Thu, 08 Jul 2010 22:51:57 +0200 schrieb Till Maas opensou...@till.name: On Thu, Jul 08, 2010 at 02:28:13PM -0600, Kevin Fenzi wrote: c) Just leave them open and let people pick pick pick away at them a few at a time? We might be done by Fedora20. Or perhaps not. f) Make a concerted push to clear the NEEDSPONSOR blocker. Get all those folks sponsored and ask them all to do a few merge reviews. I like these the most. A concerted push to clear NEEDSPONSOR would be good anyhow. Btw. in case someone is looking to sponsor someone but did not find someone who is ready, I would sponsor this one, if I currently had more time to re-familiarize myself with the packaging guidelines: https://bugzilla.redhat.com/show_bug.cgi?id=531544 b) Try and make some kind of concerted effort to get the last 242 done? We would need both people willing to review and maintainers willing to commit changes and get things completed. The problem with this one is that the maintainers are often not that much into reviews. Maybe we can do this and allow provenpackagers to commit the fixes and then have an action week to clear the NEEDSPONSOR blocker and the merge reviews and e.g. another week later an action day to allow provenpackagers to address all unhandled issues. Big +1. Count me in with helping to review and fix all unhandled issues... Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Thu, Jul 8, 2010 at 4:28 PM, Kevin Fenzi ke...@scrye.com wrote: So, here we are today with 242 still open merge reviews: http://fedoraproject.org/PackageReviewStatus/MERGE.html (Plus a few that were closed when they shouldn't have been). So, what do we do? Some possible options: a) Just close them all, any bugs in spec files in those packages can be filed as bugs against them. /RH employee hat off Fedora contributor hat on After a large survey, it is readily apparent that many of these 242 have been untouched for -years-, for packages that have been merged into Fedora and used happily for -years-. Further hundreds of other reviews outside your 242 are listed as assigned to a reviewer, but making no progress after multiple years. These merges are crowding out new packages that need merging, on bugzilla's list of packages that need a review. As such, getting any package into Fedora requires navigating an informal, ever-changing process, where the chief attributes for success involve (a) knowing a Red Hat employee or (b) public, sometimes repeated begging on fedora devel. The results are highly uneven, and not necessarily directly related to the technical attributes of benefit to the Fedora Project. Closing a 3-year-old merge review of the kernel package is reasonable bug triage. It's not like the kernel package will get un-merged. The proper course of action for already-merged packages is to file bugs against those packages. We have an entire -team- of people looking at kernel bugs, while this silly merge review: kernel sits, ignored, for several years. The current package review system is failing miserably at separating wheat from chaff, is very chaotic, and non-deterministic. Merge review: kernel is pure noise. Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
Hi, [pfj] xmms: 1:xmms-libs-1.2.11-11.20071117cvs.fc14.x86_64 Unless something very odd is going on here, xmms-libs does have the COPYING file included (just checked the spec file). Could it be that there is a problem with the build sys on x86_64 which is causing it to miss? TTFN Paul -- Biggles was quietly reading his favourite book when Algy burst through the door. Distracted for a moment, Biggles surveyed what had happened and turned a page. Algy old man he said, clearing his throat, use the handle next time... - Taken from Biggles combs his Hair signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
orphaning gg2
Hi all. I'm orphaning GNU Gadu (gg2). I no longer use it (pidgin replaces it quite well), upstream is dead and the project website domain has been taken over. If someone is interested, feel free to pick it up. Otherwise it should probably be dropped before F-14. There are some crasher bugs reported against it by abrt, but I can't reproduce them. Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Thu, 2010-07-08 at 14:28 -0600, Kevin Fenzi wrote: So, here we are today with 242 still open merge reviews: http://fedoraproject.org/PackageReviewStatus/MERGE.html (Plus a few that were closed when they shouldn't have been). So, what do we do? Some possible options: a) Just close them all, any bugs in spec files in those packages can be filed as bugs against them. b) Try and make some kind of concerted effort to get the last 242 done? We would need both people willing to review and maintainers willing to commit changes and get things completed. Just a few comments. First of all, option a) is IMHO out of the question. 242 reviews is not that much. Maybe people have not been aware so far that Merge Reviews exist and can be performed by anyone in the packagers group. This discussion should raise awareness about the fact. The work needed for the review depends, though, a lot on the nature of the package. The further down the pile we go, the more work there is per package: the spec files of say gcc, kernel or OpenOffice.org are rather daunting. I started doing merge reviews in late 2008, so far I've finished 24 of them and have 8 reviews currently still open. The biggest problem so far has been the lack of maintainer interest, often nothing has happened after my comments. For the major part a lot of BZ pings and mails to package-ow...@fedoraproject.org has done the trick, but some bugs have been awfully silent. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
Am Mittwoch, den 07.07.2010, 16:29 -0400 schrieb Tom spot Callaway: Okay. Here's the list of packages that I think might be affected by this. ... [cwickert] nimbus: nimbus-metacity-theme-0.1.4-2.fc13.noarch gtk-nimbus-engine-0.1.4-2.fc13.x86_64 nimbus-icon-theme-0.1.4-2.fc13.noarch $ rpm -ql gtk-nimbus-engine | grep COPYING/usr/share/doc/gtk-nimbus-engine-0.1.4/COPYING $ rpm -ql nimbus-icon-theme | grep COPYING/usr/share/doc/nimbus-icon-theme-0.1.4/COPYING Regars, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
Jeff Garzik (jgar...@pobox.com) said: After a large survey, it is readily apparent that many of these 242 have been untouched for -years-, for packages that have been merged into Fedora and used happily for -years-. Further hundreds of other reviews outside your 242 are listed as assigned to a reviewer, but making no progress after multiple years. These merges are crowding out new packages that need merging, on bugzilla's list of packages that need a review. That logically does not follow. If they're not being touched, and not making progress, then there's obviously no review resources being spent on them, which means they're not taking anything away from the review resources for other new packages. (We're still having a good number of new packages approved each week.) As such, getting any package into Fedora requires navigating an informal, ever-changing process, where the chief attributes for success involve (a) knowing a Red Hat employee or (b) public, sometimes repeated begging on fedora devel. ... how is it ever-changing? The review and sponsorship process has been relatively static for a long time. Yes, sometimes you have to request reviewers, or swap reviews, but that's been the case for quite a while. The proper course of action for already-merged packages is to file bugs against those packages. We have an entire -team- of people looking at kernel bugs, while this silly merge review: kernel sits, ignored, for several years. Except you'll need to have some sort of tracking of packages which haven't yet been processed looking for these bugs, so people know what packages to look at first. Which then ends up looking an awful lot like the current merge review list. The current package review system is failing miserably at separating wheat from chaff, is very chaotic, and non-deterministic. Merge review: kernel is pure noise. I'd like not to assume the worst, but given your mass closing of some review bugs, plus your arguments here about why, plus your request for a review swap earlier, I'm having trouble reading this as anything other than a transparent frustration at your package not getting reviewed fast enough for your liking, with an unsaid assertion that it's part of the 'wheat' above. Right now, we have a dearth of review resources. This leads to both merge reviews having no activity, and new package reviews sometimes having no activity. However, if a new package is important enough, someone's going to have enough self-interest to pick up the review, or enough self-interest as maintainer to swap reviews for someone else in the same boat. Frankly, that's the sort of intrinsic motivation common to open source... assuming differently, that there would or should be some sort of nebulous 'review community' sitting there waiting to take on a bunch of new submissions from the mountain seems awfully unrealistic. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Thu, Jul 8, 2010 at 6:26 PM, Bill Nottingham nott...@redhat.com wrote: I'd like not to assume the worst, but given your mass closing of some review bugs, plus your arguments here about why, plus your request for a review swap earlier, I'm having trouble reading this as anything other than a transparent frustration at your package not getting reviewed fast enough for your liking, with an unsaid assertion that it's part of the 'wheat' above. Cute re-ordering of events, there. No, after repeated experiences with seeking reviews, including this most recent one mentioned elsewhere on this list, and seeing others on this list repeating review requests, I was inspired to poke around to see why responses were so uneven. Looking at the process with fresh eyes, starting from https://fedoraproject.org/wiki/PackageReviewProcess and moving to https://fedoraproject.org/wiki/PackageMaintainers/ReviewRequests one sees a chaotic mess of package reviews, both assigned and unassigned, not really moving forward at all. Looking closely, you see a lot of packages that seem of worth, but that set is crowded by review requests for ancient packages like redhat-menus or kernel. In an ideal world, every package in fedora/devel would get a full package re-review prior to each release. But with finite resources limiting that, it seemed to me that triaging long-dead bugs for long-merged packages was a reasonable and helpful thing for the Fedora project. By all appearances, nobody else was bothering with these things after several years went by. If people want these obviously unloved, ignored review requests -- not even an rpmlint or ping in many cases -- to stick around, that's fine with me. I thought I was being helpful, but easy enough to leave things alone as well. My hail review was proceeding, and I wanted to make the process a bit easier for the -next- person wanting a review. Apologies for the ruffled feathers. The process itself is intimidating, because the wikis demand that a prospective reviewer wade into a completely unorganized swamp (BZ URLs linked-to from above URLs), hundreds of review requests, with next to zero information about where one's review would be most helpful. To an outsider, it must seem like quite a mess, with completely unknown chances for success/failure. Jeff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Python 2.7 status: mass rebuild of python packages requested
Here's where we are on Python 2.7 for Fedora 14: [1] I've updated my python src.rpm to 2.7 final (rather than the 2.7rc2 I had previously): http://dmalcolm.fedorapeople.org/python-packaging/python-2.7-3.fc14.src.rpm You can see/download a successful scratch build of this here: http://koji.fedoraproject.org/koji/taskinfo?taskID=2305942 If you want to test this, that would be great, but you need a sacrificial rawhide machine, as e.g. yum isn't going to work afterwards! (perhaps as a virtual machine) I've smoketested this on an x86_64 rawhide box, and fixed the most obvious bugs, and I've successfully used this to rebuild noarch and arch packages (python-setuptools and python-coverage), and all seems well so far in light testing. There are a few extra failures of the selftest suite [2], hopefully we can shake those out over time. So hopefully this is ready to build. I'm looking to do a mass rebuild of all src.rpms that have a requires of Requires: python(abi) = 2.6 in a built subpackage as per: https://fedoraproject.org/wiki/Mass_Rebuild_SOP I've started writing a wiki page about the rebuild: https://fedoraproject.org/wiki/Features/Python_2.7/MassRebuild, (based on http://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild ) - though it's barely started so far (it's getting late here and I thought I'd post status). I've got a few other features in-flight for F14, trying to make the Feature Submission deadline for the 13th, so the rebuild isn't imminent, but hopefully in a week or so. Hope this is helpful Dave [1] https://fedoraproject.org/wiki/Features/Python_2.7 [2] mostly seem to be false positives relating to multilib fixes, along with import crypt failing with ImportError: /usr/lib64/python2.7/lib-dynload/cryptmodule.so: undefined symbol: crypt; not sure about this one -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
On Thu, 2010-07-08 at 11:31 -0400, Brandon Lozza wrote:
A mass rebuild would be recommended as the new compiler will produce
faster code. I believe everything will benefit and it's worth looking
into. For example I noticed a significant difference on the OpenSUSE
distro when GCC was upgraded and they repackaged their software with
it in their development version 11.3. Anecdotal for sure but
everything seemed faster than the build before that change. Phoronix
Adam's Law Of Software Advances:
People On The Internet always believe that any particular incremental
change produces something faster than before ('Firefox 3.5.6 feels much
snappier than Firefox 3.5.5!'), but that everything is always slower
than it was in previous major versions / years ('Man, Firefox 3 is so
much slower than Firefox 1!')
(Appendix 1: the word 'snappier' is always used in this context.)
--
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: gcc-4.5-RH in F14
On 7/8/10, Adam Williamson awill...@redhat.com wrote:
On Thu, 2010-07-08 at 11:31 -0400, Brandon Lozza wrote:
A mass rebuild would be recommended as the new compiler will produce
faster code. I believe everything will benefit and it's worth looking
into. For example I noticed a significant difference on the OpenSUSE
distro when GCC was upgraded and they repackaged their software with
it in their development version 11.3. Anecdotal for sure but
everything seemed faster than the build before that change. Phoronix
Adam's Law Of Software Advances:
People On The Internet always believe that any particular incremental
change produces something faster than before ('Firefox 3.5.6 feels much
snappier than Firefox 3.5.5!'), but that everything is always slower
than it was in previous major versions / years ('Man, Firefox 3 is so
much slower than Firefox 1!')
(Appendix 1: the word 'snappier' is always used in this context.)
--
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
gcc 4.5 with LTO is faster though, thats what is making opensuse faster
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Thu, 2010-07-08 at 14:28 -0600, Kevin Fenzi wrote: Greetings Fedora developers... c) Just leave them open and let people pick pick pick away at them a few at a time? We might be done by Fedora20. Or perhaps not. Does the existence of a bunch of open merge reviews cause any actual harm or trouble to anyone besides people who like to compile lists of open bugs and then stare at them glumly? =) If not, then option c) seems perfectly fine to me. -- 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: Python 2.7 status: mass rebuild of python packages requested
On Thu, Jul 8, 2010 at 4:02 PM, David Malcolm dmalc...@redhat.com wrote: Hope this is helpful Dave Is there any hints on expected gotchas that we can look out for. Deprecations or API changes of significant merit? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Thu, 08 Jul 2010 20:29:42 -0400 Jeff Garzik jgar...@pobox.com wrote: On 07/08/2010 08:23 PM, Adam Williamson wrote: On Thu, 2010-07-08 at 14:28 -0600, Kevin Fenzi wrote: Greetings Fedora developers... c) Just leave them open and let people pick pick pick away at them a few at a time? We might be done by Fedora20. Or perhaps not. Does the existence of a bunch of open merge reviews cause any actual harm or trouble to anyone besides people who like to compile lists of open bugs and then stare at them glumly? =) If not, then option c) seems perfectly fine to me. If you're looking for a package to review (perhaps for a review swap :)), Fedora actively directs you to exact those sorts of long lists of open bugs: https://fedoraproject.org/wiki/PackageMaintainers/ReviewRequests Wow. What links to that? You should really be using: http://fedoraproject.org/PackageReviewStatus/ Where they are seperated out and in nice cached lists. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/08/2010 09:05 AM, Chen Lei wrote: It seems MeeGo builds core packages by using PGO already. Is there anyone who would like to volunteer to write a packaging guideline about using PGO? That's not so easy to generalize. As Jakub wrote, you need some form of workload. After the binaries are built this workload has to be executed. How to do that cannot really be summarized. Some packages might need to be installed to function. Others need permissions etc. Some might need interaction. For console programs you can do that using expect but for GUI programs... After the workload is run you need to rebuild everything again while pointing to the files created by running the workload. The first stage binaries automatically create those files. Perhaps the best that can done is providing an example but I guess every package needs to have its own way implemented. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkw2cpoACgkQ2ijCOnn/RHTFwACeO2pJfk1RHpVpUG6R+78Z+aFh sFoAnjEvsAJM2o+8pKX+kPmVtovI6Apg =cDPF -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
On Thu, 2010-07-08 at 17:51 -0700, Ulrich Drepper wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/08/2010 09:05 AM, Chen Lei wrote: It seems MeeGo builds core packages by using PGO already. Is there anyone who would like to volunteer to write a packaging guideline about using PGO? That's not so easy to generalize. As Jakub wrote, you need some form of workload. After the binaries are built this workload has to be executed. How to do that cannot really be summarized. Some packages might need to be installed to function. Others need permissions etc. Some might need interaction. For console programs you can do that using expect but for GUI programs... After the workload is run you need to rebuild everything again while pointing to the files created by running the workload. The first stage binaries automatically create those files. Perhaps the best that can done is providing an example but I guess every package needs to have its own way implemented. Is there a way to include pre-packaged workloads analysis? I realise we'd have to regenerate these somehow possible for each compiler update (not sure how the files look). This would allow us for some thing like firefox or openoffice to run some stuff offline on a packagers desktop and then use those files in a koji run later. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: merge reviews
On Thu, 2010-07-08 at 18:36 -0600, Kevin Fenzi wrote: On Thu, 08 Jul 2010 20:29:42 -0400 Jeff Garzik jgar...@pobox.com wrote: On 07/08/2010 08:23 PM, Adam Williamson wrote: On Thu, 2010-07-08 at 14:28 -0600, Kevin Fenzi wrote: Greetings Fedora developers... c) Just leave them open and let people pick pick pick away at them a few at a time? We might be done by Fedora20. Or perhaps not. Does the existence of a bunch of open merge reviews cause any actual harm or trouble to anyone besides people who like to compile lists of open bugs and then stare at them glumly? =) If not, then option c) seems perfectly fine to me. If you're looking for a package to review (perhaps for a review swap :)), Fedora actively directs you to exact those sorts of long lists of open bugs: https://fedoraproject.org/wiki/PackageMaintainers/ReviewRequests Wow. What links to that? Thank the magic of mediawiki! https://fedoraproject.org/wiki/Special:WhatLinksHere/PackageMaintainers/ReviewRequests seems several important pages do. So perhaps they should be updated to use the link below.. You should really be using: http://fedoraproject.org/PackageReviewStatus/ Where they are seperated out and in nice cached lists. kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- 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: gcc-4.5-RH in F14
On Thu, 2010-07-08 at 09:18 +0200, Jakub Jelinek wrote: Hi! F14 now has gcc-4.5-RH compiler instead of 4.4-RH. For the changes (especially user visible ones), see http://gcc.gnu.org/gcc-4.5/changes.html (though the list contains even many features that have been backported to 4.4-RH. I had to backport even over 100 of changes that were backported to 4.4-RH from trunk already, but aren't on 4.5 branch). Unless using decimal float, the compiler should be ABI compatible with 4.4-RH, including the libraries (which ought to be backwards compatible). If you experience any internal compiler errors or other compiler bugs, please file them into bugzilla. Please don't rely on LTO in 4.5, it is not mature enough (especially -fwhopr is completely unusable, -flto only barely so), things will get better in GCC 4.6. This has a multilib problem. libstdc++ has a few of the same files in both the x86-64 and i686 packages, making it impossible to have both installed (which should be possible, and is in F13). The files are a few Python bits in /usr/share/gcc-4.5.0/python/libstdcxx/v6/ . -- 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: merge reviews
On Thu, 08 Jul 2010 17:59:44 -0700 Adam Williamson awill...@redhat.com wrote: Thank the magic of mediawiki! https://fedoraproject.org/wiki/Special:WhatLinksHere/PackageMaintainers/ReviewRequests seems several important pages do. So perhaps they should be updated to use the link below.. 2 of them are done. I'm not sure on the ru one. Feel free to adjust further. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
Is there a way to include pre-packaged workloads analysis? I realise we'd have to regenerate these somehow possible for each compiler update (not sure how the files look). What a workload means to the compiler is all the results of all the conditional branches in the compiled code. What sites there are to have data points and what the association between those and any high-level notion of workload (i.e. all forms of input to the program) changes not only with compiler differences, but with every source code change. It's pretty hard to imagine what you could preserve across builds of nontrivially nonidentical source trees that would continue to line up at the basic block level where it's meaningful to the compiler. Perhaps you could do something reduced to terms of source line locations, or number of basic blocks into a named function, or something. But it sounds very iffy. This would allow us for some thing like firefox or openoffice to run some stuff offline on a packagers desktop and then use those files in a koji run later. Those are both examples of big multi-component things that probably have their own build infrastructure for exercising components in various ways. Internal ways to drive those with representative synthetic workloads are probably the wisest thing in the long run. Those are also both examples of GUI things. For those things, a representative workload could be recorded as something like a dogtail test suite (I don't really know anything about such tools, but they exist). That could perhaps be substantially automated by some magic in mock/koji to do a full rpmbuild, then a test suite run and mine out its .gcda files, and then a final rpmbuild with those results poked into its gcc runs. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
This has a multilib problem. libstdc++ has a few of the same files in both the x86-64 and i686 packages, making it impossible to have both installed (which should be possible, and is in F13). The files are a few Python bits in /usr/share/gcc-4.5.0/python/libstdcxx/v6/ . Would it work if they were in libstdc++-devel instead? In F13 that seems to be ok for /usr/include/c++/4.4.4/ files. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
On Thu, 2010-07-08 at 18:21 -0700, Roland McGrath wrote: This has a multilib problem. libstdc++ has a few of the same files in both the x86-64 and i686 packages, making it impossible to have both installed (which should be possible, and is in F13). The files are a few Python bits in /usr/share/gcc-4.5.0/python/libstdcxx/v6/ . Would it work if they were in libstdc++-devel instead? In F13 that seems to be ok for /usr/include/c++/4.4.4/ files. I dunno, I'm not a multilib expert, just an asshole telling you to make it work =) I think it probably doesn't 'work', in the sense that you can't install the f13 -devel i686 and x86-64 packages together, but in another sense that's fine, as I don't think our multilib policy says you _will_ be able to install -devel packages together and it's not a huge tragedy if you can't. So that would certainly be an improvement. Just being able to install the main lib package is the most important thing. -- 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: gcc-4.5-RH in F14
I dunno, I'm not a multilib expert, just an asshole telling you to make it work =) I'm no expert on the rpm part of the world either, but I have seen many things and I'll yell some out from the corner now and then. I think it probably doesn't 'work', in the sense that you can't install the f13 -devel i686 and x86-64 packages together, but in another sense that's fine, as I don't think our multilib policy says you _will_ be able to install -devel packages together and it's not a huge tragedy if you can't. So that would certainly be an improvement. Just being able to install the main lib package is the most important thing. The -devel package seems like the right place for them anyway. You don't really want anything extra in lib* packages that just satisfy DSO dependencies (even though these python files happen to be tiny). In F13 they live in gdb instead. If you were using gdb then you probably wanted to see the source code in the header files and thus had -devel installed anyway. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
On Thu, 2010-07-08 at 09:18 +0200, Jakub Jelinek wrote: Hi! F14 now has gcc-4.5-RH compiler instead of 4.4-RH. For the changes (especially user visible ones), see http://gcc.gnu.org/gcc-4.5/changes.html (though the list contains even many features that have been backported to 4.4-RH. I had to backport even over 100 of changes that were backported to 4.4-RH from trunk already, but aren't on 4.5 branch). Unless using decimal float, the compiler should be ABI compatible with 4.4-RH, including the libraries (which ought to be backwards compatible). If you experience any internal compiler errors or other compiler bugs, please file them into bugzilla. Please don't rely on LTO in 4.5, it is not mature enough (especially -fwhopr is completely unusable, -flto only barely so), things will get better in GCC 4.6. Just saw this on lkml? are kernel builds going to be broken? On Thu, Jul 8, 2010 at 4:33 PM, Rafael J. Wysocki r...@sisk.pl wrote: Unresolved regressions -- Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16353 Subject : 2.6.35 regression Submitter : Zeev Tarantov zeev.taran...@gmail.com Date: 2010-07-05 13:04 (4 days old) Message-ID : loom.20100705t144459-...@post.gmane.org References : http://marc.info/?l=linux-kernelm=127836002702522w=2 This is a gcc-4.5 issue. Whether it's also something that we should change in the kernel is unclear, but at least as of now, the rule is that you cannot compile the kernel with gcc-4.5. No idea whether the compiler is just entirely broken, or whether it's just that it triggers something iffy by being overly clever. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
On Thu, 2010-07-08 at 18:17 -0700, Roland McGrath wrote: Is there a way to include pre-packaged workloads analysis? I realise we'd have to regenerate these somehow possible for each compiler update (not sure how the files look). What a workload means to the compiler is all the results of all the conditional branches in the compiled code. What sites there are to have data points and what the association between those and any high-level notion of workload (i.e. all forms of input to the program) changes not only with compiler differences, but with every source code change. It's pretty hard to imagine what you could preserve across builds of nontrivially nonidentical source trees that would continue to line up at the basic block level where it's meaningful to the compiler. Perhaps you could do something reduced to terms of source line locations, or number of basic blocks into a named function, or something. But it sounds very iffy. I don't mean to preserve it across different builds, just across one build, so we do GUI stuff offline without having our koji/brew system need X installed and the ensuing issues we'll get with executing processes on it, not to mention koji/brew runs on an EL5 kernel, which may for things like glibc generate different codepaths than a Fedora kernel. So I'd package up stuff, do a koji build, download it, run my representative test suite, upload the result and do another build. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
So I'd package up stuff, do a koji build, download it, run my representative test suite, upload the result and do another build. Oh. Well, sure then. What was the question? You don't want much of it automated at all then, but you're asking about the little? The profiled build will litter your world with .gcda files, and we'll have to select some useful convention for -fprofile-dir= in builds and then setting GCOV_PREFIX/GCOV_PREFIX_STRIP environment variables when you do your run so you know where it will put them. I can see doing some rpm macro magic to tweak RPM_OPT_FLAGS for the build and implicitly generate a subpackage of the .gcno files. Those are the compile-time half of what you need to feed back into the final build. Then you'd need to get that subpackage (or its contents, the .gcno files) along with your collected .gcda files into something that could be a SourceN: for the final build. I'm really not sure how to tie that into the whole rpmbuild/mock/koji world. To preserve the actual bit for bit reproducibility of builds that makes koji great, that tarball (or whatever it is, all the .gcno and .gcda files) needs to be saved forever along with the build. We can do it with automation over the current process, where it goes into the lookaside cache and its signature committed in the sources file and all that. Or it could be some sort of special koji magic where the koji rpmbuilds just slurp from some koji database via some permanent identifier URL or whatnot, e.g. a URL set in an rpm macro that koji sets on an rpmbuild for koji build --profileball=foo.tar.xz ... after storing it there for posterity. Thanks, Roland -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
On Thu, Jul 08, 2010 at 06:32:37PM -0700, Adam Williamson wrote: I think it probably doesn't 'work', in the sense that you can't install the f13 -devel i686 and x86-64 packages together, but in another sense that's fine, as I don't think our multilib policy says you _will_ be able to install -devel packages together and it's not a huge tragedy if you can't. So that would certainly be an improvement. Just being able to install the main lib package is the most important thing. I remember a big push to make multilib -devel work many many Fedora releases ago. Possibly pre-Core Extras merge. If those files are exactly the same in both the x86 and x86_64 package they should be okay under multilib. If they aren't exactly the same they should go in a path that either has the arch in the pathname or the bitedness (lib64 vs lib) -Toshio pgpC26IdIYIBv.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc-4.5-RH in F14
On Thu, 2010-07-08 at 22:36 -0400, Toshio Kuratomi wrote: On Thu, Jul 08, 2010 at 06:32:37PM -0700, Adam Williamson wrote: I think it probably doesn't 'work', in the sense that you can't install the f13 -devel i686 and x86-64 packages together, but in another sense that's fine, as I don't think our multilib policy says you _will_ be able to install -devel packages together and it's not a huge tragedy if you can't. So that would certainly be an improvement. Just being able to install the main lib package is the most important thing. I remember a big push to make multilib -devel work many many Fedora releases ago. Possibly pre-Core Extras merge. If those files are exactly the same in both the x86 and x86_64 package they should be okay under multilib. If they aren't exactly the same they should go in a path that either has the arch in the pathname or the bitedness (lib64 vs lib) that's interesting. I'm not being theoretical here, the problem actually stops me updating this system from f13 to rawhide. So obviously there is some difference in the files, but I wouldn't usually expect that for bits of python. Particularly an init.py file - they usually contain almost nothing... -- 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: gcc-4.5-RH in F14
On Thu, 2010-07-08 at 22:36 -0400, Toshio Kuratomi wrote: On Thu, Jul 08, 2010 at 06:32:37PM -0700, Adam Williamson wrote: I think it probably doesn't 'work', in the sense that you can't install the f13 -devel i686 and x86-64 packages together, but in another sense that's fine, as I don't think our multilib policy says you _will_ be able to install -devel packages together and it's not a huge tragedy if you can't. So that would certainly be an improvement. Just being able to install the main lib package is the most important thing. I remember a big push to make multilib -devel work many many Fedora releases ago. Possibly pre-Core Extras merge. If those files are exactly the same in both the x86 and x86_64 package they should be okay under multilib. If they aren't exactly the same they should go in a path that either has the arch in the pathname or the bitedness (lib64 vs lib) This is accurate. the files must be identical if they are not elf binaries. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Python 2.7 status: mass rebuild of python packages requested
On Thu, 2010-07-08 at 20:02 -0400, David Malcolm wrote: Here's where we are on Python 2.7 for Fedora 14: [1] I've updated my python src.rpm to 2.7 final (rather than the 2.7rc2 I had previously): http://dmalcolm.fedorapeople.org/python-packaging/python-2.7-3.fc14.src.rpm You can see/download a successful scratch build of this here: http://koji.fedoraproject.org/koji/taskinfo?taskID=2305942 If you want to test this, that would be great, but you need a sacrificial rawhide machine, as e.g. yum isn't going to work afterwards! (perhaps as a virtual machine) 1. Great work! 2. When you say yum isn't going towork - you mean b/c none of its modules will be available or do you mean there is something in yum that's not working for 2.7? thanks, -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 502358] Review Request: mojomojo - Catalyst DBIx::Class powered Wiki
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=502358 Iain Arnell iarn...@gmail.com changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|cw...@alumni.drew.edu |nob...@fedoraproject.org --- Comment #14 from Iain Arnell iarn...@gmail.com 2010-07-08 23:37:29 EDT --- I'm throwing this back into the pool since Chris hasn't responded in a long while. New upstream release too. SRPM: http://iarnell.fedorapeople.org/review/mojomojo-1.01-1.fc14.src.rpm SPEC: http://iarnell.fedorapeople.org/review/mojomojo.spec KOJI: https://koji.fedoraproject.org/koji/taskinfo?taskID=2307741 The nasty looking error message generated by t/03podcoverage.t during %check can be safely ignored. -- 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
