Re: [ITP] tftp-hpa 5.0

[Gernot Hillier]

Hi there!

Am 17.11.2010 06:32, schrieb Charles Wilson:
 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.

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... :-( ).

And the first para of Port Notes is now obsolete since you added ipv6
and remap support.

Apart from that, the README got even better now, I really like it! Will
definitely help me to remember the privilege chaos background.

   Perhaps you could also add a hint that the user might want to
   change TFTPBOOT and args_value in the script before starting. Or
   perhaps you could even make it interactive?
 
 Well...I think that's an advanced topic -- especially as the package, as
 a *package*, assumes that /var/lib/tftpboot/ WILL be the directory
 containing the files to be served.

That's no problem any more. I just noticed the --args argument to
tftpd-config which is described and allows exactly what I needed. So you
already fixed this for me. :-)

 e.g. we already ensure that the directory is created, and included in
 the tarball.  If somebody wants to *modify* the installation *after*
 getting it running in its default mode, that's fine (e.g. by going to
 the Service Manager and modifying the args that way, for standalone; or
 editing /etc/inetd.d/tftp or /etc/xinetd.d/tftp).

Just for the sake of completeness: for standalone mode it's not that
easy as you can't change the cygrunsrv parameters in the Service Manager
- at least not for XP-64bit. So far, I found no easy way besides
removing and reinstalling the service. That's exactly why I decided to
instead modify tftpdir in tftpd-config.

 OK, I've uploaded my attempt at 5.0-2 here:
 
 http://cygwin.cwilson.fastmail.fm/tftp-5.0-2-src.tar.bz2
 http://cygwin.cwilson.fastmail.fm/tftp-5.0-2.tar.bz2
 http://cygwin.cwilson.fastmail.fm/tftp-server-5.0-2.tar.bz2
 http://cygwin.cwilson.fastmail.fm/tftp-server.hint
 http://cygwin.cwilson.fastmail.fm/tftp.hint
 
 In addition to the wording changes in the README and in the tftpd-config
 script, I've also enabled IPv6 and -m (remap) support.
 
 I suggest:
 
   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 with your inhouse
 IPv4 clients without any trouble.

Unfortunately, the IPv6 support breaks things for me. tftpd doesn't
start on my XP-64 box and says:

tftpd: PID : cannot open IPv6 socket, disable IPv6: Address family
   not support by protocol
tftpd: PID : Cannot set nonblock flag on socket: Bad file
   descriptor.
tftpd: PID : `tftpd` service stopped, exit status: 71

Sounds we need an extra check in the sources.

If you don't have time, I can also have a look on this.

 Release schedule:
   If you're happy with this, and confident that you can continue
 maintaining it from here out (don't worry; I'm not going to get hit by a
 bus -- but you'll be running point for tftp/tftpd) -- then we can plan
 the transition and rollout the new packages.
 
 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 time for (a) because I have to update inetutil's
 iu-config and syslog-config scripts; fortunately the major surgery --
 removing tftp/tftpd -- from inetutils is already done.

Sure, sounds pretty ok for me. As said, I can confirm that I'll be
maintaining the tftp package, but most likely, my response times will
continue to vary as in the last days - depending on my current workload.
But as I expect a rather limited amount of users needing tftp on Cygwin,
this should be ok... :-)

-- 
Gernot

Unbelievably obscure setup bug

[Jon TURNEY]

Whilst trying to write some other modifications to setup.exe, I've found what
looks like an obscure bug introduced in the following change:

 CVSROOT:  /sourceware/projects/cygwin-apps-home/cvsfiles
 Module name:  setup
 Changes by:   cori...@sourceware.org  2009-05-07 14:14:59
 
 Modified files:
   .  : ChangeLog package_db.cc 
 
 Log message:
   * package_db.cc (ConnectedLoopFinder::doIt): Revert patch from
   2008-08-29.  Add dumb hardcoded algorithm to make sure base-cygwin
   and base-passwd are always the first packages in the postinstall
   executable order.
 
 Patches:
 http://sourceware.org/cgi-bin/cvsweb.cgi/setup/ChangeLog.diff?cvsroot=cygwin-appsr1=2.618r2=2.619
 http://sourceware.org/cgi-bin/cvsweb.cgi/setup/package_db.cc.diff?cvsroot=cygwin-appsr1=2.40r2=2.41

This change to package_db.cc doesn't do what it claims as casecompare()
returns 0 to indicate equality.

