Hide Forgot
openalpp has been in the rawhide broken deps reports for a couple of days now: openalpp - 20060714-3.fc7.i386 requires libOpenThreads.so.1 Please rebuild openalpp or I can give it a spin if you're ok with that.
I guess Ralf updated OSG to 2.0 last week. I'll fire off rebuilds of openalpp, osgal and osgcal. Hopefully there won't be any build issues (knock on wood). :)
Build fails[1]. Says it is missing openthreads, where I clearly include OpenThreads-devel in the root.log. Perhaps OpenThreads-devel is not including a pkgconfig file in devel or something? I guess I'll have to figure out what is going on when I have some more free time...
oops forgot to paste the build log: [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=59674
The problem indeed is that OpenThreads 2 doesn't have a pkgconfig file, once thats worked-around it compiles fine. (not tested!). I'll attach a spec file diff + patch which I've sued to work around the missing pkgconfig file. Notice this is not pretty (I hate autoXXXX) but it works. Adding Ralf (the OpenThreads maintainer) to the CC, Ralf maybe its a food idea to add a pkgconfig file to OpenThreads in the package, the removal of this file may break compiling other apps too, and openthreads otherwise _seems_ API compatible.
Created attachment 158732 [details] specfile patch / hack to get openalpp to compile with new openthreads
Created attachment 158733 [details] configure patch / hack to get openalpp to compile with new openthreads
Do you need this right away? If so, I can just add the openthreads.pc file as a patch and set the pkgconfig file path to . (dot). This should work as suggested by Loic. Otherwise if Ralf plans on adding pkgconfig files back in the OSG packages I'd rather wait for that.
I've no need for this atm, I just noticed it in the broken deps report. Waiting for what Ralf wants todo seems like the best plan to me too.
Well, I am not sure what to do about this. With OSG-1, the pkgconfig files initially had been part a Debian patches, but later (IIRC, with 1.2) had been adopted by upstream (I.e. upstream had made pkgconfig part of their package/API). With OSG-2, upstream has dropped pkgconfig. I.e. though technically re-adding the pkgconfig files to Fedora's OSG package is not much of a problem, any package which is using OSG and is relying on OSG-pkgconfig support files, doesn't comply to OSG-2's programming environment. It's a pity, but that's one side-effect of upstream decisions. Also, let me note that I am still undecided on how to proceed with OSG. I am leaning to revert Fedora's OSG back to OSG-1 and to add a new OSG-2 package.
(In reply to comment #9) > Well, I am not sure what to do about this. Well, the packages I maintain (openalpp, osgcal, and osgal) which rely on OSG libraries are not updated very often. I think it would be nice if you could provide the pkgconfig files through the Fedora 8 cycle in order to give the upstream maintainers of these projects some time to fix their config scripts and what not for OSG 2.0. I do not see this as being harmful, because the upstream developers of the projects I package use the upstream version of OSG, not the Fedora packaged version. Is there anyone other than me who packages stuff for Fedora that relies on OSG libs?
Upstream has informed me that there are numerous issues with osg2. He has suggested to go ahead and make an osg1-compat rpm.
(In reply to comment #11) > Upstream has informed me that there are numerous issues with osg2. Which upstream? I tried to check and found what seems to be a dead and discontinued project (http://alpp.sourceforge.net) http://sourceforge.net/projects/osgal however claims to have released an osg2.0 compatible version.
Hi, poker3d depends on openalpp & osgal in their pre-osg2 version. The API of openalpp changed and the api of osg2 version also changed. poker3d would need to be ported to these new versions. osgcal also depends on osg1.2 and needs to be ported to osg2. There may be a number of packages for which there does not exist an official fedora package suffering from the same problem. It makes sense, I think, to keep a version of osg1.2 active even after the new major osg2 is being published. Just like you still have db3, db4, etc. Loic Dachary loic
Ralf, we have an osgcal ready which is osg2 compatible, but we need a pkgconfig file to be packaged with osg2, can you please add one? Debian added one which can be seen here: http://2-0.openscenegraph.dachary.org/file/3b83c8dd5399/openscenegraph-2.0/debian/openscenegraph.pc
(In reply to comment #14) > Ralf, we have an osgcal ready which is osg2 compatible, but we need a pkgconfig > file to be packaged with osg2, can you please add one? Are you current sources in CVS? I'd have to re-check details. Several weeks ago, I once did and had been able to build openal or openalpp without pkgconfig. > Debian added one which > can be seen here: > http://2-0.openscenegraph.dachary.org/file/3b83c8dd5399/openscenegraph-2.0/debian/openscenegraph.pc Well, Debian is introducing an API which doesn't exist upstream :/
The .pc files existed in 1.2 and were removed in 2.0 when Robert Osfield moved to CMake. I should talk Robert into re-introducing the .pc in the distribution once again. However, before 2.0 these files were constantly out-dated because Robert is a windows user and does not need these files. In the end it was the responsibility of the packager to fix these files. I'm not too hot for another 20 mails session about the virtues of pkgconfig, specialy if it turns out to be outdated most of the time. Instead, I think it makes sense to consider that these files are packaging tools in the same sense as the dependencies. I hope you can see my point of view. If you don't I'll have to do some work on my own software (osgal + osgcal) to accomodate for the lack of .pc file. I'd rather have you do some work and me doing nothing. But I'd understand if you prefer me doing some work and you doing nothing to improve the packaging of openscenegraph ;-)
(In reply to comment #16) > The .pc files existed in 1.2 and were removed in 2.0 when Robert Osfield moved > to CMake. Right, upstream abandoned it. > I should talk Robert into re-introducing the .pc in the distribution > once again. Feel free to do so. When upstream re-adds them, they will re-appear in Fedora. > However, before 2.0 these files were constantly out-dated Then you probably have not been using Fedora. The OSG in Fedora is heavily patched to get things close to being functional. > because > Robert is a windows user and does not need these files. In the end it was the > responsibility of the packager to fix these files. This is the wrong view: It was inevitable for the packager to do so, because upstream shipped broken files. > Instead, I think it makes sense to consider that > these files are packaging tools in the same sense as the dependencies. The point is: Upstream defines a package's API. pkgconfig is part of this. If upstream abandons something, upstream has drawn a decision - A packages users have to follow, whether they want or not. > I hope > you can see my point of view. If you don't I'll have to do some work on my own > software (osgal + osgcal) to accomodate for the lack of .pc file. Pardon, but then your work is based on ilegimate assumptions and you will have to find a different solution. > I'd rather have you do some work and me doing nothing. Pardon? > But I'd understand if you prefer me > doing some work and you doing nothing to improve the packaging of > openscenegraph ;-) Apparently you are not able to comprehend: OSG2 has changed the API. Now it's its client-applications's (your) job to follow or these client applications are dead. Whether upstream's decisions are good or not, is irrelvant, as well as the fact that Debian has re-added the *.pc's. BTW: In packages with properly integrated pkgconfig support, it's possible to pass the required *_CFLAGS and *_LIBS from the configure-line. IIRC, pkgconfig support in osgal and osgcal are broken wrt. this.
(In reply to comment #17) > (In reply to comment #16) > > However, before 2.0 these files were constantly out-dated > Then you probably have not been using Fedora. The OSG in Fedora is heavily > patched to get things close to being functional. What∠You heavily patched the pkgconfig files with OSG1 essentially *changing the API* according to your definition of what a pkgconfig file is, and you wont do it for OSG2? I'm throwing my hands up in the air here. What the hell Ralf. Just add a pkgconfig file for heavens sake. A pkgconfig file does not change the API, you do not harm anything by adding one. Am I just stupid, or are you Ralf making a big deal out of nothing. I'm probably just stupid.
Let me put this another way Ralf. Instead of you waiting for upstream to supply a pkgconfig file, why dont you just add one yourself, and send it for upstream to include. This is the best and proper way to proceed. Thank you.
# repoquery --archlist=src --repoid=updates-source --repoid=fedora-source --repoid=dribble-source --repoid=livna-source --whatrequires OpenSceneGraph-devel osgal-0:20060903-3.fc7.src osgcal-0:0.1.44-4.fc7.src As far as I can tell, I have the *only* packages that use OSG-devel. Now if I say I need a pkgconfig file, why wont you comply? It only affects me, myself and I. We are making efforts to get upstream to re-include the pkgconfig files, your help would be appreciated. *** PLEASE PLEASE PLEASE JUST RE-ADD THE PKGCONFIG FILE I LINKED TO ***
(In reply to comment #20) > # repoquery --archlist=src --repoid=updates-source --repoid=fedora-source > --repoid=dribble-source --repoid=livna-source --whatrequires OpenSceneGraph-devel > osgal-0:20060903-3.fc7.src > osgcal-0:0.1.44-4.fc7.src > > As far as I can tell, I have the *only* packages that use OSG-devel. > Now if I say I need a pkgconfig file, why wont you comply? Because the fact these package depend on OSG shipping a pkgconfig file are BUGS inside of these packages. They rely upon what had been in OSG1, but had been abandoned by upstream in OSG2, and Debian seems to have re-added as an isolated Debian-proprietary hack. > It only affects me, myself and I. We are making efforts to get upstream to > re-include the pkgconfig files, your help would be appreciated. Grant me access to CVS and I'll build openalpp w/o OSG's pkgconfig files. Fixing this is a matter of minutes (I have patches pending). Whether this would be reasonable is a different matter. As pointed out before, this version of openalpp is dead, discontinued and unmaintained. IMO, it should be removed from Fedora. Whether this will help you wrt. osgal and osgcal is a yet another question. osgal's configure definitely is too buggy to allow building w/o pkgconfig files. Fixing this is possible, but I don't know it this will help you at all or if this won't reveal further OSG1/OSG2 compatibility issues. > *** PLEASE PLEASE PLEASE JUST RE-ADD THE PKGCONFIG FILE I LINKED TO *** I will add them once upstream does - Until then, I recommend you to fix these packages.
Adding a pkgconfig file is not a hack. openalpp is not the issue. openalpp is going away with the next release of osgal (they are being combined).
(In reply to comment #22) > Adding a pkgconfig file is not a hack. Are you deaf or what? How many times do I have to repeat? Upstream has decided not to ship the pkgconfig files (and apparently doesn't consider to do so). => Any package relying on these pkgconfig files to be present is BROKEN, BUGGED, MIS-DESIGNED - In short: crap. > openalpp is not the issue. OK, then the question must be allowed why you haven't been able to fix the package? I had offered you to help, but you once again rejected it. > openalpp is > going away with the next release of osgal (they are being combined). Then update. I had asked you for the your sources, because, given the poor shape the current osgal is I am expecting the worst. You once more preferred not to answer ... your liberty.
I am waiting on the next release of osgal. Once it is ready, I will update osgal and obsolete openalpp. But that probably wont be possible if you continue to be stubborn about the pkgconfig file. OSG upstream is windows centric, they probably don't even know what a pkgconfig file is. Did you actually bother e-mailing upstream and asking about it? You need to be more proactive. We need the pkgconfig file, it makes life easier. If you let upstream know that packages that depend on osg-devel on linux need a pkgconfig file and you provide him with one, then upstream will add it. It is not a hack to add a pkgconfig file because upstream doesn't know why they are needed. The proper thing to do is to educate the OSG folks on why pkgconfig files are good. I'm starting to think you have some personal vendetta against pkgconfig files.
(In reply to comment #24) > OSG upstream is windows centric, they probably don't even know > what a pkgconfig file is. Rubbish - They even had it in OSG1. > Did you actually bother e-mailing upstream and asking about it? Why should I? THEY define what THEY want. YOU simply don't want to comprehend, that they dictate how their package is supposed to be used, not some trashy application. > You > need to be more proactive. We need the pkgconfig file, RUBBISH - YOU need to fix YOUR package to match what upstream expects. > I'm starting to think you have some personal vendetta against pkgconfig files. Absolutely no. I simply refuse to cripple and hack packages because somebody is not able to fix the bugs the packages he is trying to maintain.
I don't see any use in continuing to waste my time on this.
Ralf, if another package requires that pkgconfig file, I don't see what's wrong with adding it, especially given that the file has been provided already! There are other packages with Fedora-added .pc files too. Please try thinking in the overall interest of Fedora instead of defending principles all the time.
Additionally, compatibility with Debian is also an important reason to add the .pc file. Even if you don't like what Debian is doing, being gratuitously incompatible with them helps no one.
Kevin, Thanks for the helpful comments, but Ralph has removed himself from the CC.
http://dfn.dl.sourceforge.net/sourceforge/osgal/osgal-0.6.1.tar.gz has just been published with autotools fixes. Good to know .pc files will be provided.
osgal 0.6.1 with osg2 support built for f8 osgcal 0.1.46 with osg2 support built for f8 openalpp is now obsoleted by osgal 0.6.1 and the release engineering team has been notified that the openalpp package is now a dead.package. These packages are not marked for Test 3 because the needed updates for the OpenSceneGraph package did not make it in Test 3.