On 2/12/2014 7:45 AM, Pavel Fedin wrote:
This is me again, and this is my promised RPC package. Folder URL:
https://www.dropbox.com/sh/s95jz1ql5xs8yx7/8mhUDlI_Kg
I have updated the whole thing using recent source code. Translations
included. I hope you'll like the result.
One small question
On 2/6/2014 12:46 AM, Pavel Fedin wrote:
I'd be happy to hand off rpcgen. All it would take is a coordinated
upload, once Pavel's combined package is ready.
Good. I think we can safely experiment on x86-64 version. On i386
this new package would conflict with old sunrpc, however sunrpc
> cont
On 2/5/2014 4:19 AM, Corinna Vinschen wrote:
On Feb 5 10:39, Pavel Fedin wrote:
Hello!
Presumably you could find some public cloud with free storage space - I
use Dropbox, but I'm sure there are plenty of others.
https://www.dropbox.com/sh/s95jz1ql5xs8yx7/8mhUDlI_Kg
However, before add
On 11/20/2013 8:28 AM, Corinna Vinschen wrote:
Apart from the fact that it would be nice if our linker would do this
automatically and transparently,
Or libtool, if you use it to link your exe? PTC...since $new-libtool is
pretty high on my to-do list.
It'd be better if there was an option t
is now available. However, neither the servers nor the clients have been
well tested...so report any problems (that didn't already show up in
32bit cygwin with inetutils-1.7-2) to the main list.
--
Chuck
On 11/13/2013 7:05 AM, Corinna Vinschen wrote:
libproj-devel libproj0
proj libproj0
I think these dependencies are deliberate, to cover the older 4.5.0a-2
version. Chuck? Shouldn't they go away in favor of libproj1 only?
Yep. Fixed on sware (32bit only, as I
On 11/4/2013 7:22 AM, marco atzeri wrote:
Hi George,
unfortunately the nfs-server is without a package maintainer
http://cygwin.com/cygwin-pkg-maint
Yes, but the patch is actually for sunrpc, of which I am (nominally)
listed as the maintainer. There's an issue with sunrpc in general (I'll
ha
On 9/10/2013 1:50 PM, Christopher Faylor wrote:
upset's version normalizer considers (not unreasonably I think)
4-1.4p6-11 to be the same as 4-1.4-p6-11. So, having both files in the
same directory is going to confuse things.
Yaakov explained downthread how this came about. I /did/ notice tha
On 8/12/2013 11:45 AM, Corinna Vinschen wrote:
On Aug 12 11:29, Christopher Faylor wrote:
On Mon, Aug 12, 2013 at 01:16:33PM +0200, Corinna Vinschen wrote:
On Aug 12 07:10, Ken Brown wrote:
Maybe I jumped to an incorrect conclusion, but that (and earlier
instances of the same problem) made me
automake (wrapper)9-1
automake1.14 1.14-1
automake1.13 1.13.4-1
automake1.12 1.12.6-2
automake1.11 1.11.6-2
automake1.10 1.10.3-2
automake1.9
st is also available online at http://cygwin.com/cygwin-64bit-missing.
I'll keep it up-to-date as new packages arrive.
ORPHANED
editrights
Really? it's in the cygwin-apps repository; I thought *you* were the
maintainer.
Charles Wilson
automake1.5
automake1.6
On 8/1/2013 5:18 AM, Corinna Vinschen wrote:
Btw., I just built and uploaded the tftp package for x86_64.
For some reason, even though inetutils is built without tftp
and tftpd support, it still needs the arp/tftp.h file provided
by the tftp package.
stock inetutils assumes that tftp.h is provi
The following packages are now available for cygwin64:
mingw-gcc-4.7.3-1
mingw-gcc-core
mingw-gcc-g++
mingw-gcc-fortran
mingw-gcc-objc
mingw-gcc-ada
mingw-binutils-2.23.1-1
mingw-w32api-4.0-1
On 7/16/2013 2:59 PM, Christopher Faylor wrote:
On Tue, Jul 16, 2013 at 08:50:08PM +0200, Corinna Vinschen wrote:
The former setup64 doesn't complain, but I don't think this is a setup
problem. Rather, it's a difference between the generated ini files.
The old setup64.ini was only generated by
On 7/17/2013 10:21 AM, Christopher Faylor wrote:
If you want to keep parity with upset, then only arch is filled out
automatically. If there is no --release then that field doesn't show
up in the generated ini file.
With that change, feel free to checkin.
done.
--
Chuck
I just uploaded some new packages to the 64bit area. Do I still need to
run GEN-sware, or is x86_64 upset-enabled now?
--
Chuck
On 7/17/2013 9:48 AM, Corinna Vinschen wrote:
On Jul 17 09:26, Charles Wilson wrote:
so it's not like it could coexist with a future libexpat2-devel. I
think the "libexpat1-devel" name in 2.1.0-2 is a mistake, and it
expat should be repackaged to use "traditional" na
On 7/17/2013 4:30 AM, Corinna Vinschen wrote:
On Jul 16 17:25, Ken Brown wrote:
1. The x86_64 distro has both libexpat1-devel and libexpat-devel,
with the files of the latter being a subset of those of the former.
In addition, libexpat1-devel is missing a setup.hint, so it is put
into the Misc c
On 7/16/2013 8:28 PM, Ken Brown wrote:
On 7/16/2013 6:23 PM, Charles Wilson wrote:
@@ -277,6 +289,9 @@ Create cygwin setup.ini from setup.ini,
missing tarballs. --okmissing=source is
useful for
LOCAL-ONLY[*] srcless install media
On 7/15/2013 2:58 PM, Christopher Faylor wrote:
On Mon, Jul 15, 2013 at 02:32:24PM -0400, Charles Wilson wrote:
What changes did you have to make to upset, to teach it about the new
format? I'd like to replicate those changes in genini...
http://cygwin.com/cgi-bin/cvsweb.cgi/~che
On 7/15/2013 1:05 PM, Christopher Faylor wrote:
The setup.ini's used by these two new programs are not
backwards-compatible with old setup.exe.
What changes did you have to make to upset, to teach it about the new
format? I'd like to replicate those changes in genini...
http://cygwi
On 7/10/2013 2:11 AM, Fedin Pavel wrote:
Hello! I've just stumbled accross a bug in Automake v1.9 package. I was
trying to regenerate files in a source tree which sets automake version to
1.9. 'automake -icf' has copied files, but config.guess bundled with this
version of automake appears to no
I've updated the following 64bit packages:
autoconf-13-1 (wrapper)
autoconf2.1-2.13-12
autoconf2.5-2.69-2
See the 32bit announcement(s) for details.
--
Chuck
On 7/3/2013 12:04 PM, Achim Gratz wrote:
Yaakov (Cygwin/X) writes:
I can't test it myself at the moment, but I believe that mingw-gcc is
now broken due to its dependency on libmpc1. As a stopgap measure we
could provide a libmpc1 package that copies libmpc3, otherwise a new
mingw-gcc would ha
On 7/3/2013 4:34 AM, Corinna Vinschen wrote:
cwilson:
csih
csih/csih-debuginfo
jbigkit
run
run/run-debuginfo
done.
The libXpm-noX packages provide a version of the X.Org XPM image format
library that do NOT require the use of an X server. This library
can be used to read, process, and save XPM images, but all display
code has been removed, because that requires X. It is useful for
applications that need to m
On 6/2/2013 11:02 AM, Ken Brown wrote:
Could we get a 64bit build of libXpm-noX when you get a chance? It
would be useful for emacs-w32.
Done.
--
Chuck
On 6/28/2013 12:05 PM, Charles Wilson wrote:
Who updated p7zip from 9.20.1-1 to 9.20.1-2 (32bit), and why? (Also, I
don't see an announcement on cygwin-announce).
Never mind; false alarm. I forgot I had cygwin-ports hooked into my
cygwin 32 bit install.
--
Chuck
Who updated p7zip from 9.20.1-1 to 9.20.1-2 (32bit), and why? (Also, I
don't see an announcement on cygwin-announce).
--
Chuck
The run2 package provides two utilities: 'run2' and 'checkX' (as
the package is actually a renamed and updated successor to the
now-obsoleted checkx package). The first utility is a more powerful
replacement for the venerable 'run' utility that has long been a
part of the cygwin distribution. The
ustr (Micro string library) is a string API for C. It has tiny overhead
over just plain strdup(), is much safer, is easier to use, is faster
for many operations, and can be used with read-only or automatically
allocated data. You don't even need to link to the library to use it
(so there are no de
On 6/12/2013 3:47 PM, Corinna Vinschen wrote:
Btw., any chance you could have a look into a 64 bit inetutils? :}
Oh, ouch. That's going to be miserable, assuming I do full testing of
the included servers and clients. For this reason, it was on the very
END of my TODO list.
Or...I could just
On 6/12/2013 10:50 PM, Yaakov (Cygwin/X) wrote:
On 2013-06-12 14:08, Charles Wilson wrote:
However, in actuality, neither Bruno's "gettext-runtime" (our gettext)
nor his "gettext-tools" (our gettext-devel) really represent a
"traditional" runtime-vs-devel spli
On 6/12/2013 11:13 AM, Corinna Vinschen wrote:
I was just trying to build a package on a new 64 bit Cygwin test
machine, when I encountered a missing libintl.h. As it turned out,
I had gettext-devel installed, but not gettext. In the 64 bit version
of gettext, gettext-devel depends on libintl8,
On 6/11/2013 10:10 AM, Warren Young wrote:
On 6/11/2013 01:37, marco atzeri wrote:
you should make it test adding the relevant
prev/current/test entries as specified on
http://cygwin.com/setup.html
Is there a way to set this via the .cygport file? I tried searching its
HTML manual, and did
On 6/9/2013 7:01 AM, JonY wrote:
Care to put up 2.4.2? It's been out for some time now.
It will take some time, but yes. That'll be on the queue right after
run2 and libXpm-noX (and perhaps another 'run' b/c...well, JobQueues.
See upcoming post on main list).
--
Chuck
for mingw64 (32bit,64bit) as well as mingw.org compilers.
--
Charles Wilson
volunteer run maintainer for cygwin
On 5/23/2013 4:22 AM, Corinna Vinschen wrote:
is there a chance we can get a 64 bit "run" package any time soon?
It's required for starting X from the start menu...
Sure, I'll work on that and run2 tonight.
--
Chuck
On 5/14/2013 3:05 PM, Corinna Vinschen wrote:
I fear you might not like my answer: The problem here is NOT that the
linking works, the problem is that, if the configure test is used to
find out if we're running on Windows or not, it's simply not feasible
anymore when taking x86_64 Cygwin into ac
/Makefile.gcc
* First 64bit build
* Added debuginfo package
--
Charles Wilson
volunteer zlib maintainer for cygwin
Which utilities need this?
mkshortcut and lpr, probably. Any others?
--
Charles Wilson
volunteer cygutils maintainer for cygwin
es
* Added debuginfo package
* First 64bit build
--
Charles Wilson
volunteer jbigkit maintainer for cygwin
On 4/24/2013 4:34 AM, Corinna Vinschen wrote:
On Apr 24 00:52, Charles Wilson wrote:
Why would simply shortening the PATH have this effect?
Do you have a big environment? Thre's a chance that the stack address
moves due to that.
$ printenv | wc
65 1162418
$ echo $PATH
On 4/13/2013 11:45 PM, Yaakov (Cygwin/X) wrote:
On 2013-04-13 00:55, Andy Koppe wrote:
I've also tried installing cygport from git master but got this after
running ./autogen.sh && make:
make: *** No rule to make target `data/gnuconfig/config.guess', needed
by `all-am'. Stop.
This is one qui
On 4/23/2013 4:21 AM, Corinna Vinschen wrote:
On Apr 23 06:55, Dr. Volker Zell wrote:
I need help compiling ghostscript for 64 bit. The configure script doesn't
recognize libtiff somehow. Any ideas ?
Yes. libtiff-3.9.7-2 is apparently 32 bit:
$ file /bin/cygtiff-5.dll
/bin/cygtiff-5.dl
On 4/11/2013 6:37 PM, Yaakov (Cygwin/X) wrote:
No, cygport(1) doesn't generate README content.
Too bad. Well, maintaining the READMEs in my local git repo
side-by-side with the cygport(5) is not that big a deal -- especially
with the other cygport(1) improvements, incl #3 below.
#2) Is it
On 4/11/2013 6:08 PM, Yaakov (Cygwin/X) wrote:
It does mean that Win32API (or X11, for that matter) headers must be
#include'd before . Before I spin a new release, could you
test if this works with emacs?
Would this problem go away if we switched to jpeg-turbo?
--
Chuck
On 4/11/2013 2:58 AM, Yaakov (Cygwin/X) wrote:
Something else you missed: cygport supports a new, unversioned file
format, and creates setup.hint files, including dependency detection. I
suggest using git master right now.
I know that cygwin-specific READMEs are now no longer required or
expe
On 4/10/2013 4:03 AM, Yaakov (Cygwin/X) wrote:
The libjpeg-turbo project provides SIMD acceleration while remaining API
and ABI compatible with IJG libjpeg 6b/7/8 (based on configure flags). I
have been using this libjpeg8 locally instead of the IJG one from the
distro for some time, and have see
On 3/17/2013 12:45 PM, Christopher Faylor wrote:
1) Do you have a 64-bit version of Windows available?
2) If no, would you be willing to install one?
3) Are you willing to download the current 64-bit Cygwin and start porting
your stuff, knowing that there are still bugs?
4) Or, would you rathe
On 4/7/2013 12:21 AM, Charles Wilson wrote:
On 4/5/2013 10:15 AM, Corinna Vinschen wrote:
Chuck, editrights was the last dependency missing for csih. Would you
mind to build a new package? I was going to just copy it over from the
32 bit release area, but then it occured to me that it isn&#
On 4/7/2013 7:11 AM, Achim Gratz wrote:
I've just set up a Cygwin64 system. It seems I can run a 32bit Cygwin
in parallel without disturbing anything, is that right?
FYI, unless I've misinterpreted, I think you need to use git master
cygport to build "natively" in cygwin64. If you're cross-
On 4/7/2013 5:47 AM, JonY wrote:
For now, I intend to push it to 64bit Cygwin only, once gcc 4.7 for the
32bit cygwin hits release, I will push it there too.
There are some files in the package that replaces
e.g. "conflict with"
some of the
mingw-w64-headers CRT headers, this is done on purp
On 4/5/2013 10:15 AM, Corinna Vinschen wrote:
Chuck, editrights was the last dependency missing for csih. Would you
mind to build a new package? I was going to just copy it over from the
32 bit release area, but then it occured to me that it isn't just a script,
but contains binaries as well...
On 11/23/2012 9:22 AM, Corinna Vinschen wrote:
Chuck, are you still with us?
There's also the request to update autoconf to the latest 2.69
version: http://cygwin.com/ml/cygwin/2012-11/msg00164.html
On Nov 16 04:39, Yaakov (Cygwin/X) wrote:
On Wed, 2012-10-17 at 11:07 -0500, Yaakov (Cygwin/X
On 8/21/2012 10:17 PM, James Zern wrote:
libwebp's [1] configure script [2] does a simple check for -ltiff,
this will succeed, but the build will fail due to the missing library.
Corrected on sourceware; next release of libtiff will include this
change organically. Thanks for the heads up.
On 8/21/2012 3:17 PM, Yaakov (Cygwin/X) wrote:
Chuck, for someone who hates flag days with a passion[1], you have most
ironically forced one upon us without warning. Please rectify that by
restoring libpng14-devel (with 1.4-versioned files only, of course) ASAP.
Actually, I was just following y
On 6/1/2012 6:36 AM, Corinna Vinschen wrote:
> On Jun 1 12:20, Corinna Vinschen wrote:
>> On Jun 1 02:45, Yaakov (Cygwin/X) wrote:
>>> Fedora has switched from the i686-pc-mingw32 toolchain to the
>>> {i686,x86_64}-w64-mingw32 toolchains in F17. This means that setup
>>> cannot currently be buil
On 5/14/2012 1:32 AM, Yaakov (Cygwin/X) wrote:
> On 2012-05-14 00:31, upset lived up to its name and complained:
>> upset: *** setup.ini: warning - package minizip requires non-existent
>> package libgcc_1
>
> I made the obvious fix on sourceware; please fix your local copy, etc.
Thanks (and sorr
On 5/10/2012 10:55 PM, Yaakov (Cygwin/X) wrote:
Right; sourceware.org:/cvs/src is funny that way. AFAIK it is the only
time I have seen that with CVS, but do other exceptions exist?
libgeotiff. This is related to one of the patches I had proposed long
ago, but eventually withdrew. However, m
On 5/4/2012 8:21 PM, Yaakov (Cygwin/X) wrote:
I have sent notices of multiple security vulnerabilities in libpng going
back LAST JULY, with several additions and pings (no pun intended)
since. Can we *please* see some sign that you are still maintaining
these packages?
I wanted to roll out the
On 3/25/2012 2:40 AM, Yaakov (Cygwin/X) wrote:
> On 2012-03-24 22:12, Yaakov Selkowitz wrote:
>> Chuck,
>>
>> In the last few weeks I have seen a few packages which require
>> automake-1.11.2. Any chance you could update this soon?
>
> Actually, make that 1.11.3.
>
>> Oh, and ping on the libpng s
On 3/15/2012 11:55 PM, Christopher Faylor wrote:
> On Thu, Mar 15, 2012 at 10:30:45PM -0500, Yaakov (Cygwin/X) wrote:
>> libtool, while very commonly used, is the only major build system which
>> creates both shared and static versions of every library by default.
>> With the notable exceptions o
On 3/13/2012 10:00 AM, Corinna Vinschen wrote:
> - Either keep the files in /usr/{include,lib,lib64}/w32api, which requires
> to duplicate the files as it is done today,
I don't think it's THAT big a burden for (Chris S.|Joy Y.) to create two
different packages for (mingw32|mingw64-platform). B
On 2/27/2012 11:07 AM, marco atzeri wrote:
> Thanks for status,
> I was just wondering why most of the dependencies
> where present but a bit old.
Yep -- since the only thing those deps are actually used for, it seems,
is gnupg-2.x, I haven't been keeping them up to date without an actual
gnupg-2.
On 2/27/2012 5:51 AM, Yaakov (Cygwin/X) wrote:
> TeX Live also replaces psutils, listed as maintained by Daniel
> Boesswetter. AFACIS he hasn't posted to these lists since November
> 2003, so I think it's fair to say that it's been orphaned.
Is it possible to package this part in such a way that
On 2/26/2012 3:02 AM, marco atzeri wrote:
> All versions of libpng from 1.0.6 through 1.5.8, 1.4.8, 1.2.46, and
> 1.0.56, respectively, fail to correctly validate a heap allocation in
> png_decompress_chunk(), which can lead to a buffer-overrun and the
> possibility of execution of hostile code on
On 2/27/2012 8:56 AM, marco atzeri wrote:
> I will give a look.
> Any preference between 1.4.12 and 2.0.18 ?
I made an attempt about two years ago to port gnupg 2.x. It has
additional dependencies beyond those of 1.4.x, so I added all of those
to the distro.
However, I ran into a problem (relate
On 2/6/2012 11:49 AM, Eric Blake wrote:
I've uploaded coreutils-8.15-1 as a test release; I can kick it over to
current once you've got a cygutils release to match.
cygutils-1.4.8-1 is uploaded as a test release.
* Integrate cygstart with FD.o menu and mimetype system.
(Yaakov Selkowitz)
* Re
On 2/6/2012 6:30 AM, Corinna Vinschen wrote:
6.2 is correct. Have a look into dump_sysinfo() in utils/cygcheck.cc.
It's updated to the latest known state when the W8 test release became
available.
Ah, thanks. I looked at wincap.cc and didn't see anything there, so...
--
Chuck
On 2/6/2012 6:25 AM, Corinna Vinschen wrote:
On Feb 5 15:23, Charles Wilson wrote:
How's this? (BTW, we do similar stuff in
csih_create_privileged_user() but I didn't address that).
That looks ok to me. As for csih_create_privileged_user, I don't see
what you mean. In th
Call for assistance: can somebody with access to Windows 8 provide an
appropriate tested patch so that winProductName can recognize Windows 8
(various flavors, including Windows Server 8)?
Getting the System Version
http://msdn.microsoft.com/en-us/library/ms724429%28v=vs.85%29.aspx
has not bee
On 1/30/2012 7:01 PM, Charles Wilson wrote:
On 1/30/2012 3:32 PM, Eric Blake wrote:
In particular, it is much more powerful than the realpath(1) currently
offered by cygutils. Should I build my next coreutils package with
realpath included, and wait to upload it until we can coordinate a build
On 1/16/2012 5:14 AM, Corinna Vinschen wrote:
Chuck? Ping?
How's this? (BTW, we do similar stuff in csih_create_privileged_user()
but I didn't address that).
Index: cygwin-service-installation-helper.sh
===
RCS file: /cvs/c
On 1/30/2012 8:50 PM, Yaakov (Cygwin/X) wrote:
While you're at it, what about ascii(1)?
http://cygwin.com/ml/cygwin-apps/2011-10/msg00113.html
Nobody ever responded to my comments at the end of that thread, so it
kinda went into limbo.
Given two +1 votes (your own and Christian Franke's) i'
On 2/4/2012 3:55 AM, Jari Aalto wrote:
checkbashisms script has been included in Debian since 200x (don't know
exatly; its git log starts in 2007). It's part of the devsripts in Debian.
To check build:
tar -xf check*.bz2
./check*.sh --color --verbose all
We're not debian, and don't ex
On 1/30/2012 3:32 PM, Eric Blake wrote:
> In particular, it is much more powerful than the realpath(1) currently
> offered by cygutils. Should I build my next coreutils package with
> realpath included, and wait to upload it until we can coordinate a build
> with cygutils dropping the weaker varia
On 12/17/2011 11:35 PM, JonY wrote:
New mingw-w64 build is ready. Remove the oldest in each category, leave
pthreads.
Done.
--
Chuck
On 12/4/2011 10:03 PM, Yaakov (Cygwin/X) wrote:
On Sun, 2011-12-04 at 21:05 -0500, Charles Wilson wrote:
I found this while building (msys) versions of tcl and tk, (loosely)
based on your cygports. However...I modified tk's configure.in to do a
"proper" AC_INIT. So
On 12/4/2011 7:33 PM, Yaakov (Cygwin/X) wrote:
On Sat, 2011-12-03 at 18:45 -0500, Charles Wilson wrote:
Yaakov -- the installed tclConfig.sh and tkConfig.sh files include stuff
like this:
TCL_DEFS='-DPACKAGE_NAME=\"tcl\" -DPACKAGE_TARNAME=\"tcl\"
-DPACKAGE_VERSION
Yaakov -- the installed tclConfig.sh and tkConfig.sh files include stuff
like this:
TCL_DEFS='-DPACKAGE_NAME=\"tcl\" -DPACKAGE_TARNAME=\"tcl\"
-DPACKAGE_VERSION=\"8.5\" -DPACKAGE_STRING=\"tcl\ 8.5\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1
This causes warnings (PACKA
On 11/9/2011 5:00 AM, Jussi Kantola wrote:
AstroTortilla is fine with a custom repo. All we ever wanted was to
be able to install astrometry.net with Cygwin's setup.exe
OK.
How many
would we need for it to be considered significant enough?
No idea.
Is this document still valid?
http://so
On 11/7/2011 11:17 AM, Christopher Faylor wrote:
I've been trying not to offer an opinion here but it isn't clear to me
why so many people voted +1 for this package. It seems like we're
adding a huge package
Meh, if you exclude the star catalogs (and I think we should; and the OP
has agreed t
On 11/7/2011 8:18 AM, Jussi Kantola wrote:
> On Fri, Nov 4, 2011 at 11:13 PM, Charles Wilson wrote:
>> You should probably do that, to ensure that the build procedure works on
>> your machine. Also, to test the resuts; I have no idea how to use this
>> stuff.
>
> It bui
On 11/4/2011 2:29 AM, Charles Wilson wrote:
Your build still links against libbackend.a, rather than cygbackend.dll.
I'm trying to massage your -src package to DTRT. Stay tuned.
I've posted a revised version of your package here:
http://cygwin.cwilson.fastmail.fm/astrometry.
On 11/4/2011 11:11 AM, Yaakov (Cygwin/X) wrote:
software is quite unpolished.
From reading the web page, it appears to be a research project by a
couple of grad students -- with goals of supporting amateur and even
professional astronomers by automating what is currently a
labor-intensive ta
On 10/7/2011 12:18 PM, Jussi Kantola wrote:
However I had to modify backend-main.c so that the config file (which
defines the location of index files)
could be read from cygwin's preferred location,
/usr/share/astrometry/etc/backend.cfg.
That's a little odd, and I don't think that's exactly wha
On 11/3/2011 8:02 AM, Corinna Vinschen wrote:
I hoped that somebody who voted on the package would do the final
GTG, but in vain it seems.
Sorry...I had intended to, but got swamped with other stuff. :-(
Anyway, I just had a look. The packaging now looks basically good. One
issue I still ha
On 10/31/2011 7:39 PM, Charles Wilson wrote:
On 10/30/2011 8:44 PM, Yaakov (Cygwin/X) wrote:
Please don't.
...
This is just the beginning. Mixing GDI and X11 just doesn't work, and
since X11 is used for all other GUIs on Cygwin, so must Tk.
My suggestion, for those who wanted th
On 10/30/2011 8:26 PM, Yaakov (Cygwin/X) wrote:
ESR maintains a standalone ascii(1) which appears to have more features
than cygutils':
http://catb.org/~esr/ascii/
Should we replace this? Patch attached if so.
Well, I have mixed feelings. On the PRO side:
1) smaller cygutils == fewer heada
On 10/30/2011 8:44 PM, Yaakov (Cygwin/X) wrote:
Please don't.
...
This is just the beginning. Mixing GDI and X11 just doesn't work, and
since X11 is used for all other GUIs on Cygwin, so must Tk.
My suggestion, for those who wanted this, was to build the entire
tcl/tk(GDI) "stack" with a un
On 10/25/2011 10:46 PM, Yaakov (Cygwin/X) wrote:
The attached patch and new files integrate cygstart into the
Freedesktop.org desktop menu system. This allows Windows-specific files
(e.g. .exe, .com, .bat, .msi, .themepack) to be easily opened by
cygstart from within FD.o/X file managers (e.g. N
On 10/25/2011 10:30 PM, Yaakov (Cygwin/X) wrote:
libtool2 uses several aclocal macros, and libtoolize copies them into
m4/ automatically. Patch attached.
Applied. Thanks (wow, that bug has been there a while. I usually have
ignored bootstrap and simply run autoreconf, so I never noticed.)
On 10/26/2011 5:53 PM, Cary R. wrote:
> If I'm understanding this correctly once this change has been
> pushed we will be required to start an X server beforerunning
> gitk.
Yes.
> As someone who uses git and gitk all the time having to
> start the X server to run gitk is a pain. I haven't checke
On 10/4/2011 4:02 AM, Jussi Kantola wrote:
> category: Science
> requires: cairo libcairo2 python-cairo libnetpbm10 netpbm libpng14
> libjpeg8 zlib zlib0 python python-numpy pkg-config cygwin
> sdesc:"Astrometry.net astrometrical solver."
> ldesc:"Astrometry.net analyses an astronomical im
On 9/30/2011 6:00 AM, Andrew Schulman wrote:
>> I'd like to package and maintain nosleep for Cygwin. nosleep runs a
>> command while inhibiting the computer from sleeping or hibernating until
>> the command finishes executing.
>
> Thanks for voting everyone. Would someone now please review the p
On 9/25/2011 6:15 AM, Andrew Schulman wrote:
> nosleep has been written originally for Cygwin, so it's not available in
> any Linux distros and needs to be voted on.
+1
--
Chuck
On 9/23/2011 11:11 AM, Jason Tishler wrote:
> I'm about to commit the following patch:
>
> http://www.tishler.net/jason/software/rebase/rebase.patch
>
> Any comments before I do so?
Looks fine to me.
> Additionally, are there any conventions I should following when I tag
> the release?
"."
On 9/20/2011 9:27 AM, JonY wrote:
> This update is to fix a typo in the gcc configure command that went long
> unnoticed, now with --enable-dynamic-string.
> Anybody using C++ libraries are encouraged to recompile.
>
> Keep previous versions, thanks.
Done.
--
Chuck
On 9/20/2011 11:24 AM, Jason Tishler wrote:
> On Mon, Sep 19, 2011 at 02:53:54PM -0400, Charles Wilson wrote:
>> After the flurry of work and new features added to rebase in late
>> July/early August, any chance you could bump the version and roll a
>> new release?
>
1 - 100 of 1418 matches
Mail list logo
