[00:59] <kyrofa> sergiusens, elopio snapcraft#1638 looks good (I reviewed it previously as well), but I notice no adt has run. It's kind of a big re-org, think it's a good idea?
[00:59] <mup> PR snapcraft#1638:  tests: reorganize unit and integration suites to make them easier to split for travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1638>
[01:01] <elopio> kyrofa: let me update the other one so they run on the nightly
[01:02] <kyrofa> elopio, so don't land this yet?
[01:03] <elopio> kyrofa: ah, I thought it was landed already. Well, I guess we are in no hurry because it's already EOD. Let me trigger a few, and we land tomorrow morning.
[01:04] <kyrofa> Yeah that seems reasonable. And gives me an opportunity to test the new subscriptions
[01:04] <elopio> where's the bot?
[01:11] <elopio> snappy-m-o autopkgtest 1638 xenial:armhf xenial:amd64
[01:11] <snappy-m-o> elopio: I've just triggered your test.
[01:13] <elopio> snappy-m-o github subscribe 1638
[01:13] <snappy-m-o> elopio: I'll send you updates as tests complete in pull request snapcraft#1638 ( tests: reorganize unit and integration suites to make them easier to split for travis).
[01:13] <mup> PR snapcraft#1638:  tests: reorganize unit and integration suites to make them easier to split for travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1638>
[01:13] <elopio> I'm now sure if the subscribe thing is working.
[01:14] <kyrofa> snappy-m-o, github subscribe 1638
[01:14] <snappy-m-o> kyrofa: I'll send you updates as tests complete in pull request snapcraft#1638 ( tests: reorganize unit and integration suites to make them easier to split for travis).
[01:14] <kyrofa> elopio, yeah me neither, but I wasn't before, either
[01:14] <kyrofa> Now we know that is MUST ping us either way
[01:41] <sergiusens> snappy-m-o, github subscribe 1638
[01:41] <snappy-m-o> sergiusens: I'll send you updates as tests complete in pull request snapcraft#1638 ( tests: reorganize unit and integration suites to make them easier to split for travis).
[01:41] <mup> PR snapcraft#1638:  tests: reorganize unit and integration suites to make them easier to split for travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1638>
[01:41] <sergiusens> elopio kyrofa by default I think the bot should just go ahead and ping (all of us or at least the author)
[01:42] <kyrofa> sergiusens, it's not smart enough to tie github users to IRC nicks
[01:42] <kyrofa> I guess it would work for us though, just use the same
[01:43] <kyrofa> sergiusens, we recently updated it to ping us on failure OR success though
[01:43] <sergiusens> kyrofa we can make a manual "team" map.
[01:43] <kyrofa> Yeah that would be easy as well
[06:02] <mborzecki> good morning
[06:27] <mborzecki> mvo: morning
[06:27] <mvo> hey mborzecki
[06:28] <mvo> mborzecki: how are you?
[06:28] <mborzecki> good, thank you
[06:28] <mborzecki> sorry to bugging you early morning but would you mind taking a look at https://github.com/snapcore/snapd/pull/4235 ?
[06:28] <mup> PR #4235: cmd: pretend we're running on Ubuntu in TestExecInCoreSnapUnsetsDidRe… <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4235>
[06:28] <mvo> mborzecki: sure
[06:29] <mborzecki> this is the last thing that's currently blocking unit tests on arch
[06:29] <mvo> mborzecki: aha, ok. sure, I have a look. I'm still slightly puzzled why its needed but I will poke at it a bit (and may come back with questions)
[06:29] <mborzecki> ok
[06:30] <mvo> pedronis: thanks a lot for 4222!
[06:49] <mvo> mborzecki: I just checked the test, the issue is that the test is using /snap unconditionally when it needs to use dirs.SnapMountDir (silly test). so http://paste.ubuntu.com/25979289/ fixes the test for me without the need to do the mocking (its also more correct). could you please double check and if it also works for you just patch -R the current diff and force push the smaller diff?
[06:50] <mvo> mborzecki: or not force push just keep it as a regular commit
[06:50] <mvo> mborzecki: and when can squash-merge it
[06:50] <mborzecki> thanks, i'll check it locally and let you know
[06:51] <mvo> thanks
[07:07] <mborzecki> mvo: the snippet you posted works locally ;) i'll push changes shortly
[07:07] <mvo> mborzecki: yay, thank you
[07:15] <mborzecki> mvo: revert & patch are pushed now, thanks for the hint on fixing this, no need to go through the silly mock/restore trampoline :)
[07:17] <mvo> mborzecki: thanks! indeed but the real silliness was in the test to hardcode the /snap prefix
[07:40] <kalikiana> o/
[08:46] <pedronis> mvo: hi, was this fixed:  https://forum.snapcraft.io/t/spread-cron-is-not-running-snapd-vendor-sync/2739  ?
[08:48] <mvo> pedronis: yes, this is working again.
[08:49] <mvo> pedronis: cachio fixed it some days ago and it seems to be ok, I just checked the build history
[08:50] <mvo> mborzecki: btw, do you know the status of the lxd issue? I guess zyga worked late(?)
[08:51] <mborzecki> mvo: https://forum.snapcraft.io/t/snapcraft-adt-failures-with-the-new-core-release/2850/62 we're waiting for a patch from zyga
[08:51] <mborzecki> other than that g+s
[08:51] <mvo> mborzecki: thank you
[08:52] <mborzecki> what's the plan for .4 release?
[08:54] <mvo> mborzecki: we do it as soon as we have a patch, ideally today
[08:57] <pedronis> mvo: are you going to do a separate PR for checking pending refreshes when refreshes are managed?
[08:58] <pedronis> mvo: using #4232 basically
[08:58] <mup> PR #4232: store: add support for flags in ListRefresh() <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4232>
[08:58] <mvo> pedronis: either way is fine with me, I can separate it out or put it into the main one, whatever is easier to review for you
[08:59] <pedronis> mvo: it's going to be a separate cycle, right?  separate PR would seem better in that case
[09:00] <mvo> pedronis: I hope we can get it in for 2.30
[09:00] <pedronis> ?
[09:00] <mvo> pedronis: but separate is fine with me, probably easier to review
[09:01] <pedronis> I don't think we can merge the rest without that, afaiu, so it needs to be in 2.30
[09:01] <mvo> pedronis: yes, then we are in agreement. I misunderstood when you said separate cycle
[09:01] <pedronis> I mean separate cycle
[09:01] <pedronis> in the sense of the scheduling inside snapd
[09:01] <mvo> pedronis: yes, I think so
[09:02] <mvo> pedronis: that seems to make most sense
[09:02] <pedronis> ok
[09:02] <pedronis> I think we are in agreement
[09:03] <mvo> pedronis: cool, its my next task, I hope to get something ready by EOD
[09:03] <mvo> pedronis: firefox 57 happend and all my extension (not all, but almost) are dead so I had a bit of unplanned fixtime on this this morning :(
[09:03] <mvo> pedronis: anyway, I get back to schedule (and review feedback fixing and code reivews)
[09:04] <pedronis> it's ok, anyway it's still a bit until 2.30 beta? or I'm reading the roadmap wrong?
[09:04] <pedronis> s/I'm/am I/
[09:04] <mvo> pedronis: we still have a bit of time yes
[09:05] <mvo> pedronis: its adjusted for .4 :/
[09:05] <pedronis> mvo: is just me of mborzecki  stuff seems a bit unlikey for 2.30
[09:05] <mvo> pedronis: also autopkgtests on i386 are failing access the board for unknown reasons
[09:05] <mborzecki> pedronis: refresh timers?
[09:05] <mvo> pedronis: its unlikely :) but reflecting what is being worked on, I think its ok if it moves to 2.31
[09:05] <pedronis> time servers
[09:05] <pedronis> services
[09:06] <pedronis> mvo: ok, was just confused
[09:06] <mvo> pedronis: no worries :)
[09:06] <mborzecki> time servers... you made my hear skip a beat :)
[09:06] <pedronis> mborzecki: it's was a comment on you or anything, just a bit confused because it will take a while to code and get through review, especially given we would like to clean up the current stuff too
[09:07] <mborzecki> no worries :)
[09:10] <pedronis> mvo: I want to produce a couple of small PRs about things I mentioned yesterday at standup then I will look at your main PR again
[09:12] <mvo> pedronis: sounds good
[09:13] <mup> PR snapd#4239 opened: tests: more debug info for classic-ubuntu-core-transition <Created by mvo5> <https://github.com/snapcore/snapd/pull/4239>
[09:51] <mup> PR snapd#4240 opened: spread.yaml: increase workers for opensuse to 3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4240>
[09:56] <mup> PR snapcraft#1638 closed:  tests: reorganize unit and integration suites to make them easier to split for travis <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1638>
[10:14] <zyga-ubuntu> o/
[10:14] <zyga-ubuntu> sorry for being so late, I need to balance my sleep/wake cycle :/
[10:14] <mborzecki> zyga-ubuntu: hey
[10:17] <jamesh> zyga-ubuntu: hi.  I pushed through some changes to my user-mounts PR (rebasing on master and converting it to use snap-update-ns).  It probably still isn't quite right, but it seems to handle the simple cases I tried.
[10:17] <mvo> hey zyga-ubuntu ! good morning
[10:17] <zyga-ubuntu> jamesh: hey! thank you for doing that, I saw the notification and I'll have a look today
[10:18] <zyga-ubuntu> jamesh: what are your next plans?
[10:18] <zyga-ubuntu> mvo: hey, sorry :|
[10:18] <zyga-ubuntu> mvo: but but, were on one page of PRs :)
[10:18] <jamesh> zyga-ubuntu: I'd like to try and get portals working
[10:18] <zyga-ubuntu> jamesh: what bits are missing?
[10:19] <jamesh> so updating those branches from months back, probably folding it into the desktop interface
[10:19] <mvo> zyga-ubuntu: :)
[10:20] <mvo> zyga-ubuntu: we just need to merge one, e.g. the opensuse one and we are back on a single page
[10:20] <jamesh> zyga-ubuntu: the user-mounts thing is the main missing infrastructure.  We might run into some issues with how we change $XDG_RUNTIME_DIR though
[10:21] <jamesh> parts of document portal expect certain paths to be the same inside and outside the mount namespace.
[10:21] <zyga-ubuntu> jamesh: please update the forum thread with your plans; I'm slowly getting layout code in place and I can help
[10:22] <zyga-ubuntu> today I'm a bit dizzy for complex things but I should have fresh head on Monday
[10:24] <zyga-ubuntu> mvo: not sure if you were following the LXD discussion last night, I'll do what we agreed with jdstrand; make snap-confine setgid, drop the gid part early on and only restore it for that single freeze operation
[10:24] <zyga-ubuntu> mvo: I should have that ready in ~1.5 hours
[10:24] <zyga-ubuntu> mvo: hopefully by EOD we can push to beta
[10:25] <mvo> zyga-ubuntu: \o/
[10:25] <mvo> zyga-ubuntu: I'm trying to understand a pkgtest failure on i386 in parallel, worst case is that we need to disable one test in autopkgtest (ubuntu-core-transition is failing *only* on i386)
[10:26] <mvo> zyga-ubuntu: so +1 for a .4
[10:26] <zyga-ubuntu> only on i386, curious
[10:26] <zyga-ubuntu> mvo: thank you, good luck
[10:29] <pstolowski> mvo, hey, what's up with https://github.com/snapcore/snapd/pull/4063 ?
[10:29] <mup> PR #4063: tests: add new kernel refresh/revert test for spread-cron <Created by mvo5> <https://github.com/snapcore/snapd/pull/4063>
[10:31] <mborzecki> zyga-ubuntu: took a deeper look into https://forum.snapcraft.io/t/installing-vscode-snap-on-arch-linux/2871/5 imo there's something wrong with what's shipped in the snap, my best guess those libs are pieces of fedora userspace
[10:32] <zyga-ubuntu> mborzecki: vscode is a classic snap
[10:32] <zyga-ubuntu> mborzecki: no namespace magic, problems
[10:32] <pedronis> zyga-ubuntu: hi, what's the status of #4109
[10:32] <mup> PR #4109: cmd/libsnap: fix parsing of empty mountinfo fields <Created by zyga> <https://github.com/snapcore/snapd/pull/4109>
[10:32] <zyga-ubuntu> pedronis: it's not critical, just something I found while hacking
[10:33] <zyga-ubuntu> pedronis: there's a cleanup that I could move out of the function
[10:33] <zyga-ubuntu> pedronis: and a fix itself
[10:33] <zyga-ubuntu> pedronis: other than that not sure
[10:33] <mvo> pstolowski: meh, no time yet for this
[10:33] <pstolowski> mvo, ah, ok, no pressure, just checking
[11:24] <cachio> zyga-ubuntu, hey
[11:26] <cachio> zyga-ubuntu, I have defined for a test this snap https://github.com/sergiocazzolato/snapd/blob/tests-interface-network-status/tests/lib/snaps/test-snapd-network-status-provider/snapcraft.yaml
[11:27] <cachio> zyga-ubuntu, but I am getting some denials when I do "sudo systemd-run --unit dbus-provider-2 test-snapd-network-status-provider.provider"
[11:28] <zyga-ubuntu> cachio: hmm
[11:28] <zyga-ubuntu> cachio: what kind of denials
[11:30] <cachio> zyga-ubuntu, https://paste.ubuntu.com/25980351/
[11:30] <zyga-ubuntu> aha
[11:30] <zyga-ubuntu> is this blocking the test?
[11:30] <zyga-ubuntu> it seems that snap wants to look at the mount table
[11:30] <zyga-ubuntu> that should be handled by mount-observe
[11:30] <zyga-ubuntu> not sure why it needs it, just saying
[11:31] <cachio> zyga-ubuntu, I already tried that
[11:31] <zyga-ubuntu> owner @{PROC}/@{pid}/mounts r,
[11:31] <zyga-ubuntu> mount-observe grants this
[11:31] <zyga-ubuntu> what did you try?
[11:32] <cachio> yes, let me try again
[11:32] <pstolowski> Chipaca, hello! is this clear what we want wrt to environ in commands here https://forum.snapcraft.io/t/papercuts-mouth-sized-bugs/228 ?
[11:35] <cachio> zyga-ubuntu, I plug mout-observe and I see this https://paste.ubuntu.com/25980371/
[11:35] <zyga-ubuntu> cachio: is this test looking at its own mount table?
[11:36] <zyga-ubuntu> the rule says 'owner'
[11:36] <cachio> no
[11:37] <cachio> it is trying just to own the com.ubuntu.connectivity1.NetworkingStatus dbus interface
[11:37] <zyga-ubuntu> cachio: I'm sorry but I don't know why it would also try to access the mount table
[11:44] <Chipaca> pstolowski: what do you mean?
[11:45] <cachio> zyga-ubuntu, I have to go to the doctor
[11:45] <zyga-ubuntu> cachio: ok
[11:45] <cachio> zyga-ubuntu, I'll be 5-10 minutes late for the standup
[11:46] <Chipaca> pstolowski: the one about them being too restrictive?
[11:47] <pstolowski> Chipaca, no; do we want to interpolate "command: FOO=$SNAP/bar actual_command" or "command: env PATH=$SNAP/usr/local/bin:$PATH desktop-launch" ?
[11:47] <Chipaca> pstolowski: me, i'd explore something like: first, support having env vars as arguments to commands (even the first argument). Second, support arbitrary arguments but with no quoting nor escaping (so just disallow '"\)
[11:48] <Chipaca> pstolowski: and third, make commands be either a string, or a list; if a list, pass to exec as is
[11:48] <Chipaca> the reason for not getting into quoting and such is because it's a nightmare
[11:49] <Chipaca> and the list approach makes it not needed
[11:49] <Chipaca> (the list would take quotes and backslashes and pass them through)
[11:49] <Chipaca> um
[11:49] <Chipaca> pstolowski: answering your question there, no that's not the idea at all
[11:49] <Chipaca> pstolowski: commands already have an environment
[11:50] <Chipaca> that is, apps have an environment
[11:50] <Chipaca> pstolowski: this is about support “command: foo $BAR $BAZ”
[11:51] <mup> PR snapcraft#1742 opened: lxd: always remove tmp_dir after execution <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1742>
[11:51] <Chipaca> it's possible that work is already done though; not sure
[11:51] <pstolowski> Chipaca, ok, that should work if I read the code correctly
[11:51] <Chipaca> that post is old
[11:51] <pstolowski> Chipaca, yeah, and it originated from https://forum.snapcraft.io/t/declaratively-defining-environment-variables/175/6
[11:52] <pstolowski> Chipaca, I'm trying to understand if what's done or not, there were a couple of aspects discussed there, I'm unclear what do we want at the end
[11:54] <Chipaca> pstolowski: I think there is still work to be done here, but i've not looked in a while as i say
[11:55]  * kalikiana time for a break
[11:56] <Chipaca> popey: is the mailspring snap doing something wrong, or do none of the desktop integration bits work for anybody?
[11:56] <Chipaca> i mean system tray and notifications, in particular
[11:57] <Chipaca> (my indicators don't even work for regular apps for whatever reason but that's another discussion))
[11:58] <pstolowski> Chipaca, I see, thanks
[12:16] <sergiusens> Chipaca indicators fail completely for me, OSD works fine for mailspring
[12:24] <popey> Chipaca: what version of Ubuntu?
[12:25] <Chipaca> popey: 16.04
[12:25] <popey> zyga-ubuntu / mvo your favorite topic! https://forum.snapcraft.io/t/vdpau-support-in-snaps-on-nvidia/2876
[12:25] <popey> :)
[12:25] <Chipaca> popey: i thin right now lxd is more favourite
[12:25] <Chipaca> also my keyboard is dying :-(
[12:29] <jdstrand> ikey|zzz: hey, regarding your forum post (https://forum.snapcraft.io/t/manual-review-of-base-snaps/2839/4), both zyga and I responded to you (so not talking into the void). we need an architect to participate in the discussion, hence the open question to niemeyer in that topic
[12:29]  * ogra_ hands Chipaca https://www.massdrop.com/buy/xmit-hall-effect-mechanical-keyboard
[12:31]  * popey bans ogra_ for posting massdrop links, which will cause the collapse of the economy as we all buy them
[12:31] <ogra_> hahaha
[12:33] <Chipaca> also, that import duty
[12:33] <Chipaca> ogra_: i've got a lot of nice keyboards! the one that's dying is the one for my tablet (that i'm currently on)
[12:34] <ogra_> ah, thats bad indeed
[12:34] <ogra_> well, the above is indistructable ... (at least the switches)
[12:34] <jdstrand> pedronis: hey, I think that the base declaration is correct and the spread test failure, while real, is the right behavior
[12:35] <pedronis> jdstrand: my point is mostly that people that were testing snaps doing this will need to change their tests
[12:35] <jdstrand> pedronis: "Then the plug is connected by default"
[12:35] <jdstrand> the test should be adjusted
[12:36] <pedronis> because they don't get autoconnection for their --dangerous install anymore
[12:36] <jdstrand> I understand that
[12:36] <pedronis> just making clear this will be  a "regression" for them
[12:36] <jdstrand> that is the correct behavior. there are 5 snaps that use this
[12:37] <pedronis> I know
[12:37] <jdstrand> so I can communicate that to them and in documentation
[12:37] <pedronis> ok
[12:37] <pedronis> I fixed the integration test already
[12:37] <jdstrand> but it does mean the spread test needs to be adjusted
[12:37] <pedronis> I did that
[12:37] <pedronis> I think we are getting other spurious failures now
[12:37] <jdstrand> oh I missed that
[12:38]  * jdstrand looks
[12:38] <pedronis> it's just taking too long
[12:38] <pedronis> there's a PR by mvo that could help with that
[12:48] <pedronis> mvo: we still got prepare failures in you add opensuse workers PR :/
[12:48] <pedronis> *your
[12:49] <Son_Goku> pedronis, have we sync'd the Fedora 27 VM base image to the current Fedora 27 GA?
[12:49] <Son_Goku> and resync'd Rawhide to a recent snapshot of it?
[12:50] <pedronis> no clue
[12:50] <pedronis> I'm not on top of that
[12:50] <mup> PR snapd#4241 opened: store: bit less aggressive retry strategy <Created by pedronis> <https://github.com/snapcore/snapd/pull/4241>
[12:50] <Son_Goku> who is?
[12:50] <pedronis> mvo, zyga-ubuntu, cachio
[12:51] <pedronis> maybe
[12:51] <pedronis> Chipaca: could you look at #4241 (it's tiny)
[12:51] <mup> PR #4241: store: bit less aggressive retry strategy <Created by pedronis> <https://github.com/snapcore/snapd/pull/4241>
[12:51] <zyga-ubuntu> Son_Goku: cachio is working on updating the debian images, we alredy said that other images must follow
[12:51] <Chipaca> sure
[12:52] <Chipaca> pedronis: +1
[12:52] <pedronis> thx
[13:20] <mup> PR snapd#4242 opened: panic early if snapd is pointed to staging but staging keys are not compiled-in <Created by pedronis> <https://github.com/snapcore/snapd/pull/4242>
[13:26] <zyga-ubuntu> mvo: I'll push the branch in a moment, just want to see it work one more time
[13:26] <pedronis> mvo: do we need to disable the opensuse tests until we understand more?
[13:26] <zyga-ubuntu> pedronis: +1, also for fedora if that is broken and would impede release
[13:26] <cachio> Son_Goku, zyga-ubuntu the new fedora images will be ready early next week
[13:27] <Son_Goku> cool
[13:37] <cachio> mvo, zyga-ubuntu the debian images are not updated yet
[13:45] <sborovkov> Hi
[13:45] <sborovkov> No matching distribution found for python-distutils-extra (from snapcraft)
[13:45] <sborovkov> I am getting this when doing pip install snap craft on ubuntu
[13:45] <sborovkov> How do I work around this?
[13:57] <zyga-ubuntu> mvo: can you look at https://github.com/snapcore/snapd/pull/4230/commits/7722c0404b97fa0ac119acb495caa62c3f5ab321 please
[13:57] <mup> PR #4230: tests: add test to run snap inside lxd as a user <Created by mvo5> <https://github.com/snapcore/snapd/pull/4230>
[14:01] <sergiusens> sborovkov `pip install -r https://raw.githubusercontent.com/snapcore/snapcraft/master/requirements.txt`  python-apt and -distutils-extra are not on pypi
[14:02] <sborovkov> sergiusens, thanks
[14:02] <mvo> zyga-ubuntu: sure, looking
[14:03] <cachio> jdstrand, hey
[14:03] <mvo> zyga-ubuntu: looks good, thank you
[14:05] <cachio> jdstrand, I am creating s snap with this https://paste.ubuntu.com/25980439/
[14:05] <cachio> jdstrand, this is the python code: https://paste.ubuntu.com/25981110/
[14:05] <cachio> jdstrand, and when I do "sudo systemd-run --unit dbus-provider-2 test-snapd-network-status-provider.provider"
[14:05] <cachio> I see this denial
[14:05] <cachio> jdstrand, https://paste.ubuntu.com/25980371/
[14:06] <cachio> jdstrand, any idea what could be the reason?
[14:08] <zyga-ubuntu> jdstrand: can you look as well please, that's the thing you suggested last night
[14:08] <jdstrand> cachio: does the snap fail to work with that? most often that is a noisy denial and not a problem. The snap could plugs the mount-observe interface to get rid of it
[14:09] <jdstrand> cachio: python is one of those environments that does that (noisy denial but works otherwise)
[14:10] <cachio> jdstrand, ok
[14:10] <cachio> I'll check that
[14:11] <jdstrand> zyga-ubuntu: sure
[14:14] <cachio> jdstrand, https://paste.ubuntu.com/25981162/
[14:14] <cachio> jdstrand, it is not from a snap
[14:14] <mborzecki> i'm calling it a day, have a nice weekend everyone
[14:38] <mvo> cachio: thanks for checking 4240 - is there something we can do to help the opensuse tests to run faster again?
[14:39] <mvo> cachio: i.e. caching the downloads and storing that in our test-image or something?
[14:39] <cachio> mvo, I think the best we can do is to update regularly the images
[14:39] <cachio> so all the provisionning part is reduced almost to 0
[14:40] <cachio> mvo, I'll work on that next week
[14:40] <cachio> I'll need a new key for this
[14:42] <mvo> cachio: ok, thanks
[14:42] <mvo> cachio: should we disable opensuse until then?
[14:43] <sergiusens> elopio kyrofa updating the tests from other branches takes a bit
[14:44] <cachio> mvo, I'll take a look to opensuse
[14:44] <mvo> cachio: thank you
[14:44] <cachio> mvo, not sure why it is failing noe
[14:44] <cachio> now
[14:44] <cachio> it is a timeout in the prepare trying to install dependencies
[14:45] <cachio> mvo, it shouldn't happen
[14:52] <mup> PR snapd#4243 opened: tests: disable classic-ubuntu-core-transition on i386 temporarly <Created by mvo5> <https://github.com/snapcore/snapd/pull/4243>
[14:53] <zyga-ubuntu> mvo: tests/main is green, let's release this
[14:53] <zyga-ubuntu> can everyone available please review 4230
[14:53] <mvo> zyga-ubuntu: which one is green?
[14:53] <zyga-ubuntu> mvo: (tests/main ran locally)
[14:54] <mvo> zyga-ubuntu: for what PR (sorry, I lack context somehow)
[14:54] <zyga-ubuntu> mvo: 4230
[14:54] <mvo> zyga-ubuntu: don't we need a +1 from jamie first?
[14:54] <zyga-ubuntu> mvo: right, that's why I asked for reviews :)
[14:55] <mvo> zyga-ubuntu: aha, ok. yeah, +1 for releasing asap
[14:55] <elopio> good morning.
[14:55] <mvo> zyga-ubuntu: but it looks like your PR will fail on opensuse :/ only 3 min left and
[14:55] <mvo> 80 tests to run
[14:56] <zyga-ubuntu> oh drat
[14:56] <zyga-ubuntu> mvo: well, this is master
[14:56] <mvo> zyga-ubuntu: yeah
[14:56] <zyga-ubuntu> mvo: shall we disable suse or shall we bump the number of workers by one?
[14:56] <zyga-ubuntu> mvo: we can do a tailored PR in 2.29
[14:57] <mvo> zyga-ubuntu: adding a worker was not enough, I'm in favor of disabling
[14:57] <mvo> zyga-ubuntu: but cachio said he is looking into it
[14:57] <zyga-ubuntu> mvo: ok
[15:01] <cachio> mvo, zyga-ubuntu I am reproducing the error here
[15:01] <cachio> we can disable it until the problem is fixed
[15:01] <zyga-ubuntu> do we have any idea why it might be slower?
[15:02] <cachio> no yet, waiting for the timeout yet
[15:02] <cachio> zyga-ubuntu, let's disabe opensuse, then we can enable it again
[15:15] <cachio> zyga-ubuntu, mvo I tested here and it worked
[15:15] <cachio> perhaps is a temporal issue
[15:17] <zyga-ubuntu> cachio_lunch: did oyu test on linode?
[15:25] <kyrofa> sergiusens, do we want to determine a landing order for these other PRs?
[15:25] <kyrofa> (so we know which ones to fix first)
[15:30] <mvo> zyga-ubuntu: you have review feedback for 4230
[15:30] <zyga-ubuntu> looking
[15:30] <mvo> zyga-ubuntu: let me know if you want help :)
[15:30] <jdstrand> yes, was just going to ping you on that :)
[15:30] <mvo> zyga-ubuntu: but looks straightforward
[15:30] <zyga-ubuntu> thank you jdstrand
[15:45] <zyga-ubuntu> mvo: testing and I'll push in a sec
[15:49] <mup> PR snapcraft#1743 opened: catkin plugin: support building entire workspace <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1743>
[15:51] <zyga-ubuntu> mvo: did you disable suse?
[15:51] <zyga-ubuntu> mvo: I'd like to pull master and then push this
[15:52] <zyga-ubuntu> mvo: you can, I think, just git push the backend to manual
[15:52] <zyga-ubuntu> mvo: to save us some time
[15:55] <zyga-ubuntu> mvo: I pushed, please merge/squash
[15:56] <zyga-ubuntu> jdstrand: https://github.com/snapcore/snapd/pull/4230/files
[15:56] <mup> PR #4230: tests: add test to run snap inside lxd as a user <Created by mvo5> <https://github.com/snapcore/snapd/pull/4230>
[15:57]  * zyga-ubuntu needs to play with those real/effective/saved ids thing more
[15:59] <cachio> zyga-ubuntu, I tested on linode
[15:59] <cachio> zyga-ubuntu, I executed again the change to add a new worker for suse
[16:00] <cachio> let's see if it fails again
[16:00] <cachio> if it fails I'll disable opensuse
[16:01] <jdstrand> zyga-ubuntu: done. sorry I forgot something in my suggestion (teeny change)
[16:01] <zyga-ubuntu> jdstrand: aha
[16:02] <zyga-ubuntu> jdstrand: pushed :)
[16:03]  * zyga-ubuntu needs to run
[16:03] <cachio> jdstrand, https://paste.ubuntu.com/25981162/
[16:03] <cachio>  jdstrand, it is not from the tests
[16:03]  * kalikiana dinner time
[16:04] <zyga-afk> mvo: please get this to beta tonight if we can
[16:04] <zyga-afk> mvo: I'll be back in some hours
[16:05] <mvo> zyga-afk: I will push for it
[16:11] <kyrofa> elopio, one issue with the refactor now that I'm using it: it tells me tests are skipped, but doesn't say it's because they were slow
[16:11] <kyrofa> Before the refactor it was helpful and said "skipping slow test" or something like that
[16:11] <mvo> zyga-afk: once tests are in I will run the machinery
[16:11] <mvo> zyga-afk: thanks a bunch of fixing this!
[16:15] <pedronis> mvo: I did another pass on managed,  but didn't see your last commit, now I saw, I think the placement of that code is problematic
[16:16] <pedronis> *saw it
[16:16] <sergiusens> kyrofa oh, if that is happening, I'd agree
[16:16] <kyrofa> Alright, fixing
[16:17] <sergiusens> kyrofa also, rebase on top of new master
[16:17] <sergiusens> kyrofa I did minor piggybacking on that last merge (sorry, but sorry)
[16:17] <kyrofa> cratliff, catkin-tools has finally landed!
[16:18] <sergiusens> kyrofa and take extra care on your rebases/merges as things need to manually move on your side for tests to keep on running ;-)
[16:18] <kyrofa> sergiusens, yeah I'm working through the ament one now
[16:18] <kyrofa> Basically, if you added any new test files, they need to move, but if you modified ones that were already there, you're mostly there
[16:19] <mup> PR snapcraft#1593 closed: catkin tools plugin: add catkin tools support <Created by cratliff> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1593>
[16:21] <pedronis> mvo: we can discuss options on Monday
[16:26] <pedronis> mvo: do you need anything more from me today?
[16:29] <mvo> pedronis: thank you, I think I'm fine, I will baby-sit the build and do 2.29.4
[16:31] <elopio> kyrofa: how weird. Please report a bug, and I'll look at it as soon as I'm over with the call for testing.
[16:31] <elopio> flexiondotorg: popey: can I send a coschedule post linking to the call for testing? https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-35/2880
[16:33] <mup> PR snapd#4244 opened: disabling opensuse until timeout issue is fixed <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4244>
[16:33] <cachio> mvo, failed again on opensuse, this is the PR https://github.com/snapcore/snapd/pull/4244
[16:33] <mup> PR #4244: disabling opensuse until timeout issue is fixed <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4244>
[16:33] <cachio> I am still trying to reproduce it for here
[16:37] <mvo> cachio: thanks
[16:37] <mvo> cachio: once its green I will merge and push into the other two 2.29 prs
[16:37] <cachio> mvo, good
[16:42] <popey> elopio: great idea!
[16:42] <pedronis> cachio: thanks
[16:42] <popey> elopio: make sure you use the link button to give you a tagged link :)
[16:42] <popey> get them vaulable internet points!
[16:43] <kyrofa> sergiusens, alright, ament plugin is up to date
[16:43] <popey> https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-35/2880?u=elopio <-
[16:52] <elopio> popey: what is a tagged link? Does my user get internet points?
[16:52] <popey> Yes!
[16:53] <popey> see the url above, got your name in it
[16:53] <elopio> oh man, I've been stripping that u everywhere! So much karma lost :(
[16:53] <popey> sad4u
[16:53] <cachio> mvo, https://paste.ubuntu.com/25982089/
[16:53] <cachio> it took 5 minutes to install python3-docutils in opensuse
[16:53] <elopio> https://en.wikipedia.org/wiki/Success_Kid#/media/File:SuccessKid.jpg
[16:54] <cachio> it is in linode
[16:54] <cachio> mvo, it should take few minutes
[16:54] <cachio> mvo, few seconds
[16:54] <cachio> <30s
[16:55] <mvo> cachio: woah
[16:55] <mup> PR snapd#4245 opened: interfaces/screen-inhibit-control: handle ScreenSaver/Screensaver in DBus API <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4245>
[17:00] <cachio> mvo, testing in a vm on aws to compare
[17:03] <mvo> cachio: thanks. 4244 has not even started yet, slightly annyoing
[17:05] <mvo> jdstrand: does 4230 looks good to you now?
[17:06] <cachio> mvo, in aws works pretty fast
[17:06] <cachio> mvo, the problem is in linode
[17:06] <mup> PR snapd#4243 closed: tests: disable classic-ubuntu-core-transition on i386 temporarly <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4243>
[17:11] <cachio> mvo, any idea why I could get this error?
[17:11] <cachio> https://paste.ubuntu.com/25981162/
[17:12] <cachio> mvo, I have a snap running as a service, this is the snapcraft.yaml
[17:12] <cachio> mvo, also getting this denial when I start the service
[17:12] <cachio> https://paste.ubuntu.com/25980351/
[17:15] <mup> PR snapd#4230 closed: tests: add test to run snap inside lxd as a user <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4230>
[17:15] <mup> PR snapd#4246 opened: snap-confine: fix snap-confine under lxd <Created by mvo5> <https://github.com/snapcore/snapd/pull/4246>
[17:15] <mvo> jdstrand: -^
[17:19] <mvo> cachio: new beta is still 1-2h away, tests are slow :(
[17:19] <cachio> np
[17:24] <cachio> mvo, any idea about the problem with the network-status-provider snap?
[17:31] <kyrofa> sergiusens, pip extraction has also been updated
[17:35] <magicaltrout> hello folks
[17:35] <magicaltrout> how do you install a classic snap from a local build?
[17:35] <magicaltrout>  sudo snap install --classic ./my-snap-name_0.1_amd64.snap
[17:35] <magicaltrout> error: cannot find signatures with metadata for snap "./my-snap-name_0.1_amd64.snap"
[17:37] <nacc> magicaltrout: --dangeours
[17:37] <nacc> *dangerous
[17:37] <magicaltrout> winning
[17:37] <nacc> magicaltrout: it basically says there is no store data for it
[17:51] <jdstrand> mvo: yep, done (as per other channel)
[17:51] <mvo> jdstrand: thank you
[17:52] <jdstrand> mvo: is 2.30 already branched?
[17:52] <jdstrand> I guess I can figure that out myself
[17:53] <jdstrand> doesn't look like it
[17:53] <mvo> jdstrand: not branched yet, why?
[17:54] <jdstrand> mvo: just wanted to know if I needed to send up 2.30 branches too
[17:55] <mvo> thanks
[17:58] <cratliff> kyrofa  That's great.  I saw the .36 milestone and thought it would be a while.  Glad to see it's in.  I should try checking out the extended workspaces sometime soon.
[18:07] <sergiusens> kyrofa I have a new branch up too which could use a look
[18:07] <kyrofa> sergiusens, as do I-- the catkin-build-entire-workspace one
[18:07] <mup> PR snapcraft#1744 opened: elf: conversion from libraries <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1744>
[18:07] <sergiusens> kyrofa I saw it ;-)
[18:10]  * kyrofa reads PEP 484
[18:14] <mup> PR snapd#4244 closed: disabling opensuse until timeout issue is fixed <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4244>
[18:24] <kyrofa> Darn, autopkgtest queue has built up a bit again
[18:33] <kyrofa> elopio, pretty sure the bot is not pinging subscribers
[18:34] <kyrofa> I don't think it's ever pinged me
[18:34] <elopio> kyrofa: yup. Pretty sure you broke it ;)
[18:34] <kyrofa> Nu uh! It NEVER pinged me, I swear
[18:34] <elopio> kyrofa: so, I think next week I can add tests, and then it should be obvious what's wrong. No hurries there, right?
[18:34] <kyrofa> elopio, yeah, no rush other than curiosity, haha
[18:35] <kyrofa> elopio, kinda fun to poke at it. It'll be even better with tests
[18:35] <kyrofa> elopio, let me know? Happy to review
[18:37] <kyrofa> Does errbot have some sort of testing lib?
[18:38] <elopio> kyrofa: yes, it has. Should be easy to fake integration tests.
[18:38] <kyrofa> Sweet
[18:45] <kyrofa> man this new firefox is ugly
[18:47] <kyrofa> snappy-m-o, autopkgtest 1583 xenial:i386
[18:47] <snappy-m-o> kyrofa: I've just triggered your test.
[18:48] <kyrofa> snappy-m-o, autopkgtest 1607 xenial:i386
[18:48] <snappy-m-o> kyrofa: I've just triggered your test.
[19:02] <brunosfer> Hi
[19:03] <pdefreitas> hi
[19:04] <brunosfer> hi
[19:04] <pdefreitas> snapamos
[19:10] <brunosfer> hi
[19:12] <brunosfer> hi
[19:15] <brunosfer> hi
[19:15] <pdefreitas> hi
[19:16] <brunosfer> I'm trying to build a snap for offline connectivity. Do you know any good tutorial on how to begin with that?
[19:16] <nacc> brunosfer: "for offline connectivity"?
[19:37] <sergiusens> kyrofa it is not pinging
[19:37] <sergiusens> and never worked in this irc form either
[19:39] <cachio> mvo, news about the beta?
[19:41] <mup> PR snapd#4247 opened: interfaces: allow /bin/chown and fchownat to root:root <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4247>
[19:42] <jamesbenson> chipaca?
[20:00] <sergiusens> kyrofa is my use of mypy your only concern in the PR?
[20:02] <mvo> cachio: unfortunately not, tests still not finished :(
[20:02] <kyrofa> sergiusens, not done looking through it yet
[20:04] <cachio> mvo, np
[20:11] <om26er> jdstrand: thanks for the approval. One question: since I filed that Android Studio request, I made many changes to the packaging and the latest revision(15) is what we want to release. Will that need a separate approval from you ?
[20:12] <om26er> https://dashboard.snapcraft.io/dev/snaps/8605/rev/15/
[20:14] <om26er> oops, it seems that got approved just now.
[20:24] <jdstrand> om26er: no. you are good to go
[20:41] <mup> PR snapcraft#1745 opened: static tests: upgrade to the newest flake8 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1745>
[20:43] <kyrofa> sergiusens, variable annotations are python 3.6 only
[20:50] <sergiusens> kyrofa do they fail for you?
[20:51] <sergiusens> kyrofa snapcraft is 3.6
[20:51] <kyrofa> sergiusens, not in the deb :)
[20:51] <sergiusens> unless you mean 3.5, for which they would be silently ignored
[20:51] <kyrofa> I've not tried, was concerned they'd be syntax errors
[20:51] <sergiusens> kyrofa does it fail? it says 3.5 here -> https://docs.python.org/3/library/typing.html
[20:52] <sergiusens> where did you get 3.6?
[20:52] <kyrofa> sergiusens, comment on the PR. I'm specifically talking about syntax like this: ldd_out: List[str] = []
[20:53] <kyrofa> Annotations on variables, not functions/classes
[20:53] <sergiusens> oh, ic
[20:54] <sergiusens> kyrofa ok, enough with static checking, what about the rest?
[20:54] <zyga-afk> re
[20:54] <zyga> mvo: still here?
[20:54] <mvo> zyga: yes
[20:54] <sergiusens> the comment notation is sad
[20:54] <zyga> mvo: how are things? I saw the PR
[20:54] <mvo> zyga: we have unhappy tests, otherwise all is well
[20:54] <zyga> mvo: unhappy with LXD or random annoying failing test?
[20:55] <mvo> zyga: random
[20:55] <mvo> zyga: opensuse
[20:55] <mvo> zyga: and also random
[20:55] <sergiusens> elopio snapcraft#1745 is for you btw ;-)
[20:55] <mup> PR snapcraft#1745: static tests: upgrade to the newest flake8 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1745>
[20:55] <sergiusens> kyrofa after that I'll propose a general mypy sanity fix and rebase my branch on that
[20:56] <kyrofa> Alright. Noticed mypy isn't in the archives, too bad
[20:56] <zyga> mvo: drat
[20:56] <zyga> mvo: restart-travis-as-a-service
[20:56] <kennyloggins> do I just apt update to get the new snapd ?
[20:57] <zyga> "one does not just apt update to get new snapd" (with the mordor thing meme)
[20:57] <zyga> kennyloggins: it depends
[20:57] <zyga> kennyloggins: sometimes a core-reexec issue is faster than apt update
[20:58] <kennyloggins> IDK - i just went with stable - tell me what to do ?
[20:58] <zyga> kennyloggins: stable is usually fine unless a specific issue is affecting you
[20:58] <kennyloggins> Iam just a user.
[20:59] <sergiusens> kyrofa why would that matter?
[20:59] <sergiusens> we don't depend on the archives for any of the static tests
[20:59] <zyga> kennyloggins: in that case I'd suggest sticking to stable
[21:00] <mup> PR snapd#4248 opened:  snap-confine: fix snap-confine under lxd <Created by mvo5> <https://github.com/snapcore/snapd/pull/4248>
[21:00] <kyrofa> sergiusens, just makes things easier, that's all. Makes our dev guide harder
[21:00] <kennyloggins> okay - I shallnot do anthing then. just saw this post:
[21:00] <kennyloggins> https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-35/2880/5
[21:00] <kyrofa> Not a big deal
[21:04] <zyga> kennyloggins: that's for snapcraft, right?
[21:05] <zyga> kennyloggins: I usually think about snapd, not snapcraft, sorry, my bias
[21:08] <kennyloggins> zyga: coolbeans. No idea wat I am doing ! Weeeeeeeeee
[21:08] <kennyloggins> https://v.gd/4vCGRy
[21:35] <sergiusens> kyrofa but it doesn't change, it still is `pip install -r requirements-devel.txt`
[21:40] <mup> PR snapd#4241 closed: store: bit less aggressive retry strategy <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4241>
[21:54] <mup> PR snapd#4248 closed:  snap-confine: fix snap-confine under lxd (2.29) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4248>
[22:05] <zyga> mvo: what happened with that merge btw? why did you have to open a new PR?
[22:07] <mvo> zyga: yes, messup
[22:07] <kyrofa> Haha, sergiusens you need to start using a github mobile app or something
[22:07] <kyrofa> The emails are never threaded
[22:08] <mvo> zyga: when I merge the opensuse fix something strange happend
[22:08] <sergiusens> kyrofa oh, but why, I am using mailspring ;-)
[22:08] <mvo> zyga: 2.29.4 is building in the ppa now finnaly
[22:08] <mvo> finally
[22:08] <sergiusens> threads are a thing of the past :-P
[22:08] <kyrofa> Hahaha
[22:08] <zyga> mvo: thank you :-)
[22:09] <zyga> mvo: so, tomorrow morning my lxd container should work ok
[22:09] <zyga> mvo: (well, until I fix the other bug it will be affected by reomve)
[22:10] <zyga> mvo: but that should give us a chance to releas next week
[22:19] <kyrofa> What the heck... sergiusens all of a sudden libpython2.7-minimal is including a sitecustomize in /etc/python2.7/
[22:19] <sergiusens> kyrofa darn, I got distracted with your comment :-P focused the window to say ... er just that
[22:20] <kyrofa> I didn't know that was a valid location!
[22:21] <mvo> zyga: yeah, I hate to leave this broken over the WE, it needs to be at least in beta imo
[22:21] <sergiusens> kyrofa but, there has been no updates to python in a while on 16.04 https://launchpad.net/ubuntu/+source/python2.7
[22:22] <sergiusens> kyrofa did you shuffle code around?
[22:22] <kyrofa> It was one of the PRs I rebased
[22:23] <kyrofa> Not sure why they're clashing anyway... I suspect I broke something
[22:24] <kyrofa> Oh. No, that's where we're placing ours now. What...
[22:24] <kyrofa> Eh, I'll figure it out
[22:25] <kyrofa> Oh it's a symlink. How interesting
[22:30] <zyga> mvo: if you manage to let's also write something on the forum
[22:30] <zyga> mvo: (I can do that if you'd like)
[22:31] <gsilvapt> Hello all. I want to follow elopio suggestion on the forum to test the latest snapcraft version
[22:31] <gsilvapt> I can do it by cloning the repo and using the snapcraft's binaries to perform stuff, right?
[22:31] <zyga> gsilvapt: did his post include instructions?
[22:32] <zyga> gsilvapt: sorry for a naive question, I didn't read it
[22:32] <gsilvapt> https://forum.snapcraft.io/t/call-for-testing-snapcraft-2-35/2880
[22:32] <gsilvapt> zyga, kind of. I bet my question is fairly simple but the problem is I already have snapcraft installed
[22:32] <gsilvapt> But I know there is a way to have 2 installations working
[22:33] <kyrofa> gsilvapt, you can just test the snap if you like
[22:33] <kyrofa> But yes, you can also run it from source
[22:33] <zyga> gsilvapt: I'm sure that's true, I'm sorry I canont help you more
[22:34] <gsilvapt> kyrofa, under the snapcraft folder, right?
[22:34] <gsilvapt> I need to get used to these things if I want to contribute to snapcraft :P
[22:34] <gsilvapt> no worries, zyga :D
[22:34] <kyrofa> gsilvapt, here you go: https://github.com/snapcore/snapcraft/blob/master/HACKING.md
[22:34] <kyrofa> gsilvapt, I suggest doing it that way
[22:35] <gsilvapt> ok, I have that installed. I need to checkout to branch 2.5 and perform the steps there, right?
[22:35] <gsilvapt> s/2.5/2.35
[22:36] <gsilvapt> ok, nevermind, I'm using the version I need :-=)
[22:36] <gsilvapt> ok, nevermind, I'm using the version I need :-)
[22:37] <mvo> jdstrand, zyga store upload of 2.29.4 core fails because of the review scripts apparently, the error is "found errors in file output: unusual mode 'rws...
[22:38] <zyga> ah
[22:38] <zyga> drat
[22:38] <zyga> mvo: store checks for setgid
[22:38] <zyga> mvo: we need a fix from jdstrand and roadmr
[22:38] <roadmr> zyga: hi! which version of the review tools do you need for this?
[22:39] <zyga> roadmr: the one unwritten :)
[22:39] <roadmr> zyga: I have 2 in the queue right now, aiming for a Monday rollout
[22:39] <roadmr> zyga: dagnabbit :D
[22:39] <zyga> roadmr: in reality we need one off approval
[22:39] <mvo> roadmr, jdstrand, zyga here is an example https://launchpad.net/~snappy-dev/+snap/core/+build/108281
[22:39] <zyga> roadmr: we can fix this properly next week
[22:39] <zyga> but it would be good if that upload was approved
[22:39] <gsilvapt> kyrofa, are you available in 30 minutes? I would like to implement the `snapcraft version` command requested that we discussed in the other night. I haven't tried any further but I think tonight is the night :)
[22:42] <roadmr> zyga: so do you indeed want that weird mode?
[22:42] <roadmr> mvo: ^^
[22:43] <roadmr> zyga: I'm not really sure what to do :( because the status on the store is "failed review", not "awaiting manual review". The latter, I could possibly review and approve; but the former, and it being core, and it being Friday evenight, sounds like a recipe for getting yelled at :(
[22:43] <mvo> roadmr: yes, its a long story
[22:43] <mvo> roadmr: right, yes, I think your concerns are sensible
[22:45] <mvo> roadmr: the backstory is https://forum.snapcraft.io/t/snapcraft-adt-failures-with-the-new-core-release/2850/40 and we are quite eager to fix this regression but if its complicated/dangerous its not the best time on friday :(
[22:45] <roadmr> mvo: I think it is, for reasons explained above :( I might chance it if I had more experience with reviews, but in truth, jdstrand handles those hairy bits so I'd be doing it for the first time.
[22:46] <mup> PR snapd#4246 closed: snap-confine: fix snap-confine under lxd <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4246>
[22:47] <kyrofa> gsilvapt, yes, I'll be here :)
[22:48] <kyrofa> Happy to help
[22:48] <zyga> mvo: it's kind of depressing we dind't realize this yesteray
[22:49] <mvo> zyga: yes, slightly depressing
[22:51] <zyga> roadmr: can we make the modification to the store to allow that different mode?
[22:52] <roadmr> zyga: it's click-reviewer-tools rejecting the mode
[22:52] <roadmr> it just spits out an error in the review results, and that's what causes the store to consider the upload rejected
[22:54] <mvo> zyga: please send me a tg if this lands in the store, then I will promote to beta tomorrow morning, otherwise it will be monday (slightly sad)
[22:55] <zyga> ok
[22:55] <zyga> roadmr: who maintains c-r-t?
[22:55] <roadmr> zyga: jdstrand does
[22:55] <zyga> jdstrand: can you make that modification?
[23:03] <zyga> ok, I modified c-r-t
[23:03] <zyga> roadmr: would you deploy my change or is that too outside of protocol?
[23:04] <roadmr> zyga: I can't even deploy it myself, we'd need complicity from a webop
[23:05] <zyga> the non-test diff is: http://paste.ubuntu.com/25984118/
[23:06] <roadmr> one-character diff :)
[23:07] <zyga> hmm, setup.py test on clean master seems to fail
[23:07] <zyga> FAILED (failures=4)
[23:07] <roadmr> :(
[23:08] <gsilvapt> kyrofa,I'm just not getting how the method to get the version is called using --version
[23:08] <gsilvapt> If you could help understand that bit, perhaps I could work on a solution to have it printing snapcraft's version using version and --version
[23:09] <kyrofa> gsilvapt, sure, let me look, here
[23:10] <gsilvapt> When I look at the internals/__init__.py, I understand the method that gets the version number is the _get_version and that method can be reused. I'm just not understanding where is that method called
[23:10] <zyga> ok, I give up
[23:10] <kyrofa> gsilvapt, we use a library called "click" for our CLI handling
[23:10] <zyga> jdstrand: if you make that modificaiton please leave me or mvo a message
[23:10]  * zyga waves good night
[23:11] <kyrofa> gsilvapt, one of its features is that it has a `version_option` decorator accepts a version number, and adds a --version option
[23:11] <gsilvapt> Hum, I remember seeing some bits of code with that somewhere
[23:11] <kyrofa> gsilvapt, this is done in snapcraft/cli/__init__.py
[23:13] <kyrofa> gsilvapt, so I suggest you continue using the snapcraft.__version__ attribute
[23:13] <kyrofa> gsilvapt, but you'll need to add a new command
[23:13] <gsilvapt> Ah, I see it. I once stepped into this when I was trying to find what was going on
[23:14] <gsilvapt> Hum. So there is no chance of re-using the click library? I haven't look at the code but lets see if I can figure this out with these instructions
[23:14] <kyrofa> gsilvapt, I suggest doing that in a new file, snapcraft/cli/version.py
[23:14] <kyrofa> Oh yes, you'll use the lib, but I had a quick look and it doesn't look like it supports magically adding a "version" command like it did for the --version option
[23:14] <mup> PR snapcraft#1745 closed: static tests: upgrade to the newest flake8 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1745>
[23:14] <kyrofa> But that's okay, adding a command is still pretty easy
[23:15] <kyrofa> gsilvapt, I suggest you refer to snapcraft/cli/help.py
[23:15] <kyrofa> Yours should look pretty similar
[23:15] <kyrofa> But even simpler
[23:16] <gsilvapt> Just to check: This line is the one that actually adds the --version option, right? `@click.version_option(version=snapcraft.__version__)`
[23:19] <gsilvapt> kyrofa, would it make sense to have both commands in the same file?
[23:20] <kyrofa> gsilvapt, indeed, that line
[23:20] <kyrofa> gsilvapt, that wouldn't follow the convention established for other commands
[23:21] <kyrofa> gsilvapt, sticking to established conventions is one way we're all able to share a codebase
[23:21] <kyrofa> gsilvapt, so no, I suggest putting it in snapcraft/cli/version.py
[23:22] <gsilvapt> kyrofa, that's not my suggestion, I did not use the most correct words. Shouldn't --version and version commands be established in the same file? i.e, should I move the --version option to this new file so that they stay together?
[23:23] <kyrofa> gsilvapt, ah, I see
[23:23] <kyrofa> gsilvapt, as far as I can see, that's not actually possible, as the --version option must be specified on the root command, `snapcraft`, which is defined right there in __init__.py
[23:24] <gsilvapt> Hum, ok I see
[23:24] <gsilvapt> So, lets get some implementations done and hopefully running
[23:25] <kyrofa> Just look closely at how help is done
[23:29] <kyrofa> snappy-m-o, autopkgtest 1743 xenial:arm64
[23:29] <snappy-m-o> kyrofa: I've just triggered your test.
[23:30] <kyrofa> snappy-m-o, autopkgtest 1743 artful:amd64
[23:30] <snappy-m-o> kyrofa: I've just triggered your test.
[23:30] <gsilvapt> I think I may have found a working solution but I think I have a poor configuration of lxc
[23:31] <gsilvapt> tried running ./runtests.sh snapcraft/tests/unit/commands and got this in the first lines: https://pastebin.com/GSvYFCt1
[23:33] <gsilvapt> Well, I keep getting those after a few tests
[23:33] <kyrofa> Hmm.... not seen that before
[23:34] <gsilvapt> unittest generates a full report when it's done, am I correct? It's hard to keep looking at all these tests
[23:36] <kyrofa> gsilvapt, it'll die if it errors
[23:36] <kyrofa> Although I suspect it won't if all you did was add a new command. Did you write tests for it as well?
[23:37] <gsilvapt> yes, it said it failed anyway. And my test failed :-D
[23:37] <gsilvapt> Too bad I can't use Pycharm's test feature to just test the one I wrote
[23:37] <gsilvapt> yes, I did a similar test to the existing one using version
[23:37] <kyrofa> You can always try `python3 -m unittest snapcraft.tests.unit.commands.test_version (or whatever you called it)
[23:38] <gsilvapt> hum, right
[23:38] <gsilvapt> but is there an actual reason why PyCharm can't compile snapcraft?
[23:38] <gsilvapt> I have I feeling I have lots of tools poorly configured :|
[23:39] <kyrofa> gsilvapt, I'm afraid I don't know-- I don't use pycharm
[23:42] <gsilvapt> kyrofa, vim user?
[23:42] <kyrofa> A mixture of vim and atom
[23:42] <kyrofa> When atom decides not to crash X
[23:44] <gsilvapt> I used to use Vim but recently started using IntelliJ for Java and just fell in love with its features.  I still use Vim modal editing style. I can't go back to not use it
[23:44] <gsilvapt> By the way, I think I have some dependencies missing, even after installing requirements and requirements-devel
[23:47] <gsilvapt> kyrofa, elopio, in case you have seen anything like this before: https://pastebin.com/BDZFzmrQ
[23:47] <gsilvapt> I'm considering removing and reinstalling lxc/lxd
[23:53] <elopio> gsilvapt: weird. I have seen weird lxd errors in the past, but now It's pretty much stable for me.
[23:53] <elopio> I'm on xenial, using the lxd snap. If the snap doesn't work for you, you can try the deb.
[23:54] <gsilvapt> So, purge lxd/lxc, reinstall and try again
[23:54] <gsilvapt> ok, glad I chose a free night for this, ehehe
[23:54] <gsilvapt> But that basically means it is failing to start containers somehow
[23:55] <elopio> gsilvapt: if you installed with the deb, you need to purge lxd and lxd-client
[23:56] <gsilvapt> I think the system is lxd clean
[23:58] <gsilvapt> elopio, do I need a particular version of Ubuntu in the container?
[23:58] <gsilvapt> I previously had 17.10
[23:59] <gsilvapt> Since you're here and the expert using lxd, should I remove the containers after using them?