[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[snewt,gnewt] New CVS modules created. (Was: Re: [gnewt] Are you using a version control system?)



>>>>> "Jean-Marc" == Jean-Marc Lienher < O'ksi'D > <oksid@bluewin.ch> writes:

    Karl> I downloaded your `gnewt' .deb and the tarfile, and ran `lintian' on
    Karl> the .deb.  It revealed several packaging errors (things in
    Karl> /usr/local/*, &c.) and I thought I'd see if I could help you fix
    Karl> them...

    Jean-Marc> Help is welcome, I'm not realy familiar with packaging.

 Great.  I'll put a little time into that as things progress...

    Karl> Which brings me to the question in the subject line.  Do you keep
    Karl> `gnewt' in a version control repository already?

    Jean-Marc> Actually, no. But I'm planning to do it soon. I should read the 
    Jean-Marc> doc on sourceforge.net (linuxave.net seems not to offer the CVS service)
    Jean-Marc> But managing a CVS repository is not the most exciting job that I've 
    Jean-Marc> ever done, if you can/want to host the CVS or "bk" repository on 
    Jean-Marc> debian.org, you're welcome.

 Ok, and I will manage the repository for you if you like - and will
 communicate about important actions / decisions via the list.

  Well, I cannot get `bk' to work right.  It's too young and unstable
  for everyday use, as great as it sounds from its manuals and
  descriptions.  I'm not going to totally give up on it since it seems
  to offer many advantages over CVS, but will not be using it much for
  now.  I think it can import a CVS repository, so we can convert
  later if we decide to do that, and they have the line-of-development
  support all worked out, etc.

New Modules:
------------
 I've created two new modules in the "debian-boot" CVS repository on
 "cvs.debian.org".  One is `gnewt', with `newt' grafted into it, along
 with `minislang' from Red Hat's `anaconda-7.0'[1].  The other is
 `lrmi', an i386 utility library used for hardware detection.

 I got `lrmi' from it's authors site, after finding it in `anaconda',
 imported it, then applied Red Hat's patches.  The patch is visible in
 the repository, and appears important.  We will make a link library
 from this, I imagine.  I'm not sure what it's for just yet, but know
 it will be required by the `anaconda' version of `libfdisk' which has
 a newtered fdisk editor along with it.  We will port our code to use
 this, I believe.  Tausq?  `lrmi' is used for some sort of pnp monitor
 detection in `anaconda' (and X 4.0, afaict).  Do you know about it? 
 (for xviddetect)

 I had earlier, as I mentioned, imported `newt' to a repository, using
 VENDOR tracking, applying the Debian diff, and then upgrading the
 VENDOR branch from a newer version I found at Red Hat Software, and
 joined that to the trunk (with few conflicts).  I just grafted that
 into the `gnewt' repository (copied to the "gnewt/src/slang/"
 directory) omitting the `debian' subdirectory (which I still have for
 reference) since it's not needed at that level of the tree.

 Below the "gnewt/src/slang/" directory, I grafted in an import of Red
 Hat's `minislang'.  Perhaps if we just link it to `snewt' (for
 `dbootstrap') it will save a few bytes of disk space?  (library
 metadata, etc. would be in only one .so, rather than two, on
 root.bin)

 We now need to see into joining the changes from the other `newt' and
 `slang' trees into this one, to make it support UTF-8, &c.  From then
 on, hopefully, we can work from a consolidated tree.  It would be
 most righteous if the library packages built from this will work with
 all other newtered Woody software... to avoid forking entirely.

 I noticed that there is a slot open in the "gnewt/src/" directory for
 a framebuffer front end.  That one would be a cool little project for
 someone... perhaps O'ksi'D already has plans for that, and perhaps
 some codes written down?  I'm still in the "thinking about it" stage.

Future Plans for all of this:
-----------------------------

 It would be nice if everything we do with this can be sent back to
 the sources from which we have obtained everything in the form of
 diffs and at least read-only CVS access.  (Or `bk' when that's
 working correctly.)


Anon CVS:
---------
 For the uninitiated, the Debian CVS repository is visible via the web
 at <URL:http://cvs.debian.org>.  Read the file `README-CVS' in the
 `boot-floppies' repository for instructions on obtaining anoncvs
 access.

Attn Admins:
------------
 I think that we should allow O'ksi'D read/write access to at least
 `gnewt'.  I think that an account for him should be created on the
 machine, but with an undisclosed password until he has passed through
 the new-maintainer process.  In the home directory of that account,
 in the .ssh/authorized_keys, should be placed his SSH public key,
 prefixed by:

no-X11-forwarding,no-port-forwarding,no-agent-forwarding,command="/usr/bin/cvs --allow-root=/var/cvs/debian-boot server"

 A new group can be created and the `gnewt' repository set to it, and
 all of us added to that group if the administrators feel that to be
 necessary... since the above line would give O'ksi'D writes to almost
 everything in the `debian-boot' repository.  This at least until
 after after his new-maintainer processing has been cleared.


Footnotes: 
[1]  If you've not grabbed `anaconda' and had a look yet, you should.

A few months in the laboratory often saves several hours at the library.
mailto:karlheg@debian.org (Karl M. Hegbloom)
irc: nick karlheg on irc.debian.org



Reply to: