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
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
On 2013-07-25 07:15, Corinna Vinschen wrote:
now that the 64 bit version is in the wild, it would be incredibly cool
if you could all have a look into building your packages, which are not
yet available, for the 64 bit distro.
Alternatively, for those of your packages which are "noarch" packages
On 2013-07-31 16:55, Warren Young wrote:
This release simply fixes the libexpat${abi}-devel naming problem
brought up by Yaakov, using the new PKG_OBSOLETES feature of cygport.
Uploaded; thanks.
Yaakov
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 w
On 2013-07-30 17:54, Yaakov (Cygwin/X) wrote:
On 2013-06-03 23:30, Yaakov (Cygwin/X) wrote:
Jason,
As part of the 64bit bootstrap process, I packaged python3, but had to
configure it --without-threads due to a runtime error.
I think I tracked down the source of the problem:
The PyThread TLS
On 2013-06-03 23:30, Yaakov (Cygwin/X) wrote:
Jason,
As part of the 64bit bootstrap process, I packaged python3, but had to
configure it --without-threads due to a runtime error.
I think I tracked down the source of the problem:
The PyThread TLS APIs, added in 3.2 via issue 9786 (namely
postinstall.sh:
/usr/bin/mkdir -p "$(/usr/bin/cygpath $CYGWINFORALL -P)/Cygwin-X"
/usr/bin/mkshortcut $CYGWINFORALL -P -i /path/to/foo.exe-or-.ico -n
"Cygwin-X/AppName" -a "/usr/bin/bash.exe -l -c '/usr/bin/foo.exe -display
:0.0'" /usr/bin/run.exe
There
On 2013-07-29 03:48, Corinna Vinschen wrote:
Is it to be expected that there are packages (clang, imake,...)
dependent on gcc4-core etc. ?
the affected packages are
clangYaakov S
imakeYaakov S
libfltk-develTeun Burgers
On 2013-07-25 14:50, Warren Young wrote:
I'll wait for this PKG_OBSOLETES feature to ship in Cygport, and be a
guinea pig for it.
It's in git master already.
Yaakov
On 2013-07-23 06:54, Jon TURNEY wrote:
Please be aware that you'll need to rebuild x86_64 cairo with 1.7.22 to
resolve this issue.
Done. Thanks for tracking this down!
Yaakov
On 2013-07-23 14:39, Achim Gratz wrote:
Yaakov (Cygwin/X) writes:
I wanted to get feedback from those using cygport regarding a possible
new feature: PKG_OBSOLETES. This is best explained with an example,
so let's say I had the following:
[..]
The attached patch is what I'm worki
On x86, both binutils and gdb provide the BFD headers, but only the
former provides the libs.
On x86_64, both binutils and gdb provides the BFD headers *and* libs.
AFAIK these should *only* be provided by binutils, with the caveat that
libiberty needs a patch to install properly per my comment
On 2013-07-23 04:06, Corinna Vinschen wrote:
On Jul 23 00:02, Yaakov (Cygwin/X) wrote:
I wanted to get feedback from those using cygport regarding a
possible new feature: PKG_OBSOLETES.
Looks good to me.
Thanks for the feedback.
Btw., did you create the 64 bit expat packages or did Warren
On 2013-07-23 10:37, Ken Brown wrote:
I don't know if you saw
http://cygwin.com/ml/cygwin-apps/2013-07/msg00229.html, but Jon found
the cause of a bug that you and I both ran into. The bug has been fixed
in cygwin-1.7.22, but we need a rebuild of libcairo2 on x86_64 in order
to take advantage of
I wanted to get feedback from those using cygport regarding a possible
new feature: PKG_OBSOLETES. This is best explained with an example, so
let's say I had the following:
NAME="libfoo"
...
PKG_NAMES="libfoo1 libfoo-bin libfoo-devel"
libfoo1_CONTENTS="usr/bin/cygfoo-1.dll"
libfoo_bin_CONTENTS
I just uploaded the following packages (plus their subpackages) for the
64bit distribution:
* cmake-2.8.11-1
* giflib-4.1.6-12
* glib1.2-1.2.10-12
* gtk1.2-1.2.10-12
* gtk1.2-engines-0.12-11
* imlib-1.9.15-14
* phonon-backend-gstreamer-4.6.1-1
* qt3-3.3.8b-12
Yaakov
On 2013-07-15 16:43, upset lived up to its name and complained:
upset: *** /sourceware/ftp/pub/cygwin/x86/setup.ini: warning - package
libSuiteSparse-devel refers to nonexistent external-source: SuiteSparse
Marco,
The problem was that libSuiteSparse-devel-3.7.1-1 was left without a
source pa
On 2013-07-14 20:16, Christopher Faylor wrote:
upset: *** /sourceware/ftp/pub/cygwin/x86_64/setup.ini: warning - package
openbox requires nonexistent package xprop
upset: *** /sourceware/ftp/pub/cygwin/x86_64/setup.ini: warning - package
openbox requires nonexistent package xsetroot
upset: ***
I just uploaded the following packages (and their subpackages) for the
64-bit distribution:
* a2ps-4.14-2
* aria2-1.17.1-1
* glw-8.0.0-1
* html2ps-1.0b7-2
* units-2.01-2
* xprop-1.2.1-1
* xrdb-1.0.9-1
* xsetroot-1.1.0-1
Yaakov
On 2013-07-14 04:10, Achim Gratz wrote:
To register what has been discussed before in this thread: I can provide
upx for 64bit if anybody wants it, but unfortunately it can't deal with
64bit executables and therefore is nearly useless.
It still can be used in cross-compiling scenarios, so pleas
On 2013-07-14 01:24, David Stacey wrote:
On 14/07/13 06:40, Yaakov (Cygwin/X) wrote:
On 2013-07-13 21:38, Christopher Faylor wrote:
On Sat, Jul 13, 2013 at 09:44:40PM -0400, Andrew Schulman wrote:
There are of course other packages that could be called missing because
they haven't been p
ville
colordiff
colorgcc
connect-proxy
convmv
copyright-update
corkscrew
cppcheck
cppi
cramfs
cron
cscope
ctorrent
ctris
cvs2svn
cvsutils
cygwin-doc
cygwin-x-doc
ddd
ddir
ddrescue
delta
deroff
dhttpd
distcc
dmalloc
docbook-utils
dog
dpatch
duff
e2fsimage
editres
ELFIO
email
epstool
exif
exim
fcgi
f
On 2013-07-12 19:38, Chris Sutcliffe wrote:
On 12 July 2013 17:51, Yaakov (Cygwin/X) wrote:
On 2013-07-12 16:03, Chris Sutcliffe wrote:
My Announcement message was rejected by the moderator. Are we not
supposed to announce 64bit packages?
Did you *read* the rejection message?
Yep, this is
On 2013-07-12 16:03, Chris Sutcliffe wrote:
My Announcement message was rejected by the moderator. Are we not
supposed to announce 64bit packages?
Did you *read* the rejection message?
Yaakov
On 2013-07-11 13:36, Corinna Vinschen wrote:
But there's a catch: After uploading, while adding the svn_load_dirs
package to the cygwin-pkg-maint file I noticed that there's already a
package svn-load from Jari Aalto
BTW: http://cygwin.com/ml/cygwin-apps/2013-07/msg00066.html
Yaakov
On 2013-07-10 10:05, Charles Wilson wrote:
On 7/10/2013 2:11 AM, Fedin Pavel wrote:
Hello! I've just stumbled accross a bug in Automake v1.9 package. I was
trying to regenerate files in a source tree which sets automake
version to
1.9. 'automake -icf' has copied files, but config.guess bundled
It was just brought to my attention[1] that Jari's svn-load package is
(and always has been) missing a crucial dependency, pysvn (not to be
confused with subversion-python). I have python-pysvn and python3-pysvn
in Ports; should I move these to the distro, or remove svn-load?
Yaakov
[1] htt
On 2013-07-05 10:17, David Rothenberger wrote:
I sincerely hope that nobody will ever use scons.
+1; I cringe every time I have to deal with it.
If it becomes popular, I will quickly be out of my depth maintaining
the package, since I'm no gcc build expert nor a Python programmer.
Fortunate
On 2013-06-30 14:03, Yaakov (Cygwin/X) wrote:
On 2013-06-29 06:03, JonY wrote:
The upload should be complete last week.
OK, I'm planning to take care of the upgrade tonight.
It's done now:
* gcc-4.7.3-1 is stable; 4.5.3-3 is previous (renamed from gcc4-* to
gcc-* for simplicity
On 2013-06-29 06:03, JonY wrote:
The upload should be complete last week.
OK, I'm planning to take care of the upgrade tonight.
Yaakov
On 2013-06-19 18:15, JonY wrote:
I see, should have uploaded the earlier version from your cygport. I am
uploading it now and should take a day or so to complete. Hopefully, my
internet connection doesn't die when I'm away.
Ping?
Yaakov
On 2013-06-22 16:13, Christopher Faylor wrote:
Here's a similar list for 64-bit packages. Apparently genini's error
checking leaves something to be desired. Obviously some of these are
not obsolete.
Some of these actually are, meaning that they were copied straight from
their x86 version and
I just uploaded the following packages (plus their subpackages) for the
64bit distribution:
* cygwin32-libX11-1.6.0-1
* cygwin32-libXau-1.0.8-1
* cygwin32-libxcb-1.9.1-1
* cygwin32-libXdmcp-1.1.1-1
* cygwin32-xproto-7.7-2
* dbus-1.6.12-1
* gcr-3.6.2-1
* gnome-icon-theme-3.6.2-1
* gnome-keyring-3
On 2013-06-22 15:49, Christopher Faylor wrote:
I'm refreshing the procedure for updating setup.ini on sourceware
As part of this, I would like to suggest again that a noarch directory
be added alongside x86 and x86_64, and its files be included in each
arch's setup.ini. There are a LOT of no
On 2013-06-19 17:18, JonY wrote:
I still build gcc with the -4 suffix, but it no longer does the gcc
alternative switch. The next version should remove those.
That's not going to work. With the -4 suffix but without the symlinks,
this will never be found as *the* gcc/g++/etc. We have already
The Linux Foundation has taken over development of the FHS[1], and have
added /usr/libexec[2] to the forthcoming 3.0 spec, based in its
widespread use in some Linux distributions and other *NIX systems (*BSD,
Minix, perhaps others).
Should we do the same on Cygwin by changing the default cygco
On 2013-06-18 17:32, JonY wrote:
On 6/19/2013 06:17, Yaakov (Cygwin/X) wrote:
As for the logistics, how about you put this in a temporary location
(not under release) that I can access, and then I can deal with all the
necessary transitioning.
Where do I put the files at? /sourceware/cygwin
On 2013-06-13 19:42, Florent Monnier wrote:
If I'm not mistaken cygwin also provides some libs for mingw's toolchain.
Any chance to get a mingw compiled ocaml in cygwin?
Perhaps OT, but that is NOT as easy as it sounds.
Yaakov
On 2013-06-16 06:38, Ken Brown wrote:
On 6/15/2013 8:37 AM, Achim Gratz wrote:
It's easy enough to provide bundle packages and the normal user would
never need to look at the individual distribution packages.
Maybe I'm missing something, but I don't see the need for bundle
packages. Take the
On 2013-06-15 07:37, Achim Gratz wrote:
Reini Urban writes:
If you really want to maintain 2000+ packages do it. I don't care.
Nobody suggested that all of a sudden Cygwin should come with all CPAN
distributions pre-bundled. My current guess, based on my own usage,
would be on the order of 30
On 2013-06-17 17:21, JonY wrote:
For the record, here are the deps stated by cygport:
gcc requires: gcc-core gcc-g++
gcc-core requires: bash libcloog0 libgcc1 libgmp3 libgomp1 libiconv2 libintl8
libmpc3 libmpfr4 libppl_c4 libquadmath0 libssp0 zlib0 binutils w32api-headers
w32api-runtime
gcc-
On 2013-06-16 09:56, Christopher Faylor wrote:
I thought that Dave Korn was back and supporting gcc. Did that change?
http://cygwin.com/ml/cygwin-apps/2013-06/msg00079.html
Yaakov
On 2013-06-16 06:48, JonY wrote:
I noticed some deps are still marked as experimental, eg
cloog/ppl/mpc/mpfr/gmp. Parts of the experimental ppl even requires
experimental 4.7.x libstdc++.
For gcc-4.7, we need the test versions of all those deps.
setup constantly tries to revert it to stable v
On 2013-06-14 13:37, Reini Urban wrote:
Since you need so many perl deps, do you really want to keep them seperate?
Yes.
I would just bundle them to something like a perl-biber-bundle
package, into vendor_perl.
No, perl_vendor needs to go away, not get bigger.
Yaakov
Several people have mentioned changes they would like to see in
cygport's documentation. I believe the stable APIs are all documented
now, but what more would you like to see in the docs?
Yaakov
On 2013-06-13 13:37, Ken Brown wrote:
On 6/13/2013 6:09 AM, Yaakov (Cygwin/X) wrote:
On 2013-06-12 09:10, Ken Brown wrote:
1. Should these build prerequisites be added to the 64bit distro?
Otherwise it will be difficult for others to rebuild biber from source.
These should be added to both
On 2013-06-11 10:37, Damien Doligez wrote:
Given what Yaakov said, wouldn't it make sense to provide the former
ocaml libs and start using a versioned runtime lib approach?
I'm not sure I understand exactly what you mean, but providing several
versions of the libraries is not going to work beca
On 2013-06-12 09:10, Ken Brown wrote:
Here are my questions:
1. Should these build prerequisites be added to the 64bit distro?
Otherwise it will be difficult for others to rebuild biber from source.
These should be added to both, although I suspect many are noarch, so
you should only need to
On 2013-06-12 14:08, Charles Wilson wrote:
On 6/12/2013 11:13 AM, Corinna Vinschen wrote:
However, why is libintl.h in gettext, and not in gettext-devel?
A header file belongs in the devel package if there is one, isn't it?
The upstream maintainer, Bruno Haible, strongly recommends certain
co
On 2013-06-10 07:46, Dr. Volker Zell wrote:
I think the stack trace translates to the following:
Stack trace:
FrameFunctionArgs
ber_get_stringbvl
/usr/src/debug/openldap-2.4.35-1/libraries/liblber/decode.c:414
ber_scanf
/usr/src/debug/openldap-2.4.35-1/libraries/liblber/decode.c:790
I just uploaded the following packages for the 64bit distribution:
* apache2-2.2.23-2
* apache2-devel-2.2.23-2
* apache2-manual-2.2.23-2
The LDAP-based modules have been disabled until openldap is available
and apr/aprutil is rebuilt with it.
I'll be AFK until Sunday.
Yaakov
On 2013-06-07 07:31, Damien Doligez wrote:
D=http://gallium.inria.fr/~doligez/cygwin
wget -x -nH --cut-dirs=2 \
$D/ocaml/emacs-ocaml/emacs-ocaml-4.00.1-1.tar.bz2 \
$D/ocaml/emacs-ocaml/setup.hint \
$D/ocaml/ocaml-4.00.1-1-src.tar.bz2 \
$D/ocaml/ocaml-4.00.1-1.tar.bz2 \
$D/ocaml/ocaml-ba
I just uploaded the following packages (plus their subpackages) for the
64bit distribution:
* libdmx-1.1.3-1
* libfontenc-1.1.2-1
* libX11-1.6.0-1
* libXau-1.0.8-1
* libxcb-1.9.1-1
* libXcursor-1.1.14-1
* libXext-1.3.2-1
* libXfixes-5.0.1-1
* libXi-1.6.2.901-1
* libXinerama-1.1.3-1
* libXrandr-1
On 2013-05-31 11:58, Yaakov (Cygwin/X) wrote:
On 2013-05-31 08:39, Dr. Volker Zell wrote:
On cygwin 64bit compilation of openldap doesn't produce shared libraries for
libldap and libldap_r (although a shared lib for liblber is produced).
Assuming you are using the same build as the
On 2013-06-06 06:25, Ken Brown wrote:
On 6/6/2013 12:48 AM, Yaakov (Cygwin/X) wrote:
Hmm, didn't see that, but I may have already installed it manually
during the bootstrap. Based on the error message, the problem is that
the in-tree copy is not added to the search path during that co
I just uploaded the following packages (plus their subpackages) for the
64bit distribution:
* cppunit-1.12.1-2
* cygwin32-1.7.19-1
* dconf-0.14.1-1
* enchant-1.6.0-1
* freetds-0.91-4
* fribidi-0.19.2-1
* glib2.0-networking-2.34.2-1
* gstreamer0.10-plugins-good-0.10.31-5
* gstreamer1.0-plugins-go
On 2013-06-05 17:39, Ken Brown wrote:
In an effort to get some practice building perl modules, I tried to
rebuild perl-XML-SAX from source. If I install all perl-* packages
currently in the 64bit distribution except for that one, then the build
fails at the install stage as follows:
[snip]
If
On 2013-06-05 13:40, Ken Brown wrote:
In order to build biber.exe, I need to build the perl module
PAR::Packer.
I have PAR::Packer and its dependencies ready for upload later today,
and have updated Ports git accordingly.
On 32-bit Cygwin, boot_Win32CORE is provided by the library
/usr/lib/
I just uploaded the following packages (plus their subpackages) for the
64bit distribution:
* automoc4-0.9.88-10
* avahi-0.6.31-2
* cairo-1.12.14-2 (fixes LTO bug in libcairo-gobject)
* docbook2X-0.8.8-1
* font-cantarell-otf-0.0.12-1
* gcc-4.8.1-1 (with new fix for PR56742)
* giflib-4.2.1-1
* gn
On 2013-06-04 14:40, Corinna Vinschen wrote:
I was going to create a -5 binutils package configured with
--enable-install-libiberty, but libiberty.a is not installed.
Is there something else I have to do to accomplish that?
Well, it looks they messed this up worse than I had thought. The
var
On 2013-06-02 18:21, David Rothenberger wrote:
On 64-bit:
% cygcheck -l ruby | grep minitest
This causes the subversion ruby tests to fail.
Is there any chance this could be included in the 64-bit ruby?
This will be fixed in the -2 release.
Yaakov
On 2013-06-04 08:49, Corinna Vinschen wrote:
I have uploaded a new binutils 2.23.52-4 package to the 64 bit test
distro.
I have prepared a cygwin64-binutils.i686 with this patch to match.
But this recent (and unrelated) upstream change has caused libiberty.a
not to be installed by default:
Jason,
As part of the 64bit bootstrap process, I packaged python3, but had to
configure it --without-threads due to a runtime error. However, I am
finding now that this is not a regularly used configuration; several
major Python modules use PyGILState_*() APIs unconditionally, which
aren't e
On 2013-05-31 08:39, Dr. Volker Zell wrote:
On cygwin 64bit compilation of openldap doesn't produce shared libraries for
libldap and libldap_r (although a shared lib for liblber is produced).
Assuming you are using the same build as the i686 2.4.35-1, the problem
is that you didn't call cygaut
David,
Are you able to add your multimedia libraries to 64bit/release soon?
I'm ready to start working on GStreamer on my way to an attempt at qt4,
so I'll need those libraries first.
Yaakov
docbook2X converts DocBook documents into the man page format and the
GNU Texinfo format. It is used during 'make info' in the git package,
among others.
The upstream commands are ordinarily docbook2man and docbook2texi, but
those names collide with the more commonly used docbook-utils. Vari
On 2013-05-29 23:12, Reini Urban wrote:
On Wed, May 29, 2013 at 10:27 AM, Dr. Volker Zell wrote:
Is it possible to get a 64bit version of mhash. I need it for mcrypt. By the way
there is a newer version (0.9.9.9) on
http://sourceforge.net/projects/mhash/files/mhash/
Yes, but anybody can beat
On 2013-05-29 19:27, Ken Brown wrote:
Are you able to build poppler and libzzip-devel for 64bit Cygwin? These
are the only missing prerequisites for texlive.
Done.
Yaakov
I just added the following to 64bit/release:
boost/libboost* 1.53.0-2
botan/libbotan* 1.8.14-1 (adopting from Lapo)
monotone 1.0-3 (adopting from Lapo)
openjpeg/libopenjpeg* 1.5.1-2
poppler/libpoppler* 0.20.5-2 (no qt4 for now)
source-highlight/libsource-highlight* 3.1.7-3
zziplib/libzzip* 0.13.
On 2013-05-27 15:46, Andrew Schulman wrote:
wget \
http://home.comcast.net/~andrex2/cygwin/lftp/lftp-4.4.7-1.tar.bz2 \
http://home.comcast.net/~andrex2/cygwin/lftp/lftp-4.4.7-1-src.tar.bz2 \
http://home.comcast.net/~andrex2/cygwin/lftp/lftp-debuginfo-4.4.7-1.tar.bz2
Uploaded, and removed
Dave,
It's been a month since we last discussed the GCC upgrade. What, if
anything, is holding up a stable 4.7.3?
Yaakov
On 2013-05-23 03:44, Corinna Vinschen wrote:
However, there are a couple of packages which change the system on a
global basis. I see three groups here:
[snip]
2. Packages installing services.
#2 packages have a service name collision. Obviously you can't
install two services called
On 2013-05-23 10:19, Corinna Vinschen wrote:
On May 23 11:01, Christopher Faylor wrote:
For services, isn't there some other field besides just the name which
can be used as a delineator?
No. Every service needs a unique service name, otherwise you couldn't
manipulate services unambiguously.
On 2013-05-26 06:21, Ken Brown wrote:
D=http://sanibeltranquility.com/cygwin/release/TeX
TL=texlive
wget -x -nH --cut-dirs=2 \
${D}/${TL}/texlive-20120628-2.tar.bz2\
${D}/${TL}/texlive-20120628-2-src.tar.bz2\
${D}/${TL}/setup.hint\
${D}/${TL}/libkpathsea6/libkpathsea6-20120628-2.tar.b
On 2013-05-21 15:32, David Stacey wrote:
BASEURL=http://dl.dropbox.com/sh/7y1yn4whbyho9a7
wget --no-host-directories --force-directories --cut-dirs=5 \
${BASEURL}/UGu_bsP8XW/64bit/release/doxygen/doxygen-1.8.4-1-src.tar.bz2 \
${BASEURL}/ZRfN9VKFzW/64bit/release/doxygen/doxygen-1.8.4-1.tar.bz2 \
$
On 2013-05-20 12:08, David Stacey wrote:
BASEURL=http://dl.dropbox.com/sh/7y1yn4whbyho9a7
[snip]
Please delete 1.8.2-1 and leave 1.8.3.1-1 as previous.
Done and done.
Yaakov
On 2013-05-16 01:41, Steven Penny wrote:
Because of this dependency line
mintty
cygutils
desktop-file-utils
libglib2.0_0
python-gobject
python
A base Cygwin install now requires Python. Can this be changed? While Python is
a good language I hardly feel it is appropriate to a
On 2013-05-14 06:27, Corinna Vinschen wrote:
Er... what? Since when does syntax highlighting require perl?
Not directly: syntax highlighting requires files from vim-common, which
pulls in perl due to other perl scripts contained therein.
The old vim package I compiled when I maintained it
On 2013-05-14 05:19, Frank Fesevur wrote:
It overrides the symlink from vi to vim.exe and so this "breaks" my
current setup:
$ vi
Error detected while processing /home/Frank/.vimrc:
line1:
E319: Sorry, the command is not available in this version: syntax on
Press ENTER or type command to con
On 2013-05-14 15:13, marco atzeri wrote:
Il 5/14/2013 9:05 PM, Corinna Vinschen ha scritto:
I fear you might not like my answer: The problem here is NOT that the
linking works, the problem is that, if the configure test is used to
find out if we're running on Windows or not, it's simply not fea
On 2013-05-14 02:59, Corinna Vinschen wrote:
What bugs me with vim-minimal on Fedora is usually that it's lacking
basic vim functionality, even if it does not rely on external packages.
I'm not quite sure if I remember correctly, but in the past I think I
even had problems with color settings for
On 2013-05-12 19:24, Yaakov (Cygwin/X) wrote:
The following libraries are also currently available for the toolchain:
bzip2, cloog-isl, cloog-ppl, crypt, gettext, gmp, isl, libbfd, libffi,
libiconv, libmpc, libtool, minizip, mpfr, ppl, zlib.
I just added catgets, expat, jbigkit, libedit
As announced moments ago, I just moved ex/vi into a vim-minimal package,
compiled with the 'small' feature set and not dependent
on vim-common (hence nor perl). As these utilities are required by
POSIX[1], should the vim-minimal package be added to Base?
Yaakov
[1] http://pubs.opengroup.org/
On 2013-05-13 17:13, Warren Young wrote:
Is there work underway to make cygport understand how to generate 32-
and 64-bit packages at the same time? Or even a feature to do this
already?
Not yet.
Yaakov
I just uploaded a i686-pc-cygwin target cross-toolchain for the x86_64
distro together with over a dozen sysrooted libraries. All packages are
named with a cygwin32- prefix and are under the Devel category.
In order to use this toolchain, install at least cygwin32-gcc-{core,g++}
and all indic
On 2013-05-10 17:31, Yaakov (Cygwin/X) wrote:
The following libraries are also available for the toolchain:
bzip2, catgets, cloog-isl, cloog-ppl, crypt, db, e2fsprogs
(libcom_err/libss/etc.), expat, fontconfig, freetype2, gdbm, gettext,
gmp, gnutls, isl, libarchive, libbfd, libblkid, libedit
I just uploaded a x86_64-pc-cygwin target cross-toolchain for the i686
distro together with ~70 sysrooted libraries. All packages are named
with a cygwin64- prefix and are under the Devel category.
In order to use this toolchain, install at least
cygwin64-gcc-{core,g++}, as well as the *TEST*
On 2013-05-09 04:23, Achim Gratz wrote:
Yaakov (Cygwin/X) writes:
Could you add isl and cloog-isl to the i686 distro as well? They are
needed for the 32-to-64 cross-compiler which some maintainers need to
build their packages for x86_64.
These are all test packages built with gcc-4.7.2-2 and
Achim,
Could you add isl and cloog-isl to the i686 distro as well? They are
needed for the 32-to-64 cross-compiler which some maintainers need to
build their packages for x86_64.
Yaakov
On 2013-05-05 14:20, Achim Gratz wrote:
I guess Yaakov should upload in case something is still wrong….
I uploaded gmp/mpfr/mpclib/isl/ppl, but there were issues with the cloog
packages which I attempted to fix:
release/cloog-ppl/libcloog-ppl-devel/libcloog-ppl-devel-0.15.11-2.tar.bz2
I u
On 2013-05-04 09:11, marco atzeri wrote:
could you port intltool to 64 bit ?
Done.
Yaakov
On 2013-05-03 00:30, Achim Gratz wrote:
Yaakov (Cygwin/X) writes:
While the libmpc name makes more sense IMO, as we're already using
mpclib, you could stick with that. Only the source package uses this
name, so changing this now won't really affect anything.
Can't you simpl
On 2013-05-02 14:19, Achim Gratz wrote:
Yaakov (Cygwin/X) writes:
I would prefer that we stick with the naming used for the existing
64bit packages, which would not require a bunch of renamings on the
32bit side either.
You are asking for the impossible.
WRT Cygwin, I *specialize* in the
On 2013-05-02 08:34, Dr. Volker Zell wrote:
While packaging the 64bit version of Xfig and transfig I get the following
errors from cygport.
Stripping executables:
usr/bin/xfig.exe
/usr/share/cygport/lib/src_postinst.cygpart: line 860: [: too many arguments
/usr/share/cygport/lib/src_pos
On 2013-04-30 05:09, Dr. Volker Zell wrote:
Any chance to get 64bit versions of the Motif toolkit and imake.
Done.
Yaakov
On 2013-04-30 12:11, Achim Gratz wrote:
Yaakov (Cygwin/X) writes:
* libraries are libfooN (containing cygfoo-N.dll) and libfoo-devel
(containing headers, libfoo.*, .pc files, foo-config scripts, aclocal
macros, etc), regardless of source tarball name. Rationale: many
library sources already
On 2013-04-24 04:44, Dr. Volker Zell wrote:
64bit versions of 'ghostscript/libgs9/libgs-devel' have been uploaded to a
server near you.
o Build for cygwin 1.7.19 with gcc-4.8.0
o This version is missing libpaper support
libpaper is now in 64bit/release.
Yaakov
On 2013-04-29 13:14, Dr. Volker Zell wrote:
aspell compilation gives the following error during linking. Any ideas ?
_fileno is an MSVC-ism; use fileno instead. This used to work (despite
the compiler warning) because cygwin.def exports underscored variants
for many POSIX functions unnecessa
On 2013-04-29 13:55, Achim Gratz wrote:
Hi Yaakov,
would you mind letting me know how to repackage so I can free some time
to actually do it? Otherwise, please install as described in my
original mail, thank you.
Sorry, I've been on the road for much of the last week. Here are some
of the r
101 - 200 of 1060 matches
Mail list logo
