Re: [ITP] man-db

2014-06-02 Thread Yaakov (Cygwin/X)

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




[SECURITY] libtasn1, gnutls

2014-06-01 Thread Yaakov (Cygwin/X)

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

2014-06-01 Thread Yaakov (Cygwin/X)

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



Re: [ITP] man-db

2014-06-01 Thread Yaakov (Cygwin/X)

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

2014-05-30 Thread Yaakov (Cygwin/X)

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: cygport patches for texlive.cygclass

2014-05-30 Thread Yaakov (Cygwin/X)

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] man-db

2014-05-30 Thread Yaakov (Cygwin/X)

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: [ITP] mp3info-0.8.5a

2014-05-30 Thread Yaakov (Cygwin/X)

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] mp3info-0.8.5a

2014-05-29 Thread Yaakov (Cygwin/X)

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

2014-05-23 Thread Yaakov (Cygwin/X)
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: [PATCH cygport] Make src packages which put files under /usr/src/package-version-release/

2014-05-04 Thread Yaakov (Cygwin/X)

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

2014-05-04 Thread Yaakov (Cygwin/X)

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: perl-5.18.2-1

2014-05-03 Thread Yaakov (Cygwin/X)

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: [PATCH cygport] Make src packages which put files under /usr/src/package-version-release/

2014-04-27 Thread Yaakov (Cygwin/X)

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;
 }
 


Re: [RFC] cygport: arch-specific workdir

2014-04-27 Thread Yaakov (Cygwin/X)

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: 64-bit: Missing perl modules

2014-04-08 Thread Yaakov (Cygwin/X)

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



[SECURITY] jbigkit (CVE-2013-6369)

2014-04-08 Thread Yaakov (Cygwin/X)

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: fontconfig packaging suggestion

2014-04-04 Thread Yaakov (Cygwin/X)

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)

2014-03-27 Thread Yaakov (Cygwin/X)

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



[ITP] djvulibre, ilmbase, openexr, liblqr1, libwebp

2014-03-26 Thread Yaakov (Cygwin/X)
I will be uploading the libraries listed in the subject soon.  They are 
all optional dependencies of ImageMagick, and libwebp can be used by 
GraphicsMagick and will eventually be a dependency of future releases of 
GStreamer and WebKit.


Please note that the uploaded version of libwebp will be newer than that 
currently in Ports; the others are being moved straight from Ports.



Yaakov


Re: Untidy situation regarding p11-kit packaging causing setup inconsistency

2014-03-25 Thread Yaakov (Cygwin/X)

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

2014-03-19 Thread Yaakov (Cygwin/X)

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?

2014-03-17 Thread Yaakov (Cygwin/X)

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

2014-03-07 Thread Yaakov (Cygwin/X)
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

2014-02-25 Thread Yaakov (Cygwin/X)
Just noticed that Windows 8.1 compatibility was missing from 
setup*.exe.manifest; patch attached.



Yaakov
2014-02-25  Yaakov Selkowitz  

* 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 @@
   
   
   
+  
+  
 
   
 
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 @@
   
   
   
+  
+  
 
   
 


Re: [ITP] google-breakpad

2014-02-20 Thread Yaakov (Cygwin/X)

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

2014-02-17 Thread Yaakov (Cygwin/X)

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: Missing .la files

2014-02-17 Thread Yaakov (Cygwin/X)

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: [PATCH] rebase: fix 32-bit rollover

2014-02-11 Thread Yaakov (Cygwin/X)

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



[PATCH] rebase: fix 32-bit rollover

2014-02-10 Thread Yaakov (Cygwin/X)
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.



Yaakov
Index: rebase.c
===
RCS file: /cvs/cygwin-apps/rebase/rebase.c,v
retrieving revision 1.20
diff -u -p -r1.20 rebase.c
--- rebase.c1 Dec 2013 12:19:07 -   1.20
+++ rebase.c10 Feb 2014 19:04:01 -
@@ -1063,6 +1063,12 @@ retry:
   return FALSE;
 }
 
