Re: [ITA] _autorebase
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
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/ 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
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
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
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 0x7000 on both arches, but rebaseall uses 0x4 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
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 0x7000 on both arches, > but rebaseall uses 0x4 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
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 0x7000 on both arches, but rebaseall uses 0x4 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
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
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
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.
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".
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgpQP0DQfzKNe.pgp
Description: PGP signature
Re: [ITA] _autorebase
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 0x7000 on both arches, > > but rebaseall uses 0x4 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: 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: 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: - 0x000:7fffReserved for OS 0x000:8000 - 0x000:POSIX threads 0x001: - 0x001:7fffProcess image 0x001:8000 - 0x001:Cygwin DLL w/ all shared data 0x002: - 0x003:8 Gigs for rebased DLLs 0x004: - 0x005:8 Gigs for non-rebased DLLs 0x006: - 0x6ff:Heap bottom-up, mmaps top-down 0x700: - 0x7ff: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 pgpVEEMj9wEaG.pgp Description: PGP signature
Re: [ITA] _autorebase
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
>
>
> 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".
>
>
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
Corinna Vinschen writes: > The change is required. The base address 0x4: 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: > 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: - 0x000:7fffReserved for OS > 0x000:8000 - 0x000:POSIX threads > 0x001: - 0x001:7fffProcess image > 0x001:8000 - 0x001:Cygwin DLL w/ all shared data > 0x002: - 0x003:8 Gigs for rebased DLLs > 0x004: - 0x005:8 Gigs for non-rebased DLLs > 0x006: - 0x6ff:Heap bottom-up, mmaps top-down > 0x700: - 0x7ff: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
On Dec 15 18:20, Achim Gratz wrote: > Corinna Vinschen writes: > > The change is required. The base address 0x4: 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: > > 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: - 0x000:7fffReserved for OS > > 0x000:8000 - 0x000:POSIX threads > > 0x001: - 0x001:7fffProcess image > > 0x001:8000 - 0x001:Cygwin DLL w/ all shared data > > 0x002: - 0x003:8 Gigs for rebased DLLs > > 0x004: - 0x005:8 Gigs for non-rebased DLLs > > 0x006: - 0x6ff:Heap bottom-up, mmaps top-down > > 0x700: - 0x7ff: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 pgp4M2u86tlf9.pgp Description: PGP signature
Re: [ITA] _autorebase
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/ 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 pgpabaBlmVPi4.pgp Description: PGP signature
Re: [ITA] _autorebase
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: [ITA] _autorebase
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 pgpDh_9nlr9NX.pgp Description: PGP signature
Re: [ITA] _autorebase
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 pgpqFc7SzRKfb.pgp Description: PGP signature
Re: [ITA] _autorebase
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
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
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 RMarco 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 pgpv4TnXGD__c.pgp Description: PGP signature
Re: [ITA] _autorebase
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 > RMarco 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: [ITA] _autorebase
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 > > RMarco 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 pgp6VZbo5RUXx.pgp Description: PGP signature
Re: [ITA] _autorebase
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 > > > RMarco 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
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 > > > > RMarco 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 pgptivrt2nDLr.pgp Description: PGP signature
Re: [ITA] _autorebase
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 > > > RMarco 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 pgph9PvVzdMvt.pgp Description: PGP signature
Re: [ITA] _autorebase
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 RMarco 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
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 > RMarco 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 pgpXQXHWy5tDa.pgp Description: PGP signature
Re: [ITA] _autorebase
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
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 pgp8LGlKycQ1e.pgp Description: PGP signature
Re: [ITA] _autorebase
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
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 > RMarco 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
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
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 pgpQp6F8sIWHf.pgp Description: PGP signature
Re: [ITA] _autorebase
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: [ITA] _autorebase
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 pgpY3vNbROUqo.pgp Description: PGP signature
Re: [ITA] _autorebase
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 RMarco 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 pgpXitZCfLnAI.pgp Description: PGP signature
Re: [ITA] _autorebase
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 > RMarco 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 pgpRAKf1WJetP.pgp Description: PGP signature
Re: [ITA] _autorebase
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
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 pgpqGmP2zzgPK.pgp Description: PGP signature
Re: [ITA] _autorebase
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
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 pgps6pXoMAvat.pgp Description: PGP signature
Re: [ITA] _autorebase
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
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
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
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
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
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
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 pgprqOXIIfkHs.pgp Description: PGP signature
