subject:"Proposed F18 feature\: MiniDebugInfo"

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 (almost) no translations on the KDE spin. They're all in
kde-l10n-* packages which add up to almost the size of a CD on their own.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]

Adam Jackson wrote:
 Even if all of your objections are true, and who knows, they might be:
 we already do provide alternatives.  The Live media is not the only
 install media.

The other alternatives are either already DVDs or netinstall CDs which 
require a fast Internet connection (which people who don't even have a DVD 
drive are unlikely to have).

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

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 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, adding up to a few MiB, and we keep running 
into size issues with our live image at every single release. Size matters!

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-10 Thread Alexander Larsson

On Thu, 2012-05-10 at 10:02 +0200, drago01 wrote:
 On Thu, May 10, 2012 at 9:20 AM, Kevin Kofler kevin.kof...@chello.at 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, adding up to a few MiB, and we keep running
  into size issues with our live image at every single release. Size matters!
 
 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 century.

I agree, I think bumping the image size to 1GB and use
DVD/mini-dvd/usb-stick is the sane way forward, since we consistently
run into the cd limit and are forced to make changes that negatively
affect the user experience in various ways.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

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 century.

If every live image gets larger, that will also negatively affect the nice 
Multi Desktop Live DVDs the Ambassadors are now mass-producing. Those 
contain all our live CDs (all desktops in both 32-bit and 64-bit versions, 
where the bitness is autodetected at boot, but can be manually overridden) 
on one DVD, which is a great thing to hand out at events.

We really shouldn't bloat our images just because we can.

Downloading debugging information (and complete debugging information!) on 
demand is really the best solution. Or use the retrace server if you'd 
rather have a web service do the work for you.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]

2012-05-10 Thread Troy Dawson

On 05/09/2012 03:07 PM, Jaroslav Reznik 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.
 
 I'd like to break CD limit too but we should not forgot there are users
 for which CD is top technology from dreams and we have a lot of these
 users among some countries... For me personally CD is history, even 
 DVD, same 1 GB flash drive. We can afford it. But some people can't 
 and are our users thanks to the ability to get a cheap OS, that can
 run on cheap HW and is still modern.
 
 The question is - how many people will be affected? Or should we 
 provide some fallback option - stripped down CD media size image? And
 make the bigger one primary one? 
 
 R.
 

I like the idea of a separate stripped down live CD image.
But it doesn't have to be too stripped down. What if we made the LXDE
and/or Xfce spin's CD size, while the Gnome and KDE live images would be
DVD size.

*braces for the Gnome is our default desktop replies*

Troy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-10 Thread Adam Jackson

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
  user experience because you insist on a medium from the last century.
 
 If every live image gets larger, that will also negatively affect the nice 
 Multi Desktop Live DVDs the Ambassadors are now mass-producing. Those 
 contain all our live CDs (all desktops in both 32-bit and 64-bit versions, 
 where the bitness is autodetected at boot, but can be manually overridden) 
 on one DVD, which is a great thing to hand out at events.

I am unable to find any ISOs of that media.  It appears this is somewhat
intentional:

http://lists.fedoraproject.org/pipermail/devel/2011-June/152520.html

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...

- ajax


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]

2012-05-10 Thread Adam Jackson

On Thu, 2012-05-10 at 09:16 +0200, Kevin Kofler wrote:
 Adam Jackson wrote:
  Even if all of your objections are true, and who knows, they might be:
  we already do provide alternatives.  The Live media is not the only
  install media.
 
 The other alternatives are either already DVDs or netinstall CDs which 
 require a fast Internet connection (which people who don't even have a DVD 
 drive are unlikely to have).

So the set of people we'd be inconveniencing is exactly the set of
people with no bandwidth and the inability to boot from anything larger
than a CD.

Do we think that's a statistically significant number of people, or are
we just arguing?

- ajax


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]

2012-05-10 Thread Johannes Lips

On Thu, May 10, 2012 at 4:00 PM, Adam Jackson a...@redhat.com wrote:

 On Thu, 2012-05-10 at 09:16 +0200, Kevin Kofler wrote:
  Adam Jackson wrote:
   Even if all of your objections are true, and who knows, they might be:
   we already do provide alternatives.  The Live media is not the only
   install media.
 
  The other alternatives are either already DVDs or netinstall CDs which
  require a fast Internet connection (which people who don't even have a
 DVD
  drive are unlikely to have).

 So the set of people we'd be inconveniencing is exactly the set of
 people with no bandwidth and the inability to boot from anything larger
 than a CD.

 Do we think that's a statistically significant number of people, or are
 we just arguing?

Would be interesting to get some input from lower-income countries.
Ambassadors from those countries could perhaps tell us about the hardware
which is most common.

Johannes


 - ajax

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-10 Thread Tom Callaway

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) but you are currently providing a poorer
 user experience because you insist on a medium from the last century.

 If every live image gets larger, that will also negatively affect the nice 
 Multi Desktop Live DVDs the Ambassadors are now mass-producing. Those 
 contain all our live CDs (all desktops in both 32-bit and 64-bit versions, 
 where the bitness is autodetected at boot, but can be manually overridden) 
 on one DVD, which is a great thing to hand out at events.
 
 I am unable to find any ISOs of that media.  It appears this is somewhat
 intentional:
 
 http://lists.fedoraproject.org/pipermail/devel/2011-June/152520.html
 
 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...

http://fedoraproject.org/wiki/Multi_Boot_Media_SOP

Caveat: I wrote the tooling there. It does use the the generated Desktop
Live ISOs as a base for making the large super ISO.

~tom

==
Fedora Project
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]

2012-05-10 Thread Chris Murphy


On May 10, 2012, at 9:00 AM, Adam Jackson wrote:

 So the set of people we'd be inconveniencing is exactly the set of
 people with no bandwidth and the inability to boot from anything larger
 than a CD.
 
 Do we think that's a statistically significant number of people, or are
 we just arguing?

Isn't it also true the Live CD is English only? English + ancient hardware + 
middle of nowhere. Quite honestly, this sounds like rural America (we have piss 
poor bandwidth in this country).

Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

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 composed by glueing together the independent live images plus a 
boot menu, so no, the cost will not be lower for each additional desktop 
environment, the size is exactly the sum of the sizes of all the CD ISOs 
(plus a negligible overhead).

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]

