On 7/15/2010 1:50 PM, Yaakov (Cygwin/X) wrote:
As promised, here is my response to the mingw-w64 ITP.
cygport now supports several scenarios:
1) Cygwin-hosted (cross-)compilers, via toolchain.cygclass
This is exclusively for binutils, gcc, and gdb, either Cygwin-native or
any other
On 7/19/2010 4:51 AM, JonY wrote:
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/gendef/gendef-20100719-1-src.tar.bz2/download
https://sourceforge.net/projects/mingw-w64/files/Cygwin%20Snapshots/dist/gendef/libmangle-devel/libmangle-devel-20100719-1.tar.bz2/download
On 7/19/2010 2:23 PM, Charles Wilson wrote:
I tried to figure out get just the source you need via 'inherit svn'
-- but had to give up, since you want two *separate* subdirectories of
the top-level (mingw-w64-tools and mingw-w64-libraries), and perhaps
the top-level files, but you wouldn't
On 7/19/2010 9:43 PM, JonY wrote:
OK, I've tried the inherit svn method to separate both, and here are the
results:
gendef:
category: Devel
requires: libgcc1
sdesc: Generates exports definitions by analyzing executables.
^^^
On 7/19/2010 9:49 PM, Yaakov (Cygwin/X) wrote:
On Sat, 2010-07-17 at 16:26 -0400, Charles Wilson wrote:
I'll address issues with libtool/pkgconfig at that
time, as well (short version: our version of pkgconfig claims to support
sysroot via $PKG_CONFIG_SYSROOT_DIR, but newer versions have
On 7/19/2010 9:55 PM, JonY wrote:
With NLS you will still have at least partial translations, which is
better than nothing, no?
How about setting up --with-localedir to somewhere version or target
specific?
There isn't a '--with-localedir' option. But...there IS a --localedir
one. How
On 7/19/2010 9:49 PM, Yaakov (Cygwin/X) wrote:
On Sat, 2010-07-17 at 16:26 -0400, Charles Wilson wrote:
The following flags are used in the official mingw compiler, but not here:
--enable-shared (but that's okay, as it is default)
--enable-libgomp
AFAIK --enable-shared
On 7/20/2010 9:55 AM, Dave Korn wrote:
On 20/07/2010 05:53, Charles Wilson wrote:
But at SOME point, SOME part of what you've built on $host is supposed
to be used, eventually, by somebody, on $target, right?
Where should THAT live?
On the target?
I meant, *in what directory
On 7/20/2010 9:37 AM, Dave Korn wrote:
On 20/07/2010 06:26, Charles Wilson wrote:
On 7/19/2010 9:55 PM, JonY wrote:
With NLS you will still have at least partial translations, which is
better than nothing, no?
How about setting up --with-localedir to somewhere version or target
specific
On 7/15/2010 5:27 PM, Yaakov (Cygwin/X) wrote:
My test case for the mingw toolchain is, of course, setup.exe. I have
uploaded test builds of all mingw-* prereqs here:
ftp://ftp.cygwinports.org/pub/cygwinports/temp/MinGW/
setup-gcc45.patch contains the changes necessary to compile and link
On 7/20/2010 8:46 PM, Yaakov (Cygwin/X) wrote:
On Tue, 2010-07-20 at 10:51 -0400, Charles Wilson wrote:
Well, I guess the replacement package for the gcc(3)-mingw stuff can
just create symlinks:
/usr/lib/mingw - /usr/i686-pc-mingw32/sys-root/mingw/lib
/usr/include/mingw - /usr
On 7/23/2010 1:54 AM, Yaakov (Cygwin/X) wrote:
On Thu, 2010-07-22 at 22:41 -0400, Charles Wilson wrote:
OK, so the libtool stuff is still percolating. Paolo just posted his
patch series earlier today, so I haven't had a chance to test it out
yet. However, it APPEARS after a cursory glance
On 7/19/2010 9:49 PM, Yaakov (Cygwin/X) wrote:
On Sat, 2010-07-17 at 16:26 -0400, Charles Wilson wrote:
[linux toolchain]
I don't think either of these two lines belong in the cygport:
mv ${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/lib/libgcc_s.a
${D}/usr/lib/gcc/${TOOLCHAIN_TARGET}/${PV[1
On 7/24/2010 12:32 AM, Charles Wilson wrote:
On 7/19/2010 9:49 PM, Yaakov (Cygwin/X) wrote:
On Sat, 2010-07-17 at 16:26 -0400, Charles Wilson wrote:
[linux toolchain]
I'll try again, only this time using *your* linux-gcc pre-compiled
compiler package.
Same problem. Using Yaakov's latest
On 7/25/2010 2:00 AM, Yaakov (Cygwin/X) wrote:
On Sat, 2010-07-24 at 10:34 -0400, Charles Wilson wrote:
Same problem. Using Yaakov's latest pre-built linux cross compiler, and
the latest linux-glibc src package, I attempted to rebuild.
First I had the same problem where -jN was too aggressive
On 7/22/2010 8:47 PM, Yaakov (Cygwin/X) wrote:
On Tue, 2010-07-20 at 00:53 -0400, Charles Wilson wrote:
Why shouldn't cygport allow that?
Thinking about this further, I think the problem is that we're talking
about two entirely different use cases:
1) cross-compiling a package to install
On 7/25/2010 5:01 AM, Yaakov (Cygwin/X) wrote:
On Sat, 2010-07-24 at 00:26 -0400, Charles Wilson wrote:
What does gentoo do with cross compilers and sysroots? I know
ebuild/emerge supports them; do they treat them strictly as support for
cross compiles, or as installable images
On 7/26/2010 5:29 PM, Christopher Faylor wrote:
I'm not sure what the intent of the tilde in the name above was but
upset liked it and setup.exe didn't. I changed it to a '-' instead.
I'm not sure if I should modify upset or setup to deal with this. I
don't see any real need to have tildes in
On 7/26/2010 7:48 PM, JonY wrote:
its due in part to cygport's inherit svn template.
Not exactly.
IMHO either cygport shpuld be fixed to use - instead of ~ or setup
should be fixed to handle ~ in filenames.
setup uses whatever you use when you name the .cygport file.
I did this:
mv
On 7/27/2010 5:18 AM, Yaakov (Cygwin/X) wrote:
* with cross.cygclass, configure now uses --prefix=$sysroot$prefix
because of recently discussed issues with libtool and *-config scripts;
From Paolo's most recent version of his patches to provide sysroot
support in libtool:
On 7/28/2010 11:22 PM, Yaakov (Cygwin/X) wrote:
On Wed, 2010-07-28 at 19:28 -0400, Charles Wilson wrote:
From Paolo's most recent version of his patches to provide sysroot
support in libtool:
http://www.mail-archive.com/libtool-patches-mXXj517/z...@public.gmane.org/msg05556.html
[RFT PATCH
On 7/29/2010 3:21 AM, Peter A. Castro wrote:
Greetings,
A newish upstream version of zsh (and a test version) has been released.
Please upload:
Done. I added the following to the setup.hint:
curr: 4.3.10-1
test: 4.3.10dev2-1
prev: 4.3.9-1
On 7/30/2010 7:43 AM, Chris Sutcliffe wrote:
Please upload:
---
wget -x -nH --cut-dirs=1 \
http://emergedesktop.org/cygwin/googlecl/googlecl-0.9.9-1.tar.bz2 \
http://emergedesktop.org/cygwin/googlecl/googlecl-0.9.9-1-src.tar.bz2
Done.
--
Chuck
On 8/1/2010 1:56 AM, Chris Sutcliffe wrote:
Please upload:
---
wget -x -nH --cut-dirs=1 \
http://emergedesktop.org/cygwin/python-gdata/python-gdata-2.0.11-1.tar.bz2
\
http://emergedesktop.org/cygwin/python-gdata/python-gdata-2.0.11-1-src.tar.bz2
done.
--
Chuck
On 8/1/2010 7:25 AM, Reini Urban wrote:
I indent to maintain a new package rakudo-star,
which is a small addon to rakudo (aka perl6 on parrot).
387KB binary, 5MB src
Since I'm the first (in close contact with the developers) I need 5 votes.
The other distros: slackware and fedora are almost
On 8/1/2010 8:31 AM, Charles Wilson wrote:
On 7/29/2010 3:21 AM, Peter A. Castro wrote:
Greetings,
A newish upstream version of zsh (and a test version) has been released.
Please upload:
Done. I added the following to the setup.hint:
curr: 4.3.10-1
test: 4.3.10dev2-1
prev: 4.3.9-1
On 8/5/2010 3:09 PM, Chris Sutcliffe wrote:
libtool: link: warning: undefined symbols not allowed in
i686-pc-cygwin shared libraries
but I can't find any output from libtool to tell me what symbols are
undefined. Is there a way to find out what libtool is complaining
about?
There may not
On 8/6/2010 5:18 PM, Corinna Vinschen wrote:
On Aug 6 17:09, Christopher Faylor wrote:
Why not present as much info as possible? I don't know what libkate
is but it would be nice to be able to satisfy my curiousity on that page
rather than jumping to a web page and googling.
Well, that's
On 8/6/2010 11:52 PM, Chris Sutcliffe wrote:
I wish to maintain rtorrent and the additional libraries it requires
that are not currently part of the Cygwin distribution:
[snip]
All these packages have been approved by the Fedora project, but as
far as I can tell have not been included as part
On 8/7/2010 4:20 AM, Charles Wilson wrote:
The attached implement all of these suggestions. But the port builds
fine from source both with and without my modifications.
Oh -- and the setup.hints for the -doc, -devel, runtime, (and -lic)
packages are missing external-source: libsigc++2.0
On 8/6/2010 11:52 PM, Chris Sutcliffe wrote:
All these packages have been approved by the Fedora project, but as
far as I can tell have not been included as part of the official
Fedora distribution. However, it is part of Debian's stable packages
(lenny). As a result, I don't believe it
I noticed when compiling Chris' latest ITPs that if there is no binary
main package. That is:
libsigc++2.0-VER-REL-src.tar.bz2
libsigc++2.0-VER-REL.tar.bz2 empty package
libsigc++2.0_0-VER-REL.tar.bz2
etc
Then cygport will create that empty package automatically (in $topdir)
but does not copy
On 8/6/2010 11:52 PM, Chris Sutcliffe wrote:
I wish to maintain rtorrent and the additional libraries it requires
that are not currently part of the Cygwin distribution:
[snip]
All these packages have been approved by the Fedora project, but as
far as I can tell have not been included as part
On 8/8/2010 12:59 PM, Steven Monai wrote:
Some notes about the packaging:
The setup.hints of the libtorrent subpackages (libtorrent11 and
libtorrent-devel) are missing their 'external-source: libtorrent' line.
Odd...my local (modified) copy has these; I wonder if the patch I posted
for Chris
On 1/5/2010 11:48 AM, Charles Wilson wrote:
Personally, I dislike global static variables. It's also bad practice
with popt, because a single program can have multiple parsing contexts.
(Not that any of the cygutils tools do this; so if you want to globally
modify all cygutils popt-using
On 8/15/2010 5:26 PM, Andy Koppe wrote:
On 15 August 2010 22:11, Charles Wilson wrote:
So, if you want to forward port your locale/charset changes and
cleanup-handling changes for mkshortcut (probably as two separate
patches) I'll try to act on them more rapidly this time. :-)
So you'd
libtirpc is an updated version of the Sun RPC library. As such, it
replaces part of the (orphaned) sunrpc package -- just as on linux, it
replaces the built-in RPC routines in glibc:
http://nfsv4.bullopensource.org/doc/tirpc_rpcbind.php
The headers are installed into \
/usr/lib/tirpc/rpc/*
and
sunrpc is orphaned. It provides libraries and headers for rpc routines,
utilities including rpcgen, documentation, and the portmap daemon.
The current version of sunrpc is 4.0-3, from 2005.
The proposed version, 4.0-4, has NOT been recompiled. It is simply a
repackaged version of 4.0-3, with
On 8/25/2010 8:14 PM, JonY wrote:
On 8/25/2010 12:19, JonY wrote:
since cygport and gcc has been updated, I can do the packaging without
any local hacks.
Ping.
Less than a single day is a bit quick to ping.
I'll take a look at this tonight or tomorrow; thanks for your hard work.
--
Chuck
On 8/27/2010 8:27 PM, Chris Sutcliffe wrote:
wget -x -nH --cut-dirs=1 \
http://emergedesktop.org/cygwin/w32api/w32api-3.15-1.tar.bz2 \
http://emergedesktop.org/cygwin/w32api/w32api-3.15-1-src.tar.bz2
Done.
--
Chuck
On 8/25/2010 12:19 AM, JonY wrote:
since cygport and gcc has been updated, I can do the packaging without
any local hacks.
Here are the packages.
Overall comments: I see you reverted to bundling the DLLs with the
compiler packages (e.g. no separate mingw64-x86_64-libfoo-* tarballs).
While
Originally posted in
http://cygwin.com/ml/cygwin-apps/2010-08/msg00213.html
but I figure it needs its own thread.
When testing JonY's mingw64 compiler, I found that often the include
files ended up in the wrong directory. Also, JonY apparently did as
well, since his cygport(5)'s
On 8/31/2010 8:52 PM, JonY wrote:
On 9/1/2010 03:32, Charles Wilson wrote:
Rebuilds fine from source (*), but the binary tarball above is not ok.
It has the headers in the following directory:
usr/x86_64-w64-mingw32/sys-root/mingw/x86_64-w64-mingw32/include/
instead of
usr/x86_64-w64-mingw32
On 9/1/2010 1:44 AM, Yaakov (Cygwin/X) wrote:
On Tue, 2010-08-31 at 17:34 -0400, Charles Wilson wrote:
When testing JonY's mingw64 compiler, I found that often the include
files ended up in the wrong directory.
Often?
As in, the ones that inherit toolchain are fine. The ones that inherit
On 8/31/2010 11:20 PM, JonY wrote:
On 9/1/2010 10:28, Charles Wilson wrote:
On 8/31/2010 8:52 PM, JonY wrote:
Strange, I'll try a rebuild. The former should be the correct location.
Errr...no. The *latter* is the correct location (at least, that's where
the sysroot'ed compiler will look
On 9/1/2010 11:44 AM, JonY wrote:
On 9/1/2010 23:15, Charles Wilson wrote:
On 8/31/2010 11:20 PM, JonY wrote:
On 9/1/2010 10:28, Charles Wilson wrote:
On 8/31/2010 8:52 PM, JonY wrote:
Strange, I'll try a rebuild. The former should be the correct
location.
Errr...no. The *latter
On 9/5/2010 12:53 PM, Andy Koppe wrote:
Please upload:
wget http://mintty.googlecode.com/files/mintty-0.8.3-1.tar.bz2
wget http://mintty.googlecode.com/files/mintty-0.8.3-1-src.tar.bz2
Please delete 0.7.1-1, leaving 0.8.2-1 as previous.
done.
--
Chuck
On 8/9/2010 3:29 AM, Charles Wilson wrote:
On 6/4/2010 3:35 PM, Charles Wilson wrote:
win32/pe TLS handling added
http://upx.hg.sourceforge.net/hgweb/upx/upx/rev/3616167cefd7
FYI, as of Sep 04:
UPX 3.06 has been released. It is a minor 3.0x maintenance release to
version 3 whose major
On 9/6/2010 7:47 AM, Damien Doligez wrote:
This is the contents of my setup.hint file for the updated package,
mostly unchanged from Igor's version:
--
sdesc: The Objective Caml compiler and runtime
ldesc: Objective Caml is a
On 9/7/2010 6:03 AM, Yaakov (Cygwin/X) wrote:
Given the recent issues on the list, I think it's about time I ITA
tcl/tk.
More power to you, but I don't think cgf has gone anywhere...so tcltk
isn't yet orphaned.
--
Chuck
On 9/7/2010 2:55 PM, Christopher Faylor wrote:
On Tue, Sep 07, 2010 at 08:40:43PM +0200, Matthias Andree wrote:
Insight is dead for all practical purposes, but Tcl/Tk in Cygwin depending
on X11 rather than Win32 would be major regression. Not that I'd have time
to help though.
This has
On 9/9/2010 6:10 AM, JonY wrote:
OK, we're amost there.
binutils and runtime are GTG.
gcc, headers, and pthreads are really close.
Everything rebuilds from source fine, and the uploaded packages actually
match the rebuilt versions (or vice versa). So that's all good. Plus, I
was able to
On 9/11/2010 2:07 AM, JonY wrote:
OK, new files are up, same links.
Err...the pthread packages seem to be missing...
--
Chuck
On 9/12/2010 10:24 PM, JonY wrote:
On 9/13/2010 01:01, Charles Wilson wrote:
On 9/11/2010 2:07 AM, JonY wrote:
OK, new files are up, same links.
Err...the pthread packages seem to be missing...
Sorry about that, pthreads now uploaded.
OK, all packages rebuild fine from souce. Also, now we
On 9/13/2010 6:52 AM, JonY wrote:
OK, new headers tarballs up. Thanks for keeping an eye out.
All packages are uploaded. Please wait 24 hours until they can
propagate to the mirrors, then post announcements to cygwin-announce.
Please look at the suggested templates here:
On 9/13/2010 2:16 PM, Corinna Vinschen wrote:
Chuck, can you please update http://cygwin.com/cygwin-pkg-maint, too?
Done.
On 9/14/2010 9:35 AM, Buchbinder, Barry (NIH/NIAID) [E] wrote:
Since so little is in the base-cygwin and base-passwd packages, might
it make sense to fold them into base-files?
No, IIRC there are issues with circular dependencies. Since these
packages live very close to the root of the
On 9/16/2010 9:38 AM, JonY wrote:
I have uploaded the 32bit toolchain, I hope there are no thinkos when
adapting the cygport files.
All packages rebuild from source ok. Packaging looks good; I used them
to build a working xz and liblzma with no trouble. genini is happy with
the setup.hints
Autobuild is a package that process output from building software,
primarily focused on packages using Autoconf and Automake, and then
generate a HTML summary file, containing links to each build log. The
output include project name, version, build host types (cross compile
aware), compiler host
On 9/20/2010 4:15 AM, Peter Rosin wrote:
But is it really a requirement? If you are referring to libtool commit
v2.2.10-92-g92d24b3, then that patch adds an /optional/ dependency on
autobuild. If you are a maintainer doing a release of libtool, it
probably is a requirement, but are you not
On 9/20/2010 10:43 AM, Eric Blake wrote:
Ironically, the main reason cygport autoreconf's everything is to ensure
that libtoolized packages use cygwin's customized version of...libtool.
Yes, it is rather ironic that building the cygwin package of libtool
requires running autoreconf, in order
On 9/20/2010 2:22 PM, Eric Blake wrote:
No, if I understand Peter's comment correct, autobuild is NOT required
for libtool, even with an autoreconf. Why? Because the original
libtool patch at commit 92d24b3 made the use of AB_INIT optional - it
only calls the macro _if_ autobuild.m4 could be
On 9/24/2010 5:09 AM, Corinna Vinschen wrote:
It would be very helpful for uploading if you could create a real
directory hirachy:
cygwin/tidy
tidy-20090325-1-src.tar.bz2
tidy-20090325-1.tar.bz2
setup.hint
/libtidy0_99_0
On 9/20/2010 4:31 PM, Charles Wilson wrote:
Yep, now we actually need votes.
I have 4 votes, now; anybody want to spot me another?
--
Chuck
On 9/30/2010 2:27 AM, Gernot Hillier wrote:
As the inetutils' tftpd is too limited for our use cases
I'll take a look at your packaging, and give the client/server a few
tests -- but it will have to wait until the weekend.
The first thing I noted, is that tftp-hpa still installs the server as
On 10/1/2010 10:34 AM, Gernot Hillier wrote:
We'll need to coordinate the release of tftp-hpa
Hmmm...now that I think about it, it would be really great if the
package name(s) themselves were simply
tftp-5.0-N
tftp-server-5.0-N
Users aren't going to CARE that the
On 10/4/2010 5:28 AM, Corinna Vinschen wrote:
On Oct 4 10:24, Gernot Hillier wrote:
Am 01.10.2010 17:47, schrieb Charles Wilson:
So, I really think you should enable IPv6. Now, that means a lot of
new porting work, because there are ALWAYS issues with porting IPv6
networking to cygwin/win32
On 10/4/2010 4:24 AM, Gernot Hillier wrote:
First of all, thanks for your detailed review, response and your
suggestions!
You're welcome.
Am 01.10.2010 17:47, schrieb Charles Wilson:
We'll need to coordinate the release of tftp-hpa
Hmmm...now that I think about it, it would be really great
On 10/4/2010 12:02 PM, Corinna Vinschen wrote:
On Oct 4 11:10, Charles Wilson wrote:
It's not so much *cygwin*, as *windows*. If a socket is opened to
listen for both IPv4 and IPv6 packets, then *all* received packets will
appear as IPv6 ones -- IPv4 ones will show up wrapped as
::
On 10/4/2010 4:33 PM, Bill Hoffman wrote:
I am trying to get
a new CMake release uploaded to cygwin
Will this include fixes for WIN32 being erroneously defined for cygwin?
http://cmake.org/Bug/view.php?id=10122
This just bit me trying to build opencv; no, I don't want
window_w32.cpp
On 10/5/2010 4:45 PM, Charles Wilson wrote:
Will this include fixes for WIN32 being erroneously defined for cygwin?
http://cmake.org/Bug/view.php?id=10122
Sorry, wrong list.
--
Chuck
On 10/4/2010 12:17 PM, Gernot Hillier wrote:
Ok, so I'll wait for your update...
And that's great; obviously your internal team can continue to use what
you have, until the revised version comes along. In fact, it's great
that you have an in-place testing environment; we can easily make
On 10/14/2010 6:16 AM, Marco Atzeri wrote:
so we have a DLL called 7z.so
that seems not used
It is dynamically loaded by 7z.exe:
7z uses plugins (7z.so and Codecs/Rar29.so) to handle archives.
7za is a stand-alone executable.
7za handles less archive formats than 7z.exe.
7zr is a
and w32api belong to Chris Sutcliffe.
* All other mingw-* packages belong ot Charles Wilson.
Chuck, since you maintain most of the mingw-* packages and are involved
with mingw.org, you're the most logical choice. FYI, my prototypes are
now in Ports git:
http://cygwin
On 11/6/2010 1:52 PM, Christopher Faylor wrote:
I'm not against this idea but I'd like to see what others think about
this.
I like it too. I don't actually use a web-accessible overlay (my
overlay is a local directory; the resolution rules are different in
that case) but I think it's a useful
On 11/7/2010 6:41 PM, Ken Brown wrote:
-lole32 -lwsock32 -lnetapi32 /usr/lib/libuuid.a -L/lib -L/usr/lib
^^
/usr/lib/libintl.a /usr/lib/libiconv.a /usr/lib/mingw/liblzma.a -lbz2
-lz -lmingw32
mklink2.o: In function `make_link_2':
On 11/8/2010 7:45 AM, Andy Koppe wrote:
On 8 November 2010 12:29, Ken Brown wrote:
You can see 'g++-3 -mno-cygwin' in the link command that I
quoted in my original post.
You're right. Sorry for the confusion.
There must be some other reason that
/usr/lib/libuuid.a is used.
It's due to
On 10/29/2010 1:26 AM, Yaakov (Cygwin/X) wrote:
On Thu, 2010-10-28 at 18:21 -0400, Charles Wilson wrote:
(e.g. my
gcc-3 -mno-cygwin compiler can use the mingw-cross-compiler's
mingw-runtime and w32api packages, with a little help). I documented
Do we *really* still need gcc-3 -mno-cygwin
On 11/8/2010 10:11 AM, Charles Wilson wrote:
OTOH, mingw.org has switched officially to dw2, but (for instance)
mandriva's mingw toochain is i586-pc-mingw32 (that is, it isn't a 32bit
spin of mingw64) but uses sjlj -- mainly because, in UPSTREAM gcc,
that's still the default IIRC. Sadly
On 11/12/2010 10:49 AM, Gernot Hillier wrote:
On 12.10.2010 20:29, Charles Wilson wrote:
Here's my revised version of your package:
http://cygwin.cwilson.fastmail.fm/tftp-5.0-1-src.tar.bz2
http://cygwin.cwilson.fastmail.fm/tftp-5.0-1.tar.bz2
http://cygwin.cwilson.fastmail.fm/tftp-server-5.0
On 11/15/2010 9:46 AM, Gernot Hillier wrote:
Some minor comments about /usr/share/doc/Cygwin/tftp.README:
* confuses config-tftpd with tftpd-config in (at least) two places
* Under 3), it describes the manual way to install the standalone...
* In one place, you reference /var/log/messages
On 11/15/2010 9:26 AM, Corinna Vinschen wrote:
The 64 bit kernel was developed after the XP 5.1 kernel. The resulting
64 bit-clean 5.2 kernel was then used for XP 64, 2K3 32 and 64 bit. The
numbering makes a lot of sense, given the history. And so, obviously,
XP 64 shares the new behaviour
On 11/15/2010 7:36 AM, Gernot Hillier wrote:
It seems that XP64 really behaves like NTServer2003 in the sense that
LocalSystem cannot change user: I can start the so-created service, but
when trying to connect, it fails on fork as expected with tftpd: PID
: cannot drop privileges:
On 11/15/2010 8:45 AM, Marco Atzeri wrote:
--- Lun 15/11/10, Reini Urban ha scritto:
Another minor pick, not that important.
/etc/slsh.rc:
% Add local additions here
It tries to load local-packages from
/usr/share/slsh/local-packages
but this dir does not exist.
Can you add an empty file
On 11/13/2010 3:31 AM, Lapo Luchini wrote:
Charles Wilson wrote:
PS: I wasn't able to compile setup.ini locally using genini, is it
possible for split packages?
Yes, it is. Did you use the --recursive option?
And, of course, the files need to be arranged as Corinna indicated
above
On 11/15/2010 12:14 PM, Corinna Vinschen wrote:
On Nov 15 10:36, Charles Wilson wrote:
Does that sound like a good plan?
Step #3
PROFIT
It sounds like a plan, but I think it's too complicated. The sole
purpose of the csih_is_nt2003 was to check for certain properties of the
OS
On 11/15/2010 2:12 PM, Corinna Vinschen wrote:
On Nov 15 12:32, Charles Wilson wrote:
Obviously, the easiest solution is to just document the current behavior:
... with the exception of csih_is_nt2003, which true for both 64bit
Windows XP, as well as NT Server 2003 and higher, since XP64
On 11/15/2010 9:46 AM, Gernot Hillier wrote:
Some minor comments about /usr/share/doc/Cygwin/tftp.README:
* confuses config-tftpd with tftpd-config in (at least) two places
Fixed.
* Under 3), it describes the manual way to install the standalone
service instead of the much more
On 11/17/2010 3:51 AM, Jan Nieuwenhuizen wrote:
Corinna Vinschen schreef op wo 17-11-2010 om 09:34 [+0100]:
Please remove version guile-1.6.7-4
There's a small problem. The libguile12 package is required by TeXmacs
and by the guile setup.hint itself. But even so, the guile-1.6.7-4
On 11/19/2010 4:54 AM, Gernot Hillier wrote:
Now, we miss a s/5.0-1/5.0-3/ in the README. ;-) Or will the version
number be reset upon final upload to cygwin.com? Why -3? See below (IPv6
problems... :-( ).
What are you talking about? The package I uploaded has:
- version 5.0-2 --
On 11/19/2010 10:17 AM, Gernot Hillier wrote:
I just wanted to escape the circular paradoxon: we can now change the
string to 5.0-2, but because of that change we'd have to bump up the
version to -3. But then, the string is wrong again, so we have to start
another cycle. And this loops
On 11/19/2010 10:59 AM, Gernot Hillier wrote:
Ok, after you solved the IPv6 stuff, let's get back to our original test
plan.
On 17.11.2010 06:32, Charles Wilson wrote:
1) test the binary in IPv4 mode. e.g. drop it in place of your
current 5.0-1 tftpd.exe and make sure it still works
Updated packages are available by pointing setup.exe here:
http://cygutils.fruitbat.org/ITP/mingw-gcc/
[Chris Sutcliff: see notes section below]
***
DO NOT INSTALL BLINDLY. FOLLOW THESE INSTRUCTIONS INSTEAD!
1) run
On 11/23/2010 5:28 PM, Charles Wilson wrote:
The attached patch does this
automatically.
Yeah, about that...
--
Chuck
? .Tpo
? chuck-doconfigure
? chuck-doconfigure.patch
? doconfigure-old
? yaakov-doconfigure
? yaakov-doconfigure.patch
Index: bootstrap.sh
On 11/23/2010 6:32 PM, Peter Rosin wrote:
Would it be possible to have a postinstall script for one of the new
packages that includes the awkward fixups? That way automatic fixup is
possible if you just reinstall the appropriate package, which seems
simple to support?
The problem is, because
On 11/23/2010 7:41 PM, Christopher Faylor wrote:
On Tue, Nov 23, 2010 at 05:28:46PM -0500, Charles Wilson wrote:
DO NOT ALLOW setup.exe to install mingw-binutils yet, even though
setup.exe will whine about it. Nor mingw-w32api or mingw-runtime, or
any of the mingw libraries (zlib, bzip2, xz
On 11/24/2010 12:06 AM, Christopher Faylor wrote:
Why do you not have similar concerns with the mingw64-i686 and
mingw64-x86_64 toolchains?
I believe I did raise a concern but, even if I didn't and I only thought
about it and never voiced it, it hardly matters that you got me.
I'm not
On 11/23/2010 7:28 PM, Peter Rosin wrote:
Over in linux-land, the mingw compiler is usually named i586-..., is that
an option?
On Fedora and Mandriva, yes. It seems SuSe uses i686-pc-mingw32. I
think the target should match (as closely as is sane) the way
mingw.org's native compiler is
On 11/20/2010 2:04 AM, Charles Wilson wrote:
On 11/19/2010 10:59 AM, Gernot Hillier wrote:
On 17.11.2010 06:32, Charles Wilson wrote:
We'll have to coordinate
a) uploading the tftp and the updated inetutils packages, and
b) sending the announcements of those two packages
I'll need some
On 11/30/2010 9:52 AM, JonY wrote:
Note that mingw64-*-runtime versioning scheme changed, with appropriate
setup.hint changes added, hopefully correctly.
Done. (You were missing the links to the new -runtime files, but I got
them from sourceforge anyway).
--
Chuck
901 - 1000 of 1203 matches
Mail list logo
