Description of problem: The current version of python-rdflib in rawhide is 3.2.3, which dates back to 2012-10-10. The RDF world has changed significantly since then; improvements in rdflib releases since 3.2.3 include the addition of RDFa parsing support, for example, which is increasingly important these days. rdflib 4.1.0 was released on 2013-12-31 (https://pypi.python.org/pypi/rdflib/4.1.0).
This is late also because the relation between python-rdflib and python-rdfextras changed with the version 4, so we haven't got around to update it. If you know how to update a spec, feel free to propose a patch, I'll review it, otherwise I'm putting it on my todo :)
Created attachment 868120 [details] Update python-rdflib SPEC for RDFLib 4.1.0 release This patch updates the python-rdflib spec to support RDFLib 4.1.0. All tests pass (with the inclusion of a patch that has also been submitted upstream for a SPARQLStore test that is skipped in other tests). It looks like rdfextras has simply been rolled into RDFLib core, so before this update can be rolled out, python-rdfextras needs to be updated along with python-rdflib to avoid a conflict with the rdfpipe executable that both packages now try to install. As a transition path, would it be possible to update python-rdfextras to install nothing at all in rawhide and, then remove python-rdfextras entirely as a package in rawhide + 1? I haven't dealt with removing a package from Fedora before. Alternately, we could make the python-rdflib SPEC subpackage python-rdfextras for us.
Thanks for looking into this. The proper way is to use Provides/Obsoletes tags and retire python-rdfextras from the distribution. I am curious about the chmod +x on things which are in the python sitelib, I see there was one already but this looks strange.
Created attachment 868133 [details] Update python-rdflib SPEC for RDFLib 4.1.0 release Failed to deal with infixowl.py properly. Resolved.
So, rdfpipe in the bindir is just a very thin wrapper for rdfpipe.py in the sitelib; you can execute rdfpipe.py directly. That said, this is my first time packaging a Python library, so I happily defer to your experience in such matters! For example, the infixowl.py sitelib case may more properly be handled by sed. Thanks for your tip on Provides/Obsoletes, that makes sense. Is that something I can leave in your hands?
Hmm. While this builds fine and the spec and SRPM and RPM pass rpmlint with just a handful of warnings, installing the resulting RPM on Fedora 20 and running rdfpipe from the command line then fails because /usr/lib/python2.7/site-packages/rdflib-4.1.0-py2.7.egg-info/requires.txt includes: html5lib==0.95 SPARQLWrapper setup.py talks about a bug in html5lib-1.0b2 causing them to pin the dep to html5lib-0.95, but html5lib 0.999 is out (two bugfix releases after html5lib-1.0b2). I opened a separate bug last night asking for an update of python-html5lib. I'll poke the RDFLib team directly to find out if html5lib-0.999 resolves the problem in question. And it looks like we might now have a hard dependency requiring us to package SPARQLWrapper, unless we sed out the SPARQLWrapper line for now and document the package as such. Oh the rabbit holes.
Created attachment 868157 [details] Unpin html5lib version requirement Per https://github.com/RDFLib/rdflib/pull/360, versions of html5lib after 1.0b2 resolve the regression that occurred in 1.0b2. This patch matches the patch that I have sent to upstream.
Created attachment 868159 [details] Unpin html5lib version requirement Format the "unpin html5lib" patch as part 2 in a series of patches to apply to python-rdflib (includes the changes to the SPEC as well as the upstream patch).
Added dependency on bug 1070082 (html5lib update)
Thanks for looking into this. I see that this is assigned to me. I don't have time to work on python-rdflib anymore, sorry, so I can orphan this package within the Fedora pkg db and one of you can pick this up, if you like.
Hi Dave: For now I've added myself to the ACL lists, requesting commit and approveacl privileges. I'd be willing to co-maintain this with Pierre-Yves if he's willing. Some good news: Upstream has been very accommodating and have accepted my patch to unpin html5lib; they have also agreed to remove the strict dependency on SPARQLWrapper (including merging my patch to skip the remaining failing test) for the 4.1 series, in the hopes that we'll be able to package SPARQLWrapper in time for a 4.2 release. So we'll likely see a 4.1.1 release in the near future that will not require any patches from us. In the meantime, I'll start trying to pull together a python-sparqlwrapper package for review so that we'll be ready for rdflib 4.2.
Created attachment 869736 [details] Add Obsoletes entry for replacing python-rdfextras Per previous discussion, add an Obsoletes entry to the spec file to indicate that this package replaces python-rdfextras.
Dan, could you maybe provide your patches using git format-patch? Also, I see an Obsoletes but no provides :)
"repoquery --whatrequires python-rdfextras" says nothing requires python-rdfextras, and http://fedoraproject.org/wiki/Upgrade_paths_%E2%80%94_renaming_or_splitting_packages#Do_I_need_to_Provide_my_old_package_names.3F says "Providing your old package names is not necessary to create working upgrade paths. [...] Accumulating layers of compatibility rules in your spec file will only make it harder to understand and maintain by you and others." So I went with the option of not providing a Provides clause. In any case, I'll replace the current set of patches with a git format-patch series. I could just point at a git branch if that would be preferable to churn in this bug...
Created attachment 869936 [details] Update python-rdflib SPEC for RDFLib 4.1.0 release
Created attachment 869937 [details] Unpin html5lib version requirement
Created attachment 869938 [details] Make SPARQLWrapper optional require for 4.1
Created attachment 869939 [details] Add Obsoletes entry for replacing python-rdfextras
Upstream just merged https://github.com/RDFLib/rdflib/pull/368 (which is my patch for making SPARQLWrapper an optional require). When RDFLib upstream releases 4.1.1 we'll be able to simplify this patch series significantly.
The problem with git branch is that they cannot be deleted, so patch works. Do you think it worth updating now or should we wait for 4.1.1?
(In reply to Dan Scott from comment #11) > Hi Dave: For now I've added myself to the ACL lists, requesting commit and > approveacl privileges. I'd be willing to co-maintain this with Pierre-Yves > if he's willing. Dan: I've granted you "commit" and "approveacl" rights within the pkgdb.
(In reply to Pierre-YvesChibon from comment #20) > Do you think it worth updating now or should we wait for 4.1.1? At this point, upstream is being very responsive and is likely to issue a 4.1.1 (with additional bug fixes) in the near future, so let's wait for it. In the meantime, we can work on modifying the spec file to create a python3 variant of this package (as that's another big piece of support they added in the run up to 4.x). I assume that a python3-rdflib package will require a full review process?
Created attachment 870443 [details] Update python-rdflib SPEC for RDFLib 4.1.1 release Speaking of upstream 4.1.1, it was released last night. Upstream decided to revert the change that made SPARQLWrapper optional in the 4.1 branch at the last minute, and instructed us to go ahead and patch it. So I've uploaded a new patch that includes all of the 4.1.1 spec updates, plus the patch for making SPARQLWrapper optional, as a single squashed commit. Sadly my muscle memory also pushed my working branch to the Fedora git repo, so we now have an update-4.1.1 branch. *sigh*
Since you have commits rights, you might as well just push you change to the master branch. You can always commit now and build later when ducks are in order :)
(In reply to Pierre-YvesChibon from comment #24) > Since you have commits rights, you might as well just push you change to the > master branch. > > You can always commit now and build later when ducks are in order :) Fair enough... pushed to master :)
Hmm. Now that python-html5lib has been updated and pushed to stable, I put some more work into getting this ready to go (see latest pushes to master), but we're not ready yet. The problem is that scratch builds are failing at the testing stage because html5lib isn't being found, per http://kojipkgs.fedoraproject.org//work/tasks/3978/6623978/build.log, but http://kojipkgs.fedoraproject.org//work/tasks/3978/6623978/root.log shows the new python-html5lib being installed, and building locally works (the same tests pass locally). This has me scratching my head. I suppose it's possible that my local system is unclean and the rpm build environment is finding a source install of html5lib. I'll try on a clean Fedora VM tomorrow (although any more experienced advice is welcome).
On the bright side, I was able to reproduce the scratch build failure on a local mock environment. On the dark side, I'm no closer to figuring out why it fails to find html5lib; when I install the python-html5lib package locally I'm able to import html5lib and run simple scripts. Possibly something in the rdflib test setup munges the python path? Argh.
One more data point: when I run nosetests on a local copy of the rdflib 4.1.1 source tree, if I do not have python-html5lib installed then I get the same errors as we see in the mock builds. However, as soon as I install python-html5lib those errors go away. So something is definitely happening in the mock env to prevent rdflib from successfully importing html5lib. But I'm at a loss as to what the cause might be.
Comment on attachment 870443 [details] Update python-rdflib SPEC for RDFLib 4.1.1 release Now that we have commit rights to the repository, obsolete the out-of-date patch.
Quick update: The python-html5lib problem was resolved by a missing dependency. RDFLib 4.1.2 is coming, including several fixes that I contributed to upstream to support Python3. At that point, I'll produce a spec that builds both Python2 and Python3 versions of RDFLib. And then we should finally be able to close this :)
Koji is now building python-rdflib-4.1.2 (python2 only), so testing will be greatly appreciated.
python-rdflib-4.1.2-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/python-rdflib-4.1.2-1.fc20
Package python-rdflib-4.1.2-1.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing python-rdflib-4.1.2-1.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-5839/python-rdflib-4.1.2-1.fc20 then log in and leave karma (feedback).
python-rdflib-4.1.2-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.