[02:10] <mup> PR snapcraft#2418 closed: Release changelog for 3.0.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2418>
[06:11] <mborzecki> morning
[06:27] <zyga> Hi
[06:57] <mborzecki> zyga: hey
[07:07] <zyga> Hej
[07:07] <zyga> Breakfasting
[07:07] <zyga> I sent a PR last night
[07:08] <zyga> Fixing leap issues
[07:08] <zyga> I will make a small variant for 2.36
[07:46] <mvo> good morning! it looks like the tests in 6243 got restarted, did we see any trace of the protocol error in the last run?
[07:48] <mvo> looks like the current run was good, I do another one now
[07:50] <mborzecki> mvo: i restarted them twice already, first time failed in prepare of juju observe test (unrelated), next failure was centos mirrors being flaky
[07:51] <mvo> mborzecki: heh
[07:51] <mvo> mborzecki: ok, it had one green now and I just triggered it again (via rename of GIL->GML)
[07:57] <mborzecki> super simple review #6241
[07:57] <mup> PR #6241: tests/main/parallel-install-store: verify installation of more than one instance at a time <Parallel installs ⛓> <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6241>
[07:58] <pstolowski> mornings
[08:01] <zyga> Back from walk
[08:01] <zyga> Brrrr
[08:01] <zyga> Though I really like it when winter makes everything dry
[08:02] <zyga> Hey mvo
[08:02] <zyga> I will be around shortly
[08:03] <mvo> zyga: hey, no worries
[08:03] <mvo> zyga: all is looking great, I'm in a very good mood, PRs look super interessting
[08:03] <zyga> I posted the leap fix last night
[08:03] <zyga> Just the master version
[08:04] <zyga> 2.36 will be microscopic
[08:04] <zyga> Master has a cleanup as well
[08:04] <mvo> zyga: aha, even better
[08:28] <pedronis> mborzecki: I put a question in #6079
[08:28] <mup> PR #6079: [RFC] `snap connections` command <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6079>
[08:29] <mup> PR snapd#6234 closed: overlord: don't write system key if security setup fails (2.36) <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6234>
[08:33] <mborzecki> pedronis: thanks, finishing up with snapd update for arch now, will lack at your review in a bit
[08:41] <mup> PR snapd#6221 closed: interfaces: return security setup errors (2.36) <⛔ Blocked> <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6221>
[08:46] <zyga> mvo: https://github.com/snapcore/snapd/pull/6245
[08:46] <mup> PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6245>
[08:46] <zyga> it won't pass entirely
[08:47] <zyga> after that there will be only one small patch that makes apparmor-parser errors really reported and 2.36 is green
[08:47] <zyga> similar to the one you closed above in 6221
[08:47] <mup> PR snapd#6245 opened: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6245>
[08:47] <zyga> if you want I can add it here
[08:50] <pstolowski> mvo: that case you found with brave install & removal sequence is amazing; it really has to involve all the three ops, just installing the instance and removing it (2 ops) is not enough
[08:55] <mvo> pstolowski: yeah, I found this too, its interessting
[08:56] <mvo> zyga: it sounds like like it can be added to 6245 if its small
[08:56] <zyga> mvo: yes, and one will not pass without the other
[08:56] <zyga> I'll do just that
[08:56] <zyga> mvo: thank you for merging the 2.36 fix even though it was not passing
[08:57] <zyga> pstolowski, mvo: what's the special case with brave?
[08:57] <pstolowski> zyga: sudo snap install brave && sudo snap install brave_test && sudo snap remove brave brave_test
[08:57] <pstolowski> zyga: (with instances feature on)
[08:57] <zyga> mhm
[08:57] <pedronis> pstolowski: hi, do we have developer docs for interface hooks?
[08:58] <pstolowski> zyga: results in a bunch of conflicts and retries on the last step, take a good while to finish
[08:58] <pedronis> pstolowski: conflicts on what?
[08:59] <pstolowski> pedronis: yes, they were written a couple of weeks ago
[08:59] <pstolowski> pedronis: conflicts on disconnects on removal (last op)
[08:59] <pedronis> I see
[09:00] <pedronis> pstolowski: I suppose at this point they are expected, no? we'll need to step back to improve that? or is there a low hanging fruit?
[09:01] <pstolowski> pedronis: yes, we expect it, but mvo observed a noticable slowdown with edge (which i can confirm)
[09:02] <pedronis> ok
[09:02] <pstolowski> pedronis: it was noticed ~last week
[09:02] <pstolowski> pedronis: and again, it completes and work, is just slow
[09:03] <pedronis> pstolowski: any candidate on why? feel free to dig a bit when you have a bit of time
[09:05] <pstolowski> pedronis: yeah i'm on, investigating, don't know yet
[09:10] <mborzecki> hmm no smart way of reloading snap-confine aa profile on arch when installing/updating snapd, i expect people to run into problems with snap-confine
[09:10] <zyga> oh
[09:10] <zyga> can we do that ourselves?
[09:10] <zyga> in the package file?
[09:11] <mborzecki> zyga: i can, but it's unclear whether i should, you know, the unwritten policy of doing nothing :)
[09:11] <zyga> hehe
[09:11] <zyga> does that also apply to libc breaking people on upgrades?
[09:11] <zyga> is there any limit?
[09:11] <mborzecki> hahah, it's /r/archlinux, or bbs.archlinux.org or just archlinux.org main page with 'manual steps needed' memo
[09:12] <zyga>  /o\
[09:12] <mborzecki> though i don't recall any major screwups for years now
[09:12]  * zyga is happy with opensuse :)
[09:13] <mborzecki> i mean, surprisingly, it just works
[09:19] <mborzecki> does it make sense to request snapd restart on a classic system where reexec is not supported?
[09:19] <zyga> mmm
[09:20] <zyga> probably not
[09:20] <mborzecki> that's what happens on arch, fedora and prooably opensuse too
[09:21] <zyga> morning Chipaca
[09:21] <Chipaca> morning
[09:21] <mborzecki> this basically https://paste.ubuntu.com/p/xRnrQMNTH8/
[09:21] <mborzecki> Chipaca: morning, sir
[09:21] <pedronis> Chipaca: hi
[09:22] <Chipaca> 'sup
[09:24] <pedronis> mborzecki: hi, you have various things under review, but no current task that isn't blocked on feedback? is that true?
[09:26] <mborzecki> pedronis: i'm addressing feedback on the PRs and chopping selinux branch up to pull out the bits that aren't strictly related (mostly tests)
[09:27] <pedronis> mborzecki: ah ok, so you are not blocked atm?
[09:27] <pedronis> Chipaca: did you see https://github.com/snapcore/snapd/pull/6236#discussion_r237451827 ?
[09:27] <mup> PR #6236: Staticcheck fixes <Created by chipaca> <https://github.com/snapcore/snapd/pull/6236>
[09:27] <mborzecki> pedronis: no
[09:27] <Chipaca> pedronis: I did
[09:27] <Chipaca> I'm assuming it's technically correct
[09:28] <Chipaca> in practice, not sure how important it is :-)
[09:30] <pedronis> Chipaca: ?
[09:30]  * pedronis is probably missing something
[09:30] <Chipaca> pedronis: the current regep means we won't run staticcheck on ".0" releases
[09:31] <Chipaca> because go doesn't do .0, instead just does ""
[09:31] <Chipaca> apparently
[09:31] <pedronis> Chipaca: not sure why you say is not important? having a test that doesn't run for a while
[09:31] <pedronis> and then again
[09:32] <pedronis> is usually source of confusion
[09:32] <pedronis> of which if have enough I think
[09:32] <pedronis> s/if/we/
[09:33] <pedronis> Chipaca: or you thinking that .0 never makes it into Ubuntu anyway?
[09:33] <Chipaca> I'll fix it (not that way though)
[09:33] <pedronis> anyway changing it is likely quicker than this silly discussion :)
[09:33] <Chipaca> but, i'm worried that already 1.11 is breaking things for us
[09:34] <Chipaca> wonder what 1.12 will bring
[09:34] <Chipaca> and then there's go 2
[09:34] <pedronis> one thing at a time
[09:35] <Chipaca> pedronis: did you see"go 2 considered harmful"?
[09:35] <Chipaca> https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf
[09:35]  * Chipaca grins
[09:36] <pedronis> no
[09:36] <zyga> lol
[09:37] <Chipaca> changing subjects, I pushed a little "make snapd start faster" pr after talking with cachio yesterday
[09:37] <Chipaca> and mvo fixed the spread tests (thanks mvo!)
[09:37] <Chipaca> and now it's so fast, systemd freaks out :-/
[09:38] <pedronis> I saw it
[09:38] <pedronis> ah
[09:38] <Chipaca> :-)
[09:38] <pedronis> no good deed goes unpunished
[09:38] <Chipaca> bah, it might be something else
[09:38] <Chipaca> i need to dig
[09:38] <Chipaca> but
[09:38] <Chipaca> Job for snapd.service failed because start of the service was attempted too often. See "systemctl status snapd.service" and "journalctl -xe" for details.
[09:38] <Chipaca> that thing :)
[09:38] <pedronis> Chipaca: let's try to merge 6192 first
[09:38] <Chipaca> ok
[09:39]  * Chipaca looks at what's missing there
[09:39] <pedronis> couple of minors there, and it needs a 2nd review (I cannot review twice)
[09:44] <Chipaca> pedronis: looking at the revision of the local snap would split error messages even more though
[09:44] <Chipaca> i mean, either snap could be local
[09:47]  * Chipaca gives it a stab
[09:47] <pedronis> Chipaca: ?
[09:47] <Chipaca> pedronis: your suggestion to, in the local case, say "current local"
[09:47] <pedronis> yes
[09:47] <Chipaca> pedronis: is about the current snap
[09:48] <Chipaca> pedronis: the revision we talk about in the error messages so far is about the new snap
[09:48] <Saviq> cachio: oh seems it worked this time: https://travis-ci.org/MirServer/mir/jobs/461685223
[09:48] <pedronis> Chipaca: let me look
[09:48] <pedronis> I might be very confused
[09:49] <Chipaca> pedronis: unless you meant to always say "current local", as in that-which-is-locally-current
[09:49] <Chipaca> and not as in that-which-is-locally-current-and-has-a-revision-that-is-local
[09:50] <pedronis> Chipaca: I see, I'm confused
[09:50] <pedronis> but something is off either way
[09:50] <Chipaca> hello confused i'm dad
[09:51] <pedronis> Chipaca: so we are looking at snapInfo revision
[09:51] <pedronis> great
[09:51] <pedronis> except that calling a local installed snap new revision in the 2nd message
[09:51] <Chipaca> i could've caled them newInfo and curInfo instead of snapInfo and curInfo  i guess
[09:51] <pedronis> is confusing and what threw me off
[09:52]  * Chipaca looks
[09:52] <pedronis> Chipaca: if I do snap install --dangerous foo.snap
[09:52] <pedronis> calling the incoming thing new revision
[09:52] <pedronis> is confusing
[09:52] <Chipaca> aha
[09:52] <pedronis> (tough technically correct)
[09:52] <Chipaca> i'll happily drop in any other noun :-)
[09:53] <Chipaca> I might even drop in a verb if i'm in a hurry
[09:54] <Chipaca> pedronis: I mean: «cannot refresh "foo" because [this new thing]  has epoch 123 that can't read [the old thing]'s epoch of 0»
[09:55] <pedronis> Chipaca: "new epoch %s being locally installed"  would be the verbose thing
[09:57] <Chipaca> «cannot refresh "foo" because new epoch 123 being locally installed can't read [...]»?
[09:57] <pedronis> yes
[09:57] <Chipaca> that's confusing to read
[09:57] <pedronis> I'm happy to suggestion, the current error confused me though, so we need to do better
[09:58] <Chipaca> so, it can be a try or a --dangerous
[09:58] <pedronis> yes
[09:59] <pedronis> cannot refresh "foo" with local snap because its epoch ...?
[10:00] <Chipaca> «cannot refresh "foo" because the one you're trying to install has epoch [...]»
[10:00] <Chipaca> ?
[10:00] <Chipaca> hm
[10:01] <pedronis> cannot refresh "foo" with local snap with epoch %s ... ?
[10:01] <Chipaca> cannto refresh "foo" to local snap with epoch...?
[10:02] <pedronis> that also work
[10:02] <pedronis> s
[10:02] <Chipaca> good, let me write it out in full just in case
[10:03] <Chipaca> cannot refresh %q to local snap with epoch %s, because that can't read current revision's epoch of %s
[10:03] <Chipaca> or maybe change the that to an it
[10:03] <Chipaca> cannot refresh %q to local snap with epoch %s, because it can't read current revision's epoch of %s
[10:03] <Chipaca> bah, that "revision's" there is noise
[10:03] <Chipaca> noise][1: no offence
[10:04] <pedronis> can be dropped I suppose
[10:04] <Chipaca> cannot refresh %q to local snap with epoch %s, because it can't read the current epoch of %s
[10:04] <mborzecki> snap install hello-world does-not-exist, giving 'error: store.SnapNotFound with 2 snaps' is not super user friendly
[10:04] <pedronis> mborzecki: my PR will fix it
[10:04] <mborzecki> pedronis: ack
[10:04] <Chipaca> mborzecki: i disagree, it's super friendly. You're just not its friend.
[10:04] <pedronis> I'm actually hoping to get to it today
[10:06] <mborzecki> Chipaca: hehe :P didn't bother me until yesterday i didn't notice a typo in snap name i tried to install and ended up going through snapd code to figure it out
[10:07] <Chipaca> mborzecki: tbf that error means there's a bug, it's meant as an error for us and not for users
[10:08] <mborzecki> we're lucky then that users install snaps one by one
[10:08] <mborzecki> but it did give me a bit of panic yesterday when 'snap install hello-world_foo hell-world_bar' didn't work :/
[10:09] <pedronis> Chipaca: there's two part of the code that make different assumptions, anyway #5712 should stop that afaiu
[10:09] <mup> PR #5712: overlord: make InstallMany work like UpdateMany, issuing a single request to get candidates <Reviewed> <⛔ Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5712>
[10:09] <Chipaca> pedronis: 🖒
[10:14] <pedronis> Chipaca: we probably should drop revision's alos in the other one, current epoch alone seems ok, no?
[10:15] <Chipaca> pedronis: heh
[10:15] <pedronis> given also that it might be local or not in its own
[10:15] <Chipaca> 	return fmt.Errorf("cannot refresh %q to %s with epoch %s, because it can't read the current epoch of %s", snapInfo.InstanceName(), desc, snapInfo.Epoch, curInfo.Epoch)
[10:15] <Chipaca> ^ current code
[10:15] <Chipaca> where desc is "local snap" or "new revision %s"
[10:15] <pedronis> sounds good
[10:16] <pedronis> Chipaca: we get the {}  notation right if the epoch is complicated ?
[10:16] <Chipaca> yes
[10:17] <pedronis> that's fine for now
[10:17] <pstolowski> mvo, pedronis ok, i understood the problem with slowness on brave+brave_test install+remove. perhaps HO would be fastest to explain if you have a few minutes
[10:17] <Chipaca> for now it's the json one
[10:17] <Chipaca> although from using it, just {[],[]} might be enough
[10:18] <Chipaca> (as opposed to {"read":[],"write":[]} )
[10:18] <pedronis> pstolowski: I'm available in a couple of minutes
[10:19] <pstolowski> pedronis: ok, ping me then (mvo feel free to skip it)
[10:22] <Chipaca> silly Go, not telling that when I write lcoal I mean local
[10:23] <pedronis> pstolowski: ready now, in the standup
[10:23] <pstolowski> pedronis: ok coming
[10:24] <mborzecki> another thing we maybe could improve, when installing a snap that pulls in a content snap, the prompt will stay on 'Automatically connect eligible ..' for a long time, while the content snap is downloading
[10:45] <zyga> mvo: https://github.com/snapcore/snapd/pull/6245 needs a review
[10:45] <mup> PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6245>
[11:03] <zyga> pstolowski: reading https://github.com/snapcore/snapd/pull/6180
[11:03] <mup> PR #6180: snap/info: bind global plugs/slots to implicit hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6180>
[11:04] <pstolowski> zyga: thanks!
[11:08] <pedronis> mvo: zyga: Chipaca: I'll be late for standup, I posted a forum message to the team about this
[11:08] <zyga> thank you
[11:09] <mvo> pedronis: thank you
[11:09] <mvo> pstolowski: sorry, was away but I take it you clarified this?
[11:10] <pstolowski> mvo: yep, no worries
[11:10] <mvo> zyga: I do a new round of review now
[11:10] <zyga> thank you
[11:10] <Chipaca> the local authority has finally (nearly 12 months later!) come to a decision about the boys' school \o/
[11:10] <zyga> I'm not feeling well, sorry about being very slow today
[11:10] <Chipaca> … so I might miss the standup entirely today
[11:10] <mvo> zyga: no worries
[11:10]  * Chipaca hugs zyga
[11:10] <mvo> Chipaca: good news! (about the boys - not that you miss the standup ;)
[11:10] <Chipaca> but … from far away just in case it's cooties
[11:11]  * mvo hugs zyga as well
[11:11] <zyga> just cold, nothing fancy :)
[11:11] <zyga> I'll be allright
[11:11] <pedronis> Chipaca: ok
[11:13] <pstolowski> pedronis: retry mechanism seems to work *most of the time*, but there is something fishy there, *sometimes* it doesn't pick any other task until retry time of previous one is reached - see the proof with some extra debug https://pastebin.ubuntu.com/p/TYMffsdTQX/
[11:15] <cachio> Chipaca, nice, I'll try it
[11:15] <cachio> thanks
[11:16] <cachio> Saviq, nice
[11:16] <cachio> please let me know if we need any change to that image
[11:17] <pedronis> pstolowski: that seems strange, we are missing something, I suppose some prints in the taskrunner might help
[11:18] <cachio> Chipaca, which is the PR number?
[11:18] <pedronis> #6192  needs a 2nd review
[11:18] <mup> PR #6192: overlord/snapstate: on refresh, check new rev can read current <Created by chipaca> <https://github.com/snapcore/snapd/pull/6192>
[11:18] <pstolowski> pedronis: yep
[11:19] <Chipaca> cachio: #6242
[11:19] <mup> PR #6242: overlord/snapstate: use file timestamp to initialize timer <Created by chipaca> <https://github.com/snapcore/snapd/pull/6242>
[11:19] <pedronis> degville: might you could look quickly at the new errors in #6192, if you have some feedback on them
[11:20] <pedronis> notice that in most sitation the store should avoid us hitting them tough
[11:20] <pedronis> they are more relevant for local development using try or local installs
[11:20] <mborzecki> zyga: did you mean to open #6245 with target set to release/2.36? it's targeting master now
[11:20] <mup> PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6245>
[11:20] <zyga> ooh
[11:20] <zyga> shit :)
[11:20] <zyga> yes
[11:21] <zyga> fixed
[11:21] <zyga> this version is for the stable release
[11:21] <zyga> I was surprised it passed alone
[11:21] <mvo> heh, same here
[11:21] <mvo> (also surprised)
[11:22] <pedronis> degville: thanks for https://forum.snapcraft.io/t/the-docs-roadmap/8763
[11:22] <Chipaca> cachio: the problem is nfs-support restarts snapd 11 times :-)
[11:22] <Chipaca> cachio: and it's fast enough for that to be a problem now
[11:22] <Chipaca> cachio: I'm fixing
[11:23] <cachio> Chipaca, nice, thanks for that !!!
[11:24] <mvo> 5845 is ready for a second review
[11:24] <degville> no problem.
[11:24]  * pedronis can't type today
[11:26] <mup> PR snapd#6241 closed: tests/main/parallel-install-store: verify installation of more than one instance at a time <Parallel installs ⛓> <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6241>
[11:28] <mborzecki> mup: kicked off another spread run in #6243
[11:28] <mup> mborzecki: In-com-pre-hen-si-ble-ness.
[11:28] <mborzecki> mvp: kicked off another spread run in #6243
[11:28] <mborzecki> mvo: kicked off another spread run in #6243
[11:28] <mup> PR #6243: systemd: allow only a single daemon-reload at the same time <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6243>
[11:29] <mvo> mborzecki: thanks, I run this now also locally against google:ubuntu-18.04-64, so far no issues, lets see
[11:31] <Chipaca> actually, i wonder if systemd seeing the restarts as problematic are because we don't exit from the main loop properly
[11:31]  * Chipaca digs
[11:32] <Chipaca> could I get a second review of #6236? it's got a minor fix pending (in a Suggestion already) but I'd rather not re-trigger a travis just for that unless it's the only thing left
[11:32] <mup> PR #6236: Staticcheck fixes <Created by chipaca> <https://github.com/snapcore/snapd/pull/6236>
[11:32] <Chipaca> jamesh: I am keeping your user session pr in mind, have not finished the review yet though
[11:32] <mvo> Chipaca: I have it on my list, hope to get to it before lunch
[11:33] <Chipaca> mvo: excellent thanks
[11:41] <zyga> mvo: https://github.com/snapcore/snapd/pull/6245 is green!
[11:41] <mup> PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6245>
[11:41] <zyga> that's lucky
[11:52] <Chipaca> mvo: looks like we dropped the ball on https://forum.snapcraft.io/t/anything-changed-around-snapcraft-yaml-gpio-interface-for-2-36/7852/4 (unless there was more communication out of band)
[11:54] <zyga> moar fire
[11:55] <Chipaca> toasty
[11:56] <zyga> pretty please review on 6245
[11:56] <Chipaca> sir yes sir
[11:57] <zyga> thank you, that's almost all needed to make 2.36 green again
[11:57] <mvo> Chipaca: I think we fixed this but we did not communicate this well :(/
[11:57] <mvo> Chipaca: I need to look what PR fixed it, don't quite remember offhand
[11:57] <zyga> mvo: is is in 2.36.x ?
[11:57] <jamesh> Chipaca: thanks.
[11:57] <zyga> maybe we need a .3
[11:57] <mvo> zyga: I think so
[11:57] <mvo> zyga: oh, why .3? what is missing?
[11:57] <zyga> I mean, if this is not in stable
[11:57] <zyga> but in 2.37 / beta only
[11:58] <zyga> but no need otherwise
[11:58] <Chipaca> don't propose a new .X on the eve of a sprint dude, that's just mean
[11:58] <Chipaca> you need to do it the monday of the sprint and write a CVE, that's the sporting way
[11:58] <mvo> Chipaca: *wahhhhh*
[11:58]  * mvo runs away screaming
[11:58] <zyga> HAHHAHA
[11:59]  * Chipaca 's job is done
[11:59] <zyga> Chipaca: make sure to msg mvo on his cell at 23:00 on sunday ;)
[11:59] <zyga> PLANES FALLING OFF THE SKY, NEED .3
[12:01] <mvo> zyga: you guys are so mean!
[12:01] <zyga> mvo: we will attach patches :) that's foss spirit, right?
[12:01]  * zyga hugs mvo
[12:01] <mvo> lol
[12:01]  * mvo hugs zyga
[12:01] <zyga> no worries, we will wait until after breakfast
[12:05] <zyga> mborzecki: updated https://github.com/snapcore/snapd/pull/6244
[12:05] <mup> PR #6244: release: detect too old apparmor_parser <Created by zyga> <https://github.com/snapcore/snapd/pull/6244>
[12:13] <mup> PR snapd#6246 opened: spread: show AVC audits when debugging, start auditd on Fedora <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6246>
[12:15] <mup> PR snapd#6247 opened: tests/lib: do not pick up xatts when repacking core snap <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6247>
[12:16] <pedronis> mborzecki: ^ don't we have xattrs that we care about in core tough?
[12:17] <mborzecki> pedronis: afaik not yet
[12:17] <zyga> pedronis: not that I know of, ubuntu will enable xattrs but it's not done yet
[12:17] <pedronis> still is that change just exchaing a bug for another later?
[12:17] <zyga> heh, in some way yes
[12:18] <zyga> but xattrs will not show up by accident
[12:18] <zyga> and I think we will have some changes around snapd too
[12:18] <pedronis> we are not the one adding them, though? are we
[12:18] <pedronis> ?
[12:18] <zyga> sorry?
[12:18] <pedronis> zyga: I mean,  it depends on what you mean by accident,
[12:19] <pedronis> other teams doing things without telling can be considered an "accident"
[12:19] <pedronis> mborzecki: can we add some code to detect if there's xattrs that are not selinux related around?
[12:19] <zyga> I meant that there will be coordination and I expect things will fail if we rip them out in some tests. programs that were setuid root will require on capabilities instead
[12:20] <pedronis> zyga: you are an optimistic
[12:20] <mborzecki> pedronis: i'll think about it, with the context applied via mount that change may not be needed at all
[12:20] <pedronis> thx
[12:21] <mborzecki> otherwise a way of doing this without adding selinux context would be nice, but not sure if that's entirely possible when we repack the snap
[12:24] <pedronis> mborzecki: is there no utility to run something controlling the context?
[12:24] <pedronis> anyway I let you look into this further
[12:31] <mup> PR snapd#6248 opened: tests/lib/reset: restore context of removed snapd directories <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6248>
[12:34] <mup> PR snapd#6237 closed: client, store: don't use store from client (use client from store) <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6237>
[12:53] <jdstrand> zyga: hey, curious, does leap run on arm?
[12:53] <zyga> jdstrand: hey
[12:53] <zyga> yes, I think there were some pi3 announcements by suse
[12:54] <zyga> https://en.opensuse.org/HCL:Raspberry_Pi3
[12:54] <zyga> I haven't tried myself
[12:54] <zyga> why? :)
[12:54] <zyga> jdstrand: FYI, I sent some patches that disable apparmor on 43.3 because apparmor_parser 2.10.3 doesn't parse our profiles
[12:55] <jdstrand> zyga: it is because of your fyi :)
[12:55] <zyga> haha
[12:55] <zyga> I see
[12:55] <zyga> :)
[12:55] <zyga> can you expand, I don't yet see a correlation between leap and arm
[12:56] <zyga> Chipaca: https://github.com/Juniper/libxo
[12:56] <zyga> remember the topic about snap foo --json
[12:56] <zyga> and friends?
[12:56] <jdstrand> zyga: you surely recollected that we added conditional support for unsafe in classic and there is https://github.com/snapcore/snapd/pull/5982
[12:56] <mup> PR #5982: interfaces/many: conditionally use 'unsafe' with docker-support change_profile rules <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5982>
[12:56] <zyga> yes
[12:56] <zyga> but to interfaces
[12:57] <jdstrand> yes
[12:57] <zyga> snap-confine's own profile goes down in flames
[12:57] <zyga> we just never noticed
[12:57] <jdstrand> I know
[12:57] <zyga> until all hell broke loose
[12:57] <jdstrand> again, I read the pr
[12:57] <jdstrand> so I was thinking "should we even consider conditionally adding unsafe to the snap-confine profile?"
[12:58] <jdstrand> then I reread why we added it: https://github.com/snapcore/snap-confine/pull/133
[12:58] <mup> PR snap-confine#133: Adjust apparmor policy for compatibility with snap-exec <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snap-confine/pull/133>
[12:58] <zyga> 42.3 will be EOL in june next year
[12:58] <jdstrand> we added it for arm
[12:59] <jdstrand> so if arm is on leap, and we conditionally added it, the on arm leap would break
[12:59] <jdstrand> or rather, if leap is on arm
[13:00] <zyga> hmm, I don't recall the whole arm / leap part of the branch
[13:00] <jdstrand> so the answer is "no, we need to unconditionally add it"
[13:00] <zyga> ah
[13:00] <jdstrand> zyga: that branch wasn't done for leap
[13:00] <jdstrand> the branch was done to fix snapd on arm at all
[13:01] <zyga> ok, I read the patch again, I see what that was about
[13:01] <zyga> now back to the current patches
[13:01] <jdstrand> point is, if we decided to conditionally add unsafe to the snap-confine profile, then wherever we didn't add it, arm would be broken. that's silly
[13:01] <mborzecki> off to pick up the kids
[13:02] <zyga> jdstrand: where are we doing this conditionally? I must be missing something
[13:03] <jdstrand> zyga: huh? the interfaces
[13:03] <zyga> jdstrand: are you talking about the current set of patches?
[13:03] <zyga> jdstrand: ah. sorry, too many patches
[13:03] <zyga> so
[13:03] <zyga> there are two cases of broken
[13:03] <zyga> one was louder than another
[13:03] <jdstrand> zyga: I think you may be reading this irc conversation too quickly
[13:03] <zyga> we ignored some errors so the snap-confine profile being broken was below the radar for a long time
[13:03] <jdstrand> 06:57 < jdstrand> again, I read the pr
[13:03] <jdstrand> 06:57 < jdstrand> so I was thinking "should we even consider conditionally
[13:03] <jdstrand>                   adding unsafe to the snap-confine profile?"
[13:03] <zyga> but interfaces were
[13:03] <zyga> aha
[13:03] <zyga> I see
[13:04] <jdstrand> zyga: I asked you about arm on leap to answer my question that was in my head
[13:04] <zyga> thank you for explaining
[13:04] <zyga> so, we can do that in 2.37, I don't mind doing that
[13:04] <jdstrand> zyga: the pr is doing the right thing
[13:04] <zyga> we'd just have to check
[13:04] <zyga> (on a real board)
[13:04] <jdstrand> (in principle)
[13:05]  * jdstrand hasn't reviewed the code
[13:06] <zyga> jdstrand: note that there are two versions
[13:06] <jdstrand> zyga: are you planning a followup pr to clean up the classic template's conditional use of unsafe?
[13:06] <zyga> https://github.com/snapcore/snapd/pull/6245/files is super short for 2.36
[13:06] <mup> PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6245>
[13:06] <jdstrand> zyga: I saw
[13:06] <zyga> I can do that, yeah
[13:06] <zyga> I didn't connect that dot last night
[13:06] <jdstrand> zyga: yeah, well, I didn't connect the dots with the snap-confine profile when doing the classic template pr
[13:07] <zyga> in hindsight logging errors and carrying on was a costly thing :)
[13:07] <jdstrand> zyga: when these land, I'll update that open docker-support pr
[13:07] <zyga> jdstrand: did you see https://github.com/snapcore/snapd/pull/6233
[13:07] <mup> PR #6233: overlord: don't write system key if security setup fails <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6233>
[13:08] <jdstrand> no
[13:08] <zyga> that took some time to track down
[13:08] <zyga> it was breaking 2.36 for all last week and this week
[13:09] <jdstrand> I need to read that carefully-- my first question is 'why is snapd restarting when snap-seccomp and apparmor_parser are running?
[13:09] <jdstrand> '
[13:09] <zyga> jdstrand: it is done in test prep
[13:09] <zyga> that's actually the only thing we don't have a 100% firm answer
[13:09] <zyga> as in
[13:10] <zyga> to be precise
[13:10] <zyga> why snapd is being restarted while those things are in flight
[13:10] <jdstrand> exactly
[13:10] <zyga> since we use sd_notify to tell systemd we are ready only after the managers have been constructed
[13:10] <zyga> one possible explanation
[13:11] <jdstrand> that sounds... weird and probably worth knowing cause there might be other bugs that are caused by this
[13:11] <zyga> is that overlord is indeed done but this is a part of some ensure cycle
[13:11] <zyga> (so normal activity)
[13:11] <zyga> I pasted traces
[13:11] <zyga> and there's a PR that can show you all the data in one spot
[13:11] <zyga> (closed now, I can revive it)
[13:11] <jdstrand> that 'weird' comment was for your 'why snapd is being restarted while those things are in flight' comment, not your sd_notify idea
[13:11] <zyga> yes
[13:12] <zyga> so we have journald/strace/forkstat and snap changes
[13:12] <zyga> I would love if someone had a deeper look at this
[13:12] <zyga> I feel tired after fighting 2.36 issues this week
[13:12] <zyga> jdstrand: https://github.com/snapcore/snapd/pull/6230
[13:12] <mup> PR #6230: spread: detect "signal: terminated" in journal logs <⛔ Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6230>
[13:12] <zyga> the PR name is stale, it became a box of experiments
[13:13] <zyga> I can find the seed that reproduces the problem
[13:13] <pedronis> jdstrand: to be clear, this is in tests, there is quite a bit of manual restarting of snapd going on
[13:13] <zyga> though honestly any run on that branch will fail quickly
[13:14] <jdstrand> zyga: did you consider trapping the signal and waiting to stop til it was safe?
[13:14] <zyga> jdstrand: it's not our side that can trap
[13:14] <zyga> I mean, we'd have to change apparmor parser
[13:14] <pedronis> jdstrand: this is killing the helpers
[13:14] <zyga> systemd looks at the whole cgroup
[13:14] <pedronis> not snapd
[13:14] <zyga> and kills one by one
[13:14] <pedronis> anyway  we had a different solution as well
[13:14] <zyga> yes, mvo sent a PR with KillMode=process
[13:14] <zyga> though it was not merged
[13:15] <pedronis> it's not useful for non reexcing
[13:15] <jdstrand> zyga: well... snapd is calling the parser. if systemd tells us to stop and parser didn't complete...
[13:15] <pedronis> sorry, it's not useful for distros that don't update
[13:15] <zyga> jdstrand: systemd is killing both us and the parser and snap-confine
[13:15] <pedronis> but it would be cleaner
[13:15] <jdstrand> oh, I see
[13:15] <jdstrand> is that configurable in the systemd unit?
[13:15] <zyga> every process is
[13:15] <zyga> yes
[13:15] <pedronis> mvo: why did we close the KillMode change ?
[13:16] <jdstrand> I mean, sure, this may happen regularly in the tests, but maybe it happens legitimately somewhere
[13:16] <zyga> pedronis: I believe we could do both actually, it seems saner for kill mode to be process for snapd
[13:16] <pedronis> zyga: yes, my point
[13:16] <jdstrand> I don't know when that would be-- an admin restarting it? a deb upgrade?
[13:16] <zyga> but it doesn't fix reexecing cases
[13:16] <pedronis> I know
[13:16] <pedronis> but it gives us a saner future
[13:17] <zyga> yes
[13:17] <pedronis> (theoretically)
[13:17] <jdstrand> it seems rather harsh for systemd to just kill everything in the cgroup without given the parent a chance to cleanup
[13:18] <zyga> jdstrand: that's the default :)
[13:18] <zyga> but in hindsight I agree
[13:18] <pedronis> jdstrand: well, indeed there are ways to control that, it's the default tough as zyga said
[13:19] <jdstrand> there is no timeout associated with that?
[13:19] <jdstrand> anyway, I won't question the default of systemd here cause I don't have the context for that decision
[13:20] <jdstrand> but, if that is configurable, certainly for sanity we would want to at least try to have snapd shutdown cleanly
[13:20] <jdstrand> no?
[13:20] <pedronis> yes
[13:20] <pedronis> sorry, but I made a note, but we need mvo around but he is lunching
[13:21] <zyga> jdstrand: no, that's just SIGTERM
[13:21] <zyga> jdstrand: after that there is a wave of SIGKILL
[13:22]  * pstolowski lunch
[13:26] <jdstrand> zyga: that is my question. how long before the wave comes?
[13:26] <zyga> jdstrand: the wave of sigkill?
[13:26] <jdstrand> 07:21 < zyga> jdstrand: after that there is a wave of SIGKILL
[13:27] <jdstrand> zyga: you said that SIGTERM is sent. then a wave of SIGKILL
[13:27] <zyga> yes
[13:27] <zyga> DefaultTimeoutStopSec
[13:27] <jdstrand> zyga: I'm saying, trap SIGTERM, try to shutdown before the SIGKILLs
[13:27] <zyga> 90 seconds
[13:28] <zyga> jdstrand: assuming we are using kill mode process yes
[13:28] <zyga> but that would need some serious work
[13:28] <zyga> it's not easy to do now
[13:28] <zyga> e.g. manager startup is synchronous
[13:28] <zyga> so is overlord startup
[13:28] <zyga> we don't notify systemd that some startups need more time either
[13:28] <jdstrand> zyga: ok. so, certainly we can trap SIGTERM and signal the backend to finish the current parser and snap-seccomp calls, then exit without moving to the next batch, no?
[13:29] <zyga> jdstrand: we trap sigterm but the interaction between this and the rest of the daemon is not simple
[13:29] <zyga> I agree we can do this
[13:29] <jdstrand> hmm
[13:30] <jdstrand> well, I was only asking a question. it sounds like we have a stability/robustness concern here that the 6233 papered over
[13:30] <zyga> yes, I agree
[13:30] <jdstrand> not saying that 6233 is invalid for moving forward
[13:30] <zyga> we didn't notice that daemon was incorrectly stopping either
[13:31] <zyga> john sent some patches that caught that with static analysis
[13:31] <pedronis> well, first we need to stop systemd to send the SIGTERM to apparmor_parser as well, etc
[13:31] <jdstrand> ok, well, I don't mean to distract. just rasing the point that perhaps a followup for cleaning up cleanly when receiving SIGTERM is a good idea
[13:31] <jdstrand> raising*
[13:31] <zyga> it also makes testing more complex, since right now all systemd started snapd's behave the same
[13:31] <zyga> with changing of kill mode some will run under the old snapd.service unit
[13:31] <zyga> some will run under the new one
[13:32] <zyga> jdstrand: all fair points jamie,
[13:32] <zyga> I think it would be nice if we could fix this with reexec magic and systemd services
[13:34] <jdstrand> ok, reading the description of 6233, that seems like a good improvement regardless of sigterm
[13:38] <mvo> pedronis: hi, KillMode=process got closed mostly because the other changes made it less urgent, it is probably still a good idea
[13:39] <zyga> mvo: with kill mode = process, we should make sure that it also applies to snapd run from snapd.snap via that special service
[13:39] <mvo> zyga: yeah, we can install a snapd.service.d file
[13:39] <mvo> zyga: I mean, write it automatically
[13:39] <zyga> oh
[13:39] <zyga> super nice idea
[13:39] <zyga> +1001
[13:39] <mvo> zyga: :)
[13:40] <mvo> zyga: I can reopen my PR and add code to add the .d file
[13:40] <zyga> mvo: it's not urgent but yeah, for master +1
[13:41] <mvo> zyga: +1
[13:41] <zyga> mvo: though we need to think about revert consequences or just managing those .d files over time
[13:41] <mvo> zyga: indeed
[13:46] <mup> PR snapd#6249 opened: cmd/libsnap: introduce and use sc_strdup <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6249>
[13:47] <zyga> mborzecki: could you try to look at 6149 today?
[13:48] <mup> PR snapd#6250 opened: data: set KillMode=process for snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/6250>
[14:08] <mup> PR snapd#6247 closed: tests/lib: do not pick up xatts when repacking core snap <⛔ Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/6247>
[14:49] <Chipaca> degville: "keeping it the same" is that a +1 :-D
[14:52] <degville> Chipaca: yes!
[14:52] <degville> :)
[14:52] <Chipaca> wooowoeoeoo
[14:58] <pstolowski> pedronis: you're right, it's about AddBlocked predicate
[15:07] <zyga> mborzecki: hey
[15:07] <zyga> remember when you asked for a cleanup of how tools are invoked from snap-confine?
[15:16] <zyga> mborzecki: so you have your wish
[15:16] <pedronis> pstolowski: good, but yes we'll need to think a bit what to do about that
[15:16] <zyga> mborzecki: found a branch that does that :)
[15:16] <mborzecki> zyga: hah :)
[15:17] <Chipaca> mborzecki: i think you did half a review of 6912 already, could you finish it?
[15:17] <Chipaca> #6912
[15:17]  * Chipaca kicks mup
[15:17]  * Chipaca jumps up and down on mup
[15:18] <mborzecki> Chipaca: wrong PR #?
[15:18] <Chipaca> mborzecki: https://github.com/snapcore/snapd/pull/6192
[15:18] <mup> PR #6192: overlord/snapstate: on refresh, check new rev can read current <Created by chipaca> <https://github.com/snapcore/snapd/pull/6192>
[15:18] <Chipaca> #6192
[15:19] <Chipaca> 6192, 6912, what EVAR
[15:19] <mborzecki> aah epoch read thing
[15:19] <Chipaca> yeh
[15:19] <Chipaca> tempted to run with graham's +1 but thought i'd follow process for once :-p
[15:20] <zyga> Chipaca: friday called and wants to +1 your PRs
[15:20] <Chipaca> well there's one less to +1 now
[15:21] <mup> PR snapd#6192 closed: overlord/snapstate: on refresh, check new rev can read current <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6192>
[15:21] <Chipaca> and I guess I need to address the comments on the other ones
[15:21] <Chipaca> ugh, that's too much like work
[15:23] <pedronis> Chipaca: the media one has a question by me, it probably needs discussion
[15:23] <Chipaca> pedronis: yeah
[15:23] <zyga> brb
[15:23] <Chipaca> pedronis: do you have the time to discuss?
[15:24] <pedronis> Chipaca: not really today, that one we'll have to wait when we are both back
[15:24] <Chipaca> pedronis: ok
[15:42] <zyga> re
[15:42] <zyga> mvo: hey
[15:42] <zyga> mvo: do you have a sec
[15:42] <zyga> https://github.com/snapcore/snapd/pull/6235 is green
[15:42] <mup> PR #6235: overlord,apparmor: new syskey behaviour + non-ignored snap-confine profile errors <⛔ Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/6235>
[15:42] <zyga> and should make 2.36 green
[15:42] <zyga> would you mind finishing your review there
[15:42] <zyga> I'm happy to backport / cherry pick tests
[15:43] <zyga> or other stuff
[15:43] <zyga> from the corresponding master branches
[15:55]  * zyga considers EODing
[15:55] <zyga> unless someone wants to look at 2.36 PRs
[15:56] <Chipaca> pedronis: I pushed the discussed reorg to #6104. If you won't have time to re-review, can I discard your block?
[15:56] <mup> PR #6104: snapctl: add "services" <Created by chipaca> <https://github.com/snapcore/snapd/pull/6104>
[15:59] <pedronis> Chipaca: yes, the direction looks what we discussed
[16:00] <pedronis> Chipaca: done myself
[16:08] <Chipaca> pedronis: i included your rationale in the commit message, for posterity, fwiw
[16:08] <Chipaca> pedronis: thank you
[16:08] <Chipaca> zyga: #6104 is now needing a second review, if you're still itching to do one
[16:08] <mup> PR #6104: snapctl: add "services" <Created by chipaca> <https://github.com/snapcore/snapd/pull/6104>
[16:09] <zyga> yep
[16:09]  * Chipaca goes to get tea and some ibuprofen
[16:09] <zyga> Chipaca: can you trade for trivial https://github.com/snapcore/snapd/pull/6249
[16:09] <zyga> I wanna land it :)
[16:09] <mup> PR #6249: cmd/libsnap: introduce and use sc_strdup <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6249>
[16:10] <zyga> 2.36.2 looks good on suse :)
[16:10] <zyga> and startup time for snaps is nice
[16:10] <zyga> though I wonder if we need to refresh each snap to see the effect
[16:11] <zyga> I disable/enable things to see that
[16:11] <zyga> mvo: ^
[16:11] <zyga> Is that expected?
[16:11] <mvo> zyga: one refresh or enable/disable should be enough to fix the fontconfig cache
[16:11] <mvo> zyga: (also in a meeting)
[16:12] <zyga> ta
[16:12] <mup> PR snapd#6236 closed: Staticcheck fixes <Reviewed> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6236>
[16:14] <zyga> kenvandine: ping
[16:14] <zyga> is this expected? https://www.irccloud.com/pastebin/G8zDQBdJ/
[16:16] <kenvandine> zyga: yes... jamesh submitted a PR to Yaru to fix that
[16:16] <zyga> cool
[16:16] <zyga> thanks
[16:16] <kenvandine> i'll check on the status
[16:16] <kenvandine> it's been weeks
[16:17]  * cachio lunch
[16:23] <mup> PR snapd#6213 closed: interfaces: let NM access ifindex/ifupdown files <Created by alfonsosanchezbeato> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/6213>
[16:28] <zyga> Chipaca: +1
[16:29] <zyga> mvo: suse updated :)
[16:30] <zyga> error: snap "test-snapd-policy-app-consumer" has "remove-snap" change in progress
[16:30] <zyga> pstolowski: ^ is that something you were describing during the standup?
[16:31] <mvo> zyga: \o/
[16:31] <pstolowski> zyga: hmm not really, my issue doesn't cause errors
[16:33] <pstolowski> zyga: where do you see it?
[16:33] <zyga> random failure on strdup
[16:33] <zyga> (on that PR)
[16:33] <zyga> I restarted as it looked like noise
[16:34] <pstolowski> uhm
[16:36] <zyga> mvo: vscode startup on leap 42.3 and TW is very good
[16:37] <zyga> Chipaca: did you see my ping about http://juniper.github.io/libxo/libxo-manual.html xo?
[16:37] <Chipaca> zyga: i did
[16:38] <zyga> cool
[16:38] <Chipaca> zyga: I'm not adding anything to my stack right now though :-)
[16:38] <zyga> sure sure
[16:38] <zyga> it's a C api
[16:38] <zyga> but the idea is neat
[16:40] <mvo> zyga: cool
[16:41] <mvo> zyga: thanks for checking/confirming!
[16:48]  * pedronis calls it a week
[16:48] <pedronis> have a good weekend!
[16:51] <cachio> mvo, 2.36.2 in candidate
[16:53] <mvo> cachio: nice!
[16:55] <cwayne> Now with spread results on customer hw :D
[16:57] <pedronis> Chipaca: I managed to update my PR: https://github.com/snapcore/snapd/pull/5712
[16:57] <mup> PR #5712: overlord: make InstallMany work like UpdateMany, issuing a single request to get candidates <Created by pedronis> <https://github.com/snapcore/snapd/pull/5712>
[16:57] <Chipaca> pedronis: i saw! excellent
[16:57] <Chipaca> pedronis: is that enough to unblock it?
[16:58] <pedronis> yes
[16:58] <Chipaca> cwayne: that sounds like a good thing. Is that a good thing?
[16:58] <Chipaca> pedronis: neat
[16:58] <cwayne> Chipaca: no it's a great thing :)
[16:58] <Chipaca> :)
[16:58] <pedronis> Chipaca: if it gets green, there is really the last commit than needs a review and then it could go in
[16:58] <pedronis> I mean real commit, not the master merges
[16:58] <cwayne> since we've now got my team's tests plus yours running on every core update in beta :)
[16:58] <Chipaca> a'ight
[16:58] <mvo> pedronis: nice
[16:59] <mvo> cwayne: woah, nice!
[16:59] <Chipaca> what, only beta?
[16:59] <Chipaca> :-D
[16:59] <cwayne> beta's my jam
[17:21] <mup> PR snapd#6249 closed: cmd/libsnap: introduce and use sc_strdup <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6249>
[17:23] <mup> PR snapd#6251 opened: cmd/snap-confine: refactor calling snapd tools into helper module <Created by zyga> <https://github.com/snapcore/snapd/pull/6251>
[17:25] <zyga> mvo: not sure if you EOW but I'd love an ack on https://github.com/snapcore/snapd/pull/6245
[17:25] <mup> PR #6245: interfaces/backends: detect too old apparmor_parser (2.36) <Created by zyga> <https://github.com/snapcore/snapd/pull/6245>
[17:27] <mup> PR snapd#6242 closed: overlord/snapstate: use file timestamp to initialize timer <Reviewed> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6242>
[17:32] <mup> Bug #1781906 changed: Content provider interfaces introduced to snaps aren't correctly set up <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1781906>
[17:40] <mup> PR snapd#6104 closed: snapctl: add "services" <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6104>
[17:43] <mup> PR snapd#6252 opened: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6252>
[17:45] <zyga> jdstrand: hey, not sure if you want or have time on Friday evening but... https://github.com/snapcore/snapd/pull/6244 :D
[17:45] <mup> PR #6244: release: detect too old apparmor_parser <Created by zyga> <https://github.com/snapcore/snapd/pull/6244>
[17:45] <zyga> you looked at it
[17:54] <Chipaca> EOW'ing here
[17:54] <zyga> o/
[17:54] <Chipaca> when you see me next, december will be into two (decimal) digits!
[17:55] <Chipaca> :-D
[17:55] <zyga> maaan
[17:55] <zyga> envy *
[17:55] <Chipaca> well, unless i'm bored or something
[17:55] <Chipaca> :-)
[17:55] <zyga> you can always do reviews *D*
[17:55] <zyga> NOT :)
[17:55] <zyga> enjoy the time off
[17:56] <Chipaca> if I'm tempted, instead I'll work on werm
[17:56] <Chipaca> ttfn :-)
[17:56] <zyga> werm?
[17:56] <zyga> well, I'll find out in Dec
[18:01] <jdstrand> zyga: I'll try. have a few things I must get done today
[18:01] <zyga> thanks cwayne
[18:01] <zyga> thank you jdstrand :)
[18:01] <cwayne> zyga: <3
[18:17] <kenvandine> zyga: the CLA check shouldn't fail if I'm a member of canonical, right?
[18:17] <zyga> kenvandine: if it does it's a bug :)
[18:17] <zyga> are you asking about https://github.com/snapcore/snapd/pull/6252 ?
[18:17] <mup> PR #6252: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6252>
[18:17] <kenvandine> zyga: yes
[18:17] <zyga> review sent :)
[18:19] <zyga> I should EOW
[18:19] <zyga> I may be back in the office but not actively paying attention unles pinged
[18:19] <zyga> *unless
[18:58] <mup> PR snapd#6225 closed: tests: fix for failover test on how logs are checked <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6225>
[19:00]  * cachio afk
[19:08] <mup> PR snapd#6253 opened: Members of canonical LP group should pass CLA check <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6253>
[19:11] <mup> PR snapd#6224 closed: interfaces: return security setup errors <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6224>
[19:14] <zyga> kenvandine: https://github.com/snapcore/snapd/pull/6252/files#r237971362
[19:14] <mup> PR #6252: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6252>
[20:37] <mup> PR snapd#6254 opened: tests: improve how the log is checked to see if the system is waiting for a reboot <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6254>
[23:43] <dennwc> Hi! Can anyone help me to setup snapcraft dev environment? I'm trying to fix a bug related to Go modules support, but I can't get the local version of snapcraft working.


