Hello all,
I'm trying to debug an issue with 32bit application running on top of
x86_64 F12 installation. (Using multi-lib i686 RPMs)
However, debuginfo install doesn't seem to be able to resolve i686
debuginfo.
$ debuginfo-install alsa-lib.i686 alsa-plugins-pulseaudio.i686
dbus-libs.i686
On Sun, 17 Jan 2010 12:36:03 +0100, Nicolas wrote:
Le samedi 16 janvier 2010 à 15:09 -0500, Tom Lane a écrit :
Users have to provide information
about what they were doing, copies of input files, etc etc just the
same as in a manually-initiated bug report.
IMHO the big plus of abrt is
Le dimanche 17 janvier 2010 à 12:53 +0100, Michael Schwendt a écrit :
On Sun, 17 Jan 2010 12:36:03 +0100, Nicolas wrote:
Le samedi 16 janvier 2010 à 15:09 -0500, Tom Lane a écrit :
Users have to provide information
about what they were doing, copies of input files, etc etc just
the
On Sun, Jan 17, 2010 at 12:36:03PM +0100, Nicolas Mailhot wrote:
Le samedi 16 janvier 2010 à 15:09 -0500, Tom Lane a écrit :
Users have to provide information
about what they were doing, copies of input files, etc etc just the
same as in a manually-initiated bug report.
IMHO the big
On Sun, 17 Jan 2010 13:09:56 +0100, Nicolas wrote:
A downside is that ABRT is triggered for all sorts of weird
memory/heap
corruption that isn't reproducible. Stability problems with RAM chips
are widespread.
A bugzilla stock response that points at memtester and memtest86+
will
Can we draw any parallels from work in the commercial world? (I was
going to use the word 'professional' but don't want to disparage open
source work... it's just a different ecosystem)
So at work we have to produce a software product.
We test the product to the best of our ability / to test
Gilboa Davara wrote:
I'm trying to debug an issue with 32bit application running on top of
x86_64 F12 installation. (Using multi-lib i686 RPMs)
However, debuginfo install doesn't seem to be able to resolve i686
debuginfo.
That's right. There are only 64-bit debuginfo packages in the 64-bit
On Sun, 2010-01-17 at 14:18 +0100, Björn Persson wrote:
Gilboa Davara wrote:
I'm trying to debug an issue with 32bit application running on top of
x86_64 F12 installation. (Using multi-lib i686 RPMs)
However, debuginfo install doesn't seem to be able to resolve i686
debuginfo.
That's
Hi all,
is there any good way how to handle the situation described at
https://bugzilla.redhat.com/show_bug.cgi?id=528524
?
I.e. you have a single library (single soname) which can be compiled
with or without GUI support (with different ABI) -- and we'd like to
have both of them, of course
Am Sonntag, den 17.01.2010, 12:36 +0100 schrieb Nicolas Mailhot:
IMHO the big plus of abrt is it triggers even when the user is not
giving his full attention to the app and not checking what it does
exactly when it crashes (typical example is multitasking and doing stuff
in 3-4 apps when one
On 01/16/2010 04:01 PM, Christoph Wickert wrote:
I know that APRT is still very young technology, but after 2 months it's
time for a interim conclusion. For me the conclusions are:
Pro:
* abrt is a help for developers: I received one positive feedback
from a developer: The
Camilo Mesias cam...@mesias.co.uk writes:
What if every component had a placeholder bug for undiagnosed ABRT
info. Keeping all of them together would help to gauge which are
significant and which are one-in-a-million cosmic rays flipping RAM
bits etc.
Well, it's supposed to do that already I
On Sun, 2010-01-17 at 01:07 +0100, Michael Schwendt wrote:
On Sat, 16 Jan 2010 11:46:27 -0700, Kevin wrote:
Greetings.
I'd like to find some folks interested in co-maintaining or just fully
maintaining gpsdrive. It's a nifty gps app that lets you download maps
and follow progress
Am Sonntag, den 17.01.2010, 15:53 +0100 schrieb Jiri Moskovcak:
On 01/16/2010 04:01 PM, Christoph Wickert wrote:
I know that APRT is still very young technology, but after 2 months it's
time for a interim conclusion. For me the conclusions are:
Pro:
* abrt is a help for
On 01/17/2010 11:57 AM, Christoph Wickert wrote:
Am Sonntag, den 17.01.2010, 15:53 +0100 schrieb Jiri Moskovcak:
On 01/16/2010 04:01 PM, Christoph Wickert wrote:
I'm open to any ideas how to improve this.
Someone else asked this earlier - but why do users need the debug-info
packages -
On 10-01-17 12:32:17, Mail Lists wrote:
On 01/17/2010 11:57 AM, Christoph Wickert wrote:
Am Sonntag, den 17.01.2010, 15:53 +0100 schrieb Jiri Moskovcak:
On 01/16/2010 04:01 PM, Christoph Wickert wrote:
I'm open to any ideas how to improve this.
Someone else asked this earlier -
On 01/17/2010 01:20 PM, Tony Nelson wrote:
Apparently Linux has no mini-dump facility, so the upload of the whole
core dump file would be onerous as well.
I'd still bet a core file is smaller than the 60 - 100 debug packages
(per crashing app) I need before I can send a trace back.
--
I'm going to build gnome-desktop 2.29.5 in rawhide, which bumps the
soname of libgnome-desktop-2.so. Affected packages are:
avant-window-navigator
awn-extras-applets
cheese
compiz-gnome
control-center
deskbar-applet
eel2
eog
evolution
evolution-bogofilter
evolution-conduits
galeon
gnome-applets
cores typically compress fantastically well, too.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Sat, Jan 16, 2010 at 10:39:50AM -0700, Kevin Fenzi wrote:
On Sat, 16 Jan 2010 10:39:54 +0100
Till Maas opensou...@till.name wrote:
Indeed. I don't see much activity from them.
Have you tried sending them an email?
If not, I can.
No, please go ahead.
I took the liberty
On Fri, Jan 15, 2010 at 02:06:09PM -0600, Matt Domsch wrote:
On Fri, Jan 15, 2010 at 09:01:20PM +0100, Till Maas wrote:
On Fri, Jan 15, 2010 at 01:17:28PM -0600, Matt Domsch wrote:
On Fri, Jan 15, 2010 at 12:00:50AM -0600, Matt Domsch wrote:
The following 30 packages, with respective
Tony Nelson tonynel...@georgeanelson.com writes:
On 10-01-17 12:32:17, Mail Lists wrote:
Someone else asked this earlier - but why do users need the
debug-info packages - only the debugger looking at the tracebacks
needs this. So seems installing the debug files on every desktop/
server that
On Fri, Jan 15, 2010 at 1:58 PM, Till Maas opensou...@till.name wrote:
perl-SVN-Mirror iburrell (fixed by Till Maas; spot says kill it)
perl-SVN-Simple iburrell
There is a minor error: I fixed the -Simple package with a patch
submitted in the upstream bugtracker iirc 7 days ago. But I also
Am Samstag, den 16.01.2010, 22:11 -0500 schrieb Matthias Clasen:
I am going to build libxklavier 5.0 in rawhide, which bumps the soname,
and also contains a small api change. The following packages will have
to be rebuilt:
gnome-settings-daemon
gdm
control-center
kdebase-workspace
I meant to add that the reason this came up was I was trying to work out
where to put yum-langpacks in comps: yum-presto being one of the reference
packages I searched for.
So where can/should yum-langpacks live?
Jens
--
devel mailing list
devel@lists.fedoraproject.org
On Sat, 16 Jan 2010, Matt Domsch wrote:
We could easily create a new class of bugzilla ticket, say
MAINTAINED. An automated process would generate such tickets,
blocking F13MAINTAINED. The ticket would ask the maintainer to close
the ticket to remain the owner of the package. Tickets
On 01/16/2010 03:50 PM, Matt Domsch wrote:
On Sat, Jan 16, 2010 at 10:13:32AM +0100, Michael Schwendt wrote:
With nobody handling the incoming bugzilla tickets. With some bug
reports having been killed in an automated way at dist EOL. And
worse if it turns out that packages which do build are
On Sun, Jan 17, 2010 at 10:46:18PM -0500, Seth Vidal wrote:
On Sat, 16 Jan 2010, Matt Domsch wrote:
We could easily create a new class of bugzilla ticket, say
MAINTAINED. An automated process would generate such tickets,
blocking F13MAINTAINED. The ticket would ask the maintainer to
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=548234
Enrico Scholz enrico.sch...@informatik.tu-chemnitz.de changed:
What|Removed |Added
29 matches
Mail list logo
