[Attn Maintainer] octave

[Attn Maintainer] octave

[Achim Gratz]

The site octaverc has code that tries to keep the package directory
up-to-date.  That's a no-no, since normal users don't have permission to
change files under /usr/lib.

Could you please remove that code and put the update into a post-install
script?


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: [Attn Maintainer] octave

[Marco Atzeri]

On 5/29/2015 9:22 PM, Achim Gratz wrote:
>
> The site octaverc has code that tries to keep the package directory
> up-to-date.  That's a no-no, since normal users don't have permission to
> change files under /usr/lib.

/usr/share/octave/site/m/startup/octaverc is updating
   "/usr/share/octave/packages"
if any subdirectory under "/usr/share/octave/" has been added
or removed, to update the octave package database.

Why do you see actions under "/usr/lib" ?

See note on:
https://sourceware.org/ml/cygwin-announce/2014-08/msg00033.html

> Could you please remove that code and put the update into a post-install
> script?

It is build as such as a normal post-install script will not work.

I will look if I can find a mechanism that allow a common approach for 
the 50s octave-* packages.

In the past these problems make another solution impossible:

- the script must run octave and due to octave lib dependency a fork 
failures on 32bit was almost guarantee.

- the script must run for any postinstall - postremove of any
   octave-* (forge packages). So
   1) it will be heavy to run it 50 times, it must be a common one.
   2) we have no post remove.
   3) If also octave is removed the post remove must not run.

- /usr/share/octave/packages does not exist if the database is empty
   so I can not change its permission in the postinstall phase before
   its creation.

Regards
Marco








> Regards,
> Achim.

Re: [Attn Maintainer] octave

[Achim Gratz]

Marco Atzeri writes:
> /usr/share/octave/site/m/startup/octaverc is updating
>   "/usr/share/octave/packages"
> if any subdirectory under "/usr/share/octave/" has been added
> or removed, to update the octave package database.
>
> Why do you see actions under "/usr/lib" ?

I simply remembered wrong.

> See note on:
> https://sourceware.org/ml/cygwin-announce/2014-08/msg00033.html

In any case, making a whole directory mode 666 on a server isn't going
to fly.

>> Could you please remove that code and put the update into a post-install
>> script?
>
> It is build as such as a normal post-install script will not work.

TeXLive had the same problem, that's one of the reasons perpetual
postinstall scripts were introduced.  You can look at that to see how
Ken deals with that.

> I will look if I can find a mechanism that allow a common approach for
> the 50s octave-* packages.
>
> In the past these problems make another solution impossible:
>
> - the script must run octave and due to octave lib dependency a fork
> failures on 32bit was almost guarantee.

This is not a problem anymore since your postinstall action will be run
after autorebase.

> - the script must run for any postinstall - postremove of any
>   octave-* (forge packages). So
>   1) it will be heavy to run it 50 times, it must be a common one.

No, you just place a trigger that is then collected by the perpetual
postinstall.

>   2) we have no post remove.

With perpetual post-install, pre-remove is working just as well as long
as octave itself is installed.

>   3) If also octave is removed the post remove must not run.

In this case the perpetual postinstall script is also removed, so
whether the trigger is or isn't there makes no difference.

> - /usr/share/octave/packages does not exist if the database is empty
>   so I can not change its permission in the postinstall phase before
>   its creation.

Why is that?  Just because cygport by default removes empty directories?


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: [Attn Maintainer] octave

[Marco Atzeri]

On 5/30/2015 8:01 AM, Achim Gratz wrote:
> Marco Atzeri writes:

>
>> - /usr/share/octave/packages does not exist if the database is empty
>>    so I can not change its permission in the postinstall phase before
>>    its creation.
>
> Why is that?  Just because cygport by default removes empty directories?

It is a file.
When no packages exist, the file also does not exist.

> Regards,
> Achim.

  Marco

Re: [Attn Maintainer] octave

[Marco Atzeri]

On 5/30/2015 8:12 AM, Marco Atzeri wrote:
> On 5/30/2015 8:01 AM, Achim Gratz wrote:
>> Marco Atzeri writes:
>
>>
>>> - /usr/share/octave/packages does not exist if the database is empty
>>>    so I can not change its permission in the postinstall phase before
>>>    its creation.
>>
>> Why is that?  Just because cygport by default removes empty directories?
>
> It is a file.
> When no packages exist, the file also does not exist.

I mean the file "/usr/share/octave/octave_packages"
>
>> Regards,
>> Achim.
>
>   Marco
>

Re: [Attn Maintainer] octave

[Marco Atzeri]

On 5/30/2015 8:01 AM, Achim Gratz wrote:
> Marco Atzeri writes:
>
> TeXLive had the same problem, that's one of the reasons perpetual
> postinstall scripts were introduced.  You can look at that to see how
> Ken deals with that.
..
 > Regards,
 > Achim.
 >

Hi Achim,
if I understood correctly a script called

   /etc/postinstall/zp_octave_finish.dash

will be always executed at the end of the postinstall script
sequence and never renamed as ".done".

I am moving the octave update script in
  /var/lib/octave/update_packages_list

so the new octave update should work as:

1) every octave-forge preremove/postinstall script
    touches /var/lib/octave/update.flag

