Setup patch to keep test version if test version installed

Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 3545 bytes --]

Hi guys,

I need a bit of feedback.

One detail bugging me (and probably others as well) in Setup is this.
If I chose to install a test version of a package, and then start Setup
again, Setup will default to the current version of the package again.
If I'm just a bit careless, I'll overwrite my test version with the curr
version of this package.  And another Setup run will be required to fix
that...

So I was looking into Setup how to change the default behaviour to
something less annoying.  Unfortunately Setup is missing information,
especially if the installed package is a prev, curr, or test version.

But it has a version check mechanism.  And by commen sense, test
versions are always higher than curr versions.  So I came up with the
following change.

Instead of always defaulting to the curr version, Setup now checks if
the installed version of a package is higher than the curr version of
the package.  If so, and if a test version exists for this package, it
will choose the test version by default.  A welcome side effect of this
is, if the test version becomes the curr version, the installed version
will not be higher than curr, thus the curr version will be chosen
again.

Example:

  foo-1.22-1 is installed
  foo-1.23-1 is curr
  foo-1.24-1 is test
  ==> Setup chooses 1.23-1 as default.

User installs 1.24-1.  Next Setup run:

  foo-1.24-1 is installed
  foo-1.23-1 is curr
  foo-1.24-1 is test
  ==> Setup chooses 1.24-1 as default.

Maintainer releases a new test version:
 
  foo-1.24-1 is installed
  foo-1.23-1 is curr
  foo-1.24-2 is test
  ==> Setup chooses 1.24-2 as default.

Maintainer releases test version as curr version:

  foo-1.24-2 is installed
  foo-1.24-2 is curr
  ==> Setup chooses 1.24-2 as default.

Maintainer releases new test version:

  foo-1.24-2 is installed
  foo-1.24-2 is curr
  foo-1.25-1 is test
  ==> Setup chooses 1.24-2 as default.

Question:  Does that make sense?  From my local testing this behaviour
is much less annoying than the current behaviour, and the required code
changes are minimal.  The trustp function is used in other circumstances
as well, but the change won't kill these other usages at all.

