Re: [ITP] onc-rpc-devel-2_19_20140211-1
On 2/12/2014 7:45 AM, Pavel Fedin wrote: This is me again, and this is my promised RPC package. Folder URL: https://www.dropbox.com/sh/s95jz1ql5xs8yx7/8mhUDlI_Kg I have updated the whole thing using recent source code. Translations included. I hope you'll like the result. One small question: how to specify in setup.hint that this package replaces old rpcgen and sunrpc ? Actually, you don't do that in your setup.hint. Instead, the maintainer(s) of the old rpcgen and sunrpc packages publish new (empty) versions of them, and in the new setup.hints for those, mark them as follows: requires: one-rpc-devel category: _obsolete Give me a day or two to validate your package, and create the new versions of the old packages, and then we'll coordinate a simultaneous upload. -- Chuck
Re: [ITP] onc-rpc-headers-20140129-1
On 2/6/2014 12:46 AM, Pavel Fedin wrote: I'd be happy to hand off rpcgen. All it would take is a coordinated upload, once Pavel's combined package is ready. Good. I think we can safely experiment on x86-64 version. On i386 this new package would conflict with old sunrpc, however sunrpc contains portmapper which is vital for NFS server functioning. Replacing of sunrpc requires to port rpcbind, as well as adding some patches to current NFS server. Yes, this is where I got stuck before, when I tried to modernize the RPC NFS packages. We need to port rpcbind to cygwin, then modify the nfs server. I have a partial port of rpcbind...it compiles (or did), but doesn't run. However, I haven't tried again in years, and cygwin has changed quite a bit...so you may have more luck now, than I did then. -- Chuck
Re: [ITP] onc-rpc-headers-20140129-1
On 2/5/2014 4:19 AM, Corinna Vinschen wrote: On Feb 5 10:39, Pavel Fedin wrote: Hello! Presumably you could find some public cloud with free storage space - I use Dropbox, but I'm sure there are plenty of others. https://www.dropbox.com/sh/s95jz1ql5xs8yx7/8mhUDlI_Kg However, before adding this package, i'd like to discuss merging it with rpcgen and making something like onc-rpc-devel out of them. Actually they both (rpcgen and RPC headers) often come together and serve the same purpose. And i think it would be better to have one bigger package than two very small ones. What is the correct way to supersede the existing package ? I know that rpcgen has an active maintainer, but he doesn't reply (busy or not interested). Additionally, rpcgen is currently not published for x86-64. Chuck? Ping? I'd be happy to hand off rpcgen. All it would take is a coordinated upload, once Pavel's combined package is ready. -- Chuck
Re: Cygport and auto-manifestize compatibility manifest
On 11/20/2013 8:28 AM, Corinna Vinschen wrote: Apart from the fact that it would be nice if our linker would do this automatically and transparently, Or libtool, if you use it to link your exe? PTC...since $new-libtool is pretty high on my to-do list. It'd be better if there was an option to ld/gcc, of course -- but the details would be rather complicated. You wouldn't want to invoke a separate executable like windres b/c then your build recipe/makefile would have to change. Best if $LD_FLAGS could be used... maybe something hideously ugly like -w32-manifest-compat file [1] where file is not a full XML manifest, but rather contains a list of GUIDs [2], and ld/gcc autogenerates the manifest with just that stuff. That way, if you manually create a manifest (for other purposes), you could just /not/ use the new flag. I know, SHTDI... is that something we should do in cygport for the time being? [1] or comma-separated list of GUIDs? That'd get long and ugly, very fast. [2] not OS names, b/c then (a) ld/gcc would have to know the corresponding GUID, and (b) the GUID-OS database would be out of date and require a binutils/gcc patch every time Redmond released a new service pack. -- Chuck
[64bit] inetutils-1.9.1-1
is now available. However, neither the servers nor the clients have been well tested...so report any problems (that didn't already show up in 32bit cygwin with inetutils-1.7-2) to the main list. -- Chuck
Re: [HEADSUP] Re: Obsolete Packages in Requires Lines
On 11/13/2013 7:05 AM, Corinna Vinschen wrote: libproj-devel libproj0 proj libproj0 I think these dependencies are deliberate, to cover the older 4.5.0a-2 version. Chuck? Shouldn't they go away in favor of libproj1 only? Yep. Fixed on sware (32bit only, as I haven't yet ported this to 64bit.) -- Chuck
Re: sunrpc patch that fixes nfs-server failure when reading files of specific sizes
On 11/4/2013 7:22 AM, marco atzeri wrote: Hi George, unfortunately the nfs-server is without a package maintainer http://cygwin.com/cygwin-pkg-maint Yes, but the patch is actually for sunrpc, of which I am (nominally) listed as the maintainer. There's an issue with sunrpc in general (I'll have to check my logs on that), but I'm saving a copy of George's patches for future use. George -- thanks for the testing and the patches. I can't predict how long it'll be until I can fold them in, but they will not be forgotten. I'm open to relinquishing sunrpc, rpcgen, and several other networking-related packages to a new maintainer if you're interested? (But, as you've noticed, they seem pretty interrelated so they ought to go to a common home without breaking up the family) -- Chuck
Re: subtle problem with x86_64 automake1.4
On 9/10/2013 1:50 PM, Christopher Faylor wrote: upset's version normalizer considers (not unreasonably I think) 4-1.4p6-11 to be the same as 4-1.4-p6-11. So, having both files in the same directory is going to confuse things. Yaakov explained downthread how this came about. I /did/ notice that the Release numbers (11) were the same between my new version and Yaakov's bootstrap version, but figured that since the Version numbers differed in format that upset would handle it (I may have even specifically added prev: and curr: entries to the setup.hint to disambiguate priority, in case upset sorted differently than I wanted; but I'm not sure about that). I've added a kludge to the version sorter that upset uses which causes -p6 to sort before p6 but, please don't create packages with different patch number versioning schemes like this. Sorry for the confusion; it's just one of those bootstrap/NMU things we'll slowly work thru as the real maintainers catch up to all of Yaakov's wonderful work with the 64bit bootstrapping. This manifested as a neverending setup.ini creation. Every time there was a new run of upset, a new version of setup.ini would be created because the a new automake1.4 package was constantly being detected. That meant that mirrors could never catch up and the result is that we have almost no mirrors available currently. Yikes. That's...bad. :-( Sorry I didn't catch this thread earlier; I've been really sick this week. -- Chuck
Re: why does setup keep trying to install non-required packages?
On 8/12/2013 11:45 AM, Corinna Vinschen wrote: On Aug 12 11:29, Christopher Faylor wrote: On Mon, Aug 12, 2013 at 01:16:33PM +0200, Corinna Vinschen wrote: On Aug 12 07:10, Ken Brown wrote: Maybe I jumped to an incorrect conclusion, but that (and earlier instances of the same problem) made me think that Misc was installed by default. Oh, right. The setup sources seem to prove that point, too. You know, I think I will remove Misc from upset's logic. The category field should be mandatory, not optional. I assume that no one disagrees with this, right? I don't. Back in the day, Misc was used when setup.exe supported installing a directory full of random tarballs without setup.hint or setup.ini data. So, of course, if you pointed setup.exe at a directory full of random tarballs, you did so because you wanted to install them -- thus Misc was installed by default. But I don't think that (installing tarballs w/o setup.ini data) even works anymore -- and genini is easy enough to use -- so I also agree with the decision to remove Misc. -- Chuck
[64bit] Updated/added automake packages
automake (wrapper)9-1 automake1.14 1.14-1 automake1.13 1.13.4-1 automake1.12 1.12.6-2 automake1.11 1.11.6-2 automake1.10 1.10.3-2 automake1.9 1.9.6-11 automake1.8 1.8.5-11 automake1.7 1.7.9-11 automake1.6 1.6.3-12 automake1.5 1.5-11 automake1.4 1.4p6-11 Also, the gcc-tools packages: gcc-tools-epoch1-autoconf 2.59-2 gcc-tools-epoch1-automake 1.9.6-2 gcc-tools-epoch2-autoconf 2.64-2 gcc-tools-epoch2-automake 1.11.6-1 I'm slowly announcing these officially on the cygwin-announce list, but they are all up there already for both 64- and 32- bit cygwin. The interesting thing about the test suites -- while success/failure between the two was, as expected, nearly the same -- cygwin64 finished in about 65-75% of the time required by cygwin32. That's quite an improvement. -- Chuck
Re: tftp for x86_64 uploaded (was Re: Please build 64 bit packages)
On 8/1/2013 5:18 AM, Corinna Vinschen wrote: Btw., I just built and uploaded the tftp package for x86_64. For some reason, even though inetutils is built without tftp and tftpd support, it still needs the arp/tftp.h file provided by the tftp package. stock inetutils assumes that tftp.h is provided by the system, for whatever reason: 2005-01-21 Alfred M. Szmidt ... * headers/Makefile.am (dist-hook): Target removed. (header_dirs): Variable removed. (EXTRA_DIST): Variable removed. * headers/confpaths.h.in, headers/crypt.h, headers/err.h, headers/getopt.h, headers/obstack.h, headers/osockaddr.h, headers/paths.h, headers/poll.h, headers/syslog-int.h, headers/arpa/DISTFILES, headers/arpa/ftp.h, headers/arpa/telnet.h, headers/arpa/tftp.h, headers/protocols/DISTFILES, headers/protocols/talkd.h: Files removed. In the past (e.g. when tftp[d].exe was compiled and shipped as part of the cygwin inetutils package), one of the custom cygwin patches was to add tftp.h and other headers back into the inetutils src tree -- and thence to install them onto the end user's system. However, when tftp[d].exe was split off (and built using a different upstream source code provider, which unlike inetutils supported IPv6) and Gernot took over maintainership, I removed those patches to inetutils and allowed the tftpd package to provide them instead. So, yes, there is a build dependency between inetutils and tftp now. -- Chuck
Re: Sorted list of packages missing in the 64 bit distro yet
On 8/1/2013 10:37 AM, Corinna Vinschen wrote: Alternatively, if you think a package doesn't have to be rebuilt for 64 bit (Chuck's older automake versions come to mind) Given that they all had such extensive test suites, I thought it would be a useful smoke test to run them on cygwin64. So, I rebuilt and re-ran all of the test suites, on both cygwin32 and cygwin64, for all ELEVEN versions [1] of automake... 1.14 should finish in about seven more hours. [2] So...thanks, but... :-) As soon as the last test is finished, and I compose all of the announcement messages, I'll upload everything for both 32- and 64-. Should be sometime this evening or tomorrow morning. [1] 1.4p6, 1.5,1.6.3, 1.7.9, 1.8.5, 1.9.6, 1.10.3, 1.11.6, 1.12.6, 1.13.4, 1.14 not counting the automake wrapper (updated to -9, in support of am1.14), and the gcc-tools-epoch[1,2]-[autoconf,automake] packages, which are also ready for both 32- and 64-. [2] The good news is, other than the SIGQUIT thing reported earlier, behavior on 32- and 64- is identical, when you compensate for the fact that some tests are skipped because their prerequisites aren't present yet on 64-. I notice that older automakes now have more failures than they did back when originally built/tested (even on cygwin32); that appears to be due to changes in autoconf, libtool, and gettext which newer automakes have accommodated, but older ones have (obviously) not. The list is also available online at http://cygwin.com/cygwin-64bit-missing. I'll keep it up-to-date as new packages arrive. ORPHANED editrights Really? it's in the cygwin-apps repository; I thought *you* were the maintainer. Charles Wilson automake1.5 automake1.6 automake1.7 automake1.8 These are in progress... xpm-nox This is an obsolete (and marked so in its Category) backwards compatibility DLL (cygXpm-noX4.dll). It was replaced by libXpm-noX (libXpm-noX_4 contains cygXpm-noX_4.dll; note the extra underscore) in 2009. There has been a 64bit version of libXpm-noX up since 7/1/2013. At this point (seven years after last update, and four years since it was obsoleted) I think it's okay to simply delete the 32bit xpm-nox. There is nothing left that depends on it. Your call. alternatives inetutils libAfterImage libassuan libgeotiff libksba libtirpc login mingw-libgcrypt mingw-libgpg-error mingw-xz nfrotz p7zip pinentry proj pth rpcgen rsh rxvt ssmtp sunrpc tack xerces-c xinetd xsri ...and these aren't, yet. Sigh. There's also a number of packages that Yaakov built for 64 (ncurses, others; thanks, Yaakov!) that I need to pull over to my repo -- simply so I'll be prepared to continue maintenance in the future. I might also, at that time, update them as well. I've got a big ol' list. -- Chuck
Re: [64bit] Some packaging problems
On 7/17/2013 4:30 AM, Corinna Vinschen wrote: On Jul 16 17:25, Ken Brown wrote: 1. The x86_64 distro has both libexpat1-devel and libexpat-devel, with the files of the latter being a subset of those of the former. In addition, libexpat1-devel is missing a setup.hint, so it is put into the Misc category and installed by default. BTW, there are packages depending on both of these in the distro, so there will be other changes needed after one of them is removed. For all I can tell, libexpat-devel seems to be the old version, libexpat1-devel the new one. We should probably manually fix the deps in the various hint files to require libexpat1-devel and remove the libexpat-devel package. Yaakov? Unless two different versions of a library's -devel package can coexist -- e.g. all include files and static/import libraries are in versioned subdirs: /usr/include/libpng15/*.h /usr/lib/libpng15/*.a /usr/include/libpng16/*.h /usr/lib/libpng16/*.a we don't typically put the DLL number in the -devel package name. In this case, the libexpat1-devel package contains: /usr/include/expat.h /usr/include/expat_external.h /usr/lib/libexpat.a /usr/lib/libexpat.dll.a /usr/lib/pkgconfig/expat.pc so it's not like it could coexist with a future libexpat2-devel. I think the libexpat1-devel name in 2.1.0-2 is a mistake, and it expat should be repackaged to use traditional names, as it did in 2.1.0-1: expat expat-debuginfo libexpat1 libexpat-devel (no 1) Then the existing requires: in other package's setup.hints do not need to be changed. 2. gdb has the wrong setup.hint; it's the same as the setup.hint for rebase. In particular, this puts it into the Base category. Thanks, I fixed the setup.hint manually and I'm just building a new gdb package with the fixed cygport file. 3. The dependencies man == groff == perl bring perl into a default install. Hmm, is that bad? Very. perl is just as bad python, when it comes to creating a trimmed down installation, and we just went thru a significant amount of pain to split cygutils specifically to avoid pulling python in as a dependency of a Base install. OTOH, the 32 bit groff only requires some default libs, not bash, sed, and perl. Why's that? groff ships with some scripts /usr/bin/afmtodit #! /usr/bin/perl -w /usr/bin/chem #! /usr/bin/env perl /usr/bin/eqn2graph #! /bin/sh /usr/bin/gdiffmk #! /bin/sh /usr/bin/grap2graph #! /bin/sh /usr/bin/groffer #! /usr/bin/env perl /usr/bin/grog #! /usr/bin/env perl /usr/bin/mmroff #! /usr/bin/perl /usr/bin/neqn #! /bin/sh /usr/bin/nroff #! /bin/sh /usr/bin/pdfroff #! /bin/sh /usr/bin/pic2graph #! /bin/sh /usr/bin/roff2dvi #! /usr/bin/env perl /usr/bin/roff2html #! /usr/bin/env perl /usr/bin/roff2pdf #! /usr/bin/env perl /usr/bin/roff2ps #! /usr/bin/env perl /usr/bin/roff2text #! /usr/bin/env perl /usr/bin/roff2x #! /usr/bin/env perl and cygport is smart. We should probably split the groff package up as well...fedora has groff-base groff-perl groff-x11 (*) groff-doc groff groff-base: contains only necessary parts of groff formatting system which are required to display manual pages, and the groff's default dispaly device (PostScript) requires: sed sh groff-perl: contains the parts of the groff text processor package that require Perl. These include the afmtodit (font processor for creating PostScript font files), groffer (tool for displaying groff files), grog (utility that can be used to automatically determine groff command-line options), chem (groff preprocessor for producing chemical structure diagrams), mmroff (reference preprocessor) and roff2dvi roff2html roff2pdf roff2ps roff2text roff2x (roff code converters). requires: coreutils(env) perl sh groff-base (+various perl modules) groff-x11: contains the parts of the groff text processor package that require X Windows System. These include gxditview (display groff intermediate output files on X Window System display) and xtotroff (converts X font metrics into groff font metrics). requires: groff-base groff-doc: includes additional documentation for groff text processor package. It contains examples, documentation for PIC language and documentation for creating PDF files. requires: groff Presumably, groff contains everything else. (*) I don't think our groff distribution contains the x11 stuff anyway. -- Chuck
Re: [64bit] Some packaging problems
On 7/17/2013 9:48 AM, Corinna Vinschen wrote: On Jul 17 09:26, Charles Wilson wrote: so it's not like it could coexist with a future libexpat2-devel. I think the libexpat1-devel name in 2.1.0-2 is a mistake, and it expat should be repackaged to use traditional names, as it did in 2.1.0-1: expat expat-debuginfo libexpat1 libexpat-devel (no 1) Then the existing requires: in other package's setup.hints do not need to be changed. To follow the 32 bit lead, we should stick to libexpat1-devel. See the 32 bit version: expat/ expat-debuginfo/ libexpat0/ libexpat1/ libexpat1-devel/ Well, I think they are both wrong. But...that's a maintainer decision (Warren Young), really, unless overruled by one of the benign dictators. :-) groff ships with some scripts [...] and cygport is smart. We should probably split the groff package up as well...fedora has groff-base groff-perl groff-x11 (*) groff-doc groff [...] Sounds good to me. Well, again, it's really up to the maintainer (cgf), but pulling perl into Base is A Bad Thing... -- Chuck
[64bit] Upload procedure
I just uploaded some new packages to the 64bit area. Do I still need to run GEN-sware, or is x86_64 upset-enabled now? -- Chuck
Re: Please try new setup exe's
On 7/17/2013 10:21 AM, Christopher Faylor wrote: If you want to keep parity with upset, then only arch is filled out automatically. If there is no --release then that field doesn't show up in the generated ini file. With that change, feel free to checkin. done. -- Chuck
Re: Please try new setup exe's
On 7/16/2013 2:59 PM, Christopher Faylor wrote: On Tue, Jul 16, 2013 at 08:50:08PM +0200, Corinna Vinschen wrote: The former setup64 doesn't complain, but I don't think this is a setup problem. Rather, it's a difference between the generated ini files. The old setup64.ini was only generated by genini, the new by upset. For instance, here's the gcc entry generated by genini: @ gcc sdesc: GNU Compiler Collection ldesc: The GNU Compiler Collection includes front ends for C, C++, Objective-C, Fortran, Java, Ada, and Go, as well as libraries for these languages (libstdc++, libgcj,...). category: Devel And here's the gcc entry as generated by upset: @ gcc sdesc: GNU Compiler Collection ldesc: The GNU Compiler Collection includes front ends for C, C++, Objective-C, Fortran, Java, Ada, and Go, as well as libraries for these languages (libstdc++, libgcj,...). category: Devel version: 4.8.1-1 source: x86_64/release/gcc/gcc-4.8.1-1-src.tar.bz2 87070214 eb70273d8a2a555d995b0675980fcc1c [prev] version: 4.8.0-2 source: x86_64/release/gcc/gcc-4.8.0-2-src.tar.bz2 86977149 128658603c4daac97e62b4778c22a56d So in one case the entry doesn't contain any package, in the other case we have source entries. With the same input, I bet setup64 behaves the same as setup-x86_64. [...time passes, testing...] yes, when using the new setup.ini with the old setup64.exe, the effect is the same. Thanks for checking. Sounds like a genini bug. I've uploaded a new upset which checks for this corner case problem. So...genini should generate version/source lines for directories that contain only -src packages and no binary. But, wouldn't that mean that setup[-x86|-x86_64||64] would still complain if there were a setup.hint somewhere in tree that required: the source-only package? I think the answer is yes; so what's the solution there? cgf's change to upset to make it complain about the situation, in a Doctor, it hurts when I do this/Then don't do that kind of way? -- Chuck
[64bit] Added i686-pc-mingw32 toolchain
The following packages are now available for cygwin64: mingw-gcc-4.7.3-1 mingw-gcc-core mingw-gcc-g++ mingw-gcc-fortran mingw-gcc-objc mingw-gcc-ada mingw-binutils-2.23.1-1 mingw-w32api-4.0-1 mingw-runtime-4.0-1 mingw-pthreads-20110507-2 Together these provide a win32 toolchain that produces output compatible with the offerings from MinGW.org, but is incompatible with output produced by the mingw64.sourceforge.net compilers (e.g. cygwin's own i686-w64-mingw32 and x86_64-w64-mingw32 toolchains). See the 32bit announcements on cygwin-announce for more information. -- Chuck
Re: Please try new setup exe's
On 7/15/2013 2:58 PM, Christopher Faylor wrote:
On Mon, Jul 15, 2013 at 02:32:24PM -0400, Charles Wilson wrote:
What changes did you have to make to upset, to teach it about the new
format? I'd like to replicate those changes in genini...
http://cygwin.com/cgi-bin/cvsweb.cgi/~checkout~/genini/genini?rev=1.13cvsroot=cygwin-apps
... so I can test the new setup-exe's with my to-be-uploaded packages.
The new setup.exe will still understand old setup.ini's, just not the
reverse.
However, all that I did to upset (for this particular change there were
a few more other changes required) was add --release and --arch options
to produce the setup.ini with those tags.
Feel free to add those to genini if you want.
Works fine installing from the mirrors [1] or from local repo, with the
following patch to genini [2]:
2013-07-16 Charles Wilson ...
* genini: Accept 'Debug' category. Add support for
--release and --arch commandline options, and emit
the appropriate entries (default release='cygwin',
default arch='x86').
[1] With the already-reported issue regarding empty/src-only packages.
[2] This patch does not address the recently-reported issue with genini
that (might be?) related to the above empty/src-only thing:
http://cygwin.com/ml/cygwin-apps/2013-07/msg00207.html
OK to commit this patch (I think I have write access to the genini
module in the cygwin-apps repo)?
--
Chuck
Index: genini
===
RCS file: /cvs/cygwin-apps/genini/genini,v
retrieving revision 1.13
diff -u -p -r1.13 genini
--- genini 21 Jul 2010 15:02:30 - 1.13
+++ genini 16 Jul 2013 21:55:17 -
@@ -14,16 +14,26 @@ use strict;
sub mywarn(@);
sub myerror(@);
sub usage();
+sub arch_handler(@);
my @okmissing = qw'message ldesc';
my ($outfile, $help, $recursive);
+my $arch = 'x86';
+my $release = 'cygwin';
my @cmp_fmts = qw(gz bz2 lzma xz);
-GetOptions('okmissing=s'=\@okmissing, 'output=s'=\$outfile, 'help'=\$help,
'recursive'=\$recursive) or usage;
+GetOptions('okmissing=s'=\@okmissing, 'output=s'=\$outfile, 'help'=\$help,
'release=s'=\$release, 'arch=s'=\arch_handler, 'recursive'=\$recursive) or
usage;
$help and usage;
@main::okmissing{@okmissing} = @okmissing;
+sub arch_handler (@) {
+ my ($opt_name, $opt_value) = @_;
+ die invalid arch specified: '$opt_value'
+ unless $main::valid_arch{lc $opt_value};
+ $arch = $opt_value;
+}
+
if (defined($outfile)) {
open(STDOUT, '', $outfile) or die $0: can't open $outfile - $!\n;
}
@@ -46,6 +56,8 @@ print 'EOF';
EOF
my $ts = time();
+print release: $release\n;
+print arch: $arch\n;
print setup-timestamp: $ts\n;
print $main::setup_version\n if $main::setup_version;
@@ -277,6 +289,9 @@ Create cygwin setup.ini from setup.ini,
missing tarballs. --okmissing=source is useful for
LOCAL-ONLY[*] srcless install media.
--recursiverecurse all subdirectories of specified dirs
+--arch=x86|x64_86 Must be either x86 or x64_86. Defaults to x86.
+--release=string repository id: cygwin, cygwinports, etc. Defaults
+ to cygwin.
--output=file output setup.ini info to file
--help display this message
@@ -289,10 +304,13 @@ EOF
BEGIN {
my @cats = qw'
- Admin Archive Audio Base Comm Database Devel Doc Editors Games
+ Admin Archive Audio Base Comm Database Debug Devel Doc Editors Games
Gnome Graphics Interpreters KDE Libs Mail Math Mingw Net Perl
Publishing Python Science Shells Sound System Text Utils Web X11
_obsolete _PostInstallLast
';
@main::categories{map {lc $_} @cats} = @cats;
+
+my @archs = qw'x86 x86_64';
+@main::valid_arch{map {lc $_} @archs} = @archs;
}
Re: Please try new setup exe's
On 7/16/2013 8:28 PM, Ken Brown wrote: On 7/16/2013 6:23 PM, Charles Wilson wrote: @@ -277,6 +289,9 @@ Create cygwin setup.ini from setup.ini, missing tarballs. --okmissing=source is useful for LOCAL-ONLY[*] srcless install media. --recursiverecurse all subdirectories of specified dirs +--arch=x86|x64_86 Must be either x86 or x64_86. Defaults to x86. ^^^^ x86_64 Oh, you're right. It's correct where it matters (in the code); it's just the help text that got messed up. -- Chuck
Re: Please try new setup exe's
On 7/15/2013 1:05 PM, Christopher Faylor wrote: The setup.ini's used by these two new programs are not backwards-compatible with old setup.exe. What changes did you have to make to upset, to teach it about the new format? I'd like to replicate those changes in genini... http://cygwin.com/cgi-bin/cvsweb.cgi/~checkout~/genini/genini?rev=1.13cvsroot=cygwin-apps ... so I can test the new setup-exe's with my to-be-uploaded packages. -- Chuck
old automake vs. cygwin64 [Was: Automake 1.9 bug: config.guess does not recognize Cygwin64]
On 7/10/2013 2:11 AM, Fedin Pavel wrote: Hello! I've just stumbled accross a bug in Automake v1.9 package. I was trying to regenerate files in a source tree which sets automake version to 1.9. 'automake -icf' has copied files, but config.guess bundled with this version of automake appears to not know 64-bit Cygwin. Please fix. I'm planning to respin all of the [64bit] automake-* packages. Should I update the included config.guess/config.sub in each of them to the latest version (which supports cygwin64), even for ancient automake like 1.4p6? If not, then should I update ANY of the config.guess/config.subs in the non-latest automake? How far back should I propagate the latest config.* -- 1.9? 1.8? -- Chuck
[64bit] autoconf packages updated
I've updated the following 64bit packages: autoconf-13-1 (wrapper) autoconf2.1-2.13-12 autoconf2.5-2.69-2 See the 32bit announcement(s) for details. -- Chuck
Re: Preparation for gcc 4.7.3-1
On 7/3/2013 12:04 PM, Achim Gratz wrote: Yaakov (Cygwin/X) writes: I can't test it myself at the moment, but I believe that mingw-gcc is now broken due to its dependency on libmpc1. As a stopgap measure we could provide a libmpc1 package that copies libmpc3, otherwise a new mingw-gcc would have to be rolled. I'll roll a new release of the mingw(.org) toolchain in the next week. I don't think your stopgap will work, because the whole reason the dll version number changed (from libmpc1 to libmpc3) was because of backwards-incompatible API changes. -- Chuck
Re: [64bit] libXpm-noX
On 6/2/2013 11:02 AM, Ken Brown wrote: Could we get a 64bit build of libXpm-noX when you get a chance? It would be useful for emacs-w32. Done. -- Chuck
[64bit] Uploaded libXpm-noX/libXpm-noX-devel/libXpm-noX_4}-3.5.10-1
The libXpm-noX packages provide a version of the X.Org XPM image format library that do NOT require the use of an X server. This library can be used to read, process, and save XPM images, but all display code has been removed, because that requires X. It is useful for applications that need to manipulate XPM images, but are not themselves X-based. This package also includes cxpm-noX.exe (an XPM file checker) and sxpm-noX.exe (an XPM viewer). Each operates without the need of an X server. For example, try: sxpm-noX --zoom 8 --bgcolor darkblue \ /usr/share/doc/libXpm-noX/plaid_mask.xpm CHANGES (since 3.5.7-12) = o Bump to latest official release 3.5.10 o Updated to latest cygport. Rely on auto-generated setup.hints. o No longer install libtool .la library o New debuginfo (sub)package o First 64bit build. Fixes to sxpm-nox.c to support 64bit. -- Chuck
p7zip
Who updated p7zip from 9.20.1-1 to 9.20.1-2 (32bit), and why? (Also, I don't see an announcement on cygwin-announce). -- Chuck
Re: p7zip
On 6/28/2013 12:05 PM, Charles Wilson wrote: Who updated p7zip from 9.20.1-1 to 9.20.1-2 (32bit), and why? (Also, I don't see an announcement on cygwin-announce). Never mind; false alarm. I forgot I had cygwin-ports hooked into my cygwin 32 bit install. -- Chuck
[64bit] run2-0.4.2-1
The run2 package provides two utilities: 'run2' and 'checkX' (as the package is actually a renamed and updated successor to the now-obsoleted checkx package). The first utility is a more powerful replacement for the venerable 'run' utility that has long been a part of the cygwin distribution. The second is a test utility that detects whether an Xserver is active, and exits with an appropriate status value. 'run2' launches console programs while hiding any actual console (dos box) that may ordinarily be associated with them. In addition, 'run2' can: * set/modify environment variables before launching the target program * specify a start directory from which to launch the target * detect whether an X server is active or not, and launch one of two different targets -- with different command line arguments, environment settings, and startup dirs. 'run2' uses an external XML configuration file to control its own operation, and to specify the settings which should be applied to the target program(s). CHANGES since 0.4.0-1 o Avoid program compatibility issues on W7. See http://cygwin.com/ml/cygwin-developers/2012-02/msg00022.html o Fix several bugs in canonicalizing ~ paths o First 64bit build -- Chuck
Re: gettext packaging bug?
On 6/12/2013 10:50 PM, Yaakov (Cygwin/X) wrote: On 2013-06-12 14:08, Charles Wilson wrote: However, in actuality, neither Bruno's gettext-runtime (our gettext) nor his gettext-tools (our gettext-devel) really represent a traditional runtime-vs-devel split. Note that this means all of the following: /usr/lib/libintl.a /usr/lib/libintl.dll.a /usr/lib/libintl.la /usr/include/libintl.h are actually in 'gettext' and *not* in gettext-devel. IMO they really should be in the latter; if you're building a package which uses l10n, you need it anyway for autopoint, msgfmt, etc. Right, which is why gettext-devel *should* (and on 32bit, does) depend on gettext. However, I'll investigate how the linux distros package gettext co. It's possible TRTD is to have libintl-devel, libasprintf-devel, libgettextpo-devel, etc...and (most of) gettext-devel is transferred to gettext-tools. As I said, I'll investigate. -- Chuck
Re: gettext packaging bug?
On 6/12/2013 11:13 AM, Corinna Vinschen wrote: I was just trying to build a package on a new 64 bit Cygwin test machine, when I encountered a missing libintl.h. As it turned out, I had gettext-devel installed, but not gettext. In the 64 bit version of gettext, gettext-devel depends on libintl8, but not on gettext, so that's that. Ah, that's a bug in Yaakov's packaging of gettext. On 32bit, gettext-devel requires: gettext. However, why is libintl.h in gettext, and not in gettext-devel? A header file belongs in the devel package if there is one, isn't it? The upstream maintainer, Bruno Haible, strongly recommends certain conventions when packaging gettext. While we have to deviate from those recommendations somewhat for cygwin, I tried to adhere as closely as I could to them. See the attached PACKAGING file; what Bruno calls gettext-tools I've packaged as gettext-devel more or less, and what he calls gettext-runtime I've packaged as gettext, with obvious exception that DLLs themselves all get their own package(s). However, in actuality, neither Bruno's gettext-runtime (our gettext) nor his gettext-tools (our gettext-devel) really represent a traditional runtime-vs-devel split. Note that this means all of the following: /usr/lib/libintl.a /usr/lib/libintl.dll.a /usr/lib/libintl.la /usr/include/libintl.h are actually in 'gettext' and *not* in gettext-devel. I'm open to reorganizing the gettext packaging (ignore Bruno?) but we *really* don't want to make gettext depend on gettext-devel (gettext-devel pulls in git, to make autopoint work). The other way around -- where gettext-devel requires: gettext -- could work, and in fact *is* the current practice at least in the 32bit package. Background info: With the release of 0.11 way back in 2002, gettext itself was reorganized into supporting libs (in addition to the pre-existing libintl) and application code. At that time, Bruno made the original packaging suggestions; I tried to explain my version of them in the cygwin README (relevant section pasted below): 0.11.2: Between 0.10.40 and 0.11.2, there were massive changes in the gettext package. Much of the code for the development tools was pulled out and placed into two additional libraries, libgettextlib and libgettextsrc. These are NOT for use by outside programs, but only by the gettext tools themselves -- so the header files, static lib, and import lib are NOT included in the binary package (this ommission is actually *recommended* by Bruno in the PACKAGING file). However, in general these two support libraries are built as shared libraries (DLLs), so the cyggettextlib-0.11.2.dll and cyggettextsrc-0.11.2.dll files are installed. [*] Also, these libraries are NOT versioned according to the normal libtool method (--version-info x:y:z), but instead are versioned using the --release 0.11.2 method. That means that every new release of gettext will ship new versions (0.11.3, etc) of these two libs -- and since no package other than gettext itself uses them, we don't need to worry about keeping old versions around for compatibility and stuff. So, I've made all of the necessary changes to enable these two libs to be built as DLLs -- which include: 1) use the functional, not macro, form of po_gram_error and po_gram_error_at_line. Otherwise, our client programs msg*.exe will attempt, via the macro, to directly access fields of the imported structure variable gram_pos. changes: src/po-lex.h src/po-lex.c 2) provide an accessor function for the imported array-of-structures variable plural_table[] (otherwise our client programs will attempt to directly access elements of the table -- a no-no for auto-import). changes: src/plural-table.h src/plural-table.c src/msgfmt.c src/msginit.c 3) pull out the getopt functions from these libraries, [ (3) deleted because the getopt manipulations are no longer necessary nor performed in builds of modern gettext for cygwin] [*] didn't actually get this working in 0.11, so it had to wait until the 0.12 era, when I finally got the gettextsrc and gettextlib libraries building as DLLs (along with gettextpo), There was a slight tweak: 0.12.1: Update to the latest release. Also, now that libtool doesn't relink forever, use cyggettextlib-0-12-1.dll and cyggettextsrc-0-12-1.dll. Now, the odd thing about this is, cyggettext*-0-12-1 are PRIVATE libraries. Their version number will change with every new release, but since nobody (outside of this package) is allowed to use them, there's no need to worry about backwards compatibility and keeping old versions around and -- you would think -- no need to put them into their own package. BUT. cyggettextpo-0.dll provides the PUBLIC interface to those two private libraries. Thus, external packages might depend on cyggettextpo-0.dll (which in turn depends on cyggettextlib-X-Y-Z and cyggettextsrc-X-Y-Z, but they don't
Re: [RFU] sqlite3-3.7.17-3
On 6/11/2013 10:10 AM, Warren Young wrote: On 6/11/2013 01:37, marco atzeri wrote: you should make it test adding the relevant prev/current/test entries as specified on http://cygwin.com/setup.html Is there a way to set this via the .cygport file? I tried searching its HTML manual, and didn't find one. The alternative is to manually adjust the generated .hint files on test releases on my end. David Rothenberger submitted a patch for cygport to this list on 6/2, to add that feature. Don't know if Yaakov incorporated it or not, but you could locally patch your cygport if you wanted. -- Chuck
Re: Cygwin libtool update
On 6/9/2013 7:01 AM, JonY wrote: Care to put up 2.4.2? It's been out for some time now. It will take some time, but yes. That'll be on the queue right after run2 and libXpm-noX (and perhaps another 'run' b/c...well, JobQueues. See upcoming post on main list). -- Chuck
[64bit] run-1.2.0-1
The run package provides a simple application to launch console programs with their console hidden. CHANGES since run-1.1.13-1 o For cygwin platforms, require 1.7.0 o Rely on cygport auto-generated setup.hint file o First build for 64bit cygwin o Adds support for mingw64 (32bit,64bit) as well as mingw.org compilers. -- Charles Wilson volunteer run maintainer for cygwin
Re: run 64 bit package?
On 5/23/2013 4:22 AM, Corinna Vinschen wrote: is there a chance we can get a 64 bit run package any time soon? It's required for starting X from the start menu... Sure, I'll work on that and run2 tonight. -- Chuck
Re: [64bit] autoconf test for GetConsoleScreenBufferInfo
On 5/14/2013 3:05 PM, Corinna Vinschen wrote: I fear you might not like my answer: The problem here is NOT that the linking works, the problem is that, if the configure test is used to find out if we're running on Windows or not, it's simply not feasible anymore when taking x86_64 Cygwin into account. This has to be solved differently, for instance by not performing this test if configure already knows the target is Cygwin. cygutils uses a similar check in its configury to figure out if it should build the windows-only getclip/putclip programs... AC_CHECK_STDCALL_FUNC([OpenClipboard],[void *]) AM_CONDITIONAL(WITH_WINDOWS_PROGRAMS, test $ac_cv_func_OpenClipboard = yes) But this still works for both 32- and 64- bit cygwin because those lines are *preceded* by AC_CHECK_HEADERS([... windows.h]) which insures that future test programs have #include windows.h in them (assuming the header is found), so the proper declaration/decorations are present for OpenClipboard. -- Chuck
[64bit] Updated: {zlib/zlib0/zlib-devel/minizip/libminizip1/libminizip-devel}-1.2.8-1
The zlib package has been updated to version 1.2.8-1. zlib is a standard lossless compression library. This is a routine update to the latest upstream version. CHANGES since 1.2.7-1 * Update to latest upstream version * Autogenerate .hint files * Build using win32/Makefile.gcc * First 64bit build * Added debuginfo package -- Charles Wilson volunteer zlib maintainer for cygwin
[64bit] cygutils-1.4.12-1 update
Cygutils is a collection of useful(?) tools for the cygwin platform. This is a content update and feature enhancement. CHANGES (from cygutils-1.4.10-2) * winln: new ln workalike that produces native windows shortcuts. Daniel Colascione. * Build fixes adapting to new w32api. * Update to recent autoconf, automake, and gettext. * Added debuginfo subpackage. * First 64bit build. TODO (call for patches): * Update (some?) utilities to handle unicode filenames, similar to IWAMURO Motonori's work on cygstart. Which utilities need this? mkshortcut and lpr, probably. Any others? -- Charles Wilson volunteer cygutils maintainer for cygwin
[64bit]: New: {jbigkit/libjbig2/libjbig-devel}-2.0-12
The jbigkit package has been updated to version 2.0-12 (and released for the first time for 64bit). JBIG is a lossless, bilevel image compression format with better compression than TIFF-LZW (for bilevel images). It is an 'official' standard image format -- International Standard ISO/IEC 11544:1993 and ITU-T Recommendation T.82(1993). (The JBIG group is a sister organization to the more familiar JPEG group; see http://www.jbig.org/) CHANGES (since [32bit] 2.0-11) == * Rebuild using latest tools * Remove .hint files; rely on autogenerated ones * Added debuginfo package * First 64bit build -- Charles Wilson volunteer jbigkit maintainer for cygwin
Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]
On 4/24/2013 4:34 AM, Corinna Vinschen wrote: On Apr 24 00:52, Charles Wilson wrote: Why would simply shortening the PATH have this effect? Do you have a big environment? Thre's a chance that the stack address moves due to that. $ printenv | wc 65 1162418 $ echo $PATH | wc 1 19 472 Is that big? -- Chuck
Re: [64 bit] ghostscript configure script doesn't recognize libtiff
On 4/23/2013 4:21 AM, Corinna Vinschen wrote: On Apr 23 06:55, Dr. Volker Zell wrote: I need help compiling ghostscript for 64 bit. The configure script doesn't recognize libtiff somehow. Any ideas ? Yes. libtiff-3.9.7-2 is apparently 32 bit: $ file /bin/cygtiff-5.dll /bin/cygtiff-5.dll: PE32 executable (DLL) (console) Intel 80386, for MS Windows After reinstalling Yaakov's 3.9.7-1: $ file /bin/cygtiff-5.dll /bin/cygtiff-5.dll: PE32+ executable (DLL) (console) x86-64, for MS Windows Weird. I double checked that I was using cygport --64 when building that package (using the cygwin-ports cross environment), so I think there must be a bug in stock cygport -- or an infelicitous interaction between it and tiff's configury -- that prevents --64 from doing the right thing. (Or my 32-64 environment might be messed up somehow, I guess. Just trying to cover all the bases...) If I have to use a non-stock cygport, then I might as well use non-stock in the 64bit environment itself, and build natively. I'll switch to that in the future. I removed the 3.9.7-2 packages and regenerated setup64.ini. Please reinstall libtiff5-3.9.7-1 and libtiff-devel-3.9.7-1, that should get you going. Chuck, do you want to rebuild a new 64 bit tiff package set? Yes. I also have a 4.0 'test' version ready for both 32 and 64, but I guess it's back to the drawing board for that, for x86_64, as well... Btw., when uploading can you make sure that all package files are group writable? Ack. Also, make sure the tiff package doesn't depend on libstdc++6-devel. That package doesn't exist anymore. Hmm...another symptom of cygport --64 actually operating in 32bit mode, at least in this case. Those .hints are autogenerated, and on the 32bit platform libstdc++6-devel exists and is a correct dependency of libtiff-devel. I'll double check that this issue is not present when I rebuild within the native 64bit environment. -- Chuck
Re: Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]
On 4/13/2013 11:45 PM, Yaakov (Cygwin/X) wrote: On 2013-04-13 00:55, Andy Koppe wrote: I've also tried installing cygport from git master but got this after running ./autogen.sh make: make: *** No rule to make target `data/gnuconfig/config.guess', needed by `all-am'. Stop. This is one quirk of git that I've never understood: git clone does not expand submodules by default without the --recursive flag. Run git submodule update --init to get these after a clone. Something very odd: when I do this, I get fork errors: $ /usr/bin/git submodule update --init Submodule 'data/gnuconfig' () registered for path 'data/gnuconfig' 2 [main] git-fetch 6928 fork: child -1 - forked process 9228 died unexpectedly, retry 0, exit code -1073741515, errno 11 error: cannot fork() for rev-list: Resource temporarily unavailable error: Could not run 'git rev-list' remote: Counting objects: 3403, done. remote: Compressing objects: 100% (1576/1576), done. 294079 [main] git-fetch 6928 fork: child -1 - forked process 1 died unexpectedly, retry 0, exit code -1073741515, errno 11 error: cannot fork() for index-pack: Resource temporarily unavailable fatal: fetch-pack: unable to fork off index-pack Unable to fetch in submodule path 'data/gnuconfig' But, if I do this instead: $ PATH=/usr/bin /usr/bin/git submodule update --init Submodule 'data/gnuconfig' () registered for path 'data/gnuconfig' remote: Counting objects: 3403, done. remote: Compressing objects: 100% (1576/1576), done. remote: Total 3403 (delta 1786), reused 3403 (delta 1786) Receiving objects: 100% (3403/3403), 541.65 KiB | 720 KiB/s, done. Resolving deltas: 100% (1786/1786), done. From git://git.sv.gnu.org/config * [new branch] linux-overhaul-20010122 - origin/linux-overhaul-20010122 * [new branch] master - origin/master From git://git.sv.gnu.org/config * [new tag] before-miles-orphaned-changes - before-miles-orphaned-changes * [new tag] before-thomas-posix1996 - before-thomas-posix1996 * [new tag] gnumach-release-1-1-1 - gnumach-release-1-1-1 * [new tag] gnumach-release-1-1-3 - gnumach-release-1-1-3 * [new tag] post-cagney-2000-02-15 - post-cagney-2000-02-15 * [new tag] pre-cagney-2000-02-15 - pre-cagney-2000-02-15 * [new tag] release-0-1 - release-0-1 * [new tag] release-1-0 - release-1-0 Submodule path 'data/gnuconfig': checked out 'fd4dee4466c2b7bc330ff61430460e8bf6e26ddd' it works. Why would simply shortening the PATH have this effect? -- Chuck
Re: [64bit] type conflict for INT32
On 4/11/2013 6:08 PM, Yaakov (Cygwin/X) wrote: It does mean that Win32API (or X11, for that matter) headers must be #include'd before jpeglib.h. Before I spin a new release, could you test if this works with emacs? Would this problem go away if we switched to jpeg-turbo? -- Chuck
Re: Recent cygport and cygwin-specific READMEs
On 4/11/2013 6:37 PM, Yaakov (Cygwin/X) wrote: No, cygport(1) doesn't generate README content. Too bad. Well, maintaining the READMEs in my local git repo side-by-side with the cygport(5) is not that big a deal -- especially with the other cygport(1) improvements, incl #3 below. #2) Is it possible to use the auto-setup.hint-generator functionality for multi-part package sets (e.g. which contain multiple separate tarballs, in addition to -src and -debuginfo)? If so, how? Yes; it just works Fabulous. #3) As I've been gone for a while, I might've missed recent changes: do setup.exe and/or cygport support build dependencies directly in any way, rather than the ad-hoc put-it-in-a-cygwin-README technique I've been using 'til now? See DEPEND in the cygport manual. (Yes, this is confusing now that REQUIRES exists for additional *runtime* dependencies. I'm thinking of renaming this to BUILDREQUIRES or the like, but for API compatibility DEPEND would still work.) These are checked at the beginning of the build step, and a warning issued if any are missing. Great -- which actually means I can remove that bit from the cygwin-specific READMEs. That's the most annoying part of keeping the READMEs up-to-date anyway. -- Chuck
Recent cygport and cygwin-specific READMEs [Was: Re: GCC-4.7.2-2: Go/No-go?]
On 4/11/2013 2:58 AM, Yaakov (Cygwin/X) wrote: Something else you missed: cygport supports a new, unversioned file format, and creates setup.hint files, including dependency detection. I suggest using git master right now. I know that cygwin-specific READMEs are now no longer required or expected in cygwin packages. However, I like to keep mine around to document things like packaging history, cygwin-specific user notes, build dependencies, and the like. I'll admit, tho, that avoiding the need to maintain setup.hints outside of the cygport(5) is nice, at least for simple package sets (that have only one binary tarball, plus the -src and the debuginfo). Three questions: #1) Is it possible to also record cygwin-specific README content within the cygport(5)? [1] If so, can you do more than one? (I'm thinking here of inetutils, which has a separate cygwin-specific README for the -server (sub)package and for the -client (sub)package). #2) Is it possible to use the auto-setup.hint-generator functionality for multi-part package sets (e.g. which contain multiple separate tarballs, in addition to -src and -debuginfo)? If so, how? #3) As I've been gone for a while, I might've missed recent changes: do setup.exe and/or cygport support build dependencies directly in any way, rather than the ad-hoc put-it-in-a-cygwin-README technique I've been using 'til now? [1] And I don't mean just putting a giant block of #-comment lines in the cygport(5). I mean ensuring that something gets intalled into /usr/share/doc/Cygwin/ with the appropriate name and all. -- Chuck
Re: [RFC] libjpeg-turbo
On 4/10/2013 4:03 AM, Yaakov (Cygwin/X) wrote: The libjpeg-turbo project provides SIMD acceleration while remaining API and ABI compatible with IJG libjpeg 6b/7/8 (based on configure flags). I have been using this libjpeg8 locally instead of the IJG one from the distro for some time, and have seen no ABI incompatibilities. Fedora switched from IJG libjpeg to libjpeg-turbo in F14, and did the same in their MinGW toolchain for F16 (when they switched from mingw.org to mingw-w64). Perhaps we should do the same? Yes, I've been considering switching for some time (especially given the...mess...that IJG libjpeg development has been for the past few years.) I'm willing, unless there's strong objection from the list. BTW, which processor do we target these days in 32bit cygwin, as that will affect which SIMD instruction set is enabled whn libjpeg-turbo is built? i686? -- Chuck
Re: 64 bit editrights package csih
On 4/7/2013 12:21 AM, Charles Wilson wrote: On 4/5/2013 10:15 AM, Corinna Vinschen wrote: Chuck, editrights was the last dependency missing for csih. Would you mind to build a new package? I was going to just copy it over from the 32 bit release area, but then it occured to me that it isn't just a script, but contains binaries as well... I planned to get my 64bit-package-building-environment up and functional Sunday pm, so I'll work on it then, along with the pointer Yaakov sent me. 32bit csih updated to 0.9.7-1. 64bit version uploaded to 64bit release area. -- Chuck
Re: Maintainers please weigh in on 64-bit Cygwin
On 3/17/2013 12:45 PM, Christopher Faylor wrote: 1) Do you have a 64-bit version of Windows available? 2) If no, would you be willing to install one? 3) Are you willing to download the current 64-bit Cygwin and start porting your stuff, knowing that there are still bugs? 4) Or, would you rather wait for 64-bit to be completely stable before attempting anything? 5) Does the existence of two different architectures make you think that it is time for you to stop offering the package? 6) Would you be willing to have another person doing the 64-bit port for you? 7) Are you ok with a 64-bit alpha release being made available which contains your packages built by someone else? 1) Yes. 2) N/A 3) Yes. 4) No. 5) No. 6) Yes. 7) Yes. -- Chuck
Re: [ITP] mingw64-x86_64-winpthreads 3.0b_svn5726-1
On 4/7/2013 5:47 AM, JonY wrote: For now, I intend to push it to 64bit Cygwin only, once gcc 4.7 for the 32bit cygwin hits release, I will push it there too. There are some files in the package that replaces e.g. conflict with some of the mingw-w64-headers CRT headers, this is done on purpose. will cygcheck/setup have any issues? Yes. I'm not sure how that should be handled. If you want to force the switch, for that particular toolchain, then the cygwin package of the mingw-w64-headers for that toolchain should probably stop shipping those files, so that the (new) winpthreads package for that toolchain can start shipping them. If you DON'T want to force the switch, then...? Use the alternatives framework for those particular headers? -- Chuck
Re: 64bit cygport
On 4/7/2013 7:11 AM, Achim Gratz wrote: I've just set up a Cygwin64 system. It seems I can run a 32bit Cygwin in parallel without disturbing anything, is that right? FYI, unless I've misinterpreted, I think you need to use git master cygport to build natively in cygwin64. If you're cross-building from cygwin32 to create cygwin64 packages, then you need to do cygport --64 ...blahblah... -- Chuck
Re: 64 bit editrights package csih
On 4/5/2013 10:15 AM, Corinna Vinschen wrote: Chuck, editrights was the last dependency missing for csih. Would you mind to build a new package? I was going to just copy it over from the 32 bit release area, but then it occured to me that it isn't just a script, but contains binaries as well... I planned to get my 64bit-package-building-environment up and functional Sunday pm, so I'll work on it then, along with the pointer Yaakov sent me. -- Chuck
Re: automake: python3.2 and py-compile
On 11/23/2012 9:22 AM, Corinna Vinschen wrote: Chuck, are you still with us? There's also the request to update autoconf to the latest 2.69 version: http://cygwin.com/ml/cygwin/2012-11/msg00164.html On Nov 16 04:39, Yaakov (Cygwin/X) wrote: On Wed, 2012-10-17 at 11:07 -0500, Yaakov (Cygwin/X) wrote: On Tue, 2012-06-26 at 03:25 -0500, Yaakov (Cygwin/X) wrote: Starting with 3.2, python implements PEP3147[1]. The attached patch (for automake-1.11.3) fixes py-compile wrt this. Ping? Ping 2? Updated patch here: http://lists.gnu.org/archive/html/automake-patches/2012-11/msg00023.html Both autoconf and automake updates coming soon. Just gotta wait for thetestsuite(s)tooo.fiiinnnsh... They take about 8-10 hours each on my machine. -- Chuck
Re: gdk-pixbuf update? (attn: Chuck)
On 8/21/2012 3:17 PM, Yaakov (Cygwin/X) wrote: Chuck, for someone who hates flag days with a passion[1], you have most ironically forced one upon us without warning. Please rectify that by restoring libpng14-devel (with 1.4-versioned files only, of course) ASAP. Actually, I was just following your suggestion from a few /years/ back that we don't need to keep around multiple dev packages for libpng. But, given that its presence is now ingrained in other packages, I can easily bring it back. -- Chuck
Re: libtiff-devel (3.9.6-1): missing dependency on libjbig-devel
On 8/21/2012 10:17 PM, James Zern wrote: libwebp's [1] configure script [2] does a simple check for -ltiff, this will succeed, but the build will fail due to the missing library. Corrected on sourceware; next release of libtiff will include this change organically. Thanks for the heads up. -- Chuck
Re: zlib: upset messages
On 5/14/2012 1:32 AM, Yaakov (Cygwin/X) wrote: On 2012-05-14 00:31, upset lived up to its name and complained: upset: *** setup.ini: warning - package minizip requires non-existent package libgcc_1 I made the obvious fix on sourceware; please fix your local copy, etc. Thanks (and sorry for the trouble). -- Chuck
Re: cygport: user-supplied download action?
On 5/10/2012 10:55 PM, Yaakov (Cygwin/X) wrote: Right; sourceware.org:/cvs/src is funny that way. AFAIK it is the only time I have seen that with CVS, but do other exceptions exist? libgeotiff. This is related to one of the patches I had proposed long ago, but eventually withdrew. However, mine: Using the `cvs checkout -d' option doesn't work either here. It's not working as one expects it, and the additional -N option makes it only marginally better. So I noticed. :-( Is that a bug or am I misreading the manual? was fixable by adapting cygport to allow an optional 'cvs checkout -d foo' incantation, but it seems Corinna's issue can't be addressed that way. -- Chuck
Re: [SECURITY] libpng vulnerabilities
On 5/4/2012 8:21 PM, Yaakov (Cygwin/X) wrote: I have sent notices of multiple security vulnerabilities in libpng going back LAST JULY, with several additions and pings (no pun intended) since. Can we *please* see some sign that you are still maintaining these packages? I wanted to roll out the new zlib packages first as libpng depends on it. I finished those [cygwin-native, and mingw.org-cross] yesterday, given the new zlib-1.2.7 release on Thu (and have now added the minizip lib and utilities, via additional optional subpackages). I'll be rolling out the new zlib on Monday with libpng to follow soon after. -- Chuck
Re: automake 1.11.2 ?
On 3/25/2012 2:40 AM, Yaakov (Cygwin/X) wrote: On 2012-03-24 22:12, Yaakov Selkowitz wrote: Chuck, In the last few weeks I have seen a few packages which require automake-1.11.2. Any chance you could update this soon? Actually, make that 1.11.3. Oh, and ping on the libpng security updates? Ack. -- Chuck
Re: Mingw64 and Cygwin: header and libs layout
On 3/13/2012 10:00 AM, Corinna Vinschen wrote:
- Either keep the files in /usr/{include,lib,lib64}/w32api, which requires
to duplicate the files as it is done today,
I don't think it's THAT big a burden for (Chris S.|Joy Y.) to create two
different packages for (mingw32|mingw64-platform). But I could be
wrong...obviously Chris and Jon's opinions should have a major impact on
this decision.
My stance is that we should give up the unnecessary duplication of the
files. Then the question is just, where to install the shared platform
files so that they are accessible from all affected compilers, the Cygwin
GCCs as well as the Mingw64 GCCs. IMO /usr/share is the right place
for everything which is shared between multiple packages.
Err, well -- technically /usr/share is for platform-independent files. I
*guess* you could say that, in the realm of cygwin|mingw32|mingw64, the
platform headers and libs are (supposed to be) platform independent --
within that small realm of platforms.
But...not really appropriate for, say, solaris or linux, right? So a
strict interpretation says they should not go into /usr/share/.
Platform-dependent files, even headers, tend to go into /usr/lib under
some subdirectory (think /usr/lib/gcc/*/include/ -- or
./usr/lib/glib/include, /usr/lib/perl5/*/CORE/*.h, etc.
So, I could see
/usr/lib/platform/include/*.h
/usr/lib/platform/[lib/ ?]/*.a
/usr/lib64/platform/include/*.h
/usr/lib64/platform/[lib/ ?]/*.a
or somesuch.
Could Dave Korn weigh in on this?
Yes, that would be helpful, probably.
Yep.
--
Chuck
Re: [RFC] disable static libraries?
On 3/15/2012 11:55 PM, Christopher Faylor wrote: On Thu, Mar 15, 2012 at 10:30:45PM -0500, Yaakov (Cygwin/X) wrote: libtool, while very commonly used, is the only major build system which creates both shared and static versions of every library by default. With the notable exceptions of libiconv and gettext, which are used in winsup/utils, most of the time the only purpose static libraries serve is to lengthen build times and enlarge -devel packages. So my question is, do you think about adding --disable-static to the default configure flags in cygport, or is this better left to individual maintainers to (be encouraged to?) do this themselves? I think it sounds like it's a good idea to make it the default. I agree, as long as it can be disabled (for instance, mingw-zlib, mingw-bzip2, etc, which are used by setup.exe and should provide static versions) -- Chuck
Re: Fwd: GnuPG maintainer wanted
On 2/27/2012 8:56 AM, marco atzeri wrote: I will give a look. Any preference between 1.4.12 and 2.0.18 ? I made an attempt about two years ago to port gnupg 2.x. It has additional dependencies beyond those of 1.4.x, so I added all of those to the distro. However, I ran into a problem (related to pth/pthread support) such gnugp's analog to ssh-agent could not be queried, so you always had to type in your passphrase. That was obviously unacceptable, so I didn't actually post my version of gnupg-2.x The problem was basically this: 1) gnupg requires threading support via pth, NOT pthreads. This is because the gnupg folks consider real threads to provide a larger attack surface for security -- too large to adequately secure on all supported platforms -- so they require the use of the pth library. (pth provides a pseudo-thread interface that kinda works like pthreads, but the threads are actually all cooperatively managed as part of a single native thread.) 2) The pth library doesn't/didn't work on cygwin because of missing support for pth+fork. In any case, pth needed support for a facility that was, at the time, missing from cygwin (standard posix sigstack/sigaltstack approach): http://cygwin.com/ml/cygwin/2009-10/msg00467.html This was on cgf's post-1.7 TODO list, but I don't recall if it ever happened. If it did, then I have a ported pth package (un-ITP'ed) that should work. 3) So, I heavily patched gnupg to use pthreads instead. But this had a side effect that gpg-agent didn't work as expected. IIRC, this had (something) to do with cygwin's missing support for passing open file descriptors between threads (briefly mentioned on the main list last week; obviously passing open filedes between *pseudo-threads* that are actually part of the same *real* thread, as in pth, is not a problem. If we were actually using pth. I suspect, if (a) cygwin has sigstack/sigaltstack, and (b) my ported pth works ok, then a version of gnupg-2.x with my pthread patches reverted should be almost there. -- Chuck
Re: [SECURITY] libpng vulnerabilities
On 2/26/2012 3:02 AM, marco atzeri wrote: All versions of libpng from 1.0.6 through 1.5.8, 1.4.8, 1.2.46, and 1.0.56, respectively, fail to correctly validate a heap allocation in png_decompress_chunk(), which can lead to a buffer-overrun and the possibility of execution of hostile code on 32-bit systems. This serious vulnerability has been assigned ID CVE-2011-3026 and is fixed in version 1.5.9 (and versions 1.4.9, 1.2.47, and 1.0.57, respectively, on the older branches), released 18 February 2012. Thanks. I'll update soon, and probably release a 1.5 package as well. -- Chuck
Re: [RFC] Packaging texlive
On 2/27/2012 5:51 AM, Yaakov (Cygwin/X) wrote: TeX Live also replaces psutils, listed as maintained by Daniel Boesswetter. AFACIS he hasn't posted to these lists since November 2003, so I think it's fair to say that it's been orphaned. Is it possible to package this part in such a way that I can install the replacement psutils without pulling in all of TeX? -- Chuck
Re: Fwd: GnuPG maintainer wanted
On 2/27/2012 11:07 AM, marco atzeri wrote: Thanks for status, I was just wondering why most of the dependencies where present but a bit old. Yep -- since the only thing those deps are actually used for, it seems, is gnupg-2.x, I haven't been keeping them up to date without an actual gnupg-2.x package in the distro to force the issue. I was kinda hoping, back at the time, that somebody would/could help with the problems I encountered, but I haven't been routinely pinging the issue, so it isn't surprising its not on anyone else's front burner either. -- Chuck
Re: realpath: cygutils or coreutils?
On 2/6/2012 11:49 AM, Eric Blake wrote: I've uploaded coreutils-8.15-1 as a test release; I can kick it over to current once you've got a cygutils release to match. cygutils-1.4.8-1 is uploaded as a test release. * Integrate cygstart with FD.o menu and mimetype system. (Yaakov Selkowitz) * Remove ascii utility; replaced by separate package derived from ESR's implementation http://catb.org/~esr/ascii/ * Remove realpath utility; replaced by new implementation provided by coreutils (8.15 and above). As soon as Yaakov uploads his new ascii package, we're GTG. -- Chuck
Re: Bug in csih
On 2/6/2012 6:25 AM, Corinna Vinschen wrote: On Feb 5 15:23, Charles Wilson wrote: How's this? (BTW, we do similar stuff in csih_create_privileged_user() but I didn't address that). That looks ok to me. As for csih_create_privileged_user, I don't see what you mean. In that function you just add the account to the local admins group, which is the right thing to do. Where, do you think, is the problem in csih_create_privileged_user? Just that it, also, tries to figure out the name of the Administrator's group and add the newly-created user to it -- e.g. 'similar stuff'. But, as you say, this isn't really a problem in the context of creating a new (local) admin account. -- Chuck
Re: CFA: support Windows 8 in /usr/lib/csih/winProductName.exe
On 2/6/2012 6:30 AM, Corinna Vinschen wrote: 6.2 is correct. Have a look into dump_sysinfo() in utils/cygcheck.cc. It's updated to the latest known state when the W8 test release became available. Ah, thanks. I looked at wincap.cc and didn't see anything there, so... -- Chuck
Re: ITP checkbashisms -- Check for bashisms in /bin/sh scripts
On 2/4/2012 3:55 AM, Jari Aalto wrote: checkbashisms script has been included in Debian since 200x (don't know exatly; its git log starts in 2007). It's part of the devsripts in Debian. To check build: tar -xf check*.bz2 ./check*.sh --color --verbose all We're not debian, and don't explicitly exclude the use of bashism in *ALL* [/usr]/bin/*.sh scripts. Even debian doesn't disallow bashisms i *usr*/bin/ scripts -- and as /bin == /usr/bin on cygwin, we can't realy distinguish between /bin/*.sh and /usr/bin/*sh. Some of our scripts, in fact, have sh-bang lines explicitly requiring bash (e.g. cygport). So...I'm not sure this is a totally useful tool for cygwin; it might lead to unnecessary list traffic: Hey, checkbashisms complains about /usr/bin/cygport, please fix... I realize this doesn't require votes as it is already in debian, and I certainly have no veto power, but if it did require votes I'd be giving it a '0' not a '+1'. -- Chuck
Re: realpath: cygutils or coreutils?
On 1/30/2012 8:50 PM, Yaakov (Cygwin/X) wrote: While you're at it, what about ascii(1)? http://cygwin.com/ml/cygwin-apps/2011-10/msg00113.html Nobody ever responded to my comments at the end of that thread, so it kinda went into limbo. Given two +1 votes (your own and Christian Franke's) i'll go ahead and remove ascii from cygutils as well. -- Chuck
Re: Bug in csih
On 1/16/2012 5:14 AM, Corinna Vinschen wrote:
Chuck? Ping?
How's this? (BTW, we do similar stuff in csih_create_privileged_user()
but I didn't address that).
Index: cygwin-service-installation-helper.sh
===
RCS file: /cvs/cygwin-apps/csih/cygwin-service-installation-helper.sh,v
retrieving revision 1.28
diff -u -p -r1.28 cygwin-service-installation-helper.sh
--- cygwin-service-installation-helper.sh 13 Feb 2011 23:22:34 -
1.28
+++ cygwin-service-installation-helper.sh 5 Feb 2012 20:22:07 -
@@ -2244,7 +2244,6 @@ csih_account_has_necessary_privileges()
$_csih_trace
local user=$1
- local admingroup=
if [ -n ${user} ]
then
if csih_call_winsys32 net user ${user} /dev/null 21
@@ -2255,23 +2254,14 @@ csih_account_has_necessary_privileges()
csih_warning Unable to ensure that '${user}' has the
appropriate privileges.
return 1
else
-admingroup=$(/usr/bin/mkgroup -l | /usr/bin/awk -F: '{if ( $2
== S-1-5-32-544 ) print $1;}')
-if [ -z ${admingroup} ]
-then
- csih_warning Cannot obtain the Administrators group name
from 'mkgroup -l'.
- return 1
-fi
-if ! csih_call_winsys32 net localgroup ${admingroup} |
/usr/bin/grep -Eiq ^${user}.?$
-then
- # user not in Administrators group
- return 1
-else
- /usr/bin/editrights -u ${user} -t
SeAssignPrimaryTokenPrivilege /dev/null 21
- /usr/bin/editrights -u ${user} -t SeCreateTokenPrivilege
/dev/null 21
- /usr/bin/editrights -u ${user} -t SeTcbPrivilege
/dev/null 21
- /usr/bin/editrights -u ${user} -t SeServiceLogonRight
/dev/null 21
- return # status of previous command-list
-fi
+ # Don't attempt to validate membership in Administrators group
+ # Instead, just try to set the appropriate rights; if it fails
+ # then handle that, instead.
+/usr/bin/editrights -u ${user} -t
SeAssignPrimaryTokenPrivilege /dev/null 21
+/usr/bin/editrights -u ${user} -t SeCreateTokenPrivilege
/dev/null 21
+/usr/bin/editrights -u ${user} -t SeTcbPrivilege
/dev/null 21
+/usr/bin/editrights -u ${user} -t SeServiceLogonRight
/dev/null 21
+return # status of previous command-list
fi
fi
fi
Re: realpath: cygutils or coreutils?
On 1/30/2012 7:01 PM, Charles Wilson wrote: On 1/30/2012 3:32 PM, Eric Blake wrote: In particular, it is much more powerful than the realpath(1) currently offered by cygutils. Should I build my next coreutils package with realpath included, and wait to upload it until we can coordinate a build with cygutils dropping the weaker variant? Or do we want to keep the cygutils variant for a while longer? I prefer standard tools when possible, and smaller cygutils. So, let's go ahead and coordinate removing realpath from cygutils-$next. I'm ready to cut a new release of cygutils (w.o. ascii.exe and realpath.exe) as soon as Eric is ready to upload a new version of coreutils. http://cygwin.com/ml/cygwin-apps-cvs/2012-q1/msg0.html http://cygwin.com/ml/cygwin-apps-cvs/2012-q1/msg1.html -- Chuck
CFA: support Windows 8 in /usr/lib/csih/winProductName.exe
Call for assistance: can somebody with access to Windows 8 provide an appropriate tested patch so that winProductName can recognize Windows 8 (various flavors, including Windows Server 8)? Getting the System Version http://msdn.microsoft.com/en-us/library/ms724429%28v=vs.85%29.aspx has not been updated yet. Rumor suggests GetVersionEx will return 6.2 for Windows 8, but information about distinguishing the various flavors is...not easily found? -- Chuck
Re: realpath: cygutils or coreutils?
On 1/30/2012 3:32 PM, Eric Blake wrote: In particular, it is much more powerful than the realpath(1) currently offered by cygutils. Should I build my next coreutils package with realpath included, and wait to upload it until we can coordinate a build with cygutils dropping the weaker variant? Or do we want to keep the cygutils variant for a while longer? I prefer standard tools when possible, and smaller cygutils. So, let's go ahead and coordinate removing realpath from cygutils-$next. I should have some time in the next few days to do this -- and the pending csih bugfix... -- Chuck
Re: [RFU] mingw-w64
On 12/17/2011 11:35 PM, JonY wrote: New mingw-w64 build is ready. Remove the oldest in each category, leave pthreads. Done. -- Chuck
Re: ATTENTION: Tcl/Tk transition
On 12/4/2011 7:33 PM, Yaakov (Cygwin/X) wrote: On Sat, 2011-12-03 at 18:45 -0500, Charles Wilson wrote: Yaakov -- the installed tclConfig.sh and tkConfig.sh files include stuff like this: TCL_DEFS='-DPACKAGE_NAME=\tcl\ -DPACKAGE_TARNAME=\tcl\ -DPACKAGE_VERSION=\8.5\ -DPACKAGE_STRING=\tcl\ 8.5\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DSTDC_HEADERS=1 This causes warnings (PACKAGE_NAME redefined, etc) when building other packages. Which packages are you referring to? I found this while building (msys) versions of tcl and tk, (loosely) based on your cygports. However...I modified tk's configure.in to do a proper AC_INIT. So now, tk defines PACKAGE_NAME as tk -- but inherits tclConfig's setting of tcl (and etc.). It's possible that because tk doesn't, OOB, use the proper AC_INIT invocation that you don't see this problem with your builds. But...is it really right for tk to self-identify as tcl? Fix that...and then you see the warning. However, it just seems unambiguously correct, to me, that derived packages should NOT inherit tcl's settings of those particular macros. -- Chuck
Re: ATTENTION: Tcl/Tk transition
On 12/4/2011 10:03 PM, Yaakov (Cygwin/X) wrote: On Sun, 2011-12-04 at 21:05 -0500, Charles Wilson wrote: I found this while building (msys) versions of tcl and tk, (loosely) based on your cygports. However...I modified tk's configure.in to do a proper AC_INIT. So now, tk defines PACKAGE_NAME as tk -- but inherits tclConfig's setting of tcl (and etc.). Fix that...and then you see the warning. It is win/configure.in which doesn't AC_INIT properly, not unix/configure.in. D'oh! You're right. Try building my tcl-tk and you won't see any such warnings, and PACKAGE_NAME is tk. So it would seem that your fix is incorrect. But...I'm going to have to figure out WHY you don't see the warnings. How can configure.in/config.status/Makefile-$(DEFS) set PACKAGE_NAME to tk, yet *also* include the DEFS settings sifted from tclConfig.sh which sets PACKAGE_NAME to tcl, and /not/ trigger the a macro redefinition warning? (Don't answer; it just strikes me as odd -- something funny is going on in the unix/ side and I probably ought to figure out what.) Aside: the win/ side of things is /severely/ bitrotted with regards to mingw and cygwin -- I think they only care for MSVC now -- so it's just as well your new cygwin implementations are strictly unix/-only. On the MSYS side I'm trying to hybridize: tcl=unix, tk=winGDI but with proper unixy path handing (which means translations when calling into, and of return values from, w32api functions). It's...slow going. And I wonder -- when I get that far -- whether the additional add-ons (itcl, itk, tix) will be workable at all, with tcl-ish headers under unix/ and tk-ish headers under win/; the TEA tcl.m4 seems to have provisions for such a separation...but will it work? TBD. msys-tcl seems ok so far but msys-tcl-tk: it's an unholy mess, really. :-( -- Chuck
Re: ATTENTION: Tcl/Tk transition
Yaakov -- the installed tclConfig.sh and tkConfig.sh files include stuff like this: TCL_DEFS='-DPACKAGE_NAME=\tcl\ -DPACKAGE_TARNAME=\tcl\ -DPACKAGE_VERSION=\8.5\ -DPACKAGE_STRING=\tcl\ 8.5\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE_URL=\\ -DSTDC_HEADERS=1 This causes warnings (PACKAGE_NAME redefined, etc) when building other packages. Could you update your .cygport(5) to add a line like this: -e '/^TCL_DEFS/s|-DPACKAGE[^=]*=\\\[^]* ||g' \ to the munge the tclConfig.sh section of src_install? (Likewise TK_DEFS etc). -- Chuck
Re: [ITP] astrometry.net-0.38-1
On 11/9/2011 5:00 AM, Jussi Kantola wrote: AstroTortilla is fine with a custom repo. All we ever wanted was to be able to install astrometry.net with Cygwin's setup.exe OK. How many would we need for it to be considered significant enough? No idea. Is this document still valid? http://sourceware.org/cygwin-apps/package-server.html Seems accurate -- but it's missing information about gpg security. I think you want Creating a custom Cygwin package server -- you probably don't want to create or host a full mirror. Anything else I need to know? Here's what I do, locally: top/setup.exe top/genini top/release/foo/foo-1.2.3-1.tar.bz2 top/release/foo/foo-1.2.3-1-src.tar.bz2 top/release/foo/setup.hint $ cd cygwin $ ./genini --recursive release setup.ini $ bzip2 -c setup.ini setup.bz2 Then, upload setup.ini, setup.bz2, the new tarballs and setup.hint to your website, replicating the directory structure (from top/ on down). Now, your users will have to invoke setup.exe with the -X, because otherwise setup.exe will expect the setup.ini/bz2 files to be signed. However, turning the security measures off is a problem, because then your users have no protection against corrupted files on the *main* mirrors, either. So, ideally, you would ALSO sign *your* setup.ini/setup.bz2 files. See http://www.cygwin.com/ml/cygwin-announce/2008-08/msg1.html Now, this still requires your end users to take an explicit action (see item (3i),(3ii),(3iii) in the referenced announcement.) You could enable them to do (3i) or (3iii) via a batch file that you distribute...or... See the cygwin-ports instructions for their users, here: http://sourceware.org/cygwinports/ In that case, the use of 'cygstart' implies that cygwinports would be *added* to an existing cygwin installation; hence a bare-windows installation would require two separate setup.exe runs (*). This is actually a /good/ thing, because it means there's no confusion between the standard cygwin installation on my box and the cygwinports cygwin installation on my box -- your end users would just have one, to which they've added the extra stuff. (*) future update runs of setup would handle both the 'standard' packages and the addons simultaneously. Thanks once again for your time and effort! I'm sorry the lessons you gave me will go down the drain if I won't become a package manager ... ;-) You're still managing a package...it just wouldn't be hosted as an intrinsic part of the cygwin distribution itself. -- Chuck
Re: [ITP] astrometry.net-0.38-1
On 11/7/2011 8:18 AM, Jussi Kantola wrote:
On Fri, Nov 4, 2011 at 11:13 PM, Charles Wilson wrote:
You should probably do that, to ensure that the build procedure works on
your machine. Also, to test the resuts; I have no idea how to use this
stuff.
It builds fine, and the resulting installation works fine when I put
some sky catalogs in /usr/share/astrometry/data/.
Good news. Please post *your* rebuilt packages somewhere, so they can
be uploaded.
The question
becomes, would it be better to create a separate package
(astrometry.net-data-tycho or such) for the (example/test) catalogs,
than to have them in the binary/source packages? Theoretically, and I
suppose in eventual actuality as well, there could be many different
sets of catalogs, so separate packaging sounds like the way to go ...
Definitely separate. However, it may be best not to create any catalog
packages at all, and instead provide helper scripts (in
/usr/lib/astrometry/scripts/ ?) to d/l and install the individual
catalogs. The reason for this suggestion is twofold.
First, if you create a cygwin package containing the data from catalog
foo, then cygwin will be *redistributing* that data. However, many
scientific databases of this sort, while free (gratis) to use, prohibit
redistribution -- everybody is required to get them directly from the
source. So, for this sort of catalog, a helper script to enable the
end-user to do THAT is the only solution.
Second, these catalogs are HUGE. 70GB? 25GB? That's 10 to 30 times the
size of the entire cygwin distribution, source and all -- for one
catalog. Our mirrors probably won't accept that.
Provided you can rebuild this package on your machine, AND that it actually
works, consider it GTG.
With the notice/question above, it worked like a charm -- and I thank
you dearly!
I have to admit, it was pretty painful. The upstream astrometry guys
really should work on making their project more cross-platform- and
distro-packaging- friendly. E.g. use the autotools including autoconf,
automake, and libtool throughout, and treat all of the helper
libraries -- gsl-an, libkd, liban*, etc -- as libtool convenience
libraries, link all the utils against the top-level backend lib, ...
Oh, but we'd lose all the make-it-really-fast fine-tuned CFLAGS
settings in our hand-rolled makefiles -- fine, create a FastMakefile
that deduces the platform, and invokes (top-level) configure with the
appropriate CFLAGS, CPPFLAGS, and LDFLAGS, and tell users to do
make -f FastMakefile make
...Premature optimization is the root of all evil. -- Donald Knuth.
E.g. make it work, THEN make it work fast.
But that's not your problem...nor mine. :-)
Go ahead and post your rebuilt packages, and I'll upload them. Postpone
the star catalog pkgs and/or helper scripts for the -3 release (*)
--
Chuck
(*) howto: drop the scripts in the CYGWIN-PATCHES directory, and add
lines like the following to the end of the src_install() function in the
.cygport file:
exeinto /usr/lib/astrometry/scripts
doexe ${C}/my-first-script
doexe ${C}/my-second-script
Since the scripts would probably use wget or curl to d/l the catalog(s),
you'd want to update the requires: line in your setup.hint.
Re: [ITP] astrometry.net-0.38-1
On 11/7/2011 11:17 AM, Christopher Faylor wrote: I've been trying not to offer an opinion here but it isn't clear to me why so many people voted +1 for this package. It seems like we're adding a huge package Meh, if you exclude the star catalogs (and I think we should; and the OP has agreed to avoid), then bin+src weighs in at 25MB (65MB uncompressed), which is pretty large but not unheard of. Most of that is because it has a ton of exe's, and all but one are linked statically to various support libraries. (Oddly all of those libs get dumped together into the DLL, and that dll is used by only one client. But, conceivably, the other exes could also link to that dll, for a big win: from 45MB uncompressed to approx 2.5MB, based on my seat-of-pants calculation). to the distribution just to help out a very miniscule user base. Meh, without casting aspersions, I doubt the user base of our various specialized math tools -- like singular, octave, fftw3, qhull, etc -- are very large in absolute terms. But...we have maintainers, they volunteered and contributed, so here we are. If they go AWOL, then the package gets slapped with _obsolete. Same deal here. Do we really need this package in the Cygwin distribution? Well, not as such, no. We don't really NEED very much of what's currently part of the distro -- but that's never been the justification for package acceptance. Do we need fortune or robots? I think it's kinda cool for cygwin be one of the first (not THE first; it's already in BSD ports IIUC) to provide these tools, so that's why I voted +1. However, you're still (one of the) benevolent(?) dictators-for-life. Are you exercising a veto? If so, we can teach the OP how to set up an add-on setup.exe repository, like cygwin-ports, which he can host over at astronomytortilla or whatever -- so it's not a disaster if you are vetoing. -- Chuck
Re: [ITP] astrometry.net-0.38-1
On 10/7/2011 12:18 PM, Jussi Kantola wrote: However I had to modify backend-main.c so that the config file (which defines the location of index files) could be read from cygwin's preferred location, /usr/share/astrometry/etc/backend.cfg. That's a little odd, and I don't think that's exactly what was meant by the documentation http://cygwin.com/setup.html#package_contents. I don't think this is a showstopper for this release, but ordinarily configuration files belong in the top-level /etc directory. However, once installed there, a name like backend.cfg is poorly chosen, since it doesn't really indicate what package it belongs to, and thus might conflict with some other package. /usr/share/pkg/ is usually used for other, more extensive data files and support -- e.g. that's probably where your star catalog files (indexes?) ought to go. Furthermore, if backend.cfg is user-editable, then you would probably want to install it into /etc/defaults/etc/backend.cfg and include a postinstall/preremove scripts here: (a) /etc/postinstall/astrometry.net.sh (b) /etc/preremove/astrometry.net.sh whose job is to (a) copy the default version into /etc on install, IF no such file already exists, and (b) remove the /etc/backend.cfg file on uninstall, if and only if it is identical to the /etc/defaults/ one. See /etc/postinstall/tcp_wrappers.sh [or .done] /etc/preremove/tcp_wrappers.sh for and example. FYI, cygport will handle creating these scripts for you (almost) automatically, via a single command: make_etc_defaults /etc/backend.cfg All this complexity is so that user-modified configuration settings don't get clobbered by package updates, but non-modified files will get updated. However, what is probably a showstopper are various lines like this in the build: # Try building and installing python spherematch module make install-spherematch make[2]: Entering directory `/usr/src/packages/tmp/astrometry.net-0.38-1/libkd' python setup.py build --force --build-base build --build-platlib build/lib running build running build_py creating build creating build/lib copying spherematch.py - build/lib running build_ext building 'spherematch_c' extension creating build/temp.cygwin-1.7.9-i686-2.6 gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/usr/lib/python2.6/site-packages/numpy/core/include/numpy -I../qfits-an/include -I../util -I. -I/usr/include/python2.6 -c pyspherematch.c -o build/temp.cygwin-1.7.9-i686-2.6/pyspherematch.o gcc -shared -Wl,--enable-auto-image-base build/temp.cygwin-1.7.9-i686-2.6/pyspherematch.o libkd.a ../util/libanfiles.a ../util/libanutils.a ../qfits-an/lib/libqfits.a -L/usr/lib/python2.6/config -lpython2.6 -o build/lib/spherematch_c.dll cp build/lib/spherematch_c.so spherematch_c.so cp: cannot stat `build/lib/spherematch_c.so': No such file or directory make[2]: *** [spherematch_c.so] Error 1 IOW, cygwin python's distutils is _doing the right thing_ -- creating the plugin with the name spherematch_c.dll -- but the Makefile in astrometry.net thinks the plugin will always be named spherematch_c.so and reports an error when it tries to install the latter file. Also, when I did 'make install ...' my lib/astrometry/bin directory was empty. I can't help but think this will cause problems for your users... Now, this bit is interesting: - mkdir -p $(INSTALL_DIR)/python/astrometry/libkd + mkdir -p $(INSTALL_DIR)/share/astrometry/python/astrometry/libkd Normally, python extensions go under the real python dir: /usr/lib/python2.6/site-packages/pkgname/... But...this whole build system doesn't really support that; it hardcodes the destination path and then adds that path to sys.path via the application .py files; when it really should use some mechanism to find the entry in $python's sys.path list which contains site-packages. So...accepting that, the python stuff should ALSO go under /lib rather than /share, because (a) the .pyc files are platform specific, and (b) the .dll's which ought to go there are also platform specific. so, not GTG. Also, you missed Corinna's statement: If the binaries are using it (the libbackend library), they should also be linked against [the DLL], rather than being linked statically. Your build still links against libbackend.a, rather than cygbackend.dll. I'm trying to massage your -src package to DTRT. Stay tuned. -- Chuck
Re: [ITP] astrometry.net-0.38-1
On 11/4/2011 11:11 AM, Yaakov (Cygwin/X) wrote: software is quite unpolished. From reading the web page, it appears to be a research project by a couple of grad students -- with goals of supporting amateur and even professional astronomers by automating what is currently a labor-intensive task. So...like all research projects, it appears to suffer from get-it-done-itis focused on Linux and/or BSD, with little attention paid to portability. That's...problematic when going to any flavor of win32, including cygwin. I mean really: hand-editing makefiles? no configure scripts (some subdirs have them, but they are invoked as part of the top-level make, which doesn't). IMO the whole thing needs to be autotoolized, but I'm not going there. OTOH, I just spent a couple hours adding $(EXE) to about a thousand makefile rules, only to watch it blow up because of some built-in rule I can't turn off (where is it COMING from!!!??) that adds foo.exe.o to the dependencies and then looks for foo.exe.c to build it...Aaarrrggh -- Chuck
Re: [ITP] astrometry.net-0.38-1
On 11/4/2011 2:29 AM, Charles Wilson wrote: Your build still links against libbackend.a, rather than cygbackend.dll. I'm trying to massage your -src package to DTRT. Stay tuned. I've posted a revised version of your package here: http://cygwin.cwilson.fastmail.fm/astrometry.net-0.38-2-src.tar.bz2 http://cygwin.cwilson.fastmail.fm/astrometry.net-0.38-2.tar.bz2 Inside the -src tarball is the *original* upstream sources (astrometry.net-0.38.tar.bz2), a few patches, and a .cygport script. to rebuild, unpack the -src and do: $ cygport astrometry.net-0.38-2.cygport all You should probably do that, to ensure that the build procedure works on your machine. Also, to test the resuts; I have no idea how to use this stuff. Finally: the backend.exe program is linked to cygbackend.dll, which are both in /usr/lib/astrometry/bin/. All the python stuff, including three extension DLLs, are in /usr/lib/astrometry/python/*/ I modified the build procedure for cygbackend.dll -- it now generates an import lib, and it also (re)exports all of the symbols from the other (sub)libraries. That means when linking backend.exe, you don't need to list those other dependencies, because cygbackend.dll will satisfy them all. (*) Provided you can rebuild this package on your machine, AND that it actually works, consider it GTG. (*) I did not do this, but because cygbackend now exports all the symbols from (e.g.) libanfiles.a, libutils.a, libkd.a, etc, you COULD modify the link commands for almost all of the /other/ .exe's in the blind/ directory, which currently link against (many) of those static libraries, to instead link solely against cygbackend.dll (actually, libbackend.dll.a). That would make the entire package MUCH smaller. But it's a lot of work. -- Chuck
Re: [ITP] astrometry.net-0.38-1
On 11/3/2011 8:02 AM, Corinna Vinschen wrote: I hoped that somebody who voted on the package would do the final GTG, but in vain it seems. Sorry...I had intended to, but got swamped with other stuff. :-( Anyway, I just had a look. The packaging now looks basically good. One issue I still have with the package is the big number of non-standard binaries in /usr/bin. Is it really necessary to have all the binaries as user-accessible binaries in /usr/bin? Or are many of the binaries just called from another (or other) binaries which serve as the primary UI? What also bugs me are the generic names of the binaries. Plotstuff, merge-index, tablist, tabsort, checktree, ... This all sounds not much like astronomer stuff. So, I would prefer to split the binaries into two groups: - UI binary (or binaries) into /usr/bin - Helper binaries into /usr/share/astrometry/bin FHS says that architecture-dependent files should go under /usr/lib/ not /usr/share...so /usr/lib/astrometry/bin -- Chuck
Re: ATTENTION: Tcl/Tk transition
On 10/30/2011 8:44 PM, Yaakov (Cygwin/X) wrote: Please don't. ... This is just the beginning. Mixing GDI and X11 just doesn't work, and since X11 is used for all other GUIs on Cygwin, so must Tk. My suggestion, for those who wanted this, was to build the entire tcl/tk(GDI) stack with a unique prefix -- that way it wouldn't BE mixed with the other clients which (will soon be) compiled to use the X11 version. And, to even use it at all, one would have to put it in the PATH ahead of /usr/bin. That's surely not standard; and if somebody does this and it breaks something -- then they get to keep both pieces. WJM, after all. -- Chuck
Re: cygutils: replace ascii with ESR's?
On 10/30/2011 8:26 PM, Yaakov (Cygwin/X) wrote: ESR maintains a standalone ascii(1) which appears to have more features than cygutils': http://catb.org/~esr/ascii/ Should we replace this? Patch attached if so. Well, I have mixed feelings. On the PRO side: 1) smaller cygutils == fewer headaches for me. Also, since cygutils is now pulled in by several Base packages, the smaller it becomes, the better. 2) Following the same thought, if something is available (and maintained) elsewhere then cygutils shouldn't duplicate effort, unless its version really adds value -- or is unique to the cygwin platform (e.g. cygdrop). [Hmm...dump.exe = 'od -Ax -tx2z'?] 3) show all names for a single character feature is...interesting. I like the aliases listed for '' (includes gozinta -- and I haven't seen 'bra' and 'ket' used for '' and '' since Statistical Mechanics and Quantum Dynamics...tho technically it is '|' and '|') However, on the CON side: 1) I really find the default table output of ESR's version rather ugly (and the hex only -x, decimal only -d, and octal only -o tables are downright hideous). 2) No long options (so -h/-? work, but --help doesn't. Ditto -v vs. --version). And no --license. 3) Not sure if this matters, but ESR's version has no option to display the high-bit-set character codes (128..255). I find this feature of cygutils-ascii much less useful these days, now that charset:oem (and rxvt) are as-good-as-dead, and other terminals with *real* charset support -- like mintty, xterm, or rxvt-unicode -- are gaining almost complete prevalence on cygwin. I'll wait and see what other folks think before making a decision. Comments, anyone? -- Chuck
Re: ATTENTION: Tcl/Tk transition
On 10/31/2011 7:39 PM, Charles Wilson wrote: On 10/30/2011 8:44 PM, Yaakov (Cygwin/X) wrote: Please don't. ... This is just the beginning. Mixing GDI and X11 just doesn't work, and since X11 is used for all other GUIs on Cygwin, so must Tk. My suggestion, for those who wanted this, was to build the entire tcl/tk(GDI) stack with a unique prefix -- that way it wouldn't BE mixed with the other clients which (will soon be) compiled to use the X11 version. And, to even use it at all, one would have to put it in the PATH ahead of /usr/bin. That's surely not standard; and if somebody does this and it breaks something -- then they get to keep both pieces. WJM, after all. In case it wasn't clear, my suggestion was that if somebody did this, it should be hosted by a a third-party repository (similar to how cygwin-ports is structured), and not part of the actual cygwin distribution. -- Chuck
Re: cygutils: fix bootstrap for libtool2
On 10/25/2011 10:30 PM, Yaakov (Cygwin/X) wrote: libtool2 uses several aclocal macros, and libtoolize copies them into m4/ automatically. Patch attached. Applied. Thanks (wow, that bug has been there a while. I usually have ignored bootstrap and simply run autoreconf, so I never noticed.) -- Chuck
Re: cygutils: cygstart FD.o integration
On 10/25/2011 10:46 PM, Yaakov (Cygwin/X) wrote: The attached patch and new files integrate cygstart into the Freedesktop.org desktop menu system. This allows Windows-specific files (e.g. .exe, .com, .bat, .msi, .themepack) to be easily opened by cygstart from within FD.o/X file managers (e.g. Nautilus, Thunar, PCManFM, Dolphin). Applied. Thanks! I've got a few items (still) in my queue before releasing 1.4.8...but I'll try to move those up the priority list. -- Chuck
Re: ATTENTION: Tcl/Tk transition
On 10/26/2011 5:53 PM, Cary R. wrote: If I'm understanding this correctly once this change has been pushed we will be required to start an X server beforerunning gitk. Yes. As someone who uses git and gitk all the time having to start the X server to run gitk is a pain. I haven't checked this recently, but in the past the X server was a bit of a resource hog so my typical pattern is toonly start it when needed and that's not very often. Well, the cygwin-X folks have made a lot of improvements over the past year or so (and the accelerated version looks to be coming along...). However, because XWin.exe /is/ a cygwin app, it suffers all the normal posix-win32 emulation penalties that every cygwin app does. So, one solution is to just use the native win32 XMing xserver (free-as-in-beer version, or the donation-supported one). tk only depends on libX11.dll (no other X extensions), so on the client side tk is fairly light in its X-incarnation. Also, here's the cygwin-git maintainer from three years ago: http://www.cygwin.com/ml/cygwin/2008-08/msg00095.html Eric Blake wrote: According to Christopher Faylor on 8/4/2008 5:38 PM: | That opens the door to building a | real version of tcl/tk for cygwin and linking insight to it. YEAH! Among others, the git package would appreciate the availability of a modern tcl/tk. So... I understand the desire to switch to X, but I think this deserves some thought on how it will effect the general users. Well, I think it *has* been thought about, and discussed, quite a bit. The decision was pretty much adopted -- only the implementation has been delayed due to (a) lack of roundtuits of the 'cgf' denomination, (b) in the far past, we had no /modern/ (7.x) X implementation and were limping along with a very old X distro. Obviously, until (b) was fixed, it made no sense to modify tcltk. And until (a) improved -- which, apparently, it never did -- the implementation couldn't happen. Hence, cgf's decision to invite Yaakov to take over. Here are some of the previous discussions: Interest in native Tcl/Tk/Expect/Itcl/... packages? http://cygwin.com/ml/cygwin-apps/2004-10/msg00316.html Does anyone use insight on cygwin? http://www.cygwin.com/ml/cygwin/2008-08/msg00089.html tcl/tk/expect/dejagnu/gdb/insight http://cygwin.com/ml/cygwin/2009-09/msg00311.html gitk unusable in cygwin-1.7.6-1 because tcltk-20080420-1 is native win32 app. http://cygwin.com/ml/cygwin/2010-08/msg00913.html NOTE in the gitk thread above, Reini Urban, the cygwin perl and parrot maintainer, was vehemently against switching tcltk from GDI to X11. I wonder if his opinion has changed in the past year... Tcl file separator http://cygwin.com/ml/cygwin/2011-01/msg00257.html (esp. http://cygwin.com/ml/cygwin/2011-01/msg00369.html) Re: RFC: Cygwin 64 bit? http://cygwin.com/ml/cygwin-developers/2011-06/msg00081.html -- Chuck
Re: [ITP] astrometry.net-0.38-1
On 10/4/2011 4:02 AM, Jussi Kantola wrote: category: Science requires: cairo libcairo2 python-cairo libnetpbm10 netpbm libpng14 libjpeg8 zlib zlib0 python python-numpy pkg-config cygwin sdesc:Astrometry.net astrometrical solver. ldesc:Astrometry.net analyses an astronomical image (photograph of the night sky) to output, among other things, the central coordinate of the image, the visible field of view, and the list of deep sky objects potentially visible within the field. +1. However, as Corinna pointed out, there are some issues with the packaging. I'll take a look this weekend and come up with some suggestions for you. FYI, you probably don't need to list both zlib and zlib0 as requires: (most packages need just the dll, in zlib0). Ditto for cairo and libcairo2 -- you probably only need libcairo2. Also, it is no longer recommended to include 'cygwin' in the requires: list -- it is assumed that cygwin is a requirement for everything. -- Chuck
Re: [ITP] nosleep 0.1.3-1 (needs GTG)
On 9/30/2011 6:00 AM, Andrew Schulman wrote:
I'd like to package and maintain nosleep for Cygwin. nosleep runs a
command while inhibiting the computer from sleeping or hibernating until
the command finishes executing.
Thanks for voting everyone. Would someone now please review the packaging?
The package is small - just one exectable and 6 doc files.
Packaging is GTG. I didn't check the application's functionality.
Since you don't have a test suite, you might want to define a src_test
function in the cygport:
src_test() {
:
}
--
Chuck
Re: [ITP] nosleep 0.1.3-1
On 9/25/2011 6:15 AM, Andrew Schulman wrote: nosleep has been written originally for Cygwin, so it's not available in any Linux distros and needs to be voted on. +1 -- Chuck
Re: New rebase release
On 9/20/2011 11:24 AM, Jason Tishler wrote: On Mon, Sep 19, 2011 at 02:53:54PM -0400, Charles Wilson wrote: After the flurry of work and new features added to rebase in late July/early August, any chance you could bump the version and roll a new release? Yes. Should the next version be 4.0 or 3.1? I recommend the former, since there has been many significant changes. I agree: 4.0. We could call it rebase NT for New Technology -- that is much better than 3.1, which is merely a pretty wrapper around the same old underlying cruft. :-) Did anybody see the suggested new logo for the linux 3.1 kernel: http://thehackernews.com/2011/09/suggested-linux-31-kernel-logo.html -- Chuck
Re: [RFU] mingw64-*-gcc Update
On 9/20/2011 9:27 AM, JonY wrote: This update is to fix a typo in the gcc configure command that went long unnoticed, now with --enable-dynamic-string. Anybody using C++ libraries are encouraged to recompile. Keep previous versions, thanks. Done. -- Chuck
New rebase release
Jason, After the flurry of work and new features added to rebase in late July/early August, any chance you could bump the version and roll a new release? -- Chuck
Re: New rebase release
On 9/19/2011 3:46 PM, Reini Urban wrote: On Mon, Sep 19, 2011 at 8:53 PM, Charles Wilson x...@yyy.zzz wrote: PCYMTNQREAIYR That is all. -- Chuck
Re: [RFU] mingw-w64
On 8/31/2011 5:48 AM, JonY wrote: On 8/31/2011 17:11, Corinna Vinschen wrote: On Aug 31 15:15, JonY wrote: BTW, is GCC 4.6 for Cygwin anywhere near? :) 4.5.3 is near, afaik. OK, I was wondering how to transition 4.5.x to 4.6.x for mingw-w64 when the time comes, pthreads-win32 will be removed in favor of winpthreads, they're not exactly ABI compatible. Right now, only libgomp is using pthreads-win32. So, it sounds like mingw64's version of libgomp (for gcc-4.6) will have to bump its DLL number from the current libgomp-1.dll to libgomp-2.dll -- you don't want an existing -fopenmp client, that links to both libgomp-1.dll (which itself depends on pthreadGC2.dll) pthreadGC2.dll to suddenly get surprised by (new) libgomp-1.dll (which depends on winpthreads-0.dll) pthreadGC2.dll because then that existing client would depend on two different pthreads implementations. That's a sure recipe for failure... C++ ABI for 4.6.x has also changed for mingw* (including mingw.org) with the introduction of thiscall, not sure if this will affect Cygwin itself. Hmm. don't know what the correct (mingw[64]) solution for this would be. In the past, when the C++ ABI changed, we didn't bump the libstdc++ DLL number, because so many other things ALSO break (in precompiled C++ clients), that just isolating ONE change via the DLL number of one runtime lib was pointless. I suspect that is true here, too. It probably means a flag day -- all precompiled mingw[org,64] C++ offerings will need to be simultaneously upgraded with the release of the mingw[org,64] 4.6 compiler. (I don't think mingw.org HAS any, so...non-issue). OTOH, the cygwin project DOES provide several precompiled C++ packages, so cygwin will probably need to do a flag day for them (when cygwin-gcc-4.6 is released), but I don't think the cygwin package ITSELF would be affected. -- Chuck
Re: setup.exe opening page graphic
On 8/31/2011 5:42 AM, Corinna Vinschen wrote: Here's the reply from legal: We can use your 2D results from the DAZ art, as long as you put your resulting work under a free license which plays nice along the GPL. You don't have to assign copyright to some other entity like, say, Red Hat. GPL or FAL(*) both sound good to me; FAL matches the intent better, I guess. YAY!! -- Chuck
Re: setup.exe opening page graphic
[moved to cygwin-licensing] On 8/31/2011 2:48 PM, Warren Young wrote: Lacking any recommendation, I would have gone with some CC variant. I'll look into FAL first now. If it turns out that I still like CC better, I'll check for GPL compatibility. I can already rule out all the Attribution variants, for the same reason 4-clause BSD is incompatible, right? The Creative Commons FAQ explicitly says that the CC licenses (all of them, except CC0) are incompatible with the GPL -- but they say that in the context of applying CC licenses to *software*. http://wiki.creativecommons.org/FAQ#Can_I_use_a_Creative_Commons_license_for_software.3F In fact, there ARE no non-attribution CC licenses anymore. They used to have some, back in the v1.0 days: http://creativecommons.org/licenses/sa/1.0/ but they are now retired and not recommended. OTOH, debian-legal says that CC-BY-SA v3.0 (*not* 2.0) is compatible with the DFSG...which is not, of course, the same as saying it is GPL compatible. http://wiki.debian.org/DFSGLicenses#Creative_Commons_Attribution_Share-Alike_.28CC-BY-SA.29_v3.0 http://www.gnu.org/licenses/license-list.html gnu.org says that neither CC-BY-2.0 nor CC-BY-SA-2.0 are GPL compatible. They make no statement concerning v3.0 of those licenses, but I rather suspect the 3.0 versions are also incompatible (-BY-). On this page: http://www.gnu.org/licenses/licenses.html FSF says We don't take the position that artistic or entertainment works must be free, but if you want to make one free, we recommend the Free Art License (http://artlibre.org/licence/lalgb.html) The basic problem is, most strong copyleft licenses are mutually incompatible; this really can't be avoided because it's the part of each license that makes it strong that causes the difficulty; each license implements strong differently (usually by requiring derived works to carry *the same* license: you can't do that if two different licenses apply [*]). [*] Dual licensed software is different: it says you can accept one OR the other license: e.g. GPL OR MPL. GPL OR Proprietary. Not both-at-the-same-time. Old article, but contains quotes from FSF legal beagles: http://www.linux.com/archive/feed/119212 Short version: even the v3.0 CC-BY-SA licenses are probably incompatible with the GPL. You can get around that if your derived work -- software + art -- is a mere aggregation. So, Q: is bundling an icon as a resource in an .exe mere aggregation? I think it CAN be -- in fact, I rely on it, in building cygicons.dll as a mere aggregation of several different icons with different licenses. OTOH, I dunno if you can plausibly make the argument that *the icon developed specifically for setup.exe*, when linked into that exe as a resource, it actually a mere aggregation! Anyway, Corinna's email above reports that the Red Hat lawyers say the 'free license' applied to the art, must play nice along the GPL. If that means specifically compatible with, then it rules out CC-BY-SA-2.0, CC-BY-2.0, and all other CC-BY-* (ND, NC) variants except CC0 It may -- probably does -- rule out CC-BY[-SA]-3.0 GPL itself is problematic, given the preferred form for modification of the source requirement. What IS that? I've looked over a ton of debates, incl. debian legal, and nobody seems to have a good answer. FAL -- is this really GPL compatible? http://en.wikipedia.org/wiki/Free_Art_License says no Section 5 of the FAL: 5. COMPATIBILITY A license is compatible with the Free Art License provided: it gives the right to copy, distribute, and modify copies of the work including for commercial purposes and [1]without any other restrictions than those required by the respect of the other compatibility criteria; it [2]ensures proper attribution of the work to its authors and access to previous versions of the work when possible; [3]it recognizes the Free Art License as compatible (reciprocity); it requires that changes made to the work be subject to the same license or to a license which also meets these compatibility criteria. I think [1], [2], and [3] might be problems: [1] the GPL imposes a restriction that the FAL does not: GPL requires distribution of source code, while the FAL requires only access to the previous version when possible [2] isn't this like the advert clause in the original BSD? [3] the GPL certainly doesn't make any explicit reference to the the FAL, and the FSF doesn't seem to give any advisory opinion on whether the THEY recognize the FAL as compatible. But here's the elephant in the room: almost ALL discussions of license compatibility have to do with whether *software* under one license can be combined with *software* under another license. E.g. GPL apple + MIT apple. NOT GPL apple + FAL orange. So even
