[ITA] Git et al

[ITA] Git et al

[Adam Dinwoodie]

Our Git package hasn't been updated in a long time. Although its
maintainer, Eric Blake, has been on the mailing lists, I don't think
he's done any work in keeping Git up-to-date (including replying to a
number of requests for updates), so I'd like to offer to take over.

I've just built and packaged the latest released version -- 1.8.5.2 --
and have the packages ready to upload for both x86 and x86_64. I've
incorporated the enhancements Yaakov made for the Cygwin Ports version
(including splitting some of the packages), as well as some minor
fixes to resolve differences between the latest Cygwin Ports version
and the latest upstream.

I'm thus offering to take over the following existing packages:
- git
- git-completion
- git-svn
- gitk

I'll also be adding the following packages, which are split out of the
main git package:
- git-cvs
- git-debuginfo
- git-email
- git-gui
- gitweb

Following http://cygwin.com/setup.html, I've copied the assorted
setup.hint files below and uploaded the packages to
http://tastycake.net/~adam/git. I've uploaded as .xz bundles, on the
grounds that (a) that's what Cygport created, and (b) that's what's
used in the examples at [1]. Let me know if the contribution guide is
still correct and I need to repackage as bzip2 tarballs.

[1]: https://sourceware.org/cygwin-apps/package-upload.html

I've also copied my upload SSH key at the bottom of this email. I've
not included it in a normal upload request email yet, since I'm not
currently maintaining any packages. I'll send it in a separate email
if and when I get approved as maintainer, if necessary.

Adam

git/setup.hint
category: Devel
requires: bash libgcc1 libiconv2 perl perl-Error perl_vendor python
zlib0 cygutils less openssh rsync
sdesc: "Distributed version control system"
ldesc: "Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with speed and
efficiency. Git is easy to learn and has a tiny footprint with lightning fast
performance. It outclasses SCM tools like Subversion, CVS, Perforce, and
ClearCase with features like cheap local branching, convenient staging areas,
and multiple workflows."

git-completion/setup.hint
category: Devel
requires:  bash bash-completion git
sdesc: "Bash completion for Git version control system"
ldesc: "Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with speed and
efficiency. Git is easy to learn and has a tiny footprint with lightning fast
performance. It outclasses SCM tools like Subversion, CVS, Perforce, and
ClearCase with features like cheap local branching, convenient staging areas,
and multiple workflows."
external-source: git

git-cvs/setup.hint
category: Devel
requires: git perl cvsps perl-DBD-SQLite
sdesc: "CVS compatibilty support for Git version control system"
ldesc: "Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with speed and
efficiency. Git is easy to learn and has a tiny footprint with lightning fast
performance. It outclasses SCM tools like Subversion, CVS, Perforce, and
ClearCase with features like cheap local branching, convenient staging areas,
and multiple workflows."
external-source: git

git-debuginfo/setup.hint
category: Debug
requires: cygwin-debuginfo
external-source: git
sdesc: "Debug info for git"
ldesc: "This package contains files necessary for debugging the
git package with gdb."

git-email/setup.hint
category: Devel
requires: git perl perl-Error
sdesc: "Email tools for Git version control system"
ldesc: "Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with speed and
efficiency. Git is easy to learn and has a tiny footprint with lightning fast
performance. It outclasses SCM tools like Subversion, CVS, Perforce, and
ClearCase with features like cheap local branching, convenient staging areas,
and multiple workflows."
external-source: git

git-gui/setup.hint
category: Devel
requires: bash tcl-tk git gitk
sdesc: "Graphical interface for Git version control system"
ldesc: "Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with speed and
efficiency. Git is easy to learn and has a tiny footprint with lightning fast
performance. It outclasses SCM tools like Subversion, CVS, Perforce, and
ClearCase with features like cheap local branching, convenient staging areas,
and multiple workflows."
external-source: git

gitk/setup.hint
category: Devel
requires: bash tcl-tk git
sdesc: "Git repository browser"
ldesc: "Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with speed and
efficiency. Git is easy to learn and has a tiny footprint with lightning fast
performance. It outclasses SCM tools like Subversion, CVS, Perforce, and
ClearCase with features like cheap local branching, convenient staging areas,
and multiple workflows."
external-source: git

git-svn/setup.hint
category: Devel
requires: git perl perl_vendor
sdesc: "Subversion compatibility support for Git version control system"
ldesc: "Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with speed and
efficiency. Git is easy to learn and has a tiny footprint with lightning fast
performance. It outclasses SCM tools like Subversion, CVS, Perforce, and
ClearCase with features like cheap local branching, convenient staging areas,
and multiple workflows."
external-source: git

gitweb/setup.hint
category: Devel
requires: bash perl ruby git lighttpd
sdesc: "Web interface for Git version control system"
ldesc: "Git is a free and open source distributed version control system
designed to handle everything from small to very large projects with speed and
efficiency. Git is easy to learn and has a tiny footprint with lightning fast
performance. It outclasses SCM tools like Subversion, CVS, Perforce, and
ClearCase with features like cheap local branching, convenient staging areas,
and multiple workflows."
external-source: git

Name: Adam Dinwoodie
Package: git
---- BEGIN SSH2 PUBLIC KEY ----
AAAAB3NzaC1yc2EAAAADAQABAAACAQDQWpZlqxcfJ0Ke9XT/NT2WTKN3wLJR516Pg0o3TC
NXdc0VgZpb74vGGHVWm1LPj6+o5LQQ+TqyBwZ3KFpB6hUGwMpmU19/MvtE5cWnfT8gPAv5
h1CIFT0X6+kz9NEemZhJRAXgp65oJUObsb8i+9jl+trr6YNcJUhgLBrTVa25lczNY1c795
3Kj19z8iUSMZ7JIPu45l5YD7Y74hpWjXr1YyJo6D58SLAQ2y27muy0/yH9PNc9YGKuiHv/
mRrZaqLGzxnGoH8asc8NhJrMC55f0gdOkAkn10oVozWPJXg6L6JtXuI6SukEg/M5SpQkTS
I2bJVOleobCzTA0/cFJMeQ67Zul3bubszCPCSzUCO3QClS8YRWvkMrlGDP4/+qW4u8VjCD
/+UB4Wn6f5s/zCcv3ESnvul8N9A4eRcxyY7aom6iYc5YYkd4d9J6j3Sf0S9w7CQau0sAZP
LpJcW6FrmHHXY09hnPE2wz4eERO9BTimp4wb1CJCLFXSqrAQIN09eDncPhHjeqKiODWSaY
nRUsNIV1cXPQLIZuyTmNGc/A1KAypNBSwDGivihACt7fiAA4Qdpn4w7dYrci6TjEmDBx18
xu7UKrW/1XPp8SJFySbrACKHHi017T4BYkgpjMWfTs4w/KyX6VJ1/1kMP5W30Y3IGkGJzh
MiJHJyu/dt408Q==
---- END SSH2 PUBLIC KEY ----

