[06:27] <zyga> good morning
[06:32] <zyga> hey pedronis :)
[06:59] <pedronis> hi
[07:02] <mvo> hey pedronis
[07:07] <pstolowski> mornings
[07:09] <mvo> hey pstolowski
[07:13] <mup> PR snapd#7329 opened: snap: explicitly forbid trying to parallel install from seed <Created by pedronis> <https://github.com/snapcore/snapd/pull/7329>
[07:14] <pedronis> mvo: ^ pstolowski: ^
[07:14] <pedronis> pstolowski: hi
[07:14] <mvo> pedronis: ta
[07:15] <pstolowski> ok
[07:19] <zyga> mvo: what about https://github.com/snapcore/snapd/pull/7321
[07:19] <mup> PR #7321: tests: restore dpkg selections after upgrade-from-2.15 test <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7321>
[07:19] <zyga> I'm not sure how many reviews we need now
[07:20] <mup> PR snapd#7328 closed: tests: pass --remove to userdel on core <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7328>
[07:25] <mvo> zyga: its fine from my POV, its not perfect
[07:25] <zyga> mvo: yeah, I'd like to land it
[07:25] <mvo> I mean, you pointed out that the tool has flaws
[07:25] <mvo> but its fine IMO
[07:25] <zyga> mvo: yeah
[07:25] <zyga> mvo: do we need zero, one or two reviews on top of this state?
[07:28] <mvo> zyga: so far this has zero reviews… :( let me review it
[07:28] <mvo> zyga: having one review from !us would be nice I think
[07:29] <zyga> yeah, I feel the same way
[07:29] <zyga> it's unclear what the rules say when two people work on something and agree
[07:29] <mvo> zyga: lets not fuss too much, its a tiny PR and affects only tests. I'm sure if e.g. pstolowski can have a quick look it can land :)
[07:30] <zyga> +1
[07:32] <pstolowski> seems i missed my 2 minute window to review this ;)
[07:38] <pstolowski> ah, it wasa about 7321, looking at it
[07:44] <zyga> brb
[07:46] <pstolowski> one comment there, +1
[07:51] <zyga> re
[07:51] <zyga> pstolowski: replied
[07:52] <pedronis> mvo: I archive 2.40 and created the 2.42 lane, I also made cards for the UC20 things I'm working on
[07:54] <mup> PR snapd#7321 closed: tests: restore dpkg selections after upgrade-from-2.15 test <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7321>
[07:58] <mvo> pedronis: excellent, thank you
[08:38] <Chipaca> ullo ullo
[08:39] <Chipaca> i just popped in to make sure y'all were aware today's a bank holiday so that's why i'm not here
[08:39] <pstolowski> pedronis, zyga: when we optimize apparmor backend to load multiple profiles in one go we're going to loose the granularity of error handling we have now for the apparmor_parser invocation. at the moment regenerateAllSecurityProfiles just logs an error for a given snap and carries on with the rest (we can still have such per-snap policy for intermediate errors before aa parser is invoked). any toughts on that?
[08:39] <pstolowski> hey Chipaca
[08:42] <pstolowski> pedronis, zyga unless we run apparmor parser with --vebose flag and go into business of parsing it's output ('Replacement succeeded for "snap....' gets printed for every successfull profile)
[08:51] <abeato> mvo, morning! would it be possible to merge https://github.com/snapcore/snapd/pull/7252 now? Also, what about https://github.com/snapcore/snapd/pull/7173 ? Is retriggering the tests needed there?
[08:51] <mup> PR #7252: interfaces/network-manager: allow using org.freedesktop.DBus.ObjectManager <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/7252>
[08:51] <mup> PR #7173: interfaces: support Tegra display drivers <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/7173>
[08:52] <mvo> abeato: in a meeting, will check in ~1h when they are over
[08:52] <abeato> mvo, ack, thanks
[08:55] <zyga> pstolowski: interesting
[08:55] <zyga> pstolowski: on failure, we can re-run per profile and see what really failed
[08:58] <pstolowski> zyga: yeah but we need to find out which one failed (for which snap), just log this snap and don't consider entire operation as failed
[09:02] <zyga> pstolowski: yeah but when the batch fails you can re-try non-batch to reliably get information about those that really failed
[09:02] <zyga> pstolowski: alternatively
[09:02] <zyga> pstolowski: we can batch only inside one snap
[09:03] <zyga> pstolowski: that's less generic but better in terms of our understanding what to do
[09:03] <zyga> pstolowski: because when things fail, we need to change at the snap-granularity anyway
[09:04] <pstolowski> zyga: we already pass all profiles of given snap to aa parser (if that's what you mean). but re-trying one-by-one is an interesting idea
[09:05] <zyga> pstolowski: if it's already per-snap then retrying is not of much use
[09:05] <zyga> pstolowski: because it partially failed anyway
[09:05] <zyga> pstolowski: another idea: do it in stages: first compile then load
[09:05] <zyga> pstolowski: if compilation failed nothing in the system is broken
[09:05] <zyga> pstolowski: it's easier to reason about the state
[09:06] <zyga> pstolowski: you can pass a flag to the parser to let it just compile all profiles
[09:06] <zyga> pstolowski: then you can pass a different flag to ask it to just load binary profiles
[09:08] <pstolowski>  -d, --debug
[09:08] <pstolowski>            Given once, only checks the profiles to ensure syntactic correctness.
[09:08] <pstolowski> zyga: ^ yeah, interesting
[09:11] <zyga> pstolowski: rather than debug I'd try something like --skip-kernel-load
[09:11] <pstolowski> zyga: aha! thanks
[09:11] <zyga> pstolowski: you can use other options to capture the compiled profile into memory
[09:11] <zyga> pstolowski: or to disk
[09:26] <niemeyer> Morning all
[09:30] <mvo> hey niemeyer ! welcome back
[09:30] <niemeyer> Thanks! Glad to be back
[09:30] <niemeyer> How're things going?
[09:38] <mup> PR snapd#7252 closed: interfaces/network-manager: allow using org.freedesktop.DBus.ObjectManager <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7252>
[09:40] <mvo> niemeyer: going well, thank you!
[09:40] <niemeyer> I see mup is still going strong
[09:41] <mvo> niemeyer: some annoying test hickups that we are fighting but its getting better
[09:41] <mvo> niemeyer: yeah, mup was doing great last week iirc
[09:41] <mvo> mup: hey, still fine?
[09:41] <mup> mvo: I apologize, but I'm pretty strict about only responding to known commands.
[09:41]  * mvo hugs mup
[09:42] <niemeyer> Nice
[10:33] <zyga> mvo: found the bug :)
[10:33] <zyga> mvo: whee
[10:33] <zyga> core is good
[10:33] <mvo> zyga: tell me more!
[10:33] <zyga> mvo: the logic in reset_all_snap was silly wrong
[10:34] <zyga> I'll send a PR in a moment
[10:34] <mvo> zyga: ta
[10:45] <zyga> mvo: two bugs actually
[10:45] <zyga> in other news, shell is tricky
[10:52] <ogra> pfft
[11:14] <zyga> fired one more run to be sure, brb
[11:14] <zyga> mvo: tl;dr; grep -w is a deception
[11:14] <zyga> mvo: - is a word separator
[11:14] <zyga> mvo: dont-remove-this-snap-core18 matches against grep -w core18
[11:25] <mvo> zyga: woah, nice find
[11:32] <zyga> mvo: https://github.com/snapcore/snapd/pull/7330
[11:32] <mup> PR #7330: tests: fix removal of snaps on ubuntu-core <Created by zyga> <https://github.com/snapcore/snapd/pull/7330>
[11:32] <mup> PR snapd#7330 opened: tests: fix removal of snaps on ubuntu-core <Created by zyga> <https://github.com/snapcore/snapd/pull/7330>
[11:38] <mup> PR snapd#7331 opened: tests: move interfaces-contacts-service to /tmp <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7331>
[11:40] <zyga> ohh, a new PR label
[11:40] <mup> PR snapd#7332 opened: tests: remove trailing spaces from shell scripts <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7332>
[11:41] <abeato> mvo, it looks like tests for https://github.com/snapcore/snapd/pull/7173 finally passed :)
[11:41] <mup> PR #7173: interfaces: support Tegra display drivers <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/7173>
[11:41] <zyga> I need to do some reviews while tests are churning
[11:49] <mup> PR snapd#7333 opened: tests: fix system version check on listing test for external backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7333>
[11:51] <zyga> wow, only one test not passing cleanly in main on core16!
[11:51] <zyga> and a simple one at that
[12:15] <zyga> unit test failure?
[12:15] <zyga> https://www.irccloud.com/pastebin/AQb5iDB8/
[12:15] <zyga> and another one on snap_daemon user
[12:15] <zyga> https://www.irccloud.com/pastebin/5rYhzSZG/
[12:15] <zyga> mvo: is that still expected?^
[12:15] <zyga> or should I get more recent master
[12:32] <mup> PR snapd#7334 opened: tests: remove locally installed revisions of core <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/7334>
[12:38] <mvo> zyga: the daemon-user in tumbleweed?
[12:38] <zyga> mvo: that is 16.04
[12:38] <zyga> mvo: not TW
[12:38] <zyga> mvo: group removal failed because there's a user using it as primary group
[12:39] <mvo> zyga: let me check
[12:39] <zyga> mvo: offtopic: core18 does not leak any more mount points as far as my tests are showing
[12:39] <zyga> mvo: I'm running a more complete pass but this is fantastic, it's not buggy anymore :
[12:40] <zyga> mvo: this means both core and classic are clean, only two PRs to review to get there
[12:42] <mvo> zyga: cool
[12:42] <mvo> zyga: where is the userdel failure?
[12:43] <mvo> zyga: I mean, what PR failed ? I want to check the log
[12:43] <zyga> mvo: I restarted it already
[12:43] <zyga> mvo: sorry, :/
[12:43] <jamesh> and then the test suite will be 100% robust? :-)
[12:45] <zyga> jamesh: no :)
[12:45] <zyga> jamesh: but that aspect will
[12:45] <zyga> jamesh: so my test that measures it can be enabled again
[12:46] <zyga> jamesh: without acting like a mount leak detector
[12:47] <jamesh> zyga: fyi, I'm in Greece for GUADEC until Thursday (and then flying home until Friday evening).  So I may be slow to respond to activity on my PRs
[12:48] <zyga> jamesh: enjoy Guadec, I'd love to visit Greece for one :)
[12:48] <zyga> I'm doing a pass over older PRs, including many that you sent, sorry for the enormous lag
[12:49] <jamesh> zyga: no problem.  At some point I'd like to go over the work I need to complete for 20.04
[12:50] <jamesh> dbus activation is still the big one (which hopefully is getting close to unblocked)
[12:50] <jamesh> there will probably be some xdg-desktop-portal related changes too though
[12:50] <zyga> jamesh: any interesting portal work that would be of interest for us to integrate with?
[12:50]  * zyga has some back pain today, should move to laptop
[12:51] <jamesh> zyga: mostly things that were brainstormed almost a year ago
[12:51] <zyga> jamesh: as in, they are coming now?
[12:51] <zyga> after a year of being under development?
[12:52] <jamesh> I want to give xdg-desktop-portal more information about snaps, which will probably involve adding a hidden "snap" command that takes a pid for a confined app and spits out some machine readable data about the snap
[12:52] <jamesh> a year of having other priorities
[12:52] <zyga> jamesh: oh neat
[12:52] <zyga> jamesh: would it be like snap info --pid=123
[12:52] <zyga> that then matches that pid to a snap and gives you that kind of information
[12:52] <zyga> jamesh: my question is mainly: do you need more than what snap info would say
[12:53] <jamesh> in particular, I want snap name, desktop file ID, possibly presence of network plug
[12:53] <jamesh> maybe some information about readable/writable paths
[12:53] <zyga> mmm
[12:53] <zyga> jamesh: what kind of writable paths do you mean? precise rules or something high-level?
[12:54] <jamesh> zyga: the main use would be to identify cases where files do not need to be proxied through xdg-document-portal
[12:54] <zyga> oh, I see
[12:54] <jamesh> so it's alright if it isn't complete
[12:54] <zyga> jamesh: would it be ok if it was just a query per path?
[12:55] <zyga> jamesh: snap internal is-accessible --pid=123 /path/to/file
[12:55] <jamesh> zyga: perhaps.  I need to get up to speed with that code base again
[12:55] <zyga> ok
[12:55] <zyga> thanks for sharing, this is interesting
[12:56] <jdstrand> pstolowski: ime you don't want to run apparmor_parser so much on all profiles as much as run it only once at the end
[12:57] <jamesh> zyga: also: what is the best cross platform way to detect if a pid is a snap app?
[12:57] <jamesh> zyga: the current code is checking AppArmor labels, but that obviously doesn't work for the non AA distros
[12:57] <jdstrand> pstolowski: ie, snap.foo.bar has 3 interfaces. apparmor_parser it once after all 3 interfaces are connected instead of each time after one is connectedc
[12:57] <jamesh> the aim is to have something quick to check before shelling out to the "snap internal" command we eventually write
[12:58] <jdstrand> jamesh: the freezer cgroup atm
[12:58] <zyga> jamesh: that's a good question
[12:58] <zyga> jamesh: I'd like that to be an API of snapd, not something that is determined externally
[12:58] <zyga> jamesh: because e.g. the freezer or apparmor are internal implementation detail
[12:58] <zyga> jamesh: and that will change
[12:58] <zyga> jamesh: unless we can come up with a robust way to make that without making any problems
[12:58] <jamesh> zyga: the flatpak method is to check for a special file in the root directory of the process's mount namespace
[12:58] <zyga> jamesh: perhaps /proc/PID/root/meta/snap.yaml presence?
[12:59] <zyga> jamesh: that would be reliable today (except for classic snaps)
[12:59] <jdstrand> and yes, we should have an api
[12:59] <zyga> jdstrand: ^ I might even be happy with that being a stable way to check
[12:59] <zyga> regardless of an API
[12:59] <jamesh> zyga: treating classic snaps as unconfined is fine for the purposes of xdg-desktop-portal
[12:59] <jamesh> they effectively are anyway
[12:59] <pstolowski> jdstrand: right. this is kind of already done for auto-connect on install (landed recently, edge only atm)
[13:00] <jdstrand> pstolowski: the same goes for snap-seccomp
[13:00]  * zyga goes to a meeting
[13:00] <jdstrand> pstolowski: oh! 'kind of'?
[13:00] <pstolowski> jdstrand: the case i'm trying to cover now is where we regenerate all profiles on startup when system key or templates changed
[13:00] <pstolowski> jdstrand: 'kind of' in a sense that it's only for auto-connect, not connect in general
[13:01] <jdstrand> pstolowski: but that includes auto-connect via snap decl too, right?
[13:01] <jdstrand> (it would be weird if it didn't, but thought I'd ask)
[13:02] <jdstrand> pstolowski: what about app snap refresh?
[13:02] <pstolowski> jdstrand: yes, precisely that - when you install a snap, and slots get automatically connected
[13:02] <jdstrand> pstolowski: is refresh a special case for install?
[13:03] <pstolowski> otp
[13:03] <jdstrand> pstolowski: feel free to ping me after
[13:07] <mup> PR snapd#7331 closed: tests: move interfaces-contacts-service to /tmp <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7331>
[13:11] <pstolowski> jdstrand: yes, refresh as well, it's special case for install indeed
[13:15] <pstolowski> jdstrand: but there is atm no improvement if you manually snap connect multiple plugs/slots in one go. this could benefit from similiar optimization (as you suggested; and similiar to auto-connect), the framework for that is already in place and we can tackle it at some point
[13:16] <jdstrand> pstolowski: oh, I didn't know you could do more than one in one go :) indeed, that could be done. I think the key is once per command, not per snap or per batch of snaps and then you get reasonable optimizing with good error reporting
[13:17] <jdstrand> pstolowski: doing more than one profile at a time only saves you a fork/exec/tiny overhead which is probably not worth losing the error handling
[13:17] <jdstrand> at least note atm
[13:17] <jdstrand> not*
[13:17] <jdstrand> pstolowski: and this was done for snap-seccomp too?
[13:19] <pstolowski> jdstrand: yes, this was done on higher level than specific backends, we basically run setup-profiles just once at the right moment
[13:19] <jdstrand> pstolowski: woo nice! :)
[13:21] <pstolowski> jdstrand: hmm re apparmor parser, my tests on pi3 suggest we will benefit a lot (3x faster) by running aa parser once over multiple snaps' profiles, did i miss something? see https://forum.snapcraft.io/t/apparmor-parser-performance-on-pi3/12909
[13:22] <pstolowski> (re error handling i'm sure we can overcome this, per zyga's suggestions)
[13:23] <jdstrand> pstolowski: so apparmor can do some parallelizing and things for sure... but it seems your --cache-loc is wrong
[13:24] <jdstrand> pstolowski: it should be /var/cache/apparmor, not /etc/apparmor.d/cache
[13:24] <jdstrand> the cache's should be invalidated
[13:24] <jdstrand> (though)
[13:24] <jamesh> jdstrand: I'll be talking to the freedesktop-sdk folk tomorrow.  Is there anything newer than what you wrote at https://forum.snapcraft.io/t/base-runtime-freedesktop-sdk-runtime-19-08/11153/40?u=jamesh that I should be aware of?
[13:25] <jdstrand> jamesh: unfortunately not. since the work is unplanned, it is falling behind some other stuff that is planned
[13:25] <jamesh> fair enough
[13:26] <jdstrand> jamesh: but, there is a clear path forward
[13:26] <jdstrand> it's 'just work'
[13:26] <jamesh> getting to that point is half the battle :-)
[13:26] <jdstrand> (in terms of implementaion. there are a few process details to sort out, but that isn't a big deal)
[13:26] <jdstrand> jamesh: ha, yes :)
[13:27] <zyga> mvo: FYI https://github.com/snapcore/snapd/pull/7316#pullrequestreview-279586840
[13:27] <mup> PR #7316: tests: add unit tests for cmd_whoami <Created by ardaguclu> <https://github.com/snapcore/snapd/pull/7316>
[13:28]  * zyga goes to rest to avoid the back pain
[13:28] <mvo> zyga: thanks, looking
[13:31] <mvo> zyga: nice, thank you!
[13:32] <jdstrand> pstolowski: your use of snap.* is not accounting for snap-update-ns.*, no? did you find those aren't getting regenerated with ifacemgr?
[13:32] <mup> PR snapd#7173 closed: interfaces: support Tegra display drivers <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7173>
[13:33] <pstolowski> jdstrand: indeed, looks like i used the wrong cache path. anyway, that shouldn't matter for the test due to --skip-read-cache, as i was testing the pessimistic scenario only
[13:34] <pstolowski> jdstrand: and you're right i haven't tested snap-update-ns* profile (it is covered by snapd code, so code is fine)
[13:35] <jdstrand> I think what is happening here is with the single call you are benefiting from parallel processing
[13:35] <jdstrand> whereas otherwise it is completely serial
[13:36] <jdstrand> gimme a second and I can confirm that
[13:36] <mup> PR snapd#7330 closed: tests: fix removal of snaps on ubuntu-core <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7330>
[13:37] <jdstrand> right, a pi3 has 4 cpus that can be used
[13:37] <jdstrand> and so apparmor will used -j4
[13:39] <jdstrand> right, if I use --max-jobs=1 then I get roughly the same performance as serial
[13:39] <mup> PR snapcraft#2684 closed: meta: decouple DesktopFile logic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2684>
[13:39] <jdstrand> 33s vs 35s on amd64
[13:43] <pstolowski> jdstrand: ah, that means it would help on faster machines (originally the problem was reported with fast pc & lots of snaps https://forum.snapcraft.io/t/snapd-causing-lengthy-boot-time/10466), but not on low-end ones that some customers have...
[13:44] <jdstrand> pstolowski: I commented: https://forum.snapcraft.io/t/apparmor-parser-performance-on-pi3/12909/2
[13:45] <jdstrand> ps
[13:45] <pstolowski> jdstrand: thank you, that's useful feedback
[13:46] <jdstrand> pstolowski: let me dig up one more tidbit. I recall we had perf bugs in Ubuntu when we took all the CPUs and choked boot
[13:46] <zyga> mvo: another failure, daemon user present, test failed to add it
[13:47] <ogra> on actual single core HW you will also see I/O saturation that you wont if you use a multicore device and just limit cores
[13:47] <jdstrand> pstolowski: also, you may find this handy: getconf _NPROCESSORS_ONLN
[13:49] <ijohnson> jdstradn, pstolowski: fwiw the big problem I remember from a customer device about this is that it takes _ages_ on a low-end ARM CPU to finish the first boot because there's a lot of snaps and a lot of service/commands with a lot of plugs
[13:49] <mvo> zyga: yeah, I pushed a pr to get to the bottom of this
[13:49] <ijohnson> jdstrand: sorry ^
[13:49] <mvo> zyga: its very strange
[13:49] <jdstrand> pstolowski: right, I remember now. we could make the parser even faster by using a -j value higher than _NPROCESSORS_ONLN, and that was the problem. In Ubuntu, we use _NPROCESSORS_ONLN. *maybe* you want to use _NPROCESSORS_ONLN-1? (you'd want to measure, etc)
[13:50] <ijohnson> note that device only has one CPU core
[13:50] <jdstrand> ijohnson: that is already going to be helped tremendously by what pstolowski already did. run the parser once per command rather than once per interface per command
[13:50] <pstolowski> jdstrand: interesting. we may try to be conservative and paranoid there to start with
[13:51] <ijohnson> right okay, I missed part of this conversation so I wasn't sure what was being discussed right now :-) I'm sure they will be happy to hear that
[13:51] <jdstrand> btw
[13:51]  * jdstrand hugs pstolowski :)
[13:52] <jdstrand> pstolowski: ok cool. I forgot that the rpi3 had so many cores. parallelizing defintely helps with more cores :)
[13:54] <ogra> we should really measure on actual HW that was designed as single core though ... faking it like that will make you miss a lot of aspects
[13:55] <abeato> ijohnson, yes, I am happy to hear that :D
[13:55] <ogra> (though if the focus is really only on CPU processing thats probably okay ... but for overall performance mesuaring IO should also come into play)
[13:55] <pstolowski> jdstrand: thanks for looking at this!
[13:57] <jdstrand> ogra: well, note, on a single core it defaults to -j1. apparmor will use -jNUMBER OF CORES by default. My question is do we want to make that 'minus 1' or something
[13:57] <jdstrand> no one is suggesting a -j higher than the number of cores (I advocated agaisnt it :)
[13:57] <ogra> what would minus 1 achieve ? dynamic picking ?
[13:57] <jdstrand> no no
[13:58] <ogra> oh, you mean "one less"
[13:58] <jdstrand> I'm saying 1 core, -j1. 2 cores, -j1, 3 cores, -j2, etc
[13:58] <ogra> yeah
[13:58] <jdstrand> yes
[13:58] <ogra> got it, sorry, slow today
[13:58] <jdstrand> ie, leave at least one for other stuff
[13:59] <jdstrand> which is probably quite reasonable for a refresh core scenario
[13:59] <ogra> if we can we should surely do that since we might have something running in parallel (we have no real control about systemd here  i guess)
[13:59] <jdstrand> but I'll let others decide
[14:00] <abeato> jdstrand, or maybe change the nice value for the process, as another option?
[14:00] <jdstrand> oh, we can do that. calculate the cores (see aforementioned getconf command), add --max-jobs
[14:00] <jdstrand> abeato: that is an available option as well
[14:08]  * zyga has lots of back pain and stops to do any reviews too
[14:08] <zyga> sorry folks, need to break and get better somehow
[14:12]  * ijohnson relocates, back in ~15 min
[14:12] <pedronis> mvo: I got this:  https://api.travis-ci.org/v3/job/576683798/log.txt  do I need to merge master again?
[14:13] <mup> PR snapd#7334 closed: tests: remove locally installed revisions of core <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7334>
[14:14] <mvo> pedronis: no, this is still under investigation :(
[14:14] <mvo> pedronis: its strange, let me add some more debug
[14:18] <cachio> mvo, hey
[14:18] <mvo> hey cachio
[14:18] <cachio> mvo, taking a look to the error on core18 I see this
[14:18] <cachio> https://paste.ubuntu.com/p/9hzczyDQjf/
[14:18] <cachio> 2.41. instead of 2.41~
[14:18] <cachio> is it a bug?
[14:19] <cachio> or we will use dot
[14:19] <cachio> just to see if I need to change the script
[14:19] <mup> PR snapd#7336 opened: tests: add debug section to interfaces-contacts-service <Created by mvo5> <https://github.com/snapcore/snapd/pull/7336>
[14:19] <mvo> cachio: thats a bug
[14:19] <mvo> cachio: the edge is the correct version
[14:20] <mvo> cachio: its just the version number though that is wrong in beta, its the right snapd
[14:20] <mvo> cachio: with the next beta/candidate the version shoud be fine
[14:20] <cachio> mvo, perfect
[14:20] <cachio> thanks!
[14:21] <mvo> cachio: once you are happy with the beta I can push a new version. but we need to make sure of course that it includes all fixes you have for 2.41
[14:22] <cachio> mvo, sure, I'll push a fix now
[14:22] <cachio> mvo, that + the fix for listing test should be enough
[14:22] <cachio> then I have another one but so far I cound't reproduce it
[14:25] <mvo> cachio: thanks, let me tag the listing one as 2.41
[14:25] <mup> PR snapd#7332 closed: tests: remove trailing spaces from shell scripts <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7332>
[14:25] <zyga> Thank you mvo
[14:31] <mup> PR snapd#7337 opened: tests: re-enable mount-ns test on classic <Created by zyga> <https://github.com/snapcore/snapd/pull/7337>
[14:39] <zyga> mvo: all stuff fails on travis
[14:39] <zyga> E: Failed to fetch http://apt.postgresql.org/pub/repos/apt/dists/xenial-pgdg/main/binary-i386/Packages  Writing more data than expected (788347 > 787357)
[14:39] <zyga> 269
[14:39] <mvo> zyga: yeah, I noticed - I don't think we can do much, this is in the travis setup itself
[14:39] <zyga> correct :/
[14:39] <mvo> zyga: I wonder if #travis is a thing to report issues
[14:40] <mvo> zyga: but I guess nowdays #twitter is the thing :P
[14:40] <zyga> I'm sure  they know
[14:40] <zyga> yeah
[14:40] <zyga> where the kids and crazy world leaders (or is that that same thing) are
[14:40] <zyga> mvo: random simple patch from my pile https://github.com/snapcore/snapd/pull/7338
[14:40] <mup> PR #7338: tests: move restore-project-each code to existing function <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7338>
[14:40] <mup> PR snapd#7338 opened: tests: move restore-project-each code to existing function <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/7338>
[14:42] <mup> PR snapd#7339 opened: tests: don't look for lxcfs in mountinfo <Created by zyga> <https://github.com/snapcore/snapd/pull/7339>
[14:45] <zyga> mvo: cna we unblock  https://github.com/snapcore/snapd/pull/7196
[14:45] <mup> PR #7196: packaging: use passthrough for type:snapd <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7196>
[15:32] <pstolowski> cachio: https://github.com/snapcore/snapd/pull/7110 is green and can land?
[15:32] <mup> PR #7110: tests: new test to check the output after refreshing/reverting core <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7110>
[15:36] <zyga> pstolowski: please hold on
[15:36] <pstolowski> ok
[15:36] <mup> PR snapd#7340 opened: tests: adding support for arm devices on ubuntu-core-device-reg test <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7340>
[15:37] <zyga> pstolowski: I asked two questions there
[15:37] <zyga> cachio: can you please check those out?
[15:38] <cachio> zyga, sure
[15:38] <zyga> Thanks
[15:39] <zyga> I'm mainly after avoiding network IO
[15:39] <cachio> pstolowski, yes
[15:39] <cachio> :)
[15:40] <cachio> pstolowski, first let me check the questions
[15:45] <cachio> zyga, answered
[15:45] <cachio> zyga, thanks for the review, I didn't know about those questions
[15:46] <zyga> cachio: no worries, I just asked them a moment ago
[15:49]  * cachio lunch
[15:49] <zyga> cachio: replied again, sorry for being persistent about this
[15:49] <mvo> zyga: anything new in the twitter sphere about travis :) ?
[15:50] <zyga> mvo: sadly no
[15:50] <zyga> mvo: no status on travis website
[15:50] <zyga> as in, all is green there
[15:51] <mvo> booo
[15:51] <zyga> I'm still in bed so if I don't respond it's me trying to re-orient to get less painful layout
[16:04] <mvo> zyga: no worries, was just curious
[16:07] <zyga> oh, mvo is gone  :)
[16:07] <zyga> https://paste.ubuntu.com/p/Pdx9qmqbdH/
[16:07] <zyga> some unexpected stuff here
[16:07] <zyga> but I should break now
[16:22] <cachio> zyga, ok, let me see how could be changed that
[16:26] <cachio> zyga, do you know which test is installing a local version of the snap?
[16:26] <cachio> I found some but in most of the cases we are building the snap as part of the test
[16:26] <zyga> cachio: I don't remember from the top of my head, I recall seeing some that were installing a snap over itself but it was from "snap pack"
[16:26] <zyga> yeah
[16:29] <cachio> zyga, what do you suggest in this case?
[16:30] <zyga> snap install /var/lib/snapd/snap/core_$rev.snap
[16:30] <cachio> zyga, ah, ok
[16:30] <zyga> rev is read from readlink /snap/core/current
[16:31] <cachio> I'll try that
[16:38]  * zyga eod
[16:42] <cachio> zyga, updated
[16:42] <cachio> :)
[17:32] <mup> PR snapd#7341 opened: many: introduce package seed and seedtest <Created by pedronis> <https://github.com/snapcore/snapd/pull/7341>
[17:51] <zyga> travis is back to normal
[17:56] <ardaguclu_> Hi, there are some FIXME comments in various places, is it ok handling some of them. For instance, "// FIXME: this really should be TypeCore" in the types package
[17:56] <zyga> ardaguclu_: hey
[17:56] <zyga> ardaguclu_: yeah, though it's best to try asking first as some are harder or more tricky than others
[17:56] <zyga> ardaguclu_: but we 100% welcome all participation so please feel welcome :-)
[17:59] <ardaguclu_> zyga: thanks
[18:01] <ardaguclu_> creating unit tests and fixing bugs are the best ways to understand snapd codebase efficiently
[18:01] <ardaguclu_> that's why, I am really happy working these stuff :)
[18:02] <zyga> There is always something to improve :-)
[18:02] <zyga> I’m working on making the integration test suite more robust
[18:03] <zyga> Mainly by writing tools that detect misbehavior and adjusting tests not to do bad stuff
[18:07] <ardaguclu_> zyga: you are right, they are definitely not bad stuff.
[19:18] <arnatious> Hey all - I'm trying to run the code-insiders snap in an 18.04 lxd container and I'm just getting "dropping privs did not work"
[19:19] <arnatious> That look like a snap error or should I look elsewhere?
[19:26] <kyrofa> arnatious, it's definitely snap-related (comes from snap-confine if I remember correctly), just not sure what might be causing it. It's not a privileged container, is it?
[19:27] <arnatious> kyrofa nope
[19:27] <kyrofa> Hmm. zyga, any idea there? ^
[19:28] <arnatious> It has nesting enabled, and is being run from `lxc shell --user 1000 --env SHELL=/bin/bash -- sh -c /bin/bash`
[19:31] <kyrofa> arnatious, nesting shouldn't need to be enabled
[19:41] <mup> PR snapd#7342 opened: fixme: rename ubuntu*architectures to dpkg*architectures <Created by ardaguclu> <https://github.com/snapcore/snapd/pull/7342>
[19:52] <mup> PR snapcraft#2686 opened: New app handler (command-chain and no wrappers if command allows for it) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2686>
[19:58] <mup> PR snapcraft#2679 closed: colcon plugin: add ability to ignore packages in workspace <Created by danielwangksu> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/2679>
[19:58] <mup> PR snapcraft#2687 opened: colcon plugin: add ability to ignore packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2687>
[21:50] <mup> PR snapd#7343 opened: tests: moving tests to nightly suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7343>
[22:43] <mup> PR snapcraft#2688 opened: Build base types <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2688>