date:20130416



perl-Bio-SamTools has broken dependencies in the rawhide tree:
On x86_64:
perl-Bio-SamTools-1.35-2.fc19.x86_64 requires 
perl(Bio::SeqFeature::Lite)
perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq)
On i386:
perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite)
perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq)
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Trimming (or obsoleting) %changelog?

2013-04-16 Thread Matthew Miller

On Mon, Apr 15, 2013 at 09:00:00AM -0700, Toshio Kuratomi wrote:
 I believe we've had this discussion before but I don't have a link handy.  I
 think that people said they liked historical information to know when a bug,
 feature, or fix might have entered into a package (where people being end
 users, people who are primarily users, not packagers, even packagers who are
 looking at packagest hat they don't own).  However, people did seem to agree
 that there was a cutoff somewhere in the past where they no longer cared.

It's handy to have it on the system going back the last few updates. Beyond
that, I sometimes *do* care going back beyond that, but wouldn't mind the
history archived somewhere (and somewhere more accessible than deep within
the git history). Losing it completely would be a real shame.




-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  mat...@fedoraproject.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Plan to drop php-pecl-apc from Fedora - Urgent review needed

2013-04-16 Thread Remi Collet

Hi,

PHP opcode cache is a very important feature for sites with large traffic.

APC is mostly a dead project.
No stable release for php 5.4, lot of issues.

Upstream move most of dev resources to new Zend OPcache which will be
the official opcode cache, integrated in PHP 5.5.0

To be able to drop this package, we need

1/ php-pecl-zendopcache, the Zend OPcache for php 5.3 / 5.4

https://bugzilla.redhat.com/show_bug.cgi?id=91

Target version is EPEL-6 and Fedora = 18 as Fedora = 19 already have
php-opcache (subpackage of main php, same code)

2/ php-pecl-apcu, APCu, the drop-in replacement of APC for user data cache.
https://bugzilla.redhat.com/show_bug.cgi?id=928196

Target versions : Fedora = 18 and EPEL-6

Please, review this.

Remi.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Expanding the list of Hardened Packages

2013-04-16 Thread Miloslav Trmač

On Mon, Apr 15, 2013 at 11:19 PM, Richard W.M. Jones rjo...@redhat.comwrote:

 On Mon, Apr 15, 2013 at 06:48:32PM +0200, Miloslav Trmač wrote:
  Now, what to move to?  I currently don't have see any language/runtime I
  could recommend, which is in itself rather frightening.

 Ada, Eiffel, Go, Coq + OCaml, Erlang, Haskell, CompCert[*], etc. etc.

 All these languages are viable.


Perhaps for end-user applications[1], but not for libraries/code
reuse/implementing platform interfaces to be usable by applications.  How
do I call an Eiffel library from Ada and pass it a callback written in Go?
And if widely-used libraries are not available, that again makes it less
viable to write applications using them.
   Mirek

[1] To take a random set of examples, how many of these languages have
libraries or bindings for (all of) TLS, good i18n, libselinux, readline,
D-Bus, GTK?
https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

F-19 Branched report: 20130416 changes

2013-04-16 Thread Fedora Branched Report

Compose started at Tue Apr 16 09:15:20 UTC 2013

Broken deps for x86_64
--
[aeolus-conductor]
aeolus-conductor-0.10.6-2.fc19.noarch requires ruby(abi) = 0:1.9.1
[alexandria]
alexandria-0.6.9-4.fc19.noarch requires ruby(abi) = 0:1.9.1
[amide]
amide-1.0.0-4.fc19.x86_64 requires libvolpack.so.1()(64bit)
[clementine]
clementine-1.1.1-1.fc19.x86_64 requires libprotobuf.so.7()(64bit)
clementine-1.1.1-1.fc19.x86_64 requires libimobiledevice.so.3()(64bit)
[connman]
connman-1.5-4.fc19.i686 requires libxtables.so.7
connman-1.5-4.fc19.i686 requires libgnutls.so.26(GNUTLS_1_4)
connman-1.5-4.fc19.i686 requires libgnutls.so.26
connman-1.5-4.fc19.x86_64 requires libxtables.so.7()(64bit)
connman-1.5-4.fc19.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit)
connman-1.5-4.fc19.x86_64 requires libgnutls.so.26()(64bit)
[deltacloud-core]
deltacloud-core-1.0.5-2.fc19.noarch requires ruby(abi) = 0:1.9.1
[denemo]
denemo-0.9.4-0.fc18.x86_64 requires libgtksourceview-3.0.so.0()(64bit)
[dragonegg]
dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19
[eruby]
eruby-1.0.5-19.fc18.x86_64 requires libruby.so.1.9()(64bit)
eruby-libs-1.0.5-19.fc18.i686 requires ruby(abi) = 0:1.9.0
eruby-libs-1.0.5-19.fc18.i686 requires libruby.so.1.9
eruby-libs-1.0.5-19.fc18.x86_64 requires ruby(abi) = 0:1.9.0
eruby-libs-1.0.5-19.fc18.x86_64 requires libruby.so.1.9()(64bit)
[fawkes]
fawkes-firevision-0.5.0-5.fc19.i686 requires libjpeg.so.8(LIBJPEG_8.0)
fawkes-firevision-0.5.0-5.fc19.i686 requires libjpeg.so.8
fawkes-firevision-0.5.0-5.fc19.x86_64 requires 
libjpeg.so.8(LIBJPEG_8.0)(64bit)
fawkes-firevision-0.5.0-5.fc19.x86_64 requires libjpeg.so.8()(64bit)
fawkes-guis-0.5.0-5.fc19.i686 requires libgraph.so.5
fawkes-guis-0.5.0-5.fc19.x86_64 requires libgraph.so.5()(64bit)
fawkes-plugin-clips-0.5.0-5.fc19.i686 requires libclipsmm.so.2
fawkes-plugin-clips-0.5.0-5.fc19.x86_64 requires 
libclipsmm.so.2()(64bit)
fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires 
libgeos-3.3.6.so()(64bit)
fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires 
libboost_thread-mt.so.1.50.0()(64bit)
fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires 
libboost_system-mt.so.1.50.0()(64bit)
fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires 
libboost_signals-mt.so.1.50.0()(64bit)
fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires 
libboost_thread-mt.so.1.50.0()(64bit)
fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires 
libboost_system-mt.so.1.50.0()(64bit)
[flowcanvas]
flowcanvas-0.7.1-8.fc18.i686 requires libgraph.so.5
flowcanvas-0.7.1-8.fc18.x86_64 requires libgraph.so.5()(64bit)
[gcc-python-plugin]
gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 
0:4.7.2-8.fc19
gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19
gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 
0:4.7.2-8.fc19
gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19
[gdcm]
gdcm-2.0.18-6.fc18.i686 requires libpoppler.so.26
gdcm-2.0.18-6.fc18.x86_64 requires libpoppler.so.26()(64bit)
[gearbox]
gearbox-10.11-3.fc19.i686 requires libIceUtil.so.35b
gearbox-10.11-3.fc19.x86_64 requires libIceUtil.so.35b()(64bit)
[gnome-applets]
1:gnome-applets-3.5.92-3.fc18.x86_64 requires 
libgweather-3.so.1()(64bit)
[gnome-panel]
gnome-panel-3.6.2-6.fc19.x86_64 requires 
libgnome-desktop-3.so.5()(64bit)
gnome-panel-devel-3.6.2-6.fc19.i686 requires libgnome-desktop-3.so.5
gnome-panel-devel-3.6.2-6.fc19.x86_64 requires 
libgnome-desktop-3.so.5()(64bit)
[gnome-pie]
gnome-pie-0.5.3-3.20120826git1b93e1.fc19.x86_64 requires 
libbamf3.so.0()(64bit)
[gnomint]
gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_2_8)(64bit)
gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit)
gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26()(64bit)
[gooddata-cl]
gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java
[gorm]
gorm-1.2.18-1.fc19.i686 requires libgnustep-gui.so.0.22
gorm-1.2.18-1.fc19.x86_64 requires libgnustep-gui.so.0.22()(64bit)
[kawa]
1:kawa-1.11-5.fc19.x86_64 requires servlet25
[libkolab]
php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64
php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64
[matreshka]
matreshka-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-amf-0.3.0-3.fc19.i686 requires libgnat-4.7.so
matreshka-amf-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit)
matreshka-amf-mofext-0.3.0-3.fc19.i686

