per-version hints proposal

classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

per-version hints proposal

Jon TURNEY

Currently, the setup.hint file is shared between all versions.

This means that manual intervention (by the package maintainer, or on
sourceware) is needed when versions have different dependencies.

To automate this problem out of existence, I suggest replacing the
setup.hint file in an upload with a package-version-release.hint file.

This will be basically identical to the existing setup.hint, with the
advantage that it can't be trampled on by a future version, with the
following changes:

* 'skip' doesn't seem meaningful on a per-version basis.  Since it seems
we can automatically detect packages which should have this applied
anyhow (see the discussion in [1]), I'd suggest ignoring this hint, to
be retired at some future date.

* 'curr', 'prev' and 'test' don't make sense on a per-version basis.  So
I suggest a separate file for these version overrides (versions.hint?)


cygport will be updated to create a pvr.hint rather than setup.hint


calm will be changed so that:

* The requires: line written in setup.ini will contain the union of the
requires: from each pvr.hint

* The sdesc:, ldesc:, category: and message: lines in setup.ini will be
taken from the pvr.hint for the curr version

* While it's already effectively mandatory that a package has a curr
version, this requirement will be documented and enforced.

* The source: line in setup.ini for a package version will consider any
external-source: from the corresponding pvr.hint

* Uploads with a setup.hint will continue to work as before, for a
transitional period.


No setup changes are required.


Immediately, this avoids the need for manual intervention when versions
have different dependencies, and going forward, this is lays some
groundwork for supporting per-version dependencies.


[1] https://cygwin.com/ml/cygwin-apps/2016-02/msg00017.html
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: per-version hints proposal

Corinna Vinschen-2
On Jun 20 16:28, Jon Turney wrote:

>
> Currently, the setup.hint file is shared between all versions.
>
> This means that manual intervention (by the package maintainer, or on
> sourceware) is needed when versions have different dependencies.
>
> To automate this problem out of existence, I suggest replacing the
> setup.hint file in an upload with a package-version-release.hint file.
>
> This will be basically identical to the existing setup.hint, with the
> advantage that it can't be trampled on by a future version, with the
> following changes:
>
> * 'skip' doesn't seem meaningful on a per-version basis.  Since it seems we
> can automatically detect packages which should have this applied anyhow (see
> the discussion in [1]), I'd suggest ignoring this hint, to be retired at
> some future date.
>
> * 'curr', 'prev' and 'test' don't make sense on a per-version basis.  So I
> suggest a separate file for these version overrides (versions.hint?)
Ideally we wouldn't need something like "prev" at all since the version
number itself is sufficient to specify what's curr and what's old.

As for test, IMHO it would make sense to specify "this is a test
release" right in the cygport file.  This in turn could create a
per-version hint with a test marker which is evaluated by calm
accordingly.  For instance, the name of the file could take over this
role.  Or even better, the package version number itself.

This would have an additional benefit:  We couldn't just move a package
from test to curr, it would have to be explicitely rebuilt as non-test
release.

I think this is the cleanest solution.

> cygport will be updated to create a pvr.hint rather than setup.hint
>
>
> calm will be changed so that:
>
> * The requires: line written in setup.ini will contain the union of the
> requires: from each pvr.hint
>
> * The sdesc:, ldesc:, category: and message: lines in setup.ini will be
> taken from the pvr.hint for the curr version
>
> * While it's already effectively mandatory that a package has a curr
> version, this requirement will be documented and enforced.
>
> * The source: line in setup.ini for a package version will consider any
> external-source: from the corresponding pvr.hint
>
> * Uploads with a setup.hint will continue to work as before, for a
> transitional period.
>
>
> No setup changes are required.
>
>
> Immediately, this avoids the need for manual intervention when versions have
> different dependencies, and going forward, this is lays some groundwork for
> supporting per-version dependencies.
Sounds good to me.


Corinna

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: per-version hints proposal

marco atzeri-4

On 21/06/2016 14:03, Corinna Vinschen wrote:

> On Jun 20 16:28, Jon Turney wrote:
>>
>> Currently, the setup.hint file is shared between all versions.
>>
>> This means that manual intervention (by the package maintainer, or on
>> sourceware) is needed when versions have different dependencies.
>>
>> To automate this problem out of existence, I suggest replacing the
>> setup.hint file in an upload with a package-version-release.hint file.
>>
>> This will be basically identical to the existing setup.hint, with the
>> advantage that it can't be trampled on by a future version, with the
>> following changes:
>>