Since db.packages is sorted alphabetically, it looks like it actually inserts
the dependencies of the first (in alphabetical order) installed package
(assuming that's not base-cygwin or base-passwd), twice.

The log output actually shows this happening.  In my case aewm++ is the
installed package which comes first in alphabetical order, which is why the
logged dependency order list before running the postinstall scripts starts
Dependency order of packages: base-cygwin base-passwd cygwin libgcc1 libXau6
libXdmcp6 libxcb1 libX11_6 libXext6 aewm++ aewm++ ...

Attached is the obvious patch to fix this, but I'm not sure that's right, as
it runs base-passwd and base-cygwin in the opposite order to the comment
(Dependency order of packages: base-passwd cygwin base-cygwin ...), which
isn't very clear about if they merely both have to run first, or in a
given order

From aa8c426c310b932b3791b3d2d25682448c7d1f52 Mon Sep 17 00:00:00 2001
From: Jon TURNEY jon.tur...@dronecode.org.uk
Date: Fri, 19 Nov 2010 00:51:52 +
Subject: [PATCH] Obvious and probably incorrect fix for incorrect use of 
casecompare()

casecompare() returns 0 for equality
also adjust visit() so it does nothing when used to visit a node a second time
(so explicit 'base-passwd' visit won't add a duplicate entry if it's already 
been
visited, which also allows the recursive use to be simplified.

Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
 package_db.cc |   13 +++--
 1 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/package_db.cc b/package_db.cc
index 45dd3ce..f01624c 100644
--- a/package_db.cc
+++ b/package_db.cc
@@ -250,7 +250,7 @@ ConnectedLoopFinder::doIt()
   for (size_t i = 0; i  db.packages.size(); ++i)
 {
   packagemeta pkg (*db.packages[i]);
-  if (pkg.installed  casecompare (pkg.name, base-cygwin))
+  if (pkg.installed  (casecompare (pkg.name, base-cygwin) == 0))
{
  visit (i);
  break;
@@ -259,7 +259,7 @@ ConnectedLoopFinder::doIt()
   for (size_t i = 0; i  db.packages.size(); ++i)
 {
   packagemeta pkg (*db.packages[i]);
-  if (pkg.installed  casecompare (pkg.name, base-passwd))
+  if (pkg.installed  (casecompare (pkg.name, base-passwd) == 0))
{
  visit (i);
  break;
@@ -297,6 +297,10 @@ ConnectedLoopFinder::visit(size_t const nodeToVisit)
   if (!db.packages[nodeToVisit]-installed)
 /* Can't visit this node, and it is not less than any visted node */
 return db.packages.size() + 1;
+
+  if (visitOrder[nodeToVisit])
+return visitOrder[nodeToVisit];
+
   ++visited;
   visitOrder[nodeToVisit] = visited;
 
@@ -324,10 +328,7 @@ ConnectedLoopFinder::visit(size_t const nodeToVisit)
 log (LOG_PLAIN)  Search for package '  (*i)-packageName() 
 ' failed.  endLog;
   else
   {
-if (visitOrder[nodeJustVisited])
-  minimumVisitId = std::min (minimumVisitId, 
visitOrder[nodeJustVisited]);
-else
-  minimumVisitId = std::min (minimumVisitId, visit 
(nodeJustVisited));
+minimumVisitId = std::min (minimumVisitId, visit 
(nodeJustVisited));
   }
  /* next and clause */
  ++dp;
-- 
1.7.2.3

Re: [ITP] tftp-hpa 5.0

[Charles Wilson]

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 -- 2010-11-16 -
* Initial release for Cygwin 1.7.
* Revised cygwin README. Updated tftpd-config script messages.
* Enable IPv6.
* Enable pathname remapping.

- version 5.0-1 -- 2010-10-nn -
* Unreleased.

There is no 5.0-3.  I reset to 5.0-1 since I changed the name of the
package from your tftp-hpa- to tftp-  and tftp-server-.  I've made two
releases. 5.0-1 and 5.0-2.  I don't see where you are getting any
references to 5.0-3.

 And the first para of Port Notes is now obsolete since you added ipv6
 and remap support.

Good point.

 Apart from that, the README got even better now, I really like it! Will
 definitely help me to remember the privilege chaos background.

Good.

   Perhaps you could also add a hint that the user might want to
   change TFTPBOOT and args_value in the script before starting. Or
   perhaps you could even make it interactive?

 Well...I think that's an advanced topic -- especially as the package, as
 a *package*, assumes that /var/lib/tftpboot/ WILL be the directory
 containing the files to be served.
 
 That's no problem any more. I just noticed the --args argument to
 tftpd-config which is described and allows exactly what I needed. So you
 already fixed this for me. :-)

OK.

 e.g. we already ensure that the directory is created, and included in
 the tarball.  If somebody wants to *modify* the installation *after*
 getting it running in its default mode, that's fine (e.g. by going to
 the Service Manager and modifying the args that way, for standalone; or
 editing /etc/inetd.d/tftp or /etc/xinetd.d/tftp).
 
 Just for the sake of completeness: for standalone mode it's not that
 easy as you can't change the cygrunsrv parameters in the Service Manager
 - at least not for XP-64bit. So far, I found no easy way besides
 removing and reinstalling the service. That's exactly why I decided to
 instead modify tftpdir in tftpd-config.

Hmm.  I wonder if cygrunsrv ought to have a --modify function, to go
along with --install and --remove.

Well, the README also describes how to install manually using cygrunsrv,
so interested parties could do this;

   tftpd-config --standalone

to get everything (including the user accounts) set up, and then

   cygrunsrv -R tftpd
   cygrunsrv -I tftpd  other args

to reinstall with their preferred args.  But...I don't think that really
needs to be documented as such.

 I suggest:

   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 with your inhouse
 IPv4 clients without any trouble.
 
 Unfortunately, the IPv6 support breaks things for me. tftpd doesn't
 start on my XP-64 box and says:
 
 tftpd: PID : cannot open IPv6 socket, disable IPv6: Address family
not support by protocol
 tftpd: PID : Cannot set nonblock flag on socket: Bad file
descriptor.
 tftpd: PID : `tftpd` service stopped, exit status: 71

Well, that stinks.  Er...do you have IPv6 enabled at all?  It's not
enabled by default on Server2003 (and since XP64 is based on that kernel...)

Try this

   1. Go to Start | Control Panel, and double-click
  Network Connections.
   2. Right-click the network adapter on which you want
  to enable IPv6, and select Properties.
   3. Click Install.
   4. Select Protocol from the list of installation
  choices, and click Add.
   5. Select Microsoft TCP/IP Version 6, and click OK.

These instructions may be valid only on SP1 and above; I'm not sure.

Then, try to run tftpd again.  If it works, then what we need to fix is
to allow tftpd to work (in IPv4 mode) when IPv6 is not available. (*)
If it doesn't work...then we've got bigger problems.

To remove IPv6, do the same thing only click 'Uninstall' instead.

(*) The first bug is this (found by inspection):

--- tftpd.c.orig2010-11-19 07:39:42.20580 -0500
+++ tftpd.c 2010-11-19 07:40:26.22900 -0500
@@ -591,11 +591,12 @@
 syslog(LOG_ERR,
cannot open IPv6 socket, disable IPv6: %m);
 }
-}
-set_socket_nonblock(fd6, 1);
-memset(bindaddr6, 0, sizeof bindaddr6);
-bindaddr6.sin6_family = AF_INET6;
-bindaddr6.sin6_port = htons(IPPORT_TFTP);
+} else {
+set_socket_nonblock(fd6, 1);
+memset(bindaddr6, 0, sizeof bindaddr6);
+bindaddr6.sin6_family = AF_INET6;
+bindaddr6.sin6_port = htons(IPPORT_TFTP);
+   }
 }
 #endif
 if (address) {


The problem is, in the IPv6 block (unlike the IPv4 block) it is possible
to reach set_socket_nonblock(fd6, ...) when fd6 is invalid -- because
you won't 

Re: Unbelievably obscure setup bug

[Corinna Vinschen]

On Nov 19 11:52, Jon TURNEY wrote:
 
 Whilst trying to write some other modifications to setup.exe, I've found what
 looks like an obscure bug introduced in the following change:
 
  CVSROOT:/sourceware/projects/cygwin-apps-home/cvsfiles
  Module name:setup
  Changes by: cori...@sourceware.org  2009-05-07 14:14:59
  
  Modified files:
  .  : ChangeLog package_db.cc 
  
  Log message:
  * package_db.cc (ConnectedLoopFinder::doIt): Revert patch from
  2008-08-29.  Add dumb hardcoded algorithm to make sure base-cygwin
  and base-passwd are always the first packages in the postinstall
  executable order.
  
  Patches:
  http://sourceware.org/cgi-bin/cvsweb.cgi/setup/ChangeLog.diff?cvsroot=cygwin-appsr1=2.618r2=2.619
  http://sourceware.org/cgi-bin/cvsweb.cgi/setup/package_db.cc.diff?cvsroot=cygwin-appsr1=2.40r2=2.41
 
 This change to package_db.cc doesn't do what it claims as casecompare()
 returns 0 to indicate equality.
 
 Since db.packages is sorted alphabetically, it looks like it actually inserts
 the dependencies of the first (in alphabetical order) installed package
 (assuming that's not base-cygwin or base-passwd), twice.
 
 The log output actually shows this happening.  In my case aewm++ is the
 installed package which comes first in alphabetical order, which is why the
 logged dependency order list before running the postinstall scripts starts
 Dependency order of packages: base-cygwin base-passwd cygwin libgcc1 libXau6
 libXdmcp6 libxcb1 libX11_6 libXext6 aewm++ aewm++ ...
 
 Attached is the obvious patch to fix this, but I'm not sure that's right, as
 it runs base-passwd and base-cygwin in the opposite order to the comment
 (Dependency order of packages: base-passwd cygwin base-cygwin ...), which
 isn't very clear about if they merely both have to run first, or in a
 given order

The code in question was supposed to make sure that the order is always
base-cygwin base-passwd [...] and that was the case so far.  Of
course, given the obvious mishandling of the casecompare return value
it's not clear why this ever worked.  Even more mysterious is the fact
that the bugfix *breaks* this order.  Well, time to debug...


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

Re: Unbelievably obscure setup bug

[Jon TURNEY]

On 19/11/2010 13:13, Corinna Vinschen wrote:
 The code in question was supposed to make sure that the order is always
 base-cygwin base-passwd [...] and that was the case so far.  Of
 course, given the obvious mishandling of the casecompare return value
 it's not clear why this ever worked.  Even more mysterious is the fact
 that the bugfix *breaks* this order.  Well, time to debug...

Well, the bugfix breaks the order because visit() on base-cygwin inserts it
and all it's dependencies depth-first (ignoring loops).

I guess what's needed is a separate function to insert something explicitly
into the ordered list and mark that as visited, and use that for base-cygwin
and base-passwd.

Re: Unbelievably obscure setup bug

[Corinna Vinschen]

On Nov 19 13:23, Jon TURNEY wrote:
 On 19/11/2010 13:13, Corinna Vinschen wrote:
  The code in question was supposed to make sure that the order is always
  base-cygwin base-passwd [...] and that was the case so far.  Of
  course, given the obvious mishandling of the casecompare return value
  it's not clear why this ever worked.  Even more mysterious is the fact
  that the bugfix *breaks* this order.  Well, time to debug...
 
 Well, the bugfix breaks the order because visit() on base-cygwin inserts it
 and all it's dependencies depth-first (ignoring loops).

In theory base-cygwin has no dependecies.  Here are the setup.hint
snippets:

  base-cygwin:

category: Base

  base-passwd:

requires: base-cygwin
category: Base
noautodep: cygwin

  cygwin:

requires: base-passwd base-cygwin
noautodep: _update-info-dir

I think that explains it.  The problem in base-cygwin is that it depends
on cygwin since the noautodep: cygwin is missing.  So there's a
dependency chain which goes base-cygwin - cygwin - base-passwd.
That's how this order is generated.  If we add noautodep: cygwin to
base-cygwin, it would really have no dependency and should always become
the first package.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

Re: Unbelievably obscure setup bug

[Jon TURNEY]

On 19/11/2010 13:36, Corinna Vinschen wrote:
 On Nov 19 13:23, Jon TURNEY wrote:
 On 19/11/2010 13:13, Corinna Vinschen wrote:
 The code in question was supposed to make sure that the order is always
 base-cygwin base-passwd [...] and that was the case so far.  Of
 course, given the obvious mishandling of the casecompare return value
 it's not clear why this ever worked.  Even more mysterious is the fact
 that the bugfix *breaks* this order.  Well, time to debug...

 Well, the bugfix breaks the order because visit() on base-cygwin inserts it
 and all it's dependencies depth-first (ignoring loops).
 
 In theory base-cygwin has no dependecies.  Here are the setup.hint
 snippets:
 
   base-cygwin:
 
 category: Base
 
   base-passwd:
 
 requires: base-cygwin
 category: Base
 noautodep: cygwin
 
   cygwin:
 
 requires: base-passwd base-cygwin
 noautodep: _update-info-dir
 
 I think that explains it.  The problem in base-cygwin is that it depends
 on cygwin since the noautodep: cygwin is missing.  So there's a
 dependency chain which goes base-cygwin - cygwin - base-passwd.
 That's how this order is generated.  If we add noautodep: cygwin to
 base-cygwin, it would really have no dependency and should always become
 the first package.

I wasn't aware of the existence of noautodep. Now it all makes sense :-)

If everything else depends on cygwin, I think that should give the correct
ordering without any special casing?

If not, you perhaps might want to tweak the comment to indicate the order
which is required, and note that we rely base-cygwin and base-passwd having no
unvisited dependencies to get the required ordering.

[PATCH 0/3] Various setup.exe patches

[Jon TURNEY]

Jon TURNEY (3):
  Change No package - Unknown package in postinstall script
failure report.
  Ensure binary package is selected for non-curr versions.
  Move PrereqChecker.isMet() call out of ChooserPage::OnNext() to a
separate stage

 choose.cc   |   19 ++
 dialog.h|1 +
 package_meta.cc |1 +
 postinstall.cc  |2 +-
 prereq.cc   |   72 +++
 threebar.cc |   12 +
 threebar.h  |2 +
 7 files changed, 92 insertions(+), 17 deletions(-)

-- 
1.7.2.3

[PATCH 1/3] Change No package - Unknown package in postinstall script failure report.

[Jon TURNEY]

Left over postinstall scripts may well have been installed by a
package, we just don't know which one at this point.

2010-11-17  Jon TURNEY  jon.tur...@dronecode.org.uk

* postinstall.cc (do_postinstall_thread): Refer to Unknown package
rather than No package

Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
 postinstall.cc |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/postinstall.cc b/postinstall.cc
index 8a4635d..1d24027 100644
--- a/postinstall.cc
+++ b/postinstall.cc
@@ -186,7 +186,7 @@ do_postinstall_thread (HINSTANCE h, HWND owner)
 
   // and try to run what's left...
   {
-RunScript scriptRunner(No package, scripts);
+RunScript scriptRunner(Unknown package, scripts);
 scriptRunner.run_all(s);
   }
 
-- 
1.7.2.3

[PATCH 2/3] Ensure binary package is selected for non-curr versions.

[Jon TURNEY]

At the moment, selecting a test version clears the binary package
checkbox, which isn't very helpful.

It's safe to set pick() for all versions of a package, the installer
will only install the desired one.

2010-11-17  Jon TURNEY  jon.tur...@dronecode.org.uk

* package_meta.cc (set_action): Always set the binary tick box
when selecting a specific version (if binary is available)

Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
 package_meta.cc |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/package_meta.cc b/package_meta.cc
index 8640fd9..800d2ff 100644
--- a/package_meta.cc
+++ b/package_meta.cc
@@ -497,6 +497,7 @@ packagemeta::set_action (packageversion const 
default_version)
  if (i != versions.end ())
{
  desired = *i;
+ desired.pick (desired.accessible(), this);
  if (desired.sourcePackage().accessible ())
desired.sourcePackage ().pick (sourceticked, NULL);
  else
-- 
1.7.2.3

[PATCH 3/3] Move PrereqChecker.isMet() call out of ChooserPage::OnNext() to a separate stage

[Jon TURNEY]

Move PrereqChecker.isMet() call out of ChooserPage::OnNext() to a separate 
stage,
so we can put the package chooser page away and indicate progress via the 
threebar
status page.

2010-11-19  Jon TURNEY  jon.tur...@dronecode.org.uk

* choose.cc (OnNext): Remove PrereqChecker call, instead use new
WM_APP_PREREQ_CHECK state of Progress dialog.
* threebar.h (WM_APP_PREREQ_CHECK)
(WM_APP_PREREQ_CHECK_THREAD_COMPLETE): Add new messages.
* threebar.cc (OnActivate, OnMessageApp): Use single bar mode for
WM_APP_PREREQ_CHECK state.  Handle new messages.
* dialog.h (do_prereq_check_thread): Add prototype.
* prereq.cc (isMet, do_prereq_check_thread)
(do_prereq_check_reflector, do_prereq_check): Add progress reporting
during isMet, and thread containing moved PrereqChecker code.

Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
 choose.cc   |   19 ++-
 dialog.h|1 +
 prereq.cc   |   72 +++
 threebar.cc |   12 +
 threebar.h  |2 +
 5 files changed, 90 insertions(+), 16 deletions(-)

diff --git a/choose.cc b/choose.cc
index f0c6f64..59654a8 100644
--- a/choose.cc
+++ b/choose.cc
@@ -291,23 +291,10 @@ ChooserPage::OnNext ()
   logResults();
 #endif
 
-  PrereqChecker p;
-  long retval;
-  if (p.isMet ())
-{
-  if (source == IDC_SOURCE_CWD)
-   Progress.SetActivateTask (WM_APP_START_INSTALL);  // install
-  else
-   Progress.SetActivateTask (WM_APP_START_DOWNLOAD); // start download
-  retval = IDD_INSTATUS;
-}
-  else
-{
-  // rut-roh, some required things are not selected
-  retval = IDD_PREREQ;
-}
   PlaceDialog (false);
-  return retval;
+  Progress.SetActivateTask (WM_APP_PREREQ_CHECK);
+
+  return IDD_INSTATUS;
 }
 
 long
diff --git a/dialog.h b/dialog.h
index 8883a6d..0c94238 100644
--- a/dialog.h
+++ b/dialog.h
@@ -38,6 +38,7 @@ bool do_fromcwd(HINSTANCE _h, HWND owner);
 D (do_ini);
 D (do_install);
 D (do_postinstall);
+D (do_prereq_check);
 
 #undef D
 
diff --git a/prereq.cc b/prereq.cc
index f7302d9..a049630 100644
--- a/prereq.cc
+++ b/prereq.cc
@@ -38,6 +38,7 @@ static const char *cvsid =
 #include package_db.h
 #include package_meta.h
 #include msg.h
+#include Exception.h
 
 // Sizing information.
 static ControlAdjuster::ControlInfo PrereqControlsInfo[] = {
@@ -152,6 +153,10 @@ PrereqChecker::isMet ()
 {
   packagedb db;
 
+  Progress.SetText1 (Checking prerequisites...);
+  Progress.SetText2 ();
+  Progress.SetText3 ();
+
   // unmet is static - clear it each time this is called
   unmet.clear ();
 
@@ -166,6 +171,9 @@ PrereqChecker::isMet ()
 todo.push (*p);
 }
 
+  int max = todo.size();
+  int pos = 0;
+
   // churn through the work list
   while (!todo.empty ())
 {
@@ -173,6 +181,13 @@ PrereqChecker::isMet ()
   packagemeta *pack = todo.front ();
   todo.pop ();
 
+  pos++;
+  Progress.SetText2 (pack-name.c_str());
+  static char buf[100];
+  sprintf(buf, %d %%  (%d/%d), pos * 100 / max, pos, max);
+  Progress.SetText3(buf);
+  Progress.SetBar1(pos, max);
+
   // Fetch the dependencies of the package. This assumes that the
   // dependencies of the prev, curr, and exp versions are all the same.
   vector vector PackageSpecification * * *deps = pack-curr.depends ();
@@ -261,3 +276,60 @@ PrereqChecker::selectMissing ()
 }
 }
 }
+
+// ---
+// progress page glue
+// ---
+
+static int
+do_prereq_check_thread(HINSTANCE h, HWND owner)
+{
+  PrereqChecker p;
+  int retval;
+
+  if (p.isMet ())
+{
+  if (source == IDC_SOURCE_CWD)
+   Progress.SetActivateTask (WM_APP_START_INSTALL);  // install
+  else
+   Progress.SetActivateTask (WM_APP_START_DOWNLOAD); // start download
+  retval = IDD_INSTATUS;
+}
+  else
+{
+  // rut-roh, some required things are not selected
+  retval = IDD_PREREQ;
+}
+
+  return retval;
+}
+
+static DWORD WINAPI
+do_prereq_check_reflector (void *p)
+{
+  HANDLE *context;
+  context = (HANDLE *) p;
+
+  try
+  {
+int next_dialog = do_prereq_check_thread ((HINSTANCE) context[0], (HWND) 
context[1]);
+
+// Tell the progress page that we're done prereq checking
+Progress.PostMessage (WM_APP_PREREQ_CHECK_THREAD_COMPLETE, 0, next_dialog);
+  }
+  TOPLEVEL_CATCH(prereq_check);
+
+  ExitThread(0);
+}
+
+static HANDLE context[2];
+
+void
+do_prereq_check (HINSTANCE h, HWND owner)
+{
+  context[0] = h;
+  context[1] = owner;
+
+  DWORD threadID;
+  CreateThread (NULL, 0, do_prereq_check_reflector, context, 0, threadID);
+}
diff --git a/threebar.cc b/threebar.cc
index cbc8c08..10d2f18 100644
--- a/threebar.cc
+++ b/threebar.cc
@@ -147,6 +147,7 @@ ThreeBarProgressPage::OnActivate ()
 {
 case 

Re: Unbelievably obscure setup bug

[Christopher Faylor]

On Fri, Nov 19, 2010 at 02:20:13PM +, Jon TURNEY wrote:
On 19/11/2010 13:36, Corinna Vinschen wrote:
 On Nov 19 13:23, Jon TURNEY wrote:
 On 19/11/2010 13:13, Corinna Vinschen wrote:
 The code in question was supposed to make sure that the order is always
 base-cygwin base-passwd [...] and that was the case so far.  Of
 course, given the obvious mishandling of the casecompare return value
 it's not clear why this ever worked.  Even more mysterious is the fact
 that the bugfix *breaks* this order.  Well, time to debug...

 Well, the bugfix breaks the order because visit() on base-cygwin inserts 
 it
 and all it's dependencies depth-first (ignoring loops).
 
 In theory base-cygwin has no dependecies.  Here are the setup.hint
 snippets:
 
   base-cygwin:
 
 category: Base
 
   base-passwd:
 
 requires: base-cygwin
 category: Base
 noautodep: cygwin
 
   cygwin:
 
 requires: base-passwd base-cygwin
 noautodep: _update-info-dir
 
 I think that explains it.  The problem in base-cygwin is that it depends
 on cygwin since the noautodep: cygwin is missing.  So there's a
 dependency chain which goes base-cygwin - cygwin - base-passwd.
 That's how this order is generated.  If we add noautodep: cygwin to
 base-cygwin, it would really have no dependency and should always become
 the first package.

I wasn't aware of the existence of noautodep. Now it all makes sense :-)

I believe that I actually added this so that we wouldn't need to special-case
packages in setup.

cgf

Re: [PATCH 1/3] Change No package - Unknown package in postinstall script failure report.

[Christopher Faylor]

On Fri, Nov 19, 2010 at 02:51:50PM +, Jon TURNEY wrote:
Left over postinstall scripts may well have been installed by a
package, we just don't know which one at this point.

2010-11-17  Jon TURNEY  jon.tur...@dronecode.org.uk

   * postinstall.cc (do_postinstall_thread): Refer to Unknown package
   rather than No package

Looks good.  Please apply.

Thank you.

cgf

Re: [PATCH 2/3] Ensure binary package is selected for non-curr versions.

[Christopher Faylor]

On Fri, Nov 19, 2010 at 02:51:51PM +, Jon TURNEY wrote:
At the moment, selecting a test version clears the binary package
checkbox, which isn't very helpful.

It's safe to set pick() for all versions of a package, the installer
will only install the desired one.

2010-11-17  Jon TURNEY  jon.tur...@dronecode.org.uk

   * package_meta.cc (set_action): Always set the binary tick box
   when selecting a specific version (if binary is available)


Looks good.  Please apply.  

Thank you.

cgf

Re: [PATCH 3/3] Move PrereqChecker.isMet() call out of ChooserPage::OnNext() to a separate stage

[Christopher Faylor]

On Fri, Nov 19, 2010 at 02:51:52PM +, Jon TURNEY wrote:
Move PrereqChecker.isMet() call out of ChooserPage::OnNext() to a separate 
stage,
so we can put the package chooser page away and indicate progress via the 
threebar
status page.

2010-11-19  Jon TURNEY  jon.tur...@dronecode.org.uk

   * choose.cc (OnNext): Remove PrereqChecker call, instead use new
   WM_APP_PREREQ_CHECK state of Progress dialog.
   * threebar.h (WM_APP_PREREQ_CHECK)
   (WM_APP_PREREQ_CHECK_THREAD_COMPLETE): Add new messages.
   * threebar.cc (OnActivate, OnMessageApp): Use single bar mode for
   WM_APP_PREREQ_CHECK state.  Handle new messages.
   * dialog.h (do_prereq_check_thread): Add prototype.
   * prereq.cc (isMet, do_prereq_check_thread)
   (do_prereq_check_reflector, do_prereq_check): Add progress reporting
   during isMet, and thread containing moved PrereqChecker code.

Looks good.  Please apply.  

Thank you.

cgf

Re: [ITP] tftp-hpa 5.0

[Gernot Hillier]

Hi there.

On 19.11.2010 13:43, Charles Wilson wrote:
 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:
[...]
 There is no 5.0-3.  I reset to 5.0-1 since I changed the name of the
 package from your tftp-hpa- to tftp-  and tftp-server-.  I've made two
 releases. 5.0-1 and 5.0-2.  I don't see where you are getting any
 references to 5.0-3.

My tests were based on 5.0-2.

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 indefinitely, see? ;-)

 e.g. we already ensure that the directory is created, and included in
 the tarball.  If somebody wants to *modify* the installation *after*
 getting it running in its default mode, that's fine (e.g. by going to
 the Service Manager and modifying the args that way, for standalone; or
 editing /etc/inetd.d/tftp or /etc/xinetd.d/tftp).
