A reminder of tomorrow's biweekly i18n meeting:
https://fedoraproject.org/wiki/I18N/Meetings/2010-01-19
Please follow up if you have a topic for discussion.
Jens
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
hey,
I just got myself an extra laptop that I can use to test stuff.
this is the smolt profile:
http://www.smolts.org/client/show/pub_5a1b4c49-e64d-45d8-91d7-9806815221b5
please feel free to ask me to test stuff for you, I'm not using this
machine for any work.
regards,
Ankur
[ X posted to t
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 maintain
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 bui
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. Ticket
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
https://admin.fedoraprojec
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
On Fri, Jan 15, 2010 at 1:58 PM, Till Maas 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 noticed
> that
Tony Nelson 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 has a problem is mu
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 respe
On Sat, Jan 16, 2010 at 10:39:50AM -0700, Kevin Fenzi wrote:
> On Sat, 16 Jan 2010 10:39:54 +0100
> Till Maas 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 right
cores typically compress fantastically well, too.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
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
gn
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.
--
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 th
> 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 has a
> problem is much less efficient than just on the dev computer who needs
> the info
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
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
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
Camilo Mesias 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 think: if you ge
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 backt
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 o
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 --
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.
>
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
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 plans
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 "memtes
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 th
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 jus
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
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 it triggers even when the user is not
giving his full a
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 pulseau
32 matches
Mail list logo