Chris Murphy wrote:
 Isn't it also true the Live CD is English only?

Most of the CDs carry translations, the KDE one does not though, due to how 
KDE translations work (they sit in huge kde-l10n-* packages).

The idea is that you install from the live CD and then you install the 
translation for your language(s) only. I have no need for every single kde-
l10n-* langpack shipped by upstream. Hardly anybody does. Most people need 
only one or two languages.

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]

2012-05-10 Thread Orcan Ogetbil

On Wed, May 9, 2012 at 5:22 PM, Jaroslav Reznik wrote:
 - Original Message -
 On Wed, 2012-05-09 at 16:07 -0400, Jaroslav Reznik 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.
 
  I'd like to break CD limit too but we should not forgot there are
  users
  for which CD is top technology from dreams and we have a lot of
  these
  users among some countries... For me personally CD is history, even
  DVD, same 1 GB flash drive. We can afford it. But some people can't
  and are our users thanks to the ability to get a cheap OS, that can
  run on cheap HW and is still modern.
 
  The question is - how many people will be affected? Or should we
  provide some fallback option - stripped down CD media size image?
  And
  make the bigger one primary one?

 Even if all of your objections are true, and who knows, they might
 be:
 we already do provide alternatives.  The Live media is not the only
 install media.

 Yep, it's not the only way, we even have our bigger offering already.
 And yeah, let's break CD rule but first - let ask if it still apply
 or not. Maybe it's my imagination and 3rd world is not anymore
 interested in this :)

 For example to Africa, we even do not ship CDs but DVDs - so at least,
 most people have a DVD-ROM drive :) The reason is - network bandwidth
 and Installation DVD fits more packages...


An alternative would be to ship a live DVD, right? How hard is it to
create a live DVD? Why do we not leave the decision of choosing
between a live CD and a live DVD as the live image, to the spin
maintainers? Even better, (hypothetically) a spin can choose to have
both a live CD and a live DVD.

Orcan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

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 a pain with a slow internet link due to the tons of data it wants
 transmit.  Also it doesn't say what it is going to do (download ?? MB
 debuginfo / upload ?? MB core).  And there is no progress bar.  Ok,
 might have changed meanwhile, its a while back I tried last.

Great, these were the first useful posts in this thread.

Therefore IIUC the problem is ABRT is not good enough.

I was also told in the meantime ABRT Retrace Server is not the default
/ automatic option of ABRT, which is also wrong.

So we should restate this Feature as:

Because ABRT has not yet met its expectations we should provide at
least this temporary solution before ABRT gets fixed.

So you agree?


Thanks,
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

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 one (if it has its issues - such as reported UI - fixed).

Then remains the question whether .symtab-unwinds are worth the 0.5-2% size
cost which I think they are not but in reality I do not mind at all.


Thanks,
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

- 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.  IMO ABRT Retrace Server
 should be
 the default one (if it has its issues - such as reported UI - fixed).

Yep, I second to this - and it's the right way to move the hassle of
debug info stuff away from client side and our users. Current problem
is more unfinished ABRT (as UI is hardly usable, retrace server should
be default) and no other requirements should be put on users. I like mitr's 
analysis - covering most of the users. Back to objective reasons - see below.

 Then remains the question whether .symtab-unwinds are worth the
 0.5-2% size
 cost which I think they are not but in reality I do not mind at all.

For us, as KDE SIG taking care of Fedora KDE offering, it's quite a lot 
as we're unfortunately balancing on the CD capacity edge (these 3.5 MB 
and probably more are quite a huge problem...) for several releases.

On the other hand, it can help Dr. Konqui to have at least some debug 
information (and yeah, debug info installer in Dr. Konqui is ugly hack).
But as far as I know, ABRT and Dr. Konqui guys are in touch regarding
the retrace server. So again moving the debug side of thing away from
users machine.

R.

 
 Thanks,
 Jan
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-09 Thread Gerd Hoffmann

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 get abrt reports at all, because abrt simply
 is a pain with a slow internet link due to the tons of data it wants
 transmit.  Also it doesn't say what it is going to do (download ?? MB
 debuginfo / upload ?? MB core).  And there is no progress bar.  Ok,
 might have changed meanwhile, its a while back I tried last.
 
 Great, these were the first useful posts in this thread.
 
 Therefore IIUC the problem is ABRT is not good enough.

There is room for improvements indeed.  It is one but not the only problem.

   Because ABRT has not yet met its expectations we should provide at
   least this temporary solution before ABRT gets fixed.

No.  There will always be cases where the current[1] abrt model fails:

Local trace generation requires downloading lots of debuginfo.  Might
not work / work badly because:
  (1) you are offline.
  (2) your internet link is slow.
  (3) you are on 3G and don't want to pay the volume.
  (4) you don't have the disk space to store debuginfo.

Server-based trace generation requires uploading a potentially large
core file (which probably can be reduced using mozilla-like minidumps).
 Bandwidth requirements aside there are still issues with that:
  (1) works only when online.
  (2) you might not want upload to the fedora server for privacy
  or company policy reasons.
  (3) private / company-wide retrace server needs extra effort (both
  hardware and work time), you can't count on it being available.

cheers,
  Gerd

[1] I expect abrt support minidebuginfo traces too once the feature
is there.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-09 Thread Miroslav Lichvar

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 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.

What is the overall effect on the rpm size? On installation media
every percent counts, if it's close to 3%, that might be too much for
some spins.

-- 
Miroslav Lichvar
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

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 Pretty Printers support for C++ classes.

For better speed of ABRT Retrace Server core files upload we should
re-implement
gdbserver for core files

https://fedorahosted.org/pipermail/crash-catcher/2010-December/001441.html

But so far I have no idea how / if / why not ABRT Retrace Server is being
used, if the core files upload speed is a real concern etc. so I did not work
more on thue gdbserver core files access feature for ABRT Retrace Server.


  Bandwidth requirements aside there are still issues with that:
   (1) works only when online.
   (2) you might not want upload to the fedora server for privacy
   or company policy reasons.
   (3) private / company-wide retrace server needs extra effort (both
   hardware and work time), you can't count on it being available.