[...]
 Hmm.  I wonder if cygrunsrv ought to have a --modify function, to go
 along with --install and --remove.

That would be indeed helpful if someone(tm) could implement this. :-)

 Well, the README also describes how to install manually using cygrunsrv,
 so interested parties could do this;
 
tftpd-config --standalone
 
 to get everything (including the user accounts) set up, and then
 
cygrunsrv -R tftpd
cygrunsrv -I tftpd  other args
 
 to reinstall with their preferred args.  But...I don't think that really
 needs to be documented as such.

No, it's pretty ok as it is.

 Unfortunately, the IPv6 support breaks things for me. tftpd doesn't
 start on my XP-64 box and says:

 tftpd: PID : cannot open IPv6 socket, disable IPv6: Address family
not support by protocol
 tftpd: PID : Cannot set nonblock flag on socket: Bad file
descriptor.
 tftpd: PID : `tftpd` service stopped, exit status: 71
 
 Well, that stinks.  Er...do you have IPv6 enabled at all?  It's not
 enabled by default on Server2003 (and since XP64 is based on that kernel...)

No, that's a default WinXP64 installation. And I doubt we could do this
in our product.

 Try this
 
1. Go to Start | Control Panel, and double-click
   Network Connections.
2. Right-click the network adapter on which you want
   to enable IPv6, and select Properties.
