I think it would be rather nice if the possibility to link packages on the packages.gentoo.org website to its bugreports on this site. If I for exampel want to know why it looks lika a specific package take ages to get unmasked it would be nice to have a easy way too link the bugreports to the packages. After all that would make it easier for me to see if they already got my problem and to see if there is anything I can do to maybe help another and get the thing marked as stable. Reproducible: Always Steps to Reproduce:
somebody did but I don't really know who is behind it. http://gentoo-portage.com/program-bugs.php?program=2755
marduk -- what do you think?
The way that gentoo-portage does it is that they fetch a bugzilla query via http and then format it and spit it out on the web page. We could do that, but there will be a latency because we are fetching a page that is fetching a page. Not sure if that will slow down the site significantly or not.
I did like that site. However do YOU have to make it that way (trough a http query) if it slows things down? The one who reads the bug-report could if possible connect it somehow to a d-base of packages wich then the packages.gentoo.org queries and leaving the http-auery out of it. Or does that do things too complicated? It would also be nice to have somehow the one who maintain the ebuils comment of why he has it masked, if there is something he like to have better tested befor unmasking or something specific he maybe would have help with to fix. I have a lot of masked builds emerged but don't know if there's anything to contribut with just becouse I don't know what to look after, if the thing it's masked for works for me or not.
Most likely it will have to be a http get. packages.gentoo.org and bugs.gentoo.org are in different parts of the world. Also /ebuilds/* are cached for performance. I'd have to remove cacheing if we're going to be querying a dynamic database. Not saying I'm not going to do it but (I think) we're going to lose a lot of the speed I've been able to cheat into the site.
Please test with, for example, http://packages.gentoo.org/ebuilds/index_test.shtml?openoffice-ximian-1.1.52 thanks, --marduk
Now THAT was a nice thing... It was exactly something like that I hoped for. Good work!
For some reason, the bug # have been truncated to 3 digits. 778 normal P2 x86 NEW openoffice-ximian doesn't install opens___.tt actual bug #47789
I think it's fixed now. Buggy CSV parsing :-(
We needed to back out because it was hitting bugs.gentoo.org too hard. There is another solution in place, but I probably won't get to it tonight as I have to do my taxes.
Project dead or just sleeping?
Just sleeping...
Becouse it is sort of on the same topic I decided to drop one more feature-request here: Some sort of quick-note from the persons adding packages to CVS. Like for exampel a new package is placed in portage and can't be marked as stable becouse of it got a dependencie witch is not marked stable, then the he/she can make a small comment readable for the ones browsing packages.gentoo.org telling them that with possibility to link to a bugreport where the topic have been discussed. I believe a similar system would stop some of bugreports on the topics "Why haven't *blahblah* been marked stable, or for exampel "Why have you not put evolution 1.5.* into portage" and so on.....
On "sort of quick-note from the persons adding packages to CVS": that should probably go in the Changelog and if so, it will show up on packages.g.o
Well, the Changelog does not work that way righ now. The ebuildmakers tells us there what have been fixed, but never what is left to fix/test. What I mean is a floating note maybe not even depending on a specefik version of the package but not fit for the "Description" that could have about anything from a little comment about "this needs to be tested/fixed". Like for wxpython it could be: "New versions avaible, but not into portage becouse of broken deps. Bug 47810 for more info" I think comment like that does not take that long for the maintainer to do if the system supports it, and those floating comment would help alot and maybe prevent someone from fileing a duped-bugreport about the versionbump.
This might be a nice feature (though I'm not entirely convinced) however it is something that should be implemented in portage, not packages.g.o, which is just a front-end to portage. If it were a part of the portage tree I'm sure there would be no issue displaying it on packages.g.o.
Bumping this old thing to give credit (who ever made it) for the functions added (since a long time, and I have been using it all along;) to packages.g.o: the "Bugs" and "Forums" links works awesome according to me...:) Just a litte thought. Remembering that old suggesion I made back in comment #15... ....how about implement a little "TODO"-function for this into portage? That could serve the purpose, and as some ebuild-makers already have thier own TODO-lists inside of their ebuilds (both stable and unstable) which sometimes seems to point to more than just themself that function may be something which will be used. Then the TODO-lists could be shown by packages.g.o...
Closing this. I think the "Bugs" link is sufficient (for now).
