Re: Un-revert a snap

I found the following command works: snap revert --revision 29 as expected. We still need a command to list all revision of a snap install in the system (we can get that from 'df', but still better to get all info from a command) ? YC 2016-10-27 14:38 GMT+08:00 Didier Roche : > Le 27/10/2016

Re: Un-revert a snap

Le 27/10/2016 à 09:18, YC Cheng a écrit : > I found the following command works: > > snap revert --revision 29 > > as expected. Indeed, you will notice though that any new data which have been produced after the revert by revision 20 will not be available to the new revision 29, which may not be t

Re: Un-revert a snap

Reply in-line, YC 2016-10-27 15:36 GMT+08:00 Didier Roche : > Le 27/10/2016 à 09:18, YC Cheng a écrit : > > I found the following command works: > > snap revert --revision 29 > > as expected. > > > Indeed, > you will notice though that any new data which have been produced after > the revert by r

Re: Un-revert a snap

Le 27/10/2016 à 09:44, YC Cheng a écrit : > Reply in-line, YC > > 2016-10-27 15:36 GMT+08:00 Didier Roche >: > > Le 27/10/2016 à 09:18, YC Cheng a écrit : >> I found the following command works: >> >> snap revert --revision 29 >> >> as expected. > >

Re: Provisional snap for DUB (D language package/build manager)

Le 27/10/2016 à 08:37, Didier Roche a écrit : > Le 27/10/2016 à 01:13, Joseph Rushton Wakeling a écrit : >> Hello folks, > Hey Joseph, > > It would be great to have D support! Thanks for working on that :) > I'm going to try to answer to some of your questions, but I'm sure > Sergio (CCed) would be

Re: Un-revert a snap

Fire another bug https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1637119, YC 2016-10-27 16:06 GMT+08:00 Didier Roche : > Le 27/10/2016 à 09:44, YC Cheng a écrit : > > Reply in-line, YC > > 2016-10-27 15:36 GMT+08:00 Didier Roche : > >> Le 27/10/2016 à 09:18, YC Cheng a écrit : >> >> I found

Re: questions about connecting bluez interface

Hey Robert, the bluez plug and slot are now auto-connected as we put a snap-declaration for it on the store side in place. That assertion tells snapd that the bluez snap should get its slots/plugs automatically connected. But this only applies for the bluez snap coming from the store. If you insta

Re: Un-revert a snap

We actually have that already in the upcoming version. You'll be able to say "snap refresh --revison=N ", similarly to how we can revert. That said, I think the expectation exposed in the first message is a reasonable one. We should probably not blacklist the current revision if the snap name was

Re: Un-revert a snap

Not sure if the new "refresh" design will check if the local installed one have the same channel/revision or even hash that match the one from server. (I think we should.) And if yes, are we going to add something like "--force" in case of some mix channel situation ? 2016-10-27 20:42 GMT+08:00 Gu

Re: questions about connecting bluez interface

On Thu, 2016-10-27 at 13:36 +0200, Simon Fels wrote: > Hey Robert, > > the bluez plug and slot are now auto-connected as we put a snap-declaration > for it on the store side in place. That assertion tells snapd that the > bluez snap should get its slots/plugs automatically connected. But this > on

Optional daemon

Greetings, With our Rocket.Chat snap, we're looking to be able to allow someone to run an external mongodb instead of the built in one. As well as we'd like to add something like caddy / traefik etc to do ssl termination. But its not a daemon we would want enabled out of the box because of the e

Re: Optional daemon

Le 27/10/2016 à 16:50, Aaron Ogle a écrit : > Greetings, > > With our Rocket.Chat snap, we're looking to be able to allow someone > to run an external mongodb instead of the built in one. As well as > we'd like to add something like caddy / traefik etc to do ssl > termination. But its not a daemo

Re: Optional daemon

Didier: This sounds like exactly what I wanted! So once this lands I will be able to just use: snapctl get value to get user set information? Will the snapctl command be available anywhere in the snap or only in the hooks? Also the upgrade hook looks like it could be a thing of beauty. Any plan

Re: Optional daemon

Le 27/10/2016 à 17:33, Aaron Ogle a écrit : > Didier: > > This sounds like exactly what I wanted! So once this lands I will be > able to just use: snapctl get value to get user set information? Exactly! > > Will the snapctl command be available anywhere in the snap or only in > the hooks? I gues

Re: Optional daemon

Didier: With each upgrade we perform a database migration. So when reverting back the data structure in the database might have changed. This is potentially something we could handle inside of our platform specifically. But figured I would ask :) On Thu, Oct 27, 2016 at 10:53 AM Didier Roche

Ubuntu Core 16 Release Candidate 2 (with Pi and more)

Hi, The Snappy team is happy to announce the second Release Candidate of Ubuntu Core 16. Ubuntu Core is an operating system entirely based on snaps, including its foundation. Applications, kernel, core operating system, and gadget components are all managed as snaps and are installed and refreshe

Re: Optional daemon

On 10/27/2016 08:52 AM, Didier Roche wrote: > Le 27/10/2016 à 17:33, Aaron Ogle a écrit : >> Didier: >> >> This sounds like exactly what I wanted! So once this lands I will be >> able to just use: snapctl get value to get user set information? > Exactly! > >> >> Will the snapctl command be avail

Re: Optional daemon

On 10/27/2016 08:59 AM, Aaron Ogle wrote: > Didier: > > With each upgrade we perform a database migration. So when reverting > back the data structure in the database might have changed. This is > potentially something we could handle inside of our platform > specifically. But figured I would a

Re: Optional daemon

On Thu, Oct 27, 2016 at 11:56 AM Kyle Fazzari wrote: > > So are you storing this database in $SNAP_COMMON? Because $SNAP_DATA would > do this for you, no? > Correct we are doing in $SNAP_COMMON. Is $SNAP_DATA using CoW? Or is it going to be a full copy. From what I could see it was a full cop

[NEWS] PostgreSQL snaps from Command Prompt

https://www.commandprompt.com/blog/ubuntu_snap_packages_postgresql/ Command Prompt, Inc, who provide commercial support and development for PostgreSQL, have published their builds as snaps in the store, making it easy for anybody to install and use. -- Michael Hall mhall...@ubuntu.com -- Snapc

Re: [NEWS] PostgreSQL snaps from Command Prompt

Awesome. On Thu, Oct 27, 2016 at 12:21 PM, Michael Hall wrote: > https://www.commandprompt.com/blog/ubuntu_snap_packages_postgresql/ > > Command Prompt, Inc, who provide commercial support and development for > PostgreSQL, have published their builds as snaps in the store, making it > easy for an

Re: Provisional snap for DUB (D language package/build manager)

On 27/10/16 08:37, Didier Roche wrote: It would be great to have D support! Thanks for working on that :) Great to hear :-) Just to be clear, it's already in principle possible to package D applications as snaps; DUB support isn't needed, but is very helpful, because a lot of D projects do u

Re: questions about connecting bluez interface

Hi Simon and Jamie, Thank you for the explanations. I would prefer to have all testings of a snap be done locally before I upload it to the store. Another scenario is a developer/company does not want to publish a snap which has a slot. How can they deal this? BR, Robert On Thu, Oct 27, 2016 at

Re: Optional daemon

Le 27/10/2016 à 19:00, Aaron Ogle a écrit : > On Thu, Oct 27, 2016 at 11:56 AM Kyle Fazzari > mailto:kyle.fazz...@canonical.com>> wrote: > > > So are you storing this database in $SNAP_COMMON? Because > $SNAP_DATA would do this for you, no? > > > Correct we are doing in $SNAP_COMMON. Is $S