Hi, After reading the following bug I had the idea that having some kind of check like this inside portage might be useful for detecting problems with 64bit archs early on. http://bugzilla.gnome.org/show_bug.cgi?id=353314 Would it be practical to implement some parsing along these lines?
it would seem useful for non x86 arches(amd64, ia64, and probably ppc64 at a minimum) but I fear that it would be a huge undertaking to correct all the packages that throw warnings like this even though the returned result is correct(i.e. false warning) media-* stuff comes to mind.
In which cases are the warnings false?
I think I speak for the portage team when I say we'd prefer you implement it in your profile.bashrc as opposed to doing it internally to portage if possible. Much of the time there is no need for portage to know or care about these checks other than to run them and record failures.
(In reply to comment #3) > I think I speak for the portage team when I say we'd prefer you implement it in > your profile.bashrc as opposed to doing it internally to portage if possible. When PORT_LOGDIR is enabled, portage exports the name of the log file in the ebuild environment as PORTAGE_LOG_FILE. You'd want to grep that file sometime after the src_compile phase. The user level phase hooks would be one way to trigger it (but profiles and ebuilds/eclasses aren't allowed to use those). > Much of the time there is no need for portage to know or care about these > checks other than to run them and record failures. Well, we don't want to include the qa checks themselves directly in portage. However, we could create a general framework that allows qa checks like this to be implemented in eclasses or something similar.
(In reply to comment #3) > I think I speak for the portage team when I say we'd prefer you implement it in > your profile.bashrc as opposed to doing it internally to portage if possible. I don't really have a personal interest in pursuing this, I just saw that bug report and realised that automated weeding of these messages makes a certain degree of sense. > Much of the time there is no need for portage to know or care about these > checks other than to run them and record failures. Which is precisely what I'm suggesting. Interested people who read the logs or see the warnings fly by then might look into fixing them (similar to the current QA notices). However, if you don't want to have this kind of thing running in portage, that's fine -- go ahead and close this bug. It was only a suggestion and I know that not all suggestions are feasible/practical.
sounds like a dupe of 111436 however, this particular test would catch false positives ... the glib hash API for example has generic callbacks which utilize void* arguments and often times people just pass in integers ... then we end up with this warning
*** Bug 111436 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 111436 ***
