On 27/06/13 17:31, Orion Poplawski wrote:
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.
We've got a working GDAL build again.
Volker
--
dev
On Thu, 2013-06-27 at 18:41 -0400, Colin Walters wrote:
> 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 yo
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 x86/x86_6
Hello Jan,
- Original Message -
> From: Jan Kaluza
> 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 haven't check
- Original Message -
> Hello Lennart, Colin,
>
> - Original Message -
> > From: Lennart Poettering
> > 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 sto
Hello Lennart, Colin,
- Original Message -
> From: Lennart Poettering
> 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 rotation before e
- 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 26 Jun 2013 15:52:02 +0100
Frank Murphy wrote:
> On Wed, 26 Jun 2013 08:44:36 -0500
> Dennis Gilmore wrote:
>
>
> >
> > no, because pungi the tool that creates the source dvd doesnt
> > support split media. I actually want to stop making
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 p
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
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 fir
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
> > > Subject: Re: logrotate(8) and copytruncate as default
> > > It's worth noting that all of these problems go awa
On Fri, 28.06.13 01:44, P J P (pj.pan...@yahoo.co.in) wrote:
> > From: Colin Walters
> > 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 synchronous rota
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
https://fedorahosted.org/rel-eng/ticket/5623#comment:
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 earli
On Thu, Jun 27, 2013 at 6:57 PM, Miloslav Trmač wrote:
> On Thu, Jun 27, 2013 at 6:49 PM, Jan Kaluza 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
On Fri, 2013-06-28 at 01:44 +0800, P J P wrote:
> - Original Message -
>
> > From: Colin Walters
> > 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?
Th
Hello Mirek,
- Original Message -
> From: Miloslav Trmač
> 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 conside
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, netins
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 hap
On Thu, Jun 27, 2013 at 7:58 PM, P J P 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 can be a data
Hello Miloslav,
- Original Message -
> From: Miloslav Trmač
> 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' has alrea
- Original Message -
> From: Colin Walters
> 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
--
devel mailing list
Hi,
- Original Message -
> From: Jan Kaluza
> 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 in your tests t
On Thu, Jun 27, 2013 at 6:49 PM, Jan Kaluza 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
least currently, doe
- Original Message -
> On Thu, Jun 27, 2013 at 5:19 PM, P J P wrote:
> > - Original Message -
> >> From: Jan Kaluža
> >> Subject: Re: logrotate(8) and copytruncate as default
> >> This is usually fixed by sending some signal to daemon in postscript
> >> informing it that logs shou
On Thu, Jun 27, 2013 at 5:19 PM, P J P wrote:
> - Original Message -
>> From: Jan Kaluža
>> 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
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
- Original Message -
> Hello Jan,
>
> - Original Message -
> > From: Jan Kaluža
> > 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
Hello Jan,
- Original Message -
> From: Jan Kaluža
> 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.
I did
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 Off
Hello Jan,
- Original Message -
> From: Jan Kaluža
> 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 thing which can ha
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 manual
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 require
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)
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 writ
On Wed, Jun 26, 2013 at 1:14 PM, Bruno Wolff III wrote:
> On Wed, Jun 26, 2013 at 08:44:36 -0500,
> Dennis Gilmore 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.
>> but that will need
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.
Wo
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, M
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 determine
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 4
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
> > >
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 :
> > > Le 26/06/2013 14:36, Paulo César Pereira de Andrade a écrit :
> > >> Hi,
> > >>
> > >> It is taking a bit too long for some depe
43 matches
Mail list logo
