| 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 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 F |
bug |
|
|
added subscriber Junien Fridrick |
| 2016-11-18 14:22:59 |
Junien F |
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 |
|
