| Summary: | ebuilds with drawn from tree implying retrograde but no explaination on cvs | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | genbug |
| Component: | New packages | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
| Status: | VERIFIED WORKSFORME | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
If you are using hardmasked development version of Gnome, then don't moan when they disappear once the regular release is out. For xterm, why don't you just read the Changelog? 215-r1 has never been stable, so you unmasked this one revision in package.keywords and now get downgrade. Don't see what's your point here. appologies, I realised I had unmasked the two gnome packages explicitly by version number , that explains what I was getting, but buzilla search was unable to come up with my post so I could not correct it. Maybe it was too soon after the post. hwvr, xterm is not unmasked, I run ~x86. It seems and -r1 was created and then removed without explaination. Unless you can see another explaination. thx (In reply to comment #2) > hwvr, xterm is not unmasked, I run ~x86. It seems and -r1 was created and then > removed without explaination. Unless you can see another explaination. 05 Sep 2006; Seemant Kulleen <seemant@gentoo.org> -xterm-207-r1.ebuild, -xterm-215-r1.ebuild, -xterm-216.ebuild, +xterm-219.ebuild: version bump to 219, and cruft removal of some of the older versions -- 216, for example, is gone without ever hitting stable. 217 or 218 should be stabled soon There goes your explanation. Stick one particular revision will downgrade it when that revision is gone, pretty normal behaviour. appologies, I realised I had unmasked the two gnome packages explicitly by version number , that explains what I was getting, but buzilla search was unable to come up with my post so I could not correct it. Maybe it was too soon after the post. in any case something like the usual 'new version and cleanup' would seem appropriate. Indeed that would almost certainly have alerted me to my mistake. hwvr, xterm is not unmasked, I run ~x86. It seems and -r1 was created and then removed without explaination. Unless there was a bug in the r1 release which led to it's being withdrawn surely it is 215 that should have been pulled not 215-r1. Unless you can see another cause. thx for your reply. some crossed wires here. Bugzilla failed to respond, so I hit stop and reposted. lets separte the two. gnome stuff, my bad , but comments would help. xterm: >>cruft removal of some of the older versions why was r1 cruft but 215 retained. Still looks like a mistake to me. >>217 or 218 should be stabled soon well for now they're not so I get a UD. Still looks like a mistake to me. No big deal , just a few words in a comment would help see what is going on and help us resolve these situations quickly. That seems to be general policy. The point of this bug was to ping the devs invovled and maintain the usefulness of cvs. Thanks for you explainations on the detail. What's the mistake here? Obsolete ~arch ebuild removed with notice in ChangeLog. Sorry, I don't see problem, closing. in what way is 215-r1 "obselete"? Logically 215 should have gone. (In reply to comment #7) > in what way is 215-r1 "obselete"? Logically 215 should have gone. Sigh... We won't remove the only stable version, would make arch folks jump after you pretty damn fast. Finished w/ this. right , makes much more sense to delete the only ~x86 ebuild and have all the ~arch users wondering it is going on. ~x86 is "cruft". Thanks for your explainations , time and patience. (In reply to comment #9) > right , makes much more sense to delete the only ~x86 ebuild and have all the > ~arch users wondering it is going on. Sorry but what are you talking about? Current ~x86 xterm is 219, already tried to explain you a couple of times that you've unmasked one revision _only_ (which is now gone). Maybe read the docs on working with portage? http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=3 |
ebuilds withdrawn from tree implying retrograde but no explaination added on cvs. eg pango * x11-libs/pango : [ ] 1.8.1-r1 (0) [ ] 1.10.3 (0) [ ~ ] 1.10.4 (0) [ ] 1.12.3 (0) [M~ ] 1.14.3 (0) So I need to decide if I retrograde and possibly cause dependancy issues that need sorting out, unmask a hardmasked version or simply keep 1.13.2 and wait for 1.14.x to be marked usable. The last option may be the best but I have no information as to why this ~x86 was removed so I cannot decide the best way to deal with this UD situation. similar issue on other pkgs [ebuild UD] gnome-base/libgnomeui-2.14.1 [2.15.1] USE="debug*" comment is simply: gnome 2.16 ??? [ebuild UD] x11-terms/xterm-215 [215-r1] comment refers to cruft removal but no indication why r1 was removed in favour of 215. This would seem to be a mistake. a good example is jpeg-mmx. faced with the same situation I could see in cvs that 1.1.2 was a typo and hence no issues with retrograding. [ebuild UD] media-libs/jpeg-mmx-0.1.6-r1 [1.1.2-r1] could the devs making these changes take a second to add a note explaining the removal. This seems to be std practice on gentoo that got missed in these cases. It would be a great help in dealing with these UD anomolies. many thx.