Re: [ITA] Git et al

[Adam Dinwoodie]

On 11 January 2014 20:01, Adam Dinwoodie wrote:
> Following http://cygwin.com/setup.html, I've copied the assorted
> setup.hint files below and uploaded the packages to
> http://tastycake.net/~adam/git.

Correction: http://tastycake.net/~adam/cygwin/

Re: [ITA] Git et al

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

On Jan 11 20:01, Adam Dinwoodie wrote:
> Our Git package hasn't been updated in a long time. Although its
> maintainer, Eric Blake, has been on the mailing lists, I don't think
> he's done any work in keeping Git up-to-date (including replying to a
> number of requests for updates), so I'd like to offer to take over.

Thanks for the offer, but let's wait for Eric.  He seems to be very
busy these days.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [ITA] Git et al

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]

On 01/11/2014 01:01 PM, Adam Dinwoodie wrote:
> Our Git package hasn't been updated in a long time. Although its
> maintainer, Eric Blake, has been on the mailing lists, I don't think
> he's done any work in keeping Git up-to-date (including replying to a
> number of requests for updates), so I'd like to offer to take over.

While I'm not completely gone from cygwin, and while it is unusual for
someone to forcefully take over a package while the current maintainer
is still around, this is one case where I'm willing to give up my
maintainership.  There are some packages I still maintain (like
coreutils) where there are cygwin-specific patches that I want to ensure
still work across multiple cygwin versions and where I still actively
maintain efforts for those projects upstream; but when it comes to git,
I only originally volunteered for maintainer status because it built out
of the box and was needed for my work on upstream coreutils, and I am
not a very active upstream git contributor.  In short, git is a big
enough project and my cygwin time limited enough that I have not been
able to maintain it well, so I hope you can do a better job with keeping
the cygwin port up-to-date.  That said, while I don't have as much time
for cygwin packaging, I still DO plan on using git on cygwin, so I at
least want to make sure my use cases still work when upgrading to the
build you just provided before we actually upload it.

> 
> Following http://cygwin.com/setup.html, I've copied the assorted
> setup.hint files below and uploaded the packages to
> http://tastycake.net/~adam/git. I've uploaded as .xz bundles, on the

It may still be a few days before I can test that your new packaging
works for me (I'd welcome a review from anyone else as well), but the
overall idea of adopting the package from me seems reasonable.

I also wonder if you would be willing to adopt asciidoc, as the only
reason I took that package was to build git documentation out-of-the-box
(I have never personally used it except for building git).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [ITA] Git et al

[Adam Dinwoodie]

On 13 January 2014 21:32, Eric Blake wrote:
> On 01/11/2014 01:01 PM, Adam Dinwoodie wrote:
>> Our Git package hasn't been updated in a long time. Although its
>> maintainer, Eric Blake, has been on the mailing lists, I don't think
>> he's done any work in keeping Git up-to-date (including replying to a
>> number of requests for updates), so I'd like to offer to take over.
>
> While I'm not completely gone from cygwin, and while it is unusual for
> someone to forcefully take over a package while the current maintainer
> is still around,

When I first concocted this plan about six months ago, if memory serves,
you hadn't been active for a while.  You since have, and I should have
asked you before proposing myself.  Even if it works out with everyone
happy, I'm sorry for the rudeness.

> this is one case where I'm willing to give up my maintainership.
> There are some packages I still maintain (like coreutils) where there
> are cygwin-specific patches that I want to ensure still work across
> multiple cygwin versions and where I still actively maintain efforts
> for those projects upstream; but when it comes to git, I only
> originally volunteered for maintainer status because it built out of
> the box and was needed for my work on upstream coreutils, and I am not
> a very active upstream git contributor.

In honesty, I'm not sure how much time I'm going to be able to devote to
contributing upstream.  I've had a bit of a dig in the Git code, but
I've not actively pushed anything upstream yet.

> In short, git is a big enough project and my cygwin time limited
> enough that I have not been able to maintain it well, so I hope you
> can do a better job with keeping the cygwin port up-to-date.  That
> said, while I don't have as much time for cygwin packaging, I still DO
> plan on using git on cygwin, so I at least want to make sure my use
> cases still work when upgrading to the build you just provided before
> we actually upload it.
>
> It may still be a few days before I can test that your new packaging
> works for me (I'd welcome a review from anyone else as well), but the
> overall idea of adopting the package from me seems reasonable.

There's already a known, fairly major problem with my build, reported by
Steven Penny[0].  I'm hoping to get a fix to that out tomorrow evening.

[0]: http://cygwin.com/ml/cygwin/2014-01/msg00086.html

> I also wonder if you would be willing to adopt asciidoc, as the only
> reason I took that package was to build git documentation out-of-the-box
> (I have never personally used it except for building git).

I'd only be using it for Git as well, but assuming it builds
out-of-the-box, I don't see any reason why not.

Re: [ITA] Git et al

[Adam Dinwoodie]

On 13 January 2014 23:58, Adam Dinwoodie wrote:
> On 13 January 2014 21:32, Eric Blake wrote:
>> That said, while I don't have as much time for cygwin packaging, I
>> still DO plan on using git on cygwin, so I at least want to make sure
>> my use cases still work when upgrading to the build you just provided
>> before we actually upload it.
>>
>> It may still be a few days before I can test that your new packaging
>> works for me (I'd welcome a review from anyone else as well), but the
>> overall idea of adopting the package from me seems reasonable.
>
> There's already a known, fairly major problem with my build, reported by
> Steven Penny[0].  I'm hoping to get a fix to that out tomorrow evening.
>
> [0]: http://cygwin.com/ml/cygwin/2014-01/msg00086.html

There's a new build available at http://tastycake.net/~adam/cygwin/
which resolves that issue.  If you want to give it a try and let me know
how you get on, I'd be exceedingly grateful.

Re: [ITA] Git et al

[Balaji Venkataraman]

On Wed, Jan 15, 2014 at 3:06 AM, Adam Dinwoodie wrote:

> There's a new build available at http://tastycake.net/~adam/cygwin/
> which resolves that issue.  If you want to give it a try and let me know
> how you get on, I'd be exceedingly grateful.

I tried to add the path above to the list of mirrors in setup-x86.exe.
Is that how you are expecting folks to get your build? It seemed to
find setup.ini but just hung there for a while after which I gave up.
Not sure if it's a firewall problem on my end (which I doubt - since I
access other Cygwin mirrors routinely from behind the FW) or a server
problem or PEBCAK. Thanks.

Re: [ITA] Git et al

[Christopher Faylor]

On Fri, Jan 17, 2014 at 10:42:52AM -0800, Balaji Venkataraman wrote:
>On Wed, Jan 15, 2014 at 3:06 AM, Adam Dinwoodie wrote:
>>There's a new build available at http://tastycake.net/~adam/cygwin/
>>which resolves that issue.  If you want to give it a try and let me
>>know how you get on, I'd be exceedingly grateful.
>
>I tried to add the path above to the list of mirrors in setup-x86.exe.
>Is that how you are expecting folks to get your build?  It seemed to
>find setup.ini but just hung there for a while after which I gave up.
>Not sure if it's a firewall problem on my end (which I doubt - since I
>access other Cygwin mirrors routinely from behind the FW) or a server
>problem or PEBCAK.  Thanks.

