15:01:41 <jreznik> #startmeeting kde-sig -- http://fedoraproject.org/wiki/SIGs/KDE/Meetings/2011-09-13
15:01:41 <zodbot> Meeting started Tue Sep 13 15:01:41 2011 UTC.  The chair is jreznik. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:41 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:48 <jreznik> #meetingname kde-sig
15:01:48 <zodbot> The meeting name has been set to 'kde-sig'
15:01:53 <jreznik> #topic roll call
15:02:04 <jreznik> who's present today?
15:02:12 * jsmith is lurking
15:03:04 <jreznik> I expect rdieter needs time to get ready after NYC trip
15:03:15 <jreznik> than is on vacations by oct 7
15:04:00 * rnovacek is here
15:04:22 <Kevin_Kofler> Present.
15:04:57 <jreznik> ltinkl, I see you here :)
15:05:00 <jreznik> ?
15:05:16 <jreznik> #chair Kevin_Kofler rnovacek ltinkl
15:05:16 <zodbot> Current chairs: Kevin_Kofler jreznik ltinkl rnovacek
15:05:46 <jreznik> #info jreznik, Kevin_Kofler, rnovacek present, ltinkl will join us in ten minutes
15:06:21 <jreznik> #info than is on PTO
15:06:30 <jreznik> #info agenda
15:06:38 <jreznik> #undo
15:06:38 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0x115e9b4c>
15:06:42 <jreznik> #topic Agenda
15:07:41 <Kevin_Kofler> Digikam 2.x (+ kipi stack backport in kdegraphics) for F15.
15:09:11 <jreznik> ok
15:10:05 <jreznik> ah, the wiki page is by one... sorry
15:11:18 <jreznik> let's start, ltink will join us soon
15:11:28 <jreznik> #topic 4.7.1 status
15:12:52 <Kevin_Kofler> Uhm, what's the status there?
15:13:07 <jreznik> than has been working on it
15:13:14 <Kevin_Kofler> Than had imported the stuff before going on vacation, but I haven't seen builds issued since.
15:13:24 <jreznik> but looks like the last thing he tried was kdelibs build
15:13:28 <jreznik> but it failed
15:13:34 <jreznik> http://koji.fedoraproject.org/koji/buildinfo?buildID=262410
15:13:37 <Kevin_Kofler> We need to start building the stuff.
15:14:07 <rnovacek> I can start building it tomorrow
15:14:09 <jreznik> undefined reference to `sem_timedwait' etc
15:15:22 <jreznik> #info than imported 4.7.1, kdelibs build fail
15:15:31 <jreznik> #action rnovacek to start building 4.7.1
15:15:57 <jreznik> it leads me to the two bugs and 4.7.1 for f16
15:16:08 <Kevin_Kofler> Missing includes, or maybe missing *_SOURCE define.
15:16:17 <Kevin_Kofler> (_GNU_SOURCE or whatever)
15:17:19 <jreznik> ok
15:17:25 <Kevin_Kofler> Maybe it needs the flag to enable pthreads.
15:17:53 <Kevin_Kofler> Something needs to be fixed in that kdecore/util/kshareddatacache_p.h header in any case.
15:18:30 <jreznik> rnovacek: can you take a look?
15:18:35 <rnovacek> jreznik: sure
15:18:45 <jreznik> thanks
15:19:02 <Kevin_Kofler> I'd check first of all whether #include <semaphore.h> is present.
15:19:19 <Kevin_Kofler> It's supposed to be there.
15:20:15 <jreznik> today is beta change deadline, so we missed it for f16 and looks like it will take a day, two for builds and then f16 merges
15:20:46 <jreznik> mitr asked me about f16 as he wants user id fixes land there...
15:20:55 <rnovacek> should I build it for f16 too?
15:20:59 <jreznik> we have it in master only (and not all)
15:21:12 <Kevin_Kofler> rnovacek: I'd say, build it in Rawhide first, then in F16.
15:21:54 <jreznik> .bug 732830
15:21:57 <zodbot> jreznik: Bug 732830 Use /etc/login.defs to define a 'system' account instead of hard-coding 500 (kdebase-workspace) - https://bugzilla.redhat.com/show_bug.cgi?id=732830
15:22:08 <jreznik> .bug 717115
15:22:10 <zodbot> jreznik: Bug 717115 Use /etc/login.defs to define a 'system' account instead of hard-coding 500 (kde-settings) - https://bugzilla.redhat.com/show_bug.cgi?id=717115
15:26:13 <Kevin_Kofler> We need to build a new kde-settings for that stuff.
15:26:49 <Kevin_Kofler> FWIW, kde-settings trunk also has the change to bring up a folder view by default for new users. I could remove it again, but I don't think that's a good idea if we don't have another way to display liveinst by default. :-/
15:27:08 <Kevin_Kofler> (We already missed the beta with that fix. :-( That's my fault, I had forgotten about that issue.)
15:28:14 <rnovacek> so I'll apply those patches from mitr before issuing the build
15:30:03 <jreznik> we have to assure it will land to f16 asap (but no beta probably, or maybe try nih?)
15:32:38 <Kevin_Kofler> Oh, if you update kde-settings for F16, please don't add the Source1 from Rawhide without discussing that with me first. Adding the Plasma autoreq/autoprov stuff without rebuilding the core Plasma packages against it is a surefire way towards broken deps.
15:33:04 <zodbot> Announcement from my owner (jsmith): Fedora Board public IRC meeting in #fedora-board-meeting in approximately 30 minutes
15:33:32 <rnovacek> Kevin_Kofler: ok
15:35:02 <Kevin_Kofler> Anything else about 4.7.1? Otherwise, I'd suggest moving on…
15:35:18 <jreznik> move on
15:35:30 <jreznik> #topic Qt 4.7.4 status
15:36:08 <jreznik> there's one issue reported in Bodhi - there are no styles for documentation mentioned, I have to check that...
15:36:17 <Kevin_Kofler> https://admin.fedoraproject.org/updates/qt
15:36:28 * jreznik is busy with security issue in qt, fixed by 4.7.4 :)
15:36:53 <ltinkl> jreznik: yup, just noticed the qt HTML docu is misrendered
15:37:51 <Kevin_Kofler> Ugh, can't they even release a bugfix point release without breaking stuff? Hmmmph…
15:38:45 <jreznik> #info documentation problems in Qt 4.7.4
15:38:47 <Kevin_Kofler> There's also a complaint about unresolved symbols from cyrushmh, but I suspect he has an incompatible Qt sitting somewhere (the usual problem, proprietary crap bundling ancient Qt binaries).
15:39:08 <jreznik> ltinkl: could you take a look on docs problem?
15:39:10 <Kevin_Kofler> Still, it should be checked, silent ABI breakage would be very bad.
15:39:14 <ltinkl> jreznik: yup
15:39:22 <jreznik> Kevin_Kofler: yep, it has to be checked
15:39:33 <Kevin_Kofler> _ZN9QListData11detach_growEPii
15:39:38 <ltinkl> jreznik: looks like the CSS styles got omitted when packaging
15:40:01 <jreznik> ltinkl: yep
15:40:08 <Kevin_Kofler> Translated from g++ese to human, that's: QListData::detach_grow(int*, int)
15:40:30 <rnovacek> I just checked and it seems that Qt 4.8 has broken css too
15:40:53 <ltinkl> rnovacek: so the tarball might be broken
15:41:11 <Kevin_Kofler> rnovacek: Is the CSS broken or is the Assistant built without CSS support?
15:41:16 <ltinkl> otherwise we'd get missing files errors when building it
15:41:28 <Kevin_Kofler> If Assistant is built without QtWebKit, it uses a crappy HTML viewer with almost no CSS support.
15:41:44 <ltinkl> Kevin_Kofler: nope, the docu misses the CSS files, also the plain html version in /usr/share/doc/qt4/html/
15:41:44 <rnovacek> Kevin_Kofler: how can I check that?
15:41:46 <Kevin_Kofler> (Incidentally, that could be how the breakage went unnoticed, if they tested it with such a build only.)
15:42:11 <Kevin_Kofler> ldd `which assistant-qt4`
15:42:22 <ltinkl> /usr/share/doc/qt4/html/style/ is empty
15:42:31 <Kevin_Kofler> Also in 4.8?
15:42:38 <Kevin_Kofler> Looks like they broke something in their release process, then.
15:42:54 <rnovacek> Kevin_Kofler: http://fpaste.org/noFg/
15:42:57 <ltinkl> <link rel="stylesheet" type="text/css" href="style/style.css" />
15:43:05 <ltinkl> style.css missing then :)
15:43:22 <Kevin_Kofler> But why is it missing?
15:43:27 <ltinkl> no idea
15:43:32 <ltinkl> I will check
15:43:44 <rnovacek> /usr/share/doc/qt4/html/style/ empty with 4.8 too
15:43:45 <Kevin_Kofler> Did they remove it from git? (WHY?) Or did it come from elsewhere and they broke that script?
15:44:31 <Kevin_Kofler> rnovacek: That Assistant is also built without WebKit support (in addition to the missing .css file).
15:44:58 <Kevin_Kofler> Splitting QtWebKit from Qt isn't as easy as we are doing it now in our 4.8 packaging.
15:45:45 <Kevin_Kofler> Either we have to BR qt-webkit-devel in qt (circular dep, yay!) and patch Assistant to link against the installed QtWebKit, or we have to go back to building the bundled QtWebKit (and possibly throwing it away, ugh).
15:46:16 <Kevin_Kofler> Or we decide to ship the non-WebKit Assistant, but we already reverted that once because some docs really look like crap in it.
15:48:25 <jreznik> uf
15:50:18 <Kevin_Kofler> Or we also build Assistant from a separate SRPM.
15:50:44 <Kevin_Kofler> (That's possibly the cleanest solution, though it'd mean either extracting it from Qt's tarball or use the whole huge Qt tarball as the Source.)
15:51:06 <jreznik> Kevin_Kofler: +1 cleanest but how to split it from tarball
15:51:23 <Kevin_Kofler> Script?
15:51:24 <ltinkl> jreznik: will it not change with Qt 5.0?
15:51:35 <jreznik> ltinkl: but there's no qt 5 right now :)
15:51:40 <Kevin_Kofler> That said, tampering with upstream tarballs is frowned upon when not needed for legal reasons…
15:51:59 <ltinkl> I know but still, using the same tarball isn't a big issue here, it's side cached anyway
15:52:03 <Kevin_Kofler> But shipping a huge multi-hundred-MiB tarball for a few KiB doesn't make sense.
15:52:22 <Kevin_Kofler> ltinkl: The cache is per package, and there's also the SRPMs.
15:52:29 <ltinkl> right
15:55:18 <Kevin_Kofler> But this Assistant issue doesn't affect 4.7.4, only 4.8.
15:55:28 <Kevin_Kofler> (Our 4.7.4 is built with the bundled QtWebKit.)
15:55:43 <Kevin_Kofler> Anything else about 4.7.4?
15:56:18 <jreznik> probably all, we have to check the missing symbols and missing styles
15:56:35 <jreznik> #action to check missing symbols and missing styles (ltinkl)
15:56:45 <jreznik> #topic digikam 2.1 for f15
15:56:58 <jreznik> (last 4 minutes, so be quick Kevin_Kofler;-)
15:57:00 <ltinkl> jreznik: the missing symbol... most probably a local breakage
15:57:10 <Kevin_Kofler> ltinkl: I think so too.
15:57:33 <jreznik> ltinkl: but you know - it could be broken ABI... of course I think it's just local issue
15:57:34 <Kevin_Kofler> So as I said this week on #fedora-kde, I'd like to backport the kipi stack from kdegraphics 4.7.x to our 4.6.5 package so we can upgrade Digikam to the current 2.x versions (currently 2.1.1) in F15.
15:57:54 <Kevin_Kofler> jreznik and rdieter said they're OK with it.
15:57:59 <jreznik> Kevin_Kofler: how much work is it? how intrusive?
15:58:26 <jreznik> but I'm ok with it (but as we have 4.7.1 f15 repo it could land there if too much hassle with it)
15:58:28 <Kevin_Kofler> Probably not much work, just a question of untarring and making a big diff -Nur for a big patch blob.
15:59:04 <Kevin_Kofler> Revdeps may have to be rebuilt though, if the sonames changed (as I suspect).
15:59:44 <Kevin_Kofler> I'll figure out what happened to the sonames and what'd have to be rebuilt first of all.
16:00:04 <Kevin_Kofler> (other than Digikam itself, obviously, I want to upgrade that one anyway)
16:01:28 <nucleo> Some users reports about problems with database after updating from digikam 1 to digikam 2.
16:01:49 <Kevin_Kofler> I've already done this once (but that was in the good old SVN days where I could just svn diff tags/KDE/4.n.5 tags/KDE/4.n+1.0 without untarring everything, git sucks).
16:02:00 <Kevin_Kofler> (done the kdegraphics libs backport, that is)
16:02:02 <jreznik> Kevin_Kofler: ^^^ it has to be tested - db migration
16:02:26 <Kevin_Kofler> nucleo: Are you sure it was from 1 to 2 and not from 2.0 to 2.1.0?
16:02:46 <Kevin_Kofler> There are complaints about 2.1.0 having broken database migration, and 2.1.1 was released to fix it, or so they claim.
16:03:38 <nucleo> after update 2.0 to 2.1 digikam can't start but there was other thread before on mailing list about migrating from 1.8 to 2.0
16:03:43 <Kevin_Kofler> If the new Digikam really breaks the world, then I guess we'd better not touch it. :-(
16:04:13 <nucleo> http://mail.kde.org/pipermail/digikam-users/2011-September/014256.html
16:04:50 <nucleo> I mean thread in mailing list
16:06:08 <Kevin_Kofler> The complainant there said that he had the same issue already with previous "major" (I suppose he means the digit after the '1') migrations.
16:06:25 <Kevin_Kofler> (For me, major is only 0 to 1 and 1 to 2. :-) )
16:06:31 <nucleo> maybe this is not 2-specific
16:07:19 <jreznik> ok, guys, we are out of time
16:07:40 <jreznik> I expect the decision should be done based on research on db corruption, otherwise I'm ok
16:08:09 <jreznik> and of course, we would have to find solution for f15->f16 migration - it's bad to destroy library in a library app
16:08:58 <jreznik> any objections? otherwise I end meetings...
16:10:37 <jreznik> #endmeeting