Latest upstream release: 0.3.1 Current version/release in Fedora Rawhide: 0.3.0-2.fc20 URL: http://xkbcommon.org/download/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring
Latest upstream release: 0.3.2 Current version/release in Fedora Rawhide: 0.3.1-1.fc21 URL: http://xkbcommon.org/download/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring
Latest upstream release: 0.4.0 Current version/release in Fedora Rawhide: 0.3.1-1.fc21 URL: http://xkbcommon.org/download/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring
Latest upstream release: 0.4.1 Current version/release in Fedora Rawhide: 0.4.0-1.fc21 URL: http://xkbcommon.org/download/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring
0.4.2 is available now too. Hi, seems (qt5) qtbase wants xkbcommon >= 0.4.1, so would you mind updating rawhide from 0.4.0 please? (or, I could help do it, if you have no objections)
updated 0.4.2 .spec, src.rpm, and commit/diff from current master/ branch: http://rdieter.fedorapeople.org/rpms/libxkbcommon/ scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=6875578
Looks like my intended scratch build, ended up not being scratch... sorry about that. If you *do* update, probably best to bump to 0.4.2-2
Latest upstream release: 0.4.2 Current version/release in Fedora Rawhide: 0.4.0-1.fc21 URL: http://xkbcommon.org/download/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring
Hi Rex, Peter is a bit busy atm, so I'm jumping in for him now. In general you can always ping either me or Peter for input related issues. Thanks for the spec patch, esp. the cleanups. I've just started a 0.4.2-2 build for rawhide based on your patch. Interesting what you did with the non scratch srpm build. You should report that to rel-eng I guess, I don't think you're supposed to be able to do non-scratch build from anything but a git tag. Do you need a newer libxkbcommon in F-20 too ? Regards, Hans
Thanks. I discussed the issue with releng/koji-admins. Wrt F-20, *need* is probably a strong word, but nice-to-have (else, qt5-qtbase requires using some bundled code). understand too othat xkbcommon-x11 requires xcb-xkb >= 1.10 and f20 currently has libxcb-devel-1.9.1-3.fc20
(In reply to Rex Dieter from comment #9) > Thanks. > > I discussed the issue with releng/koji-admins. > > Wrt F-20, *need* is probably a strong word, but nice-to-have (else, > qt5-qtbase requires using some bundled code). understand too othat > xkbcommon-x11 requires xcb-xkb >= 1.10 I've discussed this, and unfortunately we cannot bump libxcb in F-20 because of soname changes which would then trigger a large amount of rebuilds. So sorry, but I'm afraid we cannot update libxcbcommon in F-20.
xcb-xkb is an optional dependency og libxkbcommon 0.4.x, only used for "support for creating keymaps with the X11 protocol", a feature that's new in 0.4.x. The libxkbcommon 0.3.1 currently in F20 doesn't even HAVE that feature. Therefore, it should be fine to just build libxkbcommon 0.4.2 without libxcb support in F20. And I don't agree with Rex Dieter's assertion that "*need* is probably a strong word, but nice-to-have": per our packaging guidelines, bundled libraries are not allowed and thus Qt 5.3 cannot be shipped in F20 without the updates libxcbcommon. (The update currently in testing is in blatant violation of the packaging guidelines.)
*without the updated libxkbcommon (2 typos in one noun phrase, oops)
Kevin, it would appear qtbase wants libxkbcommon-x11 too
Looking closer at it, it's a big mess: It looks like Qt 5.3 does use the new libxkbcommon-x11 support, but I'm still trying to figure out whether and how it gets built, the libxcb on F20 being supposedly too old.
http://kojipkgs.fedoraproject.org//packages/qt5-qtbase/5.3.0/3.fc20/data/logs/x86_64/build.log does NOT build the libxkbcommon-x11 support, src/x11/keymap.c is not getting built. (That's the file my scratch build of libxkbcommon against the old xcb-xkb failed on: http://kojipkgs.fedoraproject.org//work/tasks/1968/6891968/build.log )
OK, so possibly qtbase's configure check for libxkbcommon-x11 is wrong?
had a look at the commits since 0.3.1 and it is API/ABI compatible with 0.4.2. So yes, we could build this without libxkbcommon-x11 support in F20 if that fixes your issues.
Let us figure out what exactly Qt wants first. The code looks like there is an expectation that libxkbcommon-x11 is available, but building it with the bundled libxkbcommon simply does not build libxkbcommon-x11 if the libxcb is too old. I also see -DQT_NO_XKB in the build.log. So I think the .pro/.pri files in qt5-qtbase are seriously messed up. :-(
Confirmed qtbase-5.3.0 can build against libxkbcommon-0.4.2 only. So, any libxkbcommon-0.4.2 update for f20 (and f19) would be welcome and usable in future qtbase-5.3.0+ builds. Just committed, %changelog * Tue May 27 2014 Rex Dieter <rdieter> - 0.4.2-3 - make -x11 support conditional (f21+, #1000497) here too, so should be mergeable back to older branches for this purpose.
Kevin's a bit right too it seems, qtbase-opensource-src-5.3.0/src/plugins/platforms/xcb/ references xkbcommon-x11 headers too (without -DQT_NO_XKB). Looks like I need a little more work on making qtbase-5.3.0 ready for this.
I think we can probably make qtbase-5.3.0 work with whatever libraries we have by just reverting some of the 5.3 changes (conditionally for F20-). I suppose that might also help EL*.
Note, once you guys have figured out what you want, let me know if I need to do a libxkbcommon-0.4.2 build for F-20 (without the xcb bits that is).
> Note, once you guys have figured out what you want, let me know if I need to do > a libxkbcommon-0.4.2 build for F-20 (without the xcb bits that is). So the update is, yes please: We need a version ≥ 0.4.1 for the new xkb_state_key_get_utf8 function: https://bugs.freedesktop.org/show_bug.cgi?id=75892 which we need to fix this nasty Qt 5 bug: https://bugreports.qt-project.org/browse/QTBUG-36281 (more precisely, to revert the reversion of the change that fixes the bug). The bug breaks Ctrl+key combinations in Qt 5 apps, which makes e.g. the KF5 port of Konsole suck badly.
libxkbcommon-0.4.3-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/libxkbcommon-0.4.3-2.fc20
Package libxkbcommon-0.4.3-2.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 libxkbcommon-0.4.3-2.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-12552/libxkbcommon-0.4.3-2.fc20 then log in and leave karma (feedback).
libxkbcommon-0.4.3-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.