[02:40] <lotuspsychje> good morning
[02:51] <leftyfb> "Enter a valid password with a max of 12 characters."
[02:51] <leftyfb> these places drive me nuts
[02:52] <arraybolt3> Lets them provide reasonable NVIDIA stress-testing services on the side? :P
[02:52] <arraybolt3> "Audit our customers' security and get paid for your compute power!"
[02:52] <leftyfb> what gets me more is the banks that have other limitations with passwords
[02:52] <leftyfb> you would think they would want MORE secure passwords
[02:52] <leftyfb> I've contacted every one of them recently and complained and left feedback
[02:52] <arraybolt3> "Sorry, that PIN is invalid. Please make sure there are exactly 4 digits." >_<
[02:52] <oerheks> 4 digit pin code only :-(
[02:53] <oerheks> This is so 1999
[02:53] <arraybolt3> Who knows, maybe this is why people *really* hate COBOL.
[02:53] <leftyfb> don't even get me started with the places that still ask for me pin when I use apple pay
[02:54] <arraybolt3> I think one time there was a password dialog box I ran into that *wouldn't* accept symbols.
[02:55] <leftyfb> oh, those still exist
[02:55] <arraybolt3> Like what, are you storing this in plaintext in a flat file with a special parser?
[02:56] <arraybolt3> If you're hashing the password, surely the characters in it don't matter.
[02:56] <leftyfb> I'm doing this because I've spent the past few weeks moving off of Lastpass
[02:56] <JanC> 4-digit PIN codes are pretty safe if you use them for the right things
[02:56] <arraybolt3> :O
[02:57] <arraybolt3> JanC: A bank is not the right thing for that.
[02:57] <leftyfb> I think I had about 12 or 1300 passwords stored in it.  I'm down to about 400 or so left to go and 224 stored in the new password manager
[02:57] <JanC> they are; most bank cards will block your card after 3 failed attempts
[02:58] <arraybolt3> Think about it - 4 digits, that's exactly 10,000 possible codes. If you get locked out after 3 attempts, that means that one out of every 3334 bank cracking attempts succeeds.
[02:58] <leftyfb> I'm going through each site in lastpass, logging in, updating my email address if applicable, updating password, enabling MFS if available, adding it to my new password manager and removing it from last pass. It's going a lot slower than I expected
[02:58] <arraybolt3> So if there's one million attempted PIN guesses, about 300 of them work.
[02:59] <JanC> you would usually also be filmed while trying to enter that PIN
[02:59] <arraybolt3> That's easier than winning the lottery.
[03:00] <JanC> so your chances of doing that successfully (as in getting away with it) aren't very big
[03:00] <arraybolt3> JanC: Meh, valid point, but I'm sure that doesn't deter everybody.
[03:01] <JanC> most money that gets stolen with a card & PIN is where people wrote their PIN down or were forced to give it
[03:02] <arraybolt3> (You could probably narrow down the codes too - 0000, 9999, 1234, etc. probably aren't in use.)
[03:03] <JanC> my guess is that those are probably used a lot  :P
[03:03] <JanC> that and birthdays, etc.
[03:03] <arraybolt3> ...I wish I had the faith in humanity to say that I thought you were wrong XD
[03:04] <JanC> the same applies to passwords, of course
[03:04] <arraybolt3> oh my gosh that reminds me of a "lifehack" I read once.
[03:04] <arraybolt3> It was in a book, "Handy Household Hints from Heloise". It had a password creation scheme in it that was horrifically insecure.
[03:04] <arraybolt3> Something like, "Pick four digits, like your birthday, then put the first two at the start, the name of the company in the middle, and the last two at the end."
[03:05] <arraybolt3> I wonder how many compromised accounts that resulted in.
[03:05] <JanC> well, that's much better than _some_ alternatives, of course  :)
[03:06] <arraybolt3> /msg nickserv identify arraybolt3 Password!123
[03:06] <arraybolt3> :P (obviously fake)
[03:06] <JanC> better than a bare password, and certainly better than "password"
[03:06] <JanC> better than a bare *birthday*
[03:07] <arraybolt3> To make this slightly more on-topic, there used to be (might still be) a GNOME Disks bug where it will truncate your LUKS passphrase if you make it too long.
[03:08] <JanC> which might or might not be a problem  :)
[03:09] <JanC> I guess it gets really fun when you try to unlock it in another way
[03:10] <arraybolt3> Oh it's definitely a problem, you give it a passphrase, it "successfully" applies it, and then you can't get back in later :-/
[03:10] <arraybolt3> (One assumes you eventually figure it out and try successively longer truncated versions of the passphrase until it works.)
[03:12] <JanC> wouldn't it still work when you use GNOME Disk to unlock it?
[03:12] <JanC> or does it only truncate on creation?
[03:12] <arraybolt3> Not if you've used it to change your main drive's password and it's Plymouth asking you for it.
[03:13] <JanC> well, yeah, so depends on how you try to unlock it
[03:14] <arraybolt3> It's probably even more of a problem if you have encrypted /boot and so only get one shot at unlocking the partition before being dropped to a GRUB shell.
[03:15] <lotuspsychje> https://haveibeenpwned.com/
[03:15] <arraybolt3> leftyfb: 12-1300?! How on earth do you have that many accounts?
[03:15] <JanC> should be possible to unlock it from a live image (that still has the broken version)
[03:15] <lotuspsychje> meanwhile their database grows tons
[03:16] <leftyfb> arraybolt3: I've been on the internet since roughly 1993
[03:16] <arraybolt3> JanC: Hopefully true. It's not impossible to get back in (I hope!), just tricky,
[03:17] <arraybolt3> leftyfb: Hmm. I've only been on for a couple of years, and have a very small list of accounts.
[03:17] <arraybolt3> and most of those are mailing list subscriptions.
[03:17] <JanC> mailman will mail you your password anyway  :P
[03:17] <arraybolt3> Ubuntu's mailman doesn't seem to do that oddly.
[03:18] <JanC> I mean, it will mail you on request
[03:18] <arraybolt3> I have them all in Chrome anyway, so it doesn't really matter. It probably wouldn't matter if I just discarded the password entirely
[03:18] <arraybolt3> JanC: Oh, didn't know that.
[03:18] <JanC> the monthly mails are just an option
[03:19] <leftyfb> arraybolt3: I'm actually deleting the passwords stored in chrome as well
[03:20] <leftyfb> it's not something I can use easily on other devices unless I sign in to the browser with my chrome profile since I encrypted the passwords
[03:20] <arraybolt3> What password manager are you migrating to?
[03:20] <leftyfb> and it doesn't always keep in sync with other password managers
[03:20] <leftyfb> 1password
[03:20] <arraybolt3> Never heard of them.
[03:20] <JanC> arraybolt3: see e.g. https://lists.ubuntu.com/mailman/options/ubuntu-announce → enter your email address & hit the button at the bottom
[03:21] <JanC> assuming you are subscribed, of course  :)
[03:23] <leftyfb> arraybolt3: I didn't care for it at first, but it's grown on me. It does several things better than Lastpass
[03:23] <arraybolt3> leftyfb: For me, all my devices are either Chrome-compatible or don't need my passwords or I can just pull them from a Chrome-enabled device if I really need them elsewhere.
[03:24] <leftyfb> arraybolt3: if you encrypt your password store in chrome, you can't access your password remotely using the google password manager
[03:24] <arraybolt3> (As an aside, my suspicion that Chrome was more lightweight than Firefox was confirmed by a Phronix benchmark the other day - it's not just faster at most things, it's sometimes *way* faster.)
[03:24] <arraybolt3> leftyfb: I always just access it from within the browser.
[03:25] <leftyfb> with browsers, the grass is always greener. Also, going to a new browser will ALWAYS be faster since you haven't loaded it up with a bunch of addons, plugins, themes, bookmarks, passwords, cookies, cache, etc
[03:26] <JanC> lastpass isn't even worth the name "password manager", it's basically a password wide distribution manager
[03:26] <arraybolt3> I've been using Chrome for a good while and it's still noticably faster.
[03:26] <arraybolt3> Also I can access my encrypted passwords from within passwords.google.com.
[03:26] <arraybolt3> Although I don't use on-device encryption, that's probably waht you meant.
[03:27] <leftyfb> JanC: I wouldn't go that far. The "breach" wasn't as bad as everyone is making it out to be. My account didn't actually get breached. But this isn't the first time they've had an issue and they handled this very poorly. Even if your backup vault was part of the breach, they still need to get your master password to unlock it
[03:28] <JanC> arraybolt3: last time I tried it (now long ago), Chromium got *unuseably* slow once I opened a lot of tabs
[03:29] <arraybolt3> Maybe things got better, or maybe Chromium and Chrome are different.
[03:30] <JanC> do you use it with >100 tabs loaded?
[03:30] <leftyfb> https://imgur.com/a/772s4y5
[03:30] <arraybolt3> Hmm, no, I have 45 at the moment.
[03:30] <JanC> or did Phoronix test that?
[03:30] <leftyfb> arraybolt3: ^
[03:30] <arraybolt3> Once I get much higher than that though, it gets so hard to find what I'm looking for that I start cleaning them up.
[03:31] <leftyfb> JanC: I put tabs into groups these days. I have maybe 20 or so tabs outside of groups at any given moment
[03:31] <JanC> TreeStyleTab FTW  :P
[03:32] <arraybolt3> Hmm... on-device encryption scares me a bit :P
[03:32] <leftyfb> It’s not per device encryption
[03:32] <leftyfb> It’s just locked with a pass phrase
[03:33] <arraybolt3> True, but I do change my Google password every so often, and I dread the day I lose all my devices, especially if it happens just after a password change... probably irrational, but still...
[03:35] <leftyfb> a proper password manager allows you to share sets of passwords as well and have multiple "vaults"
[03:39] <arraybolt3> I mean I see what you're saying, and for some stuff that makes sense, but I don't know I'd ever bother with actually using that feature.
[03:39] <arraybolt3> Maybe that's a problem with me though :P
[03:41] <leftyfb> I do a lot
[03:41] <leftyfb> requires a lot of management
[03:51] <arraybolt3> JanC: I suspect the problem with Chromium you were hitting is probably fixed, since Chrome recently started making tabs that you weren't using much go to "sleep" or something similar - basically it has to reload the tab next time you click on it. Probably a good feature, though it does keep stealing free member-only Medium articles from me :P
[03:52] <arraybolt3> (Sometimes you don't want to burn two free articles on one article when you were just looking up how to do something in Python or whatnot.)
[03:52] <JanC> I don't want tabs to be unloaded without my permission
[03:52] <JanC> Firefox can do that too
[03:53] <JanC> some sites will not restore "state" when reloaded
[03:53] <arraybolt3> That makes sense. The day I lose a massive Reddit post or comment will probably be the day I turn that feature off.
[03:54] <arraybolt3> Though hopefully it knows better than to sleep those tabs.
[03:55] <JanC> it's mostly old sites (that don't use local storage) that do interactive search results or changes
[17:03] <lotuspsychj3> leftyfb: https://www.goto.com/blog/our-response-to-a-recent-security-incident
[17:04] <leftyfb> lotuspsychj3: ?
[17:04] <leftyfb> I don't use anything by GoTo
[17:05] <lotuspsychj3> just showing on my rss news
[17:05] <lotuspsychj3> lastpass related a bit
[17:05] <leftyfb> yeah, if anything, it's just more of the same
[17:06] <leftyfb> I'm not more concerned
[17:06] <lotuspsychj3> kk
[17:06] <leftyfb> all of my important passwords have been changed. I have about 400 or so to still go through but they're mostly dupes, outdated services or stuff I don't really care about
[17:07] <leftyfb> they would still need to get my master password to unlock the vault
[17:11] <leftyfb> wow, the ubuntu 22.04 installer is REALLY broken if you don't have DHCP
[17:19] <ravage> the statement is true in general
[17:47] <leftyfb> I don't see how this passed any sort of QA
[21:54] <enigma9o7> What is wrong with this picture? https://itsfoss.com/content/images/wordpress/2013/07/install-gambas-ubuntu-linux.jpg
[21:54] <enigma9o7> from https://itsfoss.com/install-gambas-ubuntu/
[22:05] <daftykins> no T!
[22:05] <daftykins> oh they left
[22:15] <sarnold> uwu ubunu!
[22:15] <arraybolt3> Attack of the killer lobster?
[22:16] <Jeremy31> sharknado


