Just a version bump to v1.0.1. Note the ebuild with this patch _is_ broken, but I can't see a way to fix it so I'm hoping for some input you, this bug's reader, on how it should work. Firstly, the ebuild uses fixheadtails now just to clean up some current warnings and hopefully stop errors with later versions of coreutils ;) I've not changed the src_compile()'s --enable-binary arg, even though it seems quite pointless as it is the default behaviour. Perhaps it is to stop people reporting bugs :/ src_install() now installs the full range of docs, and the example cgi script for web based SCCS navigation. src_test() is the function causing the problems. y-flag.sh should be an XFAIL in my opinion(in as much as it is broken), so it is forcibly skipped when the testsuite is run. The real cause of the problems is that "make check" will fail because it /rightly/ checks the user who runs the testsuite is not root, if they are it fails. The reason being the nature of the SCCS tools means it needs to check behaviour when files are read-only, and there is pretty much no such thing to root which would mean it falsely fail some tests which should have passed. The patch I've attached to this bug calls "su" to change the user to jay on line 33, obviously this is broken but it is to illustrate the point(and it allowed me to test the package on this box). I'm not aware of any user who could be used for this test on *all* systems, and this is where you come in: is there a user that is applicable for these types of tests[1]? Due to importance of validity tests for a package that actually holds your data, I think disabling checks would be quite foolish. It isn't like an editor where errors might cost you your current work, in this case errors could cost you your whole history. That is just my opinion on the matter though, and I'm sure others will think differently. Outside of the src_test() problems this new version of cssc brings a lot of bug fixes which definitely warrant a quick bump, or somebody willing to come down to my place of work and kick people who think we should still support SCCS file formats. If you are that person drop me a mail :P 1. I'm incredibly sure this isn't the only instance of a package where such a user is needed, but granted it is the only one I've found so far. Thinking about it some more has made me start taking more notice to the types of tests packages are running during installation. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 53861 [details, diff] cssc-1.0.1-bump.patch This patch is broken due to the problems described in the first comment!
*** Bug 85900 has been marked as a duplicate of this bug. ***
I had originally marked this bug as normal severity because the issues described relate to the stale version that is in the portage tree too :/ My apologies if it should have been marked as enhancement regardless.
Sorry, I don't use cssc, I just fixed a ChangeLog header for this package.
oh james, we meet again
Seemant, I would appreciate some/any input on the permissions problems I raised in the initial bug report. Even if this is going nowhere now, I would rather fix up the report and attachments enough that it is easier for somebody to pick up should they want to later. And of course, if the same sort of thing arises in the future I will know the correct fix. Even a pointer in to the tree would be gratefully accepted, as I can't find any solutions to similar problems currently in the tree.
James sorry for my latency on this bug. I think there is a "portage" user, perhaps we can switch to that. cc'ing the portage devs on this, though.
Quite a few other packages require that src_test is run as root. From this, src_test is always run as root even if FEATURES="userpriv". Quite likely this will be reversed in the future (all tests run as portage) and a new RESTRICT to force root src_test. For the time being though, su'ing to portage sounds acceptable.
First up sorry for the delay, holiday season. Thanks for the info! Updated the attachment, tests are now run as the portage user.
Created attachment 65833 [details, diff] cssc-bump-v2.patch
(In reply to comment #9) > Thanks for the info! Updated the attachment, tests are now run as the > portage user. > Hmm, I've just tried this on a test box with a default pam setup(pam-0.78-r2) and you can't even su to the portage user[1]. I have absolutely no idea why, for the same reason I didn't notice it before I posted the last comment; I don't use the Gentoo provided pam stuff and have close to zero idea how it even works. Considering nobody else is complaining about this package _at all_ and on top of that locally this doesn't cause a problem(we have a sccs user, which is (ab)used for the tests), perhaps the bug should just be set to an appropriate LATER/CANTFIX/WONTFIX now and forgotten instead of burning more time for you guys. 1. The error message is: su: Authentication service cannot retrieve authentication info. (Ignored)
Since the last update to this bug cssc-1.0.1 has been committed to tree without addressing the problems described here. I'm just changing the summary field to make more sense now that it isn't bump related.
Given that it doesn't look like as if this application was ever properly maintained within Gentoo, I'll mask it for removal. That said, looks like someone moved the seemingly dead project to savannah.gnu.org recently.
(In reply to comment #13) > Given that it doesn't look like as if this application was ever properly > maintained within Gentoo, I'll mask it for removal. That said, looks like > someone moved the seemingly dead project to savannah.gnu.org recently. > ?! Why are you masking maintainer-needed ebuilds without treecleaners, and why aren't you lastriting them on gentoo-dev ML? And are you seriously removing this only because of failing test suite?
That said, the app works fine (builds, installs, works)
unmasked
Yes I am. We should remove a lot more umaintained stuff. Please take maintainership, if you don't think so.
(In reply to comment #17) > Yes I am. We should remove a lot more umaintained stuff. Please take > maintainership, if you don't think so. > If the only thing that is broken here is that the tests fail, lets just RESTRICT="test" it and leave it in the tree. There's no reason to get rid of an app that works, even if no one is actively looking after it. If a bunch of bugs come up that no one wants to fix, treecleaners can take care of it then.
I went ahead and added the RESTRICT for test in the ebuild. If that's the only problem with it, there is no reason to punt it at this time. Thanks
