[15:19] <stgraber> plars: oh, not sure if you saw the lengthy discussion I had with asac and lool, but once that change lands, you'll also see incrementing build IDs in daily-proposed
[15:19] <davmor2> popey: I have apps
[15:19] <AskUbuntu> Need help to installUbuntu touch | http://askubuntu.com/q/342218
[15:19] <stgraber> plars: and those IDs won't match with daily after an image is promoted, so just ignore the daily channel for now and assume it's right.
[15:20] <plars> stgraber: oh no I didn't, even better, so we can just use the single build id and not the triplet?
[15:20] <plars> doanac, josepht, cjohnston: ^
[15:20] <stgraber> plars: you should still show the triplet because the single build id isn't terribly easy for developers to figure out what you're testing
[15:20] <davmor2> asac: no 3g here at all for me
[15:21] <ogra_> plars, we need the cdimage id for identifying the rootfs
[15:21] <stgraber> plars: but you won't see version rollback in daily-proposed anymore
[15:21] <asac> davmor2: regression?
[15:21] <asac> davmor2: from daily?
[15:21] <plars> josepht: that should at least simplify the sorting issues
[15:22] <ogra_> asac, the image with the ID 5 :)
[15:22] <davmor2> asac: yeap daily at least made an effort at 3g, showed me the logo in the indicator at least
[15:22] <mpt> oreneeshy, https://wiki.ubuntu.com/SystemSettings?action=diff&rev2=48&rev1=47
[15:22] <asac> davmor2: so the 4 RO image worked?
[15:22] <asac> ogra_: you guys uploaded ofono
[15:22] <asac> awe: ^^
[15:22] <ogra_> asac, dont look at me :P
[15:23] <slangasek> jdstrand: the apparmor sysvinit script runs in rcS, which is only run from /etc/init/rc-sysinit.conf - so after "filesystem" and "static-network-up" events.  On the phone these events actually happen quite early, but there's still no strong ordering guarantee here
[15:23] <awe> asac, yes?
[15:23] <asac> awe: can we back it out?
[15:23] <ogra_> asac, only packaging cleanup chnages
[15:23] <awe> back what out?
[15:23] <asac> hmm
[15:23] <awe> asac, context please...
[15:23] <asac> awe: ofono landing
[15:23] <asac> 3g is broken on todays images
[15:23] <ogra_> asac, see the changelog
[15:23] <ogra_> https://launchpad.net/ubuntu/saucy/+source/ofono/1.12-0ubuntu8
[15:23] <awe> asac, one sec
[15:24] <awe> mid-stand-up
[15:24] <asac> davmor2: so ...
[15:24] <ogra_> asac, its only changes to the control file
[15:24] <asac> awe: bring it up there
[15:24] <asac> davmor2: your statement above doesnt relaly sound like you had much luck with 3g before
[15:25] <ogra_> asac, there is no reason to back it out ... "Updated Standard-Version to 3.9.4 .... Update debian/compat to 9"
[15:25] <ogra_> asac, seriously, no code changes
[15:25] <davmor2> asac: I showed up in nmcli c and in ofono scripts,  just didn't connect in nm till you restarted nm.  now it isn't showing up anywhere
[15:25] <davmor2> asac: let me reboot and see if that fixes things
[15:25] <awe> cyphermox, ^^
[15:26] <awe> davmor2, did  you open a new bug?
[15:26] <cyphermox> I'm looking, but I mean, it's unclear what could be happening
[15:26] <Wellark> oSoMoN: approved-
[15:26] <davmor2> awe: nope I enabled the debugging and everything worked
[15:26] <oSoMoN> Wellark: thanks
[15:26] <Wellark> oSoMoN: but ci keeps failing
[15:26] <Wellark> I will top-approve anyway
[15:26] <awe> davmor2, but you have no 3g, correct?
[15:27] <Wellark> the autolander can figure it out
[15:27] <asac> ogra_: we also had hybris landings etc.
[15:27] <awe> if everything worked, why is asac pinging me?
[15:27] <asac> awe: read davmor2's messages
[15:27] <davmor2> awe: not on build 5 no
[15:27] <asac> for him its not working
[15:27] <asac> ogra_: can you cary into the standup
[15:27] <ogra_> asac, that would be one to worry about ... rather than a debian/control cleanup ijn ofono :)
[15:27] <cyphermox> davmor2: please reproduce the bug, file a new bug in LP and just attach /var/log/syslog, ip route, nmcli dev, nmcli con...
[15:27] <asac> ogra_: the idea of coordiating changes that are not going through daily-release with me and sil etc.?
[15:27] <asac> thx
[15:28] <davmor2> asac: that's annoying, the tutor starts on every reboot by the look of it
[15:28] <asac> davmor2: yeah thats a known issue
[15:28] <asac> mterry: ^^
[15:28] <asac> mterry: seems your thing doesnt stop starting on RO images
[15:28] <rsalveti> asac: nothing changed in ofono
[15:29] <asac> rsalveti: the build before we got hybris
[15:29] <mterry> asac, the data for AccountsService is stored in /var/lib/AccountsService/users/
[15:29] <asac> jdstrand: ^^
[15:29] <asac> mterry: you might need to change that a bit now
[15:29] <asac> mterry: check with jdstrand
[15:29] <mterry> asac, how do the RO images work?  Can we say "make this directory RW"?
[15:30] <davmor2> cyphermox: bug against ofono or nm?
[15:30] <sergiusens> ChickenCutlass: try http://bazaar.launchpad.net/~sergiusens/+junk/network/view/head:/network_gprs_provision_test.sh
[15:30] <asac> mterry: not sure. check with jdstrand. he is the architect behind this
[15:30] <asac> and can make changes or tell you what to do :)
[15:30] <sergiusens> plars: too ^^
[15:30] <lool> Ok, I've run music-app and friends-app autopilot tests before and after adding qtdeclarative5-friends-plugin, gstreamer0.10-fluendo-mp3 and gstreamer1.0-fluendo-mp3 and got all passes (2 and 4); so uploaded new meta
[15:30] <pmcgowan> lool, awesome
[15:31] <asac> davmor2: so i heard that maguro 3g is inheretently flaki
[15:31] <asac> davmor2: can you focus on the othe rfeatures like call etc.?
[15:31] <rsalveti> asac: the 3g issues was there yesterday already
[15:31] <popey> asac: mako seems good with read only 20130906
[15:31] <asac> rsalveti: for him yesterdays build was buggy, but better
[15:31] <rsalveti> and we discussed in our standup, I'd probably guess it's the same issue davmor2 had yesterday
[15:31] <asac> popey: thanks!
[15:31] <rsalveti> need logs to say what is happening
[15:31] <asac> plars: ok so lets get 06 through our dashboard
[15:31] <rsalveti> ofono package didn't break anything
[15:32] <cyphermox> davmor2: against NM, we'll reassign if necessary
[15:33] <cyphermox> so, how readonly is the readonly image?
[15:33] <cyphermox> like, how's /var ? :)
[15:33] <cyphermox> or more specifically, /var/lib
[15:33] <sergiusens> cyphermox: very, but /vcarlib/ofono and /etc/NetworkManager/system-connections is writable
[15:33] <cyphermox> ok
[15:33] <asac> rsalveti: sorry, i just try to get a clear message whether th ecurrent image has regression over the previous ones
[15:33] <asac> and hear that its completely broken and worked yesterday a bit
[15:33] <asac> so i have to follow up on that i feel :)
[15:33] <ogra_> asac, who tested it on maguro ?
[15:33] <sergiusens> asac: it's not a regression, it's a long standing bug
[15:33] <cyphermox> what about /var/lib/NetworkManager ?
[15:33] <lool> oSoMoN: Hey, do you look after libqt5webkit5?
[15:33] <ogra_> (yesterday)
[15:33] <rsalveti> asac: right, but please ask for some sort of logs as well :-)
[15:34] <cyphermox> sergiusens: ^^ this is important
[15:34] <lool> oSoMoN: I see it depends on gstreamer 0.10, but I don't know whether that relates to qtmultimedia's version or not (I assume not)
[15:34] <cwayne_> stgraber, what version of the initrd should i have?  how can i debug this?
[15:34] <plars> asac: it's mostly done on maguro, weather-app had some strange failure and needed to be restarted, but otherwise looks good so far
[15:34] <cyphermox> sergiusens: /run/NetworkManager too, but I guess that would be readwrite anyway
[15:35] <plars> asac: mako is still in progress
[15:35] <asac> plars: and mako?
[15:35] <rsalveti> lool: 5.1.1 was ported to use gst 1.0
[15:35] <asac> plars: how far?
[15:35] <plars> asac: it's on the calendar one now, about half-way down the list
[15:35] <ogra_> asac, 3g worked yesterday on mako ... nobody tested maguro ... 3g works today on mako and is broken today on maguro ... there is no regression since there was no former test
[15:35] <lool> rsalveti: ok thanks
[15:35] <oSoMoN> lool: I don’t directly look after it, though I’m interested in any issues encountered with it
[15:35] <lool> oSoMoN: gst 1.0 is all I needed to know
[15:35] <sergiusens> cyphermox: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/lxc-android-config/saucy/view/head:/etc/system-image/writable-paths
[15:36] <stgraber> cwayne_: to see the dmesg entry, any initrd from the last month should do that
[15:36] <oSoMoN> lool: I’d need to check in the code, but I don’t think it’s tied to qtmultimedia
[15:36] <plars> asac: you'll see from http://reports.qa.ubuntu.com/smokeng/saucy/image/4033/ that mako looks good so far, calendar is the first one we expect to fail at this point
[15:36] <lool> seb128: I see packagekit-backend-aptcc pulls in gst 0.10; I presume that's for automatic installation of missing codecs; what's the usual way we deal with new gst versions there?
[15:36] <oSoMoN> ah, I just saw rsalveti’s answer, sorry for the noise
[15:36] <lool> seb128: how would we go to gst 1.0 with it?  does it imply we have to switch the desktop to 1.0 (seems too late)?  or do we need to fork it?
[15:36] <cwayne_> stgraber, let me try again on a fresh build
[15:37] <lool> actually given that it's .deb, it seems it would be a matter of splitting this out in a separate package
[15:37] <sergiusens> cyphermox: hmm, missing /var/lib/ofono
[15:37] <sergiusens> stgraber:
[15:37] <stgraber> cwayne_: that's the code that gets run every time you boot: http://paste.ubuntu.com/6070846/
[15:37] <davmor2> cyphermox: https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1221802
[15:37] <stgraber> cwayne_: the only change I did after our discussion was adding the chown, the rest has always been there
[15:38] <sergiusens> stgraber: /var/lib/ofono needs to persist
[15:38] <stgraber> sergiusens: ok
[15:38] <cwayne_> hm
[15:38] <sergiusens> stgraber: was it taken out? I thought it was in
[15:38] <stgraber> sergiusens: network-manager is in there but not ofono
[15:38] <cyphermox> without /var/lib/ofono, nothing of the 3G connections is likely to work
[15:39] <cwayne_> stgraber, wait, so .customized has to be set *before* we customize it?
[15:39] <ogra_> cyphermox, hmm, why does it work for popey then >
[15:39] <ogra_> (or others that use a mako)
[15:39] <cjwatson> mterry: lxc-android-config has configuration for writable paths (etc/system-image/writable-paths)
[15:39] <popey> ogra_: hmm?
[15:39] <sergiusens> ogra_: it worked for me too, which makes me confused
[15:39] <stgraber> cwayne_: no, "! -e" means "doesn't exist"
[15:40] <ogra_> sergiusens, yeah, thats very weird
[15:40] <cwayne_> ah, right
[15:40] <stgraber> sergiusens: I'll add it
[15:40] <cyphermox> ogra_: can files be written in /var/lib/ofono at all, or do they just get removed when you reboot the phone?
[15:40] <ogra_> popey, theoretically 3G shouldnt work
[15:40] <sergiusens> cyphermox: no, they can't
[15:40] <seb128> lool, hey
[15:40] <sergiusens> cyphermox: root@ubuntu-phablet:/# touch /var/lib/ofono/s
[15:40] <ogra_> irs a readonly fs
[15:40] <sergiusens> touch: cannot touch '/var/lib/ofono/s': Read-only file system
[15:41] <popey>  /ril_0     gsm               connecting (prepare)
[15:41] <cyphermox> then how could NM read files in /var/lib/ofono written by ofono, to be able to know what to activate?
[15:41] <seb128> lool, gst doesn't change often enough that we have an "usually" there, we had one transition from gst 0.8 to 0.10 in Ubuntu before that 0.10 to 1.0
[15:41] <cyphermox> sergiusens:  this leads me to believe you were not in fact using the readonly image :)
[15:41] <seb128> lool, we switched desktop to 1.0 in raring (we didn't manage to get 0.10 out of the CD though IIRC)
[15:41] <stgraber> mterry: did I understand that you also want /var/lib/AccountsService/users/ to be writable?
[15:41] <ogra_> cyphermox, dunno, but multiple people claimed they had 3G today ... with readonly images
[15:41] <stgraber> mterry: (I'm updating the list now)
[15:41] <sergiusens> cyphermox: no, I may have remounted rw to add my serviceprovider stuff and forgot to remount ro again
[15:42] <sergiusens> cyphermox: only thing I can think of
[15:42] <lool> seb128: so the codec installation feature is probably borken I guess?
[15:42] <lool> seb128: well, I guess it doesn't really matter if libgstreamer0.10-0 is pulled by packagekit on the touch image for now
[15:42] <seb128> lool, I can't tell
[15:42] <lool> it wont break anything in itself, we dont use this feature on touch right now anyway
[15:42] <seb128> lool, why would it be broken?
[15:43] <lool> seb128: well I guess it searches for 0.10 plugins instead of the 1.0 ones you'd need!
[15:43] <awe> stgraber, /var isn't write-able?
[15:43] <stgraber> awe: only subsets of it are
[15:43] <ogra_> awe, only the dirs listed in the whitelist are writable
[15:43] <ogra_> (/var isnt)
[15:43] <seb128> lool, do we use that backend?
[15:43] <sergiusens> awe: only stuff in http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/lxc-android-config/saucy/view/head:/etc/system-image/writable-paths
[15:44] <awe> and did we inspect every piece of code that's installed?  ;)-
[15:44] <cyphermox> sergiusens: I don't know. otherwise it would have to be not readonly while ofono writes provisioning data to disk and become readonly after
[15:44] <awe> fail
[15:44] <ogra_> awe, nope, we have 6 weeks to do that :P
[15:44] <lool> seb128: for click yes
[15:44] <awe> ofono
[15:44] <lool> seb128: but not for gst in touch
[15:44] <seb128> lool, well, not for codecs on the desktop
[15:44] <lool> seb128: I dont know about gst in desktop
[15:44] <seb128> lool, we use sessioninstaller
[15:44] <seb128> which is on gstreamer1.0
[15:45] <awe> ogra_, is someone going to write a tool that does this automatically?
[15:45] <seb128> lool, https://launchpad.net/ubuntu/+source/sessioninstaller/0.20+bzr134-0ubuntu4
[15:45] <lool> seb128: so should we just turn this off or something
[15:45] <ogra_> awe, that tool is called stgraber :)
[15:45] <seb128> lool, I've no idea about what click is doing with pkgkit sorry :/
[15:45] <mterry> jdstrand, whoops, got disconnected.  When you have a sec, I'd like to talk RO image stuff
[15:45] <lool> seb128: unrelated stuff; packagekit is used as the dbus service to request click intsall
[15:45] <lool> seb128: or click update, or click removal or click list
[15:45] <asac> davmor2: so i think awe and cyphermox confirmed that this 3g issue is not really a regressoin, lets focus on the rest then (call, wifi, etc.)
[15:46] <awe> ogra_, and so what if some pieces of code wants to write to /var when the date rolls at the end of the year, and we hadn't noticed it?
[15:46] <sergiusens> asac: yes
[15:46] <seb128> lool, we should disable the codec stuff or split it out in its binary I guess
[15:46] <sergiusens> asac: there is a regression
[15:46] <sergiusens> asac: /var/lib/ofono is not writable
[15:46] <asac> aha
[15:46] <awe> asac, if it's a RO image, not necessarily true
[15:46] <asac> my hero!!!
[15:46] <asac> :)
[15:46] <asac> awe: the other image doesnt matter anymore for me :)
[15:46] <asac> RO !!!
[15:46] <asac> i am only talking about RO :)
[15:47] <awe> ogra_, can you fix?  ^^
[15:47] <stgraber> ogra_: I have the fix for ofono
[15:47] <stgraber> aw^
[15:47] <stgraber> awe: ^
[15:47] <sergiusens> awe: stgraber is already fixing
[15:48] <stgraber> just waiting to hear from mterry about accountservice
[15:48] <stgraber> since it'd be stupid to do two uploads in a 5min interval
[15:48] <davmor2> asac: no 3g, messaging indicator give no signal that there is a message, with wifi enabled unless I reboot I don't see click app, using the camera Locked up the app completely (I'll carry on after a reboot)
[15:48] <mterry> stgraber, I'm just waiting on jdstrand
[15:48] <asac> davmor2: what out of that is a regresison over our 4 build?
[15:49] <awe> stgraber, what about /var/lib/dhcp?
[15:49] <lool> seb128: seems useless in Ubuntu AIUI
[15:49] <ogra_> awe, we need to notice and update the scripts
[15:49] <ogra_> awe, click apps have their own writable space and the core OS shouldnt randomly change
[15:49] <ogra_> awe, read: we need to test enough to know about such an issue in advance and preemptively take action
[15:49] <ogra_> before the user gets it
[15:49] <seb128> lool, I think so as well
[15:49] <davmor2> asac: I never used the 4 build I was on daily,  on daily the camera worked so that might be a RO issue
[15:49] <sergiusens> stgraber: can't we make all of /var writable?
[15:49] <asac> awe: stgraber: feels like revisiting everything that is in /var/lib... might be good :)
[15:50] <awe> +1
[15:50] <stgraber> awe: shouldn't be used, NM uses /var/lib/NetworkManager for that, which is already writable
[15:50] <stgraber> sergiusens: nope
[15:50] <stgraber> sergiusens: we don't support overlays, so making all of /var writable would mean copying it all to writable storage on first boot
[15:50] <asac> stgraber: i think every directory in /var/lib should be explicitley looked at
[15:50] <stgraber> sergiusens: then if something gets added or removed from the image, it'll never be copied to writable storage
[15:50] <davmor2> asac: so now the camera app just crashes clean if I try to use it I'll try and get some feedback for that after
[15:51] <sergiusens> stgraber: if its the debian packaging stuff ony, do we care?
[15:51] <jdstrand> mdeslaur: ack
[15:51] <asac> davmor2: i assume its not writing to the right directory
[15:51] <jdstrand> slangasek: thanks
[15:52] <asac> oSoMoN: can you confirm that camera app is writing to a goo dlocation on RO image?
[15:52] <jdstrand> asac: following up with mterry
[15:52] <jdstrand> mterry: what's up?
[15:52] <rsalveti> jdstrand: sorry, just saw the backlog, so will you follow the apparmor x udev in ubuntu-dev?
[15:52] <jdstrand> rsalveti: yes
[15:52] <cwayne_> stgraber, ok, so this time i did see the 'copying custom content' line in dmesg, but still owned by system:system
[15:52] <oSoMoN> asac: that’s a question for gusch_
[15:52] <asac> stgraber: mterry also wants to write to /var/lib/AccountsService/users/ from the intro
[15:52] <rsalveti> jdstrand: ok, thanks, will review/reply the ml then
[15:53] <oSoMoN> asac: do we have some documentation on what a good location is?
[15:53] <asac> jdstrand: ^^
[15:53] <jdstrand> rsalveti: will be in a bit. responding to various pings/emails/etc. you know, one's regular morning :)
[15:53] <asac> we are kind of finding a few places in /var/lib that should be writable
[15:53] <rsalveti> yeah :-)
[15:53] <asac> so lets look at all
[15:53] <rsalveti> this channel is kind of crazy
[15:53] <mterry> asac, not just intro.  Lots of things are using AS for user data
[15:53] <mterry> launcher items, system settings
[15:53] <sergiusens> oSoMoN: this is part of what a good location is http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/lxc-android-config/saucy/view/head:/etc/system-image/writable-paths
[15:53] <sergiusens> oSoMoN: then you have all the apparmor stuff
[15:53] <rsalveti> asac: so it wasn't working at all in ro :-)
[15:53] <oSoMoN> sergiusens: thx
[15:54] <asac> rsalveti: thats what i mean :)
[15:54] <gusch_> asac: camera writes to ~/Pictures and ~/Videos (in case it will be able to record videos again)
[15:54] <asac> gusch_: thats not ok i think
[15:54] <mterry> jdstrand, AccountsService uses /var/lib/AccountsService/users/ to store data about users.  But that isn't writable in the RO images.  Can we poke a hole for that directory?
[15:54] <jdstrand> mterry: people are pinging me about /var/lib/AccountsService/users/ but I am lacking context
[15:54] <jdstrand> mdeslaur: can you listen in?
[15:54] <sergiusens> oSoMoN: which is cat /usr/share/apparmor/easyprof/policygroups/ubuntu/1.0/picture_files
[15:54] <asac> gusch_: you have to use XDG_ path's
[15:54] <rsalveti> people need to be clear that when they say they are using the RO image that means they never remounted it as rw :-)
[15:54] <asac> gusch_: check with jdstrand
[15:54] <rsalveti> otherwise it's hard to track down the issues
[15:54] <mterry> jdstrand, it's used by AccountsService to store data like "has the user skipped the demo", "what are the user's launcher items", "should the welcome screen show the infographic"
[15:55] <mdeslaur> jdstrand: listen in on what?
[15:55] <ogra_> rsalveti, so many variables
[15:55] <sergiusens> asac: writing to ~/Pictures is correct from an apparmor point of view
[15:55] <sergiusens> asac: check your /usr/share/apparmor/easyprof/policygroups/ubuntu/1.0/picture_files
[15:55] <rsalveti> ogra_: yup :-)
[15:55] <awe> straber, ok... looks like /var/lib/dhcp isn't being used, but /var/lib/bluetooth is... again for settings
[15:55] <asac> sergiusens: ok so the fact that camera doesnt save files for me and hangs is a different regression?
[15:55] <asac> felt very related because it started on RO
[15:55] <sergiusens> asac: there was some talk about xdg translations that I guess jdstrand recalls more than me
[15:55] <jdstrand> mdeslaur: what mterry is talking about
[15:55] <josepht> rsalveti: I'm assuming that applies for automated testing as well? (RE: RO never mounted RW)
[15:56] <jdstrand> mterry: ok, can we back up. I have no context. what is the issue?
[15:56] <rsalveti> josepht: yup
[15:56] <gusch_> asac jdstrand camera uses QStandardPaths in fact
[15:56] <mdeslaur> mterry, jdstrand: oh, that's because the image is ro?
[15:56] <asac> gusch_: awesome ... that SHOULD be allright then ...
[15:56] <mdeslaur> mterry, jdstrand: I guess stgraber needs to poke that hole, I'm not sure how it's done
[15:56] <asac> gusch_: do you have a maguro? maybe try :)
[15:56] <asac> maybe you can see
[15:56] <davmor2> asac: video playback of sintel sucks on 5 but didn't on daily
[15:56] <jdstrand> gusch_: you need to append $app_pkgname to the standard path. $app_pkgname is "name" in the click manifest
[15:57] <mterry> mdeslaur, jdstrand: So AS (AccountsService) is a system daemon that stores some data on the user's behalf so that the greeter and the user can both set/read it
[15:57] <rsalveti> davmor2: it should suck with both
[15:57] <rsalveti> davmor2: same hardware?
[15:57] <ogra_> asac, hmm, for me it crashes the whole shell
[15:57] <jdstrand> mterry: /me nods
[15:57] <gusch_> jdstrand: camera-app is no click package
[15:57] <davmor2> rsalveti: yeap
[15:57] <ogra_> asac, taking a pic that is
[15:57] <sergiusens> jdstrand: from the apparmor camera_files profile it seems he wants $HOME/Pictures to write the images
[15:57] <mterry> mdeslaur, jdstrand: It's used for a variety of things I listed above.  Right now on the RO image we have a bug where the first-use demo keeps appearing
[15:57] <asac> ogra_: so what landed there? :)
[15:57] <ogra_> oh, and all input apparently
[15:57] <sergiusens> gusch_: it will be
[15:57] <gusch_> asac: you mean on monday? EOD is coming very close ...
[15:57] <rsalveti> davmor2: then it could be that something else is also using your cpu
[15:57] <mterry> mdeslaur, jdstrand: because AS can't write to that directory to save the fact that it should be skipped
[15:58] <stgraber> jdstrand, mterry, awe: ok, uploading lxc-android-config with /var/lib/AccountsService/users/ and /var/lib/ofono added
[15:58] <plars> rsalveti: you do realize that in the test automation, we currently have to mount the RO images as RW right?
[15:58] <rsalveti> davmor2: because in both cases it was doing software decode
[15:58] <rsalveti> plars: seriously?
[15:58] <ogra_> asac, no idea, someone (with fater internet) should try a rw image and try to confirm
[15:58] <gusch_> sergiusens: it will what?!? All apps are going to be click packages?!?
[15:58] <mdeslaur> stgraber: thanks
[15:58] <jdstrand> gusch_: mterry ah, right, just addjust lxc-android-config. looks like stgraber is doing it for you
[15:58] <plars> rsalveti: yes
[15:58] <ogra_> asac, else i'd blame ro here too
[15:58] <mterry> jdstrand, mdeslaur: And I just wanted to see if it wass OK to add the directory to the RW part
[15:58] <jdstrand> gusch_: sorry, meant for mterry
[15:58] <lool> pmcgowan, dpm: Checked 0.10 / 1.0 gst rdepends; http://paste.ubuntu.com/6070923/ is 0.10 rdepends; seems doable with qtmultimedia/mediaplayer-app from Jim and qt 5.1.x update moved to gst 1.0, only gallery app remains
[15:58] <mterry> stgraber, thanks!
[15:58] <rsalveti> plars: haha, then we're not *really* testing the ro stuff in here
[15:58] <jdstrand> mterry: seems fine to me :)
[15:58] <davmor2> rsalveti: I've gone from rw to ro I'm wondering if it was writing a cache file some where and now can't
[15:58] <rsalveti> we could face similar issues as we had with ofono
[15:59] <asac> rsalveti: we know that
[15:59] <asac> and its worked on
[15:59] <lool> pmcgowan, dpm: (and updating seeds obviously)
[15:59] <pmcgowan> lool, ack
[15:59] <lool> pmcgowan: would I push the gallery-app gst request now?
[15:59] <pmcgowan> sure
[15:59] <pmcgowan> bug it I suppose
[15:59] <jdstrand> mterry: the ro bit is more about system-image than security. granted, we get security benefit from it, but that is a side-affect
[15:59] <rsalveti> asac: right, that's important to be fixed, otherwise we can really trust the test results
[15:59] <asac> rsalveti: no need to repeat
[15:59] <asac> :)
[15:59] <stgraber> jdstrand, mterry, awe: uploaded
[15:59] <dpm> awesome, thanks lool
[16:00] <asac> rsalveti: it is prevailining my day now
[16:00] <asac> :)
[16:00] <asac> domination :)
[16:00] <rsalveti> asac: :-)
[16:00] <jdstrand> sergiusens: ok, I'm lacking context on this too. what is the question for me?
[16:00] <jdstrand> gusch_: ^
[16:00] <ChickenCutlass> asac, ogra_ 3G not working for me on RO image as well
[16:00] <asac> rsalveti: i didnt push long enough back
[16:00] <asac> i asked a month ago to fix infrastructure first
[16:00] <rsalveti> ChickenCutlass: it's broken
[16:00] <awe> ChickenCutlass, read the backlog
[16:00] <asac> :)
[16:00] <ogra_> ChickenCutlass, yeah, it was a missing rw dir
[16:00] <ChickenCutlass> ah
[16:00] <ChickenCutlass> ok
[16:00] <ChickenCutlass> lol
[16:00] <rsalveti> ChickenCutlass: stgraber is fixing it
[16:00] <ChickenCutlass> got it
[16:00] <sergiusens> asac: this is camera http://paste.ubuntu.com/6070937/
[16:00] <seb128> mpt, can you remind me who we should ping if we need system-settings assets? For the background panel we are probably going to need the images for the welcome/home screens (e.g the bits representing the greeter/dash over the images in https://wiki.ubuntu.com/Appearance?action=AttachFile&do=get&target=phone-background.mockup.png)
[16:00] <ogra_> camera-app seems to misbehave in maguro ro
[16:00] <gusch_> jdstrand: is camera-app allowed to write to ~/Pictures
[16:00] <awe> jdstrand, popular phrase these days:  "lacking context"  ;)-
[16:00] <sergiusens> jdstrand: the use of xdg dirs and translations
[16:01] <rsalveti> asac: that's fine, we'll fix it next week
[16:01] <sergiusens> gusch_: yes all apps are going to be click
[16:01] <asac> rsalveti: the RO image?
[16:01] <rsalveti> the ro testing
[16:01] <ogra_> asac, everything :)
[16:01] <ogra_> the world
[16:01] <rsalveti> as long you let us stay focused, we'll fix it :P
[16:01] <sergiusens> ogra_: http://paste.ubuntu.com/6070937/
[16:01] <ogra_> haha
[16:02] <ogra_> sergiusens, ouch, that looks like an android prob
[16:02]  * cjwatson gets click package unregistration/removal working with the exception that it doesn't yet remove user data
[16:02] <jdstrand> gusch_: regarding writing to ~/Pictures, there was some discussion about that on the list because Pictures is translatable (it is one of the xdg user dirs)
[16:02] <sergiusens> ogra_: yes
[16:02] <ogra_> rsalveti, ^^^
[16:02] <ogra_> camera service dies
[16:02] <asac> ogra_: lool: so i am tempted to say we go back to touch as our release baseline
[16:02] <jdstrand> gusch_, sergiusens: I don't recall where we landed on that
[16:02] <asac> and wait till all the issues get fixed
[16:02] <ogra_> asac, you mean rw
[16:03] <davmor2> asac: keyboard still isn't great but that was happening on daily too
[16:03] <asac> ogra_: touch == rw, yes
[16:03] <asac> touch_ro == RO
[16:03] <jdstrand> gusch_: my previous answer was regarding xdg *base* dirs, not xdg *user* dirs. sorry for the confusion
[16:03] <ogra_> heh, ok
[16:03] <sergiusens> jdstrand: I think we were going to keep ~/Pictures on fs and only change the name you view since the fs is not exposed to users ... lool tedg might recall more
[16:03] <rsalveti> sergiusens: sorry, what is that issue exactly?
[16:03] <jdstrand> gusch_, sergiusens: I can say that I plan to upload apparmor which will handle the translated directory correctly
[16:03] <sergiusens> rsalveti: http://paste.ubuntu.com/6070937/
[16:03] <ogra_> sergiusens, jdstrand, note that we ship /home/phablet/.config/user-dirs.dirs which defines the XDG_USER_DIRS
[16:03] <lool> asac: how many tests are passing with the image read-write?
[16:04] <rsalveti> sergiusens: right, but how did you get that
[16:04] <cjwatson> I thought we were doing non-translatable directories only on the grounds that the directory names won't be visible directly anyway
[16:04] <rsalveti> sergiusens: which image, instructions, what exploded, etc
[16:04] <ogra_> rsalveti, taking a pic on maguro
[16:04] <sergiusens> rsalveti: taking a picture
[16:04] <ogra_> rsalveti, latest ro image
[16:04] <asac> lool: read write is good, but RO kills dogfoodable for sure
[16:04] <asac> nothing works kind of :)
[16:04] <asac> all wireless etc.
[16:04] <sergiusens> rsalveti: let me switch to rw
[16:04] <gusch_> jdstrand: camera uses QStandardDirs to get the location
[16:04] <cjwatson> and translating directories on the fs rather than the UI layer is a horrible misdesign anyway, so ubuntu-touch is a good opportunity to get rid of it
[16:04] <asac> and i need to release to get unity landed and other stuff
[16:04] <tedg> sergiusens, lool, I don't see the question in the backlog... what's up?
[16:04] <asac> that is stalled
[16:04] <jdstrand> gusch_, sergiusens: I can also say that 'xdg-user-dir PICTURES' will give you the translated directory
[16:04] <lool> asac: wireless works for me
[16:05] <sergiusens> rsalveti: ogra_ mount -o remount,rw / allows Pictures
[16:05] <rsalveti> sergiusens: seems the camera client crashed, so it's probably our hal or app layer
[16:05] <ogra_> sergiusens, great, so its another ro issue
[16:05] <ogra_> but which :)
[16:05] <jdstrand> gusch_: that's fine, but there are *base* dirs and *user* dirs. I was referring to base dirs in my initial comment because of an earlier discussion in this channel. I just wanted to clarify my initial XDG/click comment is all
[16:06] <asac> lool: well, ofono is busted
[16:06] <sergiusens> ogra_: strace which tell
[16:06] <ogra_> yeah
[16:06] <rsalveti> seems camera is busted as well
[16:06] <sergiusens> lool: /var/lib/ofono is missing r/w
[16:07] <jdstrand> seb128: where did we land on people using xdg user dirs, like Pictures. gusch_ is using QStandardDirs to find it-- is that what he should be using? are we going to allow Pictures to be translated or use some symlink hackery-wackery to make sure apps can depend on Pictures?
[16:07] <daker> Kaleo: hi, do you have anyidea why this is happening https://plus.google.com/u/0/photos?pid=5912883833171629858&oid=101694416703170881163 ?
[16:08] <daker> Kaleo: i was thinking it's bug 1202403 but i am not really sure
[16:08] <jdstrand> seb128: note that I will be adjusting apparmor to handle translated xdg user dirs, so apparmor won't be an issue
[16:08] <seb128> jdstrand, the consensus on the list seemed to be that we would not allow names on disk to be translated anymore
[16:08] <seb128> lool: ^ that was right?
[16:08] <sergiusens> seb128: I thought so too
[16:08] <seb128> jdstrand, we control enough of the UI to be confident we are not going to "leak" the filesystem details to users
[16:08] <lool> sergiusens: does it need to be persistent?
[16:09] <jdstrand> seb128: but depending on your answer, it might influence when I land such change to apparmor ;)
[16:09] <cjwatson> seb128: \o/
[16:09] <sergiusens> lool: yes, stgraber already fixed
[16:09] <seb128> jdstrand, e.g we can handle the translations in the toolkit
[16:09] <sergiusens> lool: we are in perm loop of issues
[16:09] <sergiusens> :-)
[16:09] <seb128> cjwatson, ;-)
[16:09] <lool> erf
[16:09] <cjwatson> this is my face of utter joy at destroying translated fs names
[16:09]  * sergiusens notices no one reads the backlog
[16:09] <jdstrand> cjwatson: seriously, they are icky :)
[16:09] <lool> sergiusens: too much traffic today
[16:09] <lool> I can't keep up
[16:09] <asac> sergiusens: hehe...thats normal
[16:09] <lool> so /var/lib/ofono is uploaded
[16:10] <asac> i am also lost... do we upload fixes for /var/lib right now? or are we investigating?
[16:10] <asac> lool: rock
[16:10] <asac> :)
[16:10] <sergiusens> asac: yeah, but the ofono issue was mentioned 15 times perhaps
[16:10] <asac> thats good news
[16:10] <lool> asac: two were uploaded
[16:10] <jdstrand> lool: re traffic> I know the feeling :)
[16:10] <ogra_> lool, right, next issue is that taking a pic crashes the shell :)
[16:10] <lool> sergiusens: see asac doesn't read the backlog either  :-)
[16:10] <ogra_> lool, on readonly images
[16:10] <lool> jdstrand: BTW pingpingping!
[16:10] <lool> ;-)
[16:10] <lool> ogra_: and that's not expected behavior?
[16:10] <jdstrand> lool: pongpongpong!
[16:10] <ogra_> lool, LOL
[16:11] <asac> lool: ok, then lets continue and get another round going :)
[16:11] <asac> sil2100: can we talk the list of candidaets through?
[16:11] <lool> ogra_: I can confirm this shell thing!
[16:11] <lool> ogra_: do we know what's causing it?
[16:11] <ogra_> not yet
[16:11] <cwayne_> stgraber, what version of ubuntu-touch-generic-initrd should i have?
[16:11] <lool> the good news is that it eventually restarts
[16:11] <ogra_> but remounting / rw fixes it
[16:11] <lool> oh _usr_bin_camera-app.32011.crash
[16:11] <ogra_> lovely
[16:12] <sil2100> asac: more or less, I'm trying to resolve some stack build/release problems right now as well
[16:12] <asac> sil2100: ok so you prep that stuff would be ready
[16:12] <kdub> who got surfaceflinger running in the flipped images? (have some questions)
[16:12] <asac> sil2100: wewould like to push the main pieces soon
[16:13] <stgraber> cwayne_: 0.47 I think
[16:13] <rsalveti> kdub: what is the issue?
[16:13] <sil2100> asac: cool - from the components that are ready, we have this to release for sure: mediascanner, mir, unity-system-compositor, autopilot, u1db-qt, unity-mir
[16:13] <sergiusens> lool: rsalveti ogra_ if you remount it once rw, it is enought for it to work always :-/
[16:13] <sil2100> asac: hud and indicators are red, so no releases there
[16:13] <kdub> rsalveti, just if i stop surfaceflinger, then try to run /system/bin/surfaceflinger in the android-chroot, the executable segfaults
[16:13] <ogra_> yippie ... heisenbug
[16:13] <cwayne_> stgraber, hmm, that's what i have
[16:14] <lool> sergiusens: ah!
[16:14] <asac> sil2100: so i think mir and unity-* wait for ricmm
[16:14] <rsalveti> kdub: you need to be inside the android container to start it up again
[16:14] <asac> sil2100: so we have mediascanner and autopilot and u1db
[16:14] <rsalveti> kdub: which means you'd need to get inside the android container via it's own adb
[16:14] <asac> sil2100: hope those are safe, but owuld like to know whats in autopilot
[16:14] <cwayne_> is there any debugging i can do to get you useful information?  i see the copying custom content in dmesg, but .local is still owned by system
[16:14] <sil2100> asac: autopilot is safe to release, it has a neat fix only
[16:14] <cwayne_> ssweeny, our tarball is all owned by root now, right?
[16:14] <asac> sil2100: ok then lets do those now
[16:14] <rsalveti> kdub: android-chroot doesn't set the right pid namespace
[16:14] <ogra_> rsalveti, android-chroot should work for starting it manually
[16:14] <davmor2> popey: ha goto calendar goto any date click on create new event it's created in today rather than the day you are on :D
[16:14] <sil2100> asac: veebers added a functionality to detect infinite mouse-movement loops
[16:15] <rsalveti> ogra_: not necessarily
[16:15] <asac> sil2100: so we could pick them up in next image
[16:15] <kdub> rsalveti, i figured something about my lxc knowledge was lacking :)
[16:15] <asac> (think 1h from now)
[16:15] <jdstrand> gusch_: based on seb128's comment, it sounds like ~/Pictures will not be translated at the fs level, so you should be able to depend on it not changing based on translation. I can't speak for QtStandardPaths though (I don't know the Qt API enough to know if it will do the translating for you)
[16:15] <ogra_> rsalveti, it does for sensorservice
[16:15] <sil2100> asac: ok, I'll check one more thing in the meantime
[16:15] <jdstrand> gusch_: but wait until lool comments
[16:15] <ogra_> not sure if SF is any different
[16:15] <rsalveti> ogra_: that's why not necessarily, it depends on the service
[16:15] <rsalveti> if it needs the property system and such
[16:15] <stgraber> cwayne_: so it may be that my android rebuild didn't pick it up, which may explain what you're seeing
[16:15] <ogra_> yeah, understood
[16:15] <lool> jdstrand, gusch_: I'm all for NOT translating these
[16:16] <jdstrand> consensus! :)
[16:16] <asac> sil2100: ok let me know when copied and what was copied :)
[16:16] <lool> last time we discussed this, we didn't have a good plan for convergence, but I think we decided to keep going with untranslated filenames anyway
[16:16] <jdstrand> and so I an further delay landing the xdg user patch for apparmor :)
[16:16] <asac> rsalveti: anything you guys want to throw into the mix as well for the next RO run?>
[16:16] <asac> like a new libhyris? :)
[16:16] <ricmm> asac: sil2100 you can go ahead with release of everything that has had branches land, on my end
[16:16] <ricmm> that is unity-mir and qtubuntu
[16:16] <asac> otherwise we have the /var/lib fixes i think plus new apps
[16:16] <rsalveti> kdub: http://paste.ubuntu.com/6070990/
[16:16] <asac> ricmm: ok cool. so not MIR itself?
[16:17] <asac> that feels not used
[16:17] <ricmm> the changes there are not the Mir changes, just some other pre-reqs that are unused right now
[16:17] <jdstrand> seb128: would you mind following up on the list that this is what was decided if it isn't clear already?
[16:17] <asac> so feels safe as well ... but not sure
[16:17] <sergiusens> asac: I want to find ou`t what's wrong with the camera
[16:17] <rsalveti> asac: nothing from my side, I don't land stuff in friday
[16:17] <asac> rsalveti: ok
[16:17] <asac> you are smart :)
[16:17] <ricmm> it would certainly help to have them in the archive, for the following landings
[16:17]  * asac notes that we land thursday stuff though :)
[16:17] <asac> lol
[16:17] <ricmm> as it wont happen right now, it will just make it cleaner for the next proposals I guess
[16:17] <sil2100> ricmm: ah, so it's safe to release those without getting anything broken, yes?
[16:17] <rsalveti> thursday is fine, we have friday to fix
[16:17] <rsalveti> :P
[16:17] <popey> davmor2: http://bugs.launchpad.net/ubuntu-calendar-app ☻
[16:18] <stgraber> cwayne_: so the chown definitely is in there...
[16:18] <asac> ricmm: so double checking:                  mediascanner, mir, unity-system-compositor, autopilot, u1db-qt, unity-mir
[16:18] <asac> out of those we should pick: mir, unity-* ?
[16:18] <asac> ricmm: and we have very low likelyhood of sideeffects :)?
[16:18] <asac> nice
[16:18] <kdub> rsalveti, will give it a try
[16:18] <stgraber> cwayne_: what do you get if you do cat /etc/media-info?
[16:18] <rsalveti> kdub: that gets you in the android pid namespace properly, so you can execute whatever you want/need there
[16:18] <ricmm> asac: mir is irrelevant to me, their landing has nothing to do with our supporting effort
[16:18] <asac> ricmm: seems greyback disagrees
[16:18] <ricmm> asac: from my end, unity-mir and qtubuntu are good to go
[16:18] <ogra_> asac, i dont think mediascanner is used by anything yet, should be safe to pull in as well
[16:18] <cwayne_> stgraber, Ubuntu Saucy Salamander (development branch) - armhf (20130906)
[16:18] <ricmm> asac: uh?
[16:18] <asac> ricmm: ok... even with greybacks comment?
[16:19]  * rsalveti lunch
[16:19] <stgraber> cwayne_: hmm, that doesn't make any sense...
[16:19] <asac> ricmm: check -unity channel
[16:19] <ricmm> yes I did
[16:19] <davmor2> asac: so other than the camera and 3g and no messaging indicator changes and no...... it's a great image honest
[16:19] <cwayne_> stgraber, hm?
[16:19] <asac> davmor2: nice irony :)
[16:19] <ricmm> asac: unity-mir, qtubuntu should be safe, unity8 no
[16:19] <ricmm> asac: but if you want you can hold them all, the unity-mir qtubuntu stuff is unused anyways
[16:19] <stgraber> cwayne_: you're on the right version, I just inspected its content and the initrd is correct, so I'm really confused why it's not working
[16:19] <asac> ricmm: we dont see unity8 packages staged i think
[16:19] <ricmm> until the later branches come in play
[16:20] <asac> sil2100: so unity-mir, qtubuntu from ricmm side
[16:20] <asac> and the rest as discussed
[16:20] <cwayne_> stgraber, maybe our tarball is wrong, let me try something real quick
[16:20] <kdub> rsalveti, hmm, last command (to get the android pid namespace shell) get the 'device not found'
[16:20] <asac> sil2100: not mir itself
[16:20] <seb128> jdstrand, done
[16:20] <sil2100> ricmm: ok, well, I'll publish qtubuntu then - is it fine to release the qtubuntu bits without the unity-mir ones?
[16:20] <rsalveti> kdub: try killing adb from your host
[16:20] <stgraber> cwayne_: do you override the android tarball (mako-*.tar.xz) with something older?
[16:20] <davmor2> asac: the best is the 2 shots I took with the camera seem to be saved I'm going to pull them in a second and see if they actually were or not
[16:20] <cwayne_> stgraber, nope
[16:20] <ricmm> sil2100: yes
[16:20] <sil2100> ricmm: since sadly, I cannot easily release unity-mir without unity8, so I would hold those up until all is ready
[16:20] <arnoldkj> Hey, I've just flashed my nexus 7 to UT. I didn't have the bootloader unlocked when I first tried to run it and it soft-bricked it though. I got it back, just thought I'd report. (I know it was my own fault)
[16:21] <ricmm> sil2100: then just dont do qtubuntu either
[16:21] <kdub> rsalveti, same store
[16:21] <kdub> *story
[16:21] <ricmm> no point, they are both no-ops at the current moment
[16:21] <sil2100> asac: what about mir then? Since I got a bit confused... can I release mir as well? Mir as in Mir
[16:21] <ricmm> unused without unity8
[16:21] <ricmm> might as well hold to reduce the delta, in case other stuff breaks
[16:21] <ricmm> asac: agree?
[16:21] <rsalveti> kdub: hm, which image are you using? a recent one?
[16:21] <asac> yeah hold it
[16:21] <ricmm> sil2100: hold unity-mir, qtubuntu and mir then
[16:21] <asac> not sure about desktop testing impact and all that either
[16:22] <asac> ricmm: sorry, but better to call it a day then :)
[16:22] <ricmm> release the rest thats queued (:>
[16:22] <rsalveti> kdub: syslog should tell more if the device id did indeed change
[16:22] <kdub> rsalveti, yeah cdimage-touch from yesterday for manta
[16:22] <sil2100> ricmm, asac: ok ;)
[16:23] <sil2100> asac: I also see some click related things needing release, such as unity-scope-click and ubuntu-download-manager - I think those should be ok to release?
[16:24] <asac> davmor2: maybe you could confirm thjat the image gets better when applying the read/write fixes by lool
[16:24] <asac> ?
[16:24] <asac> that would give us some confidence :)
[16:24] <asac> sil2100: why not :)
[16:24] <asac> sil2100: download-manager? is that an application?
[16:24] <asac> not a service?
[16:24] <asac> hmm
[16:25] <asac> sil2100: those are in which stack?
[16:25] <sil2100> asac: those are in the 'click-package' stack
[16:25] <sil2100> asac: the description says: Ubuntu Download Manager - daemon
[16:25] <kdub> rsalveti, thanks for the help, i get what's going on now
[16:26] <lool> ogra_, sergiusens, asac, davmor2: Outside of ofono and accounts, were there other regressions confirmed to be specific to r/o?  camera-app might be, but not 100% sure, anything else?
[16:26] <rsalveti> kdub: one other way would be disabling the android-tools-adbd upstart job and setting the property via ssh
[16:26] <rsalveti> and see if it works better
[16:26] <rsalveti> kdub: cool
[16:26] <ogra_> lool, not that we know of
[16:26] <sil2100> asac: ah ha, I see Ken missed one more thing that's ready for release - the ubuntu-ui-toolkit ;) But I'm a bit worried to release that on Friday (even though all the tests passed)
[16:26] <rsalveti> will go for lunch, let me know if it still fails for you
[16:27] <ogra_> lool, (i bet we find ten more over the next week though,, but nothing obvious)
[16:27] <davmor2> lool: possibly the video playback on previous RW images it has been fine in RO it sucks
[16:27] <ogra_> davmor2, does it play fine for the first secs and then turn into a slideshow with sound ?
[16:28] <ogra_> if so, thats normal until we get the new gstreamer stack
[16:28] <davmor2> ogra_: no basically a slideshow from the start
[16:28] <asac> sil2100: yeah. my experience tells me ubuntu-ui-toolkit is more dangerous
[16:28] <lool> sergiusens: crash in gallery-app is from libusermetricsinput1
[16:28] <ogra_> davmor2, so it degraded a bit then ... well, i wouldnt count that a blocker
[16:28] <asac> pmcgowan: bzoltan: we have a ubuntu-ui-toolkit and felt we shouldnt push it in late on friday. agree?
[16:29] <asac> sil2100: what does the changelog say?
[16:30] <sil2100> asac: looks like an AP fix...
[16:30] <sil2100> asac: * Do not duplicate the pointer instantiation on the autopilot emulators. (LP: #1220346)
[16:30] <sil2100> Fairly safe I suppose
[16:31] <asac> sil2100: do you have the diff?
[16:31] <doanac> sergiusens: python-autopilot doesn't seem to have changed yet in touch images. Its still on1.3.1+13.10.20130830-0ubuntu1
[16:31] <asac> sil2100: the upstream code diff? i couldnt find that easily in our system... seems we strip that off
[16:31] <doanac> is there something i need to do to get the updated version included?
[16:31] <asac> only packagieng diff is there
[16:31] <sil2100> asac: yes, that's another thing on my 'would be nice to have' - https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/fix1220346-pointing_device/+merge/183719
[16:32] <sil2100> asac: it's AP changes only
[16:32] <lool> http://paste.ubuntu.com/6071055/
[16:33] <davmor2> asac, lool: click packages work, settings in apps are stored, notes are stored so the RO isn't effecting everything at least :)
[16:34] <lool> :-)
[16:34] <lool> sergiusens: http://paste.ubuntu.com/6071055/
[16:34] <asac> sil2100: feels too risky. its not clear if that is fixing any real autopilot bugs
[16:34] <asac> sil2100: so best it can do is break test
[16:34] <asac> sil2100: i think we should punch it in before going EOD
[16:36] <lool> sergiusens: Do you know how the usermetrics stuff works?
[16:36] <asac> after we have the next image
[16:36] <asac> sil2100: so leave it, lets kick image
[16:36] <asac> then start automation and if the image isnt good
[16:36] <asac> :)
[16:36] <asac> cry
[16:36] <davmor2> asac: how do I enable rw then?
[16:36] <cwayne_> stgraber, so i made sure that my tarball was all owned by root, and now .local/share is owned by root, so the chown still didn't work
[16:36] <asac> lool: tell davmor2 about the /var/lib fixes that we uploaded
[16:36] <asac> so he can validate that they help?
[16:36] <stgraber> cwayne_: what device are you testing on?
[16:36] <asac> thanks!
[16:37] <lool> davmor2: the accounts and ofono breakage should be fixed
[16:37] <cwayne_> stgraber, mako
[16:37] <lool> when the initramfs is rebuilt and the image is rebuilt
[16:37] <sil2100> asac: I published autopilot and mediascanner from the things that I could
[16:37] <sil2100> ;)
[16:37] <cwayne_> stgraber, so everything in the tarball should be owned by root, correct?
[16:37] <stgraber> cwayne_: yep
[16:37] <lool> asac: I had indirectly mentioned it, but confirmed again
[16:37] <stgraber> cwayne_: (I'm running a test here with a minimal custom image)
[16:38] <asac> davmor2: i think its apparmor rules you have to add
[16:38] <asac> sil2100: ok stuff in?
[16:38] <ogra_> lool, you forgot the android upload :)
[16:38] <stgraber> cwayne_: ok, reproduced the issue here, now to figure it out...
[16:38] <asac> sil2100: good, so once they are in relesae pocket
[16:39] <asac> lets continue
[16:39] <sil2100> asac: yes, waiting for them, checking for the status
[16:39] <cwayne_> whew, at least i'm not crazy :)
[16:39] <asac> sil2100: what about download-manager etc.?
[16:39] <asac> that not?
[16:39] <davmor2> lool: so you are pushing a new image with the fixes then?
[16:39] <lool> davmor2: eventually, will take some time still
[16:40] <ogra_> 3h i'd guess
[16:40] <asac> lool: which package are we waiting for ?
[16:40] <asac> ogra_: come on... 1h :)
[16:40] <asac> we are agile :-P
[16:40] <lool> asac: lxc-android-config to be published in saucy, then building android
[16:40] <ogra_> asac, its a chain of packages
[16:40] <asac> respinning is cheap :-P
[16:40] <asac> oha i dont think i want to know
[16:40] <asac> just dont run away :)
[16:41] <davmor2> asac: yes we are agile, that's why we can play dodgeball, computer systems on a fixed build time not so agile :D
[16:41] <ogra_> lool, does that stuff actually end up inside the initrd ? i thought it is read by the initrd from /
[16:42] <sergiusens> lool: not sure how usermetrics worked
[16:42] <Ikarus> ugh, I wish Ubuntu Touch on semi-supported devices had a nicer installer, instead of "download obscure here" "download other stuff there", etc
[16:42] <sergiusens> Ikarus: if porters supported it you could phablet-flash community
[16:43] <davmor2> asac: no data sources available I took two photos damn you phone :D
[16:43] <lool> sergiusens: it segfaults on startup at least
[16:43] <stgraber> cwayne_: [    3.709262] /init: line 5: chown: not found
[16:43] <lool> sergiusens: trying to su to usermetrics + running it => segv
[16:43] <lool> pete-woods: Hey!
[16:44] <lool> pete-woods: Could you help us debug usermetrics?
[16:44] <Ikarus> sergiusens: I know, but it's a shame people aren't driven to it :(
[16:44] <cwayne_> stgraber, huh, that seems not great
[16:44] <sil2100> asac: those as well
[16:44] <lool> pete-woods: it seems to segfault on startpu, at least with the readonly images
[16:44] <asac> sil2100: good
[16:44] <stgraber> cwayne_: yeah, I'm vaguely surprised we don't have chown in the initrd :)
[16:44] <stgraber> cwayne_: it's easily fixable though
[16:44] <ogra_> asac, so the ofono fix should be ready without an upload chain ...
[16:45] <ogra_> i just checked the code
[16:45] <sil2100> There's nothing better than a Friday image!
[16:45] <lool> sergiusens: Ok, found the gallery-app thing
[16:45] <cwayne_> stgraber, ah, easily fixable, my favorite type of bug :)
[16:45] <jdstrand> davmor2: re the conversation between you and asac> what is broken that needs rw?
[16:46] <awe> jdstrand, /var/lib/ofono for one
[16:46] <awe> fix has been uploaded
[16:46] <stgraber> cwayne_: well, for a definition of easily fixable that'll take half a day to land in an image
[16:46] <sergiusens> jdstrand: /var/lib/ofono and /var/lib/Accounts
[16:46] <asac> jdstrand: also something for mterry where the new intro saves its configs (also uploaded i think)
[16:46] <cwayne_> stgraber, right, but that's more waiting time than working time, right??
[16:47] <ogra_> that was /var/lib/Accounts
[16:47] <jdstrand> asac, davmor2: that isn't apparmor. that is ro fs. stgraber uploaded fixes to lxc-android-config for that
[16:47] <pete-woods> lool: it tries to write to /var/usermetrics
[16:47] <sergiusens> jdstrand: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/lxc-android-config/saucy/revision/89
[16:47] <asac> right
[16:47] <pete-woods> could that be it?
[16:47] <sergiusens> jdstrand: nope
[16:47] <jdstrand> sergiusens: oh?
[16:48] <sergiusens> jdstrand: no as in, it isn't apparmor
[16:48] <sergiusens> :-)
[16:48] <jdstrand> sergiusens: ah, yes
[16:48] <sergiusens> jdstrand: I would of pinged you if it was
[16:48] <jdstrand> hehe
[16:48] <sergiusens> ;-)
[16:48] <davmor2> jdstrand: No I think apparmour was mentioned as the way to get out of RO mode
[16:48] <stgraber> cwayne_: right, just two uploads
[16:48] <cwayne_> stgraber, awesome :)
[16:48] <jdstrand> sergiusens: ack, I saw someone mention apparmor might need to be updated, so thought I'd check on it
[16:48] <cwayne_> maybe i'll just take a break until later today then :P
[16:48] <jdstrand> sergiusens: thanks for handling that for me :)
[16:49] <plars> asac: results on 20130906 should all be there for except for smem and memevent, sdk needs to rerun on mako... it got that ssl error like I saw recently
[16:50] <pete-woods> lool: is there somewhere more correct (/var/lib/... ?) that it should keep its database?
[16:51] <stgraber> pete-woods: I just uploaded a fix for /var/lib/usermetrics, should hopefully be good in the next image
[16:51] <sergiusens> rsalveti: ogra_: lool asac camera error http://paste.ubuntu.com/6071136/
[16:51] <ogra_> plars, heh, why does mako run one test less
[16:51] <plars> ogra_: see above, it got an ssl error... network seemed ok but when it tried to connect to lp it failed with that ssl error
[16:52] <lool> pete-woods: https://bugs.launchpad.net/libusermetrics/+bug/1221839
[16:52] <plars> ogra_: so it missed the sdk test
[16:52] <lool> pete-woods: No, that dir is fine
[16:52] <ogra_> plars, ah
[16:52] <plars> ogra_: it's queued up
[16:52] <lool> pete-woods: This is like low priority, we'll fix the write issue
[16:52] <ogra_> yeah, i didnt make the connnection
[16:52] <lool> pete-woods: but would be good to fix the lib not to crash if service dies and service to report something useful (per bug)
[16:52] <plars> ogra_: the sdk test doesn't actually do much though, the chances of it failing for anything to be concerned about are pretty much zero
[16:53] <ogra_> yeah
[16:53] <lool> sergiusens: camera error is found
[16:53] <lool> sergiusens: i thnk
[16:53] <sergiusens> lool: oh, good, what was it exactly?
[16:53] <pete-woods> lool: okay, cool I will improve the error reporting :)
[16:53] <lool> sergiusens: this usermetrics bt I showed you because /var/lib/usermetrics wasn't in writable_paths  :-)
[16:54] <lool> pete-woods: thanks  :-)
[16:54] <ogra_> nice !
[16:54] <sergiusens> lool: might be the same as for camera?
[16:55] <ogra_> that is for camera
[16:55] <lool> sergiusens: it is the camera one
[16:55] <lool> sergiusens: didn't you see my bt?
[16:55] <lool> sergiusens: this is from the .crash file I mentioned
[16:55] <lool> sergiusens: 18:34 < lool> sergiusens: http://paste.ubuntu.com/6071055/
[16:55] <sergiusens> lool: ah, no, sorry
[16:55] <lool> sergiusens: this is with debug symbols, it's in usermetrics
[16:56] <lool> sergiusens: it doens't like when it's dbus service dies
[16:56] <pete-woods> sergiusens: I'm going to improve the libusermetrics client library so that it handles a missing daemon more gracefully
[16:58] <lool> pete-woods: <3
[16:58] <pete-woods> :)
[16:59] <lool> ♥ even
[17:00] <ogra_> you and your utf8
[17:00] <sergiusens> what is utf8?
[17:00] <sergiusens> :-)
[17:00] <ogra_> :)
[17:00] <lool> (can't believe the compose sequence for ♥ is actually < + 3)
[17:00] <ogra_> heh
[17:00] <pete-woods> the guys who "play with bits" for a living tend to do stuff like that :)
[17:01] <lool> there must be some unicode easter eggs
[17:01]  * lool tries compose + e a s t e r e g g
[17:01] <pete-woods> I always like how a simple mask operation is sufficient to uppercase / lowercase ASCII
[17:01] <stgraber> asac, lool, plars: daily-proposed re-generation is slowly going, I expect it to be done in the next 2 hours, at which point I suspect the QA tools will freak out as they'll see 4-5 new builds showing up at once.
[17:01] <pete-woods> no mapping required
[17:01] <stgraber> all of which should be canceled except for the latest one
[17:01] <stgraber> from that point on, things should behave normally again
[17:01] <lool> stgraber: sounds good  :-)
[17:02] <plars> stgraber: ok, any way to notify when it happens? what all will be in this one?
[17:03] <stgraber> plars: I'm watching nusakan as it imports everything, so I can probably give you a heads up minutes after it's published
[17:03] <stgraber> plars: basically every single build that's been published since the last stable one will show up as their own version in daily-proposed
[17:04] <stgraber> plars: so you'll see a bunch of old builds appearing which you probably don't want to test
[17:04] <plars> stgraber: will it be a whole lot of updates quickly? or will there be quite a bit of time between each?
[17:05] <plars> stgraber: if it all happens within 5 min. or so, shouldn't be any problem except I'll need to kill off the extras
[17:05] <ogra_> stgraber, note that i dropped the cronjob for touch, so we dont get any unexpected builds and dont step on our own toes wrt manual building
[17:06] <stgraber> plars: it'll be a single index.json change showing you 3-4 new images in one shot
[17:06] <plars> stgraber: oh, that should be no problem at all then
[17:06] <stgraber> ogra_: ok. I'll probably trigger a new image myself once the re-import is done so it can pick up the initrd and lxc-android-config changes.
[17:07] <plars> stgraber: jenkins is pretty dumb about it, it just sees that the file had some kind of change, and kicks of a new test. The test is just going to phablet-flash whatever is in daily-proposed
[17:07] <ogra_> dont forget the android rebuild for the initrd :)
[17:07] <plars> but I'll keep an eye on it just in case
[17:07] <stgraber> ogra_: yep, I know, it's in my post-lunch todo list :)
[17:07] <ogra_> i dropped the note from the initramfs package ... i should probably just have changed it
[17:08]  * ogra_ thinks automated rebuilding of package chains should be a topic for next UDS
[17:09] <lool> so I'm getting debian #713032 when rebuilding gallery-app but it built fine in the archive
[17:09] <lool> not sure why
[17:10] <lool> I'll just blame it on CMake
[17:10] <asac> stgraber: can we maybe do that migration on monday? i am a bit scared :)
[17:10] <asac> and you can also have fun :)?
[17:10] <asac> i thought you said wed :)
[17:10] <asac> not today :)
[17:10] <stgraber> asac: I'm just running what we said we'd earlier with lool
[17:11] <lool> asac: he said he would finish the new code to do things completely differently wed-thursday if he can focus on it, but then he went to implement the quick and dirty interim solution for today
[17:11] <asac> oha
[17:11] <stgraber> asac: I haven't even started working on the rewritten tool (too busy answering everyone's questions in here)
[17:11] <asac> well, if you can juggle it with plars thats great
[17:11] <asac> but always keep a path to back out
[17:11] <asac> :)
[17:11] <asac> we wanted to get an image out in 3h :)
[17:11] <asac> or so
[17:11] <asac> err in 1h or so
[17:15] <eolo999> hi again
[17:16] <eolo999> maybe someone has read my help request of yesterday night (europe)
[17:17] <lool> sergiusens davmor2 : BTW, locally fixing usermetrics + running it, I can run camera-app + take pictures + return to shell + see them in gallery-app + see the count on the lock screen
[17:18] <eolo999> anyway I am victim of this error while phablet-flashing my nexus 7:
[17:18] <eolo999> ERROR:phablet-flash:Command 'adb shell mount /sdcard/' returned non-zero exit status 255
[17:18] <cwayne_> ok here's a weird bug:
[17:18] <lool> eolo999: anything prior to that?
[17:18] <davmor2> lool: so it was user metrics causing everything to die then
[17:18] <lool> davmor2: yes
[17:18] <lool> davmor2: it will likely fix other apps too
[17:19] <cwayne_> in my custom pre-session.d/ script, i make a symlink to /usr/lib/arm-linux-gnueabihf/, but once it's run ont he phone, the symlink points to /usr/lib/x86_64-linux-gnu/
[17:19] <eolo999> that was using cdimage-touch; while using ubuntu-system the error is while mountin /data
[17:20] <eolo999> INFO:phablet-flash:Restarting device... wait
[17:20] <eolo999> INFO:phablet-flash:Restarting device... wait complete
[17:20] <eolo999> error: device not found
[17:20] <eolo999> ERROR:phablet-flash:Command 'adb shell mount /sdcard/' returned non-zero exit status 255
[17:20] <eolo999> sorry for pasting here
[17:20] <lool> eolo999: it doesn't seem to be able to find the device
[17:20] <lool> eolo999: do you care to preserve what's currently on the device?
[17:20] <popey> eolo999: does "adb devices" list it?
[17:20] <eolo999> It loses connection while restarting the devices
[17:21] <eolo999> it hangs with the open droid robot
[17:21] <eolo999> :)
[17:21] <lool> eolo999: do you see the ubuntu logo in the recovery?
[17:21] <eolo999> nope
[17:23] <eolo999> what do you mean by in the recovery
[17:23] <eolo999> ?
[17:23] <eolo999> popey: it list the device before flashing
[17:25] <cwayne_> lool, ping
[17:25] <eolo999> maybe I missed something but it seems that this kind of disconnect when restarting is affecting a lot of people
[17:27] <lool> cwayne_: pong
[17:27] <cwayne_> lool, hey, i was seing a really weird bug earlier in one of my custom pre-session.d/ scripts
[17:28] <cwayne_> lool, i was trying to symling /usr/lib/arm-linux-gnueabihf/qt5/qml/Ubuntu to /custom/usr/share/themes, but it was somehow uinstead setting the link to /usr/lib/x86_64-linux-gnu/
[17:28] <lool> eolo999: press volume up + volume down + power when booting, you'll get the fastboot menu; select recovery; if that doesn't show an Ubuntu logo, you want to rebootstrap, perhaps starting with android (simplest) or manually (no written instructions)
[17:28] <eolo999> ok
[17:29] <lool> cwayne_: how so?
[17:29] <cwayne_> lool, i have no idea.
[17:30] <lool> cwayne_: so were you doing this on an installed device?
[17:30] <lool> cwayne_: what image were you using and what command did you run?
[17:30] <lool> cwayne_: x86_64-linux-gnu is particularly suspicious  :-)
[17:31] <sergiusens> eolo999: adb kill-server; sudo adb start-server and start over
[17:31] <davmor2> lool yay /me goes off for tea
[17:31] <eolo999> sergiusens: I tried both with and without sudo
[17:31] <cwayne_> lool, on an installed device, and the command i ran was ln -s /usr/lib/arm-linux-gnueabihf/qt5/qml/Ubuntu /custom/usr/share/themes
[17:32] <lool> cwayne_: is your goal to create a symlink in /custom/usr/share/themes that points at /usr/lib/arm-linux-gnueabihf/qt5/qml/Ubuntu?
[17:32] <cwayne_> yep
[17:33] <lool> cwayne_: http://paste.ubuntu.com/6071323/
[17:33] <lool> WFM
[17:34] <cwayne_> lool, yeah i just did it again and now it worked
[17:34]  * cwayne_ is very confused, but at least it's working now :)
[17:40] <lool> cwayne_: :-)
[17:45] <sergiusens> rsalveti: ping
[18:18] <asac> lool: where do we stand :)?
[18:18] <asac> android alrewady building?
[18:18] <ogra_> https://launchpad.net/ubuntu/saucy/+source/android/20130905-0ubuntu3
[18:19] <ogra_> another 20min or so
[18:19] <ogra_> (plus proposed migration ... plus promotion)
[18:20] <asac> cool
[18:20] <rsalveti> sergiusens: pong
[18:20] <asac> ogra_: thx
[18:20] <asac> sil2100: all your stuff is all in release now?
[18:21] <davmor2> cwayne_: there is a difference between you being confused cause of the shiny shiny and it being confusing ;)
[18:21] <cwayne_> davmor2, :P
[18:23] <davmor2> cwayne_: I see you're not trying to deny it though :D
[18:23] <sergiusens> rsalveti: hey, where are we getting adbd from in recovery.img?
[18:23] <sergiusens> rsalveti: stock android build or is it being repacked?
[18:24] <jdstrand> mdeslaur, jjohansen, rsalveti, ogra_: fyi, 'Dealing with AppArmor policy for hardware-specific access to devices'. please comment if you object (a +1 would be nice too :)
[18:24] <rsalveti> sergiusens: sorry, not sure I follow, do you mean where in the code adbd is being copied as part of recovery?
[18:24] <sergiusens> rsalveti: I'm having the suspicion that adbd is compiled in host mode as logcat expect /dev/log (instead of /dev/alog) and wait-for-device doesn't work (the latter is what I want fixed)
[18:24] <jdstrand> mdeslaur, jjohansen, rsalveti, ogra_: sent to ubuntu-devel@
[18:24] <rsalveti> jdstrand: thanks
[18:25] <rsalveti> sergiusens: oh, right, let me check
[18:25] <sergiusens> rsalveti: if I fixed the latter I can get rid of the timeouts when rebooting
[18:25] <jdstrand> rsalveti: here is incentive for you. if I get a +1, then I'll assign it to myself :)
[18:25] <sergiusens> rsalveti: just run adb wait-for-device when the system is booted
[18:25] <jdstrand> rsalveti: is that bribery?
[18:25] <sergiusens> then adb reboot recovery
[18:25] <sergiusens> and run again
[18:26] <rsalveti> sergiusens: sure, I know wait-for-device works fine with our image, never tested with recovery
[18:26] <rsalveti> let me check
[18:26] <rsalveti> jdstrand: haha, sounds good
[18:26] <sergiusens> rsalveti: also try to run logcat... that will give you the ultimate hint
[18:26] <sergiusens> ogra_: do you know?
[18:26] <sil2100> asac: actually... not all, but it's ok
[18:27] <sil2100> asac: since autopilot didn't move out of -proposed since probably it's blocked, even though there's an FFe for the feature
[18:27] <sil2100> Laney: hi!
[18:27] <asac> ogra: can you check the autopilot in proposed?
[18:27] <asac> sil2100: i think it needs a beta freeze exception
[18:28] <sil2100> asac: I thought an accepted FFe was enough
[18:29] <ogra_> asac, autopilot-touch/powerpc unsatisfiable Depends: libautopilot-qt (>= 1.3)
[18:29] <ogra_> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[18:29] <asac> sil2100: can you check if autopilot-qt is ftbfs on power?
[18:30] <ogra_> asac, its a binary dep
[18:30] <ogra_> not a build dep
[18:31] <ogra_> proposed migration checks binaries :)
[18:32] <Laney> sil2100: you need to check update_excuses and update_output
[18:32] <Laney> there you will see that it is not blocked
[18:33] <rsalveti> sergiusens: logcat doesn't seem to be available in recovery
[18:33] <mdeslaur> jdstrand: thanks, sent reply
[18:33] <sergiusens> rsalveti: it is
[18:33] <rsalveti> even with adb shell
[18:33] <sergiusens> rsalveti: mount /system if it isn't mounted
[18:34] <rsalveti> oh, right
[18:34] <rsalveti> not by default :-)
[18:34] <sergiusens> rsalveti: /system/bin/logcat ... it will tell you it can't open /dev/alog/main, but if you ln -s /dev/alog /dev/log it will work
[18:35] <rsalveti> sergiusens: working fine here
[18:35] <rsalveti> sergiusens: are you sure you're using our recovery?
[18:35] <rsalveti> actually, you are
[18:35] <rsalveti> because logcat in your case is looking for /dev/alog
[18:35] <rsalveti> but I have /dev/alog/ by default
[18:35] <sergiusens> rsalveti: yes... I am... I have the ubuntu logo :-P
[18:36] <jdstrand> mdeslaur: I am both surprised and not surprised you liked. On the one hand, it was your idea, on the other hand, you hate ideas :P
[18:36] <sergiusens> rsalveti: might be a maguro thing...
[18:36] <rsalveti> let me check with maguro
[18:36] <jdstrand> mdeslaur: seriously though, thanks for working through that with me
[18:36]  * jdstrand hugs mdeslaur
[18:36] <rsalveti> but wait-for-device didn't work, so that's something to investigate
[18:36] <rsalveti> we might be missing something
[18:36] <rsalveti> would indeed be useful to have it there
[18:37] <sergiusens> rsalveti: not useful, necessary ;-)
[18:38] <sergiusens> rsalveti: hmmm... logcat worked for me now... (but I flashed the legacy image totry something)
[18:38] <mdeslaur> jdstrand: hehe, no it's always worth discussing...it happens to be the one I like best, but I'm always open to being convinced otherwise.
[18:38] <jdstrand> mdeslaur: I know you are :) I'm just kidding
[18:38] <rsalveti> sergiusens: what do you mean by legacy? ;-)
[18:38] <rsalveti> unflipped?
[18:39] <rsalveti> flipped?
[18:39] <rsalveti> sergiusens: /dev/alog is also available in maguro for me
[18:39] <jdstrand> mdeslaur: this issue has been keeping me up at nights. I will be glad to get it fixed
[18:41] <sergiusens> rsalveti: yeah, not sure what happened...
[18:42] <mdeslaur> jdstrand: yes, bundling it with the device-specific stuff instead of the main policy package is way better. You'll sleep well tonight :)
[18:42] <sergiusens> rsalveti: works for me now :-/
[18:42] <sergiusens> rsalveti: but failed once
[18:42] <mdeslaur> jdstrand: I guess it will also move it to the device-specific image?
[18:42] <rsalveti> sergiusens: well, but do you need logcat?
[18:42] <sergiusens> arg, I reset my config and now don't have eternal history
[18:43] <sergiusens> rsalveti: nope, I was just wanting to take a look
[18:43] <sergiusens> rsalveti: just in case some error was being logged for wait-for-device
[18:43] <rsalveti> right, let's just see what needs to be done to have a working wait-for-device
[18:43] <rsalveti> right
[18:43] <jdstrand> mdeslaur: I figure I would implement it in that manner like you suggested, yes
[18:45] <rsalveti> 1214        /* Allow a command to be run after wait-for-device,
[18:45] <rsalveti> 1215            * e.g. 'adb wait-for-device shell'.
[18:45] <mdeslaur> jdstrand: I haven't looked at the core/device image split at all (heck, if it's even implemented)...is it based on packages, or directories?
[18:45] <rsalveti> cool, didn't know about that
[18:45] <sergiusens> rsalveti: really? it's the best :-)
[18:45] <rsalveti> :-)
[18:45] <rsalveti> best documentation is the code
[18:45] <sergiusens> rsalveti: I discovered you can do wait-for-local wait-for-any as well
[18:45] <rsalveti> yeah, awesome
[18:54] <PLA_> To chime in with eolo999, I get "exit status 255" when running "phablet-flash ubuntu-system --no-backup". More info here: http://pastebin.ubuntu.com/6071558/
[18:57] <sergiusens> PLA_: can you adb reboot recover and then adb devices ?
[19:02] <PLA_> adb reboot recover and then adb devices works.
[19:04] <_5m0k3> PLA_: Did you try running phablet-flash ubuntu-system --no-backup a second time?  Mine worked the second go-around
[19:06] <PLA_> I've tried "phablet-flash ubuntu-system --no-backup" many times. Always ends the same: http://pastebin.ubuntu.com/6071558/
[19:07] <popey> PLA_: what device?
[19:07] <PLA_> Nexus 4
[19:08] <mhall119> wow! the Launcher lets you add icons now!
[19:08] <_5m0k3> tbh, I'm really not digging the new system images.  It just feels so... restricted
[19:09] <asac> ogra_: where are we?
[19:14] <mterry> mhall119, you've posted on G+ a few times about wallpapers.  Do you set it manually?  The system settings background panel doesn't seem to work for me
[19:14] <mterry> (in Touch)
[19:15] <AskUbuntu> Galaxy Nexus fails to boot after unsuccessful Ubuntu Touch installation | http://askubuntu.com/q/342298
[19:17] <mhall119> mterry: yeah, I manually call gsettings from the terminal-app
[19:18] <mhall119> will be much nicer when the background panel in system-settings can do it
[19:18] <mterry> mhall119, OK, cool.  Note that soonish, a branch I wrote to support a separate background on the greeter will look like a regression to you then (your greeter will revert to default background).  Let me get a command line for you to set that as you like, once that lands...
[19:19] <mterry> dbus-send --system --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User32011 org.freedesktop.Accounts.User.SetBackgroundFile string:/usr/share/backgrounds/background_3.png
[19:19] <mterry> mhall119, ^
[19:20] <mhall119> thanks mterry, I'll tuck that away somewhere safe :)
[19:22] <ogra_> asac, i have no idea whats up with autopilot ... whikle it complains about ppc it also says "Valid Candidate"
[19:23] <balloons> can anyone with a device handy confirm this bug? Bascially, rssreader doesn't seem to let you add a new feed on a phablet device. https://bugs.launchpad.net/ubuntu-rssreader-app/+bug/1221893
[19:24] <jdstrand> mdeslaur: I don't know. I figured I'd start with lxc-android-config and go from there
[19:24] <popey> balloons: lemme see
[19:25] <yulia> Good evening guys, would any of you please have a little time to help me about unlocking the simcard on a Nexus 4?
[19:25] <balloons> popey, ty :-)
[19:26] <sergiusens> balloons: works for me
[19:27] <balloons> sergiusens, did you add a new topic as part of the creation?
[19:27] <balloons> it locks up my manta and crashes
[19:27] <sergiusens> balloons: although adding is not intuitive
[19:27] <popey> balloons: it doesnt crash here
[19:27] <sergiusens> balloons: yeah, topic is N
[19:27] <popey> it freezes
[19:27] <balloons> sergiusens, what device? popey, what device?
[19:27] <popey> n4
[19:27] <sergiusens> balloons: I added omg ubuntu wordpress something on maguro
[19:27] <sergiusens> and ro images
[19:27] <popey> ro here too
[19:28] <balloons> ok so.. I'm still on the flipped, I haven't swapped yet.. it was on the agenda for today once this was fixed :-p
[19:28] <sergiusens> balloons: might be good to state if a specific topic/feed would crash and complete the bug with more info
[19:28] <popey> +1
[19:28] <balloons> well it sounds like it's crashing for popey also? the feed doesn't matter for me
[19:29] <sergiusens> balloons: how about topic length
[19:29] <sergiusens> ?
[19:30] <balloons> sergiusens, I too did a 1 char topic.. I mean I can mess with it a bit more
[19:30] <sergiusens> balloons: ok, I tried 'n' and 'something' as topics
[19:30] <balloons> just to confirm, popey you did experience a lock-up right? did the app continue or did it lock completely?
[19:31] <popey> yes, it froze for a bit
[19:31] <balloons> popey, but it continued? you got back to the main view and could see the feed?
[19:32] <balloons> just want to update the bug accordingly.. it might just be me, heh
[19:32] <ashvani> Hi
[19:35] <popey> balloons: came back to the main view, yes
[19:35] <popey> but the feed didn't update, dunno if it's a duff feed
[19:36] <balloons> popey, k, I'll note it and keep digging
[19:36] <ashvani> can anybody help me
[19:36] <ashvani> in installing ubantu on mobile
[19:39] <AskUbuntu> What is the diference between the images of Ubuntu Touch? | http://askubuntu.com/q/342303
[19:41] <stgraber> sergiusens: any idea as to what happened to robru (ubuntu-phone mailing list)?
[19:41] <asac> ogra_: we dont need that autopiolot do we?
[19:41] <asac> the rest is in
[19:41] <asac> kick off a build
[19:41] <stgraber> sergiusens: if I had to guess, I'd go with insufficient disk space or some kind of adb disconnect while transfering the image
[19:41] <sergiusens> stgraber: let me check list
[19:42] <asac> ogra_: care most about the android changes for /var/lib
[19:43] <sergiusens> stgraber: protocol failure ... plars is the only person I know that sees that consistently
[19:43] <sergiusens> stgraber: other reasons for a protocol failure are bad cable or micro disconnects
[19:43] <stgraber> robru: do you get that error consistently?
[19:44] <plars> we see it on occasion in the automated runs
[19:44] <asac> sergiusens: in case ogra is gone you might need to give us a new image kick :)
[19:45] <karni> Hi guys. I'd like to touch /userdata/.writable_image, but there's no userdata in my /
[19:45] <sergiusens> asac: sure, like now? I'm sorry I wasn't tracking the channel to know what we are missing
[19:45] <karni> Where should I look for it?
[19:45] <stgraber> robru: try re-running phablet-flash ubuntu-system from the recovery mode (probably with -d <device name> as it'll fail to auto-detect)
[19:45] <asac> sergiusens: i dont know either...  i believe ogra thought we need to wait for autopilot
[19:45] <asac> but the rest is in
[19:45] <asac> stgraber: which packge do we need to check to see if the /var/lib rw fixes are in archive?
[19:45] <sergiusens> asac: good; lool or stgraber did we get the metric stuff in persistent mode?
[19:46] <sergiusens> asac: android-lxc-config
[19:46] <stgraber> sergiusens: I've got a lxc-android-config change and an initrd (android) change that I want in the next build
[19:46] <stgraber> sergiusens: AFAIK both should be ready now, though nusakan is busy re-importing daily-proposed at the moment so don't expect anything to publish to touch_ro for at least another hour
[19:47] <stgraber> sergiusens: so I'd say, kick the build in ~30min, that way it should finish around the time daily-proposed is done regenerating
[19:47] <asac> stgraber: i am talking about what was uploaded
[19:47] <sergiusens> stgraber: well I need to kick cdimage first
[19:47] <asac> a fwe hours ago :)
[19:47] <sergiusens> asac: it's up   https://launchpad.net/ubuntu/saucy/+source/lxc-android-config/0.89
[19:47] <stgraber> asac: sure and as I said, that's lxc-android-config and android
[19:48] <asac> ok are both in the archive?
[19:48] <asac> then lets go
[19:48] <stgraber> sergiusens: yes, that's what I meant, wait 30min before kicking the build
[19:48] <sergiusens> asac: https://launchpad.net/ubuntu/saucy/+source/android/20130905-0ubuntu3
[19:48] <asac> otherwise we wont see anyting that might have 3g fixed
[19:48] <asac> today
[19:48] <sergiusens> stgraber: ok, will wait and continue with other things
[19:48] <asac> sergiusens: wait?
[19:48] <stgraber> sergiusens: if you kick it now, it'll just end up having to wait 30min not being published while nusakan finishes catching up on the daily-proposed import
[19:48] <sergiusens> asac: lets wait 30'
[19:48] <asac> is it really important what we wait for?
[19:48] <karni>  2) Use the experimental writable flag by doing touch
[19:48] <karni>     /userdata/.writable_image and rebooting your device.
[19:48] <karni> Can someone explain this to me ? :) ↑
[19:48] <asac> sergiusens: i would prefer if i could still find someone to test the build once its ffinished :)
[19:48] <asac> and its friday
[19:49] <asac> not sure if thats realisitic anyway :)
[19:49] <asac> but given how busted the touch_ro folks are... i am not sure
[19:49] <asac> sergiusens: ah ic
[19:49] <stgraber> asac: if we build it now it won't be published for at least another hour anyway since we need nusakan to finish catching up on the daily-proposed re-import first
[19:49] <sergiusens> asac: I can corroborate the regressions are gone once the build is done
[19:49] <asac> yeah i am bad at reading
[19:49] <asac> so no way
[19:49] <asac> ok
[19:49] <asac> i hope there will be no issues
[19:50] <stgraber> asac: so we could kick it now but all it'll achieve is making nusakan even slower and making my channel re-generating take even longer :)
[19:50] <asac> sergiusens: we need to punch it through utah still
[19:50] <asac> plars that is :)
[19:50] <asac> not sure how long he can be here at all
[19:50] <sergiusens> asac: plars is an hour behind me :-)
[19:50] <asac> stgraber: your and sergiusens call... the facts are above
[19:50] <asac> ok
[19:50] <asac> so thend o what needs to do
[19:50] <asac> but dont forget :)
[19:50] <asac> i am out for 1h
[19:50] <asac> cu
[19:51] <sergiusens> asac: we'll manage with stgraber, he can kick off cdimage too I think
[19:51]  * plars is just waiting on a new image :)
[19:52] <stgraber> yep, I definitely have shell access to nusakan (otherwise it'd be a nightmare to do my system-image or ubuntu-release work :))
[19:53] <stgraber> sergiusens: I still have 7 delta images to generate, I'll kick a build once I'm half way done, that should make the timing right
[19:54] <sergiusens> stgraber: ack
[19:55] <rah> I have a bunch of .img files in out/target/product/*/
[19:56] <rah> there, for example, ramdisk.img, ramdisk-recovery.img, recovery.img, system.img, userdata.img, boot.img
[19:56] <rah> which should be flashed to which nand partitions?
[19:57] <rsalveti> jdstrand: 3) -> +1
[19:58] <rsalveti> as long we have this documented in the porting guide I'm fine
[19:58] <jdstrand> \o/
[19:58] <jdstrand> yeah
[19:58] <rsalveti> can't reply to the ml yet as I didn't yet get the email
[19:58] <rsalveti> not sure what happens with ubuntu-devel
[19:58] <jdstrand> that's weird, I accidentally sent it twice :)
[19:58] <ogra_> stgraber, thanks
[19:58] <rsalveti> seems the only list that takes a few hours/days for me to get all the emails
[20:00]  * stgraber is really quite happy with the current system-image importer performance, diffing two 1.2GB images in ~5min including compression/decompression is pretty reasonable
[20:01] <rsalveti> cool
[20:04]  * eolo999 is reinstalling restoring android :(
[20:04] <lool> stgraber: I was just checking whether I would see pxz in top, and I did  :-)
[20:04] <lool> stgraber: good to see it's put to good use on the day after it gets added
[20:06] <eolo999> sergiusens: what does your comment on https://bugs.launchpad.net/phablet-tools/+bug/1215436 means? You catched the problem?
[20:07] <lool>    android | 20130905-0ubuntu3 | saucy/multiverse | source, all
[20:07] <lool> sergiusens: Should I kick a build?
[20:07] <sergiusens> eolo999: no, we are living with a workaround for a while
[20:07] <sergiusens> lool: stgraber was going to
[20:07] <lool> ah he needs to finish the import
[20:07] <stgraber> lool: yeah, today would be a nightmare if pxz wasn't installed :)
[20:08] <sergiusens> lool: yup
[20:08] <eolo999> sergiusens: that means I can give a second try?
[20:08] <sergiusens> eolo999: it doesn't mean anything
[20:08] <eolo999> ok
[20:09] <rah> ogra_: any idea which .img files go where in a device's NAND?
[20:09] <eolo999> can you describe the workaround in brief?
[20:09] <stgraber> lool: I think that'll officially be the longest import-cdimage run though, generating 115 full tarballs and 110 deltas :)
[20:10] <lool> wow
[20:10] <lool> stgraber: so you're reimporting everything?
[20:10] <stgraber> lool: yep, daily-proposed is technically a new channel without any relation to daily, so it's re-importing absolutely everything
[20:11] <lool> stgraber: hmm now that I thin of it, we could have named it something sensical
[20:11] <lool> like daily-all or something
[20:11] <lool> and kept it
[20:11] <lool> *think
[20:12] <stgraber> lool: 0.93 tarball/minute, that's pretty good!
[20:12] <stgraber> lool: well, once I'm done with my changes, daily-proposed will containg all images, each with a delta from the latest stable
[20:13] <stgraber> lool: (I also disabled garbage collection for now, so we won't be throwing anything away until I'm done with my changes)
[20:14] <stgraber> image generation is done, starting publishing now.
[20:16] <rah> am I on ignore or what?
[20:16] <stgraber> max version of daily-proposed will move from 5 (current) to 27 (after re-import)
[20:17] <stgraber> sergiusens: I just kicked a touch build now
[20:27] <stgraber> plars: new daily-proposed has been published, current tip is 27
[20:27] <plars> ack
[20:27] <lool> cool
[20:27] <lool> plars: another image coming soon though
[20:28] <plars> stgraber: this image is just renumbered though right? no difference from 20130906?
[20:28] <stgraber> plars: right, that's 20130906
[20:28] <stgraber> plars: .1 is coming in ~30min
[20:29] <cwayne_> stgraber, i dont suppose the chown fix is in?
[20:29] <stgraber> cwayne_: .1 should have the chown fix yeah
[20:29] <cwayne_> stgraber, awesome thanks
[20:40] <sergiusens> xnox: can you try apt-get install libnotify-dev:armhf in your chroot?
[20:42] <sergiusens> xnox: this is what I get http://paste.ubuntu.com/6072019/
[20:43] <xnox> sergiusens: do you by any chance have an "rc" removed, but not purged instance of libpython2.7-minimal:amd64 ?
[20:43] <xnox> sergiusens: what's the output of "$ dpkg -l | grep python2.7-minimal" ?
[20:43] <sergiusens> xnox: hm, I didn't purge, but I did apt-get remove the bzr install that is in your original readme that brought this in
[20:43] <xnox> and probably of a different version as well?
[20:44] <asac> sergiusens: any luck on getting an image slot :)?
[20:44] <sergiusens> asac: stgraber triggered
[20:44] <asac> sergiusens: how long?
[20:44] <ogra_> asac, stgraber cares
[20:44] <asac> ah i see backlog
[20:44] <ogra_> 20min i'd say
[20:44] <asac> pi mal daumen
[20:44] <xnox> sergiusens: right, yeah, than you have config files left-overs from the previous package. Imho it's a dpkg bug and / or Multiarch spec. As the "rc" conf files are left around and are considered of a different version and thus in dpkg view of things "conflicting"
[20:44] <asac> :)
[20:45] <ogra_> jau
[20:45] <sergiusens> xnox: thanks, let me check, but that means no bzr in the schroot, right?
[20:46] <stgraber> asac: the image should be on cdimage within 10min, it'll take a bit longer for system-image to process so ogra's 20min sounds reasonable
[20:46] <stgraber> (the builder is currently in post-build cleanup)
[20:47] <ogra_> do you pull from nusakan or cdimage ?
[20:47] <stgraber> ogra_: directly from /srv on nusakan
[20:47] <xnox> sergiusens: your alternative is to do: $ apt-get install libpython2.7-minimal:amd64 libpython2.7-minimal:armhf
[20:47] <ogra_> awesome, the syncing to cdimage costs a good 5min,
[20:47] <stgraber> ogra_: all the system-image code runs under the cdimage user directly on nusakan (/srv/system-image.ubuntu.com), so reading from a mirror would be a bit stupid :)
[20:48] <xnox> sergiusens: cause you want both arches installed, configured, and same checksum conf-files.
[20:48] <sergiusens> xnox: got it, thanks
[20:48] <ogra_> stgraber, oh, i thought it runs on the new server ... heh
[20:48] <xnox> sergiusens: and then you should be able to keep bzr.
[20:48] <stgraber> ogra_: nope, the server I have for system-image is just the web server nusakan pushes to, all the actual system-image generation is done by nusakan
[20:49] <sergiusens> xnox: well I don't necessarily want it though, but thanks :-)
[20:49] <ogra_> cool
[20:50] <xnox> sergiusens: =) i'm guessing you weren't going to edit python internal config files either..... ;-)
[20:51] <asac> stgraber: yeah. i assume now that we do touch_ro, we cant flip order because system needs the other as input?
[20:51] <asac> stgraber: was the RT ticket closed?
[20:51] <asac> i think so
[20:51] <asac> something about performance that was
[20:52] <stgraber> yeah, IS finally backported pxz to precise, that's how I managed to re-import everything that quickly, otherwise it'd have taken over a day
[20:55] <asac> plars: guess slowly start prepping the lab :)
[20:55] <sergiusens> xnox: well fwiw I can't install python-minimal:amd64 and python-minimal:armhf
[20:56] <plars> asac: unless you want me to go ahead and roll out the branch we discussed earlier, I don't think there's anything I can do to prep for it right now... I was going to wait until tonight or tomorrow at the earliest to roll that out though
[20:56] <plars> asac: my plan was to wait until the testing on this image was done
[20:57] <stgraber> barry: hey, looks like system-image got confused, I'm updating my device on the daily-proposed channel, from version 4 to version 27 and for some reason it decided that the right path was 4 => 9 (looked like deltas) then 9 => 27 (full)
[20:57] <stgraber> barry: anyway, that wasn't supposed to work to begin with (since 4 is == 27) but still surprised that system-image didn't just tell me to grab the latest full :)
[20:58] <barry> stgraber: what does `system-image-cli --dry-run` say?
[20:58] <rah> what are android-boot.img and android-ramdisk.img in the output directory?
[20:59] <barry> stgraber: # system-image-cli -n -c daily-proposed
[20:59] <barry> Upgrade path is 27
[20:59] <barry>
[20:59] <barry> # system-image-cli --info
[20:59] <barry>
[20:59] <barry> current build number: 4
[20:59] <barry> device name: grouper
[20:59] <barry> channel: daily
[20:59] <barry>
[20:59] <barry> stgraber: so from daily:4 -> daily-proposed:27 in one step
[21:00] <lool> 20130906.1 is up on cdimage
[21:01] <plars> stgraber: does the system-image update automatically once that happens? or do you have to kick something off? About how long after would that normally happen?
[21:02] <rah> xnox?
[21:02] <rah> asac?
[21:02] <rah> ogra_?
[21:02] <barry> plars: i think stgraber is doing it from the command line.  you have a lot more options from the cli
[21:06] <rah> :-/
[21:06] <plars> have to step away for just a bit, the tests will kick off automatically when the images show up and I'll be back shortly to monitor them
[21:07] <lool> plars: it's automatic
[21:07] <cwayne_> Kaleo, im still having some issues.. no matter what i set selected.fieldText to, the gallery app labels are always white
[21:09] <cwayne_> oops, nm
[21:10] <xnox> sergiusens: libpython2.7-minimal is multiarch and co-installable, But you can only have one python-minimal as it's normal executables and hence on one (host) arch only.
[21:11] <stgraber> looks like some were missing in the previous batch, system-image's consistency checker notice and is re-generating those now so publishing will take a bit longer than expected (probably another 10-15min)
[21:11] <stgraber> I'm quite happy that the check found those problems and solved them the right way, now I just need to figure out what happened to those files to begin with :)
[21:11] <xnox> stgraber: for grouper I get version 9 update and it's 404 =/
[21:12] <stgraber> xnox: what URL is 404 specifically?
[21:12] <xnox> rah: same what they are on android.....
[21:12] <xnox> stgraber: hm. I use the magical Updates UI which simply says ERROR 404 Retry ? button
[21:12] <xnox> (from ubuntu system settings app)
[21:13] <rah> xnox: I've never seen image files named "android-boot.img" on android, only files named "boot.img"
[21:13] <stgraber> xnox: ah, not useful then :) may be one of those files the consistency checker just noticed and fixed
[21:13] <cwayne_> Wellark, ping
[21:13] <stgraber> plars: build 28 published
[21:13] <xnox> stgraber: yeah, it's install & restart now =)
[21:13] <rah> xnox: I have "android-boot.img" and "boot.img"
[21:13] <stgraber> cwayne_: try now
[21:13] <rah> xnox: I'm asking what "android-boot.img" is
[21:14] <rah> xnox: are you maintaining that there is an "android-boot.img" file on android?
[21:14] <sergiusens> rah: it's the original android  boot.img
[21:15] <rah> sergiusens: what do you mean by "original"?
[21:15] <sergiusens> rah: it's the android boot img... we use an ubuntu one on ubuntu
[21:15] <rah> sergiusens: original implies some transition from a past state to the present state
[21:15] <rah> sergiusens: what was the past state?
[21:16] <rah> sergiusens: what was the transition?
[21:17] <rah> what's the difference between an "android" boot img and an "ubuntu" boot img?
[21:18] <sergiusens> rah: http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_build.git;a=blob;f=core/Makefile;h=76eb3b87a3a881a786362e624da0c0d7f96acc9f;hb=refs/heads/phablet-saucy#l372
[21:18] <cwayne_> stgraber, doing a clean flash right now
[21:19] <rah> sergiusens: this doesn't tell me much
[21:21] <rah> this is like giving me the steps of a recipe when I asked "what's for dinner?"
[21:21] <rah> sergiusens: do you know what the difference is between the android-boot.img and boot.img files?
[21:21] <sergiusens> rah: I explained in layman terms and as verbose as can be... I call it a fail for me to explain and I'll leave it to someone else
[21:22] <sergiusens> rah: I already told you, one is the plain android boot image and the other is the ubuntu one
[21:23] <rah> that's a difference in the words you're using to describe them
[21:23] <rah> it tell me nothing
[21:23] <rah> one is "android", one is "ubuntu"
[21:23] <rah> right
[21:23] <rah> ok
[21:23] <rah> what does that mean?
[21:24] <rah> let's just leave it at fail
[21:24]  * rah -> gone
[21:26] <lool> images should be up
[21:26] <lool> I see 28 for grouper at least
[21:26] <lool> and mako
[21:31] <danielbeck> Hello! I'm the developer of the RSS Feed Reader "RamSamSam Reader" (Ubuntu App showdown). I wanted to ask for help: I want to know if the application adheres to the user interface guidelines and how I could improve the user interface.
[21:33] <xapel> I am trying to get Ubuntu touch flashed to an Asus Transformer 101 tablet. Not having much success at the moment. Can anyone help me please?
[21:38] <popey> xapel: has someone ported to the transformer?
[21:39] <cwayne_> mzanetti, ping
[21:39] <mzanetti> cwayne_: hi
[21:41] <robru> stgraber, I get "error: device not found", which is unsurprising since it won't turn on.
[21:41] <cwayne_> mzanetti, hey, so unity seems to automatically add icons to the launcher after its launched, even if its already on the launcher
[21:41] <xapel> popey: yes, I believe so. http://forum.xda-developers.com/showthread.php?t=2168473
[21:42] <Tom__> Hi there, I have just installed Ubuntu Touch on a supposedly new Galaxy Nexus, but there seems to be an issse
[21:42] <robru> stgraber, the error I quoted on the ml was from the first flash attempt, which caused the bricking. the tablet at the time displayed the recovery menu, but then it turned off and i can't get it back
[21:42] <asac> plars: thx
[21:42] <robru> stgraber, but note that I had previous flashes flipped images with great success, and many times. it's this system-image flash that hasn't worked for me
[21:42] <Tom__> ...issue with the screen and I was wondering whether it means the screen was used for a long time or something else..
[21:42] <mzanetti> cwayne_: yes. that's a bug that is fixed already, but we're having troubles with jenkins and can't release anything since 2 days
[21:42] <asac> plars: did the new image come out yet?
[21:43] <Tom__> When you set the entire screen to white, the entire surface becomes yellowish, except for the parts where the (previous) *black* Android bars were usually displayed (at the top and at the bottom of the screen). Black bars logically mean that the screen is almost unused in this area.
[21:43] <stgraber> robru: is that mako or grouper?
[21:43] <robru> stgraber, grouper
[21:44] <stgraber> robru: ok, get it to reboot, as soon as you see the google logo press both volume buttons at the same time
[21:44] <stgraber> robru: that should get you into fastboot, then using the volume buttons, select recovery mode and enter using the power button
[21:44] <robru> stgraber, oh, wait, now phablet-flash got it into recovery mode. no idea why... it just found the device this time
[21:45] <asac> which image version are we waiting for?
[21:45] <stgraber> robru: ok. When the device is in an odd state, phablet-flash might misdetect it, in such case, pass it an extra -d grouper to force it
[21:46] <asac> i guess 5:...6.1...
[21:46] <stgraber> asac: current is 28 (rootfs is 20130906.1). It's published and everything, so just waiting for QA to run
[21:46] <robru> stgraber, well, it seems to me that phablet-flash borked halfway through the flash, leaving the tablet in an unbootable state. i tried this quite a few times earlier today without any luck. i'm not sure what changed now but somehow the google bootloader screen (with the unlocked lock) just showed up and i ran phablet-flash and now it's flashing.
[21:46] <asac> plars: is it running?
[21:46] <robru> I don't want to say it's "working" because so far all I see is the recovery screen, but that is an improvement.
[21:47] <cwayne_> stgraber, seems to work :D
[21:47] <stgraber> robru: ok. If that still fails somehow, get it into recovery mode, run "adb shell rm /cache/recovery/*" to cleanup some space, then change your micro-USB cable and try again with -d grouper
[21:49] <robru> stgraber, oh, the recovery screen has an error on it. "E: Can't open /cache/something-or-other....' (it disappeared before i could read it)
[21:50] <sergiusens> robru: can open autodeploy.zip or ubuntu_commands, the former is not important for this, the latter is
[21:50] <stgraber> robru: that's normal
[21:50] <stgraber> sergiusens: well, even missing ubuntu_command is fine at that stage (copying files over)
[21:51] <sergiusens> stgraber: robru you can check what goes on from a recovery point of view by looking at /tmp/recovery.log
[21:52] <sergiusens> after it's done that's what ends up on /cache/recovery/log
[21:55] <sergiusens> xnox: what about this? dpkg: dependency problems prevent configuration of libglib2.0-dev:
[21:55] <sergiusens>  libglib2.0-dev depends on python (>= 2.7.1-0ubuntu2); however:
[21:55] <sergiusens>   Package python is not configured yet.
[21:56] <sergiusens> I know I'm just randomly shooting this stuff, but these don't look nice if the idea is to do cross building
[22:00] <lool> asac: v28
[22:00] <lool> asac: it's up, not sure whether it's in QA
[22:01]  * lool tries cross-building gallery-app
[22:02] <sergiusens> lool: just do apt-get install libnotify-dev:armhf in your build env
[22:03] <sergiusens> lool: this is the fun stuff I get ootb http://paste.ubuntu.com/6072304/
[22:03] <stgraber> wow, the dashboard could do with some improved sorting :)
[22:03] <stgraber> 28: is showing up somewhere in the middle of the page
[22:03] <lool> lol
[22:04] <lool> stgraber: didn't even think of that
[22:04] <stgraber> so far all tests are passing though
[22:04] <lool> ship it!
[22:04] <lool> sadly, asac will soon remind us that the last tests are usually the harder ones to pass
[22:05] <lool> sergiusens: will check it out, right now it churns through the bdeps
[22:06] <plars> asac: yep :)
[22:06] <sergiusens> lool: do the tests or the devices get tired of running? :-)
[22:07] <lool> sergiusens: it was painful to build on my laptop, so I figured it would be awful on the device  :-)
[22:07] <lool> that said, the phone has twice the cores of the laptop
[22:07] <lool> sergiusens: I do get the python stuff too
[22:08] <lool> sergiusens: is libnotify the reason of libgstreamer -> libglib failing?
[22:09] <sergiusens> lool: it's a builddep for the share-app
[22:09] <lool> grmpf, the only reason for python are the autopilot tests
[22:09] <asac> anyone able to confirm that 3g works now?
[22:09] <asac> :)
[22:09] <lool> /var/lib/dpkg/info/python2.7-minimal.postinst: 38: /var/lib/dpkg/info/python2.7-minimal.postinst: python2.7: not found
[22:10] <lool> /var/lib/dpkg/info/libglib2.0-0:armhf.postinst: 44: /var/lib/dpkg/info/libglib2.0-0:armhf.postinst: /usr/lib/arm-linux-gnueabihf/glib-2.0/glib-compile-schemas: not found
[22:10] <sergiusens> lool: yeah, I get the same
[22:10] <sergiusens> lool: but http://paste.ubuntu.com/6072327/
[22:10] <sergiusens> not sure why python is a dep for libglib2.0-dev
[22:11] <lool> sergiusens: /usr/bin/gdbus-codegen
[22:11] <lool> and /usr/bin/gtester-report too
[22:11] <sergiusens> lool: shouldn't that be split out into a -tools package?
[22:11] <lool> sergiusens: I guess
[22:11] <sergiusens> oh well
[22:11] <lool> it's usually painful at this scale
[22:12] <sergiusens> lool: long way to get this in the easy to xcompile state
[22:12] <lool> yes and no
[22:12] <lool> it's not that many issues given the size of the stack
[22:13] <cwayne_> sergiusens, ping
[22:16] <lool> sergiusens: your log seems to show the same two failing (python and glib)
[22:16] <lool> and we could fix both in glib
[22:17] <lool> I dont get why python2.7-minimal is allowed though
[22:17] <sergiusens> cwayne_: pong
[22:18] <lool> I was expecting foreign
[22:18] <asac> plars: do the results look good? cant see 'em on the dash yet
[22:19] <sergiusens> lool: xnox gave some explanations above wrt to python
[22:19] <slangasek> lool: well, nothing should actually depend on -minimal anyway, so it shouldn't matter :)
[22:19] <sergiusens> slangasek: what about this one? http://paste.ubuntu.com/6072327/
[22:19] <slangasek> lool: however, the obvious counterexample for M-A: foreign is python2.7 itself
[22:20] <slangasek> sergiusens: libglib2.0-dev doesn't (shouldn't) depend on python2.7-minimal
[22:20] <cwayne_> sergiusens, is there an easy way to wipe the user data and start fresh without doing a full phablet-flash?
[22:20] <lool> slangasek: libglib2.0-dev depends on python
[22:20] <sergiusens> slangasek: no, it depends on python
[22:20] <slangasek> it depends on python, which is M-A: allowed
[22:20] <slangasek> so it should probably depend on python:any ?
[22:20] <plars> asac: yes, so far
[22:20] <sergiusens> slangasek: well I get this http://paste.ubuntu.com/6072304/
[22:21] <slangasek> sergiusens: what's the native arch?
[22:21] <sergiusens> slangasek: amd64
[22:23] <asac> can you give 3g a shot?
[22:23] <slangasek> sergiusens: that output doesn't show why python2.7-minimal isn't configured, though
[22:23] <asac> plars: ?
[22:23] <sergiusens> slangasek: I can get the full output, one sec
[22:23] <plars> asac: 3g has never worked for me
[22:23] <plars> asac: last time I talked to awe about it, there were some known issues
[22:24] <plars> asac: I did try it again earlier today, and it seems to get a connection to the network, but the carrier redirects me to some sort of nonexistant page
[22:24] <sergiusens> slangasek: not full (my history got trimmed) http://paste.ubuntu.com/6072386/ but there's Setting up python2.7-minimal (2.7.5-5ubuntu1) ...
[22:24] <sergiusens> /var/lib/dpkg/info/python2.7-minimal.postinst: 38: /var/lib/dpkg/info/python2.7-minimal.postinst: python2.7: not found
[22:25] <awe> plars, never?
[22:25] <slangasek> sergiusens: confusing.  what's /usr/bin/python2.7?
[22:26] <plars> awe: never
[22:26] <sergiusens> slangasek: ah... ARM,
[22:26] <awe> plars, last time we discussed 3g was in reference to a device in the QA lab
[22:26] <slangasek> sergiusens: oh, well how did that happen? :)
[22:26] <awe> that had a SIM that hadn't been activated yet
[22:26] <sergiusens> slangasek: I have no idea
[22:26] <slangasek> sergiusens: ok :-)
[22:26] <sergiusens> slangasek: all I did was apt-get install libnotify-dev:armhf
[22:26] <awe> plars, I wasn't aware of any other issues you were having?
[22:26] <plars> awe: that was a completely different problem, the sim I have locally has been activated
[22:27] <slangasek> sergiusens: so nothing in that log shows /usr/bin/python2.7 being clobbered, but clearly it has been
[22:27] <plars> awe: this was the previous issues we discussed, where you said there are bugs where it takes a long time to connect to 3g (and sometimes doesn't) and other problems where you had to hand-modify files to get it to connect correctly.  You had me make some changes but it still didn't work
[22:27] <awe> plars, again this is the first I've heard of your issues.  Have you filed a bug and/or worked with anyone else on figuring out what's wrong?
[22:27] <plars> awe: you told me there were bugs for this at the time
[22:27] <awe> plars, there's been a longstanding NM problem
[22:28] <awe> the fix landed earlier this week
[22:28] <awe> I believe it landed Tue or Wed
[22:28] <plars> I can try again in just a bit... furthest I've ever got was just a bit ago (previous image today) and it seemed to want to redirect me to some sort of tmobile androidapi site, but it gives an error
[22:28] <lool> slangasek: full sbuild log http://paste.ubuntu.com/6072397/
[22:28] <plars> I haven't had a chance to mess with it since then though
[22:29] <lool> on amd64
[22:29] <awe> plars, there also was a breakage with the RO images today
[22:29] <slangasek> lool: right, that log shows it selecting python2.7:armhf, which is not what we want
[22:29] <awe> but a fix was uploaded
[22:29] <plars> right, should be in this image from what I understand
[22:29] <slangasek> so if that's pulled in by glib, the fix is to make libglib2.0-dev Depend on python:any
[22:30] <asac> plars: so i think the problem was that everything was broken now
[22:30] <asac> plars: like no carrier etc.
[22:30] <asac> so if it works the same as before it would not be  a regression
[22:31] <lool> slangasek: ack; I guess we have to iterate to try it out
[22:31] <sergiusens> slangasek: could be http://paste.ubuntu.com/6072405/
[22:31] <slangasek> sergiusens: yep, that's what I would expect to see, and should be fixed by a python:any dep
[22:32] <slangasek> haw, and the libglib2.0-dev dep is autogenerated from dh_python
[22:32] <slangasek> dh_python2
[22:32] <lool> yeah, due to tools
[22:34] <lool> sergiusens: do you know how to test video thumbnails with gallery app?
[22:34] <sergiusens> lool: the user way is to record a video with the camera app
[22:34] <lool> I get Error loading image metadata: /home/lool/Vidéos/xyz.ogg: The file contains data of an unknown image type
[22:34] <sergiusens> lool: the other way would be to drop a video in /Pictures
[22:34] <lool> Pictures!
[22:34] <lool> sergiusens: I meant on my desktop
[22:35] <sergiusens> lool: oh, never used it on desktop
[22:36] <slangasek> sadness, 'apt-get build-dep -a armhf glib2.0' doesn't work
[22:44] <lool>         if (file.suffix().compare("mp4", Qt::CaseInsensitive) == 0) {
[22:44] <lool> sergiusens: actually has to be named .mp4
[22:48] <asac> plars: dont see any dashboard results still
[22:48] <asac> plars: any idea?
[22:48] <plars> really?
[22:48] <plars> hmm
[22:48] <plars> let me look
[22:48] <asac> thx
[22:49] <lool> asac: scroll to middle
[22:50] <lool> maguro has 135 passed
[22:50] <lool> mako 144
[22:50] <plars> yeah, sorting is broken on the dashboard
[22:50] <plars> because of the version numbering
[22:50] <plars> josepht is working on a fix I think
[22:51] <plars> ok, just got it installed locally
[22:53] <plars> awe: I get the same thing I was describing that I got earlier: it redirects me to http://androidapi.t-mobile.com/apppack/mvno.html
[22:53] <lool> can't take videos on mako itself
[22:54] <plars> but in the browser, it gives a network error
[22:55] <awe> plars, can you pastebin the contents of /var/lib/ofono/<IMSI>/gprs?
[22:55] <awe> also the output of /usr/share/ofono/scripts/list-contexts?
[22:56] <awe> note <IMSI> is a directory name that's looks like a hash ( eg. 345189011... )
[22:56] <plars> awe: http://paste.ubuntu.com/6072499/
[22:56] <RobbyF> is it just me or do you have to set the time and date manually still?
[22:56] <lool> RobbyF: should be set by ntpdate when you connect to network
[22:57] <awe> plars, OK... so ofono was able to lookup your service provider correctly
[22:57] <plars> awe: dns seems to resolve ok, so *something* works
[22:57] <awe> lool, is TZ set-able yet?
[22:57] <RobbyF> I'm on a wifi only with gnexus' never updates
[22:58] <awe> plars, when you say... "it redirects me to  ______", what do you mean by "it"?
[22:58] <lool> awe: not sure
[22:58] <awe> I'm confused if it's not the browser
[22:58] <slangasek> debuild's handling of -e argument ordering is infuriating
[22:58] <plars> awe: when I open the browser app, and put in ubuntu.com, google.com, and every other thing I've tried so far, it instead tries to send me to the url above
[22:59] <lool> slangasek: like last one doesn't override more recent one?
[22:59] <asac> plars: oha ... hard to spot :)
[22:59] <asac> lool: :)
[22:59] <awe> plars, can you ping ubuntu.com from the command-line?
[22:59] <asac> so can someone plz confirm that the fatal 3g from before is gone :)?
[22:59] <slangasek> lool: like all -e options are ignored after some arbitrary point in the argument list which I haven't figured out
[22:59] <lool> slangasek: I /think/ I've seen something similar earlier today trying to override my -j2 macro with a -j0 that wasn't pickedup
[22:59] <asac> davmor2: ?
[22:59] <asac> :)
[22:59] <plars> awe: no, ping doesn't seem to work, but it gets the right ip address from dns
[22:59] <slangasek> lool: so if I do 'debuild -eCONFIG_SITE -uc -us -B -aarmhf', it works.  If I do 'debuild -uc -us -B -aarmhf -eCONFIG_SITE', it does not.
[23:00] <lool> slangasek: oh it stops considering it has any args for itself when it meets the first dpkg-bp flag
[23:00] <sergiusens> asac: I'm installing right now
[23:00] <slangasek> lool: yes, infuriating
[23:00] <sergiusens> asac: will update you as soon as it boots
[23:01] <awe> plars, can you pastebin the context of 'list-contexts'?
[23:01] <awe> I think I may know what's happening...
[23:02] <plars> awe: http://paste.ubuntu.com/6072520/
[23:03] <awe> thanks
[23:03] <awe> one last request...
[23:03] <awe> nmcli d
[23:03] <awe> and nmcli c
[23:03] <awe> and I lied
[23:03] <lool> slangasek: just checked mine, completely unrelated
[23:03] <lool> just a dpkg-bp bug it seems
[23:03] <sergiusens> awe: if you use my script you can just ask for the run of that command ;-)
[23:03] <awe> cause really there's one final request
[23:04] <lool> nothing, DEB_BUILD_OPTS is empty; -j2 sets parallel=2; -j2 -j0 sets "parallel="
[23:04] <lool> how weird
[23:04] <plars> awe: http://paste.ubuntu.com/6072526/
[23:04] <awe> please create a bug
[23:04] <plars> awe: sure, this is something new?
[23:04] <awe> yes
[23:04] <awe> the connection looks active from both ofono & NM's perspective
[23:04] <plars> awe: on the image itself? or do you think I should put it on ofono or NM?
[23:05] <awe> this could be the routing bug that popey reported
[23:05] <sergiusens> asac: /var/lib/ofono is indeed working now
[23:05] <awe> plars, just file a touch-preview-images bug
[23:05] <awe> and assign to me
[23:06] <sergiusens> asac: skip intro also working
[23:07] <sergiusens> asac: and preinstalled apps sort of working, they are there and launch but icons aren't showing up
[23:08] <awe> plars, 'netstat -rn' would be one final bit of information that would help.   It looks like the connection is active, but it also looks like you're not getting bounced to a
[23:09] <awe> plars, does the webpage you referenced above show up on the phone, or does it show a server error?
[23:09] <awe> if I try to load on my desktop, I get the latter
[23:09] <plars> awe: if it's a routing problem, I wouldn't expect it to get a response from dns
[23:09] <plars> awe: no, it returns a server error
[23:10] <awe> well, you're clearly getting redirected
[23:10] <awe> did you purchase the SIM directly from t-mobile, curious that it's redirecting you to a page about MVNO ( mobile virtual network operator )
[23:10] <awe> also have you tried the SIM in another phone and confirmed it works?
[23:11] <asac> sergiusens: thats mako?
[23:11] <sergiusens> asac: maguro
[23:11] <asac> sergiusens: can you get a connection at all?
[23:11] <asac> ok good
[23:12] <asac> so how about mako? anyone?
[23:12] <asac> plars: a few tests failed
[23:12] <asac> need retry
[23:12] <sergiusens> asac: I have to break ro to get to that point as my data isn't in the serviceproviders.xml yet so I would need to replace it... I'll replace, reboot and run my script
[23:13] <asac> hmm. ok
[23:13] <asac> maybe get your data in there :)
[23:13] <asac> lol
[23:13] <sergiusens> cjwatson: seems the icon path isn't being correctly set again
[23:13] <sergiusens> asac: I have!
[23:13] <sergiusens> asac: well I had my patch applied upstream
[23:13] <asac> ok so not back down yet
[23:13] <sergiusens> asac: waiting for it to funnel in, cyphermox's plate
[23:13] <plars> asac: I'll restart them, give me a moment to finish writing this bug up
[23:15] <robru> stgraber, ugh, lost it again. power button is unresponsive, screen black
[23:15] <sergiusens> asac: in case you want to give it a go http://bazaar.launchpad.net/~sergiusens/+junk/network/view/head:/network_gprs_provision_test.sh
[23:15] <robru> stgraber, http://paste.ubuntu.com/6072562/ buh
[23:16] <sergiusens> asac: the pastebinit are the replacements needed to make it run on utah (monday sprint task I hope)
[23:17] <sergiusens> lool: what's the fastest way to go from .crash to backtrace?
[23:17] <sergiusens> asac: data works
[23:17] <slangasek> sergiusens: apport-unpack && gdb?
[23:17] <sergiusens> slangasek: thanks
[23:17] <plars> awe: https://bugs.launchpad.net/touch-preview-images/+bug/1221969
[23:19] <awe> plars, when you say it's a "straightalk" SIM on the t-mobile, sounds pretty  much like a MVNO to me
[23:19] <awe> ;)
[23:21] <lool> sergiusens: apport-retrace -g I think
[23:21] <lool> sergiusens: that's what I used earlier today
[23:21] <lool> sergiusens: it unpacks and launched gdb binary /tmp/core
[23:21] <lool> sergiusens: I didn't find how to install the dbgsym automatically yet; I think I found this in the past
[23:21] <awe> plars, can you also grep for the for "GPRS" in /var/log/syslog and add to the bug?
[23:22] <awe> plars, do have a phone running stock Android?
[23:22] <awe> I'm curious as to whether this SIM works on Android
[23:24] <asac> sergiusens: so what you did was change the file, go back to RO and then reboot?
[23:25] <awe> plars, also can you please verify that the account has "data" minutes allocated?
[23:25] <sergiusens> asac: yes
[23:25] <asac> so now we need mako too i guess
[23:25] <sergiusens> asac: me no have mako
[23:25] <asac> sergiusens: you think thats a valid test :)?
[23:25] <sergiusens> asac: yes it is
[23:25] <plars> awe: it's supposed to be unlimited talk/message/data
[23:25] <asac> rsalveti: want to try a mako before running out? :)
[23:26] <asac> popey: guess also already in weekend fun? :)
[23:26] <awe> understood, but could you please verify from their website?  You're getting redirected to a webpage, which to me indicates that it's possibly an account setup problem.   plars, as mentioned the other thing I'd like to know is whether it works in a stock Android phone
[23:27] <awe> AFAIK, this is the first time I've heard of someone using a MVNO SIM
[23:27] <awe> so it also could be related to that
[23:28] <plars> awe: I could flash it to android and try from there, but I don't know anything about the account. For that I'd probably have to wait and talk to Larry on Monday
[23:28] <awe> plars, everything else looks correct ( ofono's APN, NM's state, routing table, ... )
[23:28] <awe> plars, so yes... let's check with Larry on Monday.
[23:28] <lool> gn everyone
[23:29] <lool> I'm sure this build will eventually pass all tests
[23:29] <awe> when I asked awhile ago about getting instructions from Larry on how to get a card that was in a weird state, I never heard back.  Perhaps you, I, and Larry could do a hangout on Monday?
[23:29] <awe> plars, ^^
[23:30] <plars> awe: I responded to you right away to that on irc, and on the bug, I assumed you had the card?
[23:30] <plars> awe: rick has one for you
[23:30] <plars> awe: I told him to make sure not to activate it
[23:31] <awe> ah, plars maybe I didn't see the bug update
[23:32] <awe> plars, is it fair to say though that all cards involved have been "straightalk" cards?
[23:32] <plars> awe: yeah, np. Rick had one that hadn't been used (or activated) yet, should be able to get it from him
[23:32] <awe> Rick ?
[23:32] <plars> awe: most likely, yes
[23:32] <plars> awe: rfowler
[23:33] <awe> ok, we can discuss Mon
[23:33] <awe> or I can order
[23:33] <awe> by the way...
[23:34] <awe> from straightalk's site
[23:34] <plars> asac: test_capture.TestCapture.test_shoot_button_disable seemed to fail on both mako and maguro
[23:36] <asac> plars: thats camera?
[23:36] <plars> asac: yes
[23:36] <asac> that wasnt failing in previous build?
[23:36] <awe> plars, from the straigttalk website ( I clicked on Shop|SIM Cards ): "In order for your phone's INTERNET... to work, you will need to update your phone's APN ( ... ) settings by following a few simple steps.  These settings can be found on our website at apn.straighttalksim.com."
[23:36] <awe> plars, did you manually edit the APN settings per these instructions?
[23:37] <plars> awe: hmm, no first I've heard of that... I'll take a look
[23:37]  * awe notes that our System Settings UI is missing the ability to edit the APN
[23:37] <asac> plars: we retried those in the past, no?
[23:38] <plars> asac: this didn't fail previously
[23:38] <plars> awe: is there a way to do it from the command line?
[23:39] <awe> you need to stop NM and ofono
[23:39] <awe> and then edit the ofono gprs settings file
[23:39] <awe> ( /var/lib/ofono/<IMSI>/gprs )
[23:39] <awe> depending on what the parameter changes are
[23:39] <awe> ( I'm looking now )
[23:41] <awe> seems I can't get the required changes without a SIM.  Can you please paste the info for your SIM from apn.straighttalk.com into the bug?
[23:42] <sergiusens> asac: camera fix didn't make it in it seems
[23:43] <sergiusens> lool: ^^
[23:44] <sergiusens> lool: /var/lib/usermetrics is there, but might not be enough
[23:44] <asac> sergiusens: thats not a regression to previous RO then?
[23:44] <asac> plars: i think camera is crashy
[23:44] <sergiusens> asac: nope, just a fix that didn't get fixed
[23:44] <sergiusens> so a non fix
[23:44] <sergiusens> asac: I need to go, will bbl
[23:44] <asac> stgraber: so which build was build 5?
[23:44] <asac> err
[23:44] <asac> build 4
[23:45] <asac> plars: i really think its crashy
[23:45] <asac> and i have seen camera crashes before
[23:45] <asac> retry plz and record
[23:45] <johnjohn101> what part of october will i be able to have an ubuntu phone?
[23:45] <plars> asac: yeah, there was a .crash file for it
[23:48] <plars> awe: updated
[23:48] <awe> thanks!
[23:49] <awe> so this really isn't a bug
[23:49] <slangasek> sergiusens: can confirm that fixing the libglib2.0-dev dep on python is sufficient to make libnotify-dev cross-installable.  Now to get dh_python2 fixed upstream...
[23:49] <awe> that said, you need to confirm that the given settings work
[23:51] <asac> plars: so retried?
[23:51] <asac> plars: i think there were often crashes
[23:51] <asac> who knows whats going on wiht this
[23:51] <asac> i dont see anything changing
[23:51] <plars> asac: yeah, it's in the queue
[23:52] <asac> plars: can you at least boot test and check that everything else works?
[23:52] <asac> on mako?
[23:52] <asac> we need someone saying that it works at all i guess in case the tests are good
[23:52] <plars> asac: I've boot tested it, been working through the 3g stuff with awe
[23:52] <asac> ah cool
[23:52] <asac> well. get a proven SIM - if any :)
[23:52] <asac> hehe
[23:53] <asac> ubuntu certified
[23:53] <awe> asac, mvno
[23:53] <awe> ;)
[23:53] <asac> reads cryptic to me
[23:54] <awe> mobile virtual network operator
[23:54] <awe> means the auto-provisioning of the parameters necessary to activate a data call will always fail
[23:54] <awe> and thus the user needs to hand configure their phone settings
[23:54] <plars> asac: the click packages that are installed don't seem to work, nor do they have an icon
[23:54] <awe> which we unfortunately have no settings UI for...
[23:55] <plars> asac: wait, they might work, just don't have icon
[23:56] <asac> plars: i only want to hear about regressions over "daily" :)
[23:56] <asac> daily has click completely not working well afaik :)
[23:57] <athairus> hello everyone, I'm new and have just installed the latest build on my verizon galaxy nexus (toro)
[23:57] <athairus> I'd like to help by reporting bugs as I see them
[23:57] <athairus> the first one I've noticed was in the browser, the swipe gestures have a very noticable lag to them
[23:57] <athairus> what's the proper way to report this?
[23:58] <plars> asac: video playback still slow, but not a regression