On Wed, 2013-06-26 at 16:01 +0200, Volker Fröhlich wrote:
On Wed, 2013-06-26 at 09:52 -0300, Paulo César Pereira de Andrade wrote:
2013/6/26 Remi Collet fed...@famillecollet.com:
Le 26/06/2013 14:36, Paulo César Pereira de Andrade a écrit :
Hi,
It is taking a bit too long for
On Wed, Jun 26, 2013 at 02:41:42PM -0700, Adam Williamson wrote:
On Wed, 2013-06-26 at 13:50 +0100, Richard W.M. Jones wrote:
On Tue, Jun 25, 2013 at 12:46:05PM +, Fedora Branched Report wrote:
Compose started at Tue Jun 25 09:15:02 UTC 2013
Broken deps for x86_64
The issue seems to be that the minimum-required nspr version in xulrunner
is determined by
pkg-config --modversion nspr
which returns 4.10.0, the package version however is 4.10 (without the
trailing .0). This causes the builddep resolution to fail when building
firefox.
On Thu, Jun 27, 2013 at
Yes, that's it. But it looks like a rpm bug to me. Or we need to fix the
nspr package to provide a correct modversion...no not a
xulrunner/firefox issue after all.
ma.
On 27.6.2013 12:26, Sandro Mani wrote:
The issue seems to be that the minimum-required nspr version in xulrunner
is
On Wed, Jun 26, 2013 at 02:27:32PM -0700, Adam Williamson wrote:
On Wed, 2013-06-26 at 14:24 -0700, Adam Williamson wrote: On Wed, 2013-06-26
at 23:21 +0200, Marcel J.E. Mol wrote: On Wed, Jun 26, 2013 at 01:22:21PM
-0700, Adam Williamson wrote: On Wed, 2013-06-26 at 20:40 +0200, Marcel
Hi,
Recently I've seen multiple issues related to new file creation by logrotate(8).
A race condition described by [1], between creation of a new file and setting
file permissions and acl(5). Another I came across in ndjbdns [2], as it
continued
to write to an open, but rotated log file.
On Wed, Jun 26, 2013 at 1:14 PM, Bruno Wolff III br...@wolff.to wrote:
On Wed, Jun 26, 2013 at 08:44:36 -0500,
Dennis Gilmore den...@ausil.us wrote:
no, because pungi the tool that creates the source dvd doesnt support
split media. I actually want to stop making source dvds all together.
On 06/27/2013 01:54 PM, P J P wrote:
Hi,
Recently I've seen multiple issues related to new file creation by logrotate(8).
A race condition described by [1], between creation of a new file and setting
file permissions and acl(5). Another I came across in ndjbdns [2], as it
continued
to
Compose started at Thu Jun 27 08:15:02 UTC 2013
Broken deps for x86_64
--
[chmsee]
chmsee-2.0-5.git0acc572a.fc20.x86_64 requires libxpcom.so()(64bit)
[ekiga]
ekiga-4.0.1-1.fc19.x86_64 requires libedata-book-1.2.so.17()(64bit)
Compose started at Thu Jun 27 09:15:02 UTC 2013
Broken deps for x86_64
--
[avgtime]
avgtime-0-0.5.git20120724.fc19.x86_64 requires
libphobos-ldc.so.60()(64bit)
[derelict]
derelict-ogg-3-13.20130516gitd8aa11d.fc19.i686
Hi Martin,
Definitely not a rpm bug. rpm's version comparison semantics are well
defined and 4.10.0 is strictly higher than 4.10.
I would say one of the 3 things should happen to fix this:
1) Build the latest nspr release not as version 4.10, but as 4.10.0
(As I understand it, it's a
Hello Jan,
- Original Message -
From: Jan Kaluža jkal...@redhat.com
Subject: Re: logrotate(8) and copytruncate as default
This is usually fixed by sending some signal to daemon in postscript
informing it that logs should be reopened. That way, no messages are
lost. The worst
On 06/26/2013 08:01 AM, Volker Fröhlich wrote:
GDAL is currently broken because it needs a rebuild for Poppler, but the
Texlive build is broken, as far as I can see.
texlive has now been rebuilt.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA
Hello Jan,
- Original Message -
From: Jan Kaluža jkal...@redhat.com
Subject: Re: logrotate(8) and copytruncate as default
I'm not sure right now if the benefits of the copytruncate usage are
strong enough in comparison with the possibility to lost the messages
during rotation.
- Original Message -
Hello Jan,
- Original Message -
From: Jan Kaluža jkal...@redhat.com
Subject: Re: logrotate(8) and copytruncate as default
I'm not sure right now if the benefits of the copytruncate usage are
strong enough in comparison with the possibility to
On Thu, 2013-06-27 at 14:29 +0200, Jan Kaluža wrote:
This is usually fixed by sending some signal to daemon in postscript
informing it that logs should be reopened. That way, no messages are
lost. The worst thing which can happen is that some messages get logged
in the rotated file for
On Thu, Jun 27, 2013 at 5:19 PM, P J P pj.pan...@yahoo.co.in wrote:
- Original Message -
From: Jan Kaluža jkal...@redhat.com
Subject: Re: logrotate(8) and copytruncate as default
This is usually fixed by sending some signal to daemon in postscript
informing it that logs should be
- Original Message -
On Thu, Jun 27, 2013 at 5:19 PM, P J P pj.pan...@yahoo.co.in wrote:
- Original Message -
From: Jan Kaluža jkal...@redhat.com
Subject: Re: logrotate(8) and copytruncate as default
This is usually fixed by sending some signal to daemon in postscript
On Thu, Jun 27, 2013 at 6:49 PM, Jan Kaluza jkal...@redhat.com wrote:
I have the same opinion for now, but I will at least try to evaluate
that locking idea. Maybe it can end up like more reliable
copytruncate directive.
I've been looking at that option - AFAICS mandatory file locking, at
Hi,
- Original Message -
From: Jan Kaluza jkal...@redhat.com
Subject: Re: logrotate(8) and copytruncate as default
Right now, without locking, logrotate would loss more messages if the
logs are big, because copying takes more time. It would be interesting
to mention the file size
- Original Message -
From: Colin Walters walt...@verbum.org
Subject: Re: logrotate(8) and copytruncate as default
It's worth noting that all of these problems go away with the systemd
journal.
Oh, how does systemd rotate files?
---
Regards
-Prasad
http://feedmug.com
--
Hello Miloslav,
- Original Message -
From: Miloslav Trmač m...@volny.cz
Subject: Re: logrotate(8) and copytruncate as default
That's a possible argument for changing the ndjbdns logging/logrotate
configuration, AFAICS not an argument for changing the default.
Yes, 'ndjbdns'
On Thu, Jun 27, 2013 at 7:58 PM, P J P pj.pan...@yahoo.co.in wrote:
IMHO, renaming a
file which is being written to by another application does no feel right.
_Any_ data loss during normal operation is _unacceptable_.
Sure! As per the experiment so far, there is no data loss at all.
There
On 06/27/2013 08:12 AM, Kalev Lember wrote:
Hi Martin,
Definitely not a rpm bug. rpm's version comparison semantics are well
defined and 4.10.0 is strictly higher than 4.10.
Martin, Kai, and I have discussed itand have proposal consistent with yours.
I would say one of the 3 things should
We should've known it was too good to last!
Martin Banas fortunately caught a major bug in RC2 overnight:
https://bugzilla.redhat.com/show_bug.cgi?id=978852
so we are currently testing RC3 which includes a fix for that. RC3 has
not technically been released yet, but the main images - DVD,
Hello Mirek,
- Original Message -
From: Miloslav Trmač m...@volny.cz
Subject: Re: logrotate(8) and copytruncate as default
* logrotate reads all contents of file until EOF
* application appends one more data line
* logrotate calls truncate()
I see. Thanks for these input, will
On Fri, 2013-06-28 at 01:44 +0800, P J P wrote:
- Original Message -
From: Colin Walters walt...@verbum.org
Subject: Re: logrotate(8) and copytruncate as default
It's worth noting that all of these problems go away with the systemd
journal.
Oh, how does systemd rotate
On Thu, Jun 27, 2013 at 6:57 PM, Miloslav Trmač m...@volny.cz wrote:
On Thu, Jun 27, 2013 at 6:49 PM, Jan Kaluza jkal...@redhat.com wrote:
I have the same opinion for now, but I will at least try to evaluate
that locking idea. Maybe it can end up like more reliable
copytruncate directive.
On Thu, Jun 27, 2013 at 03:46:22PM -0400, Colin Walters wrote:
(Although it is presently not possible to easily have rotation limits
per-service and such, which is something fairly easy to do with sysvinit
+ logrotate).
Is there an RFE for this? Like the time-based rotation limit added
NOTE: The 32- and 64-bit Security Lab Spins are over their size limit of
700 MiB.
As per the Fedora 19 schedule [1], Fedora 19 Final Release Candidate 3
(RC3) is now available for testing. Content information, including
changes, can be found at
On Fri, 28.06.13 01:44, P J P (pj.pan...@yahoo.co.in) wrote:
From: Colin Walters walt...@verbum.org
Subject: Re: logrotate(8) and copytruncate as default
It's worth noting that all of these problems go away with the systemd
journal.
Oh, how does systemd rotate files?
We do
On Thu, 27.06.13 15:46, Colin Walters (walt...@verbum.org) wrote:
On Fri, 2013-06-28 at 01:44 +0800, P J P wrote:
- Original Message -
From: Colin Walters walt...@verbum.org
Subject: Re: logrotate(8) and copytruncate as default
It's worth noting that all of these problems
On Thu, 2013-06-27 at 23:38 +0200, Lennart Poettering wrote:
Why would you want this? I mean, we rate-limit per-service anyway, so
the issue of one app flooding evreything else should be mostly
non-existant. And hence, what you are asking for is some policy control
about what to delete first,
At the Fedora 19 Final Go/No-Go Meeting that just occurred, it was
agreed to Go with the Fedora 19 by Fedora QA, development, release
engineering and FPM.
Fedora 19 will be publicly available on Tuesday, July 02, 2013.
Thank you everyone for heroic effort on this release!
Meeting details can be
Hey, folks. So I've belatedly put the F19 QA Retrospective page up here:
https://fedoraproject.org/wiki/Fedora_19_QA_Retrospective
For the newer folks or those older folks who've forgotten, the
Retrospective page aims to gather feedback on the test/validation
process as we go through it. It's a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 26 Jun 2013 15:52:02 +0100
Frank Murphy frankl...@gmail.com wrote:
On Wed, 26 Jun 2013 08:44:36 -0500
Dennis Gilmore den...@ausil.us wrote:
no, because pungi the tool that creates the source dvd doesnt
support split media. I
- Original Message -
On Thu, 2013-06-27 at 23:38 +0200, Lennart Poettering wrote:
Why would you want this? I mean, we rate-limit per-service anyway, so
the issue of one app flooding evreything else should be mostly
non-existant. And hence, what you are asking for is some policy
Hello Lennart, Colin,
- Original Message -
From: Lennart Poettering mzerq...@0pointer.de
Subject: Re: logrotate(8) and copytruncate as default
The systemd-journald takes care of all of: receiving messages, writing
them to storage, and rotating the storage.
We do synchronous
- Original Message -
Hello Lennart, Colin,
- Original Message -
From: Lennart Poettering mzerq...@0pointer.de
Subject: Re: logrotate(8) and copytruncate as default
The systemd-journald takes care of all of: receiving messages, writing
them to storage, and rotating
Hello Jan,
- Original Message -
From: Jan Kaluza jkal...@redhat.com
Subject: Re: logrotate(8) and copytruncate as default
I think difference between systemd and logrotate in this case is that
logrotate is not owner of the logs it rotates. It has no control of writing
to them. I
Hello.
I've got bugreport that Erlang doesn't work on EL6 PPC64 achitecture.
https://bugzilla.redhat.com/show_bug.cgi?id=958953
I don't have resources to fix this issue, and nobody volunteered to
fix it so far, so I'd like to limit Erlang, and Erlang applications
and libraries on EL6 to
A file has been added to the lookaside cache for perl-Image-Size:
908db185487fabdd293f7759113b3a49 Image-Size-3.232.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://bugzilla.redhat.com/show_bug.cgi?id=978869
Bug ID: 978869
Summary: perl-Image-Size does not build on rawhide
Product: Fedora
Version: rawhide
Component: perl-Image-Size
Severity: unspecified
Priority: unspecified
https://bugzilla.redhat.com/show_bug.cgi?id=978869
Petr Šabata psab...@redhat.com changed:
What|Removed |Added
Status|NEW |ASSIGNED
commit 3fc144d11447ae23a42661848f1d448b2fedc3fc
Author: Jitka Plesnikova jples...@redhat.com
Date: Thu Jun 27 12:29:05 2013 +0200
Update BRs
perl-ExtUtils-MakeMaker.spec |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-ExtUtils-MakeMaker.spec
https://bugzilla.redhat.com/show_bug.cgi?id=892597
--- Comment #4 from František Dvořák val...@civ.zcu.cz ---
Thanks for the review, I'll incorporate the changes.
About the header file in separate subpackage: there is mentioned in Perl
section the header files shouldn't be split off (but maybe
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
perl-Bio-SamTools has broken dependencies in the F-19 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-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
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-PDL has broken dependencies in the rawhide tree:
On x86_64:
perl-PDL-2.4.10-6.fc19.x86_64 requires libgd.so.2()(64bit)
On i386:
perl-PDL-2.4.10-6.fc19.i686 requires libgd.so.2
Please resolve this as soon as possible.
--
Fedora Extras Perl SIG
https://bugzilla.redhat.com/show_bug.cgi?id=892597
--- Comment #5 from Petr Šabata psab...@redhat.com ---
You're right, keep that part as is :)
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug
https://bugzilla.redhat.com/show_bug.cgi?id=979143
Bug ID: 979143
Summary: rpm -q --provides perl has superfluous output
Product: Fedora
Version: 19
Component: perl
Severity: low
Priority: unspecified
Assignee:
https://bugzilla.redhat.com/show_bug.cgi?id=892597
--- Comment #6 from František Dvořák val...@civ.zcu.cz ---
Spec URL:
http://scientific.zcu.cz/fedora/glite-lb-types-2.0.7-2/glite-lb-types.spec
SRPM URL:
http://scientific.zcu.cz/fedora/glite-lb-types-2.0.7-2/glite-lb-types-2.0.7-2.fc20.src.rpm
54 matches
Mail list logo