3. Click Install.
4. Select Protocol from the list of installation
   choices, and click Add.
5. Select Microsoft TCP/IP Version 6, and click OK.
 
 These instructions may be valid only on SP1 and above; I'm not sure.

Yes, that helped. Now your tftpd starts and seems to work according to a
quick test.

 To remove IPv6, do the same thing only click 'Uninstall' instead.

Yes, this brings back the error as expected.

 (*) The first bug is this (found by inspection):
 
 --- tftpd.c.orig  2010-11-19 07:39:42.20580 -0500
 +++ tftpd.c   2010-11-19 07:40:26.22900 -0500
 @@ -591,11 +591,12 @@
  syslog(LOG_ERR,
 cannot open IPv6 socket, disable IPv6: %m);
  }
 -}
 -set_socket_nonblock(fd6, 1);
 -memset(bindaddr6, 0, sizeof bindaddr6);
 -bindaddr6.sin6_family = AF_INET6;
 -bindaddr6.sin6_port = htons(IPPORT_TFTP);
 +} else {
 +set_socket_nonblock(fd6, 1);
 +memset(bindaddr6, 0, sizeof bindaddr6);
 +bindaddr6.sin6_family = AF_INET6;
 +bindaddr6.sin6_port = htons(IPPORT_TFTP);
 + }
  }
  #endif
  if (address) {

And that already fixed the issue! Seems it's now working stable w/o IPv6.

It surely still spits on startup:

tftpd: PID : cannot open IPv6 socket, disable IPv6: Address family
not supported by protocol

But I think this makes sense and we should leave it there.

 The problem is, in the IPv6 block (unlike the IPv4 block) it is possible
 to reach set_socket_nonblock(fd6, ...) when fd6 is invalid -- because
 you won't exit earlier when fd4 IS valid.  Whether this is enough to
 allow tftpd to keep working (in IPv4 mode) when IPv6 is unavailable, I
 don't know -- but to test that, you may need to uninstall IPv6 support
 if you installed it above.

Hmmm, looks like a clear upstream bug which is likely not triggered on
normal Linux as they always have IPv6 available. Do you like to upstream
those patches or shall I do that later on?

-- 
Gernot Hillier
Siemens AG, CT T DE IT 1, GTF System Architecture  Platforms

Re: [PATCH 1/3] Compare package versions, not setup.ini timestamps

[Christopher Faylor]

On Sun, Nov 07, 2010 at 03:45:31PM +, Jon TURNEY wrote:
On 06/11/2010 17:52, Christopher Faylor wrote:
 On Sat, Nov 06, 2010 at 05:05:13PM +, Jon TURNEY wrote:
 Currently, when two mirrors offer different versions of a package for a 
 stability
 level, the one from the setup.ini with the latest timestamp is chosen. This 
 works
 adequately when the mirrors are exactly that, so the one which has been 
 updated most
 recently has the most up-to-date version for all packages.  But this makes 
 it difficult
 to have an overlay, a site which offers updated versions of a subset of 
 packages,
 as there's no way to reliably ensure setup selects those updated versions 
 (without
 massaging the timestamps in the setup.ini files after downloading them)

 So, instead of comparing the setup.ini timestamps, compare the package 
 version numbers
 to determine which package is most recent.

 This shouldn't change the current behaviour in the simple case where only 
 one mirror
 is selected (provided no packages have negative version numbers).
 
 I'm not against this idea but I'd like to see what others think about
 this.

I agree that this kind of change needs some careful consideration.

 I know that cygwinports and other sites use setup.exe for their own
 purposes but setup.exe was never really intended (Red Hat itself not
 withstanding) to be used as anything other than a mechanism for
 installing the cygwin distribution.  So, while, again, I am not against
 this idea, I'd like to see what others think about this.  It doesn't
 seem like we'd lose any functionality if we adopted this change but I
 may be missing something.

I hope by inspection of the change to IniDBBuilderPackage.cc, it's not too
hard to satisfy yourself that the change should make no difference when a
single mirror is selected: while parsing setup.ini, instead of comparing the
timestamp against 0, we will be comparing against version 0-0 to see if a
package version should be used at a given trust level, the answer is still
always 'yes'.

As I mentioned before, you are losing the functionality of using negative
version numbers. :-) If anyone actually cared, this is probably fixable at the
cost of some complexity in the version number parser and comparator :-)

I don't think there is any other reduction in functionality.

It looks like there are no objections to this patch, so please check it in.

Thanks.

cgf

Re: [PATCH 2/3] Remove now-unused member variables for storage of timestamp of the setup the package version came from

[Christopher Faylor]

On Sat, Nov 06, 2010 at 05:05:14PM +, Jon TURNEY wrote:
2010-11-06  Jon TURNEY  jon.tur...@dronecode.org.uk

   * package_meta.h (packagemeta): Remove unused member variables for
   storing timestamp of the setup.ini that package version came from.
   * package_meta.cc (packagemeta): Ditto.

This is obvious if you apply the previous change so, please check in.

Thanks.

cgf

Re: [PATCH 0/5] Various small patches for setup.exe

[Christopher Faylor]

On Tue, Nov 09, 2010 at 01:29:42PM +, Jon TURNEY wrote:
Hopefully uncontroversial patches to fix a few small, mainly cosmetic
issues I noticed whilst working on setup.

Jon TURNEY (5):
  Make text refering to IE5 a bit more general
  Fix a misplaced PlaceDialog()
  Improve reporting of progress whilst parsing .ini file
  Set icon used by alt-tab task switcher for setup
  Canonicalize manually added mirror URLs to ensure they end with a '/'

 choose.cc|7 +++
 ini.cc   |8 +++-
 propsheet.cc |5 +
 res.rc   |4 ++--
 site.cc  |5 +
 5 files changed, 22 insertions(+), 7 deletions(-)

Sorry for the delay.  Please check in 1-4.  I think I still like the idea
of dropping the trailing slash if it's possible unless there's a directory
with a trailing slash on disk already.  As I said, the less of that % filename
stuff the better, IMO.

Thanks.

cgf

Re: [PATCH 3/3] Add the last element of URL path to site chooser, if interesting.

[Christopher Faylor]

On Tue, Nov 09, 2010 at 02:21:23PM +, Jon TURNEY wrote:
On 08/11/2010 05:54, Christopher Faylor wrote:
 On Sun, Nov 07, 2010 at 03:54:50PM +, Jon TURNEY wrote:
 On 06/11/2010 18:00, Christopher Faylor wrote:
 This is great, please check in.  I suspect that you're just trying a
 local mirror or something but if there are actually sites in the mirror
 list which are not proper FQDNs, please report them so that they can be
 fixed in the mirror database.

 Yes, you are correct.  There are no sites in the mirror list which aren't
 FQDNs. I was just fixing what happens when you add 
 'http://localhost/cygwin/'
 (or some other locally-known non-FQDN) to the mirror list.

 Just to be clear, you want me to check in the whole patch, and not just 
 that fix?
 
 Actually, on reflection, I don't see a great benefit to parsing the UFL.
 Why not just list the whole thing?  What would be more useful to the
 Cygwin project would be to list the other information like country.

As a start, the attached patch removes the URL parsing and just shows the
whole URL in the site chooser.

I think displaying multiple columns of information would require a grid
control of some sort.

I wanted to like this but the mirror box is too small to show all of the
long urls so it doesn't really solve the problem of providing the user
with enough information to make a selection.  I guess we could make the
box much bigger but I wonder if that would be adequate.

I guess I'll look at your original patch next to see how that does things.

cgf

Re: [ITP] tftp-hpa 5.0

[Gernot Hillier]

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 with your inhouse
 IPv4 clients without any trouble.

Done. Works with the patch in your last mail.

   2) uninstall the service and re-install using the new tftpd-config
 (--standalone?).  Make sure that still works (also, you probably want to
 install the test release of csih-0.9.2-1, for the complete XP64bit
 treatment).

Tested and found another small issue: the --standalone case branch has
a superfluous shift which breaks parsing of later params. Please remove.

And - it seems there are some ways to misspell csih_inform: :-)

/usr/bin/tftpd-config: line 175: cish_inform: command not found
/usr/bin/tftpd-config: line 176: csih_infomr: command not found

   3) Make sure this 5.0-2-src package also rebuilds.

Done.

   4) Plan to advertise tftp (-hpa) as nominally supporting IPv6 but in
 the announcement we'll say it's untested.
 
   5) Don't bother to say anything about the -m remap support. AFAICT,
 it's pretty straightforward.  Unless there is a giant undetected bug
 upstream, it should Just Work(tm) if anybody tries it.

Thanks for the hints!

