[05:18] <lotuspsychje> morning touch devs :p
[08:09] <JamesTait> Good morning all; happy Apollo 11 Day! :-D
[08:31] <jamesh> mardy: ping? I have a few questions about online-accounts
[08:44] <Ron__> hello, i only want to know if the ubuntu tablet of meizu or bq will have got pen-digitalizator to write in the screen
[08:44] <Ron__> i saw the scecs but i didn't found, just 10 points of touch
[08:45] <Ron__> and sorry for my "engrish"
[09:22] <mhr3> seb128, did you ever see my question about the pkg/abi stuff?
[09:23] <seb128> mhr3, no
[09:24] <seb128> when?
[09:24] <mhr3> couple of days ago
[09:24] <mhr3> let me find it in logs
[09:26] <mhr3> seb128, http://paste.ubuntu.com/7802578/
[09:27] <seb128> mhr3, yeah, just get it added to the ubuntu-touch seed
[09:28] <mhr3> seb128, isn't it a problem that the old version would no longer be buildable? ie the src pkg would be building newer ver?
[09:28] <seb128> yeah, if you do that you need to keep different sources in the archive
[09:29] <seb128> or build old/new abi from the same source
[09:29] <mhr3> eh, option #3?
[09:36] <seb128> mhr3, no option 3
[09:37] <Laney> "don't break abi" :)
[09:40] <mhr3> seb128, not what i wanted to hear :/
[09:40] <seb128> mhr3, yeah, what Laney said is option 3
[09:40] <seb128> stop changing your interfaces all the time
[09:41]  * mhr3 looks at libmirserver22 and doesn't feel guilty despite whatever seb128 says
[09:41] <seb128> lol
[09:42] <seb128> at least they don't have clients to support/they transition those with them
[09:42] <seb128> seems it's not your case
[09:42] <mhr3> yea, lucky them
[09:44] <mhr3> seb128, so what would happen if we added it to the seed and it was no longer buildable?
[09:44] <seb128> mhr3, your new version would stay stucked in utopic-proposed and never reach an image because britney wouldn't let you do that
[09:45] <mhr3> seb128, time to migrate to rebecca, britney seems old
[09:47] <seb128> lol
[10:35] <nik90_> anybody here familiar with QDbusInterface. The clock app needs to make a call to com.canonical.indicator.datetime and retrieve some properties. However I am having trouble connecting to the dbus interface.
[10:36] <nik90_> Here is a code snippet and error output I got http://paste.ubuntu.com/7802826/
[11:28] <mhr3> seb128, can't we at least have src pkg based based on different series?
[11:29] <nik90_> dednick: ping (QDBus help)
[11:29] <mhr3> seb128, like lp:foo/abiX
[11:29] <dednick> nik90_: hey. what's up?
[11:29] <nik90_> dednick: hey, I am not sure if you remember, but I started writing the custom class for the clock app to get dbus properties from indicator datetime.
[11:30] <nik90_> dednick: however I am facing some errors that I am unable to solve, mind giving me a hand if you have time now?
[11:30] <dednick> yup
[11:31] <nik90_> dednick: so I have this code at the moment http://paste.ubuntu.com/7803025/
[11:31] <nik90_> dednick: I can confirm that it is able to read the Dbus session bus since I fixed the cmake stuff. However when I run I get the error Service Unknown
[11:31] <nik90_> dednick: I verified with d-feet if the interface, path and service names given were correct
[11:32] <nik90_> dednick: the entire code is at https://bazaar.launchpad.net/~nik90/ubuntu-clock-app/10-alarm-settings/view/head:/backend/modules/Alarm/Settings/alarmsettings.cpp
[11:33] <nik90_> dednick: I get QDBusError("org.freedesktop.DBus.Error.ServiceUnknown", "The name com.canonical.indicator.datetime.AlarmProperties was not provided by any .service files")
[11:35] <dednick> nik90_: firstly, is there a indicator branch that goes with this?
[11:35] <nik90_> dednick: I believe charles told me that this has already landed in the indicator side of things.
[11:35] <nik90_> dednick: https://bazaar.launchpad.net/~charlesk/indicator-datetime/lp-1318997-export-properties-to-dbus/view/head:/data/com.canonical.indicator.datetime.AlarmProperties.xml
[11:36] <nik90_> dednick: MP at https://code.launchpad.net/~charlesk/indicator-datetime/lp-1318997-export-properties-to-dbus/+merge/224743
[11:37] <mhr3> nik90_, your service name is wrong
[11:37] <dednick> nik90_: hang on, i need to update
[11:37] <mhr3> that's what the error is saying
[11:37] <nik90_> dednick: sure
[11:37] <nik90_> mhr3: yeah, but I cross checked the service name
[11:37] <mhr3> nik90_, it's without the .Alarm...
[11:38] <dednick> nik90_: yeah, mhr3 is correct.
[11:38] <dednick> "com.canonical.indicator.datetime" is the service name
[11:38] <nik90_> what about the object path? Is that still /com/canonical/indicator/datetime/AlarmProperties
[11:38] <mhr3> yes
[11:39] <dednick> nik90_: http://paste.ubuntu.com/7803044/
[11:39] <t1mp> I'm confused with the new network settings
[11:39] <nik90_> dednick, mhr3: ah thnx
[11:39] <t1mp> I have my network listed in "Previous networks", but I don't see a switch to enable it
[11:40] <nik90_> dednick, mhr3: that worked :)
[11:40] <seb128> mhr3, well, that's "different source package", and yes you can do that
[11:40] <dednick> mhr3: stop poaching my fixes! ;)
[11:40] <seb128> mhr3, like have lensesv6 and lensesv9
[11:40] <mhr3> seb128, \o/ at least that
[11:40] <mhr3> dednick, blame seb128, it took him ages to reply :P
[11:41] <seb128> mhr3, but those can't build any identific binaries, so you need to version the lib/bin/common/etc
[11:41] <mhr3> oh ffs
[11:41] <t1mp> oh.. disableing and then enabling wifi helped
[11:42] <mhr3> seb128, not even if we made sure that the newer ones are always higher version?
[11:42] <seb128> mhr3, no, it doesn't work that way, a binary can only belong to one source
[11:42] <mhr3> grrr
[11:44] <mhr3> hmm, maybe we could just disable all the other pkgs before releasing new abi?
[11:44] <mhr3> nah i guess that wouldn't work
[11:47] <seb128> mhr3, you could stop changing interfaces, rly ;-)
[11:47] <mhr3> seb128, tell that to c++ and gcc
[12:03] <cwayne> huh getting weird apparmor denials on my scope
[12:05] <cwayne> jdstrand: any idea why I'm getting this denial? http://paste.ubuntu.com/7803133/
[12:05] <cwayne> using template ubuntu-scope-network
[12:21] <ogra_> sergiusens, fyi https://launchpad.net/ubuntu/utopic/+source/livecd-rootfs/2.223
[12:24] <syano> Hi... recently learned about ubuntu touch...   Has ubuntu released an image that will run in any x86 device?
[12:26] <ogra_> there is the experimental desktop-next image ... that uses the UI (but none of the backend features a real touch install has)
[12:45] <jdstrand> cwayne: you aren't declaring something correctly somewhere. the items in the zmq directory should be named <"name" from click manifiest>_<"key name under hooks" from scope manifest>
[12:45] <jdstrand> cwayne: you appear to only have the part after the underscore
[12:45] <cwayne> jdstrand: I got it, yep I'd named stuff wrong
[12:46] <jdstrand> s/scope mainfest/click manifest/
[12:46] <jdstrand> ok cool
[12:50] <ogra_> mterry, yo
[12:50] <mterry> ogra_, hello!
[12:51] <ogra_> mterry, is there any dbus-ish way too find out if the user is capable to  lock the screen ?
[12:51] <mterry> what's the word?
[12:51] <mterry> ogra_, capable?
[12:51] <mterry> who isn't allowed to lock the screen?
[12:51] <ogra_> i need that for the dev-mode UI (needs to be greyed out until the user is able to lock)
[12:52] <ogra_> mterry, i would expect  anyone who doesnt have a pw set (or where it is locked)
[12:52] <mterry> ogra_, oh you mean whether a password is required to get into the session?
[12:53] <ogra_> i need to know if the user can actually unlock the screen and only then allow that dev mode can be enabled
[12:53] <mterry> ogra_, we do have an EntryIsLocked property
[12:54] <mterry> ogra_, that's false if the user has swipe-to-unlock on and/or an empty password.
[12:54] <cwayne> popey: thanks for the quick review :)
[12:54] <ogra_> mterry, cool, thanks ... looks like what i need
[12:54] <mterry> ogra_, or true if there is a prompt they have to answer associated with the account
[12:54] <ogra_> right
[12:54] <mterry> ogra_, so that's on dest=com.canonical.UnityGreeter, obj=/list, interface=com.canonical.UnityGreeter.List
[12:55] <popey> cwayne: np
[12:55] <ogra_> mterry, cool, thx
[12:55] <mterry> ogra_, you also mentioned not wanting to allow adb if the greeter is currently up?
[12:55] <ogra_> for RTM only being able to unlock is the req.
[12:55] <mterry> ok
[12:56] <mterry> Well we have a property for that too
[12:56] <ogra_> mdeslaur would like to see adb being stopped on locked state
[12:56] <mdeslaur> no
[12:56] <mdeslaur> i want it to not start if the screen is locked
[12:56] <ogra_> but that will break all our testing atm ... so this is post RTM stuff (where we will likely solve it differently by using a key exchange on machine basisi instead)
[12:57] <mdeslaur> if the screen locks while it is connected, that's fine
[12:57] <ogra_> right ... i still think we should rather go with a key db and have a key exchange instead ...
[12:57] <ogra_> basing on locked/unlocked will cause lots of testing issues
[12:57] <mdeslaur> sure
[13:01] <popey> cyphermox_: dunno if you've seen but my phone seems to have the radio wedged off.. no matter how I fiddle the airplane switch bug 1342602
[13:10] <renat__> Saviq, why the last version of shell has two sections with apps? What the first sections mean?
[13:30] <sil2100> AlbertA: hello! :)
[13:30] <sil2100> AlbertA: I heard that you're working on the unity-system-compositor fix for the breakage caused by the recent landing
[13:31] <sil2100> AlbertA: what's the ETA for a fix? Since if it's not a trivial thing, we would most probably consider a revert
[13:37] <AlbertA> sil2100: so I think we've identified
[13:37] <AlbertA> the root cause
[13:38] <AlbertA> sil2100: I think in about an hour I'll have a fix
[13:39] <AlbertA> sil2100: basically, we are blocking the QT thread that handles DBus incoming signals/requests
[13:40] <sil2100> Excellent
[13:46] <cyphermox_> popey: is that an upgrade or a new install?
[13:49] <popey> cyphermox_: upgrade, i think it broke when i repeatedly stabbed the flight mode button, but can't be certain
[13:50] <frecel> popey: should I file a bug showing up on home screen against unity or some other project?
[13:51] <popey> frecel: whats the bug?
[13:53] <frecel> popey: sometimes the home screen doesnt actually update until you touch it, as in if you turn the screen off wait a minute and then turn the screen back on it will be a minute behind and then when you touch it it will refresh and show the correct time
[13:57] <popey> frecel: i have noticed this also, i believe its a known bug
[13:58] <popey> sil2100: is the bug frecel is talking about the one you just discussed with AlbertA ?
[13:58] <AlbertA> popey: no that sounds different
[13:59] <ogra_> popey, i think thats rather the one we discussed in several morning meetings now
[13:59] <popey> yeah, did we file a bug for it?
[13:59] <ogra_> where Mirv was checkking if the event blocker is back
[13:59] <ogra_> (which doesnt seem the case)
[13:59] <popey> ok, so new bug?
[13:59] <popey> balls.
[13:59] <ogra_> popey, yeah, i guess so ... and i dont think it is filed yet+
[14:00] <popey> what would you file that on?
[14:00] <ogra_> heh
[14:00] <sil2100> popey, ogra_: yeah... I guess it's the old bug we've been seeing ;/
[14:01] <ogra_> popey, no idea ... it might go even down into the android stack or hybris ... or it might be a simple unity8 thing ... really hard to judge
[14:02] <popey> ugh.
[14:02] <popey> this is easily reproducable
[14:02] <ogra_> yes
[14:03] <ogra_> but hard to find the component at fault
[14:05] <frecel> would it be easier to find the person at fault? :D
[14:06] <popey> bug 1342742
[14:06] <popey> there you go, confirm that ☻
[14:24] <mhall119> bzoltan1: mhr3: I'm trying once again to write a scope from Trusty
[14:24] <mhall119> I have an i386 emulator with utopic and the associated kit
[14:25] <mhall119> but when I switch to that kit, the only build target I get is "simpletest"
[14:25] <mhall119> bzoltan1: also, I think there's a bug in the QtC emulator management
[14:26] <bzoltan1> mhall119: what the bug is about
[14:26] <bzoltan1> mhall119: I think I should backport the latest QtC from Utopic to the PPA. We have fixed tons of things related to the scopes. We have brand new templates and project wizard.
[14:27] <mhall119> bzoltan1: I created an emulator called 'utopic-devel', but it shows in QtC as only 'utopic' and it won't start
[14:27] <mhall119> running "ubuntu-emulator run utopic-devel" works fine
[14:27] <bzoltan1> mhall119:  that could be a real bug
[14:28] <mhall119> bzoltan1: wasn't the plan to continuously backport qtc to Trusty?
[14:29] <jhodapp> popey: are you going to fix the mediaplayer-app icon hide MR?
[14:29] <mhall119> cwayne: ping
[14:30] <cwayne> mhall119: pong
[14:30] <bzoltan1> mhall119:  for the Trusty I apply massive testing and dogfooding ... it takes time
[14:30] <mhall119> cwayne: hey man, how have you been developing scopes, are you running topic on your desktop?
[14:31] <bzoltan1> mhall119:  i will release a new trusty QtC tomorrow
[14:31] <mhall119> ok, thanks bzoltan1
[14:31] <cwayne> mhall119: yep
[14:31] <mhall119> cwayne: ok
[14:31] <bzoltan1> mhall119:  I do not  take risks... I got burned too many times
[14:31] <cwayne> mhall119: although it sucks that I have to.. it'd be so much better to be able to do it from trusty
[14:31] <mhall119> bzoltan1: do we have enough automated testing around qtc and our plugins?
[14:32] <mhall119> cwayne: I agree, which is why I'm sticking to trusty until we get it sorted
[14:32] <popey> jhodapp: do we have the right incantation?
[14:32] <cwayne> mhall119++
[14:33] <bzoltan1> mhall119:  absolutely no... autopilot was not up to the task in the last two years. Now i am testing the latest autopilot from the lp:autopilot and it seems to have major improvements. It can introspect object what it did not see before
[14:33] <jhodapp> popey: I thought so...we can copy what other .desktop files do in /usr/share/applications/
[14:34] <jhodapp> popey: like this: "NoDisplay=true"
[14:34] <jhodapp> popey: sync-monitor-calendar.desktop uses that
[14:35] <popey> jhodapp: so remove OnlyShowIn=neverShow and add NoDisplay=true ?
[14:35] <jhodapp> popey: yes
[14:35] <popey> ok, 2 min
[14:35] <jhodapp> great thanks
[14:36] <popey> jhodapp: updated branch, pushed
[14:36] <cyphermox_> popey: all I can suggest right now is to run /usr/share/ofono/scripts/online-modem to get it back online
[14:37] <jhodapp> popey: awesome
[14:37] <jhodapp> popey: testing it
[14:37] <mhr3> mhall119, tbh never tried the emulator, let me know how that goes
[14:38] <mhall119> mhr3: so far it's not
[14:38]  * mhr3 has to live on bleeding edge
[14:38] <popey> cyphermox_: that did it, thanks
[14:38] <mhall119> I'm going to try re-creating an i386 emulator without hypens in the name to see if I can get further
[14:39] <jhodapp> popey: yep it's not visible
[14:39] <cwayne> i got some of my scopes working in the i386 emulator, so it should work
[14:39] <popey> sweet jhodapp !
[14:42] <jhodapp> popey: added us to the CI sheet
[14:42] <popey> \o/
[14:47] <jhodapp> popey: it's building...will land right after
[14:48] <mterry> seb128, heyo!  Did you have time to look at the locking-hash branch?
[14:48] <popey> will keep an eye out jhodapp
[14:48] <jhodapp> cool
[14:48] <mterry> ogra_, you mentioned we can't bindmount writable files individually?  I see on my device that /etc/init/ssh.override is in my mount output.  Am I misreading that?
[14:49] <ogra_> mterry, we cant delete bind mounted files ...
[14:49] <mterry> ogra_, but I'm thinking for /etc/shadow and whatnot
[14:49] <ogra_> mterry, why do you want to fiddle with that file ?
[14:50] <mterry> ogra_, for the same reason we want libnss-extrausers!
[14:50] <mterry> ogra_, we can avoid the need for that altogether
[14:50] <ogra_> but do we want to ? note that this was discussed at the sprint ...
[14:50] <ogra_> and the nss-extrausers solution was deemed to be safest
[14:51] <mterry> ogra_, my memory from the sprint was ya'll saying that we couldn't do individual files
[14:51] <ogra_> we can
[14:51] <mterry> well..   geeze.  Just do that
[14:51] <mterry> :)
[14:52] <mterry> Do we not trust the existing protections for those files?
[14:52] <ogra_> not sure we want that ...
[14:52] <mterry> What's the argument against it?
[14:53] <mterry> mdeslaur, would there be security concerns about making /etc/shadow, /etc/group, /etc/passwd writable?
[14:53] <seb128> mterry, hey
[14:53] <seb128> mterry, I was sort of waiting for the security team to do a review ;-)
[14:54] <seb128> mterry, but sure, let me do one from the settings side
[14:54] <mterry> seb128, I'm worried about timing so the more we can front-load the better :)
[14:54] <mdeslaur> mterry: writable by who?
[14:54] <mterry> mdeslaur, bindmounted from the writable filesystem instead of the RO one
[14:55] <mterry> mdeslaur, normal file permissions and such
[14:55]  * ogra_ sighs
[14:56] <mdeslaur> mterry: I believe all the tools write a temp file beside them and then rename them in place...so I'm not sure you can bind mount those
[14:56] <mterry> ogra_, why am I bumming you out?  Am I retreading ground we've already discussed?  I don't remember this being seriously considered at the spinrt
[14:57] <mterry> mdeslaur, interesting
[14:58] <mdeslaur> isn't that part of the reason why there was discussion about an different file using nss?
[14:58] <ogra_> mterry, it was discusssed at the foundations table in the great ballroom for a bit ... feel free to implement it or not ... just going back and forth in that discussion wont get us forward iirc there were valid reasons to not make the files writable
[14:58] <ogra_> mdeslaur, right
[14:58] <ogra_> mdeslaur, the prob is that we need the tools to work with nss-extrausers ... passwd, adduser namely ...
[14:58] <mdeslaur> there was also the upgrade scenario, but my memory is a bit fuzzy on that one
[14:59] <mterry> ogra_, OK.  There must have been some discussions I wasn't a part of, I thought I was there for those meetings
[14:59] <mdeslaur> ah right, if the groups get changed in the ro image, they won't be represented in the rw version
[14:59] <cyphermox_> popey: np. I'm working on a more permanent fix but it seems there is some disagreeing on how to correct fix it
[14:59] <ogra_> mterry, it wasnt actualyl a meeting
[14:59] <popey> cyphermox_: supply a sledgehammer with every phone
[15:00] <mterry> ogra_, well regardless.  I'm caught up
[15:00] <ogra_> mdeslaur, yeah, thats handled by stgraber by chowning stuff (or by some implementation to phardcode UID/GID values at build time)
[15:00] <jarreed0> does the Ubuntu touch support an accelerometer driver, such as lis3lv02d
[15:00] <cyphermox_> popey: too costly
[15:01] <mdeslaur> ogra_: no, I mean if a group gets added to /etc/group in a package update, the rw image's /etc/group won't get it
[15:01] <mterry> ogra_, did you ever get a hold of stgraber/infinity to discuss how they manage their extrausers setup?
[15:01] <mdeslaur> unless someone writes some merge logic
[15:01] <ogra_> mdeslaur, debs arent supported :)
[15:01] <ogra_> if you use them you are on your own
[15:03]  * mterry is just nervous that we are a day away from freeze and we don't seem to understand the details of how to enable extrausers like we need to
[15:03] <mdeslaur> ogra_: so you're telling me the ro images aren't generated by canonical from debs?
[15:03]  * ogra_ is nervous that we are a day away from freeze and he doesnt get dev mode done because he discusses already planned features over and over 
[15:04] <mterry> ogra_, ok, sorry man
[15:04] <ogra_> mdeslaur, they are and for changes at build time stgraber works on a solution
[15:04] <mdeslaur> ogra_: and how would you merge that back into the rw /etc/group file?
[15:04] <mdeslaur> which is on the device and not in the image
[15:05] <ogra_> mdeslaur, we dont, we dont have a rw file
[15:05] <mterry> mdeslaur, well that's why we probably aren't planning to do rw
[15:05] <mterry> mdeslaur, that was my what-if question
[15:05] <mterry> mdeslaur, not a current plan
[15:05] <stgraber> mdeslaur: the idea is that /etc/group is read-only, /etc/writable/group is writable and we use nss-extrausers to look at both files and merge the output at the nss layer
[15:05] <mdeslaur> stgraber: right, which is why we can't just make /etc/group writable like mterry wants
[15:06] <mterry> Right, among other reasons apparently
[15:07] <ogra_> mdeslaur, exactly
[15:07] <ogra_> stgraber, any idea what we do with "passwd" ? it operates through pam and wont update the /etc/writable/shadow file
[15:07] <ogra_> in case you want to set a passwd
[15:09] <stgraber> ogra_: I suspect this may be more of a slangasek question seeing how he maintains and contributes to pam upstream :)
[15:09] <stgraber> ogra_: there's however a rather ugly but working alternative we could use
[15:10] <stgraber> ogra_: basically mount /etc/passwd /etc/group /etc/shadow and /etc/gshadow to /etc/readonly/<filename> and then mount /etc/writable/<filename> over /etc/<filename>
[15:10] <stgraber> ogra_: which then makes it so that /etc/passwd contains your local writable entries and /etc/readonly/passwd contains the rest
[15:11] <stgraber> making any tool that directly changes /etc/passwd /etc/shadow ... "just work"
[15:11] <ogra_> stgraber, hmm and leaving extrausers for the ro files ?
[15:11] <mterry> stgraber, we were just talking about that -- apparently tools that modify them do it by writing new file in /etc then moving it, which makes that plan tough
[15:11] <stgraber> ogra_: right
[15:12] <jhodapp> popey: MR is landing
[15:12] <nik90_> charles: ping
[15:12] <charles> nik90_, pong
[15:12] <stgraber> mterry: ah yeah, that's always a bit annoying, we've had the same problem with systemd and ended up having to patch it... as we can't make /etc itself writable for obvious reasons and anything short of doing that just fails
[15:13] <nik90_> charles: I got reading the alarm settings from the dbus working :)
[15:13] <stgraber> mterry: I suspect the best way there would be to patch pam (or whatever does the edit) to attempt to create the temp file, if that fails, attempt an in-place edit instead
[15:13] <nik90_> charles: I wanted to talk to you about the alarm volume though. Is it dependant on the phone volume?
[15:13] <mterry> mdeslaur, ^ how feasible is that from a security pov?
[15:13] <charles> nik90_, \o/
[15:14] <nik90_> charles: Would setting alarm volume 50 while the phone volume is 0 (silent) still ring the alarm with the alarm volume?
[15:14] <nik90_> charles: https://bugs.launchpad.net/ubuntu-clock-app/+bug/1337917
[15:16] <charles> nik90_, brb
[15:16] <nik90_> charles: ok
[15:18] <jcastro> is excessive battery drain on nexus4's a known issue?
[15:18] <jcastro> I left it on my Qi charging pad last night and woke up to 50% battery
[15:18] <popey> i haven't seen that for a while, but it can depend whats open
[15:19] <ogra_> jcastro, my mako survives a day of moderate usage
[15:19] <mdeslaur> stgraber, mterry: in-place edits on those files is a disaster waiting to happen. Can't we make passwd use the rw files?
[15:19] <ogra_> and i charge it via Qi on my nightstand
[15:19] <mdeslaur> as an option
[15:19] <ogra_> mdeslaur, thats what we'll do
[15:19] <jcastro> popey, ok I had some stuff open, will try it again
[15:19] <ogra_> mdeslaur, see stgraber's explanation above
[15:20] <ogra_> mdeslaur, but even with the rw files passwd wants to back the original up
[15:20] <ogra_> before editing
[15:23] <mterry> stgraber, separately, how does nsswitch handle merging the different databases?  Like, if I wanted to add phablet to a group also defined in /etc/group, can I have lines for that group in both and they get merged?
[15:28] <stgraber> mterry: I don't know
[15:29] <mterry> stgraber, ok.  That's actually not 100% necessary -- we can function without adding phablet to nopasswdlogin
[15:30] <stgraber> my guess would be that nss will go through the databases in order and return the first matching entry
[15:30] <ogra_> yeah
[15:30] <stgraber> which would only be a problem if you had a group in the read-only file which contained members and to which you want to add extra members but IIRC we don't have any of those in our default install (just empty groups)
[15:30] <mterry> stgraber, I also suspect that.  Would be nice (for this use case) if those lines were indexed by user instead of group
[15:30] <ogra_> thats most likely why the order of entries in nsswitch.conf matters
[15:31] <mterry> stgraber, well we do have that -- nopasswdlogin -- but we can survive without it by setting the user's password to blank
[15:32] <mterry> So yeah, that means that the only big question for libnss-extrausers is how to handle passwd changing the password
[15:34] <ogra_> by flipping the files
[15:34] <mterry> ogra_, and making passwd edit in-place, but mdeslaur seemed to hate that
[15:35] <ogra_> mterry, well, or work around the temp file creation differently
[15:35] <mdeslaur> of course, you'll hit a race and corrupt the file and the user will no longer be able to log in
[15:35] <ogra_> mdeslaur, yeah ... /me not liking
[15:35] <mterry> mdeslaur, we can presumably create the files in a folder besides /etc if we do some patching?
[15:36] <ogra_> yeah, that would be my suggestion
[15:36] <ogra_> have a dedicated writable dir for the tempfile creation
[15:37] <mdeslaur> needs to be on the same partition if you want to mv it into place
[15:37] <mdeslaur> so you can't bind mount it
[15:42] <mterry> mdeslaur, stop being difficult!  ;)
[15:42]  * mterry needs lunch brain food
[15:42] <mdeslaur> lol
[15:43] <mterry> mdeslaur, can we just go back to storing a crypt hash of the password in ~/.unity8-greeter-demo?  so much easier  :)
[15:43] <mdeslaur> sure, phablet/phablet was awesome
[15:45] <ogra_> lets just drop all that user crap ... make everything rw and the user being root
[15:49] <mterry> mdeslaur, well to be fair, a password hash in the home directory isn't nearly as bad as phablet:phablet
[15:50] <ogra_> a user readable shadow file ?
[15:51]  * ogra_ guesses that is just as bad :)
[15:55] <charles> nik90_, I don't know how the alarms' sound setting will interact with the overall volume level -- rsalveti just landed (or is landing?) the PulseAudio code so that different roles (e.g. "alarm") can have different volumes
[15:55] <charles> nik90_, iiuc, for example that's so an alarm can go off at the right volume even if the phone is in silent mode
[15:56] <nik90_> charles: iiuc?
[15:56] <charles> rsalveti, is that correct?
[15:56] <charles> nik90_, (if I understand correctly)
[15:56] <nik90_> :)
[15:56] <nik90_> charles: ok
[15:56] <charles> rsalveti, also while we're on the topic, what does indicator-datetime need to change to set the "alarm" role for the sounds it's playing?
[15:57] <nik90_> rsalveti: is there somewhere this is being tracked?
[15:57] <mterry> ogra_, only for the user's own password
[15:58] <mterry> ogra_, which admittedly isn't great, but for Touch apps shouldn't be able to read it
[15:58] <ogra_> true
[15:58] <jhodapp> charles: how is indicator-datetime playing the sounds...does it use a Qt object?
[15:58] <charles> jhodapp, it's using gstreamer
[15:59] <jhodapp> charles: right, ok...so yeah it'll be using pulsesink then
[16:00] <nik90_> charles: at the moment, I can read/write to the alarm volume, duration. Is there anything else I need to do? For instance should I also use PropertiesChanged signal that you provided? At the moment only the clock app can change these settings.
[16:01] <charles> nik90_, listening for PropertiesChanged & updating clock-app's state accordingly would be The Right Thing if you've got time to do it
[16:02] <nik90_> charles: alrite I will do that as well then.
[16:02] <charles> nik90_, I agree it's not a hard goal for RTM but if we don't do it now it'll be a bug ticket later as soon as another app starts poking with the alarms :-)
[16:02] <nik90_> charles: :-)
[16:02] <nik90_> charles: the clock app should be exclusive :P
[16:04] <charles> jhodapp, ok. Do you know what properties datetime should set there for the alarms, or is that an rsalveti question?
[16:05] <jhodapp> charles: it's rsalveti since it's dealing with pulse...I'm not exactly sure how you'll get the gstreamer pulsesink to select which output stream to be on
[16:06] <charles> jhodapp, np; thanks for the info
[16:07] <jhodapp> charles: looking at the pulsesink docs on freedesktop.org, it does look like there is a stream-properties property for the sink
[16:07] <jhodapp> charles: that might possibly allow you to select your stream
[16:07] <jhodapp> charles: I assume you're using playbin to play the alarm sound?
[16:08] <charles> jhodapp, right
[16:08] <kenvandine> Laney, i see you have a uss MP related to autopilot tests and updates, do you think that would fix http://paste.ubuntu.com/7804110/
[16:09] <Laney> kenvandine: nope, those tests are buggy
[16:09] <jhodapp> charles: yeah, take a look at the pulsesink source code to see what types of properties it'll take in that GstStructure...because you should be able to get a pointer to the pulsesink and set that property then from your code
[16:09] <Laney> wait
[16:09] <Laney> misread
[16:09] <Laney> kenvandine: umm I've not seen that one
[16:09] <Laney> did you look at what this test does?
[16:10] <kenvandine> i'm sure that failure isn't related to my branch
[16:10] <Laney> it's surprising that it fails
[16:10] <kenvandine> not yet, it wasn't in anything i touched... so looked to see if it was known
[16:10] <kenvandine> and saw your branches
[16:10] <Laney> hmm actually I did fix some bugs with 'self.about_page'
[16:10] <Laney> maybe just pre-req on my branch and see if it works after that :)
[16:11] <kenvandine> I'll see if it fails in CI first
[16:11] <kenvandine> it fails on my device
[16:11] <Laney> haven't had a CI run on that one yet though so it could be terrible in itself
[16:11] <Laney> the problem was that a recent change was making AP sometimes miss clicking on the about button
[16:12] <Laney> if an update notification comes in and moves it down so that the coordinates change after AP has decided it knows what they are
[16:12] <jdstrand> nik90_: did that apparmor rule help?
[16:13] <dpm> pitti, I've got someone translating the phone into Korean and he's finding that there is no Korean available for selection in system settings, which is probably because Korean didn't make the cut. I seem to remember that the packages are still on the archive, just not preinstalled
[16:13] <nik90_> jdstrand: yeah it did :)
[16:13] <jdstrand> ok, I'll update the policy
[16:13] <dpm> pitti, so he should be able to just go into RW mode and install the Korean touch langpack, right?
[16:13] <nik90_> jdstrand: thnx
[16:15] <nik90_> dednick: hey, I am able to now read/write into the dbus. Thnx for your help. Do you have any sample code where I can track the dbus signal to know when the property has changed in dbus?
[16:15] <nik90_> dednick: would I need to use connect() as shown in https://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/plugins/Powerd/Powerd.cpp ?
[16:20] <pitti> dpm: no, we don't build them at all, and include all available packs on the phone
[16:22] <dpm> pitti, oh, but it seems I saw a language-pack-touch-ko package on the archive. Perhaps it's indeed preinstalled already? Let me check if I see Korean myself on system settings...
[16:22] <dednick> nik90_: yep, thats the one
[16:24] <nik90_> dednick: will give it a try
[16:25] <pitti> dpm: oh, wait -- I think inclusion of new ones requires rebuilding ubuntu-touch-meta
[16:25] <pitti> dpm: so yes, apt-get installing it is fine for testing
[16:26] <pitti> dpm: I can rebuild -meta now, hten the next image will have it
[16:27] <dpm> pitti, that'd be cool, Korean is one of the languages we'd like to have good coverage for, and we've got enthusiastic translators wanting to contribute :-)
[16:27] <nik90_> charles: is there a way to change the value in d-feet so that I can check if the clock app correctly updates its state?
[16:28] <charles> nik90_, you could do it that way, even easier would be using dconf-editor and editing /com/canonical/indicator/datetime
[16:29] <nik90_> charles: ah sweet
[16:29] <charles> nik90_, open up dconf-editor, navigate down the tree on the left-hand-side to indicator-datetime, and then click on the property on the right-hand-side that you want to change
[16:30] <nik90_> thnx
[16:33] <pitti> dpm: hm, it was rebuilt three days ago
[16:33] <pitti> dpm: and language-pack-touch-ko is on it
[16:34] <pitti> dpm: then I suppose we just didn't promote an image recently
[16:42] <jdstrand> ogra_: hey, I know we've talked about this before and istr you saying it was basically solved, but how are we handling /usr/share/apparmor/hardware/*.d/* files?
[16:42] <jdstrand> ogra_: (going forward)
[16:42] <jdstrand> ogra_: I have this lingering bug to move what apparmor-easyprof-ubuntu currently ships in there to somewhere else
[16:43] <ogra_> jdstrand, shipping them per device in the device tarball and bind mount them on boot
[16:43] <ogra_> (with generic names)
[16:43] <jdstrand> ogra_: is that work being tracked somewhere?
[16:43] <ogra_> i dont think so
[16:44] <ogra_> there was a blueprint ... but nobody uses bliueprints nowadays :P
[16:44]  * jdstrand still does
[16:44] <jdstrand> which is why this bug keeps lingering
[16:44] <jdstrand> :)
[16:45] <jdstrand> or rather, why I keep getting reminded about it
[17:00] <dpm> pitti, so I've just looked at the languages available in system settings, and while I cannot read Korean, for the little knowledge I know, Korean is not in one of the selectable languages there. Unless it's the last one on the list, for which there are no fonts to display its characters
[17:02] <dpm> pitti, however, it seems language-pack-touch-ko is indeed installed on my phone
[17:04] <mhall119> yay, r133 is promoted!
[17:05] <mhall119> bzoltan1: are the UITK API docs in a separate -doc package?
[17:07] <bzoltan1> mhall119: yes, it is in the ubuntu-ui-toolkit-doc
[17:12] <mhall119> thanks bzoltan1
[17:14] <renat__> popey, I can not change the priority of this bug https://bugs.launchpad.net/ubuntu/+source/qtorganizer5-eds/+bug/1336880, can you add the permissions for me?
[17:14] <mterry> slangasek, so given the various options for writing to /etc/shadow (or similar), I'm thinking the easiest (and also useful elsewhere) thing would be to add support for libnss-extrausers locations to pam.  Mostly because the other options have probles atomically editing /etc/shadow.   How difficult / (un)recommended would adding that support be, do you think?
[17:16] <popey> renat__: hmm, dunno why you can't and I can, and what perms I could give
[17:16] <popey> renat__: what do you want me to set it to?
[17:16] <slangasek> mterry: I don't want it in pam_unix; please branch pam_unix for this purpose and add it as a separate module in the stack
[17:16] <slangasek> mterry: to be precise, I don't want it in pam_unix without it going upstream first
[17:16] <mhall119> bzoltan1: how about the upstream QML API docs, is there a package for them?
[17:16] <renat__> popey, importance = high
[17:17] <renat__> popey, could you do a triage on eds-bugs, and set the correct importance
[17:17] <renat__> this way I would be able to know which bugs I should fix first
[17:17] <popey> ok
[17:18] <bzoltan1> mhall119: there is a qt5-doc what pulls several other -doc packages
[17:20] <rsalveti> nik90_: charles: jhodapp: yeah, once the stream is using the right properties, pulse should do the right thing
[17:20] <rsalveti> but that is still in progress, didn't land yet
[17:20] <rsalveti> and I need to put a bit more work on it to be useful, so hopefully I should know more next week
[17:21] <mhall119> bzoltan1: qtdeclarative5-doc only seems to have qch docs, are qdoc-generated HTML docs in a package somwhere?
[17:22] <mhall119> ah,found qtdeclarative5-doc-html
[17:22] <bzoltan1> mhall119:  yes qt5-doc-html
[17:23]  * bzoltan1 is slow :)
[17:23] <nik90_> rsalveti: thnx
[17:32] <renat__> popey, I can not mark this bug as wont fix: bug #1336880
[17:33] <mhall119> renat__: isn't that the one you wanted marked as high importance 15 minutes ago?
[17:34] <popey> no
[17:34] <renat__> mhall119, :D, yes but I just figure out this is not a valid bug
[17:34] <mhall119> heh
[17:34] <popey> oh
[17:34] <popey> i thought it was different
[17:34] <popey> bah
[17:37] <taiebot> Waouh superb update guys i love r133 for the moment.
[17:41] <taiebot> Are you able to see your phone services in system settings on r133 i reported this bug a while back. Really need this when i go abroad. https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1323837
[17:44] <renat__> charles, I think this bug is related with that one that we discussed some time ago. could you confirm? bug #1320914
[17:45] <renat__> changing the system timezone does not update the datetime indicator
[17:45] <charles> renat__, yep I think we have another ticket for that already
[17:46] <charles> renat__, found it, https://bugs.launchpad.net/indicator-datetime/+bug/1332095
[17:46] <renat__> charles, tanks
[17:46] <renat__> thanks
[17:46] <charles> I'll close 1332095 as a dupe
[18:19] <frecel> is there an equivalent of intent from android in ut?
[18:28] <awe_> pmcgowan, what image did SIM services land in?
[18:28] <pmcgowan> awe_, not sure, over a week ago
[18:29] <awe_> where is it?  I didn't see it under Cellular Settings?
[18:29] <awe_> I'm running #132
[18:29] <mterry> mdeslaur, so I'm thinking of forking pam_unix into a pam_extrausers version that supports writing to extrausers locations.  That seems like something you might have thoughts on
[18:29] <awe_> pmcgowan, got
[18:30] <awe_> it's under System:Phone
[18:30] <pmcgowan> right
[18:30] <awe_> pmcgowan, also... the tech pref seems odd
[18:30] <awe_> 2G or 2G|3G|4G
[18:30] <pmcgowan> awe_, isnt that right?
[18:31] <awe_> we've discussed hw capabilities in the past, but never moved on implementing them
[18:31] <awe_> pmcgowan, well...does mako support 4G?
[18:31] <pmcgowan> oh, well UI doesnt know
[18:31] <awe_> seems odd that 4G should be presented to the user
[18:31] <pmcgowan> hence the |
[18:31] <awe_> pmcgowan, yea...that was my point about hw capabilities
[18:31] <awe_> or lack thereof
[18:31] <pmcgowan> right
[18:31] <awe_> so 1) a mako shouldn't mention 4G
[18:32] <awe_> and 2) on a phone that does support LTE
[18:32] <awe_> it should have three choices
[18:32] <awe_> 1) 2G ( super battery saver )
[18:32] <mdeslaur> mterry: slangasek is the one you should talk to before doing something like that
[18:32] <awe_> 2) 2G | 3G ( save battery )
[18:32] <pmcgowan> awe_,  UI is currently just generic not literal
[18:32] <awe_> 3) 4G ( super-fast )
[18:32] <pmcgowan> I see
[18:32] <pmcgowan> add a bug?
[18:32] <awe_> sure
[18:32] <pmcgowan> I will mark wishlist ;)
[18:33] <awe_> haha, I'll wait for one of our OEMs to report the same thing then
[18:33] <awe_> ;D
[18:34] <mterry> mdeslaur, he recommended a fork over patching pam_unix to support extrausers since he didn't feel comfortable with such a change unless it went upstream first
[18:38] <ogra_> forks are modern and fashionable
[18:39] <ogra_> :)
[18:41] <mdeslaur> mterry: ok, if that's what he suggested, that sounds good to me
[18:47] <nik90_> charles: could you review the c++ part of https://code.launchpad.net/~nik90/ubuntu-clock-app/10-alarm-settings/+merge/227068
[18:48] <nik90_> charles: it is for the dbus calls
[18:48] <charles> nik90_, sure
[18:51] <charles> nik90_, Jenkins needs some convincing
[18:51] <nik90_> charles: no jenkins is broken for the clock app reboot branch
[18:51] <nik90_> charles: it requires debian packaging which hasn't landed. until then it will keep reporting it as failed
[18:54] <mhall119> popey: file manager works as a generic file picker via content-hub now! \o/
[18:54] <popey> BOOM!
[18:55] <mhall119> does it do generic file imports too?
[18:56] <mhall119> doesn't seem to
[18:56] <mhall119> still, we can update document-viewer now to be useful!
[19:00] <frecel> mhall119:  popey: is there some equivalent of intent from android on ut?
[19:01] <mhall119> frecel: no
[19:01] <mhall119> frecel: the closest is the Page component, but Ubuntu works very differently than Android so even that is quite different
[19:03] <mhall119> frecel: if you want to duplicate Android-style navigation, use a PageStack in your MainView and push/pop Page items to it
[19:03] <frecel> mhall119: I don't think you understood my question. I meant intent as in this : http://developer.android.com/reference/android/content/Intent.html
[19:04] <mhall119> oh, right, I'm thinking of Activities not Intents
[19:04] <mhall119> so then no, there's no real equivalent of intents
[19:05] <mhall119> Content Hub offers some of the functionality you might use Intents for
[19:07] <frecel> mhall119: I was just hoping that if an rss link would be clicked in browser a popup could show up asking if you want to send it right to a podcatcher or an rss reader
[19:07] <mhall119> Green Mahjong *almost* works now
[19:08] <frecel> mhall119: otherwise you have to go through the hassle of copying and pasting it yourself manually
[19:09] <mhall119> kenvandine: for the usecase above ^^ would that be content-hub or url-dispatcher?
[19:09] <mhall119> I'm not sure which is best to use for mime-type based links
[19:13] <kenvandine> mhall119, not sure, you could use the content-hub with an "open with" type thing
[19:13] <kenvandine> exporting the link to the app
[19:13] <kenvandine> but it wouldn't be automatic
[19:13] <kenvandine> you'd have to long press on the link in the browser or whatever
[19:16] <frecel> kenvandine: can I say something in my manifest file that is basically "this app can handle this type of content"?
[19:16] <kenvandine> you would need to use the content-hub hook
[19:16] <kenvandine> to say it can be a destination for links
[19:17] <kenvandine> and your app would need to listen for the transfer, which would contain the link
[19:18] <frecel> how would I go about only getting links to rss and atom feeds?
[19:20] <kenvandine> the browser would need to add an export handler to know it can export those
[19:20] <kenvandine> export would be like "open with"
[19:20] <kenvandine> the browser already does this for sharing
[19:21] <kenvandine> frecel, so your app would get a signal that it has an incoming transfer, which would contain the link
[19:21] <kenvandine> and you could do what you want with the link
[19:22] <frecel> so basically you're telling me that I need to bother oxide people until they add an export handler for my case
[19:25] <kenvandine> not oxide, webbrowser-app
[19:29] <dobey> well you'd probably want it to work in apps that embed a web view too
[19:37] <frecel> dobey: well it makes sense to keep export handlers away from oxide and then have seperate widgets for oxide and the browser with export handling functionality, the browser would need the ability to run without the toolbar enabled
[19:47] <tedg> alexabreu, Commented in bug 1342129, that's fine. We don't need you to register a well-known name, just have a well-known path for the object.
[19:48] <alexabreu> tedg, ok thx
[19:54] <jdstrand> alexabreu: note, the ubuntu-webapp template is missing something that the ubuntu-sdk has, so there may still be some policy updating for me to do. please feel free to comment in the bug if you have a denial after doing what tedg suggests
[19:56] <pmcgowan> jdstrand, any reason why system-settings would be unable to play audio you can think of?
[20:01] <jdstrand> pmcgowan: perhaps media-hub doesn't have the right access? what does 'grep DEN /var/log/syslog' say?
[20:02] <pmcgowan> jdstrand, I got one for camera-app but thats it
[20:02] <jdstrand> pmcgowan: was camera-app /dev/fb0?
[20:02] <pmcgowan> yes
[20:02] <jdstrand> ok, that can be ignored
[20:03] <jdstrand> pmcgowan: yeah, I don't know otoh
[20:03] <pmcgowan> ok
[20:05] <hollooo> hello. I didn't find the TERMINAL app in the emulator. in a search engine/ on project page no binary too. anyone can help?
[20:06] <mhall119> sergiusens: I can't send or recieve MMS still on r133
[20:06] <sergiusens> mhall119: are you on tmobile?
[20:06] <mhall119> nuntium.log says something about "Cannot activate ofono context: No mms contexts found"
[20:06] <mhall119> sergiusens: no, AT&T go-phone
[20:07] <sergiusens> mhall119:  oh; that's most likely a provisioning error; not sure if apn editing landed yet; but awe_ should be able to help with the right context data
[20:08] <sergiusens> mhall119: sending is in the process of being fixed; it actually landed broken
[20:08] <mhall119> ok
[20:14] <nik90> hollooo: I think I may know why you dont see terminal in the emulator
[20:14] <awe_> mhall119, sergiusens, APN UI is still a ways off
[20:14] <nik90> hollooo: the emulator is i386, and I think the click package in the daily images are armhf. So the architecture difference could be the cause of it
[20:14] <nik90> hollooo: do you see the file manager?
[20:15] <awe_> mhall119, that said, if this doesn't work for you, can you open an ofono bug, and I'll check it out/move it, if need be
[20:16] <awe_> mhall119, one very important bit, is to include the following line from your syslog: Provisioning for MCC 310, MNC XXX...
[20:16] <awe_> just run 'grep ofono /var/log/syslog' and look for that line
[20:18] <dpm> sergiusens, someone was asking me of instructions on how to build the emulator from source. Do we have these anywhere? And are the sources in http://bazaar.launchpad.net/~phablet-team/goget-ubuntu-touch/trunk/files all he'd need to build it, or does it depend on some remote android git repo or something... ?
[20:18] <taiebot> Hi all. Are you still receiving one ring on phone calls on r133? Will miss less phone calls anyway due to haptic feedback \o/
[20:19] <sergiusens> dpm: the emulator runtime proper or the "manager"?
[20:20] <sergiusens> dpm: for the manager it's just setup a go env and then "go get launchpad.net/goget-ubuntu-touch/ubuntu-emulator"
[20:21] <mhall119> awe_: will do, do you want my nuntium.log file too?
[20:21] <sergiusens> mhall119: shouldn't be needed
[20:21] <sergiusens> it's failing at a prior step
[20:21] <mhall119> ok
[20:21] <mhall119> I'll grab that syslog stuff when I get to a USB cable
[20:21] <awe_> mhall119, definitely not
[20:22] <awe_> nuntium.* --> sergiusens
[20:22] <sergiusens> mhall119: the output of /usr/share/ofono/scripts/list-contexts can be useful
[20:22] <awe_> ;D
[20:22] <dpm> sergiusens, both, i.e. anything you need to produce an emulator that can run after building the sources. Is the runtime somewhere else?
[20:22] <mhall119> can I ssh into my device over wifi?
[20:22] <sergiusens> awe_: I suspect mhall119 is seeing that issue you told me either bill or michael had with at&t and how it was provisioned
[20:22] <awe_> sergiusens, knowing the mnc/mcc/imsi/gid from the Provisioning line mentioned above is all I need
[20:22] <mhall119> dpm: is the emulator source not in the package source?
[20:22] <awe_> then I can look at the apn-db directly
[20:23] <awe_> sergiusens, yea probably
[20:23] <sergiusens> awe_: but mhall119 might have never ever reflashed ;)
[20:23] <awe_> mbpi is going away this week
[20:23] <awe_> sergiusens, did you point him at the bug
[20:23] <sergiusens> nope
[20:23] <awe_> bfiller posted very clear instructions for the workaround
[20:23] <awe_> one sec
[20:23] <hollooo> nik90: I found some files now and I thought about a file manager too now. at the moment the emu is off because of other things to do the next 1-2 hours but i cannot remember to have seen a file manager out of the lenses. and the arm image is really slowmotion but there are apps on i386 and I saw binarys of terminal here: https://code.launchpad.net/~luksi.reiku/+recipe/ubuntu-terminal-app-daily but I have to inform how to insta
[20:23] <dpm> mhall119, Sergio is mentioning there are two things: the manager and the runtime. I'm not sure both are in http://bazaar.launchpad.net/~phablet-team/goget-ubuntu-touch/trunk/files
[20:24] <awe_> mhall119, see https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1324157
[20:24] <sergiusens> dpm: https://wiki.ubuntu.com/Touch/Emulator#Building_from_scratch
[20:24] <awe_> and more specifically bfiller's instructions at: https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1324157/comments/6
[20:25] <awe_> if you still can't get it to work, then please file a new bug and get me the "Provisioning line...", if that's not there, then just grab the output of /usr/share/ofono/scripts/list-modems
[20:26]  * awe_ notes this would be much easier with an open bug
[20:27] <dpm> sergiusens, oh, that's exactly what I needed, awesome. Do the instructions apply to both trusty and utopic?
[20:28] <sergiusens> dpm: yeah, awe_ and myself work from trusty while rsalveti does the same from utopic
[20:29] <sergiusens> dpm: only difference is the use of the gcc provided by ubuntu and the one provided in the android tree; just use the onein the android tree and you would be fine (selection is based on the ubuntu one being installed or not)
[20:29] <awe_> dev releases + native apple hw aren't always a pleasant experience
[20:30] <sergiusens> I run utopic on my devices only :-)
[20:30] <dpm> sergiusens, but I guess the build script does all the work, right? I can just point that person to the wiki page and these are all the instructions he needs? I'm guessing those build the "manager" part as well?
[20:31] <sergiusens> dpm: not the manager part; those are the two lines I sent before
[20:31] <sergiusens> we could probably add that there...
[20:37] <dpm> sergiusens, happy to add it. Something along these lines? -> https://wiki.ubuntu.com/Touch/Emulator?action=diff&rev2=59&rev1=58 I'm not sure what's needed to set up a go env, though. Could you clarify and I'll update the wiki?
[20:39] <sergiusens> dpm: sudo apt-get install golang-go
[20:39] <sergiusens> export GOPATH=$HOME/go
[20:39] <sergiusens> mkdir $GOPATH
[20:39] <sergiusens> export PATH=$PATH:$GOPATH/bin
[20:39] <sergiusens> that;s it
[20:40] <sergiusens> ah, you don't need to mkdir $GOPATH even I think
[20:44] <dpm> sergiusens, cool. Does that look ok to you now? -> https://wiki.ubuntu.com/Touch/Emulator#Building_from_scratch
[20:54] <sergiusens> dpm: it's fine
[20:54]  * sergiusens will bbl
[20:54] <dpm> cool, thanks
[21:16] <pmcgowan> Laney, do we need to fix this one soon? https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1330037
[22:50] <mterry> slangasek, you still around by any chance?  I was able to make a pam_extrausers, which works for normal passwd usage.  But I found out that "passwd -d USER" does *not* go through PAM but directly edits a hardcoded /etc/shadow path.  :(   Any recommendations there?
[22:58] <slangasek> mterry: so... do you have a spec somewhere for what all needs to be supported?  Maybe it's best if I have a look at the whole thing
[22:59] <slangasek> mterry: and then I can tell you what pieces will need changing to support it
[23:02] <mterry> slangasek, we want to support using passwd to change your user password and calling the AccountsService call that changes the "password mode" to none (and back) which ends up meaning being able to call "passwd -d USER" and optionally adding/removing from the nopasswdlogin group
[23:03] <slangasek> mterry: "using passwd" - please don't specify mechanics? :)
[23:03] <mterry> slangasek, well the end result is that I want to be able to change the user's password.  I believe the recommended way is via passwd.  That's what other pieces of our UI do that interact with changing user password
[23:04] <mterry> slangasek, i.e. using passwd with no arguments
[23:04] <slangasek> well, the recommended way is to implement pam calls directly
[23:04] <slangasek> but setting a null password is a special case, that's outside of pam
[23:04] <slangasek> (this is a detail of the shadow suite, not of pam)
[23:04] <mterry> slangasek, yeah, but that requires root access I believe.  Which is why most UI pieces go through passwd
[23:04] <slangasek> er, s/null/disabled/
[23:05] <slangasek> does 'passwd -d' work as a non-root user?  hmm
[23:05] <mterry> slangasek, no
[23:05] <mterry> slangasek, I was talking above about using pam calls directly to change password
[23:05] <mterry> slangasek, but users can call "passwd -d" via AccountsService, which will call it on their behalf
[23:06] <slangasek> right
[23:07] <slangasek> mterry: regardless, I don't believe your IRC one-liner could be the complete spec... and I don't know anything about AccountsService.  I'd like to know fully what the high-level requirements have been defined as
[23:07] <slangasek> separately from the interfaces that are currently used
[23:08] <mterry> slangasek, OK...  Well the highest-level requirement is "make https://wiki.ubuntu.com/SecurityAndPrivacySettings#Phone work"
[23:08] <slangasek> thanks, that's what I had in mind :)
[23:09] <mterry> slangasek, security team would like that to be done via real PAM password storage, as you can imagine.  :)
[23:09] <slangasek> well, I'm not sure why
[23:09] <mterry> slangasek, are you being sarcastic or sincere?
[23:09] <slangasek> sincere
[23:09] <slangasek> it's not configurable on a read-only phone image; and shares no code with the existing PAM modules
[23:10] <slangasek> so we should be careful not to require PAM if it's not actually a fit
[23:10] <mterry> slangasek, we originally had a demo version storing their password in plaintext in the user's home directory.  Then we were thinking of storing in that same file as a hash instead of plaintext as a further stop-gap, but security requested to use PAM
[23:10] <slangasek> (due to not being pluggable)
[23:10] <slangasek> ok
[23:10] <mterry> slangasek, eventually we do want Touch to be able to do multi-user goodness and all that
[23:11] <slangasek> so, "don't reimplement your own security-sensitive code from scratch" is a good guideline :)
[23:11] <slangasek> but in practice there's a lot that has to be reimplemented anyway, so it's possible PAM will help more than hinder
[23:11] <slangasek> anyway, let me have a look at this doc
[23:13] <mterry> slangasek, design (mpt) has requested that the no-password case is sincere (i.e. not just adding user to nopasswdlogin but then having them have to remember a password for further access) -- and security wanted to to disable adb / sudo in that case I believe.  So using "passwd -d" (which was already how AccountsService set "no password" mode anyway) seemed like a natural fit
[23:42] <mhall119> awe_: sergiusens: the only gprs file I found has this content: http://paste.ubuntu.com/7806270/
[23:42] <mhall119> from /var/lib/ofono/310410624173777/gprs
[23:42] <awe_> mhall119, that means that provisioning failed
[23:43] <awe_> you have an empty gprs context defined
[23:43] <mhall119> so you need that syslog line?
[23:43] <awe_> mhall119, did you open a bug?
[23:43] <awe_> mhall119, yes..
[23:43] <mhall119> awe_: not yet, sergiusens pointed me at https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1324157
[23:43] <awe_> so did I
[23:43] <awe_> specifically bfiller's comment
[23:43] <awe_> but it seems you've had a much earlier failuer
[23:43] <awe_> so there are no APNs provisioned at all
[23:44] <awe_> I mentioned in IRC earlier that the "Provisioning..." line from syslog would be extremely helpful, but if provisioning happened a long time ago, the syslog message could be gone
[23:45] <awe_> if so, then the output of /usr/share/ofono/scripts/list-modems will tell us what country code and network code are programmed for your SIM
[23:45] <mhall119> awe_: http://paste.ubuntu.com/7806297/ is from /usr/share/ofono/scripts/list-contexts
[23:45] <mhall119> http://paste.ubuntu.com/7806296/ is grepping for ofono in syslog
[23:46] <mhall119> mako, r133
[23:46] <awe_> so the line isn't present in syslog, which means your phone tried to provision awhile ago, and the log messages are gone
[23:46] <awe_> list-context just dumps what's in the gprs file
[23:46] <awe_> I need 'list-modems'
[23:48] <mhall119> awe_: http://paste.ubuntu.com/7806303/ is from list-modems
[23:51] <awe_> mhall119, so you're registered to the same AT&T network as I am
[23:52] <awe_> so the only way to recover right now is to:
[23:52] <awe_> 1) stop ofono
[23:52] <awe_> 2) delete the empty context in the gprs file
[23:52] <awe_> 3) start ofono
[23:52] <awe_> it should try to re-provision your phone, and you should the "Provisioning ... " log message
[23:53] <mhall119> awe_: I'm not sure if it matters, but I have 2 directorys in /var/lib/ofono
[23:53] <mhall119> 310410624173777  310410624173777-3
[23:53] <mhall119> -3 only has one file named version
[23:53] <awe_> nope, that's by design
[23:53] <mhall119> ok
[23:53] <awe_> sorry this is such a pain in the ass, but I've been asking for the APN settings UI since Jan
[23:54] <awe_> it's finally being worked on, and progress is being made
[23:54] <awe_> but until then, hand-editing is all we've got when things go bad
[23:54] <mhall119> ok, so delete the [context] section of the gprs file?
[23:54] <mhall119> [context1] I mean
[23:55] <awe_> exactly
[23:55] <awe_> as it's an empty placeholder created when provisioning fails
[23:55] <mhall119> I didn't see any "Provisioning..." message
[23:56] <mhall119> but I do have more contexts in the gprs file now
[23:56] <awe_> did you stop ofono first before editing, and then restart it?
[23:56] <mhall119> yes
[23:56] <awe_> can you do a pastebin of "grep ofono /var/log/syslog" again?
[23:57] <mhall119> http://paste.ubuntu.com/7806333/
[23:57] <awe_> Jul 16 19:55:23 ubuntu-phablet ofonod[5683]: Provisioning for MCC 310, MNC 410, SPN '(null)', IMSI '310410624173777', GID1 'FFFF'
[23:58] <awe_> looks like it worked this time around...   You should have the right APNs for Internet, however you may still need to follow the manual instructions for AT&T MMS per bfiller's instructions
[23:58] <mhall119> ok, I'll get somebody to try sending me an MMS first
[23:58] <mhall119> thanks awe_
[23:58] <awe_> yw