get pivy for Python3 and Debian Buster

Having trouble installing or compiling FreeCAD? Get help here.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
looo
Veteran
Posts: 3941
Joined: Mon Nov 11, 2013 5:29 pm

Re: get pivy for Python3 and Debian Buster

Post by looo »

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?
User avatar
bernd
Veteran
Posts: 12849
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland
Contact:

Re: get pivy for Python3 and Debian Buster

Post by bernd »

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: 929
Joined: Sat Aug 13, 2016 10:06 am
Contact:

Re: get pivy for Python3 and Debian Buster

Post by reox »

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
Veteran
Posts: 2511
Joined: Thu Mar 03, 2016 9:52 pm
Location: Illinois

Re: get pivy for Python3 and Debian Buster

Post by kkremitzki »

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
Veteran
Posts: 12849
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland
Contact:

Re: get pivy for Python3 and Debian Buster

Post by bernd »

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
User avatar
looo
Veteran
Posts: 3941
Joined: Mon Nov 11, 2013 5:29 pm

Re: get pivy for Python3 and Debian Buster

Post by looo »

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?
reox
Posts: 929
Joined: Sat Aug 13, 2016 10:06 am
Contact:

Re: get pivy for Python3 and Debian Buster

Post by reox »

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.
Post Reply