[ITA] _autorebase

[ITA] _autorebase

[Achim Gratz]

--8<---------------cut here---------------start------------->8---
wget="wget -rxnH http://cygwin.stromeko.net/noarch/release"
$wget/_autorebase-001000-1-src.tar.xz
$wget/_autorebase-001000-1.tar.xz
$wget/setup.hint
--8<---------------cut here---------------end--------------->8---


Requirements before deployment:

- all autodep stuff referring to _autorebase must be removed
- setup.exe version 2.858 or later must be used


Notes:

There will be no ITP for _incautorebase since Corinna wanted a
replacement for _autorebase instead.

Dependencies on _autorebase should not be used, but are harmless.  This
is a Base package and it will always be run in postinstall.

This release comes with an additional script rebase-trigger that can be
used to have the postinstall script run a full rebase or peflags the
next time setup.exe is run (with or without an update or additional
installations or removals).  Once this is in place the description of
how to do a manual full rebase should refer to this method instead since
I expect it to be much easier to follow.

Packages that need to tap into the autorebase infrastructure for dynamic
objects should drop a file /etc/rebase/dynpath.d/<package> that has the
path to be searched for dynamic objects as its content.  Currently these
files are delivered with _autorebase, but when packages get updated they
should take over that responsibility.  Please announce such changes so
that the corresponding file can be removed from the _autorebase package
before the new package version gets deployed.



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: [ITA] _autorebase

[Ken Brown]

On 12/13/2014 10:56 AM, Achim Gratz wrote:
>
> --8<---------------cut here---------------start------------->8---
> wget="wget -rxnH http://cygwin.stromeko.net/noarch/release"
> $wget/_autorebase-001000-1-src.tar.xz
> $wget/_autorebase-001000-1.tar.xz
> $wget/setup.hint
> --8<---------------cut here---------------end--------------->8---

You forgot the package directory name:

wget="wget -rxnH http://cygwin.stromeko.net/noarch/release/_autorebase"

Ken

Re: [ITA] _autorebase

[Ken Brown]

On 12/13/2014 10:56 AM, Achim Gratz wrote:
> Requirements before deployment:
>
> - all autodep stuff referring to _autorebase must be removed
> - setup.exe version 2.858 or later must be used
>
>
> Notes:
>
> There will be no ITP for _incautorebase since Corinna wanted a
> replacement for _autorebase instead.
>
> Dependencies on _autorebase should not be used, but are harmless.  This
> is a Base package and it will always be run in postinstall.
>
> This release comes with an additional script rebase-trigger that can be
> used to have the postinstall script run a full rebase or peflags the
> next time setup.exe is run (with or without an update or additional
> installations or removals).  Once this is in place the description of
> how to do a manual full rebase should refer to this method instead since
> I expect it to be much easier to follow.
>
> Packages that need to tap into the autorebase infrastructure for dynamic
> objects should drop a file /etc/rebase/dynpath.d/<package> that has the
> path to be searched for dynamic objects as its content.  Currently these
> files are delivered with _autorebase, but when packages get updated they
> should take over that responsibility.  Please announce such changes so
> that the corresponding file can be removed from the _autorebase package
> before the new package version gets deployed.

A few questions:

1. Shouldn't you have removed the following line from rebase_do?

     peflags ${verbose} -d0 -t0 -T "${g}"

2. Did you intend to have a "verbose" option, or is ${verbose} just there for 
debugging?

3. Shouldn't 0p_autorebase.dash be given a name something like 
0p_000autorebase.dash to make it reasonably sure that it will be run before all 
other 0p_* scripts?

Ken

Re: [ITA] _autorebase

[Achim Gratz]

Ken Brown writes:
> 1. Shouldn't you have removed the following line from rebase_do?
>
>     peflags ${verbose} -d0 -t0 -T "${g}"

That isn't redundant and has nothing to do with the stuff in peflags_do,
although I don't remember exactly what the problem was that was resolved
by this.  The current toolchain should be clean, though, so it may best
be an optional step.

> 2. Did you intend to have a "verbose" option, or is ${verbose} just
> there for debugging?

I've implemented it for debugging indeed, although I wouldn't mind
making it an official option.

> 3. Shouldn't 0p_autorebase.dash be given a name something like
> 0p_000autorebase.dash to make it reasonably sure that it will be run
> before all other 0p_* scripts?

It's the only one for now and perpetual scripts must be coordinated
among all packages, but if it helps you sleep better… :-)


I've just implemented the extra options and replaced the package files.

--8<---------------cut here---------------start------------->8---
wget="wget -rxnH http://cygwin.stromeko.net/noarch/release/_autorebase"
$wget/_autorebase-001000-1-src.tar.xz
$wget/_autorebase-001000-1.tar.xz
$wget/setup.hint
--8<---------------cut here---------------end--------------->8---


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: [ITA] _autorebase

[Achim Gratz]

Packages rebuilt with cygport including the changes discussed with Ken
and pre-compiled setup.exe files added.

--8<---------------cut here---------------start------------->8---
cygwin=http://cygwin.stromeko.net/
wget $cygwin/noarch/release/_autorebase/_autorebase-001000-1-src.tar.xz
wget $cygwin/noarch/release/_autorebase/_autorebase-001000-1.tar.xz
wget $cygwin/noarch/release/_autorebase/setup.hint
wget $cygwin/x86/setup-x86.exe
wget $cygwin/x86_64/setup-x86_64.exe
--8<---------------cut here---------------end--------------->8---


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: [ITA] _autorebase

[Ken Brown]

On 12/14/2014 3:56 AM, Achim Gratz wrote:
>
> Packages rebuilt with cygport including the changes discussed with Ken
> and pre-compiled setup.exe files added.
>
> --8<---------------cut here---------------start------------->8---
> cygwin=http://cygwin.stromeko.net/
> wget $cygwin/noarch/release/_autorebase/_autorebase-001000-1-src.tar.xz
> wget $cygwin/noarch/release/_autorebase/_autorebase-001000-1.tar.xz
> wget $cygwin/noarch/release/_autorebase/setup.hint
> wget $cygwin/x86/setup-x86.exe
> wget $cygwin/x86_64/setup-x86_64.exe
> --8<---------------cut here---------------end--------------->8---

I just noticed a couple of things about the base address.  First, you have a 
typo in line 4 of rebaselst (missing 'd').  Second, you use a default base 
address of 0x70000000 on both arches, but rebaseall uses 0x400000000 on x86_64.

I also just noticed that rebaseall passes the --no-dynamicbase option to rebase. 
  Maybe you should do the same, and then you could forget about the --noaslr 
option and unconditionally remove the call to peflags from rebase_do.

Sorry about the constant nitpicking, but I only just thought of comparing your 
script to rebaseall.

I'm going to test this now, but I've already tested earlier versions, so I don't 
expect to find any problems.

You've done a great service by improving setup.exe and _autorebase, and I 
personally think you deserve a gold star for this work.

Ken

Re: [ITA] _autorebase

[Achim Gratz]

Ken Brown writes:
> I just noticed a couple of things about the base address.  First, you
> have a typo in line 4 of rebaselst (missing 'd').

I'll fix that before the actual release.  Unless someone defines
BaseAddress in the environment this doesn't poase a problem, though.

> Second, you use a default base address of 0x70000000 on both arches,
> but rebaseall uses 0x400000000 on x86_64.

I haven't really seen why I'd need a different base address for x86_64
and the past two years of me using that base address locally provide at
least some justification.  I don't know where the values used in
rebaseall came from, though, but I'm reasonably sure that they've been
added to rebaseall after I've switched to rebaselst.  I don't mind
changing it to the same value as rebaseall, based on the the
architecture.  If anything that makes it easier to change the values
should the need arise.

> I also just noticed that rebaseall passes the --no-dynamicbase option
> to rebase. Maybe you should do the same, and then you could forget
> about the --noaslr option and unconditionally remove the call to
> peflags from rebase_do.

I'll have to see if I can dig out my notes from that time, but I think
it was both the ASLR and the TSAware flag that were creating problems
with some libraries (they are not supposed to have that latter flag set
anyway, but a handful of them did for whatever reason).  Adding
--no-dynamicbase is a good idea in any case since the code doesn't run
the peflags unconditionally anymore.

> Sorry about the constant nitpicking, but I only just thought of
> comparing your script to rebaseall.

No, actually it's good to have someone look at the code in depth and
thank you for doing this.

> I'm going to test this now, but I've already tested earlier versions,
> so I don't expect to find any problems.

I've replaced the packages with new versions having those fixes, please
have another look.


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: [ITA] _autorebase

[Ken Brown]

