Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
(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 https://wi
Re: Bug#886399: RFS: opencascade/7.2.0-1 [ITP]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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 kkremit...@gmail.com wrote: > >> Packag
Re: RFS: opencascade/7.2.0-1 [ITP]
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]
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]
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/. > >