=== chihchun_afk is now known as chihchun [08:22] depends on the partition :) [08:22] but I think ext4 is what you are asking for === marlinc_ is now known as marlinc [09:46] ChickenCutlass, Laney: I updated https://code.launchpad.net/~pitti/powerd/upower0.99/+merge/240141, works with both the old and new API now [09:47] sil2100: if I would want to land that via the train in vivid, can I tell it to build against -proposed? [09:47] pitti: every silo has -proposed enabled by default [09:47] sil2100: ah, good, thanks; the "PS Jenkins bot" runs don't, so I was wondering [09:48] marcustomlinson, pete-woods: any more comments on https://docs.google.com/a/canonical.com/document/d/1UohUeioi3iSBdFqmdYfGzkzFogkou_KW90YCi28DYkU/edit ? [09:48] pitti: to make sure we can do binary copies from the silos to the archive, we had to make sure we build with -proposed :) [09:48] *nod* [09:50] pitti: the PS Jenkins bot did build as well with proposed after I discussed with the CI team to enable it (as they should). This seems to have regressed, may worth a ping to them again [09:52] mardy: I'm still not sure I agree with having multiple APIs depending on whether used from an app, scope, etc [09:53] mardy: for it to be generic enough for scopes and apps, all that is missing is a callback mechanism really [09:53] marcustomlinson: well, we can talk about it, but the problem is that the API we discussed won't be very useful for apps [09:54] marcustomlinson: yes, which brings us to the main loop [09:54] mardy: what about it? [09:56] marcustomlinson: that we need to have a main loop, unless it's acceptable to have the callback invoked in another thread [09:58] mardy: Yes, I think calling back on a separate thread is acceptable. My opinion is to implement it the way I did with an internal abstracted main loop. So basically constructed with CreateInternalMainLoop [09:58] mardy: I would take my API as it is and remove the option to set UseExternalMainLoop [09:58] mardy: And let it be specified that the callback will occur on a separate thread [10:00] marcustomlinson: I think that your API is good for stateless interactions with OA (like for scopes), but not for generic apps [10:00] mardy: for an app I would set the callback, get the current statuses, then react to any status changes [10:01] marcustomlinson: your API always gets a new list of accounts, but it's not easy to know if those accounts are the same one returned the last time, or if they are new ones [10:01] mardy: ok sure, I like your API better for that [10:02] mardy: what I'm saying is a mix of the 2 [10:02] mardy: your api as it is, with the callback mechanism (including internal main loop) of mine [10:03] marcustomlinson: when you say "your API", do you mean the one I've sketched in the document, or the one from libaccounts? [10:03] mardy: the google doc one [10:03] marcustomlinson: I don't think that's a good one for apps :-/ [10:04] marcustomlinson: IMHO a good API for apps would give you the accounts as a list of objects, and then you set up notifications on those [10:04] mardy: like I said: just add the callback mechanism (including internal main loop) from mine and you have an API that serves both [10:05] marcustomlinson: IOW, the list should be returned only once, at startup, and then updated only when things change [10:05] mardy: yes [10:05] marcustomlinson: but that's a very different API from the one we sketched :-) [10:06] mardy: well not really. The app would set a callback, then call get_enabled_accounts() to get the initial statuses, then update those status (stored in the app somewhere) when things change [10:08] mardy: the callback could even be a void() [10:08] mardy: just to tell the app to call get_enabled_accounts() again [10:08] mardy: if we want it to be super simple [10:09] marcustomlinson: but then, the app needs to track the accounts somehow, to figure out which accounts have been added and removed [10:10] mardy: not if the app just calls get_enabled_accounts() every callback. [10:10] marcustomlinson: and an app needs asynchronous APIs for the authentication, in order not to block [10:11] mardy: basically, the purpose of this new API is supposed to support scopes and apps [10:11] mardy: otherwise we wouldn't be removing it from scopes [10:11] marcustomlinson: I mean, let's say that get_enabled_accounts() returns three structs; then you call it again, and it returns other three structs; how does the app know if they are the same accounts as before, or if maybe two accounts have been removed and two have been added in their place? [10:12] mardy: how does a scope know? [10:12] Good morning all; happy Friday and happy Magic Day! :-D [10:12] marcustomlinson: the nice thing about scopes, is that scopes don't need to know about it :-) That's why we could come up with this much simpler API [10:13] marcustomlinson: scopes just need to know what are the active accounts, they don't care about history [10:13] marcustomlinson: but an app might have data associated with an account [10:13] mardy: what I'm saying is, the app needs to assume that all account statuses are different and update internal state accordingly [10:13] mardy: if an app whats to monitor history then yes [10:14] mardy: the app must do the fancy stuff [10:15] marcustomlinson: right, but then those app developers who need to track accounts wouldn't like this API === chihchun is now known as chihchun_afk [10:16] marcustomlinson: I'm not against adding a callback to the API we drafted, I'm against recommending it for app developers [10:17] mardy: ok, just as long as its one API for apps and scopes [10:17] marcustomlinson: IMHo this is very oriented for background (UI-less) services [10:18] marcustomlinson: also, for apps we need to add an API to request access to an account, and to handle the authentication differently (now the API is synchronous and forbids UI interactions, and a generic app wouldn't like this) [10:18] mardy: sure, I don't have an objection to a second API that handles UI related operations [10:19] mardy: but I don't think the callback mechanism I'm describing belongs there [10:19] mardy: its not UI related, its still backend related [10:20] marcustomlinson: you are right, that we can add to our new UI-less API [10:20] marcustomlinson: I'm more concerned about the rest [10:20] mardy: is there anywhere any document that describes in more detail the api you're working on [10:20] mardy: sure, the rest (UI related stuff) can be a separate API [10:20] so that more people can have a look and provide feedback? [10:20] thostr_: this is the draft: https://docs.google.com/a/canonical.com/document/d/1UohUeioi3iSBdFqmdYfGzkzFogkou_KW90YCi28DYkU/edit [10:20] mardy: in the example of scopes, that API would be used by the shell [10:22] mardy: and if the shell wants statuses and callbacks on changes, it can use both [10:22] marcustomlinson: at the end, for generic apps I need to wrapp the whole QML API, and I wonder why -- wasn't it that APP developers should use QML or HTML5? [10:24] mardy: yes wrapping is another story. But we have to start somewhere, and that somewhere has been decided to be C++ [10:28] marcustomlinson: so, here's my proposal: I'll update the doc with the callback, and I'll also add a pragraph explaining what you can do with this API, and what you cannot do. Then let's wait a couple of days for feedback, and let's see [10:28] thostr_: how does that sound? ^ [10:28] *paragraph :-) [10:29] mardy: more explanation will definitly help there [10:30] mardy: also, since it will become the api for apps and scopes, please share this document with our architects, cwayne (representing scopes developers) but also guys from bills team (app development) [10:32] thostr_: OK [11:13] sil2100: "WARNING! CI Train is on halt!" -> is that just for RTM, or for vivid, too? [11:21] sil2100: I added the upower transition landings (vivid only) to the spreadsheet; if the CI train is down, I'll instead just merge/commit/dput manually === marcustomlinson is now known as marcustomlinson| === marcustomlinson| is now known as marcustomlinson === MacSlow is now known as MacSlow|lunch [12:26] abeato, is bug 1388044 only reproducable when APN is involved? [12:26] bug 1388044 in ubuntu-system-settings (Ubuntu) "APN editor does not keep its settings" [Undecided,New] https://launchpad.net/bugs/1388044 [12:30] abeato, seems I can reproduce it without entering/modifying any apn setting === _salem is now known as salem_ [12:37] pitti: ok, let me look [12:37] thanks [12:53] sergiusens: ping [12:56] jgdx, yes, you do not even need to edit the APN [12:57] abeato, right, can I remove that? [12:57] jgdx, indeed === MacSlow|lunch is now known as MacSlow [13:11] kenvandine, heyo! [13:11] hey [13:12] kenvandine, the u8 we needed landed in vivid and rtm [13:12] your branches are in a vivid silo :) [13:12] kenvandine, awesome [13:12] just flashing over to vivid to test [13:12] kenvandine, good morning too :) [13:12] mterry, you could help test if you have time :) [13:12] kenvandine, sure [13:12] mterry, good morning to you too :) [13:12] mterry, vivid silo 14 [13:13] mterry, i added your branches late last night and didn't update the spreadsheet with items to test [13:13] mterry, mind adding comments on what to test for your branches? [13:14] kenvandine, sure -- this is the ci train spreadsheet? [13:14] yeah [13:16] pitti: looks good -- thanks [13:16] ChickenCutlass: cheers; I'm trying to get a hold of sil2100 to answer my CI train question, then I'll land this one way or the other [13:17] kenvandine, done [13:17] mterry, thanks! [13:17] kenvandine, and flashing devel-proposed to test [13:20] Can anyone shed any light on R.stamp? My build is failing on trying to make it. There's a TODO in frameworks/base/Android.mk and a reference to magic! :/ === dandrader is now known as dandrader|afk [13:24] pitti: as per e-mail announcement it's only for ubuntu-rtm [13:27] seb128, the SliderMenu component uses the Slider from the sdk, but adds some locking to prevent the sort of value binding problem we are seeing in the brightness slider [13:28] kenvandine, why don't we fix the toolkit rather than adding fixed/workarounded widgets in some other components? [13:28] sil2100: ah, thanks; so ok if I assign a silo to these? or do you want to? [13:29] pitti: if there is a free silo then feel free to do that ;) [13:29] seb128, perhaps something like this should be added to the toolkit, but not sure how common a problem like this might be outside of dealing with things from the system [13:29] we're trying to share all these signals and settings across dbus, etc [13:30] most apps are just handling their own values [13:30] kenvandine, basically you are saying I should give up and just ack the use of custom widgets? ;-) [13:30] "custom" :) [13:30] it's what we use in the indicators :) [13:30] well, we basically say that the toolkit sucks and that instead of using it/fixing it we prefer to create a new lib and use that [13:30] it's still based on the sdk slider [13:30] that seems a bogus approch [13:30] it's worth suggesting to the sdk team, sure [13:30] i'll file a bug [13:30] thanks [13:31] but it looks like this is the reason why they created a modified slider for the indicators [13:31] right [13:31] sil2100: I haven't seen "Dest PPA:" yet, do I need to fill this out? [13:31] it doesn't mean it's the right thing to do [13:31] indeed :) [13:31] ideally our toolkit would support all our usecases [13:32] I'm fine using custom hacks as temporary workaround [13:32] pitti: how do you want to assign the silo? [13:32] but... i'd rather get this fixed than wait... since we can fix it by using an existing component [13:32] but we should aim at getting the toolkit improved as well [13:32] pitti: you just need to fill in a landing in the spreadsheet and assign through the menu :) [13:32] sil2100: I clicked on "Landing team tools" -> "assign silo" as usual [13:32] pitti: ah! Leave that blank [13:32] seb128, i'll file the bug and use the SliderMenu as an example [13:32] Just click click [13:32] seb128: right, and the popup box has a new "Dest PPA:" [13:32] sil2100: ack, thanks; sorry, but making sure I don't break anything [13:32] kenvandine, yeah, that's fine with me, as long as those things are flagged as temporary/until the sdk improves [13:33] kenvandine, thanks [13:33] pitti: this one is in case you want to release to a PPA instead of an archive [13:33] ah [13:34] seb128, kenvandine: I don’t understand that brightness slider merge proposal, sorry [13:35] seb128, kenvandine: However, as long as indicator-power and ubuntu-system-settings both have brightness sliders, I think they should share as much code as possible, to minimize the risk of bugs like bug 1376286 [13:36] bug 1376286 in ubuntu-system-settings (Ubuntu) "Slider minimum-volume icons differ in System Settings vs. Sound menu" [Low,Fix released] https://launchpad.net/bugs/1376286 [13:36] mpt, the icons are not part of the slider [13:37] mterry, ugh... [13:37] ubuntu-system-settings-wizard : Depends: unity8 (>= 8.01) but 8.00+15.04.20141030-0ubuntu1 is to be installed [13:37] kenvandine, ? my other unity8 branch bumped the version [13:37] and we have a upower issue too.. [13:37] Saviq, ^ right? [13:37] ubuntu-system-settings : Depends: libupower-glib3 (>= 0.99.0) but it is not installable [13:38] sil2100: meh, conflicts for both packages :/ [13:38] kenvandine, Saviq: it did. 8.01 is in vivid [13:38] maybe citrain didn't update ? [13:38] * kenvandine does it manually [13:39] ok, that cleared up the unity8 dep problem [13:39] but libupower-glib3 is still held in vivid-proposed [13:39] kenvandine, sweet [13:41] excuses says the autopkgtest passed [13:41] pitti, any idea why upower 0.99 is still held in proposed? [13:43] what the heck, "citrain device-upgrade 014" gave me landing-012 === dandrader|afk is now known as dandrader [13:47] kenvandine: yes :) powerd and system-settings MPs needs to land, but they are blocked by other silos that want to update those packages [13:47] the eternal serialization and long silo testing problem :/ [13:48] seb128, bug 1388094 [13:48] bug 1388094 in ubuntu-ui-toolkit (Ubuntu) "Slider component can have problems when binding value" [Undecided,New] https://launchpad.net/bugs/1388094 [13:49] kenvandine, thanks [13:50] seb128, also the thing about that brightness bug being krillin specific, it's really just that the latency is higher than mako for some reason [13:50] so the change notification for the value comes later [13:50] which updates the value in the slider and updates the backend... etc [13:50] in a loop :) [13:50] kenvandine, that makes sense [13:50] yup [13:50] weird that the latency is that much higher though [13:50] but... i don't want to know what happens under the covers there :) [13:51] kenvandine, can you put a comment in the code pointing to the bug you just opened on the toolkit? [13:51] seb128, sure [13:51] kenvandine, oh, and did you change the icons while you were at it? [13:51] kenvandine, thanks [13:53] seb128, no... what was it about the icons? [13:53] oh... [13:54] i see now :) [13:55] kenvandine, so what's the best way to workaround this upower thing? (just fixed my device from accidentally installing 012 silo) [13:55] seb128, actually... i don't know, what about the icons? [13:56] mterry: what's the "upower thing'? [13:56] the depends [13:56] settings in silo 14 can't be installed because of upower [13:56] ubuntu-system-settings : Depends: libupower-glib3 (>= 0.99.0) but it is not installable [13:56] the upower transition of course didn't land in RTM or utopic, just in vivid [13:56] yeah, vivid [13:56] it is in -proposed [13:57] pitti, ah ok, will enable [13:57] mterry, so i guess enable proposed [13:57] kenvandine, mterry: but NB that it is likely to break [13:57] https://code.launchpad.net/~laney/ubuntu-system-settings/upower0.99/+merge/230988 needs to be applied to actually work with upower 0.99 [13:57] the current trunk shouldn't even build against 0.99 [13:57] pitti, that's in the silop [13:57] silo [13:57] kenvandine: ah right, good [13:57] because it ftbfs :) [13:57] kenvandine: so that's the one I'm waiting on then :) [13:58] pitti, we're waiting on yours! :) [13:58] haha [13:58] well we better hurry and test this [13:58] I desperately need to get in laney's system-settings and my upower MP to finish the transition [13:58] it's a pile of branches [13:58] but I can't land and test them sepearately as they conflict with already existing silos [13:58] seb128, you see the mp for your titles tweak branch? [13:58] we silo'ed ourselves into total blockage :/ [13:59] kenvandine: FTBFS? [13:59] settings wouldn't build in the silo for vivid [13:59] without laney's patch [14:01] kenvandine: right, but I thought it's included in that landing? [14:01] jgdx, yes, sorry I just have too much to do with distro work to keep up with settings atm [14:01] pitti, it is, i added it after it ftbfs [14:01] it builds now [14:02] ah [14:02] kenvandine: ok, so landing this is appreciated indeed [14:02] kenvandine, icons, bug 1289465 [14:02] bug 1289465 in ubuntu-system-settings (Ubuntu) "Brightness icons are suboptimal" [Low,Confirmed] https://launchpad.net/bugs/1289465 [14:02] seb128, ah – sorry, let me know if there's anything I can do with that if you don't have the time. [14:03] jgdx, well, ken has been reviewing my changes, once those are accepted I guess one of us can get to review the ones you added on top of that [14:03] seb128, i see [14:03] that should change in the indicator too then [14:04] kenvandine, oh, they used the same as we did? [14:04] seems so, indeed [14:04] we used the same they did :) [14:04] no [14:05] I did the battery panel and there was no slider in indicators at the time [14:05] then the slider got moved [14:05] it was there, then removed, and added again :) [14:05] well, when I added the icons I didn't look to the indicator iirc [14:05] i did something with that and copied it from the indicator [14:06] i think we had more than one, and i consolidated them [14:06] anyway [14:06] i can change it, but we should add an indicator task too [14:07] k [14:07] so maybe not in the same landing [14:07] mterry, can you propose branches against the rtm branch as well? lp:ubuntu-system-settings/rtm-14.09 [14:07] instead of waiting for all this to land and merge then cherry pick [14:07] or maybe we can get them out of sync for a bit, fixing one and after the other one [14:07] yeah [14:07] i'll add it to my branch now [14:07] it makes sense, then we can lean on charles or someone :) [14:08] thanks [14:08] ok, I'm out for some exercice [14:08] back in one hour [14:09] ogra_: is there any possible way I can run things as root on my device? I want to do something automated. === alan_g is now known as alan_g|lunch [14:10] kenvandine, didn't I say I was going to do that yesterday? And never did? [14:10] popey, adb shell "echo 1234 | sudo -S ls" [14:10] mterry, yes [14:10] i was being nice :) [14:10] kenvandine, cool [14:11] ogra_: super [14:11] thanks [14:21] kenvandine, https://code.launchpad.net/~mterry/ubuntu-system-settings/shutdown-dialog-in-wizard-rtm/+merge/240272 and https://code.launchpad.net/~mterry/ubuntu-system-settings/passphrase-continue-rtm/+merge/240271 [14:22] kenvandine, though only the second is marked TOPBLOCKER [14:22] yeah, ok [14:22] thanks [14:23] * mterry goes back to testing silo 14 [14:28] kenvandine, wizard pieces of 14 seem ok, but that's just me verifying my own changes so maybe you should look at that too, and I'll look at the settings side of the silo [14:39] mterry, thanks, i tested the wizard bits too seem good [14:39] jgdx, it doesn't look like bug 1376763 is fixed [14:39] bug 1376763 in ubuntu-system-settings (Ubuntu) "Dialog doesn't take the contents size into consideration" [Undecided,In progress] https://launchpad.net/bugs/1376763 [14:39] the dialog still doesn't scroll [14:39] awe_, got a min? Seems you say in bug 1234491 that forcing manual registration mode is not possible by calling registeroperator on an operator. [14:39] bug 1234491 in ofono (Ubuntu) "Random ofono crash in network-registration" [Undecided,Fix released] https://launchpad.net/bugs/1234491 [14:40] kenvandine, I can't see what version of the sdk that landed in. [14:40] jgdx, switching to landscape doesn't make the dialog scroll :/ [14:40] me either [14:41] kalikiana, what version of the uitk did the dialog fix land in? [14:41] kenvandine, are you testing a silo? [14:41] jgdx, yeah, silo 14 for vivid [14:41] jgdx, let me take a look [14:41] kenvandine, thanks [14:41] awe_, thanks. If this is not possible, how can we then ever set registration mode to 'manual'? [14:42] jgdx, gimme a minute to switch contexts [14:42] hrmm, on latest image, i can't seem to double-tap on lock screen to change the infographic being shown [14:42] instead the launcher bounces out and it just shows the slide to unlock hint [14:43] awe_, sure thing [14:44] mterry, jgdx: ugh... uitk in vivid is 1.1.1279+14.10.20141007-0ubuntu1 [14:44] no way that includes the fix we need [14:44] * kenvandine removes that from the silo [14:44] :( [14:45] kenvandine, everything else I tested looked good (modulo cellular and bluetooth) [14:47] jgdx, what I said in the bug was that "manual operator selection mode" ( vs. automatic ) can only be used if the SIM has been programmed to allow it [14:48] jgdx, re: register being called on a particular operator, you need to be in "manual mode" first [14:48] if in auto-mode, you should't ever call register on a specific operator [14:49] kenvandine: 1.1.1298+14.10.20141016.1-0ubuntu1 [14:49] kalikiana, that isn't in vivid :( [14:49] awe_, am I reading this[1] wrong then perhaps? [1] https://github.com/rilmodem/ofono/blob/master/doc/network-api.txt [14:49] kalikiana, latest is 1.1.1279+14.10.20141007-0ubuntu1 [14:50] awe_, [Mode] property will change to "manual" if the Register()method of an operator is called. [14:50] kenvandine: well, vivid isn't on my phone either… chicken and egg :-) [14:50] kenvandine, what did you remove from the silo? [14:50] ah, jgdx... I missed that [14:50] jgdx, thx dialog resize branch from kalikiana [14:51] kenvandine: in other words, we actually need to start landing in vivid. we'll do that soon I think [14:51] that said, it's still gated on whether or not the SIM has been programmed to allow manual operator selection [14:51] awe_, basically, I want to change the mode to "manual" and looking at how to do that. I'm a bit puzzled :) [14:51] it isn't in utopic either... just rtm [14:51] per: https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1234491/comments/4 [14:51] kenvandine, oh [14:51] Ubuntu bug 1234491 in ofono (Ubuntu) "Random ofono crash in network-registration" [Undecided,Fix released] [14:51] kalikiana, we'll hold off on this until you guys get vivid updated [14:52] jgdx, hmmm....[readonly] [14:52] right [14:52] so you want to switch to manual "without selecting an operator" [14:53] awe_, preferably… [14:57] jgdx, don't think it's possible, and it actually makes sense. Normally users never touch this. If the SIM is programmed to allow this, then the act of selecting a different operator forces the phone into manual selection mode ( if allowed by the SIM ). Once this happens, there should be a control to allow the user to switch back to automatic [14:58] its a bit asymmetric, but should work... does this warrant some re-design work of the page? [14:58] awe_, that does make sense. Thank you. [14:59] it might require some re-design, yes. Now it seems you can set selection to Manual and that it should persist. [14:59] mpt, ^ could you have a look? [15:07] My phone doesn’t have a SIM in it right now, one moment [15:13] jgdx, maybe this SIM is locked to a particular carrier. I can’t tell. I don’t get the “Searching for carriers…” spinner I specced, at least. [15:14] mpt, I don't either – but that's because I think there is a bug in that UI. I have debs that fixes that. [15:14] mpt, if your sim was auto-only, that selector would have been disabled. [15:14] jgdx, ah, you mean “Automatically” would have been the only possible choice? [15:15] of course [15:15] mpt, reading the code, not quite. YOu would still see Manual but it's insensitive. [15:15] (not up to spec, but let's ignore that for now) [15:15] jgdx, right, that’s bug 1343291 [15:15] bug 1343291 in ubuntu-system-settings (Ubuntu) "UI should indicate when network registration mode is auto-only" [Medium,Triaged] https://launchpad.net/bugs/1343291 [15:16] mpt, yes [15:17] mpt, still, we cannot per awe's comments set the sim carrier selection to manual. It happens when you register with an operator. [15:18] jgdx, does that mean instead of “Automatic”/“Manual” we should have “Automatic”/“Operator 1”/“Operator 2”/“Operator 3”/…? [15:19] so that the only way to go Manual is to choose an operator directly [15:19] mpt, you would only see multiple operators as a result of a search. And search is expensive, i.e. it can kill cellular data (reading the docs right. awe_ ?). [15:19] mpt, yes [15:20] jgdx, there are two possible reasons you go into this screen: (a) to change the operator or (b) to change the APN. So the risk is that we will trigger an expensive search for operators when all you want to do is change the APN. [15:21] mpt, right, but only if the design calls for operators up front. [15:22] mpt, so "manual" is more like "Enter manual selection", which then becomes "Manual" when you have selected an operator. [15:22] jgdx, form follows function. If you can’t set “Manual” without choosing an operator simultaneously, I can think of three ways to do it: [15:23] (1) Have a “Search for Operators…” button (eww) [15:23] (2) accept the cost that the phone will automatically search for operators whenever you visit this screen, even when you just want to change the APN (maybe no big deal) [15:24] (3) promote APN to the top-level “Cellular” screen, so that the only reason you visit the “Carrier” screen is to change the carrier (a bit logically awkward if changing carrier changes your APN settings too). [15:26] awe_, what do you think? [15:26] mpt, makes sense to me. I'd favor 1) but with different semantics. 2) is okay, but it's said that the search can take minutes. And it does, on my network at least. [15:27] sorry mpt, gimme a minute [15:27] jgdx, what do you mean by “different semantics”? [15:28] jgdx, mpt, I favor (1) [15:28] or at least some explicit action that leads to a scan [15:28] I don't like auto-scans [15:28] at least in this case [15:29] mpt, actually, if we change "Automatic" to be a Switch then that semantic is okay. I saw Automatic as a itemselector. /me slaps himself. [15:29] auto-scans take some time so probably the button is a good idea [15:30] this thing about APN editor + carrier selection confused me a lot, btw [15:30] having the 2 things together [15:30] I thought manual/automatic was about whether using the APN you can edit or let the system choose it for you [15:31] jgdx, changing it from an ItemSelector to a switch would make it marginally less obvious, but wouldn’t address the scanning issue at all [15:31] mpt, changing the operator does *not* mean changing APN settings [15:31] APN are fixed per SIM [15:32] then you can register in different operators, usually when roaming [15:32] APN settings is the same even when roaming [15:32] it is about your SIM's operator, not about current network [15:32] so it actually makes much more sense to keep them separated [15:32] +1 [15:33] abeato, the “Automatically”/“Manually” list is labelled “Choose carrier:”. How did you get the idea that it was about APNs? [15:33] well, don't know, it is because APN does not depend on registered network as I have just explained, probably :) [15:33] probably because options 2 & 3 mention APNs? [15:33] ah, so that suggests (3) [15:34] mpt, yes [15:34] excellent [15:34] strongly :) [15:34] awe_’s “explicit action that leads to a scan” can then be “entering the Carrier screen” [15:34] works for me [15:34] \o/ [15:37] awe_, jgdx, so is there a bug report for this? [15:37] mpt, https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1388044 [15:37] Ubuntu bug 1388044 in ubuntu-system-settings (Ubuntu) "[cellular] Setting carrier selection to 'Manual' does not persist" [Critical,In progress] [15:40] mpt, want me to add ubuntu-ux as affected? [15:40] jgdx, already done [15:40] right [15:43] seb128: hi. I have a couple of branches up for mp to fix the top blocker bug https://bugs.launchpad.net/indicator-network/+bug/1336715 that will need some love from your system settings guys. [15:43] https://code.launchpad.net/~nick-dedekind/ubuntu-system-settings/lp1336715.check.sync/+merge/239494 [15:43] requires: https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/lp1336715.check.sync/+merge/239491 [15:43] Ubuntu bug 1336715 in unity8 (Ubuntu RTM) "[TOPBLOCKER] switch-items in indicators sometimes get out of sync with system-settings" [Critical,In progress] [15:43] dednick, what sort of work from our side? [15:44] kenvandine, mterry, pmcgowan: what are the rules for rtm and string changes? is that ok to do string tweaks knowing it regresses translations by invalidating the string and forcing a new cycles of translator work/langpack update? [15:44] olli, ^ [15:44] good question [15:44] seb128: merge reviews. i think i've fixed the bug [15:44] dednick, great, that we can do ;-) [15:45] mterry's wizard fix for the oobe did change a string that i think is directly related to fixing the bug [15:45] because the bug was about it not being obvious how to continue [15:45] kenvandine, it was not directly related [15:45] so on a passcode, it changed from 4 numbers to 4 digits only [15:45] kenvandine, "number" -> "digits only" [15:45] kenvandine, it could be pulled if needed [15:45] so it lets you know it will continue after 4 [15:45] sure it fixes confusion [15:45] but it has a cost [15:45] yeah [15:46] seb128, good point, we should be very careful not to change strings anymore [15:46] is bq happy if the string is not translated in spanish anymore? [15:46] probably not [15:46] seb128, when I wrote that branch we still had a few weeks left ;) [15:46] mterry, well, it got acked today [15:46] maybe it should not? [15:46]