+  /* handle 32-bit rollover */
+  if (down_flag
+  && machine == IMAGE_FILE_MACHINE_I386
+  && *new_image_base > 0x)
+*new_image_base = 0x1L - new_image_size;
+
 #if defined(__CYGWIN__) || defined(__MSYS__)
   /* Avoid the case that a DLL is rebased into the address space taken
  by the Cygwin DLL.  Only test in down_flag == TRUE case, otherwise


Re: x86_64 Perl module ownership

2014-02-06 Thread Yaakov (Cygwin/X)

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




neon: use ca-certificates

2014-02-06 Thread Yaakov (Cygwin/X)

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


x86_64 Perl module ownership

2014-02-06 Thread Yaakov (Cygwin/X)

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


openssl: add ca-certificates dep

2014-02-05 Thread Yaakov (Cygwin/X)

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

2014-01-30 Thread Yaakov (Cygwin/X)

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

2014-01-29 Thread Yaakov (Cygwin/X)

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

2014-01-19 Thread Yaakov (Cygwin/X)

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

2014-01-15 Thread Yaakov (Cygwin/X)

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

2014-01-14 Thread Yaakov (Cygwin/X)

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



Re: [ITA] tcl-sqlite3

2014-01-14 Thread Yaakov (Cygwin/X)

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

2014-01-14 Thread Yaakov (Cygwin/X)

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

2014-01-14 Thread Yaakov (Cygwin/X)

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

2014-01-14 Thread Yaakov (Cygwin/X)

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: RFC: usage of cygwin32-/cygwin64- cross-toolchains

2014-01-09 Thread Yaakov (Cygwin/X)

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




RFC: usage of cygwin32-/cygwin64- cross-toolchains

2014-01-09 Thread Yaakov (Cygwin/X)
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


SourceForge project upgrade

2013-12-18 Thread Yaakov (Cygwin/X)
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

2013-11-21 Thread Yaakov (Cygwin/X)

On 2013-11-21 03:06, Corinna Vinschen wrote:

2013-11-20  Yaakov Selkowitz  

* crypt.c: #include  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

2013-11-20 Thread Yaakov (Cygwin/X)

Attached patch is pretty self-explanatory.


Yaakov
2013-11-20  Yaakov Selkowitz  

	* crypt.c: #include  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 
 #include 
 #include 
+#include 
 #include "encrypt.h"
 
 const char *sc = "./"


Re: buliding lftp fails

2013-11-17 Thread Yaakov (Cygwin/X)

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)

2013-11-07 Thread Yaakov (Cygwin/X)

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

2013-10-31 Thread Yaakov (Cygwin/X)

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)

2013-10-30 Thread Yaakov (Cygwin/X)

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)

2013-10-29 Thread Yaakov (Cygwin/X)

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)

2013-10-28 Thread Yaakov (Cygwin/X)

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)

2013-10-25 Thread Yaakov (Cygwin/X)

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)

2013-10-22 Thread Yaakov (Cygwin/X)

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

2013-10-21 Thread Yaakov (Cygwin/X)

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: RFU: lcab-1.0b12-1 (64bit)

2013-10-09 Thread Yaakov (Cygwin/X)

On 2013-09-15 12:52, Jari Aalto wrote:

 http://cante.net/~jaalto/tmp/cygwin/lcab/64/lcab/setup.hint


There were two errors in this setup.hint file:

1) The tag is 'requires:' with an 's'.

2) 'cygwin' should never be listed in requires:.

I fixed this on sourceware; please fix your local copy.


Yaakov



Re: cygport: perl.cygclass and Module::Build::Tiny compatibility

2013-10-08 Thread Yaakov (Cygwin/X)

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: cygport: perl.cygclass and Module::Build::Tiny compatibility

2013-10-08 Thread Yaakov (Cygwin/X)

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: [PATCH] genini: support new tags

2013-10-07 Thread Yaakov (Cygwin/X)

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



[PATCH] genini: support new tags

2013-10-07 Thread Yaakov (Cygwin/X)
The attached patch for genini allows it to recognize (and ignore) the 
new setup.hint tags.



Yaakov
2013-10-07  Yaakov Selkowitz  

	* 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: pcre: setup.hint

2013-10-07 Thread Yaakov (Cygwin/X)

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




Re: libevent-2.0.21

2013-10-04 Thread Yaakov (Cygwin/X)

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)

2013-10-03 Thread Yaakov (Cygwin/X)

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: [64bit] python3 vs. threads

2013-10-02 Thread Yaakov (Cygwin/X)

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



Re: [HEADSUP] Missing 64 bit packages

2013-10-02 Thread Yaakov (Cygwin/X)

On 2013-08-31 11:52, Corinna Vinschen wrote:

   Reini Urban

 clamav


I have NMU'd this as well.


Yaakov



[PATCH] setup: installed xz packages (was: cygcheck: xz packages)

2013-09-17 Thread Yaakov (Cygwin/X)

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 

	* 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: Cygport per-package PKG_EXCLUDE?

2013-09-13 Thread Yaakov (Cygwin/X)

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: 64-bit Cygwin installation is missing /usr/bin/lockfile

2013-09-13 Thread Yaakov (Cygwin/X)

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: RFU: pristine-tar-1.28-1 (64bit)

2013-09-12 Thread Yaakov (Cygwin/X)

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: RFU: joe-3.7-1 (64bit)

2013-09-12 Thread Yaakov (Cygwin/X)

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: wcd-5.2.4-1 (64bit)

2013-09-12 Thread Yaakov (Cygwin/X)

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: arc-5.21p-1 (64bit)

2013-09-12 Thread Yaakov (Cygwin/X)

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: bzr-2.6.0-1 (32bit)

2013-09-12 Thread Yaakov (Cygwin/X)

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: wcd-5.2.4-1 (64bit)

2013-09-11 Thread Yaakov (Cygwin/X)

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: Ok to upload on Monday. New version of upset.

2013-09-11 Thread Yaakov (Cygwin/X)

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] doxygen-1.8.5-1

2013-09-11 Thread Yaakov (Cygwin/X)

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: [64bit] mscgen

2013-09-11 Thread Yaakov (Cygwin/X)

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 32 + 64bit] fltk-1.3.2.9965-1

2013-09-11 Thread Yaakov (Cygwin/X)

On 2013-09-10 13:55, A.R. Burgers wrote:

new packages for fltk-1.3 are here for upload:


Uploaded.


Yaakov



Re: RFU: msmtp-1.4.31-1 (32bit)

2013-09-11 Thread Yaakov (Cygwin/X)

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: pwget-2013.0911 (noarch)

2013-09-11 Thread Yaakov (Cygwin/X)

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: wcd 5.2.4-1 (32bit)

2013-09-11 Thread Yaakov (Cygwin/X)

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: bzr-2.6.0-1 (32bit)

2013-09-11 Thread Yaakov (Cygwin/X)

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 (64bit)

2013-09-11 Thread Yaakov (Cygwin/X)

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: Move python3-lxml from ports to distro?

2013-09-11 Thread Yaakov (Cygwin/X)

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

2013-09-11 Thread Yaakov (Cygwin/X)

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: [HEADSUP] Missing 64 bit packages

2013-09-11 Thread Yaakov (Cygwin/X)

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: subtle problem with x86_64 automake1.4

2013-09-10 Thread Yaakov (Cygwin/X)

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

2013-08-15 Thread Yaakov (Cygwin/X)

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: [64bit] python3 vs. threads

2013-08-15 Thread Yaakov (Cygwin/X)

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: Missing 64 bit packages

2013-08-12 Thread Yaakov (Cygwin/X)

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: Missing 64 bit packages

2013-08-12 Thread Yaakov (Cygwin/X)

On 2013-08-05 04:25, Corinna Vinschen wrote:

   editres
   js185
   lighttpd
   nspr
   nss
   perl-clone


These are up now.


Yaakov



Re: [64bit] python3 vs. threads

2013-08-08 Thread Yaakov (Cygwin/X)

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

2013-08-06 Thread Yaakov (Cygwin/X)

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: Missing 64 bit packages

2013-08-06 Thread Yaakov (Cygwin/X)

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: cygport: automatically adding --srcdir to cygconf cmdline breaks build

2013-08-02 Thread Yaakov (Cygwin/X)

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: building Perl module DBD-ODBC-4.3 under 64-bit cygwin

2013-08-01 Thread Yaakov (Cygwin/X)

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: Sorted list of packages missing in the 64 bit distro yet

2013-08-01 Thread Yaakov (Cygwin/X)

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: [64-bit Request for Testing] cppcheck-1.60.1-1

2013-08-01 Thread Yaakov (Cygwin/X)

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



  1   2   3   4   5   6   7   8   9   10   >