[02:19] <mup> PR snapd#4402 opened: tests: save the snapd-state without compression <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4402>
[06:00] <mborzecki> morning
=== pbek_ is now known as pbek
[08:05] <pstolowski> mornings
[08:16] <mborzecki> pstolowski: hey
[08:16] <pstolowski> o/
[08:44] <mborzecki> i've pushed some tools to analyze travis logs right here: https://github.com/bboozzoo/snapd-tools
=== __chip__ is now known as Chipaca
[09:14] <Chipaca> *yawn*
[09:14] <Chipaca> gmornin'
[09:16] <pstolowski> morning Chipaca!
[09:21] <mborzecki> Chipaca: o/
[09:21] <mborzecki> Chipaca: have you found anything interesting in interfaces-many test?
[09:30] <Chipaca> mborzecki: just that connect takes 4s+, and it does 65 of 'em
[09:30] <Chipaca> mborzecki: i'm wondering about digging into why it takes that long per connect
[09:31] <Chipaca> pstolowski: how long does a hook take to execute?
[09:32] <mborzecki> Chipaca: are there any hooks used in this test?
[09:33] <Chipaca> mborzecki: I don't think so, but run-hook is still run and still seems to take time
[09:33] <Chipaca> that's why i'm asking: what's the minimum time run-hook takes, if there is no hook
[09:33] <Chipaca> this is run-hook that's part of connect-snap
[09:34] <Chipaca> reporting its ReadyTime - SpawnTime to be an average of 4s also
[09:34] <pstolowski> well, hooks in the tests are very simple, hookmgr just executes hook script and grabs the output, that's as fast as it can be. unless the hook misbehaves, in which case we can get stuck waiting on 10min timeout
[09:34] <Chipaca> (ie most of the time is there)
[09:34] <Chipaca> pstolowski: so that's my question, how fast is "as fast as it can be"
[09:35] <Chipaca> because if that's 4s then something is wrong
[09:35] <pstolowski> Chipaca, if there is no hook script present then there is nothing to do.. it's a no-op
[09:35] <Chipaca> and if it's _not_ 4s, then something else is wrong :-)
[09:36] <pstolowski> Chipaca, is this about interfaces-many test?
[09:36] <Chipaca> pstolowski: there are no hook scripts in any of tests/lib/snaps/test-snapd-policy-app-*/
[09:36] <Chipaca> pstolowski: and it's taking 4s per hook
[09:36] <pstolowski> Chipaca, indeed
[09:36] <Chipaca> pstolowski: so, there's a bug in there somewhere
[09:36] <Chipaca> when I say "it's taking 4s per hook", what I should say is "it's reporting 4s per hook"
[09:36] <Chipaca> because the bug could also be in the reported time :-)
[09:38] <pstolowski> interesting. how do you measure it, do you have a modified code?
[09:39] <Chipaca> pstolowski: http://paste.ubuntu.com/26187733/
[09:39] <Chipaca> pstolowski: just looking at changes
[09:39] <Chipaca> that is, /v2/changes?select=all, and then print and sort
[09:40] <Chipaca> to be clear, i am suspecting the times are somehow wrong
[09:41] <pstolowski> Chipaca, what is the number in parentheses?
[09:41] <Chipaca> pstolowski: id
[09:41] <pstolowski> k
[09:42] <Chipaca> but it doesn't make sense for them to be like this, so it's probably counting spawn time from the change and not the task spawn, or something
[09:42] <Chipaca> meaning i might need to accumulate time along a change
[09:42] <Chipaca> hm
[09:42] <Chipaca> i'll give it a try
[09:44] <pstolowski> Chipaca, I was going to say exactly that. the times on the left looks like accumulated times from the start
[09:49] <Chipaca> pstolowski: http://paste.ubuntu.com/26187774/
[09:49] <Chipaca> accumulated, now
[09:49] <Chipaca> that makes more sense
[09:50] <Chipaca> but it does mean the time is all in connect itself
[09:51] <Chipaca> i'm going to have to profile this aren't i :-/
[09:51]  * Chipaca sighs and gets onto it
[09:52] <pstolowski> Chipaca, big gap between 8.209555 install-snap(2)/run-hook(14) and 17.577298 install-snap(8)/setup-profiles(54) ?
[09:53] <Chipaca> pstolowski: are you still looking at the non-deaccummuated one?
[09:53] <pstolowski> Chipaca, ah gosh, right, I confused the tabs in my browser
[09:53] <Chipaca> :-)
[09:54]  * pstolowski closes the old tab to be safe ;)
[09:54] <Chipaca> pedronis: shouldn't SpawnTime of a change be the time it was run, not the time it was created?
[09:54] <Chipaca> pedronis: ditto task
[09:54] <Chipaca> oh wait that's "AtTime"
[09:54] <Chipaca> which isn't in the client >:-(
[09:55] <pstolowski> Chipaca, one thing I can say for sure wrt to this test is
[09:56] <mup> PR snapd#4403 opened: asserts/signtool: support for building tools on top that fill-in/compute some headers <Created by pedronis> <https://github.com/snapcore/snapd/pull/4403>
[09:56] <pstolowski> Chipaca, in the past we had Connect doing multiple connections at once. that was changed to create one task for every connection which in reality adds even more tasks because of hooks
[09:56] <pedronis> Chipaca: Gustavo defined it that way, but basically it's creating time, not start of running time, notice that a task can start running many times (because of retry)
[09:57] <Chipaca> quick, how many definitons of a 'change' struct do we have in our codebase?
[09:57] <Chipaca> answer: no less than 4 (i wouldn't swear it wasn't more)
[09:57] <Chipaca> overlord/state has two, client has one, daemon has one
[09:58] <Chipaca> :-( no wonder theyre out of sync
[09:58] <Chipaca> pedronis: it makes knowing how long a task took to run quite hard
[09:58] <pedronis> it is hard though essentialy
[09:58] <pedronis> Chipaca: AtTime is used by retry with a specific time
[09:59] <Chipaca> pedronis: sorry, i said hard but i meant impossible, strictly
[09:59] <Chipaca> it is hard, yes
[09:59] <Chipaca> but with the data exposed we can only guess at it
[09:59] <Chipaca> gah
[09:59] <Chipaca> EOY-day should be more puppies and less cockroaches
[10:00] <pstolowski> :)
[10:00] <pedronis> we could have a cumulative run time
[10:00] <pedronis> also we have do and undo
[10:00] <pedronis> a task is not one-time function
[10:02] <mup> Issue snapcraft#1695 closed: Refactor meta into package <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1695>
[10:02] <mup> PR snapcraft#1804 closed: meta: refactor into a package <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1804>
[10:03] <pedronis> Chipaca: you need to measure stuff from TaskRunnun.run basically
[10:03] <pedronis> *TaskRunner
[10:04] <Chipaca> pedronis: i think i'll open a forum topic
[10:04] <Chipaca> otherwise it'll bug me
[10:05] <jamesh> yay.  green ticks next to my PRs again.
[10:06] <Chipaca> jamesh: oh no you jinxed it
[10:06] <Chipaca> pedronis: https://forum.snapcraft.io/t/task-accounting/3201 fwiw
[10:09] <jamesh> Chipaca: apart from the tests/main/searching bug that was recently fixed, a few times it seems the tests just take too long to run for travis
[10:09] <Chipaca> jamesh: yeah, we're looking into that -- they shouldn't
[10:10] <Chipaca> jamesh: there are some things we can do, but we'll wait for the new year as they require a concerted effort
[10:10] <Chipaca> jamesh: (this is, basically, updating the images to spend less time waiting on the network)
[10:10] <Chipaca> jamesh: but then, there're still tests that are inexplicably slow; looking into that as well
[10:10] <mborzecki> or randomly failing
[10:10] <jamesh> Chipaca: it'd also be  nice if the test output was less verbose: when there is a failure, it takes a while to locate the error message
[10:11] <Chipaca> jamesh: yeah, gustavo was going to turn off a lot of the output
[10:17] <sergiusens> kyrofa elopio you both added non actionable comments to https://github.com/snapcore/snapcraft/pull/1786 please address that
[10:17] <mup> PR snapcraft#1786: lxd: always install squashfuse <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1786>
[10:18] <pedronis> Chipaca: I added to backlog at least otherwise it will get forgotten, Doing the simplest possible thing shouldn't be too hard, it might be too simple though.
[10:46] <Chipaca> unless i'm reading this profile wrong, 2/3 of the (cpu) time is spent doing json encoding
[10:52] <pedronis> Chipaca: there might be some kind of   for loop Locking/Unlocking  state somewhere in there
[10:53] <jamesh> any chance of getting https://github.com/snapcore/snapd/pull/4140 merged?
[10:53] <mup> PR #4140: interfaces: add an interface for gnome-online-accounts D-Bus service <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4140>
[10:56] <pedronis> jamesh: if the interface don't work 14.04 should it not be exported there?
[10:56] <pedronis> *doesn't work in
[10:57] <pedronis> jamesh: I'm a bit unfraid that without clarity on that it can't be merged
[10:59] <jamesh> pedronis: I think the D-Bus API changed between those GNOME versions, but haven't really investigated because we didn't install gnome-online-accounts by default back then (I don't think it is installed in 16.04 either)
[11:00] <pedronis> jamesh: where is it installed by default?
[11:00] <jamesh> pedronis: 17.10 definitely.  We had a different online accounts system in unity7
[11:00] <pedronis> I'm not even sure we have a policy around interfaces that aren't there by default?
[11:01] <jamesh> it'd be installed on Ubuntu-GNOME for those older releases though.
[11:02] <pedronis> what happens  if one installs a snap needing this but the service is not there? does the interface auto-connect?
[11:02] <pedronis> ok, it doesn't
[11:03] <jamesh> pedronis: if you connected the interface but goa-daemon wasn't present, then the confined app would get a D-Bus error when it tried to contact the service
[11:16] <pstolowski> pedronis, i've been looking at https://forum.snapcraft.io/t/new-configure-snapd-task-and-reverting/2774/2 in the light of 'auto-connect' task. aborting will make revert fail, no? or do I miss something?
[11:17] <pedronis> pstolowski: you miss something,  as I said we would need some special casing
[11:17] <pedronis> otherwise it doesn't help
[11:18] <pstolowski> pedronis, indeed. somthing like a 'ignore-me' flag on the task?
[11:18] <pedronis> yes
[11:18] <pedronis> I thought we discussed that
[11:19] <pedronis> given that your case you are splitting the bahavior of a preexisting task it would be ok
[11:19] <pedronis> though setup-profiles is complicated
[11:23] <pstolowski> pedronis, yes, we discussed many aspects of that but i'm sure i missed some of that because of limited understanding of entire picture and edge cases; i'm sure reviews will prove that
[11:28] <mborzecki> am i the only one getting i/o timeouts all the time when trying to run anything on linode through spread?
[11:34] <koza> everyone has a superpower ;-)
[11:36] <mborzecki> yeah, i speak polish, what's your superpower koza.. oh wait :)
[11:39] <Chipaca> pedronis: spot on. Dropping the unlock/lock in a loop in a loop (in a loop?) drops execution time to nearly nothing
[11:39] <Chipaca> this is in ifacestate/helpers.go: setupSnapSecurity
[11:40] <Chipaca> basically it means doing backend.Setup() with the lock held
[11:40] <Chipaca> is that bad?
[11:40] <Chipaca> in numbers, the test drops from over 5 minutes to under 1 minute
[11:48] <pstolowski> impressive
[11:54]  * cachio afk
[12:01] <pedronis> Chipaca: I think over time we are moving away from freeing the lock if all we are doing is disk ops,  otoh some backend do systemd stuff I think
[12:04] <Chipaca> I need to go to the boys school now (and might not make it back for the standup), but i'll look into it when i return
[12:21] <sergiusens> elopio something is wrong with the nightly, trying to commit to the uncommitable https://travis-ci.org/snapcore/snapcraft/jobs/316767537
=== daniellimws is now known as Guest24164
=== Guest55974 is now known as daniellimws
=== daniellimws is now known as Guest97038
=== dows is now known as daniellimws
[13:05] <mup> PR snapcraft#1795 closed: lifecycle: do not include source tarballs from previous runs <Created by ted-gould> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1795>
[13:37]  * Chipaca returns
[14:22] <Chipaca> i wonder if gofmt can find me all the instances of a for loop with a lock/unlock inside it
[14:47] <pedronis> Chipaca: I don't think we have a ton of those, we had some in snapstate but I think we removed them
[14:52] <elopio> sergiusens checking the commit...
[14:59] <pedronis> Chipaca: we have about 51 Unlock of state/contexts  without a defer
[15:00] <pedronis> Chipaca: or were you thinking of adding something to run-checks ?
[15:01] <Chipaca> pedronis: no, was just going to look at current state
[15:02] <pedronis> Chipaca: you can probably just look at each of them
[15:05] <sergiusens> elopio and testing from master fails as transfer.sh is blocked
[15:05] <Chipaca> pedronis: heh, wrote a thing using parser and ast
[15:05] <Chipaca> found 10 locks inside loops
[15:06] <Chipaca> 6 of them not in tests
[15:08] <Chipaca> one is overlord.Loop, one (two actually) is overlord.Settle, one is TaskRunner.wait, one is devicestate.fetchKeys
[15:08] <Chipaca> and one in daemon.finishShutdown
[15:08] <Chipaca> all very boring
[15:08]  * Chipaca throws the ast away and goes for grep
[15:09] <pedronis> Settle is also test only
[15:10] <pedronis> Chipaca: notice also that they are much more problematic if the code invoked might change the state
[15:11] <pedronis> we shouldn't serialize if there's no write
[15:11] <pedronis> serialize as in JSON encode
[15:12] <sergiusens> elopio mind updating snapcraft#1802 ?
[15:12] <mup> PR snapcraft#1802: metadata: extract metadata from appstream <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1802>
[15:12] <sergiusens> elopio actually, if you have time, let's meet
[15:41] <elopio> sergiusens: on the weekly?
[15:42] <sergiusens> elopio one sec
[15:46] <pedronis> Chipaca: will you propose a PR today?
[16:27] <Chipaca> pedronis: I fear not: the systemd backend does indeed do weird stuff that can take 10s+
[16:28] <pedronis> what I feared
[16:28] <Chipaca> pedronis: so i think i need to talk with zyga about it, and there might be a bigger refactor
[16:28]  * elopio is back
[16:28] <mup> PR snapd#4404 opened: data/selinux: allow messages from policykit <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4404>
[16:28] <Chipaca> also the systemd code is suspicious
[16:28] <pedronis> Chipaca: given some control to backends, but we cannot pass state there, we  would need an interface
[16:29] <Chipaca> pedronis: maybe define them as getting a sync.Locker
[16:29] <Chipaca> not sure
[16:29] <Chipaca> maybe Setup needs to return a callback to be called without the lock, so it's only frobbed once
[16:30] <mborzecki> i'm done for today, enjoy your weekend guys
[16:30] <Chipaca> mborzecki: see you next year!
=== mbiggers_ is now known as markb1
[16:30] <mborzecki> Chipaca: oh, you're not here next week?
[16:30] <Chipaca> mborzecki: nor the one after that :-D
[16:30] <mborzecki> haha :)
[16:30] <Chipaca> mborzecki: i should be back on tuesday the twooth of january
[16:31] <mborzecki> well, then merry christmas and happy new year :)
[16:31] <Chipaca> mborzecki: likewise!
[16:32] <Chipaca> pedronis: or maybe we move to an actual database and this whole thing goes away?
[16:32] <pedronis> maybe
[16:33] <pedronis> not sure it's the best time to do that (too much other feature work/bugs)
[16:34]  * Chipaca nods
[16:35]  * pedronis calls it a year
[16:35] <pedronis> happy holidays!
[16:37] <mup> PR snapd#4405 opened: taskrunner/many: KnownTaskKinds helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/4405>
[16:39] <Chipaca> pedronis: have a good one! see you in 2018
[16:42] <pstolowski> happy holidays pedronis!
[16:45] <elopio> enjoy pedronis !
[17:20] <kyrofa> ogra_, I can't remember: will removing the classic snap reset the unpacked chroot as well?
[17:20] <kyrofa> Reset by removing it as well, I guess
[17:20] <kyrofa> Or is there a special command I need to do that?
[17:24] <kyrofa> Chipaca, perhaps you know?
[17:24] <Chipaca> kyrofa: AFAIK removing the snap will remove the chroot
[17:24] <Chipaca> kyrofa: because AFAIK the classic snap isn't special
[17:25] <kyrofa> Chipaca, well, it's a devmode snap, so I figure it can put that anywhere it wants
[17:25] <kyrofa> Removing and crossing my fingers...
[17:25] <Chipaca> kyrofa: i can check for you if you want :-)
[17:26] <kyrofa> Chipaca, nah, testing now
[17:26]  * Chipaca was curious and kicked it off to test
[17:26] <kyrofa> Chipaca, you were right
[17:27] <kyrofa> It's "creating classic environment" now. Excellent
[17:27] <Chipaca> kyrofa: sorry
[17:30] <elopio> sergiusens: we don't yet have any results from the PPA. We are at the bottom of all queues. I think that collecting daily would be alright. We won't necessary get the results of what was triggered the previous day, but we will get the results of the most recent execution.
[17:31] <elopio> there is already one execution for 20171215, so on tonights execution, the results should be collected. I'll keep an eye.
[17:31] <Chipaca> ok boys and girls, I think I'm done.
[17:32] <Chipaca> ttfn, and see you next year!
[17:36] <brunosfer> Hi guys, does anyone know how can I start the snapd with the DEBUG MODE using the binary instead of the service?
[17:40] <cjwatson> brunosfer: There are instructions for that in HACKING.md
[17:40] <cjwatson> search for DEBUG
[17:42] <brunosfer> cjwatson: Thanks
[18:03] <mup> PR snapcraft#1808 opened: ci: don't fail if the snap transfer fails <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1808>
[18:04] <elopio> nessita: cprov ^ That's to unblock you.
[18:15] <mup> PR snapcraft#1809 opened: formatting_utils: add type hints <Created by konrad11901> <https://github.com/snapcore/snapcraft/pull/1809>
[18:20] <nessita> elopio, thanks!
[18:36]  * kyrofa is shooting, responses may be delayed
[18:38] <elopio> snappy-m-o autopkgtest xenial:armhf 1807
[18:38] <snappy-m-o> Computer says nooo. See logs for details:
[18:38] <snappy-m-o>  Command '['/tmp/tmpcxggf713/retry_autopkgtest.sh', 'xenial:armhf', '1807']' returned non-zero exit status 1
[18:38] <elopio> snappy-m-o autopkgtest 1807 xenial:armhf
[18:39] <snappy-m-o> elopio: I've just triggered your test.
[18:39] <elopio> sergiusens: subscribe to that one ^
[18:39] <elopio> no need to make a new pr, that one is up-to-date with master, and will run what you are looking for.
[18:40] <sergiusens> elopio 07 because no one will touch it for a while? :-)
[18:42] <elopio> yup, and it's almost a noop change.
[18:56] <kyrofa> Uhh... nessita cprov this seems like a problem: https://pastebin.ubuntu.com/26190126/
[18:57] <kyrofa> It's working now. Maybe only some endpoints?
[18:59] <nessita> checking
[19:01] <cprov> kyrofa: does it continue to fail ? my systems are not complaining and we haven't changed certs recently, let me dig more
[19:02] <kyrofa> cprov, it happened twice. Third time it successfully downloaded/installed
[19:02] <nessita> kyrofa, is working for me: curl -s -H 'X-Ubuntu-Store: ubuntu' -H 'X-Ubuntu-Series: 16' -H 'X-Ubuntu-Architecture: amd64' 'https://api.snapcraft.io/api/v1/snaps/details/edukit-bot-kyrofa?channel=edge'
[19:10] <sergiusens> kyrofa is this an arm device? Check the date
[19:11] <cprov> kyrofa: we have some haproxy "SSL handshake failure", but it's too frequent to not have being noticed before
[19:12] <kyrofa> Fair enough, just wanted to raise it in case it was an issue. If it happens again I'll let you know
[19:18] <cprov> kyrofa: ah sergiusens is right, your system clock might not be current, https://lists.ubuntu.com/archives/snappy-devel/2015-March/000416.html
[19:30] <cachio> niemeyer, I was researching the connection issue and there is not way to connect to the machines after the connection error
[19:31] <cachio> niemeyer, so, it seems to be a problem in the machine allocation/start process
[19:33] <cachio> niemeyer, today seem to be working better than the previous days, that could be because there is less traffic
[19:33] <cachio> less people creating PRs
[19:41] <mup> PR snapd#4406 opened: interfaces/dbus: adjust slot policy for listen, accept and accept4 syscalls <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4406>
[20:07] <mup> PR snapcraft#1808 closed: ci: don't fail if the snap transfer fails <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1808>
[21:07] <sergiusens> elopio this is my endgame, snapcraft#1798
[21:07] <mup> PR snapcraft#1798: elf: strip the .note.go.buildid to make room for patching elf <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1798>
[22:05] <popey> sergiusens: is it possible to get 'dump' plugin to _just_ dump the file at the url specified by 'source' and put it in the snap? I don't want to unpack. Just dump the file in?
[22:09] <popey> think i might have to use nil, and wget in install step