Warren Young writes:
> $ git clone git://cygwin-ports.git.sourceforge.net/cygwin-ports/cygport
> Cloning into 'cygport'...
> fatal: The remote end hung up unexpectedly
>
> What am I missing?
Try this repository URL:
git://cygwin-ports.git.sourceforge.net/gitroot/cygwin-ports/cygport
Or this m
On 7/25/2013 22:31, Warren Young wrote:
On 7/25/2013 20:31, Yaakov (Cygwin/X) wrote:
On 2013-07-25 14:50, Warren Young wrote:
I'll wait for this PKG_OBSOLETES feature to ship in Cygport, and be a
guinea pig for it.
It's in git master already.
$ git clone git://cygwin-ports.git.sourceforge.
On 7/25/2013 20:31, Yaakov (Cygwin/X) wrote:
On 2013-07-25 14:50, Warren Young wrote:
I'll wait for this PKG_OBSOLETES feature to ship in Cygport, and be a
guinea pig for it.
It's in git master already.
Cool. I will try to make use of this feature before your next release,
but don't hold i
On 7/25/2013 17:36, Ken Brown wrote:
Here's your RFU:
wget -e robots=off --cut-dirs=2 -np -nH -A'*2.1.0-2*' -r \
http://etr-usa.com/cygwin64/expat/
Oh, it's one of *those*. My more recent RFUs include -A'*.hint' in the
command. The *.hint files are all there on the server, if you want
On 2013-07-25 14:50, Warren Young wrote:
I'll wait for this PKG_OBSOLETES feature to ship in Cygport, and be a
guinea pig for it.
It's in git master already.
Yaakov
On 7/25/2013 7:01 PM, Warren Young wrote:
On 7/25/2013 15:33, Ken Brown wrote:
could you provide a setup.hint for libexpat1-devel
(64 bit)? Without a setup.hint, it gets put into the Misc category and
is then installed by default.
I don't know what you're talking about. Here's the setup.hin
On 7/25/2013 15:33, Ken Brown wrote:
could you provide a setup.hint for libexpat1-devel
(64 bit)? Without a setup.hint, it gets put into the Misc category and
is then installed by default.
I don't know what you're talking about. Here's the setup.hint I RFU'd:
category: Libs
requires: cygwin
On 7/25/2013 3:50 PM, Warren Young wrote:
On 7/25/2013 02:30, Corinna Vinschen wrote:
On Jul 24 14:38, Warren Young wrote:
On 7/24/2013 05:41, Corinna Vinschen wrote:
On Jul 24 05:12, Warren Young wrote:
You'd have to fake a -3 package set, with libexpat-devel-3 set to
obsolete libexpat1-deve
On 7/25/2013 02:30, Corinna Vinschen wrote:
On Jul 24 14:38, Warren Young wrote:
On 7/24/2013 05:41, Corinna Vinschen wrote:
On Jul 24 05:12, Warren Young wrote:
You'd have to fake a -3 package set, with libexpat-devel-3 set to
obsolete libexpat1-devel-2, so that package developers would
autom
On Jul 24 14:38, Warren Young wrote:
> On 7/24/2013 05:41, Corinna Vinschen wrote:
> >On Jul 24 05:12, Warren Young wrote:
> >>You'd have to fake a -3 package set, with libexpat-devel-3 set to
> >>obsolete libexpat1-devel-2, so that package developers would
> >>automatically get new packages on the
On 7/24/2013 05:41, Corinna Vinschen wrote:
On Jul 24 05:12, Warren Young wrote:
You'd have to fake a -3 package set, with libexpat-devel-3 set to
obsolete libexpat1-devel-2, so that package developers would
automatically get new packages on their next Cygwin update.
If you're willing to do th
On Jul 24 05:12, Warren Young wrote:
> On 7/24/2013 04:06, Corinna Vinschen wrote:
> >Regardless of libexpat1-devel supposedly being a bad choice of names,
> >from the global distro perspective, it would be much easier to remove
> >the libexpat-devel package from the 64 bit distro and go over the h
On 7/24/2013 04:06, Corinna Vinschen wrote:
Regardless of libexpat1-devel supposedly being a bad choice of names,
from the global distro perspective, it would be much easier to remove
the libexpat-devel package from the 64 bit distro and go over the hint
files manually for now.
Doesn't the prob
On Jul 24 03:52, Warren Young wrote:
> On 7/23/2013 13:11, Yaakov (Cygwin/X) wrote:
> >
> >But libexpat1-devel is a BAD choice of name,
>
> You're only having a problem with -devel, right, not the library
> package proper?
>
> Does this .cygport file solve the problem?
>
>
>
> DESCRIPTION="Exp
On 7/23/2013 13:11, Yaakov (Cygwin/X) wrote:
But libexpat1-devel is a BAD choice of name,
You're only having a problem with -devel, right, not the library package
proper?
Does this .cygport file solve the problem?
DESCRIPTION="Expat XML parser library"
HOMEPAGE="http://expat.sourceforge.
On 2013-07-23 14:39, Achim Gratz wrote:
Yaakov (Cygwin/X) writes:
I wanted to get feedback from those using cygport regarding a possible
new feature: PKG_OBSOLETES. This is best explained with an example,
so let's say I had the following:
[..]
The attached patch is what I'm working with at th
Yaakov (Cygwin/X) writes:
> I wanted to get feedback from those using cygport regarding a possible
> new feature: PKG_OBSOLETES. This is best explained with an example,
> so let's say I had the following:
[..]
> The attached patch is what I'm working with at the moment. Thoughts?
Looks good to m
Warren, Ping?
On Jul 23 14:11, Yaakov (Cygwin/X) wrote:
> On 2013-07-23 04:06, Corinna Vinschen wrote:
> >On Jul 23 00:02, Yaakov (Cygwin/X) wrote:
> [...]
> >Btw., did you create the 64 bit expat packages or did Warren? The
> >history isn't visible, unfortunately. I'd like to see a solution for
On 2013-07-23 04:06, Corinna Vinschen wrote:
On Jul 23 00:02, Yaakov (Cygwin/X) wrote:
I wanted to get feedback from those using cygport regarding a
possible new feature: PKG_OBSOLETES.
Looks good to me.
Thanks for the feedback.
Btw., did you create the 64 bit expat packages or did Warren?
On Jul 23 00:02, Yaakov (Cygwin/X) wrote:
> I wanted to get feedback from those using cygport regarding a
> possible new feature: PKG_OBSOLETES. This is best explained with an
> example, so let's say I had the following:
>
> NAME="libfoo"
> ...
> PKG_NAMES="libfoo1 libfoo-bin libfoo-devel"
> libf
I wanted to get feedback from those using cygport regarding a possible
new feature: PKG_OBSOLETES. This is best explained with an example, so
let's say I had the following:
NAME="libfoo"
...
PKG_NAMES="libfoo1 libfoo-bin libfoo-devel"
libfoo1_CONTENTS="usr/bin/cygfoo-1.dll"
libfoo_bin_CONTENTS
21 matches
Mail list logo