fine for me.


> Ideally we wouldn't need something like "prev" at all since the version
> number itself is sufficient to specify what's curr and what's old.
>
> As for test, IMHO it would make sense to specify "this is a test
> release" right in the cygport file.  This in turn could create a
> per-version hint with a test marker which is evaluated by calm
> accordingly.  For instance, the name of the file could take over this
> role.  Or even better, the package version number itself.
>
> This would have an additional benefit:  We couldn't just move a package
> from test to curr, it would have to be explicitely rebuilt as non-test
> release.

not a huge fan of this.
The last time we made the perl transition we put a lot of package in
test as temporary solution. Rebuild all just to change a label
seems a waste of time.

>>
>> No setup changes are required.
>>
>>
>> Immediately, this avoids the need for manual intervention when versions have
>> different dependencies, and going forward, this is lays some groundwork for
>> supporting per-version dependencies.
>
> Sounds good to me.

+1


> Corinna

Marco


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: per-version hints proposal

Eric Blake (cygwin)-2
In reply to this post by Corinna Vinschen-2
On 06/21/2016 06:03 AM, Corinna Vinschen wrote:

>> * 'curr', 'prev' and 'test' don't make sense on a per-version basis.  So I
>> suggest a separate file for these version overrides (versions.hint?)
>
> Ideally we wouldn't need something like "prev" at all since the version
> number itself is sufficient to specify what's curr and what's old.

Except when upstream version numbers go backwards.  We'd have to adopt
something like Fedora's "epoch" numbering if we want our version numbers
to always be increasing (by bumping the epoch any time upstream versions
go backwards).

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


signature.asc (617 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: per-version hints proposal

Corinna Vinschen-2
On Jun 21 08:08, Eric Blake wrote:

> On 06/21/2016 06:03 AM, Corinna Vinschen wrote:
>
> >> * 'curr', 'prev' and 'test' don't make sense on a per-version basis.  So I
> >> suggest a separate file for these version overrides (versions.hint?)
> >
> > Ideally we wouldn't need something like "prev" at all since the version
> > number itself is sufficient to specify what's curr and what's old.
>
> Except when upstream version numbers go backwards.  We'd have to adopt
> something like Fedora's "epoch" numbering if we want our version numbers
> to always be increasing (by bumping the epoch any time upstream versions
> go backwards).
I think Yaakov is desperately asking for this for a long time :)


Corinna

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: per-version hints proposal

Corinna Vinschen-2
In reply to this post by marco atzeri-4
On Jun 21 15:49, Marco Atzeri wrote:

>
> On 21/06/2016 14:03, Corinna Vinschen wrote:
> > On Jun 20 16:28, Jon Turney wrote:
> > >
> > > Currently, the setup.hint file is shared between all versions.
> > >
> > > This means that manual intervention (by the package maintainer, or on
> > > sourceware) is needed when versions have different dependencies.
> > >
> > > To automate this problem out of existence, I suggest replacing the
> > > setup.hint file in an upload with a package-version-release.hint file.
> > >
> > > This will be basically identical to the existing setup.hint, with the
> > > advantage that it can't be trampled on by a future version, with the
> > > following changes:
> > >
>
> fine for me.
>
>
> > Ideally we wouldn't need something like "prev" at all since the version
> > number itself is sufficient to specify what's curr and what's old.
> >
> > As for test, IMHO it would make sense to specify "this is a test
> > release" right in the cygport file.  This in turn could create a
> > per-version hint with a test marker which is evaluated by calm
> > accordingly.  For instance, the name of the file could take over this
> > role.  Or even better, the package version number itself.
> >
> > This would have an additional benefit:  We couldn't just move a package
> > from test to curr, it would have to be explicitely rebuilt as non-test
> > release.
>
> not a huge fan of this.
> The last time we made the perl transition we put a lot of package in
> test as temporary solution. Rebuild all just to change a label
> seems a waste of time.
Not a huge fan of what part?  I think in general it makes sense to
keep the "test" info in the ${version}.hint file.  If a simple
change to this file moves ${version} to non-test, ok with me.


Corinna

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: per-version hints proposal

marco atzeri-4
On 21/06/2016 16:28, Corinna Vinschen wrote:

> On Jun 21 15:49, Marco Atzeri wrote:
>>
>> On 21/06/2016 14:03, Corinna Vinschen wrote:
>>> On Jun 20 16:28, Jon Turney wrote:
>>>>
>
>>
>>> Ideally we wouldn't need something like "prev" at all since the version
>>> number itself is sufficient to specify what's curr and what's old.
>>>
>>> As for test, IMHO it would make sense to specify "this is a test
>>> release" right in the cygport file.  This in turn could create a
>>> per-version hint with a test marker which is evaluated by calm
>>> accordingly.  For instance, the name of the file could take over this
>>> role.  Or even better, the package version number itself.
>>>
>>> This would have an additional benefit:  We couldn't just move a package
>>> from test to curr, it would have to be explicitely rebuilt as non-test
>>> release.
>>
>> not a huge fan of this.
>> The last time we made the perl transition we put a lot of package in
>> test as temporary solution. Rebuild all just to change a label
>> seems a waste of time.
>
> Not a huge fan of what part?  I think in general it makes sense to
> keep the "test" info in the ${version}.hint file.  If a simple
> change to this file moves ${version} to non-test, ok with me.

changing ${version}.hint is fine also for me.

Rebuilding packages not ;-)

>
>
> Corinna
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: per-version hints proposal

Achim Gratz
In reply to this post by Eric Blake (cygwin)-2
Eric Blake writes:
> Except when upstream version numbers go backwards.  We'd have to adopt
> something like Fedora's "epoch" numbering if we want our version numbers
> to always be increasing (by bumping the epoch any time upstream versions
> go backwards).

Oh please not.  I've looked into this as I thought it would be helping a
few things.  The bummer is that once you've introduced that epoch part
to any package, there is no way to drop it again.  I'd rather keep a
list of exceptions someplace for those rare cases where the versioning
algorithm doesn't do the right thing.  Actually, I'm already doing it
for the Perl distributions to override dodgy information in metadata
about dependencies.


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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: per-version hints proposal

Jon TURNEY
In reply to this post by Corinna Vinschen-2
On 21/06/2016 13:03, Corinna Vinschen wrote:
> On Jun 20 16:28, Jon Turney wrote:
[...]

>> * 'curr', 'prev' and 'test' don't make sense on a per-version basis.  So I
>> suggest a separate file for these version overrides (versions.hint?)
>
> Ideally we wouldn't need something like "prev" at all since the version
> number itself is sufficient to specify what's curr and what's old.
>
> As for test, IMHO it would make sense to specify "this is a test
> release" right in the cygport file.  This in turn could create a
> per-version hint with a test marker which is evaluated by calm
> accordingly.  For instance, the name of the file could take over this
> role.  Or even better, the package version number itself.
>
> This would have an additional benefit:  We couldn't just move a package
> from test to curr, it would have to be explicitely rebuilt as non-test
> release.
>
> I think this is the cleanest solution.

I'm not sure I agree with this reasoning.

Without control over the other elements which determine the build
product (e.g. compiler version, headers, static libraries, etc.), there
is the risk that any testing you have done on the test package is
invalidated when it is rebuilt.

Otoh, if you did have perfect build reproducibility, you are rebuilding
the package just to change a label applied to it, which seems a bit
inefficient.

I take the point that 'test' could be more useful, but I think that's
out of scope of what I want to achieve, for the moment.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: per-version hints proposal

Jon TURNEY
In reply to this post by Jon TURNEY
On 20/06/2016 16:28, Jon Turney wrote:
> Currently, the setup.hint file is shared between all versions.
>
> This means that manual intervention (by the package maintainer, or on
> sourceware) is needed when versions have different dependencies.
>
> To automate this problem out of existence, I suggest replacing the
> setup.hint file in an upload with a package-version-release.hint file.

I deployed an update to calm today which adds support for this proposal,
with some minor adjustments noted below.

Nobody can actually use this until a cygport with the corresponding
changes is released, which still needs some testing, after which I will
update the website documentation.

> This will be basically identical to the existing setup.hint, with the
> advantage that it can't be trampled on by a future version, with the
> following changes:
>
> * 'skip' doesn't seem meaningful on a per-version basis.  Since it seems
> we can automatically detect packages which should have this applied
> anyhow (see the discussion in [1]), I'd suggest ignoring this hint, to
> be retired at some future date.

skip is honoured, if present, but not required.

> * 'curr', 'prev' and 'test' don't make sense on a per-version basis.  So
> I suggest a separate file for these version overrides (versions.hint?)