On 12/14/2014 12:52 PM, Achim Gratz wrote:
> Ken Brown writes:
>> I just noticed a couple of things about the base address.  First, you
>> have a typo in line 4 of rebaselst (missing 'd').
>
> I'll fix that before the actual release.  Unless someone defines
> BaseAddress in the environment this doesn't poase a problem, though.
>
>> Second, you use a default base address of 0x70000000 on both arches,
>> but rebaseall uses 0x400000000 on x86_64.
>
> I haven't really seen why I'd need a different base address for x86_64
> and the past two years of me using that base address locally provide at
> least some justification.  I don't know where the values used in
> rebaseall came from, though, but I'm reasonably sure that they've been
> added to rebaseall after I've switched to rebaselst.  I don't mind
> changing it to the same value as rebaseall, based on the the
> architecture.  If anything that makes it easier to change the values
> should the need arise.
>
>> I also just noticed that rebaseall passes the --no-dynamicbase option
>> to rebase. Maybe you should do the same, and then you could forget
>> about the --noaslr option and unconditionally remove the call to
>> peflags from rebase_do.
>
> I'll have to see if I can dig out my notes from that time, but I think
> it was both the ASLR and the TSAware flag that were creating problems
> with some libraries (they are not supposed to have that latter flag set
> anyway, but a handful of them did for whatever reason).  Adding
> --no-dynamicbase is a good idea in any case since the code doesn't run
> the peflags unconditionally anymore.
>
>> Sorry about the constant nitpicking, but I only just thought of
>> comparing your script to rebaseall.
>
> No, actually it's good to have someone look at the code in depth and
> thank you for doing this.
>
>> I'm going to test this now, but I've already tested earlier versions,
>> so I don't expect to find any problems.
>
> I've replaced the packages with new versions having those fixes, please
> have another look.

The changes look good, and it works fine on an existing installation.  But 
there's a problem with a new installation.  The autorebase postinstall script 
seems to hang in one of the calls to "find", which I finally killed through the 
Task Manager.  /var/log/setup.log.full is full of error messages like

find: 
'./proc/registry/HKEY_CLASSES_ROOT/VirtualStore/MACHINE/SOFTWARE/Wow6432Node/Microsoft/DirectDraw/MostRecentApplication': 
Permission denied
./proc/registry/HKEY_CLASSES_ROOT/.dll: skipped because not rebaseable
./proc/registry/HKEY_CLASSES_ROOT/AppID/LocationApi.dll: skipped because not 
rebaseable
./proc/registry/HKEY_CLASSES_ROOT/AppID/MhegVM.dll: skipped because not rebaseable
./proc/registry/HKEY_CLASSES_ROOT/AppID/TOSHIBAMediaControllerIE.dll: skipped 
because not rebaseable
[...]

I don't have time to look at this more carefully today, but I wonder if the 
problem is that 000-cygwin-post-install.sh needs to run first in a new
installation.

Ken

Re: [ITA] _autorebase

[Achim Gratz]

Ken Brown writes:
> The changes look good, and it works fine on an existing installation.
> But there's a problem with a new installation.  The autorebase
> postinstall script seems to hang in one of the calls to "find", which
> I finally killed through the Task Manager.  /var/log/setup.log.full is
> full of error messages like

Great find, I've had that happen once before, but couldn't debug it at
the time.  But it's clear now: I forgot to check if find has a path
argument to chew on.  Otherwise it implicitly uses ./ and since it gets
started in / it descends into /proc/registry.  I've now both test for
the empty path and added "-xdev" to the options so find won't try to
cross the filesystem boundaries.

Packages fixed and replaced.


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: [ITA] _autorebase

[Ken Brown]

On 12/14/2014 3:48 PM, Achim Gratz wrote:
> Ken Brown writes:
>> The changes look good, and it works fine on an existing installation.
>> But there's a problem with a new installation.  The autorebase
>> postinstall script seems to hang in one of the calls to "find", which
>> I finally killed through the Task Manager.  /var/log/setup.log.full is
>> full of error messages like
>
> Great find, I've had that happen once before, but couldn't debug it at
> the time.  But it's clear now: I forgot to check if find has a path
> argument to chew on.  Otherwise it implicitly uses ./ and since it gets
> started in / it descends into /proc/registry.  I've now both test for
> the empty path and added "-xdev" to the options so find won't try to
> cross the filesystem boundaries.
>
> Packages fixed and replaced.

That fixed it.

Ken

Re: [ITA] _autorebase

[Corinna Vinschen]

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

On Dec 13 23:06, Achim Gratz wrote:
> Ken Brown writes:
> > 1. Shouldn't you have removed the following line from rebase_do?
> >
> >     peflags ${verbose} -d0 -t0 -T "${g}"
> 
> That isn't redundant and has nothing to do with the stuff in peflags_do,
> although I don't remember exactly what the problem was that was resolved
> by this.  The current toolchain should be clean, though, so it may best
> be an optional step.

This looks wrong.  -d0 is ok on 32 bit due to the tight memory layout,
but -t0 is very certainly wrong.  You *want* Cygwin executables to be
TS aware, so, if at all, -t1 would be required.

<history lesson>

Way back when none of the Cygwin binaries were TS aware (before we
defaulted to it in GCC), we had mysterious crashes when trying to run
bash from terminal server session on "real" terminal servers (in
contrast to remote desktop sessions on XP++ and non-TS servers).  I even
opened a case with Microsoft at the time.

It turned out that terminal servers check the TS awareness bit, and if
it's unset, a compatibility layer DLL is hooked into the process, which
performs certain compatibility tests.  For some reason, one of the test
left some pages in the process text segment unexecutable, which then
resulted in a very quick SEGV in bash.  After the Microsofties
discovered that the problem was based on the missing TS-awareness flag
in bash, they dropped the issue as "won't fix".  The solution was "set
the TS-awareness flag".

</history lesson>


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: [ITA] _autorebase

[Corinna Vinschen]

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

On Dec 14 18:52, Achim Gratz wrote:
> Ken Brown writes:
> > I just noticed a couple of things about the base address.  First, you
> > have a typo in line 4 of rebaselst (missing 'd').
> 
> I'll fix that before the actual release.  Unless someone defines
> BaseAddress in the environment this doesn't poase a problem, though.
> 
> > Second, you use a default base address of 0x70000000 on both arches,
> > but rebaseall uses 0x400000000 on x86_64.
> 
> I haven't really seen why I'd need a different base address for x86_64
> and the past two years of me using that base address locally provide at
> least some justification.  I don't know where the values used in
> rebaseall came from, though, but I'm reasonably sure that they've been
> added to rebaseall after I've switched to rebaselst.  I don't mind
> changing it to the same value as rebaseall, based on the the
> architecture.  If anything that makes it easier to change the values
> should the need arise.

The change is required.  The base address 0x4:00000000 is a convention
which has been introduced to get reliable memory layout on x86_64.  All
of Cygwin's memory allocations, be it thread stack, executable and DLL
base addresses, heap address, or mmap's with NULL addresses, are chosen
so as not to collide with memory allocations chosen by the OS.  The OS
utilizes the lower 2GB 32 bit address space and the upper 0xff0:00000000
address space pretty much exclusively, and leaves everything in between
for the application.  Thus we developed the following convention, which
should be followed by every tool in the distro:

  0x000:00000000 - 0x000:7fffffff    Reserved for OS
  0x000:80000000 - 0x000:ffffffff    POSIX threads
  0x001:00000000 - 0x001:7fffffff    Process image
  0x001:80000000 - 0x001:ffffffff    Cygwin DLL w/ all shared data
  0x002:00000000 - 0x003:ffffffff    8 Gigs for rebased DLLs
  0x004:00000000 - 0x005:ffffffff    8 Gigs for non-rebased DLLs
  0x006:00000000 - 0x6ff:ffffffff    Heap bottom-up, mmaps top-down
  0x700:00000000 - 0x7ff:ffffffff    Reserved for OS

This was discussed and documented multiple times during the development
of the 64 bit version.  Please let's stick to that.

> > I also just noticed that rebaseall passes the --no-dynamicbase option
> > to rebase. Maybe you should do the same, and then you could forget
> > about the --noaslr option and unconditionally remove the call to
> > peflags from rebase_do.
> 
> I'll have to see if I can dig out my notes from that time, but I think
> it was both the ASLR and the TSAware flag that were creating problems
> with some libraries

TS aware?  To the contrary.  Don't remove it!


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: [ITA] _autorebase

[Achim Gratz]

Corinna Vinschen writes:
> On Dec 13 23:06, Achim Gratz wrote:
>> Ken Brown writes:
>> > 1. Shouldn't you have removed the following line from rebase_do?
>> >
>> >     peflags ${verbose} -d0 -t0 -T "${g}"
>> 
>> That isn't redundant and has nothing to do with the stuff in peflags_do,
>> although I don't remember exactly what the problem was that was resolved
>> by this.  The current toolchain should be clean, though, so it may best
>> be an optional step.
>
> This looks wrong.  -d0 is ok on 32 bit due to the tight memory layout,
> but -t0 is very certainly wrong.  You *want* Cygwin executables to be
> TS aware, so, if at all, -t1 would be required.

This is only used for dynamic objects and the TSAware flag is bogus on
those, according to your statement here:

https://www.cygwin.com/ml/cygwin/2012-04/msg00608.html

> <history lesson>
>
> Way back when none of the Cygwin binaries were TS aware (before we
> defaulted to it in GCC), we had mysterious crashes when trying to run
> bash from terminal server session on "real" terminal servers (in
> contrast to remote desktop sessions on XP++ and non-TS servers).  I even
> opened a case with Microsoft at the time.
>
> It turned out that terminal servers check the TS awareness bit, and if
> it's unset, a compatibility layer DLL is hooked into the process, which
> performs certain compatibility tests.  For some reason, one of the test
> left some pages in the process text segment unexecutable, which then
> resulted in a very quick SEGV in bash.  After the Microsofties
> discovered that the problem was based on the missing TS-awareness flag
> in bash, they dropped the issue as "won't fix".  The solution was "set
> the TS-awareness flag".
>
> </history lesson>

