I was wondering if there might be a rough, pie in the sky, timeframe for 
releasing 3.8.

There are currently 3 debian packages [1]:
povray_3.7.0.0
povray-includes_3.7.0.0
povray-examples_3.7.0.0

I will add 2 more:
qtpovray_0.1
qtpovray-extras_0.1

Should I call it 0.1?  3.8?  3.8.0.1?
qtpovray contains the executable and desktop
qtpovray-extras contains the glorious insert menu

Maybe I should call qtpovray-extras just povray-extras?

I want to leverage the existing povray-includes
which requires a release of package povray-includes_3.8.0.0
to pick up /usr/share/povray-3.8/includes .

Also, to get the .ini files especially /etc/povray/3.8/povray.conf
I need package povray_3.8.0.0 and we're not ready for that.

I could release a qmake built package povray_3.8.0.0 with the unix shell 
version (and the /etc/povray/3.8 files I need). But that's not my call 
(or true focus).  One bleh thing about that is the executable is 
/usr/bin/povray , so one can't have 3.7 and 3.8 executables installed at 
the same time, even though the data is already separated by version.

-- 
dik
Rendered 328976 of 330000 (99%)

[1] Ubuntu 18 has povray_3.7.0.4 , but I'm mostly working on Ubuntu 16 
which is povray_3.7.0.0

Post a reply to this message

Am 22.06.2018 um 13:39 schrieb dick balaska:

> qtpovray_0.1
> qtpovray-extras_0.1
> 
> Should I call it 0.1?  3.8?  3.8.0.1?
> qtpovray contains the executable and desktop
> qtpovray-extras contains the glorious insert menu

I'd make sure that it is clear which version of POV-Ray it is based on.
For UberPOV, I'm using the scheme `vX.YZ.N` to denote versions based on
POV-Ray vX.Y.Z.

> Maybe I should call qtpovray-extras just povray-extras?

No, you should definitely not. If it's not official POV-Ray, don't make
it look like it is.

> I want to leverage the existing povray-includes
> which requires a release of package povray-includes_3.8.0.0
> to pick up /usr/share/povray-3.8/includes .
> 
> Also, to get the .ini files especially /etc/povray/3.8/povray.conf
> I need package povray_3.8.0.0 and we're not ready for that.

In my naive understanding of Unix package management, I would suggest
for now to release qtpovray as a collection of stand-alone packages, and
later - once an official POV-Ray package is available - update it to
make use of the official POV-Ray packages, modifying part of the
qtpovray packages to do nothing more than pull in the official packages.

> I could release a qmake built package povray_3.8.0.0 with the unix shell
> version (and the /etc/povray/3.8 files I need). But that's not my call
> (or true focus).  One bleh thing about that is the executable is
> /usr/bin/povray , so one can't have 3.7 and 3.8 executables installed at
> the same time, even though the data is already separated by version.

I'd say that's a thing to be addressed by whoever is the maintainer of
the debian POV-Ray package. We're not doing any Unix package
maintenance, we're just providing the source code, Unix build tools, and
a bit of support. If I'm not mistaken, the configure script allows to
specify a different binary name.

If they're smart, the package also has a `/usr/bin/povray-3.7`
hard-linked to the same file (or `/usr/bin/povray` soft-linked to
`/usr/bin/povray-3.7`), so that installing another version "on top" of
it leaves an instance of the old binary available.


> [1] Ubuntu 18 has povray_3.7.0.4 , but I'm mostly working on Ubuntu 16
> which is povray_3.7.0.0

There's little difference there; POV-Ray v3.7.0.4 is just v3.7.0 updated
to work with the compiler and 3rd party libraries that ship with Ubuntu 18.

Post a reply to this message

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> I will add 2 more [Debian pkgs]:
> qtpovray_0.1
> qtpovray-extras_0.1

fwiw, following the instructions in
http://news.povray.org/5b01fa12%241%40news.povray.org

fails to build on Slackware 14.1, a first. ;-)