2) zp_octave_finish.dash checks if
    /var/lib/octave/update.flag exists
   and if so execute
   /usr/bin/octave-cli /var/lib/octave/update_packages_list

3) /var/lib/octave/update_packages_list
    updates the octave package database and removes the
   /var/lib/octave/update.flag

If there are no fork issue on 32 bit, I will implement
in this way on 4.0.0 that I am just building together with
update of the 50s octave-forge packages.

Regards
Marco

Re: [Attn Maintainer] octave

[Achim Gratz]

Marco Atzeri writes:
> if I understood correctly a script called
>
>   /etc/postinstall/zp_octave_finish.dash
>
> will be always executed at the end of the postinstall script
> sequence and never renamed as ".done".

Yes.

> I am moving the octave update script in
>  /var/lib/octave/update_packages_list
>
> so the new octave update should work as:
>
> 1) every octave-forge preremove/postinstall script
>    touches /var/lib/octave/update.flag
>
> 2) zp_octave_finish.dash checks if
>    /var/lib/octave/update.flag exists
>   and if so execute
>   /usr/bin/octave-cli /var/lib/octave/update_packages_list
>
> 3) /var/lib/octave/update_packages_list
>    updates the octave package database and removes the
>   /var/lib/octave/update.flag

Yes, that's how it works.

> If there are no fork issue on 32 bit, I will implement
> in this way on 4.0.0 that I am just building together with
> update of the 50s octave-forge packages.

If there are fork issues, they would be hitting the users just the same.
Again, autorebase runs before any other postinstall scripts.


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

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

Re: [Attn Maintainer] octave

[Achim Gratz]

Marco Atzeri writes:
> 2) zp_octave_finish.dash checks if
>    /var/lib/octave/update.flag exists
>   and if so execute
>   /usr/bin/octave-cli /var/lib/octave/update_packages_list

You need to set the path in the update script so that it finds the DLL
in /usr/lib/lapack or the script will never work (I just see you already
fixed it for 64bit).

The shells running postinstall don't source /etc/profile or anything
like that, so you need to set up the environment as you need it.  BTW,
the postinstall scripts for octave-forge should all be dash scripts as
well, just as any other postinstall script that isn't making use of any
bash specific feature.  You don't need to check for the existence of the
update file there either, just touch it.

Again, why is it not possible to keep that DLL in a standard location or
link octave with the correct runtime search path?  If it absolutely must
be on path, then couldn't you just add it on the invocation via a
wrapper script?


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

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

Re: [Attn Maintainer] octave

[Marco Atzeri]

On 6/22/2015 6:49 PM, Achim Gratz wrote:
> Marco Atzeri writes:
>> 2) zp_octave_finish.dash checks if
>>     /var/lib/octave/update.flag exists
>>    and if so execute
>>    /usr/bin/octave-cli /var/lib/octave/update_packages_list
>
> You need to set the path in the update script so that it finds the DLL
> in /usr/lib/lapack or the script will never work (I just see you already
> fixed it for 64bit).

Packing problem. They should be equal.
I will repack the 32 bit an bump.

>
> The shells running postinstall don't source /etc/profile or anything
> like that, so you need to set up the environment as you need it.  BTW,
> the postinstall scripts for octave-forge should all be dash scripts as
> well, just as any other postinstall script that isn't making use of any
> bash specific feature.  You don't need to check for the existence of the
> update file there either, just touch it.
>
> Again, why is it not possible to keep that DLL in a standard location or
> link octave with the correct runtime search path?  If it absolutely must
> be on path, then couldn't you just add it on the invocation via a
> wrapper script?

1) openblas is optional but it collides with lapack blas.
So it must be before in the PATH

$ cygcheck -l libopenblas
/usr/bin/cygblas-0.dll

$ cygcheck -l liblapack0
/etc/profile.d/lapack0.csh
/etc/profile.d/lapack0.sh
/usr/lib/lapack/cygblas-0.dll
/usr/lib/lapack/cyglapack-0.dll


2) Is is not only octave that uses cygblas-0.dll

> Regards,
> Achim.
>

Re: [Attn Maintainer] octave

[Achim Gratz]

Marco Atzeri writes:
> 1) openblas is optional but it collides with lapack blas.
> So it must be before in the PATH
>
> $ cygcheck -l libopenblas
> /usr/bin/cygblas-0.dll

That sounds like something you'd want to use alternatives for.


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

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

Re: [Attn Maintainer] octave

[Marco Atzeri]

On 6/23/2015 7:35 AM, Achim Gratz wrote:
> Marco Atzeri writes:
>> 1) openblas is optional but it collides with lapack blas.
>> So it must be before in the PATH
>>
>> $ cygcheck -l libopenblas
>> /usr/bin/cygblas-0.dll
>
> That sounds like something you'd want to use alternatives for.
>

alternative does not work for dll's

>
> Regards,
> Achim.
>

Re: [Attn Maintainer] octave

[Achim Gratz]

Marco Atzeri writes:
>> That sounds like something you'd want to use alternatives for.
>
> alternative does not work for dll's

I keep forgetting that it uses symlinks… :-(
So could we not do this via postinstall scripts, then?


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