Would you mind preparing a last package with the discussed changes, than
I could take over - or do you still have any TODOs?

 Release schedule:
   If you're happy with this, and confident that you can continue
 maintaining it from here out (don't worry; I'm not going to get hit by a
 bus -- but you'll be running point for tftp/tftpd) -- then we can plan
 the transition and rollout the new packages.
 
 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 time for (a) because I have to update inetutil's
 iu-config and syslog-config scripts; fortunately the major surgery --
 removing tftp/tftpd -- from inetutils is already done.

Just let me know then when you're ready.

-- 
Gernot

[PATCH] A setup.exe performance enhancement

[Jon TURNEY]

setup built with '-g -O0 -pg' flags, 'time ./setup.exe. -X -q' with both a
cygwin and a cygport mirror selected, but nothing to install, takes rather a
long time:
real5m52.001s
user0m0.046s
sys 0m0.015s

start of the the call graph output from gprof:

 granularity: each sample hit covers 4 byte(s) for 0.03% of 32.84 seconds
 
 index % timeself  childrencalled name
 0.302.626001/29801   
 IniDBBuilderPackage::buildPackageSource(std::string const, std::string 
 const) [16]
 1.18   10.39   23800/29801   
 _packageversion::sourcePackage() [2]
 [1] 44.11.48   13.01   29801 
 packagedb::findSource(PackageSpecification const) const [1]
 0.636.40 142604532/182305964 
 PackageSpecification::satisfies(packageversion const) const [4]
 0.182.86 118892225/153911466 std::setpackageversion, 
 std::lesspackageversion, std::allocatorpackageversion ::begin() const 
 [13]
 0.490.40 261489666/336261198 std::setpackageversion, 
 std::lesspackageversion, std::allocatorpackageversion ::end() const [35]
 0.530.32 118914935/153963867 bool 
 __gnu_cxx::operator!=packagemeta**, std::vectorpackagemeta*, 
 std::allocatorpackagemeta*  (__gnu_cxx::__normal_iteratorpackagemeta**, 
 std::vectorpackagemeta*, std::allocatorpackagemeta*   const, 
 __gnu_cxx::__normal_iteratorpackagemeta**, std::vectorpackagemeta*, 
 std::allocatorpackagemeta*   const) [36]
 0.190.13 118914935/153939634 
 std::vectorpackagemeta*, std::allocatorpackagemeta* ::end() [48]
 0.270.00 142597441/182313940 
 std::_Rb_tree_const_iteratorpackageversion::operator++() [50]
 0.230.00 380388982/422405973 
 __gnu_cxx::__normal_iteratorpackagemeta**, std::vectorpackagemeta*, 
 std::allocatorpackagemeta*  ::operator*() const [53]
 0.220.00 261489666/336225400 
 std::_Rb_tree_const_iteratorpackageversion::operator!=(std::_Rb_tree_const_iteratorpackageversion
  const) const [52]
 0.090.00 118885134/153990748 
 __gnu_cxx::__normal_iteratorpackagemeta**, std::vectorpackagemeta*, 
 std::allocatorpackagemeta*  ::operator++() [59]
 0.080.00 142604532/182395438 
 std::_Rb_tree_const_iteratorpackageversion::operator*() const [60]
 0.000.00   29801/6824761 std::vectorpackagemeta*, 
 std::allocatorpackagemeta* ::begin() [107]

I'm not sure if this data is accurate, as it seems to get the total runtime
rather wrong, but looking at the source packagedb::findSource() is terrible:
despite the fact that db.packages is maintained in alphabetic order, it
searches the entire vector for a match every time, which is going to give
O(n^2) behaviour.

The attached patch converts the package lists from a vector to a map, so we
can directly locate packages by name.  This reduces 'time ./setup.exe. -X -q'
for setup built with the same flags doing the same work to:
real0m15.142s
user0m0.031s
sys 0m0.031s
From 98764a4634945315ac35cd8191c7562b68f54038 Mon Sep 17 00:00:00 2001
From: Jon TURNEY jon.tur...@dronecode.org.uk
Date: Fri, 19 Nov 2010 15:27:42 +
Subject: [PATCH] Change package_db collection of packages from vector to a map 
so we can look things up in it quickly

Change package_db collection of packages from vector to a map so we can look 
things up in it quickly

This allows packagedb::findBinary() and packagedb::findSource() to be 
re-written to locate packages
by name rather than searching the entire set, which makes a big difference to 
total execution time.

2010-11-19  Jon TURNEY  jon.tur...@dronecode.org.uk

* IniDBBuilderPackage.cc (IniDBBuilderPackage): Remove db.packages 
vector
sorting.
(buildPackage, buildPackageSource): Change package collection from 
vector
to map.
* PickView.cc (setViewMode, init_headers, defaultTrust): Ditto.
* choose.cc (createListview, logResults, keepClicked)
(changeTrust): Ditto
* install.cc (do_install_thread): Ditto
* download.cc (do_download_thread): Ditto
* prereq.cc (isMet): Ditto
* package_meta.cc (ScanDownloadedFiles): Ditto
* package_db.h (packagedb): Ditto
* package_db.cc (packagedb, flush, markUnVisited, setExistence)
(fillMissingCategory): Ditto
(findBinary, findSource): Rewrite to locate packages in map rather than
searching the whole vector, for performance.
(ConnectedLoopFinder, doIt, visit): Rewrite to refer to package using a
packagemeta *, as an index into the vector of packages can no longer be
used.

Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
 IniDBBuilderPackage.cc |9 +--
 PickView.cc|   12 ++--
 choose.cc  |   25 ++--
 download.cc|8 +-
 install.cc |4 

Re: [PATCH 3/3] Add the last element of URL path to site chooser, if interesting.

[Christopher Faylor]

On Sat, Nov 06, 2010 at 05:05:15PM +, Jon TURNEY wrote:
Currently, if, for example, I manually add the site 
http://mirrors.kernel.org/sources.redhat.com/cygwinports/
to setup's mirror list, I get two indistinguishable entries named 
http://mirrors.kernel.org.

Furthermore, because the code to ensure the site just added is selected uses 
the string inside the list control
to locate elements, we end up with a random one of those two indistinguishable 
entries selected (usually the
previously existing one).  This problem also prevents the selected sites being 
correctly saved and restored
for the next setup run.

So, to make the site chooser list entries unique and distinguishable, add the 
last element of the URL path to
the site chooser, if it exists and isn't 'cygwin' (or some other alternatives 
used by current mirrors)

(Also fix the logic for identifying protocol and site name part of the URL to 
find the first '/' after a '//',
rather than the first '/' after a '.', to handle sitenames which aren't FQDNs 
correctly)

2010-11-06  Jon TURNEY  jon.tur...@dronecode.org.uk

   * site.cc (init): If interesting, Show the last element of URL, as well
   as the protocol and sitename in the site chooser

I like this better than my idea of showing the full URL.  Unless there
are objections (Corinna?) please check in.

Thanks.

(We really need to revisit how we handle mirrors at some point)

cgf

Re: Unbelievably obscure setup bug

[Corinna Vinschen]

On Nov 19 10:15, Christopher Faylor wrote:
 On Fri, Nov 19, 2010 at 02:20:13PM +, Jon TURNEY wrote:
 On 19/11/2010 13:36, Corinna Vinschen wrote:
  On Nov 19 13:23, Jon TURNEY wrote:
  On 19/11/2010 13:13, Corinna Vinschen wrote:
  The code in question was supposed to make sure that the order is always
  base-cygwin base-passwd [...] and that was the case so far.  Of
  course, given the obvious mishandling of the casecompare return value
  it's not clear why this ever worked.  Even more mysterious is the fact
  that the bugfix *breaks* this order.  Well, time to debug...
 
  Well, the bugfix breaks the order because visit() on base-cygwin 
  inserts it
  and all it's dependencies depth-first (ignoring loops).
  
  In theory base-cygwin has no dependecies.  Here are the setup.hint
  snippets:
  
base-cygwin:
  
  category: Base
  
base-passwd:
  
  requires: base-cygwin
  category: Base
  noautodep: cygwin
  
cygwin:
  
  requires: base-passwd base-cygwin
  noautodep: _update-info-dir
  
  I think that explains it.  The problem in base-cygwin is that it depends
  on cygwin since the noautodep: cygwin is missing.  So there's a
  dependency chain which goes base-cygwin - cygwin - base-passwd.
  That's how this order is generated.  If we add noautodep: cygwin to
  base-cygwin, it would really have no dependency and should always become
  the first package.
 
 I wasn't aware of the existence of noautodep. Now it all makes sense :-)
 
 I believe that I actually added this so that we wouldn't need to special-case
 packages in setup.

For some reason, even if I remove the cygwin dependency from base-cygwin
in setup.ini, I still get the base-passwd cygwin base-cygwin dependency
order.  Hmm.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

Re: [PATCH 3/3] Add the last element of URL path to site chooser, if interesting.

[Corinna Vinschen]

On Nov 19 11:07, Christopher Faylor wrote:
 On Sat, Nov 06, 2010 at 05:05:15PM +, Jon TURNEY wrote:
 Currently, if, for example, I manually add the site 
 http://mirrors.kernel.org/sources.redhat.com/cygwinports/
 to setup's mirror list, I get two indistinguishable entries named 
 http://mirrors.kernel.org.
 
 Furthermore, because the code to ensure the site just added is selected uses 
 the string inside the list control
 to locate elements, we end up with a random one of those two 
 indistinguishable entries selected (usually the
 previously existing one).  This problem also prevents the selected sites 
 being correctly saved and restored
 for the next setup run.
 
 So, to make the site chooser list entries unique and distinguishable, add 
 the last element of the URL path to
 the site chooser, if it exists and isn't 'cygwin' (or some other 
 alternatives used by current mirrors)
 
 (Also fix the logic for identifying protocol and site name part of the URL 
 to find the first '/' after a '//',
 rather than the first '/' after a '.', to handle sitenames which aren't 
 FQDNs correctly)
 
 2010-11-06  Jon TURNEY  jon.tur...@dronecode.org.uk
 
  * site.cc (init): If interesting, Show the last element of URL, as well
  as the protocol and sitename in the site chooser
 
 I like this better than my idea of showing the full URL.  Unless there
 are objections (Corinna?) please check in.

No objections.  Just go ahead.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

Re: Unbelievably obscure setup bug

[David Sastre]