No, that's not intended to be a setup.exe download.

If you don't know what the above link was for then you are not the
target audience for it.

cgf

Re: [ITA] Git et al

[Balaji Venkataraman]

On Fri, Jan 17, 2014 at 10:48 AM, Christopher Faylor wrote:

> On Fri, Jan 17, 2014 at 10:42:52AM -0800, Balaji Venkataraman wrote:
>>On Wed, Jan 15, 2014 at 3:06 AM, Adam Dinwoodie wrote:

> No, that's not intended to be a setup.exe download.

Before I tried using it w/ setup.exe, I did notice that the folders
contain tar files, which I can download and untar but if that was how
one is expected to get it, a direct pointer to the file would have
sufficed. Perhaps that was the intent but I thought I should check if
setup.exe could be used. Thanks for clarifying.

Re: [ITA] Git et al

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]

On 01/15/2014 04:06 AM, Adam Dinwoodie wrote:
> On 13 January 2014 23:58, Adam Dinwoodie wrote:
>> On 13 January 2014 21:32, Eric Blake wrote:
>>> That said, while I don't have as much time for cygwin packaging, I
>>> still DO plan on using git on cygwin, so I at least want to make sure
>>> my use cases still work when upgrading to the build you just provided
>>> before we actually upload it.
>>>
>>> It may still be a few days before I can test that your new packaging
>>> works for me (I'd welcome a review from anyone else as well), but the
>>> overall idea of adopting the package from me seems reasonable.
>>
>> There's already a known, fairly major problem with my build, reported by
>> Steven Penny[0].  I'm hoping to get a fix to that out tomorrow evening.
>>
>> [0]: http://cygwin.com/ml/cygwin/2014-01/msg00086.html
> 
> There's a new build available at http://tastycake.net/~adam/cygwin/
> which resolves that issue.  If you want to give it a try and let me know
> how you get on, I'd be exceedingly grateful.

I've now had a chance to test this, and at least my use cases worked.  I
can't say I used ALL of git functionality, but what I did use shows that
your build is good.  Let's go ahead and pass the maintainer baton.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: [ITA] Git et al

[Adam Dinwoodie]

On Fri, Jan 24, 2014 at 07:25:32AM -0700, Eric Blake wrote:
> On 01/15/2014 04:06 AM, Adam Dinwoodie wrote:
> > There's a new build available at http://tastycake.net/~adam/cygwin/
> > which resolves that issue.  If you want to give it a try and let me know
> > how you get on, I'd be exceedingly grateful.
>
> I've now had a chance to test this, and at least my use cases worked.  I
> can't say I used ALL of git functionality, but what I did use shows that
> your build is good.  Let's go ahead and pass the maintainer baton.

I have an outstanding issue with the packaging I've just spotted --
git-cvs relies on perl-DBD-SQLite, which doesn't exist.  I suspect this
is a result of taking Yaakov's cygport files.  I've not used Git's CVS
tools before, so it might take me a little while to work out whether the
problems I'm seeing are the result of missing packages, PEBCAK or
something else.

Thinking about it, my build and packages take Yaakov's work over at
Cygwin Ports to split the Git packages (at the moment, git-cvs is part
of the main git package, for example, while my build separates it out).
I know there have been debates about this in the past; is there
currently any guideline about the best way to manage such package
splits?

Re: [ITA] Git et al

[Yaakov (Cygwin/X)]

On 2014-01-29 05:53, Adam Dinwoodie wrote:
> I have an outstanding issue with the packaging I've just spotted --
> git-cvs relies on perl-DBD-SQLite, which doesn't exist.

More specifically, there has been one for x86_64 since I built 
git.x86_64 during the bootstrap, but I see now that I didn't add it for 
x86.  I just uploaded an x86 package.

But along these lines, git-email also needs a few Perl modules which are 
not yet available for x86; I'll proceed with those as well, hopefully 
tonight.

> Thinking about it, my build and packages take Yaakov's work over at
> Cygwin Ports to split the Git packages (at the moment, git-cvs is part
> of the main git package, for example, while my build separates it out).
> I know there have been debates about this in the past; is there
> currently any guideline about the best way to manage such package
> splits?

I'm not sure to what debates you are referring, but the point of the 
split was to provide correct dependencies while isolating those to the 
components that actually need them.  This was already done with the more 
obvious tcl-tk dependency of gitk and git-gui, but my packages took it a 
step further.  So, for example, git-svn actually requires 
subversion-perl, but subversion is not small and not all git users are 
going to want that just in order to use git.


Yaakov

Re: [ITA] Git et al

[Adam Dinwoodie]

On Wed, Jan 29, 2014 at 10:54:27AM -0600, Yaakov (Cygwin/X) wrote:
> On 2014-01-29 05:53, Adam Dinwoodie wrote:
> >Thinking about it, my build and packages take Yaakov's work over at
> >Cygwin Ports to split the Git packages (at the moment, git-cvs is part
> >of the main git package, for example, while my build separates it out).
> >I know there have been debates about this in the past; is there
> >currently any guideline about the best way to manage such package
> >splits?
> 
> I'm not sure to what debates you are referring, but the point of the
> split was to provide correct dependencies while isolating those to
> the components that actually need them.  This was already done with
> the more obvious tcl-tk dependency of gitk and git-gui, but my
> packages took it a step further.  So, for example, git-svn actually
> requires subversion-perl, but subversion is not small and not all
> git users are going to want that just in order to use git.

I seem to recall there being some discussion (I can't remember the
specific cases) about whether it would be sensible to have, for at least
the first release after a split, all the new packages depending on the
thinned down base one.

As an example, someone using git-cvs currently would only have the git
package.  If we list git-cvs as a requirement for the new git package,
when they upgrade git they'll automatically get git-cvs and won't lose
any functionality.  The following update can lose the git-cvs
requirement, giving the full advantage of the separated packages.

I think this makes things a bit more user friendly, at least for folk
who need the separated-out packages and who update their Cygwin setup
frequently, at the expense of postponing a lot of the advantage of those
separated out packages.

Re: [ITA] Git et al

[Yaakov (Cygwin/X)]

On 2014-01-29 11:07, Adam Dinwoodie wrote:
> I seem to recall there being some discussion (I can't remember the
> specific cases) about whether it would be sensible to have, for at least
> the first release after a split, all the new packages depending on the
> thinned down base one.
>
> As an example, someone using git-cvs currently would only have the git
> package.  If we list git-cvs as a requirement for the new git package,
> when they upgrade git they'll automatically get git-cvs and won't lose
> any functionality.  The following update can lose the git-cvs
> requirement, giving the full advantage of the separated packages.

That's what announcements are for, and for those who don't read them, 
postponing the change isn't going to help.


Yaakov

Re: [ITA] Git et al

[Achim Gratz]

Yaakov (Cygwin/X) writes:
> On 2014-01-29 05:53, Adam Dinwoodie wrote:
>> I have an outstanding issue with the packaging I've just spotted --
>> git-cvs relies on perl-DBD-SQLite, which doesn't exist.
>
> More specifically, there has been one for x86_64 since I built
> git.x86_64 during the bootstrap, but I see now that I didn't add it
> for x86.  I just uploaded an x86 package.

Does it use the system SQLite and if so, does it run the tests cleanly?
I'm building that package locally against the installed libraries and
I've been getting "UNIQUE constraint" errors from the test suite since
the 3.8.x version of SQLite has landed.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: [ITA] Git et al

[Jan Nijtmans]

2014-01-29 Achim Gratz <Stromeko@nexgo.de>:
> Does it use the system SQLite and if so, does it run the tests cleanly?
> I'm building that package locally against the installed libraries and
> I've been getting "UNIQUE constraint" errors from the test suite since
> the 3.8.x version of SQLite has landed.

SQLite 3.7.17 is still available, and SQLite 3.8.3
(beta) is available as test package. Especially
3.7.17 is meant to be able to verify such
kinds of possible regressions.

Does this 3.7.17 work well with git? If so, this
looks like a regression which should be
reported to the SQLite developers. If there
is anything I can do to help, let me know.
Version 3.8.3 will come out soon.

Regards,
      Jan Nijtmans

Re: [ITA] Git et al

[Achim Gratz]

Jan Nijtmans writes:
> Does this 3.7.17 work well with git? If so, this
> looks like a regression which should be
> reported to the SQLite developers. If there
> is anything I can do to help, let me know.
> Version 3.8.3 will come out soon.

I haven't had time yet to look into what the test error with DBD::SQLite
really is.  It could be some feature that used to be enabled by default
but now isn't (or the other way around) or just that an error message
expected by the test is formatted differently.  I started building the
module against the system library rather than the included (older)
SQLite amalgamation due to the well known locking problems when
interacting with concurrent access to the same database.

As for git, I don't use git-cvs so it's hard to tell if those test
errors translate into any problem at all.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: [ITA] Git et al

[Yaakov Selkowitz]

On 2014-01-11 14:01, Adam Dinwoodie wrote:
> Our Git package hasn't been updated in a long time. Although its
> maintainer, Eric Blake, has been on the mailing lists, I don't think
> he's done any work in keeping Git up-to-date (including replying to a
> number of requests for updates), so I'd like to offer to take over.