Re: What to move to?

2013-04-16 Thread Florian Weimer


On 04/15/2013 09:04 PM, Björn Persson wrote:

Miloslav Trmač wrote:

The logical conclusion from this is to move to a language with automatic
memory management.  The top vulnerability reports for programs written in
C/C++ and most other languages so different that starting a new project
that processes untrusted data in C/C++ is becoming indefensible.


If by automatic memory management you mean garbage collection, then
that's not really what we need. Garbage collection has advantages, but
what is needed to stop the buffer overflows is bounds checking. The
compiler needs to keep track of how big each object is and insert code
to check that writes to an array stay within the bounds of the array.


There's also the issue of dangling pointers (pointers which point to a 
memory location which now holds an object of a different type).  They 
can result from misapplied memory management, or from type safety 
loopholes in the language definition.  An example for Ada is here:


  http://www.enyo.de/fw/notes/ada-type-safety.html

(See the postscript—this was already known in the Ada 83 days.  I still 
find it remarkable.  It's possible to work around this in a GC-based 
implementation.)



Now, what to move to?  I currently don't have see any language/runtime I
could recommend, which is in itself rather frightening.


I recommend Ada. Ada does bounds checking, and is compiled to machine
code with performance comparable to C.


Yes, Ada has some nice features.  At least there are real arrays, but 
they are somewhat cumbersome to work with, compared to Java, Python or, 
well, C pointers.  There are two aspects: preservation of array bounds 
in slices (so that you have to write Table (Table'First + Offset) to 
access the element Offset of Table, Offset ranging from 0 to 
Table'Length - 1), and the fact that is impossible to put an 
unconstrained array (of arbitrary length) into a constrained object 
(i.e., you need an indirection).


For many programming tasks, arrays might be at the wrong level of 
abstraction, but we have a lot of plumbing code which uses them heavily.


Garbage collection support would make it easier to introduce the 
indirection, but it would require a conservative collector at present, 
and those we have right now (Boehm-Dehmers-Weiser and the Go collectors) 
require a process-global view, touch signal handlers etc., so they do 
away with one significant Ada advantage (see below).


 Only compiler bugs can cause

buffer overflows in Ada, unless you're so foolhardy that you disable the
bounds checking.


The GNAT run-time is compiled without language-defined checks, and it 
used to have at least one buffer overflow in the Ada part.  Many Ada 
libraries used to follow GNAT's example and disabled the checks as well, 
but this has changed during the last few years, it appears.  Manual 
overflow checks are hampered by the fact that -gnato still isn't the 
default.



Ada doesn't do garbage collection across the whole program, but features
such as controlled types, generic data structures and out parameters
greatly reduce the need for garbage collection. The double-free problem
is also eliminated. (Garbage collection was made optional in Ada so
that the language would be suitable for embedded real-time systems, and
in practice most compilers don't provide it.)


Controlled types have a fixed overhead which is quite visible with small 
objects.  By default, code for abort deferral is emitted, the vtable 
pointer takes space, and avoiding unnecessary indirect calls takes some 
care by the programmer.  There's also no well-defined ABI for shared 
libraries (and adding a subprogram can change the name of existing 
subprograms).


On the other hand, lack of garbage collection means that it's feasible 
to have some GNAT-compiled part in a larger program, without the larger 
program noticing that there's a component not written in C.  I sometimes 
call this deep embedding support, and only very few language 
implementations have this property at present.  (Even with GNAT, you 
have to restrict yourself to a language subset.)  The list of feasible 
systems programming languages is much, much longer, but most need global 
run-time state, threads, signal handler manipulation, have address space 
layout requirements etc.  But that is primarily an implementation issue, 
not an aspect which is inherent to most languages.


The other aspect is low baseline overhead from the run-time system.  We 
don't want programmers to rewrite working system components in C only to 
reduce memory usage.  This is what happened (or is expected to happen) 
to some daemons written in Python.


--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Expanding the list of Hardened Packages

2013-04-16 Thread Florian Weimer


On 04/15/2013 08:17 PM, Miloslav Trmač wrote:

Sure, moving away from C/C++ does not make programs completely secure;
however, on average, C/C++ programs are noticeably less secure (because
most vulnerabilities that can happen in higher-level languages can also
happen in C, but not the other way around).


To illustrate this point, here's a fairly concrete example:  If you have 
got a program that is written in a memory-safe language which also 
provides some form of encapsulation, it is possible to demonstrate 
convincingly (*) that a software module which provides an 
encryption/decryption service never leaks the key material.  If there is 
no memory safety, other code in the program could peek at the key bits, 
and encapsulation is no longer guaranteed.  What should be a local 
property of the module now turns into a global property of the program, 
making review more difficult.


(*) As soon as cryptography is involved, mathematically rigorous results 
are the exception.


--
Florian Weimer / Red Hat Product Security Team
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: QUESTION

2013-04-16 Thread Tomas Radej

Hi,

On Mon, 15 Apr 2013 09:41:03 +
Abdellah Ben abdellahbenid...@gmail.com wrote:

 Hello.
 
 ...
 
  I toke a look at your ideas list and  I couldn’t understand any of it.

I don't think that summer coding contest is a good place to start for
you since you only have done theory. I think that you should start with
a simple application, a command-line interface (which is much easier to
start with), then you can package it for Fedora or make a graphical
user interface for it (and package it for Fedora).

What that application should be? Think of what you would like to use,
or what you think is lacking, and write it. I, myself, wrote a simple
command-line interface for a currency exchange website that I use
daily. Or an app that visualizes the disk space usage, directory by
directory.

You can also start by reading a simple small program's code, to learn
how other people do it. Then you can contribute to that code by fixing
bugs or adding features, or continuing a project that was abandoned by
its creator.

So I suggest you either come up with a simple idea, pick a language,
and realize that idea, or that you contribute in small bits to an
existing project, which you study a bit first.

 ...

Good luck, and don't be afraid to ask.

TR

-- 
Tomas Radej tra...@redhat.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Kernel functionality which replaced cpuspeed daemon thermal limits ?

2013-04-16 Thread Matthew Garrett

On Tue, Apr 16, 2013 at 03:27:52PM +0200, Petr Šabata wrote:
 On Wed, Apr 10, 2013 at 11:33:59AM +0100, Daniel P. Berrange wrote:
  Can anyone point out the kernel cpufreq config that I might have missed
  to make it take into account thermal sensors when controlling CPU freq ?
  
  If there is none, then I intend to re-submit cpuspeed for review and
  inclusion in Fedora repos.
 
 Sadly, it seems kernel indeed doesn't provide any support for
 your specific case.  You could easily write some scripts to
 handle this for you...  or re-include cpuspeed again, yes.

The kernel pays attention to the thermal limits provided by the 
platform. If the platform doesn't provide any thermal limits then you 
can write a value to the passive file in the ACPI thermal zone and it'll 
limit the frequency when it reaches that temperature.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

File ExtUtils-Helpers-0.018.tar.gz uploaded to lookaside cache by pghmcfc

A file has been added to the lookaside cache for perl-ExtUtils-Helpers:

1a49d2fcebd6748143b67b565b69fb1d  ExtUtils-Helpers-0.018.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: Plan to drop php-pecl-apc from Fedora - Urgent review needed

2013-04-16 Thread Michał Piotrowski

Hi,

2013/4/16 Remi Collet fed...@famillecollet.com

 Hi,

 PHP opcode cache is a very important feature for sites with large traffic.

 APC is mostly a dead project.
 No stable release for php 5.4, lot of issues.

 Upstream move most of dev resources to new Zend OPcache which will be
 the official opcode cache, integrated in PHP 5.5.0

 To be able to drop this package, we need

 1/ php-pecl-zendopcache, the Zend OPcache for php 5.3 / 5.4

 https://bugzilla.redhat.com/show_bug.cgi?id=91

 Target version is EPEL-6 and Fedora = 18 as Fedora = 19 already have
 php-opcache (subpackage of main php, same code)

 2/ php-pecl-apcu, APCu, the drop-in replacement of APC for user data cache.
 https://bugzilla.redhat.com/show_bug.cgi?id=928196

 Target versions : Fedora = 18 and EPEL-6

 Please, review this.


So you want to replace APC with Zend OPcache on F18 and F17?



 Remi.
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel




-- 
Best regards,
Michal

http://eventhorizon.pl/
https://getactive.pl/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-ExtUtils-Helpers] Update to 0.018

commit 789c0e9e48036645ce482658b2511c526e83ddb6
Author: Paul Howarth p...@city-fan.org
Date:   Tue Apr 16 16:12:02 2013 +0100

Update to 0.018

- New upstream release 0.018
  - Don't need Pod::Man
- Drop BR: perl(Pod::Man), no longer used

 perl-ExtUtils-Helpers.spec |8 ++--
 sources|2 +-
 2 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/perl-ExtUtils-Helpers.spec b/perl-ExtUtils-Helpers.spec
index e9b0de7..19d5865 100644
--- a/perl-ExtUtils-Helpers.spec
+++ b/perl-ExtUtils-Helpers.spec
@@ -5,7 +5,7 @@
 %global old_test_more %(perl -MTest::More -e 'print (($Test::More::VERSION)  
0.88 ? 1 : 0);' 2/dev/null || echo 0)
 
 Name:  perl-ExtUtils-Helpers
-Version:   0.017
+Version:   0.018
 Release:   1%{?dist}
 Summary:   Various portability utilities for module builders
 Group: Development/Libraries
@@ -26,7 +26,6 @@ BuildRequires:perl(File::Basename)
 BuildRequires: perl(File::Copy)
 BuildRequires: perl(File::Spec::Functions)
 BuildRequires: perl(Module::Load)
-BuildRequires: perl(Pod::Man)
 BuildRequires: perl(Text::ParseWords) = 3.22
 # Test Suite
 BuildRequires: perl(Cwd)
@@ -82,6 +81,11 @@ rm -rf %{buildroot}
 %{_mandir}/man3/ExtUtils::Helpers::Windows.3pm*
 
 %changelog
+* Tue Apr 16 2013 Paul Howarth p...@city-fan.org - 0.018-1
+- Update to 0.018
+  - Don't need Pod::Man
+- Drop BR: perl(Pod::Man), no longer used
+
 * Mon Apr 15 2013 Paul Howarth p...@city-fan.org - 0.017-1
 - Update to 0.017
   - Fix man3_pagename to properly split dirs
diff --git a/sources b/sources
index 78ee5ac..973fc52 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-1e6a4a404f83dda60513cc7fe28b9c74  ExtUtils-Helpers-0.017.tar.gz
+1a49d2fcebd6748143b67b565b69fb1d  ExtUtils-Helpers-0.018.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-ExtUtils-Helpers] Created tag perl-ExtUtils-Helpers-0.018-1.fc20

The lightweight tag 'perl-ExtUtils-Helpers-0.018-1.fc20' was created pointing 
to:

 789c0e9... Update to 0.018
--
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: Expanding the list of Hardened Packages

2013-04-16 Thread Richard W.M. Jones

On Tue, Apr 16, 2013 at 03:12:38PM +0200, Miloslav Trmač wrote:
 On Mon, Apr 15, 2013 at 11:19 PM, Richard W.M. Jones rjo...@redhat.comwrote:
 
  On Mon, Apr 15, 2013 at 06:48:32PM +0200, Miloslav Trmač wrote:
   Now, what to move to?  I currently don't have see any language/runtime I
   could recommend, which is in itself rather frightening.
 
  Ada, Eiffel, Go, Coq + OCaml, Erlang, Haskell, CompCert[*], etc. etc.
 
  All these languages are viable.
 
 
 Perhaps for end-user applications[1], but not for libraries/code
 reuse/implementing platform interfaces to be usable by applications.  How
 do I call an Eiffel library from Ada and pass it a callback written in Go?

The answer (perhaps sadly) is you have to expose a C API.  At least
OCaml and golang can generate C-compatible shared libraries.  Probably
Eiffel and Ada too, although I'm not certain on the details.

Passing pointers to objects from one language to another is likely
*not* possible however.  And it gets hard when you want to mix lots of
languages (because GCs won't cooperate with each other).

.Net does this right, although requiring a heavyweight VM to do it is
probably not necessary.

 [1] To take a random set of examples, how many of these languages have
 libraries or bindings for (all of) TLS, good i18n, libselinux, readline,
 D-Bus, GTK?

OCaml has 3/6.  Having an easy to use FFI helps a lot here.  The OCaml
code in libguestfs uses a number of different C APIs, and mostly I've
just hand-written snippets of FFI to do it.  It's not a lot of code,
although not ideal.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Another UEFI testing request

2013-04-16 Thread Alexander Bokovoy

On Mon, 15 Apr 2013, Adam Williamson wrote:
Hi folks - thanks for helping out with the last UEFI testing request,
it was very helpful. If we could impose again, it would be really
helpful if anyone with a UEFI-capable system could try a UEFI native
install of Alpha RC3:

https://dl.fedoraproject.org/pub/alt/stage/19-Alpha-RC3/

and report your results. We are hopeful that the major bugs that
affected previous builds are resolved, and many or most UEFI installs
should succeed at this point. If you try, please report whether you
got a successful installation, and if not, what problem you ran into.
Bug reports for problems are of course welcome. Thanks!

RC3 is even worse than TC6 was on Asus U38N (AMD A8-4555). Where I was
able to get to a graphical install with TC6 by appending 'nomodeset
video=1920x1080-32 to the kernel command line (and removing 'quiet'),
in RC3 even that doesn't help. While booting, at Xorg start switch to
Xorg driver causes whole screen to be black and never come to a working state.

I've tried several distributions, all fail the same way with KMS. F18
works with nomodeset but is very slow. openSUSE 12.3 works with
nomodeset and seems to be generally faster, OpenGL is accelerated.

When TC6 starts to graphic mode and gives first Anaconda screen, it
shows an error message box where the only button I could press is
'Quit':
http://lh4.googleusercontent.com/-A6BJjSaCLqQ/UW17Bl2RpoI/A_g/pqW9SAWqxLo/s1024/16.04.13+-+1

--
/ Alexander Bokovoy
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-ExtUtils-InstallPaths] Initial import (perl-ExtUtils-InstallPaths-0.009-2)

commit 0669c1cc5e5bffc7d0300390023a4ee181a6551d
Author: Paul Howarth p...@city-fan.org
Date:   Tue Apr 16 16:49:39 2013 +0100

Initial import (perl-ExtUtils-InstallPaths-0.009-2)

This module tries to make install path resolution as easy as possible.

When you want to install a module, it needs to figure out where to install
things. The nutshell version of how this works is that default installation
locations are determined from ExtUtils::Config, and they may be individually
overridden by using the install_path attribute. An install_base attribute 
lets
you specify an alternative installation root like /home/foo and prefix does
something similar in a rather different (and more complicated) way. destdir
lets you specify a temporary installation directory like /tmp/install in 
case
you want to create bundled-up installable packages.

 .gitignore  |1 +
 perl-ExtUtils-InstallPaths.spec |   71 +++
 sources |1 +
 3 files changed, 73 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..88c1c10 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/ExtUtils-InstallPaths-[0-9.]*.tar.gz
diff --git a/perl-ExtUtils-InstallPaths.spec b/perl-ExtUtils-InstallPaths.spec
new file mode 100644
index 000..87c298f
--- /dev/null
+++ b/perl-ExtUtils-InstallPaths.spec
@@ -0,0 +1,71 @@
+Name:  perl-ExtUtils-InstallPaths
+Version:   0.009
+Release:   2%{?dist}
+Summary:   Build.PL install path logic made easy
+Group: Development/Libraries
+License:   GPL+ or Artistic
+URL:   https://metacpan.org/release/ExtUtils-InstallPaths
+Source0:   
http://cpan.metacpan.org/authors/id/L/LE/LEONT/ExtUtils-InstallPaths-%{version}.tar.gz
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
+BuildArch: noarch
+# Build
+BuildRequires: perl(ExtUtils::MakeMaker)
+# Module
+BuildRequires: perl(Carp)
+BuildRequires: perl(ExtUtils::Config)
+BuildRequires: perl(File::Spec)
+# Test Suite
+BuildRequires: perl(Config)
+BuildRequires: perl(File::Find)
+BuildRequires: perl(File::Spec::Functions)
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(Test::More)
+# Release Tests
+BuildRequires: perl(Pod::Coverage::TrustPod)
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+# Runtime
+Requires:  perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+
+%description
+This module tries to make install path resolution as easy as possible.
+
+When you want to install a module, it needs to figure out where to install
+things. The nutshell version of how this works is that default installation
+locations are determined from ExtUtils::Config, and they may be individually
+overridden by using the install_path attribute. An install_base attribute lets
+you specify an alternative installation root like /home/foo and prefix does
+something similar in a rather different (and more complicated) way. destdir
+lets you specify a temporary installation directory like /tmp/install in case
+you want to create bundled-up installable packages.
+
+%prep
+%setup -q -n ExtUtils-InstallPaths-%{version}
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+rm -rf %{buildroot}
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+%{_fixperms} %{buildroot}
+
+%check
+make test RELEASE_TESTING=1
+
+%clean
+rm -rf %{buildroot}
+
+%files
+%doc Changes LICENSE README
+%{perl_vendorlib}/ExtUtils/
+%{_mandir}/man3/ExtUtils::InstallPaths.3pm*
+
+%changelog
+* Mon Apr  1 2013 Paul Howarth p...@city-fan.org - 0.009-2
+- Sanitize for Fedora submission
+
+* Sun Mar 31 2013 Paul Howarth p...@city-fan.org - 0.009-1
+- Initial RPM version
diff --git a/sources b/sources
index e69de29..8444340 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+6136200e7569dc6d225a074f04530f16  ExtUtils-InstallPaths-0.009.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[perl-ExtUtils-InstallPaths] Drop non-dual-lived buildreqs (#947454)

commit 71a4e20deb2d586793fc49bd090e922e442aebea
Author: Paul Howarth p...@city-fan.org
Date:   Tue Apr 16 16:52:35 2013 +0100

Drop non-dual-lived buildreqs (#947454)

 perl-ExtUtils-InstallPaths.spec |7 ---
 1 files changed, 4 insertions(+), 3 deletions(-)
---
diff --git a/perl-ExtUtils-InstallPaths.spec b/perl-ExtUtils-InstallPaths.spec
index 87c298f..5675d8b 100644
--- a/perl-ExtUtils-InstallPaths.spec
+++ b/perl-ExtUtils-InstallPaths.spec
@@ -1,6 +1,6 @@
 Name:  perl-ExtUtils-InstallPaths
 Version:   0.009
-Release:   2%{?dist}
+Release:   3%{?dist}
 Summary:   Build.PL install path logic made easy
 Group: Development/Libraries
 License:   GPL+ or Artistic
@@ -15,8 +15,6 @@ BuildRequires:perl(Carp)
 BuildRequires: perl(ExtUtils::Config)
 BuildRequires: perl(File::Spec)
 # Test Suite
-BuildRequires: perl(Config)
-BuildRequires: perl(File::Find)
 BuildRequires: perl(File::Spec::Functions)
 BuildRequires: perl(File::Temp)
 BuildRequires: perl(Test::More)
@@ -64,6 +62,9 @@ rm -rf %{buildroot}
 %{_mandir}/man3/ExtUtils::InstallPaths.3pm*
 
 %changelog
+* Tue Apr 16 2013 Paul Howarth p...@city-fan.org - 0.009-3
+- Drop non-dual-lived buildreqs (#947454)
+
 * Mon Apr  1 2013 Paul Howarth p...@city-fan.org - 0.009-2
 - Sanitize for Fedora submission
 
--
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: Expanding the list of Hardened Packages

2013-04-16 Thread Jan Pokorný

On 15/04/13 10:10 -0400, Steve Grubb wrote:
 I would say there is a place for SE Linux even if we compiled everything with 
 all because FORTIFY_SOURCE coverage is not absolute. For example, about a 
 month ago i ran the following test:
 
 procs=`ls /proc | grep '^[0-9]' | sort -n`
 for p in $procs
 do
   res=`cat /proc/$p/maps 2/dev/null |  awk '$2 ~ wx { print $2 }'`
   if [ x$res != x ] ; then
   cat /proc/$p/cmdline | awk '{ printf %-35s\t, $1 }'
   printf %s\n $p
   fi
 done
 
 
 What this does is display the programs with Writable and Executable memory. 
 All Fedora desktops except Mate have WX memory. (I checked KDE, Gnome, 
 Cinnamon, and Mate.)

FWIW, LXDE seems to be fine as well (if polkitd and firefox are not counted
in).

-- 
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plan to drop php-pecl-apc from Fedora - Urgent review needed

2013-04-16 Thread Jared K. Smith

On Tue, Apr 16, 2013 at 3:47 AM, Remi Collet fed...@famillecollet.comwrote:

 To be able to drop this package, we need

 1/ php-pecl-zendopcache, the Zend OPcache for php 5.3 / 5.4

 https://bugzilla.redhat.com/show_bug.cgi?id=91

 Target version is EPEL-6 and Fedora = 18 as Fedora = 19 already have
 php-opcache (subpackage of main php, same code)


Review done and approved.



 2/ php-pecl-apcu, APCu, the drop-in replacement of APC for user data cache.
 https://bugzilla.redhat.com/show_bug.cgi?id=928196

 Target versions : Fedora = 18 and EPEL-6

 Please, review this.


I'll try to get to this later today, or perhaps tomorrow.  If someone else
can do it before I get to it, please by all means do it!

--
Jared Smith
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Test-Announce] FWD: Power Management Fedora19 testday - (part of BRQ OpenHouse)

2013-04-16 Thread Martin Holec

Hi,
There is planned Power Management testday tomorrow. It will be part of 
Open House in Brno RH office
If you are interested to see capabilities of your machine or measure 
power consumption please come, you will see what your HW know.
Everybody with various HW configuration welcomed (Old  New  Obscure)

info: 
https://fedoraproject.org/wiki/Test_Day:2013-04-17_Power_Management
when:  tomorrow (Wednesday) 17. 04. 2013
where: online:  please connect mentioned  IRC channels at wiki
on-site: 13:00 - 19:00, Mint room, ground floor, Brno 1 
building

bootable USB flash disc and live CDs will be prepared for you

You are very welcome
 ThanksRegards
 Your Power Management team

-- 
Jan Scotka jsco...@redhat.com  RHCE
QA daemons Team
irc (jscotka at): #brno, #urt, #qa, #errata, #devel

___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Another UEFI testing request

On 16/04/13 09:27 AM, Alexander Bokovoy wrote:

On Mon, 15 Apr 2013, Adam Williamson wrote:

Hi folks - thanks for helping out with the last UEFI testing request,
it was very helpful. If we could impose again, it would be really
helpful if anyone with a UEFI-capable system could try a UEFI native
install of Alpha RC3:

https://dl.fedoraproject.org/pub/alt/stage/19-Alpha-RC3/

As noted on your bug report, your issue looks to be to do with the
graphics handling on your particular system, nothing to do with the
wider UEFI issues we're dealing with. Obviously a problem for you, but
it doesn't have wider implications for the Alpha release, I don't think.
Thanks for testing!

The error you hit in anaconda in TC6 is something else, but we cannot
possibly know anything about it from that screenshot: the dialog there
is the generic 'something went wrong in anaconda' dialog. We would need
you to hit 'Report Bug' and go through the process to report a bug to
bugzilla.

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

PIE breaks detection of available stack depth with getrlimit?

2013-04-16 Thread Tom Lane

Pursuant to the recent discussion about using _hardened_build in more
packages, I tried turning it on in postgresql.  I was unpleasantly
surprised to find that that causes the package's regression tests to
fail, at least when running a 32-bit build in mock under a 64-bit
kernel.  The cause appears to be that getrlimit(RLIMIT_STACK) reports
an inflated value for the process's available stack space.

Just to make it more fun, the test doesn't always fail, which makes it
look like address space randomization is affecting how much stack space
you get, but not how much getrlimit tells you you've got.

While 32-bit-under-64-bit-kernel probably isn't very reflective of real
world database usage, it is reflective of what's going to happen in
koji, so I cannot enable _hardened_build until this is resolved.

So is this a kernel bug, or a userspace bug, and if the latter what
component should I file it against?

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PIE breaks detection of available stack depth with getrlimit?

2013-04-16 Thread John Reiser

 fail, at least when running a 32-bit build in mock under a 64-bit
 kernel.  The cause appears to be that getrlimit(RLIMIT_STACK) reports
 an inflated value for the process's available stack space.

If you can write a short program that demonstrates the failure,
say by comparing getrlimit(RLIMIT_STACK) to the results of
an internal cat /proc/self/maps, then that's a kernel bug.

-- 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PIE breaks detection of available stack depth with getrlimit?

2013-04-16 Thread John Reiser

 If you can write a short program that demonstrates the failure,
 say by comparing getrlimit(RLIMIT_STACK) to the results of
 an internal cat /proc/self/maps, then that's a kernel bug.

- where.c
#include stdio.h
#include stdlib.h
#include sys/types.h
#include fcntl.h
#include sys/time.h
#include sys/resource.h

char buf[8192];

main()
{
struct rlimit rlim;
int const rv1= getrlimit(RLIMIT_STACK, rlim);
printf(stack rlim_cur=%p  rlim_max=%p  stack=%p\n,
rlim.rlim_cur, rlim.rlim_max, rlim);
fflush(stdout);
int const fd=open(/proc/self/maps, O_RDONLY);
for (;;) {
size_t len=read(fd, buf, sizeof(buf));
if (-1==len) {
perror(read); exit(1);
}
if (0==len)
break;
if (len!=write(1, buf, len))
perror(write); exit(1);
}
return 0;
}
-

$ gcc -m32 -pie -fPIE -o where where.c
$ ./where
stack rlim_cur=0x80  rlim_max=0x  stack=0xffcc472c
f7558000-f7559000 rw-p  00:00 0
f7559000-f7704000 r-xp  08:0c 402364 
/usr/lib/libc-2.15.so
f7704000-f7705000 ---p 001ab000 08:0c 402364 
/usr/lib/libc-2.15.so
f7705000-f7707000 r--p 001ab000 08:0c 402364 
/usr/lib/libc-2.15.so
f7707000-f7708000 rw-p 001ad000 08:0c 402364 
/usr/lib/libc-2.15.so
f7708000-f770b000 rw-p  00:00 0
f7725000-f7727000 rw-p  00:00 0
f7727000-f7728000 r-xp  00:00 0  [vdso]
f7728000-f7747000 r-xp  08:0c 416838 
/usr/lib/ld-2.15.so
f7747000-f7748000 r--p 0001e000 08:0c 416838 
/usr/lib/ld-2.15.so
f7748000-f7749000 rw-p 0001f000 08:0c 416838 
/usr/lib/ld-2.15.so
f7749000-f774a000 r-xp  08:15 7024004
/bigdata/home/jreiser/where
f774a000-f774b000 rw-p  08:15 7024004
/bigdata/home/jreiser/where
f774b000-f774d000 rw-p  00:00 0
ffca5000-ffcc6000 rw-p  00:00 0  [stack]
$

Looks OK to me.  0xffcc6000 - 0x80 = 0xff4c6000 which is above 0xf774d000
by 0x7d79000 which is a lot.  rlim_max=0x is infinity which
cannot be a real limit.

-- 

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Expanding the list of Hardened Packages


On 15/04/13 09:48 AM, Miloslav Trmač wrote:

On Sat, Apr 13, 2013 at 7:51 PM, Reindl Harald h.rei...@thelounge.net
mailto:h.rei...@thelounge.net wrote:

which raises the question again:

would it be not the better way to build the whole distribution hardened
by expierience that nearly anything is exploitable over the long and
performance comes after security


The logical conclusion from this is to move to a language with automatic
memory management.  The top vulnerability reports for programs written
in C/C++ and most other languages so different that starting a new
project that processes untrusted data in C/C++ is becoming indefensible.

We seem to be stuck with C as the lowest common denominator that can be
used from any runtime; long-term we _need_ to move away from that, or
Linux will gain the reputation of least-secure OS around.

Now, what to move to?  I currently don't have see any language/runtime I
could recommend, which is in itself rather frightening.


Can I step in and ask: move *what* exactly?

This is the *Fedora* development list, remember. This thread was a 
discussion of the security of the Fedora package base as a whole. The 
Fedora project does not control the development of the code behind 99% 
of the Fedora package base. The logical conclusion is to move to a 
different language doesn't seem particularly logical at all in context 
- as a reply to Harald's proposal for build parameters for all Fedora 
packages - because you're advocating a completely different change, one 
it is not at all feasible for Fedora to effect in this context.


So you've just pivoted the entire thread, for which congratulations, but 
this could really have been a separate discussion.

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Expanding the list of Hardened Packages


On 13/04/13 11:36 AM, Kevin Kofler wrote:


And I would argue that this amounts to second-guessing/duplicating what the
program tries to do in an unmaintainable morass of rules, which even for the
targeted policy (which is not even close to covering all programs in Fedora
other than as unconfined) keeps having bugs which need to be fixed every
day, even after YEARS of debugging. SELinux just does not scale,


SELinux keeps having bugs *because* they progressively build out the 
policies. The coverage of the -targeted policy is now greater than it 
was a few releases back. If they kept the coverage of the stock policies 
the same over time there would be almost no new bugs, but instead, they 
increase the coverage and hence the security it provides progressively 
with each release. *Some* bugs are associated with files moving or 
program functionality changing or whatever, but most are just the result 
of the policies growing: the 'scaling' that you say isn't working.

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Broken dependencies: rubygem-pam


On 15/04/13 05:30 AM, Josef Stribny wrote:

Hi,

change ruby(abi) to Requires: ruby(release) as in guidelines [1]

Each Ruby package must indicate it depends on a Ruby interpreter. Use ruby(release) 
virtual requirement to achieve that:

This is due to support both MRI and JRuby in next Fedora releases.


Y'know, this one kinda made me scratch my head a little when I came 
across it, because surely 'abi' is a more accurate term than 'release' 
in the context of 'there are multiple different but compatible 
interpretations of the same basic thing, and this is a virtual 
dependency for packages which can happily use any of them'? I mean, 
switching from the word 'abi' to the word 'release' because you now have 
two things that provide the same...ABI...seems exactly bass-ackwards :) 
but I may be missing something.

--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

2013-04-16 Thread Christopher Meng

Maybe trimming the changelog can be a option feature of rpmdev?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Is Raspberry Pi firmware still unsuitable for Fedora?

2013-04-16 Thread Adam Goode

Is the Raspberry Pi firmware now ok to be packaged in Fedora proper?

It looks like the Fedora guidelines for firmware can now include RPi stuff.

https://fedoraproject.org/wiki/Licensing:Main#Binary_Firmware
https://github.com/raspberrypi/firmware/blob/master/boot/LICENCE.broadcom

Yes? No?

This is all that is keeping Raspberry Pi as a remix, correct? Or still
waiting for full kernel upstream? (Let's ignore armv6hl stuff for
now.)


Thanks,

Adam
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

2013-04-16 Thread Dan Fruehauf

Hey,

I tend to be against trimming. I was just looking at the binutils changelog
(goes back to 1997):
$ rpm -q --changelog binutils | wc -c
54984

That's around 50K, and compressed (RPMs are compressed):
$ rpm -q --changelog binutils | gzip | wc -c
15552

15K is nothing. Really. I like to see the whole history of a package, it's
nice and fun.

Perhaps other packages has larger changelogs. I guess common sense is what
we should use, but generally speaking I'd say don't trim, as it doesn't
really matter and it's cleaner to have a full changelog, rather than a
story which starts somewhere in the middle.

Just out of curiosity, what packages have huge changelogs?

BR
Dan Fruehauf.


On Mon, Apr 15, 2013 at 10:43 PM, Rex Dieter rdie...@math.unl.edu wrote:

 Richard Hughes wrote:

  Is there any guidance as when to trim %changelog down to size? Some
  packages have thousands of lines of spec file dating back over 15
  years which seem kinda redundant now we're using git.

 To me, common sense dictates that it's perfectly ok to trim the length of
 the changelog as long as items that are relevant to the current release are
 kept intact.  Use your best judgement where that position lies.

 -- rex

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Another UEFI testing request

2013-04-16 Thread Chris Adams

Once upon a time, Adam Williamson awill...@redhat.com said:
 Hi folks - thanks for helping out with the last UEFI testing request, it 
 was very helpful. If we could impose again, it would be really helpful 
 if anyone with a UEFI-capable system could try a UEFI native install of 
 Alpha RC3:
 
 https://dl.fedoraproject.org/pub/alt/stage/19-Alpha-RC3/
 
 and report your results. We are hopeful that the major bugs that 
 affected previous builds are resolved, and many or most UEFI installs 
 should succeed at this point. If you try, please report whether you got 
 a successful installation, and if not, what problem you ran into. Bug 
 reports for problems are of course welcome. Thanks!

I tried a UEFI install, but it failed at installing the bootloader.

The system is a Zotac Zbox nano AD10.  I downloaded the image from the
above URL and put it on an SD card and did a UEFI boot.  I don't have
anything current on the drive, so I chose not to preserve anything.  I
tried a minimal install; no problems up to the bootloader, which gave me
an unknown error.

Also, I tried to report the failure to BZ or save it, and I got another
unknown error.
-- 
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

2013-04-16 Thread Andy Grimm

On Tue, Apr 16, 2013 at 9:25 PM, Dan Fruehauf malko...@gmail.com wrote:

 Hey,

 I tend to be against trimming. I was just looking at the binutils
 changelog (goes back to 1997):
 $ rpm -q --changelog binutils | wc -c
 54984

 That's around 50K, and compressed (RPMs are compressed):
 $ rpm -q --changelog binutils | gzip | wc -c
 15552

 15K is nothing. Really. I like to see the whole history of a package, it's
 nice and fun.

 Perhaps other packages has larger changelogs. I guess common sense is what
 we should use, but generally speaking I'd say don't trim, as it doesn't
 really matter and it's cleaner to have a full changelog, rather than a
 story which starts somewhere in the middle.

 Just out of curiosity, what packages have huge changelogs?


A lot of them are the ones you'd expect -- toolchain-related packages that
have been around forever like gcc, gdb, glibc.  SELinux related packages
have pretty huge changelogs, too.  I think the winner for greatest
changelog growth rate is likely rhc (the OpenShift client): over 350
entries in less than two years.  :-)

Andy



 BR
 Dan Fruehauf.


 On Mon, Apr 15, 2013 at 10:43 PM, Rex Dieter rdie...@math.unl.edu wrote:

 Richard Hughes wrote:

  Is there any guidance as when to trim %changelog down to size? Some
  packages have thousands of lines of spec file dating back over 15
  years which seem kinda redundant now we're using git.

 To me, common sense dictates that it's perfectly ok to trim the length of
 the changelog as long as items that are relevant to the current release
 are
 kept intact.  Use your best judgement where that position lies.

 -- rex

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel



 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Test-Announce] 2013-04-17 @ 16:00 UTC - F19 Alpha Blocker Bug Review #8

2013-04-16 Thread Tim Flink

# F19 Alpha Blocker Review meeting #8
# Date: 2013-04-17
# Time: 16:00 UTC (12:00 EDT, 09:00 PDT)
# Location: #fedora-blocker-review on irc.freenode.net

The next (and hopefully last) blocker review meeting for F19 alpha will
be held tomorrow.

We'll be running through the alpha blockers and freeze exception bugs.
The current list is available at:
http://qa.fedoraproject.org/blockerbugs/current

We'll be reviewing the bugs to determine ...

1. Whether they meet the alpha release criteria [1] and should stay
 on the list
2. Whether they are getting the attention they need

[1] http://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria

For guidance on Blocker and FreezeException bugs, please refer to
 - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
 - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

For the blocker review meeting protocol, see
 - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting


signature.asc
Description: PGP signature
___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

2013-04-16 Thread Christopher Meng

在 2013-4-17 AM9:26，Dan Fruehauf malko...@gmail.com写道：
 Just out of curiosity, what packages have huge changelogs?

Another huge one: openssl
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

2013-04-16 Thread Florian Festi

On 04/17/2013 10:25 AM, Dan Fruehauf wrote:
 That's around 50K, and compressed (RPMs are compressed):
 $ rpm -q --changelog binutils | gzip | wc -c
 15552
 
 15K is nothing. Really. I like to see the whole history of a package,
 it's nice and fun.

That's not correct. The change log is stored within the rpm header which
is not compressed. While there have been efforts to compress the header
those changes have not (yet) made it upstream as it would make rpm
packages completely incompatible with older rpm versions.

For limiting the change log entries in the binary packages
%_changelog_trimtime can be used that take a unix time stamp as an
integer value. This way the whole history is still available in the spec
file.

Florian
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

2013-04-16 Thread Mathieu Bridon

On Wed, 2013-04-17 at 12:10 +0900, Florian Festi wrote:
 For limiting the change log entries in the binary packages
 %_changelog_trimtime can be used that take a unix time stamp as an
 integer value. This way the whole history is still available in the spec
 file.

Could redhat-rpm-config set that automatically, for example to the
release date of Fedora N-1?


-- 
Mathieu

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

2013-04-16 Thread Dan Fruehauf

I stand corrected then, lets have a look at things uncompressed:
glibc - 360K
gcc - 20K
gdb - 148K

Still fail to see the big deal, sorry.



On Wed, Apr 17, 2013 at 1:10 PM, Florian Festi ffe...@redhat.com wrote:

 On 04/17/2013 10:25 AM, Dan Fruehauf wrote:
  That's around 50K, and compressed (RPMs are compressed):
  $ rpm -q --changelog binutils | gzip | wc -c
  15552
 
  15K is nothing. Really. I like to see the whole history of a package,
  it's nice and fun.

 That's not correct. The change log is stored within the rpm header which
 is not compressed. While there have been efforts to compress the header
 those changes have not (yet) made it upstream as it would make rpm
 packages completely incompatible with older rpm versions.

 For limiting the change log entries in the binary packages
 %_changelog_trimtime can be used that take a unix time stamp as an
 integer value. This way the whole history is still available in the spec
 file.

 Florian
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Trimming (or obsoleting) %changelog?

2013-04-16 Thread Florian Festi

On 04/17/2013 12:18 PM, Mathieu Bridon wrote:
 On Wed, 2013-04-17 at 12:10 +0900, Florian Festi wrote:
 For limiting the change log entries in the binary packages
 %_changelog_trimtime can be used that take a unix time stamp as an
 integer value. This way the whole history is still available in the spec
 file.
 
 Could redhat-rpm-config set that automatically, for example to the
 release date of Fedora N-1?

From a technical POV: Yes, very easily.

Figuring out if this really is a good idea and convincing all necessary
Fedora committees is left as an exercise for the reader.

Florian

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PIE breaks detection of available stack depth with getrlimit?

2013-04-16 Thread Tom Lane

John Reiser jrei...@bitwagon.com writes:
 If you can write a short program that demonstrates the failure,
 say by comparing getrlimit(RLIMIT_STACK) to the results of
 an internal cat /proc/self/maps, then that's a kernel bug.

 [ proposed test program ]

That program doesn't fail for me either, but Postgres definitely does;
probably the problem is dependent on having a bunch of shlibs loaded,
or having a SysV-style shared memory segment, or some other odd little
detail.  I adapted your program into a debugging-printout patch for
Postgres and filed the results as bz #952946.

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: PIE breaks detection of available stack depth with getrlimit?

2013-04-16 Thread Dhiru Kholia

On 04/16/13 at 05:59pm, Tom Lane wrote:
 Pursuant to the recent discussion about using _hardened_build in more
 packages, I tried turning it on in postgresql.  I was unpleasantly
 surprised to find that that causes the package's regression tests to
 fail, at least when running a 32-bit build in mock under a 64-bit
 kernel.  The cause appears to be that getrlimit(RLIMIT_STACK) reports
 an inflated value for the process's available stack space.

 So is this a kernel bug, or a userspace bug, and if the latter what
 component should I file it against?

I am wondering why Ubuntu didn't hit this bug earlier since they have
been shipping PIE enabled postgresql for a long time now.

Does this problem occurs only under Linux 3.9 kernel (and not under
Linux = 3.8 kernel versions) ?

--
Dhiru
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Broken dependencies: perl-Math-Clipper



perl-Math-Clipper has broken dependencies in the rawhide tree:
On x86_64:
perl-Math-Clipper-1.17-3.fc19.x86_64 requires 
libpolyclipping.so.5()(64bit)
On i386:
perl-Math-Clipper-1.17-3.fc19.i686 requires libpolyclipping.so.5
Please resolve this as soon as possible.


--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Broken dependencies: perl-Bio-ASN1-EntrezGene



perl-Bio-ASN1-EntrezGene has broken dependencies in the rawhide tree:
On x86_64:
perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires 
perl(Bio::Index::AbstractSeq)
On i386:
perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires 
perl(Bio::Index::AbstractSeq)
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 952589] New: perl-DateTime-1.02 is available

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=952589

Bug ID: 952589
   Summary: perl-DateTime-1.02 is available
   Product: Fedora
   Version: rawhide
 Component: perl-DateTime
  Keywords: FutureFeature, Triaged
  Severity: unspecified
  Priority: unspecified
  Assignee: st...@silug.org
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, perl-devel@lists.fedoraproject.org,
st...@silug.org
  Category: ---

Latest upstream release: 1.02
Current version in Fedora Rawhide: 1.01
URL: http://search.cpan.org/dist/DateTime/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

-- 
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=bVk1Pv1TLNa=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 Object-Tiny-1.08.tar.gz uploaded to lookaside cache by ppisar

2013-04-16 Thread Petr Pisar

A file has been added to the lookaside cache for perl-Object-Tiny:

01faa01e179ea95ec9e792dd0ead64f0  Object-Tiny-1.08.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-Object-Tiny] Import

2013-04-16 Thread Petr Pisar

commit 5adb821982e0b78824128e93b384cff4660bc075
Author: Petr Písař ppi...@redhat.com
Date:   Tue Apr 16 16:02:39 2013 +0200

Import

 .gitignore|1 +
 perl-Object-Tiny.spec |   47 +++
 sources   |1 +
 3 files changed, 49 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..527b829 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Object-Tiny-1.08.tar.gz
