Description of problem:
Fedora 9 has no package for OpenGTL, nor is there currently any in Koji. OpenGTL
is required for a fully-functioning KOffice 2. Please add OpenGTL to Fedora 10.
Are you willing to maintain it?
I might be if I could *build* it: cpack rpm generator doesn't want to work and
in four days of asking no one has answered my pleas for help. (Also, it's
currently unbuildable because of bug 455502 ;-).) However I don't know enough
what is involved in maintaining an rpm - especially from something cmake-based -
to give an educated answer.
(And if I'm not... krita2 is condemned to be broken?)
I'll see about whipping something up.
Matthew, if I got the ball rolling here, would you be interested in helping
comaintain the package?
Err, when saying that, I kinda forgot that akademy is coming up real fast, so my
free time in the short term may be insufficient to get this out until after I
Ok, I'll try to take a look when I get time. Meanwhile, with Eric Noulard's help
I managed to get cpack working; I have a usable RPM but said RPM is in gross
violation of about half of Fedora's packaging policies. My initial impression is
that it won't be possible to use cpack to make Fedora RPM's (though, I'm not
sure it would be desired anyway).
IOW I have a work-around for now so the urgency (for me, anyway) isn't quite so
high, but we still need a proper RPM for the eventual Fedora inclusion of
KOffice2. (And it would be very awesome if Fedora devs had an /official/ RPM, as
it seems there currently is not any official one for /any/ distro.)
Bug 455502 is still high priority, since it's blocking *any* build of OpenGTL on
Created attachment 312796 [details]
.spec for OpenGTL package
Ok, looks like I'll be trying out the maintainer hat. I don't have an account
set up yet (will get to it as soon as I have time), but meanwhile here's the
.spec. No patches currently, so it should be trivial to build after wget'ting
the upstream source tarball, but note that bug 455502 is still blocking (so
expect it to fail on x86_64 unless using CyrilleB's rpm).
Packaging note: last I checked, the non-OpenCTL implementation of painterly
colorspaces in krita2 (koffice 2.0+) was buggy (read: it crashed if you tried to
use it). I haven't checked if the situation is improved, but IIRC there was talk
about making OpenGTL a hard requirement for painterly spaces. Thus, we (Fedora)
need OpenGTL to prevent feature loss and/or stability issues.
Additionally, since the OpenGTL developer (Cyrille Berger) is also one of the
main krita developers, the level of dependency is likely to increase.
(In reply to comment #7)
> Created an attachment (id=312796) [details]
> .spec for OpenGTL package
> Ok, looks like I'll be trying out the maintainer hat. I don't have an account
We can get the review rolling with a pre-review, even before you organize the fedoraproject account.
I'm sure you found the packaging guidelines in:
And you should be referring to the process in:
, so please post the .spec and .src.rpm somewhere on the web, and explicitly provide the links in this bug, in the requested format, ie with description, and rpmlint status. Failing to perform the elementary stuff might suggest you aren't following these docs, which will make it difficult for both reviewers and yourself to get the package into an acceptable form.
In my view there are many reasons for the review:
- show that you have read/understood the guidelines
- ensure readable, maintainable, quality, integrated fedora packages
- that you would plan to babysit the package, rather than dump and run.
If you feel that parts of your spec may not meet the guidelines, show this knowledge by pointing those specific areas as you find them. There are many experience packager maintainers who can provide tips and improvements, to someone who shows they have a better Fedora as the goal, so good luck :-)
Created attachment 313729 [details]
.spec for OpenGTL package
fix missing defattr, fixes rpmlint errors against srpm
> We can get the review rolling with a pre-review, even before you organize the
I have an account, but the CLA may need to go through my company's legal dept... otherwise so far I haven't done anything but create it.
> And you should be referring to the process in:
> so please post the .spec and .src.rpm somewhere on the web, and explicitly
provide the links in this bug,
The .spec is already here: https://bugzilla.redhat.com/attachment.cgi?id=313729
I don't have anywhere to put the SRPM (and/or haven't figured out / set up FAS), but it's easily created:
cd ~/rpmbuild/SOURCES ; wget http://www.opengtl.org/download/OpenGTL-0.9.4.tar.bz2
cd ~/rpmbuild/SPECS ; wget https://bugzilla.redhat.com/attachment.cgi?id=313729
cd ~/rpmbuild/SPECS ; rpmbuild -bs OpenGTL.spec
(in appropriate directories, of course)
Or, is 163k small enough to just dump the SRPM in here as an attachment, also?
> in the requested format, ie with description,
and rpmlint status.
D'oh! Sorry about that! Trying again...
~/rpmbuild/RPMS/x86_64$ echo *
OpenGTL-0.9.4-1.fc9.x86_64.rpm OpenGTL-debuginfo-0.9.4-1.fc9.x86_64.rpm OpenGTL-devel-0.9.4-1.fc9.x86_64.rpm OpenGTL-libs-0.9.4-1.fc9.x86_64.rpm
~/rpmbuild/RPMS/x86_64$ rpmlint *
OpenGTL-devel.x86_64: W: no-documentation
OpenGTL-libs.x86_64: W: no-documentation
4 packages and 0 specfiles checked; 0 errors, 2 warnings.
~/rpmbuild/SRPMS$ rpmlint OpenGTL-0.9.4-1.fc9.src.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
I'm not sure if the no-documentation warning is interesting? Should I just copy the same doc to -devel, -libs? Or is there a "normal" way to handle this I'm not familiar with?
Other than the above warnings, I've tried to follow the specs as close as possible (and as far as I can tell, I'm ok w.r.t. the ReviewGuidelines checklist), but as you know this is still my first package, so I'm still feeling my way around :-).
Note: I can't conveniently test with mock right now as I'm on x86_64 (see blocking bug 455502). I'm building locally with a fixed llvm package from Cyrille Berger. When I get time, I'll test it on my other (i686) machine that should build with the current rawhide llvm package.
(In reply to comment #11)
> > so please post the .spec and .src.rpm somewhere on the web, and explicitly
> provide the links in this bug,
> The .spec is already here: https://bugzilla.redhat.com/attachment.cgi?id=313729
> I don't have anywhere to put the SRPM (and/or haven't figured out / set up
> FAS), but it's easily created:
You could use a public upload server like: http://filebin.ca/, and post the link back here, please.
Note: As I understand this is your first fedora package, the official review needs to be performed by a fedora sponsor; in the meantime I should be able to give some comments to help whip the package into shape if it needs it.
The Fedora project can provide hosting if you have an account set up; you just need to ask and someone can flip the switch that will get things set up. However, that can't be done until the CLA is completed. In fact, I'd say this review might be a bit premature until you get past the CLA, because if you can't sign it due to issues with your company then you can't contribute packages to Fedora.
fyi, koffice2 has been retargetted for F11 (at upstream's request).
otherwise, anxiously awaiting progress on the cla front.
So this package recently popped back into the review queue when the bug blocking it was cleared. However, I don't see any package to review here, and the submitter still hasn't gotten past the CLA. Is anything happening with this package? Should this ticket just be closed?
*Someone* needs to package it, but I'm not going to be able to sign a CLA at my current employer.
Then I'll close this as there's no package to review.
So should I open another bug that the package is missing, or what?
Yeah, when if we have someone willing/able to maintain this, I'd suggest opening a new and proper review. Matthew, if you've got anything newer than what's posted here already, please send it my way...
I'll get round-tuit before f12 (when koffice2 is estimated to land in fedora), unless someone else beats me to the punch.
OK, the updated stuff, and submitted a new OpenGTL review, bug #521166
*** This bug has been marked as a duplicate of bug 521166 ***