[00:02] <wxl> mhall119: same here :(
[00:04] <wxl> mhall119: the thing that's really sad about it is the changes i usually need to make are fairly trivial. not the kind of thing i should have to spend 10 minutes logging in on :/
[00:10] <pleia2> at least we can still edit it, the help.ubuntu.com/community is entirely locked down to edits until we can figure out some way to handle the spam
[00:10]  * pleia2 needs to chase down some loose ends there
[00:11] <wxl> yikes wow i didn't know that
[00:11] <wxl> i assume there's an rt ticket?
[00:11] <pleia2> wxl: there was an rt ticket to shut down the spam, which lead to a full lockdown (except admins)
[00:11] <pleia2> IS suggested we create a group of trusted editors, and only they can edit it
[00:12] <pleia2> but the idea of maintaining such a list makes my stomach ache, and I don't yet know what else they can offer us
[00:12] <pleia2> (plus such a list defeats half the point of a wiki)
[00:19] <wxl> pleia2: i guess i've never had an edit at it. what wiki software did it use?
[00:20] <pleia2> wxl: same as wiki.ubuntu.com, moinmoin
[00:20] <wxl> pleia2: then how the heck did it have a problem with spam and the wiki doesn't?
[00:22] <pleia2> wxl: if you look at 2016-01-06 under https://wiki.ubuntu.com/RecentChanges?max_days=14 the wiki.ubuntu.com one DID get a little bit of an attack, but it's nothing like the thousands of pages created on the help wiki over the holidays
[00:22] <pleia2> as far as I can tell with the help wiki, wrong place, wrong time? :)
[00:22] <pleia2> this is all a recent development
[00:23] <wxl> madness.
[00:23] <wxl> did the spam involve registering a lp account, too????
[00:23] <pleia2> the worst part is that actual people have trouble logging in, but not bots ;)
[00:23] <pleia2> yep
[00:23] <wxl> ridiculous amount of work for probably very little return
[00:24] <wxl> we should require 2fa by default on sso logins
[00:24] <pleia2> probably assumed it wasn't being watched
[00:24] <wxl> i've been using 2fa for quite a while and been pleased
[00:25] <pleia2> other projects beyond ubuntu use the SSO, since it used to be *launchpad* SSO, not ubuntu-branded and some projects unrelated to ubuntu hosted stuff there (perhaps most notably, openstack)
[00:25] <pleia2> so requiring 2fa doesn't just impact us
[00:26] <wxl> hm
[00:27] <wxl> well maybe we could require 2fa set-up for all users, make it a requirement to complete authentication on the wiki, and leave it as a user-selectable option for other sites
[00:29] <pleia2> yeah, I'll have to collect these ideas somewhere so I can have a fruitful discussion with IS
[00:30] <wxl> well you can always put it in the ticket
[00:30] <pleia2> yeah, could do
[00:30] <wxl> but if canonical hosting for our loco is any judge, most things on rt get kind of ignored XD
[00:30] <wxl> probably better to approach the right person or persons if you know where to find them
[00:30] <pleia2> I usually submit the ticket and follow up in channel, but lately all my requests have been going through quickly
[00:31] <pleia2> no need for follow up!
[00:31] <wxl> wow i wish that would happen for me
[00:31] <wxl> we've been waiting for the aforementioned hosting for almost a year
[00:31] <pleia2> this is obviously a more complicated situation though, so it probably gets pushed to the "this is hard, do later" pile
[00:31] <wxl> and honestly i don't think our request is very hard
[00:31] <pleia2> yikes, the ticket is still active?
[00:31] <wxl> though i guess it does require a wordpress install (read: security hole)
[00:31] <wxl> yep
[00:31] <wxl> let me dig it up
[00:31] <pleia2> that sounds like an oversight
[00:32] <wxl> i've talked to people about it before including IS folks
[00:32] <pleia2> crazy :(
[00:32] <wxl> also before i was on LC, jose was really helpful with trying to push it through
[00:32] <pleia2> xubuntu.org runs on wordpress hosted by canonical, no big deal
[00:32] <pleia2> anyway, I have a meeting to run to
[00:32] <pleia2> have a good evening :)
[00:32] <wxl> pleia2: i was talking about wordpress in a way that i think only a sysadmin would understand XD
[00:32] <wxl> k bai
[00:33] <wxl> USING wordpress is easy
[00:33] <wxl> SECURING wordpress is a whoooole different beast
[00:36] <wxl> pleia2: should you have some interest in the subject, this is the ticket regarding our loco's hosted site https://rt.ubuntu.com/Ticket/Display.html?id=25072 and actually it's been more than a year! that makes our ticket one of the NEWEST ones in the loco queue. oldest was open 8 years ago. so i'll just be patient :O
[07:33] <dholbach> good morning
[07:36] <popey> Morning dholbach :)
[07:36] <dholbach> hey popey
[07:37] <popey> I am not going to be around for at least the first half of the Q&A this afternoon unfortunately. Need to pick kids up from school today.
[07:38] <dholbach> popey: who did last week's?
[07:38] <popey> dunno, not me.
[07:38] <popey> hence raising it because it's my turn
[07:39] <popey> mhall119 did with davidcalle
[07:39] <dholbach> ok
[07:39] <dholbach> I'll ping Nick and dpm later on
[07:39] <popey> kk, off to drop the kids off at school now.. brb
[07:40] <dholbach> see you!
[08:31]  * popey returns
[08:33] <dholbach> balloons, dpm: it looks like it's us for the Q&A later on
[08:34] <dpm> sounds good
[08:45] <davidcalle> Morning o/
[08:58] <popey> pip pip
[10:41] <dholbach> balloons, davidcalle, dpm, mhall119, popey: we should probably get another biweekly update out by the end of the week
[10:42] <dpm> good point
[10:52] <jose> dpm: ping
[10:59] <dpm> hola jose
[10:59] <jose> dpm: todo bien?
[11:00] <dpm> todo bien, a punto para ubucon summit? :)
[11:06] <jose> yep! queria preguntarte si necesitaban una mano con algo
[11:09] <dpm> jose, gracias :) sí, te envío una lista por correo, estaba a punto de crearla
[11:09] <jose> genial
[11:10] <davidcalle> statusupdate-bot: !update
[11:10] <statusupdate-bot> * Fixing stuff
[11:10] <statusupdate-bot> * Fixing more stuff
[11:10] <statusupdate-bot> * Beer!
[11:10] <jose> lol
[11:11] <davidcalle> dholbach, dpm: here is our biweekly update ^ :p
[11:11] <dholbach> haha
[11:11] <dpm> the last one is a wishlist item, isn't it?
[11:12] <davidcalle> dpm, nope, there is a dedicated meeting
[11:32] <dpm> jose, primer mail enviado :)
[11:37] <jose> woot woot
[11:40] <nigelb> wait, what.
[11:40] <nigelb> popey: that was weird.
[11:40] <nigelb> You just approved someone onto the etherpad team and they just deactivated themselves.
[11:40] <popey> also, i mistakenly added them to another team and immediately revoked them
[11:41]  * nigelb hands popey a jug of warm tea
[11:41] <nigelb> Er, *kettle*
[11:41] <nigelb> No wait, it's a pot of tea.
[11:42] <popey> yeah, dunno what they're up to
[12:03] <dpm> jose, ok, segundo y ultimo mail enviado
[12:17] <jose> dpm: respondo ni bien regrese, tengo que correr para algunas cosas
[12:18] <dpm> jose, genial, gracias!
[14:06] <dholbach> balloons, dpm: so it'll be the 3 of us?
[14:06] <dholbach> (for the Q&A?)
[14:06] <dpm> dholbach, I'm up for it
[14:06] <dholbach> yep, me too :)
[14:06] <dpm> cool
[14:07] <dpm> dholbach, do you mind starting with the announcements?
[14:07] <dholbach> can do
[14:07] <dpm> great, thanks
[14:14] <balloons> sounds fun!
[14:15] <dholbach> balloons: does that mean you're part of it or not? :)
[14:15] <dholbach> if yes, I'd include you in the announcement
[14:15] <balloons> dholbach, if you'll have me, of course ;-)
[14:15] <dholbach> ok cool :)
[14:45] <dholbach> ok done
[15:32] <dpm> mhall119, call?
[15:43] <popey> School run.. biab
[15:51] <balloons> we ready dholbach?
[15:51] <dholbach> balloons: yep
[15:55] <dholbach> balloons: you're just on Freenode it seems
[15:55] <balloons> blargh
[15:56] <balloons> my bouncer likes to dc without saying
[17:02] <dholbach> all right my friends - I call it a day - see you all tomorrow! :-)
[23:13] <pleia2> wxl: btw, I am a sysadmin for my Actual Job, so I do know a fair amount about how to secure websites, and I wasn't speaking just as a user of wordpress ;)
[23:13] <wxl> pleia2: i know. that's why i said that XD
[23:13] <pleia2> wxl: in xubuntu we have to get all our plugin and theme patches cleared by IS when we submit them, but the turnaround is pretty quick these days
[23:13] <pleia2> so they do spend time in security review, but not long for us
[23:13] <wxl> well that's good
[23:14]  * pleia2 nods
[23:14] <pleia2> as to the queue for loco teams, I don't know what's up with that, and probably something the LC should look into
[23:14] <pleia2> if Canonical can't reasonably serve LoCos in *less than a year* then it's probably worth cutting the cord and admitting it's not something they realistically offer
[23:15] <pleia2> that at least would reduce the expectation, and give them leave to find alternate hosting
[23:16] <wxl> true true
[23:16] <wxl> so who should we approach about that?
[23:16] <pleia2> someone on the community team here
[23:16] <knome> what are we talking about?
[23:16] <pleia2> knome: web hosting for locos, wxl submitted a ticket for a wordpress blog a year ago, still not done
[23:16] <knome> right
[23:16] <pleia2> knome: and it's apparently the youngest in the loco queue
[23:16] <pleia2> so /o\
[23:16] <wxl> pleia2: and mine is one of the newest in the IS loco queue
[23:17] <wxl> yeah
[23:17] <wxl> that
[23:17] <knome> mhm
[23:17] <wxl> knome: so someone on the council shoudl talk to canonical and see if it's reasonable to still say we CAN handle supporting the locos
[23:17] <wxl> at least in terms of IS
[23:17] <knome> i don't know if it could help, but i have recently pushed this community theme to github: https://github.com/knomepasi/ubuntu-community-wordpress-theme
[23:18] <knome> so maybe they would have easier time with the requests if people just used a few centralized themes and didn't ask this and that
[23:18] <wxl> well that's certainly a problem
[23:18] <pleia2> the california loco (private hosting) uses some version of the unified theme
[23:18] <knome> unified theme?
[23:18] <pleia2> from like 100 years ago
[23:18] <knome> this is from like this year :)
[23:18] <pleia2> there was some community theme
[23:18] <knome> yeah, old as mammoths
[23:19] <pleia2> yeah
[23:19] <knome> https://raw.githubusercontent.com/knomepasi/ubuntu-community-wordpress-theme/master/screenshot.png
[23:19] <wxl> well i'll try to remember to send out an email to the cc and we'll go from there
[23:19] <pleia2> but our site is essentially a splash page, so even wordpress is overkill ;)
[23:19] <pleia2> "we'll install wordpress and add stuff to it later"
[23:19] <pleia2> mhmm
[23:19] <knome> actually, i am on this channel because i've been meaning to ask about people testing that new theme
[23:20] <knome> so wxl, if you haven't decided on a theme and want to give that a run...
[23:20] <pleia2> knome: maybe an email to the mailing list too?
[23:20] <knome> pleia2, on the todo
[23:20] <pleia2> cool
[23:21] <knome> with this theme, you can even change the logo from the wp admin, so no need for anybody to ask for another theme upload separately
[23:21] <wxl> knome: i'd email the loco-contacts list, too
[23:21] <knome> wxl, once we have ironed out the biggest bumps, yeah
[23:23] <knome> what i'd like to know now if there is something that is obviously wrong so i can fix it before people have been spreading the non-production-ready theme all over the internet
[23:23] <knome> at which point it is almost as useful as the age-old community theme
[23:24] <knome> i also wouldn't mind if this theme inspired others to contribute to it
[23:26] <knome> it's also on my todo to talk with balloons to probably get the google code-in participants try this theme out as well
[23:26] <knome> and since you can change colors and stuff from the admin too, it might be a good fit for both ubuntu gnome and ubuntu studio who are seeking for a new wordpress theme
[23:28] <knome> wxl, so instead of asking me to email everybody, would you like to take some time yourself to see if the theme works for you?
[23:28] <wxl> knome: well, once my ticket gets taken care of, perhaps in a few years, sure.
[23:28] <knome> LE sigh
[23:29] <knome> i'll ask somebody else then.
[23:29] <knome> thanks for the support!
[23:29] <pleia2> wxl is a busy person ;)
[23:29] <knome> an i'm not?
[23:29] <wxl> it's not that i'm busy
[23:29] <pleia2> not everyone can help
[23:29] <wxl> i just have nothing to test it on
[23:29] <knome> fortunately, i'm not the one who needs the wordpress theme
[23:30] <wxl> ok here's how we'll do it
[23:30] <wxl> you fly to canonical
[23:30] <wxl> rough up the head of IS a bit
[23:30] <wxl> then my ticket gets approved
[23:30] <wxl> then i try your theme
[23:30] <wxl> easy!
[23:30] <pleia2> wxl: if you want to test it, you could just use virtualbox or something
[23:30] <wxl> yeah i guess i could
[23:31] <wxl> but ANYONE can do that :)
[23:31] <knome> well, if you had read what i said, you'd know i wanted to fix things before it's uploaded on the IS servers so i didn't need to request for updates
[23:31] <pleia2> yes, but so far no one is helping knome test it
[23:31] <pleia2> so he needs folks to test in non-production environments
[23:31] <knome> it's fine, i'll ask somebody else
[23:31] <pleia2> preferably *not* on the internet, so in VMs
[23:31] <knome> i am running it in a staging server on the internet as well
[23:32] <wxl> i could probably juju my way to a wordpress theme huh? :)
[23:32] <knome> i think you are overthinking it
[23:32] <knome> just set up wordpress anywhere with a web server and push the theme there
[23:32] <knome> you can probably juju the web server, but not the theme really
[23:33] <knome> but it's in git, so you only need to git pull
[23:33] <wxl> so i'll let you know when i get a vm set up
[23:33] <knome> sure, thanks
[23:34] <wxl> admittedly this in between work but
[23:35] <knome> there's no rush
[23:35] <knome> you don't need to do it today


