> On Tue, 19 Feb 2013 20:13:23 +0900, Mamoru TASAKA wrote:
>
> > Well, cifs-mounted filesystem already returns such large inode, and
> > xscreensaver
> > already suffered from this issue.
> > https://bugs.launchpad.net/ubuntu/+source/xscreensaver/+bug/609451/comments/11
>
> About your recent com
Hi all,
This is a patch release primarily to address CVE-2013-1620
For details please see the upstream release notes are at
https://developer.mozilla.org/en-US/docs/NSS/NSS_3.14.3_release_notes
Cheers,
Elio
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mail
On Tue, 19 Feb 2013 20:13:23 +0900, Mamoru TASAKA wrote:
> Well, cifs-mounted filesystem already returns such large inode, and
> xscreensaver
> already suffered from this issue.
> https://bugs.launchpad.net/ubuntu/+source/xscreensaver/+bug/609451/comments/11
About your recent comment there on AC
On Tue, Feb 19, 2013 at 10:10:38PM +0100, Jiri Moskovcak wrote:
> >>So if you want to hack this into a tool for use on kernel bugs, go for
> >>it.
> >...and please integrate with abrt! Let's have it all working together :)
>
> - I am all for it, the abrt server is exactly the place where the
Following is the list of topics that will be discussed in the FESCo
meeting Wednesday at 18:00UTC (1:00pm EST, 19:00 CET) in #fedora-meeting on
irc.freenode.net.
Links to all tickets below can be found at:
https://fedorahosted.org/fesco/report/9
= Followups =
#topic #988 F19 Feature: System Conf
On Mon, 18 Feb 2013 19:37:05 -0500, Sam Varshavchik wrote:
> Eric Sandeen writes:
>
> > and it's not just weird obscure packages:
> >
> > # ./summarize-stat.pl `rpm -ql sendmail`
>
> This is not accurate. -ql will also list directories, and summarize-stat.pl
> then proceeds to chew on every fi
On Tue, Feb 19, 2013 at 2:26 PM, Christoph Wickert
wrote:
> Am Montag, den 18.02.2013, 23:34 + schrieb John5342:
>> On Mon, Feb 18, 2013 at 10:52 PM, Christoph Wickert
>> wrote:
>> > Despite of the question whether it's right or wrong it's a manual
>> > process and we cannot rely it really ha
On Tue, Feb 19, 2013 at 3:01 PM, Paul Wouters wrote:
> On Tue, 19 Feb 2013, Derek Pressnall wrote:
Is this the proper list to ask? Thanks.
>
> Yes it is!
>
> Paul
Cool. First off, I'd like for someone to review my project in general
terms, while I'm working on the RPM, to validate that it wou
On 02/19/2013 10:06 PM, Adam Williamson wrote:
On 19/02/13 10:38 AM, David Malcolm wrote:
On Tue, 2013-02-19 at 11:43 -0500, Dave Jones wrote:
On Tue, Feb 19, 2013 at 07:13:27AM -0500, David Malcolm wrote:
> I have a script that automates some of the workload of
reassigning the
> component
On 19/02/13 10:38 AM, David Malcolm wrote:
On Tue, 2013-02-19 at 11:43 -0500, Dave Jones wrote:
On Tue, Feb 19, 2013 at 07:13:27AM -0500, David Malcolm wrote:
> I have a script that automates some of the workload of reassigning the
> component back to where the bug really is, but it current
On Tue, 19 Feb 2013, Derek Pressnall wrote:
Hello, I'm looking at submitting my first package to Fedora, for a
backup system I recently contributed as open source. I've read
through most of the packaging guidelines (and have been doing RPM
packages in a corporate environment for a few years), b
Hello, I'm looking at submitting my first package to Fedora, for a
backup system I recently contributed as open source. I've read
through most of the packaging guidelines (and have been doing RPM
packages in a corporate environment for a few years), but have a few
Fedora-specific questions. Is th
Package perl-ExtUtils-Typemaps in Fedora devel has been retired by churchyard
To make changes to this package see:
https://admin.fedoraproject.org/pkgdb/acls/name/perl-ExtUtils-Typemaps
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de..
commit 5688d5a3e5d2192413c51ac8e46c274425b52722
Author: Miro Hrončok
Date: Tue Feb 19 20:52:01 2013 +0100
The content of this package is provided by binary package
perl-ExtUtils-ParseXS (from perl source package)
dead.package |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
---
Hi
> On Tue, Feb 19, 2013 at 1:10 PM, Eduardo Jorge
> wrote:
>
>> Fedora has one spin of games, then the packages of games
>> must also be brought up to date, I thin especially about xboard, an
>> interesting games of chess with artificial intelligenc and that is has an
>> obsole
Heya,
gnome-media is unmaintained upstream, and the only interesting thing
left in that package is the sound recorder, for which I'm sure there are
better alternatives (both in terms of UI and maintainership).
gmyth is also unmaintained upstream as far as I know. I haven't used it
in a long while
Hi
On Tue, Feb 19, 2013 at 11:43 AM, Kevin Kofler wrote:
>
> LOL… Any bug report about one of GNOME's intentional "improvements" gets
> instantly closed as INVALID, NOTABUG or WONTFIX (or as a duplicate of an
> existing bug in one of these states).
>
This is of course a false generalization. S
Hi
On Tue, Feb 19, 2013 at 1:10 PM, Eduardo Jorge wrote:
> Fedora has one spin of games, then the packages of games
> must also be brought up to date, I thin especially about xboard, an
> interesting games of chess with artificial intelligenc and that is has an
> obsolete version
On Tue, 2013-02-19 at 11:43 -0500, Dave Jones wrote:
> On Tue, Feb 19, 2013 at 07:13:27AM -0500, David Malcolm wrote:
>
> > I have a script that automates some of the workload of reassigning the
> > component back to where the bug really is, but it currently requires
> > some manual interventi
On 02/17/2013 02:42 PM, Reindl Harald wrote:
"which fool has written" was not and is not offending
in EVERY situation in real life the question to the quote you stripped
would have been clearly "Welcher Trottel hat dann die Feature-Page
geschrieben" in my native language, even if my boss himsel
Petr Pisar wrote:
> Is %configure spec macro the right place to define FILE_OFFSET_BITS?
I'd suggest throwing it into %{_optflags}.
FWIW, all KDE software is already built with -D_FILE_OFFSET_BITS=64,
FindKDE4Internal.cmake forces it (unless off_t is already 64-bit by
default). (Of course, this
Christoph Wickert wrote:
> Maybe it is a corner case, but what you describe is a corner case of the
> corner case. How many updates get actually withdrawn? 1%, 2%, 5%?
At distro EOL, all of them… Way too many updates get stuck in updates-
testing and do not make it out to stable in time for the EO
On 2/19/2013 2:08 AM, Sergei Golubchik wrote:
P.S. Frankly speaking, I didn't realize I was replying to an Oracle
employee :) Thanks for poining it out!
OK - that's funny...
A.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Mathieu Bridon wrote:
> That's called "reporting a bug", and (as far as I'm concerned) it
> actually works, especially when you're specific. You should try it:
> https://bugzilla.gnome.org
LOL… Any bug report about one of GNOME's intentional "improvements" gets
instantly closed as INVALID, N
On Tue, Feb 19, 2013 at 07:13:27AM -0500, David Malcolm wrote:
> I have a script that automates some of the workload of reassigning the
> component back to where the bug really is, but it currently requires
> some manual intervention:
> http://fedorapeople.org/cgit/dmalcolm/public_git/triage.
On 2/19/13 9:22 AM, Eric Sandeen wrote:
> On 2/19/13 4:46 AM, Richard W.M. Jones wrote:
>> On Mon, Feb 18, 2013 at 03:33:33PM -0600, Eric Sandeen wrote:
>>> XFS recently defaulted to allowing > 32 bit inode numbers, and btrfs
>>> can let inode numbers creep past 2^32 as well.
>>>
>>> While most app
On 02/19/2013 05:09 PM, Jakub Jelinek wrote:
You can't use ino_t and off_t in public header files because of that
_FILE_OFFSET_BITS dependency. At least in such header files, using
explicit 64-bit types (uint64_t, presumably) is the way to go.
You can use it in public header files just fine,
On Tue, Feb 19, 2013 at 05:04:43PM +0100, Florian Weimer wrote:
> On 02/19/2013 04:32 PM, Jakub Jelinek wrote:
> >On Tue, Feb 19, 2013 at 09:22:55AM -0600, Eric Sandeen wrote:
> >>>(3) For my code that uses st_ino, I need to ensure this is never
> >>>assigned to a 32 bit integer (eg. 'int', 'int32_
On 02/19/2013 04:32 PM, Jakub Jelinek wrote:
On Tue, Feb 19, 2013 at 09:22:55AM -0600, Eric Sandeen wrote:
(3) For my code that uses st_ino, I need to ensure this is never
assigned to a 32 bit integer (eg. 'int', 'int32_t', 'long' on 32 bit, etc.)?
To be safe I'd use it in an u64 type, I guess
Thanks guys
2013/2/19 Miroslav Suchý
> On 02/19/2013 03:43 PM, Sergio Belkin wrote:
>
>> Hi, rpmlint complains about cron files, is that a bug?
>>
>> For example:
>>
>> tmpwatch.x86_64: E: executable-marked-as-config-**file
>> /etc/cron.daily/tmpwatch
>> Executables must not be marked as config
On 2/19/13 9:32 AM, Jakub Jelinek wrote:
> On Tue, Feb 19, 2013 at 09:22:55AM -0600, Eric Sandeen wrote:
>>> (3) For my code that uses st_ino, I need to ensure this is never
>>> assigned to a 32 bit integer (eg. 'int', 'int32_t', 'long' on 32 bit, etc.)?
>>
>> To be safe I'd use it in an u64 type,
commit 3e13179037b8dd298a88da159d362c1d78953e5a
Author: Iain Arnell
Date: Tue Feb 19 08:37:02 2013 -0700
update to 0.78
.gitignore|1 +
perl-Devel-PatchPerl.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
d
A file has been added to the lookaside cache for perl-Devel-PatchPerl:
3b94806ad28da14e8c6d19e1a4ebbb22 Devel-PatchPerl-0.78.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.o
On Tue, Feb 19, 2013 at 09:22:55AM -0600, Eric Sandeen wrote:
> > (3) For my code that uses st_ino, I need to ensure this is never
> > assigned to a 32 bit integer (eg. 'int', 'int32_t', 'long' on 32 bit, etc.)?
>
> To be safe I'd use it in an u64 type, I guess. The *internal* kernel stat
> struc
On 02/19/2013 03:43 PM, Sergio Belkin wrote:
Hi, rpmlint complains about cron files, is that a bug?
For example:
tmpwatch.x86_64: E: executable-marked-as-config-file
/etc/cron.daily/tmpwatch
Executables must not be marked as config files because that may prevent
upgrades from working correctly.
On Tue, Feb 19, 2013 at 11:43:53AM -0300, Sergio Belkin wrote:
> Hi, rpmlint complains about cron files, is that a bug?
> For example:
> tmpwatch.x86_64: E: executable-marked-as-config-file
> /etc/cron.daily/tmpwatch
> Executables must not be marked as config files because that may prevent
> upgrad
On 02/19/2013 12:25 AM, Eduardo Jorge wrote:
> I guess tck;tk 8.6 is a very nice update to Fedora 19.
Already reported: http://bugzilla.redhat.com/889201
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On 2/19/13 4:46 AM, Richard W.M. Jones wrote:
> On Mon, Feb 18, 2013 at 03:33:33PM -0600, Eric Sandeen wrote:
>> XFS recently defaulted to allowing > 32 bit inode numbers, and btrfs
>> can let inode numbers creep past 2^32 as well.
>>
>> While most applications don't care one bit about st_ino retur
On Tue, 2013-02-19 at 03:52 -0500, Jaroslav Reznik wrote:
> As Adam pointed out - Bugzilla is not a best tool. The script I was
> given is neither a state of the art. Definitely it could be
> enhanced - semi-atomic operations to avoid conflicts, more clever
> work with BZ states. But more complex
On 2/19/13 6:48 AM, Petr Pisar wrote:
> On 2013-02-18, Eric Sandeen wrote:
>>
>> Anyway, if you want to check your package(s) and maybe make them
>> 64-bit-stat safe, the perl script above might help. It's more than
>> just -DFILE_OFFSET_BITS=64, since you'll need to be sure not to
>> overflow an
On 02/19/2013 07:50 AM, Andrea Pescetti wrote:
It will be clarified. The concern there started with the assumption
that "yum install OpenOffice.org" would install something else. It
doesn't, of course. So the following discussion is largely irrelevant,
but again we will be following the FES
On 02/19/2013 01:49 AM, Chris Murphy wrote:
On Feb 18, 2013, at 10:13 PM, Digimer wrote:
what's "offline data collection"?
http://smartmontools.sourceforge.net/man/smartctl.8.html
Read in particular the paragraph containing the word unfortunate.
0x0009 2 19 Transition from d
commit 4e7dc97b084c041b7fa324b88cea6e1063ab7647
Author: Iain Arnell
Date: Tue Feb 19 07:49:29 2013 -0700
update to 1.008007
.gitignore |1 +
perl-local-lib.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.g
Hi, rpmlint complains about cron files, is that a bug?
For example:
tmpwatch.x86_64: E: executable-marked-as-config-file
/etc/cron.daily/tmpwatch
Executables must not be marked as config files because that may prevent
upgrades from working correctly. If you need to be able to customize an
executa
A file has been added to the lookaside cache for perl-local-lib:
6a22da47099fafd664a9fd7c7b24805c local-lib-1.008007.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/mailm
On 2013-02-19, Richard W.M. Jones wrote:
> On Tue, Feb 19, 2013 at 12:33:07PM +, Petr Pisar wrote:
>> EOVERFLOW
>> (stat()) path refers to a file whose size cannot be represented
>> in the type off_t. This can occur when an application compiled
>> on a 32-bit platform with
Am Montag, den 18.02.2013, 23:34 + schrieb John5342:
> On Mon, Feb 18, 2013 at 10:52 PM, Christoph Wickert
> wrote:
> > Despite of the question whether it's right or wrong it's a manual
> > process and we cannot rely it really happens. On the other hand changing
> > the script to not close any
This Feature has been submitted *before* Feature Submission Deadline and it
required input/changes from the owner or it was queued.
= Features/ResourceManagementTools =
https://fedoraproject.org/wiki/Features/ResourceManagementTools
Feature owner(s): Daniel Berrange
This feature will provide a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
El Fri, 8 Feb 2013 03:40:09 -0600
Dennis Gilmore escribió:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> it was requested in https://fedorahosted.org/fesco/ticket/1004 that
> we do a mass rebuild for Fedora 19 for
> http://fedoraproject.org/w
On Tue, Feb 19, 2013 at 12:33:07PM +, Petr Pisar wrote:
> EOVERFLOW
> (stat()) path refers to a file whose size cannot be represented
> in the type off_t. This can occur when an application compiled
> on a 32-bit platform without -D_FILE_OFFSET_BITS=64 calls stat()
>
On 2013-02-18, Eric Sandeen wrote:
>
> Anyway, if you want to check your package(s) and maybe make them
> 64-bit-stat safe, the perl script above might help. It's more than
> just -DFILE_OFFSET_BITS=64, since you'll need to be sure not to
> overflow any large values you get back from stat64 etc.
On 2013-02-19, Richard W.M. Jones wrote:
> On Mon, Feb 18, 2013 at 03:33:33PM -0600, Eric Sandeen wrote:
> (1) Just ensuring the code is compiled with -DFILE_OFFSET_BITS=64 is
> sufficient to ensure the 32 bit stat will never be called, right?
>
I think so.
> (2) If my code never mentions st_ino,
Eric Sandeen wrote, at 02/19/2013 06:33 AM +9:00:
XFS recently defaulted to allowing > 32 bit inode numbers, and btrfs can let
inode numbers creep past 2^32 as well.
While most applications don't care one bit about st_ino returned from a stat()
call, the sad fact is that you'll get EOVERFLOW fro
Hi, Adam!
On Feb 19, Adam Williamson wrote:
> >
> > A lot of new features - yes, undoubtely.
> > Performance improvements - questionable.
> > This link shows a very different picture:
> > http://blog.mariadb.org/sysbench-oltp-mysql-5-6-vs-mariadb-10-0/
>
> I'm not sure we need Oracle and Maria to
I've hit gnomeshell problem for 13 times and rtythmbox for 7 times.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Mon, Feb 18, 2013 at 03:33:33PM -0600, Eric Sandeen wrote:
> XFS recently defaulted to allowing > 32 bit inode numbers, and btrfs
> can let inode numbers creep past 2^32 as well.
>
> While most applications don't care one bit about st_ino returned
> from a stat() call, the sad fact is that you'l
Ok, llvm-3.2 is now in F19 Rawhide. [1]
Mesa, gambas3, and OpenGTL have been rebuilt, which
should take care of libllvm dependencies,
except for "pure" which no longer seems [2] to build with libedit [3]. :-|
Jens
[1] http://koji.fedoraproject.org/koji/taskinfo?taskID=5031762
[2]
http://koji.fe
On 18/02/13 09:01 PM, Sergei Golubchik wrote:
Hi, Andrew!
On Feb 18, Andrew Rist wrote:
No, it's not crippleware - it's the world's most popular open source
database software.
A world's most popular open source database software can be crippleware
too. Wikipedia defines crippleware as
"
De
- Original Message -
> On Mon, Feb 18, 2013 at 10:52 PM, Christoph Wickert
> wrote:
> > Despite of the question whether it's right or wrong it's a manual
> > process and we cannot rely it really happens. On the other hand
> > changing
> > the script to not close any bugs which are ON_QA is
>
> Regards,
> Andrea.
Thanks kindly for the update!
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
60 matches
Mail list logo
