Sunday, December 30, 2012

Adopting some Debian packages?

It looks like some of the Debian packages I am interested in have been Orphaned or put up for Adoption:
  • crashmail O:  I use this one (at least for FTN points) and I have been working on packaging jamnntpd to provide another interface to the JAM message bases that Crashmail II can manage. One big reason for the low popcon for it is that there hasn't been something in Debian that can be used to access them, like jamnntpd (not yet in Debian) or GoldED+ (which used to be in Debian). Requested and was granted membership in the Alioth Crashmail project as an administrator.
  • multimail RFA: I would like that such FTN/Fidonet related applications stay in Debian, so I sent an email changing that to an ITA.  Also found a MultiMail project at SourceForge, although that is not yet reflected in the package. (Requested to be added to the project there.)
  • lha: It was removed 7 June 2012 because:  "outdated non-free binaries". Investigate about getting it back in? It appears it is being kept in Ubuntu, at least for now.)  May need to at least keep a package maintained for my own use.  There are alternative packages that can handle the format, like unar. (Will need to update crashmail Suggests in debian/control.)
A couple of others that I found are:
  • postnews O:
  • uqwk O:
  • Also found that although turqstat (A Fidonet and Usenet statistics program) was removed (as part of the process to keep Qt 3 out of wheezy) from unstable back in May of 2012 and now also isn't in testing.  If it was orphaned back then, I didn't see i ... In part, it was because of things like this?  Because of things like that (just for the X version of the package? which means either command line only or move X version to qt 4), this one may be more work than I'll have time for, especially since it would need an ITP to get it back in... Still, if the Orphan bug can be found (though a quick look didn't turn it up)...

Thursday, December 27, 2012

Project labeling issue at SF

After migrating the MakeNL SF project to their new project code (allura), noticed that the labels for the SVN repository was "Code-1" and the CVS repository was "Cvs".  Tried changing the label for the SVN repository from that "Code-1" to "SVN' but although it didn't give me an error, the label ended up being "Svn" instead.  I went back into the project admin and found that the label is listed there in all caps, so it looks to be something to do with the display of the label rather than the label itself.

Reported the issue:  Was advised in that ticket that it is a known issue that other people have reported and their reference ticket for it is:

MakeNL Project at Sourceforge updated

Updated the MakeNL project at Sourceforge,, to the new Sourceforge project code. Along with other things, this changes the paths to the code repositories (at least for browseing) and the Bug and Feature Request numbering.

One reason updating the project had been delayed was that their original migration code did not migrate CVS repositories;  since currently that is the main development code repository, that meant that we did not want to do the migration until either that changed or we had a chance to migrate the CVS repository over to another type of repository like SVN or GIT that all of the developers have the tools to be able to use.

A GIT repository is going to be available but an initial migration needs to be done again from the CVS repository;  the intent is to maintain that link between the CVS repository and the GIT code repository.
I will be doing the development of Debian packaging there, instead of using the CVS repository for that like I  used to.

An SVN repository was started with the import of a couple of older archives.  Migrating the CVS repository to the SVN repository, either using the existing one or a new one, has not been done but there is a feature request for it. (Since the CVS repository was migrated to the new SF project, it isn't as necessary to do .)