diff --git a/perl-Object-Tiny.spec b/perl-Object-Tiny.spec
new file mode 100644
index 000..cfeb6eb
--- /dev/null
+++ b/perl-Object-Tiny.spec
@@ -0,0 +1,47 @@
+Name:   perl-Object-Tiny
+Version:1.08
+Release:1%{?dist}
+Summary:Class building as simple as it gets
+License:GPL+ or Artistic
+Group:  Development/Libraries
+URL:http://search.cpan.org/dist/Object-Tiny/
+Source0:
http://www.cpan.org/authors/id/A/AD/ADAMK/Object-Tiny-%{version}.tar.gz
+BuildArch:  noarch
+BuildRequires:  perl
+BuildRequires:  perl(strict)
+BuildRequires:  perl(vars)
+BuildRequires:  perl(ExtUtils::MakeMaker)
+# Tests:
+BuildRequires:  perl(Test::More) = 0.47
+Requires:   perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+
+%{?perl_default_filter}
+
+%description
+To use Object::Tiny, just call it with a list of accessors to be created.
+This will create a basic new constructor and a bunch of simple accessors,
+and set the inheritance to be the child of Object::Tiny.
+
+%prep
+%setup -q -n Object-Tiny-%{version}
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes examples LICENSE README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Tue Apr 16 2013 Petr Pisar ppi...@redhat.com 1.08-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..5d74185 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+01faa01e179ea95ec9e792dd0ead64f0  Object-Tiny-1.08.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

