Re: yum-builddep (Re: Compiling 32bit on 64bit Fedora)
On 09/08/2011 03:44 AM, Tony Breeds wrote:
Hi All,
On a related but different note. How hard would it be to get
yum-builddep to take an --arch arg to that we can esily get the 32-bit
builddeps on a 64-bit system?
It's been recently implemented at upstream, see
https://bugzilla.redhat.com/show_bug.cgi?id=734983 for details.
Note that this is only possible when feeding spec-files to yum-builddep,
and even then it requires that spec BuildRequires are using %{_isa}
where relevant.
- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning maradns
On 7/09/2011 4:50 PM, Tomasz Torcz wrote: On Tue, Sep 06, 2011 at 02:23:36PM +0100, Khusro Jaleel wrote: On 06/09/11 06:31, Michael Fleming wrote: I've released ownership of the aforementioned package, as I've not used it in any meaningful way in some time and don't have the time to maintain it further. Upstream development seems to have picked up of late (was dormant for a long time) so potential future maintainers will have something interesting to hack on :-) Michael. I'm willing to have a go at maintaining it, I have made a few packages on CentOS in the past for internal company use (BIND 9.8) and a font package for Fedora (tlomt-league-gothic) and I think I should be able to do it. Are there any special gotchas or issues that I need to be aware of? I for one suggest including systemd unit file now: https://bugzilla.redhat.com/show_bug.cgi?id=656891 You won't be able to do it after F16 Beta. That and an update (either 1.4 or the newer 2.0, which now calls the resolver daemon Deadwood) and you're in good shape, as best I can see. Be aware that duende (the process that usually spawns off maradns' recursive and zoneserver authoritative/transfer portions) can be tricky if you're not used to such things. If you've ever worked with djbdns/dnscache before the concept is much clearer, I feel :-) Michael. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File DBD-CSV-0.33.tgz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-DBD-CSV: 0b43201bf1aa043e12bebecdec17a17e DBD-CSV-0.33.tgz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DBD-CSV] 0.33 bump
commit 0ed8f34556db02ad5cbfed2cb44ae2a586a4f430
Author: Petr Sabata con...@redhat.com
Date: Thu Sep 8 12:53:39 2011 +0200
0.33 bump
.gitignore|1 +
perl-DBD-CSV.spec | 39 ++-
sources |2 +-
3 files changed, 16 insertions(+), 26 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index ed93da4..a698b81 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
DBD-CSV-0.30.tgz
/DBD-CSV-0.31.tgz
+/DBD-CSV-0.33.tgz
diff --git a/perl-DBD-CSV.spec b/perl-DBD-CSV.spec
index 4ca855b..78392d9 100644
--- a/perl-DBD-CSV.spec
+++ b/perl-DBD-CSV.spec
@@ -1,28 +1,25 @@
Name: perl-DBD-CSV
-Version:0.31
-Release:5%{?dist}
+Version:0.33
+Release:1%{?dist}
Summary:DBI driver for CSV files
-
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/DBD-CSV/
Source0:
http://search.cpan.org/CPAN/authors/id/H/HM/HMBRAND/DBD-CSV-%{version}.tgz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
BuildArch: noarch
BuildRequires: perl(DBD::File) = 0.40
BuildRequires: perl(DBI) = 1.614
BuildRequires: perl(ExtUtils::MakeMaker)
-BuildRequires: perl(SQL::Statement) = 1.31
+BuildRequires: perl(SQL::Statement) = 1.33
BuildRequires: perl(Text::CSV_XS) = 0.71
BuildRequires: perl(Test::Harness)
-# BuildRequires = 0.90, but 0.96 is recommended
-BuildRequires: perl(Test::More) = 0.90
+# BuildRequires = 0.90, but 0.98 is recommended
+BuildRequires: perl(Test::More) = 0.98
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
Requires: perl(DBD::File) = 0.40
Requires: perl(DBI) = 1.614
Requires: perl(SQL::Statement) = 1.31
-# Requires = 0.71, but 0.73 is recommended
+# Requires = 0.71, but 0.83 is recommended
Requires: perl(Text::CSV_XS) = 0.71
# RPM 4.8 style
@@ -41,42 +38,34 @@ and implements access to so-called CSV files (Comma
separated
values). Such files are mostly used for exporting MS Access and
MS Excel data.
-
%prep
%setup -q -n DBD-CSV-%{version}
chmod -c a-x ChangeLog README lib/DBD/*.pm lib/Bundle/DBD/*.pm
-
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
-
%install
-rm -rf $RPM_BUILD_ROOT
-make pure_install DESTDIR=$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 ';'
-chmod -R u+w $RPM_BUILD_ROOT/*
-
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+find %{buildroot} -type d -depth -exec rmdir {} 2/dev/null ';'
+chmod -R u+w %{buildroot}/*
%check
make test
-
-%clean
-rm -rf $RPM_BUILD_ROOT
-
-
%files
-%defattr(-,root,root,-)
%doc ChangeLog README
%{perl_vendorlib}/Bundle/
%{perl_vendorlib}/DBD/
%{_mandir}/man3/*.3pm*
-
%changelog
+* Thu Sep 08 2011 Petr Sabata con...@redhat.com - 0.33-1
+- 0.33 bump
+- Remove now obsolete BuildRoot and defattr
+
* Mon Jul 25 2011 Petr Pisar ppi...@redhat.com - 0.31-5
- RPM 4.9 dependency filtering added
diff --git a/sources b/sources
index e055c0a..b592a63 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-50918cc0ed58dd38df462398a16adc36 DBD-CSV-0.31.tgz
+0b43201bf1aa043e12bebecdec17a17e DBD-CSV-0.33.tgz
--
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 736635] perl-DBD-CSV-0.33 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=736635 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-DBD-CSV-0.33-1.fc17 Resolution||RAWHIDE Last Closed||2011-09-08 06:55:38 -- 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: Broken dependencies: pino
Dear Pino maintainers, On Wed, Sep 7, 2011 at 3:30 PM, build...@fedoraproject.org wrote: pino has broken dependencies in the rawhide tree: On x86_64: pino-0.3-0.3.20101112hg.fc15.x86_64 requires libgee.so.2()(64bit) On i386: pino-0.3-0.3.20101112hg.fc15.i686 requires libgee.so.2 Please resolve this as soon as possible. Rawhide now has libgee 0.7; upstream has changed their versioning system so that, like Vala, the odd minor releases have API levels equal to the next even number (thus libgee 0.7 is at API level 0.8 and ships with gee-0.8.pc) I tried making a test build with the CMakeLists.txt patched, but it looks like there are other changes that need to be made: - src/accounts_widget.vala, line 38: Vala 0.13.x does not seem to like 'public static enum', removing the static allows compilation to proceed - DSO linking problem: trunc is used, requiring -lm to link against libm.so.6 Given that several changes are needed, it's probably best for one of the Pino maintainers to make the update (I'd not feel comfortable doing anything more than just adjusting for the libgee changes) Best regards, -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: 78884778 Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-16 Branched report: 20110908 changes
Compose started at Thu Sep 8 08:15:33 UTC 2011 Broken deps for x86_64 -- acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) airrac-0.1.0-2.fc16.i686 requires libstdair.so.0.36 airrac-0.1.0-2.fc16.i686 requires libstdairuicl.so.0.36 airrac-0.1.0-2.fc16.x86_64 requires libstdairuicl.so.0.36()(64bit) airrac-0.1.0-2.fc16.x86_64 requires libstdair.so.0.36()(64bit) askbot-0.7.17-1.fc16.noarch requires django-recaptcha-works assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) awn-extras-applets-0.4.2-0.1.bzr1523.fc16.x86_64 requires libgnome-menu.so.2()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libedataserver-1.2.so.14()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave emerillon-0.1.2-17.fc16.x86_64 requires libethos-ui-1.0.so.0()(64bit) emerillon-0.1.2-17.fc16.x86_64 requires libethos-1.0.so.0()(64bit) evolution-mapi-devel-3.1.90-1.fc16.i686 requires openchange-devel = 0:0.11-2 evolution-mapi-devel-3.1.90-1.fc16.x86_64 requires openchange-devel = 0:0.11-2 evolution-rss-0.2.90-27.20110818git.fc16.x86_64 requires libcamel-provider-1.2.so.28()(64bit) evolution-rss-0.2.90-27.20110818git.fc16.x86_64 requires libedataserver-1.2.so.14()(64bit) evolution-rss-0.2.90-27.20110818git.fc16.x86_64 requires libebook-1.2.so.11()(64bit) evolution-rss-0.2.90-27.20110818git.fc16.x86_64 requires libcamel-1.2.so.28()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_signals-mt.so.1.46.1()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_thread-mt.so.1.46.1()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libgeos-3.2.1.so()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) flaw-1.2.4-2.fc15.x86_64 requires libSDL_gfx.so.0()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk_images.so.1.1()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk.so.1.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_system-mt.so.1.46.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_signals-mt.so.1.46.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_thread-mt.so.1.46.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_filesystem-mt.so.1.46.1()(64bit) fuse-encfs-1.7.4-1.fc16.i686 requires libboost_serialization-mt.so.1.46.1 fuse-encfs-1.7.4-1.fc16.i686 requires libboost_filesystem-mt.so.1.46.1 fuse-encfs-1.7.4-1.fc16.i686 requires
Re: Broken dependencies: pino
On 09/08/2011 04:43 PM, Michel Alexandre Salim wrote: Given that several changes are needed, it's probably best for one of the Pino maintainers to make the update (I'd not feel comfortable doing anything more than just adjusting for the libgee changes) Upstream is struck in development stage for a long time after the rewrite started and hasn't been responsive to any bug reports filed. I am inclined to just orphan it Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning maradns
On Thu, Sep 08, 2011 at 08:52:38PM +1000, Michael Fleming wrote: On 7/09/2011 4:50 PM, Tomasz Torcz wrote: On Tue, Sep 06, 2011 at 02:23:36PM +0100, Khusro Jaleel wrote: On 06/09/11 06:31, Michael Fleming wrote: I've released ownership of the aforementioned package, as I've not used it in any meaningful way in some time and don't have the time to maintain it further. Upstream development seems to have picked up of late (was dormant for a long time) so potential future maintainers will have something interesting to hack on :-) Michael. I'm willing to have a go at maintaining it, I have made a few packages on CentOS in the past for internal company use (BIND 9.8) and a font package for Fedora (tlomt-league-gothic) and I think I should be able to do it. Are there any special gotchas or issues that I need to be aware of? I for one suggest including systemd unit file now: https://bugzilla.redhat.com/show_bug.cgi?id=656891 You won't be able to do it after F16 Beta. That and an update (either 1.4 or the newer 2.0, which now calls the resolver daemon Deadwood) and you're in good shape, as best I can see. Be aware that duende (the process that usually spawns off maradns' recursive and zoneserver authoritative/transfer portions) can be tricky if you're not used to such things. If you've ever worked with djbdns/dnscache before the concept is much clearer, I feel :-) Just drop duende. systemd does everything what duende provides. -- Tomasz Torcz God, root, what's the difference? xmpp: zdzich...@chrome.pl God is more forgiving. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 736636] perl-Text-CSV_XS-0.85 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=736636 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Text-CSV_XS-0.85-1.fc1 ||7 Resolution||RAWHIDE Last Closed||2011-09-08 07:22:41 -- 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: Broken dependencies: pino
On Thu, 2011-09-08 at 16:52 +0530, Rahul Sundaram wrote: On 09/08/2011 04:43 PM, Michel Alexandre Salim wrote: Given that several changes are needed, it's probably best for one of the Pino maintainers to make the update (I'd not feel comfortable doing anything more than just adjusting for the libgee changes) Upstream is struck in development stage for a long time after the rewrite started and hasn't been responsive to any bug reports filed. I am inclined to just orphan it I would second this. I've got a number of critical bugs still open in Bugzilla about pino; these have been open since before F15 released IIRC and it has been totally unusable (for anyone, as far as I can tell) since then. It's a shame because I was a big user of it (obviously), but I've had to go back using twitter/identi.ca directly; it simply doesn't work. Cheers Alex. -- This message was scanned by Better Hosted and is believed to be clean. http://www.betterhosted.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broken dependencies: pino
On 09/08/2011 04:54 PM, Alex Hudson wrote: I would second this. I've got a number of critical bugs still open in Bugzilla about pino; these have been open since before F15 released IIRC and it has been totally unusable (for anyone, as far as I can tell) since then. It's a shame because I was a big user of it (obviously), but I've had to go back using twitter/identi.ca directly; it simply doesn't work. I have given up co-maintainership now. FWIW, I use hotot instead Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: aggregation of gnome tools
On 8 September 2011 05:03, Joachim Backes joachim.bac...@rhrk.uni-kl.de wrote: gnome-tweak-tool Current, high level. gconf-editor Legacy. dconf-editor Current, low level. gconftool-2 Legacy. gnome-session-properties Kinda current. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: aggregation of gnome tools
On Thu, 2011-09-08 at 06:03 +0200, Joachim Backes wrote: In the meanwhile, several tools have been developed for the management of my gnome or gnome3 desktop (gui or not gui based), but each time I need to use them I have to think about what tool to use: gnome-tweak-tool gconf-editor dconf-editor gconftool-2 gnome-session-properties ... It seems there is a tendency for creating more and more such tools. Your list is a missing at least the commandline tools dconf and gsettings. But I don' think things are quite as bleak, and all these tools have their own mission: gconftool-2 / gconf-editor are obsolescent, and will fall by the wayside when the last things are ported away from GConf The dconf commandline tool is very low-level and you should just use the gsettings tool. dconf-editor is the gsettings equivalent of gconf-editor, a 'generic' graphical frontend for all settings. gnome-tweak-tool is a non-generic graphical frontend to a wider set of options than what is exposed in the control-center. It should be the first stop for anybody who feels the itch to 'tweak' his desktop. gnome-session-properties is obsolescent, a leftover from the gnome 2.x control-center. The autostart functionality will eventually be integrated somewhere in gnome-shell or the control-center. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On 8 September 2011 03:13, Andre Robatino robat...@fedoraproject.org wrote: If a packager repeatedly submits +1 for updates which turn out later couldn't possibly have worked in actual testing, then their karma privileges could be revoked. Makes sense to me. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broken dependencies: pino
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am 08.09.2011 13:34, schrieb Rahul Sundaram: On 09/08/2011 04:54 PM, Alex Hudson wrote: I would second this. I've got a number of critical bugs still open in Bugzilla about pino; these have been open since before F15 released IIRC and it has been totally unusable (for anyone, as far as I can tell) since then. It's a shame because I was a big user of it (obviously), but I've had to go back using twitter/identi.ca directly; it simply doesn't work. I have given up co-maintainership now. FWIW, I use hotot instead Rahul Using pino is like riding a dead horse. I moved to heybuddy some time ago. So +1 for orphaning pino. - -- Mit freundlichen Grüßen/Regards Heiko Adams -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREIAAYFAk5orXMACgkQ/zGbOvPHkcLVrwEAgsyayKpqL4AerSfkuslR9b9E wBELdb18MPoxt4prMzgA/1Li9KSeAi/hdFDsGv3R0i0HUeD8zBSzhTjm5Wbaj5Ic =6zNr -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Rawhide and libgee API change
Dear all,
The following packages are affected by the libgee API change in
Rawhide (from 0.6.1 / gee-1.0.pc to 0.7.0 / gee-0.8.pc). Of the two
packages I randomly tested (rygel and pino), merely changing the build
scripts to pick up the new .pc file is not sufficient; as such, I'm
preparing a compatibility package, compat-libgee06 for Rawhide:
https://bugzilla.redhat.com/show_bug.cgi?id=736674
If your package auto-requires the appropriate libgee .so, then no
immediate change is needed once this compatibility package is
reviewed. When updating your package, please check to see if the new
version is compatible with libgee 0.7.x (API level 0.8); if not, the
following snippet might be needed:
%if 0%{?fedora} 16
BuildRequires: compat-libgee06-devel
%else
BuildRequires: libgee-devel
%endif
or, more conveniently, switch to requiring the pkgconfig .pc file (so
you don't need to conditionally require different package names):
BuildRequires: pkgconfig(gee-1.0)
Please switch to BR on pkgconfig(gee-0.8) once your package is ready
for the new API.
Affected packages
=
caribou-0:0.3.5-1.fc16.src
cheese-1:3.0.2-2.fc16.src
fillmore-lombard-0:0.1.0-5.fc15.src
folks-1:0.6.0-5.fc16.src
fontik-0:0.6-4.20100901git8dd5b9fe7.fc15.src
gedit-valencia-0:0.3.0-7.20110701git808152718e3ab.fc16.src
gnome-dvb-daemon-0:0.2.1-1.fc16.src
latexila-0:2.0.8-1.fc16.src
lekhonee-gnome-0:0.11-4.fc15.src
pino-0:0.3-0.3.20101112hg.fc15.src
rygel-0:0.11.3-1.fc16.src
rygel-0:0.12.0-3.fc16.src
tracker-0:0.10.21-2.fc16.src
tracker-0:0.10.24-1.fc16.src
Thanks,
--
Michel Alexandre Salim
Fedora Project Contributor: http://fedoraproject.org/
Email: sali...@fedoraproject.org | GPG key ID: 78884778
Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide and libgee API change
On Thu, Sep 08, 2011 at 14:59:00 +0200, Michel Alexandre Salim sali...@fedoraproject.org wrote: Dear all, The following packages are affected by the libgee API change in Rawhide (from 0.6.1 / gee-1.0.pc to 0.7.0 / gee-0.8.pc). Of the two packages I randomly tested (rygel and pino), merely changing the build scripts to pick up the new .pc file is not sufficient; as such, I'm preparing a compatibility package, compat-libgee06 for Rawhide: Thanks, this extra work by you will help solve some dependency issues in rawhide and give more time for packagers to adjust to the change. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum-builddep (Re: Compiling 32bit on 64bit Fedora)
On Thu, 2011-09-08 at 10:44 +1000, Tony Breeds wrote: Hi All, On a related but different note. How hard would it be to get yum-builddep to take an --arch arg to that we can esily get the 32-bit builddeps on a 64-bit system? Is 'setarch i686 yum-builddep foo' not enough? - 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
[Bug 736608] CVE-2011-2766 perl-FCGI, fcgi: Certain environment variables shared between first and subsequent HTTP requests [fedora-all]
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=736608 Jan Lieskovsky jlies...@redhat.com changed: What|Removed |Added Summary|perl-FCGI, fcgi: Certain|CVE-2011-2766 perl-FCGI, |environment variables |fcgi: Certain environment |shared between first and|variables shared between |subsequent HTTP requests|first and subsequent HTTP |[fedora-all]|requests [fedora-all] -- 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 736604] CVE-2011-2766 perl-FCGI, fcgi: Certain environment variables shared between first and subsequent HTTP requests
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=736604 Jan Lieskovsky jlies...@redhat.com changed: What|Removed |Added Summary|perl-FCGI, fcgi: Certain|CVE-2011-2766 perl-FCGI, |environment variables |fcgi: Certain environment |shared between first and|variables shared between |subsequent HTTP requests|first and subsequent HTTP ||requests Alias||CVE-2011-2766 --- Comment #5 from Jan Lieskovsky jlies...@redhat.com 2011-09-08 09:42:35 EDT --- The CVE identifier of CVE-2011-2766 has been assigned to this issue: http://www.openwall.com/lists/oss-security/2011/09/08/2 -- 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 736609] CVE-2011-2766 perl-FCGI, fcgi: Certain environment variables shared between first and subsequent HTTP requests [epel-6]
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=736609 Jan Lieskovsky jlies...@redhat.com changed: What|Removed |Added Summary|perl-FCGI, fcgi: Certain|CVE-2011-2766 perl-FCGI, |environment variables |fcgi: Certain environment |shared between first and|variables shared between |subsequent HTTP requests|first and subsequent HTTP |[epel-6]|requests [epel-6] -- 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
Self Introduction
Ladies and Gentleman: Seemingly this is the first Self Introduction this month. I am working on a new unison package. I already filed a review request some days ago: https://bugzilla.redhat.com/show_bug.cgi?id=734531 I'm a gentle German student and loyal Linux user for several years. But I never worked in (rpm) packaging before, so please don't be harsh :-) Mainly I am using KDE SC, possibly I want to help on some KDE stuff, too. Hopefully soon I will get a sponsor and become an active member in the community. Thanks, Greg -- You can fool some of the people all of the time, and all of the people some of the time, but you can make a fool of yourself anytime. 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: Did gtkhtml2 package disappear?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/07/2011 03:27 PM, Adam Williamson wrote: On Tue, 2011-09-06 at 15:34 -0400, Daniel J Walsh wrote: On 09/06/2011 01:49 PM, Michael Schwendt wrote: On Tue, 06 Sep 2011 13:00:21 -0400, DJW (Daniel) wrote: I guess what I really need is gnome-python2-gtkhtml2, has this been replaced? What I could find is a request to drop it (it's a gnome-python2-extras subpackage): Disable Python bindings for gtkhtml2 (dead package) https://bugzilla.redhat.com/731307 Well I will drop the lockdown booleans package from policycoreutils-gui. I don't have time to figure out an alternative and I don't believe many/any people use this gui. The standard alternative seems to be webkit, quite a few packages I've noticed have migrated from gtkhtml to webkit. AFAICT, gtkhtml3 doesn't appear to have Python bindings. Thanks I figured out how to replace gtkhtml2 with webkit and have updated the package in Rawhide. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5oyfAACgkQrlYvE4MpobOAhgCdFe/nQajcUk+0s0g73JHLCvVM N8oAnilu9ePOONydWFUpVMDJzBSI86pN =SQ33 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self introduction
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I would like to introduce myself as a potential new package maintainer. I'm currently working at Nikhef in the Netherlands, the national institute for subatomic physics. The group I'm working in has been involved with grid computing since around 2000-2001, through a series of European funded projects. We work close together with the developers of the Globus Toolkit as well as VOMS (both are in Fedora), and recently we've been thinking it would be a good idea to try and include our grid security middleware in the main distribution as well. I've just filed my first review request[1] and more will follow if this goes well. All in all this is about a dozen or so packages. 1. https://bugzilla.redhat.com/show_bug.cgi?id=736717 So this is my very, very short intro (hope it's not too long). Cheers, Dennis van Dok - -- D.H. van Dok :: Software Engineer :: www.nikhef.nl :: www.biggrid.nl Phone +31 20 592 22 28 :: http://www.nikhef.nl/~dennisvd/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5ozaQACgkQIITq5lEwLHclCACeOUn1ULSNw4RrCm7AMfdGWYLs 7+sAoJuogcRp12vTdmusRmDkGAkVzIqV =hxqE -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On 09/07/2011 05:47 PM, Kevin Fenzi wrote: As someone on the other side of this (although not strongly, I could be convinced), I don't think thats my concern at all... * As a maintainer you should only be pushing an update you feel works/fixes something anyhow. Shouldn't that be an implied +1 always from the maintainer? Except that some maintainers build packages and submit them without testing them at all. I submit that we should be encouraging maintainers to test their builds, not discouraging it (which turning off selfkarma would do). If the current rule is based on the fact that we would like 3 people to test besides the maintainer, we could just bump the autokarma thresshold from 3 to 4, and additionally encourage the maintainer to test. * As a maintainer it's easy to have a env that gets out of sync with what a QA or end user would use. Ie, you make 20 iterations of a package to test something, tweak configs to check something, and get it all working, but perhaps your machine is no longer setup the way a fresh install or upgrade of your package would be. Or you tested a version and then changed just 'one little thing' and pushed that and it turned out to break it. It's also fairly easy, if not easier, as a tester to get out of sync with what an end user would use since you're likely to be installing broken stuff on your system which could have residual effects. * Even the best of us would like another pair of eyes to confirm something is really fixed/working. Yes, but we also should encourage the maintainer to confirm this too. Many past bugs could have been avoided had the maintainer tested and noticed that the fix didn't quite work the way it should have. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [389-devel] about Bug 590826 - Reloading database from ldif causes changelog to emit data no longer matches errors
On 09/07/2011 04:29 PM, Rich Megginson wrote: On 09/07/2011 05:06 PM, Noriko Hosoi wrote: Rich Megginson wrote: The problem comes from the method we use to check if the changelog does not match the database in replica_check_for_data_reload(). The RUV in the database contains obsolete elements from replicas that are no longer in use. replica_check_for_data_reload() uses ruv_covers_ruv() to see if all of the max csns in the database ruv are in the changelog maxruv, and vice versa. It fails because the database ruv contains these obsolete elements not found in the changelog maxruv. My question is - why do we care? Isn't it sufficient to check that the replicageneration in the changelog is the same as the replicageneration in the database ruv? The replicageneration is supposed to be the unique identifier of the starting point of the replicated data. If the data is reloaded (e.g. from an ldif not created with db2ldif -r), a new replicageneration will be created, and the data will mismatch. That's right. And the problem is the database RUV never be updated once the data is reloaded from such an ldif file? If the data is reloaded from a plain ldif file, a new RUV and new replicageneration will be created. Then, the server recreates the changelog every time the server is restarted? If the data is reloaded from a plain ldif file, the server will see that the changelog does not match, and will erase the changelog. The reason why this bug is causing the server to recreate the changelog every time it is restarted is because of the extra ruv elements that do not match any of the ruv elements in the changelog max ruv. You mentioned remove them in the proposed warning. Is it the only way to adjust the database RUV? As far as I can tell, the only way to adjust the database RUV is to 1) dump data using db2ldif -r 2) manually edit the file to remove the obsolete RUV elements 3) reload the data using ldif2db Note that, due to /export1/share/ds/ds.git(master)git show e9fa8249|morecommit e9fa82493548d84ac7bd2fa1f857db0023ac800d Author: Nathan Kindernkin...@redhat.com Date: Tue Jan 18 08:29:50 2011 -0800 Bug 543633 - replication problems if supplier is killed under update load ldapmodify to fix the ruv entry will deadlock the server. See https://bugzilla.redhat.com/show_bug.cgi?id=590826 for details. We should definitely fix the deadlock too. Agreed. Or, alternately, leave the check for all of the ruv elements in, but just warn if the database contains ruv elements not in the cl maxruv e.g. something like WARNING: The database RUV contains these elements not present in the changelog max ruv: These elements may be obsolete, in which case you should remove them. If they are not obsolete, you should check those servers to make sure replication is occurring. If the database RUV is not used at all, I think there is no benefit to maintain it... Warning would rather confuse users, wouldn't it? We need to have some way to clean up obsolete ruv elements. I remember this issue coming up on the 389-users list some time ago, but I did not know that it could lead to data loss. I think the warning would be acceptable as long as we had clear procedures for removing the obsolete ruv elements and checking the status of the other replicas. I think that a warning is fine too, though a ruv cleanup method is needed as you mention. --noriko -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: submitters +1ing their own packages
Hi, I think a major problem of the current update policy is, that regular users don't see if there are new package updates in updates-testing, unless they enable it and I doubt many regular users do this. So we might think about spreading the word, when a new update of a software package is available in updates-testing. I don't know how we could achieve this. Perhaps an idea which I had earlier might be to start a page or service where you could like various packages and you'll get notifications if there is something happening with that package. Perhaps https://admin.fedoraproject.org/community/ could be a starting point for this idea. Perhaps we could collect other ideas on this but I think if we make the update process more public we will get more testers for sure. Johannes On 09/08/2011 02:47 AM, Kevin Fenzi wrote: On Wed, 07 Sep 2011 12:15:56 -0700 Adam Williamsonawill...@redhat.com wrote: On Wed, 2011-09-07 at 18:38 +0100, Richard Hughes wrote: On 7 September 2011 01:02, Adam Williamsonawill...@redhat.com wrote: Is this a Bodhi bug? Or does FESCo expect voluntary compliance / case-by-case enforcement of this policy? I'm guilty of this too; when I file an update that's not getting enough karma (after a few weeks) then I give it a spin in a *fresh* VM and test it out like any normal user would do. If this is wrong, consider my wrists slapped, but otherwise I think it makes sense and gets things moving. It's against the current policy. I've argued along the same lines as you in past threads on this list, but I was on the minority side of the debate at the time, it seemed; more people were worried that maintainers would +1 their updates without bothering to test them properly. As someone on the other side of this (although not strongly, I could be convinced), I don't think thats my concern at all... * As a maintainer you should only be pushing an update you feel works/fixes something anyhow. Shouldn't that be an implied +1 always from the maintainer? * As a maintainer it's easy to have a env that gets out of sync with what a QA or end user would use. Ie, you make 20 iterations of a package to test something, tweak configs to check something, and get it all working, but perhaps your machine is no longer setup the way a fresh install or upgrade of your package would be. Or you tested a version and then changed just 'one little thing' and pushed that and it turned out to break it. * Even the best of us would like another pair of eyes to confirm something is really fixed/working. anyhow, just thought I would toss that out there... kevin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum-builddep (Re: Compiling 32bit on 64bit Fedora)
On 09/08/2011 06:27 AM, Adam Jackson wrote: On Thu, 2011-09-08 at 10:44 +1000, Tony Breeds wrote: Hi All, On a related but different note. How hard would it be to get yum-builddep to take an --arch arg to that we can esily get the 32-bit builddeps on a 64-bit system? Is 'setarch i686 yum-builddep foo' not enough? It seems rather nasty to wholly switch repo archs, when what you really want are the multilibs as they exist in the x84_64 repo. For instance, you need glibc-devel.i686, but pkgconfig.x86_64 will do just fine. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 736612] fcgi package contains embedded copy of FCGI module
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=736612 Till Maas opensou...@till.name changed: What|Removed |Added CC||fedora-perl-devel-list@redh ||at.com Component|fcgi|perl-FCGI AssignedTo|opensou...@till.name|cw...@alumni.drew.edu --- Comment #1 from Till Maas opensou...@till.name 2011-09-08 11:52:53 EDT --- fcgi does not use but provide the perl module in a sub package fcgi-perl. Afaics perl-FCGI needs to obsolete fcgi-perl according to these Guidelines: https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages https://fedoraproject.org/wiki/Package_Renaming_Process#Re-review_required Since the perl-FCGI maintainer is the co-maintainer of fcgi wrt. the -perl subpackage, I reassign this bug to perl-FCGI to take care of removing the -perl subpackage from fcgi and addding the proper Provides/Obsoletes etc to perl-FCGI. Also any provenpackager is welcome to perform the required changes to fcgi-perl. Btw. fcgi-perl exists in EPEL 5, too. -- 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 736613] fcgi package contains embedded copy of FCGI module
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=736613 Till Maas opensou...@till.name changed: What|Removed |Added CC||fedora-perl-devel-list@redh ||at.com, iarn...@gmail.com, ||trem...@tremble.org.uk Component|fcgi|perl-FCGI AssignedTo|opensou...@till.name|iarn...@gmail.com --- Comment #1 from Till Maas opensou...@till.name 2011-09-08 11:52:55 EDT --- fcgi does not use but provide the perl module in a sub package fcgi-perl. Afaics perl-FCGI needs to obsolete fcgi-perl according to these Guidelines: https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages https://fedoraproject.org/wiki/Package_Renaming_Process#Re-review_required Since the perl-FCGI maintainer is the co-maintainer of fcgi wrt. the -perl subpackage, I reassign this bug to perl-FCGI to take care of removing the -perl subpackage from fcgi and addding the proper Provides/Obsoletes etc to perl-FCGI. Also any provenpackager is welcome to perform the required changes to fcgi-perl. Btw. fcgi-perl exists in EPEL 5, too. -- 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 736612] fcgi package contains embedded copy of FCGI module
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=736612 Till Maas opensou...@till.name changed: What|Removed |Added Blocks||736759 -- 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 736613] fcgi package contains embedded copy of FCGI module
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=736613 Till Maas opensou...@till.name changed: What|Removed |Added Blocks||736759 -- 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 736759] New: fcgi package contains embedded copy of FCGI module
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: fcgi package contains embedded copy of FCGI module https://bugzilla.redhat.com/show_bug.cgi?id=736759 Summary: fcgi package contains embedded copy of FCGI module Product: Fedora EPEL Version: el5 Platform: Unspecified URL: http://search.cpan.org/dist/FCGI/FCGI.PL OS/Version: Unspecified Status: NEW Severity: medium Priority: medium Component: perl-FCGI AssignedTo: iarn...@gmail.com ReportedBy: opensou...@till.name QAContact: extras...@fedoraproject.org CC: cw...@alumni.drew.edu, iarn...@gmail.com, fedora-perl-devel-l...@redhat.com, jlies...@redhat.com, opensou...@till.name, mmasl...@redhat.com, trem...@tremble.org.uk Depends on: 736612,736613 Classification: Fedora Story Points: --- Clone Of: 736613 Type: --- +++ This bug was initially created as a clone of Bug #736613 +++ +++ This bug was initially created as a clone of Bug #736612 +++ Description of problem: The fcgi package in EPEL-6 contains embedded copy of perl Fast CGI (FCGI) module from CPAN: [1] http://search.cpan.org/dist/FCGI/FCGI.PL But there already is dedicated, system perl-FCGI package, present in EPEL-6. Thus fcgi package should depend on perl-FCGI package, rather than using its own embbedded copy (so in case of security flaw in perl-FCGI, the fcgi package won't need to be updated too). Version-Release number of selected component (if applicable): fcgi-2.4.0-10.el6.src.rpm How reproducible: Always Steps to Reproduce: 1. # pwd ../BUILD/fcgi-2.4.0 2. fcgi-2.4.0]# cd perl/ 3. perl]# ls aclocal.m4 configure echo.PL FCGI.PL Makefile.PL oldinterface.pod remote.PLtypemap ChangeLog configure.in fcgi_config.h.in FCGI.XL MANIFEST README threaded.PL version.pm Actual results: Own copy of CPAN FCGI module is embbeded in fcgi package. Expected results: EPEL-6 fcgi package uses system perl-FCGI package. --- Additional comment from opensource till.name on 2011-09-08 17:52:55 CEST --- fcgi does not use but provide the perl module in a sub package fcgi-perl. Afaics perl-FCGI needs to obsolete fcgi-perl according to these Guidelines: https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages https://fedoraproject.org/wiki/Package_Renaming_Process#Re-review_required Since the perl-FCGI maintainer is the co-maintainer of fcgi wrt. the -perl subpackage, I reassign this bug to perl-FCGI to take care of removing the -perl subpackage from fcgi and addding the proper Provides/Obsoletes etc to perl-FCGI. Also any provenpackager is welcome to perform the required changes to fcgi-perl. Btw. fcgi-perl exists in EPEL 5, too. -- 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: submitters +1ing their own packages
On Sep 7, 2011, at 7:13 PM, Andre Robatino wrote: My opinion is that packagers should be allowed to +1 their own packages after a certain delay (1 week, maybe?) if it hasn't gotten sufficient karma from others by then, and they do actual testing in a non-custom environment (for example, maintain a VM with close to default settings). I think this is an unnecessary delay. Either we trust the packager's testing ability, and his karma is valuable, or we don't and the user doesn't have the ability to add karma (exactly how is /that/ going to be programmed, I have no idea). The week delay doesn't really add anything beneficial here at all. - jlk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Wed, 2011-09-07 at 18:02 -0700, Adam Williamson wrote: On Wed, 2011-09-07 at 18:47 -0600, Kevin Fenzi wrote: * As a maintainer it's easy to have a env that gets out of sync with what a QA or end user would use. Ie, you make 20 iterations of a package to test something, tweak configs to check something, and get it all working, but perhaps your machine is no longer setup the way a fresh install or upgrade of your package would be. Or you tested a version and then changed just 'one little thing' and pushed that and it turned out to break it. Both hughsie and myself, and I think everyone else in favour of maintainer +1s, suggested maintainers should test *in a vanilla environment*, with the actual package they were submitting, before +1ing. +1ing on the basis of a test build or in a dirty environment would be a no-no and could lead to the removal of +1 privileges if repeated. I think we should define what a vanilla environment is then. One could argue that either of the following could be described as vanilla: - A fresh system without any modifications or unstable updates other than that being tested. Pro: makes testing comparable. Contra: You essentially need a special VM for testing which needs to be installed freshly for each tested update. Makes tests comparable ;-), i.e. reduces the amount of different environments in which an update is tested. I do actually want testing to be done on systems that aren't just minimal install plus updates plus a user beside root. - A system in good condition (packages verify well, no dupes) that's used normally, i.e. what you would see being used by normal persons without any fancy hacks in configuration, or worse, non-config files owned by packages. Pro: Easy to test as you don't need to do anything fancy, just yum --enablerepo=updates-testing update pkg; use pkg I'm also guilty of +1ing my updates, but only for Fedora releases where I actually tested the updated package(s). And my system is in good condition as per what I described above, I keep code to be tested in separate hierarchies, usually in subdirectories in my home. Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, Sep 8, 2011 at 12:54 PM, Nils Philippsen n...@redhat.com wrote: On Wed, 2011-09-07 at 18:02 -0700, Adam Williamson wrote: On Wed, 2011-09-07 at 18:47 -0600, Kevin Fenzi wrote: * As a maintainer it's easy to have a env that gets out of sync with what a QA or end user would use. Ie, you make 20 iterations of a package to test something, tweak configs to check something, and get it all working, but perhaps your machine is no longer setup the way a fresh install or upgrade of your package would be. Or you tested a version and then changed just 'one little thing' and pushed that and it turned out to break it. Both hughsie and myself, and I think everyone else in favour of maintainer +1s, suggested maintainers should test *in a vanilla environment*, with the actual package they were submitting, before +1ing. +1ing on the basis of a test build or in a dirty environment would be a no-no and could lead to the removal of +1 privileges if repeated. I think we should define what a vanilla environment is then. One could argue that either of the following could be described as vanilla: - A fresh system without any modifications or unstable updates other than that being tested. Pro: makes testing comparable. Contra: You essentially need a special VM for testing which needs to be installed freshly for each tested update. Makes tests comparable ;-), i.e. reduces the amount of different environments in which an update is tested. I do actually want testing to be done on systems that aren't just minimal install plus updates plus a user beside root. - A system in good condition (packages verify well, no dupes) that's used normally, i.e. what you would see being used by normal persons without any fancy hacks in configuration, or worse, non-config files owned by packages. Pro: Easy to test as you don't need to do anything fancy, just yum --enablerepo=updates-testing update pkg; use pkg Neither one of those definitions addresses the large variety of configurations that are possible with vanilla Fedora packages. E.g. your update might work wonderfully running a default Gnome desktop install, but crash portions of the KDE or XFCE stack (for cases of underlying desktop infrastructure). I don't think a maintainer can realistically replace wide-spread user based testing in a variety of environments. In light of that, we can either accept a maintainer +1 as I tested this as I would use it and it worked (which should be implied by them submitting the update already anyway), or we can disallow it as the policy says. I don't think adding more definitions or steps to the existing policy is really going to improve anything. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Become maintainer of phoronix-test-suite
Hi, I would just announce that I am taking ownership of orphan package phoronix-test-suite. Regards Markus -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, 2011-09-08 at 16:43 +0200, Johannes Lips wrote: Hi, I think a major problem of the current update policy is, that regular users don't see if there are new package updates in updates-testing, unless they enable it and I doubt many regular users do this. So we might think about spreading the word, when a new update of a software package is available in updates-testing. I don't know how we could achieve this. Perhaps an idea which I had earlier might be to start a page or service where you could like various packages and you'll get notifications if there is something happening with that package. Perhaps https://admin.fedoraproject.org/community/ could be a starting point for this idea. Perhaps we could collect other ideas on this but I think if we make the update process more public we will get more testers for sure. Bodhi already automatically notifies any bugs that an update is marked as fixing when that update is pushed into -testing, complete with instructions on how to update to the -testing package, and we (QA) have https://fedoraproject.org/wiki/QA/Join linking to https://fedoraproject.org/wiki/QA/Updates_Testing and https://fedoraproject.org/wiki/Proven_tester . -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, 2011-09-08 at 13:16 -0400, Josh Boyer wrote: - A system in good condition (packages verify well, no dupes) that's used normally, i.e. what you would see being used by normal persons without any fancy hacks in configuration, or worse, non-config files owned by packages. Pro: Easy to test as you don't need to do anything fancy, just yum --enablerepo=updates-testing update pkg; use pkg Neither one of those definitions addresses the large variety of configurations that are possible with vanilla Fedora packages. E.g. your update might work wonderfully running a default Gnome desktop install, but crash portions of the KDE or XFCE stack (for cases of underlying desktop infrastructure). I don't think a maintainer can realistically replace wide-spread user based testing in a variety of environments. In light of that, we can Neither do I, but then, we don't require wide-spread user based testing in a variety of environments: we require, in the strictest case, exactly two tests. either accept a maintainer +1 as I tested this as I would use it and it worked (which should be implied by them submitting the update already anyway), or we can disallow it as the policy says. I don't think adding more definitions or steps to the existing policy is really going to improve anything. I still think there's a significant difference between I made the same change in my private git branch, built it locally, fired it up and it worked (or I made the same change in my private git branch, and it built...) and I installed the package from koji / updates-testing on my reasonably sane Fedora 16 installation and it worked. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, Sep 8, 2011 at 11:54 AM, Nils Philippsen n...@redhat.com wrote: I think we should define what a vanilla environment is then. One could argue that either of the following could be described as vanilla: One thing I done in lieu of a full VM is to test CLI programs under mock. Of course this is a minimal system. I've even tested GUI programs in mock using Xnest. It doesn't give you the native kernel (and probably several other packages) but it also lets you test programs in other releases and 32bit/64bit environments. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Tue, Sep 06, 2011 at 08:46:50PM -0600, Kevin Fenzi wrote: It's not being enforced in bodhi, but it should be: https://fedorahosted.org/bodhi/ticket/277 It is somehow sad that nobody took the time to write a two line patch to fix this 3 year old bug report: https://fedorahosted.org/bodhi/attachment/ticket/277/0001-model.py-Change-karma-from-Submitter-to-0.patch Kind Regards Till pgpCY45xN8DEk.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, 2011-09-08 at 20:16 +0200, Till Maas wrote: It's not being enforced in bodhi, but it should be: https://fedorahosted.org/bodhi/ticket/277 It is somehow sad that nobody took the time to write a two line patch to fix this 3 year old bug report: https://fedorahosted.org/bodhi/attachment/ticket/277/0001-model.py-Change-karma-from-Submitter-to-0.patch Might be worth adding a flash() to inform why the karma wasn't added. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, Sep 08, 2011 at 01:16:50PM -0400, Josh Boyer wrote: I don't think a maintainer can realistically replace wide-spread user based testing in a variety of environments. In light of that, we can either accept a maintainer +1 as I tested this as I would use it and it worked (which should be implied by them submitting the update already anyway), or we can disallow it as the policy says. I don't think adding more definitions or steps to the existing policy is really going to improve anything. Why does pushing an update to testing imply that the maintainer has already used the package and tested it? I cannot find this requirement in the wiki and I do not find it useful. For this requirement every maintainer would need to copy the Fedora infrastructure to distribute updates to his or her testing machines. Also it would delay the possibility for other users to test an update, unless they are forced to use other distribution methods than the updates-testing repository. But then the problem to verify updates emerges, since packages are first signed when they are put into updates-testing. Kind regards Till pgpUPb2i1sxtC.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On 09/08/2011 06:27 PM, Till Maas wrote: On Thu, Sep 08, 2011 at 01:16:50PM -0400, Josh Boyer wrote: I don't think a maintainer can realistically replace wide-spread user based testing in a variety of environments. In light of that, we can either accept a maintainer +1 as I tested this as I would use it and it worked (which should be implied by them submitting the update already anyway), or we can disallow it as the policy says. I don't think adding more definitions or steps to the existing policy is really going to improve anything. Why does pushing an update to testing imply that the maintainer has already used the package and tested it? I cannot find this requirement in the wiki and I do not find it useful. For this requirement every maintainer would need to copy the Fedora infrastructure to distribute updates to his or her testing machines. Also it would delay the possibility for other users to test an update, unless they are forced to use other distribution methods than the updates-testing repository. But then the problem to verify updates emerges, since packages are first signed when they are put into updates-testing. How about tying the requirement to criteria the component belongs to? As in components flagged as base/core/critical might restrict the maintainer from +1 his own component and require more stricter QA oversight while components that are not flag as base/core/critical might not? If doable I would think that was a fair compromise... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, Sep 08, 2011 at 08:30:24PM +0200, Pierre-Yves Chibon wrote: Might be worth adding a flash() to inform why the karma wasn't added. Done: https://fedorahosted.org/bodhi/attachment/ticket/277/0001-model.py-Change-karma-from-Submitter-to-0.2.patch Kind regards Till pgpHXAZilkoL0.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, Sep 08, 2011 at 06:42:56PM +, Jóhann B. Guðmundsson wrote: As in components flagged as base/core/critical might restrict the maintainer from +1 his own component and require more stricter QA oversight while components that are not flag as base/core/critical might not? If a +1 from a maintainer is counted for the stable update threshold than the policy could just be changed to allow maintainers to push updates directly to stable. Because this is what will be possible, only that a lot of stupid interaction with Bodhi will be required. But it would fit the current policy that does not state clearly that any update submitter is allowed to push a non critpath update to stable as soon as the update received at least one +1 from anyone. Kind regards Till pgppT3x7WMkGg.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, 2011-09-08 at 18:42 +, Jóhann B. Guðmundsson wrote: How about tying the requirement to criteria the component belongs to? As in components flagged as base/core/critical might restrict the maintainer from +1 his own component and require more stricter QA oversight while components that are not flag as base/core/critical might not? If doable I would think that was a fair compromise... I think that's again in the 'makes theoretical sense but not practical sense' category. The updates we have the most trouble with are critpath updates on N-1 (F14 at present), precisely *because* of the relatively tight karma requirements. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Wed, 2011-09-07 at 18:38 +0100, Richard Hughes wrote: On 7 September 2011 01:02, Adam Williamson awill...@redhat.com wrote: Is this a Bodhi bug? Or does FESCo expect voluntary compliance / case-by-case enforcement of this policy? I'm guilty of this too; when I file an update that's not getting enough karma (after a few weeks) then I give it a spin in a *fresh* VM and test it out like any normal user would do. If this is wrong, consider my wrists slapped, but otherwise I think it makes sense and gets things moving. FWIW, I wasn't aware of the policy of not +1-ing my own updates. My approach here (for python/python3) has been that if the patch looks sane and passes the selftest suite, then I'll apply it and create the update. I've then been doing additional testing e.g. dogfooding the package for a while. If I'm happy with my subsequent testing, then I'll +1 my own update, on the grounds that I've been viewing the change from a testing perspective, rather than just from a development perspective. If not, I'll -1 it. I don't feel guilty about doing this additional testing and reporting. [See also http://dmalcolm.livejournal.com/5013.html for more notes on ways of improving QA of Bodhi candidate updates] Hope this is helpful Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, 2011-09-08 at 20:59 +0200, Till Maas wrote: On Thu, Sep 08, 2011 at 06:42:56PM +, Jóhann B. Guðmundsson wrote: As in components flagged as base/core/critical might restrict the maintainer from +1 his own component and require more stricter QA oversight while components that are not flag as base/core/critical might not? If a +1 from a maintainer is counted for the stable update threshold than the policy could just be changed to allow maintainers to push updates directly to stable. Because this is what will be possible, only that a lot of stupid interaction with Bodhi will be required. But it would fit the current policy that does not state clearly that any update submitter is allowed to push a non critpath update to stable as soon as the update received at least one +1 from anyone. We're going round in circles again, as I know I've written this at least twice in the previous threads on the topic, but: no. What Bodhi adds to the process is accountability, an audit trail, and an easy way to manage privileges. If we keep the Bodhi thresholds but allow maintainers to +1 their own updates, it makes it very very easy to look at a hyopthetical future problematic update and say 'look, you +1ed this update which was clearly broken, it went out, and caused pain to users: your +1 privileges are revoked', and actually do that, without affecting other maintainers who are following the rules. If we just let everyone push straight to stable, we lose that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, Sep 08, 2011 at 12:34:25PM -0700, Adam Williamson wrote: On Thu, 2011-09-08 at 20:59 +0200, Till Maas wrote: On Thu, Sep 08, 2011 at 06:42:56PM +, Jóhann B. Guðmundsson wrote: As in components flagged as base/core/critical might restrict the maintainer from +1 his own component and require more stricter QA oversight while components that are not flag as base/core/critical might not? If a +1 from a maintainer is counted for the stable update threshold than the policy could just be changed to allow maintainers to push updates directly to stable. Because this is what will be possible, only that a lot of stupid interaction with Bodhi will be required. But it would fit the current policy that does not state clearly that any update submitter is allowed to push a non critpath update to stable as soon as the update received at least one +1 from anyone. We're going round in circles again, as I know I've written this at least twice in the previous threads on the topic, but: no. What Bodhi adds to the process is accountability, an audit trail, and an easy way to manage privileges. If we keep the Bodhi thresholds but allow maintainers to +1 their own updates, it makes it very very easy to look at a hyopthetical future problematic update and say 'look, you +1ed this update which was clearly broken, it went out, and caused pain to users: your +1 privileges are revoked', and actually do that, without affecting other maintainers who are following the rules. If we just let everyone push straight to stable, we lose that. It is easy to go in circles if everyone is using +1 with a different meaning. If you read carefully what I quoted you will notice that I quoted a proposal to allow +1 comments only from submitters for non critpath updates. If we use your meaning of +1 comments from submitters this means that the proposal is to add an audit trail only for non critpath updates. I am pretty sure that you do not mean this. So your proposal is probably to allow +1 comments from submitters, but do not use it to calculate the karma value of an update. But this is a technical detail. Even with allowing a direct push to stable instead of using a complex karma calculation formula you will have an audit trail in Bodhi, because Bodhi creates a comment about this as well. And you can as well revoke the direct-push-to-stabe direct-push-to-stabe feature from misbehaving maintainers. Kind regards Till pgpGL1PRC2yCx.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, Sep 08, 2011 at 03:33:33PM -0400, David Malcolm wrote: package for a while. If I'm happy with my subsequent testing, then I'll +1 my own update, on the grounds that I've been viewing the change from a testing perspective, rather than just from a development perspective. If not, I'll -1 it. ^^^ Why won't you unpush your update if it fails your testing? Regards Till pgpogs0bGMBF4.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review swap: GNU parallel
Hi, since there seem to be no further objections, I would like to offer a review swap for GNU parallel. https://bugzilla.redhat.com/show_bug.cgi?id=675495 There was some debate on how this could be packaged for Fedora, but in the end we found a way everybody could agree on (at least no one disagreed). The package itself is rather simple and shouldn't take much time to review. Best regards, Golo Fuchert -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, 2011-09-08 at 22:18 +0200, Till Maas wrote: It is easy to go in circles if everyone is using +1 with a different meaning. If you read carefully what I quoted you will notice that I quoted a proposal to allow +1 comments only from submitters for non critpath updates. If we use your meaning of +1 comments from submitters this means that the proposal is to add an audit trail only for non critpath updates. I am pretty sure that you do not mean this. So your proposal is probably to allow +1 comments from submitters, but do not use it to calculate the karma value of an update. But this is a technical detail. Even with allowing a direct push to stable instead of using a complex karma calculation formula you will have an audit trail in Bodhi, because Bodhi creates a comment about this as well. And you can as well revoke the direct-push-to-stabe direct-push-to-stabe feature from misbehaving maintainers. That's true, though we still lose the wrinkle that an explicit +1 from a maintainer is a clear statement that I have actually tested this code. A direct submission to stable is not such a statement, though we could write up the policy in such a way that it was assumed to be one. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: submitters +1ing their own packages
On Thu, 2011-09-08 at 22:21 +0200, Till Maas wrote: On Thu, Sep 08, 2011 at 03:33:33PM -0400, David Malcolm wrote: package for a while. If I'm happy with my subsequent testing, then I'll +1 my own update, on the grounds that I've been viewing the change from a testing perspective, rather than just from a development perspective. If not, I'll -1 it. ^^^ Why won't you unpush your update if it fails your testing? Good point, but hasn't happened so far, IIRC -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Kudos to Tom Spot Callaway
On behalf of the systemd convertion team Just wanted to say thanks to Tom Spot Callaway he's been on fire today packaging submitted unit files and shipping them. Your work did not go unoticed! JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Become maintainer of phoronix-test-suite
On Thu 08 Sep 2011 10:31:46 AM PDT, Markus Mayer wrote: Hi, I would just announce that I am taking ownership of orphan package phoronix-test-suite. Regards Markus Yay! About time. No more rebuilding for source. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 16 Beta Test Compose 2 (TC2) Available Now!
As per the Fedora 16 schedule [1], Fedora 16 Beta Test Compose 2 (TC2) is now available for testing. Please see the following pages for download links and testing instructions. In general, official live images arrive a few hours after the install images: see the links below for updates. When they appear, the download directory should be the same as that for install images, except with the trailing /Fedora/ replaced by /Live/. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Security Lab: https://fedoraproject.org/wiki/Test_Results:Current_Security_Lab_Test Ideally, all Alpha and Beta priority test cases for Installation [2], Base [3], Desktop [4], and Security Lab [5] should pass in order to meet the Beta Release Criteria [6]. Help is available on #fedora-qa on irc.freenode.net [7], or on the test list [8]. Create F16 Beta Test Compose (TC) images: live and traditional install https://fedorahosted.org/rel-eng/ticket/4902 F16 Beta Blocker tracker bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=713564 F16 Beta Nice-To-Have tracker bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=713565 [1] http://rbergero.fedorapeople.org/schedules/f-16/f-16-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Base_validation_testing [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [5] https://fedoraproject.org/wiki/QA:Security_Lab_validation_testing [6] https://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria [7] irc://irc.freenode.net/fedora-qa [8] https://admin.fedoraproject.org/mailman/listinfo/test signature.asc Description: OpenPGP digital signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2011-09-09 @ 17:00 UTC - F16 Beta Blocker Bug Review #3
# F16 Beta Blocker Review meeting #3 # Date: 2011-09-09 # Time: 17:00 UTC [1] (13:00 EDT, 10:00 PDT, 10:00 MST) # Location: #fedora-bugzappers on irc.freenode.net The third installment of the irresistible beta blocker bug review meeting series will be this Friday at 17:00 UTC in #fedora-bugzappers. We'll be running through the beta blockers and nice-to-haves. An updated list of blocker bugs is available at https://fedoraproject.org/wiki/Current_Release_Blockers. We'll be reviewing the bugs to determine ... 1. Whether they meet the Beta release criteria [2] and should stay on the list 2. Whether they are getting the attention they need For guidance on Blocker and Nice-to-have (NTH) bugs, refer to https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and https://fedoraproject.org/wiki/QA:SOP_nth_bug_process For the blocker review meeting protocol, see https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting . Thanks, Tim [1] https://fedoraproject.org/wiki/Infrastructure/UTCHowto [2] https://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria signature.asc Description: PGP signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 734420] perl-DateTime-TimeZone-1.36 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=734420 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-DateTime-0.70-2.fc14 Resolution||ERRATA Last Closed||2011-09-08 02:56:17 -- 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 712699] CVE-2011-2201 perl-Data-FormValidator: Reports invalid field as valid when untaint_all_constraints used [fedora-all]
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=712699 --- Comment #6 from Fedora Update System upda...@fedoraproject.org 2011-09-08 02:59:41 EDT --- perl-Data-FormValidator-4.66-6.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 712699] CVE-2011-2201 perl-Data-FormValidator: Reports invalid field as valid when untaint_all_constraints used [fedora-all]
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=712699 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-Data-FormValidator-4.6 |perl-Data-FormValidator-4.6 |6-6.fc16|6-6.fc15 -- 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 712699] CVE-2011-2201 perl-Data-FormValidator: Reports invalid field as valid when untaint_all_constraints used [fedora-all]
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=712699 --- Comment #7 from Fedora Update System upda...@fedoraproject.org 2011-09-08 03:00:15 EDT --- perl-Data-FormValidator-4.66-6.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 734420] perl-DateTime-TimeZone-1.36 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=734420 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-DateTime-0.70-2.fc14 |perl-DateTime-0.70-2.fc15 -- 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 734420] perl-DateTime-TimeZone-1.36 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=734420 --- Comment #6 from Fedora Update System upda...@fedoraproject.org 2011-09-08 03:06:22 EDT --- perl-DateTime-0.70-2.fc15, perl-DateTime-Locale-0.45-1.fc15, perl-DateTime-TimeZone-1.36-1.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 712886] perl-App-Asciio keyboard shortcuts don't work and the file saved in a binary
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=712886 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Gtk2-1.224-2.fc15 Resolution||ERRATA Last Closed||2011-09-08 03:09:28 -- 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 736604] perl-FCGI, fcgi: Certain environment variables shared between first and subsequent HTTP requests
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=736604 --- Comment #1 from Jan Lieskovsky jlies...@redhat.com 2011-09-08 04:37:08 EDT --- This issue affects the versions of the perl-FCGI package, as shipped with Fedora release of 14 and 15. Please schedule an update once final upstream patch known. -- This issue affects the version of the perl-FCGI package, as present within EPEL-6 repository. Please schedule an update once final upstream patch known. -- This issue did NOT affect the versions of the fcgi package, as shipped with Fedora release of 14 and 15. Though the fcgi package in those releases contains embedded copy of the perl-FCGI package, the code in question does not contain the regression in FCGI's accept() routine yet. -- This issue did NOT affect the versions of the fcgi package, as present within EPEL-5 and EPEL-6 repositories. Though the fcgi package in those releases contains embedded copy of the perl-FCGI package, the code in question does not contain the regression in FCGI's accept() routine yet. -- 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 736604] perl-FCGI, fcgi: Certain environment variables shared between first and subsequent HTTP requests
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=736604 --- Comment #2 from Jan Lieskovsky jlies...@redhat.com 2011-09-08 04:39:02 EDT --- CVE Request: [2] http://www.openwall.com/lists/oss-security/2011/09/08/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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 736604] perl-FCGI, fcgi: Certain environment variables shared between first and subsequent HTTP requests
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=736604 Jan Lieskovsky jlies...@redhat.com changed: What|Removed |Added Depends on||736608 Depends on||736609 --- Comment #3 from Jan Lieskovsky jlies...@redhat.com 2011-09-08 04:40:09 EDT --- Created perl-FCGI tracking bugs for this issue Affects: fedora-all [bug 736608] Affects: epel-6 [bug 736609] -- 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 736608] New: perl-FCGI, fcgi: Certain environment variables shared between first and subsequent HTTP requests [fedora-all]
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-FCGI, fcgi: Certain environment variables shared between first and subsequent HTTP requests [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=736608 Summary: perl-FCGI, fcgi: Certain environment variables shared between first and subsequent HTTP requests [fedora-all] Product: Fedora Version: 15 Platform: All OS/Version: Linux Status: NEW Keywords: Security, SecurityTracking Severity: medium Priority: medium Component: perl-FCGI AssignedTo: cw...@alumni.drew.edu ReportedBy: jlies...@redhat.com QAContact: extras...@fedoraproject.org CC: cw...@alumni.drew.edu, fedora-perl-devel-l...@redhat.com Blocks: 736604 Classification: Fedora Story Points: --- Type: --- This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected Fedora versions. For comments that are specific to the vulnerability please use bugs filed against Security Response product referenced in the Blocks field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When creating a Bodhi update request, please include the bug IDs of the respective parent bugs filed against the Security Response product. Please mention CVE ids in the RPM changelog when available. Bodhi update submission link: https://admin.fedoraproject.org/updates/new/?type_=securitybugs=736604 Please note: this issue affects multiple supported versions of Fedora. Only one tracking bug has been filed; please only close it when all affected versions are fixed. [bug automatically created by: add-tracking-bugs] -- 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 736635] New: perl-DBD-CSV-0.33 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-DBD-CSV-0.33 is available https://bugzilla.redhat.com/show_bug.cgi?id=736635 Summary: perl-DBD-CSV-0.33 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-DBD-CSV 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 Story Points: --- Type: --- Latest upstream release: 0.33 Current version in Fedora Rawhide: 0.31 URL: http://search.cpan.org/dist/DBD-CSV/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy 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 736636] New: perl-Text-CSV_XS-0.85 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-Text-CSV_XS-0.85 is available https://bugzilla.redhat.com/show_bug.cgi?id=736636 Summary: perl-Text-CSV_XS-0.85 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Text-CSV_XS 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 Story Points: --- Type: --- Latest upstream release: 0.85 Current version in Fedora Rawhide: 0.83a URL: http://search.cpan.org/dist/Text-CSV_XS/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy 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 736635] perl-DBD-CSV-0.33 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=736635 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||psab...@redhat.com AssignedTo|mmasl...@redhat.com |psab...@redhat.com -- 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 736636] perl-Text-CSV_XS-0.85 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=736636 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||psab...@redhat.com AssignedTo|mmasl...@redhat.com |psab...@redhat.com -- 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 Text-CSV_XS-0.85.tgz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Text-CSV_XS: 876e4017ef95eaa5740730fef14e976f Text-CSV_XS-0.85.tgz -- 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-Text-CSV_XS] 0.85 bump
commit dc1f981a2d3b530236a1b9afb37c0c21325314fd
Author: Petr Sabata con...@redhat.com
Date: Thu Sep 8 13:04:46 2011 +0200
0.85 bump
.gitignore|1 +
perl-Text-CSV_XS.spec |6 --
sources |2 +-
3 files changed, 6 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 0dc9acf..e82dc2e 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,3 +8,4 @@ Text-CSV_XS-0.72.tgz
/Text-CSV_XS-0.81.tgz
/Text-CSV_XS-0.82.tgz
/Text-CSV_XS-0.83a.tgz
+/Text-CSV_XS-0.85.tgz
diff --git a/perl-Text-CSV_XS.spec b/perl-Text-CSV_XS.spec
index 749e045..272bf5a 100644
--- a/perl-Text-CSV_XS.spec
+++ b/perl-Text-CSV_XS.spec
@@ -1,12 +1,11 @@
Name: perl-Text-CSV_XS
-Version:0.83a
+Version:0.85
Release:1%{?dist}
Summary:Comma-separated values manipulation routines
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Text-CSV_XS/
Source0:
http://www.cpan.org/authors/id/H/HM/HMBRAND/Text-CSV_XS-%{version}.tgz
-
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
BuildRequires: perl(ExtUtils::MakeMaker)
@@ -63,6 +62,9 @@ make test
%changelog
+* Thu Sep 08 2011 Petr Sabata con...@redhat.com - 0.85-1
+- 0.85 bump
+
* Mon Aug 08 2011 Petr Sabata con...@redhat.com - 0.83a-1
- 0.83a bump
diff --git a/sources b/sources
index 8fcba5b..3b6f10b 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f9e6db6e4221d67658a26484d9214ecc Text-CSV_XS-0.83a.tgz
+876e4017ef95eaa5740730fef14e976f Text-CSV_XS-0.85.tgz
--
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
Broken dependencies: perl-Sub-Exporter-ForMethods
perl-Sub-Exporter-ForMethods has broken dependencies in the F-16 tree: On x86_64: perl-Sub-Exporter-ForMethods-0.100050-2.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) On i386: perl-Sub-Exporter-ForMethods-0.100050-2.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-NOCpulse-Gritch
perl-NOCpulse-Gritch has broken dependencies in the F-16 tree: On x86_64: perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-HTML-FormatText-WithLinks-AndTables
perl-HTML-FormatText-WithLinks-AndTables has broken dependencies in the F-16 tree: On x86_64: perl-HTML-FormatText-WithLinks-AndTables-0.01-2.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) On i386: perl-HTML-FormatText-WithLinks-AndTables-0.01-2.fc15.noarch requires perl(:MODULE_COMPAT_5.12.4) Please resolve this as soon as possible. -- 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-Text-CSV_XS] Correct the setup macro
commit 4715db5778a2650d114bb1f8a2d046e19ebabade
Author: Petr Sabata con...@redhat.com
Date: Thu Sep 8 13:11:42 2011 +0200
Correct the setup macro
perl-Text-CSV_XS.spec |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
---
diff --git a/perl-Text-CSV_XS.spec b/perl-Text-CSV_XS.spec
index 272bf5a..a7ce2a3 100644
--- a/perl-Text-CSV_XS.spec
+++ b/perl-Text-CSV_XS.spec
@@ -24,8 +24,7 @@ fields into a CSV string and parse a CSV string into fields.
%prep
-# 0.83a is a special case; change back to %{version} for next release
-%setup -q -n Text-CSV_XS-0.83
+%setup -q -n Text-CSV_XS-%{version}
iconv -f latin1 -t utf8 ChangeLog ChangeLog.utf8 mv ChangeLog.utf8
ChangeLog
chmod -c a-x examples/*
# Upstream does this on purpose (2011-03-23):
--
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
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-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- 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 736608] CVE-2011-2766 perl-FCGI, fcgi: Certain environment variables shared between first and subsequent HTTP requests [fedora-all]
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=736608 Iain Arnell iarn...@gmail.com changed: What|Removed |Added CC||iarn...@gmail.com AssignedTo|cw...@alumni.drew.edu |iarn...@gmail.com -- 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 736604] CVE-2011-2766 perl-FCGI, fcgi: Certain environment variables shared between first and subsequent HTTP requests
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=736604 Iain Arnell iarn...@gmail.com changed: What|Removed |Added External Bug ID||CPAN 68380 -- 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 736612] fcgi package contains embedded copy of FCGI module
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=736612 Iain Arnell iarn...@gmail.com changed: What|Removed |Added CC||iarn...@gmail.com AssignedTo|cw...@alumni.drew.edu |iarn...@gmail.com -- 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 736759] fcgi package contains embedded copy of FCGI module
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=736759 Iain Arnell iarn...@gmail.com changed: What|Removed |Added Status|NEW |CLOSED Resolution||NOTABUG Last Closed||2011-09-08 23:26:27 --- Comment #1 from Iain Arnell iarn...@gmail.com 2011-09-08 23:26:27 EDT --- But perl-FCGI does not exist in EL5, so there's no library duplication. It's okay for fcgi-perl to provide Perl's FCGI module here. -- 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 736612] fcgi package contains embedded copy of FCGI module
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=736612 --- Comment #2 from Fedora Update System upda...@fedoraproject.org 2011-09-08 23:57:16 EDT --- fcgi-2.4.0-17.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/fcgi-2.4.0-17.fc16 -- 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 736612] fcgi package contains embedded copy of FCGI module
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=736612 --- Comment #3 from Iain Arnell iarn...@gmail.com 2011-09-08 23:59:16 EDT --- I've removed the perl sub-package in rawhide and f16. Since fcgi-perl is already obsoleted by perl-FCGI in all branches, I don't think it's necessary to push this update to the stable branches. -- 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 736759] fcgi package contains embedded copy of FCGI module
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=736759 Bug 736759 depends on bug 736613, which changed state. Bug 736613 Summary: fcgi package contains embedded copy of FCGI module https://bugzilla.redhat.com/show_bug.cgi?id=736613 What|Old Value |New Value Resolution||WONTFIX Status|NEW |CLOSED -- 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 736613] fcgi package contains embedded copy of FCGI module
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=736613 Iain Arnell iarn...@gmail.com changed: What|Removed |Added Status|NEW |CLOSED Resolution||WONTFIX Last Closed||2011-09-09 00:07:26 --- Comment #2 from Iain Arnell iarn...@gmail.com 2011-09-09 00:07:26 EDT --- I've cherry-picked the fix for bug 736612 to el6 branch (and fixed the license tag). Since perl-FCGI already obsoletes fcgi-perl package, I don't think it's necessary to push an update for this. -- 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 736613] fcgi package contains embedded copy of FCGI module
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=736613 Bug 736613 depends on bug 736612, which changed state. Bug 736612 Summary: fcgi package contains embedded copy of FCGI module https://bugzilla.redhat.com/show_bug.cgi?id=736612 What|Old Value |New Value Resolution||NEXTRELEASE Status|MODIFIED|CLOSED -- 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 736612] fcgi package contains embedded copy of FCGI module
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=736612 Iain Arnell iarn...@gmail.com changed: What|Removed |Added Status|MODIFIED|CLOSED Resolution||NEXTRELEASE Last Closed||2011-09-09 00:09:10 -- 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