I haven't seen any progress on this for some time.  Adam, are you still 
working on this, and if so, what issues still remain?


Yaakov

Re: [ITA] Git et al

[Adam Dinwoodie]

On Tue, Jun 10, 2014 at 05:00:00PM -0500, Yaakov Selkowitz wrote:
> On 2014-01-11 14:01, Adam Dinwoodie wrote:
> >Our Git package hasn't been updated in a long time. Although its
> >maintainer, Eric Blake, has been on the mailing lists, I don't think
> >he's done any work in keeping Git up-to-date (including replying to a
> >number of requests for updates), so I'd like to offer to take over.
> 
> I haven't seen any progress on this for some time.  Adam, are you
> still working on this, and if so, what issues still remain?

In theory I'm still working on this; in practice I haven't had time to
devote to it in a while.  I'd (perhaps naively) assumed it would mostly
Just Work(TM), which turned out not to be the case.

The only outstanding issue with my build is that git-cvs wasn't working.
That seemed to be down to my build environment, as my attempts to build
the source code available via the Cygwin mirrors showed the same
behaviour, but those binaries work as expected.

I'm considering this a deal breaker since the official way to get the
current Cygwin source code is via CVS.  If I hadn't fixed it by the time
the Cygwin source moves to Git, I was going to suggest moving to the
up-to-date Git build (or more likely, a fresh build of the latest and
greatest upstream version) and accepting that while git-cvs wouldn't
work, that would no longer affect a significant proportion of people.

Re: [ITA] Git et al

[Achim Gratz]

Adam Dinwoodie writes:
> The only outstanding issue with my build is that git-cvs wasn't working.
> That seemed to be down to my build environment, as my attempts to build
> the source code available via the Cygwin mirrors showed the same
> behaviour, but those binaries work as expected.