Broken dependencies: perl-Bio-ASN1-EntrezGene



perl-Bio-ASN1-EntrezGene has broken dependencies in the F-19 tree:
On x86_64:
perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires 
perl(Bio::Index::AbstractSeq)
On i386:
perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires 
perl(Bio::Index::AbstractSeq)
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 851721] Review Request: perl-Net-Nessus-XMLRPC - Communicate with Nessus scanner(v4.2+) via XMLRPC

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=851721

Petr Šabata psab...@redhat.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||psab...@redhat.com
   Assignee|nob...@fedoraproject.org|psab...@redhat.com
  Flags||fedora-review?

--- Comment #3 from Petr Šabata psab...@redhat.com ---
Taking the review along with another Olivier's package, bug #852503.

-- 
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=6szWzP2WCza=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 952722] New: GET content gets truncated randomly and is_error still returns false

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=952722

Bug ID: 952722
   Summary: GET content gets truncated randomly and is_error still
returns false
   Product: Fedora
   Version: 18
 Component: perl-LWP-Protocol-https
  Severity: medium
  Priority: unspecified
  Assignee: ppi...@redhat.com
  Reporter: jlgon...@ya.com
QA Contact: extras...@fedoraproject.org
CC: mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
  Category: ---

Description of problem:

For the same URL and data, content for https GET responses sometimes is
returned truncated, sometimes is returned complete. Truncation point is
different each time. Amusingly, is_error always returns false.