Index: package_meta.cc
===================================================================
RCS file: /cvs/cygwin-apps/setup/package_meta.cc,v
retrieving revision 2.64
diff -u -p -r2.64 package_meta.cc
--- package_meta.cc	6 Dec 2014 13:38:54 -0000	2.64
+++ package_meta.cc	25 Jan 2015 17:16:30 -0000
@@ -570,7 +570,7 @@ packagemeta::set_action (_actions action
 	  || categories.find ("Base") != categories.end ()
 	  || categories.find ("Misc") != categories.end ())
 	{
-	  desired = default_version;
+	  desired = trustp (TRUST_CURR);
 	  if (desired)
 	    {
 	      desired.pick (desired != installed, this);
Index: package_meta.h
===================================================================
RCS file: /cvs/cygwin-apps/setup/package_meta.h,v
retrieving revision 2.42
diff -u -p -r2.42 package_meta.h
--- package_meta.h	25 Jul 2013 12:03:49 -0000	2.42
+++ package_meta.h	25 Jan 2015 17:16:30 -0000
@@ -94,6 +94,8 @@ public:
   {
     if (t == TRUST_TEST && exp)
       return exp;
+    else if (curr < installed && exp)
+      return exp;
     else if (curr)
       return curr;
     else


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
> Instead of always defaulting to the curr version, Setup now checks if
> the installed version of a package is higher than the curr version of
> the package.  If so, and if a test version exists for this package, it
> will choose the test version by default.  A welcome side effect of this
> is, if the test version becomes the curr version, the installed version
> will not be higher than curr, thus the curr version will be chosen
> again.

I'd say that's good enough for now.

> Index: package_meta.h
> ===================================================================
> RCS file: /cvs/cygwin-apps/setup/package_meta.h,v
> retrieving revision 2.42
> diff -u -p -r2.42 package_meta.h
> --- package_meta.h	25 Jul 2013 12:03:49 -0000	2.42
> +++ package_meta.h	25 Jan 2015 17:16:30 -0000
> @@ -94,6 +94,8 @@ public:
>    {
>      if (t == TRUST_TEST && exp)
>        return exp;
> +    else if (curr < installed && exp)
> +      return exp;
>      else if (curr)
>        return curr;
>      else

I'd prefer to re-arrange the tests to something along the lines of

--8<---------------cut here---------------start------------->8---
  if (exp)
    {
       if ( (t == TRUST_TEST) ||
            (curr < installed) )
--8<---------------cut here---------------end--------------->8---


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Setup patch to keep test version if test version installed

[David Stacey]

On 25/01/15 17:20, Corinna Vinschen wrote:
> Instead of always defaulting to the curr version, Setup now checks if
> the installed version of a package is higher than the curr version of
> the package.

This sounds like a great idea - providing that the logic to compare two 
version numbers is sufficiently clever. Looking at operator<() in 
package_version.cc, it appears as though this is performing simple 
string comparison on the version numbers. This would fail in a number of 
cases. A real example from setup.ini:

     package: at-spi2-atk
     curr: 2.10.2-1
     prev: 2.8.1-1

A simple string comparison would prefer prev over curr!

In your patch, maybe it could be better to call 
packageversion::compareVersions() rather than use operator<(). I'm not 
terribly familiar with the setup code, so please excuse me if I'm 
mistaken, got lost in the code, or am completely barking up the wrong tree.

Dave.

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1453 bytes --]

Hi David,

On Jan 25 23:46, David Stacey wrote:
> On 25/01/15 17:20, Corinna Vinschen wrote:
> >Instead of always defaulting to the curr version, Setup now checks if
> >the installed version of a package is higher than the curr version of
> >the package.
> 
> This sounds like a great idea - providing that the logic to compare two
> version numbers is sufficiently clever. Looking at operator<() in
> package_version.cc, it appears as though this is performing simple string
> comparison on the version numbers. This would fail in a number of cases. A
> real example from setup.ini:
> 
>     package: at-spi2-atk
>     curr: 2.10.2-1
>     prev: 2.8.1-1
> 
> A simple string comparison would prefer prev over curr!
> 
> In your patch, maybe it could be better to call
> packageversion::compareVersions() rather than use operator<(). I'm not
> terribly familiar with the setup code, so please excuse me if I'm mistaken,
> got lost in the code, or am completely barking up the wrong tree.

No, no.  Thanks for noticing!  I was sure that the comparison operators
are comparing using compareVersions() under the hood so I didn't check.
How embarrassing.  Now I see that they only do a casecompare, as you said.

I'll fix that in my code and check it in.


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1883 bytes --]

Hi Achim,

On Jan 25 19:42, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Instead of always defaulting to the curr version, Setup now checks if
> > the installed version of a package is higher than the curr version of
> > the package.  If so, and if a test version exists for this package, it
> > will choose the test version by default.  A welcome side effect of this
> > is, if the test version becomes the curr version, the installed version
> > will not be higher than curr, thus the curr version will be chosen
> > again.
> 
> I'd say that's good enough for now.
> 
> > Index: package_meta.h
> > ===================================================================
> > RCS file: /cvs/cygwin-apps/setup/package_meta.h,v
> > retrieving revision 2.42
> > diff -u -p -r2.42 package_meta.h
> > --- package_meta.h	25 Jul 2013 12:03:49 -0000	2.42
> > +++ package_meta.h	25 Jan 2015 17:16:30 -0000
> > @@ -94,6 +94,8 @@ public:
> >    {
> >      if (t == TRUST_TEST && exp)
> >        return exp;
> > +    else if (curr < installed && exp)
> > +      return exp;
> >      else if (curr)
> >        return curr;
> >      else
> 
> I'd prefer to re-arrange the tests to something along the lines of
> 
> --8<---------------cut here---------------start------------->8---
>   if (exp)
>     {
>        if ( (t == TRUST_TEST) ||
>             (curr < installed) )
> --8<---------------cut here---------------end--------------->8---

Nnnno.  I was planning to rearrange the code slightly and to add
comments to explain what the code does.  Every time I'm looking into
setup I'm desperately missing comments.  Roberts C++ class system is a
teeny little bit confusing for my taste :}


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]

On Jan 25 18:20, Corinna Vinschen wrote:
> Example:
> 
>   foo-1.22-1 is installed
>   foo-1.23-1 is curr
>   foo-1.24-1 is test
>   ==> Setup chooses 1.23-1 as default.
> 
> User installs 1.24-1.  Next Setup run:
> 
>   foo-1.24-1 is installed
>   foo-1.23-1 is curr
>   foo-1.24-1 is test
>   ==> Setup chooses 1.24-1 as default.
> 
> Maintainer releases a new test version:
>  
>   foo-1.24-1 is installed
>   foo-1.23-1 is curr
>   foo-1.24-2 is test
>   ==> Setup chooses 1.24-2 as default.
> 
> Maintainer releases test version as curr version:
> 
>   foo-1.24-2 is installed
>   foo-1.24-2 is curr
>   ==> Setup chooses 1.24-2 as default.
> 
> Maintainer releases new test version:
> 
>   foo-1.24-2 is installed
>   foo-1.24-2 is curr
>   foo-1.25-1 is test
>   ==> Setup chooses 1.24-2 as default.

Another case occured to me a few minutes ago.

What if the "test" version gets removed, without updating "curr"?

  foo-1.24-1 is installed
  foo-1.23-1 is curr
  no test version

  Now what?
  
  Right now, Setup pulls the user back to "curr", so 1.23-1 will be
  preselected.  This is more or less equivalent to `yum distro-sync'
  on Fedora.

  What would make more(?) sense is sticking to "installed" instead,
  because the version number is higher than the "curr" version.  This
  behaviour would reflect the behaviour of `yum update'.

What do you think?


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
> No, no.  Thanks for noticing!  I was sure that the comparison operators
> are comparing using compareVersions() under the hood so I didn't check.
> How embarrassing.  Now I see that they only do a casecompare, as you said.

That's arguably a bug in the comparison operator implementation, so
maybe we should fix that instead?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
> What if the "test" version gets removed, without updating "curr"?

Then there presumably was a good reason to pull that test version.

>   What would make more(?) sense is sticking to "installed" instead,
>   because the version number is higher than the "curr" version.  This
>   behaviour would reflect the behaviour of `yum update'.

With test releases that get pulled I think it really is correct that the
default reverts back to "curr".


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html

Re: Setup patch to keep test version if test version installed

[Yaakov Selkowitz]

On Mon, 2015-01-26 at 10:58 +0100, Corinna Vinschen wrote:
> On Jan 25 18:20, Corinna Vinschen wrote:
> > Example:
> > 
> >   foo-1.22-1 is installed
> >   foo-1.23-1 is curr
> >   foo-1.24-1 is test
> >   ==> Setup chooses 1.23-1 as default.
> > 
> > User installs 1.24-1.  Next Setup run:
> > 
> >   foo-1.24-1 is installed
> >   foo-1.23-1 is curr
> >   foo-1.24-1 is test
> >   ==> Setup chooses 1.24-1 as default.
> > 
> > Maintainer releases a new test version:
> >  
> >   foo-1.24-1 is installed
> >   foo-1.23-1 is curr
> >   foo-1.24-2 is test
> >   ==> Setup chooses 1.24-2 as default.
> > 
> > Maintainer releases test version as curr version:
> > 
> >   foo-1.24-2 is installed
> >   foo-1.24-2 is curr
> >   ==> Setup chooses 1.24-2 as default.
> > 
> > Maintainer releases new test version:
> > 
> >   foo-1.24-2 is installed
> >   foo-1.24-2 is curr
> >   foo-1.25-1 is test
> >   ==> Setup chooses 1.24-2 as default.

These all make sense to me.

> Another case occured to me a few minutes ago.
> 
> What if the "test" version gets removed, without updating "curr"?
> 
>   foo-1.24-1 is installed
>   foo-1.23-1 is curr
>   no test version

A similar question would arise if 1.24-1 had been "curr", then pulled
for some reason and not replaced immediately with a 1.24-2.  (In such a
case on Fedora, the downgrade would be forced through an epoch bump.)

Also relevant would be the case where a newer version of a package is
installed from a third-party repository (e.g. cmake in Ports), then in a
subsequent run, the download cache was removed and said repository is
not selected.

>   Now what?
>   
>   Right now, Setup pulls the user back to "curr", so 1.23-1 will be
>   preselected.  This is more or less equivalent to `yum distro-sync'
>   on Fedora.
> 
>   What would make more(?) sense is sticking to "installed" instead,
>   because the version number is higher than the "curr" version.  This
>   behaviour would reflect the behaviour of `yum update'.
> 
> What do you think?

Unfortunately the answer depends on the scenario.  Would it be feasible
to support both modes in setup?


Yaakov

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]

On Jan 26 11:20, Achim Gratz wrote:
> Corinna Vinschen writes:
> > What if the "test" version gets removed, without updating "curr"?
> 
> Then there presumably was a good reason to pull that test version.
> 
> >   What would make more(?) sense is sticking to "installed" instead,
> >   because the version number is higher than the "curr" version.  This
> >   behaviour would reflect the behaviour of `yum update'.
> 
> With test releases that get pulled I think it really is correct that the
> default reverts back to "curr".

Really?  Here's what I'm doing on Linux:

  The latest upstream release 1.24 adds a feature I need.  The official
  package version 1.23-44 is obviously still missing this feature, so I
  build my own rpm with the upstream version 1.24-0 and install that:

    Official:  1.23-44
    Installed: 1.24-0

  The official package gets updated to 1.23-47.  What I'm expecting
  now is that the update does NOT update my package, and that's what
  yum or apper will do.  They will leave my higher version alone:

    Official:  1.23-47
    Installed: 1.24-0

  Now the official version is pulled up to the next upstream version.
  The new package is 1.24-3.  This time the version number is higher,
  so yum or apper will update:

    Official:  1.24-3
    Installed: 1.24-3


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]

On Jan 26 11:15, Achim Gratz wrote:
> Corinna Vinschen writes:
> > No, no.  Thanks for noticing!  I was sure that the comparison operators
> > are comparing using compareVersions() under the hood so I didn't check.
> > How embarrassing.  Now I see that they only do a casecompare, as you said.
> 
> That's arguably a bug in the comparison operator implementation, so
> maybe we should fix that instead?

I'm not so sure in which scenarios the operators are used.  In those
scenarios the caasecompare might be the right thing to do.

Btw., while playing with my patch, I found that setup has a bug.
I first thought this is my patches fault, but the current release of
setup already shows this behaviour:

Consider the cygwin package:

  Installed:  1.7.34-004
  Curr:       1.7.33-1
  Test:       1.7.34-005

When I enter the chooser dialog, the "New" version is set to 1.7.33-1.
Now I click on the version number multiple times:

  1.7.33-1    --click-->    Keep
              --click-->    1.7.34-005
              --click-->    Uninstall
              --click-->    Keep

  Huh?

              --click-->    1.7.34-005
              --click-->    Uninstall
              --click-->    Keep

  Where's 1.7.33-1?

              --click-->    1.7.34-005
              --click-->    Uninstall
              --click-->    Keep

Argh.  Where does *this* occur?  I guess the above needs fixing before I
apply any changes to the default selection :(((


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2341 bytes --]

On Jan 26 11:45, Corinna Vinschen wrote:
> On Jan 26 11:15, Achim Gratz wrote:
> > Corinna Vinschen writes:
> > > No, no.  Thanks for noticing!  I was sure that the comparison operators
> > > are comparing using compareVersions() under the hood so I didn't check.
> > > How embarrassing.  Now I see that they only do a casecompare, as you said.
> > 
> > That's arguably a bug in the comparison operator implementation, so
> > maybe we should fix that instead?
> 
> I'm not so sure in which scenarios the operators are used.  In those
> scenarios the caasecompare might be the right thing to do.
> 
> Btw., while playing with my patch, I found that setup has a bug.
> I first thought this is my patches fault, but the current release of
> setup already shows this behaviour:
> 
> Consider the cygwin package:
> 
>   Installed:  1.7.34-004
>   Curr:       1.7.33-1
>   Test:       1.7.34-005
> 
> When I enter the chooser dialog, the "New" version is set to 1.7.33-1.
> Now I click on the version number multiple times:
> 
>   1.7.33-1    --click-->    Keep
>               --click-->    1.7.34-005
>               --click-->    Uninstall
>               --click-->    Keep
> 
>   Huh?
> 
>               --click-->    1.7.34-005
>               --click-->    Uninstall
>               --click-->    Keep
> 
>   Where's 1.7.33-1?
> 
>               --click-->    1.7.34-005
>               --click-->    Uninstall
>               --click-->    Keep
> 
> Argh.  Where does *this* occur?  I guess the above needs fixing before I
> apply any changes to the default selection :(((

I checked in code which fixes this issue, which simplifies the package
choosing algorithm when clicking on the package line, and which
implements the default package in a way which never "downgrades" a
package without the user's explicit consent by choosing the lower
package version manually.  This is much more in line with the update
mechanism in Linux package managers.

I uploaded test builds of this setup to cygwin.com:

  https://cygwin.com/setup-test-x86.exe
  https://cygwin.com/setup-test-x86_64.exe

Please give it a try.


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
> I checked in code which fixes this issue, which simplifies the package
> choosing algorithm when clicking on the package line, and which
> implements the default package in a way which never "downgrades" a
> package without the user's explicit consent by choosing the lower
> package version manually.  This is much more in line with the update
> mechanism in Linux package managers.

You may have solved a long-standing problem.  Let's see if everything
else still works... :-)

BTW, if you switch one package to "test" (or "prev"), then all packages
belonging to the same source package must be switched to the same state.
I'm currently doing this with an external tool via setup.ini rewrites,
but setup.exe should be taught how to do that for manual intervention.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]

On Jan 27 07:55, Achim Gratz wrote:
> Corinna Vinschen writes:
> > I checked in code which fixes this issue, which simplifies the package
> > choosing algorithm when clicking on the package line, and which
> > implements the default package in a way which never "downgrades" a
> > package without the user's explicit consent by choosing the lower
> > package version manually.  This is much more in line with the update
> > mechanism in Linux package managers.
> 
> You may have solved a long-standing problem.  Let's see if everything
> else still works... :-)
> 
> BTW, if you switch one package to "test" (or "prev"), then all packages
> belonging to the same source package must be switched to the same state.
> I'm currently doing this with an external tool via setup.ini rewrites,
> but setup.exe should be taught how to do that for manual intervention.

That's a bit over my head in terms of understanding setup's dependency
resolution algorithm.  Perhaps we should rewrite it in plain C...


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
> On Jan 27 07:55, Achim Gratz wrote:
>> You may have solved a long-standing problem.  Let's see if everything
>> else still works... :-)

Orpahned package removal doesn't work anymore, but I have no time to
take a closer look this week.

>> BTW, if you switch one package to "test" (or "prev"), then all packages
>> belonging to the same source package must be switched to the same state.
>> I'm currently doing this with an external tool via setup.ini rewrites,
>> but setup.exe should be taught how to do that for manual intervention.
>
> That's a bit over my head in terms of understanding setup's dependency
> resolution algorithm.  Perhaps we should rewrite it in plain C...

The idea would be to tie the decision of what version gets installed to
the source package rather than each individual one.  I haven't looked
into how that might be possible, but since each package already knows
its source package that shouldn't be impossible.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Setup patch to keep test version if test version installed

[Marco Atzeri]

On 1/27/2015 7:25 PM, Achim Gratz wrote:
> Corinna Vinschen writes:
>> On Jan 27 07:55, Achim Gratz wrote:
>>> You may have solved a long-standing problem.  Let's see if everything
>>> else still works... :-)
>
> Orpahned package removal doesn't work anymore, but I have no time to
> take a closer look this week.
>

>
> The idea would be to tie the decision of what version gets installed to
> the source package rather than each individual one.  I haven't looked
> into how that might be possible, but since each package already knows
> its source package that shouldn't be impossible.

Pay attention that not all packages have a source one.
On 32bit, these packages has no source

_autorebase
_update-info-dir
base-cygwin
base-files
chere
cygcheck-dep
groff-perl
libXaw8
libXft1
libXp6
libgc-devel
libgc1
libopencdk8
libostyle-devel
libostyle1
singular-help
singular-icons
singular-share
singular-surf
tesseract-ocr-deu
tesseract-ocr-eng
tesseract-ocr-fra
tesseract-ocr-ita
tesseract-ocr-nld
tesseract-ocr-por
tesseract-ocr-spa
tesseract-ocr-vie
xemacs-emacs-common
xemacs-tags


> Regards,
> Achim.

Regards
Marco

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2306 bytes --]

On Jan 27 19:25, Achim Gratz wrote:
> Corinna Vinschen writes:
> > On Jan 27 07:55, Achim Gratz wrote:
> >> You may have solved a long-standing problem.  Let's see if everything
> >> else still works... :-)
> 
> Orpahned package removal doesn't work anymore, but I have no time to
> take a closer look this week.

Example?  I just tried the libppl and libmpc1 packages, and they simply
don;'t show up anymore, neither in the current setup 2.859, nor ithe
test setup 2.861.  I don't see a difference in behaviour.

Maybe it was a mistake to simpy remove the packages, rather then going
out of my way and mark the packages obsolete instead?