What's the version of cvsimport you've got installed?  Git needs 2.x.

> I'm considering this a deal breaker since the official way to get the
> current Cygwin source code is via CVS.  If I hadn't fixed it by the time
> the Cygwin source moves to Git, I was going to suggest moving to the
> up-to-date Git build (or more likely, a fresh build of the latest and
> greatest upstream version) and accepting that while git-cvs wouldn't
> work, that would no longer affect a significant proportion of people.

Where's the cygport file for that?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: [ITA] Git et al

[Achim Gratz]

Achim Gratz writes:
> What's the version of cvsimport you've got installed?  Git needs 2.x.

Sorry, I meant cvsps, not cvsimport.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: [ITA] Git et al

[Yaakov Selkowitz]

On 2014-06-10 17:36, Adam Dinwoodie wrote:
> On Tue, Jun 10, 2014 at 05:00:00PM -0500, Yaakov Selkowitz wrote:
>> On 2014-01-11 14:01, Adam Dinwoodie wrote:
>>> Our Git package hasn't been updated in a long time. Although its
>>> maintainer, Eric Blake, has been on the mailing lists, I don't think
>>> he's done any work in keeping Git up-to-date (including replying to a
>>> number of requests for updates), so I'd like to offer to take over.
>>
>> I haven't seen any progress on this for some time.  Adam, are you
>> still working on this, and if so, what issues still remain?
>
> In theory I'm still working on this; in practice I haven't had time to
> devote to it in a while.  I'd (perhaps naively) assumed it would mostly
> Just Work(TM), which turned out not to be the case.
>
> The only outstanding issue with my build is that git-cvs wasn't working.
> That seemed to be down to my build environment, as my attempts to build
> the source code available via the Cygwin mirrors showed the same
> behaviour, but those binaries work as expected.

Are you only testing this with the Cygwin CVS repo?  Have you tried this 
with any other repos?  For example:

:pserver:anoncvs@cygwin.com:/cvs/cygwin-apps setup (Cygwin setup)
:pserver:anoncvs@cygwin.com:/cvs/cygwin htdocs (Cygwin website)


Yaakov

Re: [ITA] Git et al

[Adam Dinwoodie]

On Tue, Jun 10, 2014 at 11:20:41PM -0500, Yaakov Selkowitz wrote:
> On 2014-06-10 17:36, Adam Dinwoodie wrote:
> >The only outstanding issue with my build is that git-cvs wasn't working.
> >That seemed to be down to my build environment, as my attempts to build
> >the source code available via the Cygwin mirrors showed the same
> >behaviour, but those binaries work as expected.
> 
> Are you only testing this with the Cygwin CVS repo?  Have you tried
> this with any other repos?  For example:
> 
> :pserver:anoncvs@cygwin.com:/cvs/cygwin-apps setup (Cygwin setup)
> :pserver:anoncvs@cygwin.com:/cvs/cygwin htdocs (Cygwin website)

I've just dusted off this job, and although I was still unable to get
Git v1.8.5.2 working, bumping up to the latest v2.0.2 has had
considerably more success.

There are a few things to iron out yet: I've only checked the 32-bit
build so far, and I'm using a borrowed computer at the moment so I need
to make sure I can recreate the results on my machine.  I've also only
done very mainline testing thus far on this build, although the test
suite is running as I write this email.

I've still not been able to clone the Cygwin source code from CVS --
I've been testing by cloning the cygwin-apps repo Yaakov referenced
above -- but the errors look like a version incompatibility, and I don't
think there's much I can do about that.  If someone who knows more about
CVS and Git could take a look at the output and confirm that hypothesis,
I'd be grateful:

    $ git cvsimport -v -d :pserver:anoncvs@cygwin.com:/cvs/src src
    Initialized empty Git repository in /home/add/test/.git/
    Running cvsps...
    WARNING: malformed CVS version str: Server:
    WARNING: Your CVS client version:
    [Client: Concurrent Versions System (CVS) 1.12.13 (client/server)]
    and/or server version:
    [Server: ]
    are too old to properly support the rlog command.
    This command was introduced in 1.11.1.  Cvsps
    will use log instead, but PatchSet numbering
    may become unstable due to pruned empty
    directories.

    cvs [log aborted]: reading from server: Connection reset by peer
    DONE; creating master branch
    fatal: refs/heads/origin: not a valid SHA1
    fatal: master: not a valid SHA1
    fatal: You are on a branch yet to be born
    checkout failed: 32768

As I say, the cvsimport of the cygwin-apps repo is going just fine, so I
don't think this is a fundamental problem with my build any more.
Fingers crossed for an up-to-date Git release soon.

Re: [ITA] Git et al

[Christopher Faylor]

On Sat, Jul 19, 2014 at 08:29:41AM +0100, Adam Dinwoodie wrote:
>I've still not been able to clone the Cygwin source code from CVS --
>I've been testing by cloning the cygwin-apps repo Yaakov referenced
>above -- but the errors look like a version incompatibility, and I don't
>think there's much I can do about that.  If someone who knows more about
>CVS and Git could take a look at the output and confirm that hypothesis,
>I'd be grateful:
>
>    $ git cvsimport -v -d :pserver:anoncvs@cygwin.com:/cvs/src src
>    Initialized empty Git repository in /home/add/test/.git/
>    Running cvsps...
>    WARNING: malformed CVS version str: Server:
>    WARNING: Your CVS client version:
>    [Client: Concurrent Versions System (CVS) 1.12.13 (client/server)]
>    and/or server version:
>    [Server: ]
>    are too old to properly support the rlog command.
>    This command was introduced in 1.11.1.  Cvsps
>    will use log instead, but PatchSet numbering
>    may become unstable due to pruned empty
>    directories.
>
>    cvs [log aborted]: reading from server: Connection reset by peer
>    DONE; creating master branch
>    fatal: refs/heads/origin: not a valid SHA1
>    fatal: master: not a valid SHA1
>    fatal: You are on a branch yet to be born
>    checkout failed: 32768
>
>As I say, the cvsimport of the cygwin-apps repo is going just fine, so I
>don't think this is a fundamental problem with my build any more.
>Fingers crossed for an up-to-date Git release soon.

