Re: abrt + X Error = zillions of duplicate bug reports?
On Tuesday 24 November 2009 22:49:53 Matěj Cepl wrote:
Dne 24.11.2009 22:37, Adam Williamson napsal(a):
We came up with several possible courses of action. First, we
acknowledge that abrt team is working on improving duplicate detection,
but Matej noted that this is intrinsically hard work and abrt will
likely never be able to eliminate or even come close to eliminating
duplicate reporting.
What's the technical limitation to coming close here? It seems likely
that there will be some edge cases, but I would think that the majority
of cases aren't all that exceptional, and are fundamentally
straightforward to work out.
Don't ask me, I am just a humble bug triager (putting abrt developer on
CC of this message). What I can say is that even though I can see abrt
devs work hard to eliminate duplicates, they don't succeed much.
Apparently eliminating duplicates of bugs from beasts like Firefox or
OpenOffice is excessively hard.
Afaik, there are several projects with some crash/exception handling on top of
the stack. This makes it more difficult to find out where something actually
crashed. I think solution to this is more plugins/individual configurations.
Something like /etc/abrt/conf.d/package_name.conf
with package_name.conf content something like this (of course with better
format ;) :
refuseif()
{
IF backtrace contains adobe flash THEN RefuseReporting(This crash is caused
by proprietary blob, we can't fix it. Try to contact adobe);
ELSE IF
return OK;
}
cropbacktrace()
{
remove packagename's crash handler from top of the backtrace
}
And abrt will call these methods if they are defined.
Just my 2 cents
Michal
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fwd: Request to update ATi OSS driver for Fedora 12
On Wednesday 21 October 2009 23:27:31 Adam Williamson wrote: On Wed, 2009-10-21 at 15:16 +0800, Liang Suilong wrote: Today I upgrade my Fedora to Fedora 12 Beta, It looks very well. But I found ATi display driver does not run well. My display card is Sapphire HD3650 with 256MB GDDR3 VRAM (RV635). I choose OSS driver for my card. Glxgears runs so smoothly with xorg-x11-drv-ati because of KMS by default, nevertheless, rolling up and down in the gnome-terminal is quite slow. The performance of glxgears is about 210 frams per second. In addition, Switching to another window in Fedora 12 Beta is not as fast in Fedora 11. Later, I install xorg-x11-drv-radeonhd and set it by default in the system-config-display. Then I restart the X. I can not log into gnome. The screen turns white. I found xorg-x11-drv-radeonhd is too old, The version is 1.2.5 in the rawhide and the latest version 1.3.0 has been released for a long time. Now I turn back to xorg-x11-drv-ati. At last, I do not know which packages causes the problem, maybe xorg-x11-drv-ati, maybe xorg-x11-drv-radeonhd, maybe Mesa. So I suggest that packager updates some packge related to ATi R600/R700 display card. Fedora doesn't really care about the radeonhd driver. We may well even remove it at some point soon. The ati driver is the one you should use on Fedora, that's why it's the default. You do not get 3D acceleration out of the box on that card, r600 3D acceleration is too early to be enabled by default. If you want to try it out, install the mesa-dri-drivers-experimental package. For the slow 2D performance - _how_ slow is it, really? gnome-terminal has never been much of a speed demon. Does it get any faster if you boot with 'nomodeset' as a kernel parameter? Hi, I've installed F-12 beta on my new laptop with ati radeon hd 4570 graphic card, I was going to file new bug. With kms enabled, everything is really slw, with 'nomodeset' it's much faster. I can't say exactly how slow it is, is there anything I can use for measuring? Michal btw, mesa-dri-drivers-experimental does not work at all for me (glx apps segfault) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
does fedora have anything requiring :mail rw access?
Hi all! I've got quite simple question from dovecot's upstream: Why do we have rw access on mails for mail group? Why /var/mail/username files have 0660 username:mail permissions instead of 0600 permissions? The fact is, I don't know the answer and I'd appreciate your help. Some facts: distro | group | perm -+---+- Fedora | mail | 0660 Ubuntu | mail | 0600 openSuSE | users | 0600 (user is member of users group) debian 4.0 | mail | 0660 (Note: This is result of my own investigations on installed systems or livecds, I don't know if any installed system had changed settings.) Interesting thing is, that when new user is added to the system, useradd creates /var/mail/username file with username:mail 0660 permissions, but when you delete this file and the user gets new email, this file will be autocreated with 0600 permissions (still username:group owned) and it seems everything still works. useradd command comes from shadow-utils and fedora contains no patch changing permissions to 0660. The most important question is: Is there anything that requires these files can be read and written by mail group? If you have any info regarding this, please share. Thanks, Michal Hlavinka -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: does fedora have anything requiring :mail rw access?
On Friday 09 October 2009 15:31:45 Michal Hlavinka wrote: The most important question is: Is there anything that requires these files can be read and written by mail group? Well, I already know one, cyrus-imapd most probably requires mail rw. Is there anything else? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
This reminds me your note: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519.htm l PA does not make use of hardware mixing. And I don't plan to change that. It's obsolete technology. CPUs these days come with extensions such as MMX or SSE precisely for speeding up DSP tasks such as PCM mixing. This is way more flexible that hw mixing, and definitely the way to the future, both on the desktop and on embedded envs as well. The obsolete technology -- who made this decision? Is it your private opinion or any suggestion from sound card manufacturers? It seems that HW companies still produce the obsolete technology. First, I like pulseaudio, especially the ability of moving streams from one sink to another is awesome for laptops with external sound card :o) But imo hw mixer (or other hw parts) are not that bad... we still have hw accelerated graphic, math,... why not sound? Also this remains me that pulseaudio eats 24 % of my (1.6GHz) cpu when mapping stereo stream to 5.1 which (I suppose) some hw mixer could do while letting cpu free for other tasks. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [ANNOUNCE] New Mixer Handling in PA 0.9.16/F12
On Wednesday 29 July 2009 15:16:20 Lennart Poettering wrote: On Wed, 29.07.09 12:33, Michal Hlavinka (mhlav...@redhat.com) wrote: This reminds me your note: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-July/004519 .htm l PA does not make use of hardware mixing. And I don't plan to change that. It's obsolete technology. CPUs these days come with extensions such as MMX or SSE precisely for speeding up DSP tasks such as PCM mixing. This is way more flexible that hw mixing, and definitely the way to the future, both on the desktop and on embedded envs as well. The obsolete technology -- who made this decision? Is it your private opinion or any suggestion from sound card manufacturers? It seems that HW companies still produce the obsolete technology. First, I like pulseaudio, especially the ability of moving streams from one sink to another is awesome for laptops with external sound card :o) But imo hw mixer (or other hw parts) are not that bad... we still have hw accelerated graphic, math,... why not sound? Also this remains me that pulseaudio eats 24 % of my (1.6GHz) cpu when mapping stereo stream to 5.1 which (I suppose) some hw mixer could do while letting cpu free for other tasks. If PA eats a lot of CPU this can have many reasons, most of them have to do with the latency settings requested by the applications or that have been configured due to frequent underruns. However the actual mixing is certainly the smallest part of it. Plese don't forget that mixing is not exactly the most complex operation on earth. Well... I'm pretty sure I have no idea how it works :D I've just noticed that when playing stereo and sound card (Aureon MK II) is configured for stereo, it eats about 4 % and (when speakers are set as 5.1) only front speakers work (as expected), when I configure that card for 5.1 output and play stereo stream it goes to all 5.1 speakers and eats about 24 % of cpu -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: $HOME/bin
Paul W. Frields wrote: On Mon, Jul 13, 2009 at 02:08:55PM +0200, Ondřej Vašík wrote: Stefan Assmann wrote: Hi all, I was wondering why there's no $HOME/bin directory and $HOME/bin not mentioned in the $PATH variable. Any particular reason not to have that by default? $HOME/bin is not on every system and the other default directories in default PATH are(at least on the most of systems ;) ). However, some Linux distros do add something as: # set PATH so it includes user's private bin if it exists if [ -d $HOME/bin ] ; then PATH=$HOME/bin:$PATH fi as default - so this dir gets added automatically when does exist. I'm generally +1 for changing the default that way - as it would not change anything for users without that directory. I would only want this at the *end* of the current PATH, not the beginning, for obvious security reasons. 1. Your practice to a wide extend defeats one prime rationale for ~/bin: Replacing/Overriding vendor-provided applications by per-user installed versions. 2. Unless using ~/bin as root, these files are user-installed binaries, which under normal circumstances may only have security impacts on user files = What you call obvious security reasons are minor concerns. if su (instead of su -) is used, root will inherit user's environment including PATH. The only real issue you are solving by appending ~/bin instead of prepending ~/bin to $PATH is avoiding application-name conflicts. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: delaying an update
On Wednesday 08 July 2009 16:30:56 Michael Cronenworth wrote: Christoph Höger on 07/08/2009 09:21 AM wrote: how do I do that? I guess you can use Delete/Unpush/Revoke request or something like that in bodhi web interface. Since you have not submitted it for stable I do not see any problem. Don't do anything. :) I disagree. There are several users using packages from updates-testing. Letting them update to a package you know is broken is bad. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Suggestion re FESCO Ticket #170
On Monday 29 June 2009 12:48:11 David wrote: Re the discussion at https://www.redhat.com/archives/fedora-devel-list/2009-June/msg01991.html The below suggestion tries to satisfy all parties: - it presents a neutral default - it presents a simple choice for newbie who doesnt know what a desktop is - it shows the range of what is available - it allows a specific choice Design suggestion for the Fedora download page (http://fedoraproject.org/en/get-fedora): FEDORA LIVE CD Do you require a specific desktop ? [ * ] I don't care [ ] Fedora Live with GNOME [ ] Fedora Live with KDE [ ] Fedora Live with LXDE [ ] Fedora Live with XFCE etc The I don't care just links to whichever desktop is currently the default. Implementation of this logic doesn't require radio buttons. Just 2 links: 1) click here for default 2) or click here to choose (go to a selection menu) Clicking link #1 gets you the default. Or clicking link #2 takes you to a menu of links, one for each available choice. Fedora policy specifies which desktop the user gets if they click the default. But the above user interface design is independent of whichever one is the default. small improvement: FEDORA LIVE CD Do you require a specific desktop ? [ * ] Fedora Live with GNOME (default) [ ] Fedora Live with KDE [ ] Fedora Live with LXDE [ ] Fedora Live with XFCE etc it's better than I don't care and it suggests what to use if you really don't care :) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Hello, I don't want to start a long thread, but just to ask a couple questions for my own clarification. Does a maintainer's responsibilities end with packaging bugs? IOW, if there is a problem in the package that is _broken code_ do they need to do something about it or is it acceptable for them to close the bug and say talk to upstream? Do we want those bugs open to track when the bug is fixed in the distro? I'll accept whatever the answer is, I'm just curious. I think it depends on what type of users we want. If we want only skilled users (programmers) we can close most bugs upstream. But this is not a good way if we want also less skilled users (and bug reports from them). There are tons of packages in fedora, most of them have own upstream. For every package you need usually some kind of bugzilla registration (or mailing list subscription), which is (at least) a little bit odd - expecting users are willing to have so many subscriptions/registrations. The second problem are less skilled users. What if upstream answers: ok, thanks for bug report, please try this patch... or I've fixed it in repo, please try svn snapshot, if it's fixed for you? We can't expect all users are skilled for this. Michal -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 11 Test Day survey
1. How did you find out about Fedora Test Days? fedora-devel-list 2. Was sufficient documentation available to help you participate in a Fedora Test Day? If not, what did you find missing or in need of improvement? mostly, see examples: good: Test Day:2009-03-26 Nouveau /sbin/lspci -d 10de: | grep -iq VGA echo Join Nouveau Fedora Test Day || echo No nVidia graphics hardware found. bad: Test Day:2009-04-09 UEFI FIXME|How to identify if your system supports UEFI? This text was there for some time and than it just disappeared without any answer. 3. Did you encounter any obstacles preventing participation in Fedora test Days? How might they have been avoided? Did you discover any workaround? let's have live cd for all test days (where it makes sense) 4. Were you able to locate and download installation media for testing? Did it function as expected? yes 5. What follow-up actions do you expect after the Test Day? Are your expectations currently being met? imo it's ok now 6. Would you participate again in future Fedora Test Days? yes 7. Do you have any more general comments or any suggestions for improving future test days? start them earlier in rawhide development phase. If tens of bugs are found three weeks before freeze, we can hardly expect they are fixed in time. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
What if upstream answers: ok, thanks for bug report, please try this patch... or I've fixed it in repo, please try svn snapshot, if it's fixed for you? In that case we can roll a fixed package (e.g. as a scratch build). (If upstream says try a current snapshot, it should be fixed, I'll usually try to find the actual commit and, if I don't find it, ask can you please point me to the commit that fixed it so we can backport it?. But for some packages, just upgrading to the newer snapshot is the better solution.) But until that happens, there's no reason for the packager to be involved. Yes, but how will you notice reporter needs (your) help if bug is closed upstream? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora Bugzilla Statistics 2009-05-26 - 2009-06-01
There is much more information that can be pulled via a turbogrears app we are running. But I am looking to see what is useful in terms of a weekly report. I have the date tuesday to tuesday as it matches up with the Bugzappers meeting time. Hi, thanks for the stats. I'd like to see there additional stats for fedora 9, 10, rawhide: - overall number of opened bugs - number of new bugs in last x days - number of closed bugs in last x days Would it be possible? Michal -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