These are all valid concerns but the question is if they are relevant to 99%
of users who install Mozilla binary plugins and even Adobe Flash already
losing any security anyway.


Thanks,
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-09 Thread Kevin Kofler

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 installing any sort of 
debugging information by default.

 My personal opinion is that we should go with compressed data,

Compression does not help at all, because the live images are xz-compressed 
and the maximum size is 700 MiB compressed. If you pre-compress the data, it 
will likely only make the xz compression rate worse.

 This means we use minimal space (i.e. an installation increase by only
 0.5%)

Even that is too much, even more so if that's when compressed!

Kevin Kofler

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

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-September/000984.html

C++ classes no longer have displayed any read/write strings/data.

If there are a real concern about core files upload speed and ABRT is going to
deploy the full-quality core file transfer via gdbserver as I have shown in:
gdbserver for core files

https://fedorahosted.org/pipermail/crash-catcher/2010-December/001441.html

I can reimplement it (from elfutils based gdbserver to FSF/bfd gdbserver).
But so far I had no response to either question so I did not spend time on
something without any need and/or not used.


Thanks,
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

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

Re: Proposed F18 feature: MiniDebugInfo

2012-05-09 Thread Alexander Larsson

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 
 tests like how it impacts the current gnome/kde live cd or other 
 spins. If the additional payload is really small then I don't see a 
 problem here (but I'm glad the decision is not mine ;))

That requires us to rebuild the entire distro to get the minidebuginfo
rpms. Its certainly doable, but some work. I can produce a patch to
rpm-build that does this, but I can't really do the rebuild stuff, that
would need help from someone on the build team.

 For 2: At this point (F18 timeframe) probably not. From ABRT point of 
 view the minidebug is not a problem at all if we can use gdb to generate 
 some backtrace using the mindebuginfo. But what matters are developers 
 who will need to deal with this stripped backtrace and I can guarantee 
 that there will be many unhappy devels. And also the ABRT server 
 projects rely on the coredumps: 
 http://git.fedorahosted.org/git?p=abrt.git;a=blob_plain;f=doc/project/abrt.pdf;hb=HEAD
  
 And once put into life these server side projects will be a great help 
 in bugfixing.

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 bugreport because things are scary/slow/bad
network/whatever and at least report the low quality backtrace, which
should be very quick and require little work from the user.

I don't have a full design in mind, but I'm thinking that as soon as the
user acks that he wants to report the bug we would start by just
uploading the low quality backtrace, and *then* start retracing the bug
and show the user the backtrace with full data etc, asking them if its
ok to submit the data. That way we get at least *something* in all
crashes, and perfect reports for users that goes all the way.




-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-09 Thread Jakub Jelinek

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 bugreport because things are scary/slow/bad
 network/whatever and at least report the low quality backtrace, which
 should be very quick and require little work from the user.

But you don't need any kind of minidebuginfo for that first step,
you can make it even faster by just uploading the backtrace + build-ids
and on the server side the rest of transforming that to a low-quality
backtrace can be handled automatically, without
further user intervention, in case the user didn't go through to uploading
the high quality thing from retrace server.

Jakub
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-09 Thread Jiri Moskovcak


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 all the cases where
people abort a bugreport because things are scary/slow/bad
network/whatever and at least report the low quality backtrace, which
should be very quick and require little work from the user.


But you don't need any kind of minidebuginfo for that first step,
you can make it even faster by just uploading the backtrace + build-ids
and on the server side the rest of transforming that to a low-quality
backtrace can be handled automatically, without
further user intervention, in case the user didn't go through to uploading
the high quality thing from retrace server.

Jakub


- that's something what we have right now (should be in F18), we have a 
server which accepts something we call microreport (kind of a backtrace 
without debuginfo + build_id and some other information - yes, it's 
similar to minidump) this is small enough to be uploaded on almost any 
internet connection and contains enough information to find duplicates.


The workflow we would like to use is something like this:
1. ABRT detects a crash
2. User clicks report which sends a microreport (few kilobytes)
3. is it a dupe?
  YES: send back response with the ticket url, increase the dupe counter
  NO: ask user to upload the core or full backtrace

But, I think that's a totally different use-case than what minidebuginfo 
is trying to solve.


From what I understand the use case for minidebuginfo is when something 
crashes on machine where the full debuginfo is not available and for 
some reason the machine is configured to not store the coredumps, but we 
still want to have something more in log than just process foo has 
crashed.


--Jirka
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-09 Thread Frank Ch. Eigler


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?

- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-09 Thread Rex Dieter

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 abandon the CD-ROM
 format limits?

some folks seem to want that to happen asap (ie, for f18 or f19)

count me as 'some folk'

-- rex

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-09 Thread Frank Ch. Eigler


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 configurations of systemtap (and perf) would definitely use
this extra local data if it were available.  Ideally for stap's case,
support for these sections would likely reside in elfutils and not
require actual systemtap changes.

- FChE
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-09 Thread Matthias Clasen

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 these
  are.
 
 There is no room left on the KDE live image for installing any sort of 
 debugging information by default.
 

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...


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

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
   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 installing any sort of 
  debugging information by default.
 
 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...

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 both the smallest MiniDVD format and most extant USB sticks.
Let's do it already.

- ajax


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-09 Thread John Reiser

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 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 (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 working boxes that cannot boot from USB.

-- 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

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 DVD, the reduced seek time
  is entirely worth it.
  
  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 (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 working boxes that cannot boot from USB.

Those are wonderful numbers.  How ever did you arrive at them?

Also: Live image still not the only install method, hyperbole is not
necessary.

- ajax



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-09 Thread Bruno Wolff III


On Mon, May 07, 2012 at 17:36:07 +0200,
  Jan Kratochvil jan.kratoch...@redhat.com 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 already inserted trojan
uploading of any private info in the shipped binaries.


While this applies for some scenarios, it doesn't cover everything. Once 
the data is on those servers it is vulnerable to things (e.g. subpoenas,

mistakes in configuration) at that location that it otherwise wouldn't be.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-09 Thread Chris Adams

Once upon a time, John Reiser jrei...@bitwagon.com 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 working boxes that cannot boot from USB.

[Citation needed]

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?

-- 
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-09 Thread John Reiser

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% of working USB sticks that are
 512MB or less, and some 5% of working boxes that cannot boot from USB.
 
 Those are wonderful numbers.  How ever did you arrive at them?

They're from my own laboratory of 20 boxes and 15 USB sticks accumulated
slowly and semi-regularly over the last decade or so.  That omits
6 really ancient boxes (15 years old each) that have been discarded
along the way.

-- 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

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 (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 working boxes that cannot boot from USB.
  
  Those are wonderful numbers.  How ever did you arrive at them?
 
 They're from my own laboratory of 20 boxes and 15 USB sticks accumulated
 slowly and semi-regularly over the last decade or so.  That omits
 6 really ancient boxes (15 years old each) that have been discarded
 along the way.

Forgive me for not considering that a representative sample.

- ajax


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-09 Thread Dave Jones

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 (especially old laptops)
  that can read only CD and not DVD

As someone who frequently sees bugs that are attributed to old half-dead 
hardware
that belongs in a recycling center, I'll happily acknowledge anything that 
leaves
ancient junk behind.

I'd like to see us introduce more explicit cut-offs for support of older 
hardware.

Dave

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]

 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.

I'd like to break CD limit too but we should not forgot there are users
for which CD is top technology from dreams and we have a lot of these
users among some countries... For me personally CD is history, even 
DVD, same 1 GB flash drive. We can afford it. But some people can't 
and are our users thanks to the ability to get a cheap OS, that can
run on cheap HW and is still modern.

The question is - how many people will be affected? Or should we 
provide some fallback option - stripped down CD media size image? And
make the bigger one primary one? 

R.

 1G fits on both the smallest MiniDVD format and most extant USB
 sticks.
 Let's do it already.
 
 - ajax
 
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-09 Thread Jon VanAlten

- Original Message -
 From: Adam Jackson a...@redhat.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 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 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 (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 working boxes that cannot boot
   from USB.

   Those are wonderful numbers.  How ever did you arrive at them?

  They're from my own laboratory of 20 boxes and 15 USB sticks
  accumulated
  slowly and semi-regularly over the last decade or so.  That omits
  6 really ancient boxes (15 years old each) that have been
  discarded
  along the way.

 Forgive me for not considering that a representative sample.

 - ajax

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 made with
all available information).

cheers,
jon

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]

2012-05-09 Thread drago01

On Wed, May 9, 2012 at 10:07 PM, Jaroslav Reznik jrez...@redhat.com 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.

 I'd like to break CD limit too but we should not forgot there are users
 for which CD is top technology from dreams and we have a lot of these
 users among some countries...

Where are the numbers to back this nonsense up?
A DVD burner costs ~12 € ... and any computer that old isn't really
that capable of running  fedora reasonably anyway.

 For me personally CD is history, even
 DVD, same 1 GB flash drive. We can afford it. But some people can't
 and are our users thanks to the ability to get a cheap OS, that can
 run on cheap HW and is still modern.

See above.

 The question is - how many people will be affected? Or should we
 provide some fallback option - stripped down CD media size image? And
 make the bigger one primary one?

Well anyone can create a specialized spin for ancient hardware, but we
should not restrict ourselves because of ancient hardware.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]

2012-05-09 Thread Gerry Reno

If you watch, you can get DVD burners for about $15 USD.

eg:
http://slickdeals.net/permadeal/62972/newegg-liteon-external-cddvd-burner-w-lightscribe-support

Or used for about $5-$10 at any flea market.

On 05/09/2012 04:33 PM, drago01 wrote:
On Wed, May 9, 2012 at 10:07 PM, Jaroslav Reznik jrez...@redhat.com 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.
I'd like to break CD limit too but we should not forgot there are users
for which CD is top technology from dreams and we have a lot of these
users among some countries...
Where are the numbers to back this nonsense up?
A DVD burner costs ~12 € ... and any computer that old isn't really
that capable of running fedora reasonably anyway.

For me personally CD is history, even
DVD, same 1 GB flash drive. We can afford it. But some people can't
and are our users thanks to the ability to get a cheap OS, that can
run on cheap HW and is still modern.
See above.

The question is - how many people will be affected? Or should we
provide some fallback option - stripped down CD media size image? And
make the bigger one primary one?
Well anyone can create a specialized spin for ancient hardware, but we
should not restrict ourselves because of ancient hardware.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

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 made with
 all available information).

