| 2014-11-26 13:52:36 |
John McAleely |
bug |
|
|
added bug |
| 2014-11-26 14:26:10 |
John McAleely |
description |
Currently ubuntu-device-flash feeds data to a device script 'system-image-updater' to assemble a viable 'system-image' system partition for a phone.
As input to the factory image process, that filesystem is needed to be output from ubuntu-device-flash without an attached device. |
Currently ubuntu-device-flash feeds data to a device script 'system-image-updater' to assemble a viable 'system-image' system partition for a phone.
As input to the factory image process, that filesystem is needed to be output from ubuntu-device-flash without an attached device.
so, I think it would be useful if it were possible to say:
ubuntu-device-flash [--revision N] touch [--channel ubuntu-touch/stable] --device mako [--developer-mode] [--password X] --output-image path/to/system-image.tar.xz
Where system-image.tar.xz contains the contents of:
ubuntu-XXX.tar.xz
custom-YYY.tar.xz
device-ZZZ.tar.xz
version-AAA-tar.xz
plus any manipulations implied by the optional arguments so that this file can be input to a factory image creation tool for the device. It is assumed that these will be placed onto a suitable filesystem hosted in a single storage partition.
The optional --developer-mode arguments are so that devices can be fed into an OEM CI system that flashes the devices as they would be in the factory, but still requires test access to the system. |
|
| 2014-11-26 14:38:30 |
John McAleely |
description |
Currently ubuntu-device-flash feeds data to a device script 'system-image-updater' to assemble a viable 'system-image' system partition for a phone.
As input to the factory image process, that filesystem is needed to be output from ubuntu-device-flash without an attached device.
so, I think it would be useful if it were possible to say:
ubuntu-device-flash [--revision N] touch [--channel ubuntu-touch/stable] --device mako [--developer-mode] [--password X] --output-image path/to/system-image.tar.xz
Where system-image.tar.xz contains the contents of:
ubuntu-XXX.tar.xz
custom-YYY.tar.xz
device-ZZZ.tar.xz
version-AAA-tar.xz
plus any manipulations implied by the optional arguments so that this file can be input to a factory image creation tool for the device. It is assumed that these will be placed onto a suitable filesystem hosted in a single storage partition.
The optional --developer-mode arguments are so that devices can be fed into an OEM CI system that flashes the devices as they would be in the factory, but still requires test access to the system. |
Currently ubuntu-device-flash feeds data to a device script 'system-image-updater' to assemble a viable 'system-image' system partition for a phone (and it does other stuff this bug doesn't care about, like wiping userdata).
As input to the factory image process, that filesystem is needed to be output from ubuntu-device-flash without an attached device.
so, I think it would be useful if it were possible to say:
ubuntu-device-flash [--revision N] touch [--channel ubuntu-touch/stable] --device mako [--developer-mode] [--password X] --output-image path/to/system-image.tar.xz
Where system-image.tar.xz contains the contents of:
ubuntu-XXX.tar.xz
custom-YYY.tar.xz
device-ZZZ.tar.xz
version-AAA-tar.xz
plus any manipulations implied by the optional arguments so that this file can be input to a factory image creation tool for the device. It is assumed that these will be placed onto a suitable filesystem hosted in a single storage partition.
The optional --developer-mode arguments are so that devices can be fed into an OEM CI system that flashes the devices as they would be in the factory, but still requires test access to the system. |
|
| 2014-11-26 14:38:46 |
John McAleely |
description |
Currently ubuntu-device-flash feeds data to a device script 'system-image-updater' to assemble a viable 'system-image' system partition for a phone (and it does other stuff this bug doesn't care about, like wiping userdata).
As input to the factory image process, that filesystem is needed to be output from ubuntu-device-flash without an attached device.
so, I think it would be useful if it were possible to say:
ubuntu-device-flash [--revision N] touch [--channel ubuntu-touch/stable] --device mako [--developer-mode] [--password X] --output-image path/to/system-image.tar.xz
Where system-image.tar.xz contains the contents of:
ubuntu-XXX.tar.xz
custom-YYY.tar.xz
device-ZZZ.tar.xz
version-AAA-tar.xz
plus any manipulations implied by the optional arguments so that this file can be input to a factory image creation tool for the device. It is assumed that these will be placed onto a suitable filesystem hosted in a single storage partition.
The optional --developer-mode arguments are so that devices can be fed into an OEM CI system that flashes the devices as they would be in the factory, but still requires test access to the system. |
Currently ubuntu-device-flash feeds data to a device script 'system-image-updater' to assemble a viable 'system-image' system partition for a phone (and it does other stuff this bug doesn't care about, like wiping userdata).
As input to the factory image process, the 'system' filesystem is needed to be output from ubuntu-device-flash without an attached device.
so, I think it would be useful if it were possible to say:
ubuntu-device-flash [--revision N] touch [--channel ubuntu-touch/stable] --device mako [--developer-mode] [--password X] --output-image path/to/system-image.tar.xz
Where system-image.tar.xz contains the contents of:
ubuntu-XXX.tar.xz
custom-YYY.tar.xz
device-ZZZ.tar.xz
version-AAA-tar.xz
plus any manipulations implied by the optional arguments so that this file can be input to a factory image creation tool for the device. It is assumed that these will be placed onto a suitable filesystem hosted in a single storage partition.
The optional --developer-mode arguments are so that devices can be fed into an OEM CI system that flashes the devices as they would be in the factory, but still requires test access to the system. |
|
| 2014-11-26 14:45:47 |
John McAleely |
description |
Currently ubuntu-device-flash feeds data to a device script 'system-image-updater' to assemble a viable 'system-image' system partition for a phone (and it does other stuff this bug doesn't care about, like wiping userdata).
As input to the factory image process, the 'system' filesystem is needed to be output from ubuntu-device-flash without an attached device.
so, I think it would be useful if it were possible to say:
ubuntu-device-flash [--revision N] touch [--channel ubuntu-touch/stable] --device mako [--developer-mode] [--password X] --output-image path/to/system-image.tar.xz
Where system-image.tar.xz contains the contents of:
ubuntu-XXX.tar.xz
custom-YYY.tar.xz
device-ZZZ.tar.xz
version-AAA-tar.xz
plus any manipulations implied by the optional arguments so that this file can be input to a factory image creation tool for the device. It is assumed that these will be placed onto a suitable filesystem hosted in a single storage partition.
The optional --developer-mode arguments are so that devices can be fed into an OEM CI system that flashes the devices as they would be in the factory, but still requires test access to the system. |
Currently ubuntu-device-flash feeds data to a device script 'system-image-updater' to assemble a viable 'system-image' system partition for a phone (and it does other stuff this bug doesn't care about, like wiping userdata).
As input to the factory image process, the 'system' filesystem is needed to be output from ubuntu-device-flash without an attached device.
so, I think it would be useful if it were possible to say:
ubuntu-device-flash [--revision N] touch [--channel ubuntu-touch/stable] --device [mako|flo|whatever-is-in-the-channel] [--developer-mode] [--password X] --output-image path/to/system-image.tar.xz
Where system-image.tar.xz contains the contents of:
ubuntu-XXX.tar.xz
custom-YYY.tar.xz
device-ZZZ.tar.xz
version-AAA-tar.xz
plus any manipulations implied by the optional arguments so that this file can be input to a factory image creation tool for the device. It is assumed that these will be placed onto a suitable filesystem hosted in a single storage partition.
The optional --developer-mode arguments are so that devices can be fed into an OEM CI system that flashes the devices as they would be in the factory, but still requires test access to the system. |
|
