K3B 1.68 and EasyRPM

[Diego]

Hello everybody!

I updated K3B using kde-unstable from 1.66 to 1.68 and now, when I try 
to start it I get (if I start it from the command line, elseway it fails 
silently) this error and it doesn't start:

k3b: symbol lookup error: /usr/lib/libk3b.so.6: undefined symbol: 
_ZNK16QAbstractSpinBox16inputMethodQueryEN2Qt16InputMethodQueryE

Any clue anyone?

On another unrelated note, if you haven't noticed yet there's a new Qt 
4.x tool to ease the process of creating rpm specs:
http://kde-apps.org/content/show.php/EasyRPM?content=114271&PHPSESSID=8c...
Hope it helps! :)

Regards,
Diego

[Kevin Kofler]

Diego wrote:
> I updated K3B using kde-unstable from 1.66 to 1.68 and now, when I try
> to start it I get (if I start it from the command line, elseway it fails
> silently) this error and it doesn't start:
>
> k3b: symbol lookup error: /usr/lib/libk3b.so.6: undefined symbol:
> _ZNK16QAbstractSpinBox16inputMethodQueryEN2Qt16InputMethodQueryE
>
> Any clue anyone?

It's probably built against the Qt 4.6 beta also in kde-unstable.

Kevin Kofler

[Rex Dieter]

On 10/25/2009 01:44 PM, Diego wrote:
> Hello everybody!
>
> I updated K3B using kde-unstable from 1.66 to 1.68 and now, when I try
> to start it I get (if I start it from the command line, elseway it fails
> silently) this error and it doesn't start:
>
> k3b: symbol lookup error: /usr/lib/libk3b.so.6: undefined symbol:
> _ZNK16QAbstractSpinBox16inputMethodQueryEN2Qt16InputMethodQueryE

rpm -q k3b qt
please.

fyi, stuff in kde-unstable is not included in any buildroots, in 
general... I'm trying my best to avoid qt-4.6 dependencies for stuff 
(except where absolutely required, like arora).

-- Rex

[Kevin Kofler]

Diego wrote:
> On another unrelated note, if you haven't noticed yet there's a new Qt
> 4.x tool to ease the process of creating rpm specs:
> http://kde-apps.org/content/show.php/EasyRPM?content=114271
> Hope it helps! :)

Uh, no, that really doesn't help. Don't touch this even with a 10-foot pole!
* This is just a form which makes you fill in the .spec sections. I don't 
see how that makes things any easier than filling them in directly in the 
specfile. You still have to type in all your file lists by hand.
* The form is missing several important specfile sections, such as %post and 
%postun scriptlets. There doesn't even seem to be support for subpackages!
* Like most other specfile generators, it won't generate specfiles which are 
compliant to our guidelines. For example, License is a dropdown, you can't 
type in a compliant License tag and those it offers are not compliant ("GPL 
v2" with a space is not allowed, you have to write "GPLv2", or "GPLv2+" if 
that's what it actually is). It also wants to fill in Distribution in the 
specfile which is also not allowed by our guidelines (the build system fills 
it in). And the example in the screenshot uses hardcoded paths like /usr/bin 
instead of macros like %{_bindir}.
* The tool offers you to run rpmbuild directly, and only that. No mock. Also 
no rpmlint or anything like that.
* Its own RPM gets rpmlint complaints according to the comments on kde-
apps.org, which says about all about the quality of the specfiles it 
generates.

Packaging is NOT easy, don't trust tools which claim to make it easy!

Kevin Kofler