Hello everyone, I've been looking at becoming a packager. I've yet to find software I need that isn't in fedora yet. I just found one I think.
http://code.google.com/p/wkhtmltopdf/
It is based off of qt4 and webkit. Small source files, cmake build system. I can't find it in the repos anywhere. Would this be a good first package? I'll be using this for a couple of projects to convert html to pdf with much less hassle than ever before.
Thoughts?
go ahead
On Fri, Sep 11, 2009 at 7:23 PM, Nathanael D. Noblet nathanael@gnat.ca wrote:
Hello everyone, I've been looking at becoming a packager. I've yet to find software I need that isn't in fedora yet. I just found one I think.
http://code.google.com/p/wkhtmltopdf/
It is based off of qt4 and webkit. Small source files, cmake build system. I can't find it in the repos anywhere. Would this be a good first package? I'll be using this for a couple of projects to convert html to pdf with much less hassle than ever before.
Thoughts?
-- Nathanael d. noblet
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Nathanael D. Noblet wrote:
Hello everyone, I've been looking at becoming a packager. I've yet to find
software I
need that isn't in fedora yet. I just found one I think.
http://code.google.com/p/wkhtmltopdf/
It is based off of qt4 and webkit. Small source files, cmake
build
system. I can't find it in the repos anywhere. Would this be a
good
first package? I'll be using this for a couple of projects to
convert
html to pdf with much less hassle than ever before.
Thoughts?
Looking through the code, it looks like the #ifndef stuff for things called "extensive hacks" could cause some issues, but that's a cursory glance at it. I'm also not sure what to make of the patches for Qt in its repository. If they're serious patches, they should clone Qt on Gitorious and create merge requests. Fedora's Qt probably won't ship with them without some oversight that they aren't breaking things.
Overall, it looks simple for a first package (though it's using qmake, not CMake). I haven't packaged anything that uses qmake myself, but more complex projects can quickly get too hard to deal with in qmake.
If you're looking for other software to package, there is a wishlist on the wiki[1].
- --Ben
[1]https://fedoraproject.org/wiki/Package_maintainers_wishlist
Ben Boeckel wrote:
Looking through the code, it looks like the #ifndef stuff for things called "extensive hacks" could cause some issues, but that's a cursory glance at it. I'm also not sure what to make of the patches for Qt in its repository. If they're serious patches, they should clone Qt on Gitorious and create merge requests. Fedora's Qt probably won't ship with them without some oversight that they aren't breaking things.
At least part of their patches look like really awful hacks, e.g. they're making some of QtGui work without X11 to support their stuff being used in text mode despite using QtWebKit (which is normally a GUI component). Some of the patches also appear to break ABI compatibility.
This really needs to be made to work with unmodified upstream Qt (even if it means requiring an active X11 session). Some of the patches might be upstreamable, with or without additional required fixes (like maintaining binary compatibility), but others are just plain "no go"s.
Kevin Kofler
On Fri, Sep 11, 2009 at 9:03 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Ben Boeckel wrote:
Looking through the code, it looks like the #ifndef stuff for things called "extensive hacks" could cause some issues, but that's a cursory glance at it. I'm also not sure what to make of the patches for Qt in its repository. If they're serious patches, they should clone Qt on Gitorious and create merge requests. Fedora's Qt probably won't ship with them without some oversight that they aren't breaking things.
At least part of their patches look like really awful hacks, e.g. they're making some of QtGui work without X11 to support their stuff being used in text mode despite using QtWebKit (which is normally a GUI component). Some of the patches also appear to break ABI compatibility.
I'd try adding a shell script wrapper which just does:
if test -z "$DISPLAY"; then exec xvfb-run /usr/libexec/foo/real-binary else exec /usr/libexec/foo/real-binary fi
Then you just need a dep on xorg-x11-server-Xvfb
Incidentally, I'd like to change the OS so that you *always* have a DISPLAY (and DBUS_SESSION_BUS_ADDRESS), the first step of which would probably just be a pam_session module that asks ConsoleKit if your uid currently has a login, and if so pulls those bits in.
On Sep 11, 2009, at 7:03 PM, Kevin Kofler wrote:
Ben Boeckel wrote:
Looking through the code, it looks like the #ifndef stuff for things called "extensive hacks" could cause some issues, but that's a cursory glance at it. I'm also not sure what to make of the patches for Qt in its repository. If they're serious patches, they should clone Qt on Gitorious and create merge requests. Fedora's Qt probably won't ship with them without some oversight that they aren't breaking things.
At least part of their patches look like really awful hacks, e.g. they're making some of QtGui work without X11 to support their stuff being used in text mode despite using QtWebKit (which is normally a GUI component). Some of the patches also appear to break ABI compatibility.
This really needs to be made to work with unmodified upstream Qt (even if it means requiring an active X11 session). Some of the patches might be upstreamable, with or without additional required fixes (like maintaining binary compatibility), but others are just plain "no go"s.
Yeah, I saw their patches, but didn't look at any of the actual code. Since I know you are an avid KDE/Qt consumer, perhaps I can ask you for some information about this program and if a better way to accomplish what it is doing exists.
I write web apps, often I want to provide a pdf output of the nicely designed / styled html. This becomes difficult because I'm writing from the webserver's perspective, not a browser/rendering engine. This solves the problem very nicely for me in that it lets a rendering engine have a go at the html and then outputs the pdf. It works wonderfully in my tests. Obviously they are using the webkit/qt bindings to do this. Would there be a way to use those without the qt hacks they are introducing?
If so I don't mind getting my hands dirty to look, my C/C++ skills are a bit rusty but I've always enjoyed it, and this is an itch I've been trying to scratch for a couple years now. So would feel great if it could be solved and become part of fedora.
Nathanael D. Noblet wrote:
Hello everyone, I've been looking at becoming a packager. I've yet to find software I need that isn't in fedora yet. I just found one I think.
http://code.google.com/p/wkhtmltopdf/
It is based off of qt4 and webkit. Small source files, cmake build system. I can't find it in the repos anywhere. Would this be a good first package? I'll be using this for a couple of projects to convert html to pdf with much less hassle than ever before.
Thoughts?
I wouldn't start by finding just any project to try your hand at packaging. Packaging requires some level of continuing commitment to support. I wouldn't do that unless you feel some personal desire to support that package. Instead, find something you are really interested in.