> >> BTW, if you switch one package to "test" (or "prev"), then all packages
> >> belonging to the same source package must be switched to the same state.
> >> I'm currently doing this with an external tool via setup.ini rewrites,
> >> but setup.exe should be taught how to do that for manual intervention.
> >
> > That's a bit over my head in terms of understanding setup's dependency
> > resolution algorithm.  Perhaps we should rewrite it in plain C...
> 
> The idea would be to tie the decision of what version gets installed to
> the source package rather than each individual one.  I haven't looked
> into how that might be possible, but since each package already knows
> its source package that shouldn't be impossible.

That's another type of dependency.  You're talking about installing all
packages that are created from the same source, which is a good idea,
certainly.

I was talking about entirely different packages the "test" package
depends on.  Let's say, Eric releases a new "test" bash and a new "test"
readline.  When somebody chooses to install the "test" bash, the
dependency algorithm should automatically install the "test" libreadline
since bash depends on readline.

Resolving your kind of dependency is probably much easier to solve.  The
other type of dependency, if implemented in all seriousness, would
probably require to define version dependecies, kind of like defining
minimum version numbers for dependencies in setup.hint.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
> Example?  I just tried the libppl and libmpc1 packages, and they simply
> don;'t show up anymore, neither in the current setup 2.859, nor ithe
> test setup 2.861.  I don't see a difference in behaviour.

You have to use the -o / --delete-orphans option for this to kick in.
It should still work in 2.859 or at least it did for me.  This trustp
business in setup is a bit annoying and intransparent, but I'll figure
out how to fix it again.

> Maybe it was a mistake to simpy remove the packages, rather then going
> out of my way and mark the packages obsolete instead?

I can make obsolescence packages if anybody thinks it's useful.

> That's another type of dependency.  You're talking about installing all
> packages that are created from the same source, which is a good idea,
> certainly.

No, I'm only talking about installing all packages from the same source
with the same version selector (from prev/curr/exp).  The user still
gets to chose which of the packages to install, but shouldn't be able to
install devel from curr and doc from prev and libwhatever from test.

> I was talking about entirely different packages the "test" package
> depends on.  Let's say, Eric releases a new "test" bash and a new "test"
> readline.  When somebody chooses to install the "test" bash, the
> dependency algorithm should automatically install the "test" libreadline
> since bash depends on readline.

I've thought about this before, but that would require the format of
setup.hint and setup.ini to change and (at least optionally) allow
different dependencies per prev/curr/exp section.

> Resolving your kind of dependency is probably much easier to solve.  The
> other type of dependency, if implemented in all seriousness, would
> probably require to define version dependecies, kind of like defining
> minimum version numbers for dependencies in setup.hint.

I sort of have that already, just that I use a setup.conf file to
integrate different package sources coherently into a new setup.ini
file.  At the moment I can only override by prev/test or by putting a
package in a higher priority package source (that's how I implement
patches), but explicit version overrides are on the TODO list.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2224 bytes --]

On Jan 27 20:59, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Example?  I just tried the libppl and libmpc1 packages, and they simply
> > don;'t show up anymore, neither in the current setup 2.859, nor ithe
> > test setup 2.861.  I don't see a difference in behaviour.
> 
> You have to use the -o / --delete-orphans option for this to kick in.
> It should still work in 2.859 or at least it did for me.  This trustp
> business in setup is a bit annoying and intransparent, but I'll figure
> out how to fix it again.

I think I see why this happens.  I'll have a closer look tomorrow.

> > Maybe it was a mistake to simpy remove the packages, rather then going
> > out of my way and mark the packages obsolete instead?
> 
> I can make obsolescence packages if anybody thinks it's useful.

Thanks, but if the -o option works again, probably not.

> > That's another type of dependency.  You're talking about installing all
> > packages that are created from the same source, which is a good idea,
> > certainly.
> 
> No, I'm only talking about installing all packages from the same source
> with the same version selector (from prev/curr/exp).  The user still
> gets to chose which of the packages to install, but shouldn't be able to
> install devel from curr and doc from prev and libwhatever from test.

Why not?  Consider:  I want to *run* the new DLL, but I want to *build*
packages for the current release.  That means, I need cygwin-1.7.34-005
but cygwin-devel-1.7.33-1.

> > I was talking about entirely different packages the "test" package
> > depends on.  Let's say, Eric releases a new "test" bash and a new "test"
> > readline.  When somebody chooses to install the "test" bash, the
> > dependency algorithm should automatically install the "test" libreadline
> > since bash depends on readline.
> 
> I've thought about this before, but that would require the format of
> setup.hint and setup.ini to change and (at least optionally) allow
> different dependencies per prev/curr/exp section.

Exactly.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
> Why not?  Consider:  I want to *run* the new DLL, but I want to *build*
> packages for the current release.  That means, I need cygwin-1.7.34-005
> but cygwin-devel-1.7.33-1.

That's exactly why I properly package all snapshots by integrating them
with their base packages.  I've posted the Makefile before but, it has
changed a bit in the last few months, so if you're interested I can post
it again.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

On Jan 27 21:50, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Why not?  Consider:  I want to *run* the new DLL, but I want to *build*
> > packages for the current release.  That means, I need cygwin-1.7.34-005
> > but cygwin-devel-1.7.33-1.
> 
> That's exactly why I properly package all snapshots by integrating them
> with their base packages.  I've posted the Makefile before but, it has
> changed a bit in the last few months, so if you're interested I can post
> it again.

You lost me here.  What snapshots?!?


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2784 bytes --]

On Jan 27 21:37, Corinna Vinschen wrote:
> On Jan 27 20:59, Achim Gratz wrote:
> > Corinna Vinschen writes:
> > > Example?  I just tried the libppl and libmpc1 packages, and they simply
> > > don;'t show up anymore, neither in the current setup 2.859, nor ithe
> > > test setup 2.861.  I don't see a difference in behaviour.
> > 
> > You have to use the -o / --delete-orphans option for this to kick in.
> > It should still work in 2.859 or at least it did for me.  This trustp
> > business in setup is a bit annoying and intransparent, but I'll figure
> > out how to fix it again.
> 
> I think I see why this happens.  I'll have a closer look tomorrow.

Or today.  Can you try this patch?  Most of it is a bit of reformatting,
the importnat part is the last set_action call.

Index: choose.cc
===================================================================
RCS file: /cvs/cygwin-apps/setup/choose.cc,v
retrieving revision 2.169
diff -u -p -r2.169 choose.cc
--- choose.cc	26 Jan 2015 21:05:45 -0000	2.169
+++ choose.cc	27 Jan 2015 20:58:17 -0000
@@ -252,19 +252,23 @@ ChooserPage::OnInit ()
       bool deleted   = pkg.isManuallyDeleted();
       bool basemisc  = (pkg.categories.find ("Base") != pkg.categories.end ()
 		     || pkg.categories.find ("Misc") != pkg.categories.end ());
-      bool current   = pkg.curr || CleanOrphansOption;
-      bool upgrade   =  wanted  || (!pkg.installed && basemisc) || UpgradeAlsoOption || !hasManualSelections;
+      bool upgrade   =  wanted  || (!pkg.installed && basemisc)
+			|| UpgradeAlsoOption || !hasManualSelections;
       bool install   =   wanted  && !deleted && !pkg.installed;
       bool reinstall =  (wanted  || basemisc ) && deleted;
       bool uninstall = !(wanted  || basemisc ) && deleted;
       if (install)
-	pkg.set_action( packagemeta::Install_action, pkg.curr );
+	pkg.set_action (packagemeta::Install_action, pkg.curr);
       else if (reinstall)
-	pkg.set_action( packagemeta::Reinstall_action, pkg.curr );
+	pkg.set_action (packagemeta::Reinstall_action, pkg.curr);
       else if (uninstall)
-	pkg.set_action( packagemeta::Uninstall_action, packageversion() );
+	pkg.set_action (packagemeta::Uninstall_action, packageversion ());
       else
-	pkg.set_action( packagemeta::Default_action, ((upgrade && current) ? pkg.trustp (true,  TRUST_UNKNOWN) : pkg.installed) );
+	pkg.set_action (packagemeta::Default_action,
+			(upgrade && pkg.curr)
+			? pkg.trustp (true,  TRUST_UNKNOWN)
+			: (!pkg.curr && CleanOrphansOption)
+			  ? pkg.curr : pkg.installed);
     }
 
   ClearBusy ();


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
>> That's exactly why I properly package all snapshots by integrating them
>> with their base packages.  I've posted the Makefile before but, it has
>> changed a bit in the last few months, so if you're interested I can post
>> it again.
>
> You lost me here.  What snapshots?!?

At the moment I'm running on the 2015-01-22 snapshot.  I always make
patch packages for installation via setup for these (the version on
those packages is 1.7.34-005s20150122).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
> Or today.  Can you try this patch?  Most of it is a bit of reformatting,
> the importnat part is the last set_action call.

I think I'll get this wedged in sometime tomorrow.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2457 bytes --]

On Jan 27 22:04, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Or today.  Can you try this patch?  Most of it is a bit of reformatting,
> > the importnat part is the last set_action call.
> 
> I think I'll get this wedged in sometime tomorrow.

Thanks.  I think I have a better one, though.  The CleanOrphansOption
in cinjunction of not having a "curr" package should immediately trigger
the packagemeta::Uninstall_action:

Index: choose.cc
===================================================================
RCS file: /cvs/cygwin-apps/setup/choose.cc,v
retrieving revision 2.169
diff -u -p -r2.169 choose.cc
--- choose.cc	26 Jan 2015 21:05:45 -0000	2.169
+++ choose.cc	27 Jan 2015 21:12:01 -0000
@@ -252,19 +252,22 @@ ChooserPage::OnInit ()
       bool deleted   = pkg.isManuallyDeleted();
       bool basemisc  = (pkg.categories.find ("Base") != pkg.categories.end ()
 		     || pkg.categories.find ("Misc") != pkg.categories.end ());
-      bool current   = pkg.curr || CleanOrphansOption;
-      bool upgrade   =  wanted  || (!pkg.installed && basemisc) || UpgradeAlsoOption || !hasManualSelections;
+      bool upgrade   =  wanted  || (!pkg.installed && basemisc)
+			|| UpgradeAlsoOption || !hasManualSelections;
       bool install   =   wanted  && !deleted && !pkg.installed;
       bool reinstall =  (wanted  || basemisc ) && deleted;
-      bool uninstall = !(wanted  || basemisc ) && deleted;
+      bool uninstall = (!(wanted  || basemisc ) && deleted)
+		       || (!pkg.curr && CleanOrphansOption);
       if (install)
-	pkg.set_action( packagemeta::Install_action, pkg.curr );
+	pkg.set_action (packagemeta::Install_action, pkg.curr);
       else if (reinstall)
-	pkg.set_action( packagemeta::Reinstall_action, pkg.curr );
+	pkg.set_action (packagemeta::Reinstall_action, pkg.curr);
       else if (uninstall)
