get pivy for Python3 and Debian Buster

Having trouble installing or compiling FreeCAD? Get help here.
looo
Posts: 2965
Joined: Mon Nov 11, 2013 5:29 pm

Re: get pivy for Python3 and Debian Buster

Postby looo » Tue Jan 08, 2019 9:14 am

mlampert wrote:
Mon Jan 07, 2019 11:27 pm
One question though, it seems pivy requires numpy
I guess we can remove this dependency. It was introduced by accident. But as @kkremitzki said, FreeCAD depends on it anyway.

I have one question regarding debian-packages:
Why does debian build packages by copying the source?
please help with my conda-packaging efforts: https://liberapay.com/looooo/
User avatar
bernd
Posts: 8488
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: get pivy for Python3 and Debian Buster

Postby bernd » Tue Jan 08, 2019 12:06 pm

but FreeCAD compiles and runs without matplotlib too. Cmake says only plotmodule does not work. But I do not know if any other WB would not work. FEM uses numpy in rare tools. More or less utilities, which mean FEM works without numpy too.
reox
Posts: 666
Joined: Sat Aug 13, 2016 10:06 am
Contact:

Re: get pivy for Python3 and Debian Buster

Postby reox » Thu Jan 10, 2019 7:46 pm

looo wrote:
Tue Jan 08, 2019 9:14 am
I have one question regarding debian-packages:
Why does debian build packages by copying the source?
what do you mean? You can build a debian package by having a folder with the debian folder in it and the upstream tarball. So there is no need to copy it somewhere. But usually the upstream source is put into a repository, which makes things easier for example by using git-buildpackage.
The reasoning behind this is IMO to have the debian folder with the corresponding upstream version at a place where it does not change.
User avatar
kkremitzki
Posts: 1796
Joined: Thu Mar 03, 2016 9:52 pm
Location: Texas

Re: get pivy for Python3 and Debian Buster

Postby kkremitzki » Thu Jan 10, 2019 8:29 pm

bernd wrote:
Tue Jan 08, 2019 12:06 pm
but FreeCAD compiles and runs without matplotlib too. Cmake says only plotmodule does not work. But I do not know if any other WB would not work. FEM uses numpy in rare tools. More or less utilities, which mean FEM works without numpy too.
It's just a runtime dependency, it's used in Arch, Part Design, Path, and FEM as you know.
Like my FreeCAD work? I'd appreciate any level of support via Patreon, Liberapay, or PayPal! Read more about what I do at my blog.
User avatar
bernd
Posts: 8488
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: get pivy for Python3 and Debian Buster

Postby bernd » Fri Jan 11, 2019 9:22 am

kkremitzki wrote:
Thu Jan 10, 2019 8:29 pm
bernd wrote:
Tue Jan 08, 2019 12:06 pm
but FreeCAD compiles and runs without matplotlib too. Cmake says only plotmodule does not work. But I do not know if any other WB would not work. FEM uses numpy in rare tools. More or less utilities, which mean FEM works without numpy too.
It's just a runtime dependency, it's used in Arch, Part Design, Path, and FEM as you know.
Ahh yes.

Just realized same with pivy. It is a runtime dependency. FreeCAD does compile without pivy, but at runtime will run into trouble without pivy
looo
Posts: 2965
Joined: Mon Nov 11, 2013 5:29 pm

Re: get pivy for Python3 and Debian Buster

Postby looo » Fri Jan 11, 2019 9:25 am

reox wrote:
Thu Jan 10, 2019 7:46 pm
The reasoning behind this is IMO to have the debian folder with the corresponding upstream version at a place where it does not change.
Ok. I am not sure how much sense this makes. How to be sure the same sources are used?
please help with my conda-packaging efforts: https://liberapay.com/looooo/
reox
Posts: 666
Joined: Sat Aug 13, 2016 10:06 am
Contact:

Re: get pivy for Python3 and Debian Buster

Postby reox » Fri Jan 11, 2019 11:26 am

looo wrote:
Fri Jan 11, 2019 9:25 am
reox wrote:
Thu Jan 10, 2019 7:46 pm
The reasoning behind this is IMO to have the debian folder with the corresponding upstream version at a place where it does not change.
Ok. I am not sure how much sense this makes. How to be sure the same sources are used?
The usual approach for this is, you get the tarball from upstream and build it. So if upstream gives you the wrong version, it is the fault of upstream not the debian package.
When using gbp, you use the tags provided by upstream (or you can also import tarballs form upstream). Thus, if the tags are wrong, it is again the fault of upstream.

The version tracking is done via the debian/changelog file. dpkg-buildpackage checks if the upstream version matches the declared version in the changelog file and will warn you if it does not.

Upstream is required to produce correct versions, where no version can have multiple source trees. If upstream does that, you have problems with building on any distribution.
So that is also the reason why building from master needs some fake versioning, otherwise you can not specify which master build is the newest one.