This file is called override.hint.

> cygport will be updated to create a pvr.hint rather than setup.hint

I'll send a patch to update cygport separately.

> calm will be changed so that:
>
> * The requires: line written in setup.ini will contain the union of the
> requires: from each pvr.hint
>
> * The sdesc:, ldesc:, category: and message: lines in setup.ini will be
> taken from the pvr.hint for the curr version
>
> * While it's already effectively mandatory that a package has a curr
> version, this requirement will be documented and enforced.

calm will issue a warning, not an error, when a package doesn't have a
current version.  For the purpose above, information from the highest
version will be used in place of information from the curr version.

per the discussion [1], it's possibly useful in mksetupini, so the
warning can be suppressed there.

[1] https://cygwin.com/ml/cygwin-apps/2016-07/msg00052.html

> * The source: line in setup.ini for a package version will consider any
> external-source: from the corresponding pvr.hint
>
> * Uploads with a setup.hint will continue to work as before, for a
> transitional period.
>
>
> No setup changes are required.
>
>
> Immediately, this avoids the need for manual intervention when versions
> have different dependencies, and going forward, this is lays some
> groundwork for supporting per-version dependencies.
>
>
> [1] https://cygwin.com/ml/cygwin-apps/2016-02/msg00017.html

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: per-version hints proposal

Achim Gratz
Jon Turney writes:
>> calm will be changed so that:
>>
>> * The requires: line written in setup.ini will contain the union of the
>> requires: from each pvr.hint
>>
>> * The sdesc:, ldesc:, category: and message: lines in setup.ini will be
>> taken from the pvr.hint for the curr version

I've not given this much more thought, but I think we should change the
setup.ini syntax to allow different values for _all_ keys in a package
for each version.  The ones that are not in a specific section
(i.e. where they are now, right after the package line) would just
provide a default that gets used when there is no version-specific value
provided in the corresponding section.  Calm could/should move such
key/value pairs to the default when they are identical among the
majority of versions, otherwise use those from the current version.


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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: per-version hints proposal

Jon TURNEY
On 31/08/2016 20:13, Achim Gratz wrote:

> Jon Turney writes:
>>> calm will be changed so that:
>>>
>>> * The requires: line written in setup.ini will contain the union of the
>>> requires: from each pvr.hint
>>>
>>> * The sdesc:, ldesc:, category: and message: lines in setup.ini will be
>>> taken from the pvr.hint for the curr version
>
> I've not given this much more thought, but I think we should change the
> setup.ini syntax to allow different values for _all_ keys in a package
> for each version.

Yes, ultimately.

There's not much value until we have some functionality or UI which uses
that, though, and changing setup.ini syntax like that is probably
incompatible with older setup.

 > The ones that are not in a specific section
> (i.e. where they are now, right after the package line) would just
> provide a default that gets used when there is no version-specific value
> provided in the corresponding section.  Calm could/should move such
> key/value pairs to the default when they are identical among the
> majority of versions, otherwise use those from the current version.

This seems perhaps a bit of a premature optimization.

The setup.ini will be compressed, so any redundancy between versions
won't affect the file size much.




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: per-version hints proposal

Achim Gratz
In reply to this post by Jon TURNEY
Jon Turney writes:
> Currently, the setup.hint file is shared between all versions.
>
> This means that manual intervention (by the package maintainer, or on
> sourceware) is needed when versions have different dependencies.
>
> To automate this problem out of existence, I suggest replacing the
> setup.hint file in an upload with a package-version-release.hint file.

Since this is now moving into reality, the documentation in

https://cygwin.com/setup.html

has become out-of-date.


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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: per-version hints proposal

marco atzeri-4
On 17/09/2016 08:14, Achim Gratz wrote:

> Jon Turney writes:
>> Currently, the setup.hint file is shared between all versions.
>>
>> This means that manual intervention (by the package maintainer, or on
>> sourceware) is needed when versions have different dependencies.
>>
>> To automate this problem out of existence, I suggest replacing the
>> setup.hint file in an upload with a package-version-release.hint file.
>
> Since this is now moving into reality, the documentation in
>
> https://cygwin.com/setup.html
>
> has become out-of-date.
>
>
> Regards,
> Achim.
>

are we not yet missing an updated cygport release ?
Or a test one


Regards
Marco
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: per-version hints proposal

Jon TURNEY
On 18/09/2016 06:17, Marco Atzeri wrote:

> On 17/09/2016 08:14, Achim Gratz wrote:
>> Jon Turney writes:
>>> Currently, the setup.hint file is shared between all versions.
>>>
>>> This means that manual intervention (by the package maintainer, or on
>>> sourceware) is needed when versions have different dependencies.
>>>
>>> To automate this problem out of existence, I suggest replacing the
>>> setup.hint file in an upload with a package-version-release.hint file.
>>
>> Since this is now moving into reality, the documentation in
>>
>> https://cygwin.com/setup.html
>>
>> has become out-of-date.
>>
>>
>> Regards,
>> Achim.
>>
>
> are we not yet missing an updated cygport release ?
> Or a test one

Yes, this is only usable by people running cygport from git, currently.

After I wrote the documentation update, I found it needs to describe
the backwards-compatible use of setup.hint.

Given that, there didn't seem to be any harm in pushing the
documentation update now.


Achim,

I notice the section about postinstall scripts doesn't mention permanent
postinsall scripts at all.

Could you possibly provide a couple of paragraphs?

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: per-version hints proposal

Achim Gratz
Jon Turney writes:
> I notice the section about postinstall scripts doesn't mention
> permanent postinsall scripts at all.
>
> Could you possibly provide a couple of paragraphs?

I had sent them to this very list at the time.  I need to dig them out
of the archive unless you're faster.


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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: per-version hints proposal

Achim Gratz
Achim Gratz writes:
> Jon Turney writes:
>> I notice the section about postinstall scripts doesn't mention
>> permanent postinsall scripts at all.
>>
>> Could you possibly provide a couple of paragraphs?
>
> I had sent them to this very list at the time.  I need to dig them out
> of the archive unless you're faster.

There it is:
https://cygwin.com/ml/cygwin-apps/2014-12/msg00148.html


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

DIY Stuff:
http://Synth.Stromeko.net/DIY.html
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: per-version hints proposal

Ken Brown-6
In reply to this post by Jon TURNEY
On 9/18/2016 11:14 AM, Jon Turney wrote:

> On 18/09/2016 06:17, Marco Atzeri wrote:
>> On 17/09/2016 08:14, Achim Gratz wrote:
>>> Jon Turney writes:
>>>> Currently, the setup.hint file is shared between all versions.
>>>>
>>>> This means that manual intervention (by the package maintainer, or on
>>>> sourceware) is needed when versions have different dependencies.
>>>>
>>>> To automate this problem out of existence, I suggest replacing the
>>>> setup.hint file in an upload with a package-version-release.hint file.
>>>
>>> Since this is now moving into reality, the documentation in
>>>
>>> https://cygwin.com/setup.html
>>>
>>> has become out-of-date.
>>>
>>>
>>> Regards,
>>> Achim.
>>>
>>
>> are we not yet missing an updated cygport release ?
>> Or a test one
>
> Yes, this is only usable by people running cygport from git, currently.
>
> After I wrote the documentation update, I found it needs to describe
> the backwards-compatible use of setup.hint.
>
> Given that, there didn't seem to be any harm in pushing the
> documentation update now.
>
>
> Achim,
>
> I notice the section about postinstall scripts doesn't mention permanent
> postinsall scripts at all.
>
> Could you possibly provide a couple of paragraphs?

Another thing: The page still says that all release announcements should
contain information about unsubscribing from the cygwin-announce mailing
list.  But it seems that many (most?) maintainers have stopped doing
this.  And 'cygport announce' doesn't do it.  Should that instruction be
removed?

Ken
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: per-version hints proposal

marco atzeri-4
On 18/09/2016 18:41, Ken Brown wrote:

>
> Another thing: The page still says that all release announcements should
> contain information about unsubscribing from the cygwin-announce mailing
> list.  But it seems that many (most?) maintainers have stopped doing
> this.  And 'cygport announce' doesn't do it.  Should that instruction be
> removed?
>
> Ken

I suggest to remove the requirements.

The main list have in automatic:

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

that is it more than enough.

Regards
Marco




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: per-version hints proposal

Achim Gratz
Marco Atzeri writes:

> I suggest to remove the requirements.
>
> The main list have in automatic:
>
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>
> that is it more than enough.

That doesn't help you much when you're subscribed to the announcement
list instead of the main list, which I think was the point of the
requirement.


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
12
Loading...