| Summary: | Missing keywords/unmasking ppc64 ebuilds | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Brent Baude (RETIRED) <ranger> |
| Component: | New packages | Assignee: | ppc64 architecture team <ppc64> |
| Status: | VERIFIED FIXED | ||
| Severity: | normal | CC: | apache-bugs, tgall |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | PPC64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Brent Baude (RETIRED)
2005-04-10 13:41:28 UTC
fixed in CVS corsair, how did you get apache-1.3.33-r2 marked stable w/o marking lingerd stable? it's a DEPEND. please (when you're on the way) test'n'stamp this too or other's will complain about having complaining repoman, too ;) sorry.. fixed in CVS... :-( corsair, did you get -> dev-perl/AxKit-1.6.1 i didnt see the ~ppc64 keyword on my latest sync. could you mark 1.3.33-r2 ~ppc64 again, it is NOT stable atm! Brent: I tested AxKit-1.6.2 here and it worked fine. So I added there the ~ppc64 keyword. But as you request version 1.6.1, I tested this one and added ~ppc64, too. Benedikt: That version works for me! And I haven't seen any open bugs for that version. So I marked it stable. But if you say, that version isn't stable, I'll mark it ~ppc64 again. (maybe p.mask it, so that arch markers like me see, that it is not stable? Or open a bug that keeps track of the problems with that version. I normaly check bugzilla, before I mark packages stable. another solution to avoid things like this is to put a note to the KEYWORDS line in the ebuild. So persons who change a keyword see the note, when they use Brent: I tested AxKit-1.6.2 here and it worked fine. So I added there the ~ppc64 keyword. But as you request version 1.6.1, I tested this one and added ~ppc64, too. Benedikt: That version works for me! And I haven't seen any open bugs for that version. So I marked it stable. But if you say, that version isn't stable, I'll mark it ~ppc64 again. (maybe p.mask it, so that arch markers like me see, that it is not stable? Or open a bug that keeps track of the problems with that version. I normaly check bugzilla, before I mark packages stable. another solution to avoid things like this is to put a note to the KEYWORDS line in the ebuild. So persons who change a keyword see the note, when they use ´ekeyword´ to change it.) hmmm.... I'm in trouble, hollow, I must admit, that I proposed to at least complete the keywording action; so, if already started, and users are already using it (on ppc64), why not. I know - of course - we wanna switch *ALL AT ONCE* so, that binary incompatibility issues will be avoided. But, as I just do think about some time, theses binary incompatibility issues do apply to apache2 and related only. So, that's why I proposed the above. corsair, if you already went back to ~. no problem. I just wanted to state at this bug my thoughts right now. However, going back into pmasking it. there's no way for this as we're about to going stable rather soon than anytime later. I don't see why >=apache1.3.33-r2 is considered "unstable" instead, it's "experimental" by mean: that it's the very first release containing the new configuration layout. But hey, we've this on our own boxes for MONTHS now. All my prod. hosts even run 2.0.54 with *NEW* configuration layout since I feel it is mature anyway. So, finally, I see no big deal in it. Regards, Christian Parpart. all stable. closing |