[01:52] <guiverc> Bashing-om, s/garanty/  [whatever correct spelling is; i'm not gonna try]
[01:53] <guiverc> s/Pasma/Plasma too
[01:54] <Bashing-om> guiverc: Well, is a  quote - not much we can do to correct.
[01:57] <guiverc> i don't see any quote marks "Impish Indri Ubuntu-fr t-shirt"
[01:58] <guiverc> maybe quotes need to be added
[02:03] <Bashing-om> guiverc: Yeah . I think adding the quates is custoary for correctmess in tis case . Done. Next !
[02:04] <Bashing-om> guotes* (can tell my mind is still on support ) .
[02:07] <Bashing-om> guiverc: I got thunderstorms  moving in - I may have to cut and run.
[02:08] <guiverc> ack.  i'm still in blogo
[02:11] <guiverc> my read thru is complete Bashing-om , only those 2 comments.. looks good
[02:11] <Bashing-om> guiverc: Great - all good to go :D
[07:40] <guiverc> I just received a reply from ru-fu; confirmation of name I wanted.. thus I've changed "ru-fu" to Ruth Fuchss on wiki  (UWN 706)
[18:54] <Bashing-om> UWN: Pulling "WIP" - log checked and no further edits are known. Time to push 20:00 UTC :D
[19:59] <Bashing-om> UWN: ubuntu-news@lists is in the wind - doing the Forum post next.
[20:26] <Bashing-om> UWN: Forum post done - re-diects are next.
[20:39] <Bashing-om> UWN: Redirects also completed - Pending now is release to the Social Medias.
[21:04] <Bashing-om> Away for just a bit or so.
[21:14] <guiverc> okay to push 706 to fridge Bashing-om
[21:14] <guiverc> ? ^
[21:31] <Bashing-om> guiverc: Yup - push away - no issues are known :D
[21:31] <guiverc> https://fridge.ubuntu.com/2021/10/25/ubuntu-weekly-newsletter-issue-706/
[21:31] <guiverc> tweeted 706
[21:35] <Bashing-om> Fridge: spot check good :D
[21:35] <Bashing-om> guiverc: Clear now to do away with the evidence ?
[21:35] <guiverc> yep clear away
[21:39] <Bashing-om> Ho-kay - prepping for 707.
[21:46] <Bashing-om> UEN: We do issue 707 :D
[21:51] <guiverc> 706 pushed to fb
[21:53] <Bashing-om> guiverc: Thanks ! All caught up :D


[05:40] <Dragonkeeper> hello.  is there a plane to add voice recognition to phones. like google search (responding to ok ubuntu)  :')
[14:06] <belkinsa> Hello, is there a way to change what type of info shows up on the main screen (as in the X text sent today (as an example) one)?
[14:06] <tipai> hello everyone ...can anyone help me out with this error
[14:06] <tipai> Device falcon not found on server https://system-image.ubuntu.com channel ubuntu-touch/stable/ubuntu
[14:07] <tipai> i want to install ubuntu touch in motorola g
[14:07] <ogra_> then you would have to port it ... there is no image on that server for the falcon http://system-image.ubuntu.com/ubuntu-touch/stable/ubuntu/http://system-image.ubuntu.com/ubuntu-touch/stable/ubuntu/
[14:08] <ogra_> oops
[14:08] <ogra_> http://system-image.ubuntu.com/ubuntu-touch/stable/ubuntu/
[14:08] <ogra_> !devices
[14:08] <belkinsa> !porting
[14:08] <ogra_> if there isnt a link to an image  for your device in the wiki above, check the xda forums, perhaps someone there has worled on a port
[14:09] <tipai> okey i understand ..
[14:09] <tipai> looking forward
[14:10] <ogra_> belkinsa, i dont think you can change the defaults easily ... but there is an app in the store that can set a customm message
[14:11] <ogra_> (the bit showing the info is a generic service, apps provide the text for it)
[16:41] <habs> stgraber: Not sure if this is the right place, but trying to compile system-image-2.2 on a desktop 14.04 deriv and I get this error: http://sprunge.us/UJXS Do you know how I would go about fixing this error?
[16:43] <stgraber> habs: that would be a question for barry
[16:52] <habs> barry: ^ Thanks, was just looking to get this compiled
[18:36] <zzarr_> hello!
[18:37] <zzarr_> where do I download the image for my Meizu MX4?
[18:37] <zzarr_> I kind of did something stupid
[18:39] <zzarr_> how do I reflash the phone?
[18:41] <brobostigon> phablet-tools, :)
[18:46] <zzarr_> yes
[18:47] <zzarr_> but, it's getting stuck, not starting adb
[18:47] <zzarr_> or at least not visible with adb
[18:48] <zzarr_> what I did was stupid, I know, I was trying to move /usr to /home and make a symlink /usr -> /home/usr i order to free some storage on /
[18:49] <zzarr_> I made an backup of /usr called /usr.bak
[18:51] <zzarr_> my phone is in recovery mod, but ubuntu-device-flash touch --channel ubuntu-touch/rc-proposed/meizu.en does not do anything
[18:52] <zzarr_> do I need to enable my phone some how?
[18:53] <ogra_> you need a recovery img with adb
[18:53] <ogra_> the installed one doesnt have adb
[18:54] <zzarr_> how to obtain that?
[18:54] <zzarr_> and how to install?
[18:57] <zzarr_> found it :)
[19:03] <zzarr_> I'm in a adb shell now, how do I access / in Ubuntu Touch?
[19:04] <ogra_> you mean from recovery ?
[19:04] <zzarr_> or... if I run ubuntu-device-flash touch --device arale --channel ubuntu-touch/stable/meizu.en will I wipe /home?
[19:04] <zzarr_> yes from recovery
[19:04] <ogra_> no, not if you nort use --wipe or --boratrap
[19:05] <ogra_> *--botstrap
[19:05] <ogra_> sigh
[19:05] <ogra_> *--bootstrap
[19:05] <zzarr_> :)
[19:05] <zzarr_> I better run that line then :)
[19:05] <ogra_> sudo ubuntu-device-flash touch --channel ubuntu-touch/rc-proposed/meizu.en  --recovery-image /pathh/to/your/recovery.img
[19:06] <ogra_> that will only reinstall the system and not touch and of the writable bits (like homedir)
[19:06] <ogra_> *any
[19:07] <zzarr_> I started the line I asked about before your last response, I hope it will work
[19:08] <zzarr_> In any way, thanks alot :)
[19:08] <ogra_> --bootstrap makes it fromat the partitions, --wipe makes it rm all writable data, so dont use any of theseif you want to keep something
[19:08] <ogra_> well, good luck :)
[19:08] <zzarr_> if my /home is deleted it's no big deal, just sorting music :)
[19:10] <zzarr_> hmm... it rebooted :D
[19:11] <zzarr_> my thought's on Ubuntu Touch so far.... LOVE IT!
[19:12] <zzarr_> NORMAL BOOT :D
[19:13] <ogra_> ;)
[19:13] <zzarr_> rotating ubun... never mind, allready booted
[19:13] <zzarr_> fantastic
[19:14] <zzarr_> now I can continue destroying my phone :D (I'll do my best to not do that... yes)
[19:15] <zzarr_> is there a good way to move /usr or make / bigger?
[19:17] <ogra_> not easily, no
[19:17] <zzarr_> hmm
[19:18] <ogra_> use a chroot (that also prevents you from having to make it writable which causes various other probs)
[19:20] <zzarr_> do you think that running "sudo su", "cp /usr  /home" "mv /usr  /usr.bak", "ln -s /home/usr  /usr" could work?
[19:21] <zzarr_> I like the idea of a chroot, but how do I set that up? (I realy want XMir running)
[19:21] <ogra_> oh, i think that wont work in a chroot
[19:21] <zzarr_> should I have proposed instead of stable?
[19:21] <ogra_> so you likely have to make it writabble
[19:22] <ogra_> (and be prepared to have to re-flash too :) OTA will break)
[19:22] <zzarr_> but only when I install
[19:22] <zzarr_> yes
[19:22] <zzarr_> true
[19:22] <ogra_> (and the system isnt designed for apt updates, it will fall apart over time)
[19:23] <ogra_> there were instructions on the mailing list how to make XMir work though hacking up the os
[19:23] <ogra_> check the archives
[19:23] <zzarr_> you don't have a link to the archive?
[19:24] <zzarr_> I'll install proposed now :)
[19:25] <ogra_> https://lists.launchpad.net/ubuntu-phone/
[19:26] <zzarr_> thanks
[19:26] <ogra_> (the search interface in launchpad is crap, better search for "XMir ubuntu-phone" on google ;)
[19:27] <zzarr_> hehe, yepp
[19:38] <zzarr_> now it got proposed :)
[19:40] <zzarr_> I'll give up for today, It's getting late here in Sweden, 21:40 ( or 9:40PM)
[19:41] <zzarr_> thanks alot ogra_
[19:41] <zzarr_> bye
[22:12] <seldon> hello guys, how best way to init help deveolop for ubuntu phone...
[22:16] <seldon> exits anyway to emulate ubuntu phone?
[22:17] <k1l_> seldon: there is the ubuntu sdk
[22:19] <k1l_> seldon: https://developer.ubuntu.com/en/start/
[23:16] <Gringer> Hello, i try to acces my mx4 via Fastboot but I will see only < waiting for device > adb is workingfine. Any tips for me?