* Please do not file a Gentoo bug and instead report the above QA * issues directly to the upstream developers of this software. * Homepage: 'somehost' This sentence should not be here. QA should track all issues here and be linked to the upstream bug where possible. In some cases security may well decide to mask a package for found issues. If they are not developers tend to close WONTFIX for this see bug#337943 for an example. Reproducible: Always Expected Results: Gentoo should track all QA issues
I'm opening this bug and CC'ing QA and portage so that they can get you some feedback. That message is issued directly by Portage for QA issues in the package code. Do we have / Should we have a policy on how to deal with these bugs?
Not all of them are going to be handled through us. Some (fortify; maintainer mode; ldflags) definitely have to. Others should probably (implicit declarations). Other might actually not be something we can deal with feasibly (strict aliasing).
The issue here for me is TRACKING so that progress in determining status of the package in the tree can be controlled. It would be unreasonable for us to deal with/fix all issues. But current policy should not allow closing such bugs WONTFIX at the least This could allow possible 'bad software' in the tree and on users systems.
I do not think is it right to make users contact upstream by themselves. imho, maintainers are supposed to do that. Furthermore, if maintainers decide to commit packages with such QA notices, they should also report them to upstream too. These notices are not fatal, yet the warning is there. We should not poke users to deal with such stuff. Since it would be impossible to make QA warnings fatal, I would prefer to "fix" the message to state that the correct place to report such problems is gentoo bugzilla. Then maintainers will be responsible on how to deal with them
bug reports are being closed for strict-aliasing as RESO_UPSTREAM or as dups without an upstream report AFAI can tell. bugs 347754, 347731,347812, 347807,347818,347727,347738 citing the "do not report to Gentoo but instead report to upstream" implicit declarations closed for upstream 347737
strict aliasing violations often result in random runtime misbehavior. those shouldnt be simply closed as UPSTREAM. CC qa@g.o on the bugs in question.
347763 "the address of $some-variable will always evaluate as 'true' In another like this Diego closed as WONTFIX this will always be this way or should be done on a case by case basis? His statement was it is a macro iirc
honestly, simply copying & pasting QA logs into our bugzilla isnt terribly useful. what would be useful is actually going through and fixing said bugs. especially the upstream bugzilla/mailing list.
honestly it would be nice to have the skills to fix them all and the time. As is I have submitted patches for two of them and tested both they applied fine and were a simple matter of includes. What kind of testing does the maintainer do? This should be a standard practice before allowing the software in the tree. bug # 347817 and bug #347899 One of these bugs was closed and it (ghostscript-gpl) is also missing includes I am trying to get to that one. This is an emerge -e world on a running desktop computer. If Diego's tinderbox was running you would be recieving these for the whole portage tree. so far I've submitted close to 30+ I'm guessing many still open. That is only the system set. I haven't done much more than peek at the world merge. So ...I guess I can just add -fno-strict-aliasing to cflags. fix headers were I can and uninstall anything with arrays out of bounds. Might as well remove the QA flag while your at it.
BTW system was just around 228 packages and worlds is close to 900 I work with my hands running a building for a living I do all the refrigeration A/C , ice machines water fountains in a large arena. We hold a major college ncaa schools basketball and I have a family. You keep them open please. These packages are in your tree and on my system. Obviously the maintainers are not using this software....or testing it. Those who are will be happy to help I'll close them myself UPSTREAM when the report is done. If they don't first. But I should not even be seeing these missing includes.
One other additional piece of information for you I've spent the last year helping to make improvements to Autotools Mythbuster in my spare time. The way I looked at it, it was the way I could make the most impact on improving Gentoo since I use it.
bug #344073 added patch for missing includes there as well builds fine log attached.
Let's try some reasoned suggestions since no one has closed yet. I want to apologize to anyone I may have offended. I realize none of you guys are paid for your Gentoo development work either.and so some of my comments are irrelevant. I realize most of the issue does not center around not wanting to fix things. After settling down and thinking it over I see several issues causing the conflict. 1) Gentoo devs are overworked and under-appreciated. I do thank all of you guys for the time you invest. 2) These bugs are valid and are in the portage tree. If we extrapolate 20-30 bugs of this type from a system set of packages: Total: 265 packages (265 reinstalls), Size of downloads: 0 kB the number of bugs in the tree itself is approximately? I have only a gnome desktop mainly: 850 reinstalls), Size of downloads: 0 kB Number of bugs in the portage tree? .Flameeyes tinder box run could begin any day now will you treat his bugs this way? I speculate that he has sufficient negative feedback from certain developers over the QA issue and hence the message. 3) a concise bug reporting guide doesn't really exist. http://www.gentoo.org/doc/en/bugzilla-howto.xml You users bug reports could be a lot better and more informative. This document should begin with 1. Searching Using Bugzilla Let's not waste our users time dealing with crap already covered. Any more than you want to see dups. Check here first. Then check upstream. If there is a fix upstream report it and the error and emerge --info package-name and build log as an attachment. Note the size and need to compress some logs. Point out the bug is fixed upstream in your Gentoo bug report. Show an example of a correct log. Walk them through the untar and creating the new filename and diff -u > name.patch (I have not actually done things this way but it makes the best use of all of our time.) Encourage users to report them upstream a you have. Just tell them they get fixed faster that way. Then start explaining how to fix bugs on your own. 4) Bug reporting is not a personal attack. However if I invest personal time into properly reporting a bug on a program that is installed via portage on my Gentoo system. I will personally tend to it. If it's as simple as a sourceforge and linking to a Gentoo bug report I can do that. As a user you do get better at it and bugzilla.gentoo.org is a nice system compared to some. But I am offended by people closing the bug report without doing the dirty work. If I file it. I will do what I can to push the report upstream and you should expect users to as well. Devs should step in if upstream is difficult to reach. the link should actually be to the upstream bug report system. Not the software's homepage. 5) I submit the portage tree is too large for the number of developers we currently have. Trimming it of crappy, unmaintained code is not a bad thing. It could be a badge of honor to be in the portage tree. If we allow real QA to make it so. This is where I'm at so far. Are users and devs a team? I cannot say it feels that way. If you are not interested in the quality of the software you use then I wonder do you really use it? What motivates someone to close a real bug that could conceivably have security implications or cause random crashes? Do these not end up as runtime errors and that could be exploited or crash on the user? Are these issues really insignificant enough to be treated thus? I do care about what I install on my system.
First, thanks for the pointer to this on bug 347807. There are few different things to consider. First, I'm with Markos, users should not be being asked to do this. It should be falling to the maintainers. And more importantly, most of these kinds of issues should be *known* about, and submitted upstream about, prior to committing. I know I take this kind of things seriously in the packages I maintain. It's common sense, if portage is giving you QA warnings, you fix them or you submit upstream. As to handling of bugs pertaining to the "Submit Upstream" warnings, I close them once I know a bug has been filed. The simple fact is that as developers we are generally responsible with the ebuild sides of things. If there is an issue with the *build system* I usually try to fix it, and then submit the fix to the upstream folks. But many of these issues are *not* build issues. They are poor programming practices in the package itself. Despite the fact that in many cases I do know *how* to fix these kinds of things, trying to get familiar with the package enough to make the changes is time consuming and, in many cases, frustrating. (Poor programming practices usually means annoying to deal with entirely.) The simple fact is that at least I know *I* don't have time to maintain the ebuilds, help with build system issues, AND try to fix poor programming practices upstream. (And I would be willing to bet I'm not alone on that front.) It's just not practical, and candidly, I have ${x} amount of time as it is and I'd like to spend it on *my* end of the problems so to speak. So, although I 100% agree that these issues need to try to get resolved, I'm not exactly clear on what you're asking for from the developers. I don't mind so much that they get reported, however, I feel that if we remove that message we will get a major influx of the same kinds of bug reports. Now, I suppose we could leave the bug open with the link to upstreams bug report until it's fixed, but especially given the types of issues, it can be a while. The other option is to have some sort of portage option to display those messages and only have developers (or more ambitious users) enable it and trust that dev's will submit and work with upstream. (I can see some obvious problems here as well.) Beyond that, I'm not sure what to say. I thank you for the reporting, and if you have the patches etc, I will generally make sure they get added to the tree asap.
Again I emphasize that the bug reporting guide should be redone. Search first do not cover work already done Search first bugs.gentoo.org and then upstream bugs and cvs if browsable Note the issues users may encounter. A ruleset should be instituted outlining policy for dealing with categories of error As an example consider "breaks strict aliasing rules" Suggest setting these -fno-strict-aliasing and report upstream This can be done I know. See i686 and -fno-strict-aliasing imposed on http://bugs.gentoo.org/show_bug.cgi?id=347761 (glibc). If it is the concensus that array out of bounds are enough cause. Mask and notify upstream or if it's important enough have a skull session and fix it. Includes should just be fixed and upstream notified This simplifies the dev/maintainer's job since there is policy in place for dealing with the issues. I prefer "Now, I suppose we could leave the bug open with the link to upstreams bug report until it's fixed" The problem I see is that you gets lots of dups if the bug is closed and everyone reporting. And duplicate work is never good. If the bugf is open the informed user can now decide what to do. But cannot whine to dev. It's reported. so now they choose install /uninstall said software. I submit that your users are probably the most dogged, elite, concerned, and maybe largest set of script kiddies accumulated in one distro. (J/K but only a little) Empower them and use that manpower. Help us help you. Improve the bug reporting guide as in comment #13 and an index would greatly improve it as well. As always prioritize. When daunted I usually just put on the blinders and handle one task at a time. Please guys don't sit on your hands and wait for me to comment. Suggestions? There are enough of you on the CC list that we should be getting some. I don't know what to do about FORTIFY_SOURCE=0 as in wine. Perhaps the elog should just note the hazards and tell the user why it is done. as in: QA Notice FORTIFY_SOURCE=0 this software is installed use at your own risk.
bug #344073 and bug #347899 have patches and built fine. Is there a reason these patches have not been checked and applied? I need to bump these guys or am I being ignored? They did close the bug. Is there something wrong with including the standard system headers in GNU-Linux? At present I have un-installed xchat for missing includes might try irssi again I've used it before and it built properly. I don't get much conversation outside of #gentoo anyway. I have only peeked at the world merge just some configure doc related gnome stuff has been submitted. That doesn't contain the message. The mplayer and gnome-screensaver patchs came from the world set as well but most of the rest are system. Can we get the gnome upstream to accept bugs here on Gentoo's bugzilla? That's what I have here. you decide what to do about the rest ;) Or do I need to file all the gnome bugs upstream to be dealt with properly?
bug #347865 upstream report filed. that one was easy. Correcting myself in above comment bugs not yet closed with patches for missing includes. added cc media-video
We apply patches as manpower and time allows. Please do not CC us needlessly, we have already enough mails to deal with, thanks.
As concerns parts of both the freedesktop and gnome the advised link should at least point to https://bugzilla.gnome.org/ 2 open bugs both of which break strict-aliasing rules https://bugzilla.gnome.org/show_bug.cgi?id=637001 'net-misc/vino' and https://bugzilla.gnome.org/show_bug.cgi?id=637002 'x11-libs/vte' Portage should have at the least TRACKER bugs for these QA issues and -fno-strict aliasing should be set until these issues are addressed. Suggest trackers for each of the qa issues mentioned in the logs. implicit functions tracker breaks strict-aliasing tracker arrays out of bounds tracker This will allow qa to at least ensure that what we can do will be done. Impose proper flags in the case of strict-aliasing, fix or perhaps mask the array problems or hash out with upstream, fix the implicit functions if it's just headers. opened new: http://bugs.gentoo.org/show_bug.cgi?id=348400 http://bugs.gentoo.org/show_bug.cgi?id=348403 re-assigned http://bugs.gentoo.org/show_bug.cgi?id=348107 from bug wranglers to gnome Just reading the ebuild it is not clear where the source is even pulled from for vte
closed bug 348107 this is fixed in mail-client/evolution-2.32.1 Note: No mention any particular bug in the Changelog but many patches.
The vte bug is closed as 'not a bug' by upstream "The warnings all come from g_static_mutex_get_mutex() deep in glibconfig.h. And so deep that it's impossible to "fix" it. It's working around pthreads issues." Behdad Esfahbod Should -fno-strict-aliasing be set for this?
with gcc-4.5.x I have the following programs compile with -fno-strict-aliasing david@random ~/projects/connman $ grep -H CFLAGS /etc/portage/env/*/* /etc/portage/env/gnome-base/libgtop:CFLAGS="${CFLAGS} -fno-strict-aliasing" /etc/portage/env/media-gfx/graphviz:CFLAGS="${CFLAGS} -fno-strict-aliasing" /etc/portage/env/media-libs/libdvdnav:CFLAGS="${CFLAGS} -fno-strict-aliasing" /etc/portage/env/media-libs/libdvdread:CFLAGS="${CFLAGS} -fno-strict-aliasing" /etc/portage/env/media-sound/pulseaudio:CFLAGS="${CFLAGS} -fno-strict-aliasing" /etc/portage/env/media-sound/sox:CFLAGS="${CFLAGS} -fno-strict-aliasing" /etc/portage/env/net-irc/irssi:CFLAGS="${CFLAGS} -fno-strict-aliasing" /etc/portage/env/net-wireless/kismet:CFLAGS="${CFLAGS} -fno-strict-aliasing" /etc/portage/env/sys-boot/grub:CFLAGS="${CFLAGS} -fno-strict-aliasing" /etc/portage/env/sys-boot/lilo:CFLAGS="${CFLAGS} -fno-strict-aliasing" /etc/portage/env/x11-libs/pango:CFLAGS="${CFLAGS} -fno-strict-aliasing" /etc/portage/env/x11-libs/vte:CFLAGS="${CFLAGS} -fno-strict-aliasing" Of these lilo, grub and kismet would not build the package with the flag. The lilo and grub have flag-o-matic filtering. I managed to move lilo's ebuild to an overlay and make it work. For grub there is support for custom-optimizations. kismet is a whole 'nother ball game. I checked that package's Changelog and ebuild and just removed the package from my system completely. I submit it might be better to mask kismet until upstream fixes the package or remove it from the tree entirely. Please consider removing the request to file upstream bug reports for 'pointer-type punned breaks strict aliasing' it is a simple fix that is already done for some other packages in the tree. I do not have any kde packages and so no idea what might need to be compiled that way. On the amd64 mailing list one 'user' suggested that maintainer work flow should not actually be spent fixing bugs but rather testing packages and submitting upstream bugs. That could allow more users to file bugs and maintainers to limit the scope of their work as well as requiring less skill to be a maintainer. Developer !=Maintainer developer's are a rarer still quantity and should not be maintaining packages. Many users have the skill to be maintainers. Choose some and put them to work. Lessen your work load.
yeah, no. aliasing violations is absolutely an upstream problem and needs to be resolved there. hacking ebuilds is not the correct solution.
@QA: do you want this bug? At this stage this clearly is not a userrel bug.
In reply to comment #23 while I agree with you in spirit it is a hack; it is quickly done and ensures the system does not suffer from undefined behavior by the application. If not done the alternatives are ugly. It is also much more quickly done than filing X number bugs at each packages bug list after tracking them down and registering. Or trying to convince gentoo maintainers to do this and waiting for the result. Or fixing the package(s) yourself if you can. Or do nothing. This says nothing of the 'array subscript' or 'string format' errors. And I believe user-relations should care about the quality of the software installed via portage. This policy and messages is a direct encumbrance to quality assurance. Would hardened or security care to comment?
(In reply to comment #25) let me rephrase. hacking ebuilds to append flags is a short term mitigation and/or work around. it is not something which can be considered a "fix" and maintainers should be pestering upstream to fix their crap source.
So how then does the quality of the software become tracked if we do not allow bugs. Clucene- C++ search engine (I have emerge -C and it still wants to install when I emerge -up world) has the usual message file upstream. Severe warnings. A user has done this. 6 months ago. Looking at the open bugs on the development page nothing seems to have been closed since just before Christmas of 2010. http://sourceforge.net/tracker/?group_id=80013&atid=558446 The gmame traffic is dead for the last year. http://dir.gmane.org/gmane.comp.jakarta.lucene.clucene.devel/ One user has posted a log of issues provided by cppcheck. 3 patches have been submitted and not replied too. This seems to be the gentoo git. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-cpp/clucene/files/?diff_format=s
All yours QA :) -A
QA already has enough to track (we're a CC magnet) and do (respect *FLAGS, ...); if this shows for any user then that is indeed of concern, I suggest the Portage team only shows these for users that have explicitly enabled these QA messages. People* need to file this upstream; there is no point in filing thousands of bugs on our Bugzilla, when in fact we can easily collect a list of these with a Tinderbox run. Not to forget about that starting to fix such bugs downstream isn't possible; or well, not with all the other bugs that are around to be fixed. Given that we have other work to do first, a Tinderbox run is somewhere on our list; don't worry, in any case, it is tracked regardless of thousands of bugs. As for Clucene; if you see a package like this, feel free to suggest it to the treecleaners [0] if it meets the removal criteria of their policy [1]. * People as in interested maintainers and/or users, but not pestering everybody. [0]: https://www.gentoo.org/proj/en/qa/treecleaners/ [1]: https://www.gentoo.org/proj/en/qa/treecleaners/policy.xml