Version-Release number of selected component (if applicable):

This is happening in perl-LWP-Protocol-https version 6.02 release 4.fc16 (in
Fedora Core 16). I have also tried upgrading the package to version 6.03-3.fc18
along with perl-libwww-perl (to 6.04-3.fc18) and the problem is still there.

It works fine with perl-libwww-perl version 5.833 from RHEL 6, which is
previous to the HTTPS split from main LWP.

How reproducible:

In my system, just by GETting the complete vms page from RedHat Enterprise
Virtualization's REST API, which is about 90 KBs long for our systems. The data
transferred contains sensitive data, hence I'm not comfortable including it.
Please let me know if you need any additional info.

Steps to Reproduce:

1. Set up a user agent with hostname_verification and user SSL_ca_file
2. Set up a request for https://server:port/api/vms, pass it to the agent and
check !is_error
3. The response sometimes comes back entire, sometimes truncated at a random
point

Actual results:

The beginning of the correct Virtual Machines XML listing from RHEV truncated
at some random point.

Expected results:

The whole file.

Additional info:

As mentioned, the same script requesting the same URI works fine in RHEL 6. I
am unable at this time to test a full FC 18 system, just did for the https and
LWP packages.

-- 
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=a13TzCUqp1a=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 852503] Review Request: perl-Net-Radius - Object-oriented Perl interface to RADIUS

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=852503