-	pkg.set_action( packagemeta::Uninstall_action, packageversion() );
+	pkg.set_action (packagemeta::Uninstall_action, packageversion ());
       else
-	pkg.set_action( packagemeta::Default_action, ((upgrade && current) ? pkg.trustp (true,  TRUST_UNKNOWN) : pkg.installed) );
+	pkg.set_action (packagemeta::Default_action,
+			upgrade ? pkg.trustp (true,  TRUST_UNKNOWN)
+				: pkg.installed);
     }
 
   ClearBusy ();

Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2940 bytes --]

On Jan 27 22:14, Corinna Vinschen wrote:
> On Jan 27 22:04, Achim Gratz wrote:
> > Corinna Vinschen writes:
> > > Or today.  Can you try this patch?  Most of it is a bit of reformatting,
> > > the importnat part is the last set_action call.
> > 
> > I think I'll get this wedged in sometime tomorrow.
> 
> Thanks.  I think I have a better one, though.  The CleanOrphansOption
> in cinjunction of not having a "curr" package should immediately trigger
> the packagemeta::Uninstall_action:
> 
> Index: choose.cc
> ===================================================================
> RCS file: /cvs/cygwin-apps/setup/choose.cc,v
> retrieving revision 2.169
> diff -u -p -r2.169 choose.cc
> --- choose.cc	26 Jan 2015 21:05:45 -0000	2.169
> +++ choose.cc	27 Jan 2015 21:12:01 -0000
> @@ -252,19 +252,22 @@ ChooserPage::OnInit ()
>        bool deleted   = pkg.isManuallyDeleted();
>        bool basemisc  = (pkg.categories.find ("Base") != pkg.categories.end ()
>  		     || pkg.categories.find ("Misc") != pkg.categories.end ());
> -      bool current   = pkg.curr || CleanOrphansOption;
> -      bool upgrade   =  wanted  || (!pkg.installed && basemisc) || UpgradeAlsoOption || !hasManualSelections;
> +      bool upgrade   =  wanted  || (!pkg.installed && basemisc)
> +			|| UpgradeAlsoOption || !hasManualSelections;
>        bool install   =   wanted  && !deleted && !pkg.installed;
>        bool reinstall =  (wanted  || basemisc ) && deleted;
> -      bool uninstall = !(wanted  || basemisc ) && deleted;
> +      bool uninstall = (!(wanted  || basemisc ) && deleted)
> +		       || (!pkg.curr && CleanOrphansOption);
>        if (install)
> -	pkg.set_action( packagemeta::Install_action, pkg.curr );
> +	pkg.set_action (packagemeta::Install_action, pkg.curr);
>        else if (reinstall)
> -	pkg.set_action( packagemeta::Reinstall_action, pkg.curr );
> +	pkg.set_action (packagemeta::Reinstall_action, pkg.curr);
>        else if (uninstall)
> -	pkg.set_action( packagemeta::Uninstall_action, packageversion() );
> +	pkg.set_action (packagemeta::Uninstall_action, packageversion ());
>        else
> -	pkg.set_action( packagemeta::Default_action, ((upgrade && current) ? pkg.trustp (true,  TRUST_UNKNOWN) : pkg.installed) );
> +	pkg.set_action (packagemeta::Default_action,
> +			upgrade ? pkg.trustp (true,  TRUST_UNKNOWN)
> +				: pkg.installed);
>      }
>  
>    ClearBusy ();

This test release has another puzzeling problem I have to figure out
yet.  For some reason, it's impossible to downgrade packages at all.
Worse, if you try that, it will remove the package.  That's a rather
weird side effect of my changes, which were only supposed to change
the selection method, not the underlying workings.  Oh well.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2753 bytes --]

On Jan 28 10:55, Corinna Vinschen wrote:
> On Jan 27 22:14, Corinna Vinschen wrote:
> > On Jan 27 22:04, Achim Gratz wrote:
> > > Corinna Vinschen writes:
> > > > Or today.  Can you try this patch?  Most of it is a bit of reformatting,
> > > > the importnat part is the last set_action call.
> > > 
> > > I think I'll get this wedged in sometime tomorrow.
> > 
> > Thanks.  I think I have a better one, though.  The CleanOrphansOption
> > in cinjunction of not having a "curr" package should immediately trigger
> > the packagemeta::Uninstall_action:
> > [...]
> This test release has another puzzeling problem I have to figure out
> yet.  For some reason, it's impossible to downgrade packages at all.
> Worse, if you try that, it will remove the package.  That's a rather
> weird side effect of my changes, which were only supposed to change
> the selection method, not the underlying workings.  Oh well.

I applied a patch and uploaded new test versions, 2.863, to

  https://cygwin.com/setup-test-x86.exe
  https://cygwin.com/setup-test-x86_64.exe

These should fix the aforementioned bug I introduced, as well as another
subtil problem when checking and unchecking the Bin/Src boxes.  If both
boxes were deselected, the package got uninstalled without showing up in
the "Pending" view.  I worked around that by setting the package state
explicitely to "Uninstall" if both boxes got deselected.

This version also introduces an experimental option -m/--mirror-mode.

There's something bugging me for a long time as well.  We're running our
own Cygwin mirror on a local Linux box.  The directory is mounted via
NFS on my Windows boxes.  So, rather than installing from internet, I
"Install from Local Directory", with the local directory being the
NFS-mounted mirror directory.

This works fine, except that, after parsing setup.ini, setup hangs
unresponsive for about 2 minutes.  Only then the chooser window opens.

It turned out that the 2 minutes are spent iterating throught the full
set of packages and testing each package and each packageversion if the
underlying package file exists in the download directory.

Given that the directory is a mirror in my case, the test makes only
marginal sense.  Therefore I added the -m option which avoids most file
system access and only checks in a border case (installed version is not
in setup.ini).

If you're doing as I do, running a local mirror, you may welcome this
option.  I just don't guarantee that it always works ;}  If you find a
bug, don't hesitate to report it.


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
> This version also introduces an experimental option -m/--mirror-mode.

Thank you for this!


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 773 bytes --]

On Jan 28 22:55, Achim Gratz wrote:
> Corinna Vinschen writes:
> > This version also introduces an experimental option -m/--mirror-mode.
> 
> Thank you for this!

Well, I added it for entirely selfish reasons, so I'm not sure I deserve
getting thanks :)

In the meantime I tried what happens if the mirror is broken.  For
instance, if a file which is supposed to be installed, is missing.
Fortunately this situation is catched by the checksum check performed
right before uninstalling the old packages.  Setup opens a dialog asking
if this package should be skipped.  That's reassuring.


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
>> Thank you for this!
>
> Well, I added it for entirely selfish reasons, so I'm not sure I deserve
> getting thanks :)

I thanked you for the selfish reason that I got this crossed off my TODO
list without any effort on my part, so we're even.  ;-)


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 571 bytes --]

On Jan 29 18:27, Achim Gratz wrote:
> Corinna Vinschen writes:
> >> Thank you for this!
> >
> > Well, I added it for entirely selfish reasons, so I'm not sure I deserve
> > getting thanks :)
> 
> I thanked you for the selfish reason that I got this crossed off my TODO
> list without any effort on my part, so we're even.  ;-)

Heh :)

Btw., when, do you think, is showtime for _autorebase 2.0?


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
> Btw., when, do you think, is showtime for _autorebase 2.0?

Sometime during the next week would be good, if not then another window
would be two weeks later.  From the responses so far I gathered that
Marco doesn#t think he needs to do something for Octave and R, I will
take care of Perl myself.  That leaves PHP, Ruby and Python... so Yaakov
and Jason need to tell us when things are ready on their side I'd think.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: Setup patch to keep test version if test version installed

[Marco Atzeri]

On 1/30/2015 8:13 PM, Achim Gratz wrote:
> Corinna Vinschen writes:
>> Btw., when, do you think, is showtime for _autorebase 2.0?
>
> Sometime during the next week would be good, if not then another window
> would be two weeks later.  From the responses so far I gathered that
> Marco doesn#t think he needs to do something for Octave and R, I will
> take care of Perl myself.  That leaves PHP, Ruby and Python... so Yaakov
> and Jason need to tell us when things are ready on their side I'd think.

Octave no, but R yes.

I will upload the R_autorebase-001001-1.tar.xz together with the new
3.1.2 build as soon ready


> Regards,
> Achim.

Regards
Marco

Re: Setup patch to keep test version if test version installed

[Marco Atzeri]

On 1/30/2015 11:11 PM, Marco Atzeri wrote:
>
>
> On 1/30/2015 8:13 PM, Achim Gratz wrote:
>> Corinna Vinschen writes:
>>> Btw., when, do you think, is showtime for _autorebase 2.0?
>>

> Octave no, but R yes.
>
> I will upload the R_autorebase-001001-1.tar.xz together with the new
> 3.1.2 build as soon ready

R_autorebase is up

Marco

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

On Jan 30 20:13, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Btw., when, do you think, is showtime for _autorebase 2.0?
> 
> Sometime during the next week would be good, if not then another window

I'm on vaca today, but this week sounds good to me.  I will release
1.7.34, too, later this week.

> would be two weeks later.  From the responses so far I gathered that
> Marco doesn#t think he needs to do something for Octave and R, I will
> take care of Perl myself.  That leaves PHP, Ruby and Python... so Yaakov
> and Jason need to tell us when things are ready on their side I'd think.

Well, Jason has dropped maintaiwnrship, so it's Yaakov.  Yaakov?


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

Hey guys,

On Jan 28 21:23, Corinna Vinschen wrote:
> 
>   https://cygwin.com/setup-test-x86.exe
>   https://cygwin.com/setup-test-x86_64.exe
> 
> These should fix the aforementioned bug I introduced, as well as another
> subtil problem when checking and unchecking the Bin/Src boxes.  If both
> boxes were deselected, the package got uninstalled without showing up in
> the "Pending" view.  I worked around that by setting the package state
> explicitely to "Uninstall" if both boxes got deselected.
> 
> This version also introduces an experimental option -m/--mirror-mode.
> 
> There's something bugging me for a long time as well.  We're running our
> own Cygwin mirror on a local Linux box.  The directory is mounted via
> NFS on my Windows boxes.  So, rather than installing from internet, I
> "Install from Local Directory", with the local directory being the
> NFS-mounted mirror directory.
> 
> This works fine, except that, after parsing setup.ini, setup hangs
> unresponsive for about 2 minutes.  Only then the chooser window opens.
> 
> It turned out that the 2 minutes are spent iterating throught the full
> set of packages and testing each package and each packageversion if the
> underlying package file exists in the download directory.
> 
> Given that the directory is a mirror in my case, the test makes only
> marginal sense.  Therefore I added the -m option which avoids most file
> system access and only checks in a border case (installed version is not
> in setup.ini).
> 
> If you're doing as I do, running a local mirror, you may welcome this
> option.  I just don't guarantee that it always works ;}  If you find a
> bug, don't hesitate to report it.

