Description of problem: yum install proj-devel Setting up Install Process Setting up repositories development 100% |=========================| 1.1 kB 00:00 extras-development 100% |=========================| 1.1 kB 00:00 Reading repository metadata in from local files Parsing package install arguments Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package proj-devel.x86_64 0:4.4.8-6 set to be updated --> Running transaction check --> Processing Dependency: proj = 4.4.8-6 for package: proj-devel --> Finished Dependency Resolution Error: Missing Dependency: proj = 4.4.8-6 is needed by package proj-devel Version-Release number of selected component (if applicable): --------- Also theres a new upstream release available namly 4.4.9. would be nice to have it updated so i dont have to replace it in newrpms.
Hmmm, proj = 4.4.8-6 is there: http://fedoraproject.org/extras/development/x86_64/proj-4.4.8-6.x86_64.rpm http://fedoraproject.org/extras/development/x86_64/proj-devel-4.4.8-6.x86_64.rpm
interesting. maybe some mirrors synced it halfway. was the same problem on various mirrors though when i reported. can we still upgrade it to 4.4.9 please. i have 4.4.9 in the newrpms.susnite.dk fc3 repo for a while and want to build vs extras and livna with fc4
In Extras, proj is without maintainer. There has been some volunteer activity on fedora-extras-list, but no final word on who likes to take the package. You could if you signed up at https://admin.fedora.redhat.com/accounts/
See updates to bug 150013. I've created a patch for the issue from 150013 and would like to submit the patch and the current version of the source (4.4.9) to extras (as soon as I can get my CVS access working).
CVS access is now working. I've uploaded the new src.rpm file to the devel branch. If the solution is acceptable, I'll upload it to the FC-4 branch as well. Only problem I can see is that the change log in the spec file didn't update - does this have to be done manually?
actually i have signed up but i do not care if someone else is going to maintain this package properly. gotta fax in the legal agreement.
> Only problem I can see is that the change log in the spec file didn't > update - does this have to be done manually? Yes. In there, you document any interesting things you changed in the spec or in the overall packaging. > +# Patch for Bug 150013 > +cp %{PATCH2} ./ > +patch src/pj_gridinfo.c pj_gridinfo.patch > + You could change this to use the %patch2 macro instead. > -Version: 4.4.8 > -Release: 6 > +Version: 4.4.9 > +Release: 0 Please start at release 1. > %clean > -rm -rf $RPM_BUILD_ROOT > +#rm -rf $RPM_BUILD_ROOT Not sure why you did that. The rm -rf of buildroot must be in there. > If the solution is acceptable, I'll upload it to the FC-4 branch as well. In that case, you may need to make it "Release: 1%{?dist}", especially since there is no release number lower than 0.
Re: comment 6, well, signing up is a good thing anyway, since occasionally a lot of help is needed with some packages. And for some packages it would be beneficial if they were maintained by more than one person.
Files have been patched as suggested in the review comments and proj-4.4.9-1 has been checked into CVS (devel branch). I'd agree that more maintainers are a good thing. I've been working on a set of rpm's to enable Quantum GIS and GRASS to be added to extras (eg libgeotiff, geos, gdal, etc) so it would be useful to have a group that is familiar with these packages.
Do you want "shapelib", too?
Sure, I can maintain shapelib. They're all related packages. Let me know if these changes should be checked into the FC-4 branch as well (I'm assuming they should).
Sounds reasonable.
@ Comment #9 i am fine with that. you can take a look at the packages for fc4 and 3 on newrpms.sunsite.dk as a base probably... i had a nice gdal build for core 3 and for core 4 basically only ogdi.sf.net is troubling me. fixes appreciated ;) the rest of it should cleanly build up then. note that one fix that has to be done is to add the properly requires to the gdal-devel split rpm ;)
Rudolf, did you use the GDAL-GRASS wrapper library in your packages? One of the reasons why GDAL and GRASS didn't move forward at fedora.us was the circular dependency between GDAL and GRASS. The Debian GIS folks ran into it too, and upstream fixed it with a release of a wrapper library. Parts of this was documented in old bugzilla.fedora.us
Tried checking the updates into the FC-4 branch but ran into the following error - tag conflict. Not sure how to fix this - something to do with the %{?dist} directive ? Shawn cvs commit... For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs Enter passphrase for key '/home/smccann/.ssh/id_dsa': Commit Complete For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs Enter passphrase for key '/home/smccann/.ssh/id_dsa': ERROR: The tag proj-4_4_9-1 is already applied on a different branch ERROR: You can not forcibly move tags between branches proj-4_4_8-4:devel:mschwendt:1105695932 proj-4_4_8-0_fdr_4_rh90:RHL-9:scop:1109748279 proj-4_4_8-0_fdr_4_1:FC-1:mschwendt:1109867685 proj-4_4_8-0_fdr_4_2:FC-2:mschwendt:1109868426 proj-4_4_8-5:devel:mschwendt:1112828419 proj-4_4_8-6:devel:mschwendt:1116779683 proj-4_4_9-0:devel:smccann:1120711968 proj-4_4_9-1:devel:smccann:1120800255 cvs tag: Pre-tag check failed cvs [tag aborted]: correct the above errors first!
Yes, cvs tags are shared between branch directories. > proj-4_4_9-1:devel:smccann:1120800255 This tag is used already, so for the FC-4 branch, you cannot use it. The tags are created from the package's name-version-release values. The version-release for FC-4 could not be equal to version-release for devel anyway as it would need to be seen as "lower than" (= "older than"). Appending %{?dist} to the release field is one way how to solve this. Then FC-4 would become proj-4.4.9-1.fc4 (tag => proj-4_4_9-1_fc4). But it would be "higher than" your current devel release, and hence you would add %{?dist} also in the devel branch and re-tag the files in devel with "make tag". The only alternative to dist tags is making sure that packages in devel branch always have highest version-release compared with older distribution branches. That's not trivial if you allow for distribution upgrades from up-to-date installations [since Fedora Extras needs a separate yum update during first boot].
OK. Both spec files already had %{?dist} in the release and so I didn't update them again. Ran "make tag" in devel and then in FC-4 with no problems. I assume these will now be built in the next devel and fc4 build runs and the fc4 version should then show up in the repository and then this bug report can be closed.
http://fedoraproject.org/wiki/Extras/BuildRequests Packages within CVS won't be built automatically. Explicit build requests are required. Though, note that since last weekend, the build system is disabled while the new buildsys code is being installed and tested. Expect news to be posted to maintainers' list and extras' list.
The new version of proj (4.4.9-1) has now been built for devel and FC4 and shows up in the FC4 repository so I am closing this issue