"William D. Jones" <thor0505%comcast.net@localhost> writes:
> 1. I’m not great with CVS, and learning it has been a frustrating
> experience, to say the last. With regards to “tag aborted”, I’m
> guessing that I’m mixing up portions of the tracking NetBSD wiki
> page. from what I’ve gathered from reading other sites, I cannot
> actually tag my local copy of the source tree since anoncvs is read
> only (as CVS is centralized). I imagine there is a simple way to also
> revert an update in case a daily update breaks the build, but I have
> not found it yet. Do I understand this correctly? What is the purpose
> of importing and merging misc/cvsrep as far as anonymous checkout is
> concerned (as mentioned on the tracking current wiki page)? And, for
> anoncvs, what is the recommended method to revert a broken build after
> notifying netBSD-users via email?
CVS is not a distributed VCS, so you can't apply tags. (Developers
can't apply tags except to the central repo.) So you have a few
choices:
use the git mirror of the netbsd sources:
http://blog.netbsd.org/tnf/entry/fossil_and_git_mirrors_of
https://github.com/jsonn/src
If you need to, do a checkout with -D to fix a particular time.
See
http://releng.netbsd.org/b5reports/i386/
for the history of then the build works. While May wasn't so great,
typically if you update again and build it will have been fixed.
export snapshots and put them in some CVS, perhaps even CVS. Given
Joerg's git mirror, this option doesn't make much sense.
> 2. While I couldn’t find any mention on the NetBSD wiki, OpenBSD
> states on it’s website that all bug reports should be against the
> generic kernel (http://www.openbsd.org/faq/faq5.html#Why). Is that the
> case here as well? My 486 cannot run the generic kernel reliably,
> hence why I ask. If this also means a potential driver developed using
> a custom kernel wouldn’t be accepted, then I will happily buy more RAM
> .
You can file PRs however you like. The question is who will spend time
to address them and integrate it, and the easier you make that the
better. Building your driver against a stripped-down kernel is not a
problem, as none of that should matter. It would be nice to run your
changes against the entire test suite - see tests(7), even if they
shouldn't be affected - the point is to check for unexpected
regressions.
If you can put more RAM in the machine, I would suggest doing it, just
to speed things up. Also if you have a faster machine to build on, that
will make things easier.
> 3. Most of the files I intend to submit will not have been previously
> existing (need to create a number of source files to add the new
> driver to the tree). Is it still recommended I submit as a patch to
> PR? I haven’t actually “told” CVS about the new files yet due to my
> woes with tagging, in fear that I might break the tree... what is the
> best way to add “new files” to the CVS tree for diff/local development
> purposes and without the server choking when they don’t exist
> server-side?
Use "cvs add", and "cvs diff -N".
> 4. After giving up on tagging, I updated my source tree using CVS
> update –dP and built again successfully, as per
> http://www.netbsd.org/docs/guide/en/chap-updating.html#updating-procedure. Is
> running CVS update –dP and build.sh sufficient for rebuilding a
> distribution without having to wait 3 hours for userland to build
> (i.e. build only what changed). Specifically, will the binaries be
> identical or close-to identical as if I ran build.sh from the
> beginning (i.e. without –U)? I see a large number of source files
> beyond those changed in 24 hours being rebuilt, but I’m guessing this
> has to do with how build.sh manages its dependencies.
In theory, yes. In practice, I do this all the time and don't have
trouble except once in a very great while.
Attachment:
pgpFdHGcjm3VV.pgp
Description: PGP signature