Re: Orphaned: hddtemp, vdradmin-am
On Wed, Jan 29, 2014 at 6:11 AM, Kevin Kofler kevin.kof...@chello.at wrote: (gkrellm and ksensors should probably have that Requires too!) Don't know about ksensors, but gkrellm works perfectly fine without hddtemp so a hard dependency should not be added. Besides the dependency wouldn't even be enough for monitoring hdd temperatures; the hddtemp service needs to be explicitly enabled anyway. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Wednesday's FESCo Meeting (2014-01-29)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2014-01-29 18:00 UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1197 Procedure for suggesting/approving different Products and/or WGs? https://fedorahosted.org/fesco/ticket/1197 #topic #956 Need to audit packageset for bundling of libiberty https://fedorahosted.org/fesco/ticket/956 #topic #1117 Generalize policy about privilege escalation and Administrator user accounts https://fedorahosted.org/fesco/ticket/1117 #topic #1226 Workstation PRD for approval https://fedorahosted.org/fesco/ticket/1226 = New business = None this week = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLo/ikACgkQeiVVYja6o6PcxwCfdVwb8vUXBmZ8zc6tuoD261v+ gxYAoJHvj5jCSRM/1MXzf2vuQ0DukUtF =G8H+ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On Tue, Jan 28, 2014 at 06:15:49PM -0800, Adam Williamson wrote: Just to wax philosophical for a minute: I think there's a lot of value in building boring stuff that works well, and I might be weird, but I [snip eloquent defense of the virtues of boring basic distro work] This doesn't mean I'm against doing Big Exciting New Things in general or Fedora.next in particular, but I do want to stand up for the value of just keeping your head down (hah, I know, Adam, practice what you preach) and doing good, dull engineering work. With your pocket protector firmly in place. This is all very convincing. But you also sent me a convincing message the other week about Fedora's place on the innovation curve and, basically, the difficulty of doing all that good dull work while being innovative. Stop convincing me in different directions -- my head will fall off! Or, in seriousness, because I don't think they're *necessarily* in direct conflict, what do you think we should do about all of the above? Our mission and branding, including our foundations, tend to steer away from the dull and towards new shiny. In fact, whenever we do something that could be characterized as head-down plodding forward progress instead of a bold leap, we hear *quite a bit* of sarcasm about the four foundations in the online chatter. So, should we look at reconciling that in some way? Part of *my* idea for Fedora.next was that the base circle could focus more on this careful and non-thrilling engineering work while the outer rings could do the big-exciting things at the same time. (Or even have *some* parts of the outer rings working on big-exciting, while other parts work on _even more solid_.) *goes and gets coffee. not able to quite express what I mean. hope you understand anyway* -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
On 01/29/2014 02:57 PM, Matthew Miller wrote: On Tue, Jan 28, 2014 at 06:15:49PM -0800, Adam Williamson wrote: Just to wax philosophical for a minute: I think there's a lot of value in building boring stuff that works well, and I might be weird, but I [snip eloquent defense of the virtues of boring basic distro work] This doesn't mean I'm against doing Big Exciting New Things in general or Fedora.next in particular, but I do want to stand up for the value of just keeping your head down (hah, I know, Adam, practice what you preach) and doing good, dull engineering work. With your pocket protector firmly in place. This is all very convincing. But you also sent me a convincing message the other week about Fedora's place on the innovation curve and, basically, the difficulty of doing all that good dull work while being innovative. Stop convincing me in different directions -- my head will fall off! Or, in seriousness, because I don't think they're *necessarily* in direct conflict, what do you think we should do about all of the above? Our mission and branding, including our foundations, tend to steer away from the dull and towards new shiny. In fact, whenever we do something that could be characterized as head-down plodding forward progress instead of a bold leap, we hear *quite a bit* of sarcasm about the four foundations in the online chatter. So, should we look at reconciling that in some way? Part of *my* idea for Fedora.next was that the base circle could focus more on this careful and non-thrilling engineering work while the outer rings could do the big-exciting things at the same time. (Or even have *some* parts of the outer rings working on big-exciting, while other parts work on _even more solid_.) *goes and gets coffee. not able to quite express what I mean. hope you understand anyway* Now I'm confused too. Env and Stack WG should do new and cool things, but most of us are doing the boring work (databases and languages maintenance). I believe we can do the boring stuff even in Fedora.next. Cool stuff will be somewhere above the boring. Marcela -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1058723] FTBFS: perl-DBD-Pg-2.19.3-5.fc21: tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1058723 --- Comment #1 from Petr Pisar ppi...@redhat.com --- All Fedoras are affected. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=gLYiYFuvgXa=cc_unsubscribe -- 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
a questionable dependency chain
I've switched to rawhide yesterday, and discovered that vinagre now forces rsyslog onto my system. That's not great. The dependency chain goes something like this: vinagre - spice - libcacard - ... glusterfs ... - rsyslog-mmjsonparse - rsyslog I think there's at least two questionable links in this chain: - why does libcacard need glusterfs ? - why does glusterfs need rsyslog ? Can we get one or both of these cut, maybe ? Matthias -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: a questionable dependency chain
On Wed, Jan 29, 2014 at 09:21:22AM -0500, Matthias Clasen wrote: I've switched to rawhide yesterday, and discovered that vinagre now forces rsyslog onto my system. That's not great. The dependency chain goes something like this: vinagre - spice - libcacard - ... glusterfs ... - rsyslog-mmjsonparse - rsyslog I think there's at least two questionable links in this chain: - why does libcacard need glusterfs ? libcacard is built as part of QEMU source code. QEMU needs glusterfs but libcacard should not need it. I'd guess that QEMU's hand-crafted makefiles have fubar'd the linker args, adding '-lglusterfs' to the libcacard build, despite it not being used. Best file a bug against QEMU for this, as it should definitely be fixed. - why does glusterfs need rsyslog ? Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Drawing lessons from fatal SELinux bug #1054350
On Tue, Jan 28, 2014 at 06:42:52PM -0800, Adam Williamson wrote: Using the wiki as a TCMS is of course a gross hack, but it comes with a surprising number of advantages - see Makes sense to me. I'm actually not opposed to using the wiki in this way, but I think it highlights the need for _something else_ to be our short-quick-easy documentation solution. I wonder if it would help both of these things to move the test plans to live in package git (right next to the future taskotron scripts? Well, what would they look like, and how would you read them? What we're They would be short text files. Possibly markdown. Something simple, though. I hear you on the downside of having to have commit rights to the package in order to work on test plans in git. That applies to the taskotron tests too, though, doesn't it? Maybe we could use git submodules for this. (Where each fedora package has a submodule consisting of its tests, both automated and test plans.) But like I said I'm not really opposed to continuing to use the wiki. Maybe we just need an awareness campaign. (Some text in the bodhi.template from fedpkg update would be a good start, I think. And on the New Update page in the bodhi web interface. And definitely in https://fedoraproject.org/wiki/Package_update_HOWTO -- I'll do that, as soon as I have that coffee I didn't have when I said I was going to at the end of the last message I sent.) And, while clearly helpful, I think it suffers from a little bit of tl;dr. Maybe we could embed summaries of each right into the Bodhi page? I'm not quite clear what you mean here - what's tl? Summaries of what? I mean the links to the test cases shown in bodhi. In the context of trying to get better feedback in bodhi, it would be nice if there were a summary of each test right in the bodhi screen (not just its title). Then, there could be a little dropdown to choose between didn't try this aspect, looked at the thing in the summary; seemed okay and actually went through this full test case. That would make it easy for people to be descriptive and honest about what they actually tried. Don't get me wrong -- the way it works currently is pretty awesome and just making that more used would be great. The other thing is that I think that in addition to the per-package test cases, it would be good to encourage updates to include at least a line about what is of particular interest to test in _this_ release. Sometimes, that's the same as the update Details, but not always. It would indeed be nice if maintainers did this, though of course it's not relevant to the case we're currently considering (as the broken content in the update was a mistake and the maintainer didn't even know it was there, he'd hardly have been likely to highlight it for testing). Yes, in this case the general test plans would have covered it. Hopefully. :) -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: a questionable dependency chain
Hey, On Wed, Jan 29, 2014 at 09:21:22AM -0500, Matthias Clasen wrote: I've switched to rawhide yesterday, and discovered that vinagre now forces rsyslog onto my system. That's not great. The dependency chain goes something like this: vinagre - spice - libcacard - ... glusterfs ... - rsyslog-mmjsonparse - rsyslog I think there's at least two questionable links in this chain: - why does libcacard need glusterfs ? Looking at nm output for libcacard.so, I did not see symbols that were obviously related to glusterfs there. However, at build time, libcacard ld command line gets a lot of -lxx, including glusterfs libraries. libcacard is a sub-package of qemu, so I suspect what's happening is it gets linked with all the libraries qemu needs. This patch seems to help there and get rid of the extra libraries in ldd output (did not try an rpm build to check the deps there). diff --git a/libcacard/Makefile b/libcacard/Makefile index 47827a0..9fa297c 100644 --- a/libcacard/Makefile +++ b/libcacard/Makefile @@ -24,7 +24,7 @@ vscclient$(EXESUF): libcacard/vscclient.o libcacard.la libcacard.la: LDFLAGS += -rpath $(libdir) -no-undefined \ -export-syms $(SRC_PATH)/libcacard/libcacard.syms -libcacard.la: LIBS += $(libcacard_libs) +libcacard.la: LIBS = $(libcacard_libs) libcacard.la: $(libcacard-lobj-y) $(call LINK,$^) Christophe pgp3mWkICkw_6.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Schedule for Wednesday's FESCo Meeting (2014-01-29)
On Wed, Jan 29, 2014 at 08:12:09AM -0500, Stephen Gallagher wrote: Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. I'll be traveling and miss this meeting, by the way. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-DBD-Pg] Correct changelog
commit c83f650e5c7251cafe3734fa68bd562b214660db Author: Petr Písař ppi...@redhat.com Date: Wed Jan 29 15:26:10 2014 +0100 Correct changelog perl-DBD-Pg.spec |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) --- diff --git a/perl-DBD-Pg.spec b/perl-DBD-Pg.spec index e3431da..649fc81 100644 --- a/perl-DBD-Pg.spec +++ b/perl-DBD-Pg.spec @@ -182,7 +182,7 @@ make test * Fri Oct 31 2008 Marcela Maslanova mmasl...@redhat.com - 2.11.2-1 - update to 2.11.2 -* Mon Aug 29 2008 Marcela Maslanova mmasl...@redhat.com - 2.10.0-1 +* Fri Aug 29 2008 Marcela Maslanova mmasl...@redhat.com - 2.10.0-1 - update to 2.10.0 * Mon Aug 25 2008 Marcela Maslanova mmasl...@redhat.com - 2.9.2-1 @@ -217,7 +217,7 @@ make test * Tue Jul 17 2007 Robin Norwood rnorw...@redhat.com - 1.49-4 - Fix summary -* Tue Dec 06 2006 Robin Norwood rnorw...@redhat.com - 1.49-3 +* Tue Dec 05 2006 Robin Norwood rnorw...@redhat.com - 1.49-3 - rebuild for new version of postgres. * Wed Jul 12 2006 Jesse Keating jkeat...@redhat.com - 1.49-2 -- 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-Pg] Adapt to changes in Postgres 9.3
commit afc01c8261a61e612d82ca911dedd0fa3ca9e898
Author: Petr Písař ppi...@redhat.com
Date: Wed Jan 29 15:24:13 2014 +0100
Adapt to changes in Postgres 9.3
...for-the-PrintWarn-test-as-Postgres-got-le.patch | 27
perl-DBD-Pg.spec |9 ++-
2 files changed, 35 insertions(+), 1 deletions(-)
---
diff --git
a/DBD-Pg-2.19.3-Use-DEBUG1-for-the-PrintWarn-test-as-Postgres-got-le.patch
b/DBD-Pg-2.19.3-Use-DEBUG1-for-the-PrintWarn-test-as-Postgres-got-le.patch
new file mode 100644
index 000..b08730b
--- /dev/null
+++ b/DBD-Pg-2.19.3-Use-DEBUG1-for-the-PrintWarn-test-as-Postgres-got-le.patch
@@ -0,0 +1,27 @@
+From accf9a11bab7de2d11a36bdaa01e2e438dd33104 Mon Sep 17 00:00:00 2001
+From: Erik Rijkers e...@xs4all.nl
+Date: Fri, 17 May 2013 22:09:41 -0400
+Subject: [PATCH] Use DEBUG1 for the PrintWarn test, as Postgres got less
+ chatty in 9.3
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Petr Pisar: Removed Changes
+
+diff --git a/t/02attribs.t b/t/02attribs.t
+index e98add9..197d962 100644
+--- a/t/02attribs.t
b/t/02attribs.t
+@@ -251,7 +251,7 @@ is ($value, 1, $t);
+
+ local $SIG{__WARN__} = sub { $warning = shift; };
+
+-$dbh-do(q{SET client_min_messages = 'NOTICE'});
++$dbh-do(q{SET client_min_messages = 'DEBUG1'});
+ $t='DB handle attribute PrintWarn works when on';
+ $warning = q{};
+ eval {
+--
+1.8.5.3
+
diff --git a/perl-DBD-Pg.spec b/perl-DBD-Pg.spec
index 03086ea..e3431da 100644
--- a/perl-DBD-Pg.spec
+++ b/perl-DBD-Pg.spec
@@ -1,10 +1,13 @@
Name: perl-DBD-Pg
Summary:A PostgreSQL interface for perl
Version:2.19.3
-Release:5%{?dist}
+Release:6%{?dist}
License:GPLv2+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/T/TU/TURNSTEP/DBD-Pg-%{version}.tar.gz
+# Adapt to changes in Postgres 9.3, in upstream after 2.19.3, bug #1058723,
+# CPAN RT#88865
+Patch0:
DBD-Pg-2.19.3-Use-DEBUG1-for-the-PrintWarn-test-as-Postgres-got-le.patch
URL:http://search.cpan.org/dist/DBD-Pg/
BuildRequires: perl(Carp)
@@ -54,6 +57,7 @@ to PostgreSQL databases.
%prep
%setup -q -n DBD-Pg-%{version}
+%patch0 -p1
# Move testme.tmp.pl into tests sub-package
mv testme.tmp.pl t/
sed -i -e '/^testme.tmp.pl$/ s/^/t\//' MANIFEST
@@ -87,6 +91,9 @@ make test
%changelog
+* Wed Jan 29 2014 Petr Pisar ppi...@redhat.com - 2.19.3-6
+- Adapt to changes in Postgres 9.3 (bug #1058723)
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.19.3-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
--
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-Pg/f20] (2 commits) ...Correct changelog
Summary of changes: afc01c8... Adapt to changes in Postgres 9.3 (*) c83f650... Correct changelog (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DBD-Pg/f19] Adapt to changes in Postgres 9.3
commit 4c8ccb01e24d0b2a368c017dfe412862eeb849fd
Author: Petr Písař ppi...@redhat.com
Date: Wed Jan 29 15:24:13 2014 +0100
Adapt to changes in Postgres 9.3
...for-the-PrintWarn-test-as-Postgres-got-le.patch | 27
perl-DBD-Pg.spec |9 ++-
2 files changed, 35 insertions(+), 1 deletions(-)
---
diff --git
a/DBD-Pg-2.19.3-Use-DEBUG1-for-the-PrintWarn-test-as-Postgres-got-le.patch
b/DBD-Pg-2.19.3-Use-DEBUG1-for-the-PrintWarn-test-as-Postgres-got-le.patch
new file mode 100644
index 000..b08730b
--- /dev/null
+++ b/DBD-Pg-2.19.3-Use-DEBUG1-for-the-PrintWarn-test-as-Postgres-got-le.patch
@@ -0,0 +1,27 @@
+From accf9a11bab7de2d11a36bdaa01e2e438dd33104 Mon Sep 17 00:00:00 2001
+From: Erik Rijkers e...@xs4all.nl
+Date: Fri, 17 May 2013 22:09:41 -0400
+Subject: [PATCH] Use DEBUG1 for the PrintWarn test, as Postgres got less
+ chatty in 9.3
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Petr Pisar: Removed Changes
+
+diff --git a/t/02attribs.t b/t/02attribs.t
+index e98add9..197d962 100644
+--- a/t/02attribs.t
b/t/02attribs.t
+@@ -251,7 +251,7 @@ is ($value, 1, $t);
+
+ local $SIG{__WARN__} = sub { $warning = shift; };
+
+-$dbh-do(q{SET client_min_messages = 'NOTICE'});
++$dbh-do(q{SET client_min_messages = 'DEBUG1'});
+ $t='DB handle attribute PrintWarn works when on';
+ $warning = q{};
+ eval {
+--
+1.8.5.3
+
diff --git a/perl-DBD-Pg.spec b/perl-DBD-Pg.spec
index 00a25ac..9e71885 100644
--- a/perl-DBD-Pg.spec
+++ b/perl-DBD-Pg.spec
@@ -1,10 +1,13 @@
Name: perl-DBD-Pg
Summary:A PostgreSQL interface for perl
Version:2.19.3
-Release:3%{?dist}
+Release:4%{?dist}
License:GPLv2+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/T/TU/TURNSTEP/DBD-Pg-%{version}.tar.gz
+# Adapt to changes in Postgres 9.3, in upstream after 2.19.3, bug #1058723,
+# CPAN RT#88865
+Patch0:
DBD-Pg-2.19.3-Use-DEBUG1-for-the-PrintWarn-test-as-Postgres-got-le.patch
URL:http://search.cpan.org/dist/DBD-Pg/
BuildRequires: perl(Carp)
@@ -54,6 +57,7 @@ to PostgreSQL databases.
%prep
%setup -q -n DBD-Pg-%{version}
+%patch0 -p1
# Move testme.tmp.pl into tests sub-package
mv testme.tmp.pl t/
sed -i -e '/^testme.tmp.pl$/ s/^/t\//' MANIFEST
@@ -87,6 +91,9 @@ make test
%changelog
+* Wed Jan 29 2014 Petr Pisar ppi...@redhat.com - 2.19.3-4
+- Adapt to changes in Postgres 9.3 (bug #1058723)
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.19.3-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
--
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-Pg/f19] Correct changelog
commit a98a54e5ef6f9888e6ea7b2f52b1d757975a4da5 Author: Petr Písař ppi...@redhat.com Date: Wed Jan 29 15:26:10 2014 +0100 Correct changelog perl-DBD-Pg.spec |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) --- diff --git a/perl-DBD-Pg.spec b/perl-DBD-Pg.spec index 9e71885..c8c0cd0 100644 --- a/perl-DBD-Pg.spec +++ b/perl-DBD-Pg.spec @@ -176,7 +176,7 @@ make test * Fri Oct 31 2008 Marcela Maslanova mmasl...@redhat.com - 2.11.2-1 - update to 2.11.2 -* Mon Aug 29 2008 Marcela Maslanova mmasl...@redhat.com - 2.10.0-1 +* Fri Aug 29 2008 Marcela Maslanova mmasl...@redhat.com - 2.10.0-1 - update to 2.10.0 * Mon Aug 25 2008 Marcela Maslanova mmasl...@redhat.com - 2.9.2-1 @@ -211,7 +211,7 @@ make test * Tue Jul 17 2007 Robin Norwood rnorw...@redhat.com - 1.49-4 - Fix summary -* Tue Dec 06 2006 Robin Norwood rnorw...@redhat.com - 1.49-3 +* Tue Dec 05 2006 Robin Norwood rnorw...@redhat.com - 1.49-3 - rebuild for new version of postgres. * Wed Jul 12 2006 Jesse Keating jkeat...@redhat.com - 1.49-2 -- 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: Using git for patch management in Fedora
On 11/19/2013 10:55 AM, Mathieu Bridon wrote: On Tue, 2013-11-19 at 10:32 +, Richard W.M. Jones wrote: On Tue, Nov 19, 2013 at 06:28:47PM +0800, Mathieu Bridon wrote: Or maybe we could start using %autosetup ? http://www.rpm.org/wiki/PackagerDocs/Autosetup '%autosetup -S git' for sure, not plain %autosetup. Git correctly handles file modes and binary patches (not that binary patches should be much of a concern here, but file modes definitely are). BTW patch 2.7 does support file mode changes: http://savannah.gnu.org/forum/forum.php?forum_id=7361 Binary patches are not yet supported but they are quite useful and I've hit that with patches adding new png files for example. On the topic of new files, `%autosetup -S git` currently doesn't handle those: https://bugzilla.redhat.com/1059285 cheers, Pádraig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-DBD-CSV/epel7] Add upstream fix for t/48_utf8.t to work with Text::CSV_XS ≥ 0.99
commit edf5a566cabf6c9623e1458537b131dbe120ab92
Author: Paul Howarth p...@city-fan.org
Date: Wed Jan 29 15:32:25 2014 +
Add upstream fix for t/48_utf8.t to work with Text::CSV_XS ≥ 0.99
.gitignore |8 +-
DBD-CSV-0.38-utf8-test.patch | 53 ++
perl-DBD-CSV.spec| 13 --
3 files changed, 64 insertions(+), 10 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 2a4c754..53e2f61 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,7 +1 @@
-DBD-CSV-0.30.tgz
-/DBD-CSV-0.31.tgz
-/DBD-CSV-0.33.tgz
-/DBD-CSV-0.34.tgz
-/DBD-CSV-0.35.tgz
-/DBD-CSV-0.36.tgz
-/DBD-CSV-0.38.tgz
+/DBD-CSV-[0-9.]*.tgz
diff --git a/DBD-CSV-0.38-utf8-test.patch b/DBD-CSV-0.38-utf8-test.patch
new file mode 100644
index 000..95dd564
--- /dev/null
+++ b/DBD-CSV-0.38-utf8-test.patch
@@ -0,0 +1,53 @@
+From c88436e0e97fb4efba5432add1af480bcaa099b1 Mon Sep 17 00:00:00 2001
+From: H.Merijn Brand - Tux h.m.br...@xs4all.nl
+Date: Tue, 11 Jun 2013 14:48:52 +0200
+Subject: [PATCH] Text::CSV_XS is allowed to return encoded data if valid UTF-8
+
+Text::CSV_XS 0.99 fixed automatic encoding of valid UTF-8
+---
+ sandbox/genMETA.pl | 2 +-
+ t/48_utf8.t| 8 ++--
+ 2 files changed, 7 insertions(+), 3 deletions(-)
+
+#diff --git a/sandbox/genMETA.pl b/sandbox/genMETA.pl
+#index 3ea13e1..4ddde8a 100755
+#--- a/sandbox/genMETA.pl
+#+++ b/sandbox/genMETA.pl
+#@@ -67,7 +67,7 @@
+# charnames: 0
+# recommends:
+# perl:5.016003
+#-Test::More: 0.98
+#+Test::More: 0.99
+# installdirs: site
+# resources:
+# license: http://dev.perl.org/licenses/
+diff --git a/t/48_utf8.t b/t/48_utf8.t
+index 04a5d91..0230b4f 100644
+--- a/t/48_utf8.t
b/t/48_utf8.t
+@@ -43,7 +43,9 @@ foreach my $tbl ($tbl1, $tbl2) {
+ ok ($sth-execute,execute);
+ foreach my $i (1 .. scalar @data) {
+ ok ($row = $sth-fetch, fetch $i);
+- is_deeply ($row, [ $i , encode (utf8, $data[$i - 1]) ],
unencoded content $i);
++ my $v = $data[$i - 1];
++ utf8::is_utf8 ($v) or $v = encode (utf8, $v);
++ is_deeply ($row, [ $i , $v ], unencoded content $i);
+ }
+ ok ($sth-finish, finish);
+ undef $sth;
+@@ -57,7 +59,9 @@ foreach my $tbl ($tbl1, $tbl2) {
+ ok ($sth-execute,execute);
+ foreach my $i (1 .. scalar @data) {
+ ok ($row = $sth-fetch, fetch $i);
+- is_deeply ($row, [ $i , $data[$i - 1] ],encoded content $i);
++ my $v = $data[$i - 1];
++ ok (utf8::is_utf8 ($v), is encoded);
++ is_deeply ($row, [ $i , $v ], encoded content $i);
+ }
+ ok ($sth-finish, finish);
+ undef $sth;
+--
+1.8.5.1
+
diff --git a/perl-DBD-CSV.spec b/perl-DBD-CSV.spec
index aabb4ae..57ce388 100644
--- a/perl-DBD-CSV.spec
+++ b/perl-DBD-CSV.spec
@@ -1,11 +1,12 @@
Name: perl-DBD-CSV
Version:0.38
-Release:2%{?dist}
+Release:3%{?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
+Patch0: DBD-CSV-0.38-utf8-test.patch
BuildArch: noarch
BuildRequires: perl(Carp)
BuildRequires: perl(Cwd)
@@ -17,12 +18,12 @@ BuildRequires: perl(File::Spec)
BuildRequires: perl(IO::File)
BuildRequires: perl(SQL::Statement) = 1.402
BuildRequires: perl(Test::More) = 0.98
-BuildRequires: perl(Text::CSV_XS) = 0.94
+BuildRequires: perl(Text::CSV_XS) = 0.99
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: perl(DBD::File) = 0.41
Requires: perl(DBI) = 1.623
Requires: perl(SQL::Statement) = 1.402
-Requires: perl(Text::CSV_XS) = 0.94
+Requires: perl(Text::CSV_XS) = 0.99
%global __requires_exclude
%{?__requires_exclude:__requires_exclude|}^perl\\(DBD::File\\)$
%global __requires_exclude %__requires_exclude|^perl\\(Text::CSV_XS\\)$
@@ -39,6 +40,9 @@ MS Excel data.
%setup -q -n DBD-CSV-%{version}
chmod -c a-x ChangeLog README lib/DBD/*.pm lib/Bundle/DBD/*.pm
+# Fix t/48_utf8.t to work with Text::CSV_XS ≥ 0.99 (upstream commit)
+%patch0 -p1
+
%build
perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
@@ -58,6 +62,9 @@ make test
%{_mandir}/man3/*.3pm*
%changelog
+* Wed Jan 29 2014 Paul Howarth p...@city-fan.org - 0.38-3
+- Add upstream fix for t/48_utf8.t to work with Text::CSV_XS ≥ 0.99
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.38-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
Looking for crypto ciphers being used.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'm trying to figure out how to catalog what packages are using what cryptographic ciphers within Fedora (specifically RC4). Does anyone know of a good way of figuring that out? - -- Eric - -- Eric Sparks Christensen Fedora Project spa...@fedoraproject.org - spa...@redhat.com 097C 82C3 52DF C64A 50C2 E3A3 8076 ABDE 024B B3D1 - -- -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJS6SMAAAoJEB/kgVGp2CYvMj4L/i+Fl0d6xqsm6vj2swSFCBxL +gBO9lkW7cQuDtbUldL7iqZxkA5dxGJWuLErFxGtzkvclG+8vTnpsdZj9IYmpYCq CXxOB1WCpzdnTOFBZmOthIG+MbAIWbbHsrhxqbhcT82Ba0K347XbWWcXvM3HKIx9 iZOOSaG4Xralhi7ljFTldmfr/SUb10I197V+FWcab447p7bOW81jF1VlKkd9bfpK el8zdDL88U8OiAWNvAdoyKVT9bPD7ZDgxCRjQ/kaAplsJfSjcNUpDSwhCj+l7r4x Lr+LpcPRuwk+3SBOG72UCiBtn3VZr7CFgpaFXOBRahQEhjqVVCc9IBHN/Ptfs+3z FSEYocULrqzXsr5UAk7hknCFjooNnT0eF6Teywpng8MeN88pLmq/MEMrq6NfCvYV yIzMA+Y/uUKvYqqq6inWg8I7ngpQkGPTA/sefKQLTDGWtFRZQA3Bp6TzVDOK/Hg9 fP0NNU8t+sg+y1988q69+yXObKapOpoMzGxoSOl5rA== =4R0A -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Nightly builds of DNF available
Dear all, I am glad to announce the launch of continuous integration job for DNF. Each change now starts the bunch of DNF tests on top of upstream versions of hawkey, librepo and libcomps. It also means that from now nightly builds of DNF and its dependencies are available to you. Download them at will from http://jenkins.cloud.fedoraproject.org/job/DNF/lastSuccessfulBuild/artifact/. To check presence of new builds please follow the RSS channel http://jenkins.cloud.fedoraproject.org/job/DNF/rssAll. Best regards -- Radek Holý Associate Software Engineer Software Management Team Red Hat Czech -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Nightly builds of DNF available
On 29 January 2014 16:03, Radek Holy rh...@redhat.com wrote: I am glad to announce the launch of continuous integration job for DNF. Each change now starts the bunch of DNF tests on top of upstream versions of hawkey, librepo and libcomps. Great news, thanks for doing this. Is there any more documentation on libcomps yet? i.e. is it stable enough to use now? Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New version of Copr
On 01/28/2014 06:01 AM, Michael Stahnke wrote: Are there plans to add ARM? It is my wish as well. My plan is to talk on upcoming DevConf.cz to several people if/how it can be done. Additionally I'm in contact with Dan Horak from Secondary Arch team and we may get PPC builders. But the horizont is several months. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Planned Outage: Fedocal outage for update - 2014-01-30 10:30 UTC
Planned Outage: Fedocal outage for update - 2014-01-30 10:30 UTC There will be an outage starting at 2014-01-30 10:30 UTC, which will last approximately 1 hours, possibly less. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2014-01-30 10:30 UTC' Reason for outage: Update fedocal to 0.4.0 and use this opportunity to rebuild its database. No data should be loss Affected Services: Fedora Calendar - https://apps.fedoraproject.org/calendar/ Unaffected Services: Ask Fedora - http://ask.fedoraproject.org/ Badges - https://badges.fedoraproject.org/ BFO - http://boot.fedoraproject.org/ Blockerbugs - https://qa.fedoraproject.org/blockerbugs/ Bodhi - https://admin.fedoraproject.org/updates/ Buildsystem - http://koji.fedoraproject.org/ GIT / Source Control - pkgs.fedoraproject.org Darkserver - https://darkserver.fedoraproject.org/ DNS - ns-sb01.fedoraproject.org, ns02.fedoraproject.org, ns04.fedoraproject.org, ns05.fedoraproject.org Docs - http://docs.fedoraproject.org/ Elections - https://admin.fedoraproject.org/voting Email system Fedmsg busmon - http://apps.fedoraproject.org/busmon Fedora Account System - https://admin.fedoraproject.org/accounts/ Fedora Community - https://admin.fedoraproject.org/community/ Fedora Hosted - https://fedorahosted.org/ Fedora OpenID - https://id.fedoraproject.org/ Fedora People - http://fedorapeople.org/ Main Website - http://fedoraproject.org/ Mirror List - https://mirrors.fedoraproject.org/ Mirror Manager - https://admin.fedoraproject.org/mirrormanager/ Package Database - https://admin.fedoraproject.org/pkgdb/ QA Services Secondary Architectures Spins - http://spins.fedoraproject.org/ Start - http://start.fedoraproject.org/ Torrent - http://torrent.fedoraproject.org/ Wiki - http://fedoraproject.org/wiki/ Contact Information: Ticket Link: https://fedorahosted.org/fedora-infrastructure/ticket/4204 Please join #fedora-admin or #fedora-noc on irc.freenode.net or add comments to the ticket for this outage above. pgpucy2NG5XwE.pgp Description: PGP signature ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[389-devel] Please review (take #2) ticket 47676: Replication of the schema fails 'master branch' - 1.2.11 or 1.3.1
In the previous review, the policies (to be applied during replication of the schema) were hardcoded. This new review, is to define them into specific entries under 'cn=replSchema,cn=config so that it will be configurable. https://fedorahosted.org/389/attachment/ticket/47676/0002-Ticket-ticket47676-Replication-of-the-schema-fails-m.patch -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Fedora.next in 2014 -- Big Picture and Themes
On Wed, 2014-01-29 at 08:57 -0500, Matthew Miller wrote: On Tue, Jan 28, 2014 at 06:15:49PM -0800, Adam Williamson wrote: Just to wax philosophical for a minute: I think there's a lot of value in building boring stuff that works well, and I might be weird, but I [snip eloquent defense of the virtues of boring basic distro work] This doesn't mean I'm against doing Big Exciting New Things in general or Fedora.next in particular, but I do want to stand up for the value of just keeping your head down (hah, I know, Adam, practice what you preach) and doing good, dull engineering work. With your pocket protector firmly in place. This is all very convincing. But you also sent me a convincing message the other week about Fedora's place on the innovation curve and, basically, the difficulty of doing all that good dull work while being innovative. Stop convincing me in different directions -- my head will fall off! I have a degree in history. I can argue any side of any issue at the drop of a hat, prior research unnecessary. ;) Or, in seriousness, because I don't think they're *necessarily* in direct conflict, Seriously, this is what I think. And in fact, they work together: it's actually quite fascinating that in Fedora we have a place where we can do fairly radical stuff to a 'boring, stable' platform like the OS. That's the strength of the distribution model, I guess: as we've noted before, Fedora often blazes the trail for big hairy changes to things that might otherwise be 'too important to touch'. what do you think we should do about all of the above? Our mission and branding, including our foundations, tend to steer away from the dull and towards new shiny. In fact, whenever we do something that could be characterized as head-down plodding forward progress instead of a bold leap, we hear *quite a bit* of sarcasm about the four foundations in the online chatter. So, should we look at reconciling that in some way? Part of *my* idea for Fedora.next was that the base circle could focus more on this careful and non-thrilling engineering work while the outer rings could do the big-exciting things at the same time. (Or even have *some* parts of the outer rings working on big-exciting, while other parts work on _even more solid_.) *goes and gets coffee. not able to quite express what I mean. hope you understand anyway* I do entirely, and actually I think we may be rather on the same wavelength for once =) I'm not good at marketing-type stuff, though, so I'm not sure I have an answer for you. I know I have this basic idea that we've outlined above, but that's a tricky message to communicate to people, and I'm not your guy for creative messaging stuff. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Documentation Tools
On Wed, 29 Jan 2014 07:32:29 -0500 (EST) Kamil Paral kpa...@redhat.com wrote: I've posted a comparison between Sphinx and Dexy [1] - as well as updated the phabricator ticket [2]. The tools are pretty similar in what they can produce, so it really comes down to what people are comfortable with. The learning curve for Dexy isn't steep, and I think it's just enough easier to use compared to Sphinx for our purposes. I wondered why I hadn't seen it at Fedora Planet (neither your previous blogpost), and it's because your RSS feed is no longer updated: http://roshi.fedorapeople.org/feeds/fedora.atom.xml I wasn't able to find air-tight reasoning for one over the other for qa-devel work - but found dexy a bit easier to use and template. Source for both tutorials can be found on my bitbucket profile [3]. Thanks. Can you move it into our team repo list? https://bitbucket.org/fedoraqa // Roshi [1] http://roshi.fedorapeople.org/comparing-dexy-and-sphinx.html [2] https://phab.qadevel.cloud.fedoraproject.org/T39 [3] https://bitbucket.org/Rorosha/doc-tools ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel I've fixed the RSS issue. As for moving the repo - I think it makes more sense to move the tutorial source to taskotron (instead of the team repo list) once we decide the tool we want to use for docs - Unless there's a real need for the demo to be on the team page that I'm not seeing. // Roshi signature.asc Description: PGP signature ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Nightly builds of DNF available
On 01/29/2014 05:03 PM, Radek Holy wrote: I am glad to announce the launch of continuous integration job for DNF. Each change now starts the bunch of DNF tests on top of upstream versions of hawkey, librepo and libcomps. It also means that from now nightly builds of DNF and its dependencies are available to you. Download them at will from http://jenkins.cloud.fedoraproject.org/job/DNF/lastSuccessfulBuild/artifact/. To check presence of new builds please follow the RSS channel http://jenkins.cloud.fedoraproject.org/job/DNF/rssAll. Wouldn't it make sense to create YUM metadata so that people can automatically update DNF with itself? XMvn project which uses Fedora Jenkins instance does that, see: http://jenkins.cloud.fedoraproject.org/job/xmvn/ws/RPM/latest/ That works well for me. In my yum.conf I have: [jenkins-xmvn] name=jenkins-xmvn baseurl=http://jenkins.cloud.fedoraproject.org/job/xmvn/ws/RPM/latest cost=3000 -- Mikolaj Izdebski IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.next in 2014 -- Big Picture and Themes
Matthew Miller wrote: Our mission and branding, including our foundations, tend to steer away from the dull and towards new shiny. In fact, whenever we do something that could be characterized as head-down plodding forward progress instead of a bold leap, we hear *quite a bit* of sarcasm about the four foundations in the online chatter. Might it be time to add a fifth foundation, one of ferro-concrete, to provide a firm footing? Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Nightly builds of DNF available
I have just added the metadata creation. Good point, thank you. -- Radek Holý Associate Software Engineer Software Management Team Red Hat Czech - Original Message - From: Mikolaj Izdebski mizde...@redhat.com To: devel@lists.fedoraproject.org Sent: Wednesday, January 29, 2014 5:18:41 PM Subject: Re: Nightly builds of DNF available On 01/29/2014 05:03 PM, Radek Holy wrote: I am glad to announce the launch of continuous integration job for DNF. Each change now starts the bunch of DNF tests on top of upstream versions of hawkey, librepo and libcomps. It also means that from now nightly builds of DNF and its dependencies are available to you. Download them at will from http://jenkins.cloud.fedoraproject.org/job/DNF/lastSuccessfulBuild/artifact/. To check presence of new builds please follow the RSS channel http://jenkins.cloud.fedoraproject.org/job/DNF/rssAll. Wouldn't it make sense to create YUM metadata so that people can automatically update DNF with itself? XMvn project which uses Fedora Jenkins instance does that, see: http://jenkins.cloud.fedoraproject.org/job/xmvn/ws/RPM/latest/ That works well for me. In my yum.conf I have: [jenkins-xmvn] name=jenkins-xmvn baseurl=http://jenkins.cloud.fedoraproject.org/job/xmvn/ws/RPM/latest cost=3000 -- Mikolaj Izdebski IRC: mizdebsk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Looking for crypto ciphers being used.
Eric H. Christensen (spa...@fedoraproject.org) said: I'm trying to figure out how to catalog what packages are using what cryptographic ciphers within Fedora (specifically RC4). Does anyone know of a good way of figuring that out? I'm imagining some dystopia where every imported and rebased package is run through some system to scan the source code for crypto algorithms, licenses, etc. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Looking for crypto ciphers being used.
On Wed, Jan 29, 2014 at 4:49 PM, Eric H. Christensen spa...@fedoraproject.org wrote: I'm trying to figure out how to catalog what packages are using what cryptographic ciphers within Fedora (specifically RC4). Does anyone know of a good way of figuring that out? AFAIK there isn't one. There are various scripts that grep the source code for regexps (and if you are lucky, filter out the most blatant false positives), but even with the best scripts I've seen expect days or weeks of manual review to eliminate the false positives (and you'll have nothing to tell you about the false negatives). Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Drawing lessons from fatal SELinux bug #1054350
On Wed, 2014-01-29 at 09:26 -0500, Matthew Miller wrote: On Tue, Jan 28, 2014 at 06:42:52PM -0800, Adam Williamson wrote: Using the wiki as a TCMS is of course a gross hack, but it comes with a surprising number of advantages - see Makes sense to me. I'm actually not opposed to using the wiki in this way, but I think it highlights the need for _something else_ to be our short-quick-easy documentation solution. I wonder if it would help both of these things to move the test plans to live in package git (right next to the future taskotron scripts? Well, what would they look like, and how would you read them? What we're They would be short text files. Possibly markdown. Something simple, though. I hear you on the downside of having to have commit rights to the package in order to work on test plans in git. That applies to the taskotron tests too, though, doesn't it? Maybe we could use git submodules for this. (Where each fedora package has a submodule consisting of its tests, both automated and test plans.) Yeah it does - there's an argument to be made that you need a lot more (or, y'know, any at all) in the way of dev skills to write a taskotron test than a manual test case, but still, you could be the world's foremost expert on automated testing and not have provenpackager rights, so it's still a problem. Submodules with broader access rights doesn't seem like a bad design...but I guess if this all gets hooked up to Bodhi, you should still need package commit privs to decide which automated tests can cause an update to be rejected or whatever (or else anyone can DoS a package, accidentally or intentionally, by adding a broken automated test). But like I said I'm not really opposed to continuing to use the wiki. Maybe we just need an awareness campaign. (Some text in the bodhi.template from fedpkg update would be a good start, I think. And on the New Update page in the bodhi web interface. And definitely in https://fedoraproject.org/wiki/Package_update_HOWTO -- I'll do that, as soon as I have that coffee I didn't have when I said I was going to at the end of the last message I sent.) OK, that makes sense - you're talking about 'publicising' this system in the places *packagers* see when interacting with Bodhi. Absolutely, good idea, no objections. And, while clearly helpful, I think it suffers from a little bit of tl;dr. Maybe we could embed summaries of each right into the Bodhi page? I'm not quite clear what you mean here - what's tl? Summaries of what? I mean the links to the test cases shown in bodhi. In the context of trying to get better feedback in bodhi, it would be nice if there were a summary of each test right in the bodhi screen (not just its title). Ahh, I see. I'd worry that would make the Bodhi pages a bit long, with the way test cases are laid out - they tend to be vertical space hungry - but it'd be interesting to mock it up and see. Then, there could be a little dropdown to choose between didn't try this aspect, looked at the thing in the summary; seemed okay and actually went through this full test case. That would make it easy for people to be descriptive and honest about what they actually tried. *This* bit is part of the Glorious Bodhi 2.0 Vision, yep - if you go and find that post from forever ago in the archives, it describes something very like this. It is Bodhi 2.0-dependent, though, I think. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Sort-Naturally/epel7] Initial import (#1058968).
Summary of changes: a01074e... Initial import (#1058968). (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Fedora.next in 2014 -- Big Picture and Themes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/29/2014 12:06 PM, Björn Persson wrote: Matthew Miller wrote: Our mission and branding, including our foundations, tend to steer away from the dull and towards new shiny. In fact, whenever we do something that could be characterized as head-down plodding forward progress instead of a bold leap, we hear *quite a bit* of sarcasm about the four foundations in the online chatter. Might it be time to add a fifth foundation, one of ferro-concrete, to provide a firm footing? An astounding array and assortment of alliteration alluding to our aspirations. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLpP4MACgkQeiVVYja6o6PIsQCfc3sScSaLgZmRzrw+jljUiYrj 8LcAn0EzaQz15jPET3d+bdKMEXUYgBFu =PPo/ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Looking for crypto ciphers being used.
On 01/29/2014 07:06 PM, Miloslav Trmač wrote: On Wed, Jan 29, 2014 at 4:49 PM, Eric H. Christensen spa...@fedoraproject.org mailto:spa...@fedoraproject.org wrote: I'm trying to figure out how to catalog what packages are using what cryptographic ciphers within Fedora (specifically RC4). Does anyone know of a good way of figuring that out? AFAIK there isn't one. There are various scripts that grep the source code for regexps (and if you are lucky, filter out the most blatant false positives), but even with the best scripts I've seen expect days or weeks of manual review to eliminate the false positives (and you'll have nothing to tell you about the false negatives). And RC4 is especially tricky in this regard because it doesn't have any magic constants. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: a questionable dependency chain
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/29/2014 07:32 AM, Christophe Fergeau wrote: Hey, On Wed, Jan 29, 2014 at 09:21:22AM -0500, Matthias Clasen wrote: I've switched to rawhide yesterday, and discovered that vinagre now forces rsyslog onto my system. That's not great. The dependency chain goes something like this: vinagre - spice - libcacard - ... glusterfs ... - rsyslog-mmjsonparse - rsyslog I think there's at least two questionable links in this chain: - why does libcacard need glusterfs ? Looking at nm output for libcacard.so, I did not see symbols that were obviously related to glusterfs there. However, at build time, libcacard ld command line gets a lot of -lxx, including glusterfs libraries. libcacard is a sub-package of qemu, so I suspect what's happening is it gets linked with all the libraries qemu needs. This patch seems to help there and get rid of the extra libraries in ldd output (did not try an rpm build to check the deps there). diff --git a/libcacard/Makefile b/libcacard/Makefile index 47827a0..9fa297c 100644 --- a/libcacard/Makefile +++ b/libcacard/Makefile @@ -24,7 +24,7 @@ vscclient$(EXESUF): libcacard/vscclient.o libcacard.la libcacard.la: LDFLAGS += -rpath $(libdir) -no-undefined \ -export-syms $(SRC_PATH)/libcacard/libcacard.syms -libcacard.la: LIBS += $(libcacard_libs) +libcacard.la: LIBS = $(libcacard_libs) libcacard.la: $(libcacard-lobj-y) $(call LINK,$^) Christophe Yeah, there were lots: # rpmlint libcacard libcacard.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcacard.so.0.0.0 /usr/lib64/iscsi/libiscsi.so.2 libcacard.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcacard.so.0.0.0 /lib64/libz.so.1 libcacard.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcacard.so.0.0.0 /lib64/libgfapi.so.0 libcacard.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcacard.so.0.0.0 /lib64/libglusterfs.so.0 libcacard.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcacard.so.0.0.0 /lib64/libgfrpc.so.0 libcacard.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcacard.so.0.0.0 /lib64/libgfxdr.so.0 libcacard.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcacard.so.0.0.0 /lib64/libssh2.so.1 libcacard.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcacard.so.0.0.0 /lib64/librbd.so.1 libcacard.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcacard.so.0.0.0 /lib64/librados.so.2 libcacard.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcacard.so.0.0.0 /lib64/libcurl.so.4 libcacard.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcacard.so.0.0.0 /lib64/libuuid.so.1 libcacard.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcacard.so.0.0.0 /lib64/libaio.so.1 libcacard.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcacard.so.0.0.0 /lib64/libssl3.so libcacard.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcacard.so.0.0.0 /lib64/libsmime3.so libcacard.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcacard.so.0.0.0 /lib64/libnssutil3.so libcacard.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcacard.so.0.0.0 /lib64/libplds4.so libcacard.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcacard.so.0.0.0 /lib64/libplc4.so libcacard.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcacard.so.0.0.0 /lib64/libdl.so.2 libcacard.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libcacard.so.0.0.0 /lib64/libgthread-2.0.so.0 libcacard.x86_64: W: shared-lib-calls-exit /usr/lib64/libcacard.so.0.0.0 exit@GLIBC_2.2.5 libcacard.x86_64: W: no-documentation Also: libcacard.x86_64: E: library-without-ldconfig-postin /usr/lib64/libcacard.so.0.0.0 libcacard.x86_64: E: library-without-ldconfig-postun /usr/lib64/libcacard.so.0.0.0 needs some scripts. - -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLpUNIACgkQORnzrtFC2/ueVQCgnz2PbI0W4VF82eC/1D5Ov/9v aPYAn0roZC262UGIFePp+drX+dLFGpbG =HoH5 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Summary/Minutes from today's FESCo Meeting (2014-01-29)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 === #fedora-meeting: FESCO (2014-01-29) === Meeting started by sgallagh at 17:59:12 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-01-29/fesco.2014-01-29-17.59.log.html . Meeting summary - --- * init process (sgallagh, 17:59:24) * #1197 Procedure for suggesting/approving different Products and/or WGs? (sgallagh, 18:04:36) * AGREED: Give this topic a week for people to come up with proposals (+5, 0, -0) (sgallagh, 18:40:24) * ACTION: sgallagh to start discussion on mailing list about Spins vs. Products. (sgallagh, 18:40:40) * #956 Need to audit packageset for bundling of libiberty (sgallagh, 18:41:01) * abadger1999 has nearly finished filing bugs. Nothing more for FESCo to do. Close ticket. (sgallagh, 18:43:17) * #1117 Generalize policy about privilege escalation and Administrator user accounts (sgallagh, 18:43:24) * The default right now is that things requiring more privilege should come to fesco to be decided. (sgallagh, 18:51:39) * AGREED: Since there is nobody with sufficient interest to generalize, and there's nothing really wrong about the current status, close the ticket == stop tracking this (+7, 0, -0) (sgallagh, 18:53:00) * #1226 Workstation PRD for approval (sgallagh, 18:53:06) * AGREED: Approve the current version of the Workstation PRD (+5, 1, -1) (sgallagh, 19:00:17) * Next week's chair (sgallagh, 19:06:49) * AGREED: skip next week's (Feb 5) meeting (+6, 1, -0) (sgallagh, 19:13:38) * abadger1999 to chair Feb 12 FESCo meeting (sgallagh, 19:14:48) * Open Floor (sgallagh, 19:14:52) Meeting ended at 19:19:33 UTC. Action Items - * sgallagh to start discussion on mailing list about Spins vs. Products. Action Items, by person - --- * sgallagh * sgallagh to start discussion on mailing list about Spins vs. Products. * **UNASSIGNED** * (none) People Present (lines said) - --- * sgallagh (113) * pjones (53) * abadger1999 (52) * jwb (39) * nirik (31) * mitr (21) * notting (19) * zodbot (10) * mmaslano (8) * jreznik (1) * mattdm (0) * t8m (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLpVM4ACgkQeiVVYja6o6Np5gCfdgXqL/xQ24kInismTLkncz4O hn4An1hkqZavh4djRRAlB9b8HYVFHfyl =LjoN -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora.NEXT Products and the fate of Spins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apologies for the slightly alarmist $SUBJECT, but I want to make sure that this gets read by the appropriate groups. During today's FESCo meeting, there was the start of a discussion on how to approve new Products into the Fedora family. As part of this, it naturally strayed into discussion of what we do about Spins as they currently exist. Several ideas were raised (which I'll go through below), but we didn't feel that this was something that FESCo should answer on its own. We'd prefer community input on how to handle spins going forward. So, in no particular order (because it's difficult to say which questions are the most important): 1) Are Spins useful as they currently exist? There are many problems that have been noted in the Spins process, most notably that it is very difficult to get a Spin approved and then has no ongoing maintenance requiring it to remain functional. We've had Spins at times go through entire Fedora release cycles without ever being functional. 2) Should Spins be eliminated entirely in favor of Fedora Remixes[1]. The effect here would be that Spins are no longer an official part of The Fedora Project but are instead projects unto themselves which are permitted to consume (possibly large) portions of our tools, packages and ecosystem. Maintenance and upkeep of these spins then becomes entirely the responsibility of the downstream community that constructs them and has no mandatory draw on Fedora's marketing, ambassadors or quality assurance resources. 3) Should Spins be considered Products-in-development? In other words, should we only approve Spins that are targeted or destined for promotion to a fully-supported Fedora Product? This is a nuanced question, as it means different things for different Spins, for example Spins focusing on a target-audience (Security Spin, Design Suite Spin) vs. Spins focusing on a technology (LXDE Spin, MATE-Compiz Spin). 3b) If we treat Spins as Products-in-development, what do we do with those Spins that don't fit that criteria? I'm sure there are other questions that people will come up with on this thread, but this should provide a good framework for the discussion. [1] https://fedoraproject.org/wiki/Remix -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLpZMwACgkQeiVVYja6o6NOIwCeP6Kr6FGVYLCdU9Uofv7Xrqm1 e3oAoIEky2/IjoGBF9MqVlEbkG0jd4vv =KDoO -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Error] Created tag perl-Error-0.17022-1.fc21
The lightweight tag 'perl-Error-0.17022-1.fc21' was created pointing to: db46218... Update to 0.17022 -- 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: a questionable dependency chain
On Wed, Jan 29, 2014 at 9:04 PM, Orion Poplawski or...@cora.nwra.com wrote: Also: libcacard.x86_64: E: library-without-ldconfig-postin /usr/lib64/libcacard.so.0.0.0 libcacard.x86_64: E: library-without-ldconfig-postun /usr/lib64/libcacard.so.0.0.0 needs some scripts. Already fixed in December, I suppose your rpmlint run wasn't against the latest Rawhide libcacard? http://pkgs.fedoraproject.org/cgit/qemu.git/commit/?id=c4896d008b4e71e0cdbc505d8ff8849f830ac531 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Thursday's FPC Meeting (2014-01-30 17:00 UTC)
Following is the list of topics that will be discussed in the FPC meeting Thursday at -MM-DD 16:00 UTC in #fedora-meeting-1 on irc.freenode.net. Local time information (via. rktime): 2014-01-30 09:00 Thu US/Pacific PST 2014-01-30 12:00 Thu US/Eastern EST 2014-01-30 17:00 Thu UTC - 2014-01-30 17:00 Thu Europe/London - 2014-01-30 18:00 Thu Europe/Paris CET 2014-01-30 18:00 Thu Europe/Berlin CET 2014-01-30 22:30 Thu Asia/Calcutta IST --new day-- 2014-01-31 01:00 Fri Asia/Singapore SGT 2014-01-31 01:00 Fri Asia/Hong_Kong HKT 2014-01-31 02:00 Fri Asia/Tokyo JST 2014-01-31 03:00 Fri Australia/Brisbane EST Links to all tickets below can be found at: https://fedorahosted.org/fpc/report/12 = Followups = (likely nothing to discuss) #topic #142 Request for changes to FPG .fpc 142 https://fedorahosted.org/fpc/ticket/142 (std. bundling questions not answered) #topic #317 Bundled Library exception request for Gazebo .fpc 317 https://fedorahosted.org/fpc/ticket/317 (final suggestions requested) #topic #338 %doc and %_pkgdocdir duplicate files and cause conflicts .fpc 338 https://fedorahosted.org/fpc/ticket/338 (approval and retirement sections already passed, /opt exception passed) #topic #339 software collections in Fedora .fpc 339 https://fedorahosted.org/fpc/ticket/339 (std. bundling questions not answered) #topic #340 Bundling exception for nodeunit .fpc 340 https://fedorahosted.org/fpc/ticket/340 (no draft, to be closed) #topic #358 Please make some autotools guidelines. .fpc 358 https://fedorahosted.org/fpc/ticket/358 #topic #382 Go Packaging Guidelines Draft .fpc 382 https://fedorahosted.org/fpc/ticket/382 #topic #385 workarounds for rpm symlink - directory issue .fpc 385 https://fedorahosted.org/fpc/ticket/385 #topic #387 Bundling exception: Heimdal bundles libtommath .fpc 387 https://fedorahosted.org/fpc/ticket/387 = New business = #topic #388 recommend %autosetup over %setup .fpc 388 https://fedorahosted.org/fpc/ticket/388 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at: https://fedorahosted.org/fpc/report/12 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fpc, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
Hi, I think we should keep spins as long as we don't have a formal process to accept new products. Something like = proposal = crop (aka product-to-be) = validation = product When we'll have that, drop the whole spin thing, any spin that isn't fit to be a product should be reclassified as remix. btw, it wouldn't be wise to define that process while we're still in Fedora.Next early stages, it'll just had more entropy. First we should work to release our sample products, then use that experience to define the process to bring a new product. H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/29/2014 03:57 PM, H. Guémar wrote: Hi, I think we should keep spins as long as we don't have a formal process to accept new products. Something like = proposal = crop (aka product-to-be) = validation = product When we'll have that, drop the whole spin thing, any spin that isn't fit to be a product should be reclassified as remix. btw, it wouldn't be wise to define that process while we're still in Fedora.Next early stages, it'll just had more entropy. First we should work to release our sample products, then use that experience to define the process to bring a new product. Well, one of the things we need to decide is whether we address Spins at all during the F21 timeframe. I suspect that QA will ask for a reprieve on that score. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLpbIwACgkQeiVVYja6o6NAOwCfeqNOwmikrZgS2uuVYbSSGmY2 bgAAoKDiszJp7pvgIv8Yn7gBf6Ryu21W =YCP4 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Wed, Jan 29, 2014 at 2:57 PM, H. Guémar hgue...@fedoraproject.org wrote: Hi, I think we should keep spins as long as we don't have a formal process to accept new products. Something like = proposal = crop (aka product-to-be) = validation = product When we'll have that, drop the whole spin thing, any spin that isn't fit to be a product should be reclassified as remix. Why do we expect spins to be any more official products than they are now? I can't really imagine this ever working. Do you imagine a day where Fedora has 20, 30, 50 official products? I don't. I'd rather not confuse what is made from Fedora bits with what is based on Fedora bits but includes other bits. The remix branding does not seem appropriate for spins that are made purely from Fedora bits. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
Hi, I agree that we can't support more than a limited number of products. The point is to make a validation process sufficiently strict so we can guarantee that the would-be product would be sustainable. After all, if there are people willing to maintain it on the long term *and* our infrastructure can handle it (rel-eng, QA, etc.), why should we prevent them ? H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing:
Age URL
648
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6
77
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12079/bip-0.8.9-1.el6
41
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12427/seamonkey-2.21-3.esr2.el6
15
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0166/mediawiki119-1.19.10-1.el6
13
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0197/drupal7-7.26-1.el6
13
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0202/transifex-client-0.10-1.el6
13
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0205/drupal6-6.30-1.el6
11
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0233/libreswan-3.8-1.el6
7
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0282/moodle-2.4.8-1.el6
1
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0378/quassel-0.9.2-1.el6
0
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0398/socat-1.7.2.3-1.el6
0
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0395/libpng10-1.0.60-6.el6
0
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0393/tpp-1.3.1-16.el6
The following builds have been pushed to Fedora EPEL 6 updates-testing
bluebird-0.9-1.el6
libpng10-1.0.60-6.el6
pcp-3.8.12-1.el6
socat-1.7.2.3-1.el6
tpp-1.3.1-16.el6
zabbix22-2.2.1-5.el6
Details about builds:
bluebird-0.9-1.el6 (FEDORA-EPEL-2014-0397)
A clean minimalistic theme for Xfce, GTK+ 2 and 3
Update Information:
Bluebird GTK/Metacity theme from Shimmer Project.
http://shimmerproject.org/project/bluebird/
libpng10-1.0.60-6.el6 (FEDORA-EPEL-2014-0395)
Old version of libpng, needed to run old binaries
Update Information:
This update fixes an issue in which an image with a missing or empty palette
could cause a crash of a libpng10-using application (CVE-2013-6954).
ChangeLog:
* Thu Jan 23 2014 Paul Howarth p...@city-fan.org 1.0.60-6
- handle zero-length PLTE chunk or NULL palette with png_error(), to avoid
later reading from a NULL pointer (png_ptr-palette) in
png_do_expand_palette() (CVE-2013-6954)
* Sat Jul 27 2013 Paul Howarth p...@city-fan.org 1.0.60-5
- install docs to %{_pkgdocdir} where available
* Sun Mar 24 2013 Paul Howarth p...@city-fan.org 1.0.60-4
- tweak config.guess and config.sub to add aarch64 support (#925862)
- update source URL, moved upstream
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
1.0.60-3
- rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
* Thu Jul 19 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
1.0.60-2
- rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild
* Wed Jul 11 2012 Paul Howarth p...@city-fan.org 1.0.60-1
- update to 1.0.60
- changed a+w to u+w in Makefile.in to fix CVE-2012-3386
References:
[ 1 ] Bug #1045561 - CVE-2013-6954 libpng: unhandled zero-length PLTE chunk
or NULL palette
https://bugzilla.redhat.com/show_bug.cgi?id=1045561
pcp-3.8.12-1.el6 (FEDORA-EPEL-2014-0396)
System-level performance monitoring and performance management
Update Information:
Resolves SNMP procfs file ICMP line parse issue (BZ 1055818)
ChangeLog:
* Wed Jan 29 2014 Nathan Scott nath...@redhat.com - 3.8.12-1
- Resolves SNMP procfs file ICMP line parse issue (BZ 1055818)
- Update to latest PCP sources.
References:
[ 1 ] Bug #1055818 - pmcd SEGV in linux pmda
https://bugzilla.redhat.com/show_bug.cgi?id=1055818
socat-1.7.2.3-1.el6 (FEDORA-EPEL-2014-0398)
Bidirectional data relay between two data channels ('netcat++')
Update Information:
Security update for CVE-2014-0019, which fixes a denial of service flaw in
socat
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 648 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 138 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11560/fail2ban-0.8.10-4.el5 102 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 77 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12091/bip-0.8.9-1.el5 67 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12169/gc-7.1-6.el5 18 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0132/graphviz-2.12-10.el5 13 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0203/transifex-client-0.10-1.el5 13 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0201/drupal7-7.26-1.el5 13 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0200/drupal6-6.30-1.el5 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0400/mediawiki119-1.19.11-2.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing mediawiki119-1.19.11-2.el5 pcp-3.8.12-1.el5 Details about builds: mediawiki119-1.19.11-2.el5 (FEDORA-EPEL-2014-0400) A wiki engine Update Information: - Update to 1.19.11 - (bug 60339) (CVE-2014-1610) SECURITY: Reported RCE in djvu thumbnailing - Provide mediawiki References: [ 1 ] Bug #1058981 - CVE-2014-1610 mediawiki: remote code execution via uploaded DjVu or PDF files https://bugzilla.redhat.com/show_bug.cgi?id=1058981 [ 2 ] Bug #1030987 - CVE-2013-4567 CVE-2013-4568 CVE-2013-4572 mediawiki: security releases 1.21.3, 1.20.8, and 1.19.9 https://bugzilla.redhat.com/show_bug.cgi?id=1030987 [ 3 ] Bug #1052962 - CVE-2013-6451 CVE-2013-6452 CVE-2013-6453 CVE-2013-6454 CVE-2013-6472 mediawiki: security releases 1.22.1, 1.21.4 and 1.19.10 https://bugzilla.redhat.com/show_bug.cgi?id=1052962 pcp-3.8.12-1.el5 (FEDORA-EPEL-2014-0399) System-level performance monitoring and performance management Update Information: Resolves SNMP procfs file ICMP line parse issue (BZ 1055818) ChangeLog: * Wed Jan 29 2014 Nathan Scott nath...@redhat.com - 3.8.12-1 - Resolves SNMP procfs file ICMP line parse issue (BZ 1055818) - Update to latest PCP sources. References: [ 1 ] Bug #1055818 - pmcd SEGV in linux pmda https://bugzilla.redhat.com/show_bug.cgi?id=1055818 ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Fedora.NEXT Products and the fate of Spins
On Wed, Jan 29, 2014 at 4:03 PM, inode0 ino...@gmail.com wrote: On Wed, Jan 29, 2014 at 2:57 PM, H. Guémar hgue...@fedoraproject.org wrote: Hi, I think we should keep spins as long as we don't have a formal process to accept new products. Something like = proposal = crop (aka product-to-be) = validation = product When we'll have that, drop the whole spin thing, any spin that isn't fit to be a product should be reclassified as remix. Why do we expect spins to be any more official products than they are now? I can't really imagine this ever working. Do you imagine a day where Fedora has 20, 30, 50 official products? I don't. I'd rather not confuse what is made from Fedora bits with what is based on Fedora bits but includes other bits. The remix branding does not seem appropriate for spins that are made purely from Fedora bits. That's fair. From a resource and quality perspective though, I'd rather not burden rel-eng and QA with having to maintain, create, and test spins. They can be done entirely outside of Fedora. They can be created and hosted on their own sites, etc. F20 improved spins overall, but that was because of a concerted effort with our existing resources. If Fedora.next is going to succeed, those resources are already going to be overwhelmed with the 3 products. Spreading them thinner for little benefit in most cases seems irresponsible. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: a questionable dependency chain
On 01/29/2014 01:36 PM, Ville Skyttä wrote: On Wed, Jan 29, 2014 at 9:04 PM, Orion Poplawski or...@cora.nwra.com wrote: Also: libcacard.x86_64: E: library-without-ldconfig-postin /usr/lib64/libcacard.so.0.0.0 libcacard.x86_64: E: library-without-ldconfig-postun /usr/lib64/libcacard.so.0.0.0 needs some scripts. Already fixed in December, I suppose your rpmlint run wasn't against the latest Rawhide libcacard? http://pkgs.fedoraproject.org/cgit/qemu.git/commit/?id=c4896d008b4e71e0cdbc505d8ff8849f830ac531 Ah, oops. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Wed, Jan 29, 2014 at 3:33 PM, Josh Boyer jwbo...@fedoraproject.org wrote: On Wed, Jan 29, 2014 at 4:03 PM, inode0 ino...@gmail.com wrote: On Wed, Jan 29, 2014 at 2:57 PM, H. Guémar hgue...@fedoraproject.org wrote: Hi, I think we should keep spins as long as we don't have a formal process to accept new products. Something like = proposal = crop (aka product-to-be) = validation = product When we'll have that, drop the whole spin thing, any spin that isn't fit to be a product should be reclassified as remix. Why do we expect spins to be any more official products than they are now? I can't really imagine this ever working. Do you imagine a day where Fedora has 20, 30, 50 official products? I don't. I'd rather not confuse what is made from Fedora bits with what is based on Fedora bits but includes other bits. The remix branding does not seem appropriate for spins that are made purely from Fedora bits. That's fair. From a resource and quality perspective though, I'd rather not burden rel-eng and QA with having to maintain, create, and test spins. They can be done entirely outside of Fedora. They can be created and hosted on their own sites, etc. F20 improved spins overall, but that was because of a concerted effort with our existing resources. If Fedora.next is going to succeed, those resources are already going to be overwhelmed with the 3 products. Spreading them thinner for little benefit in most cases seems irresponsible. So I am being pulled in both directions on this. One of the goals of agility is to facilitate more things being made from Fedora (at least that was a discussed goal at various times). I agree with that and pushing aside the best things we have built from Fedora now (understanding they have been problematic in various ways in the past) seems to work against that goal. I don't accept the blanket assertion that the spins have little benefit. Do we actually have any idea how many people install Fedora from spins? Irresponsible is bit loaded. I don't know that rel-eng will be overburdened by running the script that builds them. I also don't know that there aren't other creative arrangements that could be made to facilitate the creation and distribution of spins largely or entirely under the control of those creating them without pushing them entirely outside of Fedora infrastructure. I guess I'd like those active in the spin community to make suggestions here. I imagine spins and other new creations built on Fedora to be things the project wants to promote, not push away. The reality may be that we can't do what we do now in support of spins, but I hope we can continue to do something that helps and encourages those making them. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Wed, 29 Jan 2014 16:03:08 -0500 Stephen Gallagher sgall...@redhat.com wrote: Well, one of the things we need to decide is whether we address Spins at all during the F21 timeframe. I suspect that QA will ask for a reprieve on that score. By Spins do you mean 1: http://fedoraproject.org/en/get-fedora#desktops or 2: http://fedoraproject.org/en/get-fedora#spins ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On 01/29/2014 09:33 PM, Josh Boyer wrote: On Wed, Jan 29, 2014 at 4:03 PM, inode0 ino...@gmail.com wrote: On Wed, Jan 29, 2014 at 2:57 PM, H. Guémar hgue...@fedoraproject.org wrote: Hi, I think we should keep spins as long as we don't have a formal process to accept new products. Something like = proposal = crop (aka product-to-be) = validation = product When we'll have that, drop the whole spin thing, any spin that isn't fit to be a product should be reclassified as remix. Why do we expect spins to be any more official products than they are now? I can't really imagine this ever working. Do you imagine a day where Fedora has 20, 30, 50 official products? I don't. I'd rather not confuse what is made from Fedora bits with what is based on Fedora bits but includes other bits. The remix branding does not seem appropriate for spins that are made purely from Fedora bits. That's fair. From a resource and quality perspective though, I'd rather not burden rel-eng and QA with having to maintain, create, and test spins. You do realize that you are faced with exact same problem as are with spins with wg product(s) and the resolution is the same. The sub-community producing it will have to put up the QA resources to manage and test whatever is put on top of core/base and I would think the same applies from releng perspective. To put this differently as I see it both communities QA and Releng only serve as overseers and guiding forces but wont put *any* resources themselves into spins nor wg product(s) since those resources will have to come from the sub communities producing spins or wg product(s). JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Wed, Jan 29, 2014 at 5:01 PM, inode0 ino...@gmail.com wrote: On Wed, Jan 29, 2014 at 3:33 PM, Josh Boyer jwbo...@fedoraproject.org wrote: On Wed, Jan 29, 2014 at 4:03 PM, inode0 ino...@gmail.com wrote: On Wed, Jan 29, 2014 at 2:57 PM, H. Guémar hgue...@fedoraproject.org wrote: Hi, I think we should keep spins as long as we don't have a formal process to accept new products. Something like = proposal = crop (aka product-to-be) = validation = product When we'll have that, drop the whole spin thing, any spin that isn't fit to be a product should be reclassified as remix. Why do we expect spins to be any more official products than they are now? I can't really imagine this ever working. Do you imagine a day where Fedora has 20, 30, 50 official products? I don't. I'd rather not confuse what is made from Fedora bits with what is based on Fedora bits but includes other bits. The remix branding does not seem appropriate for spins that are made purely from Fedora bits. That's fair. From a resource and quality perspective though, I'd rather not burden rel-eng and QA with having to maintain, create, and test spins. They can be done entirely outside of Fedora. They can be created and hosted on their own sites, etc. F20 improved spins overall, but that was because of a concerted effort with our existing resources. If Fedora.next is going to succeed, those resources are already going to be overwhelmed with the 3 products. Spreading them thinner for little benefit in most cases seems irresponsible. So I am being pulled in both directions on this. One of the goals of agility is to facilitate more things being made from Fedora (at least that was a discussed goal at various times). I agree with that and pushing aside the best things we have built from Fedora now (understanding they have been problematic in various ways in the past) seems to work against that goal. There is a difference between things being made from Fedora and Fedora making things for people. I'm concerned that Spins have transformed into the latter. There is nothing preventing someone from taking Fedora and making a spin and hosting it themselves. I don't accept the blanket assertion that the spins have little benefit. Do we actually have any idea how many people install Fedora from spins? We had download statistics at one point that showed most of the spins were not downloaded much. Maybe the Infra group still collects them. Irresponsible is bit loaded. I don't know that rel-eng will be overburdened by running the script that builds them. I also don't know that there aren't other creative arrangements that could be made to facilitate the creation and distribution of spins largely or entirely under the control of those creating them without pushing them entirely outside of Fedora infrastructure. Growing rel-eng could help with the resource issues (similar with QA). If the people doing spins want to step up and do that, then some of my concerns are alleviated. At least in terms of people resources. I guess I'd like those active in the spin community to make suggestions here. I imagine spins and other new creations built on Fedora to be things the project wants to promote, not push away. The reality may be that we can't do what we do now in support of spins, but I hope we can continue to do something that helps and encourages those making them. Promote is an interesting word there too. I think we want to encourage people to create things with and on Fedora. I'm not sure _promoting_ those things simply because someone made this is the right idea with Fedora.next. This isn't specific to Spins though. It's part of a much larger branding conversation that we need to have. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On 01/29/2014 10:01 PM, inode0 wrote: So I am being pulled in both directions on this. One of the goals of agility is to facilitate more things being made from Fedora (at least that was a discussed goal at various times). I agree with that and pushing aside the best things we have built from Fedora now (understanding they have been problematic in various ways in the past) seems to work against that goal. The fact is the .next and wg's are working *against* making Fedora agile again so there is no wonders you are conflicted and you seem to have realized that's spins are not being considered the *right* products ( while the output from the wg's are ). Just bare in mind in relation with Fedora.next and the WG effort that thou you are making a change it does not mean you are making progress JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Wed, 2014-01-29 at 16:33 -0500, Josh Boyer wrote: On Wed, Jan 29, 2014 at 4:03 PM, inode0 ino...@gmail.com wrote: On Wed, Jan 29, 2014 at 2:57 PM, H. Guémar hgue...@fedoraproject.org wrote: Hi, I think we should keep spins as long as we don't have a formal process to accept new products. Something like = proposal = crop (aka product-to-be) = validation = product When we'll have that, drop the whole spin thing, any spin that isn't fit to be a product should be reclassified as remix. Why do we expect spins to be any more official products than they are now? I can't really imagine this ever working. Do you imagine a day where Fedora has 20, 30, 50 official products? I don't. I'd rather not confuse what is made from Fedora bits with what is based on Fedora bits but includes other bits. The remix branding does not seem appropriate for spins that are made purely from Fedora bits. That's fair. From a resource and quality perspective though, I'd rather not burden rel-eng and QA with having to maintain, create, and test spins. They can be done entirely outside of Fedora. They can be created and hosted on their own sites, etc. F20 improved spins overall, but that was because of a concerted effort with our existing resources. If Fedora.next is going to succeed, those resources are already going to be overwhelmed with the 3 products. Spreading them thinner for little benefit in most cases seems irresponsible. Hi, Spin maintainer here. 1) Are spins useful question: I have gotten many emails from users that enjoy spins. I was also thinking about introducing 2 new spins for F21 (Cinnamon and Enlightenment). Spins offer a things that the netinstall and DVD don't: 1) Boot Fedora without installing it 2) Install fedora without having to download the entire DVD or connect to the internet. 2) In regards to the resources consumed by spins: I disagree that Spins use a lot of releng/QA resources. Releng has scripts to compose spins. They have been doing this every release for a long time. QAing a spin is simple. Grab the ISO, boot it. Does it work? Does installation complete. QA done. Design team is also involved in the spins process. They create artwork and the webpage for the spin itself. Again, I don't think that the resource consumption is significant at all 3) Should spins be made into remixes. Absolutely not in my opinion. This would probably just kill them off. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Wed, Jan 29, 2014 at 4:11 PM, Josh Boyer jwbo...@fedoraproject.org wrote: On Wed, Jan 29, 2014 at 5:01 PM, inode0 ino...@gmail.com wrote: So I am being pulled in both directions on this. One of the goals of agility is to facilitate more things being made from Fedora (at least that was a discussed goal at various times). I agree with that and pushing aside the best things we have built from Fedora now (understanding they have been problematic in various ways in the past) seems to work against that goal. There is a difference between things being made from Fedora and Fedora making things for people. I'm concerned that Spins have transformed into the latter. There is nothing preventing someone from taking Fedora and making a spin and hosting it themselves. Fedora isn't making the spins for people. The spins are putting up with Fedora's current requirements that this group do X and that group do Y on top of what the spins do in order to host the spins. At least that is my impression of how it has worked so far. And, of course, there are things preventing people from just going off and doing everything on their own. The new Workstation product could make that choice too and make the Workstation product they envision outside of Fedora. I don't accept the blanket assertion that the spins have little benefit. Do we actually have any idea how many people install Fedora from spins? We had download statistics at one point that showed most of the spins were not downloaded much. Maybe the Infra group still collects them. Those numbers were horrible but also not very informative. Approximately 150,000 copies of the desktop spins are distributed directly on pressed media each year and just that dwarfs the download numbers for the spins. Irresponsible is bit loaded. I don't know that rel-eng will be overburdened by running the script that builds them. I also don't know that there aren't other creative arrangements that could be made to facilitate the creation and distribution of spins largely or entirely under the control of those creating them without pushing them entirely outside of Fedora infrastructure. Growing rel-eng could help with the resource issues (similar with QA). If the people doing spins want to step up and do that, then some of my concerns are alleviated. At least in terms of people resources. I guess I'd like those active in the spin community to make suggestions here. I imagine spins and other new creations built on Fedora to be things the project wants to promote, not push away. The reality may be that we can't do what we do now in support of spins, but I hope we can continue to do something that helps and encourages those making them. Promote is an interesting word there too. I think we want to encourage people to create things with and on Fedora. I'm not sure _promoting_ those things simply because someone made this is the right idea with Fedora.next. This isn't specific to Spins though. It's part of a much larger branding conversation that we need to have. I agree and while it isn't what I said I did mean promote the idea of making stuff with Fedora. I suspect promoting that idea will involve examples of cool things made with Fedora though so it is muddled a bit. I completely agree about the branding conversation but I'm not sure we are ready to make some decisions without having the branding conversation first. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Wed, Jan 29, 2014 at 2:30 PM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apologies for the slightly alarmist $SUBJECT, but I want to make sure that this gets read by the appropriate groups. [snip] 1) Are Spins useful as they currently exist? There are many problems that have been noted in the Spins process, most notably that it is very difficult to get a Spin approved and then has no ongoing maintenance requiring it to remain functional. We've had Spins at times go through entire Fedora release cycles without ever being functional. Putting on my rel-eng hat I can say that any spin that fails to compose will be dropped. I believe we also encourage or even require the spin maintainers to test their spin as functional. (To work out if the spin succeeds to compose but fails to actually work) The idea is to encourage active spin process, inactive spins will auto retire by policy if they fail. Another aspect I worry about is the mirroring stuff. With the coming WGs I fear the rsync mirroring will grow very large, and spins are an attractive piece of fat to cut. Reducing size is something we worry about on the infra, rel-eng side of things. 2) Should Spins be eliminated entirely in favor of Fedora Remixes[1]. The effect here would be that Spins are no longer an official part of The Fedora Project but are instead projects unto themselves which are permitted to consume (possibly large) portions of our tools, packages and ecosystem. Maintenance and upkeep of these spins then becomes entirely the responsibility of the downstream community that constructs them and has no mandatory draw on Fedora's marketing, ambassadors or quality assurance resources. Again, from the rel-eng perspective... this proposal sounds nice. (removing spins in favor of remix) It would reduce the complexity of my work flow. So selfishly speaking removing spins sounds great. However, they are an important part of our community, and I'd feel sad to see them disappear. There is a nice aspect of them being partially hooked into the rel-eng process that adds value. The community comes together, spin maintainers have a list they talk to each other. We push them to provide quality product, etc. In my view a remix is something that contains stuff that Fedora cannot. Say for example, my chromebook remixes in F19... those broke with Fedora principles by using evil vendor tree kernels. So in my thinking that is what a remix is for. but spins 100% stay with the Fedora way of things, our four foundations or whatever. In my opinion the WGs are big giant uber-spins. [snip] ... -Jon Disnard FAS: parasense IRC: masta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On 29 January 2014 15:01, inode0 ino...@gmail.com wrote: On Wed, Jan 29, 2014 at 3:33 PM, Josh Boyer jwbo...@fedoraproject.org wrote: On Wed, Jan 29, 2014 at 4:03 PM, inode0 ino...@gmail.com wrote: On Wed, Jan 29, 2014 at 2:57 PM, H. Guémar hgue...@fedoraproject.org wrote: Hi, I think we should keep spins as long as we don't have a formal process to accept new products. Something like = proposal = crop (aka product-to-be) = validation = product When we'll have that, drop the whole spin thing, any spin that isn't fit to be a product should be reclassified as remix. Why do we expect spins to be any more official products than they are now? I can't really imagine this ever working. Do you imagine a day where Fedora has 20, 30, 50 official products? I don't. I'd rather not confuse what is made from Fedora bits with what is based on Fedora bits but includes other bits. The remix branding does not seem appropriate for spins that are made purely from Fedora bits. That's fair. From a resource and quality perspective though, I'd rather not burden rel-eng and QA with having to maintain, create, and test spins. They can be done entirely outside of Fedora. They can be created and hosted on their own sites, etc. F20 improved spins overall, but that was because of a concerted effort with our existing resources. If Fedora.next is going to succeed, those resources are already going to be overwhelmed with the 3 products. Spreading them thinner for little benefit in most cases seems irresponsible. So I am being pulled in both directions on this. One of the goals of agility is to facilitate more things being made from Fedora (at least that was a discussed goal at various times). I agree with that and pushing aside the best things we have built from Fedora now (understanding they have been problematic in various ways in the past) seems to work against that goal. I don't accept the blanket assertion that the spins have little benefit. Do we actually have any idea how many people install Fedora from spins? We have little knowledge about any installations. We can see that a lot of spins are downloaded, but there is no way after that to say whether Spin A, Spin B, or Regular DVD was the method a system was installed. Getting that information in the past has been one of those 'bridge too far' in privacy. Irresponsible is bit loaded. I don't know that rel-eng will be overburdened by running the script that builds them. I also don't know that there aren't other creative arrangements that could be made to facilitate the creation and distribution of spins largely or entirely under the control of those creating them without pushing them entirely outside of Fedora infrastructure. It is more than just running a script. There is the 'why the heck didn't this spin build this time when it did the last 20 times?' that shows up for about every spin at least once every release cycle. Most of that is usually a couple hours of work here and there, but it isn't 0 maintenance (and people like Dan Marshal have recently pitched in to help here ) Then there is that the QA of some of the spins is simple 'Does it boot?'/'Does it install' and other parts aren't like when a spin had various apps underneath the desktop didn't work but wasn't found until after we had shipped for a while. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Wed, Jan 29, 2014 at 4:39 PM, Jon jdisn...@gmail.com wrote: On Wed, Jan 29, 2014 at 2:30 PM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apologies for the slightly alarmist $SUBJECT, but I want to make sure that this gets read by the appropriate groups. [snip] 1) Are Spins useful as they currently exist? There are many problems that have been noted in the Spins process, most notably that it is very difficult to get a Spin approved and then has no ongoing maintenance requiring it to remain functional. We've had Spins at times go through entire Fedora release cycles without ever being functional. Putting on my rel-eng hat I can say that any spin that fails to compose will be dropped. I believe we also encourage or even require the spin maintainers to test their spin as functional. (To work out if the spin succeeds to compose but fails to actually work) The idea is to encourage active spin process, inactive spins will auto retire by policy if they fail. Another aspect I worry about is the mirroring stuff. With the coming WGs I fear the rsync mirroring will grow very large, and spins are an attractive piece of fat to cut. You probably didn't mean for that to sound so negative but a piece of fat to cut is how rel-eng thinks of spins? I recall being assured at the beginning that some interested company was willing to provide the necessary support for us to give this a fair try. Reducing size is something we worry about on the infra, rel-eng side of things. That is pragmatic but be a dreamer while dreaming is in style. Give worrying about how to increase the capacity of infra a try instead. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On 29 January 2014 15:49, inode0 ino...@gmail.com wrote: On Wed, Jan 29, 2014 at 4:39 PM, Jon jdisn...@gmail.com wrote: On Wed, Jan 29, 2014 at 2:30 PM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apologies for the slightly alarmist $SUBJECT, but I want to make sure that this gets read by the appropriate groups. [snip] 1) Are Spins useful as they currently exist? There are many problems that have been noted in the Spins process, most notably that it is very difficult to get a Spin approved and then has no ongoing maintenance requiring it to remain functional. We've had Spins at times go through entire Fedora release cycles without ever being functional. Putting on my rel-eng hat I can say that any spin that fails to compose will be dropped. I believe we also encourage or even require the spin maintainers to test their spin as functional. (To work out if the spin succeeds to compose but fails to actually work) The idea is to encourage active spin process, inactive spins will auto retire by policy if they fail. Another aspect I worry about is the mirroring stuff. With the coming WGs I fear the rsync mirroring will grow very large, and spins are an attractive piece of fat to cut. You probably didn't mean for that to sound so negative but a piece of fat to cut is how rel-eng thinks of spins? I recall being assured at the beginning that some interested company was willing to provide the necessary support for us to give this a fair try. How long is a fair try? It would help to define that before people go on a rant about doing it for a couple of years now. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Wed, Jan 29, 2014 at 5:19 PM, Stephen John Smoogen smo...@gmail.com wrote: On 29 January 2014 15:49, inode0 ino...@gmail.com wrote: On Wed, Jan 29, 2014 at 4:39 PM, Jon jdisn...@gmail.com wrote: Putting on my rel-eng hat I can say that any spin that fails to compose will be dropped. I believe we also encourage or even require the spin maintainers to test their spin as functional. (To work out if the spin succeeds to compose but fails to actually work) The idea is to encourage active spin process, inactive spins will auto retire by policy if they fail. Another aspect I worry about is the mirroring stuff. With the coming WGs I fear the rsync mirroring will grow very large, and spins are an attractive piece of fat to cut. You probably didn't mean for that to sound so negative but a piece of fat to cut is how rel-eng thinks of spins? I recall being assured at the beginning that some interested company was willing to provide the necessary support for us to give this a fair try. How long is a fair try? It would help to define that before people go on a rant about doing it for a couple of years now. I meant giving our new adventure a fair try, not giving spins a fair try. I also really did not mean to go on a rant. I think we have a group that sees little benefit to spins and another that sees a lot of benefit to spins. The former wants to get rid of them, the latter wants to keep them. We won't ever quantify the amount of benefit they bring so we are probably at a stalemate on the benefit question. On the resources question we can either ask for them in order to allow us to do both or we can look for new ways to reduce the cost of spins to those complaining about the burden they impose. I'm open to either of those approaches. Getting rid of them to me would be an admission that are unwilling or unable to continue supporting something that is valuable to our users and our community (just my subjective opinion and I know not everyone shares it). John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Wed, Jan 29, 2014 at 6:48 PM, inode0 ino...@gmail.com wrote: On Wed, Jan 29, 2014 at 5:19 PM, Stephen John Smoogen smo...@gmail.com wrote: On 29 January 2014 15:49, inode0 ino...@gmail.com wrote: On Wed, Jan 29, 2014 at 4:39 PM, Jon jdisn...@gmail.com wrote: Putting on my rel-eng hat I can say that any spin that fails to compose will be dropped. I believe we also encourage or even require the spin maintainers to test their spin as functional. (To work out if the spin succeeds to compose but fails to actually work) The idea is to encourage active spin process, inactive spins will auto retire by policy if they fail. Another aspect I worry about is the mirroring stuff. With the coming WGs I fear the rsync mirroring will grow very large, and spins are an attractive piece of fat to cut. You probably didn't mean for that to sound so negative but a piece of fat to cut is how rel-eng thinks of spins? I recall being assured at the beginning that some interested company was willing to provide the necessary support for us to give this a fair try. How long is a fair try? It would help to define that before people go on a rant about doing it for a couple of years now. I meant giving our new adventure a fair try, not giving spins a fair try. I also really did not mean to go on a rant. I think we have a group that sees little benefit to spins and another that sees a lot of benefit to spins. The former wants to get rid of them, the latter wants to keep them. We won't ever quantify the amount of benefit they bring so we are probably at a stalemate on the benefit question. I consider myself squarely in the middle of those two camps. I think they have value to people. I think they fill a niche, however large or small it might be. I also think they can be done by the people wishing to provide them without relying on Fedora resources for hosting and creation (outside of leveraging existing packages and repositories). I don't consider that getting rid of them at all. On the contrary, I think it lets people have more control over their spins, allows them to refresh them as they see fit throughout the release, and allows them to market and promote them beyond a token mention on a Fedora website. Is it asking spin owners to shoulder more of the burden than today? Yes. Is it unreasonable to ask that of them? In my opinion, no. Does it provide them with more freedom while still gaining the majority of the benefit of leveraging Fedora? In my opinion, yes. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On 29 January 2014 22:44, Stephen John Smoogen smo...@gmail.com wrote: On 29 January 2014 15:01, inode0 ino...@gmail.com wrote: On Wed, Jan 29, 2014 at 3:33 PM, Josh Boyer jwbo...@fedoraproject.org wrote: On Wed, Jan 29, 2014 at 4:03 PM, inode0 ino...@gmail.com wrote: On Wed, Jan 29, 2014 at 2:57 PM, H. Guémar hgue...@fedoraproject.org Something like = proposal = crop (aka product-to-be) = validation = product When we'll have that, drop the whole spin thing, any spin that isn't fit to be a product should be reclassified as remix. I can't really imagine this ever working. Do you imagine a day where Fedora has 20, 30, 50 official products? I don't. That's fair. From a resource and quality perspective though, I'd rather not burden rel-eng and QA with having to maintain, create, and test spins. They can be done entirely outside of Fedora. They can be created and hosted on their own sites, etc. I don't accept the blanket assertion that the spins have little benefit. Do we actually have any idea how many people install Fedora from spins? It is more than just running a script. There is the 'why the heck didn't this spin build this time when it did the last 20 times?' that shows up for about every spin at least once every release cycle. Most of that is usually a couple hours of work here and there, but it isn't 0 maintenance (and people like Dan Marshal have recently pitched in to help here ) Then there is that the QA of some of the spins is simple 'Does it boot?'/'Does it install' and other parts aren't like when a spin had various apps underneath the desktop didn't work but wasn't found until after we had shipped for a while. ruthlessly snipped the above down to the points I think I might respond to I think the last two releases, certainly the last release, there's been more focus on shifting that responsibility. If you look at the spins release page on https://fedoraproject.org/wiki/Releases/20/Spins that matrix was filled in by spin participants on the understanding that spins that didn't follow that process (and ensure successful compose) would be dropped. Which is a good model if spins are to continue as-is. Regardless of the task/technology split most focus on a set of packages (really, that's all a spin *can* do) and this means they get a bit more testing by people who know the domain. Regardless, that task-technology split is a little important. As Dan Mashal pointed out the 'live system' is a spin thing. That's quite good for new users (Ubuntu's early popularity was partly down to pioneering this), especially as a promotion for different desktops or particular things like security/rescue discs. Going down the everything is a product route means you have to decide whether 'Desktop' means gnome and whether kde, cinnamon, xfce and the rest could ever be products (probably not all of them if the overhead is going to be more than for a spin). From the trenches, over at Jam there is some discussion over whether it's worth continuing with it as a spin anyway. (I don't think I'm selling anyone out here, since the discussion is on a fedora mailing list...) For what we're doing the scope of a spin is a bit limiting in any case and at the same time we're actually making it harder for people using stock fedora who'd just like a package collection they could install. So, to contradict my first two paragraphs, there are a few spins that could go, perhaps even willingly, but there are some that are still important. Two thoughts: 1. Is there scope for a spin to be a particular sub-focus of a product? Desktop (all) . desktop gnome . desktop kde . desktop twm (maybe not) Server (all) . server web . server fileserver (or whatever might make sense) The idea being that everything under one product should be a subdivision of what would be included anyway. I realise there's the potential there to snowball again. 2. Does the new application gui thing understand package groups or collections? Without wishing to spread the whole cli vs gui package debate (it's quite happy in the other thread), it seems it might be relatively intuitive for someone to understand a 'give me a whole lot of music applications' button. That might provide the equivalent of what things like design and jam do currently (with the exception of availability to areas with poor net access). -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On 29 January 2014 23:58, Josh Boyer jwbo...@fedoraproject.org wrote: I consider myself squarely in the middle of those two camps. I think they have value to people. I think they fill a niche, however large or small it might be. I also think they can be done by the people wishing to provide them without relying on Fedora resources for hosting and creation (outside of leveraging existing packages and repositories). I don't consider that getting rid of them at all. On the contrary, I think it lets people have more control over their spins, allows them to refresh them as they see fit throughout the release, and allows them to market and promote them beyond a token mention on a Fedora website. Some care is needed, if there are things getting packaged to fill a role in a spin they may disappear from Fedora if the spin in question does. -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Wed, Jan 29, 2014 at 5:48 PM, inode0 ino...@gmail.com wrote: On Wed, Jan 29, 2014 at 5:19 PM, Stephen John Smoogen smo...@gmail.com wrote: On 29 January 2014 15:49, inode0 ino...@gmail.com wrote: On Wed, Jan 29, 2014 at 4:39 PM, Jon jdisn...@gmail.com wrote: Putting on my rel-eng hat I can say that any spin that fails to compose will be dropped. I believe we also encourage or even require the spin maintainers to test their spin as functional. (To work out if the spin succeeds to compose but fails to actually work) The idea is to encourage active spin process, inactive spins will auto retire by policy if they fail. Another aspect I worry about is the mirroring stuff. With the coming WGs I fear the rsync mirroring will grow very large, and spins are an attractive piece of fat to cut. You probably didn't mean for that to sound so negative but a piece of fat to cut is how rel-eng thinks of spins? I recall being assured at the beginning that some interested company was willing to provide the necessary support for us to give this a fair try. How long is a fair try? It would help to define that before people go on a rant about doing it for a couple of years now. I meant giving our new adventure a fair try, not giving spins a fair try. I also really did not mean to go on a rant. I think we have a group that sees little benefit to spins and another that sees a lot of benefit to spins. The former wants to get rid of them, the latter wants to keep them. We won't ever quantify the amount of benefit they bring so we are probably at a stalemate on the benefit question. On the resources question we can either ask for them in order to allow us to do both or we can look for new ways to reduce the cost of spins to those complaining about the burden they impose. I'm open to either of those approaches. Getting rid of them to me would be an admission that are unwilling or unable to continue supporting something that is valuable to our users and our community (just my subjective opinion and I know not everyone shares it). John There is a lot of value in the desktop spins. Most of the folks I know personally use one spin or another. I myself REMIX all of the desktop spins for my embedded stuff, and I personally use MATE and/or XFCE. It would be disappointing to drop the spins now that we have got them to such a lofty place in our community. We now hold them accountable to ensure quality, and the composes are mostly automated into koji, so burden to keep them going is not much. Mostly the space they consume is a thing to consider. I'd like to imagine a day when the KDE spin replaces gnome3 as our default desktop! Or even XFCE or whatever Do not believe Gnome3 should have lock to the default desktop offering. I would even go so far to propose a vote from the community every once in a while to decide what is our so-called default. And repeat that vote every once in a while... based on merits. So I'd rather not see the desktop spins go away. Not sure about the other spins, the pen testing, or software-stack type things Since the burden is mostly storage, and storage is cheap... I tend to think we can keep them going for now. There is the part about mirroring, and the time it takes to compose these things. My two cents. -Jon Disnard FAS: parasense IRC: masta -- -Jon -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On 30 January 2014 00:01, Ian Malone ibmal...@gmail.com wrote: Two thoughts: 1. Is there scope for a spin to be a particular sub-focus of a product? Desktop (all) . desktop gnome . desktop kde . desktop twm (maybe not) Server (all) . server web . server fileserver (or whatever might make sense) The idea being that everything under one product should be a subdivision of what would be included anyway. I realise there's the potential there to snowball again. 2. Does the new application gui thing understand package groups or collections? Without wishing to spread the whole cli vs gui package debate (it's quite happy in the other thread), it seems it might be relatively intuitive for someone to understand a 'give me a whole lot of music applications' button. That might provide the equivalent of what things like design and jam do currently (with the exception of availability to areas with poor net access). And pie in the sky for number 3: Easier composes so people can share things like embedded system spins without adding to mirroring or QA overhead. (Composes are not incredibly difficult if you know what you're doing, but that means knowing about things like needing to get pre-release kickstarts from git, set up a mock root (or ideally VM), mess about with selinux). Yes you can say host it outside fedora, but it's much easier for someone to put a .ks up on a blog, github or google code than find decent hosting for a 500MB image. (Also I've realised I didn't use the word 'regardless' nearly enough in my last email.) -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
Hello, - Original Message - From: inode0 ino...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, January 30, 2014 8:01:15 AM Subject: Re: Fedora.NEXT Products and the fate of Spins snip .. I guess I'd like those active in the spin community to make suggestions here. I imagine spins and other new creations built on Fedora to be things the project wants to promote, not push away. The reality may be that we can't do what we do now in support of spins, but I hope we can continue to do something that helps and encourages those making them. I am the maintainer of the Fedora Scientific Spin and I speak wearing my Fedora community member hat (not RH employee). A bit of background will put things into better perspective. The Fedora Scientific Spin was first released during the Fedora 16 release cycle. I failed to fix a build failure due to package dep. issues during the F19 release cycle, so, we have had 4 releases since then. I haven't been bombarded with emails from users, but I have had emails from users who find it useful and have requested for things to be included (which couldn't be included for other reasons). One good thing to come out of the failed F19 release was that I came to know that people do care about Fedora Scientific, since I had potential users looking to download it, but didn't find an ISO. Now, I will begin the pitch for Fedora Scientific to exist. I think Fedora Scientific is a good thing to have in the Open Source scientific computing ecosystem. Thanks to the packagers, we have all the tools/libraries that the ecosystem boasts of ready to use in Fedora Scientific [1]. We may be even attracting users to Fedora due to it (no facts to back it up), since the closest distro that aims to achieve what Fedora Scientific does is Scientific Linux. Some more points re. specific issues pointed out and what can be done about it: - Starting with Fedora 20, all the spin maintainers were supposed to fill a matrix (as someone else already pointed out) which was a validation that the test composes, the RCs, alphas and the betas worked correctly (installation, applications packaged, etc.). Overall I think it was a good thing to have as it helped the spin maintainers to fix issues with their builds. So, +1 to that and we should continue it. [2] - I am not exactly sure about the cost of doing the builds, checking why they may have failed, etc. So, perhaps, this can be something that my be off-shored to the spin maintainers? It increases our responsibilities, but helps lighten the load from rel-eng. - In my moment of Is Fedora Scientific actually being used? or, more recently, Is it even a contribution worth a Fedora 10-year anniversary T-shirt?, I have thought that perhaps, all the packages that Fedora Scientific ships can all be made into a yum group and the user can just do yum groupinstall fedora-scientific. Yeah, perhaps it can be done, but I hope we don't have to, since it still needs the user to download a whole bunch of stuff after the install, the exact problem I wanted to solve using Fedora Scientific. Overall, I think Fedora Spins are a good thing to have, and we must address the question of how we can keep them by sharing the work that goes into having them, rather than eliminating them or converting them into Remixes. Best, Amit. [1] http://fedora-scientific.readthedocs.org/en/latest/ (Needs a lot more work to make it complete) [2] https://fedoraproject.org/wiki/Scientific_Packages_Testing -- Amit Saha http://echorand.me -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
Spin maintainer as well sharing Dan's view about spin used to display Fedora uses of FOSS applications without needing to download either DVD or netinstall. Remixes like Korora for example are completely different because of the use of software outside Fedora repository. I think Workstation Group should consult spin maintainers for those issues before moving on. Luya -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On 29 January 2014 16:48, inode0 ino...@gmail.com wrote: On Wed, Jan 29, 2014 at 5:19 PM, Stephen John Smoogen smo...@gmail.com wrote: On 29 January 2014 15:49, inode0 ino...@gmail.com wrote: On Wed, Jan 29, 2014 at 4:39 PM, Jon jdisn...@gmail.com wrote: Putting on my rel-eng hat I can say that any spin that fails to compose will be dropped. I believe we also encourage or even require the spin maintainers to test their spin as functional. (To work out if the spin succeeds to compose but fails to actually work) The idea is to encourage active spin process, inactive spins will auto retire by policy if they fail. Another aspect I worry about is the mirroring stuff. With the coming WGs I fear the rsync mirroring will grow very large, and spins are an attractive piece of fat to cut. You probably didn't mean for that to sound so negative but a piece of fat to cut is how rel-eng thinks of spins? I recall being assured at the beginning that some interested company was willing to provide the necessary support for us to give this a fair try. How long is a fair try? It would help to define that before people go on a rant about doing it for a couple of years now. I meant giving our new adventure a fair try, not giving spins a fair try. I also really did not mean to go on a rant. My apologies, we were talking about spins so I figured that was what you were asking. In any case, it will be an important point for us to pin down for the .Next.. how long are we committed to doing it and figuring out it is working? I figure a minimum of 18-24 months would be needed but if it needs to be longer then it needs to be guessed at so that expectations up and down the tree are the same. I think we have a group that sees little benefit to spins and another that sees a lot of benefit to spins. The former wants to get rid of them, the latter wants to keep them. We won't ever quantify the amount of benefit they bring so we are probably at a stalemate on the benefit question. Well to quantify it, we need to measure it. First off that probably means tieing in some sort of 'check-in' counter to know what ones are run, how much they are run, how many are installed, and how long are they installed. That gets pretty intrusive to a lot of people. Then we make it opt in and we get a count so low and manipulative that it becomes worthless otherwise. On the resources question we can either ask for them in order to allow us to do both or we can look for new ways to reduce the cost of spins to those complaining about the burden they impose. I'm open to either of those approaches. Getting rid of them to me would be an admission that are unwilling or unable to continue supporting something that is valuable to our users and our community (just my subjective opinion and I know not everyone shares it). From a pure infrastructure point of view, the spins have the following major costs: 1) Disk space. Disks are not cheap in the world of data-access ready disks. The 4 TB SATAs sound nice but when you try serving FTP off them you find that you have to raid more than you did of the expensive SAS disks and your effective amount of disk space you can use is in the range of 1-10% of the disk space before you end up losing to speed of access, time to send, and general disk drive latency. After that you have to replace the disks quite often as they fail much sooner than any manufacturer says they will. 2) Our disk space goal for mirrors is 1 TB of disk space for the main releases. That means N-1, N, and N+1 (alpha/beta/release). We skim that and every iso, architecture, and extra makes it harder to keep. 3) Net access. Large file sharing (500+ MB iso) costs more than small file sharing (rpms). It takes up 'streams' for longer in modern routers/firewalls and thus you can fill up your pipe without saturating your pipe. This used to be gotten around via various file sharing mechanisms but these are increasingly getting shut down at the ISP and Universities for any content. 4) Many mirrors skip the spins. That means the cost gets eaten up by those that do and then they run into the top issues above which makes it more likely they don't want to mirror them. These are costs that all the mirrors have to pay on this and those are things that are 'hidden' when people think 'oh we can make another spin, it only takes me an hour to spin it up and test it.' By the way, I am not anti-spin and consider the above costs to be things that can't be paid now or in the future.. I am just wanting people to realize that even beyond releng/qa resources this is not a 'freebie'. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Wed, Jan 29, 2014 at 8:12 PM, Luya Tshimbalanga l...@fedoraproject.org wrote: Spin maintainer as well sharing Dan's view about spin used to display Fedora uses of FOSS applications without needing to download either DVD or netinstall. Remixes like Korora for example are completely different because of the use of software outside Fedora repository. I think Workstation Group should consult spin maintainers for those issues before moving on. I'm unsure of why you're addressing the Workstation WG. This discussion was generated by FESCo, not the Workstation WG. The Workstation WG has made no proposals or comments around Spins at all. If you mean you wish to collaborate with the Workstation WG on doing alternative spins, then great. Please bring that up on the desktop@ list. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Locale-Msgfmt/el6] build for EPEL
commit b25c7db824d00c05f96598912dd69272d42e4a4d
Author: Ruediger Landmann r.landm...@redhat.com
Date: Thu Jan 30 11:21:41 2014 +1000
build for EPEL
perl-Locale-Msgfmt.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Locale-Msgfmt.spec b/perl-Locale-Msgfmt.spec
index 6a4e549..b635da3 100644
--- a/perl-Locale-Msgfmt.spec
+++ b/perl-Locale-Msgfmt.spec
@@ -1,6 +1,6 @@
Name: perl-Locale-Msgfmt
Version:0.15
-Release:9%{?dist}
+Release:10%{?dist}
Summary:Compile .po files to .mo files
License:GPL+ or Artistic
Group: Development/Libraries
@@ -48,6 +48,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Jan 30 2014 Rüdiger Landmann rlandm...@redhat.com - 0.15-10
+- build for EPEL
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.15-9
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
--
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: Fedora.NEXT Products and the fate of Spins
Hi, I'm just throwing jigdo into the mix[1]. From the infrastructure side, jigdo only needs templates to be hosted. It picks rpms from the mirrors just like $package_manager. Would it be feasible to host jigdo files for spins instead of ISO files? The users would be downloading the same amount, only they'll be downloading individual packages instead of the finished ISO. It comes in handy if you're downloading more than one spin, since the already downloaded packages needn't be downloaded again. Issues with this: 1. I'm not certain if jigdo composes liveCDs 2. Upstream seems dead[2] 3. Does it run on windows/mac/not linux? 4. QA? A brain fart at best, lots of details to be fleshed out. There's also Dorrie[3], but I don't think it solves any issues. Rather, it'll probably increase infra/QA load since it is meant to be a generate an ISO on demand service. [1] http://fedoraproject.org/wiki/Features/JigdoRelease [2] http://atterer.net/jigdo/ [3] https://fedoraproject.org/wiki/Remixes_Web_Interface -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Thu, 2014-01-30 at 12:47 +1100, Ankur Sinha wrote: 2. Upstream seems dead[2] Not really dead moved from .net to .org http://atterer.org/jigdo/ We've got jigdo-gui.x86_64 : Jigdo graphical interface pyjigdo.noarch : Python version of Jigdo, slightly modified jigdo.x86_64 : Ease distribution of large files over the Internet in the repos. -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Thu, 2014-01-30 at 12:47 +1100, Ankur Sinha wrote: I'm just throwing jigdo into the mix[1]. And pyjigdo: https://fedorahosted.org/pyjigdo/ -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Nightly builds of DNF available
On Wed, 2014-01-29 at 12:11 -0500, Radek Holy wrote: I have just added the metadata creation. Good point, thank you. Is it OK to file bugs at bugzilla for nightlies, or should we only file bugs for the versions pushed to Fedora? This repo file works for me: [dnf-nightlies] name=DNF nightlies for $releasever - $basearch baseurl=http://jenkins.cloud.fedoraproject.org/job/DNF/lastSuccessfulBuild/artifact/fedora-$releasever-$basearch-build/ cost=3000 enabled=1 skip_if_unavailable=True gpgcheck=0 It gives me: Repo-id : dnf-nightlies Repo-name: DNF nightlies for Fedora 20 - x86_64 Repo-revision: 1391031363 Repo-updated : Thu Jan 30 08:36:03 2014 Repo-pkgs: 26 Repo-size: 6.9 M Repo-baseurl : http://jenkins.cloud.fedoraproject.org/job/DNF/lastSuccessfulBuild/artifact/fedora-20-x86_64-build/ Repo-expire : 172,800 second(s) (last: Thu Jan 30 15:07:09 2014) Repo-filename: ///etc/yum.repos.d/dnf-nightlies.repo -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Wed, 2014-01-29 at 16:33 -0500, Josh Boyer wrote: I'd rather not confuse what is made from Fedora bits with what is based on Fedora bits but includes other bits. The remix branding does not seem appropriate for spins that are made purely from Fedora bits. That's fair. From a resource and quality perspective though, I'd rather not burden rel-eng and QA with having to maintain, create, and test spins. The 'burden' they create on QA is precisely zero, as we explicitly do not block releases on spins other than desktop and KDE. I don't believe releng considers the spins much of a burden, either - it's more just that they don't like building and pushing out stuff that no-one's even done a sanity check on. However, we have several high quality spins that people *do* care about and *do* test: at least the desktop spins, but I know for e.g. finalzone puts a lot of work into the design spin. I think it's fairly presumptuous to suggest chucking all that stuff in favour of something that doesn't even *exist* yet. F20 improved spins overall, but that was because of a concerted effort with our existing resources. If Fedora.next is going to succeed, those resources are already going to be overwhelmed with the 3 products. Again, there is no 'burden' on QA due to spins. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Thu, Jan 30, 2014 at 9:42 AM, Adam Williamson awill...@redhat.comwrote: On Wed, 2014-01-29 at 16:33 -0500, Josh Boyer wrote: I'd rather not confuse what is made from Fedora bits with what is based on Fedora bits but includes other bits. The remix branding does not seem appropriate for spins that are made purely from Fedora bits. That's fair. From a resource and quality perspective though, I'd rather not burden rel-eng and QA with having to maintain, create, and test spins. The 'burden' they create on QA is precisely zero, as we explicitly do not block releases on spins other than desktop and KDE. I don't believe releng considers the spins much of a burden, either - it's more just that they don't like building and pushing out stuff that no-one's even done a sanity check on. However, we have several high quality spins that people *do* care about and *do* test: at least the desktop spins, but I know for e.g. finalzone puts a lot of work into the design spin. I think it's fairly presumptuous to suggest chucking all that stuff in favour of something that doesn't even *exist* yet. F20 improved spins overall, but that was because of a concerted effort with our existing resources. If Fedora.next is going to succeed, those resources are already going to be overwhelmed with the 3 products. Again, there is no 'burden' on QA due to spins. As a user of Fedora I like to say that Fedora spins give so much value to Fedora. I know a lot of people who use spins rather than the default Gnome-desktop-Live. Please don't gutter the spins ! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Wed, 2014-01-29 at 18:17 -0700, Stephen John Smoogen wrote: 1) Disk space. Disks are not cheap in the world of data-access ready disks. The 4 TB SATAs sound nice but when you try serving FTP off them you find that you have to raid more than you did of the expensive SAS disks and your effective amount of disk space you can use is in the range of 1-10% of the disk space before you end up losing to speed of access, time to send, and general disk drive latency. After that you have to replace the disks quite often as they fail much sooner than any manufacturer says they will. 2) Our disk space goal for mirrors is 1 TB of disk space for the main releases. That means N-1, N, and N+1 (alpha/beta/release). We skim that and every iso, architecture, and extra makes it harder to keep. 3) Net access. Large file sharing (500+ MB iso) costs more than small file sharing (rpms). It takes up 'streams' for longer in modern routers/firewalls and thus you can fill up your pipe without saturating your pipe. This used to be gotten around via various file sharing mechanisms but these are increasingly getting shut down at the ISP and Universities for any content. 4) Many mirrors skip the spins. That means the cost gets eaten up by those that do and then they run into the top issues above which makes it more likely they don't want to mirror them. These are costs that all the mirrors have to pay on this and those are things that are 'hidden' when people think 'oh we can make another spin, it only takes me an hour to spin it up and test it.' By the way, I am not anti-spin and consider the above costs to be things that can't be paid now or in the future.. I am just wanting people to realize that even beyond releng/qa resources this is not a 'freebie'. Of course, another way of looking at this is to see that all these things are the work we would be downloading onto several disparate groups, who would almost certainly not be capable of doing it as well and efficiently as Fedora releng is, if we decided to wash our hands of spins. jwb has tried to characterize this as an 'opportunity' for spins, but I really don't think that washes. It's much more a case of us dumping a whole lot of extra work onto any who wants to maintain a spin: * Get a domain * Get a proper SSL cert for your domain * Figure out a build process - hack up some scripts which inevitably grow into a baroque horror? Deploy your own koji? * Figure out a QA process (we have provided a QA process for spins; this cost us - well, me, personally - a few hours I was happy to spend several releases ago, and it's in place and it works) * Cover the costs of hosting, or convince someone to distribute your bits * Do all your own marketing * Somehow try to make sure that tools like liveusb-creator include your bits I'm not sure I can imagine a spin maintainer who would be *happy* about all this. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Nightly builds of DNF available
On Thu, 2014-01-30 at 5:11:31 AM, Ankur Sinha wrote: Is it OK to file bugs at bugzilla for nightlies, or should we only file bugs for the versions pushed to Fedora? Yes, it is, sure. Best regards -- Radek Holý Associate Software Engineer Software Management Team Red Hat Czech -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Wed, 2014-01-29 at 17:11 -0500, Josh Boyer wrote: On Wed, Jan 29, 2014 at 5:01 PM, inode0 ino...@gmail.com wrote: On Wed, Jan 29, 2014 at 3:33 PM, Josh Boyer jwbo...@fedoraproject.org wrote: On Wed, Jan 29, 2014 at 4:03 PM, inode0 ino...@gmail.com wrote: On Wed, Jan 29, 2014 at 2:57 PM, H. Guémar hgue...@fedoraproject.org wrote: Hi, I think we should keep spins as long as we don't have a formal process to accept new products. Something like = proposal = crop (aka product-to-be) = validation = product When we'll have that, drop the whole spin thing, any spin that isn't fit to be a product should be reclassified as remix. Why do we expect spins to be any more official products than they are now? I can't really imagine this ever working. Do you imagine a day where Fedora has 20, 30, 50 official products? I don't. I'd rather not confuse what is made from Fedora bits with what is based on Fedora bits but includes other bits. The remix branding does not seem appropriate for spins that are made purely from Fedora bits. That's fair. From a resource and quality perspective though, I'd rather not burden rel-eng and QA with having to maintain, create, and test spins. They can be done entirely outside of Fedora. They can be created and hosted on their own sites, etc. F20 improved spins overall, but that was because of a concerted effort with our existing resources. If Fedora.next is going to succeed, those resources are already going to be overwhelmed with the 3 products. Spreading them thinner for little benefit in most cases seems irresponsible. So I am being pulled in both directions on this. One of the goals of agility is to facilitate more things being made from Fedora (at least that was a discussed goal at various times). I agree with that and pushing aside the best things we have built from Fedora now (understanding they have been problematic in various ways in the past) seems to work against that goal. There is a difference between things being made from Fedora and Fedora making things for people. I'm concerned that Spins have transformed into the latter. There is nothing preventing someone from taking Fedora and making a spin and hosting it themselves. I don't accept the blanket assertion that the spins have little benefit. Do we actually have any idea how many people install Fedora from spins? We had download statistics at one point that showed most of the spins were not downloaded much. Maybe the Infra group still collects them. Irresponsible is bit loaded. I don't know that rel-eng will be overburdened by running the script that builds them. I also don't know that there aren't other creative arrangements that could be made to facilitate the creation and distribution of spins largely or entirely under the control of those creating them without pushing them entirely outside of Fedora infrastructure. Growing rel-eng could help with the resource issues (similar with QA). If the people doing spins want to step up and do that, then some of my concerns are alleviated. At least in terms of people resources. I guess I'd like those active in the spin community to make suggestions here. I imagine spins and other new creations built on Fedora to be things the project wants to promote, not push away. The reality may be that we can't do what we do now in support of spins, but I hope we can continue to do something that helps and encourages those making them. Promote is an interesting word there too. I think we want to encourage people to create things with and on Fedora. I'm not sure _promoting_ those things simply because someone made this is the right idea with Fedora.next. This isn't specific to Spins though. It's part of a much larger branding conversation that we need to have. josh I use and promote the use of the FEL spin. I did a presentation on it at the RSSC (Robotics Society of Southern California) and gave away 10 disks with the software on them. I know that that is not much in the grand scheme of things, but Electronics engineering and hobby uses of electronics is a relatively small market compared to consumer uses. However these are the guys that will build the next generation of users. Robotics are at least one of the real growing sectors of Electronics and software, and hasn't even reached much more than about 3% of the total market that will soon be felt. Add the Internet of things, and all the 3d printing of all kinds that are being developed, home built milling machines and other things that would probably be considered science fiction even 10 years ago. Linux is at the core of all those developments, and I think the FEL spin is a great contribution to those efforts. Yes, it is a niche market, but it is one that introduces the power of linux at a crucial inflection point on the next several generations of products. -- devel mailing
Re: Fedora.NEXT Products and the fate of Spins
On 29/01/14 05:17 PM, Josh Boyer wrote: On Wed, Jan 29, 2014 at 8:12 PM, Luya Tshimbalanga l...@fedoraproject.org wrote: Spin maintainer as well sharing Dan's view about spin used to display Fedora uses of FOSS applications without needing to download either DVD or netinstall. Remixes like Korora for example are completely different because of the use of software outside Fedora repository. I think Workstation Group should consult spin maintainers for those issues before moving on. I'm unsure of why you're addressing the Workstation WG. This discussion was generated by FESCo, not the Workstation WG. The Workstation WG has made no proposals or comments around Spins at all. If you mean you wish to collaborate with the Workstation WG on doing alternative spins, then great. Please bring that up on the desktop@ list. josh My bad. I mean FESCo. -- Luya Tshimbalanga Graphic Web Designer E: l...@fedoraproject.org W: http://www.coolest-storm.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora.NEXT Products and the fate of Spins
On Wed, 29 Jan 2014 16:39:03 -0600 Jon jdisn...@gmail.com wrote: Another aspect I worry about is the mirroring stuff. With the coming WGs I fear the rsync mirroring will grow very large, and spins are an attractive piece of fat to cut. Reducing size is something we worry about on the infra, rel-eng side of things. If numbers of Gnome || non Gnome Desktops //* am not including DEs' as Spins */ if less than, do such students\devs\admins move from Fedora usage as Fedora.next has nothing for them. Is not the whole purpose of .next to prevent losing users. If storage is the problem, cull all Fedora EOL 3+ year releases\rpms etc. Move spins when created to Linux tracker etc.. Or is it all an Exercise to limit Fedora to Gnome only? ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [perl-SGML-Parser-OpenSP/epel7] exclude ppc64 for now as perl-class-accessor is unavailable
On Tue, 2014-01-28 at 16:36 +, Paul Howarth wrote: On 28/01/14 16:32, Paul Howarth wrote: On 28/01/14 16:14, Nathanael Noblet wrote: commit 09acd6327d876e6d1126ebed87ae9e1e1ec84c27 Author: Nathanael D. Noblet nathan...@noblet.ca Date: Tue Jan 28 09:14:44 2014 -0700 exclude ppc64 for now as perl-class-accessor is unavailable perl-SGML-Parser-OpenSP.spec |1 + 1 files changed, 1 insertions(+), 0 deletions(-) I'm in the process of fixing that: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0374/perl-Class-Accessor-0.31-0.6.1.el6 And, having now noticed that you were referring to epel7, spot has branched this yesterday but not yet built it, so it should be available soon (in EPEL, for all architectures; only EL-6 has the arch-specific issue). Awesome - After I emailed spot I remembered that it was likely what you just described... I eagerly await the fix for el6 and build on el7. Thanks! -- 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: w3c-markup-validator
w3c-markup-validator has broken dependencies in the epel-7 tree: On x86_64: w3c-markup-validator-1.3-4.el7.noarch requires perl(SGML::Parser::OpenSP) = 0:0.991 w3c-markup-validator-1.3-4.el7.noarch requires perl(Net::IP) w3c-markup-validator-1.3-4.el7.noarch requires perl(HTML::Template) w3c-markup-validator-1.3-4.el7.noarch requires perl(Encode::HanExtra) w3c-markup-validator-1.3-4.el7.noarch requires perl(Config::General) = 0:2.32 On ppc64: w3c-markup-validator-1.3-4.el7.noarch requires perl(SGML::Parser::OpenSP) = 0:0.991 w3c-markup-validator-1.3-4.el7.noarch requires perl(Net::IP) w3c-markup-validator-1.3-4.el7.noarch requires perl(HTML::Template) w3c-markup-validator-1.3-4.el7.noarch requires perl(Encode::HanExtra) w3c-markup-validator-1.3-4.el7.noarch requires perl(Config::General) = 0:2.32 On x86_64: w3c-markup-validator-libs-1.3-4.el7.noarch requires html401-dtds On ppc64: w3c-markup-validator-libs-1.3-4.el7.noarch requires html401-dtds 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: dspam
dspam has broken dependencies in the epel-7 tree: On x86_64: dspam-3.10.2-9.el7.x86_64 requires perl(Mail::MboxParser) On ppc64: dspam-3.10.2-9.el7.ppc64 requires perl(Mail::MboxParser) On x86_64: dspam-web-3.10.2-9.el7.x86_64 requires perl(GD::Graph::lines3d) dspam-web-3.10.2-9.el7.x86_64 requires perl(GD::Graph::lines) dspam-web-3.10.2-9.el7.x86_64 requires perl(GD::Graph::bars) On ppc64: dspam-web-3.10.2-9.el7.ppc64 requires perl(GD::Graph::lines3d) dspam-web-3.10.2-9.el7.ppc64 requires perl(GD::Graph::lines) dspam-web-3.10.2-9.el7.ppc64 requires perl(GD::Graph::bars) 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 1058709] FTBFS: perl-DBD-SQLite-1.40-2.fc21: tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1058709 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|jples...@redhat.com |ppi...@redhat.com --- Comment #4 from Petr Pisar ppi...@redhat.com --- Thank you for the finding the fixes. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=GA4Fr7fXfNa=cc_unsubscribe -- 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-URI-Title] Fix the live test failures (#1058734, rt#92091)
commit 15b8df0ebb2d8c5dcd12e5c3eac2e4f478c9b721
Author: Petr Šabata con...@redhat.com
Date: Wed Jan 29 10:47:24 2014 +0100
Fix the live test failures (#1058734, rt#92091)
- Minor spec cleanup
URI-Title-1.86-live-tests.patch | 28
perl-URI-Title.spec | 15 +++
2 files changed, 39 insertions(+), 4 deletions(-)
---
diff --git a/URI-Title-1.86-live-tests.patch b/URI-Title-1.86-live-tests.patch
new file mode 100644
index 000..5222936
--- /dev/null
+++ b/URI-Title-1.86-live-tests.patch
@@ -0,0 +1,28 @@
+diff --git a/lib/URI/Title/HTML.pm b/lib/URI/Title/HTML.pm
+index 74c74b4..576cc1a 100644
+--- a/lib/URI/Title/HTML.pm
b/lib/URI/Title/HTML.pm
+@@ -60,7 +60,7 @@ sub title {
+ $title = paste - ;
+
+ } elsif ($url =~ /twitter.com\/(.*?)\/status(es)?\/\d+/i) {
+-$special_case = 'p class=js-tweet-text tweet-text ([^\]+)';
++$special_case = 'p class=js-tweet-text tweet-text([^\]+)';
+ $title = twitter - ;
+
+ } elsif ($url =~ /independent\.co\.uk/i) {
+diff --git a/t/html.t b/t/html.t
+index 585f112..8293bc2 100644
+--- a/t/html.t
b/t/html.t
+@@ -24,8 +24,8 @@ if ($s) {
+ # got title for jerakeen.org);
+
+ ok(
+- title('http://theregister.co.uk/content/6/34549.html') =~ /lack of
technology may harm your prospects/,
+- got register title);
++
title('http://yro.slashdot.org/story/14/01/28/1731201/why-does-facebook-need-to-read-my-text-messages')
=~ /Why Does Facebook Need To Read My Text Messages\? - Slashdot/,
++ got slashdot title);
+
+ ok(
+ title('http://twitter.com/al3x/status/1039647490') eq 'twitter - Arianna
Huffington: not a good saleswoman for blogging.',
diff --git a/perl-URI-Title.spec b/perl-URI-Title.spec
index 6234b7d..76d73dd 100644
--- a/perl-URI-Title.spec
+++ b/perl-URI-Title.spec
@@ -1,12 +1,13 @@
Name: perl-URI-Title
Version:1.86
-Release:6%{?dist}
+Release:7%{?dist}
Summary:Get the titles of things on the web in a sensible way
# Mentioned in URI::Title POD
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/URI-Title/
Source0:
http://www.cpan.org/authors/id/T/TO/TOMI/URI-Title-%{version}.tar.gz
+Patch0: URI-Title-1.86-live-tests.patch
BuildArch: noarch
BuildRequires: perl(base)
BuildRequires: perl(lib)
@@ -19,13 +20,15 @@ BuildRequires: perl(HTML::Entities)
BuildRequires: perl(HTTP::Request)
BuildRequires: perl(HTTP::Response)
BuildRequires: perl(Image::Size)
+# Needed for Twitter in live tests
+BuildRequires: perl(LWP::Protocol::https)
BuildRequires: perl(LWP::UserAgent)
BuildRequires: perl(Module::Pluggable) = 1.2
BuildRequires: perl(MP3::Info)
BuildRequires: perl(Test::More)
Requires: perl(File::Type) = 0.22
Requires: perl(Module::Pluggable) = 1.2
-Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(:MODULE_COMPAT_%(eval $(perl -V:version); echo
$version))
%global __requires_exclude
%{?__requires_exclude:__requires_exclude|}^perl\\(File::Type\\)
%global __requires_exclude %__requires_exclude|^perl\\(Module::Pluggable\\)
@@ -46,15 +49,15 @@ So, let's solve these issues once.
%prep
%setup -q -n URI-Title-%{version}
+%patch0 -p1
%build
perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
-make pure_install PERL_INSTALL_ROOT=%{buildroot}
+make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} \;
-find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} %{buildroot}/*
%check
@@ -66,6 +69,10 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Jan 28 2014 Petr Šabata con...@redhat.com - 1.86-7
+- Fix the live test failures (#1058734, rt#92091)
+- Minor spec cleanup
+
* Sun Aug 04 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.86-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
--
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 1058734] FTBFS: perl-URI-Title-1.86-6.fc21: tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1058734 --- Comment #1 from Petr Šabata psab...@redhat.com --- The Twitter patch is suitable (and desired) for stable Fedoras too. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=YxDUqcEMi3a=cc_unsubscribe -- 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-URI-Title/f20] Fix the live test failures (#1058734, rt#92091)
Summary of changes: 15b8df0... Fix the live test failures (#1058734, rt#92091) (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-URI-Title/f19] (3 commits) ...Fix the live test failures (#1058734, rt#92091)
Summary of changes: a1c9895... Perl 5.18 rebuild (*) 26d8d9f... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) 15b8df0... Fix the live test failures (#1058734, rt#92091) (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1059154] New: perl-DBD-SQLite distributes sqlite3 sources
https://bugzilla.redhat.com/show_bug.cgi?id=1059154
Bug ID: 1059154
Summary: perl-DBD-SQLite distributes sqlite3 sources
Product: Fedora
Version: rawhide
Component: perl-DBD-SQLite
Assignee: jples...@redhat.com
Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com, mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com,
st...@silug.org
DBD-SQLite sources come with sqlite3.c, sqlite3.h, and sqlite3ext.h which are
bundled SQLite sources. The files are not used when building perl-DBD-SQLite,
however they are installed into the system later into
/usr/lib64/perl5/vendor_perl/auto/share/dist/DBD-SQLite for this documented
purpose:
FOR DBD::SQLITE EXTENSION AUTHORS
Since 1.30_01, you can retrieve the bundled sqlite C source and/or header
like this:
use File::ShareDir 'dist_dir';
use File::Spec::Functions 'catfile';
# the whole sqlite3.h header
my $sqlite3_h = catfile(dist_dir('DBD-SQLite'), 'sqlite3.h');
[...]
You usually want to use this in your extension's Makefile.PL, and you
may want to add DBD::SQLite to your extension's CONFIGURE_REQUIRES to
ensure your extension users use the same C source/header they use to build
DBD::SQLite itself (instead of the ones installed in their system).
First it does not match Fedora philosophy, second it installed different
sources from those used for building the Perl binding.
I propose to remove this feature completely.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug
https://bugzilla.redhat.com/token.cgi?t=qxOHw1pDB0a=cc_unsubscribe
--
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-DBD-SQLite] Fix tests with sqlite = 3.8.2
commit 93072d486480034ed8c0c9aaa46cc8bad3dbad61
Author: Petr Písař ppi...@redhat.com
Date: Wed Jan 29 10:37:01 2014 +0100
Fix tests with sqlite = 3.8.2
...e-1.40-check_only_whether_sort_is_defined.patch | 26 +
DBD-SQLite-1.41_03-adapt_sqlite_3_8_2.patch| 56
perl-DBD-SQLite.spec | 11 -
3 files changed, 92 insertions(+), 1 deletions(-)
---
diff --git a/DBD-SQLite-1.40-check_only_whether_sort_is_defined.patch
b/DBD-SQLite-1.40-check_only_whether_sort_is_defined.patch
new file mode 100644
index 000..b7ece4d
--- /dev/null
+++ b/DBD-SQLite-1.40-check_only_whether_sort_is_defined.patch
@@ -0,0 +1,26 @@
+From 6458091dbcf08c5fed462f43a52254e57ef154aa Mon Sep 17 00:00:00 2001
+From: Kenichi Ishigaki ishig...@cpan.org
+Date: Tue, 27 Aug 2013 12:14:45 +0900
+Subject: [PATCH] check only whether sort is defined or not, as sort may be
+ zero under the new query planner introduced in SQLite 3.8.0
+
+---
+ t/53_status.t | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/t/53_status.t b/t/53_status.t
+index 50b29e0..141e4ec 100644
+--- a/t/53_status.t
b/t/53_status.t
+@@ -46,7 +46,7 @@ for my $func (@CALL_FUNCS) {
+ my $num_of_keys = scalar keys %$st_status;
+ ok $num_of_keys, st status: $num_of_keys indicators;
+ my $sort = $st_status-{sort};
+- ok defined $sort $sort, num of sort: $sort;
++ ok defined $sort, num of sort: $sort;
+ }
+ }
+
+--
+1.8.5.1
+
diff --git a/DBD-SQLite-1.41_03-adapt_sqlite_3_8_2.patch
b/DBD-SQLite-1.41_03-adapt_sqlite_3_8_2.patch
new file mode 100644
index 000..a4ec61e
--- /dev/null
+++ b/DBD-SQLite-1.41_03-adapt_sqlite_3_8_2.patch
@@ -0,0 +1,56 @@
+From f8a45b96f62742351c06fd956a4965004df7226d Mon Sep 17 00:00:00 2001
+From: Kenichi Ishigaki ishig...@cpan.org
+Date: Thu, 9 Jan 2014 02:30:37 +0900
+Subject: [PATCH] error messages have been slightly changed since 3.8.2
+
+---
+ t/07_error.t | 2 +-
+ t/39_foreign_keys.t | 4 ++--
+ t/rt_36838_unique_and_bus_error.t | 2 +-
+ 3 files changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/t/07_error.t b/t/07_error.t
+index 68ea9ca..cf4fdb1 100644
+--- a/t/07_error.t
b/t/07_error.t
+@@ -28,4 +28,4 @@ eval {
+ };
+ ok($@, 'Statement 2 generated an error');
+ is( $DBI::err, 19, '$DBI::err ok' );
+-like( $DBI::errstr, qr/column a is not unique/, '$DBI::errstr ok' );
++like( $DBI::errstr, qr/column a is not unique|UNIQUE constraint failed/,
'$DBI::errstr ok' );
+diff --git a/t/39_foreign_keys.t b/t/39_foreign_keys.t
+index b7632fc..fc15d89 100644
+--- a/t/39_foreign_keys.t
b/t/39_foreign_keys.t
+@@ -49,7 +49,7 @@ ok insert_track(13, My Way, 2);
+ # column (3) does not correspond to row in the artist table.
+
+ ok !insert_track(14, Mr. Bojangles, 3);
+-ok $@ =~ qr/foreign key constraint failed/;
++ok $@ =~ qr/foreign key constraint failed/i;
+
+ # This succeeds because a NULL is inserted into trackartist. A
+ # corresponding row in the artist table is not required in this case.
+@@ -62,7 +62,7 @@ ok insert_track(14, Mr. Bojangles, undef);
+ # artist table.
+
+ ok !update_track(3, Mr. Bojangles);
+-ok $@ =~ /foreign key constraint failed/;
++ok $@ =~ /foreign key constraint failed/i;
+
+ # Insert the required row into the artist table. It is then possible
+ # to update the inserted row to set trackartist to 3 (since a
+diff --git a/t/rt_36838_unique_and_bus_error.t
b/t/rt_36838_unique_and_bus_error.t
+index 2c3a819..5a8aafe 100644
+--- a/t/rt_36838_unique_and_bus_error.t
b/t/rt_36838_unique_and_bus_error.t
+@@ -17,4 +17,4 @@ $dbh-do(CREATE TABLE nums (num INTEGER UNIQUE));
+ ok $dbh-do(INSERT INTO nums (num) VALUES (?), undef, 1);
+
+ eval { $dbh-do(INSERT INTO nums (num) VALUES (?), undef, 1); };
+-ok $@ =~ /column num is not unique/, $@; # should not be a bus error
++ok $@ =~ /column num is not unique|UNIQUE constraint failed/, $@; # should
not be a bus error
+--
+1.8.5.1
+
diff --git a/perl-DBD-SQLite.spec b/perl-DBD-SQLite.spec
index da799e2..1d3c04a 100644
--- a/perl-DBD-SQLite.spec
+++ b/perl-DBD-SQLite.spec
@@ -1,12 +1,16 @@
Name: perl-DBD-SQLite
Version:1.40
-Release:2%{?dist}
+Release:3%{?dist}
Summary:SQLite DBI Driver
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/DBD-SQLite/
Source0:
http://search.cpan.org/CPAN/authors/id/I/IS/ISHIGAKI/DBD-SQLite-%{version}.tar.gz
patch0: perl-DBD-SQLite-bz543982.patch
+# Fix tests with sqlite = 3.8.0, in upstram after 1.40, bug #1058709
+Patch1: DBD-SQLite-1.40-check_only_whether_sort_is_defined.patch
+# Fix tests with sqlite = 3.8.2, in upstream after 1.41_03, bug #1058709
+Patch2: DBD-SQLite-1.41_03-adapt_sqlite_3_8_2.patch
# if sqlite = 3.1.3 then
# perl-DBD-SQLite uses the external library
# else
@@
[Bug 1058734] FTBFS: perl-URI-Title-1.86-6.fc21: tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1058734 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-URI-Title-1.86-7.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/perl-URI-Title-1.86-7.fc19 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=T4timofk1Wa=cc_unsubscribe -- 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 1058734] FTBFS: perl-URI-Title-1.86-6.fc21: tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1058734 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-URI-Title-1.86-7.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-URI-Title-1.86-7.fc20 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=BTKhQEPdyqa=cc_unsubscribe -- 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-DBD-SQLite/f20] Fix tests with sqlite = 3.8.2
Summary of changes: 93072d4... Fix tests with sqlite = 3.8.2 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1058709] FTBFS: perl-DBD-SQLite-1.40-2.fc21: tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1058709 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-DBD-SQLite-1.40-3.fc21 --- Comment #5 from Petr Pisar ppi...@redhat.com --- This is needed for F≥19. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=g3Alzqr8Tfa=cc_unsubscribe -- 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-DBD-SQLite/f19] Fix tests with sqlite = 3.8.2
commit 23d48cf77e812ba09fdf0ffc81132e475f357b60
Author: Petr Písař ppi...@redhat.com
Date: Wed Jan 29 10:37:01 2014 +0100
Fix tests with sqlite = 3.8.2
DBD-SQLite-1.41_03-adapt_sqlite_3_8_2.patch | 56 +++
perl-DBD-SQLite.spec|8 +++-
2 files changed, 63 insertions(+), 1 deletions(-)
---
diff --git a/DBD-SQLite-1.41_03-adapt_sqlite_3_8_2.patch
b/DBD-SQLite-1.41_03-adapt_sqlite_3_8_2.patch
new file mode 100644
index 000..a4ec61e
--- /dev/null
+++ b/DBD-SQLite-1.41_03-adapt_sqlite_3_8_2.patch
@@ -0,0 +1,56 @@
+From f8a45b96f62742351c06fd956a4965004df7226d Mon Sep 17 00:00:00 2001
+From: Kenichi Ishigaki ishig...@cpan.org
+Date: Thu, 9 Jan 2014 02:30:37 +0900
+Subject: [PATCH] error messages have been slightly changed since 3.8.2
+
+---
+ t/07_error.t | 2 +-
+ t/39_foreign_keys.t | 4 ++--
+ t/rt_36838_unique_and_bus_error.t | 2 +-
+ 3 files changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/t/07_error.t b/t/07_error.t
+index 68ea9ca..cf4fdb1 100644
+--- a/t/07_error.t
b/t/07_error.t
+@@ -28,4 +28,4 @@ eval {
+ };
+ ok($@, 'Statement 2 generated an error');
+ is( $DBI::err, 19, '$DBI::err ok' );
+-like( $DBI::errstr, qr/column a is not unique/, '$DBI::errstr ok' );
++like( $DBI::errstr, qr/column a is not unique|UNIQUE constraint failed/,
'$DBI::errstr ok' );
+diff --git a/t/39_foreign_keys.t b/t/39_foreign_keys.t
+index b7632fc..fc15d89 100644
+--- a/t/39_foreign_keys.t
b/t/39_foreign_keys.t
+@@ -49,7 +49,7 @@ ok insert_track(13, My Way, 2);
+ # column (3) does not correspond to row in the artist table.
+
+ ok !insert_track(14, Mr. Bojangles, 3);
+-ok $@ =~ qr/foreign key constraint failed/;
++ok $@ =~ qr/foreign key constraint failed/i;
+
+ # This succeeds because a NULL is inserted into trackartist. A
+ # corresponding row in the artist table is not required in this case.
+@@ -62,7 +62,7 @@ ok insert_track(14, Mr. Bojangles, undef);
+ # artist table.
+
+ ok !update_track(3, Mr. Bojangles);
+-ok $@ =~ /foreign key constraint failed/;
++ok $@ =~ /foreign key constraint failed/i;
+
+ # Insert the required row into the artist table. It is then possible
+ # to update the inserted row to set trackartist to 3 (since a
+diff --git a/t/rt_36838_unique_and_bus_error.t
b/t/rt_36838_unique_and_bus_error.t
+index 2c3a819..5a8aafe 100644
+--- a/t/rt_36838_unique_and_bus_error.t
b/t/rt_36838_unique_and_bus_error.t
+@@ -17,4 +17,4 @@ $dbh-do(CREATE TABLE nums (num INTEGER UNIQUE));
+ ok $dbh-do(INSERT INTO nums (num) VALUES (?), undef, 1);
+
+ eval { $dbh-do(INSERT INTO nums (num) VALUES (?), undef, 1); };
+-ok $@ =~ /column num is not unique/, $@; # should not be a bus error
++ok $@ =~ /column num is not unique|UNIQUE constraint failed/, $@; # should
not be a bus error
+--
+1.8.5.1
+
diff --git a/perl-DBD-SQLite.spec b/perl-DBD-SQLite.spec
index d212072..96f4596 100644
--- a/perl-DBD-SQLite.spec
+++ b/perl-DBD-SQLite.spec
@@ -1,12 +1,14 @@
Name: perl-DBD-SQLite
Version:1.37
-Release:4%{?dist}
+Release:5%{?dist}
Summary:SQLite DBI Driver
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/DBD-SQLite/
Source0:
http://search.cpan.org/CPAN/authors/id/A/AD/ADAMK/DBD-SQLite-%{version}.tar.gz
patch0: perl-DBD-SQLite-bz543982.patch
+# Fix tests with sqlite = 3.8.2, in upstream after 1.41_03, bug #1058709
+Patch1: DBD-SQLite-1.41_03-adapt_sqlite_3_8_2.patch
# if sqlite = 3.1.3 then
# perl-DBD-SQLite uses the external library
# else
@@ -38,6 +40,7 @@ libraries.
%prep
%setup -q -n DBD-SQLite-%{version}
%patch0 -p1 -b .bz543982
+%patch1 -p1
%build
CFLAGS=%{optflags} perl Makefile.PL INSTALLDIRS=vendor
@@ -60,6 +63,9 @@ make test
%{_mandir}/man3/*.3pm*
%changelog
+* Wed Jan 29 2014 Petr Pisar ppi...@redhat.com - 1.37-5
+- Fix tests with sqlite = 3.8.2 (bug #1058709)
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.37-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
--
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 1058709] FTBFS: perl-DBD-SQLite-1.40-2.fc21: tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1058709 --- Comment #6 from Fedora Update System upda...@fedoraproject.org --- perl-DBD-SQLite-1.40-3.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-DBD-SQLite-1.40-3.fc20 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=s7rIL5q47Ka=cc_unsubscribe -- 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 1058709] FTBFS: perl-DBD-SQLite-1.40-2.fc21: tests fail
https://bugzilla.redhat.com/show_bug.cgi?id=1058709 --- Comment #7 from Fedora Update System upda...@fedoraproject.org --- perl-DBD-SQLite-1.37-5.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/perl-DBD-SQLite-1.37-5.fc19 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=seIy39sWP2a=cc_unsubscribe -- 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 Data-Dump-Streamer-2.36.tar.gz uploaded to lookaside cache by lkundrak
A file has been added to the lookaside cache for perl-Data-Dump-Streamer: 7743bc698d1e0eb1caba849d3e0fae2c Data-Dump-Streamer-2.36.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Data-Dump-Streamer/epel7: 4/5] update to latest upstream version
commit aa1281d166f2e4421687c78adfa8745235329d96
Author: Lubomir Rintel lkund...@v3.sk
Date: Wed Jan 29 11:31:21 2014 +0100
update to latest upstream version
.gitignore |1 +
Data-Dump-Streamer-2.34-regex_dump.patch | 84 --
perl-Data-Dump-Streamer.spec | 10 ++--
sources |2 +-
4 files changed, 7 insertions(+), 90 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 834ec15..f2bfcb8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@ Data-Dump-Streamer-2.22.tar.gz
/Data-Dump-Streamer-2.32.tar.gz
/Data-Dump-Streamer-2.33.tar.gz
/Data-Dump-Streamer-2.34.tar.gz
+/Data-Dump-Streamer-2.36.tar.gz
diff --git a/perl-Data-Dump-Streamer.spec b/perl-Data-Dump-Streamer.spec
index 1a75ea3..9d28b51 100644
--- a/perl-Data-Dump-Streamer.spec
+++ b/perl-Data-Dump-Streamer.spec
@@ -1,13 +1,11 @@
Name: perl-Data-Dump-Streamer
-Version:2.34
-Release:6%{?dist}
+Version:2.36
+Release:1%{?dist}
Summary:Accurately serialize a data structure as Perl code
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Data-Dump-Streamer/
Source0:
http://search.cpan.org/CPAN/authors/id/Y/YV/YVES/Data-Dump-Streamer-%{version}.tar.gz
-# Perl 5.18 compatibility, CPAN RT#82958
-Patch0: Data-Dump-Streamer-2.34-regex_dump.patch
BuildRequires: perl(Algorithm::Diff)
BuildRequires: perl(B::Utils)
BuildRequires: perl(Compress::Zlib)
@@ -38,7 +36,6 @@ output correctly.
%prep
%setup -q -n Data-Dump-Streamer-%{version}
-%patch0 -p1
find . -type f | xargs chmod -x
%build
@@ -62,6 +59,9 @@ find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f
{} \;
%{_mandir}/man3/*
%changelog
+* Wed Jan 29 2014 Lubomir Rintel lkund...@v3.sk 2.36-1
+- update to latest upstream version
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.34-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index 11e7a65..2586ea5 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-44f90e6abbfadd773686229fec56e042 Data-Dump-Streamer-2.34.tar.gz
+7743bc698d1e0eb1caba849d3e0fae2c Data-Dump-Streamer-2.36.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