Did you test this version?  Is it ok to become the release version of
setup?


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Ken Brown]

On 2/3/2015 6:33 AM, Corinna Vinschen wrote:
> Hey guys,
>
> On Jan 28 21:23, Corinna Vinschen wrote:
>>
>>    https://cygwin.com/setup-test-x86.exe
>>    https://cygwin.com/setup-test-x86_64.exe
>>
>> These should fix the aforementioned bug I introduced, as well as another
>> subtil problem when checking and unchecking the Bin/Src boxes.  If both
>> boxes were deselected, the package got uninstalled without showing up in
>> the "Pending" view.  I worked around that by setting the package state
>> explicitely to "Uninstall" if both boxes got deselected.
>>
>> This version also introduces an experimental option -m/--mirror-mode.
>>
>> There's something bugging me for a long time as well.  We're running our
>> own Cygwin mirror on a local Linux box.  The directory is mounted via
>> NFS on my Windows boxes.  So, rather than installing from internet, I
>> "Install from Local Directory", with the local directory being the
>> NFS-mounted mirror directory.
>>
>> This works fine, except that, after parsing setup.ini, setup hangs
>> unresponsive for about 2 minutes.  Only then the chooser window opens.
>>
>> It turned out that the 2 minutes are spent iterating throught the full
>> set of packages and testing each package and each packageversion if the
>> underlying package file exists in the download directory.
>>
>> Given that the directory is a mirror in my case, the test makes only
>> marginal sense.  Therefore I added the -m option which avoids most file
>> system access and only checks in a border case (installed version is not
>> in setup.ini).
>>
>> If you're doing as I do, running a local mirror, you may welcome this
>> option.  I just don't guarantee that it always works ;}  If you find a
>> bug, don't hesitate to report it.
>
> Did you test this version?  Is it ok to become the release version of
> setup?

It works fine for me.

Ken

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2209 bytes --]

On Feb  3 08:04, Ken Brown wrote:
> On 2/3/2015 6:33 AM, Corinna Vinschen wrote:
> >Hey guys,
> >
> >On Jan 28 21:23, Corinna Vinschen wrote:
> >>
> >>   https://cygwin.com/setup-test-x86.exe
> >>   https://cygwin.com/setup-test-x86_64.exe
> >>
> >>These should fix the aforementioned bug I introduced, as well as another
> >>subtil problem when checking and unchecking the Bin/Src boxes.  If both
> >>boxes were deselected, the package got uninstalled without showing up in
> >>the "Pending" view.  I worked around that by setting the package state
> >>explicitely to "Uninstall" if both boxes got deselected.
> >>
> >>This version also introduces an experimental option -m/--mirror-mode.
> >>
> >>There's something bugging me for a long time as well.  We're running our
> >>own Cygwin mirror on a local Linux box.  The directory is mounted via
> >>NFS on my Windows boxes.  So, rather than installing from internet, I
> >>"Install from Local Directory", with the local directory being the
> >>NFS-mounted mirror directory.
> >>
> >>This works fine, except that, after parsing setup.ini, setup hangs
> >>unresponsive for about 2 minutes.  Only then the chooser window opens.
> >>
> >>It turned out that the 2 minutes are spent iterating throught the full
> >>set of packages and testing each package and each packageversion if the
> >>underlying package file exists in the download directory.
> >>
> >>Given that the directory is a mirror in my case, the test makes only
> >>marginal sense.  Therefore I added the -m option which avoids most file
> >>system access and only checks in a border case (installed version is not
> >>in setup.ini).
> >>
> >>If you're doing as I do, running a local mirror, you may welcome this
> >>option.  I just don't guarantee that it always works ;}  If you find a
> >>bug, don't hesitate to report it.
> >
> >Did you test this version?  Is it ok to become the release version of
> >setup?
> 
> It works fine for me.

Nice.  Are you a potential user of the -m option?


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Ken Brown]

On 2/3/2015 10:27 AM, Corinna Vinschen wrote:
> On Feb  3 08:04, Ken Brown wrote:
>> On 2/3/2015 6:33 AM, Corinna Vinschen wrote:
>>> Hey guys,
>>>
>>> On Jan 28 21:23, Corinna Vinschen wrote:
>>>>
>>>>    https://cygwin.com/setup-test-x86.exe
>>>>    https://cygwin.com/setup-test-x86_64.exe
>>>>
>>>> These should fix the aforementioned bug I introduced, as well as another
>>>> subtil problem when checking and unchecking the Bin/Src boxes.  If both
>>>> boxes were deselected, the package got uninstalled without showing up in
>>>> the "Pending" view.  I worked around that by setting the package state
>>>> explicitely to "Uninstall" if both boxes got deselected.
>>>>
>>>> This version also introduces an experimental option -m/--mirror-mode.
>>>>
>>>> There's something bugging me for a long time as well.  We're running our
>>>> own Cygwin mirror on a local Linux box.  The directory is mounted via
>>>> NFS on my Windows boxes.  So, rather than installing from internet, I
>>>> "Install from Local Directory", with the local directory being the
>>>> NFS-mounted mirror directory.
>>>>
>>>> This works fine, except that, after parsing setup.ini, setup hangs
>>>> unresponsive for about 2 minutes.  Only then the chooser window opens.
>>>>
>>>> It turned out that the 2 minutes are spent iterating throught the full
>>>> set of packages and testing each package and each packageversion if the
>>>> underlying package file exists in the download directory.
>>>>
>>>> Given that the directory is a mirror in my case, the test makes only
>>>> marginal sense.  Therefore I added the -m option which avoids most file
>>>> system access and only checks in a border case (installed version is not
>>>> in setup.ini).
>>>>
>>>> If you're doing as I do, running a local mirror, you may welcome this
>>>> option.  I just don't guarantee that it always works ;}  If you find a
>>>> bug, don't hesitate to report it.
>>>
>>> Did you test this version?  Is it ok to become the release version of
>>> setup?
>>
>> It works fine for me.
>
> Nice.  Are you a potential user of the -m option?

No, so I couldn't test that.  But it seems that others have tested it by now.

Ken

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]

Hi Ken,

On Feb  3 16:50, Ken Brown wrote:
> On 2/3/2015 10:27 AM, Corinna Vinschen wrote:
> >On Feb  3 08:04, Ken Brown wrote:
> >>On 2/3/2015 6:33 AM, Corinna Vinschen wrote:
> >>>Hey guys,
> >>>
> >>>On Jan 28 21:23, Corinna Vinschen wrote:
> >>>>
> >>>>   https://cygwin.com/setup-test-x86.exe
> >>>>   https://cygwin.com/setup-test-x86_64.exe
> >>>>[...]
> >>>
> >>>Did you test this version?  Is it ok to become the release version of
> >>>setup?
> >>
> >>It works fine for me.
> >
> >Nice.  Are you a potential user of the -m option?
> 
> No, so I couldn't test that.  But it seems that others have tested it by now.

Right, and thus I released this version :)


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

On Feb  2 10:17, Corinna Vinschen wrote:
> On Jan 30 20:13, Achim Gratz wrote:
> > Corinna Vinschen writes:
> > > Btw., when, do you think, is showtime for _autorebase 2.0?
> > 
> > Sometime during the next week would be good, if not then another window
> 
> I'm on vaca today, but this week sounds good to me.  I will release
> 1.7.34, too, later this week.
> 
> > would be two weeks later.  From the responses so far I gathered that
> > Marco doesn#t think he needs to do something for Octave and R, I will
> > take care of Perl myself.  That leaves PHP, Ruby and Python... so Yaakov
> > and Jason need to tell us when things are ready on their side I'd think.
> 
> Well, Jason has dropped maintaiwnrship, so it's Yaakov.  Yaakov?

Yaakov, can we *please* get this done so we can upload the new
_autorebase?


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
> Yaakov, can we *please* get this done so we can upload the new
> _autorebase?

I guess we can do it anyway, it's not creating a new problem if these
files are provided a few days later.  Let me know when you've switched
off the _autorebase autodep and version increment stuff and I'll upload
the package.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]

On Feb  5 10:12, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Yaakov, can we *please* get this done so we can upload the new
> > _autorebase?
> 
> I guess we can do it anyway, it's not creating a new problem if these
> files are provided a few days later.  Let me know when you've switched
> off the _autorebase autodep and version increment stuff and I'll upload
> the package.

The autodep stuff is automatically removed as soon as you overwrite
_autorebase'es setup.hint file since everything is code in there:

  sdesc: "Run rebaseall automatically"
  #external-source: rebase
  category: _PostInstallLast
  requires: 
  noautodep: cygwin
  autodep: .*/[^/]*\.(?:dll|so|oct)$
  incver_ifdep: yes


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]

On Feb  5 10:19, Corinna Vinschen wrote:
> On Feb  5 10:12, Achim Gratz wrote:
> > Corinna Vinschen writes:
> > > Yaakov, can we *please* get this done so we can upload the new
> > > _autorebase?
> > 
> > I guess we can do it anyway, it's not creating a new problem if these
> > files are provided a few days later.  Let me know when you've switched
> > off the _autorebase autodep and version increment stuff and I'll upload
> > the package.
> 
> The autodep stuff is automatically removed as soon as you overwrite
> _autorebase'es setup.hint file since everything is code in there:

s/code/coded/

>   sdesc: "Run rebaseall automatically"
>   #external-source: rebase
>   category: _PostInstallLast
>   requires: 
>   noautodep: cygwin
>   autodep: .*/[^/]*\.(?:dll|so|oct)$
>   incver_ifdep: yes

...in other words, just drop the last three lines in your setup.hint,
and the external-source hint.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Yaakov Selkowitz]

On Thu, 2015-02-05 at 09:57 +0100, Corinna Vinschen wrote:
> On Feb  2 10:17, Corinna Vinschen wrote:
> > On Jan 30 20:13, Achim Gratz wrote:
> > > Corinna Vinschen writes:
> > > > Btw., when, do you think, is showtime for _autorebase 2.0?
> > > 
> > > Sometime during the next week would be good, if not then another window
> > 
> > I'm on vaca today, but this week sounds good to me.  I will release
> > 1.7.34, too, later this week.
> > 
> > > would be two weeks later.  From the responses so far I gathered that
> > > Marco doesn#t think he needs to do something for Octave and R, I will
> > > take care of Perl myself.  That leaves PHP, Ruby and Python... so Yaakov
> > > and Jason need to tell us when things are ready on their side I'd think.
> > 
> > Well, Jason has dropped maintaiwnrship, so it's Yaakov.  Yaakov?
> 
> Yaakov, can we *please* get this done so we can upload the new
> _autorebase?

