On 02/10/2010 01:12 AM, Till Maas wrote:
> On Sat, Feb 06, 2010 at 04:22:27PM +0100, Till Maas wrote:
>
>> For yum related python backtrace bugs, it worked pretty well here and
>> made bug reporting a lot easier. So maybe it should only be activated
>> for cases where additional debuginfo is not ne
On Wed, Feb 10, 2010 at 10:23:48AM +0100, Jiri Moskovcak wrote:
> I think I did catch it (if ABRT was running), but ordinary users can't
> see other user's crashes (the command from this bz has to be run under
> root) unless root doesn't change this behaviour in abrt's config file.
What do I ha
Hi,
On Wed, Feb 10, 2010 at 12:51 AM, Roland McGrath wrote:
>> Replace
>> make CFLAGS="%{optflags} -X11" %{?_smp_mflags}
>> with
>> make CFLAGS="%{optflags}" LDFLAGS="-lX11" %{?_smp_mflags}
>
> This is still not really ideal. For the long run, you should be fixing the
> upstream package so th
On 02/10/2010 10:42 AM, Till Maas wrote:
> On Wed, Feb 10, 2010 at 10:23:48AM +0100, Jiri Moskovcak wrote:
>
>> I think I did catch it (if ABRT was running), but ordinary users can't
>> see other user's crashes (the command from this bz has to be run under
>> root) unless root doesn't change this b
There was a nasty flaw in _every_ automake-generated Makefile.in
until recently[*]. When making releases, most of us who maintain
automake-using packages run "make dist" or "make distcheck".
Even if you don't, your users may. The flaw put all of us at risk.
With a Makefile.in file generated by u
On Wed, Feb 10, 2010 at 10:58:03AM +0100, Jiri Moskovcak wrote:
> You need to add this to the respective analyzer's configs:
>
> InformAllUsers = yes
>
> CCpp.conf - C/C++ xrashes analyzer
> Python.conf - python analyzer
> Kerneloops.conf - kerneloops (already has this enabled)
>
> But this app
On Wed, 2010-02-10 at 10:58 +0100, Jim Meyering wrote:
> There was a nasty flaw in _every_ automake-generated Makefile.in
> until recently[*]. When making releases, most of us who maintain
> automake-using packages run "make dist" or "make distcheck".
> Even if you don't, your users may. The flaw
Jim Meyering wrote:
> There was a nasty flaw in _every_ automake-generated Makefile.in
> until recently[*]. When making releases, most of us who maintain
To clarify, the vulnerability affects the "distdir" commands
that appear only in so-called top-level Makefile.in files.
Note however, that some
On Sun, Feb 07, 2010 at 10:29:55PM +, Richard W.M. Jones wrote:
> On Fri, Feb 05, 2010 at 08:29:00PM +0100, Till Maas wrote:
> > Hiyas,
> >
> > is there a simple build system for personal repos available? E.g. give
> > it an srpm and then it will build it for several mock configs, ask to
> > s
Parag N(पराग़) wrote, at 02/10/2010 02:58 AM +9:00:
> On Tue, Feb 9, 2010 at 11:18 PM, Jakub Jelinek wrote:
>> On Tue, Feb 09, 2010 at 11:09:50PM +0530, Parag N(पराग़) wrote:
>>> Anyway I find adding missing DSO to CFLAGS in SPEC is easy solution for
>>> now.
>> They don't belong to CFLAGS, those
On Wed, Feb 10, 2010 at 08:42:53PM +0900, Mamoru Tasaka wrote:
> Parag N(पराग़) wrote, at 02/10/2010 02:58 AM +9:00:
> > On Tue, Feb 9, 2010 at 11:18 PM, Jakub Jelinek wrote:
> >> On Tue, Feb 09, 2010 at 11:09:50PM +0530, Parag N(पराग़) wrote:
> >>> Anyway I find adding missing DSO to CFLAGS in SPE
Jon Masters wrote:
> On Wed, 2010-02-10 at 10:58 +0100, Jim Meyering wrote:
>> There was a nasty flaw in _every_ automake-generated Makefile.in
>> until recently[*]. When making releases, most of us who maintain
>> automake-using packages run "make dist" or "make distcheck".
>> Even if you don't,
Compose started at Wed Feb 10 08:15:05 UTC 2010
Broken deps for i386
--
PySolFC-cardsets-2.0-2.fc13.noarch requires PySolFC = 0:1.1
blahtexml-0.6-5.fc12.i686 requires libxerces-c.so.28
doodle-0.6.7-5.fc12.i686 requires
Hi,
On Wed, Feb 10, 2010 at 5:27 PM, Jakub Jelinek wrote:
> On Wed, Feb 10, 2010 at 08:42:53PM +0900, Mamoru Tasaka wrote:
>> Parag N(पराग़) wrote, at 02/10/2010 02:58 AM +9:00:
>> > On Tue, Feb 9, 2010 at 11:18 PM, Jakub Jelinek wrote:
>> >> On Tue, Feb 09, 2010 at 11:09:50PM +0530, Parag N(पराग़
On Mon, 2010-01-18 at 17:02 -0500, Paul W. Frields wrote:
> On Mon, Jan 18, 2010 at 01:59:27PM -0700, Stephen John Smoogen wrote:
> > I just wanted to say thanks to the guys who integrated ABRT into F12.
> > It has rough edges and I know it needs improvement, but I have filed
> > more 'bugs' than i
I'm trying to track down a bug (563103) which only occurs in Koji. We
think it may be because the Rawhide qemu binary, when it runs on the
Koji RHEL 5 kernel, makes some system call that returns -EINVAL.
Unfortunately qemu turns -EINVAL from a host system call into an
emulated disk error. If qem
On Wed, 10 Feb 2010, Richard W.M. Jones wrote:
>
> I'm trying to track down a bug (563103) which only occurs in Koji. We
> think it may be because the Rawhide qemu binary, when it runs on the
> Koji RHEL 5 kernel, makes some system call that returns -EINVAL.
> Unfortunately qemu turns -EINVAL f
On Wed, Feb 10, 2010 at 09:35:07AM -0500, Seth Vidal wrote:
>
>
> On Wed, 10 Feb 2010, Richard W.M. Jones wrote:
>
> >
> > I'm trying to track down a bug (563103) which only occurs in Koji. We
> > think it may be because the Rawhide qemu binary, when it runs on the
> > Koji RHEL 5 kernel, makes
On Sat, 2010-02-06 at 10:53 +, Leigh Scott wrote:
> IMO ABRT isn't that useful as a lot of the reports don't include steps
> to reproduce (I just close the bugs after a month if they don't respond
> to the "needinfo" request).
You can do it even sooner. If backtrace is unusable and there is no
On Wed, 2010-02-10 at 15:48 +0100, Denys Vlasenko wrote:
> but then user might well enter description consisting of
> "I dont care" (or worse).
>
> --
> vda
>
>
That would ease my conscience when I closed the bug report :-)
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.f
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-PPI/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv16468
Modified Files:
perl-PPI.spec
Log Message:
* Wed Feb 10 2010 Marcela Mašláňová - 1.206-3
- make rpmlint happy
Index: perl-PPI.spec
=
- Forwarded Message -
From: "He Rui"
To: "test list"
Sent: Wednesday, February 10, 2010 8:12:57 AM GMT +01:00 Amsterdam / Berlin /
Bern / Rome / Stockholm / Vienna
Subject: Fedora 13 Alpha TC Validation Test (Thu 02-11 to Wed 02-17)
Greetings,
As we have entered F13 test phase, now it
Hi,
On Wed, Feb 10, 2010 at 3:36 AM, Kevin Fenzi wrote:
> ===
> #fedora-meeting: FESCO (2010-02-09)
> ===
>
> Meeting started by nirik at 20:02:07 UTC. The full logs are available at
> http://meetbot.fedoraproject.org/fedora-meeting/
On Wed, Feb 10, 2010 at 09:20:35PM +0530, Parag N(पराग़) wrote:
> https://fedoraproject.org/wiki/UnderstandingDSOLinkChange, its
> written that "To fix, add -lrpmio to the gcc command for any binaries
> that use librpmio." So What's wrong if I modify CFLAGS in iok.spec and
> build log can show its
On Tue, Feb 9, 2010 at 8:14 AM, Marcela Maslanova wrote:
> I was thinking also about removing e.g. win32::api from requirements
> automatically. But I'm not sure if it's worth it. If it's only one
> module which we surely don't need, then it's maybe useless.
Yeah. Sounds like we're starting a "p
>Anyway please someone take care my fontmatrix package.
I was able to get this package to build by adding the following :
--- CMakeLists.txt.old 2010-02-10 11:39:24.0 -0500
+++ CMakeLists.txt 2010-02-10 11:18:55.0 -0500
@@ -120,6 +120,7 @@
SET(PYTHONQT_LIB PythonQt)
hi,
On Wed, Feb 10, 2010 at 10:16 PM, Roland Grunberg wrote:
>>Anyway please someone take care my fontmatrix package.
>
> I was able to get this package to build by adding the following :
>
> --- CMakeLists.txt.old 2010-02-10 11:39:24.0 -0500
> +++ CMakeLists.txt 2010-02-10 11:18:55
On 02/10/2010 05:59 PM, Till Maas wrote:
> Author: till
>
> Update of /cvs/pkgs/rpms/gpscorrelate/devel
> In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv9787
>
> Modified Files:
> gpscorrelate.spec
> Added Files:
> gpscorrelate-1.6.0-stdc++.patch
> Log Message:
> * Wed Feb 10 2010
On Wed, Feb 10, 2010 at 06:12:06PM +0100, Ralf Corsepius wrote:
> This patch is wrong.
>
> The actual bug this package suffers from is using "gcc" to link c++ code.
>
> C++ code MUST be linked with "g++", using "gcc" is not right. The fact
> your package might compile without complaint with -ls
The Fedora Unity Project is proud to announce the release of new ISO
Re-Spins of Fedora 12.
These Re-Spin ISOs are based on the officially released Fedora 12
installation media and include all updates released as of February 2nd,
2010.
The ISO images are available for i386, x86_64, architectu
Parag N(पराग़) (panem...@gmail.com) said:
> Forwarding this mail on behalf of Kevin Wright as his mail to devel
> list didn't appeared yet.
Seems reasonable. Do you have a patch?
Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
> Hi,
> On Wed, Feb 10, 2010 at 12:51 AM, Roland McGrath wrote:
> >> Replace
> >> make CFLAGS="%{optflags} -X11" %{?_smp_mflags}
> >> with
> >> make CFLAGS="%{optflags}" LDFLAGS="-lX11" %{?_smp_mflags}
> >
> > This is still not really ideal. For the long run, you should be fixing the
> > upst
On Wed, 2010-02-10 at 20:42 +0900, Mamoru Tasaka wrote:
> You should add "AC_CHECK_LIB(X11, XKeysymToString)" to configure.in,
> for example.
It's nicer to use pkg-config for libraries which provide .pc files,
isn't it? X11 does:
/usr/lib64/pkgconfig/x11.pc
--
Adam Williamson
Fedora QA Communit
On Wed, 2010-02-10 at 10:20 -0800, Roland McGrath wrote:
> > Hi,
> > On Wed, Feb 10, 2010 at 12:51 AM, Roland McGrath wrote:
> > >> Replace
> > >> make CFLAGS="%{optflags} -X11" %{?_smp_mflags}
> > >> with
> > >> make CFLAGS="%{optflags}" LDFLAGS="-lX11" %{?_smp_mflags}
> > >
> > > This is sti
> To answer the question, it works because the CFLAGS happen to be applied
> to the linker command as well as the LDFLAGS. As Roland says, though,
> adding it to CFLAGS is the wrongest fix, forcing it into LDFLAGS via the
> spec file is slightly less wrong, but having the upstream code add the
> fl
On Wed, 2010-02-10 at 10:41 -0800, Roland McGrath wrote:
> > To answer the question, it works because the CFLAGS happen to be applied
> > to the linker command as well as the LDFLAGS. As Roland says, though,
> > adding it to CFLAGS is the wrongest fix, forcing it into LDFLAGS via the
> > spec file
> Well, I'd say it's at least as important that the fix should be done in
> the appropriate place - the source code's configure step - and not
> wedged into the spec file. And then, of course, it should be sent
> upstream.
Absolutely!
Thanks,
Roland
--
devel mailing list
devel@lists.fedoraproje
Paul W. Frields wrote:
>
> The problem occurs in these packages:
>
> dnssec-conf-1.21-3.fc11
> dnssec-conf-1.21-7.fc12
>
Has this question been asked of anyone yet:
Why did this update bypass updates-testing?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org
On Wed, Feb 10, 2010 at 01:34:51PM -0600, Michael Cronenworth wrote:
> Paul W. Frields wrote:
> >
> > The problem occurs in these packages:
> >
> > dnssec-conf-1.21-3.fc11
> > dnssec-conf-1.21-7.fc12
> >
>
> Has this question been asked of anyone yet:
>
> Why did this update bypass updates-te
Hi, all. So the privilege escalation policy went to FESco, who suggested
some minor tweaks and a final run-by the mailing lists before it gets
approved.
I have now adjusted the draft -
https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_privilege_escalation_policy
- to reflect all feedback
On Wed, 2010-02-10 at 13:34 -0600, Michael Cronenworth wrote:
> Paul W. Frields wrote:
> >
> > The problem occurs in these packages:
> >
> > dnssec-conf-1.21-3.fc11
> > dnssec-conf-1.21-7.fc12
> >
>
> Has this question been asked of anyone yet:
>
> Why did this update bypass updates-testing?
On 02/09/2010 05:40 PM, Charley Wang wrote:
> Also, packages that have failed to build under these new changes can
> be found here :
> https://fedoraproject.org/wiki/DSOLinkBugs
All of mine are fixed:
amanith:
Fixed in amanith-0.3-14.fc13
esperanza:
Fixed in esperanza-0.4.0-6.fc13
gbdfed:
Fixe
On 10-02-10 15:48:39, Adam Williamson wrote:
> Hi, all. So the privilege escalation policy went to FESco, who
> suggested some minor tweaks and a final run-by the mailing lists
> before it gets approved.
>
> I have now adjusted the draft -
> https://fedoraproject.org/wiki/User:Adamwill/
> Draft_F
Ben Williams wrote:
> The Fedora Unity Project is proud to announce the release of new ISO
> Re-Spins of Fedora 12.
>
> These Re-Spin ISOs are based on the officially released Fedora 12
> installation media and include all updates released as of February 2nd,
> 2010.
Sadly, this means this respi
o http://talk.fedoraproject.org/
--extension: 2009
o irc.freenode.net
--#fedora-nfr
Want to know more about No Frozen Rawhide or help get the word out about
how it will all work?
Join Jesse Keating and me this Friday on Fedora Talk to wrap up the
documentation and update wiki pages relate
I forgot to send this out yesterday, but the Fedora 13 Alpha freeze is
this coming Tuesday.
https://fedoraproject.org/wiki/Alpha_Freeze_Policy
This time around things are going to be different and interesting.
We're in the middle of deploying No Frozen Rawhide¹ which will change
how freeze breaks
On 10 February 2010 23:35, Kevin Kofler wrote:
> Ben Williams wrote:
>> The Fedora Unity Project is proud to announce the release of new ISO
>> Re-Spins of Fedora 12.
>>
>> These Re-Spin ISOs are based on the officially released Fedora 12
>> installation media and include all updates released as o
Mat Booth wrote:
> To be fair, it seems like you are updating KDE constantly. If the spin
> contains the packages available at the time it was spun, I'm not sure
> what more you can ask for.
The packages available at the time it was released. ;-) I.e. not preparing
the spin 3 days before a KDE up
On Wed, 2010-02-10 at 17:19 -0500, Tony Nelson wrote:
> "Directly read or write directly to or from system memory" has an extra
> (or out of order) "directly".
sigh. thanks.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happ
On 11 February 2010 00:49, Kevin Kofler wrote:
> Mat Booth wrote:
>> To be fair, it seems like you are updating KDE constantly. If the spin
>> contains the packages available at the time it was spun, I'm not sure
>> what more you can ask for.
>
> The packages available at the time it was released.
A friendly reminder that yesterday, February 9, 2010, we reached Feature
Freeze for Fedora 13.
A summary of the Fedora 13 milestones and exception process is here:
https://fedoraproject.org/wiki/Important_Release_Milestones
As previously noted, at Feature Freeze it is expected that all features
On 02/10/2010 08:00 PM, Mat Booth wrote:
>
> Meh.
>
> If you insist on putting out major updates for released Fedoras it
> will never a good time to do a re-spin. Oh well.
>
I find it simpler to build my own spin anyway using mock/pungi - its
very simple - simpler in my view than dealing wi
On Thu, 2010-02-11 at 01:00 +, Mat Booth wrote:
> On 11 February 2010 00:49, Kevin Kofler wrote:
> > Mat Booth wrote:
> >> To be fair, it seems like you are updating KDE constantly. If the spin
> >> contains the packages available at the time it was spun, I'm not sure
> >> what more you can as
Mat Booth wrote:
> If you insist on putting out major updates for released Fedoras it
> will never a good time to do a re-spin. Oh well.
The updates being pushed so far are bugfix releases (4.3.3, 4.3.4, 4.3.5).
We're preparing 4.4.0 now, but as this isn't even in testing at the moment,
I'm not
Kevin Kofler wrote:
> Jakub Jelinek wrote:
> > You are probably looking for bug compatibility, and that isn't something
> > GCC guarantees, definitely not between major versions.
>
> And that's one half of what I'm complaining about.
That sounds to me like you want the GCC team to keep their bugs
Björn Persson wrote:
> And what happens the day you need to compile that code with another
> compiler?
What compiler? A proprietary compiler? The BSD-style-licensed LLVM/clang
which any proprietary vendor can embrace&extend into a non-Free version?
It's not in the interest of the GNU project (wh
On Thu, Feb 11, 2010 at 03:15:56AM +0100, Kevin Kofler wrote:
>Mat Booth wrote:
>> If you insist on putting out major updates for released Fedoras it
>> will never a good time to do a re-spin. Oh well.
>
>The updates being pushed so far are bugfix releases (4.3.3, 4.3.4, 4.3.5).
>We're preparing 4
On Wed 10 February 2010 7:00:42 pm Kevin Kofler wrote:
> It's not in the interest of the GNU project (which GCC is supposed to be a
> part of) to make it easy to compile code with other compilers!
If that is the case it is extremely short sighted of them.
--
Ryan Rix
== http://hackersramblings.
Ryan Rix wrote:
> On Wed 10 February 2010 7:00:42 pm Kevin Kofler wrote:
>> It's not in the interest of the GNU project (which GCC is supposed to be
>> a part of) to make it easy to compile code with other compilers!
>
> If that is the case it is extremely short sighted of them.
That was a state
59 matches
Mail list logo