Thanks for looking into this again.  FWIW, the CVS on sourceare.org/cygwin.com
is cvs-1.11.23-16.el6.x86_64.  I've used it to import Cygwin's CVS into git
so I know that it is possible.  There is a limitation on cvsps though.  As I
understand it newer versions don't work with git.  cvsimport also only works
with cvsps v2 but that shouldn't be a problem since that's what we've got
in Cygwin.

cgf

Re: [ITA] Git et al

[David Rothenberger]

On 7/19/2014 12:29 AM, Adam Dinwoodie wrote:
> On Tue, Jun 10, 2014 at 11:20:41PM -0500, Yaakov Selkowitz wrote:
>> On 2014-06-10 17:36, Adam Dinwoodie wrote:
>>> The only outstanding issue with my build is that git-cvs wasn't working.
>>> That seemed to be down to my build environment, as my attempts to build
>>> the source code available via the Cygwin mirrors showed the same
>>> behaviour, but those binaries work as expected.
>>
>> Are you only testing this with the Cygwin CVS repo?  Have you tried
>> this with any other repos?  For example:
>>
>> :pserver:anoncvs@cygwin.com:/cvs/cygwin-apps setup (Cygwin setup)
>> :pserver:anoncvs@cygwin.com:/cvs/cygwin htdocs (Cygwin website)
> 
> I've just dusted off this job, and although I was still unable to get
> Git v1.8.5.2 working, bumping up to the latest v2.0.2 has had
> considerably more success.
> 
> There are a few things to iron out yet: I've only checked the 32-bit
> build so far, and I'm using a borrowed computer at the moment so I need
> to make sure I can recreate the results on my machine.  I've also only
> done very mainline testing thus far on this build, although the test
> suite is running as I write this email.
> 
> I've still not been able to clone the Cygwin source code from CVS --
> I've been testing by cloning the cygwin-apps repo Yaakov referenced
> above -- but the errors look like a version incompatibility, and I don't
> think there's much I can do about that.  If someone who knows more about
> CVS and Git could take a look at the output and confirm that hypothesis,
> I'd be grateful:
> 
>     $ git cvsimport -v -d :pserver:anoncvs@cygwin.com:/cvs/src src
>     Initialized empty Git repository in /home/add/test/.git/
>     Running cvsps...
>     WARNING: malformed CVS version str: Server:
>     WARNING: Your CVS client version:
>     [Client: Concurrent Versions System (CVS) 1.12.13 (client/server)]
>     and/or server version:
>     [Server: ]
>     are too old to properly support the rlog command.
>     This command was introduced in 1.11.1.  Cvsps
>     will use log instead, but PatchSet numbering
>     may become unstable due to pruned empty
>     directories.

I have been using git 2.0.2 that I built myself for a while now, so I
tried this command using my copy. FWIW, the import works just fine with
my x86_64 build, but fails with the same messages you get with the i686
build.

-- 
David Rothenberger  ----  daveroth@acm.org

Re: [ITA] Git et al

[Adam Dinwoodie]

On Sat, Jul 19, 2014 at 04:48:14PM -0700, David Rothenberger wrote:
> On 7/19/2014 12:29 AM, Adam Dinwoodie wrote:
> > On Tue, Jun 10, 2014 at 11:20:41PM -0500, Yaakov Selkowitz wrote:
> >> On 2014-06-10 17:36, Adam Dinwoodie wrote:
> >>> The only outstanding issue with my build is that git-cvs wasn't working.
> >>> That seemed to be down to my build environment, as my attempts to build
> >>> the source code available via the Cygwin mirrors showed the same
> >>> behaviour, but those binaries work as expected.
> >>
> >> Are you only testing this with the Cygwin CVS repo?  Have you tried
> >> this with any other repos?  For example:
> >>
> >> :pserver:anoncvs@cygwin.com:/cvs/cygwin-apps setup (Cygwin setup)
> >> :pserver:anoncvs@cygwin.com:/cvs/cygwin htdocs (Cygwin website)
> > 
> > I've just dusted off this job, and although I was still unable to get
> > Git v1.8.5.2 working, bumping up to the latest v2.0.2 has had
> > considerably more success.
> > 
> > There are a few things to iron out yet: I've only checked the 32-bit
> > build so far, and I'm using a borrowed computer at the moment so I need
> > to make sure I can recreate the results on my machine.  I've also only
> > done very mainline testing thus far on this build, although the test
> > suite is running as I write this email.
> > 
> > I've still not been able to clone the Cygwin source code from CVS --
> > I've been testing by cloning the cygwin-apps repo Yaakov referenced
> > above -- but the errors look like a version incompatibility, and I don't
> > think there's much I can do about that.

I realized this wasn't very clear.  To be explicit: I can successfully
import the cygwin-apps repository above with my v2.0.2 build.  I cannot,
however, import the Cygwin source repository.

> > If someone who knows more about
> > CVS and Git could take a look at the output and confirm that hypothesis,
> > I'd be grateful:
> > 
> >     $ git cvsimport -v -d :pserver:anoncvs@cygwin.com:/cvs/src src
> >     Initialized empty Git repository in /home/add/test/.git/
> >     Running cvsps...
> >     WARNING: malformed CVS version str: Server:
> >     WARNING: Your CVS client version:
> >     [Client: Concurrent Versions System (CVS) 1.12.13 (client/server)]
> >     and/or server version:
> >     [Server: ]
> >     are too old to properly support the rlog command.
> >     This command was introduced in 1.11.1.  Cvsps
> >     will use log instead, but PatchSet numbering
> >     may become unstable due to pruned empty
> >     directories.
> 
> I have been using git 2.0.2 that I built myself for a while now, so I
> tried this command using my copy. FWIW, the import works just fine with
> my x86_64 build, but fails with the same messages you get with the i686
> build.

That's odd!  I'll try to replicate that myself, but assuming I see the
same behaviour, that implies there's something going wrong that's
probably beyond my ability to debug with the time I can spare.

That said, if the 64-bit version works, and assuming nobody here
objects, I'll suggest releasing that 2.0.2 build and just highlighting
the bug in the release email, and suggesting using the 64-bit build for
folk affected by the bug.

I'll be back at my own computer later this week, so I should be able to
rebuild and test properly either this week or next.

Re: [ITA] Git et al

[Adam Dinwoodie]

