ubuntu-appstore-developers team mailing list archive

[Ted Gould <ted@xxxxxxxxxxxxx>]

Unfortunately I think we duplicated work :-/  I added approximately the
same hook to upstart-app-launch today, and it is here:

https://code.launchpad.net/~ted/upstart-app-launch/click-hook/+merge/176525

Also, that was most of the code needed to complete the click-exec
functionality so that works with this branch:

https://code.launchpad.net/~ted/upstart-app-launch/click-exec/+merge/176570

Which means for the exciting among you, you can grab that last branch
and start click packages.  At least it'll execute (the app I have just
makes a full screen window and complains it has a bad path for it's
assets because they're not in file://buildd/ )  In theory, it all works
though :-)

Hopefully those can get reviewed tomorrow and will get released by the
autorelease system tomorrow evening.

Ted


On Wed, 2013-07-24 at 00:01 +0100, Colin Watson wrote:

> [Initially sent to ubuntu-appstore-devel instead of
> ubuntu-appstore-developers.  Apparently typing is hard.]
> 
> I uploaded click 0.2.2 earlier this evening, and later 0.2.3.  Between
> them, these uploads fix a few bugs that Steve Beattie and I noticed
> between us while working on hooks, but more importantly they add a
> user-level hook to create desktop files.  With this, you can install
> Click packages and appropriate desktop files will be created in
> ~/.local/share/applications/, like this:
> 
>   $ pkcon -p install-local research/click_packages/com.ubuntu.calendar_0.4_all.click
>   Transaction:    Simulating install
>   Status:         Waiting in queue
>   Status:         Starting
>   Status:         Running
>   Transaction:    Installing files
>   Status:         Waiting in queue
>   Status:         Waiting for authentication
>   Status:         Waiting in queue
>   Status:         Starting
>   Status:         Running
>   Results:
>   Installed    com.ubuntu.calendar-0.4
> 
>   $ cat ~/.local/share/applications/com.ubuntu.calendar_calendar_0.4.desktop
>   # Generated by "click desktophook"; changes here will be overwritten.
>   [Desktop Entry]
>   Encoding = UTF-8
>   Version = 1.0
>   Type = Application
>   Terminal = false
>   Exec = aa-exec -p com.ubuntu.calendar_calendar_0.4 qmlscene calendar.qml
>   Icon = calendar64.png
>   Name = Calendar
>   X-Ubuntu-Touch = true
>   X-Ubuntu-StageHint = SideStage
>   X-Ubuntu-Gettext-Domain = calendar-app
> 
>   Path = /opt/click.ubuntu.com/com.ubuntu.calendar/0.4
> 
> As you can see:
> 
>  * The Exec entry is mangled to apply the AppArmor profile, which will
>    be "unconfined" if there is no apparmor hook defined in the app (I
>    plan to restrict this somehow, but from previous discussions the
>    security team appears happy for this to be handled by manual review
>    at least for the moment).
> 
>  * A Path entry is inserted so that the app runs with its current
>    directory set to the package unpack directory.  This should allow
>    most uses of relative paths to behave reasonably.
> 
> This will not work sensibly if the AppArmor hook isn't run, so I hope
> Steve manages to get that landed tonight!
> 
> The result of this may well be that the core apps preinstalled in the
> image as Click packages start taking precedence in the apps
> scope/whatever-it-is over those preinstalled as .debs, or possibly that
> we get both .deb and Click variants.  Autopilot may well have no idea
> how to test the Click versions, and there could be other odd
> side-effects.  I've therefore disabled Click package installation in
> tomorrow's images (CCing Oliver and Sergio FYI) as a precautionary
> measure.  That shouldn't be a regression since as far as I know the
> packages preinstalled that way weren't actually used for anything up to
> now; they were just for testing.  We can reasonably test behaviour
> related to Click packages just by installing them post-boot for the
> moment.
> 
> -- 
> Colin Watson                                       [cjwatson@xxxxxxxxxx]
>

Attachment: signature.asc
Description: This is a digitally signed message part