Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Kurt Kremitzki]

On 04/01/2018 01:39 PM, Anton Gladky wrote:

Hi Kurt,

I would propose you to join as a maintainer of netgen
and freecad. I am not using those packages now and
will "orphan" them soon.

Regards

Anton



That would be great--my long-term plans were basically along those 
lines, anyway.

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Anton Gladky]

Hi Kurt,

I would propose you to join as a maintainer of netgen
and freecad. I am not using those packages now and
will "orphan" them soon.

Regards

Anton


2018-04-01 13:57 GMT+02:00 Kurt Kremitzki :
>
>
> On 04/01/2018 06:10 AM, Anton Gladky wrote:
>>
>> Looks good for me too. Are oce and opencascade
>> are able to co-exist? In any case we need to plan
>> the moving of oce-dependent packages into opencascade.
>>
>>
>> Anton
>
>
> Yes, the regular binary packages are co-installable but the -dev packages
> conflict. The only oce-dependent package that seems to have an issue with
> libocct stuff being present is deal.ii.
>
> I contacted them on their mailing list a few weeks ago [1] to let them know
> that this change was coming and they seemed nonchalant about it being an
> issue, and willing to help if it was. I also attempted rebuilding the
> package but it didn't work out of the box with s/liboce/libocct/ and was too
> busy to investigate much further at the time.
>
> The two main oce-dependent packages I work with, FreeCAD and Netgen,
> definitely work well with OCCT and are nearly ready to switch. I have a
> FreeCAD 0.17 package waiting for an official tagging, and a Netgen 6.2.1802
> package needing just a bit more polish. I'll probably try to work on those
> in reverse order so we can enable Netgen support for the FreeCAD 0.17
> release.
>
> 1. https://groups.google.com/forum/#!topic/dealii/czU9-FY2OQA

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Kurt Kremitzki]

On 04/01/2018 06:10 AM, Anton Gladky wrote:

Looks good for me too. Are oce and opencascade
are able to co-exist? In any case we need to plan
the moving of oce-dependent packages into opencascade.


Anton


Yes, the regular binary packages are co-installable but the -dev 
packages conflict. The only oce-dependent package that seems to have an 
issue with libocct stuff being present is deal.ii.


I contacted them on their mailing list a few weeks ago [1] to let them 
know that this change was coming and they seemed nonchalant about it 
being an issue, and willing to help if it was. I also attempted 
rebuilding the package but it didn't work out of the box with 
s/liboce/libocct/ and was too busy to investigate much further at the time.


The two main oce-dependent packages I work with, FreeCAD and Netgen, 
definitely work well with OCCT and are nearly ready to switch. I have a 
FreeCAD 0.17 package waiting for an official tagging, and a Netgen 
6.2.1802 package needing just a bit more polish. I'll probably try to 
work on those in reverse order so we can enable Netgen support for the 
FreeCAD 0.17 release.


1. https://groups.google.com/forum/#!topic/dealii/czU9-FY2OQA

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Anton Gladky]

Looks good for me too. Are oce and opencascade
are able to co-exist? In any case we need to plan
the moving of oce-dependent packages into opencascade.


Anton


2018-04-01 10:18 GMT+02:00 Tobias Frost :
> On Sat, Mar 31, 2018 at 03:16:30PM -0500, Kurt Kremitzki wrote:
>> Someone on the FreeCAD forum pointed out to me that there's a problem in
>> 32-bit builds with d/occt-draw.install. I've pushed the correction to the
>> repo--not sure what else is required to correct the package since it looks
>> like it's already been uploaded.
>
> Thanks for the notice! There is no rush for this atm.
>
> I guess we first let is pass NEW, as we've targetet experimental anyway.
> Once cleared NEW, lets wait for all buildd to catch up and see if/where they
> symbols needs per-arch tweaking.
> We'll upload to unstable then and include that fix too...
> (Thats how I would procesd, let me know if it is ok for you)

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Kurt Kremitzki]

On 04/01/2018 03:18 AM, Tobias Frost wrote:

On Sat, Mar 31, 2018 at 03:16:30PM -0500, Kurt Kremitzki wrote:

Someone on the FreeCAD forum pointed out to me that there's a problem in
32-bit builds with d/occt-draw.install. I've pushed the correction to the
repo--not sure what else is required to correct the package since it looks
like it's already been uploaded.


Thanks for the notice! There is no rush for this atm.

I guess we first let is pass NEW, as we've targetet experimental anyway.
Once cleared NEW, lets wait for all buildd to catch up and see if/where they
symbols needs per-arch tweaking.
We'll upload to unstable then and include that fix too...
(Thats how I would procesd, let me know if it is ok for you)



Sure, that sounds fine to me.

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Tobias Frost]

On Sat, Mar 31, 2018 at 03:16:30PM -0500, Kurt Kremitzki wrote:
> Someone on the FreeCAD forum pointed out to me that there's a problem in
> 32-bit builds with d/occt-draw.install. I've pushed the correction to the
> repo--not sure what else is required to correct the package since it looks
> like it's already been uploaded.

Thanks for the notice! There is no rush for this atm.

I guess we first let is pass NEW, as we've targetet experimental anyway.
Once cleared NEW, lets wait for all buildd to catch up and see if/where they
symbols needs per-arch tweaking.
We'll upload to unstable then and include that fix too...
(Thats how I would procesd, let me know if it is ok for you)

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Kurt Kremitzki]

Someone on the FreeCAD forum pointed out to me that there's a problem in 
32-bit builds with d/occt-draw.install. I've pushed the correction to 
the repo--not sure what else is required to correct the package since it 
looks like it's already been uploaded.

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Tobias Frost]

On Sat, Mar 31, 2018 at 05:05:37AM -0500, Kurt Kremitzki wrote:
> 
> 
> On 03/31/2018 03:23 AM, Tobias Frost wrote:
> > On Fri, Mar 30, 2018 at 02:48:22PM +0200, Tobias Frost wrote:
> > 
> > PS: I forgot one thing:
> > Please update the date in the changelog; (convenient is to use
> > 'dch -r ""' for this, with the "")
> > 
> > --
> > tobi
> 
> All done!
> 
> > > > > - symbol files
> > > > 
> > > > I cleaned things up with c++filt and removed the offending symbols you
> > > > mentioned, but this now results in a lintian error--not sure if I should
> > > > override it or what.
> > > 
> > > Actually should be fixed in the source, but I guess for now just mark it
> > > as "optional" in the symbols file, as this is clearly a private symbol
> > > causing this... Sorry, I ran out of time also to provide a patch for 
> > > this..
> 
> Done as well.
> 
> > > > So, hopefully that summarizes what's new in my repo on salsa.d.o. 
> > > > Remember
> > > > that I remade the repo so a fresh clone will be needed. Crossing my 
> > > > fingers
> > > > that there won't be much more before this package is ready!
> > > 
> > > Unfortuantly without the pristine-tars from debsnap ;-(
> > > But I think we can add them manually to the branch later.
> > > (I did so, currently pushing to my forked project @ salsa, but I ran out 
> > > of time
> > > and could not test it before.. Please Make sure to test if building is 
> > > still working
> > > before merging it!)
> 
> Yep, I've done another build & check and everything looks good here.

Uploading! As it will have to pass the NEW queue and to avoid double work,
please remove the package manually from mentors.d.n.
Many thanks for your contribution to Debian!

-- 
tobi 

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Kurt Kremitzki]

On 03/31/2018 03:23 AM, Tobias Frost wrote:

