Skip to content
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

Packaging for Debian/Ubuntu #2003

Open
kkremitzki opened this Issue Jan 19, 2019 · 10 comments

Comments

Projects
None yet
3 participants
@kkremitzki
Copy link

kkremitzki commented Jan 19, 2019

Hi, I'm a maintainer of several related softwares as part of the Debian Science Team, and I think it would be great to get libMesh packaged for Debian--once it's in the Debian archives, it'll also be available in subsequent versions of Ubuntu, as well.

I'm able to build the current master on Debian Unstable with ./configure --without-dtk and on the v1.3.1 tag I can build normally without needing to specify any flags, so that's good. (I saw the issue that necessitated the --without flag also reported in #1849, BTW.)

Anyway, I just wanted to create this issue to open a line of communication on the topic and to let people know that I am going to begin packaging libMesh. Once I have the packaging ready I can provide an Ubuntu PPA for any interested testers (I'll probably just re-use the FreeCAD Community Extras PPA) but there will be an additional wait in the Debian NEW queue. Since the next release of Debian, Debian 10, has just entered its first freeze phase, it's unlikely libMesh will make it in on time, unfortunately.

@jwpeterson

This comment has been minimized.

Copy link
Member

jwpeterson commented Jan 20, 2019

Sounds great, thanks for letting us know about your plans.

I'm not exactly sure what is causing the issue in #1849. I don't personally build with Trilinos enabled very often, but in our DTK configure test (m4/trilinos.m4) we currently only look for the file DataTransferKit_config.hpp. If that's present, we assume that DTK_MeshContainer.hpp is going to be there as well. It's possible the names of headers have been changed since this code was developed, but a simple fix might be to search specifically for the header file in question and disable DTK if it's not found.

It would be relatively easy for me to push a patch adding such a test if you would be willing to give it a try. By the way, what Trilinos packages do you have installed when you get this particular error in Debian? I will try to reproduce it in Ubuntu 18.04.

jwpeterson added a commit to jwpeterson/libmesh that referenced this issue Jan 20, 2019

Fix bugs in DTK configure test.
* We were missing an "x" character in a string comparison test,
  causing the comparison to always be true.  This came up in issues
  libMesh#1849, libMesh#2003
* There was also an uninitialized variable which didn't print in the
  config summary; that is now also fixed.
@jwpeterson

This comment has been minimized.

Copy link
Member

jwpeterson commented Jan 20, 2019

I'm not exactly sure what is causing the issue in #1849.

There was a stupid string comparison bug that should now be fixed in #2004.

@kkremitzki

This comment has been minimized.

Copy link
Author

kkremitzki commented Jan 20, 2019

By the way, what Trilinos packages do you have installed when you get this particular error in Debian?

I had trilinos-all-dev installed. I'm testing your branch now.

Edit: Works great!

@jwpeterson

This comment has been minimized.

Copy link
Member

jwpeterson commented Jan 20, 2019

Edit: Works great!

OK, good. Let us know on this issue if you run into any more problems packaging master. I think it would definitely be best to focus on master as we are overdue for another release (1.3.0 was tagged April of last year) and there have been a fair amount of improvements/changes since then.

@jwpeterson

This comment has been minimized.

Copy link
Member

jwpeterson commented Jan 22, 2019

@kkremitzki I don't know if it's relevant to your work, but a circa-2011 version of libmesh was also once packaged for Ubuntu.

@kkremitzki

This comment has been minimized.

Copy link
Author

kkremitzki commented Jan 22, 2019

Ah, indeed it is! I didn't know that. It turns out that libmesh was previously packaged in Debian as well.

The removal bug states it was removed for failing to build from source with new (2013) versions of petsc and slepc. Since that's obviously not a problem anymore, there should be little difficulty in getting it back in, and knowing that it was previously packaged means it should be even easier to do.

@roystgnr

This comment has been minimized.

Copy link
Member

roystgnr commented Jan 22, 2019

knowing that it was previously packaged means it should be even easier to do.

Hopefully one of the changes we've made in the meantime will also help - we now by default disable integration of third-party software with non-LGPL-compatible licenses. IIRC with that long-ago Debian package the maintainer had a lot of work to do to strip out "free for academic use only" or other "good enough for most researchers but not actually open source" code.

@roystgnr

This comment has been minimized.

Copy link
Member

roystgnr commented Jan 22, 2019

Oh, and although it should go without saying: Thanks for this!! Let us know if there's anything we can do to help.

jwpeterson added a commit to jwpeterson/libmesh that referenced this issue Jan 22, 2019

Fix bugs in DTK configure test.
* We were missing an "x" character in a string comparison test,
  causing the comparison to always be true.  This came up in issues
  libMesh#1849, libMesh#2003
* There was also an uninitialized variable which didn't print in the
  config summary; that is now also fixed.
@kkremitzki

This comment has been minimized.

Copy link
Author

kkremitzki commented Jan 23, 2019

knowing that it was previously packaged means it should be even easier to do.

Hopefully one of the changes we've made in the meantime will also help - we now by default disable integration of third-party software with non-LGPL-compatible licenses. IIRC with that long-ago Debian package the maintainer had a lot of work to do to strip out "free for academic use only" or other "good enough for most researchers but not actually open source" code.

Great, indeed one of the big tasks in packaging for Debian is doing the copyright review and making sure the debian/copyright file is correct, so that will help.

One other thing worth addressing is the contents of the contrib folder. Usually we'll try to repack upstream tarballs if they contain third party code, especially if it's already packaged in Debian, so I'll surely be trying to do that since I recognize a lot of the contents of that folder. In particular I see there's Tetgen, whose AGPL license has been cause for some concern in Debian so I'd like to make linking against it optional one way or another, including possibly turning off support for it but preferably just putting affected *.so's in a separate package. Any ideas on the impact/feasability of this?

Oh, and although it should go without saying: Thanks for this!! Let us know if there's anything we can do to help.

Definitely, I'll be glad to get it back in Debian! Besides the featureset, the LGPL license really attracted me since it's the same as FreeCAD, a project I'm a part of. I'd like to explore libMesh integration in FreeCAD's FEM Workbench, so this is a necessary first step.

@jwpeterson

This comment has been minimized.

Copy link
Member

jwpeterson commented Jan 23, 2019

In particular I see there's Tetgen, whose AGPL license has been cause for some concern in Debian so I'd like to make linking against it optional one way or another

Tetgen is already optional and configured off by default. You may need to physically remove the contrib/tetgen directory before packaging it, but otherwise libmesh should work fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.