This is the mail archive of the cygwin-apps mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ITP] task-1.7.1-1 (pinging for awaiting review)

Federico Hernandez wrote:

> Great news about the task package for 1.5. As you have mentioned that
> it is GTG - will you upload it then and when. I just ask so that the
> upstream prpject could inform users about this.

  The normal procedure (see "Package acceptation") is that after getting a GTG
for your new package, you send an RFU separately and then whichever of cgf and
corinna gets to it first uploads.  I'm not sure it would be right for the
reviewer to go ahead and upload it directly - having a second pair of eyes
helps catch anything the reviewer might have missed, like for instance this:

> # setup.hint for task 1.7.1-1
> category: Utils
> requires: libncurses9
> sdesc: A command-line to do list manager
> ldesc: "Task is a command-line to do list manager.
> It has support for GTD functionality and includes
> the following features: tags, colorful tabular output,
> reports and graphs, lots of manipulation commands,
> low-level API, abbreviations for all commands and
> options, multiuser file locking, recurring tasks."

  I think you should replace "to do list" by "to-do list" or maybe "TO-DO
list" throughout :-)

> Now regarding 1.7:
>>  This appears to be intentional behaviour on the part of cygport at first
>> glance.

> As I saw this 2 DOCDIRS I thought that cygport has changed from 1.5 to
> 1.7 and looked around other packages how they get installed in cygwin
> 1.7 - for example wget. This one puts everything into
> /usr/share/doc/wget. So I assumed that this is the new "standard" to
> omit the version number of the package.

  It does seem to be.  I looked at /usr/share/doc and saw a lot of packages
that did have versions and a lot that didn't; but now I try again (using 'ls
-rt' this time) I see that it tends to be older packages that haven't been
updated in a while.

> Since the upstream project choosed to install the documentation in a
> "versioned" DOCDIR I decided that I had to add the PKG_* and DOCS
> definitions to the cygport file to as well have an unversioned DOCDIR
> for task like the other packages in cygwin 1.7.

  This seems right, but I noticed a couple of hints that suggest it isn't
working right.  First off, during the build, I see that the configure line
includes "--docdir=/usr/share/doc/task"; but after the build, the docs end up
in .../doc/task-1.7.1, which is strange.  And the technique of using a tar
--exclude option in PKG_CONTENTS[0] causes a warning from cygport when it is
surprised to find the excluded files didn't end up in the tarball:

>>>> Checking packages for missing or duplicate files
> *** Warning: Packages are missing files:
> -usr/share/doc/task-1.7.1/AUTHORS
> -usr/share/doc/task-1.7.1/COPYING
> -usr/share/doc/task-1.7.1/ChangeLog
> -usr/share/doc/task-1.7.1/INSTALL
> -usr/share/doc/task-1.7.1/NEWS
> -usr/share/doc/task-1.7.1/README
> -usr/share/doc/task-1.7.1/
>>>> Creating source patches

  I am led to wonder if there is some different behaviour between autoconf
versions that is confusing cygport.

> How should we proceed. Is the package otherwise OK? Apart for this. Do
> you want me to change something else?

  The package is fundamentally OK.  I recommend changing the wording of
setup.hint as suggested above, for both 1.5 and 1.7 versions, but it's only a
minor nicety, not critical.  So for the docs, there are three things we could
conceivably do:

1) Nothing.  Live with the warning, and assume the lack of versions on the
README and docs/task dir are the correct thing to do.  (We should have a quick
google through the list archives and see if we can find a post discussing this

2) Remove the PKG_* and DOCS definitions from your cygport, and add a line


  This gets us a package in the 1.5 style, with versioned Cygwin/README and
doc/ dirs.

3) Wait a while and see if Yaakov (cygport maintainer) can help us out here.

  I'll try a build using autoconf-2.61 instead of -2.63 and see if that makes
any difference.

> PS I have another question: For the future how would updates/new
> version of the package be handled. As I have seen I would post a RFU
> (Request for update) to this mailinglist. Is that correct?

  Yep, apart from the "U" stands for "Upload", not "Update!"  See the section
"Updating a package" at the URL I linked above, and


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]