On Fri, Nov 19, 2010 at 06:11:57PM +0100, Corinna Vinschen wrote:
 On Nov 19 10:15, Christopher Faylor wrote:
  On Fri, Nov 19, 2010 at 02:20:13PM +, Jon TURNEY wrote:
  On 19/11/2010 13:36, Corinna Vinschen wrote:
   On Nov 19 13:23, Jon TURNEY wrote:
   On 19/11/2010 13:13, Corinna Vinschen wrote:
   The code in question was supposed to make sure that the order is always
   base-cygwin base-passwd [...] and that was the case so far.  Of
   course, given the obvious mishandling of the casecompare return value
   it's not clear why this ever worked.  Even more mysterious is the fact
   that the bugfix *breaks* this order.  Well, time to debug...
  
   Well, the bugfix breaks the order because visit() on base-cygwin 
   inserts it
   and all it's dependencies depth-first (ignoring loops).
   
   In theory base-cygwin has no dependecies.  Here are the setup.hint
   snippets:
   
 base-cygwin:
   
   category: Base
   
 base-passwd:
   
   requires: base-cygwin
   category: Base
   noautodep: cygwin
   
 cygwin:
   
   requires: base-passwd base-cygwin
   noautodep: _update-info-dir
   
   I think that explains it.  The problem in base-cygwin is that it depends
   on cygwin since the noautodep: cygwin is missing.  So there's a
   dependency chain which goes base-cygwin - cygwin - base-passwd.
   That's how this order is generated.  If we add noautodep: cygwin to
   base-cygwin, it would really have no dependency and should always become
   the first package.
  
  I wasn't aware of the existence of noautodep. Now it all makes sense :-)
  
  I believe that I actually added this so that we wouldn't need to 
  special-case
  packages in setup.
 
 For some reason, even if I remove the cygwin dependency from base-cygwin
 in setup.ini, I still get the base-passwd cygwin base-cygwin dependency
 order.  Hmm.

EMBI, 
Is there a chance that this bug provides an opportunity to merge
base-files and base-passwd? I was told it was difficult (or at least
not recommended) because of a dependency chain issue.

Please excuse me if this is non-sense.

-- 
Huella de clave primaria: 0FDA C36F F110 54F4 D42B  D0EB 617D 396C 448B 31EB


signature.asc
Description: Digital signature

Re: [PATCH] A setup.exe performance enhancement

[Christopher Faylor]

On Fri, Nov 19, 2010 at 04:07:23PM +, Jon TURNEY wrote:
Change package_db collection of packages from vector to a map so we can look 
things up in it quickly

This allows packagedb::findBinary() and packagedb::findSource() to be 
re-written to locate packages
by name rather than searching the entire set, which makes a big difference to 
total execution time.

2010-11-19  Jon TURNEY  jon.tur...@dronecode.org.uk

   * IniDBBuilderPackage.cc (IniDBBuilderPackage): Remove db.packages 
 vector
   sorting.
   (buildPackage, buildPackageSource): Change package collection from 
 vector
   to map.
   * PickView.cc (setViewMode, init_headers, defaultTrust): Ditto.
   * choose.cc (createListview, logResults, keepClicked)
   (changeTrust): Ditto
   * install.cc (do_install_thread): Ditto
   * download.cc (do_download_thread): Ditto
   * prereq.cc (isMet): Ditto
   * package_meta.cc (ScanDownloadedFiles): Ditto
   * package_db.h (packagedb): Ditto
   * package_db.cc (packagedb, flush, markUnVisited, setExistence)
   (fillMissingCategory): Ditto
   (findBinary, findSource): Rewrite to locate packages in map rather than
   searching the whole vector, for performance.
   (ConnectedLoopFinder, doIt, visit): Rewrite to refer to package using a
   packagemeta *, as an index into the vector of packages can no longer be
   used.

I was just marvelling today at the inexplicable pauses in setup.exe.  Will this
reduce the amount of time that setup.exe takes parsing setup.ini?

Assuming that the answer is ok, I'm happy with this change but I'd like to get
Corinna's ok, too since it is sort of invasive.

cgf

Re: [ITP] tftp-hpa 5.0

[Charles Wilson]

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 indefinitely, see? ;-)

I'm going to nod my head in agreement...it's important that the docu of
a particular release actually agree with the version numbering OF that
release.  It the current 5.0-2 doesn't, that's a mistake.

However, it appears that a 5.0-3 needs to be released anyway, with the
patch for fd6 handling, so...

 Hmm.  I wonder if cygrunsrv ought to have a --modify function, to go
 along with --install and --remove.
 
 That would be indeed helpful if someone(tm) could implement this. :-)

I'll put it on the TODO list...

 But...I don't think that really
 needs to be documented as such.
 
 No, it's [the README, related to standalone installs] pretty ok as it is.

Ack.

 Well, that stinks.  Er...do you have IPv6 enabled at all?  It's not
 enabled by default on Server2003 (and since XP64 is based on that kernel...)
 
 No, that's a default WinXP64 installation. And I doubt we could do this
 in our product.

Understood.

 Try this

1. Go to Start | Control Panel, and double-click
   Network Connections.
2. Right-click the network adapter on which you want
   to enable IPv6, and select Properties.
3. Click Install.
4. Select Protocol from the list of installation
   choices, and click Add.
5. Select Microsoft TCP/IP Version 6, and click OK.

 These instructions may be valid only on SP1 and above; I'm not sure.
 
 Yes, that helped. Now your tftpd starts and seems to work according to a
 quick test.
 
 To remove IPv6, do the same thing only click 'Uninstall' instead.
 
 Yes, this brings back the error as expected.

That's good news...at least things kinda make sense.

 (*) The first bug is this (found by inspection):

 --- tftpd.c.orig 2010-11-19 07:39:42.20580 -0500
 +++ tftpd.c  2010-11-19 07:40:26.22900 -0500
 @@ -591,11 +591,12 @@
  syslog(LOG_ERR,
 cannot open IPv6 socket, disable IPv6: %m);
  }
 -}
 -set_socket_nonblock(fd6, 1);
 -memset(bindaddr6, 0, sizeof bindaddr6);
 -bindaddr6.sin6_family = AF_INET6;
 -bindaddr6.sin6_port = htons(IPPORT_TFTP);
 +} else {
 +set_socket_nonblock(fd6, 1);
 +memset(bindaddr6, 0, sizeof bindaddr6);
 +bindaddr6.sin6_family = AF_INET6;
 +bindaddr6.sin6_port = htons(IPPORT_TFTP);
 +}
  }
  #endif
  if (address) {
 
 And that already fixed the issue! Seems it's now working stable w/o IPv6.

Wonderful.  See my reply to your other email.

 It surely still spits on startup:
 
 tftpd: PID : cannot open IPv6 socket, disable IPv6: Address family
 not supported by protocol
 
 But I think this makes sense and we should leave it there.

Right.  This only happens (I think) in standalone mode, and end users
can always use the --ipv4 option to explicitly disable ipv6 support.

 Hmmm, looks like a clear upstream bug which is likely not triggered on
 normal Linux as they always have IPv6 available. 

I think so too.

 Do you like to upstream
 those patches or shall I do that later on?

Well, *most* of the cygwin patches for networking daemons (inetutils et
al) are very very platform specific, so I don't really tend to send them
upstream unless they can be presented in a clean way (e.g. don't break
other platforms, for intance).  For example, I wouldn't think of sending
either of these upstream:

01-rename-server.patch (they like their current naming convention)
02-missing-header.patch (zomg!!1!! its s ugly!!)

but these two probably make sense to (eventually) send up:

03-silence-warnings.patch
04-cygwin-select-on-nonblocking-works.patch


The little fd6 patch, tho, seems like a universal bug and the fix is
rather obvious -- so it should probably go upstream.  Since you're going
to be the maintainer, I think I'll let you do the honors.

--
Chuck

Re: [ITP] tftp-hpa 5.0

[Charles Wilson]

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 with your inhouse
 IPv4 clients without any trouble.
 
 Done. Works with the patch in your last mail.

Great!

   2) uninstall the service and re-install using the new tftpd-config
 (--standalone?).  Make sure that still works (also, you probably want to
 install the test release of csih-0.9.2-1, for the complete XP64bit
 treatment).
 
 Tested and found another small issue: the --standalone case branch has
 a superfluous shift which breaks parsing of later params. Please remove.

Fixed in 5.0-3.

 And - it seems there are some ways to misspell csih_inform: :-)
 
 /usr/bin/tftpd-config: line 175: cish_inform: command not found
 /usr/bin/tftpd-config: line 176: csih_infomr: command not found

Fixed in 5.0-3.

   3) Make sure this 5.0-2-src package also rebuilds.
 
 Done.

Good.

   4) Plan to advertise tftp (-hpa) as nominally supporting IPv6 but in
 the announcement we'll say it's untested.

   5) Don't bother to say anything about the -m remap support. AFAICT,
 it's pretty straightforward.  Unless there is a giant undetected bug
 upstream, it should Just Work(tm) if anybody tries it.
 
 Thanks for the hints!

See attachment for a sample announcement message.

 Would you mind preparing a last package with the discussed changes, than
 I could take over - or do you still have any TODOs?

No more TODOs on my end (except those related to /inetutils/ not
/tftp/).  Here's 5.0-3:

http://cygwin.cwilson.fastmail.fm/tftp-5.0-3-src.tar.bz2
http://cygwin.cwilson.fastmail.fm/tftp-5.0-3.tar.bz2
http://cygwin.cwilson.fastmail.fm/tftp-server-5.0-3.tar.bz2

 Release schedule:
   If you're happy with this, and confident that you can continue
 maintaining it from here out (don't worry; I'm not going to get hit by a
 bus -- but you'll be running point for tftp/tftpd) -- then we can plan
 the transition and rollout the new packages.

 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 time for (a) because I have to update inetutil's
 iu-config and syslog-config scripts; fortunately the major surgery --
 removing tftp/tftpd -- from inetutils is already done.
 
 Just let me know then when you're ready.

Will do.  BTW, just so that the checksums are all consistent, you should
probably rebuild 5.0-3 yourself, and then upload /your/ tarballs
somewhere, so that we can make sure that /your/ versions get uploaded to
sourceware.

--
Chuck


tftp-5.0-3.announce.bz2
Description: Binary data

Re: Does gvim functions correctly for any body?

[Jon TURNEY]

On 10/11/2010 02:52, Rodrigo Medina wrote:
 Some time ago I have reported a problem with gvim,
 it stops because it receives a  SEGV signal when the
 OPEN menu-item is selected. I have installed the new
 XWin server, but the problem persists.
 Does gvim functions correctly for any body?

Probably not, it crashes in the same way for me.

This is very like a problem in gvim or one of the GNOME libraries it depends
upon, which can't be fixed in the X server.

Interestingly 'gdb --args gvim -f' doesn't show the problem (so gvim -f might
be a work around).  Attaching to a running gvim with gdb --pid= and then
provoking the crash gives the following backtrace

 (gdb) bt
 #0  0x76bf1ef4 in ?? ()
 #1  0x6ff41795 in g_module_symbol () from /usr/bin/cyggmodule-2.0-0.dll
 #2  0x6ff41d64 in g_module_open () from /usr/bin/cyggmodule-2.0-0.dll
 #3  0x68169cd5 in g_io_modules_scan_all_in_directory () from 
 /usr/bin/cyggio-2.0-0.dll
 #4  0x6e5a3db6 in g_type_module_use () from /usr/bin/cyggobject-2.0-0.dll
 #5  0x68169902 in g_io_modules_scan_all_in_directory () from 
 /usr/bin/cyggio-2.0-0.dll
 #6  0x68169b7e in g_io_modules_scan_all_in_directory () from 
 /usr/bin/cyggio-2.0-0.dll
 #7  0x68180e2b in g_vfs_is_active () from /usr/bin/cyggio-2.0-0.dll
 #8  0x6aa8cdde in g_once_impl () from /usr/bin/cygglib-2.0-0.dll
 #9  0x68180a72 in g_vfs_get_default () from /usr/bin/cyggio-2.0-0.dll
 #10 0x68150893 in g_file_new_for_path () from /usr/bin/cyggio-2.0-0.dll
 #11 0x6af6044f in gtk_recent_manager_get_for_screen () from 
 /usr/bin/cyggtk-x11-2.0-0.dll
 #12 0x6e588cd6 in g_object_freeze_notify () from /usr/bin/cyggobject-2.0-0.dll
 #13 0x6e58a246 in g_object_newv () from /usr/bin/cyggobject-2.0-0.dll
 #14 0x6e58a8f0 in g_object_new () from /usr/bin/cyggobject-2.0-0.dll
 #15 0x6af5ff1b in gtk_recent_manager_new () from /usr/bin/cyggtk-x11-2.0-0.dll
 #16 0x6af5ff3c in gtk_recent_manager_get_default () from 
 /usr/bin/cyggtk-x11-2.0-0.dll
 #17 0x6aebb649 in gtk_file_chooser_button_new () from 
 /usr/bin/cyggtk-x11-2.0-0.dll
 #18 0x6e5a2dd3 in g_type_create_instance () from /usr/bin/cyggobject-2.0-0.dll
 #19 0x6e588bca in g_object_freeze_notify () from /usr/bin/cyggobject-2.0-0.dll
 #20 0x6aebb7c5 in gtk_file_chooser_button_new () from 
 /usr/bin/cyggtk-x11-2.0-0.dll
 #21 0x6e58a246 in g_object_newv () from /usr/bin/cyggobject-2.0-0.dll
 #22 0x6e58a8f0 in g_object_new () from /usr/bin/cyggobject-2.0-0.dll
 #23 0x6aebcf1b in gtk_file_chooser_button_new () from 
 /usr/bin/cyggtk-x11-2.0-0.dll
 #24 0x6aec1873 in gtk_file_chooser_widget_new () from 
 /usr/bin/cyggtk-x11-2.0-0.dll
 #25 0x6e58a246 in g_object_newv () from /usr/bin/cyggobject-2.0-0.dll
 #26 0x6e58a8f0 in g_object_new () from /usr/bin/cyggobject-2.0-0.dll
 #27 0x6aebd565 in gtk_file_chooser_dialog_new () from 
 /usr/bin/cyggtk-x11-2.0-0.dll
 #28 0x6e58a246 in g_object_newv () from /usr/bin/cyggobject-2.0-0.dll
 #29 0x6e58a7a9 in g_object_new_valist () from /usr/bin/cyggobject-2.0-0.dll
 #30 0x6e58a8ce in g_object_new () from /usr/bin/cyggobject-2.0-0.dll
 #31 0x6aebd160 in gtk_file_chooser_dialog_get_type () from 
 /usr/bin/cyggtk-x11-2.0-0.dll
 #32 0x6aebd209 in gtk_file_chooser_dialog_new () from 
 /usr/bin/cyggtk-x11-2.0-0.dll
 #33 0x0055a46a in ?? ()
 #34 0x0057ff09 in ?? ()
 #35 0x0071d000 in ?? ()
 #36 0x in ?? ()

You might try reverting to previous versions of gvim or GNOME libraries to try
to narrow down where the problem was introduced.

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: X server with multiple Windows desktops

[Jon TURNEY]

On 16/11/2010 20:37, Jim Reisert AD1C wrote:
 I'm running this program to give myself multiple Windows (7) desktops:
 
   http://technet.microsoft.com/en-us/sysinternals/cc817881.aspx
   Desktops 1.01
   Copyright (c) 2006-2010 Mark Russinovich and Bryce Cogswell
   Sysinternals - www.sysinternals.com
 
 I started the Cygwin X server on the 1st desktop, but then tried to
 open a new Xterm from the 2nd desktop.  It of course landed on the
 first one.
 
 Is there any way for the X server to recognize these as four different
 desktops, so I could, for example, open an Xterm explicitly on a given
 desktop, for example:
 
xterm -display localhost:0.1

From reading the description of how that works, I would guess you should be
able to start an instance of the X server with a different display number in
each virtual desktop.

e.g. in your 2nd desktop, start X (however you do that) with :1, and then use
xterm -display :1 to connect to it.

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: xorg-server-1.9.2-1 Fullscreen Issue

[Jon TURNEY]

On 18/11/2010 12:33, Frederick Hansen wrote:
 Just FYI, after upgrading to xorg-server 1.9.2, any attempt to run in 
 fullscreen results in an error.  Downgrading to version 1.8.2 seems to 
 correct the issue.  Running either version in multiwindow also works.
 
 The contents of Xwin.log are shown below:
 
 
 Welcome to the XWin X Server
 Vendor: The Cygwin/X Project
 Release: 1.9.2.0 (10902000)
 Build Date: 2010-11-03
 
 XWin was started with the following command line:
 
 /usr/bin/XWin -fullscreen -depth 8 -clipboard -silent-dup-error 

[snip]
 [ 30091.406] (EE) XKB: Could not invoke xkbcomp
 [ 30091.406] (EE) XKB: Couldn't compile keymap
 [ 30091.406] XKB: Failed to compile keymap
 [ 30091.406] Keyboard initialization failed. This could be a missing or 
 incorrect setup of xkeyboard-config.
 [ 30091.406] 
 Fatal server error:
 [ 30091.406] Failed to activate core devices.

Interesting.

I can start X in fullscreen without problems using the same options.

Are you sure that removing -fullscreen allows the X server to start properly?
 This kind of failure (invoking xkbcomp) is usually caused by BLODA or rebase
problems preventing xkbcomp from being spawned.  It would be unusual for that
to only occur with certain options, but I guess it is possible.

-- 
Jon TURNEY
Volunteer Cygwin/X X Server maintainer

--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://x.cygwin.com/docs/
FAQ:   http://x.cygwin.com/docs/faq/

Re: File format problem after updatin to 1.7.1 - solved

[Paul]

Jeremy Bopp jeremy at bopp.net writes:

  http://cygwin.com/cygwin-ug-net/using.html#mount-table
 
 Now that I'm looking specifically for this issue in the linked
 documentation, I see that there *is* a way to override the root
 mountpoint clearly described there.

Well Jeremy, it would have been helpful and accomodating of you to have jotted 
down the relevent info in the reply, rather than just simply saying I know.

For everyone else, the clue is the override option.

So put this in /etc/fstab:
C:/cygwin/bin /usr/bin ntfs text,override
C:/cygwin/lib /usr/lib ntfs text,override
C:/cygwin / ntfs text,override

This sets everything to textmode. We use dos based editors and so we need this 
as everytime we edit it a script file somewhere in the system, it gets written 
as a dos mode file.

If you don't need eveything changed, then omit the appropriate lines as 
necessary.

Hope this helps everyone

Paul.




--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: screen-4.0.3-6 (test release)

[Andrew Schulman]

