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: Logwatch - looking for testers
On 05/05/12 at 08:46pm, Richard Vickery wrote: > - Selinux Audit Begin > > > **Unmatched Entries** > Thank you, Richard! -- Jan Synacek Software Engineer, BaseOS team Brno, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
On May 8, 2012, at 10:43 AM, Przemek Klosowski wrote: > It seems to me that the main objection against a prominent 'install to disk' > button is that it is not part of a normal desktop workflow---if someone would > just routinely use a Live CD, it seems rude to show them an irrelevant > 'install' button. I agree, but I'm willing to let it go for F17. The one complaint I still have is that the window is really huge. I mean, it's taking up, what, 80% of the desktop real estate? > A good time and place to offer an 'install' option might be on startup (e.g. > via a notification popup), and on shutdown (by an 'install' menu option next > to 'reboot', and by another popup notifification 'you are about to shut down > the system; do you want to permanently install to disk?') I dunno. I think if there are concerns by the anaconda team about the machine state for running from within a live session, that state is even less known on shutdown than on startup. I'd sooner encourage a reboot. Another reason why I prefer the options: Live vs Install, at either bootloader menu or login. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Weekly ARM status meeting - Wed 2012/05/09
Hi everyone, A reminder that this week's ARM status meeting will take place tomorrow (Wednesday), on #fedora-meeting. There will be no phone call. Please reply to this email with any additional agenda items you want to add. Times in various timezones (please let us know if these do not work): PDT: 1pm MDT: 2pm CDT: 3pm EDT: 4pm UTC: 8pm BST: 9pm CST: 10pm Also join #fedora-arm on Freenode for general ARM discussion before/after the weekly syncup. Agenda: 0). Current build status - Gnarly bugs and build failures - Sending out regular problem package mails? - Atomics on older processors (v5)/LLVM/etc. 1). Fedora 17 Beta - What are the remaining constraints on getting this out? 2). Secondary Architecture Promotion - Update on our current status wiki page and response to reqs. 3). Your topic here Jon. P.S. I will return to poking at LLVM this afternoon. I hope to have an update in time for the meeting tomorrow - might be a very late night. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Install Fedora Button for LiveCD
On 04/27/2012 09:58 AM, Jared K. Smith wrote: What can we do in the *near* term to make it easier for people to find the "Install to Hard Drive" option from the LiveCD? It seems to me that the main objection against a prominent 'install to disk' button is that it is not part of a normal desktop workflow---if someone would just routinely use a Live CD, it seems rude to show them an irrelevant 'install' button. A good time and place to offer an 'install' option might be on startup (e.g. via a notification popup), and on shutdown (by an 'install' menu option next to 'reboot', and by another popup notifification 'you are about to shut down the system; do you want to permanently install to disk?') -- 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 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 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. I'd like to point out that I'm not actually proposing that we remove the full debug info or the ability to do stack winding on the server, as some people seem to worry about that. This is really about increasing the minimal quality of bug reports and debugging information. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F18 feature: MiniDebugInfo
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 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
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: ATI graphics card not being detected properly by F17 BETA or current update
>> I have a laptop with a radeon display that's been working fine using >> f16, but now the best I get is VESA. >> >> I've tried updating but it still boots with the blue/white bars at the >> bottom, instead of the graphic boot and the best resolution I can get >> is 1400x900 (the display is 1920x1080). >> >> I'm not sure if I need to pass something at start-up, but this seems >> like a significant regression as the display worked well with f16. >> >> Should I bugzilla this? > > Yes. But with useful details and logs, none of which are included above. > =) https://fedoraproject.org/wiki/How_to_debug_Xorg_problems > -- > Adam Williamson I've bugzilla'd this at https://bugzilla.redhat.com/show_bug.cgi?id=819850 and supplied all the information you've requested except the specific stuff for debugging ATI/AMD cards as I couldn't create a working xorg.conf that used the radeon driver. Hope this is useful. Rodd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: EPEL 6 cmake RPATH deafults?!?
On 8 May 2012 01:41, Richard Shaw wrote: > I have no problems reviewing it but do we need to seek any higher > level approval? I am not sure, but I don't think so - it meets the EPEL requirement of not replacing a RHEL package. This is why I didn't add a virtual provides for cmake, as this, I think, would overstep that line. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F18 feature: MiniDebugInfo
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 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, 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
