Releasing ownership of packages
Dear all, I am releasing ownership of my packages due to lack of time to properly maintain them. ant-antlr3 -- Antlr3 task for Ant emacs-ecb -- Emacs Code Browser emacs-rpm-spec-mode -- Major GNU Emacs mode for editing RPM spec files global -- Source code tag system inamik-tableformatter -- A set of Java classes to print text in tabulated form jopt-simple -- A Java command line parser notmuch -- system for indexing, searching, and tagging email python-functest -- Functional test framework python-mozbase -- The Mozilla suite of Python utilities python-windmill -- A web application testing framework python-wsgi-jsonrpc -- Expose Python classes via JSON using WSGI rubygem-acts-as-list -- Sorting and reordering capabilities for Active Record models trac-agilo-plugin -- A plugin for supporting the Scrum process in Trac Best regards, Karel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpm-spec-mode packaged separately from Emacs
The latest build of Emacs (emacs-24.2-4.fc19) no longer contains rpm-spec-mode. I have packaged the mode separately from Emacs to comply with Fedora Packaging Guidelines, as the mode has different upstream. Review feedback is welcome: #857865 - Review Request: emacs-rpm-spec-mode - Major GNU Emacs mode for editing RPM spec files Karel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How to proceed with MiniDebugInfo
IMHO administrators would benefit much more from the minidebuginfo feature than developers. The advantage for admins is that for every crash the computer would also give a name of the crash. So it's no longer just httpd: Core dumped., but you get a unique sequence of functions (a name) and you can talk about this particular crash with other admins (it's no longer just our webserver is randomly crashing), and search the Internet for other victims. It would be very cool if the bottom of the stack (last few functions) is printed to the terminal together with the usual Core dumped. message. For developers, it is unappealing to attempt fixing a bug just from an ordered list of function names. Karel Alexander Larsson wrote: Now, I don't want to repeat everything said before about what minidebuginfo can do, but I'll give some short examples of things that are nice to have and hard to do well without local debuginfo. * Write backtraces to syslog on coredumps * Allow ABRT to do better duplication matching (the ABRT developers even want minidebuginfo!) * Always get some minimal level of backtrace quality, even for rpms built locally or from other repositories which are not availible on the retrace servers. (Assuming they are built on a F18 or later which has this feature.) * Do system wide profiling and tracing without having to install a lot of debuginfo. * Help developers by always having at least some level of debuginfo, even for e.g. uncommon dependencies that you don't typically have debuginfo for, or when you don't have a network connection to get debuginfo packages. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bugs in debuginfo packages
Richard W.M. Jones wrote: On Thu, Feb 24, 2011 at 09:28:10AM +0100, Karel Klic wrote: component: cduce (rjones) file: cduce-0.5.3-8.fc15.i686/usr/bin/cduce - debuginfo missing; ELF stripped file: cduce-0.5.3-8.fc15.i686/usr/bin/dtd2cduce - debuginfo missing; ELF stripped This and many of the other ones that you reported against my name and OCaml native binaries. The OCaml compiler doesn't generate DWARF output (because nothing at the moment could consume it, so what would be the point). Now I don't know if it's a bug or not that debuginfo is missing for these, but maybe the script should exclude OCaml-generated programs (somehow). Fine, thanks. I modified the script to skip OCaml-generated packages. There seem to be no reasonable way to correctly detect OCaml-generated _binaries_. Karel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bugs in debuginfo packages
Ben Boeckel wrote: Anything with ghc-* can be ignored; ghc does not have debuginfo in its libraries. A list of other Haskell packages which don't fit the ghc-* pattern can be gathered as well. Ok, I modified the script to skip Haskell packages. The list is not needed, a simple detection logic seems to work fine. Karel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bugs in debuginfo packages
On 24.2.2011 at 16:17, Michael Schwendt wrote: On Thu, 24 Feb 2011 09:28:10 +0100, Karel wrote: - debuginfo symlink points to another binary in another RPM package which might not be installed Which is perfectly normal for subpackages, isn't it? There is only a single -debuginfo package for a src.rpm, but the src.rpm may build multiple [sometimes optional] packages. Michael, it means something else. I'll try to explain it on an example from the report: component: Inventor file: InventorXt-2.1.5-40.fc15.i686/usr/bin/SceneViewer - debuginfo symlink points to another binary in another RPM package which might not be installed: Inventor-demos-2.1.5-40.fc15.i686/usr/lib/Inventor/SceneViewer This comes from the Inventor SRPM, which contains many subpackages: Inventor, InventorXt, Inventor-devel, InventorXt-devel, Inventor-demos etc. Debugging symbols for every binary from every subpackage are stored in Inventor-debuginfo subpackage. So lets examine the /usr/lib/Inventor/SceneViewer binary from the Inventor-demos package. Get the build id: $ eu-readelf --notes /usr/lib/Inventor/SceneViewer | grep Build\ ID Build ID: 9b7a4aef2abc047b7b34b24eced50374d5d16bcd Now let's check the debuginfo symlink which corresponds to this build id: $ ls -l /usr/lib/debug/.build-id/9b/7a4aef2abc047b7b34b24eced50374d5d16bcd lrwxrwxrwx 1 root root 29 24. úno 16.37 /usr/lib/debug/.build-id/9b/7a4aef2abc047b7b34b24eced50374d5d16bcd - ../../../Inventor/SceneViewer So you can see the symlink points to our binary, /usr/lib/Inventor/SceneViewer. When GDB analyzes a coredump, it knows the build id and it needs to read data from the binary. So GDB follows the symlink and gets the binary. Great. Now lets examine the /usr/bin/SceneViewer binary from the InventorXt package. Get the build id: $ eu-readelf --notes /usr/bin/SceneViewer | grep Build\ ID Build ID: 9b7a4aef2abc047b7b34b24eced50374d5d16bcd The build id is the same as for /usr/lib/Inventor/SceneViewer. So the same binary is packaged twice, in two separate packages. The debuginfo symlink points to /usr/lib/Inventor/SceneViewer, even when a crash of /usr/bin/SceneViewer is analyzed. This is ok when /usr/lib/Inventor/SceneViewer is present in the system. This error message says that it is possible that /usr/lib/Inventor/SceneViewer is not present on a system where /usr/bin/SceneViewer is present. In other words, you can use InventorXt package without having Inventor-demos installed. And when you do _not_ have Inventor-demos installed, /usr/bin/SceneViewer crashes, and GDB analyzes a coredump, it checks /usr/lib/debug/.build-id/9b/7a4aef2abc047b7b34b24eced50374d5d16bcd and tries to read /usr/lib/Inventor/SceneViewer which is _not_ available. So GDB fails to find the binary. As I mentioned in the find-missing-debuginfo script header, this issue can be solved for all packages at once in rpm-build and gdb - see rhbz#641377. Is this explanation understandable? Karel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: abrt wishlist
- Separating machine-generated content from human-generated content is valuable for the developer. The two require different mental processes to handle. I have a much stronger guarantee that the abrt bug contains facts, but I also know there's no point in asking for more information. Reading a crash report is looking at structured data and divining patterns. Reading a human's bug report is listening to a story. Left brain, right brain. Good point. ABRT has become more slanted towards machine-generated bug reports unintentionally, mostly because the user interface and report format turned out this way: the implicit assumption that everything should be reported (and reported without much effort) is present in many aspects, e.g. the red warning sign for every unreported crash, green you did good thing sign for reported ones. The idea of an application only _assisting_ user to create human-made bug reports and making it easy to append the underlying technical information is still worth pursuing. It is only a matter of changing the ABRT interface to guide users this way, and to separate this way from semi-automatic crash reporting. It aslo makes sense to allow sending mostly machine-generated, few click crash reports to some new server/service. It should be possible to combine both approaches in a single application with some UI design thinking. We can change ABRT to encourage sending computer assisted, mostly human written bug reports to Bugzilla, and to enable semi-automatic crash reporting to some new server. Two ways of reporting. Not trying to combine them together as it is done now. Karel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Dne 16.11.2010 11:04, Nicolas Mailhot napsal(a): Le Lun 15 novembre 2010 23:51, Karel Klic a écrit : Major advantage of the retrace server is that you can get a good backtraces even from unfresh coredumps. And why can't this be done with debuginfofs ? It's the same data. GDB pretty printers (written in Python) need to be in the in the same tree as GDB. They are distributed among packages, so if you want them, you need to install GDB and coredump-related packages (containing the pretty printers, in version which matches the coredump) to some directory, chroot there, and then run the GDB. Then it outputs prettified backtrace. I haven't spent too much time thinking about debuginfofs, so I do not know what would be possible if we'd work on it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Dne 12.11.2010 17:35, Kevin Fenzi napsal(a): Any other exciting work in progress that might land in F15 that people are actively working on? ABRT with retrace server support, and a retrace server instance up and running. It will improve the quality of backtraces. http://fedoraproject.org/wiki/Features/RetraceServer Design: https://fedorahosted.org/pipermail/crash-catcher/attachments/20101102/f905b572/attachment-0001.xhtml Code: http://git.fedorahosted.org/git/?p=abrt.git;a=shortlog;h=refs/heads/retrace Hopefully I'll cope with ABRT duplicates: backtrace similarity algorithm with a command line Bugzilla processing tool in F15, and a HTTP front-end (service) or Bugzilla plugin for it in F16. Karel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Dne 15.11.2010 22:13, Matthew Garrett napsal(a): On Mon, Nov 15, 2010 at 08:43:39PM +0100, Karel Klic wrote: ABRT with retrace server support, and a retrace server instance up and running. It will improve the quality of backtraces. How does the user verify that there are no passwords or other personal information in the core dump? Users only verify the resulting backtrace before sending it to Bugzilla. They need to trust the retrace server administrator when they decide to upload coredumps to the server for retracing (coredumps are kept on the server only during the retracing operation - this should be stated in a privacy policy for the server). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Dne 15.11.2010 22:31, Matthew Garrett napsal(a): On Mon, Nov 15, 2010 at 08:43:39PM +0100, Karel Klic wrote: ABRT with retrace server support, and a retrace server instance up and running. It will improve the quality of backtraces. Further, what's the licensing situation here? If I have an application that (at runtime) is a mixture of GPLed and GPL-incompatible code, does sending this coredump to a remote service count as distribution? Interesting point. I do not know. What is the scope of this question? Can GPLed and GPL-incompatible code end up in the same coredump in Fedora installation without 3rd party software installed? It could happen that a coredump from Firefox contains non-free javascript from pages that were viewed around the time of the crash, but that is a browser-specific issue. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 15, new and exciting plans
Dne 15.11.2010 23:04, Matthew Garrett napsal(a): On Mon, Nov 15, 2010 at 05:01:30PM -0500, Colin Walters wrote: On Mon, Nov 15, 2010 at 4:13 PM, Matthew Garrettmj...@srcf.ucam.org wrote: Leaving the retracing at the user's end of things means that the user at least has a choice in the matter - I'm unlikely to submit any firefox crashes if I don't have an opportunity to look at what's in the backtrace. We can make symbols available for local tracing without forcing the user to download the entirity of the debuginfo, and that would seem a more reasonable approach. http://fedoraproject.org/wiki/Features/DebuginfoFS Agreed, debuginfofs will be better for many scenarios. Major advantage of the retrace server is that you can get a good backtraces even from unfresh coredumps. GDB needs access to the binary and dynamic libraries that were installed at the time of the crash when generating a backtrace. So if there was an update yesterday that installed new versions of several packages, it can happen that the backtrace can no longer be obtained from the coredump locally (without installing the old packages somewhere else). Retrace server installs packages that were used at the time of the crash, so the backtrace can be obtained. Major disadvantages of RS are that coredump upload takes time, 3rd party packages can't be easily supported, and users must trust the administrator. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Should GnuPG 1.4.x be revived?
Hi, several users of Emacs and one user of Vim complained in rhbz#574406 [1] that they can no longer use their editor to open and edit gpg-encrypted files in Fedora 13. The reason is that GnuPG 1.4 was deprecated after Fedora 12 release, and GnuPG 2 was introduced to replace it. However, GnuPG 2 is not entirely compatible with GnuPG 1.4. I looked at GnuPG 2 and it seems that it would be very difficult to modify Emacs and Vim to support it. GnuPG 2 does not allow to enter a password using shell -- it needs entire terminal (as it uses ncurses program pinentry-curses). Text editors can use only shell to send a password to GnuPG. What about reviving GnuPG 1.4? It is maintained, secure, supported, and its integration into text editors is used extensively and works well. It can live alongside GnuPG 2. What do you think? Any idea how to solve this issue? Thanks, Karel [1] https://bugzilla.redhat.com/show_bug.cgi?id=574406 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should GnuPG 1.4.x be revived?
On 07/13/2010 05:52 PM, Toshio Kuratomi wrote: Having gpg1 and gpg2 seems reasonable to me. Note, though, that the problem is slightly more limited in scope. At least with vim, if you have an X display, gpg2 will invoke the graphical pinentry where you can enter your passphrase and go about your business. It's the same with Emacs. Plain console, remote sessions that are not allowed to send the graphical window back to the local session, and systems that don't have the graphical pinentry programs installed will all experience this problem, though. Yes, exactly. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Licensing Guidelines Update - Please Read
On 07/07/2010 10:29 PM, Tom spot Callaway wrote: [kklic] emacs: 1:emacs-common-23.2-5.fc14.x86_64 1:emacs-el-23.2-5.fc14.x86_64 Fixed in rawhide. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT duplicate detection - is it for real?
Hi Christoph, there was a flaw in the duplicate detection (undiscovered for a long time) that allowed to file that duplicates you received. It has been fixed. abrt.spec: * Mon May 03 2010 Karel Klic kk...@redhat.com 1.0.9-2 - fixed crash function detection (a part of duplication detection) Karel Dne 13.5.2010 14:55, Christoph Wickert napsal(a): I'm getting the same bug reports over and over again, for example https://bugzilla.redhat.com/show_bug.cgi?id=542393 Shouldn't ABRT catch the duplicates? AFAIK abrt recognizes dupes based on hashes of the backtrace, but the format of the backtraces has changed with nearly every new ABRT version, so the backtraces will not be the same even from exactly the same crash. How to deal with that problem? And what about more complicated cases, for example a backtrace where the commandline is different as in /usr/bin/program /home/user/some.file. As user and filename change, the hash cannot be the same. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT duplicate detection - is it for real?
Dne 13.5.2010 14:55, Christoph Wickert napsal(a): AFAIK abrt recognizes dupes based on hashes of the backtrace, but the format of the backtraces has changed with nearly every new ABRT version, so the backtraces will not be the same even from exactly the same crash. The hash is not calculated from the whole backtrace, but from simplified version of it. In the case of gwget (https://bugzilla.redhat.com/attachment.cgi?id=374581), the input for hash calculation looks this way: $ abrt-backtrace ./backtrace -n -d 4 -r -m Thread node_get_last get_sequence IA__g_sequence_iter_get_sequence IA__gtk_list_store_set_valist Only names from the top few frames are used. How to deal with that problem? And what about more complicated cases, for example a backtrace where the commandline is different as in /usr/bin/program /home/user/some.file. As user and filename change, the hash cannot be the same. The command line is not a part of the hash calculation. AFAIK only the backtrace, package name, and a part of package version is. Karel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Can I have some documentation examples excluded from Abrt crash collection?
Hi Jeff, Good idea, also the opencv package would use this feature for its Python programming examples. Current ABRT cannot ignore crashes based on paths, so it must be developed. Please file a RFE in Bugzilla, and include the filename mask(s) marking the files you want to exclude. I think it will be something like: /usr/lib/python2.6/site-packages/scipy/*/examples/*.py IMHO for the beginning it is right to have even package-specific configuration (like the excluded paths) in ABRT. Later this kind of configuration should move to the packages, as ABRT configuration files and feature set become more mature and stable. Karel Jeff Spaleta wrote: So I'm maintaining matplotlib and scipy.. which effectively allows scientists to pretend they are programmers So matplotlib includes a large selection of examples to read over as documentation. Some of these example do some crazy complicated things which make use of matplotlib and wont work out of the box because they need additional python modules that are strictly related to matplotlib functionality...examples on how to embed matplotlib pythonically and other such things. I would really like it if abrt could be prevented from triggering bug tickets when these examples crash. The examples are deliberately provided as documentation of examples of things you can do with matplotlib...but not as code meant to function without additional thought on part of the user. Can I work with someone with regard to abrt to get these things excluded? -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Can I have some documentation examples excluded from Abrt crash collection?
Dne 14.4.2010 22:40, Jeff Spaleta napsal(a): On Wed, Apr 14, 2010 at 11:53 AM, Karel Klickk...@redhat.com wrote: Please file a RFE in Bugzilla, and include the filename mask(s) marking the files you want to exclude. I think it will be something like: /usr/lib/python2.6/site-packages/scipy/*/examples/*.py do you want that in Fedora bugzilla against abrt package or in the upstream abrt fedorahosted trac system? Fedora Bugzilla Thank you for filling it. K. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Can I have some documentation examples excluded from Abrt crash collection?
Dne 14.4.2010 22:02, Mathieu Bridon napsal(a): I'm not sure if that could be used for my own issues with ABRT, but let me explain it. When I'm developing a TG2 application, I sometimes get a traceback (well, I'm not perfect :). ABRT sees the traceback, and wants me to report a bug against Paster. However, the bug is not in Paster, it's in my own code, and I know it since I'm currently developing it (Paster is used to launch TG2 applications). Would it be possible to ignore this kind of tracebacks while not ignoring legit Paster issues? Yes, that should be possible after some more programming is done. To me it seems we will end up with package-specific semi-scriptable configuration in ABRT. It would read the (parsed) traceback of a crash and determine what to do with it, depending on its contents, on the origin of functions etc. Then we will also be able to ignore those plentiful Firefox crashes in proprietary plugins. In other words: please file a RFE against ABRT so your request is not forgotten, as it's perfectly valid. Karel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: What is the future of logwatch?
Hi Yaakov, please see below. On 03/16/2010 10:31 PM, Yaakov Nemoy wrote: Hey List, In the org that i work for, we use logwatch for log monitoring. Since puppet is too new to have a module in logwatch, i've had the 'joy' recently of attempting to write a functional module. In doing so, i have a number of issues i would like to bring up about logwatch in Fedora (and RHEL/CentOS). To begin with, like a good netizen, i sent a message to the mailing list upstream. So far i've heard no reply. There's the chance that it got caught in my spam filter, but i've gotten one message from the ML already. It feels like upstream is dead. There has also been no release since 2007. Since it still 'just works' i won't bring out the fire and brimstone and demand it be removed, but i would like to know, how are we going to support this? Yes, the upstream is almost dead. Nevertheless I believe if someone (anyone) starts to be active on their mailing list, it will make things move again in a good direction. If it does not, it makes sense to do a fork, because a _lot_ of people use the package, send patches, and improve logwatch in a long run. I have had this in my todo list since 5 months or so, even promising it to a colleague of mine that time. Unfortunately there are still things with higher priority to be done. If you can help and devote some time to logwatch, then we should cooperate. This question is important in the context of the issues i had programming for logwatch. A well programmed tool maintains orthogonal features in an orthogonal way. I ran into some serious bugs while trying to develop a robust module. Logwatch has two modes, one for a machine with a single set of logs, and one for generating reports for a machine with multiple logs, namely your centralised logging box. The snippets of code that filter the logs you want to analyse allow you to control for the date range and the machine the logged event was generated on. When trying to code for the puppet logs, my code ultimately only worked on the single nodes, but crapped out on our logging box. After debugging the issue, it's obvious that it's doing some prefiltering per host that is occluding all the puppet logs, when the 'splithosts' feature is enabled. Extending and maintaining this package is going to be difficult without a willing maintainer. If this is just something that needs a bug report, i would appreciate if the package maintainer, according to zodbot Karel Klíč, could speak up on this. Extending and maintaining a package are two different things. I believe that discussing some programming issues and source code design is out of scope for Fedora maintainer role. It would be too much work to do it for every package. If no one is willing to maintain logwatch, i would like to ask why is it enabled by default? For most environments, logwatch is ignored/disabled in lieu of other solutions.People who use logwatch seriously are already aware of its presence and will enable it when disabled. They are also generaly experts, and from my experience been around the sysadmin block quite a few times. For the non-expert user, discussions of target audience aside, either they know about logwatch, and perhaps keep an eye on it, or will never find it. I refer to the fact that the only way to know about logwatch on a running system is that innocous you've got mail in /var/spool/mail/root' message. Then you have to know to open up your mbox, which in my case means installing mutt which is not installed by default, and read it, and then know it's logwatch, and realize what it's there for. There are 'expert tips' i've seen that remind newbs to check logwatch on their own machines, but if this is something important, it should be more obvious, and if it's not so important, why is it enabled by default? Is it really enabled by default on Fedora? It should not be enabled in a desktop spin, and Fedora currently has no server spin. If logwatch is installed and enabled on some spin one day, this should be documented in the deployment guide, so inexperienced users can read about the presence of logwatch, and how to use it. I am willing to write something if others feel it's necessary. I'm not going to bike shed, so i'm not going to ask for any particular action. We don't have the time in our organisation to take up maintenance of logwatch, so we clearly are going to look for another solution. Still, i would like to ask the persons who made the decision to enable this by default, is it still relevant? Or is it something that's in danger of becoming cruft? Am i missing a certain perspective on why it's enabled by default? -Yaakov Best regards, Karel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gdbm soname change in Rawhide, package rebuild needed
A newer version of gdbm (1.8.0-1.8.3) has been pushed into rawhide (devel) branch. This version changes libgdbm soname, so all packages using gdbm _must be rebuilt_. The soname change is needed as the new version moves dbm and ndbm routines to separate library gdbm_compat. The new version fixes a memory leak. I also added some fixes from Debian preventing uninitialized memory contents to be stored in databases and fixing potential database read failures. Affected packages: (maintainers are CCed) am-utils avahi clisp compat-python24 freeradius fsvs gauche gnu-smalltalk jpilot-backup lighttpd Macaulay2 maildrop mt-daapd ntop ocaml OpenIPMI parrot perl perl-eperl perl-XML-LibXSLT pulseaudio python q qfaxreader qsf ruby snobol tcl-thread vacation Thanks. Best regards, Karel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT unusable again
On 02/08/2010 06:11 PM, Karel Klic wrote: On 02/08/2010 02:22 AM, Christoph Wickert wrote: Am Sonntag, den 07.02.2010, 22:26 +0100 schrieb Karel Klic: IMO all lists should be sorted by package owner. I own ~ 120 packages and it is a quite lot of work to search all these packages in your lists. I'll try to do it. Both lists are now sorted by package owner: https://fedoraproject.org/wiki/User:Kklic/ABRT_Duplicates https://fedoraproject.org/wiki/User:Kklic/ABRT_Incomplete_Backtraces -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT unusable again
On 02/08/2010 02:22 AM, Christoph Wickert wrote: Am Sonntag, den 07.02.2010, 22:26 +0100 schrieb Karel Klic: I placed the list of found bugs to the Fedora wiki [2]. IMHO only bugs with 2 comments should be closed, because 2 comments mean that the package maintainer did not touch the bug (ABRT adds 2 comments to every bug it creates). We can close 129 bugs this way. This means that the active maintainers, who responded to their reports and asked for more info will have no benefit from the script and the ones who ignored the abrt reports did right. Isn't it ironic? Yes, that is unfortunate. However, it is not polite to close a bug in the middle of some discussion. I can go through the remaining 80 bugs and close some of them manually. [1] https://fedorahosted.org/abrt/browser/src/Backtrace/abrt-bz-dupchecker Its 551 bugs that can be closed as duplicates, not 900. I placed the list of affected bugs to the Fedora wiki [3]. IMO all lists should be sorted by package owner. I own ~ 120 packages and it is a quite lot of work to search all these packages in your lists. I'll try to do it. Karel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT unusable again
Karel Klic wrote: Christoph Wickert wrote: For me as the maintainer it is a lot of work to reply to all these useless reports and for our users it's just frustrating if all their reports get closed INSUFFICIENT_DATA. I am now going to write a script which detects all the backtraces without debuginfo in Bugzilla, and closes the bugs as INSUFFICIENT_DATA with an apology. I do not know how many of them are in Bugzilla, but those can be detected and closed automatically (more info soon, it should be hacked together quickly). The script to find backtraces without debuginfo has been written[1]. I placed the list of found bugs to the Fedora wiki [2]. IMHO only bugs with 2 comments should be closed, because 2 comments mean that the package maintainer did not touch the bug (ABRT adds 2 comments to every bug it creates). We can close 129 bugs this way. Also a script [1] which finds all the duplicate backtraces (we can find) in Bugzilla has been written. Those duplicates were made by older ABRT versions without good duplicate detection. ~900 bugs can be closed with this script. Hopefully it removes some burden from package maintainers. [1] https://fedorahosted.org/abrt/browser/src/Backtrace/abrt-bz-dupchecker Its 551 bugs that can be closed as duplicates, not 900. I placed the list of affected bugs to the Fedora wiki [3]. So I'd like to close over 600 bugs in Bugzilla using scripts. Is there some Fedora policy regulating this? [1] https://fedorahosted.org/abrt/browser/scripts/abrt-bz-ratingfixer [2] https://fedoraproject.org/wiki/User:Kklic/ABRT_Incomplete_Backtraces [3] https://fedoraproject.org/wiki/User:Kklic/ABRT_Duplicates Best Regards, Karel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT unusable again
Christoph Wickert wrote: What's wrong with ABRT? ALl the backtraces I get are unusable again. If Thunar crashes, not even Thunar-debuginfo gets installed. There is a flaw in ABRT 1.0.4, which allows to submit incomplete backtraces. It got into the source code during the GUI rewrite. There is abrt-1.0.6 in Fedora 12 testing repository, which contains a fix for this issue. abrt 1.0 worked here, then came 1.0.2 which was broken. 1.0.3 was working again, but got superseded be 1.0.4 only a few of days later. This means that most of the time, all the bugs submitted are basically useless. It became better with later releases, but the bug you described made it bad again (for this release). As far as I can tell, the last large-scale change (the new GUI) was finished in 1.0.4. It introduced some bugs, but those are fixed now. A lot of people complained about the old GUI, so it seemed to us (the ABRT team) that the GUI overhaul was mandatory. Well, some people complain about the current GUI, but IMHO its better. The latest version (1.0.6) contains mostly bug fixes, so it should not break things, it should make ABRT reports sane again. For me as the maintainer it is a lot of work to reply to all these useless reports and for our users it's just frustrating if all their reports get closed INSUFFICIENT_DATA. IMHO it's not so frustrating for users, as it is frustrating for some maintainers. Users want to help by reporting crashes, but it doesn't make you sad when the crash you just reported was not useful at the end (you invested a few clicks in reporting that crash). ABRT hurt some maintainers in Fedora 12. I believe the following Fedora releases will benefit from ABRT, as the crashes in the bleeding edge software introduced in every release will be quickly detected and fixed. I am now going to write a script which detects all the backtraces without debuginfo in Bugzilla, and closes the bugs as INSUFFICIENT_DATA with an apology. I do not know how many of them are in Bugzilla, but those can be detected and closed automatically (more info soon, it should be hacked together quickly). If the situation doesn't change any time soon, we IMHO should consider disabling abrt until the issues are fixed. Please consider testing and adding +1 karma to ABRT 1.0.6 in Bodhi. Also a script [1] which finds all the duplicate backtraces (we can find) in Bugzilla has been written. Those duplicates were made by older ABRT versions without good duplicate detection. ~900 bugs can be closed with this script. Hopefully it removes some burden from package maintainers. [1] https://fedorahosted.org/abrt/browser/src/Backtrace/abrt-bz-dupchecker Best Regards, Karel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ABRT unusable again
Kevin Kofler wrote: Stefan Schulze Frielinghaus wrote: However, in the meantime I stopped reporting crashes via ABRT because I think it raises the load for a package maintainer to high while the report should go directly to upstream. Bothering the maintainer first instead of upstream is not the right thing to do. +1, in fact that's the biggest design failure in ABRT (in its current state) and basically makes it useless. Gathering backtraces is something that needs to be handled by upstream projects (like KDE does with KCrash/DrKonqi), not distributions. Some maintainers fix crashes in their packages and then send the fixes to the upstream, and some don't. Some crashes are caused by distribution-specific environment, and some are not :) It's not clear whether we should report crashes directly to the upstream. For some packages, reporting upstream could work well (Firefox, OpenOffice.org come to my mind). However, many packages have unresponsive/dead upstream, upstream without issue tracker etc. See rhbz#532307 for a beautiful example of cross-package bugfixing, which is very hard to do in upstream. At least eight applications will be fixed at the end (e.g. #542277, #547030, #550165, #558329, #561592, #561059) Karel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