Further up in that same thread.  :-)


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: [ITA] _autorebase

[Achim Gratz]

Corinna Vinschen writes:
> The change is required.  The base address 0x4:00000000 is a convention
> which has been introduced to get reliable memory layout on x86_64.  All
> of Cygwin's memory allocations, be it thread stack, executable and DLL
> base addresses, heap address, or mmap's with NULL addresses, are chosen
> so as not to collide with memory allocations chosen by the OS.  The OS
> utilizes the lower 2GB 32 bit address space and the upper 0xff0:00000000
> address space pretty much exclusively, and leaves everything in between
> for the application.  Thus we developed the following convention, which
> should be followed by every tool in the distro:
>
>   0x000:00000000 - 0x000:7fffffff    Reserved for OS
>   0x000:80000000 - 0x000:ffffffff    POSIX threads
>   0x001:00000000 - 0x001:7fffffff    Process image
>   0x001:80000000 - 0x001:ffffffff    Cygwin DLL w/ all shared data
>   0x002:00000000 - 0x003:ffffffff    8 Gigs for rebased DLLs
>   0x004:00000000 - 0x005:ffffffff    8 Gigs for non-rebased DLLs
>   0x006:00000000 - 0x6ff:ffffffff    Heap bottom-up, mmaps top-down
>   0x700:00000000 - 0x7ff:ffffffff    Reserved for OS
>
> This was discussed and documented multiple times during the development
> of the 64 bit version.  Please let's stick to that.

I've missed it at the time or didn't remember any of it.  In any case
it's implemented exactly like that in rebaselst anyway.

>> I'll have to see if I can dig out my notes from that time, but I think
>> it was both the ASLR and the TSAware flag that were creating problems
>> with some libraries
>
> TS aware?  To the contrary.  Don't remove it!

We're not talking about executables here, see my other reply.


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: [ITA] _autorebase

[Corinna Vinschen]

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

On Dec 15 18:20, Achim Gratz wrote:
> Corinna Vinschen writes:
> > The change is required.  The base address 0x4:00000000 is a convention
> > which has been introduced to get reliable memory layout on x86_64.  All
> > of Cygwin's memory allocations, be it thread stack, executable and DLL
> > base addresses, heap address, or mmap's with NULL addresses, are chosen
> > so as not to collide with memory allocations chosen by the OS.  The OS
> > utilizes the lower 2GB 32 bit address space and the upper 0xff0:00000000
> > address space pretty much exclusively, and leaves everything in between
> > for the application.  Thus we developed the following convention, which
> > should be followed by every tool in the distro:
> >
> >   0x000:00000000 - 0x000:7fffffff    Reserved for OS
> >   0x000:80000000 - 0x000:ffffffff    POSIX threads
> >   0x001:00000000 - 0x001:7fffffff    Process image
> >   0x001:80000000 - 0x001:ffffffff    Cygwin DLL w/ all shared data
> >   0x002:00000000 - 0x003:ffffffff    8 Gigs for rebased DLLs
> >   0x004:00000000 - 0x005:ffffffff    8 Gigs for non-rebased DLLs
> >   0x006:00000000 - 0x6ff:ffffffff    Heap bottom-up, mmaps top-down
> >   0x700:00000000 - 0x7ff:ffffffff    Reserved for OS
> >
> > This was discussed and documented multiple times during the development
> > of the 64 bit version.  Please let's stick to that.
> 
> I've missed it at the time or didn't remember any of it.  In any case
> it's implemented exactly like that in rebaselst anyway.
> 
> >> I'll have to see if I can dig out my notes from that time, but I think
> >> it was both the ASLR and the TSAware flag that were creating problems
> >> with some libraries
> >
> > TS aware?  To the contrary.  Don't remove it!
> 
> We're not talking about executables here, see my other reply.

Sorry, missed that.


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: [ITA] _autorebase

[Corinna Vinschen]

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

On Dec 13 16:56, Achim Gratz wrote:
> 
> --8<---------------cut here---------------start------------->8---
> wget="wget -rxnH http://cygwin.stromeko.net/noarch/release"
> $wget/_autorebase-001000-1-src.tar.xz
> $wget/_autorebase-001000-1.tar.xz
> $wget/setup.hint
> --8<---------------cut here---------------end--------------->8---
> 
> 
> Requirements before deployment:
> 
> - all autodep stuff referring to _autorebase must be removed
> - setup.exe version 2.858 or later must be used

I just uploaded setup 2.859.

> Notes:
> 
> There will be no ITP for _incautorebase since Corinna wanted a
> replacement for _autorebase instead.
> 
> Dependencies on _autorebase should not be used, but are harmless.  This
> is a Base package and it will always be run in postinstall.
> 
> This release comes with an additional script rebase-trigger that can be
> used to have the postinstall script run a full rebase or peflags the
> next time setup.exe is run (with or without an update or additional
> installations or removals).  Once this is in place the description of
> how to do a manual full rebase should refer to this method instead since
> I expect it to be much easier to follow.
> 
> Packages that need to tap into the autorebase infrastructure for dynamic
> objects should drop a file /etc/rebase/dynpath.d/<package> that has the
> path to be searched for dynamic objects as its content.  Currently these
> files are delivered with _autorebase, but when packages get updated they
> should take over that responsibility.  Please announce such changes so
> that the corresponding file can be removed from the _autorebase package
> before the new package version gets deployed.

What would be most helpful is to get a piece of documentation for us
maintainers how to use the new _autorebase facility, sent with a fat
HEADSUP subject, and which we can ideally add to setup.html.


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: [HEADSUP Maintainers] _autorebase

[Achim Gratz]

> What would be most helpful is to get a piece of documentation for us
> maintainers how to use the new _autorebase facility, sent with a fat
> HEADSUP subject, and which we can ideally add to setup.html.

The _autorebase package is designed to require no intervention from a
package maintainer in most cases.  The core of the work is done by the
rebaselst script.  It works mostly like the rebaseall script, but tries
to rebase only files that have been changed since the last time
autorebase was run.  The remainder of the package ensures that
autorebase is run each time the user runs setup.  Ad additional script
rebase-trigger allows the user to request a full rebase of the
installation on the next execution of setup.  Both scripts are
self-documenting when invoked with an option of -h or --help.

Note 1: It's possible to run rebaselst manually if you know what you're
doing.  At the moment I don't want to advertise or support that,
however.


There are two exceptions that require maintainer attention:

1. Your application uses dynamic objects that have a suffix not matched
by "dll|so|oct|mex".  There currently aren't any such applications, but
if you plan to introduce one, please discuss on cygwin-apps first.

2. Your application allows users to install dynamic objects into
site-specific directories.  Since autorebase relies on the information
in /etc/setup, it would miss to rebase these objects since they aren't
part of any package.  If you maintain such an application, please add a
file /etc/rebase/dynpath.d/<package> that contains one absolute
directory path per line that autorebase should search for dynamic
objects to rebase.  Do not include those directories that packages are
using and keep them separate from those that site installations are
going to.

As an example, Perl packages modules into /usr/lib/perl5/perl_vendor,
while site modules will go into /usr/lib/perl5/site_perl.  Only the
latter will need to be maintained via /etc/rebase/dynpath.d/perl, which
would have a single line containing the path /usr/lib/perl5/site_perl.

Currently autorebase delivers these files in /etc/rebase/dynpath.d:

octave
perl
php
python26
python27
R
ruby

If your package is going to provide one of these files in a later
release, please coordinate via cygwin-apps that it gets removed from
_autorebase together with that release.

Note 2: It would still be time to orchestrate package updates so that
the initial release of _autorebase did not include those files.
Especially for Perl that might mean we'd have to patch the package
archive, however.


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: [ITA] _autorebase

[Ken Brown]

On 12/16/2014 8:23 AM, Corinna Vinschen wrote:
> What would be most helpful is to get a piece of documentation for us
> maintainers how to use the new _autorebase facility, sent with a fat
> HEADSUP subject, and which we can ideally add to setup.html.