Yeah, someone always says this, and then I go try to get data out of
smolt, and then I drink myself into a coma.  It is (and always has been)
infuriatingly difficult to get usable numbers out of it.

At least right now it's just throwing varnish cache errors at me, so I
don't waste my time.

- ajax



signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]

2012-05-09 Thread Chris Murphy


On May 9, 2012, at 2:07 PM, Jaroslav Reznik wrote:
 
 I'd like to break CD limit too but we should not forgot there are users
 for which CD is top technology from dreams and we have a lot of these
 users among some countries... For me personally CD is history, even 
 DVD, same 1 GB flash drive. We can afford it. But some people can't 
 and are our users thanks to the ability to get a cheap OS, that can
 run on cheap HW and is still modern.
 
 The question is - how many people will be affected? Or should we 
 provide some fallback option - stripped down CD media size image? And
 make the bigger one primary one?

Is it marginally easier to stay below the CD size limit with 32-bit builds vs 
64-bit? i.e. could Fedora retain Live CD for i386, and move to a Live DVD for 
x86_64?

Or what problems are there abandoning Live CD for  10% (by estimates thus 
far), but retaining the ability to use netinst.iso for that hardware? I think 
the negative loss of this hardware for Live Desktop trial is minimal compared 
to the gain by dropping the limit.

But if it's almost trivial to have two Live Desktop builds: CD and DVD, then 
I'd suggest that route.

Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]

On Wed, 2012-05-09 at 16:07 -0400, Jaroslav Reznik 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.
 
 I'd like to break CD limit too but we should not forgot there are users
 for which CD is top technology from dreams and we have a lot of these
 users among some countries... For me personally CD is history, even 
 DVD, same 1 GB flash drive. We can afford it. But some people can't 
 and are our users thanks to the ability to get a cheap OS, that can
 run on cheap HW and is still modern.
 
 The question is - how many people will be affected? Or should we 
 provide some fallback option - stripped down CD media size image? And
 make the bigger one primary one? 