Don't wait for me, my queue is a bit backlogged at the moment.

--
Yaakov

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
> ...in other words, just drop the last three lines in your setup.hint,
> and the external-source hint.

Uploaded.  Let's see what upset does with this.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Achim Gratz writes:
> Corinna Vinschen writes:
>> ...in other words, just drop the last three lines in your setup.hint,
>> and the external-source hint.
>
> Uploaded.  Let's see what upset does with this.

The pending update is currently blocked by a duplicate python-doc
package...


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: Setup patch to keep test version if test version installed

[Yaakov Selkowitz]

On Thu, 2015-02-05 at 16:24 +0100, Achim Gratz wrote:
> Achim Gratz writes:
> > Corinna Vinschen writes:
> >> ...in other words, just drop the last three lines in your setup.hint,
> >> and the external-source hint.
> >
> > Uploaded.  Let's see what upset does with this.
> 
> The pending update is currently blocked by a duplicate python-doc
> package...

Yes, we know; it's fixed now.


Yaakov

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]

On Feb  5 16:24, Achim Gratz wrote:
> Achim Gratz writes:
> > Corinna Vinschen writes:
> >> ...in other words, just drop the last three lines in your setup.hint,
> >> and the external-source hint.
> >
> > Uploaded.  Let's see what upset does with this.
> 
> The pending update is currently blocked by a duplicate python-doc
> package...

I just had a look and there's no x86/release/python/python-doc directory.
It must have been removed in the last couple of minutes.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Yaakov Selkowitz writes:
>> The pending update is currently blocked by a duplicate python-doc
>> package...
>
> Yes, we know; it's fixed now.

Rats, it had removed the !ready files before the transfer took place.
I'll have to arm it again.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
>> The pending update is currently blocked by a duplicate python-doc
>> package...
>
> I just had a look and there's no x86/release/python/python-doc directory.
> It must have been removed in the last couple of minutes.

With that out of the way… can someone please hand over (co-)ownership of
_autorebase in cygwin-pkg-maint and !packages to me so that I can
actually upload the new package?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Setup patch to keep test version if test version installed

[Marco Atzeri]

On 2/5/2015 8:18 PM, Achim Gratz wrote:
> Corinna Vinschen writes:
>
> With that out of the way… can someone please hand over (co-)ownership of
> _autorebase in cygwin-pkg-maint and !packages to me so that I can
> actually upload the new package?

done.
You are no co-owner with Corinna

>
> Regards,
> Achim.
>
Marco

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Marco Atzeri writes:
> done.
> You are no co-owner with Corinna

Great, just in time to re-trigger the upload before the next sync.
:-)


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
> ...in other words, just drop the last three lines in your setup.hint,
> and the external-source hint.

Done.

I noticed just in time that the preremove scripts can't be dash scripts
at the moment.

Here's a patch to change that and also allow ".cmd" scripts, just like
already done for postinstall scripts:

    install.cc: allow .dash and .cmd extensions for preremove scripts also

	Modified   install.cc
diff --git a/install.cc b/install.cc
index 60c248d..653d623 100644
--- a/install.cc
+++ b/install.cc
@@ -160,10 +160,12 @@ Installer::preremoveOne (packagemeta & pkg)
   Progress.SetText1 ("Running preremove script...");
   Progress.SetText2 (pkg.name.c_str());
   Log (LOG_PLAIN) << "Running preremove script for  " << pkg.name << endLog;
-  try_run_script ("/etc/preremove/", pkg.name, ".sh");
-  try_run_script ("/etc/preremove/", pkg.name, ".bat");
+  const unsigned numexts = 4;
+  const char* exts[numexts] = { ".dash", ".sh", ".bat", ".cmd" };
+  for (unsigned i = 0; i < numexts; i++)
+    try_run_script ("/etc/preremove/", pkg.name, exts[i]);
 }
 
 void
 Installer::uninstallOne (packagemeta & pkg)
 {


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Oh, and while you are so deep in the bowels of setup.exe, would it be
possible to somehow fake a pty to shell scripts and a console to cmd so
that the scripts run by setup.exe produce their output in line-buffered
instead of fully buffered mode?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

On Feb  5 22:47, Achim Gratz wrote:
> Corinna Vinschen writes:
> > ...in other words, just drop the last three lines in your setup.hint,
> > and the external-source hint.
> 
> Done.
> 
> I noticed just in time that the preremove scripts can't be dash scripts
> at the moment.
> 
> Here's a patch to change that and also allow ".cmd" scripts, just like
> already done for postinstall scripts:
> 
>     install.cc: allow .dash and .cmd extensions for preremove scripts also

Please apply.


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]

On Feb  5 22:57, Achim Gratz wrote:
> 
> Oh, and while you are so deep in the bowels of setup.exe, would it be
> possible to somehow fake a pty to shell scripts and a console to cmd so
> that the scripts run by setup.exe produce their output in line-buffered
> instead of fully buffered mode?

Er... uh... *cough*... PTC?

For Cygwin processes this would require to duplicate lots of the pty
code from Cygwin to Setup.  For native commands it might be enough to
play with the process creation flags in the call to CreateProcess, but
that might lead to a flickering taskbar entry for a hidden console.

The other problem is that the stdio handles are redirected to a file
and thus, even if you have a console or pty, the output from the command
will use fully buffered mode.

The only way around that, afaics, is some sort of global setting (env
var?) for the buffering mode which is honored by native processes and
which may be read by the Cygwin DLL as well to enforce line buffering.
But I'm not aware such a setting exists.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
> On Feb  5 22:57, Achim Gratz wrote:
>> 
>> Oh, and while you are so deep in the bowels of setup.exe, would it be
>> possible to somehow fake a pty to shell scripts and a console to cmd so
>> that the scripts run by setup.exe produce their output in line-buffered
>> instead of fully buffered mode?
>
> Er... uh... *cough*... PTC?

I was hoping you had an idea of how to do this.  I'm coming up empty.

> For Cygwin processes this would require to duplicate lots of the pty
> code from Cygwin to Setup.  For native commands it might be enough to
> play with the process creation flags in the call to CreateProcess, but
> that might lead to a flickering taskbar entry for a hidden console.

I've tried to look for recipes, but have not found any that look promising.

http://www.pixelbeat.org/programming/stdio_buffering/

I notice the lack of both unbuffer and stdbuf in Cygwin packages…
I don't think it's possible to ask another application to flush their
buffers or is there?

> The other problem is that the stdio handles are redirected to a file
> and thus, even if you have a console or pty, the output from the command
> will use fully buffered mode.
>
> The only way around that, afaics, is some sort of global setting (env
> var?) for the buffering mode which is honored by native processes and
> which may be read by the Cygwin DLL as well to enforce line buffering.
> But I'm not aware such a setting exists.

Doesn't sound appealing.  Maybe we just have to live with it.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]

On Feb  6 12:25, Achim Gratz wrote:
> Corinna Vinschen writes:
> > On Feb  5 22:57, Achim Gratz wrote:
> >> 
> >> Oh, and while you are so deep in the bowels of setup.exe, would it be
> >> possible to somehow fake a pty to shell scripts and a console to cmd so
> >> that the scripts run by setup.exe produce their output in line-buffered
> >> instead of fully buffered mode?
> >
> > Er... uh... *cough*... PTC?
> 
> I was hoping you had an idea of how to do this.  I'm coming up empty.
> 
> > For Cygwin processes this would require to duplicate lots of the pty
> > code from Cygwin to Setup.  For native commands it might be enough to
> > play with the process creation flags in the call to CreateProcess, but
> > that might lead to a flickering taskbar entry for a hidden console.
> 
> I've tried to look for recipes, but have not found any that look promising.
> 
> http://www.pixelbeat.org/programming/stdio_buffering/
> 
> I notice the lack of both unbuffer and stdbuf in Cygwin packages…

Unbuffer should be in the expect package, stdbuf in coreutils.  In both
cases I don't know why they are missing in Cygwin.

Yaakov?  Eric?

> I don't think it's possible to ask another application to flush their
> buffers or is there?

If the application isn't prepared to do that (e.g. via signal), no.

> > The other problem is that the stdio handles are redirected to a file
> > and thus, even if you have a console or pty, the output from the command
> > will use fully buffered mode.
> >
> > The only way around that, afaics, is some sort of global setting (env
> > var?) for the buffering mode which is honored by native processes and
> > which may be read by the Cygwin DLL as well to enforce line buffering.
> > But I'm not aware such a setting exists.
> 
> Doesn't sound appealing.  Maybe we just have to live with it.

Looks like it, sorry.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1998 bytes --]

On 02/06/2015 02:24 AM, Corinna Vinschen wrote:
> On Feb  5 22:57, Achim Gratz wrote:
>>
>> Oh, and while you are so deep in the bowels of setup.exe, would it be
>> possible to somehow fake a pty to shell scripts and a console to cmd so
>> that the scripts run by setup.exe produce their output in line-buffered
>> instead of fully buffered mode?
> 
> Er... uh... *cough*... PTC?
> 
> For Cygwin processes this would require to duplicate lots of the pty
> code from Cygwin to Setup.  For native commands it might be enough to
> play with the process creation flags in the call to CreateProcess, but
> that might lead to a flickering taskbar entry for a hidden console.

For native commands (.bat, .cmd postinstalls), I have no idea.  But for
cygwin processes (.sh postinstalls), it would be neat if we could get
coreutils' stdbuf utility working on cygwin, then we just invoke 'sh -c
"stdbuf script.sh"' instead of 'sh -c "script.sh"'.

> 
> The other problem is that the stdio handles are redirected to a file
> and thus, even if you have a console or pty, the output from the command
> will use fully buffered mode.
> 
> The only way around that, afaics, is some sort of global setting (env
> var?) for the buffering mode which is honored by native processes and
> which may be read by the Cygwin DLL as well to enforce line buffering.
> But I'm not aware such a setting exists.

stdbuf uses LD_PRELOAD to tell a process in main() that it should use
line or no buffering, regardless of whether the output file is a file.
And cygwin supports LD_PRELOAD.  But to date, no one has helped figure
out how to port it to cygwin (I assume it should work, but have not had
time to try it - the difficulties lie more in getting the coreutils
Makefile to target the difference in cygwin naming with .dll instead of
.so and with .exe suffixes to worry about).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1996 bytes --]