jr@crow:1:povray$ make
cd qt/libpovray/ && /usr/bin/qmake /tmp/QP/povray/qt/libpovray/libpovray.pro -o
Makefile
cd qt/libpovray/ && make -f Makefile
make[1]: Entering directory `/tmp/QP/povray/qt/libpovray'
g++ -c -pipe -O2 -w -fPIC -D_REENTRANT -DQT_DEPRECATED_WARNINGS
-DOPENEXR_MISSING -DBUILD_ARCH="x86_64" -DTRY_OPTIMIZED_NOISE -DBUILD_X86
-DQT_NO_DEBUG -DQT_CORE_LIB -DQT_SHARED -I/usr/lib64/qt/mkspecs/linux-g++ -I.
-I/usr/lib64/qt/include/QtCore -I/usr/lib64/qt/include -I../../source
-I../../platform/unix -I../../platform/x86 -I../../unix/povconfig -I../../vfe
-I. -o tmp/QP/povray/source/backend/bounding/boundingtask.o
..../../source/backend/bounding/boundingtask.cpp
In file included from ../../source/backend/frame.h:57:0,
                 from ../../source/backend/bounding/boundingtask.cpp:42:
..../../source/base/configbase.h:1048:6: error: #error "This version of POV-Ray
requires C++11, which your compiler does not seem to support."
     #error "This version of POV-Ray requires C++11, which your compiler does
not seem to support."
      ^


I know you're only concerned with Ubuntu, but thought you'd like to know.


regards, jr.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> We're not doing any Unix package maintenance, we're just providing
> the source code,

maybe a wiki page where package scripts and/or links, and "tips + tricks", for
various platforms can be found?


regards, jr.

Post a reply to this message

On 06/22/2018 11:12 AM, jr wrote:

> requires C++11, which your compiler does not seem to support."
>       #error "This version of POV-Ray requires C++11, which your compiler does
> not seem to support."
>        ^
> 
> 
> I know you're only concerned with Ubuntu, but thought you'd like to know.
> 

I have a fix for that.  debuild (debian package maker) gave the same 
error.  Apparently, I have some personalized qt config somewhere (?) 
that throws the C++11 in there.


-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

On 06/22/2018 08:48 AM, clipka wrote:
> Am 22.06.2018 um 13:39 schrieb dick balaska:
> 
>> qtpovray_0.1
>> qtpovray-extras_0.1
>>
>> Should I call it 0.1?  3.8?  3.8.0.1?
>> qtpovray contains the executable and desktop
>> qtpovray-extras contains the glorious insert menu
> 
> I'd make sure that it is clear which version of POV-Ray it is based on.
> For UberPOV, I'm using the scheme `vX.YZ.N` to denote versions based on
> POV-Ray vX.Y.Z.

I can do that.  So my first would be qtpovray-3.80.1
ja?

> 
>> Maybe I should call qtpovray-extras just povray-extras?
> 
> No, you should definitely not. If it's not official POV-Ray, don't make
> it look like it is.

Well, that was my first thought. But, OTOH, there is no "official" 
povray, so screw all y'all. ;)
All praise to Andreas Beckmann <anb### [at] debianorg> (who I never heard of) 
as the debian maintainer.

(
I have read so much debian foo lately. It's too much. Then I unpacked 
the debian povray port, and it's all right there, with all the right 
magic words to make 3 packages from one set of source.  The only hard 
part was was bootstrapping qmake, for which the only documentation is a 
comment in a tutorial. "How do I use qmake instead of configure?" "Since 
version blah, it just magically works".

jr whined that I didn't rename my dir root from povray to qtpovray. The 
fact that I didn't bit me in the butt here. Package qtpovray must be 
built from dir root qtpovray. Then it sees qtpovray.pro first and 
ignores any ./configure that lives there.  I'm going to have to rename 
my repo.
)

> 
>> I want to leverage the existing povray-includes
>> which requires a release of package povray-includes_3.8.0.0
>> to pick up /usr/share/povray-3.8/includes .
>>
>> Also, to get the .ini files especially /etc/povray/3.8/povray.conf
>> I need package povray_3.8.0.0 and we're not ready for that.
> 
> In my naive understanding of Unix package management, I would suggest
> for now to release qtpovray as a collection of stand-alone packages, and
> later - once an official POV-Ray package is available - update it to
> make use of the official POV-Ray packages, modifying part of the
> qtpovray packages to do nothing more than pull in the official packages.

I will do that.
Although I would prefer if the data was in /usr/share/povray/3.[78]
I will be consistent and go with /usr/share/qtpovray-3.81 to match the 
existing style of /usr/share/povray-3.7

(Actually my personal preference is to keep it *all* together, i.e.
/opt/povray/bin
/opt/povray/etc
/opt/povray/var/include

I'm not a real fan of the debian model of sowing povray dust throughout 
the file system.  But it works for a couple hundred million (a billion?) 
installations, so it's good enough for me.
)

> 
>> I could release a qmake built package povray_3.8.0.0 with the unix shell
>> version (and the /etc/povray/3.8 files I need). But that's not my call
>> (or true focus).  One bleh thing about that is the executable is
>> /usr/bin/povray , so one can't have 3.7 and 3.8 executables installed at
>> the same time, even though the data is already separated by version.
> 
> I'd say that's a thing to be addressed by whoever is the maintainer of
> the debian POV-Ray package. We're not doing any Unix package
> maintenance, we're just providing the source code, Unix build tools, and
> a bit of support. If I'm not mistaken, the configure script allows to
> specify a different binary name >
> If they're smart, the package also has a `/usr/bin/povray-3.7`
> hard-linked to the same file (or `/usr/bin/povray` soft-linked to
> `/usr/bin/povray-3.7`), so that installing another version "on top" of
> it leaves an instance of the old binary available.

99% of packages don't do symlinks.  But the big boys do; gcc, python, 
wish.  I will suggest this to the debian maintainer.


-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

hi,

dick balaska <dic### [at] buckosoftcom> wrote:
> > I know you're only concerned with Ubuntu, but thought you'd like to know.
> I have a fix for that.  ... some personalized qt config somewhere (?)
> that throws the C++11 in there.

I'll be happy (and a little curious :-)) to try.

btw, replying to clipka you wrote: "99% of packages don't do symlinks."

the Slackware 'makepkg' does, just like .. "the big boys".  :-)


regards, jr.

Post a reply to this message

Am 22.06.2018 um 17:15 schrieb jr:
> hi,
> 
> clipka <ano### [at] anonymousorg> wrote:
>> We're not doing any Unix package maintenance, we're just providing
>> the source code,
> 
> maybe a wiki page where package scripts and/or links, and "tips + tricks", for
> various platforms can be found?

If you know someone knowledgeable enough and willing to write up such a
wiki page - sure.

Post a reply to this message

Am 22.06.2018 um 17:47 schrieb dick balaska:

>> I'd make sure that it is clear which version of POV-Ray it is based on.
>> For UberPOV, I'm using the scheme `vX.YZ.N` to denote versions based on
>> POV-Ray vX.Y.Z.
> 
> I can do that.  So my first would be qtpovray-3.80.1
> ja?

I'd go for 3.80.0, but the choice is up to you.


> jr whined that I didn't rename my dir root from povray to qtpovray. The
> fact that I didn't bit me in the butt here. Package qtpovray must be
> built from dir root qtpovray. Then it sees qtpovray.pro first and
> ignores any ./configure that lives there.  I'm going to have to rename
> my repo.

There's no rule that says your local Git repo has to have the same name
as the remote.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 22.06.2018 um 17:15 schrieb jr:
> > maybe a wiki page where package scripts and/or links, and "tips + tricks", for
> > various platforms can be found?
>
> If you know someone knowledgeable enough and willing to write up such a
> wiki page - sure.

I'd be happy to read up sufficient on the wiki language to add the entry for
Slackware; since all packages are built from unmodified sources, it's
essentially a link to http://www.slackbuilds.org/ where one can find the package
"ingredients" for any given os release.  the scripts are maintained and use the
3.7.0.0 source.


regards, jr.

Post a reply to this message