More importantly, maintainers need to be told about the new kinds of postinstall 
scripts now supported by setup.exe.  (Or maybe that's what you meant.)

Ken

Re: [HEADSUP Maintainers] _autorebase

[Corinna Vinschen]

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

On Dec 16 17:24, Achim Gratz wrote:
> > What would be most helpful is to get a piece of documentation for us
> > maintainers how to use the new _autorebase facility, sent with a fat
> > HEADSUP subject, and which we can ideally add to setup.html.
> 
> The _autorebase package is designed to require no intervention from a
> package maintainer in most cases.  The core of the work is done by the
> rebaselst script.  It works mostly like the rebaseall script, but tries
> to rebase only files that have been changed since the last time
> autorebase was run.  The remainder of the package ensures that
> autorebase is run each time the user runs setup.  Ad additional script
> rebase-trigger allows the user to request a full rebase of the
> installation on the next execution of setup.  Both scripts are
> self-documenting when invoked with an option of -h or --help.
> 
> Note 1: It's possible to run rebaselst manually if you know what you're
> doing.  At the moment I don't want to advertise or support that,
> however.
> 
> 
> There are two exceptions that require maintainer attention:
> 
> 1. Your application uses dynamic objects that have a suffix not matched
> by "dll|so|oct|mex".  There currently aren't any such applications, but
> if you plan to introduce one, please discuss on cygwin-apps first.
> 
> 2. Your application allows users to install dynamic objects into
> site-specific directories.  Since autorebase relies on the information
> in /etc/setup, it would miss to rebase these objects since they aren't
> part of any package.  If you maintain such an application, please add a
> file /etc/rebase/dynpath.d/<package> that contains one absolute
> directory path per line that autorebase should search for dynamic
> objects to rebase.  Do not include those directories that packages are
> using and keep them separate from those that site installations are
> going to.
> 
> As an example, Perl packages modules into /usr/lib/perl5/perl_vendor,
> while site modules will go into /usr/lib/perl5/site_perl.  Only the
> latter will need to be maintained via /etc/rebase/dynpath.d/perl, which
> would have a single line containing the path /usr/lib/perl5/site_perl.
> 
> Currently autorebase delivers these files in /etc/rebase/dynpath.d:
> 
> octave
> perl
> php
> python26
> python27
> R
> ruby
> 
> If your package is going to provide one of these files in a later
> release, please coordinate via cygwin-apps that it gets removed from
> _autorebase together with that release.
> 
> Note 2: It would still be time to orchestrate package updates so that
> the initial release of _autorebase did not include those files.
> Especially for Perl that might mean we'd have to patch the package
> archive, however.

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: [ITA] _autorebase

[Corinna Vinschen]

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

On Dec 16 16:11, Ken Brown wrote:
> On 12/16/2014 8:23 AM, Corinna Vinschen wrote:
> >What would be most helpful is to get a piece of documentation for us
> >maintainers how to use the new _autorebase facility, sent with a fat
> >HEADSUP subject, and which we can ideally add to setup.html.
> 
> More importantly, maintainers need to be told about the new kinds of
> postinstall scripts now supported by setup.exe.  (Or maybe that's what you
> meant.)

I actually only meant the new autorebase stuff, but you're oh so right
about the requirement to document how the new postinstall stuff works.
Achim, uhm... sorry abouyt that, but I guess we really have to improve
https://cygwin.com/setup.html on that so all maintainers can educate
themselves how to use the new feature.

Fortunately the web pages are in CVS as well:

  cvs -d :ext:sourceware.org:/cvs/cygwin co htdocs


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: [ITA] _autorebase

[Corinna Vinschen]

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

On Dec 17 10:39, Corinna Vinschen wrote:
> On Dec 16 16:11, Ken Brown wrote:
> > On 12/16/2014 8:23 AM, Corinna Vinschen wrote:
> > >What would be most helpful is to get a piece of documentation for us
> > >maintainers how to use the new _autorebase facility, sent with a fat
> > >HEADSUP subject, and which we can ideally add to setup.html.
> > 
> > More importantly, maintainers need to be told about the new kinds of
> > postinstall scripts now supported by setup.exe.  (Or maybe that's what you
> > meant.)
> 
> I actually only meant the new autorebase stuff, but you're oh so right
> about the requirement to document how the new postinstall stuff works.
> Achim, uhm... sorry abouyt that, but I guess we really have to improve
> https://cygwin.com/setup.html on that so all maintainers can educate
> themselves how to use the new feature.
> 
> Fortunately the web pages are in CVS as well:
> 
>   cvs -d :ext:sourceware.org:/cvs/cygwin co htdocs

Oh, and there's something else very important.  The new technique
requires the users to update setup.exe, otherwise they will get
problems.  We can't do much for people ignoring the "this setup.ini has
been created by a newer setup version" message in setup itself, but we
should at least announce the new setup version.

Achim, either you just write the complete announcement for setup from
scratch, or you give me a piece of text to include into the announcement
and I write it.  Whatever you prefer.  The important thing here is to
urge people to upgrade.

Given that many of us are not available the next 2 or 3 weeks (e.g., me),
I'm wondering if we should let the new setup version sink in during that
time, and upgrade the packages using the new feature (_autorebase, TeX
Live) only in the new year, after the 6th of January when all of us will
be back.


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: [ITA] _autorebase

[Ken Brown]

On 12/17/2014 4:52 AM, Corinna Vinschen wrote:
> On Dec 17 10:39, Corinna Vinschen wrote:
>> On Dec 16 16:11, Ken Brown wrote:
>>> On 12/16/2014 8:23 AM, Corinna Vinschen wrote:
>>>> What would be most helpful is to get a piece of documentation for us
>>>> maintainers how to use the new _autorebase facility, sent with a fat
>>>> HEADSUP subject, and which we can ideally add to setup.html.
>>>
>>> More importantly, maintainers need to be told about the new kinds of
>>> postinstall scripts now supported by setup.exe.  (Or maybe that's what you
>>> meant.)
>>
>> I actually only meant the new autorebase stuff, but you're oh so right
>> about the requirement to document how the new postinstall stuff works.
>> Achim, uhm... sorry abouyt that, but I guess we really have to improve
>> https://cygwin.com/setup.html on that so all maintainers can educate
>> themselves how to use the new feature.
>>
>> Fortunately the web pages are in CVS as well:
>>
>>    cvs -d :ext:sourceware.org:/cvs/cygwin co htdocs
>
> Oh, and there's something else very important.  The new technique
> requires the users to update setup.exe, otherwise they will get
> problems.  We can't do much for people ignoring the "this setup.ini has
> been created by a newer setup version" message in setup itself, but we
> should at least announce the new setup version.
>
> Achim, either you just write the complete announcement for setup from
> scratch, or you give me a piece of text to include into the announcement
> and I write it.  Whatever you prefer.  The important thing here is to
> urge people to upgrade.
>
> Given that many of us are not available the next 2 or 3 weeks (e.g., me),
> I'm wondering if we should let the new setup version sink in during that
> time, and upgrade the packages using the new feature (_autorebase, TeX
> Live) only in the new year, after the 6th of January when all of us will
> be back.

Good idea.  I'll probably wait even longer than that with TeX Live, to give 
people plenty of time to get the new _autorebase working first.

Ken

Re: [ITA] _autorebase

[Achim Gratz]

Corinna Vinschen writes:
> Oh, and there's something else very important.  The new technique
> requires the users to update setup.exe, otherwise they will get
> problems.  We can't do much for people ignoring the "this setup.ini has
> been created by a newer setup version" message in setup itself, but we
> should at least announce the new setup version.
>
> Achim, either you just write the complete announcement for setup from
> scratch, or you give me a piece of text to include into the announcement
> and I write it.  Whatever you prefer.  The important thing here is to
> urge people to upgrade.

I'll look into that

> Given that many of us are not available the next 2 or 3 weeks (e.g., me),
> I'm wondering if we should let the new setup version sink in during that
> time, and upgrade the packages using the new feature (_autorebase, TeX
> Live) only in the new year, after the 6th of January when all of us will
> be back.

Good idea.

In fact if we do that, I'd like to require either new releases for the
packages using /etc/rebase/dynpath.d or alternatively that they get an
additional package that drops just this file (if a full release _now_
would be too much work) and the requisite change to setup.hint to have a
dependency added so that this new package gets pulled in.


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: [ITA] _autorebase

[Corinna Vinschen]

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

On Dec 17 18:01, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Oh, and there's something else very important.  The new technique
> > requires the users to update setup.exe, otherwise they will get
> > problems.  We can't do much for people ignoring the "this setup.ini has
> > been created by a newer setup version" message in setup itself, but we
> > should at least announce the new setup version.
> >
> > Achim, either you just write the complete announcement for setup from
> > scratch, or you give me a piece of text to include into the announcement
> > and I write it.  Whatever you prefer.  The important thing here is to
> > urge people to upgrade.
> 
> I'll look into that
> 
> > Given that many of us are not available the next 2 or 3 weeks (e.g., me),
> > I'm wondering if we should let the new setup version sink in during that
> > time, and upgrade the packages using the new feature (_autorebase, TeX
> > Live) only in the new year, after the 6th of January when all of us will
> > be back.
> 
> Good idea.
> 
> In fact if we do that, I'd like to require either new releases for the
> packages using /etc/rebase/dynpath.d or alternatively that they get an
> additional package that drops just this file (if a full release _now_
> would be too much work) and the requisite change to setup.hint to have a
> dependency added so that this new package gets pulled in.

That should be fine, given the rather short list of affected maintainers:

  octave   Marco Atzeri
  perl     Reini Urban/Achim Gratz ?!?
  php      Yaakov Selkowitz
  python   Jason Tishler/Yaakov Selkowitz
  R        Marco Atzeri
  ruby     Yaakov Selkowitz

As for perl, are you still with us Reini?  As for python, Jason, you're
still around?


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: [ITA] _autorebase

[Achim Gratz]

Corinna Vinschen writes:
> That should be fine, given the rather short list of affected maintainers:
>
>   octave   Marco Atzeri
>   perl     Reini Urban/Achim Gratz ?!?
>   php      Yaakov Selkowitz
>   python   Jason Tishler/Yaakov Selkowitz
>   R        Marco Atzeri
>   ruby     Yaakov Selkowitz
>
> As for perl, are you still with us Reini?  As for python, Jason, you're
> still around?

If Reini is still waiting for his machines to arrive or if some of the
old packages need work, I can do the packaging.  I'd just need help with
the upload, I guess.


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: [HEADSUP Maintainers] setup.exe new postinstall facitilities

[Achim Gratz]

Ken Brown writes:
> More importantly, maintainers need to be told about the new kinds of
> postinstall scripts now supported by setup.exe.  (Or maybe that's what
> you meant.)

Here's my original proposal again for reference:

--8<---------------cut here---------------start------------->8---
1. I'd like to move from suffix to prefix so that the scripts will list
in approximately the order they are run.

2. I'd like to prepare for perpetual scripts, triggered scripts and
general stratified postinstallation.

3. The implementation will at first only provide pre-postinstall and
post-postinstall, both perpetual.  Proper implementation of the things
prepared for with 2. can then follow later.

Here's how I think the prefixes should look like:

naming convention: <stratum><type>(-<trigger>)?_<script name>.<suffix>
stratum := [0-9a-z]
type := [pqrt]
trigger := [a-z]+

Non-prefixed scripts will be run someplace in the middle of things
(probably at _i_nstall).  The type encodes _p_erpetual, _q_uery,
_r_unonce and _t_triggered and on each stratum the scripts get run in
that order.  Trigger names are allowed, but not acted upon for perpetual
and runonce scripts, so you can use these as a namespace for postinstall
scripts that should belong together.  A query script causes all
triggered script in run sequence after it and with the same trigger to
be run when it returns true.
--8<---------------cut here---------------end--------------->8---

At the moment the only thing that has been implemented is the 0p and zp
prefix (i.e. stratum 0 and z and type p) without queries and triggers.
These allow a package to specify a postinstall action that gets executed
_each time_ setup is run as long as the package is still installed
(perpetual postinstall scripts).  Depending on the stratum, these
postinstall scripts get run either before (stratum 0) or after (stratum
z) the conventional, run-once scripts.

Not directly related to this change is the ability to use dash instead
of bash for scripting when the script uses a ".dash" suffix (you need to
"export PATH=/bin" in those scripts).  Also, CMD command files can now
have a ".cmd" suffix in addition to plain old ".bat".


As a consequence, if your package only needs run-once scripts for
postinstall actions, then you don't need to know about the perpetual
scripts, except that you must not use any script name that matches the
regex "^[0-9a-z][pqrt]_".


For those package maintainers wanting to employ perpetual scripts, the
first thing to keep in mind is to only use this feature for things that
really can't be done with run-once scripting, so this will likely
require an extensive re-write of the current postinstall logic.  Any
perpetual script should minimize the resources used (use dash instead of
bash for instance) and exit at the earliest possible moment if no action
is required.  Scripts on stratum 0 at the moment must be able to run
with the Base packages just installed, but the postinstall scripts not
yet executed (in practical terms that rules out using bash scripts).
This limitation does not apply to stratum z scripts obviously.

In all but the most simple cases the perpetual script will check for
some condition created by a package install or de-install and then
decide what actions to take.  Since triggers have not yet been
implemented, coordination among packages using the same perpetual script
will have to use "marker" files.  These markers can be files created
during install (like /etc/setup/<package>.lst.gz) or files that are
dropped by the package.  Do not be tempted to drop the same file from
multiple packages, since deinstallation of one of those packages will
break all the other packages.  Keep in mind that the time-stamp on a
file installed by a package has no relation to the install time.


As a practical example, consider a package with three optional
sub-packages.  Depending on which of those sub-packages are present, a
configuration needs to be created.  Let's assume that the configuration
process takes a lot of time, so running it three times during
postinstall isn't a good idea.  Besides, if the user removes a
sub-package later without installing another one, then your
configuration would become stale.  You could instead use a stratum z
postinstall script that does the following things:

1. Check for presence of /etc/setup/<package>-option[123].lst.gz to
figure out which sub-packages are present.

2. Check if a configuration has been created before (via another file,
for instance) and whether the set of sub-packages was the same.

3. Exit if the configuration hasn't changed, otherwise record the new
set of sub-packages that are installed and start the configuration
process.

This way, the configuration is kept up-to-date with the installed
packages with the minimum number of configuration runs.


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: [HEADSUP Maintainers] setup.exe new postinstall facitilities

[Andrew Schulman]

> --8<---------------cut here---------------start------------->8---

I love the little ASCII art scissors.

Re: [ITA] _autorebase

[Corinna Vinschen]

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

Reini?  Jason?


Three weeks without reply is a long time... :}

