[02:00] <mup> PR snapcraft#1879 opened: extractors: replace desktop file ids with paths <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1879>
[05:42] <niemeyer> Morning all
[05:42] <niemeyer> Saviq: I've added the additional machines you requested on Spread, should be accessible to you already
[06:26] <Saviq> niemeyer: fantastic, thank you
[06:31] <mborzecki> morning
[07:40] <mup> PR snapd#4464 closed: overlord/snapstate: do a minimal sanity check on containers <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4464>
[07:45] <mvo_> cachio: everything ready in the beta channel for validation. as yesterday no new snapd, just package updates (see http://people.canonical.com/~mvo/core-changes/html/beta/ for details)
[07:47] <mborzecki> mvo_: morning
[07:49] <mvo_> hey mborzecki !
[07:49] <mborzecki> mvo_: do you know if snapcraft also needs to do some work on https://forum.snapcraft.io/t/snap-service-start-ordering/1470/ ?
[07:50] <mborzecki> mvo_: that's also what pedronis suggested, what leaves me wondering if i should poke someone from the snapcraft
[07:50] <mborzecki> team
[07:53] <mvo_> mborzecki: I think it does, it has a yaml schema for everything that can go into snapcraft.yaml. so the new things need to be added there iirc
[07:53] <mvo_> mborzecki: you can poke sergiusens (at a sprint) or kalikiana
[07:53] <mborzecki> ok, thanks
[07:53] <mvo_> mborzecki: probably relatively easy, you could give it a stab yourself
[07:55] <zyga-ubuntu> good morning
[07:55] <mborzecki> zyga-ubuntu: hey
[07:55] <zyga-ubuntu> how are you all feeling? :)
[07:58] <kalikiana> hey mborzecki
[07:59] <kalikiana> I can give you some pointers if needed
[07:59] <kalikiana> adding that should be pretty straightforward
[08:00] <kalikiana> assuming you'll want basically the same yaml as in the snap.yaml
[08:05] <sergiusens> mvo_ mborzecki we got guidance at the sprint that the user docs need to be written first before proceeding on features so a PR against the docs would be nice to see
[08:05] <zyga-ubuntu> sergiusens: interesting, thanks for sharing
[08:06]  * zyga-ubuntu enjoys morning coffee
[08:08] <pstolowski> mornings!
[08:08] <zyga-ubuntu> o/
[08:39] <mup> PR snapd#4492 closed: spread: try to enable Fedora once more <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4492>
[08:39] <mup> PR snapd#4504 opened: snap, wrappers: systemd WatchdogSec support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4504>
[08:40] <mborzecki> figured i might as well add support for the watchdog if i'm to update snapcraft and the docs
[08:44] <mvo_> mborzecki: +1
[09:13] <mup> PR snapd#4500 closed: snapstate: make no autorefresh message clearer <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4500>
[09:13] <zyga-ubuntu> 4499 needs a 2nd review
[09:14] <zyga-ubuntu> pstolowski: perhaps?
[09:14] <zyga-ubuntu> trivial
[09:16] <pstolowski> loooooking, but github is sooo slooow atm
[09:16]  * Chipaca waves
[09:17] <zyga-ubuntu> mborzecki: does this need a gustavo approval? https://github.com/snapcore/snapd/pull/4487
[09:17] <mup> PR #4487: cmd/snap: snap refresh --timer, hide --time <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4487>
[09:17] <zyga-ubuntu> Chipaca: o/ \o \o/
[09:17] <mborzecki> zyga-ubuntu: yes, probably
[09:17] <Chipaca> mvo_: I'd added the "sleep 1" thinking that the reason it wasn't seeing the messages in the journal was a race, when in the end it was git being a git
[09:17] <zyga-ubuntu> k
[09:17] <Chipaca> mvo_: so i was able to drop the sleep 1 \o/
[09:18] <mborzecki> asked niemeyer to take a look at both #4487 and #4476
[09:18] <mup> PR #4487: cmd/snap: snap refresh --timer, hide --time <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4487>
[09:18] <mup> PR #4476: overlord/{snapstate,configstate}, daemon: introduce refresh.timer, fallback to refresh.schedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4476>
[09:22] <pstolowski> uhm no github for me atm, anyone else having problems?
[09:24] <zyga-ubuntu> pstolowski: works for me
[09:25] <mvo_> Chipaca: yeah, I noticed
[09:25]  * zyga-ubuntu solicits reviews for https://github.com/snapcore/snapd/pull/4471
[09:25] <mup> PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>
[09:26] <mvo_> mborzecki: I added a suggestion to the 4467, maybe a personal thing, but I found it slighly easier this way. please check it out.
[09:28] <mborzecki> mvo_: it's much cleaner indeed, thanks
[09:33] <Chipaca> hurray for enabling opensuse spread tests again, but … they're failing again? :-(
[09:37] <mvo_> mborzecki: thank you
[09:37] <mvo_> Chipaca: yeah, tests are a bit unstable again :/
[09:37] <Chipaca> with the EOF thing I thought was my fault in the user pr!
[09:37] <Chipaca> that one was driving me crazy(er)
[09:37] <Chipaca> good luck :-D
[09:39] <mvo_> mborzecki: thanks for working on 4504! quick question: aiui for watchdogSec to work the app must call sd_notify() which needs to talk to a system socket - does that mean this pr also needs apparmor rules so that the app can access this socket?
[09:40] <Chipaca> mvo_: hah! i just commented trying to point mborzecki along those lines :-D
[09:40] <Chipaca> get out of my head :-p
[09:40] <mborzecki> mvo_: yeah, this was mentioned by Chipaca in https://forum.snapcraft.io/t/expose-a-more-consistent-subset-of-systemds-service-directives/2268
[09:40]  * mvo_ hugs Chipaca (from the inside)
[09:40] <mborzecki> anways, i'm about to find out the hard way :)
[09:40] <mvo_> mborzecki: haaha
[09:42]  * Chipaca installing every app in /var/cache/snapd/names to check for validation problems
[09:43] <Chipaca> s|app|snap with type:app|
[09:43] <mvo_> mborzecki: its slightly annoying that the NOTIFY_SOCKET is set via an env, it seems it is currently /run/systemd/notify it seems there is no grantee about this
[09:49] <mvo_> Chipaca: what is annoying is that 4503 failed three times already for different reasons :(
[09:53] <Chipaca> mvo_: if you've restarted it 3 times, then it's been restarted at least 5
[09:55] <zyga-ubuntu> oh, I restarted it too
[09:55] <mvo_> Chipaca: *weep*
[09:55] <mvo_> lol
[09:55] <zyga-ubuntu> that's one unlucky bastard then
[09:55] <mvo_> and also *moreweep*
[09:55] <zyga-ubuntu> maybe it will be around when we hit PR 10K
[09:55] <mup> PR #10: Update README.md <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/10>
[09:55] <Chipaca> we should have a 'carbon footprint per PR' competition
[09:55] <mvo_> pr #100
[09:55] <mup> PR #100: Ongoing work on the capability APIs <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/100>
[09:55] <mvo_> pr #1000
[09:55] <mup> PR #1000: debian: use sudo in setup of the proxy environment <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1000>
[09:56] <mvo_> pr #1
[09:56] <Chipaca> showoff
[09:56] <Chipaca> :-)
[09:56] <mvo_> Chipaca: heh, pretty even, no? 10: you, 100: zyga, 1000: me
[09:56] <mvo_> pr 1
[09:56] <mvo_> *pff* no pr 1?
[09:57] <Chipaca> nope
[09:57] <Chipaca> it was probably an issue
[09:57] <zyga-ubuntu> bug #1 ;-)
[09:57] <mup> Bug #1: Microsoft has a majority market share <canonical> <iso-testing> <microsoft> <package-qa-testing> <Clubdistro:Confirmed> <Computer Science Ubuntu:Confirmed for compscibuntu-bugs> <LibreOffice:New> <dylan.NET.Reflection:Invalid> <dylan.NET:Invalid> <EasyPeasy Overview:Confirmed for ramvi>
[09:57] <mup> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <LibreOffice:In Progress by bjoern-michaelsen> <Linux:New> <Linux Mint:In Progress> <The Linux OS Project:In Progress> <Neobot:New> <Novabot:New> <OpenOffice:In Progress by lh-maviya> <ReactOS Core Operating System:Incomplete> <Tabuntu:Invalid by
[09:57] <mup> tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:Invalid> <Ubuntu Malaysia LoCo Team:In Progress by apogee> <Wine:Confirmed> <Ubuntu:Fix Released> <Arch Linux:New>
 <Debian:In Progress> <Fedora:Confirmed> <Fluxbuntu:Confirmed> <openSUSE:In Progress> <Tilix:New> <https://launchpad.net/bugs/1>
