| 2014-04-17 22:36:30 |
John Lenton |
bug |
|
|
added bug |
| 2014-04-17 22:37:19 |
John Lenton |
bug task added |
|
ubuntu-push |
|
| 2014-04-18 10:36:44 |
Launchpad Janitor |
branch linked |
|
lp:~chipaca/ubuntu-push/whoopsie-whoopsie-whoopsie |
|
| 2014-04-18 14:47:59 |
John Lenton |
ubuntu-push: status |
New |
In Progress |
|
| 2014-04-18 14:48:04 |
John Lenton |
ubuntu-push: importance |
Undecided |
Critical |
|
| 2014-04-18 14:48:08 |
John Lenton |
ubuntu-push: assignee |
|
John Lenton (chipaca) |
|
| 2014-04-18 15:10:13 |
John Lenton |
ubuntu-push: status |
In Progress |
Fix Committed |
|
| 2014-04-18 15:10:41 |
John Lenton |
bug task added |
|
ubuntu-push (Ubuntu) |
|
| 2014-04-18 15:10:49 |
John Lenton |
ubuntu-push (Ubuntu): status |
New |
In Progress |
|
| 2014-04-18 15:10:54 |
John Lenton |
ubuntu-push (Ubuntu): assignee |
|
John Lenton (chipaca) |
|
| 2014-04-18 15:10:57 |
John Lenton |
ubuntu-push (Ubuntu): importance |
Undecided |
Critical |
|
| 2014-04-23 09:50:12 |
John Lenton |
bug task deleted |
whoopsie |
|
|
| 2014-04-23 09:50:59 |
John Lenton |
summary |
Returns null string during session start |
Work around whoopsie returning null string during session start |
|
| 2014-04-23 09:58:49 |
John Lenton |
description |
During session startup, the call to whoopsie_identifier_generate will on some devices leave both buffer and error as NULL.
In particular, running http://pastebin.ubuntu.com/7268480/ on mako (and presumably on manta) as a *session* upstart job, with the upstart script of http://pastebin.ubuntu.com/7268498/ will get a null, null for the first 10 seconds (approximately) on mako:
Rebooting (boot in dmesg -T at Thu Apr 17 14:32:36 2014, first "init:" line at Thu Apr 17 14:32:44 2014), in the upstart logs I get a series of
2014-04-17T14:32:54+0000 (null) :: <nil>
(that's also the first such line ,10s after init)
until suddenly
2014-04-17T14:32:56+0000 (null) :: <nil>
2014-04-17T14:32:56+0000 81dc12[...]cd58 :: <nil>
I don't know what's causing this, as it doesn't make sense from what I can read in the code. |
During session startup, the call to whoopsie_identifier_generate will on some devices leave both buffer and error as NULL.
In particular, running http://pastebin.ubuntu.com/7268480/ on mako (and presumably on manta) as a *session* upstart job, with the upstart script of http://pastebin.ubuntu.com/7268498/ will get a null, null for the first 10 seconds (approximately) on mako:
Rebooting (boot in dmesg -T at Thu Apr 17 14:32:36 2014, first "init:" line at Thu Apr 17 14:32:44 2014), in the upstart logs I get a series of
2014-04-17T14:32:54+0000 (null) :: <nil>
(that's also the first such line ,10s after init)
until suddenly
2014-04-17T14:32:56+0000 (null) :: <nil>
2014-04-17T14:32:56+0000 81dc12[...]cd58 :: <nil>
I don't know what's causing this, as it doesn't make sense from what I can read in the code.
--
The whoopsie bug is now in lp:1311571
--
[Impact]
ubuntu-push-client gets an empty string for the whoopsie identifier, which is rather not unique (so connections from multiple devices will get disconnected).
[Test Case]
You need:
* a computer capable of running the ubuntu push server.
* at least two devices using the stable image and that can talk to the computer over the network
on a computer reachable from the devices, do:
mkdir -p test-case-1309231/src/launchpad.net
cd !$
bzr branch lp:ubuntu-push
cd ubuntu-push
make bootstrap
sed -i~ -e 's/127.0.0.1//g' sampleconfigs/dev.json
make run-server-dev
on the devices, edit /etc/xdg/ubuntu-push-client/config.json (or copy it to ~phablet/.config/ubuntu-push-client/config.json and edit it there) so that "addr" points to the IP address of the computer, and port 9090; something like
"addr": "192.168.1.1:9090"
(note there is no https:// as the hosts discovery step is being skipped).
Reboot the devices. Tailing ~phablet/.cache/upstart/ubuntu-push-client.log will show a series of rapid disconnects and reconnects; the output of the server will show a series of empty "registered" (as opposed to "registered" followed by a 256-byte hash).
[Regression potential]
There's a possibility that whoopsie never stops returning a null string, and thus we never progress. Given that for whoopsie to return null seems to imply there is no network device up, that's probably for the best. |
|
| 2014-04-23 10:16:04 |
Dimitri John Ledkov |
nominated for series |
|
Ubuntu Trusty |
|
| 2014-04-23 10:16:04 |
Dimitri John Ledkov |
bug task added |
|
ubuntu-push (Ubuntu Trusty) |
|
| 2014-04-23 10:22:47 |
John Lenton |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2014-04-23 10:47:57 |
John Lenton |
description |
During session startup, the call to whoopsie_identifier_generate will on some devices leave both buffer and error as NULL.
In particular, running http://pastebin.ubuntu.com/7268480/ on mako (and presumably on manta) as a *session* upstart job, with the upstart script of http://pastebin.ubuntu.com/7268498/ will get a null, null for the first 10 seconds (approximately) on mako:
Rebooting (boot in dmesg -T at Thu Apr 17 14:32:36 2014, first "init:" line at Thu Apr 17 14:32:44 2014), in the upstart logs I get a series of
2014-04-17T14:32:54+0000 (null) :: <nil>
(that's also the first such line ,10s after init)
until suddenly
2014-04-17T14:32:56+0000 (null) :: <nil>
2014-04-17T14:32:56+0000 81dc12[...]cd58 :: <nil>
I don't know what's causing this, as it doesn't make sense from what I can read in the code.
--
The whoopsie bug is now in lp:1311571
--
[Impact]
ubuntu-push-client gets an empty string for the whoopsie identifier, which is rather not unique (so connections from multiple devices will get disconnected).
[Test Case]
You need:
* a computer capable of running the ubuntu push server.
* at least two devices using the stable image and that can talk to the computer over the network
on a computer reachable from the devices, do:
mkdir -p test-case-1309231/src/launchpad.net
cd !$
bzr branch lp:ubuntu-push
cd ubuntu-push
make bootstrap
sed -i~ -e 's/127.0.0.1//g' sampleconfigs/dev.json
make run-server-dev
on the devices, edit /etc/xdg/ubuntu-push-client/config.json (or copy it to ~phablet/.config/ubuntu-push-client/config.json and edit it there) so that "addr" points to the IP address of the computer, and port 9090; something like
"addr": "192.168.1.1:9090"
(note there is no https:// as the hosts discovery step is being skipped).
Reboot the devices. Tailing ~phablet/.cache/upstart/ubuntu-push-client.log will show a series of rapid disconnects and reconnects; the output of the server will show a series of empty "registered" (as opposed to "registered" followed by a 256-byte hash).
[Regression potential]
There's a possibility that whoopsie never stops returning a null string, and thus we never progress. Given that for whoopsie to return null seems to imply there is no network device up, that's probably for the best. |
During session startup, the call to whoopsie_identifier_generate will on some devices leave both buffer and error as NULL.
In particular, running http://pastebin.ubuntu.com/7268480/ on mako (and presumably on manta) as a *session* upstart job, with the upstart script of http://pastebin.ubuntu.com/7268498/ will get a null, null for the first 10 seconds (approximately) on mako:
Rebooting (boot in dmesg -T at Thu Apr 17 14:32:36 2014, first "init:" line at Thu Apr 17 14:32:44 2014), in the upstart logs I get a series of
2014-04-17T14:32:54+0000 (null) :: <nil>
(that's also the first such line ,10s after init)
until suddenly
2014-04-17T14:32:56+0000 (null) :: <nil>
2014-04-17T14:32:56+0000 81dc12[...]cd58 :: <nil>
I don't know what's causing this, as it doesn't make sense from what I can read in the code.
--
The whoopsie bug is now in lp:1311571
--
[Impact]
ubuntu-push-client gets an empty string for the whoopsie identifier, which is rather not unique (so connections from multiple devices will get disconnected).
[Test Case]
You need:
* a computer capable of running the ubuntu push server.
* at least two devices using the stable image and that can talk to the computer over the network
on a computer reachable from the devices, do:
mkdir -p test-case-1309237/src/launchpad.net
cd !$
bzr branch lp:ubuntu-push
cd ubuntu-push
make bootstrap
sed -i~ -e 's/127.0.0.1//g' sampleconfigs/dev.json
make run-server-dev
on the devices, edit /etc/xdg/ubuntu-push-client/config.json (or copy it to ~phablet/.config/ubuntu-push-client/config.json and edit it there) so that "addr" points to the IP address of the computer, and port 9090; something like
"addr": "192.168.1.1:9090"
(note there is no https:// as the hosts discovery step is being skipped).
Reboot the devices. Tailing ~phablet/.cache/upstart/ubuntu-push-client.log will show a series of rapid disconnects and reconnects; the output of the server will show a series of empty "registered" (as opposed to "registered" followed by a 256-byte hash).
[Regression potential]
There's a possibility that whoopsie never stops returning a null string, and thus we never progress. Given that for whoopsie to return null seems to imply there is no network device up, that's probably for the best. |
|
| 2014-04-24 07:23:08 |
Chris Halse Rogers |
ubuntu-push (Ubuntu Trusty): status |
In Progress |
Fix Committed |
|
| 2014-04-24 07:23:13 |
Chris Halse Rogers |
bug |
|
|
added subscriber SRU Verification |
| 2014-04-24 07:23:16 |
Chris Halse Rogers |
tags |
|
verification-needed |
|
| 2014-04-24 17:44:24 |
John Lenton |
description |
During session startup, the call to whoopsie_identifier_generate will on some devices leave both buffer and error as NULL.
In particular, running http://pastebin.ubuntu.com/7268480/ on mako (and presumably on manta) as a *session* upstart job, with the upstart script of http://pastebin.ubuntu.com/7268498/ will get a null, null for the first 10 seconds (approximately) on mako:
Rebooting (boot in dmesg -T at Thu Apr 17 14:32:36 2014, first "init:" line at Thu Apr 17 14:32:44 2014), in the upstart logs I get a series of
2014-04-17T14:32:54+0000 (null) :: <nil>
(that's also the first such line ,10s after init)
until suddenly
2014-04-17T14:32:56+0000 (null) :: <nil>
2014-04-17T14:32:56+0000 81dc12[...]cd58 :: <nil>
I don't know what's causing this, as it doesn't make sense from what I can read in the code.
--
The whoopsie bug is now in lp:1311571
--
[Impact]
ubuntu-push-client gets an empty string for the whoopsie identifier, which is rather not unique (so connections from multiple devices will get disconnected).
[Test Case]
You need:
* a computer capable of running the ubuntu push server.
* at least two devices using the stable image and that can talk to the computer over the network
on a computer reachable from the devices, do:
mkdir -p test-case-1309237/src/launchpad.net
cd !$
bzr branch lp:ubuntu-push
cd ubuntu-push
make bootstrap
sed -i~ -e 's/127.0.0.1//g' sampleconfigs/dev.json
make run-server-dev
on the devices, edit /etc/xdg/ubuntu-push-client/config.json (or copy it to ~phablet/.config/ubuntu-push-client/config.json and edit it there) so that "addr" points to the IP address of the computer, and port 9090; something like
"addr": "192.168.1.1:9090"
(note there is no https:// as the hosts discovery step is being skipped).
Reboot the devices. Tailing ~phablet/.cache/upstart/ubuntu-push-client.log will show a series of rapid disconnects and reconnects; the output of the server will show a series of empty "registered" (as opposed to "registered" followed by a 256-byte hash).
[Regression potential]
There's a possibility that whoopsie never stops returning a null string, and thus we never progress. Given that for whoopsie to return null seems to imply there is no network device up, that's probably for the best. |
During session startup, the call to whoopsie_identifier_generate will on some devices leave both buffer and error as NULL.
In particular, running http://pastebin.ubuntu.com/7268480/ on mako (and presumably on manta) as a *session* upstart job, with the upstart script of http://pastebin.ubuntu.com/7268498/ will get a null, null for the first 10 seconds (approximately) on mako:
Rebooting (boot in dmesg -T at Thu Apr 17 14:32:36 2014, first "init:" line at Thu Apr 17 14:32:44 2014), in the upstart logs I get a series of
2014-04-17T14:32:54+0000 (null) :: <nil>
(that's also the first such line ,10s after init)
until suddenly
2014-04-17T14:32:56+0000 (null) :: <nil>
2014-04-17T14:32:56+0000 81dc12[...]cd58 :: <nil>
I don't know what's causing this, as it doesn't make sense from what I can read in the code.
--
The whoopsie bug is now in lp:1311571
--
[Impact]
ubuntu-push-client gets an empty string for the whoopsie identifier, which is rather not unique (so connections from multiple devices will get disconnected).
[Test Case]
You need:
* a computer capable of running the ubuntu push server.
* a device using the stable image and that can talk to the computer over the network
on the computer, do:
mkdir -p test-case-1309237/src/launchpad.net
cd !$
bzr branch lp:ubuntu-push
cd ubuntu-push
make bootstrap
sed -i~ -e 's/127.0.0.1//g' sampleconfigs/dev.json
make run-server-dev
on the device, edit /etc/xdg/ubuntu-push-client/config.json (or copy it to ~phablet/.config/ubuntu-push-client/config.json and edit it there) so that "addr" points to the IP address of the computer, and port 9090; something like
"addr": "192.168.1.1:9090"
(note there is no https:// as the hosts discovery step is being skipped).
Reboot the device. The output of the server will show an empty "registered" (as opposed to "registered" followed by a 256-byte hash).
[Regression potential]
There's a possibility that whoopsie never stops returning a null string, and thus we never progress. Given that for whoopsie to return null seems to imply there is no network device up, that's probably for the best. |
|
| 2014-04-24 21:15:10 |
John Lenton |
tags |
verification-needed |
verification-done |
|
| 2014-04-30 05:07:59 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/trusty-proposed/ubuntu-push |
|
| 2014-05-01 15:33:24 |
Launchpad Janitor |
ubuntu-push (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
| 2014-05-01 15:33:46 |
Colin Watson |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2014-05-05 13:26:05 |
Launchpad Janitor |
ubuntu-push (Ubuntu): status |
In Progress |
Fix Released |
|
| 2014-05-06 12:40:37 |
John Lenton |
ubuntu-push: status |
Fix Committed |
Fix Released |
|
