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
> inclus
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 per
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
On Mon, Apr 15, 2013 at 09:32:53PM -0700, Adam Williamson wrote:
> https://dl.fedoraproject.org/pub/alt/stage/19-Alpha-RC3/
I'll try Alpha RC3 tomorrow (I'm not near my UEFI hardware today), but I
have run into an interesting problem with the backup GPT label and I
wonder if anyone else has seen i
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 dro
On Mon, Apr 15, 2013 at 11:19 PM, Richard W.M. Jones wrote:
> 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, E
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) >=
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 pro
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 a
Hi,
On Mon, 15 Apr 2013 09:41:03 +
Abdellah Ben 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
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 the
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.fedoraprojec
Hi,
2013/4/16 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
commit 789c0e9e48036645ce482658b2511c526e83ddb6
Author: Paul Howarth
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
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/pe
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 wrote:
>
> > 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,
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.fedoraproje
commit 0669c1cc5e5bffc7d0300390023a4ee181a6551d
Author: Paul Howarth
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
commit 71a4e20deb2d586793fc49bd090e922e442aebea
Author: Paul Howarth
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.sp
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 i
On Tue, Apr 16, 2013 at 3:47 AM, Remi Collet wrote:
> 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
>
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 &
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
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
> 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
> 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
#include
#include
#include
#include
#include
char buf[8192];
main()
{
On 15/04/13 09:48 AM, Miloslav Trmač wrote:
On Sat, Apr 13, 2013 at 7:51 PM, Reindl Harald 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 exploitab
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
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 r
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 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
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
Once upon a time, Adam Williamson 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.fedo
On Tue, Apr 16, 2013 at 9:25 PM, Dan Fruehauf 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 bi
# 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
在 2013-4-17 AM9:26，"Dan Fruehauf" 写道：
> 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
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
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 t
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 wrote:
> On 04/17/2013 10:25 AM, Dan Fruehauf wrote:
> > That's around 50K, and compressed (RPMs are compr
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
John Reiser 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 d
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
42 matches
Mail list logo