--- Comment #6 from Petr Šabata psab...@redhat.com ---
So I've cloned your git repository...

The spec in your SRPM and outside of it differ.
Please, update the archive first.

-- 
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=tIhOm2lxZxa=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 852503] Review Request: perl-Net-Radius - Object-oriented Perl interface to RADIUS

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=852503

Petr Šabata psab...@redhat.com changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||psab...@redhat.com
   Assignee|nob...@fedoraproject.org|psab...@redhat.com
  Flags||fedora-review?

--- Comment #5 from Petr Šabata psab...@redhat.com ---
(In reply to comment #4)
 Ok, I just did:
 https://github.com/inverse-inc/perl-Net-Radius.spec/commit/
 813b472dfaa0981c0f32aff5da4d0b0f9a6aba2b
 
 The reason I didn't do it is that I thought bumps / ChangeLog entries on
 unreleased packages undergoing a review would only add clutter and little
 value. Repoforge guys handled some of my contributions that way with that
 rationale and so I kept it. 
 
 My plan was that once released, of course, release and changelog will be
 bumped on changes.
 
 Sorry about my wrong assumptions.

I actually agree with you.

Bumping release doesn't really help anything; the reviewer should always check
the real diff from the previously submitted spec.  Tracking those in git is
ridiculously easy.

Still, there are many people in Fedora who prefer release bumps during
reviews...

Anyhow, it doesn't seem like Eduardo is going to work on this so I'll do the
review instead.  I'm also a sponsor so in case I like your packages, I'll take
you in :)

-- 
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=4ii13wVjtda=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 851721] Review Request: perl-Net-Nessus-XMLRPC - Communicate with Nessus scanner(v4.2+) via XMLRPC

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=851721

--- Comment #4 from Petr Šabata psab...@redhat.com ---
Ok, again.  SRPM and spec differ.
Please, fix that first.

-- 
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=fGSRWrj58Aa=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 920081] perl-Net-HTTP-6.06 is available

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=920081

Petr Pisar ppi...@redhat.com changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |ERRATA
Last Closed||2013-04-16 10:55:59

-- 
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=PCkWI80Qyqa=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 768394] LWP::UserAgent cuts chunked response sent through HTTPS

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=768394

Petr Pisar ppi...@redhat.com changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |ERRATA
Last Closed|2013-02-04 22:02:34 |2013-04-16 10:57: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=QVxFEfbKMRa=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 952722] GET content gets truncated randomly and is_error still returns false

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=952722

Petr Pisar ppi...@redhat.com changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |CURRENTRELEASE
Last Closed||2013-04-16 11:00:42

--- Comment #1 from Petr Pisar ppi...@redhat.com ---
There were problems with truncating HTTPS responses by LWP modules when using
IO::Socket::SSL. It has a long history and the problems lies in more packages
then just a perl-LWP-Protocol-https.

I recommend you to read bug #768394 and to pick up other packages like
perl-Net-HTTP.

I believe you will understand that I cannot support your personal mixture of
Fedora 16 and 18. According my records, problem you reported is fixed in Fedora
17 and later.

-- 
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=6K90d65JVBa=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 952722] GET content gets truncated randomly and is_error still returns false

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=952722

--- Comment #2 from José Luis González jlgon...@ya.com ---
I have installed perl-Net-HTTP from Fedora 18 and it fixes the problem.

Thanks for the info. I'm sorry I was wrong assuming the problem was in LWP. I'd
looked there for existing reports.

-- 
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=KrdxKRTgd1a=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-ExtUtils-InstallPaths/f19] (2 commits) ...Drop non-dual-lived buildreqs (#947454)

Summary of changes:

  0669c1c... Initial import (perl-ExtUtils-InstallPaths-0.009-2) (*)
  71a4e20... Drop non-dual-lived buildreqs (#947454) (*)

(*) 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-ExtUtils-InstallPaths/f18] (2 commits) ...Drop non-dual-lived buildreqs (#947454)

Summary of changes:

  0669c1c... Initial import (perl-ExtUtils-InstallPaths-0.009-2) (*)
  71a4e20... Drop non-dual-lived buildreqs (#947454) (*)

(*) 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-ExtUtils-InstallPaths/f17] (2 commits) ...Drop non-dual-lived buildreqs (#947454)

Summary of changes:

  0669c1c... Initial import (perl-ExtUtils-InstallPaths-0.009-2) (*)
  71a4e20... Drop non-dual-lived buildreqs (#947454) (*)

(*) 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-ExtUtils-InstallPaths/el6] (2 commits) ...Drop non-dual-lived buildreqs (#947454)

Summary of changes:

  0669c1c... Initial import (perl-ExtUtils-InstallPaths-0.009-2) (*)
  71a4e20... Drop non-dual-lived buildreqs (#947454) (*)

(*) 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-ExtUtils-InstallPaths/el5] (2 commits) ...Drop non-dual-lived buildreqs (#947454)

Summary of changes:

  0669c1c... Initial import (perl-ExtUtils-InstallPaths-0.009-2) (*)
  71a4e20... Drop non-dual-lived buildreqs (#947454) (*)

(*) 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-ExtUtils-InstallPaths] Created tag perl-ExtUtils-InstallPaths-0.009-3.el5

The lightweight tag 'perl-ExtUtils-InstallPaths-0.009-3.el5' was created 
pointing to:

 71a4e20... Drop non-dual-lived buildreqs (#947454)
--
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-ExtUtils-InstallPaths] Created tag perl-ExtUtils-InstallPaths-0.009-3.el6

The lightweight tag 'perl-ExtUtils-InstallPaths-0.009-3.el6' was created 
pointing to:

 71a4e20... Drop non-dual-lived buildreqs (#947454)
--
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-ExtUtils-InstallPaths] Created tag perl-ExtUtils-InstallPaths-0.009-3.fc17

The lightweight tag 'perl-ExtUtils-InstallPaths-0.009-3.fc17' was created 
pointing to:

 71a4e20... Drop non-dual-lived buildreqs (#947454)
--
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-ExtUtils-InstallPaths] Created tag perl-ExtUtils-InstallPaths-0.009-3.fc18

The lightweight tag 'perl-ExtUtils-InstallPaths-0.009-3.fc18' was created 
pointing to:

 71a4e20... Drop non-dual-lived buildreqs (#947454)
--
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-ExtUtils-InstallPaths] Created tag perl-ExtUtils-InstallPaths-0.009-3.fc19

The lightweight tag 'perl-ExtUtils-InstallPaths-0.009-3.fc19' was created 
pointing to:

 71a4e20... Drop non-dual-lived buildreqs (#947454)
--
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-ExtUtils-InstallPaths] Created tag perl-ExtUtils-InstallPaths-0.009-3.fc20