Activity log for bug #1583259

Date Who What changed Old value New value Message
2016-05-18 16:55:32 Zygmunt Krynicki bug added bug
2016-05-18 16:55:42 Zygmunt Krynicki bug task added ubuntu-core-launcher
2016-05-18 16:55:52 Zygmunt Krynicki bug task added snapcraft
2016-05-18 21:24:13 Sebastien Bacher bug added subscriber Sebastien Bacher
2016-05-18 21:24:22 Sebastien Bacher tags snap-desktop-issue
2016-05-23 17:30:15 Sergio Schvezov snapcraft: milestone 2.10
2016-05-23 17:31:34 Sergio Schvezov description We see a common pattern across many snaps, all apps are really using wrappers to set environment variables. I'd like to propose that this is exposed as first class feature in snapcraft (same like plugs and slots), snappy (where interfaces can affect variables and snappy can have sensible defaults) and ubuntu-core-launcher (to actually apply those variables to each started process). As a bit of context, this is a wrapper for a non trivial but still common app: the calculator: https://bazaar.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap/view/head:/calc#L3 The wrapper is 44 lines long, all of which set up environment variables. We see a common pattern across many snaps, all apps are really using wrappers to set environment variables. I'd like to propose that this is exposed as first class feature in snapcraft (same like plugs and slots), snappy (where interfaces can affect variables and snappy can have sensible defaults) and ubuntu-core-launcher (to actually apply those variables to each started process). As a bit of context, this is a wrapper for a non trivial but still common app: the calculator: https://bazaar.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap/view/head:/calc#L3 The wrapper is 44 lines long, all of which set up environment variables. Support environment variable that would be available to snaps. The form should look like snapcraft.yaml name: ... version: ... ... environment: # these apply to all snaps ENV1: value1 ENV2: value2 apps: app1: ... environment: ENV1: value1 # takes precedence over global ones These environment values would be transported to snap.yaml
2016-05-26 17:02:40 Sergio Schvezov snapcraft: importance Undecided Wishlist
2016-05-26 17:02:43 Sergio Schvezov snapcraft: status New In Progress
2016-05-26 17:02:46 Sergio Schvezov snapcraft: assignee Sergio Schvezov (sergiusens)
2016-05-26 17:10:18 Sergio Schvezov description We see a common pattern across many snaps, all apps are really using wrappers to set environment variables. I'd like to propose that this is exposed as first class feature in snapcraft (same like plugs and slots), snappy (where interfaces can affect variables and snappy can have sensible defaults) and ubuntu-core-launcher (to actually apply those variables to each started process). As a bit of context, this is a wrapper for a non trivial but still common app: the calculator: https://bazaar.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap/view/head:/calc#L3 The wrapper is 44 lines long, all of which set up environment variables. Support environment variable that would be available to snaps. The form should look like snapcraft.yaml name: ... version: ... ... environment: # these apply to all snaps ENV1: value1 ENV2: value2 apps: app1: ... environment: ENV1: value1 # takes precedence over global ones These environment values would be transported to snap.yaml [Impact]  * Adding an environment keyword to snapcraft.yaml, which will make it to snap.yaml which the launcher will use to setup the environment. * This reduces the amount of wrapper files. [Test Case]  1. Run `snapcraft` on the ros demo.  2. Install the snap.  3. snap should run. (if it doesn't it mostly likely means the environent was setup incorrectly). [Regression Potential]  * Very low. Environment that was previously setup by wrapper scripts could be missing when the launcher launches using the environment keyword. -- We see a common pattern across many snaps, all apps are really using wrappers to set environment variables. I'd like to propose that this is exposed as first class feature in snapcraft (same like plugs and slots), snappy (where interfaces can affect variables and snappy can have sensible defaults) and ubuntu-core-launcher (to actually apply those variables to each started process). As a bit of context, this is a wrapper for a non trivial but still common app: the calculator: https://bazaar.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap/view/head:/calc#L3 The wrapper is 44 lines long, all of which set up environment variables. Support environment variable that would be available to snaps. The form should look like snapcraft.yaml name: ... version: ... ... environment: # these apply to all snaps    ENV1: value1    ENV2: value2 apps:    app1:      ...      environment:         ENV1: value1 # takes precedence over global ones These environment values would be transported to snap.yaml
2016-05-31 18:07:09 Sergio Schvezov description [Impact]  * Adding an environment keyword to snapcraft.yaml, which will make it to snap.yaml which the launcher will use to setup the environment. * This reduces the amount of wrapper files. [Test Case]  1. Run `snapcraft` on the ros demo.  2. Install the snap.  3. snap should run. (if it doesn't it mostly likely means the environent was setup incorrectly). [Regression Potential]  * Very low. Environment that was previously setup by wrapper scripts could be missing when the launcher launches using the environment keyword. -- We see a common pattern across many snaps, all apps are really using wrappers to set environment variables. I'd like to propose that this is exposed as first class feature in snapcraft (same like plugs and slots), snappy (where interfaces can affect variables and snappy can have sensible defaults) and ubuntu-core-launcher (to actually apply those variables to each started process). As a bit of context, this is a wrapper for a non trivial but still common app: the calculator: https://bazaar.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap/view/head:/calc#L3 The wrapper is 44 lines long, all of which set up environment variables. Support environment variable that would be available to snaps. The form should look like snapcraft.yaml name: ... version: ... ... environment: # these apply to all snaps    ENV1: value1    ENV2: value2 apps:    app1:      ...      environment:         ENV1: value1 # takes precedence over global ones These environment values would be transported to snap.yaml [Impact]  * Adding an environment keyword to snapcraft.yaml, which will make it to snap.yaml which the launcher will use to setup the environment.  * This reduces the amount of wrapper files. [Test Case]  1. Run `snapcraft` on the ros demo.  2. Install the snap.  3. snap should run. (if it doesn't it mostly likely means the environent was setup incorrectly). 4. snap.yaml's `assumes` gets a `snap-run` tag. [Regression Potential]  * Very low. Environment that was previously setup by wrapper scripts could be missing when the launcher launches using the environment keyword. * The use of `assumes` will make sure this doesn't break people on older versions of snapd or snap-run -- We see a common pattern across many snaps, all apps are really using wrappers to set environment variables. I'd like to propose that this is exposed as first class feature in snapcraft (same like plugs and slots), snappy (where interfaces can affect variables and snappy can have sensible defaults) and ubuntu-core-launcher (to actually apply those variables to each started process). As a bit of context, this is a wrapper for a non trivial but still common app: the calculator: https://bazaar.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap/view/head:/calc#L3 The wrapper is 44 lines long, all of which set up environment variables. Support environment variable that would be available to snaps. The form should look like snapcraft.yaml name: ... version: ... ... environment: # these apply to all snaps    ENV1: value1    ENV2: value2 apps:    app1:      ...      environment:         ENV1: value1 # takes precedence over global ones These environment values would be transported to snap.yaml
2016-06-02 02:16:46 Sergio Schvezov bug task added click-reviewers-tools
2016-06-02 14:04:13 Jamie Strandboge click-reviewers-tools: assignee Jamie Strandboge (jdstrand)
2016-06-02 19:05:19 Sergio Schvezov snapcraft: milestone 2.10 2.11
2016-06-07 21:59:28 Jamie Strandboge click-reviewers-tools: status New Fix Committed
2016-06-27 14:07:54 Sergio Schvezov snapcraft: milestone 2.12 2.13
2016-06-28 15:53:12 Zygmunt Krynicki snap-confine: status New Invalid
2016-07-07 18:24:49 Sergio Schvezov snapcraft: milestone 2.13 2.14
2016-07-07 19:30:01 Sergio Schvezov snapcraft: status In Progress Triaged
2016-07-17 15:13:24 Leon bug added subscriber Leon
2016-07-18 04:48:07 James Lucas bug added subscriber James Lucas
2016-07-21 08:20:15 Sergio Schvezov snapcraft: milestone 2.13
2016-08-02 17:37:49 Jamie Strandboge bug task added click-reviewers-tools (Ubuntu)
2016-08-02 17:38:04 Jamie Strandboge nominated for series Ubuntu Xenial
2016-08-02 17:38:04 Jamie Strandboge bug task added click-reviewers-tools (Ubuntu Xenial)
2016-08-02 17:38:04 Jamie Strandboge nominated for series Ubuntu Yakkety
2016-08-02 17:38:04 Jamie Strandboge bug task added click-reviewers-tools (Ubuntu Yakkety)
2016-08-02 17:38:27 Jamie Strandboge click-reviewers-tools: status Fix Committed Fix Released
2016-08-02 17:38:37 Jamie Strandboge click-reviewers-tools (Ubuntu Yakkety): status New Fix Released
2016-08-02 17:52:40 Jamie Strandboge click-reviewers-tools (Ubuntu Xenial): status New In Progress
2016-08-02 18:18:17 Jamie Strandboge description [Impact]  * Adding an environment keyword to snapcraft.yaml, which will make it to snap.yaml which the launcher will use to setup the environment.  * This reduces the amount of wrapper files. [Test Case]  1. Run `snapcraft` on the ros demo.  2. Install the snap.  3. snap should run. (if it doesn't it mostly likely means the environent was setup incorrectly). 4. snap.yaml's `assumes` gets a `snap-run` tag. [Regression Potential]  * Very low. Environment that was previously setup by wrapper scripts could be missing when the launcher launches using the environment keyword. * The use of `assumes` will make sure this doesn't break people on older versions of snapd or snap-run -- We see a common pattern across many snaps, all apps are really using wrappers to set environment variables. I'd like to propose that this is exposed as first class feature in snapcraft (same like plugs and slots), snappy (where interfaces can affect variables and snappy can have sensible defaults) and ubuntu-core-launcher (to actually apply those variables to each started process). As a bit of context, this is a wrapper for a non trivial but still common app: the calculator: https://bazaar.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap/view/head:/calc#L3 The wrapper is 44 lines long, all of which set up environment variables. Support environment variable that would be available to snaps. The form should look like snapcraft.yaml name: ... version: ... ... environment: # these apply to all snaps    ENV1: value1    ENV2: value2 apps:    app1:      ...      environment:         ENV1: value1 # takes precedence over global ones These environment values would be transported to snap.yaml = SRU for snapcraft = [Impact]  * Adding an environment keyword to snapcraft.yaml, which will make it to snap.yaml which the launcher will use to setup the environment.  * This reduces the amount of wrapper files. [Test Case]  1. Run `snapcraft` on the ros demo.  2. Install the snap.  3. snap should run. (if it doesn't it mostly likely means the environent was setup incorrectly).  4. snap.yaml's `assumes` gets a `snap-run` tag. [Regression Potential]  * Very low. Environment that was previously setup by wrapper scripts could be missing when the launcher launches using the environment keyword.  * The use of `assumes` will make sure this doesn't break people on older versions of snapd or snap-run = SRU for click-reviewers-tools = [Impact] This is already fixed in the store so the SRU is for users to not see this failure their local system [Test Case] Run snap-review on the attached snap: $ snap-review ./snap-example-env/snap-example-env_0_all.snap ./snap-example-env_0_all.snap: pass [ Regression Potential] Regression potential is extremely low since this is already on production in the Ubuntu Store for many weeks. = Original description = We see a common pattern across many snaps, all apps are really using wrappers to set environment variables. I'd like to propose that this is exposed as first class feature in snapcraft (same like plugs and slots), snappy (where interfaces can affect variables and snappy can have sensible defaults) and ubuntu-core-launcher (to actually apply those variables to each started process). As a bit of context, this is a wrapper for a non trivial but still common app: the calculator: https://bazaar.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap/view/head:/calc#L3 The wrapper is 44 lines long, all of which set up environment variables. Support environment variable that would be available to snaps. The form should look like snapcraft.yaml name: ... version: ... ... environment: # these apply to all snaps    ENV1: value1    ENV2: value2 apps:    app1:      ...      environment:         ENV1: value1 # takes precedence over global ones These environment values would be transported to snap.yaml
2016-08-02 18:33:02 Jamie Strandboge attachment added snap-example-env_0_all.snap https://bugs.launchpad.net/click-reviewers-tools/+bug/1583259/+attachment/4712548/+files/snap-example-env_0_all.snap
2016-08-02 18:33:48 Jamie Strandboge description = SRU for snapcraft = [Impact]  * Adding an environment keyword to snapcraft.yaml, which will make it to snap.yaml which the launcher will use to setup the environment.  * This reduces the amount of wrapper files. [Test Case]  1. Run `snapcraft` on the ros demo.  2. Install the snap.  3. snap should run. (if it doesn't it mostly likely means the environent was setup incorrectly).  4. snap.yaml's `assumes` gets a `snap-run` tag. [Regression Potential]  * Very low. Environment that was previously setup by wrapper scripts could be missing when the launcher launches using the environment keyword.  * The use of `assumes` will make sure this doesn't break people on older versions of snapd or snap-run = SRU for click-reviewers-tools = [Impact] This is already fixed in the store so the SRU is for users to not see this failure their local system [Test Case] Run snap-review on the attached snap: $ snap-review ./snap-example-env/snap-example-env_0_all.snap ./snap-example-env_0_all.snap: pass [ Regression Potential] Regression potential is extremely low since this is already on production in the Ubuntu Store for many weeks. = Original description = We see a common pattern across many snaps, all apps are really using wrappers to set environment variables. I'd like to propose that this is exposed as first class feature in snapcraft (same like plugs and slots), snappy (where interfaces can affect variables and snappy can have sensible defaults) and ubuntu-core-launcher (to actually apply those variables to each started process). As a bit of context, this is a wrapper for a non trivial but still common app: the calculator: https://bazaar.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap/view/head:/calc#L3 The wrapper is 44 lines long, all of which set up environment variables. Support environment variable that would be available to snaps. The form should look like snapcraft.yaml name: ... version: ... ... environment: # these apply to all snaps    ENV1: value1    ENV2: value2 apps:    app1:      ...      environment:         ENV1: value1 # takes precedence over global ones These environment values would be transported to snap.yaml = SRU for snapcraft = [Impact]  * Adding an environment keyword to snapcraft.yaml, which will make it to snap.yaml which the launcher will use to setup the environment.  * This reduces the amount of wrapper files. [Test Case]  1. Run `snapcraft` on the ros demo.  2. Install the snap.  3. snap should run. (if it doesn't it mostly likely means the environent was setup incorrectly).  4. snap.yaml's `assumes` gets a `snap-run` tag. [Regression Potential]  * Very low. Environment that was previously setup by wrapper scripts could be missing when the launcher launches using the environment keyword.  * The use of `assumes` will make sure this doesn't break people on older versions of snapd or snap-run = SRU for click-reviewers-tools = [Impact] This is already fixed in the store so the SRU is for users to not see this failure their local system [Test Case] Run snap-review on the attached snap: $ snap-review ./snap-example-env_0_all.snap ./snap-example-env_0_all.snap: pass [ Regression Potential] Regression potential is extremely low since this is already on production in the Ubuntu Store for many weeks. = Original description = We see a common pattern across many snaps, all apps are really using wrappers to set environment variables. I'd like to propose that this is exposed as first class feature in snapcraft (same like plugs and slots), snappy (where interfaces can affect variables and snappy can have sensible defaults) and ubuntu-core-launcher (to actually apply those variables to each started process). As a bit of context, this is a wrapper for a non trivial but still common app: the calculator: https://bazaar.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap/view/head:/calc#L3 The wrapper is 44 lines long, all of which set up environment variables. Support environment variable that would be available to snaps. The form should look like snapcraft.yaml name: ... version: ... ... environment: # these apply to all snaps    ENV1: value1    ENV2: value2 apps:    app1:      ...      environment:         ENV1: value1 # takes precedence over global ones These environment values would be transported to snap.yaml
2016-08-02 18:33:58 Jamie Strandboge bug added subscriber Ubuntu Stable Release Updates Team
2016-08-02 21:06:12 Nish Aravamudan bug added subscriber Nish Aravamudan
2016-08-04 17:36:46 Niclas Moeslund Overby bug added subscriber Niclas Moeslund Overby
2016-08-22 10:26:08 Martin Pitt click-reviewers-tools (Ubuntu Xenial): status In Progress Fix Committed
2016-08-22 10:26:11 Martin Pitt bug added subscriber SRU Verification
2016-08-22 10:26:18 Martin Pitt tags snap-desktop-issue snap-desktop-issue verification-needed
2016-09-21 12:37:52 Jamie Strandboge tags snap-desktop-issue verification-needed snap-desktop-issue verification-done
2016-09-21 13:28:09 Launchpad Janitor click-reviewers-tools (Ubuntu Xenial): status Fix Committed Fix Released
2016-09-21 13:28:23 Jamie Strandboge removed subscriber Ubuntu Stable Release Updates Team
2016-11-18 14:22:53 Junien Fridrick bug added subscriber Junien Fridrick
2016-11-18 14:22:59 Junien Fridrick bug added subscriber The Canonical Sysadmins
2016-11-18 16:50:33 Jiří Janoušek bug added subscriber Jiří Janoušek
2016-11-29 14:54:14 Michael Vogt snappy: status New Fix Released
2017-02-02 13:56:25 Sergio Schvezov snapcraft: status Triaged In Progress
2017-02-02 13:56:28 Sergio Schvezov snapcraft: milestone 2.27
2017-02-06 15:12:13 Sergio Schvezov snapcraft: status In Progress Fix Committed
2017-02-17 10:10:39 Sergio Schvezov snapcraft: status Fix Committed Fix Released