On Feb  6 07:00, Eric Blake wrote:
> On 02/06/2015 02:24 AM, Corinna Vinschen wrote:
> > On Feb  5 22:57, Achim Gratz wrote:
> >>
> >> Oh, and while you are so deep in the bowels of setup.exe, would it be
> >> possible to somehow fake a pty to shell scripts and a console to cmd so
> >> that the scripts run by setup.exe produce their output in line-buffered
> >> instead of fully buffered mode?
> > 
> > Er... uh... *cough*... PTC?
> > 
> > For Cygwin processes this would require to duplicate lots of the pty
> > code from Cygwin to Setup.  For native commands it might be enough to
> > play with the process creation flags in the call to CreateProcess, but
> > that might lead to a flickering taskbar entry for a hidden console.
> 
> For native commands (.bat, .cmd postinstalls), I have no idea.  But for
> cygwin processes (.sh postinstalls), it would be neat if we could get
> coreutils' stdbuf utility working on cygwin, then we just invoke 'sh -c
> "stdbuf script.sh"' instead of 'sh -c "script.sh"'.
> 
> > 
> > The other problem is that the stdio handles are redirected to a file
> > and thus, even if you have a console or pty, the output from the command
> > will use fully buffered mode.
> > 
> > The only way around that, afaics, is some sort of global setting (env
> > var?) for the buffering mode which is honored by native processes and
> > which may be read by the Cygwin DLL as well to enforce line buffering.
> > But I'm not aware such a setting exists.
> 
> stdbuf uses LD_PRELOAD to tell a process in main() that it should use
> line or no buffering, regardless of whether the output file is a file.
> And cygwin supports LD_PRELOAD.

So it probably hooks into setbuf, setbuffer, setlinebuf and setvbuf.
LD_PRELOADing libc aka cygwin1.dll itself?  That sounds a bit tricky.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

coreutils: enable stdbuf (was: Setup patch to keep test version if test version installed)

[Yaakov Selkowitz]

On Fri, 2015-02-06 at 07:00 -0700, Eric Blake wrote:
> stdbuf uses LD_PRELOAD to tell a process in main() that it should use
> line or no buffering, regardless of whether the output file is a file.
> And cygwin supports LD_PRELOAD.  But to date, no one has helped figure
> out how to port it to cygwin (I assume it should work, but have not had
> time to try it - the difficulties lie more in getting the coreutils
> Makefile to target the difference in cygwin naming with .dll instead of
> .so and with .exe suffixes to worry about).

It would help if coreutils would use libtool, but I don't know if
upstream would be willing to consider that.  In the meantime, since
libstdbuf is just a module, the .so isn't a problem, and the build can
be worked around with a bit of a hack:

https://sourceforge.net/p/cygwin-ports/coreutils/ci/41db3dd6ed8d004e60b3005a9199e81306291b8c/

with the caveat that tests/misc/stdbuf.sh won't work in-tree.

--
Yaakov

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
> Please apply.

Done.  The notice via cygwin-apps-cvs was lost while the mailer was
having trouble to recognize the cygwin.com mailing lists.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

On Feb  8 21:24, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Please apply.
> 
> Done.  The notice via cygwin-apps-cvs was lost while the mailer was
> having trouble to recognize the cygwin.com mailing lists.

The patch is in, that's the important part :)


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 717 bytes --]

On Feb  4 12:19, Achim Gratz wrote:
> Corinna Vinschen writes:
> > I just applied a bigger patch, which not only changed exit, but the way
> > how the actual LogFile instance gets accessed in general.  I removed the
> > variable theLog entirely and now, rather than
> [...]
> > Please give it a try.  For your convenience I created test releases again:
> 
> Built and tested OK.

Thanks for testing!  I'm not going to upload this for the public yet.
I'm just uploading cygwin 1.7.34, that's enough to choke on for the
next couple of days :}


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
> I just applied a bigger patch, which not only changed exit, but the way
> how the actual LogFile instance gets accessed in general.  I removed the
> variable theLog entirely and now, rather than
[...]
> Please give it a try.  For your convenience I created test releases again:

Built and tested OK.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2644 bytes --]

On Feb  4 10:01, Corinna Vinschen wrote:
> On Feb  3 22:27, Corinna Vinschen wrote:
> > On Feb  3 22:04, Corinna Vinschen wrote:
> > > On Feb  3 21:37, Achim Gratz wrote:
> > > > I'm not sure we're talking about the same thing.  I've recently added
> > > > code to print an error message along with the parameter usage when a
> > > > wrong option or other non-parseable stuff was given instead of simply
> > > > exiting with no indication other than the non-zero exit code.  The
> > > > changes you've just installed look good to me, but they don't touch the
> > > > exit path in question:
> > > > [...]
> > > > I guess with those changes one could now use Log (LOG_TIMESTAMP) instead
> > > > of cerr in that place and hopefully the output would appear again?  I
> > > > was pretty certain I tested that in both mintty and CMD, but maybe
> > > > not...
> > > 
> > > I was referring explicitely to the CMD prompt being too early.  I didn't
> > > test the situation when specifying a wrong option, sorry.  The point in
> > > the file where this occurs is somewhat early.  At this point the log
> > > stuff isn't initialized and AttachConsole hasn't been called.  I'll 
> > > look into that, maybe it can be fixed easily.
> > 
> > Try this:
> 
> On second thought, this is still unclean.  What bugs me is that the
> behaviour of LogFile::exit is not easier conditionalized.  I'm going
> to change LogFile::exit to something like this:
> 
>   LogFile::exit (int exit_code, bool show_end_of_install_msg)
> 
> This allows to separate printing the "Ending cygwin install" message
> from the exit_code and so we can exit with a non-zero exit code *and*
> skip showing the message.  Hang on for a bit...

I just applied a bigger patch, which not only changed exit, but the way
how the actual LogFile instance gets accessed in general.  I removed the
variable theLog entirely and now, rather than

  LogSingleton::GetInstance ().exit (1);

or

  extern LogFile *theLog;
  theLog->exit (1);

you can simply use the macro Logger:

  Logger ().exit (1);

I also moved the global variable exit_msg into the LogFile class as
static, protected variable, and now you access it via

  Logger ().setExitMsg (42);
  Logger ().getExitMsg ();

This is much cleaner IMHO.


Please give it a try.  For your convenience I created test releases again:

  https://cygwin.com/setup-test-x86.exe
  https://cygwin.com/setup-test-x86_64.exe


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1785 bytes --]

On Feb  3 22:27, Corinna Vinschen wrote:
> On Feb  3 22:04, Corinna Vinschen wrote:
> > On Feb  3 21:37, Achim Gratz wrote:
> > > I'm not sure we're talking about the same thing.  I've recently added
> > > code to print an error message along with the parameter usage when a
> > > wrong option or other non-parseable stuff was given instead of simply
> > > exiting with no indication other than the non-zero exit code.  The
> > > changes you've just installed look good to me, but they don't touch the
> > > exit path in question:
> > > [...]
> > > I guess with those changes one could now use Log (LOG_TIMESTAMP) instead
> > > of cerr in that place and hopefully the output would appear again?  I
> > > was pretty certain I tested that in both mintty and CMD, but maybe
> > > not...
> > 
> > I was referring explicitely to the CMD prompt being too early.  I didn't
> > test the situation when specifying a wrong option, sorry.  The point in
> > the file where this occurs is somewhat early.  At this point the log
> > stuff isn't initialized and AttachConsole hasn't been called.  I'll 
> > look into that, maybe it can be fixed easily.
> 
> Try this:

On second thought, this is still unclean.  What bugs me is that the
behaviour of LogFile::exit is not easier conditionalized.  I'm going
to change LogFile::exit to something like this:

  LogFile::exit (int exit_code, bool show_end_of_install_msg)

This allows to separate printing the "Ending cygwin install" message
from the exit_code and so we can exit with a non-zero exit code *and*
skip showing the message.  Hang on for a bit...


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
> Try this:

Works a treat, please install.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 5043 bytes --]

On Feb  3 22:04, Corinna Vinschen wrote:
> On Feb  3 21:37, Achim Gratz wrote:
> > Corinna Vinschen writes:
> > > On Feb  3 18:08, Achim Gratz wrote:
> > >> Corinna Vinschen writes:
> > >> > How so?  Setup is not a Cygwin application.
> > >> 
> > >> Good point.  Then I've no idea at all, save the compiler.
> > >
> > > I had a look into this and even rearranged the behaviour when --help
> > > output is requested...
> > >
> > > However, I'm mildly sure this behaviour didn't change in the last couple
> > > of years.  The reason is that setup is not a console application but a
> > > GUI application.  When running a GUI application from CMD, CMD will
> > > detach.  Of course, when --help output is requested, setup calls
> > > AllocConsole, but that's too late.  This does not occur in a Cygwin
> > > shell becasue Cygwin always waits for process completion unless the
> > > process is sent to the background.
> > >
> > > I now made the latest setup 2.864 available as standard setup version
> > > on sourceware and removed the test releases.
> > 
> > I'm not sure we're talking about the same thing.  I've recently added
> > code to print an error message along with the parameter usage when a
> > wrong option or other non-parseable stuff was given instead of simply
> > exiting with no indication other than the non-zero exit code.  The
> > changes you've just installed look good to me, but they don't touch the
> > exit path in question:
> > 
> > --8<---------------cut here---------------start------------->8---
> >      if (!GetOption::GetInstance ().Process (argc,_argv, NULL))
> > -      exit (1);
> > +      {
> > +	GetOption::GetInstance ().ParameterUsage (cerr
> > +						  << "\nError during option processing."
> > +						  << "\nCommand Line Options:\n");
> > +	exit (1);
> > +      }
> > --8<---------------cut here---------------end--------------->8---
> > 
> > I guess with those changes one could now use Log (LOG_TIMESTAMP) instead
> > of cerr in that place and hopefully the output would appear again?  I
> > was pretty certain I tested that in both mintty and CMD, but maybe
> > not...
> 
> I was referring explicitely to the CMD prompt being too early.  I didn't
> test the situation when specifying a wrong option, sorry.  The point in
> the file where this occurs is somewhat early.  At this point the log
> stuff isn't initialized and AttachConsole hasn't been called.  I'll 
> look into that, maybe it can be fixed easily.

Try this:

