Re: autopkgtest-build-lxd failing with bionic
On Tuesday, February 20, 2018 10:44:42 PM Martin Pitt wrote: > Steve Langasek [2018-02-16 11:12 -0800]: ... > > I think the network-online.target is the better thing to key on. > > I still don't like that much, though: > - there is no requirement that this actually gets "implemented" or even > started (it's a passive target) > > - it's supposed to be a SysV backwards compat shim for LSB's "network" > dependency, and not well-defined > > - These tools should also work with Debian containers, which in theory > could also run sysvinit. This is also the reason why they still use > `runlevel` instead of `systemctl is-system-running` or something similar. > > All of these are just heuristics, though; you could have all sorts of cases > where all of these break, like sharing the host's network namespace, having > no default route but a route to the configured apt proxy, etc. Maybe the > closest approximation to this would be to grab the archive URL from > /etc/apt/sources.list and put it in a curl loop, but (1) neither wget nor > curl are in minimal installs, and (2) at that point it could just as well > be an apt-get retry loop. So what's the right systemd way to ensure the network is up? I continue to fight bugs in the postfix unit file both in Debian and Ubuntu over things happening before the network is up. As far as I can determine from the documentation, network-online.target should work, but I agree it doesn't do so reliably. Currently postfix@.service has: After=network-online.target nss-lookup.target Wants=network-online.target If inet_interfaces has been set to a specific IP address (which is a legitimate use), then if postfix tries to start before that IP address is available errors ensue. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Does the backporters team need help?
The answer is clearly yes. I've attempted a few times to pass off backports to someone new and apparently failed. I'll be glad spend a few minutes getting you up to speed, but as I'm not involved in Ubuntu development anymore, I don't really have time for more than that. Scott K On Monday, April 24, 2017 03:31:20 PM Clint Byrum wrote: > Judging by the deafening silence, either they don't read ubuntu-devel, > or the answer is yes. > > How can we resolve this? > > Excerpts from Clint Byrum's message of 2017-04-14 11:30:12 -0700: > > Hi. I was just looking and I noticed backport bugs piling up: > > > > https://bugs.launchpad.net/xenial-backports > > > > Once, long ago, I was going to join the effort, but my time for Ubuntu > > has been pretty limited. That said, if y'all need help, I can probably > > throw an hour at these kinds of things every month or so. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: ANN: DNS resolver changes in yakkety
On Monday, June 06, 2016 12:27:33 PM Stéphane Graber wrote: > On Mon, Jun 06, 2016 at 03:17:51PM +0100, Robie Basak wrote: > > There's a thread here on Ubuntu and systemd-resolved: > > https://lists.dns-oarc.net/pipermail/dns-operations/2016-June/014964.html > > > > > > > > It looks like there is some credible criticism here that is worth > > considering. > > They do have some very very good points, my main concerns after reading > the e-mail above are: > > - Anything which doesn't use the C library resolving functions, which >would include any static binary bundling its own copy of those, will >fallback to /etc/resolv.conf and not get split DNS information or the >desired fallback mechanism. > >This is likely to affect a whole bunch of Go binaries and similar >statically built piece of software. It will also, probably more visible >affect web browsers who have recently all switches to doing their own >DNS resolving. The Python interpreters have socket.gethostbyname which is, I believe, a thin layer over the C function, but neither of the two major Python DNS implmentations (python-dns and dnspython source packages) do. They parse /etc/resolv.conf and generate their own queries, so if I understand it correctly the Python world would end up not even internally consistent. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Python Click Package Naming
There are two completely different click packages with claims on the python-
click name space. The Ubuntu unique click package related to the click
packaging format is one. The other is python-click, a wrapper around python
optparse.
click has a python3-click binary. python-click has python-click and python3-
click (in Debian). In Ubuntu, the python-click binaries were renamed to
python-click-cli and python3-click-cli to deconflict the namespace.
The click python3-click has no reverse-depends outside the click package. In
Debian, python-click has several rdepends, only a few of which have be adapted
for the Ubuntu name change:
$ reverse-depends python-click
Reverse-Depends
===
* python-cligj
* python-cookiecutter
* python-rasterio [amd64 arm64 armel armhf mipsel]
* python-riemann-client
* python-snuggs
* python-softlayer
I noticed this situation when my latest upload of python-softlayer wouldn't
migrate from -proposed to -release.
I think it would make more sense to have the actual python-click that is used
by many packages to have the Python policy compliant names of python{3}-click
rather than an Ubuntu only package with no rdepends.
Scott K
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ease of enabling -proposed
On Wednesday, March 11, 2015 04:18:29 PM Rodney Dawes wrote: > On Wed, 2015-03-11 at 18:11 +, Iain Lane wrote: > > Similar to you, I'm unsure about the benefit for stable releases. There > > are probably cases where users struggling with bugs, or just trying to > > verify them, appreciate being able to get proposed updates easily. Both > > enabling NotAutomatic and removing the UI would make this harder. I'm > > not sure about the tradeoff here. > > What if, instead, we remove the checkbox from the UI, add the > NotAutomatic feature, and also enable the proposed archive in > sources.list? This way, the udpates would not be automatic, there > wouldn't be any confusing UI, and it should be relatively easy to have > SRU testing done for specific packages, by having a link or something > which installs the specific packages from proposed for testing. People > who don't want/need it won't get anything. People who want all the > proposed packages can enable them if they want. And people who just want > to test an SRU can click a link in the bug report or SRU testing request > e-mail, to install the relevant packages. > > Does that sound feasible? -proposed isn't meant to be something large numbers of end users normally run packages from. It's really a different case than what NotAutomatic was designed for. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [Ubuntu-bugcontrol] Please, consider reflecting on the Canonical Contributor Agreement
On Sunday, January 04, 2015 11:45:30 PM Marc Deslauriers wrote: > >>> I don't know how much of a problem Canonical's competitors claim the CLA > >>> is. I can point to specific instances of it being problematic in the > >>> areas of the project I'm involved in. > >> > >> I'm sure the alternative that was ultimately chosen will work out just > >> fine.> > > > > > > Ultimately, I'm sure your right. I think it would, however, have been > > better for all concerned if non-technical barriers to contribution did > > force two efforts where one would have done. > > Sorry, but I'm pretty sure some other barriers would have prevented > contributions if a simple CLA was the first thing that was blamed. Do KDE > developers not contribute to Qt? Or is Qt only used because there is no > valid alternative? Snipping down to just this since I think the discussion is largely at or past the point of diminishing returns (we disagree on some stuff and I think that's fine). I think for KDE there is a particular history that causes Canonical to be treated differently than whoever owns Qt at the moment. Here's the history lesson for those that weren't around. KDE/Canonical collaboration got started as part of the development effort for Kubuntu Karmic (9.10) [1]. It was built around the idea of joint collaboration. Canonical was contributing both to it's own repositories and KDE upstream. This later evolved into a joint effort on systray replacement [2]. This evolved into libdbusmenu-qt which had a combination of Canonical and KDE contributions. Then, later in the year, the day after one prominant KDE contributor declined to sign the Canonical Contributor Agreement [3], without notification, all of the KDE contributed code was removed [4] and development was moved to Launchpad [5]. Since, as I've mentioned up-thread, the CA/CLA have never been relevant to Ubuntu (the distro), in order to prevent regressions with the new release, we added it all back as a distro patch [6] and carried the patch until the code had been rewritten by Canonical [7]. The situation with Qt is far different. Note in this earlier post by the same person the distinction [8]. Also, the objections weren't about the concept, but about the specifics of the CA [9]. The CLA is clearly a great improvement over the original CA, but I think for a number of people in KDE, Canonical is now in the once bitten, twice shy category. "Hey, my agreement is better now and I promise I won't retroactively change conditions on accepting contributions and throw away your code again" is probably not going to sound attractive. Which, at the end, gets us to the LightDM example where the CLA (with that history behind it) ends up being the sole reason SDDM is selected instead [10]. If LightDM/SDDM had been the first time this came up, I suspect it wouldn't have been such an issue. It likely would have been manageable if the CLA had just applied to the front end and not the back end as well since KDE would have been using it's own front end, not covered by the CLA since it's not Canonical developed. Scott K [1] http://skitterman.wordpress.com/2009/07/17/kubuntu_ayatana_has_arrived/ [2] http://aseigo.blogspot.com/2010/04/system-tray-progress.html [3] aseigo.blogspot.com/2010/09/copyright-assignments-gone-wild-or-why.html [4] http://bazaar.launchpad.net/~dbusmenu-team/libdbusmenu-qt/trunk/revision/177 [5] http://bazaar.launchpad.net/~dbusmenu-team/libdbusmenu-qt/trunk/revision/180 [6] https://launchpad.net/ubuntu/+source/libdbusmenu-qt/0.6.3-0ubuntu1 [7] https://launchpad.net/ubuntu/+source/libdbusmenu-qt/0.8.0-0ubuntu1 [8] http://aseigo.blogspot.com/2010/08/copyright-assignments-of-third-kind.html [9] http://aseigo.blogspot.com/2010/09/copyright-assignments-gone-wild-or-why.html?showComment=1284586036043 [10] http://aseigo.blogspot.com/2013/03/logging-into-plasma-workspaces-2.html -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [Ubuntu-bugcontrol] Please, consider reflecting on the Canonical Contributor Agreement
On Sunday, January 04, 2015 17:39:07 Marc Deslauriers wrote: > On 2015-01-04 03:48 PM, Scott Kitterman wrote: > > On Friday, January 02, 2015 16:38:13 Marc Deslauriers wrote: > >> On 2015-01-02 04:09 PM, Scott Kitterman wrote: > >>> On Friday, January 02, 2015 01:45:48 PM Stephen M. Webb wrote: > >>> ... > >>> > >>>> Argument: The CLA grants more rights to Canonical than the contributor > >>>> gets. > >>>> > >>>> Response: No, it definitely does not. It grants to Canonical a > >>>> clearly > >>>> defined subset of the rights the contributor has, yet the contributor > >>>> keeps > >>>> all his or her original rights. The contributor loses nothing save > >>>> maybe > >>>> the ability to personally control what Canonical can do with its > >>>> investment, and that's not a right but an unintended consequence that > >>>> the > >>>> unethical can use to their advantage. The premise is invalid. > >>> > >>> ... > >>> > >>> Snipped the rest, since it doesn't, IMO, need further discussion. > >>> > >>> Here you're wrong. If Canonical releases GPL code, the GPL constrains > >>> what I can do with that code. Since Canonical is the copyright owner, > >>> they are not constrained. If I contribute code under the CLA, Canonical > >>> is not constrained to the GPL like I am regarding the code in that > >>> project. They have the same rights over my code as if they had written > >>> it. > >> > >> Exactly, so as a contributor, you can't remove rights that Canonical > >> already has over the code they've developed. > > > > Of course not and the lack of the CLA doesn't do that. > > Yes it does. The lack of a CLA would prevent Canonical from re-licensing the > code, which would mean a single contributor could remove the right > Canonical already has. > > In fact, Canonical > > threw away code from external contributors that declined to sign the > > original copyright assignment (which was replaced by the current CLA) and > > rewrote it themselves. That claim doesn't make any sense. > > Of course it does. If you contribute code to a project but don't sign a CLA > or assign copyright, you are preventing the copyright owner from > re-licensing the code. The kernel will forever be stuck on GPLv2 even > though GPLv3 is now available which is better. Hopefully the GPL license > will never get struck down in court somewhere. It only prevents relicensing of the contributed code to the extent the licenses are incompatible. It has no impact on existing code. Admittedly, in the case of something like the Linux kernel there are so many contributors that's a difference without distinction. In the case of Appmenu-Qt where the contributed code was removed and re-written that clearly could have also been done later if there as some need to relicense. > >> If there was no CLA, you could prevent Canonical from relicensing the > >> software to something possibly even better or free-er than the GPL in the > >> future. > > > > That's true, but the primary objection I've seen to the CLA is that it > > permits proprietary relicensing. If that were removed, I for one would > > find it much more reasonable. > > What if it removed the specific mention of proprietary licensing, but > included the possibility of re-licensing it under a BSD license? That would > be a complete equivalent, but for some reason people think that it's better > :) Nothing would prevent Canonical from re-licensing it as BSD, _not_ > redistributing the source, but then using it in a proprietary product. > > I for one agree with RMS on this one, and personally believe that selling > GPL exceptions is acceptable. It's a nice way of advancing free software > development, as long as part of the exception is making sure all > modifications and improvements make their way to the GPL version also. I understand that distributing BSD/MIT licensed code without source is less free than including source distribution, it's not however a proprietary license. I think that's a reasonable distinction that the "this only makes sense if you only contribute to GPL projects" argument misses. I, for one, enjoyed seeing RMS in the copyright/license holders for Windows (I think it was 95). > That being said, I'm not aware of any instances where Canonical has actually > exercised their right to re-license code to a p
Re: [Ubuntu-bugcontrol] Please, consider reflecting on the Canonical Contributor Agreement
On Friday, January 02, 2015 16:38:13 Marc Deslauriers wrote: > On 2015-01-02 04:09 PM, Scott Kitterman wrote: > > On Friday, January 02, 2015 01:45:48 PM Stephen M. Webb wrote: > > ... > > > >> Argument: The CLA grants more rights to Canonical than the contributor > >> gets. > >> > >> Response: No, it definitely does not. It grants to Canonical a clearly > >> defined subset of the rights the contributor has, yet the contributor > >> keeps > >> all his or her original rights. The contributor loses nothing save maybe > >> the ability to personally control what Canonical can do with its > >> investment, and that's not a right but an unintended consequence that the > >> unethical can use to their advantage. The premise is invalid. > > > > ... > > > > Snipped the rest, since it doesn't, IMO, need further discussion. > > > > Here you're wrong. If Canonical releases GPL code, the GPL constrains > > what I can do with that code. Since Canonical is the copyright owner, > > they are not constrained. If I contribute code under the CLA, Canonical > > is not constrained to the GPL like I am regarding the code in that > > project. They have the same rights over my code as if they had written > > it. > > Exactly, so as a contributor, you can't remove rights that Canonical already > has over the code they've developed. Of course not and the lack of the CLA doesn't do that. In fact, Canonical threw away code from external contributors that declined to sign the original copyright assignment (which was replaced by the current CLA) and rewrote it themselves. That claim doesn't make any sense. > If there was no CLA, you could prevent Canonical from relicensing the > software to something possibly even better or free-er than the GPL in the > future. That's true, but the primary objection I've seen to the CLA is that it permits proprietary relicensing. If that were removed, I for one would find it much more reasonable. > > It doesn't matter for you, since your contributions are a work made for > > hire and Canonical owns it regardless, but for people in the broader > > community who are doing this for free in the interest of improving free > > software the distinction matters a lot. > > I don't understand this. How does giving Canonical the right to relicense > your contribution conflict with the goal of improving free software? This > only matters to people who exclusively contribute to GPL licensed projects, > right? I mean, if you contribute to something BSD or MIT licensed, you're > basically allowing anyone to make it proprietary. Do BSD and MIT licensed > projects conflict with your goal of improving free software? > > I do agree that if you're a contributor who exclusively contributes to GPL > licensed projects, you may have an issue with Canonical relicensing your > code. In which case, just don't sign the CLA and fork the project, like the > GPL allows you to do. I've heard this argument before and I think it's logically unsound. If the projects in question were BSD/MIT licensed, then it would be right on target, but they aren't. The issue that I've seen most people complain about (and what I think is an issue myself) is the imbalance between outbound rights from contributors and outbound rights from Canonical. > Honestly, I can probably count on my fingers the number of people who had an > actual desire to contribute to Canonical projects but were prevented by the > CLA. If this was as big an issue as some Canonical competitors have made it > out to be, all Canonical's software would already be forked in various PPAs > and repositories. SDDM basically exists because of the CLA (at least it's being used in KDE because of it). Canonical projects like Appmenu-Qt (I think that's the right one) had contributors from non-Ubuntu KDE contributors before the copyright assignment/CLA policies were instituted. Maintaining a fork is a lot of work. Generally people aren't going to fork, they're just going to use something else that it's easier to contribute to. In the one case I'm familiar with, forking LightDM instead of using the substantially less mature SDDM was never even considered. As far as I know, much of what Canonical produces isn't even packaged outside Ubuntu, so I don't think there's a great deal of demand that would lead to forks. I don't know how much of a problem Canonical's competitors claim the CLA is. I can point to specific instances of it being problematic in the areas of the project I'm involved in. > > I get that it doesn&#
Re: [Ubuntu-bugcontrol] Please, consider reflecting on the Canonical Contributor Agreement
On Friday, January 02, 2015 01:45:48 PM Stephen M. Webb wrote: ... > Argument: The CLA grants more rights to Canonical than the contributor > gets. > > Response: No, it definitely does not. It grants to Canonical a clearly > defined subset of the rights the contributor has, yet the contributor keeps > all his or her original rights. The contributor loses nothing save maybe > the ability to personally control what Canonical can do with its > investment, and that's not a right but an unintended consequence that the > unethical can use to their advantage. The premise is invalid. ... Snipped the rest, since it doesn't, IMO, need further discussion. Here you're wrong. If Canonical releases GPL code, the GPL constrains what I can do with that code. Since Canonical is the copyright owner, they are not constrained. If I contribute code under the CLA, Canonical is not constrained to the GPL like I am regarding the code in that project. They have the same rights over my code as if they had written it. It doesn't matter for you, since your contributions are a work made for hire and Canonical owns it regardless, but for people in the broader community who are doing this for free in the interest of improving free software the distinction matters a lot. I get that it doesn't matter to you, but that doesn't make it invalid. I know a lot of reasonable people at Canonical that believe that the broader community shouldn't be so concerned about the CLA as it is today (which is - for the record - a vast improvement on the first iteration), but many people are. I guess if I look at your reply as meaning Canonical funded projects aren't really free software projects, just corporate software development that happens to be done largely in the open and that currently has free licensing, I can see the point, but I hope that's not the way I should be looking at what Canonical is doing. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [Ubuntu-bugcontrol] Please, consider reflecting on the Canonical Contributor Agreement
On Monday, December 29, 2014 01:09:57 PM Stephen M. Webb wrote: > Fact is, when it comes time for me to accept or reject a contribution, I > must outright reject any from an author who has not proven good will, and > that proof is the CLA. Fact is you're required to do so by your employer, so no judgment at all on your part is required. Your thesis would make sense if it required a reciprocal grant of rights. It doesn't. It demands more from the contributor in terms of rights than it granted (I'd find the paperwork annoying, but reasonable if that were not the case). Fact is prior to the CLA, the type of abuses you're worried about didn't happen in the project. In fact, Canonical threw away perfectly good code because some people didn't want to retroactively agree to the original copyright assignment. Fact is it's causing external groups to stay away from contributing to Canonical projects (which contributes to the tautology that the CLA is reasonable because Canonical is the primary/sole contributor). If you want a specific example, the CLA is the only reason SDDM is the KDM replacement in Plasma 5 and not LightDM. Canonical is free to set the rules for contributions to its projects however it wants, but I think you misunderstand why there is a CLA. For Ubuntu (the Linux distribution) there's no CLA and it works fine. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: update cadence & backlog management for Ubuntu on Phones
On Thursday, September 11, 2014 09:30:32 Rodney Dawes wrote: > On Wed, 2014-09-10 at 22:34 -0500, Ted Gould wrote: > > On Wed, 2014-09-10 at 16:06 -0600, Oliver Ries wrote: > > > Update Cadence: > > > > > > * System components: > > > - OTA (over the air) updates in 4 week iterations, starting at > > > > > > retail date > > > > > > - Content > > > > > > - Critical/High bug fixes that are not leading to data loss or > > > > > > loss of major functionality > > > > > > - UX fixes > > > - Prioritized feature backlog > > > > I'm a bit confused here with the feature backlog. Currently we're > > landing fixes in Utopic, and then if appropriate syncing those fixes > > over to the RTM branch to get into the production images. But features > > couldn't land in Utopic because it's in feature freeze. > > Features can still land in Utopic with a freeze exception. There's also > the difference in level of support for main and universe, such that > stuff in universe can be much more lax about freezes, given it is not in > the default Ubuntu install and not "supported" in the same way main is. This is incorrect. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Libav transition in trusty
On Wednesday, July 23, 2014 21:38:31 Reinhard Tartler wrote: > On Wed, Jul 23, 2014 at 2:13 PM, Seth Arnold wrote: > > On Wed, Jul 23, 2014 at 08:31:26AM -0400, Reinhard Tartler wrote: > >> I wonder what's the current status on the Libav10 transition: > >> > >> http://people.canonical.com/~ubuntu-archive/transitions/html/libav10.html > >> > >> It appears to be stuck for some reason. Can we please push it through > >> and manage the fallout afterwards? > >> > >> Thanks for considering. > > > > I understand that the libav transition is being held up in part by my > > security review of librevenge: > > https://bugs.launchpad.net/ubuntu/+source/librevenge/+bug/1328194 > > > > I expect to finish the review today or tomorrow. > > Thank you for your prompt answer and thanks for getting to that soon. > > Nevertheless, just for me to understand, what's the relationship > between these two packages? librevenge is needed for calligra to build which is entangled in the libav transition. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Unity Specific Application Bugs
Bug #1299872 seems to be a Unity specific incompatibility. Is there someone that could take a look at it. Neither upstream nor the Kubuntu team have any ability to troubleshoot issues like this. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Qt 5.3 landing update June 16
On Monday, June 16, 2014 17:28:32 Timo Jyrinki wrote: > The landing this week seems doable, let's do our best to fix the > remaining blockers. Many bugs are being pinpointed to specific root > problems, but we need to get rid of the remaining blockers. > > Done: > - Calendar app AP failures are also on normal images -> qt5.3 tag removed > - telephony-service fix confirmed to fix all address book app > problems, even though it still needs to be properly landed (boiko) > - Qt Creator plugins have functional branches > - popey ran an automated startup of all store apps, taking screenshots > and grabbing crashes > - As mentioned, several bugs combined to be duplicates of the root problems > > Todo blockers (all open bugs http://is.gd/gZFEqm ): > - UITK toolbar empty (SDK team / t1mp) - Gallery, notes and dropping > letter AP failures are related to same root problem - ETA ? > - Land new Oxide (chrisccoulson, oSoMon) - required for truly > functional web browser with compositing enabled also on Qt 5.3 - ETA > this week, the sooner the better > - Qt Creator 3.1.1 Ubuntu plugins (zbenjamin, me) - small packaging > glitches - ETA tomorrow > - Swipe related UITK issues (SDK team / elopio) - Calculator, > messaging AP failures related to swipe have a common root problem, and > the specific swipe behavior changing. There's a related UITK fix being > released via landing-006 silo - ETA tomorrow > - Music app switch to mediascanner2 (Music app devs) - ...after > checking the new branch works as good as with Qt 5.2, since it's long > due and qtgrilo crashes on QT 5.3 - ETA this week, the sooner the > better > - Qt gles packages needed for emulator (rsalveti, me) - > packaging/dependency fixes to qtbase-gles - ETA ? > - Unity8 crashers (Unity 8 team) - memory corruption in Qt? This is > the most worrisome blocker at the moment. > > Store apps testing: > Testing seems good so far with ~99% working with current knowledge. > All store apps have been started in an automated way by, with > screenshots and crashes grabbed. Additionally some manual testing is > being done all the time. The following six apps are known to have some > sort of problem with Qt 5.3, some of which may be related to us > missing the new Oxide (if webapp): > com.popey.nationalrail > com.ubuntu.developer.ken-vandine.pathwind_pathwind > com.ubuntu.developer.mzanetti.tagger_ubuntu-sso > com.ubuntu.developer.agdpsoftware.inkbunnyapp_inkbunnyapp_0.5.6 > com.ubuntu.developer.rick-rickspencer3.franglish_Franglish_0.4 > com.ubuntu.developer.gcollura.saucybacon_saucybacon_1.0.15 Let's please land it Wednesday at the latest then. It will take some time to build and shake out. I think we're better off to push on and sort things out than land at the end of the week and then have people vanish. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Qt 5.3 landing update June 13
On Friday, June 13, 2014 19:43:50 Timo Jyrinki wrote: > Good progress again. Looking at last week's actions: camera works in > addition to video playback, automated autopilot testing is now > functional, bugs for autopilot tests have been filed, store apps seem > quite fine initially, qtbase failing unit tests have been investigated > a bit, packaging and syncs with Debian are mostly done. > > Still todo from last week's list: Qt gles emulator packages (I need > some help from Ricardo), framework bump (Pat, lool), bug fixes (see > below). > > The landing silo [1] is now nearly ready, with some cleaning that > needs to be done at the time of landing as documented in the CI Train > [2] comments because utopic-proposed already has many Qt 5.3.0 > packages from Debian that we will use instead. The emulator (Qt gles) > and Qt Creator plugin packages are still missing. > > On the bugs front, we have 22 bugs open [3] out of 52 filed. > Telephony-service has now a fix that should fix the address book > problems. That would leave us is with: > - 1-3 autopilot test failures in UI Toolkit, gallery-app, > calendar-app, calculator-app > - Unity 8 crasher that is possibly an upstream bug in qtbase (first > backtrace just gotten) > - music-app (/qtgrilo) crashes on startup - probably the best would be > to make the anyway needed switch away from qtgrilo > - webbrowser-app is not working optimally since compositing is > disabled in Qt 5.3, but Oxide Qt already has a fix that should be > landing soon > > Otherwise the landing - with current knowledge - is in quite good > shape. Only 1 store app is confirmed to have a problem on startup at > the moment, while all others should at least start and render (popey > will rerun this semi-automated test). More testing and bugs are > certainly welcome! Read the instructions page [4] for how to enable Qt > 5.3. [5] has more of the todo list explained. > > [1] https://launchpad.net/~ci-train-ppa-service/+archive/landing-005 > [2] https://wiki.ubuntu.com/citrain > [3] http://is.gd/gZFEqm > [4] https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2 > [5] > https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AjuCdq68GSyVdF > I4QzNQdWpfME5aMEV2VXo0cUpOMkE#gid=20 Should I conclude from this that it will or will not get in on Monday as planned? Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Qt 5.3 landing update June 4
On Thursday, June 05, 2014 07:17:05 Timo Jyrinki wrote: > 2014-06-04 17:52 GMT+03:00 Scott Kitterman : > > The major thing this misses is merging from Debian. There are quite good > > Qt5 5.3.0 packages in Debian Experimental and what is uploaded to the > > archive should be based on that work. > > The main modules qtbase and qtdeclarative were already merged with > Debian's Qt 5.3.0 packaging, including the moving of include files in > all Qt modules. Some more merging will be needed at least in case if > Debian changed something between 5.2.1 and 5.3.0. I'll do direct syncs > of the suitable modules to the PPA as well. Traditionally the most > meaningful packaging changes happen in base/declarative. Great. I saw a lot of 5.3.0-0ubuntu1 in the PPA and missed the ones that had been merged. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Qt 5.3 landing update June 4
On Wednesday, June 04, 2014 09:26:48 Pat McGowan wrote:
> A small team is meeting every two days to review status of issues related
> to updating the touch image to Qt 5.3 and getting it into the Utopic
> archive.
>
> The open bug list is at [1] Media playback bugs are the main blockers (Pat)
> UITK Unit tests to be fixed (Leo)
> Silo 5 has the new packages [2] (Timo)
> Upstream javascript bug on Split() [3] has been worked around in toolkit
> and browser, Shorts app has an issue {Zoltan)
> QtCreator issue but can stay with 3.1 if need be (Zoltan)
> Some packaging changes to be done but can land as is (Timo)
> Need this [4] fixed to run automated tests from the PPA (Chris)
> QtLocation may need extra attention as it is pre-release and had some
> changes
> No issues in Unity8 at the moment
>
> We will target Monday June 16 for landing
>
> Cheers
> Pat
>
> [1] Bug list https://bugs.launchpad.net/bugs/+bugs?field.tag=qt5.3
> [2] https://launchpad.net/~ci-train-ppa-service/+archive/landing-005/
> [3] https://bugreports.qt-project.org/browse/QTBUG-39289
> [4] https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1275012
It would be nice if there was some intermediate communication between "we're
looking into it" and "We will target Monday June 16 for landing".
Collaboration is not built this way.
The major thing this misses is merging from Debian. There are quite good Qt5
5.3.0 packages in Debian Experimental and what is uploaded to the archive
should be based on that work.
Also, IIRC, June 16 is the release day for 5.3.1. Can you target the Friday
before? I think it would be less confusing.
Scott K
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Updating QtWebKit to 5.2
On Friday, May 30, 2014 10:29:10 Dmitry Shachnev wrote: > Hi all, > > I would very much like to update qtwebkit-opensource-src to version > 5.2.0. It blocks syncs of other packages, like pyqt5, > qtsensors-opensource-src and qtscript-opensource-src. It is also a > prerequisite for updating Qt itself to version 5.3 (as qttools now > depends on qtwebkit). > > According to Timo in > > https://code.launchpad.net/~mitya57/kubuntu-packaging/qtwebkit-merge-with-debian/+merge/216539: > > This looks it'd be great to have so I'm planning to build this for testing > > in addition to qtbase and qtdeclarative when U opens, but we need to > > check with webapps people (= dbarth, alex-abreu) on how they see this. > > > > I'm not clear on what's the schedule for full Oxide moving. In addition to > > touch also desktop is currently including libqt5webkit5 in default > > install still (checked with seeded-in-ubuntu qtwebkit-opensource-src). > > Does anybody know when it will be possible to upload this? > > I do not want to break Touch stuff, but I am already waiting for more > than a month and don't want to wait more. There comes a point where you can't be blocked by other's non-responsiveness. Let's do it Monday unless someone else comes up with a better plan. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Point of reviews
On Thursday, May 29, 2014 14:48:24 Colin Watson wrote: > On Fri, May 23, 2014 at 12:01:43PM -0400, Scott Kitterman wrote: > > On Friday, May 23, 2014 19:54:05 Dmitry Shachnev wrote: > > > Does this mean that anyone can bypass the NEW queue by uploading a > > > package to any PPA and then copying it using copy-package? > > > > > > If yes, then I would consider it a security hole. > > This is https://bugs.launchpad.net/launchpad/+bug/993120. I think I've > finally figured out how to fix this without blocking on more fundamental > redesign work, so I'm working on this now. > > > Particularly since the list of people that can upload to the relevant PPAs > > is not constrained to Ubuntu developers. It not only can bypass New, it > > can bypass all the normal sponsorship process. > > I raised this in a discussion today about the CI Airline (which will be > replacing CI Train soon), requesting that we make sure that the Airline > uses LP's checkUpload method to ensure that every change it lands has > been reviewed by (at least) somebody who can upload the package in > question; in my mind that makes it equivalent to a fancy sponsorship > system for this purpose. This is on the to-do list for the Airline now, > if I'm reading the task list correctly. Thanks for working on this. It seems to me the key control point is whatever controls if something is eligible to go into the archive. If that's a review, then what you're suggesting seems spot on. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Point of reviews
On Friday, May 23, 2014 12:23:50 Stéphane Graber wrote: > On Fri, May 23, 2014 at 08:14:57PM +0400, Dmitry Shachnev wrote: > > On Fri, May 23, 2014 at 8:01 PM, Scott Kitterman wrote: > > > Particularly since the list of people that can upload to the relevant > > > PPAs is not constrained to Ubuntu developers. > > > > No, I meant: is it possible to bypass the queue with only "relevant > > PPAs" or with any PPA? > > To skip binNEW entirely, you need a devirt PPA (building on the distro > builders instead of the PPA builders) and have all architectures > enabled. Otherwise the binary packages will get rebuilt post-copy and > will hit the queue at that point. Which limits this to Canonical employees (as far as I know), but the decision to grant upload rights to the archive is supposed to be a community process delegated to the DMB, not an internal Canonical process. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Point of reviews
On Friday, May 23, 2014 20:14:57 Dmitry Shachnev wrote: > On Fri, May 23, 2014 at 8:01 PM, Scott Kitterman wrote: > > Particularly since the list of people that can upload to the relevant PPAs > > is not constrained to Ubuntu developers. > > No, I meant: is it possible to bypass the queue with only "relevant > PPAs" or with any PPA? Only certain PPAs lead into the CI process which is where the bypass is. For PPAs generally, there is no review, nor should there be. They aren't part of Ubuntu and users get warnings about them being untrusted. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Point of reviews
On Friday, May 23, 2014 19:54:05 Dmitry Shachnev wrote: > On Fri, May 23, 2014 at 7:27 PM, Didier Roche wrote: > >> Since CI train packages are mostly Ubuntu specific (Qt5 is > >> somewhat unique in this regard), I'd suggest those need review in New > >> much > >> more than the 75% of our packages we get from Debian unmodified that have > >> already been through New there. > > > > This is the case since we had daily release and it's a bug/feature in > > Launchpad itself. > > Does this mean that anyone can bypass the NEW queue by uploading a > package to any PPA and then copying it using copy-package? > > If yes, then I would consider it a security hole. Particularly since the list of people that can upload to the relevant PPAs is not constrained to Ubuntu developers. It not only can bypass New, it can bypass all the normal sponsorship process. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Point of reviews
On Friday, May 23, 2014 17:39:23 Didier Roche wrote: > Le 23/05/2014 17:37, Didier Roche a écrit : > > Le 23/05/2014 17:34, Scott Kitterman a écrit : > >> On Friday, May 23, 2014 17:27:12 Didier Roche wrote: > >>> Le 23/05/2014 16:35, Scott Kitterman a écrit : > >>>> The other thing I didn't know is that CI train uploads bypass the New > >>>> queue in Ubuntu. That made my comment irrelevant anyway. This is a > >>>> bug > >>>> that REALLY needs fixing. Since CI train packages are mostly Ubuntu > >>>> specific (Qt5 is somewhat unique in this regard), I'd suggest those > >>>> need > >>>> review in New much more than the 75% of our packages we get from > >>>> Debian > >>>> unmodified that have already been through New there. > >>> > >>> This is the case since we had daily release and it's a bug/feature in > >>> Launchpad itself. > >>> > >>> This has been discussed multiple times at UDS and vUDS. It's exactly > >>> the > >>> reason why that every packaging changes are halting publication (in > >>> daily release previously, and now, in CI Train) and someone with the > >>> proper rights (uploads rights or archive admins, depending on the > >>> process) are reviewing the packaging diff before pushing the > >>> publication > >>> button. > >> > >> Did an archive admin review the upload that kicked off this > >> discussion before > >> it was released to the archive? > > > > I guess Robru did that as part of the process (as he seems to be the > > one publishing it), Robert? > > My mistake, actually, checking the logs, it was Timo publishing it. This is the fundamental problem. For normal uploads this kind of review is enforced. For CI train, it's a matter of someone remembering. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Point of reviews
On Friday, May 23, 2014 17:27:12 Didier Roche wrote: > Le 23/05/2014 16:35, Scott Kitterman a écrit : > > The other thing I didn't know is that CI train uploads bypass the New > > queue in Ubuntu. That made my comment irrelevant anyway. This is a bug > > that REALLY needs fixing. Since CI train packages are mostly Ubuntu > > specific (Qt5 is somewhat unique in this regard), I'd suggest those need > > review in New much more than the 75% of our packages we get from Debian > > unmodified that have already been through New there. > > This is the case since we had daily release and it's a bug/feature in > Launchpad itself. > > This has been discussed multiple times at UDS and vUDS. It's exactly the > reason why that every packaging changes are halting publication (in > daily release previously, and now, in CI Train) and someone with the > proper rights (uploads rights or archive admins, depending on the > process) are reviewing the packaging diff before pushing the publication > button. Did an archive admin review the upload that kicked off this discussion before it was released to the archive? Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Point of reviews
On Friday, May 23, 2014 15:47:33 Timo Jyrinki wrote: > 2014-05-23 14:41 GMT+02:00 Scott Kitterman : > > If you look at this merge proposal, it was disapproved with a suggestion > > that it was premature. Despite that, it got released and into the > > archive anyway. > > > > So what's the point of review? > > I'm not sure if you noticed the timeline, but it got released before > the reviews. Had I read negative reviews before I hit the publish > button in CI Train, I wouldn't have released it. No. I hadn't noticed. This was pointed out to me on IRC also. > I didn't wait long with this trivial typo fix since I haven't been > expecting reviews (I noticed a change earlier this week when I was > preparing qtpim). I've largely worked alone on the Ubuntu side with > some awesome help from other developers working on Ubuntu Phone and > mitya57 regarding Qt 5 and the syncing with Debian. The other thing I didn't know is that CI train uploads bypass the New queue in Ubuntu. That made my comment irrelevant anyway. This is a bug that REALLY needs fixing. Since CI train packages are mostly Ubuntu specific (Qt5 is somewhat unique in this regard), I'd suggest those need review in New much more than the 75% of our packages we get from Debian unmodified that have already been through New there. As discussed at the last vUDS, this is the first cycle where there are other Kubuntu packages using Qt5, so you should definitely expect more interest from Kubuntu developers. > Just let me know eg. on IRC if you want to start working on anything > related to Qt 5.3.0 packaging so that I can double-check everything I > have currently brewing is committed to some bzr branch. I first did a > "quick but ugly" PPA build > (https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2) and > I'm now slowly working on a tests enabled, symbols updated versions in > parallel. That will also need to be readjusted later at minimum to > sync with Debian. > > The final Qt 5.3.0 landing should also be prepared by doing archive > quality uploads to a CI Train silo, so that it can be fully tested and > then published as a whole. As Ubuntu Phone is not just ramping up but > doing daily releases, it's important not to disturb this process. The > silos work neatly in this regard, since they also allow syncing > packages from Debian to the PPA from where the whole set of tested > components is then synced to archives. The whole phone thing is why we got blocked before. Kubuntu is currently blocked on lack of 5.3.0, so we need to move forward. As discussed at the last vUDS, if that's a problem for phone, they need to make their own packages of an older version and use them. > > I'm starting to think Canonical's Qt5 stack should go in it's own > > namespace > > separate from the one used by Debian/Kubuntu as was discussed at the last > > vUDS. I don't sense much interest in collaboration. > > The Qt5 was originally put to under ~kubuntu-packagers even though it > was only used by Ubuntu so that it could be worked on in co-operation > in the long term more easily. Co-operation has in my opinion worked > nicely with anyone who has been willing to contribute to the packaging > work. Obviously with Ubuntu as the almost sole user of Qt 5 so far it > has been largely people working on Ubuntu Phone, but that's changing > now. Obviously I was missing some data when I made this assertion. I've been following Qt5 packaging in Debian pretty closely. I think focusing on helping lisandro get good 5.3.0 packages in experimental and merging from there is what we should be doing. If we have archive quality packages, they should get uploaded to the archive. CI train is causing more trouble than it's worth for these packages. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Point of reviews, was Fwd: Re: [Merge] lp:~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_fixpkgname into lp:~kubuntu-packagers/kubuntu-packaging/qtdeclarative-opensource-src
If you look at this merge proposal, it was disapproved with a suggestion that it was premature. Despite that, it got released and into the archive anyway. So what's the point of review? If the result of a negative review is "Oh, we ignored you, we'll override the disapproval and merge anyway." Why even bother? Just merge whatever you feel like. I'm starting to think Canonical's Qt5 stack should go in it's own namespace separate from the one used by Debian/Kubuntu as was discussed at the last vUDS. I don't sense much interest in collaboration. Scott K -- Forwarded Message -- Subject: Re: [Merge] lp:~timo-jyrinki/kubuntu-packaging/qtdeclarative- opensource-src_fixpkgname into lp:~kubuntu-packagers/kubuntu- packaging/qtdeclarative-opensource-src Date: Friday, May 23, 2014, 06:20:27 From: Timo Jyrinki To: Timo Jyrinki This was released, and accepted during the night, so I'm going to approve this for merging anyhow. We try to be as quick as possible with Qt 5.3. -- https://code.launchpad.net/~timo-jyrinki/kubuntu-packaging/qtdeclarative-opensource-src_fixpkgname/+merge/220601 You are reviewing the proposed merge of lp:~timo-jyrinki/kubuntu- packaging/qtdeclarative-opensource-src_fixpkgname into lp:~kubuntu- packagers/kubuntu-packaging/qtdeclarative-opensource-src. - -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Qt5 Plans For Utopic
On Tuesday, May 20, 2014 08:06:11 Scott Kitterman wrote: > On Tuesday, May 20, 2014 11:15:56 Pat McGowan wrote: > top posting fixed. > > > On Wed, May 14, 2014 at 1:58 PM, Scott Kitterman > > wrote: > > > This cycle the Kubuntu team has work planned (packaging Plasma 5, the > > > Qt5 > > > based KDE desktop environment) that requires Qt 5.3. Is there any > > > objection > > > to making Qt 5.3 the targeted major Qt5 release for 14.10? > > > > Hi Scott > > > > We are doing some testing with Qt 5.3 now. Preferably we would target it > > for 14.10 barring any unforeseen issues. What is the dependency KDE has on > > Qt 5.3? > > It's a requirement for the upcoming Plasma 5/Plasma Next (they are still > arguing about the name as far as I can tell) - the Qt5 based version of the > KDE Plasma Workspaces. We don't intend to ship it to our users as our > primary release in 14.10, but we have decided we want to make it available. > > Qt 5.3.0 is now released and Debian has started packaging it, so I'd like to > make this transition in the near future (as discussed at the last UDS, this > ought to be done earlier rather that later in the development cycle). Git head for plasma-next now requires Qt 5.3, so the lack of it is blocking Kubuntu work. It's not fully packaged yet, so the lack of any consensus on moving to it hasn't stopped anything yet, but we need to move forward on this ASAP. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Qt5 Plans For Utopic
On Tuesday, May 20, 2014 11:15:56 Pat McGowan wrote: top posting fixed. > On Wed, May 14, 2014 at 1:58 PM, Scott Kitterman wrote: > > This cycle the Kubuntu team has work planned (packaging Plasma 5, the Qt5 > > based KDE desktop environment) that requires Qt 5.3. Is there any > > objection > > to making Qt 5.3 the targeted major Qt5 release for 14.10? > Hi Scott > > We are doing some testing with Qt 5.3 now. Preferably we would target it > for 14.10 barring any unforeseen issues. What is the dependency KDE has on > Qt 5.3? > It's a requirement for the upcoming Plasma 5/Plasma Next (they are still arguing about the name as far as I can tell) - the Qt5 based version of the KDE Plasma Workspaces. We don't intend to ship it to our users as our primary release in 14.10, but we have decided we want to make it available. Qt 5.3.0 is now released and Debian has started packaging it, so I'd like to make this transition in the near future (as discussed at the last UDS, this ought to be done earlier rather that later in the development cycle). Scott K P.S. I'm subscribed to the list so there's no need to cc me. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Qt5 Plans For Utopic
This cycle the Kubuntu team has work planned (packaging Plasma 5, the Qt5 based KDE desktop environment) that requires Qt 5.3. Is there any objection to making Qt 5.3 the targeted major Qt5 release for 14.10? Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: errors.ubuntu.com and upgrade crashes
On Wednesday, May 14, 2014 01:07:51 Robert Park wrote: > On Tue, May 13, 2014 at 5:47 PM, Bjoern Michaelsen > > wrote: > >> > ... e.g. trivially: mark crashers 48hours after the upgrade > >> > as 'potentially an upgrade sideeffect' or somesuch? > >> > >> Probably not retroactively. But I imagine it would be fairly easy to > >> add info to future error reports asking if do-release-upgrade (or > >> whatever) was running at the time. > > > > That would be very useful indeed. I assume the version data sent to > > errors.ubuntu.com in these cases to be wrong and poisoning the well > > anyway: > > - the client will send an error report with the application version the > > package> > > manager reports to be installed > > > > - the application crashed will actually be a older, different one. > > This has bit me a couple of times, although I didn't understand what > was happening at the time. > > I've seen certain python tracebacks in errors.ubuntu.com that, if you > check the version number specified in the crash, you find that the > code causing the traceback literally does not exist (in that version). > The only explanation is that the user was running an older copy, which > crashed, but the report contains the version number of the updated > package. > > > It would be ideal to fingerprint the crashed binary and compare it to the > > version installed on disc, and skip reporting if those differ. > > In the case of python programs you'd want to be sure to fingerprint > all the various .py files that might be loaded... probably better to > fingerprint every file in the package, if any differ then the report > is invalid. If packages are crashing during an upgrade, that's still a bug, it's just a different one. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: ANN: TRAINCON-0 - CITRAIN all stop starting Friday
On Friday, March 21, 2014 11:33:35 Alexander Sack wrote: > Hi, > > On Fri, Mar 21, 2014 at 3:23 AM, Scott Kitterman wrote: > > On Thursday, March 20, 2014 18:58:28 Alexander Sack wrote: > >> Hi, > >> > >> I am sending this as a proxy for the not-yet existing TRAINCON bot > >> that will give you updates about our touch image alert state that come > >> with individual landing rules. > >> > >> The TRAINCON levels that were discussed at UDS are: > >> > >> - TRAINCON-2 - everything green, normal landing rules apply > >> - TRAINCON-1 - no promotion for 2 days, restricted landing rules that > >> avoids risks and fastpath regression fixes apply > >> - TRAINCON-0 - no promotion for 5 days, regression fixes only rules apply > >> > >> Since we were not able to promote a touch image since last friday, we > >> want to pursue according to the vUDS scheme above and move on to > >> TRAINCON-0 state for our touch images. To make that happen, I have > >> given the directive to the Landing Team to put the CITrain in "all > >> stop" mode first thing Friday morning in Europe. If you have > >> questions, concerns or want an exception of this "all stop" approach, > >> please contact me (asac) or in case I am not around rickspencer3 > >> directly. > >> > >> We also kindly ask our core-devs with direct upload power for their > >> support. Please wait with your uploads that affect touch until we have > >> fully recovered. > >> > >> The bugs that are needed to get fixed are below: > >> * music-app: https://bugs.launchpad.net/music-app/+bug/1292306 (Kevin > >> > >> and Saviq) > >> > >>- Upon upgrading to Qt5.2 the music app no longer plays the next > >> > >> song if the screen is off > >> > >> * alarms: > >> https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1295122 > >> (Thomas S.) > >> > >>- Alarms not going off reliably on recent touch images > >> > >> * alarms: > >> https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1295237 > >> (Thomas S.) > >> > >> - Alarm ringing not going off when clicking dismissed and you have > >> > >> to reboot the phone to stop it. > >> > >> Thanks for everyone helping us in the past week flashing out many bugs > >> related to the qt transition and special helps for those brave heros > >> that currently work hard to get these three blockers sorted. > > > > If you want to make changes in current policy for archive uploads, I think > > that should be coordinated with ubuntu-release. "But it's phone ..." > > doesn't give free reign to bypass the community structure of Ubuntu. > > Sorry if you read it like this, but this is no attempt to change > policies for distro at all! > > It's merely a measure to gauge the influx of our (Canonical Touch) > engineering teams so we can achieve our continuous quality and > delivery goals. Think of it like a "voluntarily" self imposed higher > quality bar for Touch engineering teams and friends. > > As mentioned in the mail, for individual cases where this measure > makes things tricky for the distro stakeholders, we would like to hear > about them so we can see how we can help/fix this. > > On qt, we have already admitted that it is not good practice to do it > like we did it this cycle and that we only did it because we were > fully aware that kubuntu was not blocked on it - and we also got > regularly feedback from kubuntu (I was told) while doing this. If not, > then that's what we should do better for sure. Because, for reasons unrelated to Qt5 landing, Kubuntu decided not to land KDE Frameworks 5 in the archive this cycle, the impact was minimal. The main reason I point it out is that if the same landing philosophy is used next cycle it will have a major impact on us. No one wants to upload things that are going to cause severe, prolonged breakage, but the balance between getting things mature before upload and just firing things straight into the archive is far too risk averse right now. If this traincon thing is going to stick around, I think Qt5 ought to just be uploaded normally and not be treated as part of the CI stack next cycle. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: ANN: TRAINCON-0 - CITRAIN all stop starting Friday
On Thursday, March 20, 2014 20:30:42 Adam Conrad wrote: > On Thu, Mar 20, 2014 at 10:23:44PM -0400, Scott Kitterman wrote: > > On Thursday, March 20, 2014 18:58:28 Alexander Sack wrote: > > > The bugs that are needed to get fixed are below: > > > * music-app: https://bugs.launchpad.net/music-app/+bug/1292306 (Kevin > > > > > > and Saviq) > > > > > > * alarms: > > > https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/129512 > > > 2 > > > (Thomas S.) > > > > > > * alarms: > > > https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/129523 > > > 7 > > > (Thomas S.) > > > > If you want to make changes in current policy for archive uploads, I think > > that should be coordinated with ubuntu-release. "But it's phone ..." > > doesn't give free reign to bypass the community structure of Ubuntu. > > I might also point out that this is completely backwards. I think we > would absolutely understand (and the community might not only play > along but even help out) if this was a case of "We're seeing a ton of > massive crashes throughout the phone and we can't track it down, can > you please not churn the bases sytem for a bit while we hunt." > > This isn't that. These are leaf packages. It's not remotely scalable > in a massive distributed project to ask everyone else to not upload > glibc, dbus, bash, upstart, etc (all things that are on phone images), > because of some bugs in some leaf packages. > > Lots of leaf packages have bugs. If we "stopped the line" for every > package with a bug, we'd get exactly nothing done. Stopping the line > for the engineers who work on those packages is fine, and refocussing > their efforts on fixing the bugs is even more fine. Asking everyone > else to twiddle their thumbs while that happens isn't. > > This timing is extra unpleasant, as we (the release team) are about to > freeze the world for the beta on Monday. Asking people not to upload > between now and then is denying them four days to get their pre-beta > fixes in, none of which would affect the current state of the above > three apps. > > ... Adam This is a good point. One of the big problems in this cycle was the late landing of Qt5. As we discussed in the vUDS session, one reason for it coming late was the view that we had to have zero regressions before we could stay out of the archive. In this cycle we survived it because Qt5 only had one major user, but that won't be the case next cycle. In a large integrated project like this it just doesn't scale to stop development every time there's a bump in the road. There will be bumps. QA stuff is great to minimize them, but they're going to happen. The only way to not introduce new issues is to never introduce anything new. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: ANN: TRAINCON-0 - CITRAIN all stop starting Friday
On Thursday, March 20, 2014 18:58:28 Alexander Sack wrote: > Hi, > > I am sending this as a proxy for the not-yet existing TRAINCON bot > that will give you updates about our touch image alert state that come > with individual landing rules. > > The TRAINCON levels that were discussed at UDS are: > > - TRAINCON-2 - everything green, normal landing rules apply > - TRAINCON-1 - no promotion for 2 days, restricted landing rules that > avoids risks and fastpath regression fixes apply > - TRAINCON-0 - no promotion for 5 days, regression fixes only rules apply > > Since we were not able to promote a touch image since last friday, we > want to pursue according to the vUDS scheme above and move on to > TRAINCON-0 state for our touch images. To make that happen, I have > given the directive to the Landing Team to put the CITrain in "all > stop" mode first thing Friday morning in Europe. If you have > questions, concerns or want an exception of this "all stop" approach, > please contact me (asac) or in case I am not around rickspencer3 > directly. > > We also kindly ask our core-devs with direct upload power for their > support. Please wait with your uploads that affect touch until we have > fully recovered. > > The bugs that are needed to get fixed are below: > > * music-app: https://bugs.launchpad.net/music-app/+bug/1292306 (Kevin > and Saviq) >- Upon upgrading to Qt5.2 the music app no longer plays the next > song if the screen is off > > * alarms: > https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1295122 > (Thomas S.) >- Alarms not going off reliably on recent touch images > > * alarms: > https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1295237 > (Thomas S.) > - Alarm ringing not going off when clicking dismissed and you have > to reboot the phone to stop it. > > Thanks for everyone helping us in the past week flashing out many bugs > related to the qt transition and special helps for those brave heros > that currently work hard to get these three blockers sorted. If you want to make changes in current policy for archive uploads, I think that should be coordinated with ubuntu-release. "But it's phone ..." doesn't give free reign to bypass the community structure of Ubuntu. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Changing default CFLAGS on i386
On Thursday, March 06, 2014 09:44:14 Ryan Lortie wrote: ... > By "currently run on" do you mean that we actually run on these in > situations that we know about, or that we have the theoretical ability, > if someone wanted to... > > I'm fairly sure that Unity would not run nicely on any hardware from > late 90s/early 00s. You could maybe repurpose an extremely old machine > as an Ubuntu server and we could be cutting those people out, but they > also have many other options (such as Debian). This could potentially > hurt some flavours like Xubuntu which might actually be capable of > running on hardware of that vintage. > > Looking at some typical historical models released by Dell, machines > that came with Pentium 2 and Pentium 3 chips tended to have between 64MB > (low) and 512MB (very high end). 256MB seems somewhat typical for > Pentium 3 machines, at least. Clocks are in the sub-GHz range and > entirely single-core. It's possible to imagine that XFCE could run > here, but it wouldn't exactly be nice... ... FWIW, I have a dual Pentium III 450 system from ~1999 running Ubuntu Server as a test system. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [RFC] 12.04.5
On Friday, February 07, 2014 20:28:55 Stéphane Graber wrote: > On Fri, Feb 07, 2014 at 05:24:23PM -0800, Steve Langasek wrote: > > On Fri, Feb 07, 2014 at 08:00:12AM -0800, Leann Ogasawara wrote: > > > With 12.04.4 having just released, I wanted to propose the idea of > > > having a > > > 12.04.5 point release for Precise. > > > > > > As many are aware, recent 12.04.x point releases have shipped with a > > > newer > > > kernel and X stack by default for hardware enablement purposes. > > > > > > Maintainers of these enablement stacks have agreed to support these > > > until > > > > > > a Trusty based enablement stack is supported in Precise. Once a Trusty > > > enablement stack is supported, all previous enablement stacks would EOL > > > and > > > be asked to migrate to the final Trusty based enablement stack which > > > would > > > continue to be supported for the remaining life of Precise. > > > > > > Currently, 12.04.4 is our final point release for Precise. 12.04.4 > > > shipped > > > with a Saucy enablement stack by default. This Saucy enablement stack > > > in > > > Precise will eventually EOL in favor of the Trusty enablement stack. > > > Once > > > that happens, our final point release for Precise will be delivering an > > > EOL'd enablement stack. This seems unfortunate and inappropriate. I > > > would > > > like to propose having a 5th point release for Precise which would > > > deliver > > > the Trusty enablement stack for Precise. > > > > > > Providing a 12.04.5 point release will add no additional maintenance > > > burden > > > upon teams supporting enablement stacks in Precise. It would require > > > some > > > extra effort on part of the Canonical Foundations Team as well as the > > > Ubuntu Release Team to spin up an additional set of images and testing > > > coordination etc. However, I informally discussed this with a few > > > members > > > of each of those teams and the tentative agreement was that 12.04.5 was > > > a > > > reasonable request which could be accommodated. Collectively we could > > > find > > > no compelling reason to not provide 12.04.5. We also discussed that a > > > 12.04.5 release should be optional for the Flavors to participate in. > > > > > > Additionally, we would want to purposely avoid clashing the 14.04.1 and > > > > > > 12.04.5 release dates and would suggest releasing 14.04.1 first and > > > 12.04.5 > > > after (exact date TBD). > > > > > > What are other's thoughts here? Does anyone have a compelling reason > > > for > > > not providing a 12.04.5 point release? > > > > For the record, this has the Foundations Team's support as well (we've > > already discussed the resourcing considerations). So unless someone knows > > of a reason why we *shouldn't* go ahead with this, I think the main > > question here is whether the flavors want to participate. > > Speaking with my Edubuntu flavor lead hat on, we'd be happy to participate. If there's a 12.04.5, Kubuntu will participate. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Qt5 plans for trusty
On Wednesday, January 22, 2014 12:09:28 Timo Jyrinki wrote: > 2014/1/22 Aeron Farax : > > QT 5.0 is like "beta" in 5 series, apps that use QT5 and most of them move > > to v5.2 > > > > It would be wise to include 5.2 for sake of LTS > > In progress! Everyone hopes to move to Qt 5.2 as quickly as possible. > Incidentally I just posted an update from Ubuntu Touch point of view > at: > > https://lists.launchpad.net/ubuntu-phone/msg06049.html I think moving sooner (well, it's too late for sooner in the cycle, but now) would be better for everyone. It's a development series and if we wait for everything to be perfect, we'll never get there. Mitya is already having to patch PyQt5 to make it work with the older Qt5 in Ubuntu. 5.2 should get into Debian Unstable soon (it's in Experimental already, just waiting for a transition slot). Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: libqt4-opengl-dev: Different dependencies on armhf than on other architectures
Andreas Moog wrote: >Hi there, > >I have a question about the package libqt4-opengl-dev on the armhf >architecture (source: qt4-x11). I was investigating >https://bugs.launchpad.net/bugs/941062, a build failure of the package >fracplanet and was wondering why it succeeded on all other arches as >well as on armhf in Debian. > >The difference I found was in the dependencies of libqt4-opengl-dev: > >On amd64 (and others) it is: > >Depends: libgl1-mesa-dev | libgl-dev, libglu1-mesa-dev | libglu-dev, >libqt4-dev (= 4:4.8.4+dfsg-0ubuntu19), libqt4-opengl (= >4:4.8.4+dfsg-0ubuntu19) > >But on armhf in Ubuntu (NOT in Debian): > >Depends: libgles2-mesa-dev | libgles2-dev, libqt4-dev (= >4:4.8.4+dfsg-0ubuntu19), libqt4-opengl (= 4:4.8.4+dfsg-0ubuntu19) > >Is there a reason for this difference? How would I go to further find >out why this is what it is? In Ubuntu we only support GLES on arm for performance reasons. This is an intentional difference with Debian. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: On cross-compiling qml extensions, qt packaging needs changing
On Wednesday, September 04, 2013 11:34:55 Scott Kitterman wrote: > Dmitrijs Ledkovs wrote: > >On 4 September 2013 12:09, Scott Kitterman > > > >wrote: > >> Dmitrijs Ledkovs wrote: > >> Changes like this should really be coordinated in Debian so we don't > > > >accumulate long term differences that can't easily be resolved. > > > > > >Yeah, and as far as I know Timo is doing excellent work at keeping > >packaging in sync as much as possible. > >But e.g. w.r.t. multiarch & cross-compilation overall at the moment > >Debian is still far behind Ubuntu, despite myself and many others > >pushing many mutli-arch changes back to debian. > > He is. For changes that can't be pushed to Debian now (I guess such as > this), there should still be up front coordination on the approach so > Ubuntu doesn't head off in one direction and discover later that it's > unacceptable in Debian and then Ubuntu is stuck with a permanent diff or a > lot of rework. > > If such coordination has been done, I haven't seen it on what I would > imagine to be the relevant lists. > >> Why do you need to cross compile QML anyway? It's not like you need > > > >it for bootstrapping. > > > > > >This is not to cross compile QML itself. This is for 3rd party > >developers to cross-compile their compiled qml extensions against > >ubuntu's armhf qt to be included as part of their applications for > >Ubuntu Touch. > >Or e.g. to cross-compile ubuntu-touch-settings or other packages we > >have in the archive that have qml extensions. > >Going via this route though (make qmake support cross-compilation with > >a debian specific toolchain file), will eventually make possible to > >cross-compile qt itself and also be upstream able patches for qmake. > > It sounds at least vaguely reasonable. My main concern is that the > coordination is done. OK, so I checked. No, no coordination had been done and the response I got was that this should be accommodated upstream rather than in the packaging. I think that's reasonable. Before this is done in Ubuntu, there should be some discussion with upstream about a long term plan for supporting this use case. I know an upstream fix won't be available for saucy and likely not even for "T", but the path to an upstream resolution should be started before we start on a divergence like this. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Sponsorship request to Kubuntu Bug Squishing
On Friday, September 06, 2013 17:00:35 Jonathan Riddell wrote: > I'd like to ask the Kubuntu Council for sponsorship to travel to the Munich > bug squishing party > > Costs are flight: £114.32 > hotel room €229.50 > > Of course I'd be happy to share a hotel room with anyone who'll have me. +1. Scott K -- kubuntu-devel mailing list kubuntu-de...@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: On cross-compiling qml extensions, qt packaging needs changing
Dmitrijs Ledkovs wrote: >On 4 September 2013 12:09, Scott Kitterman >wrote: >> Dmitrijs Ledkovs wrote: >> Changes like this should really be coordinated in Debian so we don't >accumulate long term differences that can't easily be resolved. >> > >Yeah, and as far as I know Timo is doing excellent work at keeping >packaging in sync as much as possible. >But e.g. w.r.t. multiarch & cross-compilation overall at the moment >Debian is still far behind Ubuntu, despite myself and many others >pushing many mutli-arch changes back to debian. He is. For changes that can't be pushed to Debian now (I guess such as this), there should still be up front coordination on the approach so Ubuntu doesn't head off in one direction and discover later that it's unacceptable in Debian and then Ubuntu is stuck with a permanent diff or a lot of rework. If such coordination has been done, I haven't seen it on what I would imagine to be the relevant lists. >> Why do you need to cross compile QML anyway? It's not like you need >it for bootstrapping. >> > >This is not to cross compile QML itself. This is for 3rd party >developers to cross-compile their compiled qml extensions against >ubuntu's armhf qt to be included as part of their applications for >Ubuntu Touch. >Or e.g. to cross-compile ubuntu-touch-settings or other packages we >have in the archive that have qml extensions. >Going via this route though (make qmake support cross-compilation with >a debian specific toolchain file), will eventually make possible to >cross-compile qt itself and also be upstream able patches for qmake. It sounds at least vaguely reasonable. My main concern is that the coordination is done. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: On cross-compiling qml extensions, qt packaging needs changing
Dmitrijs Ledkovs wrote: >So at the moment I have hacked up a way to cross compile qml extensions >[1] >The solution is not as fluid and packaging changes are needed in qt* >packages to make all of this nicer. > >Foremost one cannot install ubuntu-sdk for multiple architectures: >$ apt-get install ubuntu-sdk ubuntu-sdk:armhf > >Even a more simple case of: >$ apt-get install qtbase5-dev qtbase5-dev:armhf > >Doesn't install because of GL somewhere down the stack: >qtbase5-dev : Depends: libgl1-mesa-dev but it is not going to be >installed or >libgl-dev > Depends: libglu1-mesa-dev but it is not going to be installed or >libglu-dev >E: Unable to correct problems, you have h > >If you want to experiment with above, enabling armhf is easy: >$ dpkg --add-architecture >Add: >deb [arch=armhf] http://ports.ubuntu.com/ubuntu-ports saucy main >restricted universe multiverse > >To sources.list (if you want to get rid of warnings, other >repositories should list which architectures you want from them, e.g. >[arch=amd64,i386] for nomal ubuntu mirrors) > >Therefore at the moment, I create a chroot where I have most of >-dev:armhf packages & cross-toolchain installed, whilst on the host >system is where I install qmake & generate the makefiles. > >I've hacked up qmake mkspec files which to honour dpkg-architecture >fields which is the standard way to declare native or cross >compilations on Ubuntu. the variables from dpkg-architecutre can be >exported in the environment, or one can use it as a wrapper script: >dpkg-architecture -aarmhf -c qmake [2] >dpkg-architecture -aarmhf -c make clean [3] > >Next the qmake mkspecs are all stored in /usr/share/qt5 which is also >odd, because they are not identical between architectures, thus >ideally all of them should be moved to >/usr/lib/$(DEB_HOST_MULTIARCH)/qt5/mkspec > >Hence at the moment, I have to use sed on the generated Makefiles to >replace -lGL with -lGLESv2. > >But overall one does able to cross compile qml extensions, even using >qmake. But the co-installability of ubuntu-sdk for multiple >architectures must be resolved, otherwise we will be stuck with using >chroots and jumping between host & chroot to complete a single: >configure-clean-build cycle. [4] > >I have started on changing packaging for qtbase-opensource-src but it >seems like it's a rather big task which hopefully SDK team can take >over [5] thus at the moment I'm still monkey-patching in-place system >level directories. > >There is README in the [1] branch outlining how I have cross-compile >the stock qmlextension template example generated by the ubuntu-sdk. >And I'm happy to assist & answer any questions about multiarch & >co-installability requirements here. So far I have filed a couple of >bugs which must be resolved to allow cross-compilation for the >ubuntu-sdk [6] There are a few more, e.g. i couldn't install a few >optional qdeclarative plugins due to non-multiarch reverse >dependencies. > >[1] lp:~ubuntu-core-dev/+junk/qmake-cross >[2] -a means cross-compile from by build architecute to that target >host architecture, e.g. armhf in this case. >[3] if the generated makefiles have "include >/usr/share/dpkg/architecture.mk" then there will be no need to wrap >calls to make. >[4] well since replacing ones host system GL with something else does >usually break stuff >[5] lp:~xnox/kubuntu-packaging/qtbase-opensource-src >[6] https://bugs.launchpad.net/ubuntu/+bugs?field.tag=qmake-cross Changes like this should really be coordinated in Debian so we don't accumulate long term differences that can't easily be resolved. Why do you need to cross compile QML anyway? It's not like you need it for bootstrapping. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Call for Testing: Mir & multi-monitor
Not the versions he's testing. Bugs against PPA packages aren't bugs against Ubuntu and shouldn't be filed that way. Scott K On Tuesday, August 27, 2013 10:49:54 Robert Ancell wrote: > These packages are in Ubuntu: > https://launchpad.net/ubuntu/+source/unity-system-compositor > etc > > On Tue, Aug 27, 2013 at 10:38 AM, Scott Kitterman wrote: > > On Monday, August 26, 2013 23:22:29 Dmitrijs Ledkovs wrote: > > > On 26 August 2013 23:14, Scott Kitterman wrote: > > > > On Monday, August 26, 2013 23:11:32 Dmitrijs Ledkovs wrote: > > > >> On 26 August 2013 22:10, Nicholas Skaggs < > > > > nicholas.ska...@canonical.com> > > > > > > wrote: > > > >> > The Mir team is calling for a round of testing for Mir and > > > >> > multi-monitor > > > >> > support specifically starting today through August 28th. Help us > > > > during > > > > > >> > this round of testing to make sure Mir and features are thoroughly > > > >> > tested > > > >> > on as many devices as possible. > > > >> > > > > >> > You can find all the details you need on this wiki page. The tests > > > > will > > > > > >> > use > > > >> > the ppa:mir-team/system-compositor-testing ppa. Full instructions > > > > can > > > > > >> > be > > > >> > found on the wiki page. > > > >> > > > > >> > https://wiki.ubuntu.com/Mir/MultiMonitorTesting > > > >> > > > > >> > Please report your results good or bad on the provided wiki results > > > >> > page > > > >> > or > > > >> > the package tracker. > > > >> > > > > >> > Thanks for helping make ubuntu better! > > > >> > > > >> I got a crash report from unity-system-compositor, but I cannot > > > >> report > > > >> the bug about it because "This is not an official Ubuntu package". > > > >> Can > > > >> apport configuration please be correctly set in the packages from > > > >> that > > > >> repository to allow reporting bugs to launchpad? > > > > > > > > To where would it report them? > > > > > > Apport allows setting a project in launchpad against which to report > > > bugs from a PPA installed package. > > > Not sure, if it allows enabling reports back against ubuntu pkg. > > > > Isn't that done via a hook in the package? IIRC, there's nothing to be > > done > > centrally in apport. Since these packages aren't in Ubuntu yet, they > > should > > be filed as project specific bugs. > > > > Scott K > > > > -- > > ubuntu-devel mailing list > > ubuntu-devel@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Call for Testing: Mir & multi-monitor
On Monday, August 26, 2013 23:22:29 Dmitrijs Ledkovs wrote: > On 26 August 2013 23:14, Scott Kitterman wrote: > > On Monday, August 26, 2013 23:11:32 Dmitrijs Ledkovs wrote: > >> On 26 August 2013 22:10, Nicholas Skaggs > > > > wrote: > >> > The Mir team is calling for a round of testing for Mir and > >> > multi-monitor > >> > support specifically starting today through August 28th. Help us during > >> > this round of testing to make sure Mir and features are thoroughly > >> > tested > >> > on as many devices as possible. > >> > > >> > You can find all the details you need on this wiki page. The tests will > >> > use > >> > the ppa:mir-team/system-compositor-testing ppa. Full instructions can > >> > be > >> > found on the wiki page. > >> > > >> > https://wiki.ubuntu.com/Mir/MultiMonitorTesting > >> > > >> > Please report your results good or bad on the provided wiki results > >> > page > >> > or > >> > the package tracker. > >> > > >> > Thanks for helping make ubuntu better! > >> > >> I got a crash report from unity-system-compositor, but I cannot report > >> the bug about it because "This is not an official Ubuntu package". Can > >> apport configuration please be correctly set in the packages from that > >> repository to allow reporting bugs to launchpad? > > > > To where would it report them? > > Apport allows setting a project in launchpad against which to report > bugs from a PPA installed package. > Not sure, if it allows enabling reports back against ubuntu pkg. Isn't that done via a hook in the package? IIRC, there's nothing to be done centrally in apport. Since these packages aren't in Ubuntu yet, they should be filed as project specific bugs. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Call for Testing: Mir & multi-monitor
On Monday, August 26, 2013 23:11:32 Dmitrijs Ledkovs wrote: > On 26 August 2013 22:10, Nicholas Skaggs wrote: > > The Mir team is calling for a round of testing for Mir and multi-monitor > > support specifically starting today through August 28th. Help us during > > this round of testing to make sure Mir and features are thoroughly tested > > on as many devices as possible. > > > > You can find all the details you need on this wiki page. The tests will > > use > > the ppa:mir-team/system-compositor-testing ppa. Full instructions can be > > found on the wiki page. > > > > https://wiki.ubuntu.com/Mir/MultiMonitorTesting > > > > Please report your results good or bad on the provided wiki results page > > or > > the package tracker. > > > > Thanks for helping make ubuntu better! > > I got a crash report from unity-system-compositor, but I cannot report > the bug about it because "This is not an official Ubuntu package". Can > apport configuration please be correctly set in the packages from that > repository to allow reporting bugs to launchpad? To where would it report them? Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: vUDS Scheduling
I agree it's better to do it in public. I'm surprised it's enough effort to be worth a vUDS, but if it is, it is. Scott K On Monday, August 19, 2013 18:45:33 Daviey Walker wrote: > Hi Scott, > > I can only speak on behalf of the Cloud and Server track, but I'd like > to clarify how we intend to use this. Unlike a start-of-cycle vUDS, > this is a midcycle checkpoint opportunity. > > The purpose of this, is to drive existing blueprints to completion. > > This is an chance for those involved in Cloud and Server to do a > 'show-and-tell' of blueprints defined 3 months ago. We can evaluate > decisions made then, check if assumptions were correct, anything we > feel needs to be re-addressed and some re-scoping. Very little (if > any), new work should come from this. > > The Canonical Server team previously did this same exercise but at an > internal-only mid-cycle sprint. This is largely the same thing, but > out in the open. THIS i am a big fan of and I am sure you are also > supportive of this. > > Personally, I think the timing to clash with feature freeze lends > itself nicely. This is the time that blueprints should be de-scoped > if they are clearly not on track with features, and anything we > /really/ need to see this cycle - can be considered very carefully > with risk mitigation. > > If you have any questions about this, please feel free to give me a shout. > > > I agree that this is useful for Canonical upstreams trying to map out > > their > > next three - six months' work. From a distro development perspective, not > > so much. I would hope there's a look beyond the next three months. By > > starting to plan for 14.04 now, they'll be in a much better position to > > understand what needs doing and when to land things in the archive on a > > timely basis. > > > > Scott K > > > > On Monday, August 19, 2013 12:15:45 Rick Spencer wrote: > >> For Ubuntu touch, at least, there is a lot to figure out and do before > >> shipping 13.10. Personally, I think it would be most beneficial to do > >> that planning and have those discussions transparently and in an > >> organized manner. > >> > >> Cheers, Rick > >> > >> On Mon, Aug 19, 2013 at 11:58 AM, Scott Kitterman > > > > wrote: > >> > On Monday, August 19, 2013 10:52:18 Ted Gould wrote: > >> >> On Mon, 2013-08-19 at 10:05 -0400, Michael Hall wrote: > >> >> > UDS August 2013 > >> >> > Starts: Tue, 27 Aug 2013 14:00:00 UTC > >> >> > Ends: Thu, 29 Aug 2013 20:00:00 UTC > >> >> > >> >> Are we putting vUDS the three days before feature freeze? > >> >> > >> >> https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule > >> >> > >> >> Seems like bad time for people working on Ubuntu. > >> > > >> > I think that is generically true for the mid-cycle vUDS. This is no > >> > doubt > >> > worse than it might be, but it's a bit early to start planning the next > >> > Ubuntu release cycle. Whoever it's for, I don't think it's for people > >> > working on Ubuntu. > >> > > >> > Scott K > >> > > >> > -- > >> > ubuntu-devel mailing list > >> > ubuntu-devel@lists.ubuntu.com > >> > Modify settings or unsubscribe at: > >> > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel > > > > -- > > ubuntu-devel mailing list > > ubuntu-devel@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: vUDS Scheduling
I agree that this is useful for Canonical upstreams trying to map out their next three - six months' work. From a distro development perspective, not so much. I would hope there's a look beyond the next three months. By starting to plan for 14.04 now, they'll be in a much better position to understand what needs doing and when to land things in the archive on a timely basis. Scott K On Monday, August 19, 2013 12:15:45 Rick Spencer wrote: > For Ubuntu touch, at least, there is a lot to figure out and do before > shipping 13.10. Personally, I think it would be most beneficial to do > that planning and have those discussions transparently and in an > organized manner. > > Cheers, Rick > > On Mon, Aug 19, 2013 at 11:58 AM, Scott Kitterman wrote: > > On Monday, August 19, 2013 10:52:18 Ted Gould wrote: > >> On Mon, 2013-08-19 at 10:05 -0400, Michael Hall wrote: > >> > UDS August 2013 > >> > Starts: Tue, 27 Aug 2013 14:00:00 UTC > >> > Ends: Thu, 29 Aug 2013 20:00:00 UTC > >> > >> Are we putting vUDS the three days before feature freeze? > >> > >> https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule > >> > >> Seems like bad time for people working on Ubuntu. > > > > I think that is generically true for the mid-cycle vUDS. This is no doubt > > worse than it might be, but it's a bit early to start planning the next > > Ubuntu release cycle. Whoever it's for, I don't think it's for people > > working on Ubuntu. > > > > Scott K > > > > -- > > ubuntu-devel mailing list > > ubuntu-devel@lists.ubuntu.com > > Modify settings or unsubscribe at: > > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: vUDS Scheduling
On Monday, August 19, 2013 10:52:18 Ted Gould wrote: > On Mon, 2013-08-19 at 10:05 -0400, Michael Hall wrote: > > UDS August 2013 > > Starts: Tue, 27 Aug 2013 14:00:00 UTC > > Ends: Thu, 29 Aug 2013 20:00:00 UTC > > Are we putting vUDS the three days before feature freeze? > > https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule > > Seems like bad time for people working on Ubuntu. I think that is generically true for the mid-cycle vUDS. This is no doubt worse than it might be, but it's a bit early to start planning the next Ubuntu release cycle. Whoever it's for, I don't think it's for people working on Ubuntu. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: XMir news!
On Friday, August 09, 2013 11:57:58 Kevin Gunn wrote: > In recent days Mir and the relevant X.org patches required to support XMir > have landed in main. The final component needed for turning on XMir is the > unity-system-compositor (...or as we prefer to shorten it, u-s-c). We had > recently been performing a variety of integration tests across a spectrum > of hardware and we now feel confident about pushing u-s-c into universe. u-s-c is already often used for Ubuntu Software Center. Any chance you could find another acronym? Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: speeding up package builds
Steve Langasek wrote: >Hi Scott, > >On Thu, Aug 08, 2013 at 04:22:56PM -0400, Scott Kitterman wrote: >> >Hope this helps a bit in making package builds and migrations a bit >> >faster. > >> The last python-qt4 sync I did from Debian took over a day to migrate >due >> to the amount of time the autopkgtests took. It was at least twice >as >> long as the build time on the slowest arch. Is there work planned to >> speed up these tests? > >Jenkins claims that the python-qt4 autopkgtests themselves take < 3min >to >run: > >https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-python-qt4/19/ > >In comparison, python-qt4 4.10.2-2 took > 3h to build on armhf: > >https://launchpad.net/ubuntu/+source/python-qt4/4.10.2-2/+build/4849556 > >Was python-qt4 held up by autopkgtests from its reverse-dependencies? >Or >maybe python-qt4 was caught up the day that we were finding bugs in the >autopkgtest infrastructure itself (reporting results incorrectly to >proposed-migration)? It was tests from rdepends. IIRC there were four or five. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: speeding up package builds
Matthias Klose wrote: >I had to look at many "core" packages, which are needed for a normal >and a >buildd chroot, and and which are needed to build these packages for the >chroots. >And I was not that pleased to see how the packaging wasted CPU time. I >think >even for our migration from proposed to release it would make sense to >speed up >some builds, so that the slower architectures can catch up earlier. So >here is >what I found ... > >Parallel builds > >Unfortunately not enabled very often. The buildds set >DEB_BUILD_OPTIONS="parallel=", and if the build supports parallel >builds, it >can speed up the build substantially. Common mistakes: > > - debhelper based packages don't call with --parallel > - debhelper based packages overwrite dh_auto_build and don't call > --parallel > - cdbs based packages don't set DEB_BUILD_PARALLEL = yes > - Packages deep down in the stack live still in the stone age (bind9, > db, ghostscript, ...) > > >Documentation builds > >Many packages always build the documentation, even when only building >the >architecture dependent packages (that is, on our slowest buildds). The >easy >solution where the upstream docs are not built by default is to build >these in >an extra target. > >However I didn't find any good recipes how to write a modern debhelper >or >semi-modern cdbs rules file how to correctly configure a package to >disable the >docs build for an arch-only build, and enable the docs for an >arch-indep build. >Pointers welcome. > > >Flavour builds > >There is no benefit for our proposed to release migration, however when >testing >a package, or building a package for the first time, I'm maybe only >interested >in one flavour. Disabling one flavour reduces the build time. Mostly >seen for >packages using different builds for building udeb's. It would be nice >to >disable these if DEB_STAGE= is set. > > >Shell-script like rules files > >Using a short "modern" debhelper rules file doesn't mean that you >cannot define >your own targets to break a configure or build target in many sub >targets. It >doesn't speed up the build itself, however if you debug an issue, and >the build >starts again ... something could be done better. Please try to at >least >separate the configure and build steps. Look at boost1.xy to see what >I don't like. > > >As an example, gtk+3.0 did become eight times faster by enabling >parallel builds >(parallel=8), disabling the doc build, and the udeb flavour. Just >picking this >up, because I had to build it several times. > >Hope this helps a bit in making package builds and migrations a bit >faster. The last python-qt4 sync I did from Debian took over a day to migrate due to the amount of time the autopkgtests took. It was at least twice as long as the build time on the slowest arch. Is there work planned to speed up these tests? Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Kubuntu PowerPC builds
Harald Sitter wrote: >On Thu, Aug 1, 2013 at 2:29 PM, Ho Wan Chan >wrote: >> 2013/8/1 Harald Sitter : >> If you don't care, why should we have it then? > >If we don't spend time on it and it is tested, why should we not have >it? > Don't forget, we aren't exactly Lubuntu, who wants to support every single old computer. Alternate images are what Lubuntu still wants while we have already >dropped it. Why should we drop alternate images if we can properly test it, as >in coherence to our attitude? >>> >>> We didn't test them, that's why alternate was dropped. >> Think about this. We only have 1 tester for PowerPC. How many testers >> do we have for i386 and amd64? > >1.5. And that 1.5 testers were kubuntu developers. Compared to ppc >which had 1 who was not a kubuntu developer. > >> Alternate images can have a lot of >> testers. PowerPC will have problems. > >Since no one wanted to test alternate images despite them being easy >to test but one person tests ppc despite being hard to test, doesn't >that say something about ppc? > >>> So, what are the pros and cons of removing PowerPC image builds? Pros: Save testing time on PowerPC builds (and no need to wait for it at >all before we can release betas or final releases) >>> >>> AFAIK we'd still have to wait for the other flavors and I don't >think >>> we ever delayed a release for considerable amount of time because an >>> architecture that is not x86 based wasn't tested. >> Well, the only flavour who still supports PowerPC except us is >> Lubuntu, and that's because they really want to support PowerPC, and >> they actually spend time contacting release teams and testing even >the >> dailies. Not in our case. > >What's the pro then? > Don't have to rely on other testers >>> >>> If we are spending time testing while relying on other testers to >test >>> then something went terribly wrong... >>> >> I am sure once we have to contact them since we aren't testing. > >'ping, testing plz' is a substantial time investment. +1 Scott K -- kubuntu-devel mailing list kubuntu-de...@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
Re: Future of Appmenu Outside Unity
On Tuesday, July 23, 2013 11:23:20 PM Ted Gould wrote: > On Tue, 2013-07-23 at 22:23 -0400, Scott Kitterman wrote: > > On Tuesday, July 23, 2013 09:00:33 PM Ted Gould wrote: > > > On Tue, 2013-07-23 at 21:01 -0400, Scott Kitterman wrote: > > > > Since shortly after Mark announced the global menu [1] Kubuntu has > > > > shipped > > > > plasma-widget-menubar to provide this functionality [2] and not only > > > > for > > > > Qt/KDE, but for Gtk apps as well [3]. This has served us well on > > > > netbooks > > > > for three years and I use it myself on a daily basis on a conventional > > > > laptop. > > > > > > > > As of today [4], that's no longer possible. Appmenu-gtk has been > > > > replaced > > > > by unity-gtk-module, which (apparently intentionally) doesn't work > > > > outside Unity [5]. > > > > > > > > Is this correct? That's my impression, but I'm not aware of any > > > > discussion > > > > this, so I may have missed something. > > > > > > Oh, cool. I honestly didn't realize that it was still in use, very cool > > > that it has been useful! > > > > > > In general, the big migration here is away from DBusMenu (which was > > > Ubuntu-only) to GMenu which is in GLib. That's basically the difference > > > between appmenu-gtk and unity-gtk-module. There's no technical reason > > > that it would only work on Unity, even if it's in the name. > > > > Actually, DBusMenu is an upstream KDE feature. You may recall it was > > originally a joint Ubuntu/KDE development. > > Hmm, I don't recall. But history is best argued over beer rather than > e-mail :-) > > > We're at KDE SC 4.11 RC1 right > > now, so it's too late to do anything upstream KDE in 4.11 and the Plasma > > Workspace is feature frozen after 4.11 so that upstream can focus on > > Plasma 2 (that will use Qt5 and KDE Frameworks). So we're several > > release cycles away from being able to do anything upstream. > > That's unfortunate. I don't know if I can get someone assigned to it, > but if so, would you guys be willing to distro patch it? I'm not sure > if QMenuModel works on Qt 4, I think so, but hopefully Lars can verify > that when it gets to his timezone. I think we don't have much of a choice. We'd need to coordinate this with upstream so it gets landed for Plasma 2 and then backport the appropriate changes. > > > Which means, in a nutshell, that plasma-widget-menubar would need some > > > porting. Canonical has been working on QMenuModel[1] which provides > > > simple Qt bindings for GMenu exported menus, and should work well for > > > this purpose. I know that Lars (cc'd) has some changes that he's > > > working on there, so it is expected to get better. We are using > > > QMenuModel for all of the indicators in the Unity 8 interface, so you > > > can expect it to be well supported. > > > > How does this impact support in applications? For Qt/KDE apps (due to the > > integration in Qt4) it just works. There's no need to patch individual > > applications. Is this true for QMenuMode? Is it for Qt4 and Qt5? What's > > the upstream plan for it? > > QMenuModel is just a helper library, similar to libdbusmenu. It's not > doing the integration aspects there. We haven't discussed (AFAIK) > porting libdbusmenu-qt users to QMenuModel with any seriousness. I > think that we should, but I'll need to gather more data on the impact, > etc. I imagine that most of the people I'd ping on it are maxed out for > 13.10 already though. I appreciate you looking into it. > > > In indicator-appmenu (the module in Unity that supports the global menu > > > bar) we are currently supporting both DBusmenu applications and GMenu > > > based ones. This is largely because everything isn't ported yet. It > > > has been an unofficial goal to remove DBusmenu for the LTS. I see no > > > issue in keeping appmenu-gtk as a package, but I would consider it > > > deprecated. > > > > AIUI, currently unity-gtk-module conflicts appmenu-gtk, so they can't both > > be installed together. That would have to be fixed since many users have > > both Kubuntu and Ubuntu installed and I think we want to support that. > > > > Also, the gtk/gtk3 patches that supported appmenu-gtk have been dropped, > > so > > even if we brought the package ba
Re: Source packages appropriate by default?
On Wednesday, July 24, 2013 03:46:10 AM Robie Basak wrote: > On Tue, Jul 23, 2013 at 09:31:15PM -0400, Scott Kitterman wrote: > > Before we run off and expend a lot more effort on this, I'd like to > > see something other than handwaving that this is really is a > > significant issue. > > [size comparisions snipped] > > My concern is latency, not size. How many round trips will we save this > way? For cloud images using Amazon S3 mirrors, for example, each request > is quite a bit slower AIUI, and apt-get doesn't currently support > concurrent requests to a single server. > > This is a pain for instances that start up with cloud-init and > immediately have to update sources and install things before they can > become functional. It'd be nice to see the delay from "juju deploy" to > having a live service running get shorter. Same for "juju add-unit". > Admittedly an alternative means to achieve this could be to have > cloud-init remove the deb-src lines first, but it seems a shame to leave > others behind if this really does improve things. > > I agree that I should come up with actual figures before pushing ahead > for this reason. Has any work been done on concurrent requests? That would likely be pretty broadly useful, not just for cloud images. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
On Tuesday, July 23, 2013 09:19:36 PM Scott Ritchie wrote: > On 07/23/2013 12:02 AM, Scott Kitterman wrote: > > On Tuesday, July 23, 2013 06:59:43 AM Robie Basak wrote: > >> On Tue, Jul 23, 2013 at 01:51:46AM -0400, Scott Kitterman wrote: > >>> I think most developers would believe the current situation is > >>> appropriate. > >> > >> I disagree. > >> > >>> By default users have the same access to source and binary packages and > >>> for a free software distribution, that is the ethically correct > >>> approach. > >> > >> Indeed, but you never replied to my original response to your concern. > >> By "same access", do you specifically require the mechanism to be to > >> keep users' local apt caches maintained with source entries? If so, why > >> is such a mechanism necessary to fit the spirit of Free Software? If the > >> user still has easy access to the source, why is this not sufficient? > >> > >> I'm happy to discuss what "easy access" might actually mean, but I see > >> no reason that it should require the waste of users' bandwidth and time. > > > > Sorry. I didn't mean to ignore you. > > > > What's easy? For example, I think "install more packages to get the tools > > to get the source" (use pull-lp-source in ubuntu-dev-tools) doesn't > > qualify. There are tons of documentation all over the web and other > > places as well that assume apt-get source works. > > I agree, it would be nice to keep existing things working. > > > So those are a couple of examples of what I think is definitely not what > > we > > want. I'm open to discussion about alternate ways to preserve easy access > > to the source. > > What if we disabled default source fetching but changed apt-get source > to offer to turn them back on when it was run? One other aspect of this that has occurred to me is that adding new sources (whehter they are present, but disabled or added new) takes administrator rights. Currently, any user of the system can get source using standard distro tools (apt-get). If you have to add a repository, you either have to be an admin or get one. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
On Wednesday, July 24, 2013 11:00:40 AM Daniel J Blueman wrote: > Perhaps we have two issues here: > The 20% additional download due to sources [1] would help both issues, > but perhaps of bigger impact, trusting the country-level mirror for > the security updates? ... You aren't. Security updates are pushed first to security.ubuntu.com and then copied to archive.ubuntu.com and mirrored from there. The security pocket isn't mirrored so you always hit it directly and if a country mirror lags, you get the package from security.ubuntu.com. Also, the signing key is the same Ubuntu archive signing key whether you're getting a package form archive.ubuntu.com or a country mirror, so you aren't trusting the country mirror cryptographically either. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Future of Appmenu Outside Unity
On Tuesday, July 23, 2013 09:00:33 PM Ted Gould wrote: > On Tue, 2013-07-23 at 21:01 -0400, Scott Kitterman wrote: > > Since shortly after Mark announced the global menu [1] Kubuntu has shipped > > plasma-widget-menubar to provide this functionality [2] and not only for > > Qt/KDE, but for Gtk apps as well [3]. This has served us well on netbooks > > for three years and I use it myself on a daily basis on a conventional > > laptop. > > > > As of today [4], that's no longer possible. Appmenu-gtk has been replaced > > by unity-gtk-module, which (apparently intentionally) doesn't work > > outside Unity [5]. > > > > Is this correct? That's my impression, but I'm not aware of any > > discussion > > this, so I may have missed something. > > Oh, cool. I honestly didn't realize that it was still in use, very cool > that it has been useful! > > In general, the big migration here is away from DBusMenu (which was > Ubuntu-only) to GMenu which is in GLib. That's basically the difference > between appmenu-gtk and unity-gtk-module. There's no technical reason > that it would only work on Unity, even if it's in the name. Actually, DBusMenu is an upstream KDE feature. You may recall it was originally a joint Ubuntu/KDE development. We're at KDE SC 4.11 RC1 right now, so it's too late to do anything upstream KDE in 4.11 and the Plasma Workspace is feature frozen after 4.11 so that upstream can focus on Plasma 2 (that will use Qt5 and KDE Frameworks). So we're several release cycles away from being able to do anything upstream. > Which means, in a nutshell, that plasma-widget-menubar would need some > porting. Canonical has been working on QMenuModel[1] which provides > simple Qt bindings for GMenu exported menus, and should work well for > this purpose. I know that Lars (cc'd) has some changes that he's > working on there, so it is expected to get better. We are using > QMenuModel for all of the indicators in the Unity 8 interface, so you > can expect it to be well supported. How does this impact support in applications? For Qt/KDE apps (due to the integration in Qt4) it just works. There's no need to patch individual applications. Is this true for QMenuMode? Is it for Qt4 and Qt5? What's the upstream plan for it? > In indicator-appmenu (the module in Unity that supports the global menu > bar) we are currently supporting both DBusmenu applications and GMenu > based ones. This is largely because everything isn't ported yet. It > has been an unofficial goal to remove DBusmenu for the LTS. I see no > issue in keeping appmenu-gtk as a package, but I would consider it > deprecated. AIUI, currently unity-gtk-module conflicts appmenu-gtk, so they can't both be installed together. That would have to be fixed since many users have both Kubuntu and Ubuntu installed and I think we want to support that. Also, the gtk/gtk3 patches that supported appmenu-gtk have been dropped, so even if we brought the package back, it wouldn't build. Can those be added back? Also keeping it now, just to drop it for the LTS doesn't really help much since the Plasma Desktop will still be using DBusMenu and we'd just have to drop it then. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
On Tuesday, July 23, 2013 08:21:40 AM Jordon Bedwell wrote: > On Tue, Jul 23, 2013 at 6:32 AM, Scott Kitterman wrote: > > Assuming add-apt-repository was installed by default, it's close. I think > > something like this might be reasonable (imagine some policykit or > > whatever it is called now magic here): > > > > $ sudo apt-get source hello > > Reading package lists... Done > > Building dependency tree > > Reading state information... Done > > E: You must put some 'source' URIs in your sources.list > > Would you like 'source' URIs to be added? (y/N) > > Y > > deb-src lines have been added to your sources.list. > > ... > > Get:9 http://archive.ubuntu.com saucy/main Sources [1,001 kB] > > Get:10 http://archive.ubuntu.com saucy/restricted Sources [6,578 B] > > Get:11 http://archive.ubuntu.com saucy/universe Sources [6,071 kB] > > > > In other words, it's, I think, possible to make it roughly as easy as it > > is > > now to get source without having the sources.list "cluttered". For users > > of our releases, I doubt it saves much, but that would be a way to do it > > that both avoids whatever amount of bandwidth usage is involved until the > > user opts in to it, but preserves ready access to the source that I think > > is important. > Depending on how clever and one-off you want to be you could also just > give them the http url to the source as well. It shouldn't be that > hard to guess since apt already has most of the information needed to > just generate the URL from a chosen apt server in the normal deb. > This would allow for one-off downloads (for example somebody needs to > look at the way debian does some of it's compiles so they can > replicate without a package so they grab the source for nginx -- > that's a one-off IMO if they would never use any other source > package.) > > Though I personally like a default command that would be something > like add-apt-default-sources so you can also give them the ability to > run that command and disable sources too (but you can already do that > via the GUI and terminal by editing /etc/apt/sources.list and such.) Before we run off and expend a lot more effort on this, I'd like to see something other than handwaving that this is really is a significant issue. /ubuntu/dists/raring-security/main/source [ ] Release 24-Jul-2013 01:16 106 [ ] Sources.bz2 24-Jul-2013 01:16 32K [ ] Sources.gz 24-Jul-2013 01:16 38K For end users, how much is really downloaded? /ubuntu/dists/raring-updates/main/source [ ] Release 24-Jul-2013 01:16 105 [ ] Sources.bz2 24-Jul-2013 01:16 50K [ ] Sources.gz 24-Jul-2013 01:16 62K /ubuntu/dists/raring-updates/universe/source [ ] Release 24-Jul-2013 01:16 109 [ ] Sources.bz2 24-Jul-2013 01:16 64K [ ] Sources.gz 24-Jul-2013 01:16 77K It doesn't seem like a lot. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Future of Appmenu Outside Unity
Since shortly after Mark announced the global menu [1] Kubuntu has shipped plasma-widget-menubar to provide this functionality [2] and not only for Qt/KDE, but for Gtk apps as well [3]. This has served us well on netbooks for three years and I use it myself on a daily basis on a conventional laptop. As of today [4], that's no longer possible. Appmenu-gtk has been replaced by unity-gtk-module, which (apparently intentionally) doesn't work outside Unity [5]. Is this correct? That's my impression, but I'm not aware of any discussion this, so I may have missed something. Scott K [1] http://www.markshuttleworth.com/archives/359 [2] https://skitterman.wordpress.com/2010/07/08/global-menu-in-action-in-kubuntu-maverick/ [3] https://skitterman.wordpress.com/2010/07/09/menubar-for-gtk-and-qtkde-apps-on-kubuntu/ [4] https://bugs.launchpad.net/ubuntu/+source/appmenu-gtk/+bug/1196667 [5] https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/126 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
On Tuesday, July 23, 2013 08:12:16 AM Robie Basak wrote: > On Tue, Jul 23, 2013 at 03:02:02AM -0400, Scott Kitterman wrote: > > So those are a couple of examples of what I think is definitely not what > > we > > want. I'm open to discussion about alternate ways to preserve easy access > > to the source. > > How about: > > $ sudo apt-get source hello > Reading package lists... Done > Building dependency tree > Reading state information... Done > E: You must put some 'source' URIs in your sources.list > E: Type "add-apt-repository sources" to do this automatically for you. > $ sudo add-apt-repository sources > deb-src lines have been added to your sources.list. > Now type "apt-get update", and then "apt-get source ..." will work. > $ sudo apt-get update > (...) > $ sudo apt-get source hello > (works) > > To do this, we'd need to patch apt to add the second error line, and > implement "sources" to add-apt-repository. Assuming add-apt-repository was installed by default, it's close. I think something like this might be reasonable (imagine some policykit or whatever it is called now magic here): $ sudo apt-get source hello Reading package lists... Done Building dependency tree Reading state information... Done E: You must put some 'source' URIs in your sources.list Would you like 'source' URIs to be added? (y/N) Y deb-src lines have been added to your sources.list. ... Get:9 http://archive.ubuntu.com saucy/main Sources [1,001 kB] Get:10 http://archive.ubuntu.com saucy/restricted Sources [6,578 B] Get:11 http://archive.ubuntu.com saucy/universe Sources [6,071 kB] ... apt-get source lightdm-kde Reading package lists... Done Building dependency tree Reading state information... Done NOTICE: 'lightdm-kde' packaging is maintained in the 'Git' version control system at: git://git.debian.org/pkg-kde/kde-extras/lightdm-kde.git Need to get 1,386 kB of source archives. Get:1 http://archive.ubuntu.com/ubuntu/ saucy/universe lightdm-kde 0.3.2.1-1ubuntu2 (dsc) [1,543 B] Get:2 http://archive.ubuntu.com/ubuntu/ saucy/universe lightdm-kde 0.3.2.1-1ubuntu2 (tar) [1,379 kB] Get:3 http://archive.ubuntu.com/ubuntu/ saucy/universe lightdm-kde 0.3.2.1-1ubuntu2 (diff) [5,088 B] Fetched 1,386 kB in 1s (807 kB/s) apt-get source lightdm-kde Reading package lists... Done Building dependency tree Reading state information... Done NOTICE: 'lightdm-kde' packaging is maintained in the 'Git' version control system at: git://git.debian.org/pkg-kde/kde-extras/lightdm-kde.git Need to get 1,386 kB of source archives. Get:1 http://archive.ubuntu.com/ubuntu/ saucy/universe lightdm-kde 0.3.2.1-1ubuntu2 (dsc) [1,543 B] Get:2 http://archive.ubuntu.com/ubuntu/ saucy/universe lightdm-kde 0.3.2.1-1ubuntu2 (tar) [1,379 kB] Get:3 http://archive.ubuntu.com/ubuntu/ saucy/universe lightdm-kde 0.3.2.1-1ubuntu2 (diff) [5,088 B] Fetched 1,386 kB in 1s (807 kB/s) (and so on) In other words, it's, I think, possible to make it roughly as easy as it is now to get source without having the sources.list "cluttered". For users of our releases, I doubt it saves much, but that would be a way to do it that both avoids whatever amount of bandwidth usage is involved until the user opts in to it, but preserves ready access to the source that I think is important. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
On Tuesday, July 23, 2013 06:59:43 AM Robie Basak wrote: > On Tue, Jul 23, 2013 at 01:51:46AM -0400, Scott Kitterman wrote: > > I think most developers would believe the current situation is > > appropriate. > > I disagree. > > > By default users have the same access to source and binary packages and > > for a free software distribution, that is the ethically correct approach. > Indeed, but you never replied to my original response to your concern. > By "same access", do you specifically require the mechanism to be to > keep users' local apt caches maintained with source entries? If so, why > is such a mechanism necessary to fit the spirit of Free Software? If the > user still has easy access to the source, why is this not sufficient? > > I'm happy to discuss what "easy access" might actually mean, but I see > no reason that it should require the waste of users' bandwidth and time. Sorry. I didn't mean to ignore you. What's easy? For example, I think "install more packages to get the tools to get the source" (use pull-lp-source in ubuntu-dev-tools) doesn't qualify. There are tons of documentation all over the web and other places as well that assume apt-get source works. I think access using installed tools that are normally used for the job (wget is installed (I think) by default, but I don't think having to go to a web page to find a URL and then wget'ing the components of the source package is easy either. So those are a couple of examples of what I think is definitely not what we want. I'm open to discussion about alternate ways to preserve easy access to the source. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Source packages appropriate by default?
On Tuesday, July 23, 2013 11:02:00 AM Daniel J Blueman wrote: > By large, developers are uninterested in this, but it is important for > users and where we use Ubuntu. > > Anyone care to comment on how we can progress this? I think most developers would believe the current situation is appropriate. By default users have the same access to source and binary packages and for a free software distribution, that is the ethically correct approach. Scott K > On 15 July 2013 13:32, Daniel J Blueman wrote: > > From earlier feedback, there were no overriding reasons why package > > sources should be enabled by default. > > > > We not only save congestion on security.ubuntu.com, but quite a lot of > > country-level mirrors point to Canonical's servers, which are > > relatively distant and slow (~80KB/s from here), so this is a win. > > > > So, what's the path to change this? > > > > On 21 May 2013 22:04, J Fernyhough wrote: > >> On 21 May 2013 13:55, Robie Basak wrote: > >>> What if we provided a reasonable message if no deb-src lines are > >>> defined, with a single simple command to add them and run "apt-get > >>> update" for you? > >> > >> I don't think it would even need that - software-properties (Software > >> & Updates) already has the necessary checkbox. All that is needed to > >> enable sources is to tick that box. > >> > >>> From a technical point of view, does mirroring the deb lines into > >>> deb-src lines work in all cases? Would doing so break anything? > >> > >> This is effectively what Software Sources does under-the-hood. > >> > >> I have to agree, if the amount being downloaded is not trivial (which > >> I thought it was) then there's no need to have them enabled by default > >> when it's very easy to turn them on. One of the first things I do on > >> any new install is disable those that aren't needed. > >> > >> Jonathon > >> > >> (to the list this time) > >> > >> -- > >> Ubuntu-devel-discuss mailing list > >> ubuntu-devel-disc...@lists.ubuntu.com > >> Modify settings or unsubscribe at: > >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss> > > -- > > Daniel J Blueman -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Xorg was removed.. without an alternative
On Thursday, July 11, 2013 10:31:03 AM Aigars Mahinovs wrote: > On 11 July 2013 08:43, Scott Kitterman wrote: > > > It seems so strange to spend six months saying "don't touch that" just > > > to turn around and then spend nine months begging people to touch > > > that... > > > > I know it can be confusing, but the $devel-proposed (that should be future > > proof) serves a completely different purpose than -proposed post-release. > > > > Once > > > > Saucy is released, saucy-proposed will serve the same purpose -proposed > > has > > always served. "Not for humans" only applies to the development phase. > > It looks like the two different uses of -proposed should be separated, no? > So a $devel release would have an always empty $devel-proposed and all that > is currently pushed there would go to $devel-autobuilder-only-proposed or > something and a released verison would continue as-is. In theory, sure. In practice, it would take a lot of work to do that for very minimal gain. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Xorg was removed.. without an alternative
On Wednesday, July 10, 2013 04:36:35 PM Seth Arnold wrote: > On Wed, Jul 10, 2013 at 07:17:24PM -0400, Scott Kitterman wrote: > > > > The issue is that it's only in the *devel* pre-release when it's not > > > > safe > > > > for humans to enable it. The GUI for enabling it needs to exist > > > > because > > > > there are scenarios where humans should be enabling it: people using > > > > older > > > > stable releases who are crippled by some bug or other, and need to > > > > test > > > > SRUs sooner rather than later. > > > > > > With this enabled, a "sudo apt-get dist-upgrade" will not pull from > > > -proposed, but > > > sudo apt-get install xorg/saucy-proposed , would allow me to > > > forcefully install xorg from saucy-proposed, as an opt-in - per > > > package choice. > > > > > > [0] https://wiki.ubuntu.com/Testing/EnableProposed > > > > What part of "not for humans" is confusing? > > What will we do for SRU verification? > > Will we introduce a new -proposed-for-humans pocket once Saucy > is released? Or will we need to go edit everything that once said > "saucy-proposed isn't for humans" to read "t-proposed isn't for humans"? > > It seems so strange to spend six months saying "don't touch that" just > to turn around and then spend nine months begging people to touch that... I know it can be confusing, but the $devel-proposed (that should be future proof) serves a completely different purpose than -proposed post-release. Once Saucy is released, saucy-proposed will serve the same purpose -proposed has always served. "Not for humans" only applies to the development phase. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Xorg was removed.. without an alternative
On Wednesday, July 10, 2013 06:12:51 PM Robert Park wrote: > On Wed, Jul 10, 2013 at 4:17 PM, Scott Kitterman wrote: > > What part of "not for humans" is confusing? > > Because it's not for humans, except when it is for humans, sometimes. Not $devel-proposed. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Xorg was removed.. without an alternative
On Wednesday, July 10, 2013 11:36:58 PM Dave Walker wrote: > On 10 July 2013 20:41, Robert Park wrote: > > On Sun, Jul 7, 2013 at 12:31 PM, Jo-Erlend Schinstad > > > > wrote: > >> Perhaps it would be wise to disable the option in the GUI with a proper > >> explanation of this? It's obvious that proposed _might_ break things, but > >> it's certainly not obvious that it's not intended for humans when there's > >> a > >> GUI to enable it. > > > > The issue is that it's only in the *devel* pre-release when it's not safe > > for humans to enable it. The GUI for enabling it needs to exist because > > there are scenarios where humans should be enabling it: people using older > > stable releases who are crippled by some bug or other, and need to test > > SRUs sooner rather than later. > > Well, this is a problem we solved a while ago - making use of > Pin-Priority[0]. > > With this enabled, a "sudo apt-get dist-upgrade" will not pull from > -proposed, but > sudo apt-get install xorg/saucy-proposed , would allow me to > forcefully install xorg from saucy-proposed, as an opt-in - per > package choice. > > [0] https://wiki.ubuntu.com/Testing/EnableProposed What part of "not for humans" is confusing? Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu graphic stack roadmap update
On Friday, June 28, 2013 04:28:54 PM Oliver Grawert wrote: > hi, > > On Fr, 2013-06-28 at 10:04 -0400, Scott Kitterman wrote: > > I don't think we'll know for awhile if XMir is really as generally > > compatible as is currently being claimed. I believe it's being design > > and planned to be compatible, but I don't believe there is enough data in > > evidence at this point to know how successful it's developers have been. > > So even if KDE on XMir is no better or worse than Unity on XMir (which is > > also an assumption), I think it makes complete sense for Kubuntu to wait > > and see. > > yes, understood, i personally would jump on it asap to catch the bugs > and have Mir upstream fixing them for me. > i understand if you are cautious though... > > but i also see that riddells last post on behalf of kubuntu doesnt > really leave any room for "wait and see" anymore ... For 13.10, we've decided what we're doing. He's not saying that we've decided forever and please don't claim he is. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu graphic stack roadmap update
On Friday, June 28, 2013 11:29:08 AM Oliver Grawert wrote: > hi, > > On Do, 2013-06-27 at 14:26 -0400, Scott Kitterman wrote: > > As you know, display issues are very hardware specific. With the current > > amount of testing of Kubuntu on XMir (AFAIK one developer with one > > machine) I don't think we know anything about how well it will work for a > > general purpose flavor like Kubuntu. > so i read that sentence three times now (and i wonder if you did before > sending the mail) and i can by no means find any logic in it ... you are > claiming that the majority of bugs with Mir will be HW specific which > means that all flavours including Ubuntu will see them on a particular > HW ... I did leave a word out. Display issues are ... often ... very hardware specific. The point of that is that a few people running tests isn't sufficient to understand how something like Mir will behave on the huge variety of hardware that it will eventually be exposed to. Also, it is sometimes a specific combination of hardware and software. I recall one case which it a kwin bug that was only exposed by a specific mesa version on Intel hardware. So no, not everyone will see the same issues. > how does that affect you as a general purose desktop developer (do we > have any official flavours that aren't shipping general purpose > desktops ? (i know edubuntu and -studio are shipping special purpose app > selections, but the desktops they ship aren't single purpose to my > knowledge)) except that you can just throw these bugs over the fence to > the HW/Mir/kernel teams to get them solved (or even rely on the fact > that it will simply get fixed because other flavours see it too on that > HW without you having to take any action at all) There are subsets of the Ubuntu project that target very specific hardware. For example, if a group is working on Nexus 7, then there is only ~one hardware configuration to worry about. I agree that Unity itself isn't special purpose. > as someone working on the top level, why do you care about HW bugs at > all, just forward them to the experts to fix them (if collecting debug > data for them isn't asked to much), if composite is broken on specific > HW it will be for all of us ... That's not always the case. Since there are multiple implementations involved, sometimes it's specific to a combination of hardware and specific software, but that's not really the point of this paragraph. What I was trying to communicate (and clearly failed) is that I think there is not nearly enough information available to say that even though XMir appears to work well on one developer's system (and it did in the appear that way in the video that was posted on You Tube (and the follow-up that was done last night), that's one system. That's not nearly enough to know how it will perform more generally. Let me pick another example from the project's past to illustrate why I think it's prudent for Kubuntu not to move to XMir now: For Hardy, 8.04, Ubuntu switched to pulseaudio by default. This was a hugely controversial decision and it caused regressions in audio for a lot of users. The regressions were primarily due to driver bugs that were only exposed by pulseaudio, but users don't really care which piece of software is at fault when they system works less well after upgrade. They just want it to work. Kubuntu did not switch to pulseaudio by default until Maverick, 11.10 and so Precise, 12.04 was the first LTS where Kubuntu shipped with pulseaudio. By the time we switched, most drivers had been updated to resolve the issues exposed by pulseaudio and, while not trouble free, the switch was far smoother than what Ubuntu experienced. I don't think we'll know for awhile if XMir is really as generally compatible as is currently being claimed. I believe it's being design and planned to be compatible, but I don't believe there is enough data in evidence at this point to know how successful it's developers have been. So even if KDE on XMir is no better or worse than Unity on XMir (which is also an assumption), I think it makes complete sense for Kubuntu to wait and see. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu graphic stack roadmap update
Steve Langasek wrote: >On Thu, Jun 27, 2013 at 12:28:40PM -0400, Scott Kitterman wrote: >> > I think it's a bit premature to ask this question (there is >validity for >> > it, just the timing seems off) as things were only announced today >and the >> > technology is just becoming available for a technical assessment. >Right >> > now, only kubuntu has jumped the gun and made a decision against >Mir, I >> > hope others are taking the necessary time, will be looking at the >resources >> > that are and will be provided and make an informed decision based >on that. > >> I hardly think following the advice of our upstream developers >qualifies >> as "jumping the gun". Nothing is carved in stone for eternity. I >think >> we have taken an informed decision based on the current status. If >things >> change in the future, the decision might be re-evaluated when that >> happens. > > "Kubuntu Won't be Switching to Mir or XMir" > http://blogs.kde.org/2013/06/26/kubuntu-wont-be-switching-mir-or-xmir > >I think that's rather a bit more than following the advice of your >upstream >developers; it looks to me like Jonathan is staking out a position >against >Mir. Frankly, this doesn't look to me like an informed decision at >all, it >looks like a polemic one. XMir is going to be the X stack that >receives the >most attention from Canonical, as well as from other Ubuntu developers >working on Ubuntu-the-flavor. Given that the major concern I've seen >expressed is that the Kubuntu team won't have resources to maintain >their >own display stack, I don't see how anyone could have arrived so quickly >at >the conclusion that using the XMir stack - the one used by Ubuntu - is >risky, and using the native X stack - not used by Ubuntu - is safe. > >Compositing may be fragile, but there should be no difference visible >to >KWin between XMir and native X with respect to compositing. And given >the >tendency for bugs to arise as a result of mismatches between X+mesa, or >X+mesa+kernel, I would be much more worried about native X not >receiving the >attention it needs to be kept in sync with mesa - a problem that won't >arise >with XMir, since Mir+mesa are obviously going to be maintained as a >usable >combination. > >> Personally, I'm not certain how viable Kubuntu on X/Wayland will be >in the >> long run, but that's at least as true about Kubuntu on Mir. We'll >get to the >> long run, in the long run, but for right now Mir/XMir offers us >nothing but >> complication. > >So I'm not convinced that XMir actually represents complication for >Kubuntu, >rather than beneficial alignment. As you know, display issues are very hardware specific. With the current amount of testing of Kubuntu on XMir (AFAIK one developer with one machine) I don't think we know anything about how well it will work for a general purpose flavor like Kubuntu. As I said before, I've no idea what will make sense in the long run. For now, not immediately jumping in the deep end seems entirely logical to me. Personally, I'm skeptical that there is any long term future for non-Unity flavors in Ubuntu. I hope I'm wrong. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu graphic stack roadmap update
On Thursday, June 27, 2013 10:22:26 AM Oliver Ries wrote: > On Thu, Jun 27, 2013 at 10:13 AM, Jeremy Bicha wrote: > > On 27 June 2013 11:51, Oliver Ries wrote: > > > > Replying off-list > > > > >> I think Rebecca Black OS has you beat there. Unless you don't think > > >> Rebecca Black is mainstream enough... > > > > > > I did some research and apparently missed that, no offense intended > > > > Well the distro was tongue-in-cheek. ;) > > > > >> There's a chance that Fedora 20 would be released with Wayland by > > >> default before 14.04 LTS > > > > > > imho there is a difference between a chance of doing it and putting out > > > a > > > roadmap and committing to do it, but I might be nitpicking ;) > > > > Right, Fedora hasn't really done roadmaps for Fedora 20 yet since > > Fedora 19 hasn't yet been released. > > > > GNOME though has a roadmap: initial support this fall, full support > > next spring. It comes down to how well GNOME 3.10 on Wayland works > > because I don't think Fedora is afraid to beta-test new shiny. Fedora > > does have one shortcut...they don't have to worry about support for > > proprietary graphics drivers since those have never been officially > > supported anyway. > > > > It sounds like KDE will be ready for Wayland at the same time. > > I still think there is a difference between an upstream project being ready > and a Linux distribution being ready/willing to consume that upstream. Fortunately for us, kwin will support both X and Wayland back ends, so we can assess the maturity of both the back ends and the infrastructure status over time. A nice thing about a six month release cycle is you are stuck with something that long if you decide it's time for something else. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu graphic stack roadmap update
On Thursday, June 27, 2013 10:08:23 AM Oliver Ries wrote: > Hi Scott, > > On Thu, Jun 27, 2013 at 9:57 AM, Scott Kitterman wrote: > > On Thursday, June 27, 2013 09:51:33 AM Oliver Ries wrote: > > > > Like Kubuntu we expect to switch to Wayland in the next year or so. > > > > It's nice to see that the various desktop environment can run on XMir > > > > but I'm still not clear on whether there are any benefits to doing so. > > > > > > One obvious benefit that comes to mind is getting the stack for free and > > > not having to worry about maintenance. I do acknowledge that there are > > > other costs associated to that (adopting to Mir), but in our opinion, > > that > > > should be less than maintaining a GFX stack on your own. Canonical will > > > support the Mir stack going forward and we are offering help for > > upstreams > > > > > willing to adopt. > > > > Have any non-Canonical upstreams expressed an interest in this? > > I think it's a bit premature to ask this question (there is validity for > it, just the timing seems off) as things were only announced today and the > technology is just becoming available for a technical assessment. Right > now, only kubuntu has jumped the gun and made a decision against Mir, I > hope others are taking the necessary time, will be looking at the resources > that are and will be provided and make an informed decision based on that. I hardly think following the advice of our upstream developers qualifies as "jumping the gun". Nothing is carved in stone for eternity. I think we have taken an informed decision based on the current status. If things change in the future, the decision might be re-evaluated when that happens. Personally, I'm not certain how viable Kubuntu on X/Wayland will be in the long run, but that's at least as true about Kubuntu on Mir. We'll get to the long run, in the long run, but for right now Mir/XMir offers us nothing but complication. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu graphic stack roadmap update
On Thursday, June 27, 2013 09:51:33 AM Oliver Ries wrote: > > Like Kubuntu we expect to switch to Wayland in the next year or so. > > It's nice to see that the various desktop environment can run on XMir > > but I'm still not clear on whether there are any benefits to doing so. > > One obvious benefit that comes to mind is getting the stack for free and > not having to worry about maintenance. I do acknowledge that there are > other costs associated to that (adopting to Mir), but in our opinion, that > should be less than maintaining a GFX stack on your own. Canonical will > support the Mir stack going forward and we are offering help for upstreams > willing to adopt. Have any non-Canonical upstreams expressed an interest in this? Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Ubuntu graphic stack roadmap update
On Thursday, June 27, 2013 08:41:51 AM Oliver Ries wrote: > Our Display Server Mir has gone from a proof of concept, sufficient to > justify its announcement in March this year, to high quality, high > performance component that we think will deliver the fastest, cleanest > display experience for the Ubuntu platform. We are confident that all > desktop environments and derivatives will work well throughout the > transition, based on our ability to provide a full X compatibility layer. I'm not sure where this confidence comes from. http://blogs.kde.org/2013/06/26/kubuntu-wont-be-switching-mir-or-xmir As this is landed in the archive, please take care not to make it unduly difficult for the rest of us. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: non-Unity flavours and Mir
On Tuesday, June 18, 2013 01:38:09 PM Dmitry Shachnev wrote: > On Tue, 18 Jun 2013 00:28:49 -0400, Scott Kitterman wrote: > > I don't think there's anyone in the Kubuntu team with the skills to pick > > up on maintenance of the non-Mir display server stack [...] > > I think it is much easier to maintain Wayland stack in Ubuntu than > port all DEs we support to Mir. > > As I can see from this thread, the “common” components used by flavors > that will be patched to support Mir are Mesa, Upstart and LightDM. In > Mesa, it will be just an addition of a new backend — that shouldn’t > break anything. Speaking about Upstart, it should be able to start > Wayland, Mir or X11 based on the system configuration — this is > probably going to be implemented anyway to support two versions of > Unity in Saucy. For LightDM, it will be more difficult to support > running under different display servers, but given that KDE and GNOME > have their own DMs, it shouldn’t be a problem. For Kubuntu, the DM we use for several releases is LightDM, so that's not quite accurate. I see that there's now a work item to create a daily build system for Mesa, so I guess we'll start to find out how invasive it is shortly: https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-xorg From today's update to the spec: + [raof] make a bzr project of mesa & xorg/xmir in order to help feed daily packaging (or provide explaination why we cannot...git only ??): TODO Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: non-Unity flavours and Mir
On Tuesday, June 18, 2013 12:45:18 PM Oliver Grawert wrote: > hi, > > On Di, 2013-06-18 at 12:11 +0200, Matthias Klumpp wrote: > > 2013/6/18 Oliver Grawert : > > > hi, > > > > > > On Di, 2013-06-18 at 11:16 +0200, Matthias Klumpp wrote: > > >> Hi! > > >> > > >> 2013/6/18 Steve Langasek : > > >> > On Mon, Jun 17, 2013 at 05:13:33PM -0400, Scott Kitterman wrote: > > >> >> I think Jonathon's post earlier today captures the core issue: > > >> >> > > >> >> On Monday, June 17, 2013 09:05:08 PM Jonathan Riddell wrote: > > >> >> [...] > > >> >> > > >> >> As long as Canonical declines to work with the rest of the free > > >> >> software > > >> >> community, > > >> > > > >> > Well, I think that's an altogether inaccurate and unfair > > >> > characterization. > > >> > Canonical has always been open to working with "the rest of the free > > >> > software community"; what Canonical has not been willing to do is > > >> > blindly > > >> > follow where certain self-appointed "upstreams" would lead, when that > > >> > conflicts with the business's goals. > > >> > > >> Well, working with the upstreams (who usually know their code best), > > >> making compromises, trying to convince upstreams that the way you > > >> think something should be designed is best and finally, if there is a > > >> consensus, implement that code and make it available to everyone is > > >> basically the essence of "working with "the rest of the free software > > >> community"". It has never been easy, and if upstreams reject certain > > >> features, people are free to fork. But the dicussion needs to happen > > >> first and stuff needs to be implemented closely to upstream, so > > >> everyone knows about it and it can be accepted easily. > > >> Especially the communication step was missing in the Wayland story. > > > > > > so the right reaction is to now reject the communication from the > > > upstream/flavour side as a punishment for this ?!? > > > > There is no communication at the moment - mentioning stuff on a > > Mailinglist, which upstream developers most likely won't read (you > > cannot be subscribed to every distribution's ML) does not help. > > Contacting the upstreams directly on their mailinglists (the KWin ML > > or the GNOME Mutter ML) is the step to do. > > well, this thread is called "non-Unity *flavours* and Mir" involving > upstreams would be a secondary step ... > > > My comment was about the communication with Wayland > > . Speaking to > > Wayland developers doesn't make sense anymore, since Ubuntu is doing > > Mir now. > > i personally don't care at all about Wayland or Mir and trust the > specialists in their area to make the right decisions (as i know they > will trust me for my areas) ... > what bothers me in this thread is the attitude more than the topic, > there is an offer for communication and it is declined with a foot > stomping "i don't talk to you because you didn't talk to me first" > attitude of ten year olds ... > > ,, form people i consider friends that i learned to know as pretty > rational people and that i thought i would know better ... > > > Although emotion is involved, there are technical reasons for not > > considering Mir, which Martin has summarized in a Blogpost. > > to quote one of his reasons: > "Ubuntu has always had one of the worst graphics stack in the free > software world. I can see this in the bug tracker. The quality of the > Mesa stack in Ubuntu is really bad." > > right, thats a truely founded and technically proper researched > statement ... sadly his blogpost is full of this ... > > as a spectator who doesn't really know much or care about display > servers (but who cares very much about the online community he lives in) > and who tries to get all arguments from both sides to get an objective > opinion about the topic i must say that Chris Halse Rogers' "Why Mir" > series of blog posts appears a lot more rational with a lot less FUD > spread across it (and surprisingly no foot stomping at all)... The same blog post you're quoting selectively from goes into rather more detail about concerns: http://blog.martin-graesslin.com/blog/2013/05/mir-in-kubuntu/ Keep i
Re: non-Unity flavours and Mir
Oliver Grawert wrote: >hi, >On Di, 2013-06-18 at 06:13 -0400, Scott Kitterman wrote: >> On Tuesday, June 18, 2013 11:40:34 AM Oliver Grawert wrote: >> > as a member of this community that goes into his 9th year with >Ubuntu >> > and who who knows most of the participants in person, i must say >I'm >> > extremely shocked and disappointed by the attitude coming from the >> > community people i used to admire so much and that i usually know >as >> > pretty rational people ... >> >> Generally when I find myself at odds with a number of people who I >generally >> consider pretty rationale people it causes me to go back and >reconsider if >> maybe I've missed something in formulating my perspective on an >issue. > >well someone reached out a hand and said "can you help me understand >what i might have missed in formulating, we can have a call or another >form of forum" ... > >the answer was "no i don't have any interest in talking to you" > >... And yet this thread continues. Perhaps you're being a bit over dramatic yourself. Talking is still going on, so pretty clearly your characterization isn't completely accurate. It would probably be a lot easier to work out issues like this face to face in hallway conversation or over a beer. Unfortunately, such meetings these days are Canonical only. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: non-Unity flavours and Mir
Oliver Grawert wrote: >hi, >On Di, 2013-06-18 at 06:08 -0400, Scott Kitterman wrote: >> On Tuesday, June 18, 2013 09:00:26 AM Aigars Mahinovs wrote: >> > On 18 June 2013 07:33, Scott Kitterman >wrote: >> > > - What's the time line? When , if we follow along with Ubuntu, >would we >> > > >> > > expect to run with XMir instead of X and when would we expect to >integrate >> > > with MIR natively? >> > >> > Based solely on comments from this thread, as far as I understand, >both >> > Ubuntu and KDE will maintain the ability to work with X for the >foreseeable >> > timeframe, so this more of a question on which happens first - >Ubuntu >> > stopping support for X based desktop environments (unlikely to be >very >> > soon, given the popularity of XFCE and friends) or KWin dropping X >support >> > in favour of Wayland-only solution (also unlikely to be quite soon >given >> > how many distros are not shipping Wayland by default yet). >> > >> > There might theoretically be new features that work on Mir (or >Wayland), >> > but not on X, but those are likely to be minor and more related to >boot >> > and/or user switching rather than actual work. >> >> We covered this already. That's true, but it's also rather more >likely that >> at some point the X stack will atrophy to the point that it will be >buggy and >> not so reliable (I know that the several engineers Canonical have had >working >> on X related issues are doing actual stuff, so it's safe to assume >that if they >> are focused elsewhere, it will have an actual effect) and so >eventually, the >> fact that X still exists in Ubuntu is unlikely to be a sufficient >condition. >> >> As I've said before, I have no idea how long eventually is. > >pretty sure as long as there are X apps being shipped in Ubuntu you >will >see full support for XMir (i would assume "eventually" is several years >from now) ... I'm sure it's not less than several. Our concern is about the long run. It'll be interesting to see if XMir will actually be as transparent ad planned. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: non-Unity flavours and Mir
On Tuesday, June 18, 2013 11:40:34 AM Oliver Grawert wrote: > hi, > > On Di, 2013-06-18 at 01:34 +0200, Matthias Klumpp wrote: > > 2013/6/18 Jono Bacon : > > > I fully understand if you don't want to work on this problem, and I also > > > fully understand if the KWin maintainer is uninterested in solving this > > > problem and would prefer to focus on Wayland, but we are doing our best > > > to > > > be as open and collaborative as possible here, given the original points > > > raised in Jonathan's email. > > > > > > I see this as a trade-off. > > > > Fair point. But you can not expect KDE or GNOME to suddenly jump on > > the Mir train. Supporting a new display server is pretty damn hard, it > > took a lot of time to > > clean up all the code to abstract X dependencies and make the switch > > to a non-X displayserver possible. But after that is done, maintaining > > a new display server backend is still not easy. > > it is funny that everyone seems to assume here that anyone expects > upstream to do the work. all that happened in this thread was an offer > for conversation with upstream to define the requirements, nothing > more ... > > weather an Ubuntu community person or team or an external team (imagine > mint would want to ship with a Mir enabled KDE as an interesting > experiment or some such) might ever want to write any code is not > relevant for what was discussed in the thread. all there was, was an > offer/request for communication to have the Mir upstreams get an idea > about the requirements which could then be put on a Wiki page so > potential porters would have something to work along... > > i find it a pretty poor picture that a desktop flavour team is not even > willing to answer/ask questions and invest the 15-30 min such a call > might take ... > > all i see in this thread is canonical giving offers and complete refusal > from the other side with pointers to some totally unfounded claims about > potential bugs unity might have caused in mesa in the past ... > > as a member of this community that goes into his 9th year with Ubuntu > and who who knows most of the participants in person, i must say I'm > extremely shocked and disappointed by the attitude coming from the > community people i used to admire so much and that i usually know as > pretty rational people ... Generally when I find myself at odds with a number of people who I generally consider pretty rationale people it causes me to go back and reconsider if maybe I've missed something in formulating my perspective on an issue. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: non-Unity flavours and Mir
On Tuesday, June 18, 2013 09:00:26 AM Aigars Mahinovs wrote: > On 18 June 2013 07:33, Scott Kitterman wrote: > > - What's the time line? When , if we follow along with Ubuntu, would we > > > > expect to run with XMir instead of X and when would we expect to integrate > > with MIR natively? > > Based solely on comments from this thread, as far as I understand, both > Ubuntu and KDE will maintain the ability to work with X for the foreseeable > timeframe, so this more of a question on which happens first - Ubuntu > stopping support for X based desktop environments (unlikely to be very > soon, given the popularity of XFCE and friends) or KWin dropping X support > in favour of Wayland-only solution (also unlikely to be quite soon given > how many distros are not shipping Wayland by default yet). > > There might theoretically be new features that work on Mir (or Wayland), > but not on X, but those are likely to be minor and more related to boot > and/or user switching rather than actual work. We covered this already. That's true, but it's also rather more likely that at some point the X stack will atrophy to the point that it will be buggy and not so reliable (I know that the several engineers Canonical have had working on X related issues are doing actual stuff, so it's safe to assume that if they are focused elsewhere, it will have an actual effect) and so eventually, the fact that X still exists in Ubuntu is unlikely to be a sufficient condition. As I've said before, I have no idea how long eventually is. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: non-Unity flavours and Mir
On Tuesday, June 18, 2013 04:52:56 PM Robert Ancell wrote: > On Tue, Jun 18, 2013 at 4:33 PM, Scott Kitterman wrote: > > On Monday, June 17, 2013 09:52:49 PM Oliver Ries wrote: > > > On Fri, Jun 14, 2013 at 11:12 AM, Scott Kitterman > > > > wrote: > > Part of the problem is that no one outside Canonical know enough to really > > have an informed opinion. Here are some immediate questions that come to > > > > mind: > > - How invasive would Mir integration be? Is it isolated enough that it > > > > could > > be integrated upstream based on our testing? > > It depends on how KWin plans to support non-X display servers. > > Options that I know of are: > a) KWin implements a Wayland display server component from scratch (a lot > of work) > b) KWin is a plugin to Weston > c) KWin uses an existing Wayland display server library (none exist that I > know of) > > In case a) you would need to implement a Mir backend as well as a Wayland > backend > In case b) you would need a libmirserver backend in Weston > In case c) you would have to modify the library or it would need to allow > backends to be added Wayland support (at the for developers only , don't file bugs that don't come with a patch level of maturity) is supposed to be built into the source for Kwin for KDE SC 4.11 (of which we have in beta one of in saucy right now), so it'll be A or B. Someone who understands such things might have a look at the source and see, I expect from your description it'll be reasonably obvious to someone who knows much about this (i.e. not me). Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: non-Unity flavours and Mir
On Monday, June 17, 2013 09:52:49 PM Oliver Ries wrote: > On Fri, Jun 14, 2013 at 11:12 AM, Scott Kitterman wrote: > > On Friday, June 14, 2013 11:09:25 AM Oliver Ries wrote: > > > > [...] > > > > > in addition to that I just want to highlight, that Jono and I are > > > working > > > on creating a forum for all interested Mir stakeholders (e.g. flavors, > > > > but > > > > > also ISVs and others) to discuss such issues and drive alignment. > > > > > > We hope to have an update on that next week. > > > > OK. > > > > See this is part of the problem. I don't WANT to be a Mir stakeholder. I > > want to focus my Kubuntu work on packaging KDE and making it work well. > > Historically, one of the great things about Kubuntu has been that we could > > rely on the work of the X team to give us a great display system with up > > to > > date hardware support that we didn't have to worry about. > > with that I take that your concerns would be addressed if there was kwin > support in Mir. > > I think Ubuntu as an OS platform for KUbuntu is interested in working with > you on that. The conflict that needs to be solved is between your upstream > (kwin) and the OS platform. From what I understand from this thread is that > the main concern there (leaving any ideological or political motivation > aside) is having to support a single distribution solution, which > admittedly is fair in a world of limited resources. In addition to limited resources for development, it'd be something that upstream is completely unable to test. > My team is committed to not lock out any *buntu flavor but provide you with > all means to still run on Ubuntu as an OS platform once Mir is an integral > part of that (which is why I am referring to you as a stakeholder at least > for the transition period). > > As mentioned, we are planning to soon reach out to stakeholders and > dependent parties to discuss a plan forward on this topic. We sure would > appreciate your input in moving forward in a constructive discussion. OK. Part of the problem is that no one outside Canonical know enough to really have an informed opinion. Here are some immediate questions that come to mind: - How invasive would Mir integration be? Is it isolated enough that it could be integrated upstream based on our testing? - What's the time line? When , if we follow along with Ubuntu, would we expect to run with XMir instead of X and when would we expect to integrate with MIR natively? - When will MIR have a stable API/ABI? Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: non-Unity flavours and Mir
On Tuesday, June 18, 2013 12:06:45 AM Marc Deslauriers wrote: > On 13-06-17 11:01 PM, Scott Kitterman wrote: > >> Well to start with, we can all acknowledge that everybody just wants to > >> build something better. And while we obviously have different ideas > >> about what that means, we can still work together when it makes sense. > >> There is room enough in our ecosystem for more than one display server, > >> just as there is room enough for more than one desktop environment, more > >> than one GUI toolkit, and more than one distro. > > > > Certainly. It's certainly possible that I'm being overly pessimistic, but > > it looks to me like the path that Ubuntu is on now is more like a single > > company dominated special purpose(s) Linux variant like Android than as a > > broadly useful general purpose distribution. As I've said before, I'm > > sure Canonical sees the business benefit in investing their engineering > > resources this way, but we shouldn't pretend the change isn't happening. > > It won't be quick (I've no idea the timeframe), but that's pretty clearly > > the path. > > I disagree. Ubuntu is whatever the community and Canonical decides it > is. Nobody is preventing anyone from maintaining whatever they like in > the archive, including the components that make it a general purpose > distribution, and components required for Kubuntu to be a first class > flavour. > > A "single company dominated special purpose Linux variant" is what > happens when the community gets denied access to modify or maintain > parts of the archive. That is definitely not the case. I don't think there's anyone in the Kubuntu team with the skills to pick up on maintenance of the non-Mir display server stack. If Canonical narrows it's focus and things which the community has depended on Canonical to do fall off the table, the effect will be largely the same. I don't think Canonical intends to block anyone, it's just a natural side effect of deciding to focus on one thing that other things don't get done. The people that were depending on those other things are left holding the bag. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: non-Unity flavours and Mir
On Monday, June 17, 2013 09:32:46 PM Michael Hall wrote: > 06/17/2013 08:37 PM, Scott Kitterman wrote: > > On Monday, June 17, 2013 05:32:56 PM Steve Langasek wrote: > >> On Mon, Jun 17, 2013 at 05:13:33PM -0400, Scott Kitterman wrote: > >>> I think Jonathon's post earlier today captures the core issue: > >>> > >>> On Monday, June 17, 2013 09:05:08 PM Jonathan Riddell wrote: > >>>> On Fri, Jun 14, 2013 at 08:01:16PM +0200, Thomas Voß wrote: > >>>>> Yup :) I think a good way forward is to coordinate a call with > >>>>> Jonathan and Martin from KWin such that we can walk through the code > >>>>> together and identify the central points that would need to be mapped > >>>>> to Mir. We can then start discussing potential solutions how to add > >>>>> KWin support for Mir. > >>>> > >>>> I'm afraid I don't have interest in such a call and neither do the > >>>> KWin maintainers. I don't know anything about the KWin codebase or > >>>> how to begin porting it to another platform. KWin are busy porting it > >>>> to Wayland, the display server with consensus across Linux distros and > >>>> have no interest in supporting a display server with unstable API/ABI > >>>> that is only in one distro (from a company who have a track record of > >>>> not maintaining their features, we're having to drop indicator menu > >>>> support in Kubuntu because it's changed API). Porting KWin to Mir > >>>> would take several man-months at least and ongoing maintenance and I'm > >>>> very skeptical Canonical would take that on. > >>> > >>> As long as Canonical declines to work with the rest of the free software > >>> community, > >> > >> Well, I think that's an altogether inaccurate and unfair > >> characterization. > >> Canonical has always been open to working with "the rest of the free > >> software community"; what Canonical has not been willing to do is blindly > >> follow where certain self-appointed "upstreams" would lead, when that > >> conflicts with the business's goals. Wayland was evaluated, and found > >> not > >> to be suitable as a basis for Unity (as has been discussed elsewhere) - > >> thus, Wayland is not an upstream of Canonical (nor, TTBOMK, of any other > >> existing distros at the moment). Canonical has made a decision to > >> implement its own display server / compositor, in the form of Mir, and > >> as expressed in this thread is open to working with developers from > >> other desktops to see whether Mir can meet their needs as well. > >> > >> The KWin maintainer wasted no time after Mir was announced to make it > >> clear > >> that he wanted no part of it. I think that's unfortunate, but I also > >> don't > >> think that says anything about *Canonical's* willingness to work with > >> others in the free software community. > >> > >>> By deciding to do Mir, Canonical decided to go on it's own path that is > >>> not the one that the rest of the community was on. They're still on the > >>> path they were on and while it may be reasonable for Canonical to do > >>> it's > >>> own thing, I think Canonical has to also expect everyone else isn't > >>> going > >>> to drop their plans and toe the Canonical line about the future of > >>> $PROJECT (it could be any number of things, in this case it's what > >>> replaces X). AFAICT, both KDE and Gnome are satisfied with the path > >>> they > >>> are on with Wayland, so Mir is not interesting for them (I know far less > >>> about it for Gnome, but that's my understanding). > >> > >> There's no expectation from Canonical's side that others will drop > >> existing > >> plans to "toe the Canonical line". OTOH, as a bystander my understanding > >> is that Wayland has yet to advance beyond the level of a pet project - > >> not something production-ready that projects can rely on in a shipping > >> release. So I think it would behoove projects like GNOME and KDE to give > >> Mir a fair shake, rather than dismissing it because they've already > >> hitched their cart to Wayland. > >> > >>> I do think that the long term effect on flavors that aren&
Re: non-Unity flavours and Mir
On Monday, June 17, 2013 05:32:56 PM Steve Langasek wrote: > On Mon, Jun 17, 2013 at 05:13:33PM -0400, Scott Kitterman wrote: > > I think Jonathon's post earlier today captures the core issue: > > > > On Monday, June 17, 2013 09:05:08 PM Jonathan Riddell wrote: > > > On Fri, Jun 14, 2013 at 08:01:16PM +0200, Thomas Voß wrote: > > > > Yup :) I think a good way forward is to coordinate a call with > > > > Jonathan and Martin from KWin such that we can walk through the code > > > > together and identify the central points that would need to be mapped > > > > to Mir. We can then start discussing potential solutions how to add > > > > KWin support for Mir. > > > > > > I'm afraid I don't have interest in such a call and neither do the > > > KWin maintainers. I don't know anything about the KWin codebase or > > > how to begin porting it to another platform. KWin are busy porting it > > > to Wayland, the display server with consensus across Linux distros and > > > have no interest in supporting a display server with unstable API/ABI > > > that is only in one distro (from a company who have a track record of > > > not maintaining their features, we're having to drop indicator menu > > > support in Kubuntu because it's changed API). Porting KWin to Mir > > > would take several man-months at least and ongoing maintenance and I'm > > > very skeptical Canonical would take that on. > > > > As long as Canonical declines to work with the rest of the free software > > community, > > Well, I think that's an altogether inaccurate and unfair characterization. > Canonical has always been open to working with "the rest of the free > software community"; what Canonical has not been willing to do is blindly > follow where certain self-appointed "upstreams" would lead, when that > conflicts with the business's goals. Wayland was evaluated, and found not > to be suitable as a basis for Unity (as has been discussed elsewhere) - > thus, Wayland is not an upstream of Canonical (nor, TTBOMK, of any other > existing distros at the moment). Canonical has made a decision to implement > its own display server / compositor, in the form of Mir, and as expressed > in this thread is open to working with developers from other desktops to > see whether Mir can meet their needs as well. > > The KWin maintainer wasted no time after Mir was announced to make it clear > that he wanted no part of it. I think that's unfortunate, but I also don't > think that says anything about *Canonical's* willingness to work with others > in the free software community. > > > By deciding to do Mir, Canonical decided to go on it's own path that is > > not the one that the rest of the community was on. They're still on the > > path they were on and while it may be reasonable for Canonical to do it's > > own thing, I think Canonical has to also expect everyone else isn't going > > to drop their plans and toe the Canonical line about the future of > > $PROJECT (it could be any number of things, in this case it's what > > replaces X). AFAICT, both KDE and Gnome are satisfied with the path they > > are on with Wayland, so Mir is not interesting for them (I know far less > > about it for Gnome, but that's my understanding). > > There's no expectation from Canonical's side that others will drop existing > plans to "toe the Canonical line". OTOH, as a bystander my understanding is > that Wayland has yet to advance beyond the level of a pet project - not > something production-ready that projects can rely on in a shipping release. > So I think it would behoove projects like GNOME and KDE to give Mir a fair > shake, rather than dismissing it because they've already hitched their cart > to Wayland. > > > I do think that the long term effect on flavors that aren't deeply > > embedded in the Canonical technology set is reasonably clear and we > > shouldn't try to hide it. > > Certainly, flavors that are unable to align with technologies chosen for > Ubuntu will find themselves with more work to do to keep up quality and be > releasable. I don't think it's a foregone conclusion that this means > Kubuntu will be unreleasable because KWin will only support Wayland while > Canonical will only support X and Mir in Ubuntu; but certainly someone would > have to step up to provide *some* maintainable combination of components > here (either Wayland in Ubuntu, or KWin with support for X or Mir backend, > or...) > > I&#x
Re: non-Unity flavours and Mir
On Monday, June 17, 2013 05:54:25 PM Michael Hall wrote: > On 06/17/2013 05:13 PM, Scott Kitterman wrote: > > On Monday, June 17, 2013 04:22:41 PM Marc Deslauriers wrote: > >> On 13-06-17 04:00 PM, Jonathan Riddell wrote: > >>> On Fri, Jun 14, 2013 at 11:41:29AM -0400, Marc Deslauriers wrote: > >>>> Do you have any more details, or opened bugs about the issues? > >>> > >>> An X one for example > >>> https://bugs.kde.org/show_bug.cgi?id=xrr-ubuntu > >> > >> I was looking for issues that were caused by Unity-specific patches. > > > > I think it rather misses the point to do that. What I passed on was the > > upstream kwin perspective. Given that no kwin developer actually uses > > Kubuntu (they don't), it's quite likely that they may have misattributed > > the reasons for things, e.g. someone either on mail or IRC in > > conversation on this topic indicated that the prime driver behind pushing > > bleeding edge Mesa versions wasn't Unity, but hardware support > > requirements. It's quite likely that an upstream that's uninvolved with > > Ubuntu will understand all the reasons for all the changes, they just see > > the bug reports. > > > > I think Jonathon's post earlier today captures the core issue: > > > > On Monday, June 17, 2013 09:05:08 PM Jonathan Riddell wrote: > >> On Fri, Jun 14, 2013 at 08:01:16PM +0200, Thomas Voß wrote: > >>> Yup :) I think a good way forward is to coordinate a call with > >>> Jonathan and Martin from KWin such that we can walk through the code > >>> together and identify the central points that would need to be mapped > >>> to Mir. We can then start discussing potential solutions how to add > >>> KWin support for Mir. > >> > >> I'm afraid I don't have interest in such a call and neither do the > >> KWin maintainers. I don't know anything about the KWin codebase or > >> how to begin porting it to another platform. KWin are busy porting it > >> to Wayland, the display server with consensus across Linux distros and > >> have no interest in supporting a display server with unstable API/ABI > >> that is only in one distro (from a company who have a track record of > >> not maintaining their features, we're having to drop indicator menu > >> support in Kubuntu because it's changed API). Porting KWin to Mir > >> would take several man-months at least and ongoing maintenance and I'm > >> very skeptical Canonical would take that on. > > > > As long as Canonical declines to work with the rest of the free software > > community, those of us that are trying to do that are fundamentally > > disadvantaged. Canonical presumably has good business reasons for > > behaving as it is, so I won't even argue they should do things > > differently. I don't understand the business rationale well enough to be > > able to say. I do think that the long term effect on flavors that aren't > > deeply embedded in the Canonical technology set is reasonably clear and > > we shouldn't try to hide it. > > > > Scott K > > This thread is filled with offers from Canonical engineers to work with > the rest of the free software community to make Mir usable and useful > for their projects. By deciding to do Mir, Canonical decided to go on it's own path that is not the one that the rest of the community was on. They're still on the path they were on and while it may be reasonable for Canonical to do it's own thing, I think Canonical has to also expect everyone else isn't going to drop their plans and toe the Canonical line about the future of $PROJECT (it could be any number of things, in this case it's what replaces X). AFAICT, both KDE and Gnome are satisfied with the path they are on with Wayland, so Mir is not interesting for them (I know far less about it for Gnome, but that's my understanding). The issue isn't that Canonical engineers aren't willing to work with other people on integrating Mir, it's that because Mir is Ubuntu unique, has no stable API/ABI, conflicts with other priorities, etc., integrating Mir is simply not an interesting prospect for upstreams. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: non-Unity flavours and Mir
On Monday, June 17, 2013 04:22:41 PM Marc Deslauriers wrote: > On 13-06-17 04:00 PM, Jonathan Riddell wrote: > > On Fri, Jun 14, 2013 at 11:41:29AM -0400, Marc Deslauriers wrote: > >> Do you have any more details, or opened bugs about the issues? > > > > An X one for example > > https://bugs.kde.org/show_bug.cgi?id=xrr-ubuntu > > I was looking for issues that were caused by Unity-specific patches. I think it rather misses the point to do that. What I passed on was the upstream kwin perspective. Given that no kwin developer actually uses Kubuntu (they don't), it's quite likely that they may have misattributed the reasons for things, e.g. someone either on mail or IRC in conversation on this topic indicated that the prime driver behind pushing bleeding edge Mesa versions wasn't Unity, but hardware support requirements. It's quite likely that an upstream that's uninvolved with Ubuntu will understand all the reasons for all the changes, they just see the bug reports. I think Jonathon's post earlier today captures the core issue: On Monday, June 17, 2013 09:05:08 PM Jonathan Riddell wrote: > On Fri, Jun 14, 2013 at 08:01:16PM +0200, Thomas Voß wrote: > > Yup :) I think a good way forward is to coordinate a call with > > Jonathan and Martin from KWin such that we can walk through the code > > together and identify the central points that would need to be mapped > > to Mir. We can then start discussing potential solutions how to add > > KWin support for Mir. > > I'm afraid I don't have interest in such a call and neither do the > KWin maintainers. I don't know anything about the KWin codebase or > how to begin porting it to another platform. KWin are busy porting it > to Wayland, the display server with consensus across Linux distros and > have no interest in supporting a display server with unstable API/ABI > that is only in one distro (from a company who have a track record of > not maintaining their features, we're having to drop indicator menu > support in Kubuntu because it's changed API). Porting KWin to Mir > would take several man-months at least and ongoing maintenance and I'm > very skeptical Canonical would take that on. As long as Canonical declines to work with the rest of the free software community, those of us that are trying to do that are fundamentally disadvantaged. Canonical presumably has good business reasons for behaving as it is, so I won't even argue they should do things differently. I don't understand the business rationale well enough to be able to say. I do think that the long term effect on flavors that aren't deeply embedded in the Canonical technology set is reasonably clear and we shouldn't try to hide it. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: non-Unity flavours and Mir
On Friday, June 14, 2013 07:33:05 PM Oliver Grawert wrote: > hi, > > On Fr, 2013-06-14 at 13:12 -0400, Scott Kitterman wrote: > > On Friday, June 14, 2013 11:09:25 AM Oliver Ries wrote: > > > in addition to that I just want to highlight, that Jono and I are > > > working > > > on creating a forum for all interested Mir stakeholders (e.g. flavors, > > > but > > > also ISVs and others) to discuss such issues and drive alignment. > > > > See this is part of the problem. I don't WANT to be a Mir stakeholder. I > > want to focus my Kubuntu work on packaging KDE and making it work well. > > Historically, one of the great things about Kubuntu has been that we could > > rely on the work of the X team to give us a great display system with up > > to > > date hardware support that we didn't have to worry about. > > being a consumer of it kind of makes you a stakeholer, no ? > dont tell me you never discussed X issues with the Xorg team in the > past ... > the above is the offer to participate in a platform for conversation > about requirements, it is not like someone forces you to write patches > or so ... > it is just an extended version of this thread :) Sure. If it's a thing I can ignore unless there's a problem we have to work out, I'm happy. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: non-Unity flavours and Mir
On Friday, June 14, 2013 11:09:25 AM Oliver Ries wrote: > On Fri, Jun 14, 2013 at 10:56 AM, Thomas Voß > wrote: [...] > > > > I think we're all after a good technical solution for which there are > > > resources to implement. I know it won't happen upstream KDE and I'm > > > > almost as > > > > > confident the Kubuntu team is lacking the right skills to do it, so your > > > > offer > > > > > to look into it is most appreciated. > > > > Great, feel free to point people into my direction and we can get > > started as early as next week! > > Looking forward to it and thanks for starting the discussion. Do you > > need anything else from my side to get the conversations going? > > in addition to that I just want to highlight, that Jono and I are working > on creating a forum for all interested Mir stakeholders (e.g. flavors, but > also ISVs and others) to discuss such issues and drive alignment. > > We hope to have an update on that next week. OK. See this is part of the problem. I don't WANT to be a Mir stakeholder. I want to focus my Kubuntu work on packaging KDE and making it work well. Historically, one of the great things about Kubuntu has been that we could rely on the work of the X team to give us a great display system with up to date hardware support that we didn't have to worry about. Scott K P.S. No need to cc me. I'm subscribed to the list -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: non-Unity flavours and Mir
On Friday, June 14, 2013 06:41:33 PM Thomas Voß wrote: > On Fri, Jun 14, 2013 at 6:27 PM, Jonathan Riddell wrote: > > On Fri, Jun 14, 2013 at 11:47:43PM +0800, Ma Xiaojun wrote: > >> KDE, this one is interesting. The one even tries to support > >> proprietary OS. The same also claim their CI has very limited distro > >> coverage so they cannot support distro specific feature. Maybe we > >> replace Kwin with something else then problem solved (KDE run on > >> proprietary OS without Kwin) > > > > KDE having some applications running on Windows and Mac is irrelevant > > to this conversation. > > > > We're not going to drop KDE's compositor and window manager. > > I wouldn't have assumed that. But from a technical perspective, I'm > trying to understand why kwin couldn't be integrated with Mir. Judging > from the recent development with respect to a Wayland backend in KWin, > I got the impression that kwin's overall architecture is meant to be > pluggable to different windowing systems/compositors. I would be happy > to start looking into this if someone from the KDE/kwin team could > work together with me and guide me through the code. > > Do you think that makes sense? It could be technically. What we've lacked is someone with the time and skills to do the work. Upstream kwin have said that as long as Mir is a single distro solution, they aren't going to integrate it (which I think it quite reasonable). I think providing assistance to someone else who's going to do the work would be a different question, so we can ask. > >> I believe that there is nothing technically wrong with Mir or it is > >> fixable. If upstreams have political problems, what can we do? > > > > It's not a case of technical problems it's a case of Mir being > > different for no paticular advantage. It's a political problem of > > Canonical's making not KDE's. And the question is indeed what can we > > do in Ubuntu. > > I cannot give a political answer here but would like to resort to the > technical help offered before and evaluate how we could support KDE > (or more specifically kwin) best on Mir. I think we're all after a good technical solution for which there are resources to implement. I know it won't happen upstream KDE and I'm almost as confident the Kubuntu team is lacking the right skills to do it, so your offer to look into it is most appreciated. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: non-Unity flavours and Mir
On Saturday, June 15, 2013 12:04:18 AM Ma Xiaojun wrote: > On Fri, Jun 14, 2013 at 11:55 PM, Scott Kitterman wrote: > > As I mentioned, I'm relying on what upstream kwin has said. I know there > > have been times (quantal) when Ubuntu moving to a new mesa version in a > > manner that, from the perspective of our upstream, was overly aggressive > > caused problems. I would assume that was done because the features were > > wanted for Ubuntu specific reasons and not just version chasing. It may > > be no more than that. > > http://packages.qa.debian.org/m/mesa.html looks quite messy :) > > And I checked building flags, Arch Linux enables more stuff. Arch also think /usr/bin/python --> /usr/bin/python3 is a reasonable thing to do. > And I noted that we may need separate the build of libOSMesa and rest > of Mesa. As libOSMesa built with --enable-shared-glapi is considered > broken. > > And still want to see where are the bugs remotely caused by Unity? That isn't what I said. Kubuntu has always relied on the infrastructure provided in the Ubuntu archive to build our KDE variant on top of. It's pretty obvious to me that, at some point, this will no longer be feasible. The Kubuntu team certainly doesn't have the manpower or expertise to maintain their own X/Wayland stack. If, in the long run, the answer is to rely on Debian's maintenance effort for that, then the value of being part of the Ubuntu project is substantially diminished. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: non-Unity flavours and Mir
On Friday, June 14, 2013 11:50:05 PM Ma Xiaojun wrote: > On Fri, Jun 14, 2013 at 11:33 PM, Scott Kitterman wrote: > > Upstream kwin tells us they already see bug reports from Kubuntu users due > > to mesa changes to support Unity. I don't think it's just a new back > > end. > I checked mesa source package the other day. It looks more like a > straight sync from Debian drop some kfreebsd patches. > > What are the bugs? As I mentioned, I'm relying on what upstream kwin has said. I know there have been times (quantal) when Ubuntu moving to a new mesa version in a manner that, from the perspective of our upstream, was overly aggressive caused problems. I would assume that was done because the features were wanted for Ubuntu specific reasons and not just version chasing. It may be no more than that. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: non-Unity flavours and Mir
On Friday, June 14, 2013 11:47:43 PM Ma Xiaojun wrote: > I don't think any DE/WM other than E17, GNOME, KDE can get Wayland > support any time soon; probably never. Therefore, switching to Wayland > can potentially break these DE/WM also; nothing specific about Mir. ... > KDE, this one is interesting. The one even tries to support > proprietary OS. The same also claim their CI has very limited distro > coverage so they cannot support distro specific feature. Maybe we > replace Kwin with something else then problem solved (KDE run on > proprietary OS without Kwin) ... Not happening. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: non-Unity flavours and Mir
On Friday, June 14, 2013 11:41:29 AM Marc Deslauriers wrote: > On 13-06-14 11:33 AM, Scott Kitterman wrote: > > On Friday, June 14, 2013 11:15:17 AM Marc Deslauriers wrote: > >> On 13-06-14 11:04 AM, Scott Kitterman wrote: > >>> On Friday, June 14, 2013 03:54:32 PM Jonathan Riddell wrote: > >>>> Here's a discussion I half started as part of vUDS. > >>>> > >>>> The switch to Mir in Ubuntu seems pretty risky for the existance of > >>>> Kubuntu, I wonder if other flavours have the same probable problem. > >>>> > >>>> KWin dev has opinions on the subject > >>>> http://blog.martin-graesslin.com/blog/2013/05/mir-in-kubuntu/ From the > >>>> > >>>> architecture section on that blog post: > >>>> "Mir’s architecture is centered around Unity. It is difficult to > >>>> really > >>>> understand the architecture of Mir as the specification is so full of > >>>> buzz-words that I don’t understand it [5]. From all I can see and > >>>> understand Unity Next is a combination of window manager and desktop > >>>> shell implemented on top of Mir. How exactly this is going to look > >>>> like I do not know. Anyway it does not fit our design of having > >>>> desktop shell and window manager separated and we do not know whether > >>>> Mir would support that. We also do not know whether Mir would allow > >>>> any other desktop shell except Unity Next, given that this is the main > >>>> target. Wayland on the other hand is designed to have more than one > >>>> compositor implementations. Using KWin as a session compositor is an > >>>> example in the spec." > >>>> > >>>> and on protocol > >>>> > >>>> "But it gets worse, the protocol between Mir server and Mir clients > >>>> is defined as not being stable. In fact it’s promised that it will > >>>> break. That’s a huge problem, I would even call it a showstopper > >>>> Given that the protocol may change any time and given that the whole > >>>> thing is developed for the needs of Unity we have to expect that the > >>>> server libraries are not binary compatible or that old version of the > >>>> server libraries cannot talk with the latest client libraries" > >>>> > >>>> Canonical was going to port LightDM to Wayland but now does not plan > >>>> to so someone else would have to do this. KDE might be interested > >>>> but more likely will switch to SDDM. > >>>> > >>>> For Kubuntu the options are: > >>>> - Use Mir - infeasable as upstream can't support it as described above > >>>> - Use Wayland with packages from Debian and hope we can make those > >>>> packages > >>>> > >>>> live with Mir as best as possible > >>>> > >>>> - End of Kubuntu > >>>> > >>>> The second options is the one I'm expecting. It's completely unknown > >>>> how much it means Kubuntu and other flavours will need to maintain X > >>>> and Wayland packages, hopefully not much (it's hardly our speciality) > >>>> and hopefully Debian and Ubuntu Desktop will support it enough. > >>>> > >>>> I don't think there's a public timeline for Mir so we don't know when > >>>> this will hit us, presumably in the next year. > >>>> > >>>> Other flavours I think are this: > >>>> Mythbuntu: not evaluated, hope to do so once NVideo and AMD provide > >>>> drivers > >>>> Lubuntu: not evaluated, hope to use X and GTK > >>>> ubuntustudio: I've heard both that they use xfce based on xubuntu and > >>>> will follow them, and "aiming for users to choose whatever desktop > >>>> environment they want" > >>>> > >>>> Any other flavours got an opinions? > >>>> > >>>> Are there any misconceptions I have in the above? > >>> > >>> Given that mesa is going to be heavily patched to support Mir, I > >>> question > >>> the long term feasibility of supporting Wayland in Ubuntu. > >> > >> How would adding a new backend to mesa result in it being "heavily > >> patched"? Why would adding a new backend to mesa affect the other > >> backends, including Wayland? > > > > Upstream kwin tells us they already see bug reports from Kubuntu users due > > to mesa changes to support Unity. I don't think it's just a new back > > end. > Oh? That's quite odd, I don't see any Unity patches in the mesa package > in saucy. There are a couple of build fixes, and other trivial things, > but nothing that should be problematic. > > Do you have any more details, or opened bugs about the issues? I don't. I don't know a lot about the display stack details. I'm basing this on feedback from kwin upstream. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: non-Unity flavours and Mir
On Friday, June 14, 2013 11:15:17 AM Marc Deslauriers wrote: > On 13-06-14 11:04 AM, Scott Kitterman wrote: > > On Friday, June 14, 2013 03:54:32 PM Jonathan Riddell wrote: > >> Here's a discussion I half started as part of vUDS. > >> > >> The switch to Mir in Ubuntu seems pretty risky for the existance of > >> Kubuntu, I wonder if other flavours have the same probable problem. > >> > >> KWin dev has opinions on the subject > >> http://blog.martin-graesslin.com/blog/2013/05/mir-in-kubuntu/ From the > >> > >> architecture section on that blog post: > >> "Mir’s architecture is centered around Unity. It is difficult to really > >> understand the architecture of Mir as the specification is so full of > >> buzz-words that I don’t understand it [5]. From all I can see and > >> understand Unity Next is a combination of window manager and desktop > >> shell implemented on top of Mir. How exactly this is going to look > >> like I do not know. Anyway it does not fit our design of having > >> desktop shell and window manager separated and we do not know whether > >> Mir would support that. We also do not know whether Mir would allow > >> any other desktop shell except Unity Next, given that this is the main > >> target. Wayland on the other hand is designed to have more than one > >> compositor implementations. Using KWin as a session compositor is an > >> example in the spec." > >> > >> and on protocol > >> > >> "But it gets worse, the protocol between Mir server and Mir clients > >> is defined as not being stable. In fact it’s promised that it will > >> break. That’s a huge problem, I would even call it a showstopper > >> Given that the protocol may change any time and given that the whole > >> thing is developed for the needs of Unity we have to expect that the > >> server libraries are not binary compatible or that old version of the > >> server libraries cannot talk with the latest client libraries" > >> > >> Canonical was going to port LightDM to Wayland but now does not plan > >> to so someone else would have to do this. KDE might be interested > >> but more likely will switch to SDDM. > >> > >> For Kubuntu the options are: > >> - Use Mir - infeasable as upstream can't support it as described above > >> - Use Wayland with packages from Debian and hope we can make those > >> packages > >> > >> live with Mir as best as possible > >> > >> - End of Kubuntu > >> > >> The second options is the one I'm expecting. It's completely unknown > >> how much it means Kubuntu and other flavours will need to maintain X > >> and Wayland packages, hopefully not much (it's hardly our speciality) > >> and hopefully Debian and Ubuntu Desktop will support it enough. > >> > >> I don't think there's a public timeline for Mir so we don't know when > >> this will hit us, presumably in the next year. > >> > >> Other flavours I think are this: > >> Mythbuntu: not evaluated, hope to do so once NVideo and AMD provide > >> drivers > >> Lubuntu: not evaluated, hope to use X and GTK > >> ubuntustudio: I've heard both that they use xfce based on xubuntu and > >> will follow them, and "aiming for users to choose whatever desktop > >> environment they want" > >> > >> Any other flavours got an opinions? > >> > >> Are there any misconceptions I have in the above? > > > > Given that mesa is going to be heavily patched to support Mir, I question > > the long term feasibility of supporting Wayland in Ubuntu. > > How would adding a new backend to mesa result in it being "heavily > patched"? Why would adding a new backend to mesa affect the other > backends, including Wayland? Upstream kwin tells us they already see bug reports from Kubuntu users due to mesa changes to support Unity. I don't think it's just a new back end. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: non-Unity flavours and Mir
On Friday, June 14, 2013 03:54:32 PM Jonathan Riddell wrote: > Here's a discussion I half started as part of vUDS. > > The switch to Mir in Ubuntu seems pretty risky for the existance of > Kubuntu, I wonder if other flavours have the same probable problem. > > KWin dev has opinions on the subject > http://blog.martin-graesslin.com/blog/2013/05/mir-in-kubuntu/ From the > architecture section on that blog post: > > "Mir’s architecture is centered around Unity. It is difficult to really > understand the architecture of Mir as the specification is so full of > buzz-words that I don’t understand it [5]. From all I can see and > understand Unity Next is a combination of window manager and desktop > shell implemented on top of Mir. How exactly this is going to look > like I do not know. Anyway it does not fit our design of having > desktop shell and window manager separated and we do not know whether > Mir would support that. We also do not know whether Mir would allow > any other desktop shell except Unity Next, given that this is the main > target. Wayland on the other hand is designed to have more than one > compositor implementations. Using KWin as a session compositor is an > example in the spec." > > and on protocol > > "But it gets worse, the protocol between Mir server and Mir clients > is defined as not being stable. In fact it’s promised that it will > break. That’s a huge problem, I would even call it a showstopper > Given that the protocol may change any time and given that the whole > thing is developed for the needs of Unity we have to expect that the > server libraries are not binary compatible or that old version of the > server libraries cannot talk with the latest client libraries" > > Canonical was going to port LightDM to Wayland but now does not plan > to so someone else would have to do this. KDE might be interested > but more likely will switch to SDDM. > > For Kubuntu the options are: > - Use Mir - infeasable as upstream can't support it as described above > - Use Wayland with packages from Debian and hope we can make those packages > live with Mir as best as possible > - End of Kubuntu > > The second options is the one I'm expecting. It's completely unknown > how much it means Kubuntu and other flavours will need to maintain X > and Wayland packages, hopefully not much (it's hardly our speciality) > and hopefully Debian and Ubuntu Desktop will support it enough. > > I don't think there's a public timeline for Mir so we don't know when > this will hit us, presumably in the next year. > > Other flavours I think are this: > Mythbuntu: not evaluated, hope to do so once NVideo and AMD provide drivers > Lubuntu: not evaluated, hope to use X and GTK > ubuntustudio: I've heard both that they use xfce based on xubuntu and > will follow them, and "aiming for users to choose whatever desktop > environment they want" > > Any other flavours got an opinions? > > Are there any misconceptions I have in the above? Given that mesa is going to be heavily patched to support Mir, I question the long term feasibility of supporting Wayland in Ubuntu. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Moving Ubuntu SDK Plugin out of the QtCreator source package
Although I didn't really explore the details, I understand that currently the Ubuntu SDK QtCreator plugin has to have access to the QtCreator source to build and that's why it is a patch in the qtcreator source package. Currently that is our only diff with upstream and Debian. During this cycle, could that be moved to it's own package? Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: indicator-weather broken, should we drop it from raring?
Rodney Dawes wrote: >On Mon, 2013-04-22 at 00:00 -0500, Micah Gersten wrote: >> If it's totally broke, let's drop it and backport it if/when it gets >> fixed. A backport will appear in software center just like something >in >> the main archive if there's no archive version for it AIUI (apt >> certainly treats it that way since backports are enabled by default, >but >> pinned lower). > >Since when have backports been enabled by default? They are not enabled >on my machine >at least… Since Natty, IIRC. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: boost1.53 transition for s-series
On Tuesday, March 26, 2013 09:29:53 AM Dmitrijs Ledkovs wrote: > On 26 March 2013 09:22, Scott Kitterman wrote: > > Dmitrijs Ledkovs wrote: > >>boost1.53 is available in raring/universe, and I'd like to have > >>boost1.53 as default in the next series, at opening. > >> > >>The transition tracker is up: > >>http://people.canonical.com/~ubuntu-archive/transitions/boost1.53.html > >> > >>Here are the results of test rebuild: > >>http://people.canonical.com/~xnox/boost1.53/ > >> > >>Two thirds build fine (201), 22 packages need twiddling with > >>build-depends to try building them and the rest show some. > >> > >>OK, to go ahead for s-series opening? Please let me know your thoughts. > >> > >>I hope the recently released gcc4.8 will be default in s-series, thus > >>together with boost1.53 bringing in excellent C++11 support. > >> > > KDE all have to be built with the same boost version. Could you retry > > those as a set with the boost version changed for all of them? > I've noticed. Yes, I will be twiddling with correct build-depends. > So far this rebuild was done in the correct order with boost1.53 > forced, without changing the packages and with local packages from > previous rounds. To catch all fallout. I think as it is, we don't know enough to have an informed opinion. If I knew when Wheezy would release and when Debian would start their transition, it would be easier. For KDE, dependency freeze for KDE SC 4.11 is May 29, so we have a bit of time to work this from that point of view. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: boost1.53 transition for s-series
Dmitrijs Ledkovs wrote: >boost1.53 is available in raring/universe, and I'd like to have >boost1.53 as default in the next series, at opening. > >The transition tracker is up: >http://people.canonical.com/~ubuntu-archive/transitions/boost1.53.html > >Here are the results of test rebuild: >http://people.canonical.com/~xnox/boost1.53/ > >Two thirds build fine (201), 22 packages need twiddling with >build-depends to try building them and the rest show some. > >OK, to go ahead for s-series opening? Please let me know your thoughts. > >I hope the recently released gcc4.8 will be default in s-series, thus >together with boost1.53 bringing in excellent C++11 support. KDE all have to be built with the same boost version. Could you retry those as a set with the boost version changed for all of them? Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Distro patches in qtbase-opensource-src
Because there's an open FFe request for adding another set of distro patches to qtbase-opensource-src (still waiting to hear the upstream status, BTW - https://bugs.launchpad.net/bugs/1126205 ), I decided to take a look at the package and see what else was there. There are two currently. One, to fix the PowerPC build was upstreamed and I can see by tracing from the LP bug mentioned in debian/changelog to the linked Qt upstream bug that this fix was forwarded upstream and will be included in Qt5 5.0.2. The other, debian/patches/fix_maliit_activation.patch, I can't see documented anywhere. There is no mention in debian/changelog, and the patch headers say: Description: Fix maliit keyboard activation Maliit server wasn't necessarily activated when it should have. This patch fixes the issue. . Author: Zoltán Balogh --- Origin: Canonical Ltd Forwarded: no Last-Update: 2012-12-15 Was this ever forwarded? What's it's status? Scott K signature.asc Description: This is a digitally signed message part. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: We need your help for GSoC 2013
On Sunday, March 24, 2013 09:21:23 AM Dylan McCall wrote: > We're going to be applying for Google Summer of Code (GSoC) this year. I'm > sure many of you know the drill at this stage: it's an opportunity to grow > Ubuntu's developer community, share knowledge with talented university > students, make friends and get some really cool work done. We have a wiki > page all about GSoC 2013 that explains the hows and whys in detail: > > https://wiki.ubuntu.com/GoogleSoC2013 > > Since the last GSoC we participated in, Ubuntu has really found its own > with several projects led by Canonical and by members of the community. As > I see it, Unity, Juju, Ubuntu Touch and Mir are interesting projects that > students would enjoy contributing to, and they are all projects that > students would be best equipped to work on with Ubuntu as the mentoring > organization. And, of course, there are many more where those came from! I > already mentioned that there are many lovely benefits for the students and > for Ubuntu, and I'll also point out that this is a way to really expand on > the community-friendly nature of those projects. I think it would be > amazing if we could make that happen. > > So, this is where you come in! Do you have an idea for a project that we > could empower a student to work on over the summer? Are you interested in > mentoring one of those talented and motivated students? Either way, you're > welcome to add what you see fit to our list of ideas and mentors: > https://wiki.ubuntu.com/GoogleSoC2013/Ideas. If you want to communicate with the developers of Unity, Juju, Ubuntu Touch and Mir, you should probably find a mailing list where development of those projects is on topic. Ubuntu-devel is for development of the Ubuntu GNU/Linux distribution, not upstream projects which each have their own lists, forums, IRC channels, etc. Scott K -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