Even if all of your objections are true, and who knows, they might be:
we already do provide alternatives.  The Live media is not the only
install media.

- ajax


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]

- Original Message -
 On Wed, 2012-05-09 at 16:07 -0400, Jaroslav Reznik 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.
  
  I'd like to break CD limit too but we should not forgot there are
  users
  for which CD is top technology from dreams and we have a lot of
  these
  users among some countries... For me personally CD is history, even
  DVD, same 1 GB flash drive. We can afford it. But some people can't
  and are our users thanks to the ability to get a cheap OS, that can
  run on cheap HW and is still modern.
  
  The question is - how many people will be affected? Or should we
  provide some fallback option - stripped down CD media size image?
  And
  make the bigger one primary one?
 
 Even if all of your objections are true, and who knows, they might
 be:
 we already do provide alternatives.  The Live media is not the only
 install media.

Yep, it's not the only way, we even have our bigger offering already.
And yeah, let's break CD rule but first - let ask if it still apply 
or not. Maybe it's my imagination and 3rd world is not anymore 
interested in this :)

For example to Africa, we even do not ship CDs but DVDs - so at least,
most people have a DVD-ROM drive :) The reason is - network bandwidth
and Installation DVD fits more packages...

R.

 - ajax
 
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

- 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 the limit, but would prefer the decision be made with
  all available information).
 
 Yeah, someone always says this, and then I go try to get data out of
 smolt, and then I drink myself into a coma.  It is (and always has
 been)
 infuriatingly difficult to get usable numbers out of it.

Smolt is a good idea! But looks like I should send you some bottle
of our home distilled snaps - the legal one, Slivovice :)

R.

 At least right now it's just throwing varnish cache errors at me, so
 I
 don't waste my time.
 
 - ajax
 
 
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]

2012-05-09 Thread John Reiser

On 05/09/2012 01:33 PM, drago01 wrote:
 On Wed, May 9, 2012 at 10:07 PM, Jaroslav Reznik jrez...@redhat.com wrote:

 I'd like to break CD limit too but we should not forgot there are users
 for which CD is top technology from dreams and we have a lot of these
 users among some countries...
 
 Where are the numbers to back this nonsense up?
 A DVD burner costs ~12 € ... and any computer that old isn't really
 that capable of running  fedora reasonably anyway.

Such a claim is FALSE.  My 700MHz PentiumIII with 384MB RAM runs Fedora 11
just fine.  OpenOffice is eminently usable, for example.  It's a 2001
laptop that has only CD-ROM and USB1.1, and the BIOS cannot boot from USB.
I have added USB2.0 via PCMCIA card, and somewhere around Fedora 12
could boot from external DVD via USB2.0 (via trampoline from the harddrive)
because the PCMCIA drivers for the bridge that enables the USB2.0 card
were in the initrd.  But then the PCMCIA drivers were dropped from initrd,
so it no longer boots newer Fedora from DVD.  Meanwhile deteriorating
support for RagePro graphics has nudged me back to Fedora 11.  Fedora 11
is only 3 years old.

-- 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-09 Thread Alexander Larsson

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 these
  are.
 
 There is no room left on the KDE live image for installing any sort of 
 debugging information by default.

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.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]

2012-05-09 Thread Gerry Reno

On 05/09/2012 05:34 PM, John Reiser wrote:
 On 05/09/2012 01:33 PM, drago01 wrote:
 On Wed, May 9, 2012 at 10:07 PM, Jaroslav Reznik jrez...@redhat.com wrote:
 I'd like to break CD limit too but we should not forgot there are users
 for which CD is top technology from dreams and we have a lot of these
 users among some countries...
 Where are the numbers to back this nonsense up?
 A DVD burner costs ~12 € ... and any computer that old isn't really
 that capable of running  fedora reasonably anyway.
 Such a claim is FALSE.  My 700MHz PentiumIII with 384MB RAM runs Fedora 11
 just fine.  OpenOffice is eminently usable, for example.  It's a 2001
 laptop that has only CD-ROM and USB1.1, and the BIOS cannot boot from USB.
 I have added USB2.0 via PCMCIA card, and somewhere around Fedora 12
 could boot from external DVD via USB2.0 (via trampoline from the harddrive)
 because the PCMCIA drivers for the bridge that enables the USB2.0 card
 were in the initrd.  But then the PCMCIA drivers were dropped from initrd,
 so it no longer boots newer Fedora from DVD.  Meanwhile deteriorating
 support for RagePro graphics has nudged me back to Fedora 11.  Fedora 11
 is only 3 years old.


Just install over the network and not be stuck in Fedora 11.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]

2012-05-09 Thread Michael Cronenworth

John Reiser wrote:
 My 700MHz PentiumIII with 384MB RAM

If Fedora Live media is going to be held back due to your requirements
then I'm going to find myself a new distro to contribute to.

Yes, Fedora Live media should support a *reasonable* set of hardware.
Your hardware is no longer *reasonable*. It is time to move on. End of
discussion - as you will end up dragging this on until the horse is a
ghost (it is already a skeleton).

If the infrastructure team wants to increase default Live image sizes to
1GB then they should do it.

If you want to create your own, custom Live image on that P3 you can
easily do so[1]. I'd expect it will take about a week to complete. It
takes my year old Core i5 about 15 minutes to perform the same operation.

[1] http://fedoraproject.org/wiki/How_to_create_and_use_a_Live_CD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]

2012-05-09 Thread Przemek Klosowski


On 05/09/2012 05:34 PM, John Reiser wrote:

On 05/09/2012 01:33 PM, drago01 wrote:



A DVD burner costs ~12 € ... and any computer that old isn't really
that capable of running  fedora reasonably anyway.


Such a claim is FALSE.  My 700MHz PentiumIII with 384MB RAM runs Fedora 11
just fine.  OpenOffice is eminently usable, for example.  It's a 2001
laptop that has only CD-ROM and USB1.1, and the BIOS cannot boot from USB.
I have added USB2.0 via PCMCIA card, and somewhere around Fedora 12
could boot from external DVD via USB2.0 (via trampoline from the harddrive)
because the PCMCIA drivers for the bridge that enables the USB2.0 card
were in the initrd.  But then the PCMCIA drivers were dropped from initrd,
so it no longer boots newer Fedora from DVD.  Meanwhile deteriorating
support for RagePro graphics has nudged me back to Fedora 11.  Fedora 11
is only 3 years old.


Would that laptop not have a floppy disk that'd let you boot in 
combination with an external USB flash/CD/DVD drive? 1-2GB flash drives 
cost 2-3$ so they would be the cheapest/simplest thing to use if your 
system doesn't already have a DVD. The next best thing would be an 
external USB DVD burner that should be less than $30 or so, and is 
actually a good thing to have around the den anyway.


This reminds me of the old days in the mid- to late 90s when we were 
running DCLUG Linux Installfests in Washington DC and RedHat crew drove 
up from North Carolina, to test their install process. People would 
bring the strangest hardware, and we'd give it our best, sometimes 
working the entire afternoon on the most recalcitrant systems.


That experience taught me to make a judgement call: while, on one hand, 
hardware constraints are good because they keep things honest and 
simple, and make things fast on modern hardware, at the same time some 
limitations are just too onerous.  I would say that BIOS inability to 
boot off USB devices crosses that line.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]

2012-05-09 Thread Adam Williamson

On Wed, 2012-05-09 at 15:17 -0600, Chris Murphy wrote:

 But if it's almost trivial to have two Live Desktop builds: CD and DVD, then 
 I'd suggest that route.

I can tell you it's very unlikely they'd both get comprehensively QA'ed.
And the more spins we have, the more likely some of them are to fail to
build.

We actually already nominally *have* a 1G sized desktop spin, but it's
rarely actually spun so it's often broken. See fedora-live-desktop.ks
vs. fedora-livecd-desktop.ks.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-09 Thread Matej Cepl


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/tinycorelinux/welcome.html ;)


Matěj

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-09 Thread Adam Williamson

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 Tiny Core 
 Linux is less than 12MB ... 
 http://distro.ibiblio.org/tinycorelinux/welcome.html ;)

I think he's talking about Fedora ones, and it's a reasonable point.
None of our main live images are under 512MB in size. So given that
no-one makes 700MB or 768MB USB sticks, by going from 700MB to 1GB in
size we would effectively lose precisely zero USB sticks.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]

2012-05-09 Thread Vít Ondruch


Dne 9.5.2012 23:34, John Reiser napsal(a):

On 05/09/2012 01:33 PM, drago01 wrote:

On Wed, May 9, 2012 at 10:07 PM, Jaroslav Reznikjrez...@redhat.com  wrote:

I'd like to break CD limit too but we should not forgot there are users
for which CD is top technology from dreams and we have a lot of these
users among some countries...

Where are the numbers to back this nonsense up?
A DVD burner costs ~12 € ... and any computer that old isn't really
that capable of running  fedora reasonably anyway.

Such a claim is FALSE.  My 700MHz PentiumIII with 384MB RAM runs Fedora 11
just fine.  OpenOffice is eminently usable, for example.  It's a 2001
laptop that has only CD-ROM and USB1.1, and the BIOS cannot boot from USB.
I have added USB2.0 via PCMCIA card, and somewhere around Fedora 12
could boot from external DVD via USB2.0 (via trampoline from the harddrive)
because the PCMCIA drivers for the bridge that enables the USB2.0 card
were in the initrd.  But then the PCMCIA drivers were dropped from initrd,
so it no longer boots newer Fedora from DVD.  Meanwhile deteriorating
support for RagePro graphics has nudged me back to Fedora 11.  Fedora 11
is only 3 years old.



This discussion is about Live CD of F18+, so don't worry, nobody will 
increase Live CD size of F11 ;)



Vit
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

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 agreement. I only wanted to post here
the opposite side of oppinions on this formal feature request.

I think this is the one thing we can agree on.

With Alex' work you need very very little working, just a small unwinder.

Yes, just an unwinder. Not backtrace for debugging the problem.

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 is happening and you have to rely on the bugreport only.
This is sometimes doable even without debug info, I even wrote a blog
post about this:

http://blogs.gnome.org/alexl/2005/08/26/the-art-of-decoding-backtraces-without-debug-info/

But, having the full symbol names for all libraries and apps in all
backtraces I'll ever see in the future would help me immensely. Even if
its just an unwinder.

I am pretty sure I don't want my local developer machine always talk to
the fedora server

Again, as a developer you can affort several GBs of debuginfo.

Not only developers are interested in backtraces, and not only on their
development machine. Administrators are too, and developers are
interested in backtraces from live systems in deployment etc. It just
makes more sense to have solid reliable client side backtraces.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

On Mon, 2012-05-07 at 18:55 +0100, Peter Robinson wrote:
 On Mon, May 7, 2012 at 2:07 PM, Alexander Larsson al...@redhat.com 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, which all have various
  different pros and cons. I'd like to hear what peoples opinions on these
  are.
 
  My personal opinion is that we should go with compressed data, in the
  original files without the line number information. This means we use
  minimal space (i.e. an installation increase by only 0.5%) while being
  completely transparent to users. It does however make the normal
  packages larger in a non-optional way which some people disagree with.
 
 What sort of size impact are we talking about here, there's a lot of
 devices that people are starting to use Fedora on such as ARM devices
 that don't have a lot of storage space. One of the most widely
 deployed devices running Fedora for example is the OLPC XO-1 which
 only has 1gb of space so every size increase is a hit and Fedora is
 already starting to have quite a large muffin top to deal with.

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.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

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 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.
  
  My personal opinion is that we should go with compressed data, in the
  original files without the line number information. This means we use
  minimal space (i.e. an installation increase by only 0.5%) while being
  completely transparent to users. It does however make the normal
  packages larger in a non-optional way which some people disagree with.
 
 1) minidebuginfo.rpm is silly. Either it's small enough (and 0.5% is
 certainly that, IMO) that it goes in the main package, or it's too big and
 we should just do regular debuginfo packages.

I completely agree.

 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?

I'm not sure what these tools use to unwind, I expect that we'd have to
implement it in libunwind too (added it to the deps) at the very least.
However, anything that already supports separate debug info should be
able to also load this with very little work as it is very similar.

 3) You mention this being done in find-debuginfo.sh, via injection(?). Is
 this possible to be done automatically even for non-rpm-packaged code?

