Re: Final thoughts/votes on Kubuntu Policy
On Tue, Aug 5, 2014 at 9:58 PM, Scott Kitterman ubu...@kitterman.com wrote: On Tuesday, August 05, 2014 21:36:24 Harald Sitter wrote: On Tue, Aug 5, 2014 at 8:40 PM, Scott Kitterman ubu...@kitterman.com wrote: On Tuesday, August 05, 2014 19:55:07 Harald Sitter wrote: On Tue, Aug 5, 2014 at 7:45 PM, Scott Kitterman ubu...@kitterman.com wrote: I, for one, think the notion that we won't apply known fixes because upstream is non- responsive is silly. I don't intend to be bound by it. Where does the fix come from then? Could be defective Python code I figured out by myself (for reference, this exact scenario is why we had an even sort of working displayconfig in hardy - if this policy had been in effect, it would have had to be removed and not replaced since there was no replacement available). so why did you not pick up maintainership? Because it would have needed a full rewrite to work with the then brand new X stack reliably. We were going to have a new tool for Intrepid anyway, so beating it into sort of working was enough for Kubuntu and I'm certainly not qualified to take on upstream development for all of KDE. Why would you not be qualified? You created a Kubuntu specific fork of the software, so since you were fit to maintain that one I am sure the same would have worked upstream. Seeing as you were able to beat it into working state for Kubuntu it would appear to me that there is nothing that would have prevented you from doing the change upstream and releasing a new tarball. At worse you had to roll a tarball instead of dumping a patch into debian/ (which would then have had up-to-date translations thus possibly not being all that much of a waste of time to begin with), at best 3 other distributions had picked it up and thanks to that ended up with a working display config in their LTS release. The reasons why we don't want to condone dead upstream pseudo maintenance patchy nonesense is multifaceted. The fact that distro patchy is selfish towards everyone else is one part of it. Another one is that the patch policy needs a responsible person up the stream to review and approve and possibly merge a patch, with out one the patch policy doesn't allow certain patches at all. Another important side of the argument is that of reliable and balanced quality. No one takes on responsibility for the quality, so we must assume it has excessively shitty quality or is of no use because otherwise someone were to feel the need to stand up and take on maintenance or at the very least care enough to fix startup crashes, data loss, bug triage etc.etc.. And ultimately that leads to the question of whether we should have a piece of software of obviously shitty quality under our wings to begin with considering no one else wants to care about it either. All that being said, perhaps the policy ought to be amended to say that instead of having the package removed from the archive it must not be on our ISOs and Kubuntu should not be the maintainer. At the end of the day what someone does because they want to is their own business. So, if someone feels like foobar should be in the archive and that they feel up to the task of keeping it not broken that's their choice to make and execute. Even if it then reflects badly on Kubuntu and Ubuntu at large if a user installs that software and finds it to be unusable for whatever reason. There is not much one can do about that, and this is a global problem to some extent anyway. But, we as creators of Kubuntu however should not support selfish life-support patching for the software we use to build our product on. It does not benefit anyone to drag along broken unreliable software. Giving it the boot on the other hand does not only free up resources better spent elsewhere, it also makes people moan and whine about this super important application that is now gone and this makes it all the more likely that someone steps up and does what needs to be done to make it a super awesome piece of software again. The present policy is already given a lot of leeway to make sure the user doesn't need to suffer unless there really is no other way. But the must-not-be-patched thing is really not something that can be changed or removed IMO. If patching maintained software is semi-forking then patching unmaintained software that is entirely broken as per the presented check list is a definite fork because the patched version is then the only working version and thus the defacto source to be used. So, your concern is that this sort of short term workaround isn't possible with the presented policy, but really it is. Instead of making a distro patch you would commit your bandaid solution upstream, release a new tarball. By doing that you are making your work easily available to others and improve the quality of the upstream product. You'd then be a maintainer (of sorts). Other distros as well as our guys might have additional tweaks so they run it by
Re: Final thoughts/votes on Kubuntu Policy
On Wednesday, August 06, 2014 15:05:49 Harald Sitter wrote: On Tue, Aug 5, 2014 at 9:58 PM, Scott Kitterman ubu...@kitterman.com wrote: On Tuesday, August 05, 2014 21:36:24 Harald Sitter wrote: On Tue, Aug 5, 2014 at 8:40 PM, Scott Kitterman ubu...@kitterman.com wrote: On Tuesday, August 05, 2014 19:55:07 Harald Sitter wrote: On Tue, Aug 5, 2014 at 7:45 PM, Scott Kitterman ubu...@kitterman.com wrote: I, for one, think the notion that we won't apply known fixes because upstream is non- responsive is silly. I don't intend to be bound by it. Where does the fix come from then? Could be defective Python code I figured out by myself (for reference, this exact scenario is why we had an even sort of working displayconfig in hardy - if this policy had been in effect, it would have had to be removed and not replaced since there was no replacement available). so why did you not pick up maintainership? Because it would have needed a full rewrite to work with the then brand new X stack reliably. We were going to have a new tool for Intrepid anyway, so beating it into sort of working was enough for Kubuntu and I'm certainly not qualified to take on upstream development for all of KDE. Why would you not be qualified? You created a Kubuntu specific fork of the software, so since you were fit to maintain that one I am sure the same would have worked upstream. Seeing as you were able to beat it into working state for Kubuntu it would appear to me that there is nothing that would have prevented you from doing the change upstream and releasing a new tarball. At worse you had to roll a tarball instead of dumping a patch into debian/ (which would then have had up-to-date translations thus possibly not being all that much of a waste of time to begin with), at best 3 other distributions had picked it up and thanks to that ended up with a working display config in their LTS release. Perhaps. That would have required some commitment on my part to do work to support other distros that I wasn't willing to take on. Since the X stuff does vary from distro to distro, I had (and still have) no idea what of what I was doing was Ubuntu specific and what might be generally applicable. The reasons why we don't want to condone dead upstream pseudo maintenance patchy nonesense is multifaceted. The fact that distro patchy is selfish towards everyone else is one part of it. Another one is that the patch policy needs a responsible person up the stream to review and approve and possibly merge a patch, with out one the patch policy doesn't allow certain patches at all. Another important side of the argument is that of reliable and balanced quality. No one takes on responsibility for the quality, so we must assume it has excessively shitty quality or is of no use because otherwise someone were to feel the need to stand up and take on maintenance or at the very least care enough to fix startup crashes, data loss, bug triage etc.etc.. And ultimately that leads to the question of whether we should have a piece of software of obviously shitty quality under our wings to begin with considering no one else wants to care about it either. I generally agree with that, but there are cases where all the alternatives were worse. Shipping without any tool at all to configure a monitor was a non- starter. All that being said, perhaps the policy ought to be amended to say that instead of having the package removed from the archive it must not be on our ISOs and Kubuntu should not be the maintainer. At the end of the day what someone does because they want to is their own business. So, if someone feels like foobar should be in the archive and that they feel up to the task of keeping it not broken that's their choice to make and execute. Even if it then reflects badly on Kubuntu and Ubuntu at large if a user installs that software and finds it to be unusable for whatever reason. There is not much one can do about that, and this is a global problem to some extent anyway. That's true. It's definitely beyond the scope of what Kubuntu policy could mandate to insist on packages being removed from the archive if someone did not want them removed. That said, we still have the situation where the unmaintained crap we have is better than the alternatives available. But, we as creators of Kubuntu however should not support selfish life-support patching for the software we use to build our product on. It does not benefit anyone to drag along broken unreliable software. Giving it the boot on the other hand does not only free up resources better spent elsewhere, it also makes people moan and whine about this super important application that is now gone and this makes it all the more likely that someone steps up and does what needs to be done to make it a super awesome piece of software again. If someone had told me when I started
continuous packaging? anyone?
aloha packagers today the idea of continuous packaging popped up and I wanted to get some general thoughts on the matter. # what is this? CP is essentially what project-neon does, build all packages off of upstream git. Conceptually this technically is supposed lto be like proper CI (i.e. build as often as possible with as small changes as possible and run tests). Since this is partially not very practical from a packaging perspective let's for now think of it as regular daily builds. # what's wrong with neon? :O Neon is built in a very specific way. Namely: - completely different prefix - excessive envrionment manipulation to separate data lookup (as much as possible) as well as user specific data and settings storage - single binary units (i.e. each upstream git repo creates exactly one debian package) It is made this way because it creates next to no overhead in packaging, this is curcial to what neon is meant to achive: Provide the most bleeding edge of KDE software *next to* the ongoing efforts of high quality packaging we do manually. In other words neon is made in such a way that it does not take away developer time from the real meat, at the expense of Debian policy compliance (in some ways anyway). # so how would CP be different from neon? The idea is instead of doing daily dummy packages with only one deb as described above we build our actual packages on a daily basis against an actual upstream git branch. Continuously adjusting our packaging to what is in git and will therefore eventually become a release we will pick up. # why oh why? Right now we get a batch of a upstream tarballs, throw our *old* packaging at it, and then hammer at it until it builds. This is not only stressful it also scales really bad. The more changes are between old-release and new-release the more hammering is needed, the longer it takes, the more exhausting it is, the more bugs we introduce. Add to that the fact that we sometimes get a very excessive batch of partially even unrelated releases at pretty much the same time and you've occupied some 2 or 3 packagers for a week or two (think KDE SC, Plasma and KF5 in the same week for example). # how does CP solve that? The idea is, every day you have changes trickle in, ever so slowly, built against our packaging HEAD. Instead of getting a crazy week at the beginning of each month we spend maybe 5 minutes a day adjusting the packages that need adjustment and once the actual release hits we take our packaging throw it at the release tarballs and everything builds without problems (in theory). # why, there must be a downside to all this... Numerous tiny problems popping up all over the place that will need to have solutions invented. So it would be good if we could think of as many as possible before moving forward. I'll make a start: - unless we replicate tooling for l10n retrieval, there won't be translations and more importantly .install files that explicitly list /usr/share/locale/ will fail - doing CP makes packaging branches more confusing unless we actually land into archive (which would seem slightly terrible) as we'd have two HEAD branches... one for the actual packaging in the archive and one for the CP that is constantly moving, since keeping a handle on many branches in bzr is a jolly nightmare I am not too fond of this # and what about the tech? Thanks to blue systems and yours truly most of the tech does already exist and drives neon5 ;) So, what do you guys and gals reckon? HS -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: Final thoughts/votes on Kubuntu Policy
On Wed, Aug 6, 2014 at 7:14 PM, Scott Kitterman ubu...@kitterman.com wrote: On Wednesday, August 06, 2014 18:05:20 Harald Sitter wrote: On Wed, Aug 6, 2014 at 3:24 PM, Scott Kitterman ubu...@kitterman.com wrote: On Wednesday, August 06, 2014 15:05:49 Harald Sitter wrote: On Tue, Aug 5, 2014 at 9:58 PM, Scott Kitterman ubu...@kitterman.com wrote: On Tuesday, August 05, 2014 21:36:24 Harald Sitter wrote: On Tue, Aug 5, 2014 at 8:40 PM, Scott Kitterman ubu...@kitterman.com wrote: On Tuesday, August 05, 2014 19:55:07 Harald Sitter wrote: On Tue, Aug 5, 2014 at 7:45 PM, Scott Kitterman ubu...@kitterman.com wrote: I, for one, think the notion that we won't apply known fixes because upstream is non- responsive is silly. I don't intend to be bound by it. Where does the fix come from then? Could be defective Python code I figured out by myself (for reference, this exact scenario is why we had an even sort of working displayconfig in hardy - if this policy had been in effect, it would have had to be removed and not replaced since there was no replacement available). so why did you not pick up maintainership? Because it would have needed a full rewrite to work with the then brand new X stack reliably. We were going to have a new tool for Intrepid anyway, so beating it into sort of working was enough for Kubuntu and I'm certainly not qualified to take on upstream development for all of KDE. Why would you not be qualified? You created a Kubuntu specific fork of the software, so since you were fit to maintain that one I am sure the same would have worked upstream. Seeing as you were able to beat it into working state for Kubuntu it would appear to me that there is nothing that would have prevented you from doing the change upstream and releasing a new tarball. At worse you had to roll a tarball instead of dumping a patch into debian/ (which would then have had up-to-date translations thus possibly not being all that much of a waste of time to begin with), at best 3 other distributions had picked it up and thanks to that ended up with a working display config in their LTS release. Perhaps. That would have required some commitment on my part to do work to support other distros that I wasn't willing to take on. Since the X stuff does vary from distro to distro, I had (and still have) no idea what of what I was doing was Ubuntu specific and what might be generally applicable. I hear kwin does fine without distribution specific solutions. At any rate, if a distro had not been able to use it because of compatibility issues and you were not willing or capable or whatever to resolve it, that would have been where they needed to make their own decisions on whether to patch it into working state and hopefully upstream that patch or not ship it at all or ship the old version or whatever. By not going out and saying this here software is unmaintained, I made it so it works with kubuntu and relased version x.y which is less shitty than the previous release you pretty much excluded others from an option to possibly use it as we cannot expect others to track what we patch or don't patch (just like we don't track every other distros patch work). So had another distro needed it worst case they'd have duplicated the work on their own or be lucky enough to find our patch through a web search. The reasons why we don't want to condone dead upstream pseudo maintenance patchy nonesense is multifaceted. The fact that distro patchy is selfish towards everyone else is one part of it. Another one is that the patch policy needs a responsible person up the stream to review and approve and possibly merge a patch, with out one the patch policy doesn't allow certain patches at all. Another important side of the argument is that of reliable and balanced quality. No one takes on responsibility for the quality, so we must assume it has excessively shitty quality or is of no use because otherwise someone were to feel the need to stand up and take on maintenance or at the very least care enough to fix startup crashes, data loss, bug triage etc.etc.. And ultimately that leads to the question of whether we should have a piece of software of obviously shitty quality under our wings to begin with considering no one else wants to care about it either. I generally agree with that, but there are cases where all the alternatives were worse. Shipping without any tool at all to configure a monitor was a non- starter. There pretty much always is an almost equally suitable alternative (case in point: displayconfig-gtk). But yeah, let's assume there really is no replacement software available, and no one is willing to actually do an upstream commit (which is really a social problem as I am absolutely willing to go on record that
Re: [Merge] lp:~unity-team/kubuntu-packaging/qtdeclarative-fix-1349705 into lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src
I'll merge this when it's actually published to archives since it seems to be in a landing PPA already, and meanwhile I'm preparing the next upload as well. -- https://code.launchpad.net/~unity-team/kubuntu-packaging/qtdeclarative-fix-1349705/+merge/229183 Your team Kubuntu Packagers is requested to review the proposed merge of lp:~unity-team/kubuntu-packaging/qtdeclarative-fix-1349705 into lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src. -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [Merge] lp:~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8 into lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src
Released, this is to trigger code coverage collection only. -- https://code.launchpad.net/~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8/+merge/229651 Your team Kubuntu Packagers is requested to review the proposed merge of lp:~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8 into lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src. -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [Merge] lp:~panfaust/kubuntu-packaging-next/plasma-desktop-work2 into lp:~kubuntu-packagers/kubuntu-packaging-next/plasma-desktop
Package: plasma-desktop-data also needs to go from conflicts to breaks and please add a Replaces relationship with the same version requirement (to be on the save side) -- https://code.launchpad.net/~panfaust/kubuntu-packaging-next/plasma-desktop-work2/+merge/229082 Your team Kubuntu Packagers is subscribed to branch lp:~kubuntu-packagers/kubuntu-packaging-next/plasma-desktop. -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
[Merge] lp:~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8 into lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src
The proposal to merge lp:~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8 into lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src has been updated. Status: Needs review = Approved For more details, see: https://code.launchpad.net/~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8/+merge/229651 -- https://code.launchpad.net/~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8/+merge/229651 Your team Kubuntu Packagers is requested to review the proposed merge of lp:~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8 into lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src. -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
[Merge] lp:~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8 into lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src
The proposal to merge lp:~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8 into lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src has been updated. Status: Needs review = Approved For more details, see: https://code.launchpad.net/~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8/+merge/229651 -- https://code.launchpad.net/~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8/+merge/229651 Your team Kubuntu Packagers is requested to review the proposed merge of lp:~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8 into lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src. -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
[Merge] lp:~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8 into lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src
Timo Jyrinki has proposed merging
lp:~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8 into
lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src.
Requested reviews:
Kubuntu Packagers (kubuntu-packagers)
Related bugs:
Bug #1349297 in qtdeclarative-opensource-src (Ubuntu): Better fix for crash
due to wrong objects being garbage collected
https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1349297
For more details, see:
https://code.launchpad.net/~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8/+merge/229651
--
https://code.launchpad.net/~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8/+merge/229651
Your team Kubuntu Packagers is requested to review the proposed merge of
lp:~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8 into
lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src.
=== modified file 'debian/changelog'
--- debian/changelog 2014-07-07 08:43:27 +
+++ debian/changelog 2014-08-05 16:02:47 +
@@ -1,3 +1,21 @@
+qtdeclarative-opensource-src (5.3.0-3ubuntu8) utopic; urgency=medium
+
+ [ Michał Sawicz ]
+ * debian/patches/8454a21b-Flickable-Cancel-interaction-on-interactive-changes.patch
+- Fix flickable interaction (LP: #1349705)
+ * debian/control
+ * debian/rules
+- Force gcc-4.8 to avoid symbols changes
+
+ [ Timo Jyrinki ]
+ * debian/patches/parenttosubcreator_qqmlobjectcreator.patch:
+- Drop, rejected by upstream
+ * debian/patches/Fix-crash-when-deleting-component-in-Component.onCom.patch
+debian/patches/Fix-interaction-of-garbage-collector-with-JS-objects.patch:
+- Replace the old patch with accepted upstream approach (LP: #1349297)
+
+ -- Timo Jyrinki timo-jyri...@ubuntu.com Mon, 04 Aug 2014 10:58:28 +
+
qtdeclarative-opensource-src (5.3.0-3ubuntu7) utopic; urgency=medium
* debian/patches/Support-RFC2822Date-date-format-similar-to-V8.patch
=== modified file 'debian/control'
--- debian/control 2014-06-19 19:14:47 +
+++ debian/control 2014-08-05 16:02:47 +
@@ -11,6 +11,8 @@
Timo Jyrinki t...@debian.org
Build-Depends: debhelper (= 9),
dpkg-dev (= 1.16.1),
+# Avoiding symbols updates due to switch to gcc 4.9 by default.
+ g++-4.8,
libqt5xmlpatterns5-private-dev (= 5.3.0-0~),
pkg-kde-tools (= 0.15.12~),
python,
=== added file 'debian/patches/8454a21b-Flickable-Cancel-interaction-on-interactive-changes.patch'
--- debian/patches/8454a21b-Flickable-Cancel-interaction-on-interactive-changes.patch 1970-01-01 00:00:00 +
+++ debian/patches/8454a21b-Flickable-Cancel-interaction-on-interactive-changes.patch 2014-08-05 16:02:47 +
@@ -0,0 +1,152 @@
+From 8454a21b837ccf3968f6dbc56ed4f06d60d63c8f Mon Sep 17 00:00:00 2001
+From: Albert Astals Cid albert.ast...@canonical.com
+Date: Wed, 23 Jul 2014 15:40:42 +0200
+Subject: [PATCH] Flickable: Cancel interaction on interactive changes
+
+Otherwise if you have a listview with a flickable inside with a mouseare inside
+the pressed is never set to false if you make the interactive property of the
+outer list depend on the moving of the inner flickable. This makes that when
+later you change currentIndex of the list and you have
+StrictlyEnforceRange set, the list won't move because it still thinks it is pressed
+
+Change-Id: I2c2021f486fc0a31840c3f2199bc7cb76dc01e3e
+Reviewed-by: Martin Jones martin.jo...@jollamobile.com
+---
+ src/quick/items/qquickflickable.cpp | 41 ++--
+ src/quick/items/qquickflickable_p_p.h| 2 ++
+ tests/auto/qmltest/listview/tst_listview.qml | 41
+ 3 files changed, 63 insertions(+), 21 deletions(-)
+
+diff --git a/src/quick/items/qquickflickable.cpp b/src/quick/items/qquickflickable.cpp
+index ee71ea8..63dde66 100644
+--- a/src/quick/items/qquickflickable.cpp
b/src/quick/items/qquickflickable.cpp
+@@ -763,15 +763,8 @@ void QQuickFlickable::setInteractive(bool interactive)
+ Q_D(QQuickFlickable);
+ if (interactive != d-interactive) {
+ d-interactive = interactive;
+-if (!interactive (d-hData.flicking || d-vData.flicking)) {
+-d-clearTimeline();
+-d-hData.vTime = d-vData.vTime = d-timeline.time();
+-d-hData.flicking = false;
+-d-vData.flicking = false;
+-emit flickingChanged();
+-emit flickingHorizontallyChanged();
+-emit flickingVerticallyChanged();
+-emit flickEnded();
++if (!interactive) {
++d-cancelInteraction();
+ }
+ emit interactiveChanged();
+ }
+@@ -2015,18 +2008,24 @@ bool QQuickFlickable::yflick() const
+ void QQuickFlickable::mouseUngrabEvent()
+ {
+ Q_D(QQuickFlickable);
+-if (d-pressed) {
+-// if our mouse grab has been removed (probably by another Flickable),
+-// fix
[Merge] lp:~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8 into lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src
The proposal to merge lp:~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8 into lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src has been updated. Commit Message changed to: [ Michał Sawicz ] * debian/patches/8454a21b-Flickable-Cancel-interaction-on-interactive-changes.patch - Fix flickable interaction (LP: #1349705) * debian/control debian/rules Force gcc-4.8 to avoid symbols changes [ Timo Jyrinki ] * debian/patches/parenttosubcreator_qqmlobjectcreator.patch: - Drop, rejected by upstream * debian/patches/Fix-crash-when-deleting-component-in-Component.onCom.patch debian/patches/Fix-interaction-of-garbage-collector-with-JS-objects.patch: - Replace the old patch with accepted upstream approach (LP: #1349297) For more details, see: https://code.launchpad.net/~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8/+merge/229651 -- https://code.launchpad.net/~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8/+merge/229651 Your team Kubuntu Packagers is requested to review the proposed merge of lp:~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_530ubuntu8 into lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src. -- kubuntu-devel mailing list kubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: [Merge] lp:~kubuntu-packagers/ubuntu-release-upgrader/qt5 into lp:ubuntu-release-upgrader
Generally looks alright to me. Diff comments: === modified file 'DistUpgrade/DistUpgradeFetcherKDE.py' --- DistUpgrade/DistUpgradeFetcherKDE.py 2014-05-02 13:07:42 + +++ DistUpgrade/DistUpgradeFetcherKDE.py 2014-08-05 13:50:46 + @@ -2,6 +2,7 @@ # -*- Mode: Python; indent-tabs-mode: nil; tab-width: 4; coding: utf-8 -*- # # Copyright (c) 2008 Canonical Ltd +# Copyright (c) 2014 Harald Sitter apachelog...@kubuntu.org # # Author: Jonathan Riddell jridd...@ubuntu.com # @@ -18,58 +19,100 @@ # You should have received a copy of the GNU General Public License # along with this program. If not, see http://www.gnu.org/licenses/. -from PyKDE4.kdecore import ki18n, KAboutData, KCmdLineOptions, KCmdLineArgs -from PyKDE4.kdeui import KIcon, KMessageBox, KApplication, KStandardGuiItem -from PyQt4.QtCore import QDir, QTimer -from PyQt4.QtGui import QDialog, QDialogButtonBox -from PyQt4 import uic +try: +# 14.04 has a broken pyqt5, so don't even try to import it and require +# pyqt4. +# In 14.04 various signals in pyqt5 can not be connected because it thinks +# the signal does not exist or has an incompatible signature. Since this +# potentially renders the GUI entirely broken and pyqt5 was not actively +# used back then it is fair to simply require qt4 on trusty systems. +from .utils import get_dist +if get_dist() == 'trusty': +raise ImportError + +from PyQt5 import uic +from PyQt5.QtCore import * +from PyQt5.QtGui import * +from PyQt5.QtWidgets import * +except ImportError: +from PyKDE4.kdecore import ki18n, KAboutData, KCmdLineOptions, KCmdLineArgs +from PyKDE4.kdeui import KIcon, KMessageBox, KApplication, KStandardGuiItem +from PyQt4.QtCore import QDir, QTimer +from PyQt4.QtGui import QDialog, QDialogButtonBox +from PyQt4 import uic import apt_pkg import sys -from .utils import inhibit_sleep, allow_sleep -from .DistUpgradeFetcherCore import DistUpgradeFetcherCore +from DistUpgrade.utils import inhibit_sleep, allow_sleep +from DistUpgrade.DistUpgradeFetcherCore import DistUpgradeFetcherCore from gettext import gettext as _ from urllib.request import urlopen from urllib.error import HTTPError import os -from .MetaRelease import MetaReleaseCore import apt +from .QUrlOpener import QUrlOpener + +# TODO: uifile resolution is an utter mess and should be revised globally for +# both the fetcher and the upgrader GUI. + +# TODO: make this a singleton +# We have no globally constructed QApplication available so we need to +# make sure that one is created when needed. Since from a module POV +# this can be happening in any order of the two classes this function takes care +# of it for the classes, the classes only hold a ref to the qapp returned +# to prevent it from getting GC'd, so in essence this is a singleton scoped to +# the longest lifetime of an instance from the Qt GUI. Since the lifetime is +# pretty much equal to the process' one we might as well singleton up. +def _ensureQApplication(): +if not QApplication.instance(): +app = QApplication([ubuntu-release-upgrader]) +# Try to load default Qt translations so we don't have to worry about +# QStandardButton translations. +# FIXME: make sure we dep on l10n +translator = QTranslator(app) +if PYQT_VERSION = 0x5: +translator.load(QLocale.system(), 'qt', '_', '/usr/share/qt5/translations') +else: +translator.load(QLocale.system(), 'qt', '_', '/usr/share/qt4/translations') +app.installTranslator(translator) +return app +return QApplication.instance() + +# Qt 5 vs. KDELibs4 compat functions +def _warning(text): +if PYQT_VERSION = 0x5: +QMessageBox.warning(None, , text) +else: +KMessageBox.sorry(None, text, ) + +def _icon(name): +if PYQT_VERSION = 0x5: +return QIcon.fromTheme(name) +else: +return KIcon(name) class DistUpgradeFetcherKDE(DistUpgradeFetcherCore): -A small application run by Adept to download, verify -and run the dist-upgrade tool - -def __init__(self, useDevelopmentRelease=False, useProposed=False): -self.useDevelopmentRelease = useDevelopmentRelease -self.useProposed = useProposed -metaRelease = MetaReleaseCore(useDevelopmentRelease, useProposed) -metaRelease.downloaded.wait() -if metaRelease.new_dist is None and __name__ == __main__: -sys.exit() -elif metaRelease.new_dist is None: -return - -self.progressDialogue = QDialog() -if os.path.exists(fetch-progress.ui): -self.APPDIR = QDir.currentPath() -else: -self.APPDIR = /usr/share/ubuntu-release-upgrader - -uic.loadUi(self.APPDIR + /fetch-progress.ui,
Re: [Merge] lp:~kubuntu-packagers/ubuntu-release-upgrader/qt5 into lp:ubuntu-release-upgrader
Diff comments: === modified file 'DistUpgrade/DistUpgradeFetcherKDE.py' --- DistUpgrade/DistUpgradeFetcherKDE.py 2014-05-02 13:07:42 + +++ DistUpgrade/DistUpgradeFetcherKDE.py 2014-08-05 13:50:46 + @@ -2,6 +2,7 @@ # -*- Mode: Python; indent-tabs-mode: nil; tab-width: 4; coding: utf-8 -*- # # Copyright (c) 2008 Canonical Ltd +# Copyright (c) 2014 Harald Sitter apachelog...@kubuntu.org # # Author: Jonathan Riddell jridd...@ubuntu.com # @@ -18,58 +19,100 @@ # You should have received a copy of the GNU General Public License # along with this program. If not, see http://www.gnu.org/licenses/. -from PyKDE4.kdecore import ki18n, KAboutData, KCmdLineOptions, KCmdLineArgs -from PyKDE4.kdeui import KIcon, KMessageBox, KApplication, KStandardGuiItem -from PyQt4.QtCore import QDir, QTimer -from PyQt4.QtGui import QDialog, QDialogButtonBox -from PyQt4 import uic +try: +# 14.04 has a broken pyqt5, so don't even try to import it and require +# pyqt4. +# In 14.04 various signals in pyqt5 can not be connected because it thinks +# the signal does not exist or has an incompatible signature. Since this +# potentially renders the GUI entirely broken and pyqt5 was not actively +# used back then it is fair to simply require qt4 on trusty systems. 14.04 has a broken pyqt5, so don't even try to import it and require pyqt4. Please file a bug (with a testcase that works in utopic and doesn't work in trusty). Maybe I'll fix it and this hack won't be needed. +from .utils import get_dist +if get_dist() == 'trusty': +raise ImportError + +from PyQt5 import uic +from PyQt5.QtCore import * +from PyQt5.QtGui import * +from PyQt5.QtWidgets import * +except ImportError: +from PyKDE4.kdecore import ki18n, KAboutData, KCmdLineOptions, KCmdLineArgs +from PyKDE4.kdeui import KIcon, KMessageBox, KApplication, KStandardGuiItem +from PyQt4.QtCore import QDir, QTimer +from PyQt4.QtGui import QDialog, QDialogButtonBox +from PyQt4 import uic import apt_pkg import sys -from .utils import inhibit_sleep, allow_sleep -from .DistUpgradeFetcherCore import DistUpgradeFetcherCore +from DistUpgrade.utils import inhibit_sleep, allow_sleep +from DistUpgrade.DistUpgradeFetcherCore import DistUpgradeFetcherCore from gettext import gettext as _ from urllib.request import urlopen from urllib.error import HTTPError import os -from .MetaRelease import MetaReleaseCore import apt +from .QUrlOpener import QUrlOpener + +# TODO: uifile resolution is an utter mess and should be revised globally for +# both the fetcher and the upgrader GUI. + +# TODO: make this a singleton +# We have no globally constructed QApplication available so we need to +# make sure that one is created when needed. Since from a module POV +# this can be happening in any order of the two classes this function takes care +# of it for the classes, the classes only hold a ref to the qapp returned +# to prevent it from getting GC'd, so in essence this is a singleton scoped to +# the longest lifetime of an instance from the Qt GUI. Since the lifetime is +# pretty much equal to the process' one we might as well singleton up. +def _ensureQApplication(): +if not QApplication.instance(): +app = QApplication([ubuntu-release-upgrader]) +# Try to load default Qt translations so we don't have to worry about +# QStandardButton translations. +# FIXME: make sure we dep on l10n +translator = QTranslator(app) +if PYQT_VERSION = 0x5: +translator.load(QLocale.system(), 'qt', '_', '/usr/share/qt5/translations') +else: +translator.load(QLocale.system(), 'qt', '_', '/usr/share/qt4/translations') +app.installTranslator(translator) +return app +return QApplication.instance() + +# Qt 5 vs. KDELibs4 compat functions +def _warning(text): +if PYQT_VERSION = 0x5: +QMessageBox.warning(None, , text) +else: +KMessageBox.sorry(None, text, ) + +def _icon(name): +if PYQT_VERSION = 0x5: +return QIcon.fromTheme(name) +else: +return KIcon(name) class DistUpgradeFetcherKDE(DistUpgradeFetcherCore): -A small application run by Adept to download, verify -and run the dist-upgrade tool - -def __init__(self, useDevelopmentRelease=False, useProposed=False): -self.useDevelopmentRelease = useDevelopmentRelease -self.useProposed = useProposed -metaRelease = MetaReleaseCore(useDevelopmentRelease, useProposed) -metaRelease.downloaded.wait() -if metaRelease.new_dist is None and __name__ == __main__: -sys.exit() -elif metaRelease.new_dist is None: -return - -self.progressDialogue = QDialog() -if