Any input?


On Dec 17 19:05, Achim Gratz wrote:
> Corinna Vinschen writes:
> > That should be fine, given the rather short list of affected maintainers:
> >
> >   octave   Marco Atzeri
> >   perl     Reini Urban/Achim Gratz ?!?
> >   php      Yaakov Selkowitz
> >   python   Jason Tishler/Yaakov Selkowitz
> >   R        Marco Atzeri
> >   ruby     Yaakov Selkowitz
> >
> > As for perl, are you still with us Reini?  As for python, Jason, you're
> > still around?
> 
> If Reini is still waiting for his machines to arrive or if some of the
> old packages need work, I can do the packaging.  I'd just need help with
> the upload, I guess.
> 
> 
> Regards,
> Achim.


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: [ITA] _autorebase

[Jason Tishler]

Corinna,

On Wed, Jan 07, 2015 at 05:09:50PM +0100, Corinna Vinschen wrote:
> Reini?  Jason?
> 
> Three weeks without reply is a long time... :}
> 
> Any input?
> 
> On Dec 17 19:05, Achim Gratz wrote:
> > Corinna Vinschen writes:
> > > That should be fine, given the rather short list of affected
> > > maintainers:
> > >
> > >   octave   Marco Atzeri
> > >   perl     Reini Urban/Achim Gratz ?!?
> > >   php      Yaakov Selkowitz
> > >   python   Jason Tishler/Yaakov Selkowitz
> > >   R        Marco Atzeri
> > >   ruby     Yaakov Selkowitz
> > >
> > > As for perl, are you still with us Reini?  As for python, Jason,
> > > you're still around?
> > 
> > If Reini is still waiting for his machines to arrive or if some of
> > the old packages need work, I can do the packaging.  I'd just need
> > help with the upload, I guess.

Sorry, but I missed this post until you CC-ed me yesterday. I just read
the thread again. Are you asking about the following?

> In fact if we do that, I'd like to require either new releases for the
> packages using /etc/rebase/dynpath.d or alternatively that they get an
> additional package that drops just this file (if a full release _now_
> would be too much work) and the requisite change to setup.hint to have
> a dependency added so that this new package gets pulled in.

Thanks,
Jason

Re: [ITA] _autorebase

[Corinna Vinschen]

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

Hi Jason,

I'm glad to read from you!

On Jan  8 21:32, Jason Tishler wrote:
> Corinna,
> 
> On Wed, Jan 07, 2015 at 05:09:50PM +0100, Corinna Vinschen wrote:
> > Reini?  Jason?
> > 
> > Three weeks without reply is a long time... :}
> > 
> > Any input?
> > 
> > On Dec 17 19:05, Achim Gratz wrote:
> > > Corinna Vinschen writes:
> > > > That should be fine, given the rather short list of affected
> > > > maintainers:
> > > >
> > > >   octave   Marco Atzeri
> > > >   perl     Reini Urban/Achim Gratz ?!?
> > > >   php      Yaakov Selkowitz
> > > >   python   Jason Tishler/Yaakov Selkowitz
> > > >   R        Marco Atzeri
> > > >   ruby     Yaakov Selkowitz
> > > >
> > > > As for perl, are you still with us Reini?  As for python, Jason,
> > > > you're still around?
> > > 
> > > If Reini is still waiting for his machines to arrive or if some of
> > > the old packages need work, I can do the packaging.  I'd just need
> > > help with the upload, I guess.
> 
> Sorry, but I missed this post until you CC-ed me yesterday. I just read
> the thread again. Are you asking about the following?
> 
> > In fact if we do that, I'd like to require either new releases for the
> > packages using /etc/rebase/dynpath.d or alternatively that they get an
> > additional package that drops just this file (if a full release _now_
> > would be too much work) and the requisite change to setup.hint to have
> > a dependency added so that this new package gets pulled in.

Basically, yes.  It's a simple packaging thing AFAIU.  The files are
available in Achim's preliminiary _autorebase package.  It would be
nice if you and the other maintainers could discuss this with Achim.


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: [ITA] _autorebase

[Corinna Vinschen]

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

On Jan  7 17:09, Corinna Vinschen wrote:
> Reini?  Jason?
> 
> 
> Three weeks without reply is a long time... :}
> 
> Any input?
> 
> 
> On Dec 17 19:05, Achim Gratz wrote:
> > Corinna Vinschen writes:
> > > That should be fine, given the rather short list of affected maintainers:
> > >
> > >   octave   Marco Atzeri
> > >   perl     Reini Urban/Achim Gratz ?!?
> > >   php      Yaakov Selkowitz
> > >   python   Jason Tishler/Yaakov Selkowitz
> > >   R        Marco Atzeri
> > >   ruby     Yaakov Selkowitz
> > >
> > > As for perl, are you still with us Reini?  As for python, Jason, you're
> > > still around?
> > 
> > If Reini is still waiting for his machines to arrive or if some of the
> > old packages need work, I can do the packaging.  I'd just need help with
> > the upload, I guess.

Reini appears to have gone AWOL.  That's really a pity but not much we
can do about it.  Achim, care to take over?

Marco, Yaakov, Jason, could we please go forward?  It's just a very simple
package tweak, it seems.

I would love to have Achim's new autorebase stuff in place really soon now.


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: [ITA] _autorebase

[Marco Atzeri]