On Fri, Mar 30, 2018 at 02:48:22PM +0200, Tobias Frost wrote:

PS: I forgot one thing:
Please update the date in the changelog; (convenient is to use
'dch -r ""' for this, with the "")

--
tobi


All done!


- symbol files


I cleaned things up with c++filt and removed the offending symbols you
mentioned, but this now results in a lintian error--not sure if I should
override it or what.


Actually should be fixed in the source, but I guess for now just mark it
as "optional" in the symbols file, as this is clearly a private symbol
causing this... Sorry, I ran out of time also to provide a patch for this..


Done as well.


So, hopefully that summarizes what's new in my repo on salsa.d.o. Remember
that I remade the repo so a fresh clone will be needed. Crossing my fingers
that there won't be much more before this package is ready!


Unfortuantly without the pristine-tars from debsnap ;-(
But I think we can add them manually to the branch later.
(I did so, currently pushing to my forked project @ salsa, but I ran out of time
and could not test it before.. Please Make sure to test if building is still 
working
before merging it!)


Yep, I've done another build & check and everything looks good here.

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Tobias Frost]

On Fri, Mar 30, 2018 at 02:48:22PM +0200, Tobias Frost wrote:

PS: I forgot one thing:
Please update the date in the changelog; (convenient is to use
'dch -r ""' for this, with the "")

--
tobi

