Re: [ITP] man-db
On 2014-06-02 10:37, Chris J. Breisch wrote: Chris J. Breisch wrote: I replied to this off-list accidentally. Yaakov (Cygwin/X) wrote: On 2014-05-30 12:32, Yaakov (Cygwin/X) wrote: I started reviewing this, see inline. My modifications can be found here: https://sourceforge.net/p/cygwin-ports/man-db/ I've incorporated Yaakov's patches. There is a new version at http://files.breisch.me/pub/cygwin/man-db-64/ The setup.hint looks like it wasn't replaced. Yaakov
Re: [ITP] man-db
On 2014-05-30 12:32, Yaakov (Cygwin/X) wrote: I started reviewing this, see inline. My modifications can be found here: https://sourceforge.net/p/cygwin-ports/man-db/ On 2014-05-30 09:22, Chris J. Breisch wrote: Still, I've put up a new set of files, now. I eliminated the library package for a few reasons. 1) The libraries can't be compiled into DLL's without some effort. They appear to have unresolved references. I'm looking into this. There are two issues here: 1) The undefined symbols not allowed in $host shared libraries warning just means that you need to add -no-undefined to *_la_LDFLAGS. In fact, that's the only issue with making libman shared. (See my 2.6.7-shared-libman.patch) 2) OTOH, libmandb also depends on two global variables which are meant to be defined by executables. In order to make this shared, the global declarations need to be moved to libmandb itself, while the executables still define their values, making for a somewhat larger patch. (See my 2.6.7-shared-libmandb.patch) This latter patch may be harder to carry from one version to the next, and if another executable is added which depends on libmandb and you forget to adapt it accordingly, it will crash. So I'm actually going to suggest that you NOT use the latter, and leave libmandb static (which is the smaller of the two anyway). 2) There's no simple set of include files related to just the libraries. I could put out all of the includes, but it looks to me as if that would get messy rather quickly. These libraries are private, that's why no headers are installed. The libraries are shared just to save space by not duplicating the same objects in all the binaries. This stands; there should be neither a -libs nor -devel subpackage. I also updated the postinstall and preremove scripts to handle creation and removal of the database. I made some changes to these, but I'm wondering if we need a special _update-mandb package (similar to _update-info-dir) to manage this instead. Thoughts? This being my first attempt, I'm sure I've done something wrong. :) Just let me know what it is and I'll fix it promptly (and it actually should be promptly this time as my crisis is now under control). Other changes I made: * Use explicit --with-browser and --with-pager flags to not be affected by builder's environment (e.g., on my system BROWSER=epiphany :-), and added these to REQUIRES. * po4a is a build requirement for localized manpages of man itself; I just added this to the 64-bit distribution, and will attempt to do so soon for the 32-bit distribution as well. Please review the changes I made in my .cygport, let me know if you have any questions. Yaakov
Re: [ITP] mp3info-0.8.5a
On 2014-05-31 17:58, Filipp Gunbin wrote: On 2014-05-30 18:22, Filipp Gunbin wrote: mp3info does not write or play mp3 stream (but it may read the stream when given -r or -x switches, I don't know exactly). And that's exactly why we can't allow it. My final attempt: what if we remove those switches in a cygwin-specific patch? No. Yaakov
[SECURITY] libtasn1, gnutls
Dr. Volker Zell, gnutls-3.2.15 and libtasn1-3.6 contain fixes for several security vulnerabilities. Are you able to update these libraries soon? Yaakov
Re: [ITP] mp3info-0.8.5a
On 2014-05-29 17:14, David Stacey wrote: On 29/05/14 18:26, Yaakov (Cygwin/X) wrote: Sorry; our policy is to not include MP3 software in the distribution, so unfortunately this package cannot be accepted. Could you possibly elaborate on this please, as I wasn't aware of this policy. I presume that it's something like licence issues (not free as in freedom) or the risk of patent violation surrounding MP3. https://fedoraproject.org/wiki/Forbidden_items#MP3_Support I ask because a little while ago I managed to put a typo in a tag of a number of MP4 files, and corrected these by building AtomicParsley [1] for Cygwin. I had intended to offer it here, in case someone else found it useful. If AtomicParsley falls under the same policy then that's fine; I'll strike it off my list of things to do. The issues with some multimedia formats generally only apply to playing or writing the actual media stream (as mp3info does), not to reading the metadata (tags). Note that libid3tag and taglib are both in the distro for this reason. Similarly, AtomicParsley falls in the latter category, and is already in Fedora, so feel free to ITP it if you wish. The latest versions have been moved to BitBucket though: https://bitbucket.org/wez/atomicparsley/downloads HTH, Yaakov
Re: [ITP] man-db
I started reviewing this, see inline. On 2014-05-30 09:22, Chris J. Breisch wrote: Still, I've put up a new set of files, now. I eliminated the library package for a few reasons. 1) The libraries can't be compiled into DLL's without some effort. They appear to have unresolved references. I'm looking into this. 2) There's no simple set of include files related to just the libraries. I could put out all of the includes, but it looks to me as if that would get messy rather quickly. These libraries are private, that's why no headers are installed. The libraries are shared just to save space by not duplicating the same objects in all the binaries. So even if shared libraries can be built, the question will really be if it's worth the trouble. I also updated the postinstall and preremove scripts to handle creation and removal of the database. The files can be found at: http://files.breisch.me/pub/cygwin/man-db-64/ This being my first attempt, I'm sure I've done something wrong. :) Just let me know what it is and I'll fix it promptly (and it actually should be promptly this time as my crisis is now under control). Looking at Fedora's packaging, a few changes are definitely needed; I'll have more time for this early next week. Thanks, Yaakov
Re: cygport patches for texlive.cygclass
On 2014-05-30 14:18, Ken Brown wrote: I'm attaching texlive_arch.patch and texlive_install.patch. The first takes account of the fact that upstream TeX Live now supports 64-bit Cygwin. The second avoids installing files that are intended for TeX Live on native Windows. Committed to master with some minor formatting changes. Thanks, Yaakov
Re: [ITP] mp3info-0.8.5a
On 2014-05-30 18:22, Filipp Gunbin wrote: mp3info does not write or play mp3 stream (but it may read the stream when given -r or -x switches, I don't know exactly). And that's exactly why we can't allow it. Yaakov
Re: [ITP] mp3info-0.8.5a
On 2014-05-28 18:26, Filipp Gunbin wrote: I'd like to maintain mp3info for Cygwin. It does not have a good build system, but it's simple and I somewhat managed it to work. Besides using it as a standalone utility, it can be used in Emacs EMMS (that's in fact is why I need it). Sorry; our policy is to not include MP3 software in the distribution, so unfortunately this package cannot be accepted. I hope you will still consider becoming a maintainer for another package. There are always packages needing new maintainers; these are marked as ORPHANED here: https://cygwin.com/cygwin-pkg-maint Yaakov
HEADSUP: krb5 rebuild
As just announced on the list, I have switched our Kerberos implementation from Heimdal to MIT. The following packages need to be rebuilt ASAP once you upgrade your libkrb5-devel and its dependencies: * cyrus-sasl (David Rothenberger) * serf (David Rothenberger) * squid (Dr. Volker Zell) Dr. Volker, I understand your away right now; would you like me to do the rebuild for you? Also, a number of other packages which don't currently have any Kerberos support available may benefit from a rebuild: * amanda * c-client * cvs * fetchmail * ghostscript * neon * libtirpc * postgresql Let me know if you have any issues with upgrading and/or rebuilding your packages. Yaakov
Re: perl-5.18.2-1
On 2014-05-04 02:29, Achim Gratz wrote: Achim Gratz writes: First off, there is a flurry of changes in the content of perl_vendor that you didn't list in the announcement. This is exactly my gripe with opaque bundling: anyone who's been relying on perl_vendor to deliver a certain set of Perl distributions will suddenly find that some have been removed and others have been added and the only way to find that out is to look into the source archive. The residual changes would be a removal of Crypt-SSLeay and IPC-Cmd, while IPC-Run, Test-NoWarnings and Test-Tester would still be supplied by the build dependencies. Unless someone has a strong opinion that these two should be dropped, I'd continue to have them available. I have a few packages in Ports that require Crypt::SSLeay. Yaakov
Re: [PATCH cygport] Make src packages which put files under /usr/src/package-version-release/
On 2014-04-27 21:34, Yaakov (Cygwin/X) wrote: On 2014-04-24 15:42, Jon TURNEY wrote: From a previous discussion [1] on this subject, it seems to be that if this is desirable, then source packages should be fixed rather than working around this in setup. Attached is a patch to cygport to do exactly that. The downside is, if you then rebuild the package like that, you end up with /usr/src/NAME-VERSION-RELEASE/NAME-VERSION-RELEASE[.ARCH, as of today's git master], which seems a bit repetitive to me. What do you (and others) think about making the topdir also the workdir if the former is already of the form NAME-VERSION-RELEASE.ARCH, as per the attached patch instead? There didn't seem to be a desire to avoid the repetition, so I dropped that part and committed a simpler version of this to master. Yaakov
Re: perl-5.18.2-1
On 2014-05-02 21:05, Ken Brown wrote: On 5/2/2014 4:21 AM, Achim Gratz wrote: Reini Urban writes: It's vastly easier to keep perl_vendor than to split it up. I've been looking at the test package for the upcoming 5.18.2 release announced in http://cygwin.com/ml/cygwin-announce/2014-04/msg00038.html and I'd like to contest that assertion again. TL;DR: I still propose to keep each Perl distribution as a separate package (yes, I'm willing to ITP them) and move perl_vendor to an umbrella package that simply bundles those individual packages plus perhaps a README. I'm not even sure that such an umbrella is needed. Maintainers of packages that rely on Perl modules can simply use cygport to determine which perl-* packages are required. I don't see the need for a perl_vendor package that brings in some arbitrarily chosen collection of Perl modules. Reini, I know you think it's more work to split up perl_vendor than to keep it as is, but Achim has offered to do the work. And it would make things much easier for those of us who maintain packages that require Perl modules. With the current bundling, we have to check for each required module whether or not it's included in perl_vendor. I just did this for biber, and it's very tedious. I hope you'll reconsider. +1, and I'm willing to help with some of the modules as well. Yaakov
Re: [RFC] cygport: arch-specific workdir
On 2014-03-27 13:50, Yaakov (Cygwin/X) wrote: On 2014-03-19 13:04, Yaakov (Cygwin/X) wrote: On 2014-03-19 11:32, Ken Brown wrote: I've just started experimenting with using cygport for cross compiling, and I've come across two issues: 1. This is just a request: The latest cygport for Fedora appends i686 or x86_64 to the name of the working directory. I would find it convenient if cygport did the same thing on Cygwin, at least if the --32 or --64 option is specified. Actually, that is experimental code (based on a request from another cygport user) that was accidentally shipped when I had to reroll the source tarball for compatibility with F20/UnversionedDocDirs. Would people like to see this done always, never, or only when cross-building? This is now in git master. Yaakov
Re: [PATCH cygport] Make src packages which put files under /usr/src/package-version-release/
On 2014-04-24 15:42, Jon TURNEY wrote:
From a previous discussion [1] on this subject, it seems to be that if this is
desirable, then source packages should be fixed rather than working around
this in setup.
Attached is a patch to cygport to do exactly that.
The downside is, if you then rebuild the package like that, you end up
with /usr/src/NAME-VERSION-RELEASE/NAME-VERSION-RELEASE[.ARCH, as of
today's git master], which seems a bit repetitive to me. What do you
(and others) think about making the topdir also the workdir if the
former is already of the form NAME-VERSION-RELEASE.ARCH, as per the
attached patch instead?
(As an aside, how would a patch to move Method one and Method two to an
archive page be received? It seems to me that they are not relevant to nearly
all new packages)
http://cygwin.com/ml/cygwin-apps/2013-06/msg00182.html
Yaakov
diff --git a/bin/cygport.in b/bin/cygport.in
index 388c7d6..bf23ca2 100755
--- a/bin/cygport.in
+++ b/bin/cygport.in
@@ -670,13 +670,18 @@ unset restrict
#
-declare -r workdir=${top}/${PF}.${ARCH};
+if [ ${top##*/} = ${PF}.${ARCH} ]
+then
+ declare -r workdir=${top};
+else
+ declare -r workdir=${top}/${PF}.${ARCH};
+fi
declare -r srcdir=${workdir}/src;
declare -r origsrcdir=${workdir}/origsrc;
declare -r configdir=${workdir}/config;
declare -r logdir=${workdir}/log;
declare -r patchdir=${workdir}/patch;
-declare -r spkgdir=${workdir}/spkg;
+declare -r spkgdir=${workdir}/spkg/${PF}.${ARCH};
declare -r distdir=${workdir}/dist;
SRC_DIR=${SRC_DIR:-${ORIG_PN:-${PN}}-${PV}};
diff --git a/lib/pkg_pkg.cygpart b/lib/pkg_pkg.cygpart
index 6a21a42..a5bca08 100644
--- a/lib/pkg_pkg.cygpart
+++ b/lib/pkg_pkg.cygpart
@@ -460,8 +460,6 @@ __pkg_srcpkg() {
cp ${top}/${src} ${spkgdir};
done
- cd ${spkgdir};
-
if __arg_bool SIG
then
if check_prog gpg
@@ -478,7 +476,9 @@ __pkg_srcpkg() {
fi
fi
- tar Jcvf ${distdir}/${PN}/${PF}-src.tar.xz * || error Source package creation failed
+ cd ${spkgdir%/*};
+
+ tar Jcvf ${distdir}/${PN}/${PF}-src.tar.xz ${spkgdir##*/}/ || error Source package creation failed
echo;
}
[SECURITY] jbigkit (CVE-2013-6369)
Chuck, A vulnerability has been announced in jbigkit[1][2]; please either update to 2.1, or add the following patch to 2.0: http://pkgs.fedoraproject.org/cgit/jbigkit.git/plain/jbigkit-CVE-2013-6369.patch TIA, Yaakov [1] https://www.cl.cam.ac.uk/~mgk25/jbigkit/CHANGES [2] https://bugzilla.redhat.com/show_bug.cgi?id=1032273
Re: 64-bit: Missing perl modules
On 2014-04-08 15:52, Reini Urban wrote: On Tue, Apr 8, 2014 at 1:01 PM, Achim Gratz wrote: Reini Urban writes: Nope. Care to explain? Already did. It's vastly easier to keep perl_vendor than to split it up. For all parties. Obviously, it's not, because perl_vendor hasn't been updated for almost two years. That is evidence enough to me that having to rebuild perl core and dozens of extra modules just to update or add a single CPAN module isn't feasible. You can do individual perlrebase or wait for the full autorebase for every XS installation. Or do an ephemeral rebase that is taking the rebase map of the rest of the system correctly into account. Only if you register each and every user module with the system. But we don't want that. Yes, we do want to have packages for all Perl modules required by other packages. Telling users oh, if you want to make this Cygwin package work, go install the modules from CPAN is not a viable solution. I know that you want to cygport every single perl module, but this is a very extreme position. No, it's not. We're not talking about all of CPAN here, just those modules which are needed by other packages; even with the typical recursiveness of CPAN dependencies, it's not all that many packages. With the combined perl_vendor I'll do it as part of the build step and the user only needs to wait for one rebase run. You wouldn't need a special perlrebase for that, that's the whole point. True. With proper EUMM and MB integration we would need no perlrebase. But MB is a mess. And Module::Install even more. And I wonder what will come up next. MB::Lite is already in the works just to bypass GNU make. That's not what he meant. With _autorebase, there is no need for special rebasing of perl modules shipped in vendor_perl by the distro (or Ports), they will be rebased by setup during postinstall. As for those installed into site_perl, I think it would be an improvement to make rebaseall specifically look for those, knowing that they won't be registered otherwise. (Same could be said for Python's easy_install, Ruby's gem, R's CMD INSTALL, and PHP's pecl, except that not all of those have a site/vendor split.) Sure, that's automatic of you care to package everything. But updates come every week, not every two years. In my case I have to package things anyway since I need to distribute the to a bunch of machines that have no outward connection. Besides the need for an internal CPAN mirror, I'd generally not trust a random user to run a CPAN update and make a judgment of whether or not everything worked as expected. Packaging some 300 Perl distributions really is less work than any of the alternatives and keeping things up-to-date isn't all that time-consuming so far. +1 Fair enough. But then I would keep them uptodate with a simple cpan or rsync, which is better than setup.exe. No need to stop all services. I maintain about 40 VM's this way, cross-version and platform. cpan ensures proper testing and with CPAN::Reporter being integrated the authors even get feedback. strawberry perl does the same. But that's not how Linux distributions manage Perl modules, and that's the issue here. Yaakov
Re: fontconfig packaging suggestion
On 2014-04-04 03:40, Corinna Vinschen wrote: On Apr 3 18:52, Ken Brown wrote: There is a problem with having fontconfig include the Windows Fonts directory in /etc/fonts/fonts.conf. Namely, the font cache for that directory is very likely to be out of date [*], but most users have no idea that they need to run fc-cache to keep it up to date. This can cause slowdowns or worse for applications that use fontconfig. See, for instance http://cygwin.com/ml/cygwin/2013-12/threads.html#00246 and several similar reports that came later. I propose that fontconfig *not* include the Windows Fonts directory, but that a new package (perhaps called fontconfig-windows-fonts) be created that takes over this functionality. This could either be a subpackage of fontconfig or an independent package, in which case I would be glad to maintain it. This package would handle the Windows Fonts directory by creating the appropriate file in /etc/fonts/conf.d, and it would also provide a script that calls fc-cache to update the Windows Fonts cache. The release announcement would warn users that the script should be called whenever the Windows Fonts directory changed. And I would explicitly advise emacs-X11 users *not* to install the package unless they really want to be able to use Windows fonts while running emacs under X. WDYT? The concern is definitely valid and I'm considering various options. I'm not Yaakov, but, may I throw in a dumb idea? What if fontconfig installs scripts for sh and csh in /etc/profile.d, which has only one task: It checks if the fc cache is older than the modification date of the Windows fonts directory. If so, it either calls fc-cache or, if that takes too long, it simply informs the user in distinct words that fc-cache needs running. Would that work? Does it make sense? That's one option, but I'm not sure yet if it covers all possible scenarios. Yaakov
[RFC] cygport: arch-specific workdir (was: cygport cross compilation)
On 2014-03-19 13:04, Yaakov (Cygwin/X) wrote: On 2014-03-19 11:32, Ken Brown wrote: I've just started experimenting with using cygport for cross compiling, and I've come across two issues: 1. This is just a request: The latest cygport for Fedora appends i686 or x86_64 to the name of the working directory. I would find it convenient if cygport did the same thing on Cygwin, at least if the --32 or --64 option is specified. Actually, that is experimental code (based on a request from another cygport user) that was accidentally shipped when I had to reroll the source tarball for compatibility with F20/UnversionedDocDirs. Would people like to see this done always, never, or only when cross-building? There hasn't been much comment on this. Since it would be a visible change for package maintainers, I would appreciate more of a consensus. Are there any objections to making the workdir always arch-specific (IOW name-ver-rel.arch)? Yaakov
Re: Untidy situation regarding p11-kit packaging causing setup inconsistency
On 2014-03-25 21:30, Shaddy Baddah wrote: [snip] If so, do we need a release of the -2 soon? No, we don't; 0.20.2 will be available for both arches as soon as I'm finished building GNOME 3.10 (as early as tomorrow). Yaakov
Re: cygport cross compilation
On 2014-03-19 11:32, Ken Brown wrote:
I've just started experimenting with using cygport for cross compiling,
and I've come across two issues:
1. This is just a request: The latest cygport for Fedora appends i686 or
x86_64 to the name of the working directory. I would find it convenient
if cygport did the same thing on Cygwin, at least if the --32 or --64
option is specified.
Actually, that is experimental code (based on a request from another
cygport user) that was accidentally shipped when I had to reroll the
source tarball for compatibility with F20/UnversionedDocDirs. Would
people like to see this done always, never, or only when cross-building?
2. I tried to do a build for x86-cygwin on x86_64-cygwin, but the
compiler didn't work:
$ cat test.c
int
main ()
{
return 0;
}
$ i686-pc-cygwin-gcc test.c
/tmp/ccaAaoj6.s: Assembler messages:
/tmp/ccaAaoj6.s:9: Error: invalid instruction suffix for `push'
WFM. Are you missing cygwin32-binutils?
Yaakov
Re: perl update?
On 2014-03-15 13:54, Reini Urban wrote: Oh sorry. I was waiting for the latest socket fix upstream to fix the problem with processes from the the CPAN shell not reacting to input, but it didn't happen. There are 12 test cases failing 32bit and 3 for 64bit so I guess it's time now. http://perl514.cpanel.net/build/builders/perl5-cygwin http://perl514.cpanel.net/build/builders/perl5-cygwin64 When you do update perl to 5.16+, please mark it as test: in order to give us time to rebuild everything first before marking it stable. Yaakov
[ITP] cross-pkg-config
In cygport git master, I changed how cygport uses pkg-config when
cross-compiling.
While pkg-config isn't technically a target tool (its configure doesn't
accept --target), using the plain pkg-config for cross-compiling
requires setting several environment variables. While this is easy
within the confines of cygport, it's not practical for independent usage.
Instead, pkg-config can be configured at build time with several options
to behave like a target tool by default, and PKG_FIND_PKG_CONFIG
actually uses AC_PATH_TOOL to find PKG_CONFIG. Hence, Fedora provides
such packages for the mingw-w64 toolchains, as do I for my Cygwin
toolchains there.
Therefore, as of commit af8971d, cygport now requires a $host-pkg-config
for cross-toolchains. These packages should be built with
toolchain.cygclass and configured as such:
--disable-host-tool
--program-prefix=${TOOLCHAIN_TARGET}-
--with-pc-path=${TOOLCHAIN_LIBDIR}/pkgconfig:${TOOLCHAIN_DATADIR}/pkgconfig:/usr/share/pkgconfig
--with-system-include-path=${TOOLCHAIN_INCLUDEDIR}
--with-system-library-path=${TOOLCHAIN_LIBDIR}
I already have packages for the cygwin and mingw-w64 cross-toolchains.
I intend to upload these in the next few days, after which I should be
ready to ship a new version of cygport.
Yaakov
[PATCH] setup: add Windows 8.1 to manifest
Just noticed that Windows 8.1 compatibility was missing from
setup*.exe.manifest; patch attached.
Yaakov
2014-02-25 Yaakov Selkowitz yselkow...@users.sourceforge.net
* setup.exe.manifest: Add Windows 8.1 to compatibility list.
* setup64.exe.manifest: Ditto.
Index: setup.exe.manifest
===
RCS file: /cvs/cygwin-apps/setup/setup.exe.manifest,v
retrieving revision 2.5
diff -u -p -r2.5 setup.exe.manifest
--- setup.exe.manifest 5 Apr 2013 08:42:48 - 2.5
+++ setup.exe.manifest 25 Feb 2014 16:54:06 -
@@ -27,6 +27,8 @@
supportedOS Id={35138b9a-5d96-4fbd-8e2d-a2440225f93a}/
!--The ID below indicates application support for Windows 8 --
supportedOS Id={4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}/
+ !--The ID below indicates application support for Windows 8.1 --
+ supportedOS Id={1f676c76-80e1-4239-95bb-83d0f6d0da78}/
/application
/compatibility
/assembly
Index: setup64.exe.manifest
===
RCS file: /cvs/cygwin-apps/setup/setup64.exe.manifest,v
retrieving revision 2.1
diff -u -p -r2.1 setup64.exe.manifest
--- setup64.exe.manifest5 Apr 2013 08:42:48 - 2.1
+++ setup64.exe.manifest25 Feb 2014 16:54:06 -
@@ -34,6 +34,8 @@
supportedOS Id={35138b9a-5d96-4fbd-8e2d-a2440225f93a}/
!--The ID below indicates application support for Windows 8 --
supportedOS Id={4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}/
+ !--The ID below indicates application support for Windows 8.1 --
+ supportedOS Id={1f676c76-80e1-4239-95bb-83d0f6d0da78}/
/application
/compatibility
/assembly
Re: [ITP] google-breakpad
On 2014-02-18 07:28, Jon TURNEY wrote: These packages contain the minidump analysis part of breakpad, a multi-platform crash reporting and analysis system using minidumps. It doesn't make much sense to package the libbreakpad_client crash handling library, as this conflicts with cygwin's error_start facility. It might make some sense to make MinGW cross-compiled packages of libbreakpad_client in the future. I can't find this in any major linux distribution, so votes are required. +1 Yaakov
Re: Missing .la files
On 2014-02-17 13:28, Ken Brown wrote: I know there has been a change in cygport so that by default, .la files are no longer shipped. But the .la files for fontconfig, expat, and freetype are needed for the Cygwin build of xetex.exe for the native TeX Live distribution. This is a static build. (Native TeX Live uses static builds to reduce library dependencies.) AFAICS the static linkage is the issue here, not the .la files: The .la files are present in the x86 distro but not the x86_64 distro. Without the .la files, libtool produces a link command line g++ ... -o xetex.exe ... -lfontconfig -lexpat -lfreetype ..., g++ -static? resulting in error messages like /usr/lib/gcc/x86_64-pc-cygwin/4.8.2/../../../../x86_64-pc-cygwin/bin/ld: cannot find -lfontconfig g++/ld do NOT need .la files in order to link libraries properly. But when linking with -static, .dll.a files will be ignored and only libNAME.a files will be found. (That's why Cygwin's own implibs are .a and not .dll.a.) Since building packages with --disable-static is now the default, attempting to link with most libraries will result in such an error. With the .la files present, the command line becomes g++ ... -o xetex.exe ... /usr/lib/libfontconfig.dll.a /usr/lib/libexpat.dll.a /usr/lib/libfreetype.dll.a ... Which may actually be a bug in libtool by ignoring (or at least changing the meaning of) -static. A workaround is to copy the .la files from my x86 installation to my x86_64 distro. Please don't do that. If not, can the .la files for those three libraries be added to the x86_64 distro? That's clearly not necessary. The real question is if we should be providing static libraries. Fedora has moved away from them for the most part (and they also remove .la files), and we have been doing the same for a while. Keeping in mind that there is no completely static linkage on Cygwin, and we already have a dynamically linked texlive in the distro, I'm not convinced that there is a real need to provide static libraries for all of its many dependencies. But as I wrote that, it occurred to me that IIRC texlive can be built with either system or bundled dependencies. Wouldn't their distribution be built with --without-system-*? Yaakov
Re: Missing .la files
On 2014-02-17 16:44, Ken Brown wrote: On 2/17/2014 3:25 PM, Yaakov (Cygwin/X) wrote: On 2014-02-17 13:28, Ken Brown wrote: If not, can the .la files for those three libraries be added to the x86_64 distro? That's clearly not necessary. The real question is if we should be providing static libraries. Fedora has moved away from them for the most part (and they also remove .la files), and we have been doing the same for a while. Keeping in mind that there is no completely static linkage on Cygwin, and we already have a dynamically linked texlive in the distro, I'm not convinced that there is a real need to provide static libraries for all of its many dependencies. But as I wrote that, it occurred to me that IIRC texlive can be built with either system or bundled dependencies. Wouldn't their distribution be built with --without-system-*? Yes, for all the libraries that they bundle. But they don't bundle the three libraries I mentioned. So my revised request is that Cygwin provide static libraries for fontconfig, expat, and freetype. If you think this is inappropriate, can you suggest another way for me to deal with the problem? I could of course build the static libraries myself, but then it becomes difficult for others to replicate the build. Fontconfig is the main culprit here (the others are its own deps), but AFAICS these are not bundled on purpose, and should indeed be linked dynamically: https://www.tug.org/pipermail/tex-live/2006-October/011366.html The reasoning there is sound IMO. Furthermore, the TeX Live guide implies a runtime dependency on fontconfig for all *NIX systems (see sections 3.1.1, 3.1.4, and 3.4.4): https://www.tug.org/texlive/doc/texlive-en/texlive-en.html Therefore, I believe the correct course of action here is to fix the texlive build system to not insist on static fontconfig and deps. Wherever it is in the xetex build, change those flags to -Wl,-Bdynamic -lfontconfig -lexpat -lfreetype -Wl,-Bstatic. Yaakov
Re: [PATCH] rebase: fix 32-bit rollover
On 2014-02-11 04:22, Corinna Vinschen wrote: On Feb 10 15:07, Yaakov (Cygwin/X) wrote: When running rebase on multiple DLLs for x86, downwards rollover is now going back to the top of the 64-bit address space, which isn't right for x86 images. This patch should restore the previous behaviour of rolling over (under?) to the top of the 32-bit space instead. I didn't attempt to deal with upwards rollover due to the following comment. Thanks for catching. We should not rollover indiscriminately into the upper two gigs either, though. It won't work for real 32 bit systems, only for WOW64 systems. But given that rebase is running on a specific machine, we could take the WOW64-iness into account. Also, rebase should not start at the upper bound, because it will collide with PEB, TEB and shared-user-data anyway, see the output of /proc/$PID/maps. AFAICS, we should start at either 0xfffe (WOW64) or 0x7f6 (real 32 bit). Does that make sense? I think so, but in parse_args it allows for -b to be anywhere in the 4GB space for ix86. Should that not be allowed if not on WoW64 either? Also, on ix86 systems, should /3GB configurations (bcdedit /set IncreaseUserVa in newer versions of Windows) be taken into account, and how? Yaakov
x86_64 Perl module ownership
Ken, During the x86_64 porting process, we added a large number of Perl modules to the distro rather quickly, but we never updated cygwin-pkg-maint. AFAICS these are yours, as dependencies of biber: perl-Business-ISBN perl-Business-ISBN-DATA perl-Business-ISMN perl-Business-ISSN perl-Capture-Tiny perl-Config-AutoConf perl-Data-Compare perl-Data-Diver perl-Date-Simple perl-Encode-EUCJPASCII perl-Encode-HanExtra perl-Encode-JIS2K perl-ExtUtils-LibBuilder perl-File-Find-Rule perl-File-Slurp perl-File-Slurp-Unicode perl-IO-HTML perl-IPC-Run3 perl-List-AllUtils perl-Log-Log4perl perl-LWP-Protocol-https perl-MIME-Charset perl-Mozilla-CA (*) perl-Number-Compare perl-Readonly perl-Readonly-XS perl-Regexp-Common perl-Text-BibTeX perl-Text-Glob perl-Tie-Cycle perl-Unicode-Collate perl-Unicode-GCString perl-XML-LibXML-Simple perl-XML-LibXSLT And these as mine, as dependencies of git-email or of perl-PAR-Packer itself: perl-Archive-Zip perl-Authen-SASL perl-Digest-HMAC perl-Digest-SHA1 perl-Encode-Locale perl-Getopt-ArgvFile perl-File-Listing perl-HTML-Parser perl-HTML-Tagset perl-HTTP-Cookies perl-HTTP-Daemon perl-HTTP-Date perl-HTTP-Message perl-HTTP-Negotiate perl-IO-Socket-SSL perl-List-MoreUtils perl-LWP perl-LWP-MediaTypes perl-Module-ScanDeps perl-Net-HTTP perl-Net-SMTP-SSL perl-Net-SSLeay perl-PAR perl-PAR-Dist perl-PAR-Packer perl-Params-Util perl-Proc-ProcessTable perl-Term-ReadKey perl-Term-ReadLine-Gnu perl-Tk-Canvas-GradientColor perl-Tk-ColoredButton perl-Tk-Getopt perl-Tk-Pod perl-URI perl-WWW-RobotRules perl-XML-LibXML perl-XML-NamespaceSupport perl-XML-Parser perl-XML-SAX perl-XML-SAX-Base perl-YAML Regarding perl-Mozilla-CA, I would like to add a patch from Fedora to use the system ca-certificates instead of the (old) bundled copy. I have this in git now: https://sourceforge.net/p/cygwin-ports/perl-Mozilla-CA/ci/master/tree/perl-Mozilla-CA.cygport Could you proceed with this change, or should I? With that change, there may not be much of a need (if any) to update this module for the foreseeable future. Otherwise, any corrections to this list? Yaakov
neon: use ca-certificates
Dr. Volker, When you have a chance, could you please rebuild neon with --with-ca-bundle=/usr/ssl/certs/ca-bundle.crt, and add ca-certificates to libneon27_REQUIRES? TIA, Yaakov
Re: x86_64 Perl module ownership
On 2014-02-06 20:41, Ken Brown wrote: On 2/6/2014 7:43 PM, Yaakov (Cygwin/X) wrote: AFAICS these are yours, as dependencies of biber: [snip] perl-Business-ISBN-DATA Data Typo, but cygwin-pkg-maint is all lower case anyway. And these as mine, as dependencies of git-email or of perl-PAR-Packer itself: [snip] perl-list-MoreUtils was mine. Fixed. Regarding perl-Mozilla-CA, I would like to add a patch from Fedora to use the system ca-certificates instead of the (old) bundled copy. I have this in git now: [snip] Could you proceed with this change, or should I? With that change, there may not be much of a need (if any) to update this module for the foreseeable future. I'll do it. I'm traveling at the moment, but I should be able to do it by Sunday or Monday. Great, thanks. Otherwise, any corrections to this list? Only the two indicated above. Thanks; committed. Yaakov
openssl: add ca-certificates dep
Corinna, Now that ca-certificates provides /usr/ssl/cert.pem[1][2], which is the hardcoded location in libcrypto, AFAICS libopenssl100 should depend on ca-certificates. Note that Fedora does this as well[3], as do our libgnutls28 and libnss3 packages. This would assure that e.g. wget.x86_64 works OOTB with HTTPS URIs. This can be fixed for future releases by adding ca-certificates to libopenssl100_REQUIRES, but this should be added to x86*/release/openssl/libopenssl100/setup.hint now. Agreed? Yaakov [1] http://cygwin.com/ml/cygwin/2013-09/msg00161.html [2] http://cygwin.com/ml/cygwin-announce/2013-10/msg7.html [3] http://pkgs.fedoraproject.org/cgit/openssl.git/tree/openssl.spec#n107
Re: [ITA] Git et al
On 2014-01-29 11:07, Adam Dinwoodie wrote: I seem to recall there being some discussion (I can't remember the specific cases) about whether it would be sensible to have, for at least the first release after a split, all the new packages depending on the thinned down base one. As an example, someone using git-cvs currently would only have the git package. If we list git-cvs as a requirement for the new git package, when they upgrade git they'll automatically get git-cvs and won't lose any functionality. The following update can lose the git-cvs requirement, giving the full advantage of the separated packages. That's what announcements are for, and for those who don't read them, postponing the change isn't going to help. Yaakov
Re: [ITA] Git et al
On 2014-01-29 05:53, Adam Dinwoodie wrote: I have an outstanding issue with the packaging I've just spotted -- git-cvs relies on perl-DBD-SQLite, which doesn't exist. More specifically, there has been one for x86_64 since I built git.x86_64 during the bootstrap, but I see now that I didn't add it for x86. I just uploaded an x86 package. But along these lines, git-email also needs a few Perl modules which are not yet available for x86; I'll proceed with those as well, hopefully tonight. Thinking about it, my build and packages take Yaakov's work over at Cygwin Ports to split the Git packages (at the moment, git-cvs is part of the main git package, for example, while my build separates it out). I know there have been debates about this in the past; is there currently any guideline about the best way to manage such package splits? I'm not sure to what debates you are referring, but the point of the split was to provide correct dependencies while isolating those to the components that actually need them. This was already done with the more obvious tcl-tk dependency of gitk and git-gui, but my packages took it a step further. So, for example, git-svn actually requires subversion-perl, but subversion is not small and not all git users are going to want that just in order to use git. Yaakov
Re: [ITA] tcl-sqlite3
On 2014-01-15 03:12, Jan Nijtmans wrote: 2014/1/14 Yaakov (Cygwin/X): I don't see any links to a -src package, or better yet, a URL to the .cygport and patches (if any). That's because the -src package is the same as the sqlite3 src package. However, the one with the latest modifications can be found here now: https://dl.dropboxusercontent.com/u/69449580/Cygwin/sqlite3/sqlite3-3.8.2-3-src.tar.xz What is the source of the ICU and zlib patches, and why have you added them? ICU is a *huge* dependency for something as small as sqlite3. Your src.patch includes an incorrect hunk for sqlite3.h:SQLITE_VERSION_NUMBER. I also don't understand the reasoning for your tclsqlite3.c patches. Also, you also clobbered the upstream README with a Cygwin-specific one; please don't do that. It's not a problem, but partly-versioned (only the 3) library file has the advantage that no uninstall needs to be done after an upgrade to a higher version. The directory cannot accidentally keep old versions of files around, every upgrade will simply overwrite it with the new version. Huh? setup will remove the previous version before installing the newer one anyway. If the filename is agreed upon, still agreement is needed on the directory where those file should be installed. Using /usr/lib/tcl8.x/sqlite3 is not strange at all: TEA dictates that there should be a tclConfig.sh file in /usr/lib, but Debian moves that to /usr/lib/tcl8.x as well. It's already in the search path of Tcl, so it will work without the need to patch Tcl itself. No one's talking about patching Tcl. The OOTB default works as well, and doesn't pollute a directory which is currently used solely for the standard library. TEA (without full-version): TM (Tcl module new style): My suggestion (looks like Fedora's sqlite-tcl package): If it works, don't fix it. IMO we should let TEA do its thing. And who can add the tcl-sqlite3 package to cygwin-pkg-maint? That's not necessary, as it will have an external-source: sqlite3. Yaakov
[SECURITY] xpdf
Dr. Volker, Could you add this patch to xpdf for CVE-2012-2142: http://pkgs.fedoraproject.org/cgit/xpdf.git/plain/xpdf-3.03-CVE-2012-2142.diff Yaakov
Re: [ITA] tcl-sqlite3
On 2014-01-14 03:55, Corinna Vinschen wrote: I don't know much about sqlite, but your package content puzzles me: usr/lib/sqlite3.8.2/pkgIndex.tcl usr/lib/sqlite3.8.2/sqlite382.dll usr/share/man/mann/sqlite3.n.gz This looks only vaguely related to tcl. I see that the existing tcl-sqlite3-3.7.15.2-1.tar.bz2 in the 64 bit distro looks similar, Yes, that's the default TEA layout. but it's bound against sqlite-3.7.15.2, so it probably won't work with recent sqlite versions anyway. It should still work, it just won't have bindings for the newest features in sqlite-3.8.x. I really don't quite grok the directory layout and the naming. I took a look into the Fedora package, which is called sqlite-tcl. It provides /usr/lib/tcl8.5/sqlite3 /usr/lib/tcl8.5/sqlite3/libtclsqlite3.so /usr/lib/tcl8.5/sqlite3/pkgIndex.tcl That makes more sense to me: - As a tcl package the shared lib should be under /usr/lib/tcl8.5 Not necessarily. Packages built with Tcl stubs are not linked to libtcl8.5 and should be compatible with any (at least newer) version of Tcl without having to be rebuilt. - The subdir and the shared lib shouldn't have the *exact* name of the sqlite version, otherwise they don't make sense anymore if sqlite gets updated to, say, 3.8.3. Tcl extensions are loaded via pkgIndex.tcl, so the module name itself is irrelevant. Yaakov
Re: [ITA] tcl-sqlite3
On 2014-01-14 10:45, Corinna Vinschen wrote: And, having said that, I'm wondering why Cygwin has two dirs: /usr/lib/tcl8.5 /usr/lib/tcl8 with the latter having two subdirs, 8.4 and 8.5. What's the deal here? There are two different ways of providing tcl extensions, packages and modules, the latter being new in 8.5 but AFAICS hasn't taken off. You can read more about them here: http://wiki.tcl.tk/37432 http://wiki.tcl.tk/12999 Yaakov
Re: [ITA] tcl-sqlite3
On 2014-01-14 09:50, Jan Nijtmans wrote: After some experimenting, I'm proposing the following layout: usr/lib/tcl8.5/sqlite3- ../tcl8.6/sqlite3 (soft link) usr/lib/tcl8.6/sqlite3/pkgIndex.tcl usr/lib/tcl8.6/sqlite3/tclsqlite3.dll usr/share/man/mann/sqlite3.n.gz This way, both Tcl 8.5 and 8.6 can find the package without the need to duplicate anything. And the full version numbers are gone. Is that better? /usr/lib/tcl8.x is for the Tcl standard library; I don't think that other packages -- particularly those that aren't actually dependent on a particular version of Tcl -- belong there. Yaakov
Re: [ITA] tcl-sqlite3
On 2014-01-14 14:52, Corinna Vinschen wrote: In how far does that affect the filename? We're adding new APIs to Cygwin all the time, but the DLL is still called cygwin1.dll. And that's how it works for any other DLL as well as long as it doesn't break backward compatibility, API-wise. This is a loadable module, not a link library, and unlike other language interpreters which load extensions directly based on file name, Tcl package-type extensions are loaded based on a metadata file (pkgIndex.tcl). It is actually typical of Tcl extensions to be versioned in this way. Yaakov
Re: [ITA] tcl-sqlite3
On 2014-01-14 13:49, Corinna Vinschen wrote: Ok, thanks. Apart from that, would you mind to review the package and give a GTG (or not)? I'm just not feeling savvy enough, neither in tcl nor in sqlite. I don't see any links to a -src package, or better yet, a URL to the .cygport and patches (if any). Yaakov
RFC: usage of cygwin32-/cygwin64- cross-toolchains
Now that we're long finished bootstrapping cygwin64, I was wondering to what degree (if any) are the cygwin32-* and cygwin64-* packages in either the Cygwin distro or the Fedora Cygwin repository are of actual use. If you are using any of these, please specify on which platform you are using them (i686/x86_64, Cygwin, F19, or if you want to move to F20) and to what extent (IOW to build Cygwin package A/B/C which require libraries X/Y/Z). This will help me best manage my time wrt keeping these updated. TIA, Yaakov
Re: RFC: usage of cygwin32-/cygwin64- cross-toolchains
On 2014-01-10 00:06, Christopher Faylor wrote: On Thu, Jan 09, 2014 at 11:32:44PM -0600, Yaakov (Cygwin/X) wrote: Now that we're long finished bootstrapping cygwin64, I was wondering to what degree (if any) are the cygwin32-* and cygwin64-* packages in either the Cygwin distro or the Fedora Cygwin repository are of actual use. If you are using any of these, please specify on which platform you are using them (i686/x86_64, Cygwin, F19, or if you want to move to F20) and to what extent (IOW to build Cygwin package A/B/C which require libraries X/Y/Z). This will help me best manage my time wrt keeping these updated. I use them in (essentially) Fedora 18 but I have vague plans to update to the latest Fedora sometime soon. And which libraries are you using? Yaakov
SourceForge project upgrade
Please note that my SourceForge-hosted services have been upgraded to their new platform. This means that the cygwin-ports and fedora-cygwin git repos are now in new locations. You will need to run the following command from within your git checkout(s) to continue to pull updates: git remote set-url origin git://git.code.sf.net/p/$project/$repo Where $project is either cygwin-ports or fedora-cygwin and $repo the package repository name (e.g. cygport). Yaakov Cygwin Ports
Re: [PATCH] crypt: fix for -Wimplicit-function-declaration
On 2013-11-21 03:06, Corinna Vinschen wrote: 2013-11-20 Yaakov Selkowitz yselkowitz@... * crypt.c: #include time.h to fix implicit declaration of time(3). Thanks, applied. Shall I create a new release? Since srand(3) takes an int, I'm not sure that it's actually necessary in this particular case. BTW, you read my mind wrt your subsequent encrypt.h patch; thanks. Yaakov
[PATCH] crypt: fix for -Wimplicit-function-declaration
Attached patch is pretty self-explanatory. Yaakov 2013-11-20 Yaakov Selkowitz yselkowitz@... * crypt.c: #include time.h to fix implicit declaration of time(3). Index: crypt.c === RCS file: /cvs/cygwin-apps/crypt/crypt.c,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 crypt.c --- crypt.c 7 May 2012 11:00:13 - 1.1.1.1 +++ crypt.c 21 Nov 2013 00:55:55 - @@ -1,6 +1,7 @@ #include stdio.h #include stdlib.h #include string.h +#include time.h #include encrypt.h const char *sc = ./
Re: buliding lftp fails
On 2013-11-17 14:36, Andrew Schulman wrote: $ cygport lftp prep cygport lftp.cygport prep ... The .cygport is mandatory with spec-style cygport(5). BTW, do you have pkg-config installed? Yaakov
Re: Updated: texinfo-5.2-1 (32/64)
On 2013-11-06 13:52, Christopher Faylor wrote: I've made a new version of 'texinfo' available for installation. This is the most recent version of texinfo available from ftp.gnu.org. Headsup package maintainers: Some packages, particularly older ones, may require a patch for compatibility with texinfo 5.x. Fedora has already made this transition, so patches are available from the corresponding Fedora package: http://pkgs.fedoraproject.org/cgit/ HTH, Yaakov
Re: [ITP] WeeChat -- Fast, light and extensible chat client
On 2013-10-18 11:40, Corinna Vinschen wrote: On Oct 18 16:54, Sebastien wrote: And I understood why they were missing: my locale is french under cygwin (LANG=fr_FR), and the cygport tool is grepping output of objdump -p for the text DLL Name: (file pkg_info.cygpart in cygport sources). When your locale is not english, this text is translated (in french I have: Nom DLL:). So if I run cygport with this command: cygport weechat-0.4.2-1.cygport package I have nothing in requires field. Instead I have to run: LANG=C cygport weechat-0.4.2-1.cygport package which gives all dependencies in the requires field. I think it is a bug in cygport tool. Or at least, if you consider it's not a bug, it should be mentioned in the help that the tool must be run with an english locale (or LANG=C). Anyway, I think it would be better to fix that, so that other users will not spent time like me to understand why the requires field is empty! Yaakov, any comment? This should be fixed in git master, commit 50cdfcd; running cygport itself with LANG=C should NOT be necessary. (BTW, I'm willing to consider localizing cygport itself if there are interested translators.) Yaakov
Re: new version of ocaml package (4.01.0-1)
On 2013-10-25 04:25, Damien Doligez wrote: So, here it is: I have a new version of the OCaml package (4.01.0-1), both for 32 and 64 bits. Both packages are marked as test: I have successfully finished my OCaml rebuild for both arches, so I made these stable. It would still be helpful to have ocaml-labltk for x86, and please keep me posted with any developments wrt FlexDLL. Thanks, Yaakov
Re: new version of ocaml package (4.01.0-1)
On 2013-10-29 04:14, Corinna Vinschen wrote: On Oct 28 15:17, Yaakov (Cygwin/X) wrote: I started working on porting flexdll-0.31, but the testsuite is failing with cannot relocate, target is too far errors; IIUC the issue has to do with our use of the medium code model. In the In theory, the usage of the medium code model was supposed to *fix* the issue. Can the testsuite problem be reduced into a STC which we can have a look at? I was referring to a FlexDLL error message, not a Cygwin one. The former only supports relocs within the lower 32-bit range (even with 64-bit binaries), so this will need to be fixed upstream first. Yaakov
Re: new version of ocaml package (4.01.0-1)
On 2013-10-25 04:25, Damien Doligez wrote: So, here it is: I have a new version of the OCaml package (4.01.0-1), both for 32 and 64 bits. I have uploaded the files to cygwin.com, but I haven't put the !ready files yet. Both packages are marked as test: - For 32 bits, because I don't want to hurt you again. I'm guessing that a test version of the package will let you recompile the libraries in Ports, and then when you tell me you're ready, I'll make a curr version. Ack, I'll let you know when I'm finished the rebuild (but see below). - For 64 bits, because we don't have Flexdll yet, so dynlink is not supported, which means that many OCaml programs won't work. I've already prodded the Flexdll upstream. I'm publishing this because it's the best we can have on 64-bit for the moment. I started working on porting flexdll-0.31, but the testsuite is failing with cannot relocate, target is too far errors; IIUC the issue has to do with our use of the medium code model. In the meantime, the primary use of OCaml on supported platforms is native code compilation, so I suggest we make this stable on x86_64. Both packages include labltk. Are you sure? AFAICS it's only in the x86_64 package. Because of the extra dependencies, for the next release, I suggest making a separate ocaml-labltk package with usr/bin/labltk and usr/lib/ocaml/labltk/ (and usr/lib/ocaml/stublibs/dlllabltk.so on x86), along with adding --exclude=*labltk* to ocaml_base_CONTENTS. We do a similar thing with Python and Ruby's Tcl/Tk support. Yaakov
Re: new version of ocaml package (4.01.0-1)
On 2013-10-25 04:25, Damien Doligez wrote: How do we proceed? Should I send these !ready files? Yes, please; I'll try to work on this from my end next week. Yaakov
Re: The upload system is live (Re: Major changes coming to procedure for uploading to sourceware)
On 2013-10-22 12:59, Andrew Schulman wrote: I'm sorry there's still no lftp for 64-bit - I'm having trouble compiling it - a configure problem. I'll post about this soon to see if someone can help me to solve it. This builds and seems to be working: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/lftp Yaakov
Re: [ITP] WeeChat -- Fast, light and extensible chat client
On 2013-10-21 01:26, Jan Nieuwenhuizen wrote: Jan, our 32 bit version of guile is 1.8.7 from 2010, the 64 bit version is at 1.8.8. Do you see any chance to update guile to a 2.x version? Ah, am I still maintainer for Guile? Yes. Currently, LilyPond does not work with guile 2 yet so we'd have to keep 1.8.x around for a bit anyway. Definitely, there are many others which are still compatible only with 1.8. Yaakov
Re: cygport: perl.cygclass and Module::Build::Tiny compatibility
On 2013-10-08 14:12, Achim Gratz wrote: While building some Perl modules today that use Module::Build::Tiny, the install took place in the system site_perl rather than the inst directory. The reason is that Module::Build::Tiny only recognizes options with a double dash (i.e. --destdir=/path). Since Module::Build recognizes the option syntax correctly, I've just changed this locally to get a complete package. There are probably a few other places where these tiny (pardon the pun) differences need attention, but I didn't have time for that today. Also, the check for the presence of Module::Build is wrong when Module::Build::Tiny is used. Thanks for pointing this out, but could you give me some specific CPAN packages which use Module::Build::Tiny so I could work on this? Yaakov
Re: cygport: perl.cygclass and Module::Build::Tiny compatibility
On 2013-10-08 15:43, Achim Gratz wrote: Yaakov (Cygwin/X) writes: Thanks for pointing this out, but could you give me some specific CPAN packages which use Module::Build::Tiny so I could work on this? I've caught it on Test::Warnings and of course Module::Build::Tiny itself; but any of these should do: https://metacpan.org/requires/distribution/Module-Build-Tiny As I needed to get on with other work, I just cleaned out site_perl and re-generated all my packages after patching perl.cygclass. There'd been an occurence of site_perl in the manual pages for the modules that some fixup routine of cygport packaging caught and fixed; I assume that it could likely be prevented by adding the -- treatment in some other place. This should be fixed in git master, commit 5dad3c2. Yaakov
Re: pcre: setup.hint
On 2013-10-07 13:03, Achim Gratz wrote: The pcre directory has a setup.hint with just skip: as the only entry. This would indicate a source-only package, however pcre does have a package with documentation and binaries that can't be installed due to this. Fixed, thanks for noticing. Yaakov
[PATCH] genini: support new tags
The attached patch for genini allows it to recognize (and ignore) the
new setup.hint tags.
Yaakov
2013-10-07 Yaakov Selkowitz yselkowitz@...
* genini (parse): Ignore arch:, release:, and skip: tags.
Index: genini
===
RCS file: /cvs/cygwin-apps/genini/genini,v
retrieving revision 1.14
diff -u -p -r1.14 genini
--- genini 17 Jul 2013 16:33:16 - 1.14
+++ genini 7 Oct 2013 19:24:32 -
@@ -139,6 +139,15 @@ sub parse {
$main::setup_version = $_;
next;
};
+ /^arch:/ and do {
+ next;
+ };
+ /^release:/ and do {
+ next;
+ };
+ /^skip:/ and do {
+ next;
+ };
/^\@\s+(\S+)/ and do {
$pname = $1;
$what = '';
Re: [PATCH] genini: support new tags
On 2013-10-07 14:46, Christopher Faylor wrote: On Mon, Oct 07, 2013 at 02:28:00PM -0500, Yaakov (Cygwin/X) wrote: The attached patch for genini allows it to recognize (and ignore) the new setup.hint tags. Only skip: is a valid setup.hint tag. OK, bad wording, but genini accepts an existing setup.ini as input, so it needs to understands its tags as well. Yaakov
Re: libevent-2.0.21
On 2013-10-04 10:07, Chris Olin wrote: Didn't see this until after sending my response to Christopher. I'm unfamiliar with Cygwin Ports. If libevent is already available there, is there a process to have it brought into Cygwin so then all that I really need to do is package tmux and send out an ITP? Done. It should show up on the mirrors shortly, at which point you may proceed with ITPing tmux. HTH, Yaakov
Re: RFU: ctorrent-1.3.4-dnh3.2-2 (64bit)
On 2013-10-03 09:54, Ken Brown wrote: On 9/15/2013 2:27 AM, Jari Aalto wrote: wget --recursive --no-host-directories --cut-dirs=5 \ http://cante.net/~jaalto/tmp/cygwin/ctorrent/64/ctorrent/ctorrent-1.3.4-dnh3.2-2-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/ctorrent/64/ctorrent/ctorrent-1.3.4-dnh3.2-2.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/ctorrent/64/ctorrent/setup.hint Uploaded. Jari, This setup.hint lists 'openssl100' as a dependency, but there is no such package. I have corrected this on sourceware, but please fix your local copy accordingly. Yaakov
Re: [HEADSUP] Missing 64 bit packages
On 2013-08-31 11:52, Corinna Vinschen wrote: Reini Urban clamav I have NMU'd this as well. Yaakov
Re: [64bit] python3 vs. threads
On 2013-08-15 12:50, Yaakov (Cygwin/X) wrote: On 2013-08-15 10:32, Corinna Vinschen wrote: Jason? Is there any chance you could pick this up? I NMU'd both python and python3 for x86_64 earlier this week as a prerequisite for the GNOME 3.8 update; so far they're both working well. I just added a -3 with a patch for the uuid module: http://bugs.python.org/issue18784 Jason, any chance of matching updates for x86? Yaakov
[PATCH] setup: installed xz packages (was: cygcheck: xz packages)
On 2013-09-16 12:40, Christopher Faylor wrote:
On Fri, Sep 13, 2013 at 02:06:19PM -0400, Christopher Faylor wrote:
On Fri, Sep 13, 2013 at 12:10:47PM -0500, Yaakov (Cygwin/X) wrote:
cygcheck needs fixing wrt .tar.xz packages; patch attached.
Thanks for noticing this but I think I'd like to see a more general
fix. In upset, I just completely relaxed the checking of .gz/.bz2/.xz
in favor of just checking for .tar. So, instead, something like the
below.
I just confirmed: It doesn't work. I did, however, check in a modified
version that has the salutary effect of not segv'ing. It seems to work
but, now that I think of it, I haven't downloaded any new packages with
.xz extensions. It is general enough that, if it works for .tar.bz2, it
should also work for .tar.xz.
While setup installed .tar.xz packages fine, it turns out they're not
being seen as installed the next time setup is run. Patch attached in
your name, since the code is literally a copy of your rewritten
winsup/cygwin/dump_setup.cc:find_tar_ext().
Yaakov
2013-09-17 Christopher Faylor me.cygwin2013@...
* filemanip.cc (find_tar_ext): Generalize search for .tar extension,
avoiding looking for specific compression types.
Index: filemanip.cc
===
RCS file: /cvs/cygwin-apps/setup/filemanip.cc,v
retrieving revision 2.36
diff -u -p -r2.36 filemanip.cc
--- filemanip.cc 30 Aug 2012 22:32:14 - 2.36
+++ filemanip.cc 17 Sep 2013 19:59:43 -
@@ -70,18 +70,13 @@ base (const std::string aString)
int
find_tar_ext (const char *path)
{
- char *end = strchr (path, '\0');
- /* check in longest first order */
- const char *ext;
- if ((ext = trail (path, .tar.bz2)) (end - ext) == 8)
-return ext - path;
- if ((ext = trail (path, .tar.gz)) (end - ext) == 7)
-return ext - path;
- if ((ext = trail (path, .tar)) (end - ext) == 4)
-return ext - path;
- if ((ext = trail (path, .tar.lzma)) (end - ext) == 9)
-return ext - path;
- return 0;
+ char *p = strchr (path, '\0') - 9;
+ if (p = path)
+return 0;
+ if ((p = strstr (p, .tar)) != NULL)
+return p - path;
+ else
+return 0;
}
/* Parse a filename into package, version, and extension components. */
Re: 64-bit Cygwin installation is missing /usr/bin/lockfile
On 2013-08-14 09:13, Corinna Vinschen wrote:
I'm puzzled. Here's my procmail.cygport file:
[snip]
MAKEOPTS=EXE=.exe LOCKINGTEST=100 BASENAME=${D}/usr MANDIR=${D}/usr/share/man
[snip]
The important thing here is the definition of MAKEOPTS. When I call
`cygport procmail.cygport install, then cygmake is called with
BASENAME set to just /usr, not to the evaluated resulting string
${D}/usr.
Why is ${P} in SRC_URI evaluated correctly, but why isn't ${D} in
MAKEOPTS?!?
PN/PV/PR/P/etc. are defined before source()ing the cygport(5) -- dating
back to when these were detected from the file name instead of its
contents -- but S/B/C/D are initialized *afterwards*, primarily because
S can vary if SRC_DIR is defined.
In this case, you'll need to pass the BASENAME and MANDIR arguments
directly to cygmake and cyginstall.
Yaakov
Re: Cygport per-package PKG_EXCLUDE?
On 2013-08-03 14:36, Achim Gratz wrote: David Stacey writes: cygport already has the --exclude option that you can use when specifying package contents. Not really a cygport option, but a side-effect of $pkg_contents getting expanded into the command line of (GNU) tar which then interprets the --exclude directive. The above gets the job done, but I'm not sure that it is officially sanctioned. It is, and I use it myself all the time. I have added a mention thereof to the docs in git master. Yaakov
Re: RFU: bzr-2.6.0-1 (32bit)
On 2013-09-12 07:59, Jari Aalto wrote: wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/bzr/bzr-2.6.0-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/bzr/bzr-2.6.0-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/bzr/setup.hint Uploaded. Yaakov
Re: RFU: arc-5.21p-1 (64bit)
On 2013-09-12 13:43, Jari Aalto wrote: wget --recursive --no-host-directories --cut-dirs=5 \ http://cante.net/~jaalto/tmp/cygwin/arc/64/arc/arc-5.21p-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/arc/64/arc/arc-5.21p-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/arc/64/arc/setup.hint I got 403 or 404 on the setup.hint files for the following x86_64 packages: abook arc rats rxp Yaakov
Re: RFU: wcd-5.2.4-1 (64bit)
On 2013-09-12 13:29, Jari Aalto wrote: wget --recursive --no-host-directories --cut-dirs=5 \ http://cante.net/~jaalto/tmp/cygwin/wcd/64/wcd/setup.hint \ http://cante.net/~jaalto/tmp/cygwin/wcd/64/wcd/wcd-5.2.4-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/wcd/64/wcd/wcd-5.2.4-1.tar.bz2 Uploaded the following for x86_64: afio annoyance-filter antiword apng2gif apngasm apngdis apngopt arj aview bzr indent joe mercurial msmtp pristine-tar splint tig unifdef untex vfu wcd wdiff wiggle zsync Yaakov
Re: RFU: joe-3.7-1 (64bit)
On 2013-09-12 13:31, Jari Aalto wrote: wget --recursive --no-host-directories --cut-dirs=5 \ http://cante.net/~jaalto/tmp/cygwin/joe/64/joe/joe-3.7-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/joe/64/joe/joe-3.7-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/joe/64/joe/setup.hint The ncurses dependency was incorrect in your setup.hint file. I fixed it on sourceware, but please make sure to fix your local copy. Yaakov
Re: RFU: pristine-tar-1.28-1 (64bit)
On 2013-09-12 13:32, Jari Aalto wrote: wget --recursive --no-host-directories --cut-dirs=5 \ http://cante.net/~jaalto/tmp/cygwin/pristine-tar/64/pristine-tar/pristine-tar-1.28-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/pristine-tar/64/pristine-tar/pristine-tar-1.28-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/pristine-tar/64/pristine-tar/setup.hint I had to remove this for now, as it requires xdelta which has yet to be packaged for x86_64. Yaakov
Re: [HEADSUP] Missing 64 bit packages
On 2013-08-31 11:52, Corinna Vinschen wrote: Charles Wilson libtirpc xerces-c Reini Urban protobuf FYI, I just NMU'd these as prereqs of Ports packages. Yaakov
Re: Move python3-lxml from ports to distro?
On 2013-09-11 08:47, Jon TURNEY wrote: Is it possible to move python3-lxml from ports to the distro? Done for both python-lxml and python3-lxml. HTH, Yaakov
Re: Moving libzip from ports to the distros
On 2013-09-03 07:53, Dr. Volker Zell wrote: Is it possible to move libzip from ports to the distros ? I could use it in the latest version of pstoedit for a new backend generating PowerPoint pptx files. Done. HTH, Yaakov
Re: RFU: wcd-5.2.4-1 (64bit)
On 2013-09-11 04:49, Jari Aalto wrote: wget --recursive --no-host-directories --cut-dirs=4 \ http://cante.net/~jaalto/tmp/cygwin/wcd/64/setup.hint \ http://cante.net/~jaalto/tmp/cygwin/wcd/64/wcd-5.2.4-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/wcd/64/wcd-5.2.4-1.tar.bz2 Could you rearrange the 64bit packages so they don't all end up in a '64' directory? e.g. ~jaalto/tmp/cygwin64/wcd/ with --cut-dirs=3? Yaakov
Re: RFU: bzr-2.6.0-1 (32bit)
On 2013-09-11 04:02, Jari Aalto wrote: wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/bzr/bzr-2.6.0-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/bzr/bzr-2.6.0-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/bzr/setup.hint These 404'd. Yaakov
Re: RFU: wcd 5.2.4-1 (32bit)
On 2013-09-11 02:44, Jari Aalto wrote: wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/wcd/setup.hint \ http://cante.net/~jaalto/tmp/cygwin/wcd/wcd-5.2.4-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/wcd/wcd-5.2.4-1.tar.bz2 wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/mercurial/mercurial-2.7.1-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/mercurial/mercurial-2.7.1-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/mercurial/setup.hint wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/pristine-tar/pristine-tar-1.28-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/pristine-tar/pristine-tar-1.28-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/pristine-tar/setup.hint Uploaded these packages for x86 only (see my other message about your x86_64 RFUs). BTW, there's nothing saying that you can't RFU multiple packages in one message. Yaakov
Re: RFU: pwget-2013.0911 (noarch)
On 2013-09-11 10:43, Jari Aalto wrote: 2013-09-11 18:13 Jari Aalto wrote: | Perl; upload to both 32bit and 64bit wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/pwget/pwget-2013.0911+gitaf1c897-2-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/pwget/pwget-2013.0911+gitaf1c897-2.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/pwget/setup.hint Uploaded for both arches. Yaakov
Re: RFU: msmtp-1.4.31-1 (32bit)
On 2013-09-11 10:20, Jari Aalto wrote: wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/msmtp/msmtp-1.4.31-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/msmtp/msmtp-1.4.31-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/msmtp/setup.hint Uploaded. Yaakov
Re: [RFU 32 + 64bit] fltk-1.3.2.9965-1
On 2013-09-10 13:55, A.R. Burgers wrote: new packages for fltk-1.3 are here for upload: Uploaded. Yaakov
Re: [64bit] mscgen
On 2013-09-09 01:16, David Stacey wrote: In my capacity as doxygen maintainer, I have a build of mscgen for 64-bit Cygwin. Doxygen can use this package to add sequence diagrams to the output. For sake of completeness, you may wish to take this until such a time as Michael McTernan (the mscgen maintainer) is ready to provide his own version. As he hasn't been heard from in two years, sounds like a good plan; uploaded. Should this be added to doxygen's requires:? Yaakov
Re: [RFU] doxygen-1.8.5-1
On 2013-09-09 01:15, David Stacey wrote: # 32-bit: # 64-bit: Uploaded. Please delete 1.8.3.1 and leave 1.8.4 as previous. Done. Yaakov
Re: Ok to upload on Monday. New version of upset.
On 2013-09-08 17:16, Christopher Faylor wrote: - Handles any compression format as long as it is understood by 'tar -vtf'. So .xz files should now be ok. If it isn't I'll be able to fix that quickly. I believe that setup.exe should also properly handle .xz files so I'd be interested in seeing if everything behaves correctly if you upload a .xz file now. FYI, the newly uploaded cygport-0.14.0-1 is in .tar.xz format, and appears correctly in cygwin.com/packages and setup.ini. Yaakov
Re: RFU: wcd-5.2.4-1 (64bit)
On 2013-09-11 21:44, Jari Aalto wrote: 2013-09-12 01:48 Yaakov (Cygwin/X) | Could you rearrange the 64bit packages so they don't all end up in a | 64' directory? e.g. ~jaalto/tmp/cygwin64/wcd/ with --cut-dirs=3? Adjusted in later posts (bug in script dind't consider 64bit URLs) You fixed --cut-dirs, but the packages' parent directory is still 64 instead of the package name, as they need to be. The 32/64-bit designation needs to be higher up (e.g. ~jaalto/tmp/cygwin64/wcd or ~jaalto/tmp/cygwin/64/wcd, etc.). Yaakov
Re: subtle problem with x86_64 automake1.4
On 2013-09-10 12:50, 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. This would be partially my fault. I NMU'd 1.4-p6-11 as part of the x86_64 bootstrap, with they hyphen per the upstream tarball versioning, not realizing the x86 package was versioned 1.4p6 (without the hyphen), and bumped the release number due to the addition of Fedora's patchset. When Chuck got around to redoing his packages, his last x86 release was 10, so he bumped his to 11, probably not realizing that it needed to be 12 because of my x86_64-only bump. 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. I removed my bootstrap packages in favour of Chuck's to be safe. Yaakov
Re: [64bit] python3 vs. threads
On 2013-08-15 10:32, Corinna Vinschen wrote: Jason? Is there any chance you could pick this up? I NMU'd both python and python3 for x86_64 earlier this week as a prerequisite for the GNOME 3.8 update; so far they're both working well. Yaakov
Re: [64bit] python3 vs. threads
On 2013-08-15 13:23, Corinna Vinschen wrote: On Aug 15 12:50, Yaakov (Cygwin/X) wrote: I NMU'd both python and python3 for x86_64 earlier this week as a prerequisite for the GNOME 3.8 update; so far they're both working well. That sounds good, basically, but what means NMU'd? :} Non-maintainer upload (Debian lingo, I'm not aware of a similar term in Fedora-land). Yaakov
Re: Missing 64 bit packages
On 2013-08-05 04:25, Corinna Vinschen wrote: editres js185 lighttpd nspr nss perl-clone These are up now. Yaakov
Re: Missing 64 bit packages
On 2013-08-05 04:25, Corinna Vinschen wrote: beforelight e2fsimage exif fvwm gsm libesmtp libmetalink mkcomposecache odbc-psql python-twisted sessreg snownews xcb-util-renderutil These are up now as well. grandr xfindproxy These are deprecated, and will soon be removed from i686 as well. xwinwm This too may be deprecated soon in favour of XtoW. Yaakov
Re: [64bit] python3 vs. threads
On 2013-07-30 20:52, Yaakov (Cygwin/X) wrote: I have patchsets ready for 2.7.5 (to fix the parsetuple issue) and 3.2.5 in Ports git; see 3.2-thread-cygwin64.patch for my proposed solution, which would have to be rebased to a newer version and expanded to all the other platform-specific implementations before pushing upstream. If you're okay with these, I have packages ready for x86_64. http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/python;a=tree http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/python3;a=tree Ping? Yaakov
Re: Missing 64 bit packages
On 2013-08-06 00:26, Andrew Schulman wrote: In x86, please obsolete lablgtk2, and unfortunately also sng. sng depends on libpng12, which is now obsolete. FreeBSD Ports builds sng with libpng15's internal headers; just added similar hack to Ports git: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/sng HTH, Yaakov
Re: Missing 64 bit packages
On 2013-08-06 14:48, Jon TURNEY wrote: ORPHANED xmon I do use this occasionally, so if Yaakov doesn't want this, I will adopt it. Go ahead. Yaakov
Re: cygport: automatically adding --srcdir to cygconf cmdline breaks build
On 2013-08-02 09:32, Corinna Vinschen wrote:
The configury consists of a non-autoconf configure file in the toplevel
dir, which disallows to build outside the source tree. But I have to
use it to get a `all in one go' configure/make run.
This is explicitly mentioned in the cygconf section of the manual:
cygconf is intended for configure scripts generated by, or compatible with,
autoconf. Packages with handwritten configure scripts may not accept all
the flags used by cygconf, in which case a direct call to the configure
script is in order.
So change this:
src_compile() {
cd ${S}
lndirs
cd ${B}
cygconf --enable-shared
cygmake
}
to something like (depending on what options this configure actually
accepts):
src_compile() {
lndirs
cd ${B}
./configure --sysconfdir=/etc --prefix=/usr || error configure failed
cygmake
}
Yaakov
Re: Please build 64 bit packages
On 2013-08-01 02:57, Corinna Vinschen wrote:
On Jul 31 18:23, Yaakov (Cygwin/X) wrote:
I just copied over the newest version of all noarch packages whose
deps are available. Ignoring obsolete packages, as of this moment,
the diffstat between the arches is +81/-316.
Cool, many thanks!
How did you generate the diffstat? The numbers indicate a lot of
preliminary work before running the tool since a simple diff returns
numbers along the lines of -1000/+1500.
First off, I'm basing my numbers on *source* packages. I then removed
all obsolete packages from the i686 list, as well as the cygwin{32,64}-*
packages from both lists (since those aren't really relevant to this
discussion). A copy of my list is at
sourceware:~yselkowitz/TODO_DISTRO_X64.diff.
So I'm wondering, do you have a list of important packages (like,
say, ocaml, inetutils, any libs) still missing? It might help to
get a better picture of the state of the x86_64 distro.
I'd say llvm, nspr, ocaml and postgresql are the most noticeable missing
prereqs at the moment. The first two are mine, but they require
significant porting work (particularly llvm), and I've been focused on
other packages. There are a few other minor libraries missing, but the
rest looks to be mostly programs that just need a rebuild.
Yaakov
Re: Please build 64 bit packages
On 2013-08-01 04:05, Corinna Vinschen wrote: I could take your diff and generate a missing packages list with maintainer names from there and publish it here on cygwin-apps. I could do this every few weeks, so we could keep a porting progress and discussion platform to discuss the dependencies which still have to be resolved. Does that sounds useful? Yes, but right now we know people are waiting for ocaml and postgresql, so we can leave off their reverse deps for now. Yaakov
Re: [64-bit Request for Testing] cppcheck-1.60.1-1
On 2013-08-01 08:53, Chris Sutcliffe wrote: On 1 August 2013 08:04, Corinna Vinschen wrote: On Aug 1 07:36, Chris Sutcliffe wrote: One thing I noticed is that cygport listed cygwin64-gcc-core as a dependency for cppcheck. Will this cause an issue when installed on 64-bit Cygwin? This looks wrong. I removed this dependency manually for now. The correct dependency is libgcc1, and the same is true if cygwin32-gcc-core shows up in a 64-32 scenario. Thanks, I'll clean up my local copy as well. Yaakov, I'm assuming cygport is picking this up automatically, is there anyway it can be skipped, or is it something I'll need to keep an eye on going forward? You should *always* look at the dependencies and make sure they make sense, that's why they're shown when generated. In the case of libgcc1, I'm afraid you'll need to edit this manually until I figure out a workaround. Yaakov
Re: Sorted list of packages missing in the 64 bit distro yet
On 2013-08-01 09:37, Corinna Vinschen wrote: from the list Yaakov generated today, I created another list of missing packages sorted by maintainer (first name). That gives you an easy overview what's missing and which of those packages are yours. It's not a very long list, actually. It would be very nice if you could have a look if some of your packages are still missing and build them as time permits. Alternatively, if you think a package doesn't have to be rebuilt for 64 bit (Chuck's older automake versions come to mind), just say the word and I remove them from the list. 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 [snip] pdksh This is actually an obsolete package that I missed; its replacement is mksh. Unknown maintainer perl-clone That's mine, as a prerequisite of perl-DBI, and it's now in my upload queue. Damien Doligez ocaml Ping? David Rothenberger pdftk This requires gcc-java. Yaakov
Re: building Perl module DBD-ODBC-4.3 under 64-bit cygwin
On 2013-08-01 07:57, Simon Barnes wrote: I'm having difficulty with this and would appreciate any suggestions. It does build under 32-bit cygwin. Not really. The included makefile tries to force Cygwin to use ODBC32, where we use iODBC; the conflicts between the two is what cause this error. A patch to correctly build DBD::ODBC is in Ports: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/perl-DBD-ODBC;a=tree A binary perl-DBD-ODBC is also available in the Ports repo. Yaakov
Re: Please try new setup exe's
On 2013-07-15 13:58, Christopher Faylor wrote: 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. [snip] The intent of release:, as I stated elsewhere is to eventually get rid of the mirror directories created by setup.exe. They will be replaced with release directories like cygwin or, e.g., cygwinports. As of last week, Ports uses the new $arch/setup.ini layout with release: cygwinports. Do you have a patch already to implement the release directories? Yaakov
