Re: [ITA] Git et al
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
Re: [ITA] Git et al
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
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
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 signature.asc Description: OpenPGP digital signature
Re: [ITA] Git et al
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
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
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
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 signature.asc Description: OpenPGP digital signature
Re: [ITA] Git et al
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
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
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 signature.asc Description: OpenPGP digital signature
Re: [ITA] Git et al
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:anon...@cygwin.com:/cvs/cygwin-apps setup (Cygwin setup) :pserver:anon...@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:anon...@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
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:anon...@cygwin.com:/cvs/cygwin-apps setup (Cygwin setup) :pserver:anon...@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:anon...@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
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:anon...@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
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:anon...@cygwin.com:/cvs/cygwin-apps setup (Cygwin setup) :pserver:anon...@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:anon...@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 daver...@acm.org
Re: [ITA] Git et al
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
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
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:anon...@cygwin.com:/cvs/cygwin-apps setup (Cygwin setup) :pserver:anon...@cygwin.com:/cvs/cygwin htdocs (Cygwin website) Yaakov
Re: [ITA] Git et al
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
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
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
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
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) 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
2014-01-29 Achim Gratz strom...@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
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
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 signature.asc Description: OpenPGP digital signature
Re: [ITA] Git et al
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
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
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
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
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 pgpjWoWQRO68g.pgp Description: PGP signature
Re: [ITA] Git et al
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 signature.asc Description: OpenPGP digital signature
Re: [ITA] Git et al
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
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/