> On Tue, Mar 27, 2018 at 01:40:28AM -0500, Kurt Kremitzki wrote:
> > Ok, I've concluded the next round of work on the package. I recreated the
> > repo with `gbp import-dscs --debsnap`. I moved my d/watch and
> > +Files-Excluded d/copyright file but ran into issues with missing files
> > (e.g. src/Standard file and folders was totally missing) when trying to do
> > `gbp import-orig --uscan`. I ended up just importing from the .orig.tar.gz
> > and manually cleaning out the problematic copyright files with `git
> > filter-branch`. This also required a little patch to remove references to
> > the deleted samples in the doc build.
> 
> Ok, strange, because Files-Excluded usually works really nicely...
> Maybe a bug in mk-origtargz? 
> 
> Please note that repackaging requires you to suffix the upstream version
> with "+dfsg" (as we've removed files due to DFSG reasons).
> I've patched d/changelog and d/watch, MR will follow.
> 
> Another MR is asking you to add me as Uploader... (Of course only if
> you want) The advantage is that I could have commited all those fixed directly
> and have uploaded the package already ;-)) If accepted, please also add me to
> the repo so that I can directly commit.
> 
> > I also added things to d/copyright per your review recommendations.
> > 
> > > - d/changelog.gz / changelog.html.gz
> > 
> > I decided to remove d/changelog.gz & d/changelog.html.gz as well.
> > > - d/patches
> > >- did you check with upstream whether they would accept the patches,
> > >  especially fix-install-dir-references.diff.
> > 
> > I will work on getting this and the manpage upstreamed.
> 
> > > - lintian overrides
> > 
> > I cleaned these up.
> > 
> > > - script-not-executeable
> > >You writd in the override:# /usr/share/occt/bin/*.sh are reference
> > scripts
> > >Can you expand what you mean? Are they examples? Are they
> > >needed? For what are they needed?
> > >One of the scripts references DRAWEXE which is listed
> > >in d/non-installed
> > 
> > Yes, part of Draw's purpose is testing and demonstrating OCCT behavior with
> > tweaked dependencies, so these scripts are a reference for environment
> > variable tweaks which can be done in a wrapper script around the occt-draw
> > binary.
> > 
> > > - test suite
> > >You write in the lintian override that runs only under Windows with a
> > >custom occt-draw.. Can you elaborate? What is the difference to the
> > >occt-draw we ship?
> > 
> > To be honest, I will need to iterate on the occt-draw package. The upstream
> > devs mainly use Windows so things don't work perfectly out of the box right
> > now (although they do work.) Once they do, I will integrate the upstream
> > test suite (which itself uses occt-draw) into the Debian package.
> 
> OK, IMHO we can work on it after the initial upload too, no need to have this
> perfect from the beginning.
> 
> > > - occt-doc
> > 
> > Renamed.
> > 
> > > - the xpm images...
> > >Where are they from? What is the copyright?
> > 
> > This is a bit of a tricky question--they are definitely derived from
> > upstream's logo (see opencascade.com) which is included in the source as
> > ./src/DrawResources/OCC_logo.png. These .xpm files first appeared in the 6th
> > revision of the first version packaged for Debian, 6.2-6. However, they are
> > not explicitly mentioned in the changelog or elsewhere. I believe the files
> > were made manually by the former maintainer Adam C. Powell IV by modifying
> > the aforementioned source image (which contains the text "OpenCASCADE") by
> > cropping most out of the text out and changing filetypes (the .xpm files
> > just say 'OCC' with the same font as the upstream file.
> > 
> > So, I'm not sure if they should go in with the debian/* stanza in
> > d/copyright which includes Mr. Powell, or in the upstream stanza for *
> > files. Assuming it's a derivative work, albeit a trivial one, I've decided
> > to lump it in with the debian/* stanza currently.
> 
> I think this is right. 
> 
> > > - symbol files
> > 
> > I cleaned things up with c++filt and removed the offending symbols you
> > mentioned, but this now results in a lintian error--not sure if I should
> > override it or what.
> 
> Actually should be fixed in the source, but I guess for now just mark it
> as "optional" in the symbols file, as this is clearly a private symbol
> causing this... Sorry, I ran out of time also to provide a patch for this..
>  
> > So, hopefully that summarizes what's new in my repo on salsa.d.o. Remember
> > that I remade the repo so a fresh clone will be needed. Crossing my fingers
> > that there won't be much more before this package is ready!
> 
> Unfortuantly without the pristine-tars from debsnap ;-(
> But I think we can add them manually to the branch later.
> 

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Tobias Frost]

On Tue, Mar 27, 2018 at 01:40:28AM -0500, Kurt Kremitzki wrote:
> Ok, I've concluded the next round of work on the package. I recreated the
> repo with `gbp import-dscs --debsnap`. I moved my d/watch and
> +Files-Excluded d/copyright file but ran into issues with missing files
> (e.g. src/Standard file and folders was totally missing) when trying to do
> `gbp import-orig --uscan`. I ended up just importing from the .orig.tar.gz
> and manually cleaning out the problematic copyright files with `git
> filter-branch`. This also required a little patch to remove references to
> the deleted samples in the doc build.

Ok, strange, because Files-Excluded usually works really nicely...
Maybe a bug in mk-origtargz? 

Please note that repackaging requires you to suffix the upstream version
with "+dfsg" (as we've removed files due to DFSG reasons).
I've patched d/changelog and d/watch, MR will follow.

Another MR is asking you to add me as Uploader... (Of course only if
you want) The advantage is that I could have commited all those fixed directly
and have uploaded the package already ;-)) If accepted, please also add me to
the repo so that I can directly commit.

> I also added things to d/copyright per your review recommendations.
> 
> > - d/changelog.gz / changelog.html.gz
> 
> I decided to remove d/changelog.gz & d/changelog.html.gz as well.
> > - d/patches
> >- did you check with upstream whether they would accept the patches,
> >  especially fix-install-dir-references.diff.
> 
> I will work on getting this and the manpage upstreamed.

> > - lintian overrides
> 
> I cleaned these up.
> 
> > - script-not-executeable
> >You writd in the override:# /usr/share/occt/bin/*.sh are reference
> scripts
> >Can you expand what you mean? Are they examples? Are they
> >needed? For what are they needed?
> >One of the scripts references DRAWEXE which is listed
> >in d/non-installed
> 
> Yes, part of Draw's purpose is testing and demonstrating OCCT behavior with
> tweaked dependencies, so these scripts are a reference for environment
> variable tweaks which can be done in a wrapper script around the occt-draw
> binary.
> 
> > - test suite
> >You write in the lintian override that runs only under Windows with a
> >custom occt-draw.. Can you elaborate? What is the difference to the
> >occt-draw we ship?
> 
> To be honest, I will need to iterate on the occt-draw package. The upstream
> devs mainly use Windows so things don't work perfectly out of the box right
> now (although they do work.) Once they do, I will integrate the upstream
> test suite (which itself uses occt-draw) into the Debian package.

OK, IMHO we can work on it after the initial upload too, no need to have this
perfect from the beginning.

> > - occt-doc
> 
> Renamed.
> 
> > - the xpm images...
> >Where are they from? What is the copyright?
> 
> This is a bit of a tricky question--they are definitely derived from
> upstream's logo (see opencascade.com) which is included in the source as
> ./src/DrawResources/OCC_logo.png. These .xpm files first appeared in the 6th
> revision of the first version packaged for Debian, 6.2-6. However, they are
> not explicitly mentioned in the changelog or elsewhere. I believe the files
> were made manually by the former maintainer Adam C. Powell IV by modifying
> the aforementioned source image (which contains the text "OpenCASCADE") by
> cropping most out of the text out and changing filetypes (the .xpm files
> just say 'OCC' with the same font as the upstream file.
> 
> So, I'm not sure if they should go in with the debian/* stanza in
> d/copyright which includes Mr. Powell, or in the upstream stanza for *
> files. Assuming it's a derivative work, albeit a trivial one, I've decided
> to lump it in with the debian/* stanza currently.

I think this is right. 

> > - symbol files
> 
> I cleaned things up with c++filt and removed the offending symbols you
> mentioned, but this now results in a lintian error--not sure if I should
> override it or what.

Actually should be fixed in the source, but I guess for now just mark it
as "optional" in the symbols file, as this is clearly a private symbol
causing this... Sorry, I ran out of time also to provide a patch for this..
 
> So, hopefully that summarizes what's new in my repo on salsa.d.o. Remember
> that I remade the repo so a fresh clone will be needed. Crossing my fingers
> that there won't be much more before this package is ready!

Unfortuantly without the pristine-tars from debsnap ;-(
But I think we can add them manually to the branch later.
(I did so, currently pushing to my forked project @ salsa, but I ran out of time
and could not test it before.. Please Make sure to test if building is still 
working
before merging it!)

--
tobi 

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Kurt Kremitzki]

Ok, I've concluded the next round of work on the package. I recreated 
the repo with `gbp import-dscs --debsnap`. I moved my d/watch and 
+Files-Excluded d/copyright file but ran into issues with missing files 
(e.g. src/Standard file and folders was totally missing) when trying to 
do `gbp import-orig --uscan`. I ended up just importing from the 
.orig.tar.gz and manually cleaning out the problematic copyright files 
with `git filter-branch`. This also required a little patch to remove 
references to the deleted samples in the doc build.


I also added things to d/copyright per your review recommendations.

> - d/changelog.gz / changelog.html.gz

I decided to remove d/changelog.gz & d/changelog.html.gz as well.

> - d/patches
>- did you check with upstream whether they would accept the patches,
>  especially fix-install-dir-references.diff.

I will work on getting this and the manpage upstreamed.

> - lintian overrides

I cleaned these up.

> - script-not-executeable
>You writd in the override:# /usr/share/occt/bin/*.sh are reference 
scripts

>Can you expand what you mean? Are they examples? Are they
>needed? For what are they needed?
>One of the scripts references DRAWEXE which is listed
>in d/non-installed

Yes, part of Draw's purpose is testing and demonstrating OCCT behavior 
with tweaked dependencies, so these scripts are a reference for 
environment variable tweaks which can be done in a wrapper script around 
the occt-draw binary.


> - test suite
>You write in the lintian override that runs only under Windows with a
>custom occt-draw.. Can you elaborate? What is the difference to the
>occt-draw we ship?

To be honest, I will need to iterate on the occt-draw package. The 
upstream devs mainly use Windows so things don't work perfectly out of 
the box right now (although they do work.) Once they do, I will 
integrate the upstream test suite (which itself uses occt-draw) into the 
Debian package.


> - occt-doc

Renamed.

> - the xpm images...
>Where are they from? What is the copyright?

This is a bit of a tricky question--they are definitely derived from 
upstream's logo (see opencascade.com) which is included in the source as 
./src/DrawResources/OCC_logo.png. These .xpm files first appeared in the 
6th revision of the first version packaged for Debian, 6.2-6. However, 
they are not explicitly mentioned in the changelog or elsewhere. I 
believe the files were made manually by the former maintainer Adam C. 
Powell IV by modifying the aforementioned source image (which contains 
the text "OpenCASCADE") by cropping most out of the text out and 
changing filetypes (the .xpm files just say 'OCC' with the same font as 
the upstream file.


So, I'm not sure if they should go in with the debian/* stanza in 
d/copyright which includes Mr. Powell, or in the upstream stanza for * 
files. Assuming it's a derivative work, albeit a trivial one, I've 
decided to lump it in with the debian/* stanza currently.


> - symbol files

I cleaned things up with c++filt and removed the offending symbols you 
mentioned, but this now results in a lintian error--not sure if I should 
override it or what.


So, hopefully that summarizes what's new in my repo on salsa.d.o. 
Remember that I remade the repo so a fresh clone will be needed. 
Crossing my fingers that there won't be much more before this package is 
ready!

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Tobias Frost]

On Fri, Mar 16, 2018 at 09:43:26AM -0500, Kurt Kremitzki wrote:
> 
> 
> On 03/15/2018 04:37 PM, Tobias Frost wrote:
> > On Wed, Mar 14, 2018 at 11:46:28AM +0100, Tobias Frost wrote:
> > > What is still missing from my side is a complete d/copyright review,
> > > but I need a break right now... Will continue later.
> > 
> > Ok, went over the package for a copyright review.
> > One part of the result resulted in a MR [1], but not all could
> > be fixed with that; could be that we need to repack the source
> > and/or ask upstream to fix that in their repo too.
> > 
> > I fear that we have some problematic files:
> > - There are some files from QT examples, but the license header seems to
> >be "old" and unfortunatly not distributeable.
> >Affected are some files in samples/qt/FuncDemo/src, e.g edge.cpp
> >(Later versions of this file seems to be dual-licensed, so likely
> >the remedy is to "update" to a newer version by upstream.
> >But for now, I guess this samples can be removed from the tarball
> >by repacking.
> 
> These were the files I opened an upstream bug about [1] which they've
> already provided a commit for [2], but the bug is tagged for 7.3.0 so I'll
> make a patch to apply it here.

Unfortuantly a patch is not enough, as the problematic sources would
still be in the tarball, which'd be not ok for copyright issues as we
would still distribute them. (actually, we should remove them from
the repository to be safe... git-filter can do that, I guess or 
nuke the repo and regenerate it from scratch. The latter would also 
fix another small issue with the repo: It'd be nice to import all old
versions of Debian packaging from opencascade, using gbp import-dscs --debsnap)

> > - src/NCollection/NCollection_UtfIterator.lxx
> >Is also copyrighted by Unicode Inc. We'll need to have a dedicated
> >section in d/copyright for it
> > - src/OpenGl/glext.h needs also to be documented in d/copyright.
> 
> Roger that.
> 
> > - samples/ios/UIKitSample/UIKitSample/ViewController.* are
> >"copyright ... all rights reserverd.".
> >I guess we need to delete the iOS example from the tarball...
> > - opencascade/samples/mfc/standard/06_Ocaf/src/DebugBrowser.hxx
> >(example, there are others as well) scares me license wise.
> >We will have to delete them (no big loss, as MFC examples are
> >not really useful for us) or ask upstream to clarify.
> > 
> > When we're repackaging anyway, we should also remove all those
> > Windows-Only samples (and their VS project files)
> 
> There are also some .bat files in the top-level directory that are not
> needed. What is the proper procedure for getting rid of them all when
> packaging with git?

I guess we'll need to repack the source, so the removal would be done
while creation of the orig.tar, before importing it into the git repo.
(We need repacking because of the problematic sources; I would not 
bother with the extra files otherwise)

One way would be to use the Files-Excluded: feature of d/copyright,
picked up by uscan or an get-orig-source target for d/rules when you
want to package from a git-commit. (I use the latter for some of my
packages, look at dhewm3 or rbdoom3bfg -- IIRC the latter takes the
list of files to be removed from Files-Excluded for get-orig-source)

> > 
> > Otherwise were some years not accurate (fixed in [1]) and some copyright
> > holders not "verbabitmly" coppied, but else there not much to fix
> > left...
> > 
> > 
> > [1] https://salsa.debian.org/kkremitzki-guest/opencascade/merge_requests/1
> > 
> > --
> >   tobi
> > 
> 
> 
> 1. https://tracker.dev.opencascade.org/view.php?id=29559
> 2. 
> http://git.dev.opencascade.org/gitweb/?p=occt.git;a=commitdiff;h=dd0fae1d0f3ad5faea55e78dee07d735730a2c61;hp=726b5d9e920db065d98ad1b79fc2ab1beb24ba49

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Kurt Kremitzki]

On 03/15/2018 04:37 PM, Tobias Frost wrote:

On Wed, Mar 14, 2018 at 11:46:28AM +0100, Tobias Frost wrote:

What is still missing from my side is a complete d/copyright review,
but I need a break right now... Will continue later.


Ok, went over the package for a copyright review.
One part of the result resulted in a MR [1], but not all could
be fixed with that; could be that we need to repack the source
and/or ask upstream to fix that in their repo too.

I fear that we have some problematic files:
- There are some files from QT examples, but the license header seems to
   be "old" and unfortunatly not distributeable.
   Affected are some files in samples/qt/FuncDemo/src, e.g edge.cpp
   (Later versions of this file seems to be dual-licensed, so likely
   the remedy is to "update" to a newer version by upstream.
   But for now, I guess this samples can be removed from the tarball
   by repacking.


These were the files I opened an upstream bug about [1] which they've 
already provided a commit for [2], but the bug is tagged for 7.3.0 so 
I'll make a patch to apply it here.



- src/NCollection/NCollection_UtfIterator.lxx
   Is also copyrighted by Unicode Inc. We'll need to have a dedicated
   section in d/copyright for it
- src/OpenGl/glext.h needs also to be documented in d/copyright.


Roger that.


- samples/ios/UIKitSample/UIKitSample/ViewController.* are
   "copyright ... all rights reserverd.".
   I guess we need to delete the iOS example from the tarball...
- opencascade/samples/mfc/standard/06_Ocaf/src/DebugBrowser.hxx
   (example, there are others as well) scares me license wise.
   We will have to delete them (no big loss, as MFC examples are
   not really useful for us) or ask upstream to clarify.

When we're repackaging anyway, we should also remove all those
Windows-Only samples (and their VS project files)


There are also some .bat files in the top-level directory that are not 
needed. What is the proper procedure for getting rid of them all when 
packaging with git?




Otherwise were some years not accurate (fixed in [1]) and some copyright
holders not "verbabitmly" coppied, but else there not much to fix
left...


[1] https://salsa.debian.org/kkremitzki-guest/opencascade/merge_requests/1

--
  tobi




1. https://tracker.dev.opencascade.org/view.php?id=29559
2. 
http://git.dev.opencascade.org/gitweb/?p=occt.git;a=commitdiff;h=dd0fae1d0f3ad5faea55e78dee07d735730a2c61;hp=726b5d9e920db065d98ad1b79fc2ab1beb24ba49

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Tobias Frost]

On Wed, Mar 14, 2018 at 11:46:28AM +0100, Tobias Frost wrote:
> What is still missing from my side is a complete d/copyright review,
> but I need a break right now... Will continue later.

Ok, went over the package for a copyright review.
One part of the result resulted in a MR [1], but not all could 
be fixed with that; could be that we need to repack the source
and/or ask upstream to fix that in their repo too.

I fear that we have some problematic files:
- There are some files from QT examples, but the license header seems to
  be "old" and unfortunatly not distributeable.
  Affected are some files in samples/qt/FuncDemo/src, e.g edge.cpp
  (Later versions of this file seems to be dual-licensed, so likely
  the remedy is to "update" to a newer version by upstream.
  But for now, I guess this samples can be removed from the tarball
  by repacking.
- src/NCollection/NCollection_UtfIterator.lxx
  Is also copyrighted by Unicode Inc. We'll need to have a dedicated
  section in d/copyright for it
- src/OpenGl/glext.h needs also to be documented in d/copyright.
- samples/ios/UIKitSample/UIKitSample/ViewController.* are
  "copyright ... all rights reserverd.".
  I guess we need to delete the iOS example from the tarball...
- opencascade/samples/mfc/standard/06_Ocaf/src/DebugBrowser.hxx
  (example, there are others as well) scares me license wise.
  We will have to delete them (no big loss, as MFC examples are
  not really useful for us) or ask upstream to clarify. 

When we're repackaging anyway, we should also remove all those
Windows-Only samples (and their VS project files)

Otherwise were some years not accurate (fixed in [1]) and some copyright
holders not "verbabitmly" coppied, but else there not much to fix
left...


[1] https://salsa.debian.org/kkremitzki-guest/opencascade/merge_requests/1

--
 tobi

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Tobias Frost]

(Anton, there is a question below for you, that's why you are in To:))

On Fri, Mar 09, 2018 at 01:13:54AM -0600, Kurt Kremitzki wrote:
> Control: tags -1 - moreinfo
> 
> Alright, I've addressed all the points brought up by you two (thanks for the
> feedback so far!)
> 
> I have done a thorough check of the licenses, updated d/copyright, and found
> a few problematic Qt Commercial license files, which I reported to upstream.
> [1]
> 
> But, besides the files mentioned in [1], I think everything else is ready
> for review.
> 
> I've verified FreeCAD works well with this, and previously my WIP Netgen 6.2
> package worked well but is currently experiencing issues which I think are
> unrelated. The only other dependent package is deal.ii which I am not
> familiar with and will have to investigate later as part of the phase-out of
> liboce.
> 
> 1. https://www.opencascade.com/content/packaging-again-debian#comment-20398
> 

Hi,

here's a review...(it is not sorted by priority or like)

- d/patches
  - did you check with upstream whether they would accept the patches,
especially fix-install-dir-references.diff.   

- d/rules:
  - override_dh_auto_configure -> the comment refers to an non-existing
  file. Is the ignoring of cmake's return value still needed?
  - see below for dh_doxygen.

- d/control
  - there is a missing B-D on graphviz, otherwise doxygen will fail
  - (bonus area:) It would be great if doxygen could be put to
B-D-indep, so only installed then building the -all packages
I did not check how much effort this is, it is not required for an
upload, but as doxygen has a huge dependency chain, this is nice for
the buildds.
  - for the doxygen cleanup, prefer using dh_doxygen, and you should 
do that in a override for dh_installdocs(1)

- d/changelog
  - the line with dbgsym can go, as those are automatic and did not
require a change in the sources.
  
- d/changelog.gz / changelog.html.gz
  I'm not sure if we should ship those in the debian directory.

  But first the technical things:
  One copy should be enough, do not ship both html and text. (I would prefer
  the text version) Especially, as the html version has problems: it
  sources files from external websites (css, google-analytics) which is a
  breach of privacy and not acceptable for Debian.  Then, if you ship
  them as changelogs, they are not to be installed using *.docs, they
  should be installed using dh_installchangelogs(1), because this tool
  will "do the right thing" and install it into every package, which is
  require by the Policy*.  You should not compress the changelogs in the
  debian directory, the tool mentioned above will do that for you.

  (* I'm omitting here the other possibility to use
  symlinks between packages, which could be used to deuplicate them, IMHO
  not worth the effort)

  Said, that I'm not sure if we should the upstream changelog in the
  debian directory; It will be an easy error to make to miss updating it
  as it will always be manual. If you want to keep it, this would be
  needed to be documented in README.Source, and we have many packages
  without upstream changelogs, so don't let you get nuts by this
  linitian messages ;) It would be better to ask upstream to put the
  changelog into their releases tarballs (which then needs to be NOT
  behind a login, IIRC)

  I leave it up to you whether you want to have the changelog manually
  or if you want to ditch it completly. (if you keep it, the fixes
  described above will be needed)

- lintian overrides
  - usually overrides should only be done if there is a problem with
linitian detecting the correct things, IOW it should not be
used to "silence" things, e.g
If upstream does not support something, just keep the message...
(e.g no-upstream changelog, testsuite-autopkgtest-missing,
debian-watch-does-not-check-gpg-signature)

E.g those overrides should be removed:
- source-contains-autogenerated-visual-c++-file 
- no-upstream-changelog


- spelling-errors-in-binary overrides
  Note hat this is about binaries, not about comments in the source
  code! (as your override comment suggests)
  At least a few of them are legitimate, at least the random spot
  checks I did on. Disclaimer: I did not check context if this would 
  change code behaviour. Needs to be checked with upstream
  I egrep'ed on:
  - tranformations 
  - convertion
  - unkown
  I'd recommend to get in touch with upstream, maybe providing them a
  patch to apply. (This will not be required for the upload, but
  spelling should be fixed at least long term)

- script-not-executeable
  You writd in the override:# /usr/share/occt/bin/*.sh are reference scripts
  Can you expand what you mean? Are they examples? Are they
  needed? For what are they needed?
  One of the scripts references DRAWEXE which is listed
  in d/non-installed

- symbol files
  I think you should run the symbols through c++filt, see 
  dpkg-gensymbols(1) and 

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Tobias Frost]

Hi Kurt, 

On Fri, Mar 09, 2018 at 01:13:54AM -0600, Kurt Kremitzki wrote:
> Control: tags -1 - moreinfo
> 
> Alright, I've addressed all the points brought up by you two (thanks for the
> feedback so far!)
> 
> I have done a thorough check of the licenses, updated d/copyright, and found
> a few problematic Qt Commercial license files, which I reported to upstream.
> [1]
> 
> But, besides the files mentioned in [1], I think everything else is ready
> for review.
> 
> I've verified FreeCAD works well with this, and previously my WIP Netgen 6.2
> package worked well but is currently experiencing issues which I think are
> unrelated. The only other dependent package is deal.ii which I am not
> familiar with and will have to investigate later as part of the phase-out of
> liboce.
> 
> 1. https://www.opencascade.com/content/packaging-again-debian#comment-20398

Just a head-up:
I've just cloned the repo from salsa
I will not be able to look more deeply into it today, but I will take a
look tomorrow 

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Kurt Kremitzki]

Control: tags -1 - moreinfo

Alright, I've addressed all the points brought up by you two (thanks for 
the feedback so far!)


I have done a thorough check of the licenses, updated d/copyright, and 
found a few problematic Qt Commercial license files, which I reported to 
upstream. [1]


But, besides the files mentioned in [1], I think everything else is 
ready for review.


I've verified FreeCAD works well with this, and previously my WIP Netgen 
6.2 package worked well but is currently experiencing issues which I 
think are unrelated. The only other dependent package is deal.ii which I 
am not familiar with and will have to investigate later as part of the 
phase-out of liboce.


1. https://www.opencascade.com/content/packaging-again-debian#comment-20398

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Kurt Kremitzki]

On 03/04/2018 01:11 AM, Anton Gladky wrote:

Then after each release you one need to make a diff over all headers
and create also symbols-files to be sure that the ABI is not broken.

Anton



I've got the symbols files set up now.

By the way, while talking to upstream I've seen that they refer to this 
library as OCCT pretty exclusively [1] (see also Wikipedia [2]). Since 
this will be replacing OpenCASCADE Community Edition (liboce-*), I was 
thinking it would be nice to save everyone some typing by renaming my 
work so far to use libocct-* instead of libopencascade-*. It's kind of 
late in the game to do this, I suppose, but I know at least *my* fingers 
would appreciate it. Thoughts?


1. https://www.opencascade.com/content/packaging-again-debian#comment-20351
2. https://en.wikipedia.org/wiki/Open_Cascade_Technology

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Anton Gladky]

Then after each release you one need to make a diff over all headers
and create also symbols-files to be sure that the ABI is not broken.

Anton


2018-03-04 1:18 GMT+01:00 Kurt Kremitzki :
>
>
> On 03/03/2018 04:12 PM, Anton Gladky wrote:
>>
>> 2018-03-01 5:32 GMT+01:00 Kurt Kremitzki :
>> 
>>>
>>> To summarize:
>>> 1. When the OCC was in Debian previously, and its current form in the
>>> Ubuntu
>>> PPA, we had e.g. libopencascade-foundation-7.1.0
>>> 2. Anton suggested e.g. libopencascade-foundation-7.2
>>> 3. Appendix A of the Debian New Maintainer's Guide [1] suggests
>>> libopencascade-foundation7 is correct
>>> 4. Some packages also use the form libopencascade7-foundation, and this
>>> seems most correct to me
>>>
>>> But which one should be used here? In the case of 4, would the -dev files
>>> just be e.g. libopencascade-foundation-dev? or libopencascade7-*-dev?
>>
>> 
>>
>> Well it depends. If upstream guarantees the stable API/ABI between minor
>> releases, that it is OK to have  libopencascade-foundation-7. But to be on
>> the safe side, I think it is better to use libX,Y.Z-schema.
>>
>> Anton
>>
>
> They do use a major.minor.maintenance version scheme so perhaps the .Z
> portion would be unnecessary.

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Kurt Kremitzki]

On 03/03/2018 04:12 PM, Anton Gladky wrote:

2018-03-01 5:32 GMT+01:00 Kurt Kremitzki :


To summarize:
1. When the OCC was in Debian previously, and its current form in the Ubuntu
PPA, we had e.g. libopencascade-foundation-7.1.0
2. Anton suggested e.g. libopencascade-foundation-7.2
3. Appendix A of the Debian New Maintainer's Guide [1] suggests
libopencascade-foundation7 is correct
4. Some packages also use the form libopencascade7-foundation, and this
seems most correct to me

But which one should be used here? In the case of 4, would the -dev files
just be e.g. libopencascade-foundation-dev? or libopencascade7-*-dev?



Well it depends. If upstream guarantees the stable API/ABI between minor
releases, that it is OK to have  libopencascade-foundation-7. But to be on
the safe side, I think it is better to use libX,Y.Z-schema.

Anton



They do use a major.minor.maintenance version scheme so perhaps the .Z 
portion would be unnecessary.

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Anton Gladky]

2018-03-01 5:32 GMT+01:00 Kurt Kremitzki :

> To summarize:
> 1. When the OCC was in Debian previously, and its current form in the Ubuntu
> PPA, we had e.g. libopencascade-foundation-7.1.0
> 2. Anton suggested e.g. libopencascade-foundation-7.2
> 3. Appendix A of the Debian New Maintainer's Guide [1] suggests
> libopencascade-foundation7 is correct
> 4. Some packages also use the form libopencascade7-foundation, and this
> seems most correct to me
>
> But which one should be used here? In the case of 4, would the -dev files
> just be e.g. libopencascade-foundation-dev? or libopencascade7-*-dev?


Well it depends. If upstream guarantees the stable API/ABI between minor
releases, that it is OK to have  libopencascade-foundation-7. But to be on
the safe side, I think it is better to use libX,Y.Z-schema.

Anton

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Kurt Kremitzki]

On 02/27/2018 12:02 PM, Tobias Frost wrote:

Hi,

just to avoid a dead-lock: you're still working on the package, nothing to
review atm?
Just let us know (and remove the moreinfo tag as sign) when ready for
the next round of review. (I'd like to avoid reviewing when not everything
has been implemented)

--
tobi



Yep, I'm still working on it--I got stuck for quite a while by the issue 
I mentioned in my reply to Anton (the dpkg-shlibdeps errors.) I just 
fixed this a couple of days ago (missing *.substvars files) so hopefully 
I should be able to wrap up the rest of your suggestions soon.


I do have a question regarding the naming of everything, though. 
According to `objdump -p lib*.so | grep SONAME`, where * is any of the 
objects provided by OpenCASCADE 7.2.0, the SONAME is just 7, although 
lib*.so and lib*.so.7 are both just symlinks to lib*.so.7.2.0. This 
creates some uncertainty...


To summarize:
1. When the OCC was in Debian previously, and its current form in the 
Ubuntu PPA, we had e.g. libopencascade-foundation-7.1.0

2. Anton suggested e.g. libopencascade-foundation-7.2
3. Appendix A of the Debian New Maintainer's Guide [1] suggests 
libopencascade-foundation7 is correct
4. Some packages also use the form libopencascade7-foundation, and this 
seems most correct to me


But which one should be used here? In the case of 4, would the -dev 
files just be e.g. libopencascade-foundation-dev? or libopencascade7-*-dev?


I suppose, also, that I should split opencascade-draw into a library and 
non-library part. I updated its description to reflect why it should be 
included:
	"Draw is a command interpreter based on TCL and a graphical system used 
to test and demonstrate Open CASCADE Technology modeling libraries."


Upstream requires bug reports to use it to show reproducibility of 
problems, and it's useful for learning the library, so it does need to 
be included.


Regarding the problematic binary name DRAWEXE, besides just getting rid 
of uppercase I thought perhaps it would be good to just rename it to 
e.g. `opencascade7-draw`. Thoughts?


I'll add the -doc package as well. What exactly would this be named, by 
the way, in light of my version question above? And while I'm at it, 
should I consider a -dbg package?



1. https://www.debian.org/doc/manuals/maint-guide/advanced.en.html#library

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Tobias Frost]

Hi, 

just to avoid a dead-lock: you're still working on the package, nothing to
review atm?
Just let us know (and remove the moreinfo tag as sign) when ready for
the next round of review. (I'd like to avoid reviewing when not everything
has been implemented)

--
tobi

On Thu, Feb 22, 2018 at 04:37:34PM -0600, Kurt Kremitzki wrote:
> I'm still addressing some of the feedback given by you and Tobias, but I
> thought I would post an update.
> 
> On 02/12/2018 05:44 AM, Anton Gladky wrote:
> > Hi Kurt,
> > 
> > Just a short review. I did not test the package. But some
> > stuff should be fixed before it will be uploaded.
> > 
> > As I understand you want to maintain the package under the
> > umbrella of debian science team? If so, please fix some
> > corresponding fields (maintaner etc) in d/control.
> > 
> > =
> > 1. source/include-binaries remove
> > 2. source/options - remove
> > 3. quilt debian/control : quilt - remove
> > 4. VCS - salsa under d/science
> > 5. all lib-packages should be numbered according to its API-version,
> > something like libopencascade-modeling-algorithms7.2
> > 6. Install files of lib-packages should have something like
> > usr/lib/*/libTKMath.so.*, not the particular version
> > 7. --parallel option is not needed with debhelper > 10
> 
> All of the above are done (but not pushed yet.)
> 
> > 8. Not sure about option -DCMAKE_BUILD_TYPE=Release.
> 
> Neither am I--normally when I run eg `ccmake` on the OpenCASCADE source this
> variable is already set to `Release`, but without this I get an error
> suggesting it's being set to `none`. I chalked it up to an idiosyncracy in
> OpenCASCADE.
> 
> > 9. Simplify d/rules. All cp-commands should be replaces by the lines
> > in d/install-files
> 
> Got it--the only one I had a question about was the
> opencascade-draw7.2.desktop file I have in the debian directory. Is it ok
> that I now have something like this in opencascade-draw7.2.install?:
> 
> ../opencascade-draw*.desktop usr/share/applications/
> 
> > 10. Check whether you need mkdir-commands in d/rules
> 
> They were superfluous.
> 
> > 11. override_dh_makeshlibs looks questionable
> 
> Removed.
> 
> > 12. Use dh_missing --fail-missing to be sure that all files are installed.
> 
> Good suggestion, there were about 300 files not being included, most of them
> part of opencascade-draw, which isn't used by FreeCAD and thus I hadn't
> noticed a problem from this.
> 
> However, with all the files included the package now FTBFS with a ton of
> errors like this:
> 
> dpkg-shlibdeps: error: cannot find library libTKBinTObj.so.7 needed by
> debian/opencascade-draw7.2/usr/lib/x86_64-linux-gnu/libTKTObjDRAW.so.7.2.0
> (ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '')
> 
> All the libraries mentioned are files provided by the libopencascade-
> packages, so I tried adding them to opencascade-draw7.2's Depends: but that
> didn't resolve it, so I'm a little stuck.
> 
> > 13. Point the first upload into the experimental.
> 
> Updated.
> 
> > 14. Double-check __all__ the files and their licenses to save the time
> > for FTP-masters.
> 
> Will do once I clean up my current work and before I push.
> 

Re: RFS: opencascade/7.2.0-1 [ITP]

[Kurt Kremitzki]

I'm still addressing some of the feedback given by you and Tobias, but I 
thought I would post an update.


On 02/12/2018 05:44 AM, Anton Gladky wrote:

Hi Kurt,

Just a short review. I did not test the package. But some
stuff should be fixed before it will be uploaded.

As I understand you want to maintain the package under the
umbrella of debian science team? If so, please fix some
corresponding fields (maintaner etc) in d/control.

=
1. source/include-binaries remove
2. source/options - remove
3. quilt debian/control : quilt - remove
4. VCS - salsa under d/science
5. all lib-packages should be numbered according to its API-version,
something like libopencascade-modeling-algorithms7.2
6. Install files of lib-packages should have something like
usr/lib/*/libTKMath.so.*, not the particular version
7. --parallel option is not needed with debhelper > 10


All of the above are done (but not pushed yet.)


8. Not sure about option -DCMAKE_BUILD_TYPE=Release.


Neither am I--normally when I run eg `ccmake` on the OpenCASCADE source 
this variable is already set to `Release`, but without this I get an 
error suggesting it's being set to `none`. I chalked it up to an 
idiosyncracy in OpenCASCADE.



9. Simplify d/rules. All cp-commands should be replaces by the lines
in d/install-files


Got it--the only one I had a question about was the 
opencascade-draw7.2.desktop file I have in the debian directory. Is it 
ok that I now have something like this in opencascade-draw7.2.install?:


../opencascade-draw*.desktop usr/share/applications/


10. Check whether you need mkdir-commands in d/rules


They were superfluous.


11. override_dh_makeshlibs looks questionable


Removed.


12. Use dh_missing --fail-missing to be sure that all files are installed.


Good suggestion, there were about 300 files not being included, most of 
them part of opencascade-draw, which isn't used by FreeCAD and thus I 
hadn't noticed a problem from this.


However, with all the files included the package now FTBFS with a ton of 
errors like this:


dpkg-shlibdeps: error: cannot find library libTKBinTObj.so.7 needed by 
debian/opencascade-draw7.2/usr/lib/x86_64-linux-gnu/libTKTObjDRAW.so.7.2.0 
(ELF format: 'elf64-x86-64' abi: '0201003e'; RPATH: '')


All the libraries mentioned are files provided by the libopencascade- 
packages, so I tried adding them to opencascade-draw7.2's Depends: but 
that didn't resolve it, so I'm a little stuck.



13. Point the first upload into the experimental.


Updated.


14. Double-check __all__ the files and their licenses to save the time
for FTP-masters.


Will do once I clean up my current work and before I push.

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Tobias Frost]

Control: tags -1 moreinfo

Hallo Kurt,

Sorry for the delay, I did not find time for a review up to 
now...

- Please consider the feedback from Anton
- d/compat is 11, but you B-D only on debhelper > 9
- d/rules: --with quilt is not needed, also the B-D on quilt is not.
- c/changelog: The Entry starting with "Close: ..." should be rephrased,
like "Reintroding package (Closes: #xxx) and maybe moved to the top
- All changes compared to the last version in Debian needs to be
  documented, e.g  Document also that you are the new maintainer.
- menu files are depreciated, drop it in favour of the desktop file.
- opencascade-examples.docs contains README.Debian.html, but there is no
  such file.
- d/control: The versioned dependencies on the -dev packages look wrong.
  I guess you need to have e.g "libopencascade-foundation-dev
  (>=${binary:Version}), see Policy 8.5
- there is a lintian override for "binary without manpage" for DRAWEXE,
but there is a debian/DRAWEXE.1 file...
- can you make that name (DRAWEXE) "lower-case", please ?
- "data" should not be installed via open*-example.docs. At least 
  it does not look like docs.
- As anton said: Please use the SO-Name for the packages.
- the opencascade-draw package is not multiarch:same; but it contains
  libaries.. Does it needed to be split in a library and non-libary
  part?

Questions/Remarks:
- what is the purpose of the the CAE test harness? (Is there enought
use case to have it packaged)
- I see that the package could also generate doxygen docs. Is it worth
to package them in a -doc package?
- d/copyright misses at least the Debian part with attribution to the
former maintainers.
- please use wrap-and-sort (to also remove trailing whitespaces)
- many (pedantic and informational) lintian stuff which is easy to fix.
- as you seem to pack from a git repository (as d/copyright says it is
from) you can also remove the generated visual C++ stuff. (if this 
pendantic lintian message is valid)
- would be great if you could tell upstream about the many spelling
errors lintian knows about, or even better, provide them with a
patch to fix them. The patch could be temporarily applied so
that those linitian Is are gone too...
- more lintian stuff -- please ensure that lintian is run when you build
  the package!
N: Processing binary package libopencascade-modeling-algorithms-dev (version 
7.2.0-1, arch amd64) ...
W: libopencascade-modeling-algorithms-dev: description-too-long
- please check if you can enable hardening or if those lintian messages
  are not valid.

Ok, enough for today.. (Its late alreaedy)

Let me know if you need more information about my remarks and when
ready remobe the moreinfo tag.


On Mon, Feb 12, 2018 at 12:44:22PM +0100, Anton Gladky wrote:
> Hi Kurt,
> 
> Just a short review. I did not test the package. But some
> stuff should be fixed before it will be uploaded.
> 
> As I understand you want to maintain the package under the
> umbrella of debian science team? If so, please fix some
> corresponding fields (maintaner etc) in d/control.
> 
> =
> 1. source/include-binaries remove
> 2. source/options - remove
> 3. quilt debian/control : quilt - remove
> 4. VCS - salsa under d/science
> 5. all lib-packages should be numbered according to its API-version,
> something like libopencascade-modeling-algorithms7.2
> 6. Install files of lib-packages should have something like
> usr/lib/*/libTKMath.so.*, not the particular version
> 7. --parallel option is not needed with debhelper > 10
> 8. Not sure about option -DCMAKE_BUILD_TYPE=Release.
> 9. Simplify d/rules. All cp-commands should be replaces by the lines
> in d/install-files
> 10. Check whether you need mkdir-commands in d/rules
> 11. override_dh_makeshlibs looks questionable
> 12. Use dh_missing --fail-missing to be sure that all files are installed.
> 13. Point the first upload into the experimental.
> 14. Double-check __all__ the files and their licenses to save the time
> for FTP-masters.
> =
> 
> Also it is important to check whether the package so-installable with
> oce. Also all dependent on oce packages should be checked, whether
> they can be rebuilt against opencascade. No need to keep two similiar
> packages in the archive.
> 
> PS I am mostly off this week.
> 
> Regards
> 
> 
> 
> Anton
> 
> 
> 2018-02-11 18:36 GMT+01:00 Kurt Kremitzki :
> > Hello all,
> >
> > I am still looking for a sponsor for this package. My current work is at
> > https://salsa.debian.org/kkremitzki-guest/opencascade.
> >
> > I have an experimental FreeCAD 0.17 (as well as Netgen 6.2.1801) built 
> > against
> > this package, and I would greatly like to get them in to Testing, if at all
> > possible, in time for the March 1st import freeze for Ubuntu 18.04, so I 
> > will
> > gladly do whatever work is needed to get these packages into shape if 
> > someone
> > more senior can point me in the right direction.
> >
> > Thanks.
> >
> > On Fri, 05 Jan 2018 05:39:25 -0600 

Re: RFS: opencascade/7.2.0-1 [ITP]

[Anton Gladky]

Hi Kurt,

Just a short review. I did not test the package. But some
stuff should be fixed before it will be uploaded.

As I understand you want to maintain the package under the
umbrella of debian science team? If so, please fix some
corresponding fields (maintaner etc) in d/control.

=
1. source/include-binaries remove
2. source/options - remove
3. quilt debian/control : quilt - remove
4. VCS - salsa under d/science
5. all lib-packages should be numbered according to its API-version,
something like libopencascade-modeling-algorithms7.2
6. Install files of lib-packages should have something like
usr/lib/*/libTKMath.so.*, not the particular version
7. --parallel option is not needed with debhelper > 10
8. Not sure about option -DCMAKE_BUILD_TYPE=Release.
9. Simplify d/rules. All cp-commands should be replaces by the lines
in d/install-files
10. Check whether you need mkdir-commands in d/rules
11. override_dh_makeshlibs looks questionable
12. Use dh_missing --fail-missing to be sure that all files are installed.
13. Point the first upload into the experimental.
14. Double-check __all__ the files and their licenses to save the time
for FTP-masters.
=

Also it is important to check whether the package so-installable with
oce. Also all dependent on oce packages should be checked, whether
they can be rebuilt against opencascade. No need to keep two similiar
packages in the archive.

PS I am mostly off this week.

Regards



Anton


2018-02-11 18:36 GMT+01:00 Kurt Kremitzki :
> Hello all,
>
> I am still looking for a sponsor for this package. My current work is at
> https://salsa.debian.org/kkremitzki-guest/opencascade.
>
> I have an experimental FreeCAD 0.17 (as well as Netgen 6.2.1801) built against
> this package, and I would greatly like to get them in to Testing, if at all
> possible, in time for the March 1st import freeze for Ubuntu 18.04, so I will
> gladly do whatever work is needed to get these packages into shape if someone
> more senior can point me in the right direction.
>
> Thanks.
>
> On Fri, 05 Jan 2018 05:39:25 -0600 kkremit...@gmail.com wrote:
>> Package: sponsorship-requests
>> Severity: wishlist
>>
>> Dear mentors,
>>
>> I am looking for a sponsor for my package "opencascade"
>>
>> * Package name : opencascade
>> Version : 7.2.0-1
>> Upstream Author : Open CASCADE S.A.S.
>> * URL : https://www.opencascade.com
>> * License : LGPL 2.1 with OpenCASCADE exception
>> Section : science
>>
>> It builds those binary packages:
>>
>> libopencascade-data-exchange-7.2.0 - Open CASCADE Technology module
>> for CAD data format interoperabili
>> libopencascade-data-exchange-dev - Open CASCADE Technology module for
>> CAD data format interoperabili
>> libopencascade-foundation-7.2.0 - Open CASCADE Technology module
>> underlying all other OCCT classes
>> libopencascade-foundation-dev - Open CASCADE Technology module
>> underlying all other OCCT classes
>> libopencascade-modeling-algorithms-7.2.0 - Open CASCADE Technology
>> module containing vast range of geometric
>> libopencascade-modeling-algorithms-dev - Open CASCADE Technology
>> module containing vast range of geometric
>> libopencascade-modeling-data-7.2.0 - Open CASCADE Technology data
>> structures for 2D/3D geometric primi
>> libopencascade-modeling-data-dev - Open CASCADE Technology data
>> structures for 2D/3D geometric primi
>> libopencascade-ocaf-7.2.0 - Open CASCADE Technology module offering
>> solutions for application
>> libopencascade-ocaf-dev - Open CASCADE Technology module offering
>> solutions for application
>> libopencascade-visualization-7.2.0 - Open CASCADE Technology module
>> providing complex mechanisms for g
>> libopencascade-visualization-dev - Open CASCADE Technology module
>> providing complex mechanisms for g
>> opencascade-draw - Open CASCADE Technology CAE test harness
>> opencascade-misc - Open CASCADE Technology CAE platform shared library
>> miscellaneous
>>
>> To access further information about this package, please visit the
>> following URL:
>>
>> https://mentors.debian.net/package/opencascade
>>
>>
>> Alternatively, one can download the package with dget using this
>> command:
>>
>> dget -x https://mentors.debian.net/debian/pool/main/o/opencascade/ope
>> ncascade_7.2.0-1.dsc
>>
>> More information about opencascade can be obtained from https://www.ope
>> ncascade.com/.
>>
>>
>

Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]

[Sebastian Kuzminsky]

On 02/11/2018 10:36 AM, Kurt Kremitzki wrote:
> Hello all,
> 
> I am still looking for a sponsor for this package. My current work is at
> https://salsa.debian.org/kkremitzki-guest/opencascade.
> 
> I have an experimental FreeCAD 0.17 (as well as Netgen 6.2.1801) built against
> this package, and I would greatly like to get them in to Testing, if at all
> possible, in time for the March 1st import freeze for Ubuntu 18.04, so I will
> gladly do whatever work is needed to get these packages into shape if someone
> more senior can point me in the right direction.

I'm not a Developer or Maintainer  (just a user with aspirations at this
point) so I can't help you with sponsorship.

But I'm a FreeCAD user, and have been for several years, and I would be
super happy to see it in Debian.  It would be a strong enabler for folks
who into open-source personal fabrication.


-- 
Sebastian Kuzminsky

Re: RFS: opencascade/7.2.0-1 [ITP]

[Kurt Kremitzki]

Hello all,

I am still looking for a sponsor for this package. My current work is at
https://salsa.debian.org/kkremitzki-guest/opencascade.

I have an experimental FreeCAD 0.17 (as well as Netgen 6.2.1801) built against
this package, and I would greatly like to get them in to Testing, if at all
possible, in time for the March 1st import freeze for Ubuntu 18.04, so I will
gladly do whatever work is needed to get these packages into shape if someone
more senior can point me in the right direction.

Thanks.

On Fri, 05 Jan 2018 05:39:25 -0600 kkremit...@gmail.com wrote:
> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors,
>
> I am looking for a sponsor for my package "opencascade"
>
> * Package name : opencascade
> Version : 7.2.0-1
> Upstream Author : Open CASCADE S.A.S.
> * URL : https://www.opencascade.com
> * License : LGPL 2.1 with OpenCASCADE exception
> Section : science
>
> It builds those binary packages:
>
> libopencascade-data-exchange-7.2.0 - Open CASCADE Technology module
> for CAD data format interoperabili
> libopencascade-data-exchange-dev - Open CASCADE Technology module for
> CAD data format interoperabili
> libopencascade-foundation-7.2.0 - Open CASCADE Technology module
> underlying all other OCCT classes
> libopencascade-foundation-dev - Open CASCADE Technology module
> underlying all other OCCT classes
> libopencascade-modeling-algorithms-7.2.0 - Open CASCADE Technology
> module containing vast range of geometric
> libopencascade-modeling-algorithms-dev - Open CASCADE Technology
> module containing vast range of geometric
> libopencascade-modeling-data-7.2.0 - Open CASCADE Technology data
> structures for 2D/3D geometric primi
> libopencascade-modeling-data-dev - Open CASCADE Technology data
> structures for 2D/3D geometric primi
> libopencascade-ocaf-7.2.0 - Open CASCADE Technology module offering
> solutions for application
> libopencascade-ocaf-dev - Open CASCADE Technology module offering
> solutions for application
> libopencascade-visualization-7.2.0 - Open CASCADE Technology module
> providing complex mechanisms for g
> libopencascade-visualization-dev - Open CASCADE Technology module
> providing complex mechanisms for g
> opencascade-draw - Open CASCADE Technology CAE test harness
> opencascade-misc - Open CASCADE Technology CAE platform shared library
> miscellaneous
>
> To access further information about this package, please visit the
> following URL:
>
> https://mentors.debian.net/package/opencascade
>
>
> Alternatively, one can download the package with dget using this
> command:
>
> dget -x https://mentors.debian.net/debian/pool/main/o/opencascade/ope
> ncascade_7.2.0-1.dsc
>
> More information about opencascade can be obtained from https://www.ope
> ncascade.com/.
>
>