A new version of screen, 4.0.3-6, is available in the Cygwin distribution.
This is a test release, that includes the experimental vertical split
feature (http://fungi.yuggoth.org/vsp4s/).  Because this is a test release,
you'll have to click through the list of available versions of screen in
setup.exe in order to see and install it.

The purpose of this release is to allow Cygwin users to try out the
vertical split feature.  Many people seem to have been using this feature
happily for a long time, and most distros seem to include it in their
screen packages now.  However, the feature is undocumented AFAIK, and I
myself had no success in using it.  So, if you're interested in this
feature, please try it out and let me know (1) how well it works for you;
and (2) how it works, so I can include that information in README.Cygwin.
I'll include the feature in a new current release if and only if enough
people tell me that they like it and it works.

screen is a terminal multiplexer and window manager that runs several
separate 'screens' on a single physical character-based terminal.  Each
virtual terminal emulates a DEC VT100 plus several ANSI X3.64 and ISO 2022
functions.  You can create multiple windows with any programs in them, kill
the current window, switch between windows or copy text between them, view
a list of active windows, rename windows, view scrollback history, and
more.  You can detach your session and even log out if you wish; your
programs will keep running, and you can reattach later, maybe when logged
in from a different host.

Andrew E. Schulman


***


To update your installation, click on the Install Cygwin now link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the List-Unsubscribe:  tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com  

If you need more information on unsubscribing, start reading here: 

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: sshd problem with recent snapshots

[Corinna Vinschen]

On Nov 16 09:33, Ken Brown wrote:
 On 11/16/2010 8:58 AM, Corinna Vinschen wrote:
  Is there a chance that your service entires still point to a cygrunsrv
  under C:\cygwin instead of D:\cygwin-1.7?
 
 No.  The installation in C:\cygwin is newer than the one in D:\cygwin-1.7; 
 it's just a small installation that I sometimes use for testing purposes, and 
 it doesn't even have cygrunsrv installed.  In any case, that wouldn't explain 
 why reverting to the 09-12 snapshot fixes the problem.  Are you sure there's 
 nothing in the 09-17 Changelog that could account for this?  There do seem to 
 be some network-related changes, though I don't claim to understand them:
 
   * path.cc (symlink_info::check_reparse_point): Add comment.
   (symlink_info::check): Fetch FileNetworkOpenInformation rather than
   FileBasicInformation throughout, except on NFS.  Explain why.  Store
   FILE_NETWORK_OPEN_INFORMATION in conv_hdl.  Remove
   FILE_ATTRIBUTE_DIRECTORY attribute in conv_hdl for reparse point
   symlinks.
   * path.h (class path_conv_handle): Add FILE_NETWORK_OPEN_INFORMATION
   member _fnoi.
   (path_conv_handle::fnoi): New accessor method for _fnoi.
   (path_conv::fnoi): New accessor method for cubv_hdl._fnoi.

These changes only affect files, not ttys.

The failing chmod(/dev/tty1, 0622) is actually trying to change the
permissions on internal objects, like events, mutexes, and pipes, which
together constitute a tty/pty.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: File format problem after updatin to 1.7.1 - solved

[Jeremy Bopp]

On 11/17/2010 09:55 PM, Paul wrote:
 Jeremy Bopp jeremy at bopp.net writes:
 
 http://cygwin.com/cygwin-ug-net/using.html#mount-table

 Now that I'm looking specifically for this issue in the linked
 documentation, I see that there *is* a way to override the root
 mountpoint clearly described there.
 
 Well Jeremy, it would have been helpful and accomodating of you to have 
 jotted 
 down the relevent info in the reply, rather than just simply saying I know.

Well, Paul, I referred to the official source of information in the
hopes that the list archives would not be polluted with contradictory
information if those details ever change again.  It's not as if
following the link and reading the documentation is particularly
difficult.  It certainly wasn't an attempt to be unhelpful or obtuse,
but you can go on believing whatever you like.

Have fun opening other old threads and chastising random people.

-Jeremy

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Win 7 sshd help

[Kirby Bakken]

Help.

I recently installed cygwin w/sshd packages on my Win7 pro PC.  I've 
gotten ssh to work both with localhost, and with the LAN IP address.


However, trying to ssh from 'outside' my router doesn't work.  I CAN ssh 
to my linux box.  Then I change the port-forward in the router to my 
Win7 box, and I got 'permission denied' after the password prompt.  
After much fiddling, the /etc/host.allow/deny files have somewhere along 
the line disappeared.  Now, I get a timeout...


Questions:

1) are the host.allow and deny files required?
2) are there any known problems with sshd running on Win7?

Before I 'munged' my installation and the allow/deny files diisappeared, 
I had tried su and login, and got permission denied errors


I've un-installed sshd and re-installed it several times

The /var/log/sshd.log file is oddly empty...  Trying to run 
/usr/sbin/sshd  and not as a service hasn't worked.


Ideas?  Suggestions?

Kirby

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Win 7 sshd help

[Bryan]

On Fri, Nov 19, 2010 at 15:17, Kirby Bakken bakke...@gmail.com wrote:
 Help.

 I recently installed cygwin w/sshd packages on my Win7 pro PC.  I've gotten
 ssh to work both with localhost, and with the LAN IP address.

 However, trying to ssh from 'outside' my router doesn't work.  I CAN ssh to
 my linux box.  Then I change the port-forward in the router to my Win7 box,
 and I got 'permission denied' after the password prompt.  After much
 fiddling, the /etc/host.allow/deny files have somewhere along the line
 disappeared.  Now, I get a timeout...

 Questions:

 1) are the host.allow and deny files required?

hosts.allow and hosts.deny only work if you compiled using tcp_wrappers

 2) are there any known problems with sshd running on Win7?


I use SSHd on several Windows 7 machines (when I'm not on my native
OpenBSD laptop)

 Before I 'munged' my installation and the allow/deny files diisappeared, I
 had tried su and login, and got permission denied errors

 I've un-installed sshd and re-installed it several times

 The /var/log/sshd.log file is oddly empty...  Trying to run /usr/sbin/sshd
  and not as a service hasn't worked.

 Ideas?  Suggestions?

 Kirby


Disable your windows 7 firewall, or make it so that it passes port 22.
 If you are remote, make sure your ISP isn't blocking port 22 inbound
to your router.  I had an ISP that blocked a lot of ports below 1024.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

[ANNOUNCEMENT] Updated: csih-0.9.2-1

[Charles Wilson]

csih (cygwin-service-installation-helper) provides a library
of shell functions that can be used by other cygwin packages
that provide servers and daemons. It can assist in various
service installation tasks, such as:

* identifying the underlying Windows OS
* detecting whether a privileged user exists and what its
  name is (that is, a user account with enhanced privileges
  necessary for some services)
* creating a privileged user if one doesn't already exist
  (assuming the caller has permissions to create new users)
* creating normal users
* obtaining the (localized) name of well known accounts
  (Guest, Administrator)

It is currently used by inetutils(iu-config, syslogd-config),
openssh (ssh-host-config, ssh-user-config), sspi(sspi-config),
sysvinit(init-config), and various others.  csih should not be
used directly; instead, config scripts like the ones mentioned
above should 'source' the csih script, and then use the
functions provided.

This is bugfix release. It is specific for cygwin-1.7,
and will not operate correctly if installed under cygwin-1.5.
For legacy cygwin installations, use csih-0.2.x. As cygwin-1.7
requires WinNT or better, csih-0.9.x will also report an error
if used on legacy (Win9x) systems.

[[ cygwin binary utilities compiled using gcc-4.3.4-3 ]]
[[ native binary utilities compiled using gcc-4.3.4-3 and 
gcc-mingw-core-20050522-1 ]]

CHANGES (since 0.9.1-1)

o Remove all vestiges of pre-NT support.
o Update user messages and comments to accurately reflect handling of
  Windows XP 64bit. Note that this means 'csih_is_nt2003' is now
  /documented/ to return true for Windows XP 64, in additional to
  the expected Windows NT Server 2003 and above. This is necessary
  because XP64 shares the same kernel as NT2003, and thus both display
  similar behavior regarding the privileges of the built-in SYSTEM
  account.
o getVolInfo uses cygwin_create_path instead of deprecated
  cygwin_conv_to_full_win32_path.

-- 
Charles Wilson
volunteer csih maintainer for cygwin



To update your installation, click on the Install Cygwin now link
on the http://cygwin.com/ web page.  This downloads setup.exe to
your system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the List-Unsubscribe:  tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is
available starting at this URL.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Updated: screen-4.0.3-6 (test release)

[Andrew Schulman]

A new version of screen, 4.0.3-6, is available in the Cygwin distribution.
This is a test release, that includes the experimental vertical split
feature (http://fungi.yuggoth.org/vsp4s/).  Because this is a test release,
you'll have to click through the list of available versions of screen in
setup.exe in order to see and install it.

The purpose of this release is to allow Cygwin users to try out the
vertical split feature.  Many people seem to have been using this feature
happily for a long time, and most distros seem to include it in their
screen packages now.  However, the feature is undocumented AFAIK, and I
myself had no success in using it.  So, if you're interested in this
feature, please try it out and let me know (1) how well it works for you;
and (2) how it works, so I can include that information in README.Cygwin.
I'll include the feature in a new current release if and only if enough
people tell me that they like it and it works.

screen is a terminal multiplexer and window manager that runs several
separate 'screens' on a single physical character-based terminal.  Each
virtual terminal emulates a DEC VT100 plus several ANSI X3.64 and ISO 2022
functions.  You can create multiple windows with any programs in them, kill
the current window, switch between windows or copy text between them, view
a list of active windows, rename windows, view scrollback history, and
more.  You can detach your session and even log out if you wish; your
programs will keep running, and you can reattach later, maybe when logged
in from a different host.

Andrew E. Schulman


***


To update your installation, click on the Install Cygwin now link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the List-Unsubscribe:  tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com  

If you need more information on unsubscribing, start reading here: 

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

Updated: csih-0.9.2-1

[Charles Wilson]

csih (cygwin-service-installation-helper) provides a library
of shell functions that can be used by other cygwin packages
that provide servers and daemons. It can assist in various
service installation tasks, such as:

* identifying the underlying Windows OS
* detecting whether a privileged user exists and what its
  name is (that is, a user account with enhanced privileges
  necessary for some services)
* creating a privileged user if one doesn't already exist
  (assuming the caller has permissions to create new users)
* creating normal users
* obtaining the (localized) name of well known accounts
  (Guest, Administrator)

It is currently used by inetutils(iu-config, syslogd-config),
openssh (ssh-host-config, ssh-user-config), sspi(sspi-config),
sysvinit(init-config), and various others.  csih should not be
used directly; instead, config scripts like the ones mentioned
above should 'source' the csih script, and then use the
functions provided.

This is bugfix release. It is specific for cygwin-1.7,
and will not operate correctly if installed under cygwin-1.5.
For legacy cygwin installations, use csih-0.2.x. As cygwin-1.7
requires WinNT or better, csih-0.9.x will also report an error
if used on legacy (Win9x) systems.

[[ cygwin binary utilities compiled using gcc-4.3.4-3 ]]
[[ native binary utilities compiled using gcc-4.3.4-3 and 
gcc-mingw-core-20050522-1 ]]

CHANGES (since 0.9.1-1)

o Remove all vestiges of pre-NT support.
o Update user messages and comments to accurately reflect handling of
  Windows XP 64bit. Note that this means 'csih_is_nt2003' is now
  /documented/ to return true for Windows XP 64, in additional to
  the expected Windows NT Server 2003 and above. This is necessary
  because XP64 shares the same kernel as NT2003, and thus both display
  similar behavior regarding the privileges of the built-in SYSTEM
  account.
o getVolInfo uses cygwin_create_path instead of deprecated
  cygwin_conv_to_full_win32_path.

-- 
Charles Wilson
volunteer csih maintainer for cygwin



To update your installation, click on the Install Cygwin now link
on the http://cygwin.com/ web page.  This downloads setup.exe to
your system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the List-Unsubscribe:  tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain@cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is
available starting at this URL.