looo wrote: ↑Tue Jun 13, 2017 6:43 am
I am not sure if it is possible to use one debianized dir for both. At least I have added dependencies for py2 and py3. Maybe launchpad builds for both directly? Locally I haven't figured out to build with python2...
The python-pivy package should likely offer Python 2 build of Pivy. And as the version will be higher the distribution provided python-pivy package gets upgraded when PPA is added. The python3-pivy package is a new package and it provides Python 3 build of Pivy.
looo wrote: ↑Tue Jun 13, 2017 6:43 am
But now I am quite sure, the only important thing is the debianized directory + the dsc file. (quite sure, but still confused)
Providing the source package is what is important yes. Everything else we did (building locally) was just about making sure it can be build.
looo wrote: ↑Tue Jun 13, 2017 6:43 am
And called debuild -S -sa
Here is where you will in addition sign the source package.
looo wrote: ↑Tue Jun 13, 2017 10:46 am
But how to support also the other versions of ubuntu? Do I need to create a debianized-source-archive for every release of ubuntu?
You need to provide source package for each release. Note that for Ubuntu 16.04 and up you will need to change Build-Depends section to satisfy dependencies compared to Ubuntu 14.04:
Did you change the "Destination series:" and "Rebuild the copied sources"
exactly what I did.
also with "proper" naming (ppa1 suffix) there is still the same issue. Some packages are suffixed with eg.: "ubuntu14.04...". Maybe I have to do the same?
looo wrote: ↑Tue Jun 13, 2017 1:27 pm
exactly what I did.
also with "proper" naming (ppa1 suffix) there is still the same issue. Some packages are suffixed with eg.: "ubuntu14.04...". Maybe I have to do the same?
OK it looks like this worked for eigen3 because it's headers only. So I think you will need to upload a new source package for each series. The link to your PPA is broken so I can't download the package and look at the debian control file. Usually only the changelog needs to be changed between the different series. But if package names are different or you used versions for the dependencies this may not be the case. The package really needs to be python3-pivy though or it will conflict with the default python-pivy (ie py27) package.
Great work on this! Now you enjoy the hair pulling delight of Launchpad
sgrogan wrote: ↑Tue Jun 13, 2017 1:43 pm
Now you enjoy the hair pulling delight of Launchpad
To be honest the discussion started only a few days back and we are "nearly done" (hopefully ). Try that on macOS or Windows.
@looo
You will need to bump the minor version number or use different identifier as the same source package can't exist for two Ubuntu releases. Some examples:
ok, so I will create them locally and upload 2 package (py2, py3) for every distro (trusty, xenial, zesty) (all in all 6 packages). The question is, can we move these packages to the freecad ppa?
also there was reported an error on trusty amd64.
sgrogan wrote:The package really needs to be python3-pivy though or it will conflict with the default python-pivy (ie py27) package.
Therefore you can add another PPA to satisfy some dependencies. But we shouldn't just reuse some random PPAs for creating official FreeCAD PPA builds. Therefore maybe better approach would be to upload source package for swig from backports as @sgrogan suggested and build the swig package on PPA to test that for Trusty. I don't know if you can enable backports on PPA. But doing that (providing swig 3 for Trusty from PPA) could mess with user system and such things need to be investigated to not affect other packages provided by default that use swig. If it's a small and localized thing it makes sense. If it affects other packages on a larger scale it shouldn't be done.
Also note, that swig3.0 is only a build-dependency. So we could enable backports on the ppa where we build pivy but not on the freecad-ppa where we copy the debs afterwards. I will try later if enabling the backports is working.
I can test your PPA over the weekend if you will manage to finish the work for Ubuntu 16.04. And i guess in VirtualBox for Ubuntu 14.04 if you will add swig package to it. After all that will work without detected issues we can discuss further what makes the most sense. I don't see the need to rush this on daily PPA as we can figure out all the details by using your personal PPA directly. As for any additional help you might need just ask.
P.S. Thinking further should daily PPA switch to Python 3 by default? Would having temporary freecad-experimetal PPA for the purpose of Python3/Qt5 migration make sense? As there is PPA available for PySide2 we can reuse. But currently that would only work on Ubuntu 16.04 and maybe on Ubuntu 14.04. And Python3/Qt5 combination doesn't builds successfully ATM. But i guess it would be good if it would and maybe if having build logs on why it fails successful build could happen a bit sooner. And after to investigate if AppImage could be made from such PPA.