Summary: | gcc-config-1.4.0 is b0rken | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Bob <custom_basses> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | VERIFIED INVALID | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
URL: | http://forums.gentoo.org/viewtopic-t-365969-start-16.html | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Bob
2005-08-30 08:47:34 UTC
there is no gcc-config-1.4.0 there is no gcc-config-1.4.0? what a joke. there's no need to lie about the situation. the file mistakenly found its way into the snapshot portage-20050827.tar.bz2, and you fixed the problem by removing the ebuild from portage. i don't have any problems with developers admitting that mistakes have been made and promptly fixing the problem. i do take issue with the way that you quietly made the problem go away and then called me a liar. anyone who looks at the file portage-20050827.tar.bz2 will find that i'm telling the truth. fixing the bug by erasing the file does not constitute an INVALID resolution. it is a VERIFIED bug that you've fixed. but sweeping the bug under the carpet does make your statistics look better, doesn't it? i dont know wtf your problem is but you need to chill out at no time was gcc-config-1.4.0 ever available in the stable or unstable trees ... it was package.masked the entire time it was in portage it has since been removed this bug is INVALID because the only way for you to get gcc-config 1.4.0 onto your system was to change maskings that we had in place ok, i have chilled. i think that you need to take a close look at the portage snapshot for the 27th and you'll find that your assertions are mistaken. you might also want to read the referenced thread above, as it clearly shows that the offensive ebuild was in the portage tree in an unmasked state as of the snapshot on the 27th and when i emerged it onto three systems 24 hours ago. this isn't a case where i have unmasked the ebuild. this is a case where there was a legitimate mistake in the portage tree. i find it very difficult to understand why you cannot admit that there was an error in the portage tree, or why you insist on attempting to shift blame to the user who reports the error. that is just wrong. if you read the log files from cvs, gcc-config-1.4.0 was deleted Aug 9th while the package.mask entry was not removed until Aug 20th i'm not responsible in anyway for snapshots so i cannot vouch that they are not broken i am at a loss to explain why the bug occurred or how it was fixed, but even so i am glad that the situation has been resolved. thank you for your time. |