Re: ITP: buthead -- Copy all but the first few lines (CANCEL)
On 2012-10-09 22:06, marco atzeri wrote: | build fine so GTG | | but why we need it? | | BUGS |Functionality overlaps with tail -n +count |or awk '(NRcount)' or sed 1,countd Good point. Probably not useful enough as there are alternatives. Withdrawn, Jari
Re: RFE: Cygw32 GNU Emacs Port
On 10/9/12 10:37 PM, Christopher Faylor wrote: On Tue, Oct 09, 2012 at 08:16:41PM -0700, Daniel Colascione wrote: On 10/9/12 7:45 PM, Ken Brown wrote: 1. This strikes me as going against the spirit of Cygwin, which tries to emulate Linux. Why shouldn't users who want a GUI version of emacs just use emacs-X11, as they would on Linux? If I wanted to emulate Linux, I'd run VirtualBox. What you want is completely irrelevant. I'm a Cygwin user, and I posted on a Cygwin mailing list and argued that a package should be included in Cygwin. As part of my argument, I described why Cygwin is useful to me and why I think the package I'm proposing would make Cygwin more useful. There's nothing wrong with that. Yes, you've heard the Cygwin is not VirtualBox argument before. You're not swayed. I get it. So why bother replying? If I were compelled to interrupt conversations just to complain that I'd already heard some argument or other, I wouldn't be able to function in society. Hell, I probably wouldn't make it down the block without being arrested. signature.asc Description: OpenPGP digital signature
Re: RFE: Cygw32 GNU Emacs Port
On Oct 9 23:13, Christopher Faylor wrote: On Tue, Oct 09, 2012 at 10:45:01PM -0400, Ken Brown wrote: [Redirecting from cygwin to cygwin-apps.] On 10/9/2012 10:19 PM, Daniel Colascione wrote: [...] When we release Emacs 24.3 packages for Cygwin, would it be possible to add a package for users who want to use cygw32 Emacs? It would be easy enough for me to do, assuming it builds without a problem. But I have a couple of qualms about it: 1. This strikes me as going against the spirit of Cygwin, which tries to emulate Linux. Why shouldn't users who want a GUI version of emacs just use emacs-X11, as they would on Linux? We don't provide Win32 versions of other X11 programs as far as I know. 2. Because there is so much Windows-specific code in it, I wouldn't feel competent to support it if users have problems. I'm not at all familiar with that kind of programming. I'd like to hear what others think, especially cgf and Corinna. I had similar mild concerns about the un-Cygwinness of it. But, we do have other packages like mintty which have specific Windows code in them and, even the X package has to have Windows code. So, I'd leave the decision entirely up to your competent hands. I'm amazed that you do such a good job supporting such a complicated package already so I'd expect that you could pick up the Windows stuff eventually. The only question is really if you want to take on the added support costs. Maybe you could release it as a test package and see just how much bother it could be? Otherwise, I could say ABSOLUTELY NOT and you could blame me. :-) Not much more to say. As an additional datapoint I'd like to point out that Volker's XEmacs package also already comes with a Win32 GUI, which is used by default if DISPLAY isn't set. If a package has to choose (for technical reasons) between an X GUI and a W32 GUI, I'd prefer the X GUI. If both GUIs are possible in parallel, it's the maintainer's call. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] w32api-3.0b_svn5368-1
On Oct 9 22:48, Yaakov (Cygwin/X) wrote: On Tue, 2012-10-09 at 12:06 +0200, Corinna Vinschen wrote: Why does bind include iphlpapi.h at all? As a Cygwin application it's not supposed to use Windows and Cygwin network functions in parallel. Because you asked me to make it so: http://www.cygwin.com/ml/cygwin-apps/2009-01/msg00097.html Oops, *blush*. So I hacked the code to do exactly that: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/bind;a=blob;f=9.7.1-lwconfig-win32.patch;h=d05c009 Perhaps a solution is for cygwin/in.h to #define s_addr s_addr to trigger inaddr.h's include guard? Will do. But that only helps in your case after we updated to the next Cygwin version. I guess you already added such a #define to the bind code? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: ITP: xloadimage -- Graphics file viewer under X11
On Oct 9 18:37, marco atzeri wrote: On 10/8/2012 3:01 PM, Jari Aalto wrote: 2012-10-08 15:27 marco atzeri On 2012-10-08 14:27, marco atzeri wrote: | | /tmp/ITP/xloadimage/xloadimage-4.1/.build/build/configure: | Permission denied I believe an added check now handles this. Repackaged. Thanks, Jari wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/xloadimage/setup.hint \ http://cante.net/~jaalto/tmp/cygwin/xloadimage/xloadimage-4.1-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/xloadimage/xloadimage-4.1-1.tar.bz2 # To check packaging cd xloadimage tar -xf *-src.tar.bz2 it builds and packages fine. GTG Uploaded. I'm a bit puzzled where to put X packages. Some packages are in the top-level dir, some are under X11, some under X.Org. I put xloadimage under X.Org now, but... is that right? Is there some grand scheme I'm not aware about? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: RFU: makeself -- Utility to generate self-extractable archives
On Oct 10 07:53, Jari Aalto wrote: 2012-10-09 21:49 David Sastre Medina | | If you want to take over mantainership of makeself, I have no | objections. According to its git log, there have been some minor improvements during | this year. Ok; packaged from Git: wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/makeself/makeself-2.1.5+20120813+gitdcbe778-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/makeself/makeself-2.1.5+20120813+gitdcbe778-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/makeself/setup.hint Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: RFU: keychain 2.7.1-1 (ITA: new maintainer)
On Oct 10 08:44, Jari Aalto wrote: 2012-10-09 21:49 David Sastre Medina | | P.S. keychain (also a simple shell script) is orphaned, and there's a | new version upstream, just in case you're interested. New upstream release: wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/keychain/keychain-2.7.1-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/keychain/keychain-2.7.1-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/keychain/setup.hint Err... hang on. This package is officially maintained by Jonathan C. Allen. I admit that we had no feedback from him since 2007, but it doesn't hurt to ask. Jonathan? Are you still with us in some way? You are still officially maintainer of 5 packages, bsflite, keychain, naim, ncftp and tnef. None of them has been update since 2007, though... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: ITP: duff -- Duplicate file finder
On Oct 9 19:00, marco atzeri wrote: On 10/9/2012 9:37 AM, Jari Aalto wrote: wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/duff/duff-0.5.2-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/duff/duff-0.5.2-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/duff/setup.hint # To check packaging cd duff tar -xf *-src.tar.bz2 ./*.sh --color --verbose all Included in Debian: http://packages.debian.org/duff Jari [ setup.hint ] sdesc: Duplicate file finder ldesc: A command-line utility for identifying duplicates in a given set of files. It attempts to be usably fast and uses the SHA family of message digests as a part of the comparisons. category: Utils requires: libintl8 it builds runs and packages fine. GTG Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: ITP: pstotext -- Extract text from PostScript and PDF files
On Oct 9 18:15, marco atzeri wrote: On 10/9/2012 5:29 PM, Jari Aalto wrote: wget --recursive --no-host-directories --cut-dirs=3 \ http://cante.net/~jaalto/tmp/cygwin/pstotext/pstotext-1.9-1-src.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/pstotext/pstotext-1.9-1.tar.bz2 \ http://cante.net/~jaalto/tmp/cygwin/pstotext/setup.hint # To check packaging cd pstotext tar -xf *-src.tar.bz2 ./*.sh --color --verbose all Included in Debian: http://packages.debian.org/pstotext Notes: Program uses ghostscript for processing. Jari it builds and runs fine. GTG Uploaded. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: upload protocol
On Oct 9 12:58, Christopher Faylor wrote: Would it make sense to always wait for an RFU after an ITP? As an uploader, I'd rather not have to scan conversations for clues for when a package is ready for upload. I was actually waiting for Jari to send an RFU for the packages that he'd recently ITP'ed but, now that I think of it, maybe that's not what we usually do. I'd like to propose that we always require an RFU. I have no strong opinion. I always scan the threads for the magic GTG incantation anyway. Whatever everyone prefers is ok with me. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [ITA] w32api-3.0b_svn5368-1
On Oct 10 10:24, Corinna Vinschen wrote:
On Oct 9 22:48, Yaakov (Cygwin/X) wrote:
On Tue, 2012-10-09 at 12:06 +0200, Corinna Vinschen wrote:
Why does bind include iphlpapi.h at all? As a Cygwin application it's not
supposed to use Windows and Cygwin network functions in parallel.
Because you asked me to make it so:
http://www.cygwin.com/ml/cygwin-apps/2009-01/msg00097.html
Oops, *blush*.
So I hacked the code to do exactly that:
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/bind;a=blob;f=9.7.1-lwconfig-win32.patch;h=d05c009
Perhaps a solution is for cygwin/in.h to #define s_addr s_addr to
trigger inaddr.h's include guard?
Will do. But that only helps in your case after we updated to the next
Cygwin version. I guess you already added such a #define to the bind
code?
Can you check if my patch to cygwin/in.h works for you?
Index: include/cygwin/in.h
===
RCS file: /cvs/src/src/winsup/cygwin/include/cygwin/in.h,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -p -r1.18 -r1.19
--- include/cygwin/in.h 6 Jul 2012 13:52:18 - 1.18
+++ include/cygwin/in.h 10 Oct 2012 08:36:33 - 1.19
@@ -112,11 +112,15 @@ enum
IPPORT_USERRESERVED = 5000
};
+/* Avoid collision with Mingw64 headers. */
+#ifndef s_addr
/* Internet address. */
struct in_addr
{
in_addr_t s_addr;
};
+#define s_addr s_addr
+#endif
/* Request struct for IPv4 multicast socket ops */
Other than that, was there any other roadblock on the way to the Mingw64
headers?
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
Re: ITP: xloadimage -- Graphics file viewer under X11
On 10/10/2012 10:44 AM, Corinna Vinschen wrote: it builds and packages fine. GTG Uploaded. I'm a bit puzzled where to put X packages. Some packages are in the top-level dir, some are under X11, some under X.Org. I put xloadimage under X.Org now, but... is that right? Is there some grand scheme I'm not aware about? Thanks, Corinna Yaakov for cygport is using X11 for this type of programs ftp://ftp.cygwinports.org/pub/cygwinports/release-2/X11/ and X.org for the server itself ftp://ftp.cygwinports.org/pub/cygwinports/release-2/X.Org/ Marco
Re: RFE: Cygw32 GNU Emacs Port
On 10/10/2012 4:14 AM, Corinna Vinschen wrote: On Oct 9 23:13, Christopher Faylor wrote: On Tue, Oct 09, 2012 at 10:45:01PM -0400, Ken Brown wrote: [Redirecting from cygwin to cygwin-apps.] On 10/9/2012 10:19 PM, Daniel Colascione wrote: [...] When we release Emacs 24.3 packages for Cygwin, would it be possible to add a package for users who want to use cygw32 Emacs? It would be easy enough for me to do, assuming it builds without a problem. But I have a couple of qualms about it: 1. This strikes me as going against the spirit of Cygwin, which tries to emulate Linux. Why shouldn't users who want a GUI version of emacs just use emacs-X11, as they would on Linux? We don't provide Win32 versions of other X11 programs as far as I know. 2. Because there is so much Windows-specific code in it, I wouldn't feel competent to support it if users have problems. I'm not at all familiar with that kind of programming. I'd like to hear what others think, especially cgf and Corinna. I had similar mild concerns about the un-Cygwinness of it. But, we do have other packages like mintty which have specific Windows code in them and, even the X package has to have Windows code. So, I'd leave the decision entirely up to your competent hands. I'm amazed that you do such a good job supporting such a complicated package already so I'd expect that you could pick up the Windows stuff eventually. The only question is really if you want to take on the added support costs. Maybe you could release it as a test package and see just how much bother it could be? Otherwise, I could say ABSOLUTELY NOT and you could blame me. :-) Not much more to say. As an additional datapoint I'd like to point out that Volker's XEmacs package also already comes with a Win32 GUI, which is used by default if DISPLAY isn't set. If a package has to choose (for technical reasons) between an X GUI and a W32 GUI, I'd prefer the X GUI. If both GUIs are possible in parallel, it's the maintainer's call. OK, I'll give it a try. Since Daniel is willing to help with support, it shouldn't be much extra work. Ken
Re: upload protocol
On Wed, Oct 10, 2012 at 03:31:51AM -0600, Warren Young wrote: On 10/9/2012 10:58 AM, Christopher Faylor wrote: Would it make sense to always wait for an RFU after an ITP? That's how I thought it always worked. To my mind, ITP is only a trial run, asking experienced packagers to test that everything's okay. RFU is exactly what it says: the request for upload. ITP followed by GTG implies that an RFU is coming shortly, but I agree with Chris, nothing should happen until that RFU *does* come. It gives the packager a chance to change something minor brought up in the ITP discussion, for example. As it happens, I think this sort of gun-jumping happened with the Doxygen 1.8.0-1 packages. I gave a GTG with reservations to the ITP, several days ago. David said in the thread he was off working on addressing some of those reservations, but then yesterday Corinna uploaded from the ITP message. I'm not regretting my GTG. I thought the packages were at least no worse than my 1.7.4-1 packages that David's packages replace. But, I think David was expecting a second chance before sending the RFU. Thanks for the real world example. That is exactly the kind of thing I was talking about. cgf
Re: RFE: Cygw32 GNU Emacs Port
On Tue, Oct 09, 2012 at 11:50:22PM -0700, Daniel Colascione wrote: On 10/9/12 10:37 PM, Christopher Faylor wrote: On Tue, Oct 09, 2012 at 08:16:41PM -0700, Daniel Colascione wrote: On 10/9/12 7:45 PM, Ken Brown wrote: 1. This strikes me as going against the spirit of Cygwin, which tries to emulate Linux. Why shouldn't users who want a GUI version of emacs just use emacs-X11, as they would on Linux? If I wanted to emulate Linux, I'd run VirtualBox. What you want is completely irrelevant. I'm a Cygwin user, and I posted on a Cygwin mailing list and argued that a package should be included in Cygwin. As part of my argument, I described why Cygwin is useful to me and why I think the package I'm proposing would make Cygwin more useful. There's nothing wrong with that. Yes, you've heard the Cygwin is not VirtualBox argument before. You're not swayed. I get it. So why bother replying? If I were compelled to interrupt conversations just to complain that I'd already heard some argument or other, I wouldn't be able to function in society. Hell, I probably wouldn't make it down the block without being arrested. I tend to reply to these types of Cygwin should be X because I say so messages because 1) I can and 2) to make sure that there is no confusion on what Cygwin is which could otherwise could cause others to chime in with enthusiastic I know! I think Cygwin should be more like a floor wax!
Re: ITP: xloadimage -- Graphics file viewer under X11
On Wed, 2012-10-10 at 10:44 +0200, Corinna Vinschen wrote: I'm a bit puzzled where to put X packages. Some packages are in the top-level dir, some are under X11, some under X.Org. I put xloadimage under X.Org now, but... is that right? Is there some grand scheme I'm not aware about? For easier management, I asked that release/X.Org/ only be used for modular X.org components, all of which are maintained by Jon Turney or myself: http://www.cygwin.com/ml/cygwin-apps/2008-11/msg5.html Anything else X-related can go into release/X11/. Yaakov
Re: ITP: xloadimage -- Graphics file viewer under X11
On Oct 10 11:42, Yaakov (Cygwin/X) wrote: On Wed, 2012-10-10 at 10:44 +0200, Corinna Vinschen wrote: I'm a bit puzzled where to put X packages. Some packages are in the top-level dir, some are under X11, some under X.Org. I put xloadimage under X.Org now, but... is that right? Is there some grand scheme I'm not aware about? For easier management, I asked that release/X.Org/ only be used for modular X.org components, all of which are maintained by Jon Turney or myself: http://www.cygwin.com/ml/cygwin-apps/2008-11/msg5.html Anything else X-related can go into release/X11/. Thanks, I moved xloadimage to X11. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: upload protocol
On 10/10/12 10:31, Warren Young wrote: As it happens, I think this sort of gun-jumping happened with the Doxygen 1.8.0-1 packages. I gave a GTG with reservations to the ITP, several days ago. David said in the thread he was off working on addressing some of those reservations, but then yesterday Corinna uploaded from the ITP message. I'm not regretting my GTG. I thought the packages were at least no worse than my 1.7.4-1 packages that David's packages replace. But, I think David was expecting a second chance before sending the RFU. Yes, I was a little surprised when my doxygen package was uploaded! I had made the changes that Warren suggested, and I sent another [ITP] message last Thursday (4 Oct 2012): http://cygwin.com/ml/cygwin-apps/2012-10/msg00021.html As a newbie, I didn't know whether to wait for more comments, or to submit a [RFU] (as I'd been given a GTG) - maybe someone would be kind enough to clarify this. But before either could happen, the package got uploaded anyway! But to repeat: the package that was uploaded included the suggestions that Warren made. Cheers, Dave.
Re: RFU: keychain 2.7.1-1 (ITA: new maintainer)
On Wed, Oct 10, 2012 at 11:00:04AM +0200, Corinna Vinschen wrote: On Oct 10 08:44, Jari Aalto wrote: 2012-10-09 21:49 David Sastre Medina | | P.S. keychain (also a simple shell script) is orphaned, and there's a | new version upstream, just in case you're interested. New upstream release: Err... hang on. This package is officially maintained by Jonathan C. Allen. I admit that we had no feedback from him since 2007, but it doesn't hurt to ask. Jonathan? Are you still with us in some way? You are still officially maintainer of 5 packages, bsflite, keychain, naim, ncftp and tnef. None of them has been update since 2007, though... I'm sorry. Somehow, I had the idea of keychain being orphaned already. I tried searching the mail archives, but I could only find this thread from some months ago: http://sourceware.org/ml/cygwin-apps/2012-03/msg00082.html Again, I apologize. Completely unintended. -- Primary key fingerprint: AD8F BDC0 5A2C FD5F A179 60E7 F79B AB04 5299 EC56 signature.asc Description: Digital signature
Re: upload protocol
On 10/10/2012 11:46 AM, David Stacey wrote: As a newbie, I didn't know whether to wait for more comments, or to submit a [RFU] (as I'd been given a GTG) All of the discussion was questions of whether, not how or why. So, I think you should have just made the changes you wanted to make, and RFU'd the result. There was pretty much no way you could have lost the GTG status. But whatever, it all came out okay.
Re: ITP: qiv -- Quick image viewer for X
On Mon, 2012-10-08 at 16:23 +0300, Jari Aalto wrote: 2012-10-08 12:46 marco atzeri | build fine, runs, but most of the dependecies seem not direct ones : Hm, I usually go with objdump: $ objdump -p .inst/usr/bin/qiv.exe | egrep -i '\.dll' | egrep -vi 'KERNEL32|cygwin1.dll|MPR.DLL|GDI32|USER32|ntdll.dll' | sort DLL Name: cygImlib2-1.dll DLL Name: cygX11-6.dll DLL Name: cygXinerama-1.dll DLL Name: cyggdk-x11-2.0-0.dll DLL Name: cyggdk_pixbuf-2.0-0.dll DLL Name: cygglib-2.0-0.dll DLL Name: cyggobject-2.0-0.dll DLL Name: cygmagic-1.dll DLL Name: cygpango-1.0-0.dll Which one, cygcheck top-level or objdump, is correct listing to use? objdump (as cygport does). Yaakov
Re: [ITA] w32api-3.0b_svn5368-1
On Wed, 2012-10-10 at 11:09 +0200, Corinna Vinschen wrote: On Oct 10 10:24, Corinna Vinschen wrote: On Oct 9 22:48, Yaakov (Cygwin/X) wrote: Perhaps a solution is for cygwin/in.h to #define s_addr s_addr to trigger inaddr.h's include guard? Will do. But that only helps in your case after we updated to the next Cygwin version. I guess you already added such a #define to the bind code? Can you check if my patch to cygwin/in.h works for you? WFM. Other than that, was there any other roadblock on the way to the Mingw64 headers? I think there's still one issue wrt xorg-server; I need to check that again. Yaakov
[ITP] python-argparse
New runtime dep of BIND 9.9.2: ftp://ftp.cygwinports.org/pub/cygwinports/release-2/Python/python-argparse/ This will only be necessary until such time that Python is updated to 2.7, as it then will be part of the standard library. Yaakov
