Re: Linux and application installing - a second perspective
On 09/23/2010 06:09 PM, Bruno Wolff III wrote: On Thu, Sep 23, 2010 at 15:51:37 +0200, FlorianFestiffe...@redhat.com wrote: 1) Comps groups. Not even used by PK to the full extend. Nevertheless several groups are huge with over 100 packages (winner being Games with over 300). Sorry, 100 packages in one list view doesn't work for me. Games have meta data that allows them to be further subdivided in their desktop files. This should up in the part of you app that takes that data into account. If you read on you'll see that I actually use exactly this data. When showing the packages in the Application menu tree the games are already subdivided. Try it out and see yourself! Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
libnotify issue on F14 and rawhide
I have packaged xneur, which on review [1] and its build fine on Fedora
12 and 13. On Fedora 14 it is failed [2] with error:
/usr/include/libnotify/notification.h:28:21: fatal error: gtk/gtk.h: No such
file or directory
I try figure out what happened and go step by step add includes in
CFLAGS like:
make %{?_smp_mflags} CFLAGS=%{optflags} -I%{_includedir}/gtk-2.0
after many attempts and googling I finally arrived to:
make %{?_smp_mflags} CFLAGS=%{optflags} %( pkg-config --cflags --libs
gtk+-2.0 )
which work like a charm.
But I can't understand why I should provide it manually and why it does
not required in previous releases?
I slightly dig more and found it happened on linking with libnotify
library. And finaly result:
On Fedora 13:
$ pkg-config --cflags libnotify = 0.4.0
-pthread -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/dbus-1.0
-I/usr/lib/dbus-1.0/include -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12
On Fedora 14 (f14-test.scrye.com):
$ pkg-config --cflags libnotify = 0.4.0
-pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include
Should I fill bug on libnotify or it is the expected behavior?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=623604
[2]
http://koji.fedoraproject.org/koji/getfile?taskID=2482272name=build.log
http://koji.fedoraproject.org/koji/getfile?taskID=2482272name=build.log
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libnotify issue on F14 and rawhide
Pavel Alexeev (aka Pahan-Hubbitus) wrote, at 09/24/2010 06:11 PM +9:00:
I have packaged xneur, which on review [1] and its build fine on Fedora 12
and 13. On Fedora 14 it is failed [2] with error:
/usr/include/libnotify/notification.h:28:21: fatal error: gtk/gtk.h: No such
file or directory
I try figure out what happened and go step by step add includes in CFLAGS
like:
make %{?_smp_mflags} CFLAGS=%{optflags} -I%{_includedir}/gtk-2.0
after many attempts and googling I finally arrived to:
make %{?_smp_mflags} CFLAGS=%{optflags} %( pkg-config --cflags --libs
gtk+-2.0 )
which work like a charm.
But I can't understand why I should provide it manually
and why it does not required in previous releases?
I slightly dig more and found it happened on linking with libnotify library.
And finaly result:
On Fedora 13:
$ pkg-config --cflags libnotify = 0.4.0
-pthread -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/dbus-1.0
-I/usr/lib/dbus-1.0/include -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/libpng12
On Fedora 14 (f14-test.scrye.com):
$ pkg-config --cflags libnotify = 0.4.0
-pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include
Should I fill bug on libnotify or it is the expected behavior?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=623604
[2] http://koji.fedoraproject.org/koji/getfile?taskID=2482272name=build.log
http://koji.fedoraproject.org/koji/getfile?taskID=2482272name=build.log
This change on libnotify is intentional.
http://git.gnome.org/browse/libnotify/commit/?id=0eb56b2fcf16d5381011e0bae2cf942416dae55c
https://bugzilla.gnome.org/show_bug.cgi?id=622550
Regards,
Mamoru
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libnotify issue on F14 and rawhide
24.09.2010 13:27, Mamoru Tasaka пишет:
Pavel Alexeev (aka Pahan-Hubbitus) wrote, at 09/24/2010 06:11 PM +9:00:
I have packaged xneur, which on review [1] and its build fine on Fedora 12
and 13. On Fedora 14 it is failed [2] with error:
/usr/include/libnotify/notification.h:28:21: fatal error: gtk/gtk.h: No such
file or directory
I try figure out what happened and go step by step add includes in CFLAGS
like:
make %{?_smp_mflags} CFLAGS=%{optflags} -I%{_includedir}/gtk-2.0
after many attempts and googling I finally arrived to:
make %{?_smp_mflags} CFLAGS=%{optflags} %( pkg-config --cflags --libs
gtk+-2.0 )
which work like a charm.
But I can't understand why I should provide it manually
and why it does not required in previous releases?
I slightly dig more and found it happened on linking with libnotify library.
And finaly result:
On Fedora 13:
$ pkg-config --cflags libnotify = 0.4.0
-pthread -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/dbus-1.0
-I/usr/lib/dbus-1.0/include -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12
On Fedora 14 (f14-test.scrye.com):
$ pkg-config --cflags libnotify = 0.4.0
-pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include
Should I fill bug on libnotify or it is the expected behavior?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=623604
[2] http://koji.fedoraproject.org/koji/getfile?taskID=2482272name=build.log
http://koji.fedoraproject.org/koji/getfile?taskID=2482272name=build.log
This change on libnotify is intentional.
http://git.gnome.org/browse/libnotify/commit/?id=0eb56b2fcf16d5381011e0bae2cf942416dae55c
https://bugzilla.gnome.org/show_bug.cgi?id=622550
How I should deal with it?
Is it normal add such parameters in make or in configure (%configure
LIBNOTIFY_CFLAGS=%( pkg-config --cflags libnotify = 0.4.0 gtk+-2.0
) LIBNOTIFY_LIBS=%( pkg-config --libs libnotify = 0.4.0 gtk+-2.0 ))?
And what is also very strange and interesting. When build failed with
fatal error: gtk/gtk.h: No such file or directory if I go in builddir
and manually invoke last command:
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../lib/config -I../../lib/misc
-I../../lib/lib -Wall -Wextra -Werror -g0 -std=gnu99 -fPIC -pthread
-I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I/usr/include/libxml2 -I/usr/include
-pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -c sound.c -fPIC -DPIC -o
.libs/libxnnotify_la-sound.o
compilation fine done without any problem. How it find all includes? And
why it is not happened in rpmbuild process?
Regards,
Mamoru
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PostgreSQL 9 for F14?
Michał Piotrowski, Mon, 20 Sep 2010 17:32:49 +0200: PostgreSQL 9 was released http://www.postgresql.org/about/news.1235 Are there any chances to get this for F14? The new version supports basic replication scenarios, so I would not have to use PgPool :) I think this is an ideal project for http://repos.fedorapeople.org/ Best, Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC A GOOD name is rather to be chosen than great riches. -- Proverbs 22:1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: pushing updates for FTBFS
Hi, On 09/22/2010 07:37 PM, Toshio Kuratomi wrote: On Tue, Sep 21, 2010 at 03:25:25PM -0600, Kevin Fenzi wrote: On Tue, 21 Sep 2010 10:06:09 -0700 Eric Smithe...@brouhaha.com wrote: A bug was filed against meshlab because of an FTBFS for Fedora 14. I added a patch to resolve it and submitted an update. After seven days with no feedback, I was able to push it to stable. Were there reports of the existing build causing problems? Personally, I would check such changes in, but only push out an update in f14 if there were other changes that made it worthwhile, or the existing build caused issues. Rawhide of course you should build for for these issues. For an FTBFS for a new Fedora release, does it really make sense to have the seven day delay? I don't see what the downside would be of allowing it to be pushed to stable immediately. Even if there's something wrong with the update, it isn't going to replace a working package. I don't see the point of pushing it as an update at all, unless it's fixing some bad behavior in the existing build or there are other reasons (upstream update, etc). For (unreleased) F14, I think that the arugment that future work on the package is better off starting with something that works than to start off with something that's broken by new gcc, boost, etc is very valid. If I get a time-sensitive security bug about foo in Fedora 14, I want to have as few extraneous issues as possible so I can hunt down and fix the bug quickly. Right, and on top of that, fixing ftbfs woth an update (for unreleased versions only) also makes live a lot easier for secondary archs if it does not build on i386 chances are almost 100% it won't build no ppc / arm / alpha / sparc / s390 / whatever either. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100924 changes
Compose started at Fri Sep 24 08:15:29 UTC 2010 Broken deps for x86_64 -- almanah-0.7.3-3.fc14.x86_64 requires libedataserverui-1.2.so.10()(64bit) antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 claws-mail-plugins-geolocation-3.7.6-5.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) 0:1.3.0 clutter-gst-devel-1.2.0-1.fc15.x86_64 requires pkgconfig(clutter-1.0) 0:1.3.0 clutter-gtkmm-0.9.5-1.fc14.i686 requires libclutter-gtk-0.10.so.0 clutter-gtkmm-0.9.5-1.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) clutter-gtkmm-devel-0.9.5-1.fc14.i686 requires pkgconfig(clutter-gtk-0.10) = 0:0.10.2 clutter-gtkmm-devel-0.9.5-1.fc14.x86_64 requires pkgconfig(clutter-gtk-0.10) = 0:0.10.2 emerillon-0.1.2-7.fc14.x86_64 requires librest-0.6.so.0()(64bit) emerillon-0.1.2-7.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libedata-book-1.2.so.2()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-1.2.so.17()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-provider-1.2.so.17()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgtkjava-2.8.so frysk-devel-0.4-26.fc14.i386 requires libglibjava-0.2.so frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.x86_64 requires libglibjava-0.2.so()(64bit) frysk-devel-0.4-26.fc14.x86_64 requires libgtkjava-2.8.so()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libglibjava-0.2.so()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgtkjava-2.8.so()(64bit) 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-python2-brasero-2.31.1-5.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-brasero-2.31.1-5.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-totem-2.31.1-5.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples libchamplain-gtk-0.6.1-4.fc14.i686 requires libclutter-gtk-0.10.so.0 libchamplain-gtk-0.6.1-4.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) libchamplain-gtk-devel-0.6.1-4.fc14.i686 requires pkgconfig(clutter-gtk-0.10) libchamplain-gtk-devel-0.6.1-4.fc14.x86_64 requires pkgconfig(clutter-gtk-0.10) 1:libopensync-plugin-evolution2-0.22-6.fc14.x86_64 requires libedata-book-1.2.so.3()(64bit) 1:libopensync-plugin-evolution2-0.22-6.fc14.x86_64 requires libedata-cal-1.2.so.8()(64bit) mail-notification-evolution-plugin-5.4-22.fc14.x86_64 requires libcamel-1.2.so.18()(64bit) mail-notification-evolution-plugin-5.4-22.fc14.x86_64 requires libcamel-provider-1.2.so.18()(64bit) meego-panel-devices-0.2.4-2.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) meego-panel-zones-0.2.0-0.1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires mingw32(libpng-3.dll) moblin-app-installer-0.4.0-0.9.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) moblin-panel-status-0.1.21-5.fc14.x86_64 requires libsocialweb-client.so.1()(64bit) moblin-panel-status-0.1.21-5.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc perl-Gtk2-MozEmbed-0.08-7.fc15.x86_64 requires gecko-libs = 0:1.9.3.0 pyclutter-gtk-0.10.0-2.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) rubygem-ruby-debug-doc-0.10.4-0.2.rc1.fc14.noarch requires /ursr/bin/env spacewalk-certs-tools-1.1.1-2.1.fc15.noarch requires spacewalk-backend-libs = 0:0.8.28 totem-2.90.5-5.fc15.i686 requires libpeasui-1.0.so.0 totem-2.90.5-5.fc15.x86_64 requires libpeasui-1.0.so.0()(64bit) tracker-evolution-plugin-0.8.17-1.fc15.x86_64 requires
libedataserverui soname bump in Fedora 14
Hi all, I'm so sorry for a late notice, but there was a soname bump of libedataserverui library from evolution-data-server package in time for 2.31.91 update, but I didn't notice this change, and because this update didn't get it to the testing repo, then I realized just now, when I finished an update to 2.31.92 and pushed it to updates-testing. Affected packages seems to be these: almanah anjal gnome-panel It should be enough to just rebuild these against evolution-data-server-2.31.92, which is still marked for a build system. The update request url is here: https://admin.fedoraproject.org/updates/evolution-mapi-0.31.92-1.fc14,evolution-exchange-2.31.92-1.fc14,openchange-0.9-8.fc14,evolution-2.31.92-1.fc14,evolution-data-server-2.31.92-1.fc14,gtkhtml3-3.31.92-1.fc14 Bye, Milan ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-14 Branched report: 20100923 changes
On Thu, Sep 23, 2010 at 07:01:16PM +0100, Peter Robinson wrote: Is it really necessary to include entire package change logs in the rpm changelog? What is wrong with referencing either the included changelog or a URL to a changelog that people can go and reference. I remember this being discussed ages ago but I'm not sure if there was a packaging policy instigated. Along the same lines, why should we have RPM %changelog at all? The git repo should maintain the changelog which can be automatically integrated with the binary RPM at build time. At the moment we have the same information in at least 2 places. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-SOAP-Lite/el5/master] Filter LWP::Protocol and other bogus provides (#557485)
commit df4968db479bcdb91a4321e5e658ce4756b0dae0
Author: Paul Howarth p...@city-fan.org
Date: Fri Sep 24 14:41:36 2010 +0100
Filter LWP::Protocol and other bogus provides (#557485)
- Filter bogus provide of perl(LWP::Protocol) (#557485)
- Filter additional bogus provides:
- perl(My::PingPong)
- perl(URI::jabber)
- perl(URI::mq)
- perl(URI::tcp)
- Re-enable the test suite
- BR: perl(version) and perl(MIME::Parser), needed for test suite
- Don't ship patch backup files
.gitignore |2 +-
filter-requires.sh |3 --
perl-SOAP-Lite.spec | 58 ++
3 files changed, 36 insertions(+), 27 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a5b098a..0e1e16d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-SOAP-Lite-0.68.tar.gz
+/SOAP-Lite-0.710.07.tar.gz
diff --git a/perl-SOAP-Lite.spec b/perl-SOAP-Lite.spec
index ae9886c..6a57e8a 100644
--- a/perl-SOAP-Lite.spec
+++ b/perl-SOAP-Lite.spec
@@ -1,33 +1,38 @@
-Name: perl-SOAP-Lite
+Name: perl-SOAP-Lite
Version: 0.710.07
-Release: 2%{?dist}
+Release: 3%{?dist}
Summary: Client and server side SOAP implementation
License: GPL+ or Artistic
Group: Development/Libraries
-URL: http://search.cpan.org/dist/SOAP-Lite/
-Source0:
http://search.cpan.org/CPAN/authors/id/B/BY/BYRNE/SOAP/SOAP-Lite-%{version}.tar.gz
+URL: http://search.cpan.org/dist/SOAP-Lite/
+Source0:
http://search.cpan.org/CPAN/authors/id/B/BY/BYRNE/SOAP/SOAP-Lite-%{version}.tar.gz
# Submitted upstream: http://rt.cpan.org/Public/Bug/Display.html?id=20569
Patch0:SOAP-Lite-0.710.07-nil-value.patch
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildRequires: perl-XML-Parser
-BuildRequires: perl(ExtUtils::MakeMaker)
-BuildArch: noarch
-
-#%define bogusreqs 'MQ\\|Jabber'
-#%define bogusreqs perl.Net..Jabber.
-#%global reqfilt sh -c '%{__perl_requires} | %{__grep} -Ev %{bogusreqs}'
-#%define __perl_requires %{reqfilt}
-%define bogusreqs 'perl(MQClient::MQSeries)\
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(MIME::Parser)
+BuildRequires: perl(version)
+BuildArch: noarch
+
+# Filter out unwanted requires and provides (#557485)
+%global bogusreqs 'perl(MQClient::MQSeries)\
perl(MQSeries)\
perl(MQSeries::Message)\
perl(MQSeries::Queue)\
perl(MQSeries::QueueManager)\
perl(Net::Jabber)'
+%global bogusprovs 'perl(LWP::Protocol)\
+perl(My::PingPong)\
+perl(URI::jabber)\
+perl(URI::mq)\
+perl(URI::tcp)'
%global reqfilt sh -c %{__perl_requires} | %{__grep} -Fv %{bogusreqs}
+%global provfilt sh -c %{__perl_provides} | %{__grep} -Fv %{bogusprovs}
%define __perl_requires %{reqfilt}
-
+%define __perl_provides %{provfilt}
%description
SOAP::Lite is a collection of Perl modules which provides a simple and
@@ -36,7 +41,9 @@ client and server side.
%prep
%setup -q -n SOAP-Lite-%{version}
-%patch0 -p1 -b .nil-value
+
+# Add support for nil value, a XML-RPC extension (CPAN RT#20569)
+%patch0 -p1
%build
%{__perl} Makefile.PL --noprompt INSTALLDIRS=vendor
@@ -47,19 +54,13 @@ rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2/dev/null ';'
-
-#Items not yet in Extras
-#find $RPM_BUILD_ROOT -type f -name JABBER* -exec rm -f {} ';'
-#find $RPM_BUILD_ROOT -type f -name MQ* -exec rm -f {} ';'
-
chmod -R u+w $RPM_BUILD_ROOT/*
%clean
rm -rf $RPM_BUILD_ROOT
%check
-# Currently disabled until upstream fixes
-#make test
+make test
%files
%defattr(-,root,root,-)
@@ -77,6 +78,17 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man1/*
%changelog
+* Fri Sep 24 2010 Paul Howarth p...@city-fan.org - 0.710.07-3
+- Filter bogus provide of perl(LWP::Protocol) (#557485)
+- Filter additional bogus provides:
+ - perl(My::PingPong)
+ - perl(URI::jabber)
+ - perl(URI::mq)
+ - perl(URI::tcp)
+- Re-enable the test suite
+- BR: perl(version) and perl(MIME::Parser), needed for test suite
+- Don't ship patch backup files
+
* Tue Sep 09 2008 Lubomir Rintel lkund...@v3.sk - 0.710.07-2
- Re-add the nil patch
--
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 557485] Extra provides need trimming
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=557485 Paul Howarth p...@city-fan.org changed: What|Removed |Added Status|NEW |MODIFIED CC||p...@city-fan.org Status Whiteboard|AcualBug|ActualBug --- Comment #1 from Paul Howarth p...@city-fan.org 2010-09-24 09:47:03 EDT --- I have committed a change in git to address this problem and generally clean things up a bit (including re-enabling the test suite). The resulting rpmdiff is as follows: removed PROVIDES perl(LWP::Protocol) removed PROVIDES perl(My::PingPong) removed PROVIDES perl(URI::jabber) removed PROVIDES perl(URI::mq) removed PROVIDES perl(URI::tcp) ..T /usr/bin/SOAPsh.pl ..T /usr/bin/XMLRPCsh.pl ..T /usr/bin/stubmaker.pl ..T /usr/lib/perl5/vendor_perl/5.8.8/Apache ..T /usr/lib/perl5/vendor_perl/5.8.8/Apache/XMLRPC ..T /usr/lib/perl5/vendor_perl/5.8.8/IO ..T /usr/lib/perl5/vendor_perl/5.8.8/OldDocs ..T /usr/lib/perl5/vendor_perl/5.8.8/OldDocs/SOAP ..T /usr/lib/perl5/vendor_perl/5.8.8/OldDocs/SOAP/Transport ..T /usr/lib/perl5/vendor_perl/5.8.8/SOAP ..T /usr/lib/perl5/vendor_perl/5.8.8/SOAP/Lite ..T /usr/lib/perl5/vendor_perl/5.8.8/SOAP/Lite/Deserializer ..T /usr/lib/perl5/vendor_perl/5.8.8/SOAP/Transport ..T /usr/lib/perl5/vendor_perl/5.8.8/UDDI ..T /usr/lib/perl5/vendor_perl/5.8.8/XML ..T /usr/lib/perl5/vendor_perl/5.8.8/XML/Parser S.T /usr/lib/perl5/vendor_perl/5.8.8/XMLRPC ..T /usr/lib/perl5/vendor_perl/5.8.8/XMLRPC/Lite.pm removed /usr/lib/perl5/vendor_perl/5.8.8/XMLRPC/Lite.pm.nil-value ..T /usr/lib/perl5/vendor_perl/5.8.8/XMLRPC/Transport ..T /usr/share/doc/perl-SOAP-Lite-0.710.07 ..T /usr/share/man/man1/SOAPsh.pl.1.gz ..T /usr/share/man/man1/XMLRPCsh.pl.1.gz ..T /usr/share/man/man1/stubmaker.pl.1.gz ..T /usr/share/man/man3/Apache::SOAP.3pm.gz ..T /usr/share/man/man3/Apache::XMLRPC::Lite.3pm.gz ..T /usr/share/man/man3/OldDocs::SOAP::Lite.3pm.gz ..T /usr/share/man/man3/OldDocs::SOAP::Transport::FTP.3pm.gz ..T /usr/share/man/man3/OldDocs::SOAP::Transport::HTTP.3pm.gz ..T /usr/share/man/man3/OldDocs::SOAP::Transport::IO.3pm.gz ..T /usr/share/man/man3/OldDocs::SOAP::Transport::JABBER.3pm.gz ..T /usr/share/man/man3/OldDocs::SOAP::Transport::LOCAL.3pm.gz ..T /usr/share/man/man3/OldDocs::SOAP::Transport::MAILTO.3pm.gz ..T /usr/share/man/man3/OldDocs::SOAP::Transport::MQ.3pm.gz ..T /usr/share/man/man3/OldDocs::SOAP::Transport::POP3.3pm.gz ..T /usr/share/man/man3/OldDocs::SOAP::Transport::TCP.3pm.gz ..T /usr/share/man/man3/SOAP::Client.3pm.gz ..T /usr/share/man/man3/SOAP::Constants.3pm.gz ..T /usr/share/man/man3/SOAP::Data.3pm.gz ..T /usr/share/man/man3/SOAP::Deserializer.3pm.gz ..T /usr/share/man/man3/SOAP::Fault.3pm.gz ..T /usr/share/man/man3/SOAP::Header.3pm.gz ..T /usr/share/man/man3/SOAP::Lite.3pm.gz ..T /usr/share/man/man3/SOAP::Lite::Packager.3pm.gz ..T /usr/share/man/man3/SOAP::Packager.3pm.gz ..T /usr/share/man/man3/SOAP::SOM.3pm.gz ..T /usr/share/man/man3/SOAP::Schema.3pm.gz ..T /usr/share/man/man3/SOAP::Serializer.3pm.gz ..T /usr/share/man/man3/SOAP::Server.3pm.gz ..T /usr/share/man/man3/SOAP::Test.3pm.gz ..T /usr/share/man/man3/SOAP::Trace.3pm.gz ..T /usr/share/man/man3/SOAP::Transport.3pm.gz ..T /usr/share/man/man3/SOAP::Transport::LOOPBACK.3pm.gz ..T /usr/share/man/man3/SOAP::Transport::POP3.3pm.gz ..T /usr/share/man/man3/SOAP::Utils.3pm.gz ..T /usr/share/man/man3/UDDI::Lite.3pm.gz ..T /usr/share/man/man3/XML::Parser::Lite.3pm.gz ..T /usr/share/man/man3/XMLRPC::Lite.3pm.gz ..T /usr/share/man/man3/XMLRPC::Test.3pm.gz ..T /usr/share/man/man3/XMLRPC::Transport::HTTP.3pm.gz ..T /usr/share/man/man3/XMLRPC::Transport::POP3.3pm.gz ..T /usr/share/man/man3/XMLRPC::Transport::TCP.3pm.gz Mike, I can build this as well if you're busy and otherwise happy with this change. -- 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: libedataserverui soname bump in Fedora 14
On Fri, 24 Sep 2010 10:57:41 +0200, Milan wrote: Hi all, I'm so sorry for a late notice, but there was a soname bump of libedataserverui library from evolution-data-server package in time for 2.31.91 update, but I didn't notice this change, and because this update didn't get it to the testing repo, then I realized just now, when I finished an update to 2.31.92 and pushed it to updates-testing. Affected packages seems to be these: almanah anjal gnome-panel It should be enough to just rebuild these against evolution-data-server-2.31.92, which is still marked for a build system. The update request url is here: https://admin.fedoraproject.org/updates/evolution-mapi-0.31.92-1.fc14,evolution-exchange-2.31.92-1.fc14,openchange-0.9-8.fc14,evolution-2.31.92-1.fc14,evolution-data-server-2.31.92-1.fc14,gtkhtml3-3.31.92-1.fc14 Useful information. Due to a bug in mash's spam-o-matic (aka Rawhide and F-14 Branched report), packages with library SONAME versions as in evolution-data-server have never been determined as being related to unresolvable SONAME dependencies (bugzilla 637172). With the fix, the related-pkg owner will be notified in addition to the owner of the broken package. | source rpm: almanah-0.7.3-3.fc14.src.rpm | package: almanah-0.7.3-3.fc14.i686 from fedora-14-development-i386 | unresolved deps: | libedataserverui-1.2.so.10 | related pkgs: | evolution-data-server -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-14 Branched report: 20100924 changes
Compose started at Fri Sep 24 13:15:20 UTC 2010 Broken deps for x86_64 -- antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 cyphesis-0.5.21-2.fc13.x86_64 requires libpython2.6.so.1.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libedata-book-1.2.so.2()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-1.2.so.17()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-provider-1.2.so.17()(64bit) evolution-sharp-0.21.1-9.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) gnome-python2-evolution-2.31.1-5.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10 libglade-java-2.12.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10 libgnome-java-2.12.4-12.fc12.x86_64 requires libgcj.so.10()(64bit) libvte-java-0.12.1-15.fc12.i686 requires libgcj.so.10 libvte-java-0.12.1-15.fc12.x86_64 requires libgcj.so.10()(64bit) matahari-0.0.5-1.fc14.x86_64 requires libqmf.so.1()(64bit) mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires mingw32(libpng-3.dll) ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc perl-Gtk2-MozEmbed-0.08-6.fc14.15.x86_64 requires gecko-libs = 0:1.9.2.4 php-pecl-imagick-3.0.0-7.fc14.x86_64 requires libMagickWand.so.3()(64bit) php-pecl-imagick-3.0.0-7.fc14.x86_64 requires libMagickCore.so.3()(64bit) plee-the-bear-0.4.1-5.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) plee-the-bear-0.4.1-5.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) plee-the-bear-0.4.1-5.fc14.x86_64 requires libboost_system-mt.so.1.41.0()(64bit) qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) 1:rubygem-actionmailer-2.3.5-1.fc13.noarch requires rubygem(actionpack) = 0:2.3.5 1:rubygem-rails-2.3.8-1.fc14.noarch requires rubygem(actionmailer) = 0:2.3.8 rubygem-ruby-debug-doc-0.10.4-0.2.rc1.fc14.noarch requires /ursr/bin/env spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires spacewalk-backend-libs = 0:0.8.28 valide-0.6.1-0.22.20103003svn511.fc14.i686 requires libvala.so.0 valide-0.6.1-0.22.20103003svn511.fc14.x86_64 requires libvala.so.0()(64bit) viking-0.9.91-3.fc13.x86_64 requires libgps.so.18()(64bit) wfut-1.1.0-8.fc12.x86_64 requires libgcj.so.10()(64bit) Broken deps for i386 -- antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 cyphesis-0.5.21-2.fc13.i686 requires libpython2.6.so.1.0 evolution-couchdb-0.4.92-1.fc14.i686 requires libcamel-provider-1.2.so.17 evolution-couchdb-0.4.92-1.fc14.i686 requires libebook-1.2.so.9 evolution-couchdb-0.4.92-1.fc14.i686 requires libgtkhtml-editor.so.0 evolution-couchdb-0.4.92-1.fc14.i686 requires libedata-book-1.2.so.2 evolution-couchdb-0.4.92-1.fc14.i686 requires libcamel-1.2.so.17 evolution-sharp-0.21.1-9.fc14.i686 requires libcamel-1.2.so.19 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 gnome-python2-evolution-2.31.1-5.fc14.i686 requires libcamel-1.2.so.19 gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-gtk-0.4.so.0 gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-0.4.so.0 intellij-idea-9.0.1.94.399-11.fc14.i686 requires jna-examples libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10 libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10 libvte-java-0.12.1-15.fc12.i686 requires libgcj.so.10 matahari-0.0.5-1.fc14.i686 requires libqmf.so.1 mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires mingw32(libpng-3.dll) ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc perl-Gtk2-MozEmbed-0.08-6.fc14.15.i686 requires gecko-libs = 0:1.9.2.4 php-pecl-imagick-3.0.0-7.fc14.i686
[Bug 570321] Missing Dependencies postgresql-plperl and perl-BDB-Pg 2.0
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=570321 Mark Chappell trem...@tremble.org.uk changed: What|Removed |Added Blocks||425821(EPEL5-BrokenDeps) -- 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: F-14 Branched report: 20100923 changes
On Fri, Sep 24, 2010 at 5:34 PM, Toshio Kuratomi a.bad...@gmail.com wrote: On Fri, Sep 24, 2010 at 02:44:34PM +0100, Richard W.M. Jones wrote: On Thu, Sep 23, 2010 at 07:01:16PM +0100, Peter Robinson wrote: Is it really necessary to include entire package change logs in the rpm changelog? What is wrong with referencing either the included changelog or a URL to a changelog that people can go and reference. I remember this being discussed ages ago but I'm not sure if there was a packaging policy instigated. Along the same lines, why should we have RPM %changelog at all? The git repo should maintain the changelog which can be automatically integrated with the binary RPM at build time. At the moment we have the same information in at least 2 places. We need to have the rpm changelog in the rpm so that the end user's can see it. For the fact that its gone from version X to version Y yes. For the actual application changed between version X and version Y they can see the ChangeLog that's in the %doc or alternatively check the release notes for the new version upstream (which can be easily provided as a link in the rpm changelog). I just don't see the point in duplicating hundreds of line of upstream release notes in the rpm changelog when all that's actually changed in the rpm is that we've gone from release X to release Y. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-14 Branched report: 20100923 changes
On 09/24/2010 12:43 PM, Peter Robinson wrote: On Fri, Sep 24, 2010 at 5:34 PM, Toshio Kuratomia.bad...@gmail.com wrote: On Fri, Sep 24, 2010 at 02:44:34PM +0100, Richard W.M. Jones wrote: On Thu, Sep 23, 2010 at 07:01:16PM +0100, Peter Robinson wrote: Is it really necessary to include entire package change logs in the rpm changelog? What is wrong with referencing either the included changelog or a URL to a changelog that people can go and reference. I remember this being discussed ages ago but I'm not sure if there was a packaging policy instigated. Along the same lines, why should we have RPM %changelog at all? The git repo should maintain the changelog which can be automatically integrated with the binary RPM at build time. At the moment we have the same information in at least 2 places. We need to have the rpm changelog in the rpm so that the end user's can see it. For the fact that its gone from version X to version Y yes. For the actual application changed between version X and version Y they can see the ChangeLog that's in the %doc or alternatively check the release notes for the new version upstream (which can be easily provided as a link in the rpm changelog). I just don't see the point in duplicating hundreds of line of upstream release notes in the rpm changelog when all that's actually changed in the rpm is that we've gone from release X to release Y. It is extremely useful to see the RPM info on which vulnerabilities (CVS numbers, etc) were fixed by the update, especially when they are backported and therefore not reflected in the package version number. In principle, the system for extracting %changelog from git might work, with two provisos: - people understand that git changelogs have slightly different purpose than RPM changelogs: git records 'what' changed, while RPM should also tell 'why' it was changed. In other words, we'd be relying on developers making high-level as well as low-level comments in the 'log. - the volume of changelog output should not overwhelm useful information contained in the log. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-14 Branched report: 20100923 changes
On Fri, Sep 24, 2010 at 17:43:47 +0100, Peter Robinson pbrobin...@gmail.com wrote: For the fact that its gone from version X to version Y yes. For the actual application changed between version X and version Y they can see the ChangeLog that's in the %doc or alternatively check the release notes for the new version upstream (which can be easily provided as a link in the rpm changelog). I just don't see the point in duplicating hundreds of line of upstream release notes in the rpm changelog when all that's actually changed in the rpm is that we've gone from release X to release Y. On the otherside, sometimes all there is, is a note that the version changed. Including a link to the upstream release notes is nice, even if there isn't anything else that seems important enough to call out. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-14 Branched report: 20100923 changes
On Fri, Sep 24, 2010 at 05:43:47PM +0100, Peter Robinson wrote: On Fri, Sep 24, 2010 at 5:34 PM, Toshio Kuratomi a.bad...@gmail.com wrote: On Fri, Sep 24, 2010 at 02:44:34PM +0100, Richard W.M. Jones wrote: On Thu, Sep 23, 2010 at 07:01:16PM +0100, Peter Robinson wrote: Is it really necessary to include entire package change logs in the rpm changelog? What is wrong with referencing either the included changelog or a URL to a changelog that people can go and reference. I remember this being discussed ages ago but I'm not sure if there was a packaging policy instigated. Along the same lines, why should we have RPM %changelog at all? The git repo should maintain the changelog which can be automatically integrated with the binary RPM at build time. At the moment we have the same information in at least 2 places. We need to have the rpm changelog in the rpm so that the end user's can see it. For the fact that its gone from version X to version Y yes. Actually, this is normally reflected in the package version which is quite visible. For the actual application changed between version X and version Y they can see the ChangeLog that's in the %doc or alternatively check the release notes for the new version upstream (which can be easily provided as a link in the rpm changelog). rpm -q --changelog repoquery -q --changelog Very handy for asking and answering the questions like: foobar started segfaulting. yum history tells me I updated it, libbaz, and libzardoz. Any changes in those that could have caused this? I'm having problems with foobar not being able to connect to https://. I wonder if the new update in updates-testing might fix that? I just don't see the point in duplicating hundreds of line of upstream release notes in the rpm changelog when all that's actually changed in the rpm is that we've gone from release X to release Y. I agree that duplicating hundreds of lines is not productive. To me the rpm changelog should give me enough information to know if I might be on the right track when I ask the questions above. Having hundreds of lines of changelog per entry is counter-productive to that goal:: If I have to wade through hundreds of lines for each of foobar, libbaz, and libzardoz I might well miss that one of the changelog entries addressed the problem I'm looking for. The rpm changelog should be more like NEWS than a changelog; and usually a summary of NEWS, at that. (imho, no packaging guidelines currently mandate this, etc.) -Toshio pgpXtrqLSRGcK.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please Review: (630091) fix coverity Defect Type: Memory - illegal accesses issues
https://bugzilla.redhat.com/show_bug.cgi?id=630091 https://bugzilla.redhat.com/attachment.cgi?id=449474action=edit -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: F-14 Branched report: 20100923 changes
Toshio Kuratomi wrote: I would much prefer to generate the git log from the rpm changelog than vice-versa, though. THe git log is going to contain more entries than the rpm changelog as little things get fixed from time to time that deserve a commit in git but don't deserve a mention in the rpm changelog. This should be pretty easy to do in fedpkg commit by having that perform its fedpkg clog action and then automatically adding that information into what the git message will be... Wouldn't that duplicate entries in the Git changelog? If fedpkg clog takes the topmost entry from the RPM changelog, that will be the same entry as last time in those cases that deserve a commit in Git but don't deserve a mention in the RPM changelog. It seems to me that fedpkg would have to search the Git changelog for the text it took from the RPM changelog, and prompt the packager for another log message if it's already there. Björn Persson 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: F-14 Branched report: 20100923 changes
On 09/24/2010 01:32 PM, Toshio Kuratomi wrote: The rpm changelog should be more like NEWS than a changelog; and usually a summary of NEWS, at that. (imho, no packaging guidelines currently mandate this, etc.) I could swear I had written don't copy the upstream changelog into the rpm changelog, summarize in a line or two if you must., but apparently, I never did. :/ ~spot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F-14 Branched report: 20100923 changes
On Fri, 2010-09-24 at 13:11 -0400, Przemek Klosowski wrote: In principle, the system for extracting %changelog from git might work, with two provisos: - people understand that git changelogs have slightly different purpose than RPM changelogs: git records 'what' changed, while RPM should also tell 'why' it was changed. In other words, we'd be relying on developers making high-level as well as low-level comments in the 'log. - the volume of changelog output should not overwhelm useful information contained in the log. It's not really in principle; other distros have been doing this for years (it's been this way in Mandriva ever since I became a contributor there). The RPM changelog is generated from SCM commit messages. If you want an SCM commit message not to show up in the RPM changelog - say it's just you fixing a stupid mistake in the spec - preface it with SILENT: . This system always seemed to work fine. -- 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: F-14 Branched report: 20100923 changes
On Fri, Sep 24, 2010 at 07:55:08PM +0200, Björn Persson wrote: Toshio Kuratomi wrote: I would much prefer to generate the git log from the rpm changelog than vice-versa, though. THe git log is going to contain more entries than the rpm changelog as little things get fixed from time to time that deserve a commit in git but don't deserve a mention in the rpm changelog. This should be pretty easy to do in fedpkg commit by having that perform its fedpkg clog action and then automatically adding that information into what the git message will be... Wouldn't that duplicate entries in the Git changelog? If fedpkg clog takes the topmost entry from the RPM changelog, that will be the same entry as last time in those cases that deserve a commit in Git but don't deserve a mention in the RPM changelog. It seems to me that fedpkg would have to search the Git changelog for the text it took from the RPM changelog, and prompt the packager for another log message if it's already there. Well, the idea would be to drop you into an editor where the buffer is prefilled with that info. So if you only occasionally make an extra commit, you'll only occassionally have to delete it. -Toshio pgp9sezsvJkQP.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
koji.TagError
Why is this happening? rubygem-state_machine-0.9.4-3.fc12 unsuccessfully untagged from dist-f12-updates-testing-pending by bodhi Operation failed with the error: koji.TagError: build rubygem-state_machine-0.9.4-3.fc12 not in tag dist-f12-updates-testing-pending Is it something i can fix? (action?) Guillermo http://www.neotechgw.com http://gomix.fedora-ve.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review request: Nice-to-have bug process documentation proposal
On Thu, 2010-09-23 at 12:58 +0100, Adam Williamson wrote: Hi, everyone. So we partly used the proposed new nice-to-have bug tracking system during the F14 Beta process, and it seemed to go well. In a quick burst of airport productivity, I've quickly written up a bunch of proposed new wiki pages and modifications to existing ones to document the nice-to-have process (and, incidentally, extend documentation of the blocker process, since we don't seem to have much of it beyond the blocker meeting SOP right now). All the pages can be found here: https://fedoraproject.org/wiki/Category:NTH_adjustment_drafts Thanks for providing draft wiki edits with the proposal. I've made a few _minor_ tweaks to the wiki pages. it should be pretty obvious which are new and which are modifications of existing pages. I hope this is mostly straightforward and non-controversial. A quick five-minute summary is that we will now have (in fact, we already do) trackers for nice-to-have bugs for Alpha, Beta and Final releases as well as trackers for blocker bugs. Bugs on these NTH lists will be given priority after blocker bugs for QA, devel and releng work for releases. Fixes for these bugs - and *only* these bugs, if a fix is to be taken through a freeze, there must be a matching accepted NTH bug - will be taken through release freezes. Proposing, reviewing and monitoring NTH bugs will work exactly as it does for blocker bugs, and mostly happen in the blocker meetings, but of course after consideration of the blocker lists. I like the idea of formalizing the 'nice-to-have' process. I recall tension during the F-13-RC phase regarding the decision making process that allowed a selection of non-Blocker fixes into the release. I hope that this process helps clarify the acceptable exceptions to the blocker process. In practice this is a formalization of existing procedure - until F14 Beta, QA and releng did much the same process but entirely informally, we just kept lists of bugs we'd take fixes for either in our heads or in the RC creation trac tickets. This process is meant to be more robust, documented and discoverable. Perhaps the pending rel-eng SOP documents would cover this, but I'm unclear how FXX-accepted bugs are treated during at compose time. For our current Blocker bug process, it's established that if the appropriate blocker bug list is not empty, we can't compose. With non-blocker nice-to-have (NTH) bugs, how would that fix get into a compose? Guessing ... * The fix would have to be packaged and available in bodhi updates-testing * The bodhi update has received the required karma * The accepted bug is in VERIFIED state? To summarize, what instructions can we provide maintainers with so they can be confident an tested, packaged and approved nice-to-have fix will be pulled into any (re)compose? Perhaps, more of a question for the release-engineering team. Different topic ... In the days of using *only* Blocker bugs, it's now somewhat confusing to look at the F14Beta-accepted tracker, after we started mirroring F14Beta, and see 12 open bugs (some trackers) [1]. I don't think this is a bad thing, but perhaps another item to manage based on the result of the go/no-go meeting ... move any pending FXX-accepted bugs into the next milestone (so open FXXBeta-accepted bugs would move to FXX-accepted)? [1] https://bugzilla.redhat.com/showdependencytree.cgi?id=F14Beta-acceptedhide_resolved=1 Some releng SOP pages may require minor updates, I figured I'd leave that to releng. The process for creating blocker trackers should also be updated to cover creating NTH trackers (I couldn't find that; poelcat, where is it?) https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers I assume User:Adamwill/QA:SOP_blocker_bug_meeting_nth_draft is intended to replace QA:SOP_Blocker_Bug_Meeting, and not define an additional blocker review meeting? I've queued https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_nth_process_nth_draft up for some additional reading, I'll reply later with any additional comments. Thanks, James signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: koji.TagError
On Fri, 2010-09-24 at 14:48 -0430, Guillermo Gómez wrote: Why is this happening? rubygem-state_machine-0.9.4-3.fc12 unsuccessfully untagged from dist-f12-updates-testing-pending by bodhi Operation failed with the error: koji.TagError: build rubygem-state_machine-0.9.4-3.fc12 not in tag dist-f12-updates-testing-pending Is it something i can fix? (action?) See: Guillermo http://www.neotechgw.com http://gomix.fedora-ve.org -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: koji.TagError
On Fri, 2010-09-24 at 16:50 -0400, Matt McCutchen wrote: On Fri, 2010-09-24 at 14:48 -0430, Guillermo Gómez wrote: Why is this happening? rubygem-state_machine-0.9.4-3.fc12 unsuccessfully untagged from dist-f12-updates-testing-pending by bodhi Operation failed with the error: koji.TagError: build rubygem-state_machine-0.9.4-3.fc12 not in tag dist-f12-updates-testing-pending Is it something i can fix? (action?) See: Oops. Somehow I hit Send instead of Paste. https://lists.fedoraproject.org/pipermail/test/2010-September/094041.html -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 637077] New: PID file location miss match
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: PID file location miss match
https://bugzilla.redhat.com/show_bug.cgi?id=637077
Summary: PID file location miss match
Product: Fedora
Version: 13
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: amavisd-new
AssignedTo: st...@silug.org
ReportedBy: t...@appletz.jp
QAContact: extras...@fedoraproject.org
CC: st...@silug.org, fedora-perl-devel-l...@redhat.com,
kana...@kanarip.com
Classification: Fedora
Description of problem:
'/usr/share/clamav/clamd-wrapper' considers the place of the PID file to be
'/var/run/clamd.${CLAMD_SERVICE}/clamd.pid' if it isn't specified.
However, because '/etc/clamd.d/amavisd.conf' specifies
'var/run/amavisd/clamd.pid', so
it is necessary to be specified in '/etc/sysconfig/clamd.amavisd'.
--- SOURCES/amavis-clamd.sysconfig~ 2006-01-26 17:11:54.0 -0500
+++ SOURCES/amavis-clamd.sysconfig 2010-09-24 07:51:42.605828909 -0400
@@ -1,3 +1,4 @@
CLAMD_CONFIGFILE=/etc/clamd.d/amavisd.conf
CLAMD_SOCKET=/var/spool/amavisd/clamd.sock
+CLAMD_PIDFILE=/var/run/amavisd/clamd.pid
CLAMD_OPTIONS=
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 637110] New: perl-HTML-Encoding-0.61 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-HTML-Encoding-0.61 is available https://bugzilla.redhat.com/show_bug.cgi?id=637110 Summary: perl-HTML-Encoding-0.61 is available Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: ASSIGNED Keywords: FutureFeature, Triaged Severity: medium Priority: low Component: perl-HTML-Encoding AssignedTo: ville.sky...@iki.fi ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, ville.sky...@iki.fi Classification: Fedora Latest upstream release: 0.61 Current version in Fedora Rawhide: 0.60 URL: http://search.cpan.org/dist/HTML-Encoding/ Please consult the package update guidelines before you issue an update to a stable branch: https://fedoraproject.org/wiki/Package_update_guidelines More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_Release_Monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 637111] New: perl-YAML-LibYAML-0.34 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-YAML-LibYAML-0.34 is available https://bugzilla.redhat.com/show_bug.cgi?id=637111 Summary: perl-YAML-LibYAML-0.34 is available Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: ASSIGNED Keywords: FutureFeature, Triaged Severity: medium Priority: low Component: perl-YAML-LibYAML AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora Latest upstream release: 0.34 Current version in Fedora Rawhide: 0.33 URL: http://search.cpan.org/dist/YAML-LibYAML/ Please consult the package update guidelines before you issue an update to a stable branch: https://fedoraproject.org/wiki/Package_update_guidelines More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_Release_Monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File YAML-LibYAML-0.34.tar.gz uploaded to lookaside cache by mmaslano
A file has been added to the lookaside cache for perl-YAML-LibYAML: 85b4427e88597392d9cdefbad0469245 YAML-LibYAML-0.34.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-YAML-LibYAML] - udpate
commit d3310af87e2de6d9aca1d95de4c41df7ad87a31d
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Fri Sep 24 13:30:25 2010 +0200
- udpate
.gitignore |1 +
perl-YAML-LibYAML.spec | 13 -
sources|2 +-
3 files changed, 10 insertions(+), 6 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 0c191af..91d6e1d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
YAML-LibYAML-0.33.tar.gz
+/YAML-LibYAML-0.34.tar.gz
diff --git a/perl-YAML-LibYAML.spec b/perl-YAML-LibYAML.spec
index 0b2d0a1..73b42dd 100644
--- a/perl-YAML-LibYAML.spec
+++ b/perl-YAML-LibYAML.spec
@@ -1,11 +1,11 @@
Name: perl-YAML-LibYAML
-Version:0.33
+Version:0.34
Release:1%{?dist}
Summary:YAML::LibYAML Perl module
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/YAML-LibYAML/
-Source0:
http://www.cpan.org/authors/id/N/NU/NUFFIN/YAML-LibYAML-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/I/IN/INGY/YAML-LibYAML-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::More)
@@ -26,7 +26,7 @@ iconv -f iso8859-1 -t utf-8 README README.1
mv README.1 README
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
+%{__perl} Makefile.PL INSTALLDIRS=perl OPTIMIZE=$RPM_OPT_FLAGS
make %{?_smp_mflags}
%install
@@ -49,11 +49,14 @@ rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes README
-%{perl_vendorarch}/auto/*
-%{perl_vendorarch}/YAML*
+%{perl_archlib}/auto/*
+%{perl_archlib}/YAML*
%{_mandir}/man3/*
%changelog
+* Fri Sep 23 2010 Marcela Mašláňová mmasl...@redhat.com - 0.34-1
+- udpate
+
* Thu Jun 3 2010 Marcela Maslanova mmasl...@redhat.com - 0.33-1
- update
diff --git a/sources b/sources
index aaf6a41..4bda7ea 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-001a21618af05ee3a12dbb8cd6bd9b13 YAML-LibYAML-0.33.tar.gz
+85b4427e88597392d9cdefbad0469245 YAML-LibYAML-0.34.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 637111] perl-YAML-LibYAML-0.34 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=637111 Marcela Mašláňová mmasl...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution||RAWHIDE Last Closed||2010-09-24 07:40:25 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Variable-Magic-0.44.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Variable-Magic: 9c8c4f73547996d6f08a3a2452f2a444 Variable-Magic-0.44.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Variable-Magic] Update to 0.44
commit c35617a512b49b304963c76a0ee509b8f2074a72
Author: Emmanuel Seyman emmanuel.sey...@club-internet.fr
Date: Sat Sep 25 01:30:28 2010 +0200
Update to 0.44
.gitignore |1 +
perl-Variable-Magic.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 4c2f35e..4112c0c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Variable-Magic-0.43.tar.gz
+/Variable-Magic-0.44.tar.gz
diff --git a/perl-Variable-Magic.spec b/perl-Variable-Magic.spec
index b69e4a3..a6bd5ad 100644
--- a/perl-Variable-Magic.spec
+++ b/perl-Variable-Magic.spec
@@ -1,5 +1,5 @@
Name: perl-Variable-Magic
-Version:0.43
+Version:0.44
Release:1%{?dist}
Summary:Associate user-defined magic to variables from Perl
License:GPL+ or Artistic
@@ -56,6 +56,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Fri Sep 25 2010 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 0.44-1
+- Update to 0.44.
+
* Sun Jun 26 2010 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 0.43-1
- Update to 0.43.
diff --git a/sources b/sources
index b855baf..3a0709b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-12badae22241ed9575f6c91a4d63f346 Variable-Magic-0.43.tar.gz
+9c8c4f73547996d6f08a3a2452f2a444 Variable-Magic-0.44.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[pkgdb] perl-Module-Build (un)retirement
Package perl-Module-Build in Fedora devel has been unretired by kevin and is now orphan. To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Module-Build -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[389-devel] Please review (revised): [Bug 635987] Incorrect sub scope search result with ACL containing ldap:///self
https://bugzilla.redhat.com/show_bug.cgi?id=635987 https://bugzilla.redhat.com/attachment.cgi?id=449487action=diff https://bugzilla.redhat.com/attachment.cgi?id=449487action=edit Thanks to Rich for analysing the bug introduced by the previous commit. The attached patch should fix it. Description: This commit made for the bug 635987 introduced a bug to replication. commit 8ac525e5ac997378f4f2a386e9b96568c8d66db5 Author: Noriko Hosoinho...@redhat.com Date: Tue Sep 21 15:12:07 2010 -0700 subtree_candidates (ldbm_search.c) If you do have a tombstone filter, descendants will be NULL, and idl_intersection of candidates and descendents will wipe out all of the candidates, leaving just the one entry, e-ep_id. Changed to call idl_intersection only when the filter is not for tombstone or entryrdn_get_noancestorid (false, by default). smime.p7s Description: S/MIME Cryptographic Signature -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
