Re: [Development] Qt 5 and old versions of XCB
On domingo, 18 de março de 2012 12.03.17, craig.sc...@csiro.au wrote: I'm sorry, but we can't keep supporting very old systems. By the time of the release, OpenSUSE 11.1 will be 18 months old or older. Wow. are you suggesting that we're only interested in ensuring Qt5 runs on systems that 18 months old or newer? That's going to make a lot of enemies. No, 18 months is a bit too short. But 2 or 2½ years seems better. I asked about xcb on the LSB mailing list and early responses suggest that although xcb has been mentioned there before, it doesn't sound like it's progressed much beyond that. Dropping support for xlib and relying on xcb would thus make Qt5 a non-starter for some people. No one is working on xlib and it's not a reference platform. XCB is and it's been around for years. Not arguing with you on this one. But my question is how consistent is xcb support across the major linux distributions? If ISV's can't build a binary that they can reliably distribute, that's going to be a serious road block for them to move to Qt5. Support is pretty much consistent. Every Linux distro uses X.org, which uses XCB. As for LSB, it's a matter of it being stuck in time in 2006/2007. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Removal of xlib plugin - a possible disaster.
http://codereview.qt-project.org/#change,20091 My negative review of the Change comes out of 3 facts: (1) I have personally experienced the yet-to-be-documented problem, with both widget and declarative-based example programs, in which the GUI never appears: The program crashes with SIGSEGV, probably when attempting to assign size hints for the main Window. For me, the problem began occurring in February- but I wasn't doing much with Qt on XCB platform plugin during late January, so the problem may have been created/exposed at an earlier time. In any case, it was happening 100% of the time with my Distro, Mageia-1. (I have new problem with Mageia-2, described as fact #3 below.) (2) That problem has been reported by others on IRC. I'm not capable of creating a tight search on Jira bugreports, but I didn't see a report for the problem. If someone can assist in that search, we'd be looking for xcb plugin, sigsegv crash, bug opened after the start of 2012. (3) Wondering if my Distro was too old, (and most of it's RPMs were built in April of 2011), I just upgraded to Mageia-2 beta-2. I no longer get SIGSEGV, but I get a problem which _could_ be closely related: referencing an Undefined Symbol related to WM hints. https://bugreports.qt-project.org/browse/QTBUG-24835 --- comments --- I can't think of a WORSE spectacle, for the reputation of Qt-Project, than the Release of an Alpha Build in which large numbers of exerpienced Qt users on Linux Linux _might_ be unable to use the XCB plugin and show a main Window, before getting some kind of 'ABEND', with _any_ of our own provided examples. Sending the Alpha out with xlib plugin removed would be like selling a car without an emergency brake: Yes, the main brake system is the one you should use, but if totally dies you have GOT to have another one. With these two bugs present (i.e. SIGSEGV happening on some older Distros, and Undefined Symbol happening on RPMs built just 6 days ago), you NEED to have an alternative, EASY plugin for these people to use. Even at alpha. Yes, the bugs should be documented, isolated, and fixed. But, from my own Test/Integration/Release career, I'd say that our choices for alpha are (A) leave the xlib plugin present, and maybe even make it build automatically on X11 systems; or (B) stop ignoring the IRC I'm getting 'segment fault' with an example program postings, and POSTPONE ALPHA until we've got them fixed. And I'd vote for alternative A -- keep the alpha schedule, but provide xlib as an alternative plugin. Just my opinion, but it's held pretty strongly. Since I have only ONE box, with ONE disk, I can't easily go back to mageia-1 to reproduced bug #1. But I'm pretty confident that some of our Qt5-Alpha-1 users will experience it, and their doco might help to pin it down pretty well. :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The qtbase CI should run the qtdeclarative tests
While it's not normal to do this type of dependency lock for upwards dependencies, i think in this case we should indeed do the extra checking. Not just because QtDeclarative is such an important tech for Qt5, but also because it's a very good test case for QtBase. The extra time used for checking both repos will give much greater stability as a whole. Maybe the fast platforms can do the extra checking, while slow platforms still handle only QtBase? At least we will capture most compile issues? (The CI rules might get very complicated though.) Rohan/Sergio, what will be the turn-around increase if we always test Declarative together with QtBase? Thanks! -- Sent from my Nokia N9 On 3/16/12 17:15 Hansen Kent (Nokia-MP/Oslo) wrote: Hi, Again the qtdeclarative CI has been blocked an entire day because of qtbase changes. It's great that the CI catches all these issues, but at the same time it's ridiculous how much time is spent suffering through failed qtdeclarative CI runs and fixing those failures up after the fact! If the turn-around time will increase by one hour or whatever by also testing qtdeclarative as part of the qtbase CI runs, so what? The increased stability and confidence in the results should easily make it a net win. No longer will there be a need to wonder whether a failed qtdeclarative CI run was due to one of the actual staged changed, or a recent qtbase change, and dreading the aftermath that comes from that. The current option of pinning the qtbase SHA1 used by qtdeclarative to some older, known good SHA1 _after_ a breaking qtbase change has gone through, is bad. BAD! Don't ask me to write a paper called Pinning of SHA1s considered harmful, because I will. Pinning just masks the failure. C'mon, after first locating a good qtbase SHA1 and being able to commit your own changes again, wouldn't you ideally want to go on with your own work instead of spending the rest of the day chasing down some unknown change in qtbase, contacting the author (if possible), waiting for the fix/revert, and babysitting that through the CI? But someone certainly needs to fix it, and while that's ongoing, new changes are blissfully making their way into qtbase, which means new qtdeclarative failures can appear, and it gets progressively harder to get out of the mess. (Happened twice this week.) Marking qtdeclarative tests as insignificant due to qtbase-introduced failures, just to get stuff through the CI again, is also a bit ho-humm. Who follows up that backlog of ignored tests? Yes, there are some qtbase changes that require qtdeclarative to be adapted (AKA intentional breakages), and then you need to run the qtbase CI in isolation. But that should be the exception, not the rule. It's in those cases one should first pin the qtbase SHA1 in qtdeclarative before staging the qtbase change, and afterwards adapt qtdeclarative (with a change already prepared and reviewed) and unpin the qtbase SHA1 at once. Takes away all the surprise. Hey, I know, we can just move qtdeclarative into qtbase. Bring back the -no-declarative configure option and we're golden. With best wishes for the weekend, Kent ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Removal of xlib plugin - a possible disaster.
On domingo, 18 de março de 2012 11.23.51, Robin Burchell wrote: I can't think of a WORSE spectacle, for the reputation of Qt-Project, than the Release of an Alpha Build in which large numbers of exerpienced Qt users on Linux Linux might be unable to use the XCB plugin and show a main Window, before getting some kind of 'ABEND', with any of our own provided examples. I agree: If we are shipping an alpha in which the xcb plugin is unusable for large numbers of people (though this needs to be quantified - how many people are hitting these problems?), then we're doing it wrong. We shouldn't ship something that doesn't work. I disagree partially. The purpose of the Alpha is to request and obtain feedback on the API and features, not the implementation. So if we know of bugs and limitations of the implementation, we can document them. So it's entirely permissible to release an Alpha with a list of what is known to work and what isn't. However, we need a minimum of things working so that users are able to test the new APIs and functionality. I don't know completely what the current status is. That's why I am part of the pre-alpha testing so we can find it out and fix the most showstopper bugs, so users can test. So far, in my testing, I have found that Qt Creator compiles and runs, with Qt Quick parts (I don't know if 1 or 2) show fine, but the QWidget backgrounds show black (menus, tree views, etc.). I have not found any crashes on startup. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Commit policies and the Qt 5 alpha
Hi everybody, there are quite a few people meeting up in Oslo this week, and we'll try to finish up the Qt 5 alpha there. For this reason I'd like everybody to restrain themselves in what they submit to the master branch. The main focus needs to be to get the alpha, so please focus on staging only commits that help us get the alpha out. At the same time, I'd like to announce that we need to tighten our policy regarding changes to Qt 5 a bit more. This is required for us to really focus on stabilizing Qt 5, and bringing us onto the right path towards a release. Here are the new rules for essential modules: * From now on no more changes that are source incompatible with Qt 4.8. 1-2 exceptions are still waiting in the API changes branch and Thiago's new QUrl. * No more source incompatible changes to features/API that are new in Qt 5, unless approved by the module's maintainer after a discussion on the mailing list * Try to avoid binary incompatible changes, as they slow down development. * The only changes that should still go in are: - Regressions against Qt 4.x (this implies that the platform plugins have some more freedom) - Major bugs for functionality that has been there in 4.x - Bug fixes to new functionality - Performance improvements - Improvements to memory consumption Qt Addons are encouraged to follow the same rules if they want to have a 5.0 release at around the same time as Qt 5.0. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Commit policies and the Qt 5 alpha
On domingo, 18 de março de 2012 19.55.53, lars.kn...@nokia.com wrote: * No more source incompatible changes to features/API that are new in Qt 5, unless approved by the module's maintainer after a discussion on the mailing list Does this include source-incompatible changes that restore compatibility with Qt 4? After discussion here and maintainer's approval, of course. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Removal of xlib plugin - a possible disaster.
None of the below changes the fact that the xlib plugin is unmaintained and broken. Removing it is the right thing to do for exactly that reason. If things don't work with an older xcb release, let's add a configure test requiring a minimum version that works. I rather have configure bail out with an error message telling the user to upgrade xcb (or their distribution) than advising them to use a plugin we know is broken. Cheers, Lars On 3/18/12 7:59 AM, ext Rick Stockton rickstock...@reno-computerhelp.com wrote: http://codereview.qt-project.org/#change,20091 My negative review of the Change comes out of 3 facts: (1) I have personally experienced the yet-to-be-documented problem, with both widget and declarative-based example programs, in which the GUI never appears: The program crashes with SIGSEGV, probably when attempting to assign size hints for the main Window. For me, the problem began occurring in February- but I wasn't doing much with Qt on XCB platform plugin during late January, so the problem may have been created/exposed at an earlier time. In any case, it was happening 100% of the time with my Distro, Mageia-1. (I have new problem with Mageia-2, described as fact #3 below.) (2) That problem has been reported by others on IRC. I'm not capable of creating a tight search on Jira bugreports, but I didn't see a report for the problem. If someone can assist in that search, we'd be looking for xcb plugin, sigsegv crash, bug opened after the start of 2012. (3) Wondering if my Distro was too old, (and most of it's RPMs were built in April of 2011), I just upgraded to Mageia-2 beta-2. I no longer get SIGSEGV, but I get a problem which _could_ be closely related: referencing an Undefined Symbol related to WM hints. https://bugreports.qt-project.org/browse/QTBUG-24835 --- comments --- I can't think of a WORSE spectacle, for the reputation of Qt-Project, than the Release of an Alpha Build in which large numbers of exerpienced Qt users on Linux Linux _might_ be unable to use the XCB plugin and show a main Window, before getting some kind of 'ABEND', with _any_ of our own provided examples. Sending the Alpha out with xlib plugin removed would be like selling a car without an emergency brake: Yes, the main brake system is the one you should use, but if totally dies you have GOT to have another one. With these two bugs present (i.e. SIGSEGV happening on some older Distros, and Undefined Symbol happening on RPMs built just 6 days ago), you NEED to have an alternative, EASY plugin for these people to use. Even at alpha. Yes, the bugs should be documented, isolated, and fixed. But, from my own Test/Integration/Release career, I'd say that our choices for alpha are (A) leave the xlib plugin present, and maybe even make it build automatically on X11 systems; or (B) stop ignoring the IRC I'm getting 'segment fault' with an example program postings, and POSTPONE ALPHA until we've got them fixed. And I'd vote for alternative A -- keep the alpha schedule, but provide xlib as an alternative plugin. Just my opinion, but it's held pretty strongly. Since I have only ONE box, with ONE disk, I can't easily go back to mageia-1 to reproduced bug #1. But I'm pretty confident that some of our Qt5-Alpha-1 users will experience it, and their doco might help to pin it down pretty well. :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 and old versions of XCB
On 3/18/12 6:28 PM, ext Bradley Smith bsm...@baysmith.com wrote: Every Linux distro uses X.org, which uses XCB. Including openSUSE 11.1, but just any XCB is not enough. It needs to be more recent than some version. For users with an incompatible version of XCB, I think we can provide a better user experience than hitting compiler errors when building Qt. If someone knows the minimum version required, hopefully configure tests can check for it. While trying to upgrade XCB, I also found that OpenGL support was only enabled if the xcb-xlib configuration test passed. I don't believe this limitation was reported by the configuration output either. Feel free to provide patches for better diagnostic messages then. Solving the problem of old distro's is not that hard. All that's required is to link xcb statically into the platform plugin. This is something that can be done, it can even be made rather simply in the Qt build system. But it would require someone with the interest to do the work. So far nobody has volunteered. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Commit policies and the Qt 5 alpha
On 3/18/12 9:05 PM, ext Thiago Macieira thiago.macie...@intel.com wrote: On domingo, 18 de março de 2012 19.55.53, lars.kn...@nokia.com wrote: * No more source incompatible changes to features/API that are new in Qt 5, unless approved by the module's maintainer after a discussion on the mailing list Does this include source-incompatible changes that restore compatibility with Qt 4? After discussion here and maintainer's approval, of course. Yes, we said that SC with 4.x is important to us. So these changes might still make sense. But any of them should still be brought up here. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 and old versions of XCB
Every Linux distro uses X.org, which uses XCB. Including openSUSE 11.1, but just any XCB is not enough. It needs to be more recent than some version. For users with an incompatible version of XCB, I think we can provide a better user experience than hitting compiler errors when building Qt. If someone knows the minimum version required, hopefully configure tests can check for it. While trying to upgrade XCB, I also found that OpenGL support was only enabled if the xcb-xlib configuration test passed. I don't believe this limitation was reported by the configuration output either. Feel free to provide patches for better diagnostic messages then. Solving the problem of old distro's is not that hard. All that's required is to link xcb statically into the platform plugin. This is something that can be done, it can even be made rather simply in the Qt build system. Could be a good suggestion. How about a compromise? Since there are concerns around how many linux distros will be running a recent enough version of xcb, could a properly built static xcb library be provided as part of the Qt build itself (noting Thiago's follow-up comments about -fPIC)? A configure option could be provided for those who have to care about this (but it could be off by default). That should save ISV's a lot of headaches. Not sure if the xcb licensing terms would be compatible with Qt's, but on the face of it, it looks likely to be okay. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Removal of xlib plugin - a possible disaster.
On 03/18/2012 03:23 AM, Robin Burchell wrote: On Sun, Mar 18, 2012 at 7:59 AM, Rick Stockton rickstock...@reno-computerhelp.com wrote: SNIP I can't think of a WORSE spectacle, for the reputation of Qt-Project, than the Release of an Alpha Build in which large numbers of exerpienced Qt users on Linux Linux _might_ be unable to use the XCB plugin and show a main Window, before getting some kind of 'ABEND', with _any_ of our own provided examples. I agree: If we are shipping an alpha in which the xcb plugin is unusable for large numbers of people (though this needs to be quantified - how many people are hitting these problems?), then we're doing it wrong. We shouldn't ship something that doesn't work. With these two bugs present (i.e. SIGSEGV happening on some older Distros, and Undefined Symbol happening on RPMs built just 6 days ago), you NEED to have an alternative, EASY plugin for these people to use. Even at alpha. No. As I said, the problems need to be *fixed*. Providing workarounds just means that people that can _find_ the workarounds keep using those workarounds, those that _can't_ find them think Qt 5 is crap, it doesn't work, and when that workaround is under/unmaintained code, that won't leave a good impression anyway. (B) stop ignoring the IRC I'm getting 'segment fault' with an example program postings IRC is *not* a bugtracker. It's transient. You're shouting into a void, and if someone who happens to be able to help you reads what you're saying, and has some time to help you - great. That doesn't mean you should treat it as the one place to report issues. Writing to the mailing list is a more sensible idea, as it has a much more permanent record. Filing bugs (or even better: patches), and bringing them to the attention of the people who work on that code (through mailing lists, or if you _know_ who to speak to, IRC) is even better. Relatedly, quoting you from Gerrit: I have been present when OTHERS have brought up the same problem (crash with SIGSEGV, before bringing up the main window) on OTHER Distros, starting sometime in mid (or late?) February. No one addressed it, and I've got no experience in this area. [w00t has been logged in at the time of least 2-3 of those queries... but possibly in unannounced back later mode at those times.] Unless something goes wrong with my server, I'm always connected, but not necessarily reading, or even in front of the computer. I connect to IRC through a server, and then connect to _it_ when I'm around. Sometimes, I might read things that happened while I was away, but not often. Exactly a point which I attempted to make. But I didn't emphasize that you were ALMOST CERTAINLY, because my word possibly is not a good word for almost certainly. Thanks for making this more clear than I wrote it. Bottom line: everyne who hears of such an event on Qt5, on any of our IRC channels, should _beg_ the person to open a QTBUG for it. I have two seperate such connections (one for work, one for personal stuff), and between them, I'm on around 70-80 different channels. If I tried to keep track of everything that happened in those channels all of the time, I'd never get anything else done. So I don't. I know that many other people use IRC in similar ways Your 100% right, of course. I myself am Away, without being marked Nick_AWAY, frequently. and POSTPONE ALPHA until we've got them fixed. I think we'd need to really have an idea of what the problem is, how many people it affects, and the effort to fix it, before we can make that call. But yes, as I've said: I don't think that shipping broken code is a good idea. Strongly agreed, and I think that we understand each other. We just recommend different approaches: I see the Alpha as a good tool to get this bug quantified AND possibly more isolated, well-defined -- by having other people (with a far wider range of Linux system configurations) experiencing cases in the real world. There is a significant probability that it WON'T be happen to a lot of normal users: my own system had a strange combination of old xcb core and xcb utils, but with new Wayland/Mesa/Cairo etc. I'd like to see Alpha-1 cut sooner, rather than later (even if it contains severe bugs, with workarounds such as xlib plugin). You'd prefer higher quality, putting XCB fails to initialize a main Window with size hints on the list of Releaes-Critical bugs, even for an Alpha Release. We're in agreement that the one thing NOT to do is put out alpha _with_ show-stopper XCB bugs present, *AND* xlib plugin removed. You recommend to fix the show-stopper bugs first, I recommend to leave xlib in as a workaround. Thanks for a great discussion! I will not be changing my review vote (on removing Xlib) before XCB again becomes usable on my own system. Dr. Scott, and others, have brought up other issues of great interest -- but the first choice, probably, is whether or not to
Re: [Development] Qt 5 and old versions of XCB
What is the minimum version of XCB required for Qt 5? It appears that libxcb-1.5 and xcb-proto-1.6 are required. These releases were announced Dec 3 2009 and Dec 2 2009 respectively. Does anyone have a way to determine how wide spread libxcb = 1.5 has become in the last 15 months? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 and old versions of XCB
What is the minimum version of XCB required for Qt 5? It appears that libxcb-1.5 and xcb-proto-1.6 are required. These releases were announced Dec 3 2009 and Dec 2 2009 respectively. Does anyone have a way to determine how wide spread libxcb = 1.5 has become in the last 15 months? Not 15 months, 27 months. Does anyone have a way to determine how wide spread libxcb = 1.5 has become in the last 27 months? (Must be the effect of having small children that the last two years feels like one.) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The qtbase CI should run the qtdeclarative tests
marius.storm-ol...@nokia.com said: While it's not normal to do this type of dependency lock for upwards dependencies, i think in this case we should indeed do the extra checking. Not just because QtDeclarative is such an important tech for Qt5, but also because it's a very good test case for QtBase. What would be the proposed workflow to resolve this situation? - I have a change in qtbase which I can't push because it breaks a qtdeclarative test. - I have a fix to the test in qtdeclarative but I can't push it because it doesn't pass without my qtbase change. One solution I can think of is to introduce a %reverse_dependencies in sync.profile, used for CI and nothing else, which can control the SHA1 of qtdeclarative used while testing qtbase. Another is to skip the testing of qtdeclarative in qtbase branchname's CI if qtdeclarative's sync.profile does not contain qtbase = refs/heads/branchname. The extra time used for checking both repos will give much greater stability as a whole. Well, we don't really know that. Note that introducing qtdeclarative into the qtbase tests means that both directions of breakage are now possible (i.e. not only can qtbase changes block qtdeclarative's CI, but now qtdeclarative changes will be able to block qtbase's CI - though it should be unlikely). However it's certainly reasonable to expect that, and give it a try. Maybe the fast platforms can do the extra checking, while slow platforms still handle only QtBase? At least we will capture most compile issues? I think we'd start with adding new configurations rather than modifying existing ones. e.g. as there is currently a linux-g++-32 Ubuntu 10.04 x86 configuration for qtbase, there could be a new linux-g++-32 Ubuntu 10.04 x86 with declarative configuration. Doing it that way also means the with declarative configuration can run just the qtdeclarative autotests (we assert that there's no need to run the qtbase autotests again), theoretically not increasing the overall runtime. Unfortunately there's probably not enough resources to do that for some platforms (like Mac). (The CI rules might get very complicated though.) Yes, in some ways I feel this is adding complexity to the test setup to work around a false simplicity in our source code setup. We claim that Qt is modular, but actually we know some parts of it are not really, so we add gates to enforce some level of de-modularization. Rohan/Sergio, what will be the turn-around increase if we always test Declarative together with QtBase? The runtime should be somewhere between the current runtime of qtbase, and the qtbase runtime plus the qtdeclarative runtime. Anything more would be speculation ... but I don't think the runtime would be a big issue :) Anyway, overall I think it's worth a try, but we should accept that this could also create some new problems as well as solving some existing ones. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 and old versions of XCB
2012/3/19 Bradley Smith bsm...@baysmith.com: What is the minimum version of XCB required for Qt 5? It appears that libxcb-1.5 and xcb-proto-1.6 are required. These releases were announced Dec 3 2009 and Dec 2 2009 respectively. Does anyone have a way to determine how wide spread libxcb = 1.5 has become in the last 15 months? Not 15 months, 27 months. Does anyone have a way to determine how wide spread libxcb = 1.5 has become in the last 27 months? Debian Squeeze (last stable) and Ubuntu Lucid (last LTS) both have xcb = 1.5. http://packages.debian.org/search?keywords=libxcb1 http://packages.ubuntu.com/search?keywords=libxcb1 Cheers, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