On Mon, Jul 21, 2014 at 08:45:53AM +0100, Adam Dinwoodie wrote:
> > I have been using git 2.0.2 that I built myself for a while now, so I
> > tried this command using my copy. FWIW, the import works just fine with
> > my x86_64 build, but fails with the same messages you get with the i686
> > build.
> 
> That's odd!  I'll try to replicate that myself, but assuming I see the
> same behaviour, that implies there's something going wrong that's
> probably beyond my ability to debug with the time I can spare.
> 
> That said, if the 64-bit version works, and assuming nobody here
> objects, I'll suggest releasing that 2.0.2 build and just highlighting
> the bug in the release email, and suggesting using the 64-bit build for
> folk affected by the bug.
> 
> I'll be back at my own computer later this week, so I should be able to
> rebuild and test properly either this week or next.

Just to update folk: I've bumped to v2.0.4, and everything's working a
lot more nicely.  I've managed CVS imports using both 32-bit and 64-bit,
and I'm in the process of ironing out a few kinks in the test suites
before I'm ready to release.

This definitely feels like the home stretch for getting something ready
to upload and distribute.

Re: [ITA] Git et al

[Adam Dinwoodie]

On Mon, Aug 04, 2014 at 10:41:06PM +0100, Adam Dinwoodie wrote:
> Just to update folk: I've bumped to v2.0.4, and everything's working a
> lot more nicely.  I've managed CVS imports using both 32-bit and 64-bit,
> and I'm in the process of ironing out a few kinks in the test suites
> before I'm ready to release.
> 
> This definitely feels like the home stretch for getting something ready
> to upload and distribute.

I think everything's good to go!  CVS imports are working fine, I've
used the build myself briefly (and a previous almost-identical build for
a while), and the test suites are almost all passing*.

I'm not sure what the process is for adopting somebody else's package;
the "Submitting a new package" instructions don't seem to apply since
it's not a new package, but I don't yet have upload rights to just go
ahead and do it.

The packages and setup.hint files are all ready to use and/or upload
from http://tastycake.net/~adam/cygwin/.  Before I can go ahead and
release, I think I need to be added to cygwin-pkg-maint so I can send in
an SSH key, and I possibly need a GTG from another maintainer.

Adam

* I've run all the tests I reasonably can and ironed out all the
failures and unexpected skips except for a binary grep test that
inexplicably passes, a CVS test that fails on 32-bit due to what looks
like a bug in the cvs executable, and some rare 64-bit hangs when
interacting with remotes that are sad but I don't believe should block
the release.

Re: [ITA] Git et al

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1688 bytes --]

On 08/13/2014 01:12 PM, Adam Dinwoodie wrote:
> On Mon, Aug 04, 2014 at 10:41:06PM +0100, Adam Dinwoodie wrote:
>> Just to update folk: I've bumped to v2.0.4, and everything's working a
>> lot more nicely.  I've managed CVS imports using both 32-bit and 64-bit,
>> and I'm in the process of ironing out a few kinks in the test suites
>> before I'm ready to release.
>>
>> This definitely feels like the home stretch for getting something ready
>> to upload and distribute.
> 
> I think everything's good to go!  CVS imports are working fine, I've
> used the build myself briefly (and a previous almost-identical build for
> a while), and the test suites are almost all passing*.
> 
> I'm not sure what the process is for adopting somebody else's package;
> the "Submitting a new package" instructions don't seem to apply since
> it's not a new package, but I don't yet have upload rights to just go
> ahead and do it.
> 
> The packages and setup.hint files are all ready to use and/or upload
> from http://tastycake.net/~adam/cygwin/.  Before I can go ahead and
> release, I think I need to be added to cygwin-pkg-maint so I can send in
> an SSH key, and I possibly need a GTG from another maintainer.

I'll look over your latest packaging, and if it works for me (aka builds
fine, and lets me do a git checkout of some of my usual repos), I'll
update cygwin-pkg-maint to list you as maintainer and reply back.  It
may be this weekend before I actually get the time to spend on it, though.

Thanks again for stepping up and adopting this from me.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]

Re: [ITA] Git et al

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]

On 08/13/2014 01:37 PM, Eric Blake wrote:

>> The packages and setup.hint files are all ready to use and/or upload
>> from http://tastycake.net/~adam/cygwin/.  Before I can go ahead and
>> release, I think I need to be added to cygwin-pkg-maint so I can send in
>> an SSH key, and I possibly need a GTG from another maintainer.
> 
> I'll look over your latest packaging, and if it works for me (aka builds
> fine, and lets me do a git checkout of some of my usual repos), I'll
> update cygwin-pkg-maint to list you as maintainer and reply back.  It
> may be this weekend before I actually get the time to spend on it, though.

Packaging isn't quite right.  After unpacking the -src tarball, I see a
file git-2.0.4-1.src.patch, with contents:

Binary files origsrc/git/t/lib-gpg/random_seed and
src/git/t/lib-gpg/random_seed differ
Binary files origsrc/git/t/lib-gpg/trustdb.gpg and
src/git/t/lib-gpg/trustdb.gpg differ

As a result, the prep phase fails with:
*** ERROR: patch git-2.0.4-1.src.patch will not apply

It's probably possible to patch git.cygport to cause the diff engine to
ignore these files, and once they are ignored, then the file would not
be created.

Removing that file lets cygport get further, but you'll need to respin
the package so that it builds the first time without me having to delete
the file.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]

Re: [ITA] Git et al

[Marco Atzeri]

On 15/08/2014 06:24, Eric Blake wrote:
> On 08/13/2014 01:37 PM, Eric Blake wrote:
>
> Packaging isn't quite right.  After unpacking the -src tarball, I see a
> file git-2.0.4-1.src.patch, with contents:
>
> Binary files origsrc/git/t/lib-gpg/random_seed and
> src/git/t/lib-gpg/random_seed differ
> Binary files origsrc/git/t/lib-gpg/trustdb.gpg and
> src/git/t/lib-gpg/trustdb.gpg differ
>
> As a result, the prep phase fails with:
> *** ERROR: patch git-2.0.4-1.src.patch will not apply
>
> It's probably possible to patch git.cygport to cause the diff engine to
> ignore these files, and once they are ignored, then the file would not
> be created.

Adam,
just add

DIFF_EXCLUDES="random_seed trustdb.gpg"