Index: main.cc
===================================================================
RCS file: /cvs/cygwin-apps/setup/main.cc,v
retrieving revision 2.79
diff -u -p -r2.79 main.cc
--- main.cc	3 Feb 2015 19:51:49 -0000	2.79
+++ main.cc	3 Feb 2015 21:27:31 -0000
@@ -227,17 +227,16 @@ WinMain (HINSTANCE h,
   _argv = __argv;
 
   try {
+    bool help_option = false;
+    bool invalid_option = false;
     char cwd[MAX_PATH];
     GetCurrentDirectory (MAX_PATH, cwd);
     local_dir = std::string (cwd);
 
     if (!GetOption::GetInstance ().Process (argc,_argv, NULL))
-      {
-	GetOption::GetInstance ().ParameterUsage (cerr
-						  << "\nError during option processing."
-						  << "\nCommand Line Options:\n");
-	exit (1);
-      }
+      help_option = invalid_option = true;
+    else if (HelpOption)
+      help_option = true;
 
     if (!((string) Arch).size ())
       {
@@ -264,7 +263,7 @@ WinMain (HINSTANCE h,
     unattended_mode = PackageManagerOption ? chooseronly
 			: (UnattendedOption ? unattended : attended);
 
-    if (unattended_mode || HelpOption)
+    if (unattended_mode || help_option)
       set_cout ();
 
     /* Get System info */
@@ -275,7 +274,7 @@ WinMain (HINSTANCE h,
        supposed to elevate. */
     nt_sec.initialiseWellKnownSIDs ();
     /* Check if we have to elevate. */
-    bool elevate = !HelpOption && version.dwMajorVersion >= 6
+    bool elevate = !help_option && version.dwMajorVersion >= 6
 		   && !NoAdminOption && !nt_sec.isRunAsAdmin ();
 
     /* Start logging only if we don't elevate.  Same for setting default
@@ -284,7 +283,7 @@ WinMain (HINSTANCE h,
     const char *sep = isdirsep (local_dir[local_dir.size () - 1])
 				? "" : "\\";
     /* Don't create log files for help output only. */
-    if (!elevate && !HelpOption)
+    if (!elevate && !help_option)
       {
 	theLog->setFile (LOG_BABBLE, local_dir + sep + "setup.log.full",
 			 false);
@@ -293,8 +292,10 @@ WinMain (HINSTANCE h,
 			<< setup_version << endLog;
       }
 
-    if (HelpOption)
+    if (help_option)
       {
+	if (invalid_option)
+	  Log (LOG_PLAIN) << "\nError during option processing." << endLog;
 	Log (LOG_PLAIN) << "\nCommand Line Options:\n" << endLog;
 	GetOption::GetInstance ().ParameterUsage (Log (LOG_PLAIN));
 	Log (LOG_PLAIN) << endLog;


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2526 bytes --]

On Feb  3 21:37, Achim Gratz wrote:
> Corinna Vinschen writes:
> > On Feb  3 18:08, Achim Gratz wrote:
> >> Corinna Vinschen writes:
> >> > How so?  Setup is not a Cygwin application.
> >> 
> >> Good point.  Then I've no idea at all, save the compiler.
> >
> > I had a look into this and even rearranged the behaviour when --help
> > output is requested...
> >
> > However, I'm mildly sure this behaviour didn't change in the last couple
> > of years.  The reason is that setup is not a console application but a
> > GUI application.  When running a GUI application from CMD, CMD will
> > detach.  Of course, when --help output is requested, setup calls
> > AllocConsole, but that's too late.  This does not occur in a Cygwin
> > shell becasue Cygwin always waits for process completion unless the
> > process is sent to the background.
> >
> > I now made the latest setup 2.864 available as standard setup version
> > on sourceware and removed the test releases.
> 
> I'm not sure we're talking about the same thing.  I've recently added
> code to print an error message along with the parameter usage when a
> wrong option or other non-parseable stuff was given instead of simply
> exiting with no indication other than the non-zero exit code.  The
> changes you've just installed look good to me, but they don't touch the
> exit path in question:
> 
> --8<---------------cut here---------------start------------->8---
>      if (!GetOption::GetInstance ().Process (argc,_argv, NULL))
> -      exit (1);
> +      {
> +	GetOption::GetInstance ().ParameterUsage (cerr
> +						  << "\nError during option processing."
> +						  << "\nCommand Line Options:\n");
> +	exit (1);
> +      }
> --8<---------------cut here---------------end--------------->8---
> 
> I guess with those changes one could now use Log (LOG_TIMESTAMP) instead
> of cerr in that place and hopefully the output would appear again?  I
> was pretty certain I tested that in both mintty and CMD, but maybe
> not...

I was referring explicitely to the CMD prompt being too early.  I didn't
test the situation when specifying a wrong option, sorry.  The point in
the file where this occurs is somewhat early.  At this point the log
stuff isn't initialized and AttachConsole hasn't been called.  I'll 
look into that, maybe it can be fixed easily.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
> On Feb  3 18:08, Achim Gratz wrote:
>> Corinna Vinschen writes:
>> > How so?  Setup is not a Cygwin application.
>> 
>> Good point.  Then I've no idea at all, save the compiler.
>
> I had a look into this and even rearranged the behaviour when --help
> output is requested...
>
> However, I'm mildly sure this behaviour didn't change in the last couple
> of years.  The reason is that setup is not a console application but a
> GUI application.  When running a GUI application from CMD, CMD will
> detach.  Of course, when --help output is requested, setup calls
> AllocConsole, but that's too late.  This does not occur in a Cygwin
> shell becasue Cygwin always waits for process completion unless the
> process is sent to the background.
>
> I now made the latest setup 2.864 available as standard setup version
> on sourceware and removed the test releases.

I'm not sure we're talking about the same thing.  I've recently added
code to print an error message along with the parameter usage when a
wrong option or other non-parseable stuff was given instead of simply
exiting with no indication other than the non-zero exit code.  The
changes you've just installed look good to me, but they don't touch the
exit path in question:

--8<---------------cut here---------------start------------->8---
     if (!GetOption::GetInstance ().Process (argc,_argv, NULL))
-      exit (1);
+      {
+	GetOption::GetInstance ().ParameterUsage (cerr
+						  << "\nError during option processing."
+						  << "\nCommand Line Options:\n");
+	exit (1);
+      }
--8<---------------cut here---------------end--------------->8---

I guess with those changes one could now use Log (LOG_TIMESTAMP) instead
of cerr in that place and hopefully the output would appear again?  I
was pretty certain I tested that in both mintty and CMD, but maybe
not...


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

On Feb  3 18:08, Achim Gratz wrote:
> Corinna Vinschen writes:
> > How so?  Setup is not a Cygwin application.
> 
> Good point.  Then I've no idea at all, save the compiler.

I had a look into this and even rearranged the behaviour when --help
output is requested...

However, I'm mildly sure this behaviour didn't change in the last couple
of years.  The reason is that setup is not a console application but a
GUI application.  When running a GUI application from CMD, CMD will
detach.  Of course, when --help output is requested, setup calls
AllocConsole, but that's too late.  This does not occur in a Cygwin
shell becasue Cygwin always waits for process completion unless the
process is sent to the background.

I now made the latest setup 2.864 available as standard setup version
on sourceware and removed the test releases.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
> How so?  Setup is not a Cygwin application.

Good point.  Then I've no idea at all, save the compiler.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1702 bytes --]

On Feb  3 17:07, Achim Gratz wrote:
> Corinna Vinschen writes:
> > You're a user of the new -m option if I understood you correctly.
> > Does it work for you?
> 
> Yes, very well indeed.
> 
> > What about allowing to specify this in the GUI?  I was mulling over
> > adding a fourth option to the "Choose A Download Source" dialog:
> >
> >  o Install from Internet
> >  o Download Without Installing
> >  o Install from Local Download Directory
> >  o Install from Local Mirror Directory
> >
> > Option 3 is the same as before, but specifying "Download Directory"
> > to distinguish this from "Mirror Directory".
> >
> > Good/Bad/Ugly?
> 
> I'm not sure it's useful in the GUI-only scenario when someone just
> double-clicks the icon.  At least in my case that use is strictly for
> script-controlled installations.  It will be hard for people to tell
> what the difference is between Download and Mirror directory and which
> they should use.  People who know what they're doing can just as easily
> make a shortcut that adds the -m option.
> 
> BTW, there seems to be a regression that I don't understand: when a
> wrong option is given, a message to this effect should be emitted and
> then the parameter usage.  This used to work, but even though the code
> did not change this is not happening anymore.  I've rolled back to the
> old version of setup, but not cygwin1.dll, so if its not the compiler it
> would be a change in the DLL that is responsible.

How so?  Setup is not a Cygwin application.


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
> You're a user of the new -m option if I understood you correctly.
> Does it work for you?

Yes, very well indeed.

> What about allowing to specify this in the GUI?  I was mulling over
> adding a fourth option to the "Choose A Download Source" dialog:
>
>  o Install from Internet
>  o Download Without Installing
>  o Install from Local Download Directory
>  o Install from Local Mirror Directory
>
> Option 3 is the same as before, but specifying "Download Directory"
> to distinguish this from "Mirror Directory".
>
> Good/Bad/Ugly?

I'm not sure it's useful in the GUI-only scenario when someone just
double-clicks the icon.  At least in my case that use is strictly for
script-controlled installations.  It will be hard for people to tell
what the difference is between Download and Mirror directory and which
they should use.  People who know what they're doing can just as easily
make a shortcut that adds the -m option.

BTW, there seems to be a regression that I don't understand: when a
wrong option is given, a message to this effect should be emitted and
then the parameter usage.  This used to work, but even though the code
did not change this is not happening anymore.  I've rolled back to the
old version of setup, but not cygwin1.dll, so if its not the compiler it
would be a change in the DLL that is responsible.  I suspect there is
some race with the output since also in the case of --help the output
from setup somehow mixes in with the prompt from cmd and you have to
press Enter a second time to get the prompt back.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Corinna Vinschen writes:
> On Feb  3 16:09, Achim Gratz wrote:
>> Achim Gratz writes:
>> > [TEST 2]
>> 
>> [TEST 3]
>
> *frown*

Sorry for that, but the mail server I use needed a configuration change
and this is the only mailing list that was affected so I had to test
directly.  Things are back to normal, I can reply and post again from
Gnus.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 962 bytes --]

On Feb  3 14:56, ASSI wrote:
> Corinna Vinschen writes:
> > Did you test this version?  Is it ok to become the release version of
> > setup?
> 
> WJFFM.  I didn't test the downgrade scenario since none of my
> installations have "test" or "prev" packages in setup.ini, though.

You're a user of the new -m option if I understood you correctly.
Does it work for you?

What about allowing to specify this in the GUI?  I was mulling over
adding a fourth option to the "Choose A Download Source" dialog:

 o Install from Internet
 o Download Without Installing
 o Install from Local Download Directory
 o Install from Local Mirror Directory

Option 3 is the same as before, but specifying "Download Directory"
to distinguish this from "Mirror Directory".

Good/Bad/Ugly?


Thanks,
Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 264 bytes --]

On Feb  3 16:09, Achim Gratz wrote:
> Achim Gratz writes:
> > [TEST 2]
> 
> [TEST 3]

*frown*


Corinna

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

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

Achim Gratz writes:
> [TEST 2]

[TEST 3]

Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

[TEST 2]

Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

Re: Setup patch to keep test version if test version installed

[Achim Gratz]

[TEST] 

Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

DIY Stuff:
http://Synth.Stromeko.net/DIY.html

Re: Setup patch to keep test version if test version installed

[ASSI]

Corinna Vinschen writes:
> Did you test this version?  Is it ok to become the release version of
> setup?

WJFFM.  I didn't test the downgrade scenario since none of my
installations have "test" or "prev" packages in setup.ini, though.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada