[19:01] <ubot5`> In #ubuntu-discuss, blackflow said: !next is <reply> Another satisfied customer leaves the building! Please come again!


[10:55] <mup> Issue operator#304 closed: Use git describe to log version when running from git <Created by chipaca> <Closed by chipaca> <https://github.com/canonical/operator/issues/304>
[10:55] <mup> PR operator#319 closed: ops: get version from git <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/319>
[10:59] <mup> Issue operator#309 closed: KeyError: 'JUJU_MODEL_NAME' while emitting event from Harness <Created by exceptorr> <Closed by chipaca> <https://github.com/canonical/operator/issues/309>
[11:05] <Chipaca> pjdc: 👋
[11:21] <facubatista> Muy buenos días a todos!
[11:21] <Chipaca> facubatista: 👋
[11:23] <facubatista> hola Chipaca
[11:26]  * Chipaca integrates https://jazzkeys.plan8.co/ into emacs
[11:27] <Chipaca> facubatista: https://jazzkeys.plan8.co/?msg=-M9IfwcZxxA0wD6iLmb1
[11:28] <facubatista> Chipaca, ja, nice!!
[11:29] <facubatista> I wonder how it be to really integrate it with the keyboard, maybe not with the editor, just at a system level
[11:31] <Chipaca> facubatista: snap install bucklespring
[11:34] <facubatista> it's a wonder how it's balanced across speakers :)
[11:34] <Chipaca> facubatista: you can adjust how "wide" that goes, as well
[11:34] <Chipaca> with headphones i find i need to set it to a lot less than the default for it to be reasonable
[11:34] <Chipaca> with speakers the default sounds 'right'
[11:35] <Chipaca> having written that, it's obvious why =)
[11:35] <facubatista> yes
[12:03] <facubatista> Chipaca, so, how we continue with that spec?
[12:08] <Chipaca> facubatista: let it prove for another day
[12:10] <facubatista> Chipaca, ack, let me know
[12:12] <Chipaca> facubatista: but AIUI we need to expand on the contents of charmcraft.yaml and give a go through a .charm contents in the concrete
[12:14] <jam> morning facubatista
[12:14] <facubatista> Chipaca, a) charmcraft.yaml is for the whole tool, not just build, we may write about it in a different doc, and point from this one?
[12:14] <facubatista> jam, hola!
[12:15] <Chipaca> jam: #320 gtg, #318 and #322 waiting for +1s
[12:15] <mup> PR #320: ops/framework.py: Move pickle into Storage <Created by jameinel> <https://github.com/canonical/operator/pull/320>
[12:15] <mup> PR #318: Simplified the CharmBase init signature <Created by facundobatista> <https://github.com/canonical/operator/pull/318>
[12:15] <mup> PR #322: log: set up sys.excepthook to log exceptions <Created by chipaca> <https://github.com/canonical/operator/pull/322>
[12:15]  * Chipaca the taskmaster
[12:15] <facubatista> Chipaca, b) you say to dump the content of a real .charm's tree there?
[12:16] <Chipaca> facubatista: and IIRC the build directory itself also (but that can wait until we've made it not be so symlinky)
[12:16] <Chipaca> (or pretend we've already done that :)
[12:17] <facubatista> Chipaca, we need to talk about that, I don't see the benefit of copying bytes
[12:18] <Chipaca> facubatista: ok
[12:18] <Chipaca> (i don't see the benefit of copying bytes either)
[12:18] <facubatista> (in this case in particular, copying bytes is a good thing in lot of places for this thingies called computers)
[12:18] <Chipaca> facubatista: the trick is always to copy as little as possible
[12:19] <Chipaca> 1/2 of all computer science treaties are about that
[12:19] <Chipaca> the other 3/4 are about estimation
[12:19] <facubatista> :)
[12:20] <facubatista> Chipaca, so, let's talk about symlinks! here? HO? later?
[12:22] <Chipaca> facubatista: here is fine
[12:22] <Chipaca> facubatista: so i'll start saying what I'd like
[12:22] <Chipaca> facubatista: then you tell me why i'm wrong
[12:23] <Chipaca> facubatista: I'd like build to do the equivalent of 'cp -al' of all the relevant bits, and then explicitly symlink things like hooks that we want to be symlinks, and then create the zip with the actual symlinks in it
[12:23] <facubatista> Chipaca, you're never wrong! you may not be as much right as I am
[12:24] <Chipaca> facubatista: I'd like build to create the venv outside of build (.venv maybe?) and the 'cp -al' it into build also, so it can be thrown away / recreated cheaply when not changed
[12:24] <Chipaca> facubatista: but this last thing is just optimization
[12:24]  * facubatista does `man cp` for first time in years
[12:24] <Chipaca> facubatista: hardlink files, create directories
[12:25] <Chipaca> facubatista: almost no byte copying :)
[12:27] <facubatista> Chipaca, let's leave the venv to a second phase of this talk
[12:27] <Chipaca> totes
[12:29] <facubatista> Chipaca, so, doing 'cp -al' is compared to 'symlinks' in: (let me finish)
[12:30] <facubatista> a) nicer, as it no create actual symlinks (hardlinks are cheap!)
[12:30] <facubatista> b) more work, as we need to actually do a lot of recursive work to create trees and all files inside those trees
[12:31] <facubatista> c) nicer, as we may get to have "actual symlinks" in the zip file
[12:31] <facubatista> Chipaca, is (c) the real benefit of your proposal here? is this what you're actually searching for?
[12:32] <Chipaca> d) nicer, as a developer looking into build/ will see something a lot closer to what they get from unzipping the charm
[12:32] <Chipaca> (c) and (d) are what i'm going for
[12:32] <Chipaca> (a), meh; (b), smop :-)
[12:34] <facubatista> Chipaca, ah, (d) convinced me
[12:36] <facubatista> Chipaca, I'm writing something, it may take me 5-10'
[12:49] <Chipaca> second monday of late standup, it throws me every time
[12:49]  * Chipaca gets tea
[12:52] <facubatista> Chipaca, what do you think? https://github.com/canonical/charmcraft/issues/29
[12:52] <facubatista> Chipaca, btw, would you close milestone 0.1.1? thanks
[14:28] <facubatista> Chipaca, let's talk about the venv?
[14:28] <Chipaca> veeeeeenv
[14:30] <Chipaca> facubatista: sorry my brain was momentarily taken over by zombies
[14:31] <Chipaca> facubatista: what do you want to talk about wrt venv?
[14:32] <facubatista> Chipaca, where it will be located
[14:32] <facubatista> the second phase of the talk we had before
[14:36] <Chipaca> facubatista: so, as per previous discussions, we want a way of not recreating the venv when it wouldn't change, right?
[14:36] <facubatista> Chipaca, yes
[14:36] <facubatista> Chipaca, I was thinking about using the hash of all requirements to check if we should or we shouldn't
[14:38] <facubatista> Chipaca, I like putting the venv inside the build directory, so we only "stain" one place
[14:39] <facubatista> Chipaca, we can not put that kind of dir in project's directory, as it may already have a .venv, or a .env, or a venv, etc
[14:40] <Chipaca> facubatista: but doesn't build start by nuking build/?
[14:40] <facubatista> Chipaca, I would change that, to probably start by nuking everything *but* the venv dir if we shouldn't
[14:48] <Chipaca> facubatista: so … what's the issue?
[14:49] <facubatista> Chipaca, before you wanted to put it outside... "I'd like build to create the venv outside of build"
[14:50] <Chipaca> facubatista: ¯\_(ツ)_/¯ details
[14:50] <Chipaca> facubatista: outside as in 'not nuked'; if you think it's easier / more foolproof to have it inside but not nuked, then, works for me
[14:55] <facubatista> Chipaca, perfect
[14:56] <Chipaca> siiigh. Changing 'fake_script' so that all scripts are python instead of bash triples the time our tests take to run
[15:00] <facubatista> Chipaca, what if we mock them?
[15:01] <Chipaca> facubatista: that's not very welcoming
[15:01] <facubatista> jaja
[15:02] <Chipaca> i'll be playing with different ways of doing it, later
[15:33] <Chipaca> jam: standup?
[16:05]  * facubatista -> lunch
[17:15] <mup> Issue operator#188 closed: Improve calling for Object descendant tree  <enhancement> <Created by facundobatista> <Closed by facundobatista> <https://github.com/canonical/operator/issues/188>
[17:15] <mup> PR operator#318 closed: Simplified the CharmBase init signature <Created by facundobatista> <Merged by facundobatista> <https://github.com/canonical/operator/pull/318>
[17:54] <mup> PR operator#320 closed: ops/framework.py: Move pickle into Storage <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/320>
[18:58] <mup> Issue operator#289 closed: hook exception logged at DEBUG <Created by jetpackdanger> <Closed by chipaca> <https://github.com/canonical/operator/issues/289>
[18:58] <mup> PR operator#322 closed: log: set up sys.excepthook to log exceptions <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/322>
[20:55]  * facubatista eods


[01:49] <TheMuso> bschaefer, bregma, is there any particular reason there is 2 separate private ExpanderView classes in dash/FilterExpanderLabel.cpp and unity-shared/SearchBar.cpp? I see a slight difference in FindAreaUnderMouse, so I would think this could be worked around.
[01:50] <TheMuso> bschaefer, bregma, I ask because I need to implement some a11y for the ExpanderView class in the searchbarcode to get at the filter results label properly."
[02:14] <bregma> TheMuso, I admit I have no idea, Trevinho might know best but he's not back until Wednesday I believe
[02:16] <TheMuso> bregma: Ok thanks.
[02:37] <bschaefer> i dont know either :(
[03:22] <TheMuso> Ok thanks guys, I'll poke Trevinho later this week.
[08:08] <tsdgeos> Mirv: ping
[08:24] <Mirv> tsdgeos: pong
[08:25] <tsdgeos> Mirv: i have a few patches more for the qtdbus thing that should help, can you rebuild the silo?
[08:25] <Mirv> tsdgeos: ok, sure.
[08:25] <tsdgeos> Mirv: http://paste.ubuntu.com/10710979/
[08:26] <Mirv> omg :) ok, starting to pull those.
[08:29] <Mirv> I wish there was an option besides "pull ongoing upstream development rewrite".. but as long as it works..
[08:45] <tsdgeos> Mirv: yeah :/
[08:49] <Mirv> tsdgeos: the patches need some rebasing for 5.4 but I survived the previous ones too. some objects/functions renamed.
[08:51] <tsdgeos> Mirv: ok, tell me if you need help
[10:02] <tsdgeos> dednick: how's the autopilot stuff going? i see  it's down to less failures, did you track down the issues with dragging?
[10:17] <dednick> tsdgeos: yeah. was down to the screen switching off when we locked the phone. We simulated it using uinput to press power button twice. But sometimes it would only press once, causing screen to remain off.
[10:19] <dednick> tsdgeos: i think creating the uinput device and using it immediately was the issue. I don't think udev picks up the create immediately, so the first press might be missed by mir input handler.
[10:19] <tsdgeos> dednick: so basically what my autopilot patch fixes?
[10:19] <dednick> tsdgeos: what fix?
[10:19] <tsdgeos> it's funny if i wanted to fix only the password -> assword usecase
[10:19] <tsdgeos> but it would fix the rest too
[10:19] <tsdgeos> dednick: the one you reviewed :D
[10:20] <dednick> tsdgeos: no, its different. doesnt use the keyboard
[10:20] <tsdgeos> ah
[10:20] <tsdgeos> ok
[10:20] <tsdgeos> but it's interesting
[10:20] <dednick> power button goes directly through udev
[10:20] <tsdgeos> because i remember the testcase also has something like pre-create uinput stuff
[10:20] <tsdgeos> dednick: ah it's us writing to udev direclty? not though autopilot?
[10:21] <dednick> tsdgeos: but yeah. might be the same issue
[10:21] <dednick> tsdgeos: well, it's autopilot-uinput
[10:21] <dednick> which creates a /dev/uinput device
[10:21] <tsdgeos> right
[10:21] <tsdgeos> but it's also precreated i think
[10:21] <tsdgeos> let me see
[10:22] <dednick> tsdgeos: it is in autopilot uinput, but not in our test
[10:22] <tsdgeos> ahh
[10:22] <tsdgeos> right
[10:22] <dednick> tsdgeos: the lock method is global
[10:22] <tsdgeos> so we do
[10:22] <tsdgeos> uinput = evdev.UInput(name='unity8-autopilot-power-button',
[10:22] <tsdgeos> 7	devnode='/dev/autopilot-uinput')
[10:22] <tsdgeos> in our own code
[10:22] <dednick> yeah, but we use it immediately
[10:22] <tsdgeos> correct
[10:22] <tsdgeos> that's bound to race like the thing i was fixing
[10:23] <dednick> ya. i'm considering putting in a global one somewhere if possible.
[10:23] <dednick> a pre-created one i mean
[10:25] <dednick> tsdgeos: I'll also see if i can write an AP test for the lock alone. so we can make sure it doesn't regress and cause this confusion issue again.
[10:26] <tsdgeos> cool :)
[10:26] <dednick> even though it probably belongs in unity-system-compositor.
[12:07] <mzanetti> dandrader, hmm... have you ever tried the unity-desktop-session-mir?
[12:08] <dandrader> mzanetti, I don't think so
[12:08] <mzanetti> dandrader, looks like the patch with the surface focusing broke that
[12:18] <Mirv> mmh, that QDBusUtil::dbusService
[12:19] <mzanetti> anyone knows how to disable the edges intro?
[12:19] <mzanetti> I tried this
[12:19] <mzanetti> dbus-send --system --print-reply --dest=com.canonical.PropertyService /com/canonical/PropertyService com.canonical.PropertyService.SetProperty string:edge boolean:false
[12:19] <mzanetti> but doesn't seem to change anything
[12:20] <mzanetti> Saviq, ^
[12:20] <Mirv> mzanetti: sudo -S dbus-send --system --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User32011 org.freedesktop.DBus.Properties.Set string:com.canonical.unity.AccountsService string:demo-edges variant:boolean:false ?
[12:20] <mzanetti> vesar, ^
[12:21] <mzanetti> Mirv, well, on desktop that is
[12:21] <mzanetti> but I'll try
[12:21] <Mirv> oh, that's indeed for phone
[12:21] <Mirv> worth trying
[12:21] <Mirv> well, not worth with User32011 probably...
[12:21] <mzanetti> yeah changing "user32011" to user1000 should do
[12:22] <mzanetti> whoever came up with that dbus-send syntax...
[12:22] <mzanetti> seriously...
[12:22] <Mirv> :D
[12:22] <Mirv> mzanetti: indeed, it should be inline xml!
[12:23] <mzanetti> vesar, try this:
[12:23] <Mirv> the longer the line the more professional it looks
[12:23] <mzanetti> sudo -S dbus-send --system --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User1000 org.freedesktop.DBus.Properties.Set string:com.canonical.unity.AccountsService string:demo-edges variant:boolean:false
[12:23] <mzanetti> Mirv, I wonder why phablet-config does that on com.canonical.PropertyService, not on AccountsService
[12:24] <mzanetti> vesar_, try this:
[12:24] <mzanetti> sudo -S dbus-send --system --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User1000 org.freedesktop.DBus.Properties.Set string:com.canonical.unity.AccountsService string:demo-edges variant:boolean:false
[12:25] <Mirv> mzanetti: these are mostly pieces of wisdoms that spread by copy-pasting around.. and people don't feel ownership of phablet-tools
[12:30] <vesar> Mir, mzanetti: oh boy. That worked!
[12:30] <mzanetti> cool
[12:30] <vesar> Mirv, ^
[12:30] <mzanetti> thanks Mirv
[12:31] <vesar> Thanks guys
[12:42] <Mirv> no problem, great that there's something that works. I think my last unity8 on desktop tryout stopped at the same problem.
[12:47] <tsdgeos> Mirv: do you have an eta for the new qt with the patches? or may be worth me compiling it myself so i can keep trying?
[12:53] <Saviq> mzanetti, the User1000 bit is because you're talking to the system dbus so you need to identify the user on whose behalf you want this change
[12:53] <mzanetti> sure
[12:53] <mzanetti> I was more wondering why the phablet-config tool seems to set something on PropertyService instead of AccountsService
[12:54] <Saviq> mterry should know, but ultimately I imagine PropertyService is just another entry point to AccountsService
[12:55] <mzanetti> yeah, would make sense
[12:55] <mzanetti> anyhow. problem solved by now
[12:56] <Mirv> tsdgeos: still building locally as I combined an upload seb is currently doing plus the DBus patches needed some more fixing (all QDBusUtil::dbusService -> dbusServiceString() etc). I will push it once it builds. if you want to test on your own, this is what I'm currently building http://paste.ubuntu.com/10711883/ (applies on top of lp:~kubuntu-packagers/kubuntu-packaging/qtbase-opensource-src)
[12:58] <tsdgeos> oki
[12:59] <tsdgeos> maybe helps if i build locally to speed up testing in case something explodes
[12:59] <Mirv> tsdgeos: it seems my local build is pass the build phase, in unit tests, so I'll push a test build to the PPA now
[13:01] <Mirv> amd64 build will take 2h 23min based on previous ppa build
[13:05] <kgunn> ChrisTownsend: hey is unity8-desktop-session-mir working ok ?
[13:05]  * kgunn hadn't had time to check
[13:06] <ChrisTownsend> kgunn: As far as I know.  I've been out since middle of last week, so I'm updating system right now and will try.
[13:06] <kgunn> cool
[13:06] <kgunn> will be good to hear
[13:06] <ChrisTownsend> kgunn: I know the unity8-lxc stuff is busted right now with the transition to systemd.
[13:06] <kgunn> mzanetti: ^
[13:07] <mzanetti> ack
[13:09] <ChrisTownsend> kgunn: mzanetti: Yeah, I can log into a Unity8 session w/ fully updated 15.04 system.
[13:09] <mzanetti> ChrisTownsend, does focusing different windows and typing with the keyboard work for you?
[13:11] <ChrisTownsend> mzanetti: No, that seems broken.  I tried "Search" in System Settings and nothing.
[13:11] <mzanetti> yeah, same for me
[14:15] <tsdgeos> Mirv: looking good, my self compiled stuff ran the calculator autopilot fine twice in a row
[14:16] <Saviq> did you backport half of Qt 5.6 already? ;)
[14:17] <tsdgeos> shhhh
[14:17] <tsdgeos> i haven't even started the talks for the async image provider
[14:17] <davidcalle> sil2100, ping
[14:19] <sil2100> davidcalle: pong
[14:19] <sil2100> (in a meeting)
[14:20] <davidcalle> sil2100, nevermind (for now :) )
[14:40] <tsdgeos> dednick: maybe instead of that sleep 1, you can create the device in the constructor of the test?
[14:40] <tsdgeos> or yeah not fake the keypress can work too
[14:49] <dednick> tsdgeos: ya. i did already
[14:49] <tsdgeos> cool
[14:50] <ChrisTownsend> Regarding the Wizard, what other conditions would cause it to run even if '~/.config/ubuntu-system-settings/wizard-has-run' exists?
[14:51] <tsdgeos> dednick: any clue what happened with with last CI run?
[14:52] <tsdgeos> ChrisTownsend: just to make sure, you mean the wizard and not the edge tutorial, right?
[14:53] <ChrisTownsend> tsdgeos: Sorry, I mean the edge tutorial.  This is in a desktop session.
[14:53] <tsdgeos> ChrisTownsend: https://code.launchpad.net/~mterry/unity8/tutorial-reappears/+merge/254263 helps?
[14:54] <ChrisTownsend> tsdgeos: I'll take a look at that.  Thanks!
[14:55] <tsdgeos> ChrisTownsend: and then there's also https://code.launchpad.net/~mterry/unity8/skip-spread-tutorial-on-desktop/+merge/253866 you may be interested in
[14:55] <tsdgeos> since it's desktop+tutorial related too
[14:56] <tsdgeos> Mirv: Ran 122 tests in 2296.058s OK
[14:56] <tsdgeos> :)
[14:56] <tsdgeos> i'll stop now and wait for the real thing on the ppa
[14:57] <ChrisTownsend> tsdgeos: Oh cool, thanks!
[15:23] <mzanetti> Saviq, I'm kicking a build of silo25. I need packages of one of the branches in there
[15:23] <Saviq> mzanetti, sure, was about to do that too
[15:25] <ChrisTownsend> What makes the edge tutorial run?  On unity8-desktop-session-mir, the tutorial doesn't run, so is there a trick to keep it from running?
[15:25] <Saviq> ChrisTownsend, it does run there, people have been complaining that they can't get through the right edge bit
[15:26] <Saviq> AccountsService.demoEdges is the only bit we're looking at whether to run it or not
[15:26] <ChrisTownsend> Saviq: Hmm, I don't see it run when I run from that.  Only when I'm running from the Ubuntu Next ISO.
[15:27] <Saviq> ChrisTownsend, any chance you completed it once already?
[15:28] <Saviq> dbus-send --system --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User1000 org.freedesktop.DBus.Properties.Get string:com.canonical.unity.AccountsService string:demo-edges
[15:28] <ChrisTownsend> Saviq: It's quite possible I did some time ago, I just don't remember.
[15:29] <ChrisTownsend> Saviq: Yeah, that's set to false.
[15:29] <tsdgeos> mterry: about https://code.launchpad.net/~mterry/unity8/tutorial-reappears/+merge/254263 may it be because you're seeing is delayed garbage collection?
[15:29] <Saviq> dbus-send --system --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User1000 org.freedesktop.DBus.Properties.Set string:com.canonical.unity.AccountsService string:demo-edges variant:boolean:true
[15:29] <Saviq> ChrisTownsend, ↑ this would bring it back
[15:29] <ChrisTownsend> Saviq: I could also set that to false using dbus-send and then bypass the tutorial, right?
[15:30] <ChrisTownsend> Saviq: I want it false:)
[15:30] <Saviq> ChrisTownsend, sure, totally
[15:30] <ChrisTownsend> Saviq: Cool, thanks!
[15:30] <tsdgeos> mterry: and maybe qmltestrunner has/hits different garbage collection patterns?
[15:30] <mterry> tsdgeos, yeah...  I guess?  Like really delayed.  Many seconds
[15:31] <mterry> tsdgeos, because when you hit this bug, you can go through the tutorial several times
[15:31] <mterry> tsdgeos, so it's really taking its sweet time cleaning that up
[15:31] <tsdgeos> or it's a bug :D
[15:31] <mterry> tsdgeos, I just couldn't figure out why I was seeing different behavior (like what might trigger the bug)
[15:32] <ChrisTownsend> Saviq: I think I'll add that dbus trick to the bug report to help folks get through this for the time being.
[15:32] <tsdgeos> mterry: question is, think is something we should spend time investigating deeper or just approve your code and be done with it?
[15:32] <Saviq> ChrisTownsend, good idea, mention that the 1000 there is UID
[15:32] <mterry> tsdgeos, yeah that's where I was  :)
[15:32] <ChrisTownsend> Saviq: Right, I'll make that clear.
[15:33] <ChrisTownsend> Saviq: Probably just use $UID instead of 1000.
[15:34] <Saviq> ChrisTownsend, unless they run it from under a different user ;)
[15:34] <ChrisTownsend> Saviq: True dat
[15:34] <tsdgeos> mterry: not sure what you mean with that
[15:35] <mterry> tsdgeos, I just meant, I had arrived at the point of not caring about the root cause anymore, and was willing to submit an MP for the "good enough" workaround
[15:35] <tsdgeos> ok
[15:35] <tsdgeos> mterry: we have simpler code otoh so seems like a win
[15:35] <tsdgeos> i'll review
[15:36] <mterry> tsdgeos, yeah, truthfully, this could have just been cleanup from the refactor, even without the bug
[15:53] <tsdgeos> mterry: garg
[15:53] <tsdgeos> i can't test that bug
[15:53] <mterry> tsdgeos, you can't even reproduce it now?
[15:53] <tsdgeos> since i need to unlock my sim
[15:53] <tsdgeos> which obviously i can't do on the wizard
[15:53] <tsdgeos> i guess i can use my other phone to remove the pin lock from my sim
[15:53] <tsdgeos> think that's not supported yet from the Ubuntu Phone
[15:54] <tsdgeos> or is it?
[15:54]  * tsdgeos checks
[15:55] <tsdgeos> doesn't look like it
[15:55] <tsdgeos> seb128: would you know if the settings app lets you set a new sim pin?
[15:56] <seb128> tsdgeos, I'm not sure, jgdx or kenvandine would know for sure, ask on #ubuntu-touch?