[06:16] <mborzecki> morning
[06:17] <mborzecki> starting later today, had to drive kids to school
[07:02] <zyga> Hey mborzecki
[07:02] <zyga> Friday comes so quickly lately
[07:02] <mborzecki> zyga: hey
[07:04] <pstolowski> morning
[07:08] <mborzecki> pstolowski: hey hey
[07:09] <mborzecki> btw. godbus and our unit tests are a bit messy
[07:10] <mup> PR snapd#6046 closed: cmd/snap-confine: remove SC_NS_FAIL_GRACEFULLY <Simple 😃> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6046>
[07:10] <zyga> Thank
[07:17] <mup> PR snapd#6045 closed: cmd/snap-seccomp: only look for PTRACE_GETFPX?REGS where available <Created by chipaca> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6045>
[07:22] <mborzecki> need coffee
[07:47] <mborzecki> Chipaca: what do you think about https://github.com/snapcore/snapd/pull/6042#discussion_r228421624 ?
[07:47] <mup> PR #6042: overlord/standby: fix a race between standby goroutine and stop <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6042>
[07:50] <Chipaca> mborzecki: not a lot
[07:51] <Chipaca> mborzecki: coffee hasn't kicked in
[07:52] <mborzecki> Chipaca: heh same here :)
[08:00] <Chipaca> mborzecki: so
[08:01] <Chipaca> mborzecki: that channel in the test still has the same race
[08:01] <Chipaca> mborzecki: unless i'm missing something :-)
[08:01] <Chipaca> let me apply it locally to test
[08:02] <mborzecki> Chipaca: ok
[08:05] <Chipaca> mborzecki: hm, the patch won't
[08:05] <Chipaca> won't patch i mean
[08:05] <mborzecki> Chipaca: doesn't apply?
[08:05] <Chipaca> right
[08:06] <mborzecki> sec, i'll give you a link then
[08:06] <mborzecki> Chipaca: https://github.com/bboozzoo/snapd/commit/ed331c0c44b8fd776cca49ed1e8a34060eb682e9
[08:07] <Chipaca> mborzecki: did you know you can add ".diff" to the end of that?
[08:07] <mborzecki> omg, really? :)
[08:07] <zyga> yep :)
[08:08] <mborzecki> damn, it works
[08:08] <zyga> anyone for a trivial remove PR https://github.com/snapcore/snapd/pull/6047 ?
[08:08] <mup> PR #6047: cmd: remove remnants of sc_should_populate_mount_ns <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/6047>
[08:09] <zyga> sorry for starting late
[08:09] <zyga> I feel so sleepy
[08:09] <zyga> yesterday was good though, some useful things got done
[08:11] <zyga> https://github.com/snapcore/snapd/pull/6019 needs a 2nd review
[08:11] <mup> PR #6019: ifacestate: optimize disconnect hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6019>
[08:12] <zyga> Chipaca: you commented on https://github.com/snapcore/snapd/pull/6016 before, a formal +1 or -1 would help to decide
[08:12] <mup> PR #6016: [RFC] move various name validation helpers to snap/name package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6016>
[08:12] <Chipaca> zyga: there was a chunk of discussion of the pr, i need to re-read it a bit
[08:13] <zyga> thanks, sure
[08:13] <zyga> disclaimer: I'm not trying to be pushy, just looking at PRs top to bottom
[08:14] <mborzecki> so i'm reading dbus spec and find this: It could be ASCII or UTF-8, but could also be ISO Latin-1 or any other encoding.
[08:15] <mborzecki> aka. surpsise string
[08:15] <mup> PR snapd#5958 closed: NOT-REVIEW: tests: Add debug info main suite <Created by sergiocazzolato> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5958>
[08:15] <mup> PR snapd#6008 closed: client, daemon, cmd/snap: indicate that services are socket/timer activated <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6008>
[08:16] <zyga> mborzecki: aka what were they thinking?
[08:16] <Chipaca> mborzecki: what could be?
[08:18] <mborzecki> Chipaca: linux security label
[08:18] <Chipaca> ah
[08:18] <zyga> pstolowski: is https://github.com/snapcore/snapd/pull/5962/files read y for review?
[08:19] <mup> PR #5962: ifacestate/hotplug: hotplug handlers <Complex> <Hotplug 🔌> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5962>
[08:19] <Chipaca> mborzecki: about standby, I wonder about the need of the nested goroutine
[08:19] <pstolowski> zyga: yes
[08:20] <mborzecki> Chipaca: hm maybe, i wrote that before morning coffee
[08:20] <Chipaca> mborzecki: it seems to me (but i could be wrong) that the second (outer) goroutine and the stopDone channel are spurious
[08:20] <Chipaca> mborzecki: want to merge your changes, and i push more onto it? i've got a couple of tweaks (one of them, dropping that outer goroutine) but otherwise lgtm
[08:21] <zyga> ogra_: can you please check https://github.com/snapcore/snapd/pull/5915
[08:21] <mup> PR #5915: interfaces/network-setup-control: allow calling netplan generate/apply <Created by ogra1> <https://github.com/snapcore/snapd/pull/5915>
[08:21] <Chipaca> i'm not convinced the channel dance is better than the wait, in that i'm not sure it's racy in the same way (just less likely because it's using the 200ms wait from the standby instead of an external 50ms wait) but if you are, i'm happy
[08:21] <mborzecki> Chipaca: you want to merge the whole PR or should i just push that patch to the branch?
[08:22] <Chipaca> mborzecki: to the -proposal branch?
[08:22] <mborzecki> ok
[08:22] <Chipaca> mborzecki: I don't mind
[08:22] <Chipaca> mborzecki: I already pushed to yours:-)
[08:23] <Chipaca> mborzecki: i do that, and then you merge once we agree?
[08:23] <mborzecki> Chipaca: sgtm
[08:24] <zyga> mborzecki: could you please check https://github.com/snapcore/snapd/pull/5789
[08:24] <mup> PR #5789: snap: only show "next" refresh time if its after the hold time <Created by mvo5> <https://github.com/snapcore/snapd/pull/5789>
[08:25] <zyga> Chipaca: can you look at https://github.com/snapcore/snapd/pull/5712 - it is green and has two reviews, I wonder if we should just merge it
[08:25] <zyga> (perhaps re-triggering tests to see if it really passes now)
[08:25] <mup> PR #5712: overlord: make InstallMany work like UpdateMany, issuing a single request to get candidates <Reviewed> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5712>
[08:28] <Chipaca> zyga: no plz
[08:30] <Chipaca> zyga: samuele hasn't merged it because it needs more tests
[08:30] <zyga> k
[08:30] <zyga> I'll add blocked
[08:31] <Chipaca> zyga: add a comment about why, then :-)
[08:31] <Chipaca> zyga: 1 sec let me give you a link
[08:31] <zyga> done
[08:31] <zyga> oh?
[08:32] <zyga> just comment on the PR :)
[08:32] <Chipaca> zyga: https://irclogs.ubuntu.com/2018/10/04/%23snappy.html#t19:52
[08:33] <zyga> ta
[08:33] <Chipaca> commented also
[08:33] <mup> PR snapd#5885 closed: Adding DPDK interface for DPDK Snap <Decaying ☢> <Created by wililupy> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5885>
[08:34] <zyga> with a few simple reviews we will be on one page
[08:36] <mup> PR snapd#6047 closed: cmd: remove remnants of sc_should_populate_mount_ns <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6047>
[08:37] <zyga> Chipaca: can we merge https://github.com/snapcore/snapd/pull/6025 or would you rather wait until Gustavo sees it?
[08:37] <mup> PR #6025: Add go.mod files <Created by ryanjyoder> <https://github.com/snapcore/snapd/pull/6025>
[08:37]  * zyga goes to review https://github.com/snapcore/snapd/pull/6034
[08:37] <Chipaca> zyga: it feels like he should be at least aware of it, n'eh?
[08:38] <mup> PR #6034: many: save media info when installing, show it when listing <Created by chipaca> <https://github.com/snapcore/snapd/pull/6034>
[08:38] <zyga> yep, I'll add blocked
[08:38] <Chipaca> zyga: and tag him please
[08:38] <Chipaca> zyga: 6034, tag it for pedronis please
[08:38] <Chipaca> zyga: thank you :-)
[08:38] <zyga> k
[08:40] <Chipaca> mborzecki: tell me what you think of that (re 6042)
[08:44] <Chipaca> degville: morning sir
[08:58] <degville> Chipaca: morning!
[09:00] <Chipaca> degville: was just wanting to check if you'd had time to look at the changes to https://github.com/snapcore/snapd/pull/5955/files
[09:00] <mup> PR #5955: cmd/snap, tests: snapshots for all <Snapshots 📸> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5955>
[09:00] <degville> Chipaca: yes, sorry - looking now.
[09:01] <Chipaca> degville: ok no problem
[09:01] <Chipaca> degville: thank you
[09:07] <mup> PR snapd#6049 opened: cmd/snap, userd, testutil: tweak DBus tests to use private session bus connection <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6049>
[09:07] <mborzecki> Chipaca: zyga: hope this may fix userd/dbus issues we're seeing in tests
[09:07] <mborzecki> ^^
[09:07] <Chipaca> looking
[09:07] <zyga> mmm
[09:10] <zyga> mborzecki: I'm not familiar with private connections, can you explain that a little more?
[09:10] <zyga> the code looks fine
[09:10] <zyga> just not sure I understand the problem enough to give meaningful vote
[09:10] <mborzecki> zyga: that's just a separate connection, i.e. with the changes the DBus test suite and userd use separate connections
[09:11] <zyga> for test suite I sort of understand
[09:11] <zyga> but for userd I don't
[09:11] <zyga> separate from what/
[09:11] <mborzecki> from nothing else atm
[09:12] <zyga> aha
[09:14] <Chipaca> mborzecki: the problem is that the dbus module shares the connection?
[09:14] <mborzecki> Chipaca: yes
[09:14] <Chipaca> ie two things doing dbus.SessionBus() get the same thing
[09:15] <mborzecki> yup
[09:15] <zyga> ahh
[09:15] <Chipaca> and then one of them closes it and the other one says 'wuuut'
[09:15] <zyga> that's wonky
[09:15] <zyga> +1 then
[09:15] <mborzecki> and if you do say go test -count=n it breaks too
[09:15] <Chipaca> yeh :-)
[09:17] <mborzecki> now i need to remind myself of what i was doing before i started fixing those tests :)
[09:18] <zyga> can you review https://github.com/snapcore/snapd/pull/6048 before doing that :D
[09:18] <mup> PR #6048: cmd/snap-exec: don't fail on some try mode snaps <Created by zyga> <https://github.com/snapcore/snapd/pull/6048>
[09:22] <mborzecki> Chipaca: now that i see it, `opineReady <- struct{}{}` could be just `close(opineReady)`, but otherwise +1
[09:23] <mborzecki> actually I'll push that
[09:26] <mborzecki> Chipaca: pushed
[09:26] <Chipaca> mborzecki: :-D
[09:26] <mborzecki> so now zyga and pstolowski must approve :P
[09:27] <zyga> which one?
[09:27] <mborzecki> zyga: #6042
[09:27] <mup> PR #6042: overlord/standby: fix a race between standby goroutine and stop <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6042>
[09:27] <zyga> mborzecki: after the media PR from John
[09:27] <zyga> brb, coffee
[09:30] <mborzecki> Chipaca: don't remember, did we already have a pr for blocking installing confined snaps with --classic?
[09:31] <mborzecki> or was it you working on this?
[09:32] <Chipaca> mborzecki: #6039
[09:32] <mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
[09:33] <Chipaca> not super happy with that pr
[09:33] <Chipaca> but i can only so much
[09:33] <Chipaca> but, no error kind, meaning no user-facing error message
[09:33] <mborzecki> heh, surising that someone actually tries to install snaps like this
[09:33] <Chipaca> mborzecki: it's the same person that 'rm -rf /' on a core system to see if they could break it
[09:34] <Chipaca> :-D
[09:34] <Chipaca> (hint: they could)
[09:34] <mborzecki> i think rm -rf / doesn't work anymore
[09:34] <mborzecki> not without some extra --foo switch
[09:34] <Chipaca> well, they had to add the --extra-foo
[09:34] <popey> --no-preserve-root
[09:35] <Chipaca> popey: hush you'll blow your cover
[09:35] <popey> --i-know-what-im-doing --honest
[09:35] <Chipaca> mborzecki: the fix to that was making things immutable, but testing it is a pain
[09:35] <mborzecki> well, there should be a switch for dd to :P
[09:36] <Chipaca> mborzecki: so we've got a chattr implementation to do it, but didn't get to _actuallly_ do it :-/
[09:36] <Chipaca> mborzecki: linux is going soft in its old age
[09:37] <Chipaca> these days you can't even mkfs /dev/sda without it saying "are you sure dude?"
[09:37] <mborzecki> haha
[09:50] <mborzecki> #6039 unit tests are passing locally, but not on travis
[09:50] <mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
[09:50] <mborzecki> hm maybe something new in master
[09:52] <tomwardill> another question... If I install a snap from the store, then install a development version of it (using --dangerous), would the pre-refresh hook run?
[09:52] <mborzecki> pstolowski: ^^
[09:54] <pstolowski> tomwardill: yes
[09:54] <tomwardill> pstolowski: lovely, thankyou
[09:55] <zyga> Chipaca: I reviewed the media PR
[09:56] <zyga> looking at https://github.com/snapcore/snapd/pull/6042/
[09:56] <mup> PR #6042: overlord/standby: fix a race between standby goroutine and stop <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6042>
[10:25] <pstolowski> looking at it as well
[10:25] <Chipaca> zyga: https://play.golang.org/p/lRvxLmTlypq
[10:26] <zyga> right, I get that but I think the wording is unintuitive
[10:27] <Chipaca> ah ok
[10:27]  * Chipaca goes to the gym
[10:30]  * Chipaca really goes
[10:40] <pstolowski> #6019 needs 2nd review
[10:40] <pstolowski> and is green
[10:40] <mup> PR #6019: ifacestate: optimize disconnect hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6019>
[10:41] <mborzecki> shall we land #6042? or does anyone want another look?
[10:41] <mup> PR #6042: overlord/standby: fix a race between standby goroutine and stop <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6042>
[10:41] <mup> PR snapd#6049 closed: cmd/snap, userd, testutil: tweak DBus tests to use private session bus connection <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6049>
[10:59]  * pstolowski lunch
[11:23] <mborzecki> Chipaca: do you have any tests skipped in overlord/snapstate?
[11:24] <cachio> mborzecki, hey, about the error on + systemctl restart snapd.socket
[11:24] <cachio> Job for snapd.socket failed.
[11:24] <mborzecki> cachio: hi, any progress there?
[11:25] <cachio> mborzecki, well, it is fixed if I restart snapd.service too
[11:25] <cachio> It is like a race with the dependencies
[11:26] <cachio> I see in the logs that snapd.seeded.service fails to restart
[11:26] <cachio> and then snapd.socket fails too
[11:26] <cachio> it is happening mostly on debian
[11:27] <cachio> is it a good solution to restart the snapd.service as well?
[11:28] <mborzecki> hm i think snapd.seeded fails because the socket failed
[11:29] <mborzecki> cachio: if you restart snapd.service then it won't be socket activated in the tests anymore
[11:29] <cachio> I am restarting both  in fact
[11:29] <mborzecki> snapd and snapd.socket?
[11:29] <cachio> mborzecki, does it make sense?
[11:29] <cachio> yes
[11:30] <mborzecki> cachio: show abou systemctl stop snapd && systemctl restart snapd.socket ?
[11:30] <mborzecki> maybe it's snapd proper and systemd racing to creat the socket?
[11:30] <cachio> yes, systemctl restart snapd.{service,socket}
[11:32] <mup> PR snapd#6050 opened: overlord/snapstate: run tests for classic snaps even on systems that don't support classic <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6050>
[11:33] <cachio> mborzecki, this is the error https://paste.ubuntu.com/p/6mNsDRNRYy/
[11:34] <cachio> that's why I restarted first the snapd service
[11:36] <popey> Chipaca: joining us for snapd catchup?
[11:38]  * popey assumes not
[11:53] <Chipaca> popey: sorry :-(
[11:53] <Chipaca> popey: was mvo there?
[11:53] <Chipaca> mborzecki: tests skipped where?
[11:56] <Chipaca> mborzecki: $ grep -r '\.Skip(' overlord/snapstate/  | sort | uniq -c
[11:56] <Chipaca>      12 overlord/snapstate/snapstate_test.go:		c.Skip("no support for classic")
[11:56] <mborzecki> Chipaca: right, but if you run go test overlord/snapstate then there are no tests skipepd on your system, right?
[11:56] <Chipaca> mborzecki: a ver...?
[11:58] <Chipaca> mborzecki: OK: 461 passed
[11:58] <Chipaca> mborzecki: compare with go test -v -short cmd/snap: OK: 330 passed, 13 skipped
[11:58] <Chipaca> ./cmd/snap i mean
[11:58] <Chipaca> mborzecki: why?
[11:59] <mborzecki> Chipaca: #6050 makes all of overlord/snapstate run on my system
[11:59] <mup> PR #6050: overlord/snapstate: run tests for classic snaps even on systems that don't support classic <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6050>
[11:59] <Chipaca> why wouldn't it?
[12:00] <Chipaca> does your system not support classic?
[12:00] <mborzecki> Chipaca: no, arch does not
[12:00] <Chipaca> aw
[12:01] <mborzecki> i can add symlink, but the tests shouldn't rely on that
[12:01] <Chipaca> right
[12:01] <Chipaca> given they should be setting global root to some tmpdir, they could create the symlink in there
[12:03] <Chipaca> dang i need to make lunch for the troop
[12:03] <Chipaca> brb
[12:04] <mup> PR snapd#6048 closed: cmd/snap-exec: don't fail on some try mode snaps <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6048>
[12:05] <popey> Chipaca: np, sadly not
[12:10] <mborzecki> off to pick up the kids
[12:23] <ogra> zyga, that netplan PR requires some extra time for re-doing my snap with changed profile etc ... that will still take a bit ... though jdstrand pointed to a thread where it all has been tested, we should probably just use that as input
[12:23] <zyga> ogra: thanks, anytime you can do it is fine
[12:24] <ogra> greyback, yo ! ... i'm trying to get a simple SDL2 pictureviewer to work natively on mir-kiosk, i belive everything is correct but i still end up with "SDL Failed to create window: failed to create a window surface" when trying to start the app
[12:24] <ogra> greyback, the tutorials are rather sparse in that regsrd
[12:25] <ogra> *regard
[12:25] <greyback> ogra: for a reason :) Every toolkit can/wil be different
[12:26] <greyback> ogra: if you test on your desktop, does it work? So run miral-kiosk, then set the wayland socket env var, and run that sdl app
[12:26] <ogra> greyback, well, i dont want to use xwayland (which i surely could as fallback) ...
[12:27] <ogra> greyback, hmm whats that var ? do i need to explicitly set it in a kiosk launcher ? (i see the wayland-0 socket)
[12:28] <greyback> ogra: ofc. Pure SDL2 should work on top of Mir. I've not tried it in a while. What app?
[12:28] <ogra> imv ... but with a wrapper etc
[12:28] <greyback> ogra: that mir kiosk launcher script will take care of the env var for oyu
[12:28] <ogra> which one ? i wrote my own :)
[12:29] <greyback> ogra: "miral-app"
[12:29] <ogra> well, how do i get that into my snap ?
[12:29] <ogra> mir-kiosk surely doesnt ship it
[12:30] <greyback> ogra: nope it doesn't. I'm not worrying about snaps just yet, I want to check that sdl app runs on top of Mir at all
[12:30] <ogra> well, where is the source for miral-app so i can pull it into my snap ?
[12:30] <popey> greyback: what sdl2 apps have you tried?
[12:31] <ogra> https://tutorials.ubuntu.com/tutorial/wayland-kiosk#3 is really sparse ...
[12:31] <ogra> err https://tutorials.ubuntu.com/tutorial/wayland-kiosk#0
[12:31] <greyback> ogra: https://github.com/MirServer/mir/blob/master/examples/miral-shell/miral-run.sh
[12:32] <greyback> ogra: yes you're right, it is sparse
[12:33] <popey> Chipaca: i was going to raise this at the meeting btw. https://forum.snapcraft.io/t/ubuntu-core-doesnt-batch-reboots/8174/1
[12:33] <popey> ogra: ^ I mentioned before that core reboots multiple times, this shows it
[12:34] <greyback> popey: tbh I didn't. I snapped gtk2/3 and qt4/5. I know sdl2 works on mir, I never tried snapping one
[12:34] <popey> be nice to have some hello world level tutorials of those
[12:34] <popey> which aren't massively wordy tomes
[12:34] <pstolowski> Chipaca, mborzecki, zyga, cachio I'll probably miss the standup, need to pick up my daughter returning from school trip
[12:34] <popey> just "here's the yaml, here's the snap, done"
[12:34] <zyga> pstolowski: ack
[12:35] <greyback> popey: agreed
[12:35] <zyga> popey: here's the jam, here's the snack, done
[12:35] <zyga> ;-)
[12:38] <popey> cprov: is there any more comprehensive docs on using surl than the readme?
[12:39] <zyga> surl?
[12:39] <diddledan> curl?
[12:40]  * diddledan hurls the surl with a curl making it whirl.
[12:41] <popey> https://github.com/cprov/surl / https://snapcraft.io/surl
[12:43] <diddledan> yeah, that readme needs moar details
[12:43] <ogra> popey, yeah, saw the post
[12:44] <diddledan> e.g. what is the `-a` parameter for? does it accept anything other than `stg-reg`? what does `stg-reg` even mean?
[12:44] <ogra> greyback, ok, now after setting MIR_SOCKET and WAYLAND_DISPLAY (i made sure i can see and access the files they point to), i get "SDL Failed to Init: wayland not available"
[12:45] <popey> diddledan: oi! I was first in the queue! :D
[12:45] <diddledan> popey: 2x2?
[12:45] <popey> :)
[12:45]  * diddledan holds popey's hand and stands along side to go in together like good little boys
[12:46] <zyga> oh, surl is nice :)
[12:47] <zyga> Chipaca: did you see that a?
[12:57] <mborzecki> re
[12:57] <mborzecki> surl? small curl?
[12:59] <Chipaca> zyga: which a?
[12:59] <ogra> the one before b ?
[12:59] <zyga> sorry, not a ;) surl
[12:59] <Chipaca> zyga: i have not. Have you seen icdiff?
[12:59] <zyga> no I have not
[13:00] <Chipaca> now we're even
[13:00]  * Chipaca heads to the standup
[13:00] <Chipaca> or is that stands for the standup
[13:21] <dot-tobias> greyback, ogra: Re: chromium-mir-kiosk rotation issue – here are my findings https://forum.snapcraft.io/t/cross-post-chromium-mir-kiosk-in-portrait-mode-rotated-mir-kiosk-layout/8175
[13:23] <ogra> dot-tobias, did you consider simply not using i3 ?
[13:25] <greyback> dot-tobias: thanks for that excellent post.
[13:25] <dot-tobias> ogra: I do, but I am completely out of my depth here when it comes to display servers and the likes. And I need to get a portrait mode-kiosk running ASAP because the beta testers are already waiting 😄
[13:26] <greyback> dot-tobias: I'll see what I can figure out now then
[13:26] <greyback> dot-tobias: you're making a product with it?
[13:27] <ogra> dot-tobias, well, i have the mirkiosk snap in the store that i'm planning to do an appliance with soon ... but i wot start on the integration work before next week ... then i'll hit (and hopefully solve) the same issues
[13:28] <ogra> currently i'm sadly struggling with unexpected SDL2 issues for a native wayland slideshow appliance (picture-frame appliance)
[13:29] <ogra> err
[13:29] <ogra> s/mirkiosk/magicmirror/
[13:29] <ogra> silly typo ... too much mir in my head now
[13:30] <dot-tobias> ogra: 😄 Excited to see how you'll tackle these issues (with way more proficiency in this stack)
[13:31] <ogra> i'll probably simply hack around the issues i hit ... like using matchbox or openbox if they can behave more dynamic than i3 ... or hacking xrandr calls into the launcher or some such :)
[13:32] <tomwardill> ogra: I am excited to see magicmirror as a snap, I've got a Pi display on it's way to me atm
[13:32] <ogra> i also still have to solve some issues with magicmirror itself ... getting the modules in a writable area while keeping the runtime code readonly seems extremely hard without patching upstream
[13:33] <ogra> i initially tried to simply ship all available modules by default ... but somehow a 6.2GB source tree resulted from that (and a 700MB snap) ... that feels a bit like overkill :)
[13:34] <Chipaca> degville: writing is hard. Maybe I'll just replace the help text with emoji.
[13:34] <Chipaca> degville: 📸🖒
[13:34] <degville> Chipaca: yeah.
[13:34] <degville> +1
[13:35] <tomwardill> ogra: I'd probably try and get a config variable or something upstreamed at that point
[13:35] <tomwardill> but I've no idea how feasible that is
[13:35] <ogra> yeah
[13:36] <ogra> i havent talked to upstream yet ... the prob is that the code uses relative paths inside ... like ... everywhere
[13:36] <ogra> foo=../../bar ... and such
[13:36] <ogra> as soon as you operate with a symlink into $SNAP_DATA these relative paths break
[13:37] <Chipaca> ogra: keeping in mind i have no context, layouts might help
[13:37] <ogra> sigh ... so mir and SDL2 seems like a no-go ... and i dont really want the 120MB overhead adding the desktop launcher and xwayland stuff :((((
[13:38] <ogra> Chipaca, they do, but are they not holding my snap upload anymore at the review steap ?
[13:38] <ogra> *step
[13:38] <dot-tobias> ogra: My use-case is a smart mirror as well 😊 And layouts (plus massive help from zyga) helped tremendously to cope with Rails and its assumption that everything lives inside its root directory.
[13:39] <ogra> Chipaca, developing on core requires a painful amount of patience since all features i need to use make my packages go stuck until jdstrand finds the time to review ...
[13:39] <ogra> so i always try to find a way around experimental features if possible
[13:40] <ogra> it typically means my turnaround time for finishing a demo extends by about a week
[13:41] <mup> PR snapd#6051 opened: cmd/snap-update-ns: parse the -u <uid> command line option <Created by zyga> <https://github.com/snapcore/snapd/pull/6051>
[13:41] <ogra> greyback, are we sure the xenial SDL2 can actually work with mir-kiosk ?
[13:41] <zyga> Chipaca: can we land https://github.com/snapcore/snapd/pull/6042
[13:41] <mup> PR #6042: overlord/standby: fix a race between standby goroutine and stop <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6042>
[13:41] <ogra> (has anyone tested that ?)
[13:42] <zyga> https://github.com/snapcore/snapd/pull/6019 needs a 2nd review
[13:42] <mup> PR #6019: ifacestate: optimize disconnect hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6019>
[13:43] <mup> PR snapd#6042 closed: overlord/standby: fix a race between standby goroutine and stop <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6042>
[13:43] <zyga> koza_: ping
[13:43] <zyga> koza_: can you please fix https://github.com/snapcore/snapd/pull/5897#issuecomment-433412089 - merge master as well if you can please
[13:43] <ogra> zyga, i think he is travelling
[13:43] <mup> PR #5897: interfaces/builtin: add device-buttons interface for accessing events <Created by bergotorino> <https://github.com/snapcore/snapd/pull/5897>
[13:44] <dot-tobias> zyga: Is there a timeline when layouts will no longer prevent automated reviews, as they're now out of beta AFAIR?
[13:44] <zyga> cachio: there's one question from chipaca on https://github.com/snapcore/snapd/pull/5714#issuecomment-430589737
[13:44] <mup> PR #5714: tests: new test for cifs-mount interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5714>
[13:44] <zyga> dot-tobias: I think that is a good question
[13:45] <zyga> dot-tobias: given that some people are sprinting today I think we will know next week (Tuesday is a good day to ask)
[13:45] <zyga> dot-tobias: I think they will be out of review mode once 2.36 ships
[13:45] <zyga> or was that 2.35 (/me never knows)
[13:45] <dot-tobias> zyga: Ok, great! Thanks for the info
[13:46] <zyga> jdstrand: ^ will layouts be blocked by store review after 2.36 ships?
[13:46] <zyga> Chipaca, degville: is https://github.com/snapcore/snapd/pull/5955 good for landing?
[13:46] <mup> PR #5955: cmd/snap, tests: snapshots for all <Snapshots 📸> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5955>
[13:47] <Chipaca> zyga: we're still hashing out the last tweaks to docs
[13:47] <zyga> +1
[13:47] <zyga> merge when ready
[13:47] <Chipaca> there's one paragraph that's stumped us a bit
[13:47] <zyga> it looks very nice
[13:47]  * zyga reads the new things
[13:47] <Chipaca> i've got a bunch of changes
[13:47] <Chipaca> and waiting to see if we can figure out the last one
[13:47] <Chipaca> otherwise i'll just push what i've got and land when green
[13:49] <zyga> https://github.com/snapcore/snapd/pull/5955#discussion_r228533627 for one crazy idea
[13:49] <mup> PR #5955: cmd/snap, tests: snapshots for all <Snapshots 📸> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5955>
[13:49] <zyga> mborzecki: can you do a quick pass over https://github.com/snapcore/snapd/pull/6051
[13:49] <mup> PR #6051: cmd/snap-update-ns: parse the -u <uid> command line option <Created by zyga> <https://github.com/snapcore/snapd/pull/6051>
[13:50] <cachio> zyga, ahh, let me see that, I already tested mount.cifs and it was failing but I don't remember the error
[13:50] <zyga> cachio: thanks! :)
[13:50] <zyga> mborzecki: and you could do a 2nd re-review of https://github.com/snapcore/snapd/pull/5789
[13:50] <mup> PR #5789: snap: only show "next" refresh time if its after the hold time <Created by mvo5> <https://github.com/snapcore/snapd/pull/5789>
[13:50] <zyga> with a few more reviews we could be at < 25 in a few minutes
[13:54] <zyga> mborzecki: and perhaps something actionable on https://github.com/snapcore/snapd/pull/5792 - not sure
[13:54] <mup> PR #5792: [RFC] {config,snap}state: add new refresh.metered=force option and flip default <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5792>
[13:55]  * zyga stops harassing people for reviews
[13:57] <mborzecki> on #6039, refreshing from --classic to strict (as in the next revision is strict) should not be blocked i presume
[13:57] <mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
[13:58] <mborzecki> (i'm down to one failing unit test which does exactly this scenario)
[14:01] <zyga> mborzecki: yes, I agree
[14:01] <zyga> yeah :)
[14:01] <zyga> I had a stab at it last night and gave up
[14:03]  * zyga -> dog
[14:11] <cprov> popey: no, we started mentioning it in store docs (https://dashboard.snapcraft.io/docs/v2/en/api-store-info.html), but it needs more love
[14:15] <diddledan> I know the feeling. I need more love, too ;-p
[14:28]  * cachio afk
[14:28] <mborzecki> yup all unit tests passing now
[14:32] <mborzecki> Chipaca: pstolowski: could you do a 2nd review of this change https://github.com/snapcore/snapd/pull/6050 ?
[14:32] <mup> PR #6050: overlord/snapstate: run tests for classic snaps even on systems that don't support classic <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6050>
[14:33] <Chipaca> mborzecki: i'm -0 on it as proposed so i'd rather not :-)
[14:35] <mborzecki> Chipaca: you'd rather see this done in test setup?
[14:35] <Chipaca> wait
[14:35] <Chipaca> mborzecki: sorry wrong pr
[14:35] <Chipaca> ETOOMANYBALLSINJUGGLE
[14:36] <Chipaca> let me wade out of these failing tests and i can review if pstolowski didn't beat me to it
[14:36] <mborzecki> https://www.youtube.com/watch?v=1D5Sa2Yq-2g
[14:37] <pstolowski> mborzecki: looking
[14:38] <Chipaca> mborzecki: more like https://youtu.be/3vyGMrQ0MBo?t=34
[14:41] <mborzecki> Chipaca: hmm pstolowski just +1 ed it, want to me hold off merging it?
[14:42] <Chipaca> mborzecki: no no
[14:42] <Chipaca> mborzecki: the one i'm not too happy about is the --classic error one
[14:42] <Chipaca> but -0, ie non-blocking
[14:43] <mup> PR snapd#6050 closed: overlord/snapstate: run tests for classic snaps even on systems that don't support classic <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6050>
[14:46] <greyback> ogra: yeah this doesn't work at all. Xenial sdl2 uses glx directly, even when wayland backend selected. Works ok on bionic. This needs fixing
[14:46] <ogra> aha
[14:47] <ogra> ... another estimated 10min job that turned into a day of hackery :(
[14:47] <ogra> i'm trying to resort to xwayland but that doesnt work either now :(
[14:48] <ogra> greyback, "You need to connect this snap to one which implements the wayland-socket-dir plug." ... wasnt that dropped long ago ?
[14:49] <greyback> ogra: it was, where you find that?
[14:49] <ogra> in my snap :P
[14:49] <ogra> i just added after: [ xwayland-kiosk-helper, desktop-gtk2 ] ... the respective env vards and launchers ...
[14:50] <greyback> ogra: clean and refetch?
[14:50] <greyback> xwayland-kiosk-helper anyway
[14:51] <ogra> i clean and rebuild all the time
[14:51] <zyga> small planned power outage
[14:51] <zyga> I'll be back online in ~30 minutes
[14:52] <greyback> ogra: I've no idea how you get that then. This is the xwayland-kiosk-helper script: https://github.com/MirServer/xwayland-kiosk-helper/blob/master/xwayland-preload/xwayland-kiosk-launch
[14:53] <ogra> greyback, definitely not what lands in the prime dir here
[14:53] <ogra> greyback, http://paste.ubuntu.com/p/Yy4hdrrwGg/
[14:54] <greyback> right, that's old
[14:54] <ogra> yeah
[14:54] <zyga> and now on battery power while the power line is adjusted around here
[14:54] <ogra> and i'm 100% sure i have the new one in the other builds i did two weeks ago ... on the same host
[14:56] <ogra> greyback, are you sure the parts entry on the wiki points to master ?
[14:56] <greyback> ogra: as if the old remote part url was cached
[14:56] <greyback> ogra: yep, just double-checked
[14:56] <ogra> weird
[14:56] <ogra> let me run snapcraft update
[14:57] <ogra> the thing is that i built other snaps before that had the right part
[14:57] <ogra> on the very same machine
[14:57] <greyback> bizarre
[14:58] <mborzecki> Chipaca: pushed to mvo's PR, probably even more reason for -1 now :)
[14:59] <ogra> icviewer[4019]: #################################################################################
[14:59] <ogra> icviewer[4019]: NOTICE: the 'wayland-socket-dir' interface has been removed!
[14:59] <ogra> icviewer[4019]: Remove reference to it and WAYLAND_SOCKET_DIR from your snapcraft.yaml.
[14:59] <ogra> icviewer[4019]: Consult the instructions in
[14:59] <ogra> icviewer[4019]: https://github.com/MirServer/xwayland-kiosk-helper/blob/master/snapcraft.yaml
[14:59] <ogra> icviewer[4019]: #################################################################################
[14:59] <ogra> nope ...
[14:59] <ogra> didnt help
[14:59] <ogra> oh
[14:59] <ogra> it did :P
[15:00] <diddledan> /kick ogra FLOOOOOOOOD :-p
[15:00] <ogra> but it doesnt start anyway :/
[15:00] <ogra> what a mess ...
[15:01] <ogra> greyback, huh ?!? ... why the heck do you exit 5 after this message instead of just unsetting WAYLAND_SOCKET_DIR quietly
[15:02] <greyback> ogra: to force people to migrate. I didn't think it would impact many people
[15:02] <greyback> sorry, you're in the awkward transition period
[15:03] <ogra> yeah, there are probably only 5 people like me in the world atm :P
[15:04]  * ogra re-builds the snap from scratch again
[15:06] <ogra> ok, it starts now ...
[15:06]  * ogra finally starts his actual work
[15:08] <zyga> ...and we have one page of reviews now :)
[15:08] <mup> PR snapd#5789 closed: snap: only show "next" refresh time if its after the hold time <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5789>
[15:09] <zyga> https://github.com/snapcore/snapd/pull/6019 is simple and needs a 2nd review
[15:09] <mup> PR #6019: ifacestate: optimize disconnect hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6019>
[15:19] <zyga> cachio: there's a conflict on v
[15:19] <zyga> https://github.com/snapcore/snapd/pull/5887
[15:19] <mup> PR #5887: tests: moving core-snap-refresh-on-core test from main to nested suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5887>
[15:19] <zyga> cachio: and please let me know once you have details about 2.36 regression
[15:22] <zyga> cachio: small tweak required to fix test in https://github.com/snapcore/snapd/pull/5714
[15:22]  * zyga is eager to end the week with ~20 PRs
[15:22] <mup> PR #5714: tests: new test for cifs-mount interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5714>
[15:23] <zyga> Chipaca, mborzecki, pstolowski: can we try to get as many reviews as we can
[15:23] <zyga> the week is almost over
[15:23]  * Chipaca hugs zyga
[15:23] <pstolowski> yep! 6019 needs just 1 more review ;) and is easy
[15:23] <zyga> reviews help move everyone
[15:24] <Chipaca> zyga: i'm afraid the epoch thing takes priority today, but i should be out of the woods in an hour or so
[15:28] <zyga> Chipaca: I was about to say that I was planning to be out here and in the woods in an hour but it's dark and cold so ...
[15:31] <mup> PR snapcraft#2386 opened: project_loader: raise error if part in after is undefined <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2386>
[15:34] <Chipaca> yea i was going to go for a run but here i am
[15:39] <zyga> pstolowski: thank you for the review
[15:41] <pstolowski> yw
[15:47] <cachio> zyga, sure, working on it #5714
[15:47] <mup> PR #5714: tests: new test for cifs-mount interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5714>
[15:47] <zyga> thank you :)
[15:50] <zyga> pstolowski: updated now
[15:50] <pstolowski> looking
[15:53] <zyga> mborzecki: errors on https://github.com/snapcore/snapd/pull/6039
[15:53] <mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
[15:56] <mborzecki> zyga: heh, right the snap was already installed earlier in the test
[16:02]  * Chipaca went for tea and accidentally muffins /o\
[16:03] <Chipaca> in my defence, the tests are taking a long time :-D
[16:03] <Chipaca> zyga: any reviews of note?
[16:03] <zyga> Chipaca: go for low hanging fruit :)
[16:03] <zyga> or for stuff that needs the last prod to move
[16:03] <zyga> we are on one page now :)
[16:03]  * Chipaca goes for watermelons
[16:04] <zyga> mborzecki: iterating on unsigned uid
[16:04] <Chipaca> zyga: unsigned uid?
[16:04] <zyga> parsing :)
[16:04] <Chipaca> as opposed to "lol i don't care that uids are unsigned" go?
[16:05] <zyga> Chipaca: I should have called it
[16:05] <zyga> int cookie
[16:05] <zyga> then nobody would object ;)
[16:05] <Chipaca> but then you'd want cookies
[16:05] <zyga> void *data
[16:05]  * zyga runs
[16:05] <mborzecki> fwiw go uses int for uids so there's that
[16:06] <zyga> Chipaca: I think https://github.com/snapcore/snapd/pull/6041 is your kind of review
[16:06] <mup> PR #6041: client, cmd/daemon: allow disabling keepalive, improve degraded mode unit tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6041>
[16:06] <zyga> mborzecki: you saw https://github.com/snapcore/snapd/pull/6039 - right?
[16:06] <mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
[16:06] <zyga> https://github.com/snapcore/snapd/pull/6019 is low hanging landing
[16:06] <mup> PR #6019: ifacestate: optimize disconnect hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6019>
[16:06] <mborzecki> zyga: yes, i'm waiting for spread run to finish
[16:06] <zyga> https://github.com/snapcore/snapd/pull/6016 could land if someone says yes
[16:06] <mup> PR #6016: [RFC] move various name validation helpers to snap/name package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6016>
[16:07] <zyga> as could https://github.com/snapcore/snapd/pull/5982
[16:07] <mup> PR #5982: interfaces/many: conditionally use 'unsafe' with docker-support change_profile rules <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5982>
[16:07] <mborzecki> zyga: 6016 needs more discussion probably
[16:07] <zyga> mborzecki: yeah but it could also land ;)
[16:07] <Chipaca> and if instead of reviewing … i push a new one?
[16:07] <zyga> Chipaca: gaah,
[16:07] <zyga> we would have pagination
[16:07] <zyga> please don't break GitHub ;)
[16:08] <Chipaca> oops
[16:08] <zyga> https://github.com/snapcore/snapd/pull/5887 has 0 reviews
[16:08] <mup> PR #5887: tests: moving core-snap-refresh-on-core test from main to nested suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5887>
[16:08] <mup> PR snapd#6052 opened: snap, store, overlod/snapstate: always send epochs <Created by chipaca> <https://github.com/snapcore/snapd/pull/6052>
[16:08] <zyga> but it also has a conflict so
[16:08] <zyga> Chipaca: maan, now I have to review it :)
[16:10] <Chipaca> zyga: yes, yes you do
[16:10] <mup> PR snapd#6041 closed: client, cmd/daemon: allow disabling keepalive, improve degraded mode unit tests <Created by bboozzoo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6041>
[16:10] <Chipaca> we should add a "notice me sempai" tag for gustavo
[16:11] <Chipaca> senpai*
[16:12] <Chipaca> travis has this "can fail" thing
[16:12] <Chipaca> where you can have tests that can fail and it doesn't block a merge
[16:13] <Chipaca> i'm not saying we should use it for distros that can't keep their mirrored ducks in a line, but *cough* opensuse *cough*
[16:13] <zyga> Chipaca: done
[16:15] <zyga> back to C
[16:16] <zyga> mborzecki: ^ if you want to do more last minute before EOW PRs then the one from Chipaca about epochs would be great
[16:28] <zyga> mborzecki: updated the parser based on your feedback
[16:32] <mborzecki> zyga: i think the code still allows 0x123 and 0123, if we want to support it then i guess it's ok
[16:32] <mborzecki> pushed a last patch to #6039, calling it eow, need to help kids with homework
[16:33] <zyga> it doesn't - I will push one more test
[16:33] <mup> PR #6039: snapstate: do not allow classic mode for strict snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/6039>
[16:33] <zyga> mborzecki: thank you! enjoy the weekend and see you next week
[16:33] <mborzecki> zyga: thanks, you too
[16:38] <zyga> Chipaca: ok, anything I can review?
[16:47] <Chipaca> zyga: stacked on the snapshots one, so nah
[16:49] <zyga> mmm
[16:49] <zyga> I shall EOD then
[17:13] <Chipaca> zyga: for next week, i'd like to figure out how to print e.g. "El Capitan" in the "darwin" line of 'snap version'
[17:13] <Chipaca> and then … then I'd make it print "El Capitán"
[17:14] <Chipaca> otoh it seems kernel version and codename go in lockstep
[17:14] <Chipaca> dunno
[17:19] <Chipaca> popey: could you add a "type" to that list?
[17:19] <Chipaca> er
[17:19]  * Chipaca checks the date
[17:19] <Chipaca> yeah, friday
[17:19] <popey> que?
[17:55] <zyga> Chipaca: hmm,
[17:55] <zyga> I can help with that :)
[17:55] <zyga> Chipaca: you basically query the api and get a version number
[17:55] <zyga> and map that to strings
[17:55] <mup> PR snapcraft#2386 closed: project_loader: raise error if part in after is undefined <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2386>
[17:59] <zyga> https://www.irccloud.com/pastebin/EmmPBcjL/
[17:59] <zyga> Chipaca: ^
[18:35] <Chipaca> ok, listen
[18:35] <Chipaca> https://www.youtube.com/watch?v=hdWyYn0E4Ys
[18:35] <mup> PR snapd#5955 closed: cmd/snap, tests: snapshots for all <Snapshots 📸> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5955>
[19:01]  * zyga hugs Chipaca
[19:01] <zyga> really nice work :)
[19:03] <zyga> Chipaca: I think this is the music that goes well with pull requests
[19:03] <zyga> https://www.youtube.com/watch?v=Pmd3UiNfNkA
[19:50] <zyga> cachio: the cifs test is not passing
[19:51] <zyga> https://github.com/snapcore/snapd/pull/5714#issuecomment-433524035
[19:51] <mup> PR #5714: tests: new test for cifs-mount interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5714>
[19:52] <cachio> I am waiting for the new cifs snap to be approved
[19:52] <zyga> aha
[19:52] <zyga> can you add a comment to the PR please
[19:52] <zyga> perhaps jdstrand can approve the snap
[19:52] <zyga> jdstrand: ^
[19:52] <cachio> zyga, the snaps are being uploaded
[19:53] <cachio> to the store
[19:53] <cachio> I'll run the tests again in few minutes
[19:57] <zyga> super, thank you!
[20:24] <cachio>
[20:34] <mup> PR snapd#6051 closed: cmd/snap-update-ns: parse the -u <uid> command line option <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6051>
[20:35] <mup> PR snapd#6019 closed: ifacestate: optimize disconnect hooks <Created by stolowski> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6019>
[20:46]  * cachio afk
[20:46] <mup> PR snapd#6053 opened: cmd/snap, daemon, strutil: use CommaSeparatedList to split a CSL <Created by chipaca> <https://github.com/snapcore/snapd/pull/6053>
[20:51] <zyga> Chipaca: +1
[20:52] <zyga> error: invalid argument for flag `--id' (expected main.snapshotID): strconv.ParseUint: parsing "": invalid syntax
[20:52] <zyga> Chipaca: is that a real bug or is merge with master needed?
[20:52] <zyga> https://api.travis-ci.org/v3/job/442553822/log.txt
[20:53] <zyga> https://www.irccloud.com/pastebin/6dCobmCw/
[20:53] <Chipaca> zyga: where's that?
[20:53] <zyga> https://github.com/snapcore/snapd/pull/5916
[20:53] <Chipaca> - Save data of snap "test-snapd-tools" in snapshot set #1 (user: unknown userid<PHONE_NUMBER>)
[20:53] <mup> PR #5916: data: run snapd.autoimport.service only after seeding <Created by mvo5> <https://github.com/snapcore/snapd/pull/5916>
[20:53] <zyga> yeah, I noticed
[20:53] <zyga> this is amazon linux 2
[20:53] <Chipaca> ¯\_(ツ)_/¯
[20:53] <zyga> my thoughts exactly
[20:54] <zyga> what is the user there normally?
[20:54] <Chipaca> I'm not going to dig, tonight
[20:54] <zyga> is it "test"
[20:54] <Chipaca> 12345
[20:54] <zyga> mmm
[20:54] <zyga> ok
[20:54] <zyga> yeah, sure it's super late
[20:54] <zyga> just weird
[20:54] <zyga> I'll restart the whole suite, that merges master locally
[20:54] <Chipaca> wait
[20:54] <Chipaca> no
[20:54] <zyga> ok
[20:54] <zyga> I'll wait
[20:54] <Chipaca><PHONE_NUMBER>
[20:54] <Chipaca> is "no change"
[20:54] <Chipaca> it's 0xfffffffe
[20:54] <zyga> waat!
[20:54] <zyga> -1
[20:55] <Chipaca> hmmm
[20:55] <Chipaca> is it -1, or is it -2
[20:56] <zyga> >>> ctypes.c_uint(-2)
[20:56] <zyga> c_uint(4294967294L)
[20:56] <zyga> -2
[20:56] <Chipaca> 1. I can't even
[20:56] <Chipaca> 2. not tonight
[20:57] <zyga> haha
[20:57] <zyga> yes, that's a good plan
[20:57] <zyga> let's fight this next week :)
[20:57] <zyga> I'll keep the log in case someone restarts


[11:36] <sigi> Morning, i have a vps and try to configure the dns server/overwrite dhcp setting for it. i can see a 50-cloud-init.yaml file and i'm wondering how the merge and priority behaviour is or if it exists as there also exits dns overrides: Would a 40-override.yaml or a 60-override.yaml with something like this work?
[11:36] <sigi> network:
[11:36] <sigi>   version: 2
[11:36] <sigi>   renderer: networkd
[11:36] <sigi>   ethernets:
[11:36] <sigi>     eth0:
[11:36] <sigi>       nameservers:
[11:36] <sigi>         addresses:
[11:36] <sigi>           - <IP_ADDRESS>