They should work as I tested the patches against clean source on Linux.NormandC wrote:Thanks!
I think I'll try with the clean netgen source as you're doing, and apply the patches.
[Ubuntu Daily PPA] Transitioning to OCCT7, VTK7...
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: [Ubuntu Daily PPA] Transitioning to OCCT7, VTK7...
Re: [Ubuntu Daily PPA] Transitioning to OCCT7, VTK7...
Thanks for the links! (second one is missing the hyphen in homebrew-freecad BTW)
As I wrote before, we need to document the different packaging processes in the wiki. I know it represents a lot of work, but I believe it's more sustainable that way - easier to update because you don't have to hunt down tens of topics spanning years and hundreds of replies.
I was thinking about a Packaging portal that would set the context then link to the different packaging projects, each with its own wiki page or portal:
Packaging
As I wrote before, we need to document the different packaging processes in the wiki. I know it represents a lot of work, but I believe it's more sustainable that way - easier to update because you don't have to hunt down tens of topics spanning years and hundreds of replies.
I was thinking about a Packaging portal that would set the context then link to the different packaging projects, each with its own wiki page or portal:
Packaging
- PackagingOnLinux
- Ubuntu PPA
- AppImage
- Snap packages?
- ...
- PackagingOnWindows
- PackagingOnMac
- ???
Re: [Ubuntu Daily PPA] Transitioning to OCCT7, VTK7...
OCCT7-packaging: master is updated
https://git.launchpad.net/~freecad-main ... g?h=master
I found that the debian/copyright file was completely empty... I had to fix it (I salvaged and modified the one from the liboce package)
sgrogan, I'll let you update the gdo35 branch, but it's not a pressing issue.
I created a build recipe from the packaging branch and the OCCT7.1 branch, but as I wanted to be a good Launchpad citizen, I followed the recommendation in the Create a new source recipe page:
Pretty sure it's the debian/source/format 3.0 (quilt) problem I mentioned.
[1] https://help.launchpad.net/Packaging/So ... ingStarted
[2] http://packaging.ubuntu.com/html/patche ... -use-quilt
https://git.launchpad.net/~freecad-main ... g?h=master
I found that the debian/copyright file was completely empty... I had to fix it (I salvaged and modified the one from the liboce package)
sgrogan, I'll let you update the gdo35 branch, but it's not a pressing issue.
I created a build recipe from the packaging branch and the OCCT7.1 branch, but as I wanted to be a good Launchpad citizen, I followed the recommendation in the Create a new source recipe page:
So I learned yet another Debian packaging tool! [1]Launchpad wrote:We strongly recommend that you test your recipe locally first.
- Saved the recipe in a text file named OCCT7.recipe
- Installed git-build-recipe package
- Launched build of recipe with
Code: Select all
git-build-recipe --allow-fallback-to-native OCCT7.recipe
Code: Select all
W: opencascade source: native-package-with-dash-version
W: opencascade source: debhelper-but-no-misc-depends opencascade-misc
W: opencascade source: vcs-field-uses-not-recommended-uri-format vcs-git git+ssh://git.launchpad.net/~freecad-maintainers/+git/OCCT7
W: opencascade source: quilt-build-dep-but-no-series-file
W: opencascade source: patch-system-but-no-source-readme
Finished running lintian
- The source package is not uploaded, so format needs to be set to 1.0 just like in the gitpackaging branch.
- [Assumption] Doing so makes it incompatible with the quilt patching system.
I hoped to get this over with before the end of the weekend, but I think I'm going to call this a night...Ubuntu Packaging Guide wrote:Older packages using source format 1.0 will need to explicitly use Quilt, usually by including a makefile into debian/rules.
[1] https://help.launchpad.net/Packaging/So ... ingStarted
[2] http://packaging.ubuntu.com/html/patche ... -use-quilt
Re: [Ubuntu Daily PPA] Transitioning to OCCT7, VTK7...
I'm just not built to let goNormandC wrote:I think I'm going to call this a night...
Found the reference, seems simple enough:
Debian New Maintainers' Guide | Chapter 4. Required files under the debian directory https://www.debian.org/doc/manuals/main ... eq.en.html4.4.3. Customization of rules file
There are many ways to customize the rules file created with the new dh command.
The dh $@ command can be customized as follows:
(...)
- Add support for the dh_quilt_patch and dh_quilt_unpatch commands.
- Include the quilt package in Build-Depends.
- Use dh $@ --with quilt instead.
- This applies and un-applies patches to the upstream source from files in the debian/patches directory for a source package in the 1.0 format.
- This is not needed if you use the new 3.0 (quilt) source package format.
Fix already committed to the OCCT7-packaging branch.
EDIT: it seems I requested a build on the occt7-release recipe 2 hours ago in my own PPA
How the heck did it succeed?
https://launchpad.net/~gemnoc/+archive/ubuntu/ppa (I only built xenial packages)
Re: [Ubuntu Daily PPA] Transitioning to OCCT7, VTK7...
The following FreeCAD info says (almost) all
OS: Ubuntu 16.04.2 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.10426 (Git)
Build type: Unknown
Branch: master
Hash: 6612e7c753920098440947dd48cbf1ab19e2dc72
Python version: 2.7.12
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.1.0
FreeCAD built from master based on my libopencascade debian packages. Geometry creation seems to be working fine. But I had to disable all the workbenches that rely on MESH/SMESH because I didn't install netgen-headers nor vtk.
Next is figuring out how to package a patched netgen-5.3.1...
sgrogan, not building MESH and MESHPART means a lot of workbenches can't be built, including Arch, Draft, OpenSCAD, FEM. This is unacceptable for the daily PPA. Considering this, there is actually no rush to build the libopencascade packages on the daily PPA. Unless you think there would be a way to get netgen 4.9.13/vtk6/med 3.0.6 working with OCCT7.1 ? Does SMESH need netgen/nglib? It's still all fuzzy to me.
OS: Ubuntu 16.04.2 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.10426 (Git)
Build type: Unknown
Branch: master
Hash: 6612e7c753920098440947dd48cbf1ab19e2dc72
Python version: 2.7.12
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.1.0
FreeCAD built from master based on my libopencascade debian packages. Geometry creation seems to be working fine. But I had to disable all the workbenches that rely on MESH/SMESH because I didn't install netgen-headers nor vtk.
Next is figuring out how to package a patched netgen-5.3.1...
sgrogan, not building MESH and MESHPART means a lot of workbenches can't be built, including Arch, Draft, OpenSCAD, FEM. This is unacceptable for the daily PPA. Considering this, there is actually no rush to build the libopencascade packages on the daily PPA. Unless you think there would be a way to get netgen 4.9.13/vtk6/med 3.0.6 working with OCCT7.1 ? Does SMESH need netgen/nglib? It's still all fuzzy to me.
Re: [Ubuntu Daily PPA] Transitioning to OCCT7, VTK7...
Interestingly, I found on the Debian git repository for the netgen package a debian/5.1.dfsg tag for building a netgen 5.1 package. It dates back 3 years ago. Why the heck haven't they completed the work?
I'll try to see if it can be of use with 5.3.1.
https://anonscm.debian.org/cgit/debian- ... n/5.1.dfsg
I'll try to see if it can be of use with 5.3.1.
https://anonscm.debian.org/cgit/debian- ... n/5.1.dfsg
Re: [Ubuntu Daily PPA] Transitioning to OCCT7, VTK7...
No certainly you aren'tNormandC wrote:I'm just not built to let go
I am sure you will find a solution for netgen
Re: [Ubuntu Daily PPA] Transitioning to OCCT7, VTK7...
If you install VTK then only BUILD_FEM_NETGEN needs to disabled. The standard Ubuntu VTK should work fine. All workbenches will build. Only the netgen support in Mesh and Fem WB's will be disabled but everything else works. This is how the Win daily's are being packaged, except with OCCT 7.0NormandC wrote:sgrogan, not building MESH and MESHPART means a lot of workbenches can't be built, including Arch, Draft, OpenSCAD, FEM. This is unacceptable for the daily PPA. Considering this, there is actually no rush to build the libopencascade packages on the daily PPA. Unless you think there would be a way to get netgen 4.9.13/vtk6/med 3.0.6 working with OCCT7.1 ? Does SMESH need netgen/nglib? It's still all fuzzy to me
"fight the good fight"
Re: [Ubuntu Daily PPA] Transitioning to OCCT7, VTK7...
OS: Ubuntu 16.04.2 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.10235 +20 (Git)
Build type: Debug
Branch: bspline_stage1b_2017_thirddeliverable
Hash: fb907b9cb0d6a884519949045f9f423fc302f6b4
Python version: 2.7.12
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.1.0
Thank you guys for your work.
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.10235 +20 (Git)
Build type: Debug
Branch: bspline_stage1b_2017_thirddeliverable
Hash: fb907b9cb0d6a884519949045f9f423fc302f6b4
Python version: 2.7.12
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.1.0
Thank you guys for your work.
I am happy you did it. You made me update from Trusty to Xenial, but now I can program againNormandC wrote:EDIT: it seems I requested a build on the occt7-release recipe 2 hours ago in my own PPA
How the heck did it succeed?
https://launchpad.net/~gemnoc/+archive/ubuntu/ppa (I only built xenial packages)
I have it this way, I do not compile NETGEN, but I do compile the others.sgrogan wrote:If you install VTK then only BUILD_FEM_NETGEN needs to disabled. The standard Ubuntu VTK should work fine. All workbenches will build. Only the netgen support in Mesh and Fem WB's will be disabled but everything else works. This is how the Win daily's are being packaged, except with OCCT 7.0
Re: [Ubuntu Daily PPA] Transitioning to OCCT7, VTK7...
@NormandC, abdullah is your first alpha tester and a good one indeed!abdullah wrote:I am happy you did it. You made me update from Trusty to Xenial, but now I can program again
"fight the good fight"