On 1/14/2015 10:40 AM, Corinna Vinschen wrote:
> On Jan  7 17:09, Corinna Vinschen wrote:
>> Reini?  Jason?
>>
>>
>> Three weeks without reply is a long time... :}
>>
>> Any input?
>>
>>
>> On Dec 17 19:05, Achim Gratz wrote:
>>> Corinna Vinschen writes:
>>>> That should be fine, given the rather short list of affected maintainers:
>>>>
>>>>    octave   Marco Atzeri
>>>>    perl     Reini Urban/Achim Gratz ?!?
>>>>    php      Yaakov Selkowitz
>>>>    python   Jason Tishler/Yaakov Selkowitz
>>>>    R        Marco Atzeri
>>>>    ruby     Yaakov Selkowitz
>>>>
>>>> As for perl, are you still with us Reini?  As for python, Jason, you're
>>>> still around?
>>>
>>> If Reini is still waiting for his machines to arrive or if some of the
>>> old packages need work, I can do the packaging.  I'd just need help with
>>> the upload, I guess.
>
> Reini appears to have gone AWOL.  That's really a pity but not much we
> can do about it.  Achim, care to take over?
>
> Marco, Yaakov, Jason, could we please go forward?  It's just a very simple
> package tweak, it seems.

No problem to any repackage, but I have not really understood
what is required for Octave and R.


> I would love to have Achim's new autorebase stuff in place really soon now.
>
>
> Thanks,
> Corinna
>

Re: [ITA] _autorebase

[Corinna Vinschen]

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

On Jan 14 10:50, Marco Atzeri wrote:
> On 1/14/2015 10:40 AM, Corinna Vinschen wrote:
> >On Jan  7 17:09, Corinna Vinschen wrote:
> >>Reini?  Jason?
> >>
> >>
> >>Three weeks without reply is a long time... :}
> >>
> >>Any input?
> >>
> >>
> >>On Dec 17 19:05, Achim Gratz wrote:
> >>>Corinna Vinschen writes:
> >>>>That should be fine, given the rather short list of affected maintainers:
> >>>>
> >>>>   octave   Marco Atzeri
> >>>>   perl     Reini Urban/Achim Gratz ?!?
> >>>>   php      Yaakov Selkowitz
> >>>>   python   Jason Tishler/Yaakov Selkowitz
> >>>>   R        Marco Atzeri
> >>>>   ruby     Yaakov Selkowitz
> >>>>
> >>>>As for perl, are you still with us Reini?  As for python, Jason, you're
> >>>>still around?
> >>>
> >>>If Reini is still waiting for his machines to arrive or if some of the
> >>>old packages need work, I can do the packaging.  I'd just need help with
> >>>the upload, I guess.
> >
> >Reini appears to have gone AWOL.  That's really a pity but not much we
> >can do about it.  Achim, care to take over?
> >
> >Marco, Yaakov, Jason, could we please go forward?  It's just a very simple
> >package tweak, it seems.
> 
> No problem to any repackage, but I have not really understood
> what is required for Octave and R.

AFAIU, you just have to provide a per-package file defining the path
to your dynamic libs.  I just unpacked
http://cygwin.stromeko.net/noarch/release/_autorebase/_autorebase-001000-1.tar.xz
and it contains files under etc/rebase/dynpath.d/ called R and octave:

  $ cat etc/rebase/dynpath.d/R
  /usr/lib/R/site-library
  $ cat etc/rebase/dynpath.d/octave 
  /usr/lib/octave/site

IIUC, you simply have to provide the files yourself, so every package
can influence easily what the new autorebase rebases :)

Achim, is that about right?


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: [ITA] _autorebase

[Achim Gratz]

Corinna Vinschen writes:
> AFAIU, you just have to provide a per-package file defining the path
> to your dynamic libs.  I just unpacked
> http://cygwin.stromeko.net/noarch/release/_autorebase/_autorebase-001000-1.tar.xz
> and it contains files under etc/rebase/dynpath.d/ called R and octave:
>
>   $ cat etc/rebase/dynpath.d/R
>   /usr/lib/R/site-library
>   $ cat etc/rebase/dynpath.d/octave 
>   /usr/lib/octave/site
>
> IIUC, you simply have to provide the files yourself, so every package
> can influence easily what the new autorebase rebases :)
>
> Achim, is that about right?

Yes, and if a full package rebuild isn't possible for whatever reason
this file could just be packaged in a separate package that then needs
to be referenced from the main package via dependency.  It looks like
this will need to be done for Perl if Reini doesn't re-surface.

BTW, do we want to keep these files in /etc or move to /var/lib?  Both
Ken and I interpret the LSB/FSH document as recommending /var/lib as the
place to put such things.  We could of course do that later on (there's
other stuff in /etc that would fall under that rule), but since nothing
has been released at the moment I thought I should ask again if a policy
decision has been reached already.


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: [ITA] _autorebase

[Corinna Vinschen]

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

On Jan 14 18:00, Achim Gratz wrote:
> Corinna Vinschen writes:
> > AFAIU, you just have to provide a per-package file defining the path
> > to your dynamic libs.  I just unpacked
> > http://cygwin.stromeko.net/noarch/release/_autorebase/_autorebase-001000-1.tar.xz
> > and it contains files under etc/rebase/dynpath.d/ called R and octave:
> >
> >   $ cat etc/rebase/dynpath.d/R
> >   /usr/lib/R/site-library
> >   $ cat etc/rebase/dynpath.d/octave 
> >   /usr/lib/octave/site
> >
> > IIUC, you simply have to provide the files yourself, so every package
> > can influence easily what the new autorebase rebases :)
> >
> > Achim, is that about right?
> 
> Yes, and if a full package rebuild isn't possible for whatever reason
> this file could just be packaged in a separate package that then needs
> to be referenced from the main package via dependency.  It looks like
> this will need to be done for Perl if Reini doesn't re-surface.
> 
> BTW, do we want to keep these files in /etc or move to /var/lib?  Both
> Ken and I interpret the LSB/FSH document as recommending /var/lib as the
> place to put such things.  We could of course do that later on (there's
> other stuff in /etc that would fall under that rule), but since nothing
> has been released at the moment I thought I should ask again if a policy
> decision has been reached already.

/var/lib/rebase/dynpath.d sounds good to me.


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: [ITA] _autorebase

[Achim Gratz]

Corinna Vinschen writes:
>> BTW, do we want to keep these files in /etc or move to /var/lib?  Both
>> Ken and I interpret the LSB/FSH document as recommending /var/lib as the
>> place to put such things.  We could of course do that later on (there's
>> other stuff in /etc that would fall under that rule), but since nothing
>> has been released at the moment I thought I should ask again if a policy
>> decision has been reached already.
>
> /var/lib/rebase/dynpath.d sounds good to me.

OK, that's a decision then.  I'll roll a new test autorebase package
with that location and no files in that directory shortly, but it may
take another week and a half before I get to it.



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: [ITA] _autorebase

[Yaakov Selkowitz]

On Wed, 2014-12-17 at 18:16 +0100, Corinna Vinschen wrote:
> On Dec 17 18:01, Achim Gratz wrote:
> > In fact if we do that, I'd like to require either new releases for the
> > packages using /etc/rebase/dynpath.d or alternatively that they get an
> > additional package that drops just this file (if a full release _now_
> > would be too much work) and the requisite change to setup.hint to have a
> > dependency added so that this new package gets pulled in.
> 
> That should be fine, given the rather short list of affected maintainers:
> 
>   octave   Marco Atzeri
>   perl     Reini Urban/Achim Gratz ?!?
>   php      Yaakov Selkowitz
>   python   Jason Tishler/Yaakov Selkowitz
>   R        Marco Atzeri
>   ruby     Yaakov Selkowitz

Some of these -- php and python at least -- do not have separate 'site'
and 'vendor' extension directories, so adding a directory entry for
these would pick up DLLs that are already registered with setup's
database.  How would you avoid duplicates (and hence wasted imagebase
space) in this case?


Yaakov

Re: [ITA] _autorebase

[Achim Gratz]

Yaakov Selkowitz writes:
> Some of these -- php and python at least -- do not have separate 'site'
> and 'vendor' extension directories, so adding a directory entry for
> these would pick up DLLs that are already registered with setup's
> database.  How would you avoid duplicates (and hence wasted imagebase
> space) in this case?

Rebase in database mode uses the same path only once I thought.


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: [ITA] _autorebase

[Corinna Vinschen]

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

On Jan 14 19:04, Achim Gratz wrote:
> Yaakov Selkowitz writes:
> > Some of these -- php and python at least -- do not have separate 'site'
> > and 'vendor' extension directories, so adding a directory entry for
> > these would pick up DLLs that are already registered with setup's
> > database.  How would you avoid duplicates (and hence wasted imagebase
> > space) in this case?
> 
> Rebase in database mode uses the same path only once I thought.

Yes, rebase eliminates duplicates on the commandline.


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: [ITA] _autorebase

[Achim Gratz]

Here's the new version that places its files into /var instead of /etc
as per our previous discussion.

The control files that belong to other packages (for rebasing of dynamic
objects) and go into /var/lib/rebase/dynpath.d have been split out each
into their own package for the maintainers of those packages to grab and
integrate (or just make their packages depend on via setup.hint if no
new release is done).  These will not be in the officially release of
_autorebase.