It surely is, the actual change is just a few lines of added shell code.

Basically, when you've separated out the normal separate debug info
you make a copy of it, then run some strip operations on the copy to
remove all but the minimal debug info, then you do:
 xz $debuginfofile
 objcopy --add-section .gnu_debugdata=$debuginfofile.xz $executable

 4) I disagree with the contention that this should all be done via the
 retrace server.

 For this to provide a reasonable amount of information, all you need is:
 - an unwinder
 
 Simpler is usually better.

Agree.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

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:
  
  - all relevant binaries and DSOs built in Fedora
 
 When we are considering Fedora Bugzilla bugreports then it is valid.
 Custom downloaded binaries will not have this compressed-.symtab anyway.

Any rpm built by anyone with this feature will have this information in
it. Be it a locally rebuild fedora rpm such as a scratch build or a
totally custom rpm. Just like we build debuginfo rpms for such rpms.

  For this to provide a reasonable amount of information, all you need is:
  - an unwinder
 
 The problem is .symtab is not sufficient information for a backtrace.

You keep saying this, but I and several others think that having it is a
sufficient for a great many things.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-08 Thread Jakub Jelinek

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 is happening and you have to rely on the bugreport only.
 This is sometimes doable even without debug info, I even wrote a blog
 post about this:
 
 http://blogs.gnome.org/alexl/2005/08/26/the-art-of-decoding-backtraces-without-debug-info/
 
 But, having the full symbol names for all libraries and apps in all
 backtraces I'll ever see in the future would help me immensely. Even if
 its just an unwinder.

But for that you really don't need the symtabs stored in the binaries/shared
libraries, you can just have the backtrace without symbols printed + print
relevant build-ids at the beginning, a script at any time can reconstruct
that into not just the symbol names, but also lineinfo.  And the build-ids
will help even if you want to look at further details (.debug_info, source
files).

Jakub
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

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 run it in gdb myself. When you need it is when
something weird is happening and you have to rely on the bugreport only.
This is sometimes doable even without debug info, I even wrote a blog
post about this:

http://blogs.gnome.org/alexl/2005/08/26/the-art-of-decoding-backtraces-without-debug-info/

But, having the full symbol names for all libraries and apps in all
backtraces I'll ever see in the future would help me immensely. Even if
its just an unwinder.

But for that you really don't need the symtabs stored in the binaries/shared
libraries, you can just have the backtrace without symbols printed + print
relevant build-ids at the beginning, a script at any time can reconstruct
that into not just the symbol names, but also lineinfo. And the build-ids
will help even if you want to look at further details (.debug_info, source
files).

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. The later is far more robust and simple.
It lets you directly get a reasonable backtrace given *only* the actual
binaries in the running process.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-08 Thread Jakub Jelinek

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 minidebuginfo. The later is far more robust and simple.
 It lets you directly get a reasonable backtrace given *only* the actual
 binaries in the running process.

What is far more robust and simple is something we simply have to agree to
disagree on.

Jakub
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-08 Thread Jan Kratochvil

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. The later is far more robust and simple.
 It lets you directly get a reasonable backtrace given *only* the actual
 binaries in the running process.

Also during local crashes the daemon/process has been automatically updated in
the meantime on the disk while the older binary is still running - and it
crashes.  Only a few packages restart the daemon on its update (openssh does),
most packages do not (*).

In such case of stale running binary even local /usr/lib/debug is not enough
(and minidebuginfo sure also does not work), with ABRT Retrace Server it
always just works.

The unavailability of infrastructure is a myth, people have moved to Google
services from local programs and there are no complaints for unavailability.

partial countercase to my argument: minidebuginfo could still work for the
main executable as during the crash dump it is still readable as /proc/PID/exe
and it could be extracted from it.  But for any .so libraries there is no
associated fd provided by kernel so in practice it is not applicable anyway.


Regards,
Jan


(*) OT: Is not restarting a daemon on its update a packaging bug or not?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-08 Thread Miloslav Trmač

On Mon, May 7, 2012 at 11:36 PM, Lennart Poettering
mzerq...@0pointer.de 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 machines, with the same prepared OS
 image. You want to know about the backtraces as admin. Now, since the OS
 images are all the same some errors will happen across all the machines
 at the same time. Now, with your logic this would either result in all
 of them downloading a couple of GB of debuginfo for glibc and stuff like
 that, or all of them bombarding the retrace server, if they can.

No, someone administering a pool of machines would also want to
collect the crash information centrally instead of running tools
manually on every machine in the pool - and it turns out ABRT was from
the start designed to support such data collection; all core files can
be configured to end up at a single analysis machine.

The analysis machine can either have debuginfo installed locally (if
the single OS image is always the same) and just run gdb with full
information, or there can be a company-wide retrace server - it's an
open source project as well.  At no moment is a system administrator
of a large pool of machines forced to send data to Fedora
infrastructure if they don't want to.


 But anyway, I don't think it's worth continuing this discussion, this is
 a bit like a dialogue between two wet towels...

Let me try it one more time anyway, it seems to me that various use
cases were being mixed together in the reply quoting.  There are about
three major different classes of users, depending on who is the first
responder to a particular crash (not depending no who will ultimately
want to review the information):
1) Developers of the software in question
2) Non-programming end-users.
3) System administrators who do not routinely deal with this
particular program, but may need to get as much data as possible.
and the discussion was mixing 1 and 2, and 2 and 3 fairly often.


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 logging and do other non-default things to make
their job easier; The Fedora defaults don't matter that much for them,
and the mini debuginfo is not that useful either.

2) Non-programming end-users.  _This_ is the case that we need to get
right by default.In many cases, a developer is lucky if the end
user ever sends any crash report, they often don't respond to
follow-up questions, and the problem does not have to be reproducible
at all.  From such users we definitely want as full crash information
as possible (IOW, including the variable contents information) because
there won't be a second change to get it.  The mini debuginfo is
therefore irrelevant, we need to steer users to the retrace server (or
to attaching full core files to reports, which has much worse privacy
impact).

