On Fri, 2012-06-22 at 17:36 +0200, Roman Rakus wrote:
> On 05/08/2012 08:15 AM, Alexander Larsson wrote:
> > See the feature page for detail on the space use. On my F17 desktop
> > install with and 8 gigabytes /usr it would add 43 megabytes of data.
> >
> What about to not install it by default but
On 05/08/2012 08:15 AM, Alexander Larsson wrote:
On Mon, 2012-05-07 at 18:55 +0100, Peter Robinson wrote:
On Mon, May 7, 2012 at 2:07 PM, Alexander Larsson wrote:
I just wrote a new Feature proposal for shipping minimal debug info by
default:
https://fedoraproject.org/wiki/Features/MiniDebugIn
On 5/14/12 8:19 PM, Adam Williamson wrote:
Well, the desktop team has said for a while that the thing they'd really
want to add to the desktop image if they had more room is LibreOffice,
but that requires substantially more than a few dozen MB. Basically,
they consider saving a small amount of r
On Mon, 2012-05-14 at 14:50 -0400, Adam Jackson wrote:
> On Mon, 2012-05-14 at 13:48 -0400, Bill Nottingham wrote:
>
> > I'm still a bit baffled that a 3.5 MB increase on a 700MB live image
> > is considered a complete showstopper. That's one git package, for example;
> > I would hope that creativ
> I'm still a bit baffled that a 3.5 MB increase on a 700MB live image
> is considered a complete showstopper. ...
Another place to check is the raw filesystem size before adding payload
and before compressing. The unused space squashes "nicely" because it
was created as zero on purpose, but sti
On Mon, 2012-05-14 at 13:48 -0400, Bill Nottingham wrote:
> I'm still a bit baffled that a 3.5 MB increase on a 700MB live image
> is considered a complete showstopper. That's one git package, for example;
> I would hope that creative dependency trimming can find that space.
> (Or reorganization o
Jaroslav Reznik (jrez...@redhat.com) said:
> - Original Message -
> >
> > This being said I am +1 for 1 GB, but please note that I only speak
>
> Another thing - we realized that targeting 1 GB is non sense when we
> have 700 MB, so we moved to 1.5 GB. There was a little difference and
>
On 05/14/2012 01:40 AM, Alexander Larsson wrote:
> I understand that you want to ship isolated images for each of the
> desktops in this combination image, as that is what is tested, etc.
> However, there is gonna be a lot of duplicated bits in those images.
> Can't we use some form of image where
- Original Message -
>
> This being said I am +1 for 1 GB, but please note that I only speak
Another thing - we realized that targeting 1 GB is non sense when we
have 700 MB, so we moved to 1.5 GB. There was a little difference and
no way to put everything on it. With 1 GB target and no 7
- Original Message -
> Am Mittwoch, den 09.05.2012, 11:57 -0400 schrieb Adam Jackson:
> > On Wed, 2012-05-09 at 11:45 -0400, Matthias Clasen wrote:
> > > On Wed, 2012-05-09 at 13:35 +0200, Kevin Kofler wrote:
> > > > Alexander Larsson wrote:
> > > > > The feature page lists some of the back
On Fri, 2012-05-11 at 16:42 +0200, Christoph Wickert wrote:
> Am Mittwoch, den 09.05.2012, 11:57 -0400 schrieb Adam Jackson:
> > On Wed, 2012-05-09 at 11:45 -0400, Matthias Clasen wrote:
> > > On Wed, 2012-05-09 at 13:35 +0200, Kevin Kofler wrote:
> > > > Alexander Larsson wrote:
> > > > > The feat
Am Mittwoch, den 09.05.2012, 11:57 -0400 schrieb Adam Jackson:
> On Wed, 2012-05-09 at 11:45 -0400, Matthias Clasen wrote:
> > On Wed, 2012-05-09 at 13:35 +0200, Kevin Kofler wrote:
> > > Alexander Larsson wrote:
> > > > The feature page lists some of the background and statistics. It also
> > > >
Gerd Hoffmann wrote:
> Sounds more useful to me to just have a single live image which has
> multiple desktop environments included, so you don't have the common
> bits multiple times at the dvd ...
That sounds nice in theory, but is just not practical:
* The per-desktop live images are what we de
On 05/11/12 00:36, Kevin Kofler wrote:
> Adam Jackson wrote:
>> Therefore I have difficulty evaluating just how much impact this would
>> be. Do you have a link to the recipe for building such an image? I
>> suspect the incremental cost of each additional desktop environment
>> would be successiv
Adam Jackson wrote:
> Therefore I have difficulty evaluating just how much impact this would
> be. Do you have a link to the recipe for building such an image? I
> suspect the incremental cost of each additional desktop environment
> would be successively lower, but without data...
The DVD is co
On 05/10/2012 10:56 AM, Adam Jackson wrote:
> On Thu, 2012-05-10 at 12:08 +0200, Kevin Kofler wrote:
>> drago01 wrote:
>>> Not really, you are restricting yourself by the artificial CD size limit.
>>> You don't have to use the full size of whatever bigger medium you
>>> choose (DVD, 1 or 2GB stick)
On Thu, 2012-05-10 at 12:08 +0200, Kevin Kofler wrote:
> drago01 wrote:
> > Not really, you are restricting yourself by the artificial CD size limit.
> > You don't have to use the full size of whatever bigger medium you
> > choose (DVD, 1 or 2GB stick) but you are currently providing a poorer
> > u
drago01 wrote:
> Not really, you are restricting yourself by the artificial CD size limit.
> You don't have to use the full size of whatever bigger medium you
> choose (DVD, 1 or 2GB stick) but you are currently providing a poorer
> user experience because you insist on a medium from the last centu
On Thu, 2012-05-10 at 10:02 +0200, drago01 wrote:
> On Thu, May 10, 2012 at 9:20 AM, Kevin Kofler wrote:
> > I'd rather we just don't add yet another size overhead to every package. Our
> > packages keep growing and growing even without that. A few KiB here, a few
> > KiB there, in many packages,
On Thu, May 10, 2012 at 9:20 AM, Kevin Kofler wrote:
> Alexander Larsson wrote:
>> Its not particularly hard to strip the debuginfo when constructing the
>> live image, although then installation from it will not really work as
>> the rpms checksums will be wrong.
>
> Indeed, that doesn't sound li
Alexander Larsson wrote:
> Its not particularly hard to strip the debuginfo when constructing the
> live image, although then installation from it will not really work as
> the rpms checksums will be wrong.
Indeed, that doesn't sound like a sane solution to me.
I'd rather we just don't add yet an
Matthias Clasen wrote:
> We could easily drop some of less-than-half-complete translations to
> make room for a bit of minidebuginfo. Last time I looked, translations,
> fonts, etc made up upwards of 25% of the livecd. Or we could just drop
> the obsolescent cdrom size limitation...
There are (alm
On Thu, 2012-05-10 at 07:19 +0200, Matej Cepl wrote:
> On 9.5.2012 20:56, Chris Adams wrote:
> > Also: "some 7% of working USB sticks that are 512MB or less" - when have
> > any of the standard Live images _ever_ fit on a 512M media?
>
> It of course depends on your definition of “standard”, but T
On 9.5.2012 20:56, Chris Adams wrote:
Also: "some 7% of working USB sticks that are 512MB or less" - when have
any of the standard Live images _ever_ fit on a 512M media?
It of course depends on your definition of “standard”, but Tiny Core
Linux is less than 12MB ...
http://distro.ibiblio.org
On Wed, 2012-05-09 at 13:35 +0200, Kevin Kofler wrote:
> Alexander Larsson wrote:
> > The feature page lists some of the background and statistics. It also
> > lists some options in how to implement this, which all have various
> > different pros and cons. I'd like to hear what peoples opinions on
- Original Message -
> On Wed, 2012-05-09 at 16:23 -0400, Jon VanAlten wrote:
>
> > Isn't there some hardware profile report thingo? Would it be
> > possible to use that data to quantify the potential effect of
> > growing live media beyond CD size limit? (I would support
> > breaking th
On Wed, 2012-05-09 at 16:23 -0400, Jon VanAlten wrote:
> Isn't there some hardware profile report thingo? Would it be
> possible to use that data to quantify the potential effect of
> growing live media beyond CD size limit? (I would support
> breaking the limit, but would prefer the decision be
- Original Message -
> From: "Adam Jackson"
> To: "Development discussions related to Fedora"
>
> Sent: Wednesday, May 9, 2012 3:02:33 PM
> Subject: Re: Proposed F18 feature: MiniDebugInfo
>
> On Wed, 2012-05-09 at 12:00 -0700, John Reise
On Wed, May 09, 2012 at 11:20:43AM -0700, John Reiser wrote:
> > 1G fits on both the smallest MiniDVD format and most extant USB sticks.
> > Let's do it already.
>
> If so, then please acknowledge explicitly that Fedora would be discarding
> some 4% of running, otherwise-capable machines (es
On Wed, 2012-05-09 at 12:00 -0700, John Reiser wrote:
> On 05/09/2012 11:46 AM, Adam Jackson wrote:
> > On Wed, 2012-05-09 at 11:20 -0700, John Reiser wrote:
>
> >> If so, then please acknowledge explicitly that Fedora would be discarding
> >> some 4% of running, otherwise-capable machines (especi
On 05/09/2012 11:46 AM, Adam Jackson wrote:
> On Wed, 2012-05-09 at 11:20 -0700, John Reiser wrote:
>> If so, then please acknowledge explicitly that Fedora would be discarding
>> some 4% of running, otherwise-capable machines (especially old laptops)
>> that can read only CD and not DVD, some 7%
Once upon a time, John Reiser said:
> If so, then please acknowledge explicitly that Fedora would be discarding
> some 4% of running, otherwise-capable machines (especially old laptops)
> that can read only CD and not DVD, some 7% of working USB sticks that are
> 512MB or less, and some 5% of work
On Mon, May 07, 2012 at 17:36:07 +0200,
Jan Kratochvil wrote:
* There are privacy issues with sending the users coredumps to some
server on the internet
As whole Fedora is built by the Fedora Project and Retrace Server is also run
by Fedora Project this is non-issue. There can be alread
On Wed, 2012-05-09 at 11:20 -0700, John Reiser wrote:
> On 05/09/2012 08:57 AM, Adam Jackson wrote:
>
> > I know I've said this before, but: we should break the CD size barrier
> > precisely so people can't burn things to CDs. If you must burn to
> > optical media, do yourself a favor and burn a
On 05/09/2012 08:57 AM, Adam Jackson wrote:
> I know I've said this before, but: we should break the CD size barrier
> precisely so people can't burn things to CDs. If you must burn to
> optical media, do yourself a favor and burn a DVD, the reduced seek time
> is entirely worth it.
>
> 1G fits
On Wed, 2012-05-09 at 11:45 -0400, Matthias Clasen wrote:
> On Wed, 2012-05-09 at 13:35 +0200, Kevin Kofler wrote:
> > Alexander Larsson wrote:
> > > The feature page lists some of the background and statistics. It also
> > > lists some options in how to implement this, which all have various
> > >
On Wed, 2012-05-09 at 13:35 +0200, Kevin Kofler wrote:
> Alexander Larsson wrote:
> > The feature page lists some of the background and statistics. It also
> > lists some options in how to implement this, which all have various
> > different pros and cons. I'd like to hear what peoples opinions on
notting wrote:
> [...]
> 2) "It will also make it easier to do things like system wide profiling,
> userspace dynamic probes and causual debugging."
>
> However, the Scope: is only gdb and rpm. Wouldn't said tools also need
> changes? Would this be done in libdwarf, or similar?
> [...]
Profiling
Frank Ch. Eigler wrote:
>
> kevin.kofler wrote:
>
>> [...] There is no room left on the KDE live image for installing
>> any sort of debugging information by default. [...]
>
> What are the live-image spins' plans as to management of future
> growth? At what point, if ever, do they intend to
kevin.kofler wrote:
> [...] There is no room left on the KDE live image for installing
> any sort of debugging information by default. [...]
What are the live-image spins' plans as to management of future
growth? At what point, if ever, do they intend to abandon the CD-ROM
format limits?
- FC
On 05/09/2012 01:51 PM, Jakub Jelinek wrote:
On Wed, May 09, 2012 at 01:44:03PM +0200, Alexander Larsson wrote:
I'm not proposing that we drop the existing backtraces with full debug
info, but (appart from the other places where backtraces are also
useful) I'd like it if ABRT could somehow catch
On Wed, May 09, 2012 at 01:44:03PM +0200, Alexander Larsson wrote:
> I'm not proposing that we drop the existing backtraces with full debug
> info, but (appart from the other places where backtraces are also
> useful) I'd like it if ABRT could somehow catch all the cases where
> people abort a bugr
On Wed, 2012-05-09 at 13:32 +0200, Jiri Moskovcak wrote:
> Appart from that I see two questions here:
> 1. Whether to add the minidebuginfo in Fedora
> 2. Whether to use this stripped backtrace when reporting a bug.
>
>
> For 1: The decision to use it or not should be based on some real-life
>
On Wed, 09 May 2012 13:33:29 +0200, Alexander Larsson wrote:
> That would means 43Mb larger
I guess you mean 43MB and not 5MB.
Jan
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, 09 May 2012 13:32:08 +0200, Jiri Moskovcak wrote:
> As for the bandwidth limitations when using ABRT - I hope Lennart's
> core stripping library might help here.
But this degrades backtrace quality again as I have shown in:
https://fedorahosted.org/pipermail/crash-catcher/2010-Sep
Alexander Larsson wrote:
> The feature page lists some of the background and statistics. It also
> lists some options in how to implement this, which all have various
> different pros and cons. I'd like to hear what peoples opinions on these
> are.
There is no room left on the KDE live image for i
On Wed, 2012-05-09 at 10:36 +0200, Miroslav Lichvar wrote:
> On Mon, May 07, 2012 at 03:07:20PM +0200, Alexander Larsson wrote:
> > I just wrote a new Feature proposal for shipping minimal debug info by
> > default:
> > https://fedoraproject.org/wiki/Features/MiniDebugInfo
> >
> > The feature page
On 05/07/2012 03:07 PM, Alexander Larsson wrote:
I just wrote a new Feature proposal for shipping minimal debug info by
default:
https://fedoraproject.org/wiki/Features/MiniDebugInfo
The feature page lists some of the background and statistics. It also
lists some options in how to implement this
On Wed, 09 May 2012 10:35:16 +0200, Gerd Hoffmann wrote:
> Server-based trace generation requires uploading a potentially large
> core file (which probably can be reduced using mozilla-like minidumps).
"mozilla-like minidumps" would bring us unusable backtraces due to other
reasons such as GDB Pre
On Mon, May 07, 2012 at 03:07:20PM +0200, Alexander Larsson wrote:
> I just wrote a new Feature proposal for shipping minimal debug info by
> default:
> https://fedoraproject.org/wiki/Features/MiniDebugInfo
>
> The feature page lists some of the background and statistics. It also
> lists some opti
On 05/09/12 08:23, Jan Kratochvil wrote:
> On Tue, 08 May 2012 15:03:28 +0200, Alexander Larsson wrote:
>> Take this post for instance:
>>
>> https://plus.google.com/110933625728671692704/posts/iFXggK7Q8KJ
> +
> On Tue, 08 May 2012 15:10:28 +0200, Gerd Hoffmann wrote:
>> Wrong. From /me you don't
- Original Message -
> On Wed, 09 May 2012 09:27:57 +0200, Alexander Larsson wrote:
> > So, having at least some level of quality local backtraces will
> > still be
> > good even if ABRT becomes better.
>
> Some new option is always good.
>
> Questionable is what should be the default. I
On Wed, 09 May 2012 09:27:57 +0200, Alexander Larsson wrote:
> So, having at least some level of quality local backtraces will still be
> good even if ABRT becomes better.
Some new option is always good.
Questionable is what should be the default. IMO ABRT Retrace Server should be
the default on
On Wed, 2012-05-09 at 08:23 +0200, Jan Kratochvil wrote:
> Because ABRT has not yet met its expectations we should
> provide at
> least this temporary solution before ABRT gets fixed.
>
> So you agree?
I agree that ABRT should be better, but I don't agree that having local
minimal
On Tue, 08 May 2012 15:03:28 +0200, Alexander Larsson wrote:
> Take this post for instance:
>
> https://plus.google.com/110933625728671692704/posts/iFXggK7Q8KJ
+
On Tue, 08 May 2012 15:10:28 +0200, Gerd Hoffmann wrote:
> Wrong. From /me you don't get abrt reports at all, because abrt simply
> is
On Mon, 2012-05-07 at 15:07 +0200, Alexander Larsson wrote:
> I just wrote a new Feature proposal for shipping minimal debug info by
> default:
> https://fedoraproject.org/wiki/Features/MiniDebugInfo
>
> The feature page lists some of the background and statistics. It also
> lists some options in
On 05/08/12 13:08, Miloslav Trmač wrote:
> On Mon, May 7, 2012 at 11:36 PM, Lennart Poettering
> wrote:
>> On Mon, 07.05.12 23:02, Jan Kratochvil (jan.kratoch...@redhat.com) wrote:
>>> On Mon, 07 May 2012 22:16:02 +0200, Lennart Poettering wrote:
>> I mean, just think of this: you have a pool of w
On Tue, 2012-05-08 at 13:08 +0200, Miloslav Trmač wrote:
> My take:
>
> 1) Developers of the software in question: Bluntly, the ~1-100 users
> in the whole world shouldn't matter in our discussion - if they are
> even running the RPM, they can and probably will install complete
> debuginfo, enable
On Mon, May 7, 2012 at 11:36 PM, Lennart Poettering
wrote:
> On Mon, 07.05.12 23:02, Jan Kratochvil (jan.kratoch...@redhat.com) wrote:
>> On Mon, 07 May 2012 22:16:02 +0200, Lennart Poettering wrote:
> I mean, just think of this: you have a pool of workstations to
> administer. It's all the same m
On Tue, 08 May 2012 08:34:57 +0200, Alexander Larsson wrote:
> Its true that that is all the information you need from the
> process/core. But you need to have the rest of the information availible
> *somewhere*, such as on a global retrace server or just having it
> locally in the minidebuginfo. T
On Tue, May 08, 2012 at 08:34:57AM +0200, Alexander Larsson wrote:
> Its true that that is all the information you need from the
> process/core. But you need to have the rest of the information availible
> *somewhere*, such as on a global retrace server or just having it
Yes.
> locally in the min
On Tue, 2012-05-08 at 08:30 +0200, Jakub Jelinek wrote:
> On Tue, May 08, 2012 at 08:09:04AM +0200, Alexander Larsson wrote:
> > This is your opinion. I rarely need the full backtrace in a bug report,
> > because it you can get one its generally something thats easily
> > reproduced and I can just
On Tue, May 08, 2012 at 08:09:04AM +0200, Alexander Larsson wrote:
> This is your opinion. I rarely need the full backtrace in a bug report,
> because it you can get one its generally something thats easily
> reproduced and I can just run it in gdb myself. When you need it is when
> something weird
On Mon, 2012-05-07 at 22:44 +0200, Jan Kratochvil wrote:
> On Mon, 07 May 2012 22:24:15 +0200, Bill Nottingham wrote:
> > 4) I disagree with the contention that this should all be done via the
> > retrace server. For the retrace server to work, you have to have
> > all of the following:
> >
> > -
On Mon, 2012-05-07 at 16:24 -0400, Bill Nottingham wrote:
> Alexander Larsson (al...@redhat.com) said:
> > I just wrote a new Feature proposal for shipping minimal debug info by
> > default:
> > https://fedoraproject.org/wiki/Features/MiniDebugInfo
> >
> > The feature page lists some of the backg
On Mon, 2012-05-07 at 18:55 +0100, Peter Robinson wrote:
> On Mon, May 7, 2012 at 2:07 PM, Alexander Larsson wrote:
> > I just wrote a new Feature proposal for shipping minimal debug info by
> > default:
> > https://fedoraproject.org/wiki/Features/MiniDebugInfo
> >
> > The feature page lists some
On Mon, 2012-05-07 at 23:54 +0200, Jan Kratochvil wrote:
> On Mon, 07 May 2012 23:36:04 +0200, Lennart Poettering wrote:
> > But anyway, I don't think it's worth continuing this discussion, this is
> > a bit like a dialogue between two wet towels...
>
> I also do not think we can ever find an agr
On Mon, 07 May 2012 23:36:04 +0200, Lennart Poettering wrote:
> I mean, just think of this: you have a pool of workstations to
> administer. It's all the same machines, with the same prepared OS
> image.
Then I probably use readonly /usr/lib/debug over NFS.
> Now, with your logic this would eith
On Mon, 07.05.12 23:02, Jan Kratochvil (jan.kratoch...@redhat.com) wrote:
> On Mon, 07 May 2012 22:16:02 +0200, Lennart Poettering wrote:
> > Everybody who builds OSes or appliances, and who needs to supervise a
> > large number of systems, and hosts, wants stacktraces that just work,
> > and don'
On Mon, 07 May 2012 22:16:02 +0200, Lennart Poettering wrote:
> Everybody who builds OSes or appliances, and who needs to supervise a
> large number of systems, and hosts, wants stacktraces that just work,
> and don't require network access or any complex infrastructure.
Yes, they work for me.
On Mon, 07 May 2012 22:24:15 +0200, Bill Nottingham wrote:
> 4) I disagree with the contention that this should all be done via the
> retrace server. For the retrace server to work, you have to have
> all of the following:
>
> - all relevant binaries and DSOs built in Fedora
When we are consideri
Alexander Larsson (al...@redhat.com) said:
> I just wrote a new Feature proposal for shipping minimal debug info by
> default:
> https://fedoraproject.org/wiki/Features/MiniDebugInfo
>
> The feature page lists some of the background and statistics. It also
> lists some options in how to implement
On Mon, 07.05.12 17:50, Jan Kratochvil (jan.kratoch...@redhat.com) wrote:
> On Mon, 07 May 2012 17:40:18 +0200, Lennart Poettering wrote:
> > on the individual machine,
>
> There is no backing reason for this requirement. It does not matter
> where.
That's my requirement, and actually of many o
On Mon, May 7, 2012 at 2:07 PM, Alexander Larsson wrote:
> I just wrote a new Feature proposal for shipping minimal debug info by
> default:
> https://fedoraproject.org/wiki/Features/MiniDebugInfo
>
> The feature page lists some of the background and statistics. It also
> lists some options in how
On Mon, 07 May 2012 18:10:17 +0200, Colin Walters wrote:
> My experience is otherwise; just look at how the kernel works in
> practice. People often post stack traces to the list, and it's
> certainly not uncommon for problems to be fixed just based on this data.
Linux kernel is not generalizable
On Mon, 2012-05-07 at 17:50 +0200, Jan Kratochvil wrote:
>
> * Opinions to this item significantly differ but minidebuginfo-only
>backtraces are in many (IMO most) cases not usable for problem analysis.
My experience is otherwise; just look at how the kernel works in
practice. People often
On Mon, 07 May 2012 17:40:18 +0200, Lennart Poettering wrote:
> on the individual machine,
There is no backing reason for this requirement. It does not matter where.
> without having to keep coredumps,
Core dump currently always have to be shortly stored on the disk anyway, even
for using mini
On Mon, 07.05.12 16:25, Jan Kratochvil (jan.kratoch...@redhat.com) wrote:
> On Mon, 07 May 2012 15:07:20 +0200, Alexander Larsson wrote:
> > I just wrote a new Feature proposal for shipping minimal debug info by
> > default:
> > https://fedoraproject.org/wiki/Features/MiniDebugInfo
>
> The "sever
On Mon, 07 May 2012 17:29:12 +0200, Jakub Jelinek wrote:
> On Mon, May 07, 2012 at 05:25:29PM +0200, Jan Kratochvil wrote:
> > On Mon, 07 May 2012 16:34:27 +0200, Jakub Jelinek wrote:
> > > For bug reporting, you don't need to upload core files, if all you want
> > > is to augment backtraces with s
On Mon, 07 May 2012 17:15:17 +0200, Alexander Larsson wrote:
> * They don't work offline, or before/after the network is up
+
> * Its problematic to use a retrace server during early boot, or e.g. in
> non-session apps like a daemon
/var/spool/abrt/ stores them for later GUI upload, it already w
On Mon, May 07, 2012 at 05:25:29PM +0200, Jan Kratochvil wrote:
> On Mon, 07 May 2012 16:34:27 +0200, Jakub Jelinek wrote:
> > For bug reporting, you don't need to upload core files, if all you want
> > is to augment backtraces with symbol info and perhaps line info, then
> > all you can do is just
On Mon, 07 May 2012 16:34:27 +0200, Jakub Jelinek wrote:
> For bug reporting, you don't need to upload core files, if all you want
> is to augment backtraces with symbol info and perhaps line info, then
> all you can do is just upload backtraces without symbol info/line info,
> supply the relevant
On Mon, 2012-05-07 at 16:25 +0200, Jan Kratochvil wrote:
> On Mon, 07 May 2012 15:07:20 +0200, Alexander Larsson wrote:
> > I just wrote a new Feature proposal for shipping minimal debug info by
> > default:
> > https://fedoraproject.org/wiki/Features/MiniDebugInfo
>
> The "several choices" is mis
On Mon, May 07, 2012 at 04:25:46PM +0200, Jan Kratochvil wrote:
> On Mon, 07 May 2012 15:07:20 +0200, Alexander Larsson wrote:
> > I just wrote a new Feature proposal for shipping minimal debug info by
> > default:
> > https://fedoraproject.org/wiki/Features/MiniDebugInfo
>
> The "several choices"
On Mon, 07 May 2012 15:07:20 +0200, Alexander Larsson wrote:
> I just wrote a new Feature proposal for shipping minimal debug info by
> default:
> https://fedoraproject.org/wiki/Features/MiniDebugInfo
The "several choices" is missing the primary possibility of no debug info
needed at the client si
85 matches
Mail list logo
