Hi, Please find attached cvsnt-2.0.62.1817.ebuild, and some ancillary files that need to be put into its files directory. I suggest dev-util/cvsnt For further info on cvsnt, see http://www.cvsnt.org/wiki, and in particular http://www.cvsnt.org/wiki/CvsntAdvantages. Greetings from Luxembourg, David
Created attachment 48207 [details] the ebuild
Created attachment 48208 [details] some metadata
Created attachment 48209 [details] dev-util/cvsnt/files/cvs.pam
Created attachment 48210 [details] dev-util/cvsnt/files/cvslockd
Created attachment 48211 [details] dev-util/cvsnt/files/cvspserver
What about using system-auth in pam instead of winbind/unix? ================= #%PAM-1.0 auth required pam_stack.so service=system-auth account required pam_stack.so service=system-auth ================= Like for dev-util/cvs (/usr/portage/dev-util/cvs/files/cvs.pam). This if far more generic and should work for everybody who don't have a special PAM configuration and will also work for most people who did modify their config (by changing /etc/pam.d/system-auth)
In the xinet config file, for more genericity, you should not put the only_from line. The machine running cvsnt may not be on a private network at all. Worse, it's likely to be on only one of those networks, not both. So it's not a secure default. If you really want to put a default only_from line, then you should put "only_from = localhost".
Ref comment #7 (http://bugs.gentoo.org/show_bug.cgi?id=77536#c7) It *is* a secure default, because disable = yes. An entry for only_from is, IMHO a darn good idea because Gentoo has /etc/xinetd.conf which sets the *defaults* for only_from to localhost, so unless an override is specified here, only localhost can connect to pserver (which rather defeats the whole purpose of pserver). Does it matter that the defaults for only_from are set to some private LAN addresses... when the sys admin edits this file to set disable = no, they can also set only_from at the same time (if they really do have a public IP address - which is crazy because a publically accessible CVS repository really should be on a private LAN with a firewall or two between it and the Inet).
Created attachment 48287 [details] dev-util/cvsnt/files/cvs.pam updated cvs.pam (wrt comment #6)
comment 8 I know that the file as-is is secure because of "disable = yes". What I mean is that once enable, it's "sort of" secure. Either it's not secure enough because it allows hosts that are not on the local network to connect, or it's too secure because for some hosts, it doesn't work without modifying the only_from line. > "Does it matter that the defaults for only_from are set to some [...]". Well then if it doesn't matter, why not put it to something truly secure by allowing only localhost? ;) And if you want to force the administrator to look at the line, then you should make it so it doesn't work for any host, that's a better incentive than having it working for some and not working for others.
ref comment #10 (http://bugs.gentoo.org/show_bug.cgi?id=77536#c10) Probably the easiest thing to do is just add a comment line before the allow_from line saying 'change the allow_from as applicable'.
If this ebuild ever get around to being added to Portage, duplicate and bump my ebuild to dev-util/cvsnt-2.0.62.1852.ebuild to get the latest bleeding edge release
Bump to dev-util/cvsnt-2.0.62.1852.ebuild to get the latest testing release... But keep the original ebuild (cvsnt-2.0.62.1817.ebuild) for a slightly less bleeding-edge release.
Bumping to 2.5.01.1927
Created attachment 57706 [details] dev-util/cvsnt/cvsnt-2.5.01.1927.ebuild
Created attachment 57707 [details] dev-util/cvsnt/files/cvsnt.pam
Probably an idea to create a virtual package to hold either cvsnt or cvs... since cvsnt is compatible with cvs, and a few packages have cvs as a dependency (which means even if cvsnt is installed, it will be overinstalled by cvs).
Created attachment 58737 [details] dev-util/cvsnt/cvsnt-2.5.01.1949.ebuild ebuild for build 1949 (latest testing release)
The eBuild can be bumped to cvsnt-2.5.01.1969.ebuild. Build 1969 is an update from previous releases that: * Fix problem with deleting then resurrecting binary files * Add suport for default-deny ACLs (AclMode) * New options: add -r: Add to branch add -b: Add and mark with bug id edit -C: Check file is unmodified & up to date before edit * PCRE now used for regexp matches in commit support files * Default to only running first match in commit support files, support '+' prefix for running additional lines. * .ico files default binary in cvswrappers * Merge attempts to preserve file execute permissions * Fix warning message in msi installer * plink updated. Support for sessions added. * Fix for plink hanging with some servers. Note: rename is to be fixed within the 2.5.02 timeframe, so isn't included in this update.
Created attachment 59611 [details] dev-util/cvsnt/cvsnt-2.5.01.1973.ebuild Latest testing release: CVSNT 2.5.01.1973 (Friday 20th May 2005)
Created attachment 59943 [details] dev-util/cvsnt/cvsnt-2.5.01.1976.ebuild bump toCVSNT 2.5.01.1976 (Monday 23rd May 2005)
Created attachment 60358 [details] dev-util/cvsnt/files/cvsnt-2.5.01.1976-rcs.patch patch for the Unknown expansion option '
Created attachment 60358 [details] dev-util/cvsnt/files/cvsnt-2.5.01.1976-rcs.patch patch for the Unknown expansion option ' æ' problem
Created attachment 60359 [details] dev-util/cvsnt/cvsnt-2.5.01.1976-r1.ebuild modded to patch build 1976 to rid the annoying Unknown expansion option '
Created attachment 60359 [details] dev-util/cvsnt/cvsnt-2.5.01.1976-r1.ebuild modded to patch build 1976 to rid the annoying Unknown expansion option ' æ' problem
Created attachment 60538 [details] dev-util/cvsnt/cvsnt-2.5.01.1986.ebuild bump for build 1986
Created attachment 60780 [details] dev-util/cvsnt/cvsnt-2.5.01.1990.ebuild Bump for build 2.5.01.1990
Created attachment 61277 [details] dev-util/cvsnt/cvsnt-2.5.01.1998.ebuild ebuild for cvsnt-2.5.01.1998 Note that this has a small patch which ensures that the new -I@ function works correctly. (This patch is already in the upstream cvsnt source.)
Created attachment 61278 [details] dev-util/cvsnt/files/cvsnt-2.5.01.1998-import.patch patch to go with build 1998
Created attachment 61302 [details] dev-util/cvsnt/files/cvsnt-2.5.01.1998-cvsdbk.patch Patches cvs.dbk to correct invalid link
Created attachment 61303 [details] dev-util/cvsnt/cvsnt-2.5.01.1998-r1.ebuild Now supports the DOC keyword to build the documentation.
I can't speak for the other people on this mailing alias but I've never used this package and have no idea how it it could be beneficial to us. Primarily cvs-utils@ exist for the sole sake of the 'cvs' package. Being that there are only 3 of us on this alias and none of us have added this package yet. Chances are probably pretty slim that any of us 3 will. Bouncing bug back to bug-wranglers@ to see if anybody else might want to pick up this package.
Ref comment #30 "can't speak for the other people on this mailing alias but I've never used this package and have no idea how it it could be beneficial to us." Well, for starters you could actually bother to look at the web site (http://www.cvsnt.org/wiki) which does explain things (especially http://www.cvsnt.org/wiki/CvsntAdvantages). Or, how about trying to emerge the package and have a play with it insetad of instantly dismissing it because its something new to you? Briefly, cvsnt was a fork of cvs to make it work on Windows NT... it then got lots of extra features, and was backported to Linux... and its been actively developed over the past few years, steadily gaining new features... and its ideal for mixed Linux/Windows environment (since it does cute things like sspi authentication).
I did look at both pages, read them brielfy and I stated I dont see how this is beneficial to the cvs-utils@ group which only maintains 1 package 'dev-util/cvs' which Gentoo's basic infrastructure depends on heavily. For the record also nobody has dismissed your ebuild. It's been rerouted to back into a larger pool so other devs can have the opportunity to pick it up if it's something they are interested in.
Created attachment 61796 [details] dev-util/cvsnt/cvsnt-2.5.01.2007.ebuild Build 2007
Created attachment 62244 [details] dev-util/cvsnt/cvsnt-2.5.01.2013.ebuild Build 2013
Created attachment 63139 [details] dev-util/cvsnt/cvsnt-2.5.01.2025.ebuild Bump for build 2.5.01.2025. +new USE flag server to enable/disable server-side support. +net-misc/howl is required so its added to DEPEND.
Created attachment 64388 [details] dev-util/cvsnt/cvsnt-2.5.02.2040 Release 2.5.02.2040
Created attachment 64955 [details] dev-util/cvsnt/cvsnt-2.5.02.2047.ebuild Bump for 2.5.02 (Servalan) Build 2047 (Release Candidate 2)
Created attachment 65018 [details] dev-util/cvsnt/cvsnt-2.5.02.2048.ebuild bump for 2.5.02.2048
Created attachment 66085 [details] dev-util/cvsnt/cvsnt-2.5.02.2060.ebuild 2.5.02 (Servelan) RC4! + Makefile.in gets patched so that --without-config-dir no longer needs to be specified... net result, the server now knows where the config files are, so cvs init can modify them. + example Config files are only written if USE=+server + Plugins.example written to config files directory (if USE=+server)
I really can't be bothered to keep submitting new ebuilds if all they are going to do is bitrot here instead of getting put into the official portage tree. (Harsh words, I know, but after maintaining these ebuilds for well over 6 months I think I'm justified in bitching.) So, if anybody wants the latest ebuilds for cvsnt, please rsync them from my server using: rsync -rztp --delete rsync://rsync.omz13.com/local-portage/dev-util/cvsnt /usr/local/portage/dev-util to get them into your local portage tree.
*shrug* Okay. http://dev.gentoo.org/~ciaranm/docs/mw-faq/ignored.txt
(In reply to comment #41) > *shrug* Okay. Thanks for closing this bug... I've now Reopened it, since that way it will be nice and visible and hopefully will get picked up by a dev who isn't afraid of putting cvsnt into the portage tree. (Yeah, you may be surprised to learn that people actually use cvsnt with gentoo... there is more to life than svn and classic cvs... and in case you didn't know it, remember that cvsnt was forked from cvs - which was stagnating at the time - and includes many features over and above those in classic cvs, plus its very useful in a mixed linux/windows environment).
Sure, whatever. Reassigning this one back to bug wranglers, it's inappropriate for maintainer-wanted since we don't work with anything except attached ebuilds.
(In reply to comment #43) > Sure, whatever. Reassigning this one back to bug wranglers, it's inappropriate > for maintainer-wanted since we don't work with anything except attached ebuilds. Well, dear Ciaran, you and every other gentoo dev out there don't actually appear to be working with any of the atatched ebuilds since they've been nicely ignored for the past 7 months! So don't give me that "inappropriate" crap. As always, more effort is being spent keeping this out than getting it in. I think the following quote from some text that you wrote (http://dev.gentoo.org/~ciaranm/docs/manifesto.txt) is just wonderful: "Gentoo is *not* about inclusiveness, nor is it about giving recognition and approval to every single project and person under the sun. A degree of elitism is necessary and appropriate if we want to maintain any kind of standard." Nice attitude dude. (Oh, and I'm being just a tad sarcastic.)
I guess if no dev wants cvsnt; the ebuild isn't even attached and maintainer-wanted doesn't want it - it should be closed.
No, it can bloody well stay open until some dev picks it up... even if that's not for another decade. I was under the impression that gentoo was all about choice... seems to me unless the vcs is svn or cvs, its being excluded.
(In reply to comment #45) > the ebuild isn't even attached Uh? What's https://bugs.gentoo.org/attachment.cgi?id=66085 then? I count 16 other ebuild attachments (obsolete included) david, maybe there is a conspiracy against you.
(In reply to comment #47) > (In reply to comment #45) > > the ebuild isn't even attached > > Uh? What's https://bugs.gentoo.org/attachment.cgi?id=66085 then? I count 16 > other ebuild attachments (obsolete included) Correct. FWIW, dev-util/cvsnt/cvsnt-2.5.01.1927.ebuild is the last *official* release of cvsnt... all the other ebuilds are for *interim* releases. As always, the latest bleding edge ebuilds can be rsync'd from my site. > david, maybe there is a conspiracy against you. At the risk of sounding paranoid, its does seems to look like that.
there's no conspiracy, just no dev who cares enough about cvsnt.
(In reply to comment #49) > there's no conspiracy, Probably true... just a darn lot of apathy towards cvsnt (which just happens to be a bit of an improvement over classic cvs, and way easier to work with/administer than svn). BTW, I took Nahor's comment about conspiracy to be rather tongue-in-cheek... I'm not paranoid, but I've been around the block a few times. Let's be honest, some devs have in the past done some things that give the impression that conspiracies abound (hint: all the crap surrounding BAS/c aka gentoo-stats, which was a very sorry story indeed). > just no dev who cares enough about cvsnt. Sure, the devs are just too busy caring about things that are on their own personal agendas.
> Sure, the devs are just too busy caring about things that are on their own personal agendas. And what's wrong with that?
OK, I've had enough. Bugzilla is not a chatroom and I'm not interested in receiving pointless bugspam into my mailbox. As comment #40 says, you are not interested in maintaining this ebuild up-to-date any more, and noone from the devs wants to commit and maintain this ebuild. Direct your complaints to Gentoo IRC channels or /dev/null, *not* to bugzilla. CLOSING.
CLOSED
