Please note this is my first package. I am looking for a sponsor. Spec URL: http://mattchan.homelinux.net:55555/brlcad/brlcad.spec SRPM URL: http://mattchan.homelinux.net:55555/brlcad/brlcad-7.14.9.20090823svn-0.fc11.src.rpm Description: BRL-CAD is a powerful Open Source combinatorial Constructive Solid Geometry (CSG) solid modeling system that includes interactive 3D solid geometry editing, high-performance ray-tracing support for rendering, geometric analysis, signal-processing tools, path-tracing, and photon mapping support for geometric representation and analysis.
*** Bug 236856 has been marked as a duplicate of this bug. ***
Matt, you're using x86_64 as a marker for 64-bt arch - please, keep in mind, that we also have sparc and ppc64 targets. I'll post more notes later.
Thanks for the quick comments! I've made the changes to add sparc64, ppc64, and alpha to the %ifarch operator The spec file at the link has been updated. The new SRPM is at http://mattchan.homelinux.net:55555/brlcad/brlcad-7.14.9.20090823svn-1.fc11.src.rpm Matt
I discovered that the SRPM had a directory name bug when doing a koji build. I've updated the tarball name and rebuilt it. The latest link now points to the correct version. Sorry for the inconvenience, Matt
Hey Matt. I took a quick look, and a few things to address before a review: 1. It looks like your are building some of the internally bundled copies of libraries: Build tkhtml3 ........................: yes Build tkImg ..........................: yes Build Utah Raster Toolkit.............: yes Build Template Numerical Toolkit......: yes Build openNURBS.......................: yes Build NIST STEP Class Libraries.......: yes You should use system versions of these, or in cases they don't yet exist in Fedora, submit them for review first. I know tkImg at least is in Fedora already, not sure about the others. 2. The License tag doesn't appear right... see the Licesing page for the correct tags, and note that "," is not valid. 3. rpmlint has a number of complaints. Try and address those? If you can take a look at those and spin up a new package I can look at reviewing this for you.
Ping any progress on this, Matt ?
Ack. I'm sorry, I don't know how, but I missed the email about Kevin's comment. I guess there's a downside to too many bugzilla emails. I will have some time to work on this in the weekend to fix the license and rpmlint errors. I thought they were only trivial ones, but I didn't test the most recent changes. The libraries are somewhat of a sticky issue. I consulted with the BRL-CAD devs on the possibility of abstracting out the libraries while building this package. It appears that they have made heavy 3rd party modifications to most of these libraries, especially Utah, Template Numerical, openNURBS, and NIST STEP, and the upstream projects are unwilling to accept them or are no longer active. TkHTML is a dead project as far as I know. None of those libraries listed should be present in fedora 11. Is it still considered a good idea to abstract out the libraries, or should we just consider them a part of the BRL-CAD package? According to the BRL-CAD devs, they don't really resemble the original libraries/projects anymore. To my knowledge, there is no project outside of BRL-CAD that makes use of their modifications to these libs. Thoughts? Matt
Well, the guideline is at: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries I really wish projects wouldn't do this kind of thing. It makes it much harder to get them packaged for a distribution. ;(
Hmm that's the first time I've read that page. So what do we do now? Would applying to FeSCo be appropriate? This lib problem is also the reason other distributions are having trouble accepting BRL-CAD. (The lib naming problem being the other one. BRL-CAD's been in development for 20 years, so it doens't follow standard naming schemes.) Matt
Could we get some more information on this? How many libraries are included? How many are dead upstream and how many won't accept brl-cad's patches? Where were the patches sent to? Where the libraries are dead upstream, the best thing to do would be for brl-cad upstream to take over (or release a renamed fork) with their modified versions. Where the upstreams don't want the changes we should find out why (a) the upstreams don't want them and (b) why brl-cad does. Then we'd have to decide whether to work with brl-cad to phase out the need for the library, work with the library upstream to clean up the changes for inclusion, or get someone (hopefully brl-cad) to maintain the forked version.
We wish we didn't have to do that kind of thing too. Alas, there is not a universal cross-platform package management system that we can rely on to be default installed cross-platform. With the exception of openNURBS and NIST SCL, our external dependencies are unmodified and primarily provided as a download convenience for users. Our build aims hard to "just work" by default, regardless of platform and environment. We go to great lengths in our build system to perform compilation testing to detect installed libraries and to use them when we can. Additionally, there are compilation options to force all or individual dependencies on and off so that package management systems can be sure they're getting a system-installed library. The default is merely "auto-detect". I'm really not sure what Matt meant by not following standard naming schemes. Is there even such a thing? The problem has been simple naming conflicts as our core public libraries are sub-projects in themselves with trade mark identity. The solution there is to install our libraries in a sub-directory (e.g., /usr/lib/brlcad/librt.so) and update the system linker search paths so the conflict is avoided. To get more specific on our external dependencies and respond to Toshio's request .. here's the list of installable dependencies their status: tkhtml3: no source changes, build convenience tkImg: no source changes, build convenience Utah Raster Toolkit: no upstream, we apply security and build fixes (but otherwise do not modify) TNT: no source changes (it's only header files) openNURBS: some source mods, upstream is not interested (competes with their business) NIST SCL: no upstream, heavily modified (we'll eventually manage it as a sub-project) We're using openNURBS in a way that upstream specifically doesn't support. It's a fantastic library that provides (a) geometric representation and (b) conversion facilities, yet is a subset of their larger commercial Rhino SDK which includes (c) geometric analysis facilities. We need a, b, and c for the same reasons they did, so we have to implement a portion of what they intentionally remove. We're looking into ways to refactor our modifications so they are an independent superset (so upstream is unmodified), but that's not where things are at today. Big thanks and appreciation to Matt Chan for taking this up. Thanks to everyone else for taking the time to review and critique. It will be great to see BRL-CAD integrated. Cheers! Sean
There is also a problem with the librt.so from brlcad that may conflicts with the glibc one on linux. Any progress on this side ? (specially using pkg-config will be an easy way to abstract the problem). At least that was the pending question when I took care of the package some time ago: https://bugzilla.redhat.com/show_bug.cgi?id=236856 There are also well known duplicates: (took from my spec file). #Rename wall #mv $RPM_BUILD_ROOT%{_bindir}/wall $RPM_BUILD_ROOT%{_bindir}/brlcad-wall mv $RPM_BUILD_ROOT%{_bindir}/dstat $RPM_BUILD_ROOT%{_bindir}/brlcad-dstat mv $RPM_BUILD_ROOT%{_bindir}/istat $RPM_BUILD_ROOT%{_bindir}/brlcad-istat
Ah yes, can't forget the *long* efforts of kwizart that started us down this path (thanks to you too Nicolas!).. The 'wall' command was renamed about 20 months ago. I don't recall dstat/istat ever being raised as an issue, though. Do you have a reference link for the istat conflict? Regardless, dstat and istat are non-critical tools that can be easily renamed. I'll put it in our queue for the next release (7.16.2). We provide pkg_config files (as well as a brlcad-config script) so installing libraries into a subdirectory should take care of the librt/libbu/libbn conflicts. Cheers! Sean
While creating a package for tkImg, I noticed that they include modified source versions of libz, libpng, libungif, libjpeg, and libtiff (from Aug 2000) so they can be loaded into the tcl/tk core. Does anyone care to weigh in on this? Does this count as a violation of Fedora's pre-packaged libraries clause? TkImg upstream seems to be dead or close to it. The last release was in Dec 2002 and there's only blips of activity on their sourceforge tracker so it may be difficult to have changes implemented. Matt
Yes. See: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#When_a_Bundled_Library_is_Discovered_Post-Review Basically: file a bug on it, and make it block the blocker used to track these issues.
Another bit of fun while exploring tkHTML3 this time: Everything is statically linked in, from 2006 or so. I'm not sure what it would take to refactor to use dynamic libs, never tried before and I don't know if the lib versions from 2006 are still around. Upstream appears to be dead as well: http://groups.google.com/group/tkhtml3/browse_thread/thread/3eeb094b7b460e3a As before, any thoughts? Matt
When an upstream is dead like you're saying tkImg and tkHTML3 are, the problem of bundled and static libraries is exacerbated. In those cases, instead of having to wait for multiple upstreams to discover problems, make fixes, announce them, and then have the next upstream in the chain realise the problem affects their bundled libraries, make fixes, and release updated tarballs, we have upstreams whose source will never change even though there's known security vulnerabilities. This makes it even more imperative that the packager fixes these problems as soon as possible as the packager is the new upstream for the package and if they package with these problems then the maintenance burden for fixing those types of security problems falls entirely on them.
It's worth noting a few updates since this recent set of updates about tkImg and tkHTML3. First off, some clarifications. The tkImg package only bundles those external dependencies for download convenience and can be disabled. In fact, our bundling of tkImg itself in BRL-CAD was a simple subset of just the PNG Tcl bindings (without libpng, libz, or any other lib). That said .. we're already in the process of replacing tkImg with tkPNG since it's even more simple and is closer to the minimal functionality that we need. To top it off, we found existing RPMs for tkImg around the same time.. :) As for tkHTML3 and the assertion that things were being statically linked in, that was a mistake. The tkHTML3 sources don't even have any external dependencies, much less linking in anything static. There was some confusion inferred from a misleading statement on the website about a related code. So the basic summary, it's mostly all moot. We'll have to get tkPNG packaged, but that should be very easy.
> The tkImg package only bundles those external dependencies for download convenience and can be disabled. Excellent. As long as those are disabled in the Fedora build it's perfectly acceptable :-) The rest of your update sounds very encouraging as well.
A quick update on our progress so far: The TNT (and JAMA) libraries have been abstracted out and packaged. The review requests are at 549980 and 550234. If someone has a second, could they review them quickly please? They are just a bunch of headers and have less than 25 files each package. It shouldn't take more than 30 mins for each. And on the tkhtml3 front, the former upstream dev has confirmed directly that the project is dead. The brlcad team have made provisions to take over the upstream for the STEP and Utah projects. The transition to tkPng will be made in the next release, and tkImg will be dropped as a requirement. Tkhtml3 and OpenNURBS are the remaining issues which have not been resolved yet. Matt
Unblocking FE-NEEDSPONSOR since I just sponsored Matt.
A quick status update on our progress since the last comment: - TkHtml3 has been taken over officially. The BRLCAD team is working towards creating an updated release that we can use in our package and also setting up project infrastructure. - Utah Raster Toolkit has been taken over as well. They're in the process of deciding on a new name for the project to establish a new home for it. - TNT and JAMA have been reviewed and are ready for submission into the repos. Our remaining issues preventing packaging are: - Project infrastructure for NIST Step Class Libraries, TkHtml3, Utah Raster Toolkit - releases for above mentioned projects - refactor OpenNURBS code to be compatible with upstream Matt
Since it seems that this isn't yet ready for review, I'm going to mark it as such. If it does become ready for review, please clear the Whiteboard field above.
Just thought I'd post some updated info in case anyone wants to start working on this again: The situation with Utah Raster Toolkit and TkHtml3 remains largely unchanged - in both cases the primary need is to set up separate project infrastructure. That's not currently high priority for us, but it is on the TODO list. TNT/JAMA is still currently needed, but we are looking to switch to using the Eigen C++ headers now that they've become MPL2+LGPLv2+ licensed - once we complete that process, the TNT/JAMA issue will go away. We will use Eigen 3.1.2 or greater - there's already a Fedora Eigen3 package from the looks of it, although it's currently at 3.0.6: https://admin.fedoraproject.org/pkgdb/acls/name/eigen3 The openNURBS issues remain unchanged - we are trying to boil down our code changes into either things that can live in our own libraries, or patches upstream will accept. The NIST Step Class Libraries are the most interesting update - there is now a separate open source project working on this code called STEPcode: http://stepcode.org. BRL-CAD is working with this project to merge our changes into their upstream - this is a large job (http://stepcode.org/mw/index.php/BRL-CAD_patches) but there is active interest on both sides. Once the merge is complete and STEPcode makes a release with BRL-CAD's changes, we will be able to build against STEPcode as a proper external dependency. For anyone wanting to make progress towards BRL-CAD being a viable Fedora RPM candidate, I'd suggest starting by contacting the STEPcode list and helping with the merge process and/or creating a Fedora STEPcode RPM.
Fine. I will try to make an RPM of stepcode.
There has been no comments on this ticket for quite some time. As per the policy for stalled reviews please respond within a week or this will be closed. Matt are you intending to pick this up again or is this no longer in your radar? https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews
I don't have time to work with this package unfortunately. I'm actually packaging a few other projects now. This time a few of my colleagues and I are the authors so hopefully it will go smoother. Sorry. Can someone pick this up for me if they're interested?
(In reply to Matt Chan from comment #27) > I don't have time to work with this package unfortunately. > > I'm actually packaging a few other projects now. This time a few of my > colleagues and I are the authors so hopefully it will go smoother. > > Sorry. Can someone pick this up for me if they're interested? Thanks for responding so quickly. In that case I'll close this as a dead review for now to clean up the queue a bit and so that others can see the process isn't continuing and they can open a fresh review ticket if they desire.
For your info, I started interesting in making a spec file for brlcad and all libraries that need to be unbundled. If anybody wants to cooperate, feel free to send me an e-mail. Have a nice day