headers
Gernot Hillier | 1 Oct 2010 16:34
Picon

Re: [ITP] tftp-hpa 5.0

Hi!

Am 30.09.2010 09:46, schrieb Charles Wilson:
> On 9/30/2010 2:27 AM, Gernot Hillier wrote:
> 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.

Great, thanks in advance!

> The first thing I noted, is that tftp-hpa still installs the server as
> "/usr/sbin/in.tftpd" (no .exe).  For consistency with the inetutils
> server it is replacing -- and cygwin standards -- that should be renamed
> to "/usr/sbin/tftpd.exe"

Done.

> I'd always intended to retire inetutil's tftpd and tftp in favor of the
> hpa version, but I haven't had enough 'tuits.  Thanks!

I knew. That's one reason why I decided to roll a hopefully nice package
out of it and publish ist... :-)

> We'll need to coordinate the release of tftp-hpa with an update to
> inetutils (removing its tftp*).  

Hmmm, wouldn't it make sense to also split inetutils and keep tftp* in a
separate package? So users are not forced to switch?

> If possible, it would be nice to split
> the server and client components into two separate packages (see rsh and
(Continue reading)

Permalink | Reply | 37 comments |
headers
Charles Wilson | 1 Oct 2010 17:47
Favicon

Re: [ITP] tftp-hpa 5.0

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 implementation/source came from the
'tftp-hpa' distribution.

Mandriva packages tftp-hpa as plain old "tftp" and "tftp-server".

SUSE packages both client and server in a single package called "tftp"
(not "tftp-hpa"):
https://build.opensuse.org/package/view_file?file=tftp.spec&package=tftp&project=openSUSE%3AFactory

Fedora also appears to provide tftp-hpa, and names the resulting
packages "tftp" and "tftp-server" (and tftp-debuginfo)
http://koji.fedoraproject.org/koji/rpminfo?rpmID=1995280

Debian does package as "tftp-hpa" -- but that's because Debian ALSO
provides the netkit-based "tftp" package.  apt can handle
conflicts...but setup.exe doesn't; see below.

> with an update to
>> inetutils (removing its tftp*).  
> 
> Hmmm, wouldn't it make sense to also split inetutils and keep tftp* in a
> separate package? So users are not forced to switch?
(Continue reading)

Permalink | Reply | 36 comments |
headers
Ken Brown | 2 Oct 2010 23:02
Picon
Favicon

[RFU] {emacs,emacs-X11,emacs-el}-23.2-3

wget -x -nH --cut-dirs=2 \
   http://www.math.cornell.edu/~kbrown/cygwin/emacs/setup.hint \
   http://www.math.cornell.edu/~kbrown/cygwin/emacs/emacs-23.2-3-src.tar.bz2 \
   http://www.math.cornell.edu/~kbrown/cygwin/emacs/emacs-23.2-3.tar.bz2 \
   http://www.math.cornell.edu/~kbrown/cygwin/emacs/emacs-X11/setup.hint \
   http://www.math.cornell.edu/~kbrown/cygwin/emacs/emacs-X11/emacs-X11-23.2-3.tar.bz2 \
   http://www.math.cornell.edu/~kbrown/cygwin/emacs/emacs-el/setup.hint \
   http://www.math.cornell.edu/~kbrown/cygwin/emacs/emacs-el/emacs-el-23.2-3.tar.bz2

Please delete the 23.1-10 and 23.2-2 packages, leaving 23.2-3 as
current and 23.2-1 as previous.

Thanks.

Ken
Permalink | Reply | 1 comment |
headers
Andy Koppe | 3 Oct 2010 18:51
Picon

[RFU] mintty-0.9.1-1

Please upload:

wget http://mintty.googlecode.com/files/mintty-0.9.1-1.tar.bz2
wget http://mintty.googlecode.com/files/mintty-0.9.1-1-src.tar.bz2
wget http://mintty.googlecode.com/svn/tags/0.9.1/cygport/setup.hint

0.9b2-1 and 0.8.2-1 can be deleted, leaving 0.8.3-1 as previous.

Thanks,
Andy
Permalink | Reply | 1 comment |
headers
Yaakov (Cygwin/X | 3 Oct 2010 20:44
Picon
Gravatar

Re: [RFU] mintty-0.9.1-1

On Sun, 2010-10-03 at 17:51 +0100, Andy Koppe wrote:
> Please upload:
> 
> wget http://mintty.googlecode.com/files/mintty-0.9.1-1.tar.bz2
> wget http://mintty.googlecode.com/files/mintty-0.9.1-1-src.tar.bz2
> wget http://mintty.googlecode.com/svn/tags/0.9.1/cygport/setup.hint
> 
> 0.9b2-1 and 0.8.2-1 can be deleted, leaving 0.8.3-1 as previous.

Done and done.

Yaakov
Permalink | Reply | 0 comments |
headers
Yaakov (Cygwin/X | 3 Oct 2010 20:49
Picon
Gravatar

Re: [RFU] {emacs,emacs-X11,emacs-el}-23.2-3

On Sat, 2010-10-02 at 17:02 -0400, Ken Brown wrote:
> Please delete the 23.1-10 and 23.2-2 packages, leaving 23.2-3 as
> current and 23.2-1 as previous.

Done and done.

Yaakov
Permalink | Reply | 0 comments |
headers
Gernot Hillier | 4 Oct 2010 10:24
Picon

Re: [ITP] tftp-hpa 5.0

Dear Chuck!

First of all, thanks for your detailed review, response and your 
suggestions!

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 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 implementation/source came from
> the 'tftp-hpa' distribution.
[...]
> setup.exe doesn't have any provision for specifying conflicts.  So,
> we can only have one (current) package that provides any specific
> file (such as /bin/tftp.exe or /usr/sbin/tftpd.exe).

Ic. I'm not that of a Cygwin expert so I just trust your opinion here.
Changing the package accordingly is fine for me. (Keeping inetutils'
tftp implementation was just a quick idea w/o thinking about the
conflict resolving stuff).

> While I don't really have any issues with remap, I wonder why you
> dropped tcpwrappers? It adds no complexity to the build, and helps --
> to a certain degree -- with some of the security issues endemic to
> the tftp protocol.  (Especially as tftpd-hpa operates in such a way
> that you *can't* call it via the 'tcpd' utility in inetd.conf).
>
> Also, the whole *point* of obsoleting inetutil's version is because
> it is not capable of support IPv6 -- but tftp-hpa is.
(Continue reading)

Permalink | Reply | 35 comments |
headers
Corinna Vinschen | 4 Oct 2010 10:30
Favicon

Re: [ITP] xclip 0.12

On Sep 29 22:47, rolandc wrote:
> xclip is included in the Debian distribution:
> http://packages.debian.org/stable/xclip
> 
> http://zfire.free.fr/cygwin/xclip-0.12-1.tar.bz2
> http://zfire.free.fr/cygwin/xclip-0.12-1-src.tar.bz2
> 
> -------- setup.hint ---------
> category: X11
> requires: libXmu6 libX11_6
> sdesc: "Command line clipboard grabber"
> ldesc: "xclip is a command line utility that is designed to run on any
> system with an
> X11 implementation. It provides an interface to X selections ("the clipboard")
> from the command line. It can read data from standard in or a file and place it
> in an X selection for pasting into other X applications. xclip can also print
> an X selection to standard out, which can then be redirected to a file or
> another program."

Packaging looks good.  It would be nice if you could provide not only
the setup.hint in plain text, but also as downloadable link to simplify
uploading.

I uploaded this package with a tweak to setup.hint.  The ldesc string
contains quotation marks -> ("the clipboard").  I just removed them.
Please fix that in your local copy of setup.hint.

Please send an announcement to the cygwin-announce mailing list
per the description in http://cygwin.com/setup.html#submitting.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Corinna Vinschen | 4 Oct 2010 11:28
Favicon

Re: [ITP] tftp-hpa 5.0

On Oct  4 10:24, Gernot Hillier wrote:
> Am 01.10.2010 17:47, schrieb Charles Wilson:
> >Also, the whole *point* of obsoleting inetutil's version is because
> >it is not capable of support IPv6 -- but tftp-hpa is.
> >
> >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...see the rsh package's patches (also,
> >xinetd).

Chuck, for the dumb of us, can you please reiterate in a few words
what problems you're talking about?  I'm kind of in trouble to think
of any Cygwin-specific IPv6 problem apart from some border cases.
I have at least two packages which I use IPv6 with, openssh and
syslog-ng, and I have no trouble with them.

> We can for sure try to re-enable and fix all these issues, but as for
> you, my time for these tasks is also quite limited and I can't promise
> quick results here...

IMHO a new tftp only makes sense if it has some visible advantages
over the old one.  Tcpwrappers, readline and IPv6 shouldn't be that
tricky.

But we're all volunteers here.  If it's not a security related problem,
we're not asking for "quick".

> Hmmm, anyone running tftpd should know that (s)he should protect it from
> any productive network as it's insecure by design. In my eyes, putting
> tftpd behind an effective firewall is just the right answer here. Any
(Continue reading)

Permalink | Reply | 6 comments |
headers
Charles Wilson | 4 Oct 2010 17:10
Favicon

Re: [ITP] tftp-hpa 5.0

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...see the rsh package's patches (also,
>>> xinetd).
> 
> Chuck, for the dumb of us, can you please reiterate in a few words
> what problems you're talking about?  I'm kind of in trouble to think
> of any Cygwin-specific IPv6 problem apart from some border cases.
> I have at least two packages which I use IPv6 with, openssh and
> syslog-ng, and I have no trouble with them.

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
::ffff::71.15.23.51 or something.

So, if the app listens for both packet types, it really better support
IPv4-in-IPv6 addressing. Many of them don't.

This isn't really a cygwin bug, but an application bug exposed by how
windows, underneath cygwin, handles mixed-mode sockets.

Also, when iterating interfaces, windows returns *a lot* more than the
obvious ones (like, my simple laptop with wireless + wired returns about
a dozen...some are VPN tunneling devices, etc) and IIRC lists the IPv6
ones first.  There was also some issue, the details of which escape me
right now, related to IPv6 localhost ::1 and 127.0.0.1.  But the point
(Continue reading)

Permalink | Reply | 5 comments |

Gmane