[09:57]  * zyga-ubuntu gets back to work
[10:03] <Saviq> jdstrand: fwiw, it's just a case of installing xrdp and a desktop environment, and putting the session name (like "mate-session") in ~/.xsession
[10:15] <zyga-ubuntu> kind ping about 4471
[10:15] <zyga-ubuntu> it's blocking everything for me
[10:15] <zyga-ubuntu> please halp
[10:17] <ogra> mvo_, i have some weird behaviour of core on one of my boards here, seems it auto-refreshed to the beta one even though it tracks edge
[10:19] <mvo_> ogra: what do you see in "snap changes"?
[10:19] <ogra> mvo_, https://paste.ubuntu.com/26409733/
[10:19] <ogra> tracking:    edge
[10:19] <ogra> installed:   16-2.30 (3872) 71MB core
[10:19] <mvo_> ogra: I switched edge/beta around a bit in the morning, so maybe you see effects from this
[10:20] <ogra> in the morning ? ... thats 3:30am !
[10:20] <mvo_> ogra: this an non i386/amd64 system, right?
[10:20] <ogra> (admittedly in technical sense that is "morning" indeed :P )
[10:21] <ogra> mvo_, armhf
[10:21] <mvo_> ogra: heh :) yeah, I did not mess around with things at this time
[10:21] <mvo_> ogra: when is the next auto-refresh (snap refresh --time)?
[10:21] <ogra> $ snap refresh --time
[10:21] <ogra> schedule: 00:00-05:59/6:00-11:59/12:00-17:59/18:00-23:59
[10:21] <ogra> last: 2018-01-18T06:21:00Z
[10:21] <ogra> next: 2018-01-18T15:55:00Z
[10:21] <mvo_> ogra: I wonder if the next auto-refresh will push you back to a +git version
[10:22] <ogra> the revision is lower now ...
[10:22] <ogra> (in edge(
[10:22] <ogra> i could run a manual refresh ...
[10:22] <mvo_> ogra: yeah, this is what I did this morning, moved edge back to a git version
[10:22] <mvo_> ogra: yeah, just snap refresh should bring you back. I think its "expected" (in an unexpected way)
[10:22] <ogra> (should not be different from auto, right ?)
[10:23] <ogra> and so it does ...
[10:23] <ogra> Make snap "core" (3852) available to the system
[10:23] <ogra> ...
[10:23] <mvo_> ogra: i.e. yesterday edge was "2.30" and there was a core snap build in the night which also had 2.30, then later your board refrehsed to 2.30 and in my morning I pushed edge back into +git land and now it should refresh to this (does that make sense)
[10:24] <ogra> yeah, makes complete sense
[10:24] <ogra> thanks for clearing the myth :)
[10:25] <mvo_> ogra: its all (more) confusing because no auto-builds, everything need to be manually approved for building
[10:25] <ogra> (i only noticed because i had put the revision into a release note for a customer ... and was just shocked that i typoed 3852 for 3872 when i looked at it this morning :P )
[10:26] <ogra> mean that the revisions were so similar :)
[10:26] <mvo_> heh
[10:26] <mvo_> ok
[10:51] <ads20000> Speaking of `beta`s...the beta is a different revision to candidate/stable but the same version number? Seems confusing...what happened there?
[10:51] <ads20000> Was it just because you were switching them around? :
[10:51] <ads20000> * :P
[10:54] <ogra> version numbers in snaps are shallow
[10:54] <ogra> they are just a string in snapcraft.yaml ...
[10:54] <ogra> revisions are what counts
[10:54] <Chipaca> well
[10:54] <ogra> that said ...
[10:55] <Chipaca> versions are for human consumption :-)
[10:55] <ogra> it is likely the content is actually the same in the case of core
[10:55] <Chipaca> and are merely descriptive
[10:55] <ogra> (unless some of the additional packages changed ... the core snapcraft.yaml actually generates the version from the snapd version)
[11:16] <zyga-ubuntu> Chipaca: it failed again
[11:16] <zyga-ubuntu> on fedora
[11:27] <mup> PR snapd#4503 closed: osutil/sys: ppc has 32-bit getuid already <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4503>
[11:31] <zyga-ubuntu> mvo_: was it green in the end/
[11:31] <mvo_> zyga-ubuntu: no, i merged it anyway
[11:32] <mvo_> zyga-ubuntu: I need to get a deb build to see if it fixes the build failure
[11:33] <Chipaca> "contact develper"
[11:33]  * Chipaca looks for a brown paper bag
[11:33] <mvo_> *cough*
[11:34] <Chipaca> and i only realised when writing https://forum.snapcraft.io/t/snapd-is-now-doing-a-little-sanity-check-on-install/3566
[11:47] <zyga-ubuntu> hmm?
[11:47] <zyga-ubuntu> what is contact developer about?
[11:51] <mvo_> zyga-ubuntu: "develper"
[11:51] <zyga-ubuntu> ah
[11:51] <zyga-ubuntu> typo
[11:54] <jdstrand> zyga-ubuntu: fyi, I reviewd 4472
[11:54] <jdstrand> reviewed even
[11:58] <zyga-ubuntu> thank you!@
[11:59] <zyga-ubuntu> thanks! I'll update the rules and merge
[11:59] <zyga-ubuntu> jdstrand: I'm working on layouts now, while they won't work (apparmor) they are now applied to mount profile, the PR will need some discussion but it looks like a good start
[12:01]  * pstolowski lunch
[12:02] <jdstrand> greyback: ok, so, in thinking about this, I think we want to adjust the *mir*ConnectedPlugAppArmor policy to have '/{dev,run}/shm/\#* mrw,', then have your snap plugs mir and x11
[12:04] <jdstrand> greyback: the idea is that if your snap snips xwayland, it is a mir client, so needs to 'plugs: [mir]', then the thing that talks to x11 needs to 'plugs: [x11]'
[12:05] <greyback> jdstrand: xwayland is a wayland client, it's not using the mirclient libraries
[12:05] <jdstrand> greyback: this is slightly odd because the app is really the slot for x11 though
[12:05] <greyback> yeah I know
[12:05] <jdstrand> greyback: the shm access is really a mir thing though, no?
[12:06] <greyback> is having a separate xwayland snap, which has the x11 slot, too much?
[12:06] <greyback> jdstrand: that is something I've never quite figured out
[12:06] <greyback> perhaps I should, to get things straight
[12:06] <jdstrand> greyback: in terms of policy, the shm access is only in mir
[12:07] <greyback> true
[12:07] <jdstrand> I was extrapolating from there when I suggested adjusting mir
[12:07] <greyback> yep, understood
[12:07] <jdstrand> I also understand the the shm access within the context of mir is considered safe
[12:08] <greyback> let me ask around and try verify that
[12:08] <greyback> or at least figure out exactly what in /dev/shm is needed
[12:08] <greyback> and by what
[12:09] <jdstrand> greyback: ftr, having a separate xwayland snap would not be required. you could embed it; your snap would just slots x11 (assuming we had that policy)
[12:09] <jdstrand> so you slot it to yourself
[12:09] <jdstrand> but, let me read something back you said a minute ago
[12:09] <greyback> I didn't know you could slot to yourself
[12:10] <greyback> that would do the trick
[12:10] <jdstrand> let's assume that xwayland is one command in your snap and chromium another
[12:10] <jdstrand> (for clarity)
[12:10] <jdstrand> if xwaland is a wayland client, it should plugs wayland (let's not worry about shm for the moment)
[12:11] <jdstrand> chromium is not a wayland client, so it should plugs x11
[12:11] <jdstrand> xwayland command is providing x11
[12:11] <jdstrand> so xwayland slots x11
[12:11] <jdstrand> so
[12:12] <jdstrand> the x11 interface grows the slot side (perhaps we can put the shm access in PermanentSlotAppArmor...)
[12:12] <greyback> right so ar
[12:12] <greyback> far
[12:12] <jdstrand> the you have
[12:12] <jdstrand> name: foo
[12:12] <jdstrand>   apps:
[12:13] <jdstrand>     chromium:
[12:13] <jdstrand>       plugs: [ x11 ]
[12:13] <jdstrand>     xwayland:
[12:13] <jdstrand>       slots: [ x11 ]
[12:13] <jdstrand>       plugs: [ wayland ]
[12:14] <jdstrand> greyback: I think that aligns with how you described how xwayland works
[12:14] <mvo_> Chipaca: and another ppc failure: https://paste.ubuntu.com/26410328/ - this time in boltdb
[12:14] <greyback> jdstrand: yes that makes sense
[12:15] <greyback> I'll give that a go
[12:15] <greyback> jdstrand: thanks for the advice
[12:15] <jdstrand> greyback: *today* a full on Xorg xserver wouldn't be able to run with the slot policy you right for x11, but that is ok. if that ever comes up, we can adjust the policy. this way you can focus just on the xwayland bits
[12:15] <mup> PR snapd#4505 opened: interfaces/mount,snap: early support for snap layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4505>
[12:15] <jdstrand> right?
[12:16] <jdstrand> s/right/write/?
[12:16] <jdstrand> (what an ugly typo)
[12:16] <zyga-ubuntu> Chipaca: ^ early PR for layouts,
[12:16] <zyga-ubuntu> mvo_: ^
[12:16] <mvo_> ta
[12:16] <greyback> jdstrand: heh, silly english with homonyms
[12:17] <zyga-ubuntu> small, just for quick feedback on the idea
[12:19] <jdstrand> greyback: for your testing, perhaps just tuck the shm access into the PermamentSlotAppArmor bit of x11 and add a TODO comment to investigate. before we merge, you investigate. it might be that we adjust mirConnectedPlugAppArmor to have the shm access and xwayland to plugs: [ wayland, mir ] since *this* wayland client happens to need it cause of some mir thing
[12:19] <jdstrand> obviously depending on your investigation
[12:19] <greyback> jdstrand: *nod*
[12:19] <greyback> that's a plan
[12:19] <jdstrand> greyback: ok, sorry for the lagginess on this. I'll be back from sprinting next week
[12:20] <greyback> jdstrand: not at all, thank you for the help
[12:20] <jdstrand> np
[12:51] <mup> PR snapd#4506 opened: iterate on the container sanity check: patch typo, move to snap, add to pack <Created by chipaca> <https://github.com/snapcore/snapd/pull/4506>
[12:55] <zyga-ubuntu> Chipaca: sorry to bug you but could you please (perhaps) split that PR into distinct commits that can be reviwed earliy
[12:55] <zyga-ubuntu> *easily
[12:56] <zyga-ubuntu> Chipaca: maybe one for typo, one for mv, more for extra features
[12:56] <zyga-ubuntu> otherwise that's a 1K diff
[12:56] <Chipaca> zyga-ubuntu: I can. Most of the diff is the move from snapstate to snap, i guess
[12:56] <Chipaca> lemme close that
[12:56] <Chipaca> before it chomps up a travis
[12:57] <zyga-ubuntu> thanks
[12:57] <zyga-ubuntu> oh drat, standup
[12:57] <zyga-ubuntu> ... quick coffeee
[12:57] <zyga-ubuntu> eeeeeeeeeeee
[12:58] <mup> PR snapd#4506 closed: iterate on the container sanity check: patch typo, move to snap, add to pack <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4506>
[13:01] <Chipaca> zyga-ubuntu: there you go
[13:02] <mup> PR snapd#4506 opened: iterate on the container sanity check: patch typo, move to snap, add to pack <Created by chipaca> <https://github.com/snapcore/snapd/pull/4506>
[13:06] <mup> PR snapd#4499 closed: packaging/14.04: move linux-generic-lts-xenial to recommends <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4499>
[13:16] <mborzecki> cachio: do you the version of fedora kernel used on linode?
[13:32]  * kalikiana time for lunch
[13:34] <zyga-ubuntu> woot, one branch merged :)
[13:35] <mup> PR snapd#4472 closed: cmd/snap-confine: allow snap-update-ns to poke writable holes in $SNAP <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4472>
[13:35] <zyga-ubuntu> pstolowski: about 4358, how to approach it?
[13:35] <zyga-ubuntu> pstolowski: any advice on how to review it?
[13:40] <tyhicks> zyga-ubuntu: hey - I never saw if you got the apparmor label query issue straightened out?
[13:41] <zyga-ubuntu> tyhicks: yes and no
[13:41] <zyga-ubuntu> tyhicks: I drowned in dbus, iteration is a pain
[13:42] <zyga-ubuntu> tyhicks: but mvo added a label that jdstrand suggested that fixed the problem
[13:42] <zyga-ubuntu> tyhicks: (labeling the snap userd service as unconfined)
[13:42] <tyhicks> zyga-ubuntu: do I need to fix a bug caused by that upstream change?
[13:42] <zyga-ubuntu> tyhicks: it looks like the bug is real but it's not a pressing issue for us now
[13:42] <zyga-ubuntu> tyhicks: I think so, it will affect other things
[13:42] <zyga-ubuntu> (not just snapd)
[13:43] <tyhicks> zyga-ubuntu: what's a simple reproducer? attempt to query a label of a peer connection in bionic?
[13:44] <zyga-ubuntu> tyhicks: on bionic, revert mvo's change (I'll give you a link in a moment), install gimp (probably works with other snaps but this works for sure); snap run --shell gimp; xdg-open http://example.org
[13:44] <zyga-ubuntu> tyhicks: the logs indicate that there's no peer label information and thus the rule for peer=unconfined doesn't apply and the activation is denied
[13:44] <pstolowski> zyga-ubuntu, it would probably make sense to start by getting the understanding of the associated spread test and its 2 test snaps and their hooks
[13:44] <zyga-ubuntu> tyhicks: it's *just* activation that is broken
[13:45] <zyga-ubuntu> tyhicks: once activated it works correctly
[13:45] <zyga-ubuntu> pstolowski: thank you, let's see
[13:46] <zyga-ubuntu> tyhicks: I attached logs on the forum if you need those
[13:46] <zyga-ubuntu> (and some advice on how to collect them)
[13:46] <zyga-ubuntu> tyhicks: I think activation should happen regardless and not bail out on lack of the label
[13:47] <zyga-ubuntu> tyhicks: or activation should carry implicit confinement "unconfined"
[13:47] <zyga-ubuntu> tyhicks: reading the code it seems that activation should fail (by design) only on explicit deny rules
[13:47] <zyga-ubuntu> tyhicks: that was the intent
[13:47] <zyga-ubuntu> tyhicks: but this is not how it behaves
[13:48] <pstolowski> zyga-ubuntu, then repo.go and doConnect handler. policy and connection.go changes last
[13:51] <tyhicks> zyga-ubuntu: thanks - that helps a lot to understand the problem
[13:51] <tyhicks> zyga-ubuntu: I have some ideas about how to do this correctly
[13:54] <zyga-ubuntu> tyhicks: the branch to revert, once it lands, is https://github.com/snapcore/snapd/pull/4495
[13:54] <mup> PR #4495: data/dbus: add AssumedAppArmorLabel=unconfined <Created by mvo5> <https://github.com/snapcore/snapd/pull/4495>
[13:55] <jdstrand> tyhicks: bug #1742687
[13:55] <mup> Bug #1742687: Launching URLs in snapped applications no longer works in 18.04 <AppArmor:Invalid> <D-Bus:New> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1742687>
[14:05] <seb128> jdstrand, zyga-ubuntu, is there really a bug there? to be it looks like that dbus/apparmor enforces more checking that it used to and that the autoactivated services that AssumedAppArmorLabel info by design
[14:06]  * zyga-ubuntu lunch
[14:06] <zyga-ubuntu> seb128: yes, I think so
[14:06] <zyga-ubuntu> seb128: reading the code and patch descriptions seems to imply it should not behave this way
[14:06] <zyga-ubuntu> seb128: I'll defer to tyhicks's decision
[14:07] <seb128> zyga-ubuntu, you should report it upstream, they might just fix it for us
[14:08] <zyga-ubuntu> seb128: yeah, I can do that, good idea
[14:10] <seb128> zyga-ubuntu, thanks
[14:31] <zyga-ubuntu> ok, let's review things
[14:31] <zyga-ubuntu> then let's file that bug
[14:31] <zyga-ubuntu> and then, let's ... not sure yet :)
[14:31] <kalikiana> re
[14:31] <zyga-ubuntu> mborzecki: https://github.com/snapcore/snapd/pull/4505
[14:31] <mup> PR #4505: interfaces/mount,snap: early support for snap layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4505>
[14:31] <zyga-ubuntu> mborzecki: would the group / user thing be a problem on arch?
[14:33] <mborzecki> zyga-ubuntu: there's a 'nobody' group around here only
[14:37] <mborzecki> zyga-ubuntu: the uids in tests are hardcoded too
[14:39] <mborzecki> zyga-ubuntu: maybe it would be best to guess nobody/nogroup the same way we deal with directories
[14:40] <mborzecki> zyga-ubuntu: li.Group is coming from the snap right?
[14:41] <zyga-ubuntu> mborzecki: hymm
[14:42] <zyga-ubuntu> mborzecki: yes
[14:42] <zyga-ubuntu> mborzecki: I think that I need to tweak that to contain a fixed mapping
[14:42] <zyga-ubuntu> mborzecki: this mapping must make sense on the inside, not for classic host
[14:42] <zyga-ubuntu> mborzecki: and we only support 'root' and 'nobody'
[14:56] <zyga-ubuntu> Chipaca: did you see 4506 failures?
[14:56] <Chipaca> zyga-ubuntu: i saw your comment
[14:56] <Chipaca> i'll dig in a bit
[14:57] <Chipaca> (that pr is a backburner one)
[14:57] <jdstrand> seb128 (cc zyga-ubuntu and tyhicks): tyhicks and I talked about it. it is fine that dbus is offering more mediation, but the way it is doing it is a bit weird. tyhicks will comment in the bug
[14:57] <zyga-ubuntu> k
[14:58] <seb128> jdstrand, thanks
[15:24]  * kalikiana really, really hates regex today
[15:24]  * kalikiana getting more tea
[15:31] <zyga-ubuntu> kalikiana: regex is your friend, imagine if you had to do it by hand
[15:32] <zyga-ubuntu> kalikiana: btw, do you knof about regex derivatives?
[15:32] <zyga-ubuntu> kalikiana: I found that interesting a while back
[15:32] <zyga-ubuntu> kalikiana: https://en.wikipedia.org/wiki/Brzozowski_derivative
[15:36] <mvo_> Chipaca: looks like we need https://paste.ubuntu.com/26411304/ in upstream bolt (funny enough this seems to be not fixed in the coreos fork either - ppc seems to be not super popular)
[15:36] <zyga-ubuntu> mvo_: before it blows up, can we check if this builds on other fringe arches?
[15:38] <mvo_> zyga-ubuntu: which one do you have in mind?
[15:41] <zyga-ubuntu> mvo_: s390 and all the other ones nobody has but will block us in next package build in the archive
[15:46] <Chipaca> ooh, just got a very helpful email, trying to sell me email listings of redhat users
[15:47] <kalikiana> zyga-ubuntu: hmmm I did not know that! will have to read up on it
[15:47]  * Chipaca considers forwarding it to<EMAIL_ADDRESS>:-p
[15:50] <zyga-ubuntu> kalikiana: it's not useful very often as it's not something implemented in any standard library I know
[15:50] <zyga-ubuntu> kalikiana: but since I love that topic, I wanted to share it :)
[15:50] <zyga-ubuntu> Chipaca: how much?
[15:51] <kalikiana> zyga-ubuntu: usually I adore the concept as well, just not today when I'm fighting with a tricky case :-P
[15:51] <zyga-ubuntu> kalikiana: what is the case? I will be your garden dwarf friend
[15:52] <zyga-ubuntu> kalikiana: explain the problem to me
[15:54] <cachio> niemeyer, when you have some time, could you please take a look to https://github.com/snapcore/spread/pull/49
[15:54] <mup> PR spread#49: send keepalive packets every 10 seconds to avoid losing the connection <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/49>
[15:55] <kyrofa> kalikiana, I also find rubular.com to be helpful
[15:55] <zyga-ubuntu> pstolowski: some early feedback on 4358
[15:55] <Chipaca> zyga-ubuntu: no idea
[15:55] <zyga-ubuntu> pstolowski: marked as requeste changes because I'm still going through it and I have more questions pending
[15:56] <zyga-ubuntu> pstolowski: sorry about that but if you follow the diff from the end and go up the order of my questions will be more logical
[15:56]  * zyga-ubuntu reads diffs from the other end usually
[15:56] <pstolowski> zyga-ubuntu, ty!
[15:56] <pstolowski> :)
[15:57] <zyga-ubuntu> can I ask for firmer vote on https://github.com/snapcore/snapd/pull/4502
[15:57] <mup> PR #4502: interfaces/builtin: add support for content "source" section (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4502>
[15:57] <zyga-ubuntu> pstolowski: sorry for the needs fixing, I don't see anything strongly broken, just want to understand it
[15:57] <zyga-ubuntu> pstolowski: what's the idea with the new interface btw? are we adding a new interface designed for testing?
[15:57] <pstolowski> zyga-ubuntu, sure, no worries
[15:58] <Chipaca> here's an initeresting test to do: set up a long loop that installs and removes the same snap. compare how long it takes to install the 2nd time, vs the Nth time.
[15:58] <zyga-ubuntu> Chipaca: what's the result you got?
[15:58] <pstolowski> zyga-ubuntu, yes, this is something I brought up on the standup (limited testatibility with existing ifaces) and Gustavo suggested to created a new interface just for testing
[15:58] <kalikiana> zyga-ubuntu, kyrofa: I'm staring at this `\A(on)\s+([^,\s](?:,?[^,\s]+)*)(\s(to)\s+([^,\s](?:,?\S+)*)|)\Z` which rejects "on i386, ubuntu to armhf" as invalid. due to the extra space after the comma. Except we *want* to parse it so we can show a special error. Now if I remove the change the two `[^,\s]` to `[^,]` it parses but the groups are merged in one
[15:58] <Chipaca> on this machine, subjectively (because i didn't start out to measure this) it looks like as changes hit 10k, things get a lot slower
[15:58] <zyga-ubuntu> pstolowski: should it be in a different file name?
[15:58] <zyga-ubuntu> pstolowski: er, should the file have a different name
[15:59]  * kalikiana finds https://regex101.com/ quite nice but sadly it can't extrapolate the intended use case
[15:59] <zyga-ubuntu> pstolowski: test_... go is not usually built, rightt?
[15:59] <Chipaca> I don't think I'll have time to run that test today, but i might tomorrow :-)
[15:59] <zyga-ubuntu> kalikiana: looking
[15:59] <pstolowski> zyga-ubuntu, i'm open to renaming it. I if the only expectation is about display name, it should clearly indicate it's not an interface for normal use
[16:00] <pstolowski> d/I if/
[16:00] <zyga-ubuntu> pstolowski: yes, i would add some provisions for hiding it (though not needed now)
[16:01] <zyga-ubuntu> kalikiana: man, that could use the mode that enables whitespace and comments
[16:01] <zyga-ubuntu> kalikiana: did you think about using a lexer and parser to make things like that easier to follow?
[16:02] <zyga-ubuntu> kalikiana: can you please remind me what \A and \Z does in the engine you are working with (I presume python)
[16:03] <Chipaca> zyga-ubuntu: start and end of string
[16:03] <kalikiana> zyga-ubuntu: start and end of the string
[16:03] <kalikiana> and yes, it's Python
[16:04] <zyga-ubuntu> kalikiana: are those different from ^ and $?
[16:04] <Chipaca> zyga-ubuntu: the m modifier changes ^ and $ to start of lines inside the string, so you need a bigger anchor
[16:04] <zyga-ubuntu> ah
[16:04] <zyga-ubuntu> I see
[16:04] <Chipaca> or was it the s modifier
[16:04] <Chipaca> one of 'em two
[16:04] <zyga-ubuntu> I think it's 'm'
[16:04] <zyga-ubuntu> kalikiana: ok and the (?: ) syntax, what does that introduce?
[16:05] <kalikiana> zyga-ubuntu: it ignores the group in the results
[16:05] <zyga-ubuntu> ok,
[16:05] <zyga-ubuntu> kalikiana: that's dangerous perhaps
[16:05] <zyga-ubuntu> kalikiana: it can cause states to be combined in the resulting DFA
[16:05] <zyga-ubuntu> I'm not sure how much nfa->dfa action happens in python tho
[16:05]  * zyga-ubuntu experiments
[16:05] <Chipaca> zyga-ubuntu: it's like () but without capture
[16:06] <Chipaca> zyga-ubuntu: which is nice, because (foo)+ is weird
[16:06] <zyga-ubuntu> perfect, thank you
[16:11] <zyga-ubuntu> kalikiana: and what would you like this to match, in geral
[16:11] <zyga-ubuntu> *general
[16:11] <zyga-ubuntu> kalikiana: do you have a spec of what is valid (in english)
[16:14] <zyga-ubuntu> kalikiana: I'll be back, I need to walk outside for an hour, see you later (just write the spec please)
[16:15] <kalikiana> zyga-ubuntu: enjoy!
[16:16] <Chipaca> mvo_: I subscribed you to #1744113 because I thought you might have something to add to the discussion
[16:16] <mup> Bug #1744113: should the /names endpoint include kernels, gadgets, cores? <Snap Store:New> <https://launchpad.net/bugs/1744113>
[16:19] <kalikiana> kyrofa: if you wanna have a look wrt the refactor, to re-uses on now in snapcraft#1800 - aside from my fighting with the regex the code works
[16:19] <mup> PR snapcraft#1800: grammar: on..to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1800>
[16:22] <Chipaca> mvo_: dear IT worker, Good work.
[16:22] <Chipaca> mvo_: that doesn't happen often! :-)
[16:22] <mup> PR snapd#4336 closed: spread.yaml: add fedora 27 <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4336>
[16:23] <kalikiana> kyrofa: I've found an interesting problem btw. having both `to armhf` and `on i386 to armhf` will be counted as duplicates. I'm not sure how to address that... the refactoring is turning out to be a little less straightforward
[16:24] <kyrofa> kalikiana, well they kind of are, aren't they?
[16:25] <kyrofa> It's possible for them both to match
[16:28] <kyrofa> elopio, what's on your docket for today? Looks like I owe you a few reviews
[16:30] <elopio> kyrofa: I want to finish collecting all the existing translations for the repo, and start the docs that Sergio requested.
[16:30] <elopio> kyrofa: I am on vacations tomorrow, so it would be nice to finish the PRs today too.
[16:31] <kalikiana> kyrofa: I found myself trying out `on amd64 to amd64` because why not, and that's an error. Which is probably fine since it's somewhat pointless. But separate `on amd64` statements probably do make sense in some cases.
[16:33] <cachio> zyga-ubuntu, please take a look to #4351 when you have a time
[16:33] <mup> PR #4351: tests: new test to validate location control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4351>
[16:34] <blackboxsw> good day folks, I'm looking at creating a snapd/seed  directory for curtin & cloud-init  and wanted to chat about what I might be missing. Is it preferable for me to start a forum post for that?
[16:40]  * kalikiana going to wrap up for today in a bit
[16:41] <kyrofa> kalikiana, curious to hear what cases
[16:42] <kyrofa> I can't think of any cases where they couldn't be merged
[16:44] <kyrofa> Hahaha snapcraft#1877 is hilarious
[16:44] <mup> PR snapcraft#1877: tests: move test files out of the snapcraft dir <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1877>
[16:44] <kyrofa> Easiest review ever, close my eyes and +1
[16:45] <kyrofa> elopio, any chance you made sure autopkgtests ran correctly as well (since those are effected by this as well)?
[16:47] <kalikiana> kyrofa: Yeah. Arguably it's totally okay to fail like that. I just wanted to be sure to bring it up. Could still add that later in any case.
[16:48] <blackboxsw> also quick question on snap auto-import. Is this command line utility which is actually searching for /var/lib/snapd/seed ?
[16:48] <kyrofa> kalikiana, yeah it's part of the initial yaml spec, which may not grow quite as well as we would hope
[16:48] <kyrofa> Not yaml spec, sorry, grammar spec
[16:48] <elopio> kyrofa: we can get the bot to do that
[16:48] <kyrofa> elopio, oh wait, amd64 is back huh?
[16:49] <kyrofa> elopio, I've just been assuming everything was still down
[16:49] <elopio> snappy-m-o autopkgtest 1877 xenial:amd64
[16:49] <snappy-m-o> Computer says nooo. See logs for details:
[16:49] <snappy-m-o>  Command '['/tmp/tmp02uqh_h1/retry_autopkgtest.sh', '1877', 'xenial:amd64']' returned non-zero exit status 1
[16:49] <kyrofa> :(
[16:52] <mvo_> Chipaca: sure, looking
[16:53] <mvo_> Chipaca: re dear it works> where did you see that?
[16:53] <Chipaca> mvo_: #1743079
[16:53] <mup> Bug #1743079: apparmor exit code 123 <snapd (Ubuntu):Incomplete> <https://launchpad.net/bugs/1743079>
[16:54] <kyrofa> elopio, I assume you have access to those logs?
[16:55] <elopio> kyrofa: yes, checking.
[16:55] <elopio> It would be more useful if the bot made a summary of the exception, instead of just exit 1
[16:59] <mvo_> Chipaca: haha - right
[17:00] <mvo_> Chipaca: I guess I will make this my new job title "IT worker"
[17:02]  * Chipaca bbiab
[17:03] <mup> PR snapcraft#1874 closed: kbuild: pick up CROSS_COMPILE only if it's not empty <Created by piso77> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1874>
[17:03] <elopio> kyrofa: it's replying with a 500, so not yet.
[17:04] <elopio> I'll give them a try here.
[17:04] <kyrofa> Uh oh
[17:21] <cjwatson> kyrofa: Surprising that GH doesn't handle that.  I fixed that kind of thing in LP a while back AFAIK (https://bugs.launchpad.net/turnip/+bug/1712754)
[17:21] <mup> Bug #1712754: git diffs do not track renames <canonical-is> <turnip:Fix Released by cjwatson> <https://launchpad.net/bugs/1712754>
[17:22] <zyga-ubuntu> back now
[17:24] <zyga-ubuntu> cachio: approved
[17:24] <cachio> zyga-ubuntu, tx
[17:38] <blackboxsw>
[17:38] <zyga-ubuntu> so now that we have slack
[17:38] <zyga-ubuntu> is there a slack for snappy?
[17:39] <zyga-ubuntu> hmm
[17:53] <mup> PR snapd#4507 opened: advisor: use forked bolt to make it work on ppc <Created by mvo5> <https://github.com/snapcore/snapd/pull/4507>
[17:55] <kyrofa> elopio, I really only have one issue with snapcraft#1879
[17:55] <mup> PR snapcraft#1879: extractors: replace desktop file ids with paths <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1879>
[18:15] <lotuspsychje> good evening to all
[18:16] <lotuspsychje> i have a wish for a snap command, whats the prefered way to do this? bug/wishlist?
[18:16] <zyga-ubuntu> lotuspsychje: try opening a forum topic on forum.snapcraft.io
[18:16] <lotuspsychje> zyga-ubuntu: ok thank you
[18:17] <zyga-ubuntu> lotuspsychje: pleasure :)
[18:26] <lotuspsychje> zyga-ubuntu: https://forum.snapcraft.io/t/req-snap-list-command-to-see-latest-added-snaps/3581
[18:28] <zyga-ubuntu> lotuspsychje: nice! I commented alreay
[18:28] <zyga-ubuntu> *already
[18:29] <lotuspsychje> zyga-ubuntu: nice thank you!
[18:37] <lotuspsychje> zyga-ubuntu: sudo snap find lists a few  but not all right
[18:37] <zyga-ubuntu> lotuspsychje: yes, those are "curated snaps" (not really curated much ATM)
[18:37] <zyga-ubuntu> lotuspsychje: but a feed of recently added or refreshed snaps would be interesting
[18:39] <lotuspsychje> zyga-ubuntu: atm i always have to go to the store website and filter recently added
[18:42] <mvo_> Chipaca: my bbolt (coreos fork) PR for fixing ppc got merged within 30min, that is quite impressive
[19:05] <Chipaca> mvo_: niice
[19:05] <Chipaca> mvo_: tag me on the pr, i'll look at it later tonight
[19:05] <Chipaca> bye for now
[19:05] <Chipaca> mvo_: i mean on the pr to move to the fork, if there is one :-)
[19:29] <smiso> hi: Any one who any ideeas how to persistent add ip forwarding to ubuntu core?
[19:30] <zyga-ubuntu> smiso: hey
[19:30] <zyga-ubuntu> smiso: you can implement that in a snap that uses the network-control interface
[19:30] <zyga-ubuntu> let me check
[19:31] <zyga-ubuntu> smiso: you may need either or both network-control and firewall-control
[19:31] <zyga-ubuntu> and then you should be able to set that up yourself (in your snap)
[19:31] <zyga-ubuntu> I don't think we offer any default way to manage that today
[19:31] <zyga-ubuntu> only as interfaces to snap applications
[19:53] <cachio> zyga-ubuntu, any idea why netlink-audit interface could be denying the connection https://paste.ubuntu.com/26412541/
[19:58] <cachio> zyga-ubuntu, this is executed with the interface connected https://github.com/sergiocazzolato/snapd/blob/tests-interface-netlink-audit/tests/lib/snaps/test-snapd-netlink-audit/bin/bind
[21:31] <Snapdragon> Hello
[22:46] <blackboxsw> hrm. snap known --remote model series=16 model=generic-classic brand-id=generic returns an ill-formed yaml file for sign-key-sha3-384 value the multi-line value doesn't use
[22:47] <blackboxsw> nevermind.... not supposed to be yaml


[00:37] <redir> wallyworld: PTAL http://reviews.vapour.ws/r/5548 and make sure I understood you.
[00:37] <wallyworld> ok
[00:40] <wallyworld> redir: you sure you oushed the changes? i can't see a new diff
[00:41] <redir> shit I need to rbt it
[00:41] <redir> RB ate my original PR
[00:42] <redir> wallyworld: ^^ rbt post -u run...
[00:42] <wallyworld> ok
[01:12] <wallyworld> axw: looking at the cloud facade - the credential apis take / return tags. but i thought our general principal was that tags are not to be exposed outside of the apis (wire format only). we pass in names etc and these are converted to tags inside api/*
[01:21] <axw> wallyworld: feel free to change it. I like the type safety and documentation it brings
[01:21] <wallyworld> axw: yeah, i get that too. i'll leave for now, but we should agree on a consistent approach
[01:22] <wallyworld> axw: should raise as a tb topic
[01:27] <wallyworld> axw: damn, and we also leak params structs for results where we return a slice of {*Value, *Error}
[01:28] <axw> wallyworld: where?
[01:28] <wallyworld> everywhere, eg
[01:28] <wallyworld> func (c *Client) StorageDetails(tags []names.StorageTag) ([]params.StorageDetailsResult, error)
[01:28] <axw> wallyworld: oh, yeah we do that in many places. I thought you meant in Cloud
[01:29] <wallyworld> sigh, i'll just stick to current convention for now
[03:22] <thumper> wallyworld, menn0: can you see this ? http://imgur.com/a/zmSPH
[03:23] <wallyworld> yes
[03:23] <thumper> good?
[03:23] <menn0> nice
[03:23] <wallyworld> ecept for colour blind people
[03:24] <menn0> looks good to me... the red could have better contrast IMO but that comes down to your terminal color settings
[03:24] <thumper> I can't help them...
[03:25] <menn0> thumper: I'm not sure that "unknown" should be highlighted. it's not that unusual for a charm to not set workload status
[03:25] <thumper> right, but if we mark it yellow, people will want to set it green, right?
[03:26] <wallyworld> thumper: we can help them by choosing better colours, like jenkins does
[03:27] <wallyworld> but red and green are nice i admit
[03:56] <natefinch> use red for bad, blue for good.  add symbols to make it more clear - ✘ error   	✔ success
[03:57] <natefinch> ❓ unknown
[03:57] <thumper> no symbols with this change
[04:00] <natefinch> red / blue then
[04:31] <thumper> huh...
[04:31] <thumper> interesting
[04:31] <thumper> tried bright blue for the good color
[04:31] <thumper> but watch -c doesn't show that
[04:32] <thumper> weird
[04:32] <thumper> less -R does
[04:32] <thumper> I'm tempted to stay with green for now and see what response we get
[04:35] <natefinch> 10% of men are color blind. That's probably 9% of our target market...  I personally know several color blind people.  It's just a bad idea, and sort of inexcusable in this day and age. It sucks the default linux tools don't cooperate, but that doesn't mean we shouldn't do the right thing anyway.
[04:37] <natefinch> sounds like we might be hitting something like this: https://github.com/cloudfoundry/cli/issues/840
[04:37] <natefinch> do we always output color, or do we do some terminal detection?
[04:39] <wallyworld> axw: if you get bored of looking at juju heap dumps, no rush or anything, http://reviews.vapour.ws/r/5554/
[04:40] <axw> wallyworld: will take a look after lunch
[04:40] <wallyworld> sure, no hurry
[04:54] <menn0> thumper: phew... source prechecks done. just 2 more target prechecks to go.
[04:54] <menn0> doing some manual QA now
[04:56] <menn0> veebers: the migration prechecks around juju versions, upgrades in progress and machine health have all landed
[04:56] <menn0> veebers: and there's a bunch more on their way
[04:57] <veebers> menn0: sweet. Tomorrow morning I might take some of your time to flesh out any remaining CI tests for the migration parts
[04:57] <menn0> veebers: sounds good
[04:58] <thumper> review up: http://reviews.vapour.ws/r/5555/
[05:00] <thumper> natit was just the blue, watch showed red/green/yellow, thinking it is the high 8
[05:03] <thumper> wallyworld, menn0: here is what blue for good looks like http://imgur.com/a/4kMVu
[05:03] <wallyworld> thumper: ah, so you looked at what jenkins does :-)
[05:03] <thumper> no
[05:03] <thumper> nate suggested it
[05:03] <thumper> wallyworld: review is ready
[05:04] <wallyworld> thumper: that's what i suggested too, sigh
[05:04] <thumper> it is a one line change to go from green -> blue
[05:04] <thumper> ok, you too
[05:04] <wallyworld> looking
[05:04]  * thumper heading off to bjj, will check on review later
[05:09] <menn0> thumper-afk: I prefer green (but only slightly)
[05:34] <axw> wallyworld: how will the ListCredentials API be used?
[05:34] <axw> wallyworld: just wondering what's the use if you can't see all of the attributes
[05:35] <wallyworld> axw: the GUI will use it to load credential data to be displayed and to allow to user to paste in new secrets if they want to update their credentials. it still needs to be fleshed out
[05:36] <wallyworld> so for openstack say, you can see you domain and tenant and username etc
[05:36] <wallyworld> but not the secret
[05:36] <wallyworld> i'm thinking we can always add in secrets if needed
[05:37] <axw> wallyworld: yeah ok, I guess that's fine. maybe we could set the value to "" for those attributes at least, so you can tell that they're redacted rather than missing
[05:37] <wallyworld> that's a fair point
[05:37] <wallyworld> i'll do that
[05:37] <axw> wallyworld: or a separate field with names of refacted attrs
[05:38] <axw> redacted*
[05:38] <axw> le shrug
[05:38] <wallyworld> separate field might be ok too
[06:31] <wallyworld> axw: so there's just the revoked issue to consider now - as explained in the rb comment, the api just sets the revoked flag; we need to decide how to best handle that in subsequent prs
[06:33] <axw> wallyworld: ok, will look again in a moment
[06:33] <wallyworld> no rush
[06:48] <axw> wallyworld: I'm having second thoughts about delaying removal of revoked creds now, but we can change it in a follow up if needed
[06:48] <axw> wallyworld: just thinking, in terms of security you probably want that gone from the db ASAP
[06:48] <axw> rather than waiting around for something to stop referring to them
[07:09] <wallyworld> axw: i was kinda thinking the same think, and that goes along with not shipping secrets by default. the reason for a new type is that I wanted to keep cloud.Credential nice and clean, but i guess adding a redacted slice is ok
[07:11] <wallyworld> axw: with remiving them straight away, the idea is that a followup would implement the listener to immediately notify everything that those credentials are gone; that also allows them to be replaced immediately with the same name
[07:11] <wallyworld> so i'm happy to revert to what was there originally
[07:12] <wallyworld> axw: you +1 with s/Revoke/Remove in state ?
[07:29] <axw> wallyworld: you don't need to add Redacted to cloud.Credential yet
[07:30] <wallyworld> axw: yeah, came to the same conclusion
[07:30] <wallyworld> have removed the new type
[07:47] <TheMue> morning
[09:38] <Mmike> Hi, lads. How do I get older version of a charm source? charm-pull-source seems to download only the most recent version. Or: where do I ask questions like this? :)
[10:58] <perrito666> morning
[11:05] <voidspace> perrito666: morning
[11:18] <TheMue> ah, two old colleagues. already wondered where the European ones are.
[11:21] <babbageclunk> fwereade: Thanks for the review - have you got a moment to talk about the Undertaker tests?
[11:37] <perrito666> TheMue: I am not in europe :p
[11:38] <fwereade> babbageclunk, let's
[11:38] <rogpeppe> mgz: just went back to this after a while and found that it had failed, but it's not clear why. any idea? http://juju-ci.vapour.ws:8080/job/github-merge-juju/8952
[11:38] <TheMue> perrito666: no, but at least voidspace should be
[11:38] <babbageclunk> fwereade: Wanna hangout?
[11:38] <TheMue> perrito666: has been so quiet in the channel this morning
[11:39] <fwereade> babbageclunk, sgtm
[11:39] <perrito666> TheMue: well its like 8:30 for me :p
[11:39] <babbageclunk> fwereade: https://hangouts.google.com/hangouts/_/canonical.com/core?hl=en&authuser=1
[11:40] <mgz> rogpeppe: I'll take a look
[11:41] <rogpeppe> mgz: ta
[11:41] <rogpeppe> mgz: not that important, but it's useful to know how/why these things fail
[11:41] <mgz> I agree
[11:42] <rogpeppe> mgz: i sometimes wonder if we should auto-retry when an intermittent error happens that's not to do with the code being tested
[11:43] <mgz> I'd like to surface those to github better at least
[11:43] <rogpeppe> mgz: yeah
[11:44] <rogpeppe> mgz: the main one is that if a merge has been blocked because of critical bugs, it would be good to retry when unblocked
[11:44] <rogpeppe> mgz: i've actually thought of doing a little daemon that would do that for me
[11:51]  * babbageclunk goes for a run.
[12:07] <voidspace> TheMue: I'm still in Europe, yes
[12:07] <voidspace> TheMue: morning o/
[12:08] <TheMue> voidspace: o/ but it seems dimitern and frobware are on vacation
[12:17] <voidspace> TheMue: ah, maybe. I don't see that in the calendar.
[12:18] <TheMue> voidspace: I've only interpreted the silence that way *lol*
[12:19]  * TheMue currently plays a bit with crypto packages for token signatures
[12:20] <voidspace> TheMue: you might be right, I know frobware was going on holiday but I can't remember if he is due back yet or not.
[12:20] <frobware> voidspace: I'm here...
[12:21] <voidspace> frobware: hello o/
[12:21] <frobware> o/
[12:24] <TheMue> ah, hey frobware o/
[12:25] <frobware> TheMue: hello
[12:45]  * frobware runs for some lunch before standup
[13:20] <babbageclunk> dimitern: Did you get everything sorted in the bug you guys were working on?
[13:21] <dimitern> babbageclunk: more or less - I'm working on good, well tested fix now - will start proposing PRs soon :)
[13:21] <babbageclunk> dimitern: nice one
[13:23] <babbageclunk> Yay, thanks whoever added the build-parameters info for queued builds in Jenkins!
[13:23] <babbageclunk> Now I can see how far back mine is. :(
[13:30] <rogpeppe> tiny review: this fixes a couple of unreliable tests: https://github.com/juju/juju/pull/6119
[13:32] <babbageclunk> rogpeppe: LGTM! Failing less often sounds nice.
[13:33] <mgz> rogpeppe: your mp from earlier failed to merge again, in case you didn't see
[13:34] <mgz> rogpeppe: not the same issue
[13:34] <mgz> ah, you resent
[14:01] <perrito666> Bbl doctors appointment
[14:01] <katco> natefinch: dimitern: standup time
[14:02] <katco> fwereade: standup time
[14:09] <rogpeppe> mgz: now i wanna put my "fix unreliable tests" PR near the top of the queue so that the other PRs have more hope of landing...
[14:10] <mgz> :
[14:10] <mgz> D
[14:10] <mgz> ow face cut in half
[14:10] <mgz> we can cancel things above it in the queue that haven't started yet, if there are lots
[14:19] <babbageclunk> mgz: Is build 8976 stuck? It's been running since 12:32.
[14:20] <mgz> lets have a look
[14:21] <mgz> hm, harder to see what's up with the new multi task thing
[14:22] <fwereade> katco, oops, sorry, I was packing
[14:22] <katco> fwereade: no worries; any updates on refcounting stuff?
[14:23] <fwereade> katco, I may or may not land the cleanup change after the flight
[14:24] <fwereade> katco, ...but I have no excuse not to land that one that was already reviewed
[14:24] <fwereade> not *land* the cleanup change, but push it for review
[14:24]  * fwereade fail english? that's unpossible
[14:24] <katco> fwereade: haha
[14:25] <fwereade> probably ought to be off now to avoid panic later
[14:25] <fwereade> o/
[14:25] <katco> fwereade: cool; yeah, figured the cleanup is the more important of the 2? the one you can land just sets the stage?
[14:25] <katco> k tc fwereade
[14:25] <fwereade> katco, yeah exactly
[14:25] <fwereade> later all
[14:25] <katco> fwereade: ta
[14:26] <mgz> babbageclunk: I unstuck it
[14:26] <babbageclunk> mgz \o/
[14:26] <mgz> mattyw: your run failed - the hang was not your fault, but also looks like to have a map-order dependent test failure
[14:26] <babbageclunk> mgz ok now cancel all the other ones except for mine.
[14:27] <mgz> babbageclunk: :P
[14:27] <mattyw> mgz, yeah - that was fixed an hour ago but I'm waiting for this die so I can propose the fix
[14:28] <mgz> ec2 wasn't giving us a machine and the script doesn't have a shorter timeout at the right point for that
[14:33] <natefinch> dimitern: ok, back in the standup hangout?
[14:34] <dimitern> natefinch: omw
[15:07] <natefinch> dimitern: ssh<EMAIL_ADDRESS>[15:17] <babbageclunk> dimitern: Assuming I've turned on security.nesting, I should be able to bootstrap to lxd inside a lxd container, right?
[15:19] <babbageclunk> frobware: ^^
[15:19] <frobware> babbageclunk: yes, been a while since I tried though
[15:20] <frobware> babbageclunk: my profile: http://pastebin.ubuntu.com/23112208/
[15:20] <babbageclunk> frobware: Someone over in #juju is getting an error with beta16 bootstrapping to lxd - I tried it and get the same error, with both lxd 2.1 and 2.0.4
[15:22] <babbageclunk> frobware: They say it wasn't happening in beta15. Does it sound like that packaging problem you guys were talking about?
[15:22] <frobware> babbageclunk: :(
[15:22] <babbageclunk> frobware: I don't see it if I use my built-from-source juju, only in a container with a juju from ppa
[15:23] <babbageclunk> frobware: Anyway, I'll log a bug about it.
[15:23] <frobware> babbageclunk: ack. sidetracked atm :\
[15:24] <babbageclunk> frobware: No worries, just wanted confirmation that it should work. Thanks!
[15:24] <dimitern> babbageclunk: I haven't tried recently
[15:24] <dimitern> I know we set security.nesting by default
[15:27] <babbageclunk> dimitern: ok, thanks.
[16:01] <frobware> babbageclunk: I just started a container OK
[16:02] <frobware> babbageclunk: but I just built from tip of master
[16:02] <babbageclunk> frobware: yeah, I get that as well - try with juju beta16 from the ppa
[16:03] <frobware> babbageclunk: perhaps. I _need_ this bootstrap. :)
[16:04] <babbageclunk> frobware: Tsk! They're cattle not pets! ;)
[16:05] <frobware> babbageclunk: diff between tip and 16: 140 files changed, 4769 insertions(+), 1405 deletions
[16:05] <babbageclunk> frobware: I'm just checking it's a beta16 thing by trying with beta15.
[16:07] <babbageclunk> frobware: yeah, it works with beta15.
[16:08] <redir> morning juju
[16:09] <redir> juju-dev even
[16:10] <frobware> babbageclunk: you have your bisect point
[16:10] <babbageclunk> frobware: gah, sounds like fun!
[16:17] <dimitern> frobware, babbageclunk, voidspace: I'd appreciate a review on this: http://reviews.vapour.ws/r/5559/, I tried to keep the changes straightforward - mostly added tests
[17:09] <mgz> rogpeppe: urk your unreliable test fix branch didn't go through
[17:10] <mgz> feature tests failed
[17:10] <perrito666> it was unreliable
[17:10] <perrito666> :p
[17:10] <perrito666> sorry could not resist
[17:11] <mgz> I'll requeue it later, as my branch before failed due to the one that branch fixes :)
[17:11] <mgz> I think we have a bug for the feature tests already?
[17:12] <mgz> sinzui: do you know? unit test failure of featuretests due to api connection refused
[17:13] <sinzui> mgz: I definitely saw one recently, but I was also reviewing 18 months of data. I will look
[17:13] <mgz> sinzui: thank you
[17:26] <sinzui> mgz: http://reports.vapour.ws/releases/issue/578f7bf1749a567c7344833e is increasing in frequency
[17:28] <sinzui> mgz: cmdStorageSuite.TestStorageAddToUnitSuccess has never failed in CI testing
[17:30] <mgz> hm, I wonder if it's something new on juju-core-slave then
[17:34] <rogpeppe> mgz: i know
[17:34] <rogpeppe> mgz: i've reported a bunch of unreliable test bugs today
[17:34] <mgz> rogpeppe: <3
[17:35] <rogpeppe> mgz: including most recently this: https://bugs.launchpad.net/juju/+bug/1618560
[17:35] <mup> Bug #1618560: worker/txnpruner: sporadic test failure <juju:New> <https://launchpad.net/bugs/1618560>
[17:35] <rogpeppe> mgz: took me a little while to figure out how that could fail (i've added a comment)
[17:35] <rogpeppe> mgz: a lot seem to be failing because they can't contact the API server. not sure what's going on there.
[17:36] <rogpeppe> mgz: feel free to discard any dupes.
[19:09]  * redir lunches
[19:25]  * redir lunches in a minute after reboot
[20:56] <alexisb> wallyworld, I will miss the sts call
[20:56] <wallyworld> ok
[21:02] <wallyworld> niedbalski: google hates me, be there as soon as hangouts starts working
[21:03] <niedbalski> wallyworld, sure, np!
[21:06] <thumper> oh FFS
[21:06] <thumper> this test: BootstrapSuite.TestBootstrapProviderDetectRegions has blocked two landings
[21:06] <thumper> intermittent failure due to ordering
[21:06] <thumper> anyone fixing this yet?
[21:07] <alexisb> https://bugs.launchpad.net/juju/+bug/1618582
[21:07] <mup> Bug #1618582: BootstrapSuite.TestBootstrapProviderDetect(No)Regions fails the expected auth type due to misordering <intermittent-failure> <regression> <trusty> <unit-test> <xenial> <juju:Triaged by wallyworld> <https://launchpad.net/bugs/1618582>
[21:07] <alexisb> ^^^ ian earned a regression
[21:07] <alexisb> but you are welcome ot fix it
[21:08] <alexisb> thumper, ^^
[21:08] <thumper> k
[21:10] <thumper> alexisb: I'll grab it
[21:10] <thumper> it is blocking me
[21:11] <thumper> is there a card for it on the board?
[21:11] <alexisb> thumper, nope
[21:18] <thumper> found it
[21:23] <thumper> quick review for someone: https://bugs.launchpad.net/juju/+bug/1618582
[21:23] <mup> Bug #1618582: BootstrapSuite.TestBootstrapProviderDetect(No)Regions fails the expected auth type due to misordering <intermittent-failure> <regression> <trusty> <unit-test> <xenial> <juju:In Progress by thumper> <https://launchpad.net/bugs/1618582>
[21:23]  * thumper sighs
[21:23] <thumper> this one http://reviews.vapour.ws/r/5561/diff/#
[21:25] <thumper> alexisb: want to review it?
[21:25] <thumper> or menn0
[21:25] <thumper> http://reviews.vapour.ws/r/5561/diff/#
[21:26] <thumper> menn0: morning btw
[21:26] <menn0> thumper: howdy
[21:26] <menn0> alexisb, thumper: I'll review it. I'm OCR.
[21:26] <thumper> menn0: review is a trivial fix for a test that is failing half the time
[21:26] <perrito666> this database is a poorly writen joke
[21:26] <thumper> heh
[21:28] <perrito666> our latest foe https://jira.mongodb.org/browse/SERVER-20729
[21:31] <menn0> thumper: ship it
[21:31] <thumper> ta
[21:34] <menn0> perrito666: i'm not apologising for the db, but that ticket is closed and seems to refer to something dodgy the user was doing
[21:34] <perrito666> menn0: we are being biten by the error, but the cause is not the same
[21:34] <menn0> perrito666: ah ok
[21:35] <perrito666> apparently that can happen for a number of reason included but not limited to, the db shut down abnormally
[21:36] <thumper> menn0: when can we have the external migration flag?
[21:36] <thumper> prechecks seems to be taking longer than we thought
[21:36] <menn0> thumper: it has... I ran into a lot of problems yesterday
[21:37] <menn0> thumper: the latest changes are ready but I noticed a possible issue while QAing yesterday
[21:37] <menn0> thumper: around unit status
[21:37] <menn0> thumper: I can pause prechecks after my current PR is done (although there's only 2 checks left to implement after that actually, but they involve minor API work)
[21:38] <thumper> I've pushed the external flag to beta 18
[21:38] <thumper> so keep with prechecks
[21:38] <menn0> ok
[21:40] <thumper> menn0: thoughts? https://bugs.launchpad.net/juju/+bug/1606991
[21:40] <mup> Bug #1606991: TestWaitMinionNeverBecomeMinion wrong minion <ci> <intermittent-failure> <regression> <unit-tests> <windows> <juju:Triaged> <https://launchpad.net/bugs/1606991>
[21:41] <menn0> thumper: nothing to do with migrations if that's what you're thinking
[21:41] <menn0> thumper: will just happened to use the word minion for this leadership test
[21:42] <menn0> thumper: I have almost no clue about how leadership works
[21:42] <menn0> thumper: but I can dig into it if you need me to
[22:03] <thumper> menn0: txn pruner clock branch: http://reviews.vapour.ws/r/5562/
[22:04] <thumper> menn0: ok, re bug abovev
[22:05] <thumper> wallyworld: https://bugs.launchpad.net/juju/+bug/1603176 thoughts on this?
[22:05] <mup> Bug #1603176: juju debug-log returns not logged-in error <debug-log> <login> <juju:Triaged> <https://launchpad.net/bugs/1603176>
[22:06] <menn0> thumper: ok, just reviewing perrito666's PR atm, will do yours next
[22:06] <thumper> I wonder if it is how we are passing creds through to the streaming apis
[22:06] <wallyworld> hmmm
[22:07] <wallyworld> off hand i am not sure, but it does seem suspicious that it's not for a normal rpc call
[22:21] <menn0> perrito666: the diff on RB for PR 6104 doesn't match what's actually in the PR on Github
[22:21] <menn0> perrito666: in the review UserAccessSpec has ObjectID, but the PR doesn't have that
[22:22] <menn0> perrito666: sorry ObjectUUID, not ObjectID
[22:25] <thumper> hmm... enable-ha on to two manual machines seem to not work
[22:30] <thumper> can anyone else see the problem here? http://pastebin.ubuntu.com/23113867/
[22:30] <thumper> both amusing and not at the same time
[22:31] <menn0> thumper: it should be using a non localhost IP otherwise the other nodes can't connect?
[22:31] <thumper> :)
[22:32] <thumper> well.. it complains a few lines lower that it has multiple entries with the same _id
[22:32] <thumper> I'm poking more
[22:32] <menn0> thumper: regarding the txnpruner fix, it looks great but I don't think you need the started channel do you?
[22:33] <thumper> menn0: kinda, otherwise the test doesn't know when to start advancing the clock
[22:33] <thumper> unless you have other ideas
[22:34] <menn0> I think I do...
[22:34]  * menn0 checks the test clock
[22:34] <menn0> I think the test clock has a feature to let the test know when After has been called
[22:36] <menn0> thumper: yep, that's it. The testing clock can return a channel via the Alarms method which lets you know when After has been called
[22:36] <menn0> thumper: you can just wait for that in the test
[22:36] <menn0> it's exactly for this use case
[22:36] <thumper> ah, cool
[22:36] <thumper> please leave a note :)
[22:36] <menn0> will do
[22:36] <thumper> that was the only bit I was not happy with
[22:37] <thumper> hmm...
[22:37]  * thumper wonders how this works with ha lxd
[22:38]  * thumper fires one up
[22:38] <thumper> has anyone else got tab completion woes with juju?
[22:38] <thumper> juju _juju_complete_2_0: command not found
[22:39] <thumper> that was juju <tab>
[22:39] <menn0> thumper: ship it
[22:45] <menn0> thumper: it looks like the juju-2.0 package isn't installing /etc/bash_completion.d/juju-2.0
[22:46] <thumper> I haven't installed the package
[22:46] <thumper> I'm running from source
[22:46] <menn0> thumper: you don't have the official juju-2.0 installed as well?
[22:47] <thumper> nope
[22:47] <thumper> don't think so
[22:47] <menn0> if you installed from source how could bash know where to find the completion?
[22:47] <thumper> probably should yes?
[22:48] <thumper> I do have that installed
[22:48] <menn0> hmmm, it actually works for me
[22:48] <thumper> and I am missing  /etc/bash_completion.d/juju-2.0
[22:49] <menn0> I have juju-2.0-beta17 installed
[22:49] <thumper> hmm... I must be missing the ppa
[22:49] <thumper> I have beta 15
[22:50] <menn0> thumper: I actually just have /etc/bash_completion.d/juju-core and that seems to work
[22:50] <thumper> and beta 15 doesn't install anything in /etc/bash_completion.d
[22:50] <menn0> there's more stuff in /usr/share/bash-completion/juju*
[22:50] <menn0> that's probably the problem then
[22:50]  * menn0 checks where his juju package came from
[22:51] <menn0> thumper: yeah, I have the stable PPA
[22:51] <menn0> cd
[22:52] <thumper> menn0: just the stable?
[22:52] <menn0> thumper: yep
[22:52] <thumper> stable doesn't ahve juju in it
[22:52] <thumper> menn0: as in ppa:juju/stable
[23:00] <thumper> interesting
[23:00] <thumper> when using lxd in ha mode
[23:00] <thumper> the same input generates a different result
[23:00] <thumper> curious
[23:16] <perrito666> menn0: sorry was at the market, what happened with gh and rb?
[23:17] <menn0> perrito666: the diff on Github is not the same as the one on RB
[23:18] <perrito666> meh, that sucks (that being rb)
[23:18] <perrito666> menn0: so your review does not apply?
[23:19] <menn0> perrito666: well most of it will still apply
[23:19] <perrito666> menn0: tx for the heads up btw, ill take a look to see if I can make them be the same
[23:20] <menn0> perrito666: the main thing I noticed is that state.UserAccessSpec doesn't have ObjectUUID in the pull request on Github
[23:20] <menn0> perrito666: did you manually update the diff on RB?
[23:21] <perrito666> menn0: nope
[23:21] <menn0> weird
[23:21] <perrito666> menn0: I dont even have the tools for that on my system
[23:42] <menn0> axw: the maximum log buffer size would be around 100MB
[23:42] <menn0> so not ridiculous
[23:46] <axw> menn0: ah that's probably not it then, thanks
[23:49] <thumper> rogpeppe: I fixed that bootstrap test already
[23:49] <thumper> rogpeppe: you didn't mark in the bug that you were fixing it
[23:49] <thumper> so I did
[23:55] <perrito666> menn0: love your doorbell