--8<---------------cut here---------------start------------->8---
wget="wget -rxnH --cut-dirs=2 http://cygwin.stromeko.net/noarch/release/_autorebase"
$wget/_autorebase-001001-1-src.tar.xz
$wget/_autorebase-001001-1.tar.xz
$wget/octave_autorebase-001001-1.tar.xz
$wget/perl_autorebase-001001-1.tar.xz
$wget/php_autorebase-001001-1.tar.xz
$wget/python26_autorebase-001001-1.tar.xz
$wget/python27_autorebase-001001-1.tar.xz
$wget/R_autorebase-001001-1.tar.xz
$wget/ruby_autorebase-001001-1.tar.xz
$wget/setup.hint
--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: [HEADSUP Maintainers] _autorebase

[Achim Gratz]

Corinna Vinschen writes:
> What would be most helpful is to get a piece of documentation for us
> maintainers how to use the new _autorebase facility, sent with a fat
> HEADSUP subject, and which we can ideally add to setup.html.

The _autorebase package is designed to require no intervention from a
package maintainer in most cases.  The core of the work is done by the
rebaselst script.  It works mostly like the rebaseall script, but tries
to rebase only files that have been changed since the last time
autorebase was run (it keeps the information to do this in
/var/cache/rebase).  The remainder of the package ensures that
autorebase is run each time the user runs setup.

An additional script rebase-trigger allows the user to request a full
rebase of the installation on the next execution of setup.  Both scripts
are self-documenting when invoked with an option of -h or --help.

Note: It's possible to run rebaselst manually if you know what you're
doing.  At the moment I don't want to advertise or support that,
however.


There are two exceptions that require maintainer attention:

1. Your application uses dynamic objects that have a suffix not matched
by "dll|so|oct|mex".  There currently aren't any such applications, but
if you plan to introduce one, please discuss on cygwin-apps first.

2. Your application allows users to install dynamic objects into
site-specific directories.  Since autorebase relies on the information
in /etc/setup, it would miss to rebase these objects since they aren't
part of any package.  If you maintain such an application, please add a
file /var/lib/rebase/dynpath.d/<package> that contains one absolute
directory path per line that autorebase should search for dynamic
objects to rebase.

Do not include those directories that packages are using and keep them
separate from those that site installations are going to.  If
user-installed and packaged files are shared in the same path,
_autorebase will need to check them each time setup is run, which
increases runtime.  The rebase database ensures that each file is
handled only once.  This is based on the path name, so you must ensure
that the same file doesn't get fed to rebase via two different paths.

As an example, Perl packages modules into /usr/lib/perl5/perl_vendor,
while site modules will go into /usr/lib/perl5/site_perl.  Only the
latter will need to be maintained via /var/lib/rebase/dynpath.d/perl,
which would have a single line containing the path
/usr/lib/perl5/site_perl.

Currently these files should be in /var/lib/rebase/dynpath.d if the
corresponding packages are installed:

octave
perl
php
python26
python27
R
ruby

Your package must provide one of these files when or before the
autorebase package gets released.


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: [HEADSUP Maintainers] _autorebase

[Corinna Vinschen]

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

On Jan 17 11:16, Achim Gratz wrote:
> Corinna Vinschen writes:
> > What would be most helpful is to get a piece of documentation for us
> > maintainers how to use the new _autorebase facility, sent with a fat
> > HEADSUP subject, and which we can ideally add to setup.html.
> 
> The _autorebase package is designed to require no intervention from a
> package maintainer in most cases.  [...]

Thanks Achim!


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: [ITA] _autorebase

[Corinna Vinschen]

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

On Jan 17 11:05, Achim Gratz wrote:
> Here's the new version that places its files into /var instead of /etc
> as per our previous discussion.
> 
> The control files that belong to other packages (for rebasing of dynamic
> objects) and go into /var/lib/rebase/dynpath.d have been split out each
> into their own package for the maintainers of those packages to grab and
> integrate (or just make their packages depend on via setup.hint if no
> new release is done).  These will not be in the officially release of
> _autorebase.
> 
> --8<---------------cut here---------------start------------->8---
> wget="wget -rxnH --cut-dirs=2 http://cygwin.stromeko.net/noarch/release/_autorebase"
> $wget/_autorebase-001001-1-src.tar.xz
> $wget/_autorebase-001001-1.tar.xz
> $wget/octave_autorebase-001001-1.tar.xz
> $wget/perl_autorebase-001001-1.tar.xz
> $wget/php_autorebase-001001-1.tar.xz
> $wget/python26_autorebase-001001-1.tar.xz
> $wget/python27_autorebase-001001-1.tar.xz
> $wget/R_autorebase-001001-1.tar.xz
> $wget/ruby_autorebase-001001-1.tar.xz
> $wget/setup.hint
> --8<---------------cut here---------------end--------------->8---

What about the perl_autorebase package?  Are you going to push this
into the perl stuff?


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: [HEADSUP Maintainers] _autorebase

[Andrew Schulman]

> On Jan 17 11:16, Achim Gratz wrote:
> > Corinna Vinschen writes:
> > > What would be most helpful is to get a piece of documentation for us
> > > maintainers how to use the new _autorebase facility, sent with a fat
> > > HEADSUP subject, and which we can ideally add to setup.html.
> > 
> > The _autorebase package is designed to require no intervention from a
> > package maintainer in most cases.  [...]
> 
> Thanks Achim!

The whole autorebase effort is so clearly gold star worthy that I went ahead and
awarded one:

http://cygwin.com/goldstars/#AG

(I hope my description is right)

Re: [HEADSUP Maintainers] _autorebase

[Corinna Vinschen]

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

On Jan 19 09:42, Andrew Schulman wrote:
> > On Jan 17 11:16, Achim Gratz wrote:
> > > Corinna Vinschen writes:
> > > > What would be most helpful is to get a piece of documentation for us
> > > > maintainers how to use the new _autorebase facility, sent with a fat
> > > > HEADSUP subject, and which we can ideally add to setup.html.
> > > 
> > > The _autorebase package is designed to require no intervention from a
> > > package maintainer in most cases.  [...]
> > 
> > Thanks Achim!
> 
> The whole autorebase effort is so clearly gold star worthy that I went ahead and
> awarded one:
> 
> http://cygwin.com/goldstars/#AG
> 
> (I hope my description is right)

Good thinking.


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: [ITA] _autorebase

[Corinna Vinschen]

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

Guys, ping?

On Jan 19 09:53, Corinna Vinschen wrote:
> On Jan 17 11:05, Achim Gratz wrote:
> > Here's the new version that places its files into /var instead of /etc
> > as per our previous discussion.
> > 
> > The control files that belong to other packages (for rebasing of dynamic
> > objects) and go into /var/lib/rebase/dynpath.d have been split out each
> > into their own package for the maintainers of those packages to grab and
> > integrate (or just make their packages depend on via setup.hint if no
> > new release is done).  These will not be in the officially release of
> > _autorebase.
> > 
> > --8<---------------cut here---------------start------------->8---
> > wget="wget -rxnH --cut-dirs=2 http://cygwin.stromeko.net/noarch/release/_autorebase"
> > $wget/_autorebase-001001-1-src.tar.xz
> > $wget/_autorebase-001001-1.tar.xz
> > $wget/octave_autorebase-001001-1.tar.xz
> > $wget/perl_autorebase-001001-1.tar.xz
> > $wget/php_autorebase-001001-1.tar.xz
> > $wget/python26_autorebase-001001-1.tar.xz
> > $wget/python27_autorebase-001001-1.tar.xz
> > $wget/R_autorebase-001001-1.tar.xz
> > $wget/ruby_autorebase-001001-1.tar.xz
> > $wget/setup.hint
> > --8<---------------cut here---------------end--------------->8---
> 
> What about the perl_autorebase package?  Are you going to push this
> into the perl stuff?

Can we make this transition really soon now, please?

From the above I take it that the only required action on your part is
to grab your package-releated FOO_autorebase package, pull it into your
package directory, and add a dependency of your runtime package to your
FOO_autorebase package.

  octave   Marco Atzeri
  R        Marco Atzeri

  perl     Achim Gratz

  python   Jason Tishler/Yaakov Selkowitz
  php      Yaakov Selkowitz
  ruby     Yaakov Selkowitz

When this is done, which seems really simple, we can eventually upload
Achim's _autorebase package and be done with 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: [ITA] _autorebase

[Corinna Vinschen]

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


Marco, Achim, Yaakov?  Anybody of you here?


