-
-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatic creation of .deb packages #72
Conversation
The following is a good read regarding the license compatibility: https://www.gnu.org/licenses/license-compatibility.html CalculiX is licensed under the GPLv2 license, which requires any redistributed versions to be licensed under the same license. So, we have an issue. |
Can't we simply have the adapter be GPL2 instead of GPL3 ? That looks like the best way to remove headaches to me. Unless we can't because we'd need the authorization of all people who contributed to the adapter or something like this ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very good so far! I already commented on tiny details, thus the amount of comments. Let's have another review iteration later, as now I only looked at the code.
Where did it hang with 21.04? Did you get any error messages?
We would then also need to add this information to the adapter documentation.
Can we just merge this change everywhere needed, please? :-) This is anyway what we have currently documented.
We need a versioning scheme here and we should put some thought on it. Since the adapter works with only specific versions of CalculiX, but any preCICE v2.x, I would suggest something like
You can generate such a hash very easily, with
Let's forget about PaStiX in the Debian package right now. This PR is already a significant step ahead.
We should eventually also start making releases here, similarly to other adapters. This would be much better than the current branching model.
As we already discussed on Gitter, maybe this is indeed what we should do. Reaching out to all contributors should be still doable. But let's make sure first that this is the right thing to do. |
Co-authored-by: Gerasimos Chourdakis <chourdak@in.tum.de>
Co-authored-by: Gerasimos Chourdakis <chourdak@in.tum.de>
Co-authored-by: Gerasimos Chourdakis <chourdak@in.tum.de>
Co-authored-by: Gerasimos Chourdakis <chourdak@in.tum.de>
Co-authored-by: Gerasimos Chourdakis <chourdak@in.tum.de>
Co-authored-by: Gerasimos Chourdakis <chourdak@in.tum.de>
No errors, just infinite waiting. Maybe they have already switched everything to 21.10 ?
Yes, I was thinking of waiting for the official release.
I'm all in favor, but I'd prefer someone more experienced handled that. (Not really changing the makefile, but 2.17 branch is already 45 commits behind master, so that's slightly messy)
By the way, I'm not 100% sure what preCICE version to use for the build. If we compile with 2.3 but use only features from <= 2.2, would the adapter work on a computer with preCICE 2.2 installed, for instance ? More generally, should we always build with the most recent version of preCICE 2.x ?
So we simply need to provide the output of sha256sum so that people can check ?
That seems very reasonable to me.
Even with clean releases, there's still the issue of having different code for each CalculiX version no ? |
Co-authored-by: Gerasimos Chourdakis <chourdak@in.tum.de>
21.04 is still supported (and I am still using it).
We should build/test with the latest version of preCICE. But, because we are linking to a shared library, any preCICE v2.x version will work. (there was even an AdvProg slide on lecture "Build time" regarding exactly this example 😅 )
Exactly. Unless linter suggests more steps.
Yes. But we should have a clear policy on which CalculiX versions we support. I would vote to only support the latest one. |
Weird, I should give it another try at some point.
Woops :D
As far as I remember it didn't complain about the lack of sha256, I was more thinking about how we just publish keys every time there's a new preCICE release.
Probably a good idea to add support for 2.18 before dropping the others then ! |
Slightly unrelated, but following this precice/precice#1132 (comment) I realized it was probably interesting (in the long run) to modify Makefiles to provice a |
I am not sure if investing on Make would be the right thing to do in that direction. Migrating to CMake could open such possibilities, but I guess it would be complicated to do it in the downstream project (adapter) without already having support from the upstream (CalculiX + dependencies). |
Regarding licensing, this is the license of CalculiX, as found in the
Since we have the From the FSF article that @fsimonis posted above:
The correct license of In our case, we maintain the GPLv2 notice in |
The Debian package is now named "calculix-precice2" and not "calculix-precice". The Github Action workflow was modified to allow more flexible updates. There is now a variable which helps reduce the number of things to change to upgrade CalculiX version or package version.
I did some improvements :
I'm undrafting the PR, though I also plan some adjustements to |
Co-authored-by: Gerasimos Chourdakis <chourdak@in.tum.de>
packaging/calculix-precice2_2.17-1_amd64/usr/share/doc/calculix-precice2/copyright
Outdated
Show resolved
Hide resolved
Removed the Author description (see https://linux.die.net/man/7/man-pages) and added a link to the Github issues for reporting bugs
Co-authored-by: Gerasimos Chourdakis <chourdak@in.tum.de>
@MakisH @KyleDavisSA I don't have the rights to fix the conflict, but it's a trivial one. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Fixed the conflict.
- I tried downloading the packages for 20.04 and doing some simple checks. The
sha256sum
seems to be correct. Lintian is happy apart from the one change suggested here. - I have not tried installing the generated packages. Maybe try to install preCICE and the adapter from Debian packages in a clean Ubuntu 20.04 VM before merging?
- The rest looks good!
Lintian-conforming: Don't start with an article. Co-authored-by: Gerasimos Chourdakis <chourdak@in.tum.de>
It works on my working Ubuntu VM, worked on my Mint VM before this VM died, and on a clean WSL Ubuntu 20.04. I think tests are conclusive :) |
Nice! Please don't forget to also add this to the adapter documentation. |
Indeed, but we should probably start making releases first. |
This adds a Github Actions workflow that download dependencies and Calculix source code, builds the adapter (the "regular" version, without PaStiX), creates a .deb package and uploads it as artifact. (It can then be downloaded from Github on the workflow run)
Currently runs on Ubuntu 18.04 and 20.04 (The 2 latest LTS versions). It should work on other versions but I couldn't get Github to run on 21.04, and it stalled the entire workflow forever so I removed it.
Usage : download the corresponding artifact and
sudo apt install [packagefile]
. This requires an installation ofpreCICE
through the provided packages (i.e. this package won't work with a custom build of preCICE, as it explicitly requires the libprecice package)The makefile has been updated to be similar (just replaced 2.16 by 2.17 everywhere) to the one of the master branch instead of the current v2.17, which is outdated and painful to use, especially within scripts.
Things yet to do :
packaging/manpage.md
FIXED : CalculiX says "distribute with GPL2 or above" which solves the problem. GPL3 it is.
FIX : Package indicates 2.0.0 is enough.
Things to do or think about in the long run :