Re: [Ubuntu-phone] Defining Click framework(s) for 13.10
On Wed, Sep 18, 2013 at 04:31:51PM +0200, Loïc Minier wrote: > This should be as backwards-compatible as possible (at least up to > 12.04) I guess you mean 14.04 here. > Also, do we want multiple frameworks, notably for webapps or for cordova? We designed click so that it could support multiple frameworks in the future, but it doesn't yet. If all these putative frameworks are going to be in the Ubuntu Touch images anyway, then I'd recommend just using a single framework declaration at the moment. -- Colin Watson[cjwat...@canonical.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Defining Click framework(s) for 13.10
On Fri, Sep 20, 2013 at 05:39:39PM +0200, Loïc Minier wrote: > On Wed, Sep 18, 2013, Colin Watson wrote: > > We designed click so that it could support multiple frameworks in the > > future, but it doesn't yet. If all these putative frameworks are going > > to be in the Ubuntu Touch images anyway, then I'd recommend just using a > > single framework declaration at the moment. > > Ah, I thought we could currently have multiple frameworks on the system > and a click manifest could only depend on one, is that not the case? That's true, but if all the systems we care about have all the frameworks, then we don't really gain anything. I'd just leave it at a simple single-framework system for 13.10 and expand later. -- Colin Watson[cjwat...@canonical.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] [Ubuntu-appstore-developers] sdk/click framework 14.04 ETA?
On Mon, Jan 20, 2014 at 09:46:48AM -0500, Pat McGowan wrote: > On 01/19/2014 06:44 PM, Sergio Schvezov wrote: > > Do we have an ETA to at least just define this? > > Do we have a process of what needs to be done after every release? > > > > Reason for asking it that the reminders app is ready for store upload, > > but I'm most certainly sure it won't work on all framework 13.10 > > supported releases (saucy). > What does it depend on that was not defined for 13.10? We talked about > defining a 13.10.1 early Feb for apps that require the recent additions > to the framework. We shouldn't define things as 13.10.x when they aren't in saucy. It's confusing. > > We don't really need to have it in final form, since this is still > > moving along; but having the tag would be good to filter out where we > > know this is bound not to work. > The Qt 5.2 approach decision somewhat affects the timing and rollout for > the 14.04 tag. We also are waiting on the support for multiple > frameworks to land. I think we should stop waiting for the next thing to land, and simply define a 14.04 framework (possibly "beta" or similar, or else just defined as unstable) now. Otherwise we end up deadlocked. -- Colin Watson[cjwat...@canonical.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] How to find current framework version (for the click scope, not an app)
On Wed, Jan 08, 2014 at 01:38:57PM -0600, Jamie Strandboge wrote:
> On 01/08/2014 12:42 PM, Mike McCracken wrote:
> > The click scope currently has a hard-coded string
> > "framework:ubuntu-sdk-13.10"
> > which it uses to query the click store for apps to display.
> >
> > It seems like we should be getting that from somewhere else.
> > Is there an authoritative place to get the name of the currently installed
> > framework?
> >
>
> This is a great question. The available frameworks are in the
> /usr/share/click/frameworks directory, but it seems that you should use the
> click API or call out to (the nonexistent) 'click frameworks' (or similar)
> command. CC'ing Colin for input.
Please file a bug on the Ubuntu click package about this so that I don't
forget. I think it would be best to add an API for this as part of the
libclick work. In the meantime the following Python code or equivalent
should be safe (although please include a reference to any packages
where you've open-coded this in your bug report on click):
def installed_frameworks():
ext = ".framework"
for name in os.listdir("/usr/share/click/frameworks"):
if name.endswith(ext):
yield name[:-len(ext)]
--
Colin Watson [cjwat...@ubuntu.com]
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] Multiple frameworks for apps
As I understand it, the agreement from the app-frameworks discussion at UDS was that we wanted to be able to offer slightly more fine-grained framework declarations, and allow apps to require multiple frameworks. (This would also help with ABI breaks like Qt 5.2; no reason to require QML-only apps to change just because we change an implementation detail of the platform that only affects native-code apps.) I planned for this when laying out the Click file formats, but it didn't make the implementation cut for 13.10. The code currently in lp:click, which will become version 0.4.14, extends the "framework" manifest field a bit to support this. With this, assuming appropriate declaration files in /usr/share/click/frameworks/, apps will be able to do something like this: "frameworks": "ubuntu-14.04-qml, ubuntu-14.04-html5" click does not care what the names are; these are just examples. The idea here is that if we do need to do ABI breaks in the future, at least this limits the set of affected apps, and presumably we can keep the most widely-used ones more stable. I would suggest that we don't go overboard on how fine-grained we make this, so that app authors don't need to make overly complex decisions. If you have any (non-bikeshed) concerns about this, please let me know before I get the landing ask for click 0.4.14 approved. :-) Cheers, -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Multiple frameworks for apps
On Wed, Jan 22, 2014 at 07:18:00PM +0200, Jani Monoses wrote: > Colin Watson wrote: > > "frameworks": "ubuntu-14.04-qml, ubuntu-14.04-html5" > > Should this be > "framework": "ubuntu-14.04-qml, ubuntu-14.04-html5" > that is the current manifest key name did not change to the plural form ? That's correct. Sorry for my typo. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] [Ubuntu-appstore-developers] Multiple frameworks for apps
On Wed, Jan 22, 2014 at 01:16:07PM -0500, Rodney Dawes wrote: > On Wed, 2014-01-22 at 17:10 +0000, Colin Watson wrote: > > If you have any (non-bikeshed) concerns about this, please let me know > > before I get the landing ask for click 0.4.14 approved. :-) > > How will we get a list of all the frameworks the system supports, for > apps to run on? https://lists.launchpad.net/ubuntu-phone/msg06051.html -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] [Ubuntu-appstore-developers] Multiple frameworks for apps
On Wed, Jan 22, 2014 at 04:17:24PM -0600, Ted Gould wrote: > On Wed, 2014-01-22 at 11:48 -0600, Jamie Strandboge wrote: > > "frameworks": "ubuntu-sdk-13.10, ubuntu-14.04-qml" > > Don't have strong opinions on the rest of the thread, but can we please > make this: > > > "frameworks": ["ubuntu-sdk-13.10", "ubuntu-14.04-qml"] I initially did it this way, but found that I had already defined the format as being that of a Debian package dependency relationship field, which has other useful properties - it may allow extensibility to declaring versions in a better way in future, for instance. So, no, I'd prefer not to make that change, sorry. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Multiple frameworks for apps
On Wed, Jan 22, 2014 at 03:22:19PM -0500, Pat McGowan wrote: > Does this support the concept of a range of framework versions? Or is > the idea we explicitly list each version the system supports, as would > the apps click package. The format has space for that (see my mail to Ted a moment ago), although at present this is unimplemented. I'm trying to only implement things where it's already fairly well-understood how we'd use them, to avoid painting us into a corner by mistake. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] [Ubuntu-appstore-developers] Multiple frameworks for apps
On Wed, Jan 22, 2014 at 11:48:07AM -0600, Jamie Strandboge wrote: > This affects click-apparmor and while we did talk about this a bit at UDS, I > want to restate it here. I realize click doesn't care about this, but will we > expect things like this: > > "frameworks": "ubuntu-sdk-13.10, ubuntu-14.04-qml" > > If so, that complicates things greatly because there is one APP_ID defined per > app in the click package and therefore only one apparmor profile per app. I think the most practical way to deal with this is roughly as you suggest, by causing the review tools to reject ridiculous combinations. I don't expect particularly many, and it should be easy to avoid them getting out of hand; doing it in the review tools gives us more flexibility than doing it in the packaging system. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] [Ubuntu-appstore-developers] Multiple frameworks for apps
On Thu, Jan 23, 2014 at 12:21:00PM +0100, Alexander Sack wrote: > How do we find and define what the "sane" combinations are? That's trivial - we can start by saying that you only get to use combinations with the same prefix, e.g. "ubuntu-sdk-14.04*". Those will presumably just be broken down from what might previously have been declared as "ubuntu-sdk-14.04", so are clearly a sane combination. I don't think any of this should block click 0.4.14. What frameworks you want to declare is up to you(r team); if you want to just declare "ubuntu-sdk-14.04" then that's fine by me and click will behave as before. I just want to have the support in place so that if and when you need this (I predict it's "when", since this is something I've already been asked for several times) then I don't have to scramble to enable it in the package manager. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] [Ubuntu-appstore-developers] Multiple frameworks for apps
On Thu, Jan 23, 2014 at 02:23:16PM +0100, Alexander Sack wrote: > How about adding such safety belts to our click packaging tools as well? > > e.g. bail out or present big warnings if someone tries to package up > an app with disagreeing versions? Happy to do so once somebody tells me what rules we want to apply. :-) -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] [Ubuntu-appstore-developers] Multiple frameworks for apps
On Thu, Jan 23, 2014 at 02:20:28PM +0100, Alexander Sack wrote: > Q: does the click package manager also take care of disabling apps > that are incompatible after you get an image update that stops > shipping a specific framework version? Not as yet. Could somebody file a bug for me to look into that? -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] [Ubuntu-appstore-developers] Multiple frameworks for apps
On Thu, Jan 23, 2014 at 03:19:46PM +0100, Alexander Sack wrote: > On Thu, Jan 23, 2014 at 2:59 PM, Colin Watson wrote: > > Happy to do so once somebody tells me what rules we want to apply. :-) > > I think a "conservative" rule to start off with might be: > > 1. requiring ubuntu-sdk-libs-YY.MM is valid > 2. requiring exactly ONE ubuntu-sdk-libs-YY.MM-SUBFRAMEWORK is valid > 3. everything else is not valid. > > We can later be more liberal and allow more funky combinations once we > see a real need for it. > > Sounds good? Not really - I don't think we need to be as conservative as this (we could easily allow any matching ubuntu-sdk-YY.MM*), and I would prefer to trust our review processes to ensure that our single monolithic framework is split in a sensible way and not made excessively fine-grained. However, I also want to get on with other things rather than getting bogged down in a long debate about this, so I've just committed this: * build: Enforce only a single framework declaration for now, by request. ... which effectively ensures that things are no different from before from the perspective of app authors, but if we want to experiment with other options then "click install" won't get in the way. You can get back to me if you want to adjust this policy. Cheers, -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] [Ubuntu-appstore-developers] Switching Click framework to 14.04 Dev
On Thu, Feb 13, 2014 at 09:10:02AM -0500, Pat McGowan wrote: > Note that the developer should be able to claim support for multiple > frameworks. > > We had decided to revision frameworks separately for Qt/QML and HTML, so > should we go ahead with that now rather than use a "sdk" named revision? Jamie's item 7 is a prerequisite for that, and it'll take a little while (weeks, not months). We need to move on with this, so I think we should probably go ahead with the monolithic sdk framework to unblock people, and consider subdividing later. (decoupling for the win) -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] [Ubuntu-appstore-developers] Switching Click framework to 14.04 Dev
On Thu, Feb 13, 2014 at 08:45:28AM -0600, Jamie Strandboge wrote: > On 02/13/2014 08:10 AM, Pat McGowan wrote: > > Note that the developer should be able to claim support for multiple > > frameworks. > > To be clear-- the developer can claim support for multiple frameworks with the > same major version. Eg, this is allowed (syntax might not be final here, but > you > get the idea): > > "framework": ["ubuntu-sdk-14.04-dev", "ubuntu-sdk-14.04"] Except that this is currently disallowed per https://lists.launchpad.net/ubuntu-phone/msg06093.html. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Landing team 10.03.14
On Tue, Mar 11, 2014 at 11:08:36AM -0400, Pat McGowan wrote: > We have identified an issue in click when the same app was both > pre-installed and updated from the store. A fix is in the works. Right. Here's an explanation for posterity, since this is not at all obvious. Click maintains multiple databases of packages, which are associated with the different ways in which a package can be installed. The default setup has a "core" database for the packages that are preinstalled in the stock Ubuntu image, a "custom" database for packages that are preinstalled by carriers/OEMs, and a "default" database for user-installed packages. It's possible for the same package to exist at more than one version: for example you might have an older factory version with a newer version that you upgraded from the store; and it's possible for different users of a single system to "register" different versions of a package, so that if I upgrade a package on my tablet then my wife can choose whether she wants to upgrade rather than being forced to do it at the same time, etc. This is generally quite flexible. However, up to now it's been possible for the same version of the same package to be unpacked in different databases. This isn't an obviously sensible thing to do deliberately, but it can easily arise if you upgrade a package from the store and then later upgrade to a system image that has that same version of the package preinstalled. In this case, we have a serious semantic problem. Packages may attach to "hooks" defined by system packages, which may either be system-level (apply to all users, generally mediate access to system resources of some kind and work on files shared by all users) or user-level (apply to each user independently). Hooks create symlinks which are named after the application ID (package name, application name, version). For a system-level hook, what should the symlink point to if there's more than one unpacked copy of the same version of the same package? Usually it doesn't matter - they're the same thing, after all - but in the case of the apparmor hook it is vitally important that this be self-consistent and consistent with how all users launch the application, because the apparmor hook uses the target of the hook symlink as an input to the profile it generates to grant the application read access to its own files. The result of getting this wrong is that the application cannot read its own files and thus cannot start. I have instituted a new rule that the deepest of any unpacked copies of the same version of the same package will always be used. This is a bit counterintuitive because normally shallower databases win so that users can override preinstalled packages, but in this case it's the best choice because it allows us to eventually garbage-collect old unpacked copies from user data and thus save valuable space. This will land in click 0.4.18.x shortly. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Landing team 10.03.14
On Wed, Mar 12, 2014 at 02:41:54AM -0300, Ricardo Salveti de Araujo wrote: > It seems we got a critical click regression with 233 (click user hook > fails to start), making the user unable to launch any click package > (camera, facebook, twitter, etc). > > Opened bug https://bugs.launchpad.net/ubuntu/+source/click/+bug/1291192 > for this one. Thanks. I reproduced an identical failure with new test code; fix in landing-004 now. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] [PROPOSAL] No (click) apps on images by default
it, which isn't free, but that can be fixed easily enough. Obviously this doesn't free the disk space used by the unpacked copy of the app in the base image; we can't, since it's read-only. I would not expect the preinstalled apps to be particularly large; if there are large ones that are commonly hidden by carriers, or maybe ones that are frivolous enough that they don't add much value to our stock images, then I can see the logic in removing those entirely; but that shouldn't be the first thing we reach for. I think this unregister-for-all-users mechanism is the best way to deal with this kind of thing, and I designed the multiple-database system in Click with exactly this use case as one of those I had in mind. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] [PROPOSAL] No (click) apps on images by default
On Wed, Mar 12, 2014 at 09:39:30PM -0300, Ricardo Salveti de Araujo wrote: > Thanks a lot for the detailed explanation, really useful (which brings > a question if this is documented already somewhere). It wasn't, but I've pushed a lightly-edited version of my brain-dump here: https://click.readthedocs.org/en/latest/databases.html -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] [PROPOSAL] No (click) apps on images by default
On Wed, Mar 12, 2014 at 11:05:25PM +, Colin Watson wrote: > click unregister --root=/custom --all-users PACKAGE-NAME This should be --root=/custom/click, not --root=/custom, to match how the database is declared. I've fixed the documentation in click accordingly. Sorry for that typo. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Some bugs with click store.
On Thu, Mar 13, 2014 at 03:34:29PM +0400, Зонов Роман wrote: >Firstly, click apps are loading too long. It is annoying. If you're referring to click app startup time, these two branches will make that substantially better when they land: https://code.launchpad.net/~cjwatson/upstart-app-launch/libclick-pkgdir/+merge/209909 https://code.launchpad.net/~cjwatson/upstart-app-launch/libclick-manifest/+merge/210520 -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Some bugs with click store.
On Thu, Mar 13, 2014 at 04:00:39PM +0400, Зонов Роман wrote: > 13.03.2014, 15:58, "Colin Watson" : > > On Thu, Mar 13, 2014 at 03:34:29PM +0400, Зонов Роман wrote: > >> Firstly, click apps are loading too long. It is annoying. > > > > If you're referring to click app startup time, these two branches will > > make that substantially better when they land: > > Thank you for your work, but I'm telling about another thing. Then I > turn on phone, firstly I see standard apps. After 5-10 seconds I see > click apps in Apps scope. That is annoying. I only work on some bits of this, so directing your e-mail only to me personally and not to the list is counterproductive since the people who would need to see your mail won't see it. I guess this was probably an accident, so CCing the list back in. In this case, this sounds like a problem with the click scope. I have some work in progress to convert it to use libclick to get the list of installed packages rather than having to start a Python interpreter, and that should speed things up. I doubt that would account for 5-10 seconds, though, so perhaps there is some other problem here. Cheers, -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Some bugs with click store.
On Thu, Mar 13, 2014 at 12:34:06PM +, Dimitri John Ledkov wrote: > On 13 March 2014 12:10, Зонов Роман wrote: > > Thank you for your work, but I'm telling about another thing. Then I > > turn on phone, firstly I see standard apps. After 5-10 seconds I see > > click apps in Apps scope. That is annoying. > > The apps scope, shows applications from the app store (not locally > installed), which is fetched over the internet on first boot, thus the > download delay. While this is true, it doesn't at all justify the described behaviour; installed apps should be displayable before any response is received from the network. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Landing team 14.03.14
On Fri, Mar 14, 2014 at 09:48:38PM -0500, Jamie Strandboge wrote:
> 1. we are going to force everyone to rebuild with ubuntu-sdk-14.04-dev1 (I
> thought we were going to use ubuntu-sdk-14.04-qml-dev1,
> ubuntu-sdk-14.04-html-dev1 and ubuntu-sdk-14.04-papi-dev1 anyway...) and then
> again with ubuntu-sdk-14.04-qml|html|papi in a few weeks. This seems less than
> ideal.
Well, firstly, it's rubbish to have missed the splitting; we should get
the proper frameworks in as soon as you and I are both actually at work.
If I'd been properly around when we'd been doing this I'd have noticed
in time ...
But secondly, there's absolutely no reason why we should drop -dev1
frameworks from the released image if their ABI hasn't been broken.
I've made this point before and I think Click/Frameworks encapsulates
it. So there's no reason app authors would have to rebuild for that.
> 2. we are asking people to upload apps to the store with a framework
> (or qt5.2 for that matter) that doesn't yet exist on a promoted image.
My understanding is that the store will only return results to clients
that match frameworks they have.
> In theory, they can test the packaging changes by using
> --force-missing-framework with click install, but does pkcon
> install-local support that?
No.
> (Aside: what will libclick do for base framework and base version if
> the framework is missing?)
The framework doesn't exist so you'll never get as far as being able to
query it. How that's handled depends on how click-apparmor starts using
libclick; click itself doesn't use the
click_framework_get_base_{name,version} functions.
--
Colin Watson [cjwat...@ubuntu.com]
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Landing team 20.03.14
On Thu, Mar 20, 2014 at 01:47:40PM -0400, Bill Filler wrote: > Just an update on this: the messaging-app test fix won't land until the > next image promotion (after the current one) as it depends on a bunch of > other dependencies to be rebuilt with cherry picked changes that are > already in a existing silo. So messaging-app will get updated with the > fix when that silo lands (silo 18) I've forced messaging-app through -proposed - in this case we can tolerate the uninstallables on arm64/powerpc/ppc64el for a period, as all the necessary fixes have been identified and are in progress on various branches. I don't want to hold things up for those. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Landing team meeting 19.03.14
then we'll have a series of successive out-of-phase bugs and we'll end up never being able to promote an image again. I think we've drawn too broad a lesson from past problems. Yes, we need to be careful not to aggregate risk from lots of nearby overlapping changes. But I don't believe that after ten years we don't have the institutional expertise to spot when two changes truly have nothing to do with each other - and our stack is big enough that this is still frequently the case. Even when our archive was a complete free-for-all with no automatic installability gatewaying (and so upgrades were often broken), we still managed to produce pretty decent desktop milestone images with only a couple of days of heavy lifting, and most of that was typically cleaning up after problems that proposed-migration and other parts of the daily quality initiative now keep out of the archive for us. I am not at all convinced that the phone stack is so much more complex that we can't loosen our grip a bit and still have things workable, especially now that we have some much better technology for catching many frequent categories of regressions (certainly a worthwhile benefit of all this hard experience over the last couple of years); and as a bonus we might not burn out some of our best engineers trying to do ultra-tight coordination of everything all the time. Given the choice, which is better: to have slightly more frequent breakage, but have key engineers be fresh and able to work on urgent problems that come their way every so often; or to have our key engineers concentrate hard every day to make sure as few regressions as possible slip in, at the cost that when difficult problems show up they're too tired and demotivated to deal with them properly? I'm worried that risk aversion means we tend to aim for the latter. Cheers, -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Landing team meeting 19.03.14
On Thu, Mar 20, 2014 at 09:45:14PM -0500, Victor Thompson wrote: > Colin Watson wrote: > > Given the choice, which is better: to have slightly more frequent > > breakage, but have key engineers be fresh and able to work on urgent > > problems that come their way every so often; or to have our key > > engineers concentrate hard every day to make sure as few regressions as > > possible slip in, at the cost that when difficult problems show up > > they're too tired and demotivated to deal with them properly? I'm > > worried that risk aversion means we tend to aim for the latter. > > Frequent breakages that get put on a "list" while the project moves > forward is exactly why the Terminal app had the backspace/enter > regression for months. I didn't say that bugs like that should be put on the shelf and ignored. What I said was that management should absolutely be making sure that the right people are working on that sort of thing, but without blocking dozens of other engineers until it's done. The probability of changes to the base system interfering in any significant way with somebody's ability to sort out a core-app-level bug like this is negligible. > There are two paths to take right now for the music app bug: > 1. Wait for the upstream QtMultimedia bug to be fixed [1] > 2. Move aggressively towards the Media Hub component with playlist support > > Given that the project's need to push features to the QA supported > channel (I'm not convinced that most dogfooders are on the > non-proposed channel anyway), I suggest we avoid the upstream battle > and move towards integrating the Media Hub as quickly as possible. I hope you're not suggesting that we stop the line until media-hub is ready. I've got no problem with the media-hub direction (indeed I approved its feature freeze exception bug 1290360 recently); but from the landing point of view it is a significant and large new chunk of work. It could easily take some time to stabilise in its own right. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANN: TRAINCON-0 - CITRAIN all stop starting Friday
On Fri, Mar 21, 2014 at 03:08:19PM +0100, Alexander Sack wrote: > On the front of data, we haven't seen much new. For instance we only > know about a single case where this "all halt" event has negative > impact; so please speak up if you are affected. I'm blocked on fixing click chroot to install the proper qtdeclarative plugins until this is done. I could also shave 1.4 seconds off every click app startup immediately if I were allowed to land the approved MPs in question. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] phablet-flash can't find index.json
On Fri, Mar 21, 2014 at 09:14:11AM -0700, Sameer Verma wrote: > For a Nexus 7 2102 WiFi, this is what I get. > > sverma@imagenius:~$ sudo phablet-flash ubuntu-system --channel > devel-proposed --bootstrap > INFO:phablet-flash:Device detected as grouper > INFO:urllib3.connectionpool:Starting new HTTPS connection (1): > system-image.ubuntu.com > ERROR:phablet-flash:https://system-image.ubuntu.com/devel-proposed/grouper/index.json > cannot be retrieved Try "--channel ubuntu-touch/devel-proposed". -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Landing team 21.03.2014
On Sun, Mar 23, 2014 at 02:59:19PM +, Sam Bull wrote: > On dim, 2014-03-23 at 10:04 -0300, Sergio Schvezov wrote: > > The installed version can be checked by running > > click list | grep music > > So, this appears to fail due to a webapp I uninstalled months ago. > http://pastebin.com/bg5PXa30 Could you file a bug on the click package in Ubuntu about that, please? It shouldn't crash on this. > > Also add > > find /var/lib/apparmor -ls > > Rather a lot of stuff in here, most of them are for apps that are not > installed. > http://pastebin.com/2G4H2De4 Yes, this looks like the same thing that Sergio reported to me the other day. I think I'm beginning to get a handle on it and am working through it now. > > You should be able to edit as root for non preinstalled apps without > > escaping from read only > > OK, so I was trying to edit the files > in /opt/click.ubuntu.com/org.sambull.bitcoin-app/current/ > I'm guessing this is no longer the right location, as that is also where > the old versions of music are stored. No, that's the correct place for user-installed apps (well, ish - the current/ symlink predates per-user registrations and is not really used for much any more, so I'd like to figure out how to get rid of it at some point as it causes some code cruft, but it should point to the same place at least). https://click.readthedocs.org/en/latest/databases.html has a brain-dump of the layout. > Checking the .desktop file, it > appears the files it's using are in /opt/.click/, but I still have the > same problem. When I try to save in nano, it confirms the location to > save, but hitting enter just makes an error sound and it refuses to > save. Are you using "sudo nano" rather than just "nano"? The files will all be owned by the clickpkg user, not by phablet. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Landing team 21.03.2014
On Mon, Mar 24, 2014 at 01:45:52PM +, Colin Watson wrote: > On Sun, Mar 23, 2014 at 02:59:19PM +, Sam Bull wrote: > > Rather a lot of stuff in here, most of them are for apps that are not > > installed. > > http://pastebin.com/2G4H2De4 > > Yes, this looks like the same thing that Sergio reported to me the other > day. I think I'm beginning to get a handle on it and am working through > it now. OK, https://code.launchpad.net/~click-hackers/click/trunk/+merge/212458 should fix this (but not the "click list" crash you mentioned). I'm trying to get that landed soonish so that people can stop having to waste time being horrendously confused by this. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Landing team 21.03.2014
On Tue, Mar 25, 2014 at 09:34:10PM +, Sam Bull wrote: > On lun, 2014-03-24 at 13:45 +0000, Colin Watson wrote: > > On Sun, Mar 23, 2014 at 02:59:19PM +, Sam Bull wrote: > > > On dim, 2014-03-23 at 10:04 -0300, Sergio Schvezov wrote: > > > > The installed version can be checked by running > > > > click list | grep music > > > > > > So, this appears to fail due to a webapp I uninstalled months ago. > > > http://pastebin.com/bg5PXa30 > > > > Could you file a bug on the click package in Ubuntu about that, please? > > It shouldn't crash on this. > > Alright, done. > https://bugs.launchpad.net/ubuntu/+source/click/+bug/1297519 Thanks, will look as soon as I can. > Do you think this has something to do with the click packages not > running? It'd be really nice to get the other half of my apps running > again. No, I just landed the fix for that. It'll be in the next image. https://launchpad.net/ubuntu/+source/click/0.4.20 -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Landing team 27.03.14
On Thu, Mar 27, 2014 at 06:22:05PM +0100, Didier Roche wrote: > Two images produced today with some blockers on the list. We > continue landing as much as possible, knowing that today, we were > low on free slots due to beta freeze. Once it this is lifted, we > should back up to a normal landing speed. This should be back up now; the archive is still frozen in the sense that uploads will land in the unapproved queue, but we no longer have to worry about stepping on the toes of final beta image preparation so we should be able to get things through expeditiously even if they aren't auto-accepted. Please let the release team know if something seems to be stuck and you don't know why. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] Image build infrastructure revamp status
[This is a Foundations/CI project; I haven't posted a status update on it before, but a few people have asked about it in private mail, so it might be helpful to have a public update to refer to.] We've been working on reorganising the infrastructure for the live filesystem parts of our image builds. At the moment there's a single dedicated builder for each architecture that the central image build system (lp:ubuntu-cdimage, running on nusakan.canonical.com) can ask to produce various live filesystems; ubuntu-cdimage then fetches the results from it, performs some final polishing steps (for ISO images, this involves building a pool of .debs among other things, so is a fairly complex procedure requiring debian-cd and a local mirror; for phone images it's relatively simple), and publishes the output on cdimage.ubuntu.com. In the case of phone images, system-image then steps in to turn these into the system-image format and compute deltas etc. This is serviceable for what we're doing with it right now, but there are a few motivations for improving things which have been on the wishlist for some time: * It's not at all horizontally scalable. We notice this most around milestone releases when we try to do lots of image builds at once, and we can only do one at a time per architecture. This is basically why respin cycles for milestones take eight hours or whatever ridiculous amount it is. * We can't sensibly extend this to experimental builds. * To a first approximation, ubuntu-cdimage has only been deployed once (although I rewrote it a while back, and one of the goals of the rewrite was to make deployment easier). We discussed this at the release engineering sprint last year, and the general consensus was that we should move live filesystem building into Launchpad. This has a number of advantages: both build farms are normally well within capacity except for occasional bursts that tend to be at complementary times; we would be able to run many more image builds at once and thus drastically reduce the time required for a full respin; it would be much easier to monitor builds in progress; builds will be cancellable without sysadmin intervention; and we'll get one or two extra builders on most architectures by merging the build farms, at least where the hardware in use is new enough to make that worthwhile. I've been working on this on and off for a while, and essentially full-time since 14.04 released. The current status is as follows: * The launchpad-buildd package in production already has most of the code required to build live filesystems; this was done towards the end of last year. More recent testing uncovered a few small but critical problems with this code with various real-world image types (buggy handling of symlinks and of duplicate files in build output); one fix is in trunk and the other is awaiting review. * The bulk of the required changes to Launchpad itself have been through one review pass and are awaiting re-review. The required extensions to the web UI are still only on my local disk, as I have a few more tests to write first, but I expect to finish that in the first half of the coming week. * I have a local installation that is capable of building full live filesystem images, tested with both Ubuntu Desktop and Ubuntu Touch (i386). * I have a local ubuntu-cdimage branch that can request live filesystem builds from a local Launchpad instance and wait for them to complete. It cannot yet download the results. There's still a fair bit to do, but my aim is to have this landed and in production in time for the core sprint in Malta in the last week of May. The engineers developing the CI Airline need to be able to build live filesystems against PPAs as a component of their work, and so I've been in discussions with them to make sure that we will be able to use the same software for this, and where possible the same infrastructure, rather than duplicating work. In anticipation of this requirement, the database modelling for live filesystems in Launchpad includes the facility to associate a build with a PPA, although the pieces required to pass that through to the sources.list used to construct the live filesystem aren't quite in place yet. The CI Airline will need its own cut-down ubuntu-cdimage and system-image instances, and I'll be working with Paul Larson early this week to get the ubuntu-cdimage part of that up and running; phone image builds are simple enough from this point of view that I don't expect that to be difficult. Although I can't speak for system-image, I think we are well on course to have all the rest of this either done before Malta or easy to finish off there. Cheers, -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : u
Re: [Ubuntu-phone] Image build infrastructure revamp status
On Sun, May 11, 2014 at 06:46:04PM -0400, Stéphane Graber wrote: > I'm mostly off until Malta, only around this Friday and Monday-Tuesday > of next week (16, 19 and 20th of May) so if you have cdimage setup by > then, it's possible I can help setting things up for system-image > builds, if you need more time, then it's just a matter of sitting > together with Paul in Malta and getting the remaining bits sorted out (I > expect we'll need some minor tweaks to the code but nothing too scary). Thanks. Folks on the call sounded like they at least had enough to get started, so we'll see how it goes. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Renaming to: Ubuntu App Launch
On Thu, May 22, 2014 at 11:13:50AM -0500, Ted Gould wrote: > We've discussed it before and I've got a MR ready for UAL to make the > naming change so that we're ready to move away from Upstart as our Init > system. I'd like to work with folks on running sed through their code > and landing this change next week. If you've got a test script or > something that is dependent on the name "upstart-app-launch" please be > prepared to change. In theory, we should be able to do it in one silo > and folks shouldn't notice, I'm just worried about dependencies that are > external to debs or not mentioned. If you have a dependency that you > know of that I'm unlikely to find, please mention it. click uses upstart-app-pid optionally to assist with its garbage-collection of unused packages; you might miss this because it only Recommends: upstart-app-launch-tools and it falls back to mostly-working behaviour if it doesn't find it. Since some people backport click to earlier releases, I'd prefer to make it cope with both old and new names rather than just doing a straight search-and-replace. I'll sort this out and land it independently; hopefully I can manage to do that before you start work on Monday so it won't get in your way. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] Archive management plans for phone RTM
move on
without risk of breaking phone images. We'll have a -proposed pocket
as usual and proposed-migration will operate on it. I'd like
permissions on this distribution to be identical to those in Ubuntu
where possible, but we can discuss details there. There'll be
system-image channels for RTM, probably per-device.
* We don't want to have to maintain RTM series for a long time. The
plan is to move devices to the next stable branch along as soon as
possible. To facilitate this, the usual rule should be that changes
should only go into this distribution after they're already on their
way into mainline Ubuntu (as for SRUs), to make sure that we don't
end up in a situation where developers land changes on the stable
branch but don't quite get round to landing them in mainline.
= FAQ =
Can we use this strategy for other Ubuntu flavours or derivatives?
In theory, maybe. It's very much easier to use this strategy for
phone images, though, because the standard distribution mechanism is
via system-image channels so we don't need to worry about updating
sources.list or arranging for mirroring of the derived archive, etc.
There's also a potentially serious social cost to having lots of
archive branches, and I wouldn't want to do so except for short
durations under tight management; I don't want to see the
Ubuntu-and-flavours development community fracturing unnecessarily.
That said, the raw technology may prove to be useful in other similar
contexts in the future. Ask us after we've had some experience with
running it for RTM ...
What if derived distributions can't be made to work after all?
We fall back to PPAs and keep a really close eye on everything.
Fortunately this is an unlikely scenario, I think, as this will
probably end up being more work.
How will we manage syncing and merging?
The nature of the RTM branch is such that we probably won't need very
much in the way of keeping up to date with Ubuntu. Most changes will
land via the CI engine. That said, there will doubtless be some
things like security updates to core packages that we need to land, so
time permitting I'd like to set up something like merge-o-matic to
keep track of this. If possible, these will be copied via the CI
engine to minimise the risk of unexpected image testing failures.
Will non-Canonical developers be able to take part in this?
The current engine ("CI Train") is visible to non-Canonical
developers, but the use of a spreadsheet, a private Jenkins instance,
and semi-manual organisation of landings makes it difficult to use in
practice. The new engine (sometimes called "CI Airline") is due to
land this month and should be much easier to use without
company-specific privileges. I see no reason why it can't all be
open.
We'll be trying hard to have a common rootfs across customers, but
it's possible that deadlines will force there to be a couple of
patches which land separately for one or the other. Where possible,
though, this kind of thing will be in the device or custom tarball
rather than the main rootfs.
Any other questions?
--
Colin Watson [cjwat...@ubuntu.com]
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Archive management plans for phone RTM
I got the ubuntu-phone list's address wrong in my original post. I've bounced the original message to the correct address, but please make sure to replace ubuntu-ph...@lists.ubuntu.com with ubuntu-phone@lists.launchpad.net when following up. Sorry about that. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Archive management plans for phone RTM
On Wed, Jun 04, 2014 at 04:54:03PM -0400, Scott Kitterman wrote: > How will uploads to this new derived distribution get back into > Ubuntu? I think I said something about this in my original mail, but I want to set a rule that nothing gets into the derived distribution without being in Ubuntu first (even if not completely landed, they should at least be in the process, e.g. in -proposed), so it's purely a stabilisation branch without new work of its own. I had considerable support from relevant managers last week for this being a general rule, although the people doing the direct customer engagement note that there may be some urgent cases where it won't work out. As far as I can tell we should be able to make sure that those are exceptions rather than the rule. When the branch closes, I intend to check through it to ensure that everything has landed in Ubuntu. If the archive permissions all match up, then it should be OK to copy source+binaries back on the grounds that the same set of people were allowed to upload and review it; otherwise, a few manually-checked source uploads shouldn't be a big deal. Canonical is, as far as I can make out, strongly committed to making sure that it's possible to continue rolling production phones forward to newer versions without having to maintain lots of long-lived per-customer branches, which implies making sure that everything in stable branches also lands in mainline. That makes me confident that this won't be forgotten even if I get hit by a bus or something. > Will uploads to this new derived distribution be limited to Ubuntu > developers? If not, how is this being controlled? I would very much like the permissions on the derived distribution to be set to exactly match those on Ubuntu, and the permissions on the derived series to exactly match those on utopic, so that there's no uncertainty about whether it's safe to copy packages back and forward. It's not meant to be a laxer version of the primary archive, but if anything err in the opposite direction. Most landings will be taking place using the CI engine, so the same issues apply as in the recent conversation on ubuntu-devel. I expect that by that point we will be using the ground-up rewrite of the engine that's currently in preparation, and hopefully the task to ensure that all uploads have some kind of review from somebody with LP Archive.checkUpload() permission on the package will be completed by then, at which point there should be no awkward grey areas. That said, if that task isn't done, or if the CI work slips so that we're still using the current "CI Train" engine by then, it's no worse than the situation today. We'll presumably also need some version of the IRC notifications that #ubuntu-release currently gets on queue and image events. I have no very strong opinion on whether those should be on #ubuntu-release to keep everything consolidated (especially if the permissions are set to match so that the same people have access to handle them), or whether that's too much noise that many of the denizens there don't care about. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Archive management plans for phone RTM
On Thu, Jun 05, 2014 at 12:10:25AM +0100, Dimitri John Ledkov wrote: > On 4 June 2014 21:20, Colin Watson wrote: > > Any other questions? > > Will PPAs be enabled on the derivative distribution, such that if I > wish/need I can build packages in the PPA against the RTM suite. Yes, there's no particular reason not to, and they'll have to be in order for the CI engine to work. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Archive management plans for phone RTM
On Wed, Jun 04, 2014 at 06:27:36PM -0700, Alex Chiang wrote: > On Wed, Jun 4, 2014 at 1:20 PM, Colin Watson wrote: > > Can we use this strategy for other Ubuntu flavours or derivatives? > > > > In theory, maybe. It's very much easier to use this strategy for > > phone images, though, because the standard distribution mechanism is > > via system-image channels so we don't need to worry about updating > > sources.list or arranging for mirroring of the derived archive, etc. > > There's also a potentially serious social cost to having lots of > > archive branches, and I wouldn't want to do so except for short > > durations under tight management; I don't want to see the > > Ubuntu-and-flavours development community fracturing unnecessarily. > > Will this mechanism be able to support an arbitrary number of > commercial downstream flavors? My assumption here is that a commercial > downstream will branch off RTM itself, forming RTM'. Possibly, but it's rather heavyweight and I don't know how well it would scale to lots of them, so I'd prefer not to do too many like that at the moment. Just layering a PPA on top should do for most such cases and makes it easier to keep the downstreams up to date, which I gather we probably want to do anyway. With suitable use of apt pinning during image building we could even provide a simple mechanism for downstreams to elect to hold back a given package, without them having to micromanage everything. > I assume the "probably per-device" channel mechanism could be used here? Right, but you do need an archive or combination of archives to build an image from. > Will there be some mechanism to recreate the archive at the RTM or > RTM' branch point? I am thinking of a factory hotfix nightmare where > access to the exact source / package versions will be critical in > debugging the issue. I think we could use most of the same script that we'll need to use to do the initial branching to recover the RTM branchpoint and republish it somewhere else; we just need to keep the manifest or datestamp or whatever. Similarly the same kind of thing would work on a slightly different axis for what you're calling the RTM' branchpoint, if suitably parameterised. Once it's written I'd been planning to put the script in lp:ubuntu-archive-tools for convenient access. (I suppose it would also be possible to create artificial branchpoint series to act as tags, but I think that's overkill; that could end up being a significantly larger set of binaries to keep live on the publishing system when we really just need to be able to republish them as a contingency plan.) We should think about when to mark the rtm-14.09 (or whatever) series as "Current Stable Release" in LP, since that would provide a simple GA kind of tag without much effort, and everything after it could go into rtm-14.09-updates. > We can make the nightmare worse by imagining that it inexplicably > occurs 6 months after initial shipment. For Ubuntu this is fine because we don't garbage-collect pre-release binaries from development series until well after the point anyone is going to care about them. For RTM I'd need to check what the GC policy would be. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Archive management plans for phone RTM
On Thu, Jun 05, 2014 at 12:00:23AM -0400, Scott Kitterman wrote: > Personally, I'm fine with it being in #ubuntu-release. I think we're already > much too fragmented and people are too comfortable in their own corner of the > project. Thanks for the feedback. That was my inclination too, but I have a somewhat different perspective as I expect to be processing a bunch of the queue events regardless of where they end up, so didn't want to prejudge anyone else. > As you know from previous mails, I'm very troubled by the current CI train > situation with respect to permissions. I believe it is completely > inconsistent with our governance processes and represents, at best, an > unknown > from a security perspective. No worse than the situation today is no comfort > for me (and yes, I know it's the same either way, but I think this is a > critical infrastructure issue - the only reason this isn't a Tech Board item > right now is it's already on the way to being resolved). I generally agree with your concerns about making sure that the archive permission model actually means something. For the time being I'm happy that a resolution is on its way, but I do intend to keep track of this. (I was glad to see one relevant upstream developer being prompted by the earlier conversation on ubuntu-devel into applying for PPU; that seems like something to encourage.) Regardless of how important I think it is, though, I just don't think it's *relevant* to the RTM plans, as it's independent in a mathematical sense. It makes no difference whether Ubuntu archive permissions are being worked around in the primary archive or exactly the same way in a derived archive with identical permissions, and so I would prefer not to complicate things by tying the two jobs together; they're each tractable in isolation, but I'd be concerned about the risk of requiring that we do both before the RTM date. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] [Launchpad-dev] Archive management plans for phone RTM
On Mon, Jun 09, 2014 at 08:02:24AM -0500, Ted Gould wrote: >I know that Apport has some checks to see if packages are in the archive >or not, and treat them differently based on that. Will this effect Apport >adversely? If so, can we make sure to have a work item to train Apport to >handle the derived distributions intelligently? Good call, thanks. I've added a work item to https://blueprints.launchpad.net/ubuntu/+spec/development-1406-rtm-archive (which I just created) to make sure we remember this. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Archive management plans for phone RTM
On Tue, Jun 10, 2014 at 06:31:02PM -0700, Robert Park wrote: > On Wed, Jun 4, 2014 at 1:20 PM, Colin Watson wrote: > > * CI and Foundations team members will spend the next two months making > >sure that all the tools we need are in place. This includes fixing > >up derived distributions, preparing an initialisation script, making > >sure that the CI engine (train or airline, as appropriate) can handle > >building for a derived distribution, and adding support for > >ubuntu-touch image builds from derived distributions. > > What will be involved in bringing CI Train up to speed for derived > distributions? Currently CI Train is able to do releases targeted at a > "series" (trusty, utopic), or arbitrary PPAs. It'll still be a series, just not a series of Ubuntu. All it needs is the ability to target series of a different distribution. This will involve: * replacing the "/ubuntu/" part of ppa.launchpad.net URLs * parameterising the various places that the "ubuntu" distribution is hardcoded in cupstream2distro/launchpadmanager.py * adding "distribution" options anywhere we currently have "series" options * possibly adjusting anything that uses pbuilder or similar to use a different archive mirror URL You can look at the various tools in lp:ubuntu-archive-tools for a model: pretty much all of those take -d/--distribution options as well as -s/--series (or -s/--suite). > The PPA option would have been a lot easier from a CI Train > perspective, requiring no code changes on our end. In some ways it would have been a simpler option, but the lack of isolation from the parent distribution is really a killer. PPAs weren't designed to support this kind of entirely-independent use. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Archive management plans for phone RTM
On Wed, Jun 11, 2014 at 09:01:23AM +0200, Didier Roche wrote: > Le 11/06/2014 05:21, Colin Watson a écrit : > > * replacing the "/ubuntu/" part of ppa.launchpad.net URLs > > * parameterising the various places that the "ubuntu" distribution is > >hardcoded in cupstream2distro/launchpadmanager.py > > 1. The only place this needs to be changed is at: > def get_ubuntu(): > '''Get the ubuntu distro''' > lp = get_launchpad() > return lp.distributions['ubuntu'] > > All the get_series() and other functions are first calling get_ubuntu(). I think we generally want to change things to pass both distribution name and distroseries name to get_series, too. At least that's my experience of the approach that works well in other tools - the "ubuntu" default can be set in optparse configuration or similar. > 3. Apart from changing the set of ppas to be based on this new > distribution and the destination copy (can we retarget the existing > ones, maybe?), that will be all I think. We'll need to fix https://bugs.launchpad.net/launchpad/+bug/879048 before we know exactly what shape this needs to take. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] New image build infrastructure enabled
A bit later than planned, the new image build infrastructure I described in https://lists.ubuntu.com/archives/ubuntu-devel/2014-May/038267.html is now in production and being used for all new live filesystem builds. Hopefully the main immediate practical effect of this will be that respin cycles for the milestone release this week will be much faster as we'll be able to distribute them out to more builders. There are a couple of features still awaiting deployment, namely builds from -proposed (needed for stable releases) and builds with extra PPAs (needed for the new CI engine). IS has a ticket for this and it should get done this week. This will have the effect of slightly increasing the load on our devirtualised build farm for the time being, because it will be assuming the additional load previously taken by the livefs builders. Fear not: we will shortly be turning the livefs builders into additional Launchpad builders. This will give us a net increase in capacity (especially noticeable on powerpc, I expect), since the livefs builders were not running builds non-stop beforehand. Cheers, -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANN: adb soon (June 30) to be disabled by default
On Mon, Jun 23, 2014 at 09:30:05AM -0300, Sergio Schvezov wrote: > For people (and CI) who would still want this enabled on clean > installations, all you need to do is add a --developer-mode toggle > option to ubuntu-device-flash. Do you know how this will work with dual boot (humpolec)? The approach involving the terminal app would work, I guess, but it would be nice to have something built into the dual boot Android app so that we don't have to fumble with the terminal. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] New image build infrastructure enabled
On Mon, Jun 23, 2014 at 06:15:43PM +0300, Bob Looter wrote: > That is very interesting happening and very cool. > Is the infrastructure of the image deployment going > to be kept in MAAS| Cloud | Ubuntu or Canonical. > This new cloud thing has amazed me a little since > it adds in a lots new possibilities for us all. > Since live image building can be done directly at MAAS with juju. Our builders are currently a static farm rather than horizontally scalable. There's work in progress, independently, to move the virtualised PPA build farm onto an OpenStack cloud; hopefully, we will eventually be able to merge the devirtualised build farm into this too. MAAS may well be somewhere in this stack, although it's several layers removed from anything I'm doing. This is all basically orthogonal to the work to move livefs building into our main build farm though. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANN: adb soon (June 30) to be disabled by default
On Mon, Jun 23, 2014 at 02:54:07PM -0300, Sergio Schvezov wrote: > It's just a flag into the ubuntu_commands to enable in recovery, I > guess if someone pointed me to the sources, I could add a patch. lp:humpolec > That said; people with systems already running should not be hit by > this as it just a change of defaults. Right, but in practice I end up reinstalling a lot :-) -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANNOUNCEMENT: Bileto improvements, Dashboard deprecation
On Thu, Aug 27, 2015 at 10:16:25AM -0700, Robert Park wrote:
> On Aug 27, 2015 9:54 AM, "Rodney Dawes" wrote:
> > One small thing that I think would help a lot, is to have the link to
> > the PPA, have the "/+packages" added to the end of the URL. The main PPA
> > page by itself is pretty much useless, and what I need is to get at the
> > links to download the armhf .debs that were built, or to see build logs,
> > which are all on the +packages page.
>
> Hmmm, I'm not sure about this one. I /just/ went live with a change
> that puts a ton of useful (to me) info in the ppa description field, if i
> make this change as you say then I'd have to click extra to get to what i
> want. Unfortunately the description isn't shown on the other page.
>
> Maybe we could have both links? That might clutter it a bit too much, not
> sure what would be best.
The Archive:+index / Archive:+packages split for PPAs is a bit of a mess
really and needs rethinking (there are several bugs about this), but as
an interim band-aid I think we'd favourably consider a patch which
duplicated the description across both the "user-focused" index and the
"developer-focused" +packages page. Starting points:
lib/lp/soyuz/templates/archive-{index,packages}.pt and
lib/lp/soyuz/browser/archive.py.
--
Colin Watson[cjwat...@canonical.com]
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] s390x to be enabled for landing silos
On Tue, Dec 08, 2015 at 10:01:16AM -0800, Steve Langasek wrote: > Now that the s390x architecture bootstrap for xenial has made some headway, > we will shortly be adding s390x to the list of enabled architectures for the > landing silo ppas. This is now done. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] RTM silo management in CI Train
For the plan to deliver the phone RTM from a derived "ubuntu-rtm"
distribution, we'll need to use a different set of silo PPAs, since PPAs
are attached to a particular distribution (which is clearer now that the
PPA URL format has been changed to include the distribution name).
Although there are a few remaining bits, Launchpad has mostly now been
extended to cope with non-Ubuntu PPAs, and it's time to think about how
we're going to handle this in CI Train.
We probably just want to create another 20 silos for ubuntu-rtm once it
exists. The open questions are how to refer to them, and how to arrange
to land things in them. In the remainder of this mail I will refer to
PPAs consistently using their new ~OWNER/DISTRIBUTION/NAME scheme in an
attempt to minimise confusion.
Note that Didier indicated in
https://lists.ubuntu.com/archives/ubuntu-release/2014-June/002898.html
that he thought the changes to cupstream2distro itself would be pretty
straightforward. I agree, for what it's worth.
* Names? The current scheme is
~ci-train-ppa-service/ubuntu/landing-{000..020}, with 000 being a
test silo. We could use
~ci-train-ppa-service/ubuntu-rtm/landing-{021..040} to avoid having
to invent a new naming scheme. However, this is sort of non-obvious
to the uninitiated, it doesn't give us a nice space for a test silo,
and it cuts off further expansion of the ubuntu silos in case we need
that. Could we use
~ci-train-ppa-service/ubuntu-rtm/landing-{000..020}? Launchpad will
permit this (PPAs are unique up to owner/distribution/name), so the
only question is whether this is clear enough.
* How do we refer to these informally? Right now people say "silo 1"
etc. Perhaps "silo RTM-1"? I think it ought to be made clear when
you're landing something in the more tightly-controlled RTM archive.
* How will we handle this in the spreadsheet? My only thought so far
is that we should have a column for whether you're targeting RTM or
not. But I guess at the moment we have a destination series in the
"Assign to silo" menu entry, which is used for trusty builds - I
guess maybe that could be extended to include a distribution? Seems
a bit easy to make a mistake that way though.
* Presumably the backend and the dashboard would both need to be
extended. I'm not familiar with the details here and would welcome
commentary from those who are.
* Anything else?
Thanks,
--
Colin Watson [cjwat...@ubuntu.com]
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] RTM silo management in CI Train
On Wed, Jul 16, 2014 at 02:55:42PM -0400, Rodney Dawes wrote: > On Tue, 2014-07-15 at 17:54 +0100, Colin Watson wrote: > > * Anything else? > > Will all landings in ubuntu-rtm also be copied to the ubuntu archive? If > not, when will the disparity begin, and how will it be managed going > forward? I expect us to attempt to enforce a rule that everything landing in ubuntu-rtm must first have landed in ubuntu, much like SRU rules. I proposed this to management in Malta and there was general agreement that in most cases this would be workable. There will no doubt be a few exceptions due to deadline pressure, but hopefully few enough that we can keep a list manually in the landing team. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] RTM archive update; branch management for upstreams
This is a follow-up to previous threads; please read those first: https://lists.launchpad.net/ubuntu-phone/msg08410.html https://lists.launchpad.net/ubuntu-phone/msg09051.html = What's happened so far? = We've been very busy over the last few weeks implementing the archive management plan for RTM. Last week we performed a successful dry-run of the distribution branch procedure on Launchpad's "dogfood" instance (which we use for QA of the upload, build, and publish subsystems); of course we found and fixed a few bugs along the way, but overall it was quite smooth. We have a dashboard in place (http://ci.ubuntu.com/smokeng/utopic/touch_stable/), which looks plausible with the exception of a few failures that indicate missing packages in the branch. The remaining thing to finish here is completing the dry-run of CI Train against RTM (Łukasz is working on this). After that we can consider the dry-run complete. Exactly when we branch is still a matter of some debate. The competing pressures are that we need to branch early enough that we have time to shake out bugs in the new infrastructure, but late enough that engineers are spending a minimum of time on extra landing effort. Furthermore, I'm on vacation from 13-18 August, and while I have a backup, it would really be better for me to be around if possible to make sure things aren't exploding. That suggests a provisional branch date of the week of 4-8 August. If this is a problem, please give detailed reasons. = How will branching work for upstreams? = The archive branch will be cut from the point in the Ubuntu archive's overall history corresponding to the most recent promoted image. This will result in https://launchpad.net/ubuntu-rtm/14.09 or similar, and I'll send a report with the full list of initial source package versions. We don't have a central way to make branches of all upstream projects involved. It's also not really necessary to do so; it's fine for upstreams to make a branch when they first need to land something for RTM. You'd take the version of the package in question in the RTM archive, then branch from the corresponding tag, push, and create a new project series in Launchpad so that something like lp:yourproject/rtm-14.09 works (the exact name isn't very important, but it probably ought to contain "rtm" and "14.09" somewhere). You'll then tell the landing team which branch you want to land any given silo on; ideally that will be in the spreadsheet, but if not we'll at least be able to select it manually. In general you will be required to land things for devel-proposed before attempting to land them for stable-proposed, in order that we don't lose changes (bearing in mind that we'll want to move on to a new branch a few months down the line). There will no doubt be the occasional deadline-driven exception, but the exceptions should not be common practice. Thanks, -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] RTM branch
(TL;DR: The RTM derived distribution is branched, but don't panic. We'll be running some test landings, and will be asking for some cooperation from EMs on this, but the full work of maintaining a branch will only kick in on 19 August. See below for details.) We have created the initial branch for Ubuntu RTM, which is finishing publishing now: https://launchpad.net/ubuntu-rtm/14.09 http://derived.archive.canonical.com/ubuntu-rtm/ This was branched from the point in the archive history corresponding to devel-proposed image #178. I know I said we should use a promoted image, but the landing team tell me that #178 is very close to being good with the main exception being a problem affecting the calendar app, and given that I'd rather have something that's quite recent. We have a few more things on the list: I haven't yet dealt with setting up image builds and the like, for instance, but that will be done shortly. I've attached a list of the source package names and versions that were copied. Changes made in ubuntu-rtm between 2014-08-08 and 2014-08-19 will probably not be persistent. The plan at this point is: 2014-08-08: set up infrastructure, branch 2014-08-11 - 2014-08-18: exercise infrastructure by selecting some test landings on devel-proposed to reland on the RTM branch, aiming to get good coverage of upstream teams so that everyone's comfortable and so that we get good feedback 2014-08-19: (my first day back from vacation) bulk-update ubuntu-rtm/14.09 from the point in the archive corresponding to the latest promoted image 2014-08-20 - 2014-08-28: for new devel-proposed landings that are required for RTM, reland them on the RTM branch in coordination with the landing team The point of this approach is to make sure that we're completely confident in the infrastructure and have no unforeseen glitches, without imposing an undue load on engineering teams while lots of people are still busy with significant feature development. The bulk-update step relies on there being no cases where Ubuntu and Ubuntu RTM have source or binary packages with the same versions but different contents. Any landings through CI Train will straightforwardly satisfy this by virtue of the fact that the distroseries version number is different (this is a hack, but I'll take it). For now, I would recommend not attempting to upload anything directly to 14.09 without first double-checking with the landing team. Thanks to all involved in getting this set up, particularly William Grant and IS. Cheers, -- Colin Watson [cjwat...@ubuntu.com] a52dec 0.7.4-17 aalib 1.4p5-43 abootimg0.6-1 account-plugins 0.11+14.04.20140409.1-0ubuntu1 account-polld 0.1+14.10.20140806.1-0ubuntu1 accounts-qml-module 0.4+14.10.20140528-0ubuntu1 accountsservice 0.6.37-1ubuntu8 acl 2.2.52-1 address-book-app0.2+14.10.20140806-0ubuntu1 address-book-service0.1.1+14.10.20140804-0ubuntu1 adduser 3.113+nmu3ubuntu3 advancecomp 1.19-1 akonadi 1.12.91-0ubuntu1 alsa-driver 1.0.25+dfsg-0ubuntu4 alsa-lib1.0.28-1 alsa-plugins1.0.28-1ubuntu1 alsa-utils 1.0.28-1ubuntu1 android 20140805-0353-0ubuntu3 android-headers 4.4.2-2-0ubuntu1 android-src-vendor 7-0ubuntu1 android-tools 4.2.2+git20130218-3ubuntu26 ant 1.9.4-1 ant-contrib 1.0~b3+svn177-6 anthy 9100h-23ubuntu2 antlr 2.7.7+dfsg-5 apache-log4j1.2 1.2.17-4ubuntu3 apache-pom 10-2build1 apache2 2.4.10-1ubuntu1 apg 2.2.3.dfsg.1-2ubuntu1 apparmor2.8.96~2541-0ubuntu2 apparmor-easyprof-ubuntu1.2.15 appconfig 1.66-1 appdata-tools 0.1.7-3 apport 2.14.5-0ubuntu3 apr 1.5.1-2 apr-util1.5.3-2 apt 1.0.4ubuntu6 asciidoc8.6.9-2ubuntu1 asm33.3.2-2 aspell 0.60.7~20110707-1ubuntu1 aspell-en 7.1-0-1 astroid 1.1.1-1 astyle 2.03-1.2 at 3.1.14-1ubuntu2 at-spi2-atk 2.10.2-3ubuntu1 at-spi2-core2.10.2.is.2.10.1-0ubuntu1 atk1.0 2.12.0-1ubuntu1 atkmm1.62.22.7-2ubuntu1 attica 0.4.2-1 attr1:2.4.47-1ubuntu1 auctex 11.87-1ubuntu2 audiofile 0.3.6-2 audit 1:2.3.2-2ubuntu1 augeas 1.2.0-0ubuntu2 autoconf2.69-7 autoconf2.132.13-63 autoconf2.642.64-3 autogen 1:5.18.3-5ubuntu1 automake-1.14 1:1.14.1-3ubuntu1 automake1.111:1.11.6-2 automake1.9 1.9.6+nogfdl-4ubuntu1 automoc 1.0~version-0.9.88-5build1 autopilot 1.5.0+14.10.20140806.1-0ubuntu1 autopilot-gtk 1.4+14.10.20140526-0ubuntu1 autopilot-legacy1.4.1+14.10.20140430-0ubuntu4 autopilot-qt1.4+14.10.20140724.1-0ubuntu3 autotools-dev 20140510.1 avahi 0.6.31-4ubuntu3 avalon-framework4.2.0-9 bamf0.5.1+14.04.20140409-0ubuntu1 base-files 7.2ubuntu6 base-passwd 3.5.33 bash4.3-8ubuntu1 bash-completion 1:2.1-4 batik 1.7.ubuntu-8ubuntu2 bc 1.06.95-9 bcel5.2-10 bdfresize 1.5-8 bind9 1:
Re: [Ubuntu-phone] Landing team 08.08.14
On Sat, Aug 09, 2014 at 08:15:05AM -0700, Steve Langasek wrote: > On Sat, Aug 09, 2014 at 12:21:56AM +0200, Łukasz 'sil2100' Zemczak wrote: > > #179 > > - http://people.canonical.com/~lzemczak/landing-team/179.commitlog > > Since the ubuntu-rtm archive has been branched from 178 rather than 179, it > seems to me that we would want to get all of the changes from the > actually-promoted 179 into 178 as a group. Is this something that we should > do with direct uploads to the ubuntu-rtm archive, or should these changes go > through a silo for re-testing? Given that the plan is to bulk-update the RTM archive on the 19th anyway, it seems prudent to me to test out that process with a small and thus easily auditable set of changes. I'll therefore update the archive to #179 by way of direct copies on Monday morning, and we can then see about doing some test runs of CI Train after that's completed. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Landing team 08.08.14
On Sat, Aug 09, 2014 at 10:43:03PM +0100, Colin Watson wrote: > On Sat, Aug 09, 2014 at 08:15:05AM -0700, Steve Langasek wrote: > > On Sat, Aug 09, 2014 at 12:21:56AM +0200, Łukasz 'sil2100' Zemczak wrote: > > > #179 > > > - http://people.canonical.com/~lzemczak/landing-team/179.commitlog > > > > Since the ubuntu-rtm archive has been branched from 178 rather than 179, it > > seems to me that we would want to get all of the changes from the > > actually-promoted 179 into 178 as a group. Is this something that we should > > do with direct uploads to the ubuntu-rtm archive, or should these changes go > > through a silo for re-testing? > > Given that the plan is to bulk-update the RTM archive on the 19th > anyway, it seems prudent to me to test out that process with a small and > thus easily auditable set of changes. I'll therefore update the archive > to #179 by way of direct copies on Monday morning, and we can then see > about doing some test runs of CI Train after that's completed. I've updated to #179 now, copying these packages: apport2.14.5-0ubuntu4 aspell0.60.7~20110707-1.1 autogen 1:5.18.3-6 binutils 2.24.51.20140807-1ubuntu2 busybox 1:1.22.0-8ubuntu1 codespeak-lib 1.4.23-1 crash 7.0.7-1ubuntu1 gnome-vfs 1:2.24.4-6ubuntu1 gnutls28 3.2.16-1ubuntu1 graphite2 1.2.4-3ubuntu1 lapack3.5.0-3 libibverbs1.1.8-1ubuntu1 libprelude1.0.0-11.3ubuntu1 librevenge0.0.1-3 libunity 7.1.4+14.10.20140808-0ubuntu1 libxvmc 2:1.0.8-2ubuntu1 location-service 2.0.1+14.10.20140808-0ubuntu1 ntfs-3g 1:2013.1.13AR.1-2ubuntu3 openldap 2.4.31-1+nmu2ubuntu9 pacemaker 1.1.10+git20130802-4ubuntu2 python-dbusmock 0.11.1-1 qtmir 0.4.1+14.10.20140808-0ubuntu1 qtmir-gles0.4.1+14.10.20140808-0ubuntu1 qtubuntu 0.60+14.10.20140808.1-0ubuntu1 qtubuntu-gles 0.60+14.10.20140808.1-0ubuntu1 rsyslog 7.4.4-1ubuntu7 tcl8.58.5.15-4ubuntu1 telepathy-gabble 0.18.3-0ubuntu2 twm 1:1.0.8-1ubuntu1 unity88.00+14.10.20140808-0ubuntu1 The process for this seems to have gone smoothly. Some uploaders will have got some noisy e-mail about it, as we haven't yet fixed Launchpad to allow us to avoid that; we have an Asana task for that. Although it isn't on these images any more, gnutls26 doesn't actually get to fall out of the ubuntu-rtm distribution yet. As far as I can see, this is because of a chain of packages in the build-dependency closure of the touch-android seed that eventually ends up with libavformat55 -> libgnutls26. Fixing this before 2014-08-19 would be a good idea if at all possible. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANNOUNCEMENT: Landers! CI Train redeployed to support the RTM distribution + more
On Fri, Aug 15, 2014 at 09:23:10AM +0200, Oliver Grawert wrote: > Am Donnerstag, den 14.08.2014, 19:09 -0400 schrieb Pat McGowan: > > Can we select multiple targets for landing, i.e. both utopic and rtm? > > That wouldn't make much sense ... what you land in utopic will propagate > into rtm with the next sync anyway. There's going to be one more mass sync (today or at least this week), and then nothing more. The point of doing this derived distribution thing was to be able to disconnect the RTM from mid-cycle utopic development. Work targeted at RTM will need to be re-landed on ubuntu-rtm/14.09, after it's on track to get into devel. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ANNOUNCEMENT: Landing team - RTM landings now officially open!
Can I request in general that people not spend too much mental energy worrying about how much work this is going to be for now? We have various tools available that can be used to make this more efficient, such as parallel silo assignment or source+binary copies from one distribution into the other (possibly via a silo, so that they can be retested in the alternate context). I'm quite sure that the landing team will learn from the first few attempts here and figure out what makes sense for various situations, but since regrettably only a couple of people took us up on the request to try test landings during the two weeks allocated for this purpose, we do not yet have the experience required to write detailed documentation for all cases. We will therefore now have to work it out on the fly. The main other thing I would request is that people put some thought into the fact that, while the two distributions are at the same level now, they are expected to diverge quite quickly as utopic development continues; this was the point of creating a derived distribution, so that phone development could be isolated from mainline Ubuntu development. Please remember that binaries cannot necessarily be freely copied from one to the other, although in some cases it will of course work fine; expecting that they can be copied in without testing will carry some risks. Hopefully proposed-migration should shield us from the obvious possible mistakes here. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] ubuntu->rtm package sync
On Mon, Aug 25, 2014 at 01:49:36PM -0400, Bill Filler wrote: > >From sil2100's email last week on Aug 21st it said that we have > branched, but it seems the last sync from ubuntu to rtm was done Aug > 19th. This is not accurate; I performed the sync on the 21st. > We had some packages land on the 20th that are not in the RTM > image that I expected to be (ubuntu-keyboard-*) and there may be others. Can you please give me exact package names and versions? > Is it possible to resync so that rtm branches created on the 21st are in > sync with what's in the rtm archive? It should be immaterial when branches were created. The important thing is that you must create RTM branches with an explicit branch point corresponding to the version in the ubuntu-rtm archive. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Landing team 05.09.14
On Fri, Sep 05, 2014 at 11:24:53PM +0200, Łukasz 'sil2100' Zemczak wrote: > ** Can't manually install clicks "Signature verification error" since #205 > https://bugs.launchpad.net/bugs/1360582 > [Time counter 9/7] > => Merge requests present > -> Landing reverted. But real fixes are ready. This is in ~ci-train-ppa-service/ubuntu/landing-003 and ~ci-train-ppa-service/ubuntu-rtm/landing-003 now. With luck we'll be able to get it developer-tested and QA-validated soon. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Image #236 broke device flashing
On Thu, Sep 11, 2014 at 08:03:26PM -0500, Victor Thompson wrote: > Additionally, my device (mako) keeps prompting me to update the same 4 > apps Click package installation was broken in #236 and #237, which may account for that part of it. It's fixed in #238. https://bugs.launchpad.net/bugs/1368246 -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Landing team 11.09.14
On Thu, Sep 11, 2014 at 09:42:24PM +0200, Łukasz 'sil2100' Zemczak wrote: > ** Can't manually install clicks "Signature verification error" since #205 > https://bugs.launchpad.net/bugs/1360582 > [Time counter 13/7] > => Merge requests present > -> Landing reverted. Packagekit changes landed, now only UITK changes > need to happen. This was fixed in #235 and ubuntu-rtm #27, so I think you can take it off your list. > ** upstart can race with cgmanager when using remove-on-empty > https://bugs.launchpad.net/bugs/1357252 > => Merge requests present > -> We have been told to only whitelist this for one promotion, so now > it's a blocker. Currently the archive has the u-a-l revert (no cgroups > support), but it seems to be a crucial feature. I think this might be fixed on the upstart side now? Commented on the bug. That said, the ubuntu-app-launch changes do not appear to have been reintroduced yet. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] error in ppa and sbuild
On Tue, Sep 30, 2014 at 10:17:47AM +0630, Ko Ko Ye` wrote: > https://launchpadlibrarian.net/186098513/buildlog_ubuntu-trusty-armhf.ubuntu-keyboard_0.99.trunk.phablet2%2B14.04.20140415-0ubuntu3_FAILEDTOBUILD.txt.gz I suspect that this is just in the category of things that won't work under qemu, so won't be buildable for non-x86 architectures on virtualised builders. There isn't very much we can do about this until we get real hardware in place that can do ARM virtualisation, and upgrade the OpenStack cloud used for the builders to support this. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Landing team 08.10.14
On Thu, Oct 09, 2014 at 11:05:32AM +0200, Oliver Grawert wrote: > Am Mittwoch, den 08.10.2014, 16:38 -0700 schrieb Steve Langasek: > > On Wed, Oct 08, 2014 at 08:47:35PM +0200, Łukasz 'sil2100' Zemczak wrote: > > > The only problem is that we seem to be having some problems with the > > > system-image server. Because of this some of our newly built images are > > > not yet available for usage... The issues are now being investigated. > > > > We believe this issue is now resolved, and images are successfully being > > published to the system-image server. > > while this was true for images that are already sitting on nusakan (the > build machine) it does not import any new ones at all anymore > http://paste.ubuntu.com/8525648/ has the output of a -c run i just > did ... This is due to: https://docs.python.org/3/whatsnew/3.0.html#ordering-comparisons Since this evidently requires some additional porting work, and since the images that contained non-ASCII file names have presumably all been processed by now (this may not be a safe assumption ...), I've cowboyed import-images back to /usr/bin/python for the time being so that it can proceed. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
[Ubuntu-phone] Help needed with protobuf transition
There's a new version of protobuf in vivid-proposed, which now ships the binary package libprotobuf9 rather than libprotobuf8. I'm organising most of the required rebuilds (http://people.canonical.com/~ubuntu-archive/transitions/html/protobuf.html), but there are two source packages that are normally handled by CI Train: compiz mir (The transition page lists telephony-service and unity-system-compositor as well, but these only have indirect dependencies on the relevant library packages so can be ignored for this purpose.) Should I just rebuild these directly in vivid-proposed, or could somebody organise a silo with no-change rebuilds for these? I don't currently have a working device where I could do any useful testing myself, and since I have 7.5 working days remaining before I move to Launchpad development it's probably not a sensible use of my time to get that going again. I realise that a silo will require waiting until CI Train is operational. Note that this includes a proper fix for https://bugs.launchpad.net/ubuntu/+source/protobuf/+bug/1275826, which previously caused problems. It may be reasonable to amend the workaround in ubuntuone-storage-protocol. Note further that this only affects vivid, and not ubuntu-rtm/14.09. The most recent versions of compiz and mir in vivid were built for vivid and not copied to or from ubuntu-rtm/14.09, so this shouldn't get in anyone's way in terms of binary compatibility. Thanks, -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Help needed with protobuf transition
On Thu, Dec 04, 2014 at 06:54:02AM -0500, Stephen M. Webb wrote: > For Compiz, I'll be organizing a landing today (if possible) for other > reasons. Thanks. That will automatically build with libprotobuf9, but it won't be possible to merge-and-clean it unless mir has been rebuilt as well, so perhaps it would be best to just include a mir rebuild in the same silo? -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Help needed with protobuf transition
On Thu, Dec 04, 2014 at 04:00:00PM +, Alan Griffiths wrote: > On 04/12/14 13:18, Stephen M. Webb wrote: > > If ci-train is going to be down for any length of time, it would > > probably be better to just do a no-change upload and we'll pick it > > up for the next landing when ci-train comes back. That would > > minimize delays in the queue and we're used to that with Compiz. I > > can't speak for the Mir guys though. > > assuming Mir compiles and passes the automated tests with the new > protobuf (which I'd expect) a no-change rebuild will be fine will be > fine. OK, thanks to you both. Uploaded: https://launchpad.net/ubuntu/+source/compiz/1:0.9.12.0+15.04.20141120-0ubuntu2 https://launchpad.net/ubuntu/+source/mir/0.9.0+15.04.20141125-0ubuntu2 -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
Re: [Ubuntu-phone] Ubuntu at MWC in Barcelona
On Tue, Feb 28, 2017 at 10:28:37AM +0100, Mathijs Veen wrote: > For histories sake, i would be very interested to know whether or not > it was already decided in 2013 at the launch of the first ubuntu touch > image that .click was going to be a temporary thing. Not as far as I know. -- Colin Watson [cjwat...@ubuntu.com] -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
