Re: [ITA] boost
On Jun 13 00:21, Yaakov S wrote: Boost is orphaned, and the current package is outdated and anyway needs to be rebuilt for Python 2.6. So: http://mirrors.kernel.org/sources.redhat.com/cygwinports/tmp-py26/boost/ Good news. Please go ahead. Gold star awarded.
Re: [ITA] e2fsprogs, e2fsimage
On Jun 24 22:14, Yaakov S wrote: Continuing my mission to remove the overlaps between distro and Ports, I'll take e2fsprogs. Go ahead, please. Same for e2fsimage. Gold star awarded.
Re: [ITA] cppunit
On Thu, Jun 24, 2010 at 10:23:16PM -0500, Yaakov (Cygwin/X) wrote: I asked for cppunit to be updated for gcc4 back in January[1], pinged in February[2], resulting in a very generous offer from cgf[3]. For lack of response from the previous maintainer (Ross Smith II), I request permission to consider the package orphaned, to which I hereby ITA: ftp://sourceware.org/pub/cygwinports/release-2/cppunit/cppunit-1.12.1-1-src.tar.bz2 ftp://sourceware.org/pub/cygwinports/release-2/cppunit/cppunit-1.12.1-1.tar.bz2 ftp://sourceware.org/pub/cygwinports/release-2/cppunit/setup.hint Yaakov [1] http://cygwin.com/ml/cygwin/2010-01/msg00483.html [2] http://cygwin.com/ml/cygwin/2010-02/msg00031.html [3] http://cygwin.com/ml/cygwin/2010-02/msg00054.html I'm glad to see that you're finally starting to take me up on my generous offer. Gold star awarded.
Re: [ITA] cyrus-sasl
On Jul 2 10:21, David Rothenberger wrote: On 7/2/2010 1:34 AM, Corinna Vinschen wrote: On Jun 30 08:14, David Rothenberger wrote: I would like to adopt cyrus-sasl. It is listed as orphaned and Gareth Pearce recently indicated he was not planning to repackage it.[1] Thanks for taking over. Packaging looks good to me, just the setup.hint files... Thanks for catching those errors. You were right, of course. Here's the updated setup.hints and packages. Uploaded. Again, thanks for taking over this package. Gold star awarded.
Re: [ITP] mingw-w64
On 7/6/2010 1:10 AM, JonY wrote:
I had a thinko, thanks for the patch. Yeah, cygport moves the libtool
dlls around.
I will recheck on the README file and libobjc-2, I thought I patched up
the configure file.
You did, but...
Alright, I repackaged binutils to add the /etc/profile.d scripts
I'll look at mingw64-binutils again later. But right now I'm looking
only at mingw64-gcc:
and
repackaged gcc to get rid of the wrongly installed objc dll.
With the new libtool restrict, no more moving needed. I can also confirm
that libobjc-2.dll goes into bin32 and bin64 on cygport install.
I found the problem: configure.ac is patched, but there's no mechanism
to ensure that the corresponding change to configure is included in the
patch (by default, cygport *assumes* you will run autoreconf, and so
explicitly excludes configure, Makefile.in (for automake projects), etc
from the diff.)
Now, in this case you do NOT want to run autoreconf. The gcc codebase
requires careful handling if you want to update the auto* generated
files; autoreconf is not smart enough.
So, there are a couple of ways around this. All are pretty ugly.
Perhaps the simplest is an extra command in src_build:
(cd ${S}/libobjc autoconf)
to just force the end user to fixup THAT configure script only,
without mucking with any other auto* generated files.
Another option (one that I've had to use on occasion) is to give up on
letting cygport handle the patch generation for .src.patch. What you
do, is you just don't HAVE a .src.patch. Instead, you make your OWN
patch, ensure it contains all the files you want to include, like
libobjc/configure, and name that patch ANYTHING but ${P}.src.patch.
Then, add this to your cygport:
PATCH_URI=the-name-of-my-custom-patch
But...this cygportism has bugged me for a while. So, I tried to create
a generic facility where you could, for instance, do:
DIFF_NO_EXCLUDES=configure Makefile.in *.m4
and then cygport would ensure that, even if it ordinarily would exclude
a file from the diff, if that file name (or pattern) appears in
$DIFF_NO_EXCLUDES then it would avoid doing so. But that got to be
really hard, what with all the word expansion and shell metacharacter
worries. (Plus, it would have slowed down ALL cygports in a pretty big
way during __pkg_diff, for the benefit of only a few.)
So, instead, I whipped up a different patch to cygport which only tells
cygport to avoid automatically adding the autoconf, automake, and
aclocal-generated files to the diff excludes list. To use it, add this
to your cygport:
RESTRICT+= autoreconf-diff-excludes
However, before you modify your .cygport recipe to rely on un-official
cygport patches, let's make sure Yaakov actually accepts the patch. (I
know from long painful experience that you do NOT want to get ahead of
Yaakov's patch-acceptance process).
Given all that, this remaining issue where libobjc/configure is not kept
in sync with libobjc/configure.ac is the only remaining problem with
rebuilding the mingw64-gcc packages. With that corrected, it rebuilds
fine from source.
--
Chuck
Re: [ITP] mingw-w64
On 7/6/2010 23:36, Charles Wilson wrote:
On 7/6/2010 1:10 AM, JonY wrote:
I had a thinko, thanks for the patch. Yeah, cygport moves the libtool
dlls around.
I will recheck on the README file and libobjc-2, I thought I patched up
the configure file.
You did, but...
Alright, I repackaged binutils to add the /etc/profile.d scripts
I'll look at mingw64-binutils again later. But right now I'm looking
only at mingw64-gcc:
and
repackaged gcc to get rid of the wrongly installed objc dll.
With the new libtool restrict, no more moving needed. I can also confirm
that libobjc-2.dll goes into bin32 and bin64 on cygport install.
I found the problem: configure.ac is patched, but there's no mechanism
to ensure that the corresponding change to configure is included in the
patch (by default, cygport *assumes* you will run autoreconf, and so
explicitly excludes configure, Makefile.in (for automake projects), etc
from the diff.)
Now, in this case you do NOT want to run autoreconf. The gcc codebase
requires careful handling if you want to update the auto* generated
files; autoreconf is not smart enough.
I did this too with the libstdc++-v3, libgomp and etc, but only
libobjc-2 is having trouble?
So, there are a couple of ways around this. All are pretty ugly.
Perhaps the simplest is an extra command in src_build:
(cd ${S}/libobjc autoconf)
to just force the end user to fixup THAT configure script only,
without mucking with any other auto* generated files.
Right now, libtool version difference prevents that from going smoothly.
Another option (one that I've had to use on occasion) is to give up on
letting cygport handle the patch generation for .src.patch. What you do,
is you just don't HAVE a .src.patch. Instead, you make your OWN patch,
ensure it contains all the files you want to include, like
libobjc/configure, and name that patch ANYTHING but ${P}.src.patch.
Then, add this to your cygport:
PATCH_URI=the-name-of-my-custom-patch
Just use diff -ur origsrc src right? I have not actually edited any
files other than the autotool stuff.
But...this cygportism has bugged me for a while. So, I tried to create a
generic facility where you could, for instance, do:
DIFF_NO_EXCLUDES=configure Makefile.in *.m4
and then cygport would ensure that, even if it ordinarily would exclude
a file from the diff, if that file name (or pattern) appears in
$DIFF_NO_EXCLUDES then it would avoid doing so. But that got to be
really hard, what with all the word expansion and shell metacharacter
worries. (Plus, it would have slowed down ALL cygports in a pretty big
way during __pkg_diff, for the benefit of only a few.)
So, instead, I whipped up a different patch to cygport which only tells
cygport to avoid automatically adding the autoconf, automake, and
aclocal-generated files to the diff excludes list. To use it, add this
to your cygport:
RESTRICT+= autoreconf-diff-excludes
However, before you modify your .cygport recipe to rely on un-official
cygport patches, let's make sure Yaakov actually accepts the patch. (I
know from long painful experience that you do NOT want to get ahead of
Yaakov's patch-acceptance process).
I can see his hesitation about accepting the .cygport file, it won't
build cleanly on another machine unless its patched too.
Given all that, this remaining issue where libobjc/configure is not kept
in sync with libobjc/configure.ac is the only remaining problem with
rebuilding the mingw64-gcc packages. With that corrected, it rebuilds
fine from source.
Alright, thanks for the review, I'll get a new upload as soon as possible.
[RFU] libogg-1.2.0-1
Please delete 1.1.3-1 and leave 1.1.4-1 as the previous version. wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg0/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg0/libogg0-1.2.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg-devel/libogg-devel-1.2.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg-1.2.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libogg/libogg-1.2.0-1-src.tar.bz2 -- David Rothenberger daver...@acm.org
[RFU] libvorbis-1.3.1-1
Please remove 1.2.0-2 and leave 1.2.3-1 as the previous version. wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/libvorbis/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libvorbis/libvorbisfile3/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libvorbis/libvorbisfile3/libvorbisfile3-1.3.1-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libvorbis/libvorbisenc2/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libvorbis/libvorbisenc2/libvorbisenc2-1.3.1-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libvorbis/libvorbis0/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libvorbis/libvorbis0/libvorbis0-1.3.1-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libvorbis/libvorbis-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libvorbis/libvorbis-devel/libvorbis-devel-1.3.1-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libvorbis/libvorbis-1.3.1-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libvorbis/libvorbis-1.3.1-1-src.tar.bz2 -- David Rothenberger daver...@acm.org
[RFU] libao-1.0.0-1
Please leave 0.8.8-1 as previous. The new version introduces libao4, so please move the libao2 package to the _obsolete category. wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/libao/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libao/libao4/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libao/libao4/libao4-1.0.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libao/libao-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libao/libao-devel/libao-devel-1.0.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libao/libao-1.0.0-1.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libao/libao-1.0.0-1-src.tar.bz2 \ -- David Rothenberger daver...@acm.org
[ITP] libkate - Karaoke codec
I'd like to package libkate[1] in preparation for packaging the newest version of vorbis-tools. libkate is included in Fedora[2]. libkate is currently part of Cygwin Ports[3]. Cygwin Ports also includes KateDJ, a Python application. Unforunately, that requires python-wx2.8, which is not available outside of Cygwin Ports. So, I've not packaged KateDJ. I did bump the version so it's one higher than Cygwin Ports. Yaakov, is this the right thing to do? libkate-bin/setup.hint -- category: Audio requires: libkate libkate1 external-source: libkate sdesc: Ogg karaoke/text encapsulation codec (utilities) ldesc: Kate is a codec for karaoke and text encapsulation for Ogg. Most of the time, this would be multiplexed with audio/video to carry subtitles, song lyrics (with or without karaoke data), etc, but doesn't have to be. A possible use of a lone Kate stream would be an e-book. libkate-devel/setup.hint -- category: Audio requires: libkate libkate1 libogg-devel external-source: libkate sdesc: Ogg karaoke/text encapsulation codec (libdevel) ldesc: Kate is a codec for karaoke and text encapsulation for Ogg. Most of the time, this would be multiplexed with audio/video to carry subtitles, song lyrics (with or without karaoke data), etc, but doesn't have to be. A possible use of a lone Kate stream would be an e-book. libkate1/setup.hint -- category: Audio requires: libkate libgcc1 external-source: libkate sdesc: Ogg karaoke/text encapsulation codec (runtime) ldesc: Kate is a codec for karaoke and text encapsulation for Ogg. Most of the time, this would be multiplexed with audio/video to carry subtitles, song lyrics (with or without karaoke data), etc, but doesn't have to be. A possible use of a lone Kate stream would be an e-book. libkate/setup.hint -- category: Audio requires: sdesc: Ogg karaoke/text encapsulation codec (documentation) ldesc: Kate is a codec for karaoke and text encapsulation for Ogg. Most of the time, this would be multiplexed with audio/video to carry subtitles, song lyrics (with or without karaoke data), etc, but doesn't have to be. A possible use of a lone Kate stream would be an e-book. download: -- wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/libkate/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libkate/libkate1/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libkate/libkate1/libkate1-0.3.7-3.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libkate/libkate-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libkate/libkate-devel/libkate-devel-0.3.7-3.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libkate/libkate-bin/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libkate/libkate-bin/libkate-bin-0.3.7-3.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libkate/libkate-0.3.7-3.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libkate/libkate-0.3.7-3-src.tar.bz2 \ [1] http://wiki.xiph.org/index.php/OggKate [2] https://admin.fedoraproject.org/pkgdb/acls/name/libkate?_csrf_token=8cfaffccd2219fc9f182194d72de212903915a25#F-9 [3] http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/media/libkate/ -- David Rothenberger daver...@acm.org
Re: [ITP] mingw-w64
On 7/6/2010 11:59 AM, JonY wrote:
On 7/6/2010 23:36, Charles Wilson wrote:
Now, in this case you do NOT want to run autoreconf. The gcc codebase
requires careful handling if you want to update the auto* generated
files; autoreconf is not smart enough.
I did this too with the libstdc++-v3, libgomp and etc, but only
libobjc-2 is having trouble?
Correct. The reason is because the relevant changes are in Makefile.am
and Makefile.in (or configure.host) for those other libraries. For
libobjc, the change is in configure.ac/configure.
What's even trickier, is that cygport's heuristic for determining
whether to exclude Makefile.in relies on the design of the *top*
directory of the source. For a number of odd reasons, the top level gcc
directory doesn't cause the exclude Makefile.in logic to fire -- but
it DOES cause the exclude configure logic to fire.
So, you end up with the patches to Makefile.am and libobjc/configure.ac
(and configure.host) as expected. You ALSO end up with the Makefile.in
patches (because the exclude Makefile.in logic in cygport did not
fire), but you miss the libobjc/configure change because the exclude
configure logic DID fire.
Perhaps the simplest is an extra command in src_build:
(cd ${S}/libobjc autoconf)
to just force the end user to fixup THAT configure script only,
without mucking with any other auto* generated files.
Right now, libtool version difference prevents that from going smoothly.
Err...I didn't have any problems running *autoconf* in that directory (I
did NOT run autoREconf). But I didn't think this was the best option
anyway...
Another option (one that I've had to use on occasion) is to give up on
letting cygport handle the patch generation for .src.patch. What you do,
is you just don't HAVE a .src.patch. Instead, you make your OWN patch,
ensure it contains all the files you want to include, like
libobjc/configure, and name that patch ANYTHING but ${P}.src.patch.
Then, add this to your cygport:
PATCH_URI=the-name-of-my-custom-patch
Just use diff -ur origsrc src right? I have not actually edited any
files other than the autotool stuff.
Yes (*) -- but not without manually editing the result, because you'd be
quite likely to pick up a lot of cruft that you don't want. That's why
cygport goes to such trouble to build an exclude list.
However, when I use this option...that's exactly what I do:
diff -urN origsrc src foo.patch
and then edit foo.patch to remove those bits I *know* should not be
included.
(*) If you know you added some files to src/*, then also use -N. Also,
for the .src.patch replacement, you'll want to use -x CYGWIN-PATCHES.
However, before you modify your .cygport recipe to rely on un-official
cygport patches, let's make sure Yaakov actually accepts the patch. (I
know from long painful experience that you do NOT want to get ahead of
Yaakov's patch-acceptance process).
I can see his hesitation about accepting the .cygport file, it won't
build cleanly on another machine unless its patched too.
Well, let's be clear: it's not Yaakov that accepts your package .cygport
file. He is in charge of the cygport tool, nothing more (well,
actually, a WHOLE GIANT PILE more of additional packages, but that's not
relevant here).
In the VAST majority of cases, we'd prefer that any package in the
distro that purports to use 'cygport' to build, actually uses THE
official cygport. But there have been exceptions in the past; these
exceptions caused a lot of extra list traffic and pain for the provider
(me!) of the package whose cygport required the modified tool.
So...there will be pain; I advise you to avoid that pain; but...I
*think* you can do it (rely on a custom cygport tool with minor
modifications) if you really think it is necessary. Final decision on
that rests with the consensus of other package maintainers on this
list...not JUST Yaakov (and not just me, either).
Given all that, this remaining issue where libobjc/configure is not kept
in sync with libobjc/configure.ac is the only remaining problem with
rebuilding the mingw64-gcc packages. With that corrected, it rebuilds
fine from source.
Alright, thanks for the review, I'll get a new upload as soon as possible.
No, no...please slow down. You're doing a lot of extra work and
honestly, I can't keep up. Let's bundle changes an only update the
cygwin packages on sf.org when it makes sense to do so. That would save
you a lot of extra unnecessary work, I think.
I think right now, we're waiting on a verdict -- or alternate suggestion
-- from Yaakov about what patches he will accept in (a soon to be
released version of) cygport, the tool.
--
Chuck
Re: [ITP] libkate - Karaoke codec
On Tue, 2010-07-06 at 11:19 -0700, David Rothenberger wrote: I'd like to package libkate[1] in preparation for packaging the newest version of vorbis-tools. libkate is included in Fedora[2]. Looks good to me. FYI, instead of the custom src_install() to remove KateDJ, you could define the following after *_CONTENTS: PKG_IGNORE=usr/bin/KateDJ usr/lib/python*/ usr/share/man/man1/KateDJ* That will remove the missing file warnings during the packaging stage, and later when wxPython is available you just change PKG_IGNORE to katedj_CONTENTS. libkate is currently part of Cygwin Ports[3]. Cygwin Ports also includes KateDJ, a Python application. Unforunately, that requires python-wx2.8, which is not available outside of Cygwin Ports. So, I've not packaged KateDJ. For now this is correct, although I ought to ITP wxWidgets/wxPython someday. I did bump the version so it's one higher than Cygwin Ports. Yaakov, is this the right thing to do? Yes, and I will remove this from Ports; I don't particularly care about KateDJ. BTW, we still need libtheora as a prereq to GStreamer; since you already have the rest of the Xiph.org packages, would you be willing to ITP that as well? Feel free to take from Ports: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/media/libtheora/ Yaakov
Re: [ITP] libkate - Karaoke codec
On 7/6/2010 2:55 PM, Yaakov (Cygwin/X) wrote: On Tue, 2010-07-06 at 11:19 -0700, David Rothenberger wrote: I'd like to package libkate[1] in preparation for packaging the newest version of vorbis-tools. libkate is included in Fedora[2]. Looks good to me. FYI, instead of the custom src_install() to remove KateDJ, you could define the following after *_CONTENTS: PKG_IGNORE=usr/bin/KateDJ usr/lib/python*/ usr/share/man/man1/KateDJ* Thanks for the tip. BTW, we still need libtheora as a prereq to GStreamer; since you already have the rest of the Xiph.org packages, would you be willing to ITP that as well? Feel free to take from Ports: http://cygwin-ports.svn.sourceforge.net/viewvc/cygwin-ports/ports/trunk/media/libtheora/ Sure, I'll take a look at it. -- David Rothenberger daver...@acm.org Chamberlain's Laws: (1) The big guys always win. (2) Everything tastes more or less like chicken.
[ITP] libtheora - Xiph.Org's video codec
I'd like to package libtheora. It is part of Debian Stable[1]. libtheora is currently part of Cygwin Ports. Yaakov asked that I ITP it.[2] libtheora-devel/setup.hint -- category: Libs requires: libtheora libtheora0 libtheoradec1 libtheoraenc1 libogg-devel external-source: libtheora sdesc: Xiph.Org Theora video codec (development) ldesc: Theora is Xiph.Org's first publicly released video codec, intended for use within the Ogg's project's Ogg multimedia streaming system. Theora is derived directly from On2's VP3 codec; Currently the two are nearly identical, varying only in encapsulating decoder tables in the bitstream headers, but Theora will make use of this extra freedom in the future to improve over what is possible with VP3. libtheora0/setup.hint -- category: Libs requires: libtheora libgcc1 libogg0 external-source: libtheora sdesc: Xiph.Org Theora video codec (unified runtime) ldesc: Theora is Xiph.Org's first publicly released video codec, intended for use within the Ogg's project's Ogg multimedia streaming system. Theora is derived directly from On2's VP3 codec; Currently the two are nearly identical, varying only in encapsulating decoder tables in the bitstream headers, but Theora will make use of this extra freedom in the future to improve over what is possible with VP3. libtheoradec1/setup.hint -- category: Libs requires: libtheora libgcc1 external-source: libtheora sdesc: Xiph.Org Theora video codec (decoder runtime) ldesc: Theora is Xiph.Org's first publicly released video codec, intended for use within the Ogg's project's Ogg multimedia streaming system. Theora is derived directly from On2's VP3 codec; Currently the two are nearly identical, varying only in encapsulating decoder tables in the bitstream headers, but Theora will make use of this extra freedom in the future to improve over what is possible with VP3. libtheoraenc1/setup.hint -- category: Libs requires: libtheora libgcc1 libogg0 libtheoradec1 external-source: libtheora sdesc: Xiph.Org Theora video codec (encoder runtime) ldesc: Theora is Xiph.Org's first publicly released video codec, intended for use within the Ogg's project's Ogg multimedia streaming system. Theora is derived directly from On2's VP3 codec; Currently the two are nearly identical, varying only in encapsulating decoder tables in the bitstream headers, but Theora will make use of this extra freedom in the future to improve over what is possible with VP3. setup.hint -- category: Libs requires: sdesc: Xiph.Org Theora video codec (documentation) ldesc: Theora is Xiph.Org's first publicly released video codec, intended for use within the Ogg's project's Ogg multimedia streaming system. Theora is derived directly from On2's VP3 codec; Currently the two are nearly identical, varying only in encapsulating decoder tables in the bitstream headers, but Theora will make use of this extra freedom in the future to improve over what is possible with VP3. download: -- wget -x -nH --cut-dirs=2 \ http://home.comcast.net/~david.rothenberger/cygwin/libtheora/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libtheora/libtheoraenc1/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libtheora/libtheoraenc1/libtheoraenc1-1.1.1-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libtheora/libtheoradec1/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libtheora/libtheoradec1/libtheoradec1-1.1.1-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libtheora/libtheora0/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libtheora/libtheora0/libtheora0-1.1.1-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libtheora/libtheora-devel/setup.hint \ http://home.comcast.net/~david.rothenberger/cygwin/libtheora/libtheora-devel/libtheora-devel-1.1.1-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libtheora/libtheora-1.1.1-2.tar.bz2 \ http://home.comcast.net/~david.rothenberger/cygwin/libtheora/libtheora-1.1.1-2-src.tar.bz2 [1] http://packages.debian.org/lenny/libtheora0 [2] http://cygwin.com/ml/cygwin-apps/2010-07/msg00049.html -- David Rothenberger daver...@acm.org
gcc4: next release
Hello, Can I ask what will be the next version of GCC be in Cygwin? I'm working on the mingw-w64 GCC package on Cygwin. Normally, anything cygwin gets installed to /usr, however, with gcc 4.6, the locales data clashes. Charles suggested installing to /opt/mingw64, this doesn't fit well with the cygwin model, but no clashes there. This allows mingw-w64 GCC version to be independent of Cygwin's. Yaakov suggested installing to /usr, but there are some problems with it. This makes GCC look in /usr/mingw regardless of what the toolchain target is (anything matching mingw*), bad idea if we want a gcc 4 mingw.org cross toolchain later. It can be fixed, but I'm not too sure how yet. Locale data is also conflicting. Yaakov suggested that I sync up with Cygwin GCC so the clash won't be so problematic, eg 4.5.0 Cygwin with 4.5.1 branch snapshot for mingw-w64. GCC 4.5.x branch and the 4.6.x branch ABI changed for win64, I'm trying to avoid breaking user's self-built packages, so 4.5.0 and earlier is out of the question. The current 4.3.4 is too old for mingw-w64. I'll be absent for about a week starting tomorrow, so no need to hurry in replying.
Re: gcc4: next release
On Wed, Jul 07, 2010 at 09:47:20AM +0800, JonY wrote: Hello, Can I ask what will be the next version of GCC be in Cygwin? I'm working on the mingw-w64 GCC package on Cygwin. Normally, anything cygwin gets installed to /usr, however, with gcc 4.6, the locales data clashes. Charles suggested installing to /opt/mingw64, this doesn't fit well with the cygwin model, but no clashes there. This allows mingw-w64 GCC version to be independent of Cygwin's. I'd want to check with Corinna on this but I am mildly opposed to putting this in /opt. I don't think it makes sense there. But I haven't been following closely, though. Where does Debian put these packages? cgf
Re: gcc4: next release
On Tue, 2010-07-06 at 22:07 -0400, Christopher Faylor wrote: I'd want to check with Corinna on this but I am mildly opposed to putting this in /opt. I don't think it makes sense there. But I haven't been following closely, though. Where does Debian put these packages? I'm working with JonY on this as well. If DaveK splits out the info and l10n into a separate gcc4-common package when he updates to 4.5.x (or 4.6 trunk), then JonY can package a similar version for mingw64 and depend on that to provide those files. That, together with one other fix, should allow mingw64 to go into /usr. The only requirement will be coordinating releases (at least the same major.minor) so that l10n will work for mingw64 as well without worrying about these collisions. The alternative is to simply --disable-nls but IMO that is less than optimal. Yaakov
Re: [ITP] mingw-w64
On 7/7/2010 04:26, Charles Wilson wrote:
On 7/6/2010 11:59 AM, JonY wrote:
On 7/6/2010 23:36, Charles Wilson wrote:
Now, in this case you do NOT want to run autoreconf. The gcc codebase
requires careful handling if you want to update the auto* generated
files; autoreconf is not smart enough.
I did this too with the libstdc++-v3, libgomp and etc, but only
libobjc-2 is having trouble?
Correct. The reason is because the relevant changes are in Makefile.am
and Makefile.in (or configure.host) for those other libraries. For
libobjc, the change is in configure.ac/configure.
What's even trickier, is that cygport's heuristic for determining
whether to exclude Makefile.in relies on the design of the *top*
directory of the source. For a number of odd reasons, the top level gcc
directory doesn't cause the exclude Makefile.in logic to fire -- but
it DOES cause the exclude configure logic to fire.
So, you end up with the patches to Makefile.am and libobjc/configure.ac
(and configure.host) as expected. You ALSO end up with the Makefile.in
patches (because the exclude Makefile.in logic in cygport did not
fire), but you miss the libobjc/configure change because the exclude
configure logic DID fire.
Perhaps the simplest is an extra command in src_build:
(cd ${S}/libobjc autoconf)
to just force the end user to fixup THAT configure script only,
without mucking with any other auto* generated files.
Right now, libtool version difference prevents that from going smoothly.
Err...I didn't have any problems running *autoconf* in that directory (I
did NOT run autoREconf). But I didn't think this was the best option
anyway...
Another option (one that I've had to use on occasion) is to give up on
letting cygport handle the patch generation for .src.patch. What you do,
is you just don't HAVE a .src.patch. Instead, you make your OWN patch,
ensure it contains all the files you want to include, like
libobjc/configure, and name that patch ANYTHING but ${P}.src.patch.
Then, add this to your cygport:
PATCH_URI=the-name-of-my-custom-patch
Just use diff -ur origsrc src right? I have not actually edited any
files other than the autotool stuff.
Yes (*) -- but not without manually editing the result, because you'd be
quite likely to pick up a lot of cruft that you don't want. That's why
cygport goes to such trouble to build an exclude list.
However, when I use this option...that's exactly what I do:
diff -urN origsrc src foo.patch
and then edit foo.patch to remove those bits I *know* should not be
included.
(*) If you know you added some files to src/*, then also use -N. Also,
for the .src.patch replacement, you'll want to use -x CYGWIN-PATCHES.
However, before you modify your .cygport recipe to rely on un-official
cygport patches, let's make sure Yaakov actually accepts the patch. (I
know from long painful experience that you do NOT want to get ahead of
Yaakov's patch-acceptance process).
I can see his hesitation about accepting the .cygport file, it won't
build cleanly on another machine unless its patched too.
Well, let's be clear: it's not Yaakov that accepts your package .cygport
file. He is in charge of the cygport tool, nothing more (well, actually,
a WHOLE GIANT PILE more of additional packages, but that's not relevant
here).
In the VAST majority of cases, we'd prefer that any package in the
distro that purports to use 'cygport' to build, actually uses THE
official cygport. But there have been exceptions in the past; these
exceptions caused a lot of extra list traffic and pain for the provider
(me!) of the package whose cygport required the modified tool.
So...there will be pain; I advise you to avoid that pain; but...I
*think* you can do it (rely on a custom cygport tool with minor
modifications) if you really think it is necessary. Final decision on
that rests with the consensus of other package maintainers on this
list...not JUST Yaakov (and not just me, either).
Given all that, this remaining issue where libobjc/configure is not kept
in sync with libobjc/configure.ac is the only remaining problem with
rebuilding the mingw64-gcc packages. With that corrected, it rebuilds
fine from source.
Alright, thanks for the review, I'll get a new upload as soon as
possible.
No, no...please slow down. You're doing a lot of extra work and
honestly, I can't keep up. Let's bundle changes an only update the
cygwin packages on sf.org when it makes sense to do so. That would save
you a lot of extra unnecessary work, I think.
I think right now, we're waiting on a verdict -- or alternate suggestion
-- from Yaakov about what patches he will accept in (a soon to be
released version of) cygport, the tool.
OK, I've updated the cygport in the mingw64-tc64-gcc4 source file, no
changes to the other files. I've added the cd ${S}/libojc autoconf calls.
I'll be away for about a week, so do take your time to review too.
Yaakov can also give his opinions.
