Please find attached cvsnt-220.127.116.117.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,
Created attachment 48207 [details]
Created attachment 48208 [details]
Created attachment 48209 [details]
Created attachment 48210 [details]
Created attachment 48211 [details]
What about using system-auth in pam instead of winbind/unix?
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]
updated cvs.pam (wrt comment #6)
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-18.104.22.1682.ebuild to get the latest bleeding edge release
Bump to dev-util/cvsnt-22.214.171.1242.ebuild to get the latest testing release...
But keep the original ebuild (cvsnt-126.96.36.1997.ebuild) for a slightly less bleeding-edge release.
Bumping to 2.5.01.1927
Created attachment 57706 [details]
Created attachment 57707 [details]
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]
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
Created attachment 59611 [details]
Latest testing release: CVSNT 2.5.01.1973 (Friday 20th May 2005)
Created attachment 59943 [details]
bump toCVSNT 2.5.01.1976 (Monday 23rd May 2005)
Created attachment 60358 [details]
patch for the Unknown expansion option '
Created attachment 60358 [details]
patch for the Unknown expansion option ' æ' problem
Created attachment 60359 [details]
modded to patch build 1976 to rid the annoying Unknown expansion option '
Created attachment 60359 [details]
modded to patch build 1976 to rid the annoying Unknown expansion option ' æ'
Created attachment 60538 [details]
bump for build 1986
Created attachment 60780 [details]
Bump for build 2.5.01.1990
Created attachment 61277 [details]
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]
patch to go with build 1998
Created attachment 61302 [details]
Patches cvs.dbk to correct invalid link
Created attachment 61303 [details]
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
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]
Created attachment 62244 [details]
Created attachment 63139 [details]
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]
Created attachment 64955 [details]
Bump for 2.5.02 (Servalan) Build 2047 (Release Candidate 2)
Created attachment 65018 [details]
bump for 2.5.02.2048
Created attachment 66085 [details]
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
rsync -rztp --delete
to get them into your local portage tree.
(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
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
> for maintainer-wanted since we don't work with anything except attached
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
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
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)
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
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
Direct your complaints to Gentoo IRC channels or /dev/null, *not* to bugzilla.