> Removing that file lets cygport get further, but you'll need to respin
> the package so that it builds the first time without me having to delete
> the file.

Marco

Re: [ITA] Git et al

[Adam Dinwoodie]

On Thu, Aug 14, 2014 at 10:24:58PM -0600, Eric Blake wrote:
> On 08/13/2014 01:37 PM, Eric Blake wrote:
> Packaging isn't quite right.  After unpacking the -src tarball, I see a
> file git-2.0.4-1.src.patch, with contents:
> 
> Binary files origsrc/git/t/lib-gpg/random_seed and
> src/git/t/lib-gpg/random_seed differ
> Binary files origsrc/git/t/lib-gpg/trustdb.gpg and
> src/git/t/lib-gpg/trustdb.gpg differ
> 
> As a result, the prep phase fails with:
> *** ERROR: patch git-2.0.4-1.src.patch will not apply

On Fri, Aug 15, 2014 at 06:46:27AM +0200, Marco Atzeri wrote:
> just add
> 
> DIFF_EXCLUDES="random_seed trustdb.gpg"

Thank you both!  I'd assumed cygport would magically create a source
file that would Just Work, and didn't think to test it explicitly.  I'll
respin as Marco suggests and check it builds out-of-the-box this time
around.

This probably won't be until next week now, as I have guests this
weekend and won't be spending much time at my PC.

On Fri, Aug 15, 2014 at 02:04:59AM -0500, Yaakov Selkowitz wrote:
> Please note that I have just added a number of perl module packages
> required for git-email.  Please be sure to install perl-Authen-SASL,
> perl-IO-Socket-SSL, perl-MailTools, and perl-Net-SMTP-SSL for both
> arches in order to pick up the correct dependencies.

Shall do!  I'll include those in the next respin as well.

Adam

Re: [ITA] Git et al

[Adam Dinwoodie]

On Fri, Aug 15, 2014 at 09:24:52AM +0100, Adam Dinwoodie wrote:
> <snip>

Beware the To/Cc headers in that last reply.  I'm not sure how I maanged
to screw them up like that.  I'm going to blame the fact that I'm still
trying to get used to Mutt's interface.

Re: [ITA] Git et al

[Yaakov Selkowitz]

On Wed, 2014-08-13 at 20:12 +0100, Adam Dinwoodie wrote:
> On Mon, Aug 04, 2014 at 10:41:06PM +0100, Adam Dinwoodie wrote:
> > Just to update folk: I've bumped to v2.0.4, and everything's working a
> > lot more nicely.  I've managed CVS imports using both 32-bit and 64-bit,
> > and I'm in the process of ironing out a few kinks in the test suites
> > before I'm ready to release.
> > 
> > This definitely feels like the home stretch for getting something ready
> > to upload and distribute.
> 
> I think everything's good to go!  CVS imports are working fine, I've
> used the build myself briefly (and a previous almost-identical build for
> a while), and the test suites are almost all passing*.

Please note that I have just added a number of perl module packages
required for git-email.  Please be sure to install perl-Authen-SASL,
perl-IO-Socket-SSL, perl-MailTools, and perl-Net-SMTP-SSL for both
arches in order to pick up the correct dependencies.


Yaakov

Re: [ITA] Git et al

[Adam Dinwoodie]

On Fri, Aug 15, 2014 at 02:04:59AM -0500, Yaakov Selkowitz wrote:
> On Wed, 2014-08-13 at 20:12 +0100, Adam Dinwoodie wrote:
> > I think everything's good to go!  CVS imports are working fine, I've
> > used the build myself briefly (and a previous almost-identical build for
> > a while), and the test suites are almost all passing*.
> 
> Please note that I have just added a number of perl module packages
> required for git-email.  Please be sure to install perl-Authen-SASL,
> perl-IO-Socket-SSL, perl-MailTools, and perl-Net-SMTP-SSL for both
> arches in order to pick up the correct dependencies.

Yaakov,

I can pick up all the above for 64-bit Cygwin, but the perl-Authen-SASL
package doesn't appear to be available for 32-bit Cygwin.  Can you check
it's uploaded and available correctly?

Cheers,

Adam

Re: [ITA] Git et al

[Yaakov Selkowitz]

On 2014-08-20 15:19, Adam Dinwoodie wrote:
> I can pick up all the above for 64-bit Cygwin, but the perl-Authen-SASL
> package doesn't appear to be available for 32-bit Cygwin.  Can you check
> it's uploaded and available correctly?

Fixed; sorry about that.


Yaakov

Re: [ITA] Git et al

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]

On 08/13/2014 01:12 PM, Adam Dinwoodie wrote:
> On Mon, Aug 04, 2014 at 10:41:06PM +0100, Adam Dinwoodie wrote:
>> Just to update folk: I've bumped to v2.0.4, and everything's working a
>> lot more nicely.  I've managed CVS imports using both 32-bit and 64-bit,
>> and I'm in the process of ironing out a few kinks in the test suites
>> before I'm ready to release.
>>
>> This definitely feels like the home stretch for getting something ready
>> to upload and distribute.
> 
> I think everything's good to go!  CVS imports are working fine, I've
> used the build myself briefly (and a previous almost-identical build for
> a while), and the test suites are almost all passing*.
> 
> I'm not sure what the process is for adopting somebody else's package;
> the "Submitting a new package" instructions don't seem to apply since
> it's not a new package, but I don't yet have upload rights to just go
> ahead and do it.

Adam, you are now listed as maintainer in cygwin-pkg-maint, so go ahead
and submit your ssh key email.  I trust that you'll fix the remaining
package wrinkle before actually pushing a package, but even though I had
a slight issue in rebuilding the package, I haven't had any problems
using the pre-built binaries.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]

Re: [ITA] Git et al

[Andrew Schulman]

> > I'm not sure what the process is for adopting somebody else's package;
> > the "Submitting a new package" instructions don't seem to apply since
> > it's not a new package, but I don't yet have upload rights to just go
> > ahead and do it.
> 
> Adam, you are now listed as maintainer in cygwin-pkg-maint, so go ahead
> and submit your ssh key email.  I trust that you'll fix the remaining
> package wrinkle before actually pushing a package, but even though I had
> a slight issue in rebuilding the package, I haven't had any problems
> using the pre-built binaries.

Belated gold star awarded:  http://cygwin.com/goldstars/#AD