I mean, hey, how are we going to go forward if nobody even bothers to
reply?  :(


On Jan 20 21:29, Corinna Vinschen wrote:
> On Jan 19 09:53, Corinna Vinschen wrote:
> > On Jan 17 11:05, Achim Gratz wrote:
> > > Here's the new version that places its files into /var instead of /etc
> > > as per our previous discussion.
> > > 
> > > The control files that belong to other packages (for rebasing of dynamic
> > > objects) and go into /var/lib/rebase/dynpath.d have been split out each
> > > into their own package for the maintainers of those packages to grab and
> > > integrate (or just make their packages depend on via setup.hint if no
> > > new release is done).  These will not be in the officially release of
> > > _autorebase.
> > > 
> > > --8<---------------cut here---------------start------------->8---
> > > wget="wget -rxnH --cut-dirs=2 http://cygwin.stromeko.net/noarch/release/_autorebase"
> > > $wget/_autorebase-001001-1-src.tar.xz
> > > $wget/_autorebase-001001-1.tar.xz
> > > $wget/octave_autorebase-001001-1.tar.xz
> > > $wget/perl_autorebase-001001-1.tar.xz
> > > $wget/php_autorebase-001001-1.tar.xz
> > > $wget/python26_autorebase-001001-1.tar.xz
> > > $wget/python27_autorebase-001001-1.tar.xz
> > > $wget/R_autorebase-001001-1.tar.xz
> > > $wget/ruby_autorebase-001001-1.tar.xz
> > > $wget/setup.hint
> > > --8<---------------cut here---------------end--------------->8---
> > 
> > What about the perl_autorebase package?  Are you going to push this
> > into the perl stuff?
> 
> Can we make this transition really soon now, please?
> 
> From the above I take it that the only required action on your part is
> to grab your package-releated FOO_autorebase package, pull it into your
> package directory, and add a dependency of your runtime package to your
> FOO_autorebase package.
> 
>   octave   Marco Atzeri
>   R        Marco Atzeri
> 
>   perl     Achim Gratz
> 
>   python   Jason Tishler/Yaakov Selkowitz
>   php      Yaakov Selkowitz
>   ruby     Yaakov Selkowitz
> 
> When this is done, which seems really simple, we can eventually upload
> Achim's _autorebase package and be done with it.


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: [ITA] _autorebase

[Marco Atzeri]

On 1/22/2015 6:21 PM, Corinna Vinschen wrote:
>
> Marco, Achim, Yaakov?  Anybody of you here?
>

I looked on the octave , and I don't think we
need a autorebase package, as the default
location is a tree under user HOME.
Moreover I am already packing anything that build on cygwin.

I need to look at the R as I am less familiar with it.

Marco

Re: [ITA] _autorebase

[Corinna Vinschen]

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

Hi Marco,

On Jan 22 18:44, Marco Atzeri wrote:
> On 1/22/2015 6:21 PM, Corinna Vinschen wrote:
> >
> >Marco, Achim, Yaakov?  Anybody of you here?
> >
> 
> I looked on the octave , and I don't think we
> need a autorebase package, as the default
> location is a tree under user HOME.
> Moreover I am already packing anything that build on cygwin.

The /var/lib/rebase/dynpath.d/octave file covers the path
/usr/lib/octave/site.  I don't know octave but that doesn't look
overly wrong to me to allow rebasing user-installed DLLs.

> I need to look at the R as I am less familiar with it.

/var/lib/rebase/dynpath.d/R covers /usr/lib/R/site-library.


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: [ITA] _autorebase

[Marco Atzeri]

On 1/22/2015 6:52 PM, Corinna Vinschen wrote:
> Hi Marco,
>
> On Jan 22 18:44, Marco Atzeri wrote:
>> On 1/22/2015 6:21 PM, Corinna Vinschen wrote:
>>>
>>> Marco, Achim, Yaakov?  Anybody of you here?
>>>
>>
>> I looked on the octave , and I don't think we
>> need a autorebase package, as the default
>> location is a tree under user HOME.
>> Moreover I am already packing anything that build on cygwin.
>
> The /var/lib/rebase/dynpath.d/octave file covers the path
> /usr/lib/octave/site.  I don't know octave but that doesn't look
> overly wrong to me to allow rebasing user-installed DLLs.

It will be eventually "/usr/lib/octave/packages"
site is for scripts

$ cygcheck -l octave-signal |grep "\.oct"
/usr/lib/octave/packages/signal-1.3.0/x86_64-unknown-cygwin-api-v49+/cl2bp.oct
/usr/lib/octave/packages/signal-1.3.0/x86_64-unknown-cygwin-api-v49+/medfilt1.oct
/usr/lib/octave/packages/signal-1.3.0/x86_64-unknown-cygwin-api-v49+/remez.oct
/usr/lib/octave/packages/signal-1.3.0/x86_64-unknown-cygwin-api-v49+/sosfilt.oct
/usr/lib/octave/packages/signal-1.3.0/x86_64-unknown-cygwin-api-v49+/upfirdn.oct
/usr/lib/octave/packages/signal-1.3.0/x86_64-unknown-cygwin-api-v49+/__fwht__.oct
/usr/lib/octave/packages/signal-1.3.0/x86_64-unknown-cygwin-api-v49+/__ultrwin__.oct

I have no objections to make a octave_autorebase-001001-1.tar.xz
anyway when the new autorebase is in place.

>> I need to look at the R as I am less familiar with it.
>
> /var/lib/rebase/dynpath.d/R covers /usr/lib/R/site-library.
>
>
> Thanks,
> Corinna

Re: [ITA] _autorebase

[Corinna Vinschen]

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

On Jan 22 19:04, Marco Atzeri wrote:
> 
> 
> On 1/22/2015 6:52 PM, Corinna Vinschen wrote:
> >Hi Marco,
> >
> >On Jan 22 18:44, Marco Atzeri wrote:
> >>On 1/22/2015 6:21 PM, Corinna Vinschen wrote:
> >>>
> >>>Marco, Achim, Yaakov?  Anybody of you here?
> >>>
> >>
> >>I looked on the octave , and I don't think we
> >>need a autorebase package, as the default
> >>location is a tree under user HOME.
> >>Moreover I am already packing anything that build on cygwin.
> >
> >The /var/lib/rebase/dynpath.d/octave file covers the path
> >/usr/lib/octave/site.  I don't know octave but that doesn't look
> >overly wrong to me to allow rebasing user-installed DLLs.
> 
> It will be eventually "/usr/lib/octave/packages"
> site is for scripts

Uh, ok.

> I have no objections to make a octave_autorebase-001001-1.tar.xz
> anyway when the new autorebase is in place.

I'm not exactly sure now, but I thought the idea was that the
PACKAGE_autorebase packages are already in place before _autorebase
is updated.  But on second thought, it's not exactly essential to
keep this order.  We could update _autorebase as soon as Achim is
ok with that.


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: [ITA] _autorebase

[Marco Atzeri]

On 1/22/2015 8:33 PM, Corinna Vinschen wrote:
> On Jan 22 19:04, Marco Atzeri wrote:
>>
>>
>
>> I have no objections to make a octave_autorebase-001001-1.tar.xz
>> anyway when the new autorebase is in place.
>
> I'm not exactly sure now, but I thought the idea was that the
> PACKAGE_autorebase packages are already in place before _autorebase
> is updated.  But on second thought, it's not exactly essential to
> keep this order.  We could update _autorebase as soon as Achim is
> ok with that.

both are fine for me.

R seems to use
   /usr/lib/R/site-library
for new add-on stuff.

And
   /usr/lib/R/library
   /usr/lib/R/modules

for updating existing stuff already part of the core.

> Thanks,
> Corinna

Regards
Marco

Re: [ITA] _autorebase

[Achim Gratz]

Corinna Vinschen writes:
> What about the perl_autorebase package?  Are you going to push this
> into the perl stuff?

For the moment I'd use a separate package and an edited setup.hint, any
new Perl release will likely have it included into the perl-base
package.  But the packaging for future Perl releases isn't finalized
yet.


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: [ITA] _autorebase

[Achim Gratz]

Corinna Vinschen writes:
> Marco, Achim, Yaakov?  Anybody of you here?
>
>
> I mean, hey, how are we going to go forward if nobody even bothers to
> reply?  :(

I just came back from a business trip halfway around the world.  This
list is still blocked when trying to reply from Gmane, so I usually
can't answer here when I'm not home.


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: [ITA] _autorebase

[Achim Gratz]

Marco Atzeri writes:
> I looked on the octave , and I don't think we
> need a autorebase package, as the default
> location is a tree under user HOME.
> Moreover I am already packing anything that build on cygwin.

Good, then just drop the file and be done 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: [ITA] _autorebase

[Achim Gratz]

Corinna Vinschen writes:
>> It will be eventually "/usr/lib/octave/packages"
>> site is for scripts
>
> Uh, ok.
>
>> I have no objections to make a octave_autorebase-001001-1.tar.xz
>> anyway when the new autorebase is in place.
>
> I'm not exactly sure now, but I thought the idea was that the
> PACKAGE_autorebase packages are already in place before _autorebase
> is updated.  But on second thought, it's not exactly essential to
> keep this order.  We could update _autorebase as soon as Achim is
> ok with that.

If the package maintainer says there isn't anything to rebase currently
then we don't need that file and it can easily be added later.


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: [ITA] _autorebase

[Achim Gratz]

Marco Atzeri writes:
> R seems to use
>   /usr/lib/R/site-library
> for new add-on stuff.

Right.  I'm not sure how common it is for users to use that facility.

> And
>   /usr/lib/R/library
>   /usr/lib/R/modules
>
> for updating existing stuff already part of the core.

Are you expecting users to do that or would you rather make an updated
release if that happens?


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

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

Re: [ITA] _autorebase

[Corinna Vinschen]

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

On Jan 24 16:32, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Marco, Achim, Yaakov?  Anybody of you here?
> >
> >
> > I mean, hey, how are we going to go forward if nobody even bothers to
> > reply?  :(
> 
> I just came back from a business trip halfway around the world.

Sorry, but we can't allow these alleged "business trips" anymore. ;)

> This list is still blocked when trying to reply from Gmane, so I
> usually can't answer here when I'm not home.

I have no idea if that could be changed and if so, how.  I guess a short
PM would be in order if you want to chime in in a case like this.


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 --]