3) System administrators who do not routinely deal with this
particular program, but may need to get as much data as possible.
Now, this is _not_ the case that we need to get right by default -
although it would be nice if we could.  And the question is what will
the system administrators do with the information?

3a) The system administrator will try to fully debug the crash,
perhaps even preparing a patch.  In that case they need full source
code, understand the program etc, and having to install full debuginfo
is really not too much to ask; mini debuginfo would be marginally
useful.

3b) The system administrator will only attempt to roughly understand
the problem (_this_ is what a typical kernel user does, e.g. ah, SCSI
error handling is in the backtrace, so there must be something wrong
with the disk subsystem).  This is where mini debuginfo comes in
useful.


Can we agree on the above, at least  that 1) and 2) are not noticeably
improved by mini debuginfo, and that 3b benefits from mini debuginfo?
(There may be disagreement about 3a, but I'm not inclined to worry
about it too much - it's fairly similar to 1) anyway).

If so, good - let's talk about whether we want the additional code
complexity and packaging complexity and space usage, to benefit 3b)
only.  (I'd say that it's not something I would work on, and not
something FESCo should mandate that it must be supported, but if
someone else writes the code and either upstreams or the respective
Fedora package owners want to accept it, why not?).

BTW, the feature suggests mini debuginfo would be useful for userspace
tracing - AFAIK such uses, e.g. systemtap, use the variable location
information very extensively, and would thus not benefit from mini
debuginfo.
   Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

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 logging and do other non-default things to make
 their job easier; The Fedora defaults don't matter that much for them,
 and the mini debuginfo is not that useful either.

I generally agree with this. When i'm working on an app I generally have
custom builds of it and its dependencies. However, at some point down
the dependency chain i start relying on distro packages, and it would be
kind of nice to have some info for that when e.g. profiling or
something.

 2) Non-programming end-users.  _This_ is the case that we need to get
 right by default.In many cases, a developer is lucky if the end
 user ever sends any crash report, they often don't respond to
 follow-up questions, and the problem does not have to be reproducible
 at all.  From such users we definitely want as full crash information
 as possible (IOW, including the variable contents information) because
 there won't be a second change to get it.  The mini debuginfo is
 therefore irrelevant, we need to steer users to the retrace server (or
 to attaching full core files to reports, which has much worse privacy
 impact).

I agree that we need to get this right, and that its the most important
problem. However, I don't agree with your reasoning. Its true that it
would be nice to have as much information as possible, and having the
retraced data availible when it works is nice. However, the details with
retracing, having to show the full backtrace letting you ack the
backtrace for privacy issue, the waiting for the retracing to happen,
etc, risks scaring the user away resulting in nothing being reported at
all. 

Take this post for instance:

https://plus.google.com/110933625728671692704/posts/iFXggK7Q8KJ

It show exactly why this is a problem. We try to get more information,
but the result is less information. 

A report based on the minidebuginfo already existing on the system will
give you a basic backtrace that is quite useful, and this should be
reportable with a single, fast operation just sending the data to the
server (as well as logging it to the system logs). The developer can
then do the retrace from that on the server side to get line numbers if
they are needed. We can also have an optional method of reporting that
gives the full stacktrace information, does the retracing over the
network and whatnot, but I don't think its a good idea to do by default.

 BTW, the feature suggests mini debuginfo would be useful for userspace
 tracing - AFAIK such uses, e.g. systemtap, use the variable location
 information very extensively, and would thus not benefit from mini
 debuginfo.

True.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo

2012-05-08 Thread Gerd Hoffmann

On 05/08/12 13:08, Miloslav Trmač wrote:
 On Mon, May 7, 2012 at 11:36 PM, Lennart Poettering
 mzerq...@0pointer.de 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 machines, with the same prepared OS
 image. You want to know about the backtraces as admin. Now, since the OS
 images are all the same some errors will happen across all the machines
 at the same time. Now, with your logic this would either result in all
 of them downloading a couple of GB of debuginfo for glibc and stuff like
 that, or all of them bombarding the retrace server, if they can.
 
 No, someone administering a pool of machines would also want to
 collect the crash information centrally instead of running tools
 manually on every machine in the pool

Who talks about running stuff manually?  I'd expect we'll have some
service (abrt?) doing it automagically and send the trace to syslog, so
the userspace traces end up in the logs like the kernel oopses do today.

 - and it turns out ABRT was from
 the start designed to support such data collection; all core files can
 be configured to end up at a single analysis machine.

The minidebuginfo traces can easily go a central logserver too.

 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 logging and do other non-default things to make
 their job easier; The Fedora defaults don't matter that much for them,
 and the mini debuginfo is not that useful either.

Depends.  My internet link isn't exactly fast.  For stuff I'm working on
I have the debuginfo packages locally mirrored / installed.  For other
stuff I havn't and it can easily take hours to fetch it.  Having at
least a basic trace without delay has its value.  Often this is enougth
to track it down.

Or when debugging your own program (with full debuginfo) it is useful to
have at least the symbols of the libraries used in the trace too.

 2) Non-programming end-users.  _This_ is the case that we need to get
 right by default.In many cases, a developer is lucky if the end
 user ever sends any crash report, they often don't respond to
 follow-up questions, and the problem does not have to be reproducible
 at all.  From such users we definitely want as full crash information
 as possible (IOW, including the variable contents information) because
 there won't be a second change to get it.  The mini debuginfo is
 therefore irrelevant, we need to steer users to the retrace server (or
 to attaching full core files to reports, which has much worse privacy
 impact).

Wrong.  From /me you don't get abrt reports at all, because abrt simply
is a pain with a slow internet link due to the tons of data it wants
transmit.  Also it doesn't say what it is going to do (download ?? MB
debuginfo / upload ?? MB core).  And there is no progress bar.  Ok,
might have changed meanwhile, its a while back I tried last.

 Can we agree on the above, at least  that 1) and 2) are not noticeably
 improved by mini debuginfo,

No.

 BTW, the feature suggests mini debuginfo would be useful for userspace
 tracing - AFAIK such uses, e.g. systemtap, use the variable location
 information very extensively, and would thus not benefit from mini
 debuginfo.

How about 'perf top -p $pid'?

cheers,
  Gerd

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Proposed F18 feature: MiniDebugInfo