From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32665 invoked by alias); 17 Feb 2016 17:33:37 -0000 Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com Received: (qmail 32640 invoked by uid 89); 17 Feb 2016 17:33:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-96.6 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_PBL,RDNS_DYNAMIC,USER_IN_WHITELIST autolearn=no version=3.3.2 spammy=learnt, *required*, Features, strive X-HELO: calimero.vinschen.de Received: from ipbcc0d020.dynamic.kabel-deutschland.de (HELO calimero.vinschen.de) (188.192.208.32) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 17 Feb 2016 17:33:34 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id 4AEB2A804A8; Wed, 17 Feb 2016 18:33:32 +0100 (CET) Date: Wed, 17 Feb 2016 17:33:00 -0000 From: Corinna Vinschen To: cygwin-apps@cygwin.com Subject: Re: [ITP] Inetutils 1.9.4 Message-ID: <20160217173332.GL29076@calimero.vinschen.de> Reply-To: cygwin-apps@cygwin.com Mail-Followup-To: cygwin-apps@cygwin.com References: <56B78518.2000209@boland.nl> <20160208140438.GJ27646@calimero.vinschen.de> <56BED384.70607@boland.nl> <20160213171623.GA8374@calimero.vinschen.de> <56C34E21.7060003@boland.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/8E7gjuj425jZz9t" Content-Disposition: inline In-Reply-To: <56C34E21.7060003@boland.nl> User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2016-02/txt/msg00044.txt.bz2 --/8E7gjuj425jZz9t Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 5122 Hi Daniel, On Feb 16 17:28, D. Boland wrote: > Corinna Vinschen wrote: > >On Feb 13 07:56, D. Boland wrote: > >>Corinna Vinschen wrote: > >>>On Feb 7 18:55, D. Boland wrote: > >>>>Some programs in the inetutils suite are packaged already: > >>>>[...] > >>>>So I added these on the 'required' lines. > >>>They are not actually *required* to run inetd, right? Does it really > >>>make sense to add them as require packages then? > >>[...] > >These tools are provided separately in many Linux distros for quite > >some time, and while those tools can be started by inetd, inetd > >doesn't require them and they don't require inetd (xinetd is perfectly > >capable of replacing inetd). >=20 > I don't see why this makes sense. The ping, hostname, whois and tftp > programs *do* belong to the inetutils package, right? But if you insist, > i'll comply. Let's use modern Linux distros as role model, please. > >- usr/bin/inetutils-server-config installs inetd and syslogd in one > > go. That's a no no. There should be two installation scripts since > > you can't expect that a user who wants one service also wants the > > other one. Some people would probably like to stick to the Windows > > logging, or install syslog-ng. > > > >- Apropos syslog-ng: syslogd potentially collides with syslog-ng. > > However, instead of reusing the existing /usr/bin/syslogd-config > > script, your new scripts don't check for an existing syslog-ng > > installation at all. >=20 > I'll create inetutils-inetd-config and inetutils-syslogd-config. The latt= er > will check for syslog-ng existance. Ok. It would just be nice if your service installer scripts would follow the technique used by other service installer scripts and not work entirely differently. > >- sbin/ifconfig is mostly non-functional since Cygwin doesn't support > > most of the functionality. Do you really want to maintain it? > > > >- usr/bin/traceroute is non-functional: > > > > $ traceroute.exe www.wdr.de > > traceroute to e2636.g.akamaiedge.net (104.90.150.230), 64 hops max > > traceroute: socket: Operation not permitted >=20 > That's because you're not in Administrator mode. Ping (from Atzeri's > package) does the same. The error message ultimately comes from the 'send= to' > function, which is in cygwin1.dll That's because ping is using raw sockets which are restricted to admins. Sadly Windows doesn't support the SUID bit... Linux' traceroute supports the -U flag which uses UDP packages. That might be a default option for non-admin accounts, if this traceroute supports UDP tracing as well, wouldn't it? > >- What also irritates me is that almost none of the patches from the > > former package made it into your version. Did you actually check the > > patches from the current 1.9.1 source package and made sure that they > > are really not required anymore, especially concerning O_BINARY/O_TEXT > > mode, authentication, exception handling, and, generally, backward > > compatibility? >=20 > What surprised me was the sheer number of patches. A whopping 573 of them. > Are they bug-fixes? Features? Shouldn't both be sent upstream? What about > the dont-mess-with-userspace rule? You once told me > that "we mostly strive to make Cygwin accommodate user space". >=20 > I'm not sure if I want to adopt inetutils with all these patches. It feels > like a can of worms. I cannot find any explanations for the patches in the > README files. Those patches are going to haunt me. I am a systems-program= mer > for 20 years now. And I learnt Torvald's first rule of kernel programming > the hard way. >=20 > Please let me adopt the package in a clean way. If a parent adopts a chil= d, > there will be new rules. The real parents didn't want the child, or could= n't > keep the child for unknown reasons. I don't mess with the child and it wi= ll > love me for it. I'll take full resposibility for not messing with the chi= ld > ;-) >=20 > Seriously, I really think it is fair to re-negotiate if and how I will me= ss > with inetutils. I'm the new maintainer, right? The concerns about > authentication I understand, but isn't a big issue. It's in the new, much > smaller patch. And aren't things like O_BINARY/O_TEXT mode and exception > handling a concern of the upstream maintainers? There are two points here. One, I didn't say that you have to take the patches as is. They might partially not even be necessary anymore. I asked you if you have *checked* them. Some of them might contain stuff which should stay available one way or the other to be backward compatible with the former version of inetutils (especially inetd). The missing O_BINARY stuff looks suspicious, for instance. Two, of course it's preferably if necessary patches go upstream. But upstream might not even know that we're using their package. And if the old maintainer didn't communicate with upstream, it would probably make sense if the new maintainer would try to pick up. Corinna --=20 Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat --/8E7gjuj425jZz9t Content-Type: application/pgp-signature; name="signature.asc" Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWxK7sAAoJEPU2Bp2uRE+gwDUP/0zV9DIsKA1qqDcjUvjNABo6 8mGoD5oTzBdQczoOjA56xwHkTF6m/2IlNpaUBkHPc8hxx88BC9iBKNKGiUshJBI3 Sg8IesV0top53RZVm1QB+Sn/kcEJ/X/Si8vby8iM4c6emEtrt4cPIzScv9aH6vGO 48Abb9ATTl2s2kf/SbVDDCWQbC4968gANGItwCZiC0DJ7Wv74kVOZaajJx4p1RD7 cX4TYRRk77cgvYmTEfQp6Ru3KYRGfp4O1vU1gj/ligCXO56WG+J06Orsruh8nfjA L+MeEY2jFzK0RkNK7olrTclsVyF/msf3oZ1pxbr3yBr4igf+2d+nCGfLAXqRNsxd zoRTqD/5tVaDhK1ZI3kgOpRlCMdrt1AleKsg5tSSPRtekVyAywuG+VZbGqWC9ZbR JZ0XdG1cxcqDt1Ym6FKfsp1uz8DXcETeL1Hnv1lfDtb0qC0nMwRCXhLefdNKrZBc X8lfmH5qQVYZ3Irfx1wk6/DF1aluGfS4lTp0gleN+BFDPqByZkId/hqQLd8ZufAH HK0FTdnbOupl5jy/GTTdaT7lA0qb4XC4jVNYSFqv89LjXEZ1KEgLFvnWfalZ/1fC /rs9mAZPJuUJNpAtRv7ohNswE0gpmMfzgEaBLqRPTWBb6RSprmVAZVID5dUXYn7f wZPCQLkIJJ5PHCQ9a2xs =IClN -----END PGP SIGNATURE----- --/8E7gjuj425jZz9t--