From gustavo.niemeyer at canonical.com Wed May 18 22:25:44 2016 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Wed, 18 May 2016 19:25:44 -0300 Subject: Mailing lists merging In-Reply-To: References: Message-ID: The transition is now complete. Welcome to snapcraft at lists.ubuntu.com! On Mon, May 16, 2016 at 2:59 PM, Gustavo Niemeyer < gustavo.niemeyer at canonical.com> wrote: > Hello snapcrafters, > > We just had a great design sprint in Vancouver last week, discussing the > so many new ideas that will be landing in the next few months. We'll be > slowly covering those in the coming weeks. > > As part of these conversations, we also talked about the fact we have two > mailing lists today, snappy-devel and snappy-app-devel, which have > cross-over content and audiences. > > We decided to fix that by moving both of them into a single one: > snapcraft at lists.ubuntu.com > > Messages sent to the old lists will be properly redirected to the new > location, and the members of both will be moved over to the new one > automatically. > > This will be happening imminently, so your categorization filters will > need some tweaking soon. > > > gustavo @ http://niemeyer.net > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.long at haloprivacy.com Thu May 19 19:54:52 2016 From: kevin.long at haloprivacy.com (Kevin Long) Date: Thu, 19 May 2016 19:54:52 +0000 Subject: Can your run a private "store" for snappy apps? Message-ID: <3493B6AA-1C01-480C-BC12-6D2809BB11EF@haloprivacy.com> Greetings, first post to the list ! With the snappy/core model , can one configure devices running snappy to only connect to a private store , which would only contain snaps which I have put into that private store? I am researching to choose a platform to deploy apps in *private* cloud scenarios, where a quite limited # of apps has been thoroughly vetted and the apps in the “store” would be configured very specifically to bootstrap against a database containing information about end users of that private cloud (LDAP basically) , Or should I just forget it and go with something like Docker, since it is architected for private image repos already? Thank you! Kevin Long From manik at canonical.com Thu May 19 20:18:36 2016 From: manik at canonical.com (Manik Taneja) Date: Thu, 19 May 2016 13:18:36 -0700 Subject: Can your run a private "store" for snappy apps? In-Reply-To: <3493B6AA-1C01-480C-BC12-6D2809BB11EF@haloprivacy.com> References: <3493B6AA-1C01-480C-BC12-6D2809BB11EF@haloprivacy.com> Message-ID: Dear Kevin, Great to have you on board the snappy bandwagon. Yes, we do provide the capability to connect snappy devices to a private store under the auspices of a commercial relationship. If this is something you wish to explore further, please unicast me with details on your product and lets touch base to determine how best to move forward. Regards, Manik Taneja On Thu, May 19, 2016 at 12:54 PM, Kevin Long wrote: > > Greetings, first post to the list ! > > With the snappy/core model , can one configure devices running snappy to > only connect to a private store , which would only contain snaps which I > have put into that private store? > > I am researching to choose a platform to deploy apps in *private* cloud > scenarios, where a quite limited # of apps has been thoroughly vetted and > the apps in the “store” would be configured very specifically to bootstrap > against a database containing information about end users of that private > cloud (LDAP basically) , > > > Or should I just forget it and go with something like Docker, since it is > architected for private image repos already? > > > Thank you! > > Kevin Long > > -- > Snapcraft mailing list > Snapcraft at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -------------- next part -------------- An HTML attachment was scrubbed... URL: From woodrow.shen at canonical.com Fri May 20 06:36:24 2016 From: woodrow.shen at canonical.com (Woodrow Shen) Date: Fri, 20 May 2016 14:36:24 +0800 Subject: How to make pre-installed snaps work with --devmode from u-d-f ? Message-ID: Hi all, Currently, we know that some snaps just installed with "--devmode" to work around issues from interfaces. Meanwhile, we'd like to use u-d-f to create an image which included these snaps by "--install" option, but we get failures to activate the service of these snaps (they can work well with "--devmode" by manual, e.g. `sudo snap install pciutils --devmode`). So the problem I want to clarify is u-d-f can have the option to support "--devmode" ? Thanks, -- Woodrow Shen Software Engineer, Canonical ltd. UES | CE | PC & Core, Taipei -------------- next part -------------- An HTML attachment was scrubbed... URL: From zygmunt.krynicki at canonical.com Fri May 20 07:07:02 2016 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Fri, 20 May 2016 09:07:02 +0200 Subject: How to make pre-installed snaps work with --devmode from u-d-f ? In-Reply-To: References: Message-ID: Hi The way images are built is being reorganized now. What this means for you in practice: - you will be able to define what an image should contain in a simple file (model assertion) - the new ubuntu-image tool will take that assertion and create an image - on first boot, everything will be installed by snapd - if your snap has confinement: devmode it will be installed as such (I'll confirm with the rest of the team to be sure) Best regards ZK On Fri, May 20, 2016 at 8:36 AM, Woodrow Shen wrote: > Hi all, > > Currently, we know that some snaps just installed with "--devmode" to work > around issues from interfaces. Meanwhile, we'd like to use u-d-f to create > an image which included these snaps by "--install" option, but we get > failures to activate the service of these snaps (they can work well with > "--devmode" by manual, e.g. `sudo snap install pciutils --devmode`). So the > problem I want to clarify is u-d-f can have the option to support > "--devmode" ? > > Thanks, > > -- > Woodrow Shen > Software Engineer, Canonical ltd. > UES | CE | PC & Core, Taipei > > -- > Snapcraft mailing list > Snapcraft at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > From jamie at canonical.com Fri May 20 13:11:02 2016 From: jamie at canonical.com (Jamie Strandboge) Date: Fri, 20 May 2016 08:11:02 -0500 Subject: How to make pre-installed snaps work with --devmode from u-d-f ? In-Reply-To: References: Message-ID: <1463749862.4114.27.camel@canonical.com> On Fri, 2016-05-20 at 09:07 +0200, Zygmunt Krynicki wrote: > Hi > > The way images are built is being reorganized now. What this means for > you in practice: >  - you will be able to define what an image should contain in a simple > file (model assertion) >  - the new ubuntu-image tool will take that assertion and create an image >  - on first boot, everything will be installed by snapd >  - if your snap has confinement: devmode it will be installed as such > (I'll confirm with the rest of the team to be sure) > I'm not sure if you are talking about the image generation process only, but I thought for normal install the 'confinement' flag in the yaml indicates that the snap cannot be installed without specifying --devmode. If it is instead simply a way to tell 'snap install' to install in devmode without specifying --devmode, then we've effectively reintroduced 'unconfined' and people might install things thinking they are confined when they are not. Speaking of which-- do we indicate anywhere that a snap is operating in devmode? I just installed hello-world with --devmode and I don't see in 'snap list' or 'snap interfaces' anything indicating it is in devmode. -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From zygmunt.krynicki at canonical.com Fri May 20 13:11:57 2016 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Fri, 20 May 2016 15:11:57 +0200 Subject: How to make pre-installed snaps work with --devmode from u-d-f ? In-Reply-To: <1463749862.4114.27.camel@canonical.com> References: <1463749862.4114.27.camel@canonical.com> Message-ID: @jamie: not yet, I have a patch for that but I never sent it On Fri, May 20, 2016 at 3:11 PM, Jamie Strandboge wrote: > On Fri, 2016-05-20 at 09:07 +0200, Zygmunt Krynicki wrote: >> Hi >> >> The way images are built is being reorganized now. What this means for >> you in practice: >> - you will be able to define what an image should contain in a simple >> file (model assertion) >> - the new ubuntu-image tool will take that assertion and create an image >> - on first boot, everything will be installed by snapd >> - if your snap has confinement: devmode it will be installed as such >> (I'll confirm with the rest of the team to be sure) >> > I'm not sure if you are talking about the image generation process only, but I > thought for normal install the 'confinement' flag in the yaml indicates that the > snap cannot be installed without specifying --devmode. If it is instead simply a > way to tell 'snap install' to install in devmode without specifying --devmode, > then we've effectively reintroduced 'unconfined' and people might install things > thinking they are confined when they are not. > > Speaking of which-- do we indicate anywhere that a snap is operating in devmode? > I just installed hello-world with --devmode and I don't see in 'snap list' or > 'snap interfaces' anything indicating it is in devmode. > > -- > Jamie Strandboge | http://www.canonical.com > From gustavo.niemeyer at canonical.com Fri May 20 13:39:47 2016 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Fri, 20 May 2016 10:39:47 -0300 Subject: How to make pre-installed snaps work with --devmode from u-d-f ? In-Reply-To: <1463749862.4114.27.camel@canonical.com> References: <1463749862.4114.27.camel@canonical.com> Message-ID: In principle it feels fine to allow people to build images with snaps in devmode. If one is willing to go over the trouble to create an image with the offending snap baked in, surely the prompt informing of what it means to install it in the first place was seen several times by then. Then, it should be very easy to have a flag on ubuntu-image itself: ubuntu-image --devmode, which would also have exactly the same semantics of either prompting interactively, or forcing the user to specify --i-completely-trust=dev1,dev2,dev3. So both ways to get a snap into the image would have the same behavior and awareness of the sensitivity of such operations. On Fri, May 20, 2016 at 10:11 AM, Jamie Strandboge wrote: > On Fri, 2016-05-20 at 09:07 +0200, Zygmunt Krynicki wrote: > > Hi > > > > The way images are built is being reorganized now. What this means for > > you in practice: > > - you will be able to define what an image should contain in a simple > > file (model assertion) > > - the new ubuntu-image tool will take that assertion and create an image > > - on first boot, everything will be installed by snapd > > - if your snap has confinement: devmode it will be installed as such > > (I'll confirm with the rest of the team to be sure) > > > I'm not sure if you are talking about the image generation process only, > but I > thought for normal install the 'confinement' flag in the yaml indicates > that the > snap cannot be installed without specifying --devmode. If it is instead > simply a > way to tell 'snap install' to install in devmode without specifying > --devmode, > then we've effectively reintroduced 'unconfined' and people might install > things > thinking they are confined when they are not. > > Speaking of which-- do we indicate anywhere that a snap is operating in > devmode? > I just installed hello-world with --devmode and I don't see in 'snap list' > or > 'snap interfaces' anything indicating it is in devmode. > > -- > Jamie Strandboge | http://www.canonical.com > > > -- > Snapcraft mailing list > Snapcraft at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie.bennett at canonical.com Fri May 20 13:45:39 2016 From: jamie.bennett at canonical.com (Jamie Bennett) Date: Fri, 20 May 2016 14:45:39 +0100 Subject: How to make pre-installed snaps work with --devmode from u-d-f ? In-Reply-To: References: <1463749862.4114.27.camel@canonical.com> Message-ID: > On 20 May 2016, at 14:39, Gustavo Niemeyer wrote: > > In principle it feels fine to allow people to build images with snaps in devmode. If one is willing to go over the trouble to create an image with the offending snap baked in, surely the prompt informing of what it means to install it in the first place was seen several times by then. > > Then, it should be very easy to have a flag on ubuntu-image itself: ubuntu-image --devmode, which would also have exactly the same semantics of either prompting interactively, or forcing the user to specify --i-completely-trust=dev1,dev2,dev3. So both ways to get a snap into the image would have the same behavior and awareness of the sensitivity of such operations. This is fine for the image builder but I like Jamie’s suggestion about informing the user, probably through a column in snap list, that the snap is installed in devmode. Regards, Jamie. > On Fri, May 20, 2016 at 10:11 AM, Jamie Strandboge > wrote: > On Fri, 2016-05-20 at 09:07 +0200, Zygmunt Krynicki wrote: > > Hi > > > > The way images are built is being reorganized now. What this means for > > you in practice: > > - you will be able to define what an image should contain in a simple > > file (model assertion) > > - the new ubuntu-image tool will take that assertion and create an image > > - on first boot, everything will be installed by snapd > > - if your snap has confinement: devmode it will be installed as such > > (I'll confirm with the rest of the team to be sure) > > > I'm not sure if you are talking about the image generation process only, but I > thought for normal install the 'confinement' flag in the yaml indicates that the > snap cannot be installed without specifying --devmode. If it is instead simply a > way to tell 'snap install' to install in devmode without specifying --devmode, > then we've effectively reintroduced 'unconfined' and people might install things > thinking they are confined when they are not. > > Speaking of which-- do we indicate anywhere that a snap is operating in devmode? > I just installed hello-world with --devmode and I don't see in 'snap list' or > 'snap interfaces' anything indicating it is in devmode. > > -- > Jamie Strandboge | http://www.canonical.com > > > -- > Snapcraft mailing list > Snapcraft at lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > -- > gustavo @ http://niemeyer.net -- > Snapcraft mailing list > Snapcraft at lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Fri May 20 14:51:37 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Fri, 20 May 2016 07:51:37 -0700 Subject: Can your run a private "store" for snappy apps? In-Reply-To: <3493B6AA-1C01-480C-BC12-6D2809BB11EF@haloprivacy.com> References: <3493B6AA-1C01-480C-BC12-6D2809BB11EF@haloprivacy.com> Message-ID: <573F2479.70603@ubuntu.com> Hi Kevin You can do this today in a couple of ways. For example, you can use a classic base (standard Ubuntu cloud images) and deliver the snaps directly to the right machines, or pull them to those machines from a cron job. That would be my recommendation now. We are working to make it easy to have private snaps in the store, too. Mark On 19/05/16 12:54, Kevin Long wrote: > Greetings, first post to the list ! > > With the snappy/core model , can one configure devices running snappy to only connect to a private store , which would only contain snaps which I have put into that private store? > > I am researching to choose a platform to deploy apps in *private* cloud scenarios, where a quite limited # of apps has been thoroughly vetted and the apps in the “store” would be configured very specifically to bootstrap against a database containing information about end users of that private cloud (LDAP basically) , > > > Or should I just forget it and go with something like Docker, since it is architected for private image repos already? > > > Thank you! > > Kevin Long > From mark at ubuntu.com Fri May 20 15:03:47 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Fri, 20 May 2016 08:03:47 -0700 Subject: How to make pre-installed snaps work with --devmode from u-d-f ? In-Reply-To: References: <1463749862.4114.27.camel@canonical.com> Message-ID: <573F2753.70700@ubuntu.com> On 20/05/16 06:45, Jamie Bennett wrote: > This is fine for the image builder but I like Jamie’s suggestion about informing the user, probably through a column in snap list, that the snap is installed in devmode. +1. In MOTD too, and in webdm. Mark From anthony.wong at canonical.com Fri May 20 16:14:24 2016 From: anthony.wong at canonical.com (Anthony Wong) Date: Sat, 21 May 2016 00:14:24 +0800 Subject: snapcraft kernel.py plugin requires Ubuntu One account In-Reply-To: <571627D3.2080106@ubuntu.com> References: <7289078e25f24e0a97789575173499aa@dwmail02.dewetron.com> <571627D3.2080106@ubuntu.com> Message-ID: On 19 April 2016 at 20:42, Sergio Schvezov wrote: > > > El 19/04/16 a las 05:48, Gunther Laure escribió: > > Hi! > > > > > > > > I try to run a continuous integration build for a custom kernel module. > > > > This fails as I need to provide my Ubuntu One credentials so that the > > kernel plugin is able to download “os.snap” using the Ubuntu Store API. > > > The need to download the os.snap is just a temporary side effect. If > everything is executed as planned, the need to download an os snap to > build the kernel will become a thing of the past. > > > My problem: I do not want to make my credentials public to anyone who is > > able to look into the Jenkins build job … > > > > > > > > Is there the possibility for an anonymous download? Or a credential file? > > There are two options; log in from a different device and copy > .config/snapcraft/snapcraft.cfg to your jenkins instance OR create a > random joe user and copy over the credentials. > Just tried to build kernel snap on Launchpad today and have this issue. AFAIK neither of these options can be done on Launchpad, so I think it is still not possible to build kernel snap there yet. -- Anthony -- Anthony Wong Engineering Manager, Hardware Enablement Canonical Ltd. www.canonical.com On 19 April 2016 at 20:42, Sergio Schvezov wrote: > > > El 19/04/16 a las 05:48, Gunther Laure escribió: > > Hi! > > > > > > > > I try to run a continuous integration build for a custom kernel module. > > > > This fails as I need to provide my Ubuntu One credentials so that the > > kernel plugin is able to download “os.snap” using the Ubuntu Store API. > > > The need to download the os.snap is just a temporary side effect. If > everything is executed as planned, the need to download an os snap to > build the kernel will become a thing of the past. > > > My problem: I do not want to make my credentials public to anyone who is > > able to look into the Jenkins build job … > > > > > > > > Is there the possibility for an anonymous download? Or a credential file? > > There are two options; log in from a different device and copy > .config/snapcraft/snapcraft.cfg to your jenkins instance OR create a > random joe user and copy over the credentials. > > > -- > snappy-devel mailing list > snappy-devel at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snappy-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jian.luo.cn at gmail.com Fri May 20 18:33:04 2016 From: jian.luo.cn at gmail.com (Jian LUO) Date: Fri, 20 May 2016 20:33:04 +0200 Subject: snap ignores the proxy environment variables Message-ID: Hi list, can someone confirm this bug about snap ignoring the proxy environment variables? https://bugs.launchpad.net/snappy/+bug/1579652 Cheers, Jian -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo.niemeyer at canonical.com Fri May 20 18:59:58 2016 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Fri, 20 May 2016 15:59:58 -0300 Subject: snap ignores the proxy environment variables In-Reply-To: References: Message-ID: Hi Jian, The snap tool is just a client to the snapd daemon. Changing its environment will not affect the running server. We need to find a good way to update it easily. Meanwhile, you can find tune the snapd.service configuration via a systemd configuration file. Please have a look here for a hint: http://serverfault.com/questions/413397/how-to-set-environment-variable-in-systemd-service On Fri, May 20, 2016 at 3:33 PM, Jian LUO wrote: > Hi list, > > can someone confirm this bug about snap ignoring the proxy environment > variables? > > https://bugs.launchpad.net/snappy/+bug/1579652 > > Cheers, > > Jian > > -- > Snapcraft mailing list > Snapcraft at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From fcdoth at gmail.com Fri May 20 19:38:46 2016 From: fcdoth at gmail.com (Fernando Correa Neto) Date: Fri, 20 May 2016 19:38:46 +0000 Subject: Rpi3 boots, reaches login but no Wifi Message-ID: Hey there After successfully booting up the Rpi3 image and trying to setup wifi, I noticed the following error: [ 15.468298] brcmfmac_sdio mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.bin failed with error -2 [ 16.210654] systemd-journald[475]: Received request to flush runtime journal from PID 1 [ 16.473872] brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50 [ 17.279125] cfg80211: World regulatory domain updated: [ 17.279149] cfg80211: DFS Master region: unset [ 17.279159] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 17.279175] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [ 17.279187] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) [ 17.279199] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A) [ 17.279214] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A) [ 17.279229] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s) [ 17.279242] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s) [ 17.279254] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A) [ 17.279266] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A) [ 17.488436] brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50 Scanning the web I've found that when that happens, it's either because of an old firmware or a missing .txt that should be sitting right next to the firmware blob, in this case brcmfmac43430-sdio.txt Checking Rpi3's /lib/firmware/brcm, there's no .txt. I wonder what are my options there. What's the recommended way for testing a simple file placement followed by rmmod/modprob in a snappy world? Regards, Fernando -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo.niemeyer at canonical.com Fri May 20 19:38:36 2016 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Fri, 20 May 2016 16:38:36 -0300 Subject: snap ignores the proxy environment variables In-Reply-To: References: Message-ID: John has a more elegant response to this same question here: http://askubuntu.com/questions/764610/how-to-install-snap-packages-behind-web-proxy-on-ubuntu-16-04/773230#773230 On Fri, May 20, 2016 at 3:59 PM, Gustavo Niemeyer < gustavo.niemeyer at canonical.com> wrote: > Hi Jian, > > The snap tool is just a client to the snapd daemon. Changing its > environment will not affect the running server. > > We need to find a good way to update it easily. Meanwhile, you can find > tune the snapd.service configuration via a systemd configuration file. > > Please have a look here for a hint: > > > http://serverfault.com/questions/413397/how-to-set-environment-variable-in-systemd-service > > > > On Fri, May 20, 2016 at 3:33 PM, Jian LUO wrote: > >> Hi list, >> >> can someone confirm this bug about snap ignoring the proxy environment >> variables? >> >> https://bugs.launchpad.net/snappy/+bug/1579652 >> >> Cheers, >> >> Jian >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/snapcraft >> >> > > > -- > gustavo @ http://niemeyer.net > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie.bennett at canonical.com Sat May 21 00:07:05 2016 From: jamie.bennett at canonical.com (Jamie Bennett) Date: Sat, 21 May 2016 01:07:05 +0100 Subject: Rpi3 boots, reaches login but no Wifi In-Reply-To: References: Message-ID: Hi Fernando, > On 20 May 2016, at 20:38, Fernando Correa Neto wrote: > > Hey there > > After successfully booting up the Rpi3 image and trying to setup wifi, I noticed the following error: > > [ 15.468298] brcmfmac_sdio mmc1:0001:1: Direct firmware load for brcm/brcmfmac43430-sdio.bin failed with error -2 > [ 16.210654] systemd-journald[475]: Received request to flush runtime journal from PID 1 > [ 16.473872] brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50 > [ 17.279125] cfg80211: World regulatory domain updated: > [ 17.279149] cfg80211: DFS Master region: unset > [ 17.279159] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) > [ 17.279175] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) > [ 17.279187] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm), (N/A) > [ 17.279199] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, 2000 mBm), (N/A) > [ 17.279214] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (N/A) > [ 17.279229] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 KHz AUTO), (N/A, 2000 mBm), (0 s) > [ 17.279242] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, 2000 mBm), (0 s) > [ 17.279254] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 2000 mBm), (N/A) > [ 17.279266] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm), (N/A) > [ 17.488436] brcmf_sdio_htclk: HT Avail timeout (1000000): clkctl 0x50 > > > Scanning the web I've found that when that happens, it's either because of an old firmware or a missing .txt that should be sitting right next to the firmware blob, in this case brcmfmac43430-sdio.txt > Checking Rpi3's /lib/firmware/brcm, there's no .txt. > > I wonder what are my options there. What's the recommended way for testing a simple file placement followed by rmmod/modprob in a snappy world? I'm not sure of the answer but I do know that Oliver has been working with RPi3 images lately and may be able to help. CC'ing him here. Regards, Jamie. > Regards, > Fernando > -- > Snapcraft mailing list > Snapcraft at lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft From fcdoth at gmail.com Thu May 19 15:19:28 2016 From: fcdoth at gmail.com (Fernando Correa Neto) Date: Thu, 19 May 2016 15:19:28 +0000 Subject: Rpi3 testing In-Reply-To: <1463599549.4114.12.camel@canonical.com> References: <1463592221.23678.4.camel@ubuntu.com> <1463596541.4114.10.camel@canonical.com> <1463598801.29215.2.camel@ubuntu.com> <1463599549.4114.12.camel@canonical.com> Message-ID: FYI, I just tested and it works. Generated the image with: sudo ./ubuntu-device-flash core rolling-core --gadget canonical-pi3 --developer-mode --channel=edge --kernel canonical-pi2-linux --os xenial-preinstalled-core-armhf.os.snap -o rpi3-all-snap.img -Fernando On Wed, May 18, 2016 at 4:26 PM Jamie Strandboge wrote: > On Wed, 2016-05-18 at 21:13 +0200, Oliver Grawert wrote: > > hi, > > > > On Mi, 2016-05-18 at 13:35 -0500, Jamie Strandboge wrote: > > > > > > Oliver, fyi this snappy-workaround-apparmor.service was only needed on > 15.04 > > > and > > > fixed in the parser in 15.10. If this is causing you trouble, please > feel > > > free > > > to remove it now > > already happened and tested ... thats what will go to the store > > tomorrow ... > > \o/ Thanks! :) > > -- > Jamie Strandboge | http://www.canonical.com > > -- > snappy-devel mailing list > snappy-devel at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snappy-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From woodrow.shen at canonical.com Fri May 20 06:34:26 2016 From: woodrow.shen at canonical.com (Woodrow Shen) Date: Fri, 20 May 2016 14:34:26 +0800 Subject: How to make pre-installed snaps work with --devmode from u-d-f ? Message-ID: Hi all, Currently, we know that some snaps just installed with "--devmode" to work around issues from interfaces. Meanwhile, we'd like to use u-d-f to create an image which included these snaps by "--install" option, but we get failures to activate the service of these snaps (they can work well with "--devmode" by manual, e.g. `sudo snap install pciutils --devmode`). So the problem I want to clarify is u-d-f can have the option to support "--devmode" ? Thanks, -- Woodrow Shen Software Engineer, Canonical ltd. UES | CE | PC & Core, Taipei -------------- next part -------------- An HTML attachment was scrubbed... URL: From didrocks at ubuntu.com Fri May 20 07:24:55 2016 From: didrocks at ubuntu.com (Didier Roche) Date: Fri, 20 May 2016 02:24:55 -0500 Subject: RPI3 Linux Kernel Build help ! In-Reply-To: References: Message-ID: <573EBBC7.9080702@ubuntu.com> Le 18/05/2016 12:22, Huy Nguyen a écrit : > Hi All, Hey Huy, > > I have successfully built linux kernel for RPI3 using the below web > site : > > https://www.raspberrypi.org/documentation/linux/kernel/building.md > > > I copied the newly built *zImage* to microSD card and re-name this > to kernel7.img. > > *PI3 crashed *with the newly built zImage. > > My question is whether the Raspberry aforementioned web site is > up-to-date for > building RPI3 linux kernel ? > > *Is anyone successfully built linux kernel for RPI3 and booted Okay ?* I guess your email was perfectly timed with the "Rpi3 testing" thread on the same ML where Ogra anwered some of those questions. If you need further help, do not hesitate to jump on that thread :) Cheers, Didier > > > Thank You. > > Huy Nguyen > e-mail : huy5220 at gmail.com > cell# : 214.289.8829 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fcdoth at gmail.com Sat May 21 22:12:05 2016 From: fcdoth at gmail.com (Fernando Correa Neto) Date: Sat, 21 May 2016 22:12:05 +0000 Subject: RPI3 Linux Kernel Build help ! In-Reply-To: References: Message-ID: Hey On Wed, May 18, 2016 at 2:22 PM Huy Nguyen wrote: > Hi All, > > I have successfully built linux kernel for RPI3 using the below web > site : > > https://www.raspberrypi.org/documentation/linux/kernel/building.md > > > I copied the newly built *zImage* to microSD card and re-name this to > kernel7.img. > > *PI3 crashed *with the newly built zImage. > > My question is whether the Raspberry aforementioned web site is > up-to-date for > building RPI3 linux kernel ? > > *Is anyone successfully built linux kernel for RPI3 and booted Okay ?* > Since the info about generating the image ended up in the snapcraft mailing list, I'll past the relevant bit here on how to generate a working image (working as almost working since there's an issue with wifi currently) Grab this: http://people.canonical.com/~ogra/snappy/all-snaps/ubuntu-device-flash and run: sudo ./ubuntu-device-flash core rolling-core --gadget canonical-pi3 --developer-mode --channel=edge --kernel canonical-pi2-linux --os xenial-preinstalled-core-armhf.os.snap -o rpi3-all-snap.img That should give you a flashable image. -Fernando -------------- next part -------------- An HTML attachment was scrubbed... URL: From huy5220 at gmail.com Sat May 21 23:44:26 2016 From: huy5220 at gmail.com (Huy Nguyen) Date: Sat, 21 May 2016 16:44:26 -0700 Subject: RPI3 Linux Kernel Build help ! In-Reply-To: References: Message-ID: Hi All , Thank You for all supported emails. Issue was resolved by renaming of newly built *Image* ( instead of zImage ) to k*ernel7.img ,* *then copied to micro SD card.* My RPI3 is now successfully booted. My apology to all if my emails has been included in wrong list. Best Regards, Huy Nguyen e-mail : huy5220 at gmail.com cell# : 214.289.8829 On Sat, May 21, 2016 at 3:12 PM, Fernando Correa Neto wrote: > Hey > > On Wed, May 18, 2016 at 2:22 PM Huy Nguyen wrote: > >> Hi All, >> >> I have successfully built linux kernel for RPI3 using the below web >> site : >> >> https://www.raspberrypi.org/documentation/linux/kernel/building.md >> >> >> I copied the newly built *zImage* to microSD card and re-name this to >> kernel7.img. >> >> *PI3 crashed *with the newly built zImage. >> >> My question is whether the Raspberry aforementioned web site is >> up-to-date for >> building RPI3 linux kernel ? >> >> *Is anyone successfully built linux kernel for RPI3 and booted Okay ?* >> > > Since the info about generating the image ended up in the snapcraft > mailing list, I'll past the relevant bit here on how to generate a working > image (working as almost working since there's an issue with wifi currently) > > Grab this: > http://people.canonical.com/~ogra/snappy/all-snaps/ubuntu-device-flash > > and run: > > sudo ./ubuntu-device-flash core rolling-core --gadget canonical-pi3 > --developer-mode --channel=edge --kernel canonical-pi2-linux --os > xenial-preinstalled-core-armhf.os.snap -o rpi3-all-snap.img > > That should give you a flashable image. > > -Fernando > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Mon May 23 08:33:26 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Mon, 23 May 2016 11:33:26 +0300 Subject: Minimal Kiosk App with Snappy In-Reply-To: References: Message-ID: <5742C056.9060709@ubuntu.com> Hi Anthony You should be able to get first-class support for Electron as I know there are a few Electron-based snaps in progress. I wanted to bring your mail thread into the new list (snapcraft at lists.ubuntu.com). I'm pretty sure your use case, a web-based kiosk style snap, is going to be very common. So for now I would suggest that you work on a desktop snap that works on plain old Ubuntu 16.04 desktop in --devmode while other folks work out the kinks for non-X11 electron snaps. That wont take long and then yours will fit right in :) Mark On 25/04/16 17:29, Anthony Kolodzinski wrote: > Hi all, > > I am new to Snappy development, and have a question regarding an > application I am developing. > > My requirement is to be able to run a minimal, single window GUI using > HTML, CSS, Javascript, and to be able to run it natively using a framework > like electron . > > My question is, should I attempt to build X and electron in a docker > container, and hook that into my monitor, or use something like the QT Web > Engine with MIR. > > Secondly, I have searched around, but if anybody has any resources that > provide examples on how to accomplish this it would be greatly appreciated. > Thanks. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marco.trevisan at canonical.com Mon May 23 15:50:45 2016 From: marco.trevisan at canonical.com (Marco Trevisan) Date: Mon, 23 May 2016 17:50:45 +0200 Subject: Minimal Kiosk App with Snappy In-Reply-To: <5742C056.9060709@ubuntu.com> References: <5742C056.9060709@ubuntu.com> Message-ID: <574326D5.7010808@canonical.com> Hi Anthony, Electron OS backend (brightray) doesn't support mir yet AFAIK, although if you want to use this framework you could use a simple X server in the mean time, and then move to mir once we get support for that (I expect this to be a quick update at that point). I've been playing a little with electron apps and snapcraft, and they can run pretty easily by using something like this [1]. However, right now it only works when installed in --devmode, but I guess we'll fix this soon. [1] https://code.launchpad.net/~3v1n0/+junk/electron-quick-start-snap Il 23/05/2016 10:33, Mark Shuttleworth ha scritto: > Hi Anthony > > You should be able to get first-class support for Electron as I know > there are a few Electron-based snaps in progress. > > I wanted to bring your mail thread into the new list > (snapcraft at lists.ubuntu.com). > > I'm pretty sure your use case, a web-based kiosk style snap, is going to > be very common. So for now I would suggest that you work on a desktop > snap that works on plain old Ubuntu 16.04 desktop in --devmode while > other folks work out the kinks for non-X11 electron snaps. That wont > take long and then yours will fit right in :) > > Mark > > On 25/04/16 17:29, Anthony Kolodzinski wrote: >> Hi all, >> >> I am new to Snappy development, and have a question regarding an >> application I am developing. >> >> My requirement is to be able to run a minimal, single window GUI using >> HTML, CSS, Javascript, and to be able to run it natively using a framework >> like electron . >> >> My question is, should I attempt to build X and electron in a docker >> container, and hook that into my monitor, or use something like the QT Web >> Engine with MIR. >> >> Secondly, I have searched around, but if anybody has any resources that >> provide examples on how to accomplish this it would be greatly appreciated. >> Thanks. From anthonykolodzinski at gmail.com Mon May 23 15:53:32 2016 From: anthonykolodzinski at gmail.com (Anthony Kolodzinski) Date: Mon, 23 May 2016 15:53:32 +0000 Subject: Minimal Kiosk App with Snappy In-Reply-To: <574326D5.7010808@canonical.com> References: <5742C056.9060709@ubuntu.com> <574326D5.7010808@canonical.com> Message-ID: Thanks for the support, guys. Also Mark, thanks for the intros. When this is figured out it will be a powerful tool for kiosk/medium size connected device development. I will try all of this out shortly! On Mon, May 23, 2016 at 11:50 AM Marco Trevisan < marco.trevisan at canonical.com> wrote: > Hi Anthony, > > Electron OS backend (brightray) doesn't support mir yet AFAIK, although > if you want to use this framework you could use a simple X server in the > mean time, and then move to mir once we get support for that (I expect > this to be a quick update at that point). > > I've been playing a little with electron apps and snapcraft, and they > can run pretty easily by using something like this [1]. However, right > now it only works when installed in --devmode, but I guess we'll fix > this soon. > > [1] https://code.launchpad.net/~3v1n0/+junk/electron-quick-start-snap > > Il 23/05/2016 10:33, Mark Shuttleworth ha scritto: > > Hi Anthony > > > > You should be able to get first-class support for Electron as I know > > there are a few Electron-based snaps in progress. > > > > I wanted to bring your mail thread into the new list > > (snapcraft at lists.ubuntu.com). > > > > I'm pretty sure your use case, a web-based kiosk style snap, is going to > > be very common. So for now I would suggest that you work on a desktop > > snap that works on plain old Ubuntu 16.04 desktop in --devmode while > > other folks work out the kinks for non-X11 electron snaps. That wont > > take long and then yours will fit right in :) > > > > Mark > > > > On 25/04/16 17:29, Anthony Kolodzinski wrote: > >> Hi all, > >> > >> I am new to Snappy development, and have a question regarding an > >> application I am developing. > >> > >> My requirement is to be able to run a minimal, single window GUI using > >> HTML, CSS, Javascript, and to be able to run it natively using a > framework > >> like electron . > >> > >> My question is, should I attempt to build X and electron in a docker > >> container, and hook that into my monitor, or use something like the QT > Web > >> Engine with MIR. > >> > >> Secondly, I have searched around, but if anybody has any resources that > >> provide examples on how to accomplish this it would be greatly > appreciated. > >> Thanks. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.gunn at canonical.com Mon May 23 16:06:46 2016 From: kevin.gunn at canonical.com (Kevin Gunn) Date: Mon, 23 May 2016 11:06:46 -0500 Subject: Minimal Kiosk App with Snappy In-Reply-To: References: <5742C056.9060709@ubuntu.com> <574326D5.7010808@canonical.com> Message-ID: Hey Anthony - but also, if you are interested in looking into your other suggestion "something like the QT Web Engine with MIR" You could try out Mir as well, just check out https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ The wiki talks through this, but in effect it provides a guide for using a Qt example app that you could easily fork and replace with your own client app snap. would love to hear your feedback. br,kg On Mon, May 23, 2016 at 10:53 AM, Anthony Kolodzinski < anthonykolodzinski at gmail.com> wrote: > Thanks for the support, guys. > Also Mark, thanks for the intros. > > When this is figured out it will be a powerful tool for kiosk/medium size > connected device development. > > I will try all of this out shortly! > > On Mon, May 23, 2016 at 11:50 AM Marco Trevisan < > marco.trevisan at canonical.com> wrote: > >> Hi Anthony, >> >> Electron OS backend (brightray) doesn't support mir yet AFAIK, although >> if you want to use this framework you could use a simple X server in the >> mean time, and then move to mir once we get support for that (I expect >> this to be a quick update at that point). >> >> I've been playing a little with electron apps and snapcraft, and they >> can run pretty easily by using something like this [1]. However, right >> now it only works when installed in --devmode, but I guess we'll fix >> this soon. >> >> [1] https://code.launchpad.net/~3v1n0/+junk/electron-quick-start-snap >> >> Il 23/05/2016 10:33, Mark Shuttleworth ha scritto: >> > Hi Anthony >> > >> > You should be able to get first-class support for Electron as I know >> > there are a few Electron-based snaps in progress. >> > >> > I wanted to bring your mail thread into the new list >> > (snapcraft at lists.ubuntu.com). >> > >> > I'm pretty sure your use case, a web-based kiosk style snap, is going to >> > be very common. So for now I would suggest that you work on a desktop >> > snap that works on plain old Ubuntu 16.04 desktop in --devmode while >> > other folks work out the kinks for non-X11 electron snaps. That wont >> > take long and then yours will fit right in :) >> > >> > Mark >> > >> > On 25/04/16 17:29, Anthony Kolodzinski wrote: >> >> Hi all, >> >> >> >> I am new to Snappy development, and have a question regarding an >> >> application I am developing. >> >> >> >> My requirement is to be able to run a minimal, single window GUI using >> >> HTML, CSS, Javascript, and to be able to run it natively using a >> framework >> >> like electron . >> >> >> >> My question is, should I attempt to build X and electron in a docker >> >> container, and hook that into my monitor, or use something like the QT >> Web >> >> Engine with MIR. >> >> >> >> Secondly, I have searched around, but if anybody has any resources that >> >> provide examples on how to accomplish this it would be greatly >> appreciated. >> >> Thanks. >> >> > -- > Snapcraft mailing list > Snapcraft at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo.niemeyer at canonical.com Tue May 24 12:37:22 2016 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Tue, 24 May 2016 09:37:22 -0300 Subject: Code moved Message-ID: Hello all, The code repository for snapd now lives at: https://github.com/snapcore/snapd Other projects will soon move over under the new GH org name too. gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.lenton at canonical.com Tue May 24 16:03:48 2016 From: john.lenton at canonical.com (John Lenton) Date: Tue, 24 May 2016 17:03:48 +0100 Subject: snap list/find output Message-ID: As we add richer options to snaps and want to rightly expose them in the commandline output, the question is how to make it usable. The output of `snap list`, for example, needs to show, in a single line that could reasonably be as narrow as 80 columns wide: some are text fields, with reasonably long limits (e.g. 32 chars for version): name version revision developer name, at least if different from publisher name summary (when querying the store we could also have "price" for example) and some that are flagish: is it private? is it devmode? try? has it been paid for? does it provide services, and are they running ok? does it have updates available? is the revision we're on "pinned" because of it being manually requested? it has updates available, and we're not going there because ...they're devmode and we aren't? [this might be invisible to the client] ...we tried and had to rollback? ...rollback was done by user? there's also some system-level things we want to output on snap list: is a reboot required? is it a devmode-only thing? (e.g. running without apparmor in the kernel) is the system tainted or otherwise dirty? (nothing done for this yet, but needs thinking aboot) i'm also probably forgetting things. One thing I *don't* want us to do is have something like the header on `dpkg -l`: Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==============-============-============-================================= I also don't want us to punt on the problem by not exposing this info and having a `-o` option à la ps; the defaults should be good enough (especially given that the REST API is straightforward enough if developers need more control) (not to say that we don't add something like -o down the line, but it's cornercase). So, having said all this, I think we can get very good results by using adaptive layout with a combination of colours, a bit of unicode, and per-column shortening strategies. A lot of this working hinges on there being a clear precedence in the "flagish" columns. For example, First off, if the output isn't a tty, just output tab-separated non-shortened columns. Easy for programs to poke at. Otherwise: Never shorten name nor revision. If just those two don't fit, tough luck. But don't use a header for Revision (as most often that will be wider than the revision); just r%d (after version, if it fit). Put all flagish things under a single (e.g.) "Notes" column. If a ", "-separated list of the most succint way of describing each flag doesn't fit, put "see info" (or e.g. "👉info" if that works). Assume you've shortened it for now. Colourize the line based on what's in the notes (e.g. red if it demands attention). Maybe also add an exclamation mark if it does! If you're already at the width, that's it. Otherwise, while each bit of info doesn't go over the width, Shorten version down to the localised length of "Version", using an ellipsis (… U+2026 HORIZONTAL ELLIPSIS) in the middle. Shorten developer name down to the localized length of "Developer", with an ellipsis at the end. Add summary, ellipsised at the end. Go back and lengthen "notes" if possible. that, to my mind, works. I can implement a PoC of this so we can play with it if you'd rather, but I didn't want to dive into doing that first before we checked whether I was sane. Anyway. Bikeshed away! From gustavo.niemeyer at canonical.com Tue May 24 16:40:20 2016 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Tue, 24 May 2016 13:40:20 -0300 Subject: snap list/find output In-Reply-To: References: Message-ID: Thanks for putting these ideas together, John. So, some preliminary thoughts: - We don't need to have list and find output with the same format; they're oriented towards different problems (finding what to install, vs. listing what is installed), so we can optimize their output for these problems. - Not every single detail about a snap should be present in the output for these commands. This is obvious, but also too easy to unintentionally get wrong. - Some of the mentioned flags are system-level settings (tainting, reboot required, etc). These should not be in find or list. - It's okay to shorten fields which are likely too long (summary), but doesn't seem okay to shorten core fields such as version. - Having "see info" for data that sometimes is there and sometimes not seems a bit strange. I'd prefer to draw a line about what is there or not so it doesn't get out of hand, but trust these details defined to always be there. - Revisions can be x1 for local revisions, so we the "r" prefix doesn't look so great here or anywhere else. Having it space-separated from the version also feels slightly awkward because it breaks the obvious parsing (N columns == A+1+B fields). On that basis, here is a concrete proposal: https://gist.github.com/niemeyer/22c0c8619456a9494396bc3af6ff1891 The notes presented there are the only details I'd show as the output of these commands. Other data would be presented elsewhere. On Tue, May 24, 2016 at 1:03 PM, John Lenton wrote: > As we add richer options to snaps and want to rightly expose them in > the commandline output, the question is how to make it usable. > > The output of `snap list`, for example, needs to show, in a single > line that could reasonably be as narrow as 80 columns wide: > > some are text fields, with reasonably long limits (e.g. 32 chars for > version): > > name > version > revision > developer name, at least if different from publisher name > summary (when querying the store we could also have "price" for example) > > and some that are flagish: > > is it private? > is it devmode? > try? > has it been paid for? > does it provide services, and are they running ok? > does it have updates available? > is the revision we're on "pinned" because of it being manually requested? > it has updates available, and we're not going there because > ...they're devmode and we aren't? [this might be invisible to the client] > ...we tried and had to rollback? > ...rollback was done by user? > > there's also some system-level things we want to output on snap list: > > is a reboot required? > is it a devmode-only thing? (e.g. running without apparmor in the kernel) > is the system tainted or otherwise dirty? (nothing done for this yet, > but needs thinking aboot) > > i'm also probably forgetting things. > > One thing I *don't* want us to do is have something like the header on > `dpkg -l`: > > Desired=Unknown/Install/Remove/Purge/Hold > | > Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ Name Version Architecture Description > > +++-==============-============-============-================================= > > I also don't want us to punt on the problem by not exposing this info > and having a `-o` option à la ps; the defaults should be good enough > (especially given that the REST API is straightforward enough if > developers need more control) (not to say that we don't add something > like -o down the line, but it's cornercase). > > So, having said all this, I think we can get very good results by > using adaptive layout with a combination of colours, a bit of unicode, > and per-column shortening strategies. > > A lot of this working hinges on there being a clear precedence in the > "flagish" columns. For example, > > First off, if the output isn't a tty, just output tab-separated > non-shortened columns. Easy for programs to poke at. Otherwise: > > Never shorten name nor revision. If just those two don't fit, tough > luck. But don't use a header for Revision (as most often that will be > wider than the revision); just r%d (after version, if it fit). > Put all flagish things under a single (e.g.) "Notes" column. If a ", > "-separated list of the most succint way of describing each flag > doesn't fit, put "see info" (or e.g. "👉info" if that works). Assume > you've shortened it for now. Colourize the line based on what's in the > notes (e.g. red if it demands attention). Maybe also add an > exclamation mark if it does! > If you're already at the width, that's it. Otherwise, while each bit > of info doesn't go over the width, > Shorten version down to the localised length of "Version", using an > ellipsis (… U+2026 HORIZONTAL ELLIPSIS) in the middle. > Shorten developer name down to the localized length of "Developer", > with an ellipsis at the end. > Add summary, ellipsised at the end. > Go back and lengthen "notes" if possible. > > that, to my mind, works. > > I can implement a PoC of this so we can play with it if you'd rather, > but I didn't want to dive into doing that first before we checked > whether I was sane. > > Anyway. Bikeshed away! > > -- > Snapcraft mailing list > Snapcraft at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.lenton at canonical.com Wed May 25 08:43:35 2016 From: john.lenton at canonical.com (John Lenton) Date: Wed, 25 May 2016 09:43:35 +0100 Subject: snap list/find output In-Reply-To: References: Message-ID: With your suggestion for "snap find" output, even with the paltry packages we have today, you already have just three characters left before the 80th column for summary, and a third of that width is used up for "version". That seems wrong to me, and it's only going to get worse as "Notes" gets used. "snap list" would hit similar issues as well. On 24 May 2016 at 17:40, Gustavo Niemeyer wrote: > Thanks for putting these ideas together, John. > > So, some preliminary thoughts: > > - We don't need to have list and find output with the same format; they're > oriented towards different problems (finding what to install, vs. listing > what is installed), so we can optimize their output for these problems. > > - Not every single detail about a snap should be present in the output for > these commands. This is obvious, but also too easy to unintentionally get > wrong. > > - Some of the mentioned flags are system-level settings (tainting, reboot > required, etc). These should not be in find or list. > > - It's okay to shorten fields which are likely too long (summary), but > doesn't seem okay to shorten core fields such as version. > > - Having "see info" for data that sometimes is there and sometimes not seems > a bit strange. I'd prefer to draw a line about what is there or not so it > doesn't get out of hand, but trust these details defined to always be there. > > - Revisions can be x1 for local revisions, so we the "r" prefix doesn't look > so great here or anywhere else. Having it space-separated from the version > also feels slightly awkward because it breaks the obvious parsing (N columns > == A+1+B fields). > > On that basis, here is a concrete proposal: > > https://gist.github.com/niemeyer/22c0c8619456a9494396bc3af6ff1891 > > The notes presented there are the only details I'd show as the output of > these commands. Other data would be presented elsewhere. > > > > On Tue, May 24, 2016 at 1:03 PM, John Lenton > wrote: >> >> As we add richer options to snaps and want to rightly expose them in >> the commandline output, the question is how to make it usable. >> >> The output of `snap list`, for example, needs to show, in a single >> line that could reasonably be as narrow as 80 columns wide: >> >> some are text fields, with reasonably long limits (e.g. 32 chars for >> version): >> >> name >> version >> revision >> developer name, at least if different from publisher name >> summary >> >> >> >> (when querying the store we could also have "price" for example) >> >> and some that are flagish: >> >> is it private? >> is it devmode? >> try? >> has it been paid for? >> does it provide services, and are they running ok? >> does it have updates available? >> is the revision we're on "pinned" because of it being manually requested? >> it has updates available, and we're not going there because >> ...they're devmode and we aren't? [this might be invisible to the client] >> ...we tried and had to rollback? >> ...rollback was done by user? >> >> there's also some system-level things we want to output on snap list: >> >> is a reboot required? >> is it a devmode-only thing? (e.g. running without apparmor in the kernel) >> is the system tainted or otherwise dirty? (nothing done for this yet, >> but needs thinking aboot) >> >> i'm also probably forgetting things. >> >> One thing I *don't* want us to do is have something like the header on >> `dpkg -l`: >> >> Desired=Unknown/Install/Remove/Purge/Hold >> | >> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend >> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) >> ||/ Name Version Architecture Description >> >> +++-==============-============-============-================================= >> >> I also don't want us to punt on the problem by not exposing this info >> and having a `-o` option à la ps; the defaults should be good enough >> (especially given that the REST API is straightforward enough if >> developers need more control) (not to say that we don't add something >> like -o down the line, but it's cornercase). >> >> So, having said all this, I think we can get very good results by >> using adaptive layout with a combination of colours, a bit of unicode, >> and per-column shortening strategies. >> >> A lot of this working hinges on there being a clear precedence in the >> "flagish" columns. For example, >> >> First off, if the output isn't a tty, just output tab-separated >> non-shortened columns. Easy for programs to poke at. Otherwise: >> >> Never shorten name nor revision. If just those two don't fit, tough >> luck. But don't use a header for Revision (as most often that will be >> wider than the revision); just r%d (after version, if it fit). >> Put all flagish things under a single (e.g.) "Notes" column. If a ", >> "-separated list of the most succint way of describing each flag >> doesn't fit, put "see info" (or e.g. "info" if that works). Assume >> you've shortened it for now. Colourize the line based on what's in the >> notes (e.g. red if it demands attention). Maybe also add an >> exclamation mark if it does! >> If you're already at the width, that's it. Otherwise, while each bit >> of info doesn't go over the width, >> Shorten version down to the localised length of "Version", using an >> ellipsis (… U+2026 HORIZONTAL ELLIPSIS) in the middle. >> Shorten developer name down to the localized length of "Developer", >> with an ellipsis at the end. >> Add summary, ellipsised at the end. >> Go back and lengthen "notes" if possible. >> >> that, to my mind, works. >> >> I can implement a PoC of this so we can play with it if you'd rather, >> but I didn't want to dive into doing that first before we checked >> whether I was sane. >> >> Anyway. Bikeshed away! >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > -- > gustavo @ http://niemeyer.net From gustavo.niemeyer at canonical.com Wed May 25 13:59:26 2016 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Wed, 25 May 2016 10:59:26 -0300 Subject: snap list/find output In-Reply-To: References: Message-ID: On Wed, May 25, 2016 at 5:43 AM, John Lenton wrote: > With your suggestion for "snap find" output, even with the paltry > packages we have today, you already have just three characters left > before the 80th column for summary, and a third of that width is used > up for "version". That seems wrong to me, and it's only going to get > worse as "Notes" gets used. > The length of those fields does not depend on the number of packages we have. We can have just a few, and be close to the maximum expected width. And unfiltered find is likely to get very busy indeed, because you'll always be hitting the worst possible width available for all fields. Eventually we should likely prevent that command from running altogether. Looking at my 16.04 installation for more relevant data, the max length for versions is 52, but the average is 12 and the median is 7. The output of unfiltered dpkg -l starts the summary at column 129, despite displaying only the name, version, arch, and summary. I don't think we can win if the goal is having meaningful output for everything under 80 columns. gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.lenton at canonical.com Wed May 25 16:36:34 2016 From: john.lenton at canonical.com (John Lenton) Date: Wed, 25 May 2016 17:36:34 +0100 Subject: snap list/find output In-Reply-To: References: Message-ID: I think we can do better than your proposal, but it's easier to implement than what I had in mind, and I'm running out of both time to do this and energy to argue the point. Going with yours as a first pass. On 25 May 2016 at 14:59, Gustavo Niemeyer wrote: > > > On Wed, May 25, 2016 at 5:43 AM, John Lenton > wrote: >> >> With your suggestion for "snap find" output, even with the paltry >> packages we have today, you already have just three characters left >> before the 80th column for summary, and a third of that width is used >> up for "version". That seems wrong to me, and it's only going to get >> worse as "Notes" gets used. > > > The length of those fields does not depend on the number of packages we > have. We can have just a few, and be close to the maximum expected width. > And unfiltered find is likely to get very busy indeed, because you'll always > be hitting the worst possible width available for all fields. Eventually we > should likely prevent that command from running altogether. > > Looking at my 16.04 installation for more relevant data, the max length for > versions is 52, but the average is 12 and the median is 7. The output of > unfiltered dpkg -l starts the summary at column 129, despite displaying only > the name, version, arch, and summary. > > I don't think we can win if the goal is having meaningful output for > everything under 80 columns. > > > gustavo @ http://niemeyer.net From gustavo.niemeyer at canonical.com Wed May 25 16:42:40 2016 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Wed, 25 May 2016 13:42:40 -0300 Subject: snap list/find output In-Reply-To: References: Message-ID: Thanks, John. And as usual, winning the argument is not the point. If you have ideas for how to improve on the proposal, please just shoot a branch or even just a mocked output and let's talk. On Wed, May 25, 2016 at 1:36 PM, John Lenton wrote: > I think we can do better than your proposal, but it's easier to > implement than what I had in mind, and I'm running out of both time to > do this and energy to argue the point. Going with yours as a first > pass. > > On 25 May 2016 at 14:59, Gustavo Niemeyer > wrote: > > > > > > On Wed, May 25, 2016 at 5:43 AM, John Lenton > > wrote: > >> > >> With your suggestion for "snap find" output, even with the paltry > >> packages we have today, you already have just three characters left > >> before the 80th column for summary, and a third of that width is used > >> up for "version". That seems wrong to me, and it's only going to get > >> worse as "Notes" gets used. > > > > > > The length of those fields does not depend on the number of packages we > > have. We can have just a few, and be close to the maximum expected width. > > And unfiltered find is likely to get very busy indeed, because you'll > always > > be hitting the worst possible width available for all fields. Eventually > we > > should likely prevent that command from running altogether. > > > > Looking at my 16.04 installation for more relevant data, the max length > for > > versions is 52, but the average is 12 and the median is 7. The output of > > unfiltered dpkg -l starts the summary at column 129, despite displaying > only > > the name, version, arch, and summary. > > > > I don't think we can win if the goal is having meaningful output for > > everything under 80 columns. > > > > > > gustavo @ http://niemeyer.net > > -- > Snapcraft mailing list > Snapcraft at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From seth.arnold at canonical.com Wed May 25 22:29:19 2016 From: seth.arnold at canonical.com (Seth Arnold) Date: Wed, 25 May 2016 15:29:19 -0700 Subject: snap list/find output In-Reply-To: References: Message-ID: <20160525222919.GA10350@hunt> On Wed, May 25, 2016 at 10:59:26AM -0300, Gustavo Niemeyer wrote: > Looking at my 16.04 installation for more relevant data, the max length for > versions is 52, but the average is 12 and the median is 7. The output of > unfiltered dpkg -l starts the summary at column 129, despite displaying > only the name, version, arch, and summary. > > I don't think we can win if the goal is having meaningful output for > everything under 80 columns. Is there anything we can do to encourage version numbers to be tolerably short? It's a new world after all and we can suggest best practices. Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: not available URL: From kirkland at canonical.com Wed May 25 22:54:09 2016 From: kirkland at canonical.com (Dustin Kirkland) Date: Wed, 25 May 2016 15:54:09 -0700 Subject: snap list/find output In-Reply-To: <20160525222919.GA10350@hunt> References: <20160525222919.GA10350@hunt> Message-ID: We should really be standardizing around (at least recommending) Semantic Versioning. See: semver.org On May 25, 2016 5:30 PM, "Seth Arnold" wrote: > On Wed, May 25, 2016 at 10:59:26AM -0300, Gustavo Niemeyer wrote: > > Looking at my 16.04 installation for more relevant data, the max length > for > > versions is 52, but the average is 12 and the median is 7. The output of > > unfiltered dpkg -l starts the summary at column 129, despite displaying > > only the name, version, arch, and summary. > > > > I don't think we can win if the goal is having meaningful output for > > everything under 80 columns. > > Is there anything we can do to encourage version numbers to be tolerably > short? It's a new world after all and we can suggest best practices. > > Thanks > > -- > Snapcraft mailing list > Snapcraft at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo.niemeyer at canonical.com Thu May 26 00:02:50 2016 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Wed, 25 May 2016 21:02:50 -0300 Subject: snap list/find output In-Reply-To: References: <20160525222919.GA10350@hunt> Message-ID: Hi Dustin, It's really not up to snapd to enforce that. The version field has basic reasonable constraints about what chars may be used and max length, but is otherwise free form. The question here was just whether we shorten the value for presentation when it becomes too long, and in that case we're getting to the conclusion that snapd may have an opinion because it will hurt everybody else to display excessively long values there. That said, the full version value will still be available via "snap show" or similar. On Wed, May 25, 2016 at 7:54 PM, Dustin Kirkland wrote: > We should really be standardizing around (at least recommending) Semantic > Versioning. See: semver.org > On May 25, 2016 5:30 PM, "Seth Arnold" wrote: > >> On Wed, May 25, 2016 at 10:59:26AM -0300, Gustavo Niemeyer wrote: >> > Looking at my 16.04 installation for more relevant data, the max length >> for >> > versions is 52, but the average is 12 and the median is 7. The output of >> > unfiltered dpkg -l starts the summary at column 129, despite displaying >> > only the name, version, arch, and summary. >> > >> > I don't think we can win if the goal is having meaningful output for >> > everything under 80 columns. >> >> Is there anything we can do to encourage version numbers to be tolerably >> short? It's a new world after all and we can suggest best practices. >> >> Thanks >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/snapcraft >> >> > -- > Snapcraft mailing list > Snapcraft at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo.niemeyer at canonical.com Wed May 25 22:45:39 2016 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Wed, 25 May 2016 19:45:39 -0300 Subject: snap list/find output In-Reply-To: <20160525222919.GA10350@hunt> References: <20160525222919.GA10350@hunt> Message-ID: Yes, we discussed this online today and one way to do this is precisely to go with what John suggests and shorten the version numbers that are unreasonable. That becomes a strong encouragement for them to remain short enough to be readable without additional commands. The only detail here is that we should be careful about how we shorten the versions. For example, assuming 1.23.45.6.7.8.9.10.11.12.13 We should shorten it as something along the lines of 1.23.45...12.13 Instead of, say, 1.23.4(...)2.13 or 1.23.45.6.7... (actual lengths TBD) Of course, there's always the chance that one decides to use a version that cannot be reasonably broken down like this, but then it sounds okay that they don't read as nicely either. On Wed, May 25, 2016 at 7:29 PM, Seth Arnold wrote: > On Wed, May 25, 2016 at 10:59:26AM -0300, Gustavo Niemeyer wrote: > > Looking at my 16.04 installation for more relevant data, the max length > for > > versions is 52, but the average is 12 and the median is 7. The output of > > unfiltered dpkg -l starts the summary at column 129, despite displaying > > only the name, version, arch, and summary. > > > > I don't think we can win if the goal is having meaningful output for > > everything under 80 columns. > > Is there anything we can do to encourage version numbers to be tolerably > short? It's a new world after all and we can suggest best practices. > > Thanks > > -- > Snapcraft mailing list > Snapcraft at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.ancell at canonical.com Thu May 26 04:19:32 2016 From: robert.ancell at canonical.com (Robert Ancell) Date: Thu, 26 May 2016 04:19:32 +0000 Subject: File-roller and snaps Message-ID: Hi all, I've added support to file-roller to view squashfs filesystems - this means you can now browse the contents of a .snap in Yakkety. See https://bugs.launchpad.net/bugs/1585867 for details. --Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Thu May 26 12:07:27 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Thu, 26 May 2016 13:07:27 +0100 Subject: File-roller and snaps In-Reply-To: References: Message-ID: <5746E6FF.3030500@ubuntu.com> On 26/05/16 05:19, Robert Ancell wrote: > I've added support to file-roller to view squashfs filesystems - this > means you can now browse the contents of a .snap in Yakkety. See > https://bugs.launchpad.net/bugs/1585867 for details. Great idea, thanks Robert! Once it's stable would it be worth SRUing to Xenial? Mark From gustavo.niemeyer at canonical.com Thu May 26 13:52:49 2016 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Thu, 26 May 2016 10:52:49 -0300 Subject: File-roller and snaps In-Reply-To: References: Message-ID: Very nice, thank you! On Thu, May 26, 2016 at 1:19 AM, Robert Ancell wrote: > Hi all, > > I've added support to file-roller to view squashfs filesystems - this > means you can now browse the contents of a .snap in Yakkety. See > https://bugs.launchpad.net/bugs/1585867 for details. > > --Robert > > -- > Snapcraft mailing list > Snapcraft at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.ancell at canonical.com Thu May 26 21:08:22 2016 From: robert.ancell at canonical.com (Robert Ancell) Date: Thu, 26 May 2016 21:08:22 +0000 Subject: File-roller and snaps In-Reply-To: <5746E6FF.3030500@ubuntu.com> References: <5746E6FF.3030500@ubuntu.com> Message-ID: Yes, I was going to wait for upstream to ack the patches and confirm no issues in Yakkety then SRU it. On Fri, May 27, 2016 at 12:07 AM Mark Shuttleworth wrote: > On 26/05/16 05:19, Robert Ancell wrote: > > I've added support to file-roller to view squashfs filesystems - this > > means you can now browse the contents of a .snap in Yakkety. See > > https://bugs.launchpad.net/bugs/1585867 for details. > > Great idea, thanks Robert! Once it's stable would it be worth SRUing to > Xenial? > > Mark > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alfonso.sanchez-beato at canonical.com Fri May 27 13:10:56 2016 From: alfonso.sanchez-beato at canonical.com (Alfonso Sanchez-Beato) Date: Fri, 27 May 2016 15:10:56 +0200 Subject: Auto-connect when installing compatible snaps Message-ID: Hi list, Which is the current status of the auto-connect story? Currently we are working on network-manager and modem-manager snaps, which ideally should connect compatible plugs/slots when both are installed in the system (this is indeed just one scenario for this feature). Otherwise we need to 1. Install both 2. Connect plugs to slots 3. Re-start services (due to apparmor denials when trying to register for tracking DBus name for partner before connection is established) Br, Alfonso -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamie at canonical.com Fri May 27 16:17:04 2016 From: jamie at canonical.com (Jamie Strandboge) Date: Fri, 27 May 2016 11:17:04 -0500 Subject: Auto-connect when installing compatible snaps In-Reply-To: References: Message-ID: <1464365824.3666.18.camel@canonical.com> On Fri, 2016-05-27 at 15:10 +0200, Alfonso Sanchez-Beato wrote: > Hi list, > > Which is the current status of the auto-connect story? Currently we are > working on network-manager and modem-manager snaps, which ideally should > connect compatible plugs/slots when both are installed in the system (this > is indeed just one scenario for this feature). > > Otherwise we need to > 1. Install both > 2. Connect plugs to slots > 3. Re-start services (due to apparmor denials when trying to register for > tracking DBus name for partner before connection is established) > Zyga can correct me here as needed but how it is supposed to work is that the network-manager interface is supposed to define enough in its PermanentSlot security policy to allow a snap providing the slot to run upon install (ie, permanent slot policy can be thought of as auto-connected on install). When another snap plugs into the network-manager slot, the ConnectedSlot policy is added to the snap providing the slot and the ConnectedPlug policy is added to the plugging snap. When that happens, the security policy is reloaded into the kernel for both sides and the snap providing the slot should not have to be restarted. If this isn't working for you, please file a bug. Depending on how your plugging service is written, it may need to be restarted, but it could be written in such a way as to (politely) keep trying until it is connected. As for auto-connections in general, decisions to auto-connect or not are made on a case by case basis between the snappy architects (Gustavo), snappy (zyga) and security (typically me) teams. This is something we are actively working through and there will be quite a few improvements in this area. For the moment for network-manager in particular, you need to install both and do one 'slot connect' operation. -- Jamie Strandboge | http://www.canonical.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From zygmunt.krynicki at canonical.com Fri May 27 17:18:49 2016 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Fri, 27 May 2016 19:18:49 +0200 Subject: Auto-connect when installing compatible snaps In-Reply-To: <1464365824.3666.18.camel@canonical.com> References: <1464365824.3666.18.camel@canonical.com> Message-ID: On Fri, May 27, 2016 at 6:17 PM, Jamie Strandboge wrote: > On Fri, 2016-05-27 at 15:10 +0200, Alfonso Sanchez-Beato wrote: >> Hi list, >> >> Which is the current status of the auto-connect story? Currently we are >> working on network-manager and modem-manager snaps, which ideally should >> connect compatible plugs/slots when both are installed in the system (this >> is indeed just one scenario for this feature). >> >> Otherwise we need to >> 1. Install both >> 2. Connect plugs to slots >> 3. Re-start services (due to apparmor denials when trying to register for >> tracking DBus name for partner before connection is established) >> > > Zyga can correct me here as needed but how it is supposed to work is that the > network-manager interface is supposed to define enough in its PermanentSlot > security policy to allow a snap providing the slot to run upon install (ie, > permanent slot policy can be thought of as auto-connected on install). When > another snap plugs into the network-manager slot, the ConnectedSlot policy is > added to the snap providing the slot and the ConnectedPlug policy is added to > the plugging snap. When that happens, the security policy is reloaded into the > kernel for both sides and the snap providing the slot should not have to be > restarted. If this isn't working for you, please file a bug. Depending on how > your plugging service is written, it may need to be restarted, but it could be > written in such a way as to (politely) keep trying until it is connected. That is accurate. For network manager you should not need to connect to the slot for the service to function properly. > As for auto-connections in general, decisions to auto-connect or not are made on > a case by case basis between the snappy architects (Gustavo), snappy (zyga) and > security (typically me) teams. This is something we are actively working through > and there will be quite a few improvements in this area. For the moment for > network-manager in particular, you need to install both and do one 'slot > connect' operation. I think that for n-m we should consider auto-connecting the tool to the service but this is obviously not invalidating what I said above about permanent slot snippet. In general I would also auto-connect compatible plug/slots from within one snap, on install. Thanks ZK From ted at ubuntu.com Fri May 27 17:22:39 2016 From: ted at ubuntu.com (Ted Gould) Date: Fri, 27 May 2016 12:22:39 -0500 Subject: Interface for Snappy Apps that understand Unity8 Application Lifecycle Message-ID: <1464369759.5091.4.camel@ubuntu.com> Hello, We need to understand which apps understand the Unity8 application lifecycle so that we don't try to manage apps that aren't designed with an application lifecycle in mind. I've gone ahead and proposed a PR just to get the name started, though I imagine it'll have more features in the future as we continue to develop it. It is the first step (with many more in the future) in moving towards getting Snappy apps working with Unity8. https://github.com/snapcore/snapd/pull/1229 Ted##SELECTION_END## -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From gustavo.niemeyer at canonical.com Fri May 27 17:40:55 2016 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Fri, 27 May 2016 14:40:55 -0300 Subject: Interface for Snappy Apps that understand Unity8 Application Lifecycle In-Reply-To: <1464369759.5091.4.camel@ubuntu.com> References: <1464369759.5091.4.camel@ubuntu.com> Message-ID: Can we please go into more detail about what it means to support the application lifecycle? Having an interface that does absolutely nothing feels somewhat awkward, which may hint that there are better designs for it. On Fri, May 27, 2016 at 2:22 PM, Ted Gould wrote: > Hello, > > We need to understand which apps understand the Unity8 application > lifecycle so that we don't try to manage apps that aren't designed with an > application lifecycle in mind. I've gone ahead and proposed a PR just to > get the name started, though I imagine it'll have more features in the > future as we continue to develop it. It is the first step (with many more > in the future) in moving towards getting Snappy apps working with Unity8. > > https://github.com/snapcore/snapd/pull/1229 > > Ted > > -- > Snapcraft mailing list > Snapcraft at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From ted at ubuntu.com Fri May 27 17:48:16 2016 From: ted at ubuntu.com (Ted Gould) Date: Fri, 27 May 2016 12:48:16 -0500 Subject: Interface for Snappy Apps that understand Unity8 Application Lifecycle In-Reply-To: References: <1464369759.5091.4.camel@ubuntu.com> Message-ID: <1464371296.5091.9.camel@ubuntu.com> In a nutshell, it is listening to a set commands that are sent via the Mir connection from QtMir/Unity8 which correspond with the different states that an application is put in. As an example, it is told when it is about to be suspended so that the application can save data in memory to disk. For QML/Qt apps this is implemented in the QPA plugin. Applications that do not speak this protocol could lose user data if they were killed by Unity8 and didn't realize they needed to use their chance to save. Ted On Fri, 2016-05-27 at 14:40 -0300, Gustavo Niemeyer wrote: > Can we please go into more detail about what it means to support the > application lifecycle? > > Having an interface that does absolutely nothing feels somewhat > awkward, which may hint that there are better designs for it. > > On Fri, May 27, 2016 at 2:22 PM, Ted Gould wrote: > > Hello, > > > > We need to understand which apps understand the Unity8 application > > lifecycle so that we don't try to manage apps that aren't designed > > with an application lifecycle in mind. I've gone ahead and proposed > > a PR just to get the name started, though I imagine it'll have more > > features in the future as we continue to develop it. It is the > > first step (with many more in the future) in moving towards getting > > Snappy apps working with Unity8. > > > > https://github.com/snapcore/snapd/pull/1229 > > > > Ted > > > > -- > > Snapcraft mailing list > > Snapcraft at lists.ubuntu.com > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman > > /listinfo/snapcraft > > > > > --  > gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From gustavo.niemeyer at canonical.com Fri May 27 19:06:35 2016 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Fri, 27 May 2016 16:06:35 -0300 Subject: Interface for Snappy Apps that understand Unity8 Application Lifecycle In-Reply-To: <1464371296.5091.9.camel@ubuntu.com> References: <1464369759.5091.4.camel@ubuntu.com> <1464371296.5091.9.camel@ubuntu.com> Message-ID: The interface you proposed didn't add any special abilities for the snap to listen to additional events from the system. Isn't that about the unity8 interface itself? On Fri, May 27, 2016 at 2:48 PM, Ted Gould wrote: > > In a nutshell, it is listening to a set commands that are sent via the Mir > connection from QtMir/Unity8 which correspond with the different states > that an application is put in. As an example, it is told when it is about > to be suspended so that the application can save data in memory to disk. > For QML/Qt apps this is implemented in the QPA plugin. Applications that do > not speak this protocol could lose user data if they were killed by Unity8 > and didn't realize they needed to use their chance to save. > > Ted > > On Fri, 2016-05-27 at 14:40 -0300, Gustavo Niemeyer wrote: > > Can we please go into more detail about what it means to support the > application lifecycle? > > Having an interface that does absolutely nothing feels somewhat awkward, > which may hint that there are better designs for it. > > On Fri, May 27, 2016 at 2:22 PM, Ted Gould wrote: > > Hello, > > We need to understand which apps understand the Unity8 application > lifecycle so that we don't try to manage apps that aren't designed with an > application lifecycle in mind. I've gone ahead and proposed a PR just to > get the name started, though I imagine it'll have more features in the > future as we continue to develop it. It is the first step (with many more > in the future) in moving towards getting Snappy apps working with Unity8. > > https://github.com/snapcore/snapd/pull/1229 > > Ted > > -- > Snapcraft mailing list > Snapcraft at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > -- > gustavo @ http://niemeyer.net > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob.ryan.humphrey at gmail.com Fri May 27 19:40:00 2016 From: jacob.ryan.humphrey at gmail.com (Jacob Humphrey) Date: Fri, 27 May 2016 14:40:00 -0500 Subject: Snap vs Snappy Message-ID: <5748A290.3010202@gmail.com> Hello, I'm sorry if this has already been covered, but I couldn't find anything in the archives. Currently the snapd package for xenial contains the command "snap", which is used to manage snaps; however all of the documentation on the Ubuntu site refer to the command "snappy", which has the same purpose, but slightly different syntax. Is there a reason we have these two commands for the same purpose? Also, if "snap" is the command that is used in xenial, why do we not have documentation for it? I'd appreciate any clarification on this matter. Thank you, Jacob Humphrey From ted at ubuntu.com Fri May 27 19:43:53 2016 From: ted at ubuntu.com (Ted Gould) Date: Fri, 27 May 2016 14:43:53 -0500 Subject: Interface for Snappy Apps that understand Unity8 Application Lifecycle In-Reply-To: References: <1464369759.5091.4.camel@ubuntu.com> <1464371296.5091.9.camel@ubuntu.com> Message-ID: <1464378232.5091.12.camel@ubuntu.com> Ah, good point, we should also put with this permission access to the Mir socket that Unity8 creates. I'll figure out how to do that and update the PR. Is there anything else you'd like to see in the PR? Ted On Fri, 2016-05-27 at 16:06 -0300, Gustavo Niemeyer wrote: > > The interface you proposed didn't add any special abilities for the > snap to listen to additional events from the system. > > Isn't that about the unity8 interface itself? > > > On Fri, May 27, 2016 at 2:48 PM, Ted Gould wrote: > > > > In a nutshell, it is listening to a set commands that are sent via > > the Mir connection from QtMir/Unity8 which correspond with the > > different states that an application is put in. As an example, it > > is told when it is about to be suspended so that the application > > can save data in memory to disk. For QML/Qt apps this is > > implemented in the QPA plugin. Applications that do not speak this > > protocol could lose user data if they were killed by Unity8 and > > didn't realize they needed to use their chance to save. > > > > Ted > > > > On Fri, 2016-05-27 at 14:40 -0300, Gustavo Niemeyer wrote: > > > Can we please go into more detail about what it means to support > > > the application lifecycle? > > > > > > Having an interface that does absolutely nothing feels somewhat > > > awkward, which may hint that there are better designs for it. > > > > > > On Fri, May 27, 2016 at 2:22 PM, Ted Gould > > > wrote: > > > > Hello, > > > > > > > > We need to understand which apps understand the Unity8 > > > > application lifecycle so that we don't try to manage apps that > > > > aren't designed with an application lifecycle in mind. I've > > > > gone ahead and proposed a PR just to get the name started, > > > > though I imagine it'll have more features in the future as we > > > > continue to develop it. It is the first step (with many more in > > > > the future) in moving towards getting Snappy apps working with > > > > Unity8. > > > > > > > > https://github.com/snapcore/snapd/pull/1229 > > > > > > > > Ted > > > > > > > > -- > > > > Snapcraft mailing list > > > > Snapcraft at lists.ubuntu.com > > > > Modify settings or unsubscribe at: https://lists.ubuntu.com/mai > > > > lman/listinfo/snapcraft > > > > > > > > > > > > > --  > > > gustavo @ http://niemeyer.net > > > --  > gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From leo.arias at canonical.com Fri May 27 19:44:35 2016 From: leo.arias at canonical.com (Leo Arias) Date: Fri, 27 May 2016 13:44:35 -0600 Subject: Snap vs Snappy In-Reply-To: <5748A290.3010202@gmail.com> References: <5748A290.3010202@gmail.com> Message-ID: <5748A3A3.7020803@canonical.com> Hello! On 2016-05-27 13:40, Jacob Humphrey wrote: > I'm sorry if this has already been covered, but I couldn't find > anything in the archives. Currently the snapd package for xenial > contains the command "snap", which is used to manage snaps; however all > of the documentation on the Ubuntu site refer to the command "snappy", > which has the same purpose, but slightly different syntax. > > Is there a reason we have these two commands for the same purpose? > Also, if "snap" is the command that is used in xenial, why do we not > have documentation for it? I'd appreciate any clarification on this matter. snappy was the name of the command in 15.04. It was renamed to snap in 16.04. We are still updating the new documentation in the site, sorry about it! pura vida. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From gustavo.niemeyer at canonical.com Fri May 27 19:46:44 2016 From: gustavo.niemeyer at canonical.com (Gustavo Niemeyer) Date: Fri, 27 May 2016 16:46:44 -0300 Subject: Interface for Snappy Apps that understand Unity8 Application Lifecycle In-Reply-To: <1464378232.5091.12.camel@ubuntu.com> References: <1464369759.5091.4.camel@ubuntu.com> <1464371296.5091.9.camel@ubuntu.com> <1464378232.5091.12.camel@ubuntu.com> Message-ID: It should also be named "unity8" if that's what it is, and should also contain every other aspect that a unity8 application will need to work. Best place to start is the unity7 interface, and also a catch up jdstrand online would certainly help raising points I'm missing. On Fri, May 27, 2016 at 4:43 PM, Ted Gould wrote: > > Ah, good point, we should also put with this permission access to the Mir > socket that Unity8 creates. I'll figure out how to do that and update the > PR. > > Is there anything else you'd like to see in the PR? > > Ted > > On Fri, 2016-05-27 at 16:06 -0300, Gustavo Niemeyer wrote: > > > The interface you proposed didn't add any special abilities for the snap > to listen to additional events from the system. > > Isn't that about the unity8 interface itself? > > > On Fri, May 27, 2016 at 2:48 PM, Ted Gould wrote: > > > In a nutshell, it is listening to a set commands that are sent via the Mir > connection from QtMir/Unity8 which correspond with the different states > that an application is put in. As an example, it is told when it is about > to be suspended so that the application can save data in memory to disk. > For QML/Qt apps this is implemented in the QPA plugin. Applications that do > not speak this protocol could lose user data if they were killed by Unity8 > and didn't realize they needed to use their chance to save. > > Ted > > On Fri, 2016-05-27 at 14:40 -0300, Gustavo Niemeyer wrote: > > Can we please go into more detail about what it means to support the > application lifecycle? > > Having an interface that does absolutely nothing feels somewhat awkward, > which may hint that there are better designs for it. > > On Fri, May 27, 2016 at 2:22 PM, Ted Gould wrote: > > Hello, > > We need to understand which apps understand the Unity8 application > lifecycle so that we don't try to manage apps that aren't designed with an > application lifecycle in mind. I've gone ahead and proposed a PR just to > get the name started, though I imagine it'll have more features in the > future as we continue to develop it. It is the first step (with many more > in the future) in moving towards getting Snappy apps working with Unity8. > > https://github.com/snapcore/snapd/pull/1229 > > Ted > > -- > Snapcraft mailing list > Snapcraft at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > -- > gustavo @ http://niemeyer.net > > > > > > -- > gustavo @ http://niemeyer.net > > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From gustavo at niemeyer.net Fri May 27 19:44:04 2016 From: gustavo at niemeyer.net (Gustavo Niemeyer) Date: Fri, 27 May 2016 16:44:04 -0300 Subject: Snap vs Snappy In-Reply-To: <5748A290.3010202@gmail.com> References: <5748A290.3010202@gmail.com> Message-ID: Hi Jacob, The snappy command was part of the ancient Ubuntu Core release. Nowdays all we have is "snap", which is just a client of snapd. Documentation must be ported indeed. Sorry for the confusion. On Fri, May 27, 2016 at 4:40 PM, Jacob Humphrey < jacob.ryan.humphrey at gmail.com> wrote: > Hello, > > I'm sorry if this has already been covered, but I couldn't find > anything in the archives. Currently the snapd package for xenial contains > the command "snap", which is used to manage snaps; however all of the > documentation on the Ubuntu site refer to the command "snappy", which has > the same purpose, but slightly different syntax. > > Is there a reason we have these two commands for the same purpose? > Also, if "snap" is the command that is used in xenial, why do we not have > documentation for it? I'd appreciate any clarification on this matter. > > Thank you, > Jacob Humphrey > > > > -- > Snapcraft mailing list > Snapcraft at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -- gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From jacob.ryan.humphrey at gmail.com Fri May 27 20:14:48 2016 From: jacob.ryan.humphrey at gmail.com (Jacob Humphrey) Date: Fri, 27 May 2016 15:14:48 -0500 Subject: Snap vs Snappy In-Reply-To: References: <5748A290.3010202@gmail.com> Message-ID: <5748AAB8.4070806@gmail.com> Hi, Thank you Gustavo and Leo for clearing that up. Is there anything I can do to help speed up the creation of the new documentation? On 05/27/2016 02:44 PM, Gustavo Niemeyer wrote: > Hi Jacob, > > The snappy command was part of the ancient Ubuntu Core release. > Nowdays all we have is "snap", which is just a client of snapd. > > Documentation must be ported indeed. Sorry for the confusion. > > > On Fri, May 27, 2016 at 4:40 PM, Jacob Humphrey > > > wrote: > > Hello, > > I'm sorry if this has already been covered, but I couldn't > find anything in the archives. Currently the snapd package for > xenial contains the command "snap", which is used to manage snaps; > however all of the documentation on the Ubuntu site refer to the > command "snappy", which has the same purpose, but slightly > different syntax. > > Is there a reason we have these two commands for the same > purpose? Also, if "snap" is the command that is used in xenial, > why do we not have documentation for it? I'd appreciate any > clarification on this matter. > > Thank you, > Jacob Humphrey > > > > -- > Snapcraft mailing list > Snapcraft at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > > > > -- > > gustavo @ http://niemeyer.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Sat May 28 04:45:12 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Sat, 28 May 2016 05:45:12 +0100 Subject: Snap vs Snappy In-Reply-To: <5748AAB8.4070806@gmail.com> References: <5748A290.3010202@gmail.com> <5748AAB8.4070806@gmail.com> Message-ID: <57492258.9030905@ubuntu.com> On 27/05/16 21:14, Jacob Humphrey wrote: > Thank you Gustavo and Leo for clearing that up. Is there anything > I can do to help speed up the creation of the new documentation? Welcome aboard, Jason! It's really helpful to see documents through the eyes of someone fresh to the project, so any contributions you make there would be very welcome indeed. I'm working on a new step-by-step tour of snapcraft in a google doc, will share that with you shortly and any contributions you care to make will be most appreciated. Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From michal.sawicz at canonical.com Mon May 30 12:23:13 2016 From: michal.sawicz at canonical.com (=?UTF-8?Q?Micha=c5=82_Sawicz?=) Date: Mon, 30 May 2016 14:23:13 +0200 Subject: Interface for Snappy Apps that understand Unity8 Application Lifecycle In-Reply-To: <1464371296.5091.9.camel@ubuntu.com> References: <1464369759.5091.4.camel@ubuntu.com> <1464371296.5091.9.camel@ubuntu.com> Message-ID: <574C30B1.5080109@canonical.com> W dniu 27.05.2016 o 19:48, Ted Gould pisze: > In a nutshell, it is listening to a set commands that are sent via the > Mir connection from QtMir/Unity8 which correspond with the different > states that an application is put in. As an example, it is told when it > is about to be suspended so that the application can save data in memory > to disk. For QML/Qt apps this is implemented in the QPA plugin. > Applications that do not speak this protocol could lose user data if > they were killed by Unity8 and didn't realize they needed to use their > chance to save. I just wonder if this is anything really unity8-specific. We've not created special APIs (at least not compared to Qt ones), we're not actively killing apps for no reason, it's just that we're more resource constrained and OOM killer kicks in quicker. When closing apps, we do tell apps, after waking them, when the user closes them, so they know they need to save data (we're not giving them a chance to prevent closing, at least not yet). Well-behaved apps (LibreOffice, Firefox) do this already by periodically saving restore information, would you consider those as "supporting the unity8 lifecycle"? -- Michał Sawicz Canonical Ltd. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From fcdoth at gmail.com Mon May 30 16:26:48 2016 From: fcdoth at gmail.com (Fernando Correa Neto) Date: Mon, 30 May 2016 16:26:48 +0000 Subject: My journal on Snappy/RPi3 Message-ID: Hi there. Just wanted to let you know that I've decided to keep track of all my Snappy/RPi3 testing over https://medium.com/@fcorrea It might be interesting for those going through the same adventures as I am ;) Regards, Fernando -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at ubuntu.com Mon May 30 16:40:10 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Mon, 30 May 2016 17:40:10 +0100 Subject: My journal on Snappy/RPi3 In-Reply-To: References: Message-ID: <574C6CEA.90103@ubuntu.com> Thanks Fernando! I look forward to fixing the rough spots you run into and mostly look forward to you having happy users of your snaps :) Mark On 30/05/16 17:26, Fernando Correa Neto wrote: > Hi there. > > Just wanted to let you know that I've decided to keep track of all my > Snappy/RPi3 testing over https://medium.com/@fcorrea > It might be interesting for those going through the same adventures as > I am ;) > > Regards, > Fernando > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ogra at ubuntu.com Mon May 30 17:49:22 2016 From: ogra at ubuntu.com (Oliver Grawert) Date: Mon, 30 May 2016 19:49:22 +0200 Subject: My journal on Snappy/RPi3 In-Reply-To: References: Message-ID: <1464630562.7961.3.camel@ubuntu.com> hi, On Mo, 2016-05-30 at 16:26 +0000, Fernando Correa Neto wrote: > Hi there. > > Just wanted to let you know that I've decided to keep track of all my > Snappy/RPi3 testing over https://medium.com/@fcorrea > It might be interesting for those going through the same adventures > as I am ;) > note that we are working on getting the missing firmware files into our kernel snap by default. great to see that you got it all working in the end, even though we are still a bit away from finalized images  :)  ciao oli -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From sergio.schvezov at canonical.com Mon May 30 21:01:19 2016 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Mon, 30 May 2016 18:01:19 -0300 Subject: ANN: snapcraft 2.9 is now available Message-ID: <574CAA1F.2080408@ubuntu.com> Hello snapcrafters! We are pleased to announce the release of version 2.9 of snapcraft: https://launchpad.net/snapcraft/+milestone/2.9 This is the first release since Xenial Xerus 16.04 has been released. - A `confinement` property which indicates if the snap should be installed with devmode to function (for snaps still under development but worth sharing out) or strictly confined. - Implemented support for upcoming epoch feature that will enable snaps to perform stepped upgrades through critical revisions. - Bash completion for snapcraft commands. With this release and a point release for 2.8 there have been many polishing bug fixes. Polish is one of the main focuses for snapcraft now. Please refer to the changelog on the milestone page to read about these "micro" improvements. To consume the latest snapcraft release on Xenial Xerus (16.04), we suggest you install the snapcraft package from the Ubuntu Archives: sudo apt update sudo apt install snapcraft To get the source for this release check it out at https://github.com/ubuntu-core/snapcraft/releases/tag/2.9 A great place to collaborate and discuss features, bugs and ideas on snapcraft is snapcraft at lists.ubuntu.com mailing list or directly in the #snappy channel on irc.freenode.net. To file bugs, please go to https://bugs.launchpad.net/snapcraft/+filebug. Last but not least the team thanks all the external contributions seen so far! Happy snapcrafting, - Sergio and the team -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From peter.chen at lemaker.com Tue May 31 08:33:21 2016 From: peter.chen at lemaker.com (peter.chen at lemaker.com) Date: Tue, 31 May 2016 16:33:21 +0800 Subject: snappy: Command not found Message-ID: <2016053116332091784010@lemaker.com> Hi, All I want to port the snappy ubuntu to the LeMaker Gutiar refer to the project at https://github.com/xapp-le/SnappyUbuntuCore . I have read the README from the project ,and pre-installed some software which it mentioned on the ubuntu 16.04. However, It failed when i run the command "make gadget", and output error info "snappy: Command not found" . How do i install the snappy command on the ubuntu 16.04 ? Look forward to your reply, Thanks. Best Regards Peter Chen Making Innovation Easy LeMaker Team -- The Professional Makers for Hardware and Software Customization. Address: B1002, SIAT campus, Shenzhen University Town, Shenzhen, China Post Code: 518055 Tel: 0755-36330749 Email: support at lemaker.org (Technical Support) product at lemaker.org (Product Distribution) http://www.lemaker.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 6594_6594_6594_clip_i(07-13-12-20-59).jpg Type: image/jpeg Size: 6594 bytes Desc: not available URL: From zygmunt.krynicki at canonical.com Tue May 31 08:41:42 2016 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Tue, 31 May 2016 10:41:42 +0200 Subject: snappy: Command not found In-Reply-To: <2016053116332091784010@lemaker.com> References: <2016053116332091784010@lemaker.com> Message-ID: On Tue, May 31, 2016 at 10:33 AM, peter.chen at lemaker.com < peter.chen at lemaker.com> wrote: > Hi, All > I want to port the snappy ubuntu to the LeMaker Gutiar refer to the > project at https://github.com/xapp-le/SnappyUbuntuCore > . > I have read the README from the project ,and pre-installed some software > which it mentioned on the ubuntu 16.04. However, > It failed when i run the command "make gadget", and output error info *"* > *snappy: Command not found"* . How do i install the *snappy *command on > the ubuntu 16.04 ? > Hi In 16.04 the command is called "snap". Having said that instruction on the github repository may need tweaking (I didn't try building that). The "snap" command is pre-installed on ubuntu so you should have it available out of the box. Best regards ZK -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.chen at lemaker.com Tue May 31 08:58:22 2016 From: peter.chen at lemaker.com (peter.chen at lemaker.com) Date: Tue, 31 May 2016 16:58:22 +0800 Subject: snappy: Command not found References: <2016053116332091784010@lemaker.com>, Message-ID: <2016053116582198985027@lemaker.com> Hi, ZK The project use the command below in the SnappyUbuntuCore/builder/gadget.mk : snappy: snappy build gadget However, the newer command snap didn't support the same option: snap build gadget And i should how to use it ? Thanks. BR Peter Chen Making Innovation Easy LeMaker Team -- The Professional Makers for Hardware and Software Customization. Address: B1002, SIAT campus, Shenzhen University Town, Shenzhen, China Post Code: 518055 Tel: 0755-36330749 Email: support at lemaker.org (Technical Support) product at lemaker.org (Product Distribution) http://www.lemaker.org/ From: Zygmunt Krynicki Date: 2016-05-31 16:41 To: peter.chen at lemaker.com CC: snapcraft; 张腾 Subject: Re: snappy: Command not found On Tue, May 31, 2016 at 10:33 AM, peter.chen at lemaker.com wrote: Hi, All I want to port the snappy ubuntu to the LeMaker Gutiar refer to the project at https://github.com/xapp-le/SnappyUbuntuCore . I have read the README from the project ,and pre-installed some software which it mentioned on the ubuntu 16.04. However, It failed when i run the command "make gadget", and output error info "snappy: Command not found" . How do i install the snappy command on the ubuntu 16.04 ? Hi In 16.04 the command is called "snap". Having said that instruction on the github repository may need tweaking (I didn't try building that). The "snap" command is pre-installed on ubuntu so you should have it available out of the box. Best regards ZK -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 6594_6594_6594_clip_i(07-13-12-20-59).jpg Type: image/jpeg Size: 6594 bytes Desc: not available URL: From zygmunt.krynicki at canonical.com Tue May 31 08:59:46 2016 From: zygmunt.krynicki at canonical.com (Zygmunt Krynicki) Date: Tue, 31 May 2016 10:59:46 +0200 Subject: snappy: Command not found In-Reply-To: <2016053116582198985027@lemaker.com> References: <2016053116332091784010@lemaker.com> <2016053116582198985027@lemaker.com> Message-ID: On Tue, May 31, 2016 at 10:58 AM, peter.chen at lemaker.com < peter.chen at lemaker.com> wrote: > Hi, ZK > The project use the command below in the *SnappyUbuntuCore/builder/**gadget.mk > * : > > *snappy: snappy build gadget* > > However, the newer command *snap *didn't support the same option: > * snap build gadget* > > And i should how to use it ? Thanks. > There are some subtle differences between the two. Let me check that repository out and get back to you. Best regards ZK -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.chen at lemaker.com Tue May 31 09:03:14 2016 From: peter.chen at lemaker.com (peter.chen at lemaker.com) Date: Tue, 31 May 2016 17:03:14 +0800 Subject: snappy: Command not found References: <2016053116332091784010@lemaker.com>, , <2016053116582198985027@lemaker.com>, Message-ID: <2016053117031460440628@lemaker.com> Hi, ZK Thank you . Best Regards Peter Chen Making Innovation Easy LeMaker Team -- The Professional Makers for Hardware and Software Customization. Address: B1002, SIAT campus, Shenzhen University Town, Shenzhen, China Post Code: 518055 Tel: 0755-36330749 Email: support at lemaker.org (Technical Support) product at lemaker.org (Product Distribution) http://www.lemaker.org/ From: Zygmunt Krynicki Date: 2016-05-31 16:59 To: peter.chen at lemaker.com CC: snapcraft; 张腾 Subject: Re: Re: snappy: Command not found On Tue, May 31, 2016 at 10:58 AM, peter.chen at lemaker.com wrote: Hi, ZK The project use the command below in the SnappyUbuntuCore/builder/gadget.mk : snappy: snappy build gadget However, the newer command snap didn't support the same option: snap build gadget And i should how to use it ? Thanks. There are some subtle differences between the two. Let me check that repository out and get back to you. Best regards ZK -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 6594_6594_6594_clip_i(07-13-12-20-59).jpg Type: image/jpeg Size: 6594 bytes Desc: not available URL: From ogra at ubuntu.com Tue May 31 09:51:53 2016 From: ogra at ubuntu.com (Oliver Grawert) Date: Tue, 31 May 2016 11:51:53 +0200 Subject: snappy: Command not found In-Reply-To: <2016053116332091784010@lemaker.com> References: <2016053116332091784010@lemaker.com> Message-ID: <1464688313.30150.45.camel@anubis> Am Dienstag, den 31.05.2016, 16:33 +0800 schrieb peter.chen at lemaker.com: > Hi, All > I want to port the snappy ubuntu to the LeMaker Gutiar refer to the > project at https://github.com/xapp-le/SnappyUbuntuCore . > I have read the README from the project ,and pre-installed some > software which it mentioned on the ubuntu 16.04. However, > It failed when i run the command "make gadget", and output error info > "snappy: Command not found" . How do i install the snappy command on > the ubuntu 16.04 ? looking at your tree, there is a lot more you need to change: in the 16 series the package.yaml files are gone (and replaced by snap.yaml files with a slightly different syntax). snappy can not build any snap packages anymore (it turned into a management-only tool). for building you need to use snapcraft on a 16.04 install (can be a chroot) now ... (the direct equivalent of "snappy build" would be "snapcraft snap", specifically for the kernel you probably want to use a full snapcraft build process using the snapcraft kernel plugin though) looking at your yaml files within the kernel and gadget dirs, snappy-ab is also gone. everything is a snap now (which essentially means: a squashfs file) and all these snaps live on a single writable partition and get loop mounted on demand (this includes kernel and os snap), this made the A/B partitioning setup obsolete (make sure to use the latest ubuntu-device-flash binary from [1], it creates the right partitioning by default). at [2] you can find the code for the currently used raspberry pi2 gadget snap, it shouldnt be to hard to adapt the meta data of your gadget according to the snap.yaml there. note that some things changed, specifically for u-boot. we stopped using/supporting any txt files to manage the auto-reboot and upgrade management, all config needs to live in a uboot.env binary blob now. there is a README in the above tree that explains how to create it, as well as the uboot.env.in file that we use as input for this. a few build config changes are also required to make the uboot.env blob work, the patch we use on top of the upstream u-boot tree can be found at [3]. regarding the kernel, there is a snapcraft example for building a 96boards kernel at [4], that should get you going... i guess the above should help you to start moving forward in the right direction, don't hold back on the further questions you will surely have, just drop them here ;) ciao oli [1] http://people.canonical.com/~mvo/all-snaps/ [2] http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files/head:/pi2/ [3] http://paste.ubuntu.com/16199863/ [4] https://github.com/ubuntu-core/snapcraft/tree/master/demos/96boards-kernel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part URL: From anthony.wong at canonical.com Tue May 31 10:27:29 2016 From: anthony.wong at canonical.com (Anthony Wong) Date: Tue, 31 May 2016 18:27:29 +0800 Subject: snappy: Command not found Message-ID: Hi Peter, It will be easier if you follow how we enabled the hikey board for demo, because that's for Ubuntu Core 16. You can find the kernel and the associated snapcraft.yaml to build the kernel snap at https://code.launchpad.net/~canonical-hwe-team/+git/hikey_linux and the gadget snap at https://code.launchpad.net/~canonical-hwe-team/+git/hikey_gadget_snap. More details on bringing the board up can be found here . Happy snapping! Anthony -- Anthony Wong Engineering Manager, Hardware Enablement Canonical Ltd. www.canonical.com On 31 May 2016 at 17:03, peter.chen at lemaker.com wrote: > Hi, ZK > Thank you . > > Best Regards > ------------------------------ > > *Peter Chen* > > > *Making Innovation EasyLeMaker Team -- The Professional Makers for > Hardware and Software Customization.* > > Address: B1002, SIAT campus, Shenzhen University Town, Shenzhen, China > Post Code: 518055 > > Tel: 0755-36330749 > > Email: > support at lemaker.org (Technical Support) > product at lemaker.org (Product Distribution) > > > > > http://www.lemaker.org/ > > > *From:* Zygmunt Krynicki > *Date:* 2016-05-31 16:59 > *To:* peter.chen at lemaker.com > *CC:* snapcraft ; 张腾 > *Subject:* Re: Re: snappy: Command not found > > > On Tue, May 31, 2016 at 10:58 AM, peter.chen at lemaker.com < > peter.chen at lemaker.com> wrote: > >> Hi, ZK >> The project use the command below in the *SnappyUbuntuCore/builder/**gadget.mk >> * : >> >> *snappy: snappy build gadget* >> >> However, the newer command *snap *didn't support the same option: >> * snap build gadget* >> >> And i should how to use it ? Thanks. >> > > There are some subtle differences between the two. Let me check that > repository out and get back to you. > > Best regards > ZK > > > -- > Snapcraft mailing list > Snapcraft at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 6594_6594_6594_clip_i(07-13-12-20-59).jpg Type: image/jpeg Size: 6594 bytes Desc: not available URL: From mark at ubuntu.com Tue May 31 10:41:10 2016 From: mark at ubuntu.com (Mark Shuttleworth) Date: Tue, 31 May 2016 11:41:10 +0100 Subject: Docs for snapcraft Message-ID: <574D6A46.2040105@ubuntu.com> Hi folks It's great to see the level of interest in making snaps! I've been tracking comments and a lot of people seem to be stuck on snapcraft, so I think we can put some effort into improving those docs. But I wondered if we shouldn't instead focus up front on explaining the snap format itself. That way, people could make snaps manually initially, then switch to using the tools they like best for making the snap. Personally I think snapcraft is amazing, but it does create an extra layer of abstraction to push through, which may be confusing to someone just starting out. Thoughts? Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From woodrow.shen at canonical.com Tue May 31 11:32:28 2016 From: woodrow.shen at canonical.com (Woodrow Shen) Date: Tue, 31 May 2016 19:32:28 +0800 Subject: snappy: Command not found In-Reply-To: References: Message-ID: Hi Peter, The work from https://github.com/xapp-le/SnappyUbuntuCore is created by me, and I'm sorry to make you confused because the current master branch isn't ported completely yet, and I'll continue to do the porting based on 3.11 kernel. Woodrow On Tue, May 31, 2016 at 6:27 PM, Anthony Wong wrote: > Hi Peter, > > It will be easier if you follow how we enabled the hikey board for demo, > because that's for Ubuntu Core 16. You can find the kernel and the > associated snapcraft.yaml to build the kernel snap at > https://code.launchpad.net/~canonical-hwe-team/+git/hikey_linux and the > gadget snap at > https://code.launchpad.net/~canonical-hwe-team/+git/hikey_gadget_snap. > More details on bringing the board up can be found here > . > > Happy snapping! > > Anthony > > -- > Anthony Wong > Engineering Manager, Hardware Enablement > Canonical Ltd. www.canonical.com > > On 31 May 2016 at 17:03, peter.chen at lemaker.com > wrote: > >> Hi, ZK >> Thank you . >> >> Best Regards >> ------------------------------ >> >> *Peter Chen* >> >> >> *Making Innovation EasyLeMaker Team -- The Professional Makers for >> Hardware and Software Customization.* >> >> Address: B1002, SIAT campus, Shenzhen University Town, Shenzhen, China >> Post Code: 518055 >> >> Tel: 0755-36330749 >> >> Email: >> support at lemaker.org (Technical Support) >> product at lemaker.org (Product Distribution) >> >> >> >> >> http://www.lemaker.org/ >> >> >> *From:* Zygmunt Krynicki >> *Date:* 2016-05-31 16:59 >> *To:* peter.chen at lemaker.com >> *CC:* snapcraft ; 张腾 >> *Subject:* Re: Re: snappy: Command not found >> >> >> On Tue, May 31, 2016 at 10:58 AM, peter.chen at lemaker.com < >> peter.chen at lemaker.com> wrote: >> >>> Hi, ZK >>> The project use the command below in the *SnappyUbuntuCore/builder/**gadget.mk >>> * : >>> >>> *snappy: snappy build gadget* >>> >>> However, the newer command *snap *didn't support the same option: >>> * snap build gadget* >>> >>> And i should how to use it ? Thanks. >>> >> >> There are some subtle differences between the two. Let me check that >> repository out and get back to you. >> >> Best regards >> ZK >> >> >> -- >> Snapcraft mailing list >> Snapcraft at lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/snapcraft >> >> > > -- > Snapcraft mailing list > Snapcraft at lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > > -- Woodrow Shen Software Engineer, Canonical ltd. UES | CE | PC & Core, Taipei -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 6594_6594_6594_clip_i(07-13-12-20-59).jpg Type: image/jpeg Size: 6594 bytes Desc: not available URL: From peter.chen at lemaker.com Tue May 31 12:33:27 2016 From: peter.chen at lemaker.com (peter.chen at lemaker.com) Date: Tue, 31 May 2016 20:33:27 +0800 Subject: snappy: Command not found References: <2016053116332091784010@lemaker.com>, <1464688313.30150.45.camel@anubis> Message-ID: <201605312032037101727@lemaker.com> Hi, Thanks for your information ,I will have a try. Best Regards Peter Chen Making Innovation Easy LeMaker Team -- The Professional Makers for Hardware and Software Customization. Address: B1002, SIAT campus, Shenzhen University Town, Shenzhen, China Post Code: 518055 Tel: 0755-36330749 Email: support at lemaker.org (Technical Support) product at lemaker.org (Product Distribution) http://www.lemaker.org/ From: Oliver Grawert Date: 2016-05-31 17:51 To: snapcraft Subject: Re: snappy: Command not found Am Dienstag, den 31.05.2016, 16:33 +0800 schrieb peter.chen at lemaker.com: > Hi, All > I want to port the snappy ubuntu to the LeMaker Gutiar refer to the > project at https://github.com/xapp-le/SnappyUbuntuCore . > I have read the README from the project ,and pre-installed some > software which it mentioned on the ubuntu 16.04. However, > It failed when i run the command "make gadget", and output error info > "snappy: Command not found" . How do i install the snappy command on > the ubuntu 16.04 ? looking at your tree, there is a lot more you need to change: in the 16 series the package.yaml files are gone (and replaced by snap.yaml files with a slightly different syntax). snappy can not build any snap packages anymore (it turned into a management-only tool). for building you need to use snapcraft on a 16.04 install (can be a chroot) now ... (the direct equivalent of "snappy build" would be "snapcraft snap", specifically for the kernel you probably want to use a full snapcraft build process using the snapcraft kernel plugin though) looking at your yaml files within the kernel and gadget dirs, snappy-ab is also gone. everything is a snap now (which essentially means: a squashfs file) and all these snaps live on a single writable partition and get loop mounted on demand (this includes kernel and os snap), this made the A/B partitioning setup obsolete (make sure to use the latest ubuntu-device-flash binary from [1], it creates the right partitioning by default). at [2] you can find the code for the currently used raspberry pi2 gadget snap, it shouldnt be to hard to adapt the meta data of your gadget according to the snap.yaml there. note that some things changed, specifically for u-boot. we stopped using/supporting any txt files to manage the auto-reboot and upgrade management, all config needs to live in a uboot.env binary blob now. there is a README in the above tree that explains how to create it, as well as the uboot.env.in file that we use as input for this. a few build config changes are also required to make the uboot.env blob work, the patch we use on top of the upstream u-boot tree can be found at [3]. regarding the kernel, there is a snapcraft example for building a 96boards kernel at [4], that should get you going... i guess the above should help you to start moving forward in the right direction, don't hold back on the further questions you will surely have, just drop them here ;) ciao oli [1] http://people.canonical.com/~mvo/all-snaps/ [2] http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files/head:/pi2/ [3] http://paste.ubuntu.com/16199863/ [4] https://github.com/ubuntu-core/snapcraft/tree/master/demos/96boards-kernel -- Snapcraft mailing list Snapcraft at lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 6594_6594_6594_6594_c(07-24-20-47-10).jpg Type: image/jpeg Size: 6594 bytes Desc: not available URL: From peter.chen at lemaker.com Tue May 31 12:54:37 2016 From: peter.chen at lemaker.com (peter.chen at lemaker.com) Date: Tue, 31 May 2016 20:54:37 +0800 Subject: snappy: Command not found References: , Message-ID: <2016053120543728594624@lemaker.com> Hi, Woodrow It is doesn't matter, I have got lots of tutorial from your members，and i will have a try. Thanks for your help again. Best Regards Peter Chen Making Innovation Easy LeMaker Team -- The Professional Makers for Hardware and Software Customization. Address: B1002, SIAT campus, Shenzhen University Town, Shenzhen, China Post Code: 518055 Tel: 0755-36330749 Email: support at lemaker.org (Technical Support) product at lemaker.org (Product Distribution) http://www.lemaker.org/ From: Woodrow Shen Date: 2016-05-31 19:32 To: Anthony Wong CC: peter.chen at lemaker.com; Liming Wang; 张腾; snapcraft Subject: Re: snappy: Command not found Hi Peter, The work from https://github.com/xapp-le/SnappyUbuntuCore is created by me, and I'm sorry to make you confused because the current master branch isn't ported completely yet, and I'll continue to do the porting based on 3.11 kernel. Woodrow On Tue, May 31, 2016 at 6:27 PM, Anthony Wong wrote: Hi Peter, It will be easier if you follow how we enabled the hikey board for demo, because that's for Ubuntu Core 16. You can find the kernel and the associated snapcraft.yaml to build the kernel snap at https://code.launchpad.net/~canonical-hwe-team/+git/hikey_linux and the gadget snap at https://code.launchpad.net/~canonical-hwe-team/+git/hikey_gadget_snap. More details on bringing the board up can be found here. Happy snapping! Anthony -- Anthony Wong Engineering Manager, Hardware Enablement Canonical Ltd. www.canonical.com On 31 May 2016 at 17:03, peter.chen at lemaker.com wrote: Hi, ZK Thank you . Best Regards Peter Chen Making Innovation Easy LeMaker Team -- The Professional Makers for Hardware and Software Customization. Address: B1002, SIAT campus, Shenzhen University Town, Shenzhen, China Post Code: 518055 Tel: 0755-36330749 Email: support at lemaker.org (Technical Support) product at lemaker.org (Product Distribution) http://www.lemaker.org/ From: Zygmunt Krynicki Date: 2016-05-31 16:59 To: peter.chen at lemaker.com CC: snapcraft; 张腾 Subject: Re: Re: snappy: Command not found On Tue, May 31, 2016 at 10:58 AM, peter.chen at lemaker.com wrote: Hi, ZK The project use the command below in the SnappyUbuntuCore/builder/gadget.mk : snappy: snappy build gadget However, the newer command snap didn't support the same option: snap build gadget And i should how to use it ? Thanks. There are some subtle differences between the two. Let me check that repository out and get back to you. Best regards ZK -- Snapcraft mailing list Snapcraft at lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -- Snapcraft mailing list Snapcraft at lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft -- Woodrow Shen Software Engineer, Canonical ltd. UES | CE | PC & Core, Taipei -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 6594_6594_6594_6594_c(07-24-20-47-10).jpg Type: image/jpeg Size: 6594 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 6594_6594_6594_c(05-31-20-34-18).jpg Type: image/jpeg Size: 6594 bytes Desc: not available URL: From ted at ubuntu.com Tue May 31 14:02:59 2016 From: ted at ubuntu.com (Ted Gould) Date: Tue, 31 May 2016 09:02:59 -0500 Subject: Interface for Snappy Apps that understand Unity8 Application Lifecycle In-Reply-To: <574C30B1.5080109@canonical.com> References: <1464369759.5091.4.camel@ubuntu.com> <1464371296.5091.9.camel@ubuntu.com> <574C30B1.5080109@canonical.com> Message-ID: <1464703379.478.8.camel@ubuntu.com> On Mon, 2016-05-30 at 14:23 +0200, Michał Sawicz wrote: > W dniu 27.05.2016 o 19:48, Ted Gould pisze: > > In a nutshell, it is listening to a set commands that are sent via > > the > > Mir connection from QtMir/Unity8 which correspond with the > > different > > states that an application is put in. As an example, it is told > > when it > > is about to be suspended so that the application can save data in > > memory > > to disk. For QML/Qt apps this is implemented in the QPA plugin. > > Applications that do not speak this protocol could lose user data > > if > > they were killed by Unity8 and didn't realize they needed to use > > their > > chance to save. > I just wonder if this is anything really unity8-specific. We've not > created special APIs (at least not compared to Qt ones), we're not > actively killing apps for no reason, it's just that we're more > resource > constrained and OOM killer kicks in quicker. When closing apps, we do > tell apps, after waking them, when the user closes them, so they know > they need to save data (we're not giving them a chance to prevent > closing, at least not yet). > > Well-behaved apps (LibreOffice, Firefox) do this already by > periodically > saving restore information, would you consider those as "supporting > the > unity8 lifecycle"? While other systems like Android and iOS have this type of behavior, I don't know of anyone else doing it on a GNU/Linux. Certainly they could , but they aren't. While we tell apps when a user closes them, they're expected to save state before that because most of the time it's not the user closing them, it is the OOM killer. While I think that it is great apps periodically save, I would not consider them implementing the lifecycle as they are today. I think that it would be easy for them to migrate to do so (literally adding a single observer to that same code path) until they do they aren't supporting it and risk losing user data. So, I agree with Gustavo that calling it Unity8 today makes sense, and we can put other U8 interfaces in there to have potentially fewer interfaces going forward. Ted -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.schvezov at canonical.com Tue May 31 23:25:21 2016 From: sergio.schvezov at canonical.com (Sergio Schvezov) Date: Tue, 31 May 2016 20:25:21 -0300 Subject: Docs for snapcraft In-Reply-To: <574D6A46.2040105@ubuntu.com> References: <574D6A46.2040105@ubuntu.com> Message-ID: <574E1D61.1050303@ubuntu.com> El 31/05/16 a las 07:41, Mark Shuttleworth escribió: > Hi folks Hi there. I'm going to break the ice here or try to. > It's great to see the level of interest in making snaps! I've been > tracking comments and a lot of people seem to be stuck on snapcraft, so > I think we can put some effort into improving those docs. We landed a change which will come in 2.10 which on `snapcraft init` prepares something you can snap right away. I've been on the crossroads on this one but it figures that someone doing `snapcraft init` is just getting started with the tool. So now you can $ snapcraft init $ snapcraft And get a snap right away. I want to make this more guided as we move along (gamification). It is still a template to the keen eye, so it is still of use to someone in the know how wanting to ramp up a new project. > But I wondered if we shouldn't instead focus up front on explaining the > snap format itself. That way, people could make snaps manually > initially, then switch to using the tools they like best for making the > snap. What to expect of a snap and how it integrates with the rest of the system would be really ideal. I would paint it with user stories ("I write desktop apps ...", "I work on embedded systems over i2c..", etc.) so we don't go into length about technical details that are not relevant to some people. Yes everyone uses `interfaces`, but introducing the concept at the right time makes things easier to grasp because it matters to the persons use case at that time. > Personally I think snapcraft is amazing, but it does create an extra > layer of abstraction to push through, which may be confusing to someone > just starting out. > > Thoughts? My thoughts are biased towards trying to use snapcraft for everything but we should not block on people wanting to do whatever they want during their creative process. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: