[00:02] <sergiusens> nacc: if you are seeing failures to upload; this has been going on all day (not related to 2.40) and something snapstore related
[00:03] <nacc> sergiusens: no, wasn't that -- and now i'm thinking it is something else (possibly worse, in that some jobs succeeded and some failed). I'm retriggering all 4 so they use 2.40 hopefully and we'll see what happens
[00:04] <nacc> sergiusens: urgh ... unsquashfs failures? https://jenkins.ubuntu.com/server/job/git-ubuntu-ci/350/console
[00:04] <nacc> i just had two of the four fail that way
[00:05] <nacc> sergiusens: but the other two got past that point, it seems
[00:05] <sergiusens> nacc: that is a corrupted download of the core snap; this is part of the general store slow down we are all waiting to get fixed
[00:05] <nacc> sergiusens: oh ok, retry should work?
[00:06] <nacc> sergiusens: or is there a better ... solution?
[00:06] <sergiusens> nacc: I am not in the store team, but a retry could work, yes
[00:06] <nacc> sergiusens: thanks!
[00:06] <nacc> we'll see what it does :)
[00:07] <sergiusens> nacc: btw, why aren't you using launchpad buildd and such?
[00:37] <cjwatson> I can understand people not doing so for per-commit CI
[00:38] <cjwatson> Though I hope we'll support that kind of thing at some point
[00:43] <nacc> sergiusens: what cjwatson said
[00:44] <nacc> sergiusens: in any case, some jobs are showing the link error for libgpg-error still
[00:44] <nacc> but not all
[00:44] <nacc> sergiusens: which feels like a worse place to be than we were
[00:44] <nacc> i'll start debugging in the AM
[01:28] <mup> PR snapcraft#2039 closed: Release changelog for 2.40.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2039>
[02:34] <mup> PR snapcraft#2040 opened: lifecycle: always prime dependencies <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2040>
[05:19] <mborzecki> morning
[05:20] <mborzecki> something wrong with the store? the download seems to be capped at 50-60kBps
[05:57] <zyga> good morning
[05:57]  * zyga goes to wake the kids
[05:57] <zyga> mborzecki: yes, store is affected by ceph issue
[05:58] <mborzecki> ceph has fallen apart/
[05:58] <mborzecki> ?
[06:18] <zyga> mborzecki: not sure what happened really
[06:18] <zyga> it's online but very slow apparently
[06:19]  * zyga is almost done with the kids
[06:24] <zyga> not if only kids made me breakfast in return :)
[06:41] <zyga> good morning pedronis, is #4931 ready to go? it has 2 "+1"s and it is green but you expressed an idea that there's perhaps more to be done in that area
[06:41] <mup> PR #4931: configcore: give a chance to immediately recompute the next refresh time when schedules are set <Blocked> <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4931>
[06:43] <zyga> pstolowski|afk: I'll play with #4946
[06:43] <mup> PR #4946: ifacestate: don't surface stale connections <Created by stolowski> <https://github.com/snapcore/snapd/pull/4946>
[07:03] <pstolowski> morning
[07:04] <kalikiana> moin moin
[07:04] <kalikiana> o/ pstolowski
[07:05] <pstolowski> hey kalikiana
[07:19] <pedronis> zyga: yes, it needs to be done differently to be correct
[07:19] <zyga> pedronis: thanks for confirming that
[07:20] <pedronis> that's why I marked it blocked
[07:34] <mup> PR snapd#4920 closed: timeutil: in Human, count days with fingers <Created by chipaca> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4920>
[07:36] <zyga> pstolowski: hey, I pushed to https://github.com/snapcore/snapd/pull/4946/files
[07:36] <mup> PR #4946: ifacestate: don't surface stale connections <Created by stolowski> <https://github.com/snapcore/snapd/pull/4946>
[07:36] <zyga> can you please have a look
[07:38] <pstolowski> zyga: thanks, looking
[07:44] <pstolowski> zyga: looks good, thanks for extra test
[07:54] <pstolowski> zyga: thinking about this stale connections problem.. as i mentioned on the forum, discard-conns is the last task on snap-removal, it may never get executed if a task before it fails; if think we should run this task regardless of any earlier error (use Lanes?)
[08:00] <zyga> pstolowski: can you walk me through an example please
[08:00] <zyga> (sorry for the lag, my daughter is just leaving for school now)
[08:06] <pstolowski> zyga: we run stop-snap-services, remove-aliases, unlink-snap, remove-profiles, remove hook, discard-conns is last; in particular remove-hook can easily pose problems; discard-conns should be executed always I think
[08:07] <pstolowski> zyga: and nb, i wonder if remove hook shouldn't be called earlier in the sequnce, it's probably run too late
[08:07] <zyga> pstolowski: when remove hook fails, what happens then?
[08:08] <pstolowski> zyga: ah, ignore remove-hook failure, no problem there, we set ignoreError:true on it
[08:09] <pstolowski> zyga: so yeah, the only problem is if any other task fails and discard-conns is not reached
[08:10] <pstolowski> I need to run to the dentist, bbl
[08:10] <zyga> pstolowski: sure
[08:10] <zyga> pstolowski|denti: when you are back, do we undo stuff when any of those fail?
[08:10] <pstolowski|denti> zyga: no, we don't have undo on snap removal, afair it's very hard to undo those
[08:11] <pstolowski|denti> (something we discussed on different occasion with pedronis afair)
[08:15] <mup> PR snapcraft#2013 closed: tests: run tests on Trusty on Travis <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/2013>
[08:16] <pedronis> zyga, mborzecki: #4931 is updated
[08:16] <mup> PR #4931: configcore: give a chance to immediately recompute the next refresh time when schedules are set <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4931>
[08:17] <zyga> lookinbg
[08:17] <pedronis> zyga: the change is simple, testing it a bit less so
[08:18] <mup> PR snapcraft#1800 closed: grammar: on..to statement <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1800>
[08:18] <mup> PR snapcraft#1900 closed: many: handle copying of symlink permissions gracefully <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1900>
[08:38] <mborzecki> zyga: do you know what the plan for nvidia is?
[08:38] <zyga> mborzecki: review your branch with gustavo
[08:38] <zyga> mborzecki: and I think we'll do 2.32.2 with this
[08:40] <mborzecki> zyga: oh ok
[08:45] <zyga> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1648681.html
[09:08] <zyga> not a happy store day
[09:09] <sparkiegeek> zyga: we're just helping you improve your error handling ;)
[09:19] <zyga> sparkiegeek: oh yes, we need to get creative on the word "http" :-)
[09:19]  * zyga hugs sparkiegeek 
[09:19] <zyga> it's good that we have plenty of reviews to make :)
[09:24] <om26er> popey: kindly register the name 'sublime-text' under snapcrafters as I don't have the permissions to do so.
[09:25]  * zyga would love to see sublime-text with subl alias 
[09:26] <popey> om26er: someone else has registered it, back in 2016
[09:26] <popey> but never uploaded anything
[09:26] <popey> I'll ping them a mail to let them know we'd like to take it over
[09:27] <om26er> popey: yeah, that would make sense
[09:27] <om26er> zyga: the app name is already subl in the yaml file, so we only need the alias (that I'll request once we upload it).
[09:28] <zyga> pedronis: I reviewed #4931
[09:28] <mup> PR #4931: configstate: give a chance to immediately recompute the next refresh time when schedules are set <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4931>
[09:29] <popey> om26er: mail sent
[09:29] <popey> lets give it a few days for them to respond
[09:29] <zyga> om26er: perfect!
[09:30] <zyga> om26er: I use the deb still but I  use sublime everywehre so I'm super happy to switch
[09:30] <zyga> it would be nice if there was a way for github to add a banner to pull request page saying "we know about XXX issue, tests are red while that happens"
[09:30] <om26er> aha, so you are our first user ;-)
[09:31] <popey> well crap, their email bounces
[09:31] <om26er> zyga: I also contacted upstream, so you got anything to add there: https://forum.sublimetext.com/t/modern-instalation-snap-package/31123
[09:31] <zyga> is wbond the upstream?
[09:31] <om26er> zyga: yes
[09:32] <om26er> popey: bummer, wonder what's next for us.
[09:32] <mup> PR snapd#4921 closed: skip test if no user "daemon" in build jail <Created by rkitover> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4921>
[09:32] <popey> I'm going to take it.
[09:32] <popey> if you registered a snap over a year ago, never uploaded anything and deleted your email address...
[09:33] <zyga> pedronis: can you please look at https://github.com/snapcore/snapd/pull/4911
[09:33] <mup> PR #4911: daemon,client: add build-id to /v2/system-info <Created by mvo5> <https://github.com/snapcore/snapd/pull/4911>
[09:33] <zyga> I'm inclined to merge it but I wanted to double check
[09:34] <pedronis> do we still know if we need it?
[09:34] <zyga> I don't think we need it but it's actually very useful for other reasons
[09:34] <zyga> snap version is how we ask people to report bugs and give us initial hints
[09:35] <popey> om26er: done, snapcrafters has sublime-text now
[09:35] <om26er> popey: do we need to ask for 'classic' confinement again ?
[09:36] <om26er> also what about remove the name sublime-text-3 completely, is that possible ?
[09:36] <popey> Yes, I would recommend asking for both the alias and classic confinement in one post
[09:36] <popey> we can just unpublish the sublime-text-3 so nobody can see it
[09:38] <om26er> popey: we already have a alias request in forum.snapcraft.io, so only created a new request for classic confinement
[09:38] <popey> Awesome
[09:38] <popey> Nice work om26er :)
[09:39] <pstolowski> back
[09:44] <om26er> popey: have you also enabled auto builds for that new name ?
[09:44] <popey> not yet.
[09:45] <om26er> hmm, I think for classic confinement request to proceed we would need to have something in the build queue.
[09:46] <om26er> ...same goes for alias request
[09:46] <popey> one moment, I have to remve s-t3 first
[09:46] <popey> https://usercontent.irccloud-cdn.com/file/JzviDh1g/
[09:46] <popey> ^
[09:47] <pedronis> zyga: I will re-look in a bit,  I'm in a twisty maze of conflicts and also it getting close to lunch
[09:47] <zyga> pedronis: ack, thank you and enjoy your lunch :)
[09:49] <popey> https://usercontent.irccloud-cdn.com/file/fNwd5Kq9/
[09:49] <popey> ^ om26er
[09:50] <greyback> was there a CI wobble? https://github.com/snapcore/snapd/pull/4932
[09:50] <mup> PR #4932: interfaces/content: add rule so slot can access writable files at plug's mountpoint <Created by gerboland> <https://github.com/snapcore/snapd/pull/4932>
[09:50] <greyback> log complaining of odd things
[09:50] <mborzecki> zyga: pushed updates to #4942
[09:50] <mup> PR #4942: cmd/snap: user session application autostart v3 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4942>
[09:50] <popey> om26er: all done from here?
[09:51] <greyback> mborzecki: yay, thanks for that, I'm looking forward to using it
[09:51] <om26er> popey: seems so, yes
[09:51] <popey> awesome
[09:51] <popey> o/ thanks again!
[09:52] <om26er> popey: add me as a collaborator ?
[09:55] <zyga> om26er: can you please ping me once the snap is published
[09:55] <om26er> zyga: sure, will do.
[10:01] <mup> PR snapd#4947 opened: spread: disable StartLimitInterval option on opensuse-42.3 <Created by stolowski> <https://github.com/snapcore/snapd/pull/4947>
[10:01] <om26er> popey: whenever you read this: 1. Kindly add me as a collaborator to sublime-text, 2. I can still `snap info sublime-text-3` so its not really gone.
[10:03] <om26er> zyga: the build failed because it requires classic confinement, that I believe will be granted by jdstrand (and also the alias).
[10:05] <zyga> om26er: did it fail or just got flagged on upload?
[10:05] <om26er> zyga: the latter.
[10:25]  * zyga reviews 4772
[10:25] <zyga> that's a biggie
[10:25] <zyga> I'm reading and scrolling and scrolling
[10:25] <zyga> and thinking, gee, how long is this
[10:25] <zyga> then noticed the header :)
[10:42] <pstolowski> E: Unable to locate package linux-image-extra-4.15.0-12-generic on ubuntu 18.04 in spread
[10:54] <zyga> pstolowski: missing update perhaps?
[10:55] <pstolowski> or archive not fully sync? i've restarted the test, let's see if it persists
[10:55] <zyga> nowadays archive cannot be partially synced
[11:27] <pedronis> zyga:  I have a nitpick about #4911
[11:27] <mup> PR #4911: daemon,client: add build-id to /v2/system-info <Created by mvo5> <https://github.com/snapcore/snapd/pull/4911>
[11:28] <zyga> pedronis: I'll tweak tha
[11:28] <zyga> that
[11:30] <zyga> pedronis: done
[11:45] <zyga> pedronis: review on the big store PR
[11:46]  * zyga breaks for 15 minutes
[11:59]  * zyga debugs current 18.04 issue
[12:01] <mborzecki> off to pick up my daughter from school, bb for standup
[12:07] <zyga> hmm
[12:07] <zyga> I know what's wrong now
[12:07] <zyga> cachio: ping
[12:07] <cachio> zyga, hey
[12:08] <zyga> cachio: two questions
[12:08] <zyga> what is our kernel in google ubuntu bionic image?
[12:08] <zyga> I get Linux mar281357-854414 4.15.0-12-generic #13-Ubuntu SMP Thu Mar 8 06:24:47 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[12:08] <mup> PR #13: Bugfix/review tools reenable <Created by mvo5> <Merged by elopio> <https://github.com/snapcore/snapd/pull/13>
[12:08] <zyga> which is very odd
[12:08] <zyga> second
[12:08] <zyga> we need to regenerate that image
[12:08] <zyga> and get a more recent kernel
[12:08] <zyga> because modules for this kernel are no longer in the package
[12:08] <zyga> this must be done ASAP or we must disable bionic tests
[12:09] <zyga> we fail because essentially this happens:
[12:09] <zyga> google:ubuntu-18.04-64 ...# apt-cache policy linux-image-extra-4.15.0-12-generic
[12:09] <zyga> N: Unable to locate package linux-image-extra-4.15.0-12-generic
[12:09] <zyga> N: Couldn't find any package by glob 'linux-image-extra-4.15.0-12-generic'
[12:09] <zyga> N: Couldn't find any package by regex 'linux-image-extra-4.15.0-12-generic'
[12:09] <cachio> zyga, the ubuntu bionic image is not generated by us
[12:09] <cachio> zyga, let me try with the last image
[12:09] <zyga> cachio: ah, I see
[12:09] <zyga> yeah, let's try today's image
[12:10] <cachio> yes
[12:10] <zyga> if this works I'll send the PR
[12:11] <mup> PR snapd#4721 closed: tests: update interface tests to remove extra checks and normalize tests <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4721>
[12:12] <zyga> cachio: have a look at 4948
[12:12] <mup> PR snapd#4948 opened: spread: use more recent bionic snapshot <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4948>
[12:14] <cachio> zyga, aoorived
[12:14] <cachio> zyga, just wait to see the test results
[12:14] <zyga> thanks, let's see if something blows up along the way
[12:14] <zyga> I'm running it locally here and it's past the point where it broke earlier
[12:15] <cachio> zyga, this images are being updated every day with latest changes
[12:15] <zyga> yeah, it's something w may have to repeat until release
[12:15] <cachio> previously I made to detect automatically the last one and use it
[12:15] <zyga> after release I assume our image will be an alias to the latest stable bionic image
[12:15] <cachio> but we had problems too
[12:15] <cachio> yes
[12:31] <pedronis> zyga: I upadted #4931 , let me know if it's clearer
[12:31] <mup> PR #4931: configstate: give a chance to immediately recompute the next refresh time when schedules are set <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4931>
[12:31] <zyga> thanks, looking
[12:39] <mup> PR snapd#4877 closed: snap-confine: fallback to /lib/udev/snappy-app-dev if the core is older <Created by mvo5> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4877>
[12:39]  * kalikiana lunch
[12:42]  * zyga considers closing https://github.com/snapcore/snapd/pull/4349
[12:42] <mup> PR #4349: Make snapd.autoimport configurable <Blocked> <Decaying> <Created by ogra1> <https://github.com/snapcore/snapd/pull/4349>
[12:42] <zyga> we have plenty of PRs and this one doesn't seem to move now
[12:42] <zyga> ogra_: ^
[12:42] <ogra_> zyga, what should move there ?
[12:43] <zyga> ogra_: the PR got NACKed, is there ongoing discussion or other reason to keep it open?
[12:43] <zyga> note that we can always reopen things
[12:43] <ogra_> zyga, it ends with a question from alex to gustavo that got never answered
[12:43] <zyga> we're just struggling with the number of open PRs
[12:43] <ogra_> zyga,  we need this feature for a customer ...
[12:43] <ogra_> one way or the other
[12:43] <niemeyer> What's the PR?
[12:44] <ogra_> my suggestion was turned down, a question was asked what a better approach would be and that is where it stands now
[12:44] <zyga> niemeyer: #4349
[12:44] <mup> PR #4349: Make snapd.autoimport configurable <Blocked> <Decaying> <Created by ogra1> <https://github.com/snapcore/snapd/pull/4349>
[12:44] <mup> PR snapd#4948 closed: spread: use more recent bionic snapshot <Critical> <Created by zyga> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4948>
[12:45] <zyga> thanks Sergio!
[12:45] <zyga> we need to merge master into most important PRs that are ready to land now
[12:46] <ogra_> zyga, niemeyer, the way more important one is #4819 though ... thats slowly getting urgent
[12:46] <mup> PR #4819: interfaces/serial: change pattern not to exclude /dev/ttymxc* <Created by bergotorino> <https://github.com/snapcore/snapd/pull/4819>
[12:46] <zyga> cachio: I made a back port of the google update for 3.32 but it seems we are still using linode there
[12:46] <ogra_> (i think koza adjusted it properly to be mergeable)
[12:46] <zyga> ogra_: I'll look now
[12:46] <ogra_> ... that one also has an open alex question :)
[12:48] <zyga> that one looks mergeable now, with the updates given it adds one specific new pattern and corresponding tests
[12:48] <zyga> hmm
[12:48]  * zyga needs to read the tests in detail though
[12:48] <mup> PR snapd#4349 closed: Make snapd.autoimport configurable <Blocked> <Decaying> <Created by ogra1> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/4349>
[12:48] <ogra_> right, but we need to do something about the fact that it will bite us again with the next customer
[12:49] <ogra_> so long term a more graceful regex is needed
[12:49] <ogra_> (manufacturers tend to invent their own tty names for serial ports ... thats not uncommon)
[12:49] <zyga> ogra_: what names those serial ports? that's a specific kernel driver picking such name?
[12:50] <ogra_> zyga, the BSP kernel typically
[12:50] <ogra_> or the devicetree
[12:50] <niemeyer> ogra_: Closed, commented, let us know
[12:51] <zyga> ogra_: I believe it will largely fix itself with hotplug
[12:52] <ogra_> zyga,  point is ... vendors tend to make up new ttyXXX names when introducing a new board
[12:53] <ogra_> and customers using the image tend to waste hours and hours trying to find out why the serial interface they defined does not work at all ... there is no actual valid reason to have a whitelist there
[12:54] <zyga> ogra_: there are some reasons, it's not as clear cut as you claim IMO; still I think work on hot plug will change how we do this thing, it may be that for devices that are automatically detected we will trust the path
[12:54] <ogra_> (but i'm preaching that since we started adding this list in #2626 ... )
[12:54] <mup> PR #2626: interfaces: relax path requirements for serial <Created by jocave> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2626>
[12:54] <zyga> koza: hey
[12:54] <zyga> koza: looking at #4819, can you tell me what the various test changes are for
[12:54] <mup> PR #4819: interfaces/serial: change pattern not to exclude /dev/ttymxc* <Created by bergotorino> <https://github.com/snapcore/snapd/pull/4819>
[12:54] <zyga> koza: I was expecting just some new test chunk
[12:55] <mup> PR snapd#4672 closed: tests: adding test for removable-media interface <Go! Go! Go!> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4672>
[12:55] <zyga> koza: not alterations to existing tests
[12:55] <ogra_> zyga, FYI note that the customer is stuck working on their own features due to this since a week before the sprint ... (the devices are needed for some of their BT addo boards that everything else depends on)
[12:55] <ogra_> *addon
[12:56] <ogra_> zyga, it would be good if we didnt run into this again ... if hotplug helps with serial terminals etc then fine ... if we cant get it in time fore the next customer loosening the whitelist would be helpful though
[12:57] <zyga> ogra_: we cannot open it up to arbitrary tty string AFAIR but I understand what you are saying
[12:58] <ogra_> zyga, can you explain why we cannot open it up with a less strict regex ?
[12:59] <ogra_> (nobody explained the reason for this ever... which caused alex' question in that PR)
[12:59] <mborzecki> zyga: fwiw yocto keeps a list of 'known' tty names in the project tree https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-extended/shadow/files/securetty
[13:00] <zyga> mborzecki: that's pretty useful
[13:00] <mborzecki> probably covers most of what you'd see in the wild
[13:00] <ogra_> zyga, i understad that we do not want to open access to tty[0-n] here ... but everything else *is* a serial tty
[13:00] <zyga> ogra_: as chipaca there commented, /dev/tty, /dev/ttyN are off-limits
[13:00] <ogra_> yes
[13:01] <ogra_> so a regex that makes sure you have a letter there would suffice
[13:01] <zyga> oh
[13:01] <zyga> standup
[13:01] <mborzecki> zyga: gogogo
[13:02] <ogra_> zyga,  having to wait one full snapd release cycle fore every customer that has a new serial tty name is costly and not really practical ... and there seems to be n reason for that strictness
[13:02] <ogra_> *no
[13:03] <zyga> ogra_: I'll work on landing this PR and we can discuss with jdstrand if a more open regex is ok
[13:04] <ogra_> zyga, great (i talked to jdstrand in budapest and he said he would support opening it up)
[13:04] <zyga> ok
[13:04] <ogra_> (if you read the old PR he already supported it there ;) )
[13:06] <jdstrand> it's true. we shouldn't do it without niemeyer though since the current approach is based on his decision
[13:07] <ogra_> yes
[13:07] <jdstrand> note the other day I mentioned a middle ground: take ogra_'s list and expand the regex for everything we know about
[13:07] <jdstrand> if we had done that, the latest one would've already been allowed
[13:07] <ogra_> yep :)
[13:07] <jdstrand> so I suspect future boards will tend to just work if we do that
[13:08] <ogra_> unless a vedor adds a new name :)
[13:08] <jdstrand> hence 'tends' :)
[13:08] <ogra_> (which happens more frequent than one would think sadly :) )
[13:10] <ogra_> (i admittedly never understood that ... ttyS* used to be sufficient for like 15 years ... but apparently branding on a device node level became a thing at some point)
[13:11] <alexlarsson> jamesh: hey, did you see https://github.com/flatpak/xdg-desktop-portal/issues/167#issuecomment-376810447
[13:18] <koza> zyga, answered
[13:32] <kalikiana> re
[13:38] <koza> zyga: thanks and sorry for confusing ;-)
[13:38] <zyga> nah, ok
[13:38] <zyga> I'm just dumb today
[13:47] <pedronis> niemeyer:  btw the first PR of the chain is #4771,  the rename to SnapAction etc is there
[13:47] <mup> PR #4771: store: add Store.SnapAction to support the new install/refresh api endpoint <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4771>
[13:50] <pedronis> niemeyer: I scheduled something with Bret after your lunch break
[13:50] <niemeyer> pedronis: Thank you!
[14:10] <ondra> kyrofa is sergio around or on holidays?
[14:14] <kyrofa> ondra, sergio is on holidays for the rest of this week and next. Can I help?
[14:28] <om26er> popey: Hey! did you add me as a collaborator for sublime-text ?
[14:29] <popey> om26er: no. I don't think we should. The requirements for classic confinement prohibit it.
[14:29] <popey> om26er: sorry, been on and off the keyboard as I'm on holiday
[14:29] <popey> (currently getting my car tyres replaced) :)
[14:31] <om26er> alright ok. I had rights to android studio and sublime previously ;-)
[14:32]  * zyga break
[14:33] <ondra> kyrofa already chatted to ev https://bugs.launchpad.net/snapcraft/+bug/1759592
[14:33] <mup> Bug #1759592: kernel build fails for lack of modprobe <Snapcraft:New> <https://launchpad.net/bugs/1759592>
[14:33] <jdstrand> roadmr: two snaps have a weird runtime error: https://dashboard.snapcraft.io/snaps/tiled/revisions/61/ and https://dashboard.snapcraft.io/snaps/huggle/revisions/651/
[14:33] <roadmr> jdstrand: yes :(
[14:33] <jdstrand> roadmr: what is that about?
[14:33] <roadmr> jdstrand: we've been having wobbly/slow transfers (uploads/downloads) since yesterday.
[14:33] <jdstrand> ok
[14:33] <kyrofa> ondra, and that's a regression from 2.35, sounds like?
[14:33] <ondra> kyrofa just getting frustrated that yet another break for kernel snap build in LP. Close to give up on LP builds
[14:34] <jdstrand> roadmr: so retriggering the review should allow it to continue?
[14:34] <roadmr> jdstrand: what's happening is that, as the store server tries to pull the snap for review, it times out resulting in an incomplete transfer...
[14:34] <roadmr> jdstrand: that constitutes an invalid squashfs causing those errors you see.
[14:34] <ondra> kyrofa this is for deb, so before builds were failing because of wrong initrd location
[14:34]  * jdstrand nods
[14:34] <roadmr> jdstrand: sometimes, yes; if the retry manages to get a full download, it'll work. Worth a try.
[14:34] <roadmr> jdstrand: it'll all normalize once our storage goes back to full speed
[14:34] <roadmr> jdstrand: I'll try to get an ETA on that
[14:34] <jdstrand> roadmr: yep, cool. thanks!
[14:35] <ondra> kyrofa locally this is unlikely to fail, as usually you have modprobe installed
[14:35] <kyrofa> ondra, okay, we need to SRU another quick fix as well, so I'll get this fix in there as well, hang tight
[14:35] <jdstrand> roadmr: with the r1015, I wanted to not assume anything (not that those changes would cause this)
[14:35] <cachio> zyga, which info do you need for #4943
[14:35] <mup> PR #4943: tests: adding debian sid to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4943>
[14:35] <ondra> kyrofa may be add LP build as part of release test
[14:36] <roadmr> jdstrand: yes, makes sense, but I'm certain it's unrelated. We've been seeing this since before 1015 was rolled out
[14:36] <roadmr> jdstrand: (things broke yesterday morning, 1015 rolled out today wee hours)
[14:36] <jdstrand> roadmr: yep. not saying it was related, just wanted to touch base
[14:36] <roadmr> jdstrand: appreciated :) thanks
[14:36] <cachio> zyga, https://paste.ubuntu.com/p/B5QY2GDBkB/
[14:37] <cachio> zyga, I don't see errors on logs
[14:38] <kyrofa> cjwatson, if I set the "source archive" when requesting a snap build in LP to a PPA containing a newer snapcraft, will that use the newer snapcraft?
[14:39] <cachio> zyga, https://paste.ubuntu.com/p/kM7zMJtQHB/
[14:42] <popey> om26er: we should fix that :S
[14:44] <popey> om26er: sublime-text amd64 is in edge
[14:45] <cjwatson> kyrofa: Yes
[14:45] <popey> i need to put an icon in the store om26er
[14:45] <om26er> popey: yeah and a screenshot as well
[14:46] <cjwatson> ondra: One of the purposes of the work in progress to allow LP builds to consume snapcraft as a snap is to make it easier to do LP-build-based QA as part of release tests
[14:46] <cjwatson> Not immediately helpful to you, but it is definitely something we've discussed and have work in progress to improve
[14:46] <kaliy> hi. who could I ping to transfer ownership of a snap in the store?
[14:46] <popey> om26er: i have also closed the sublime-text-3 channels
[14:47] <popey> kaliy: nessita  is who usually processes mine, and requires an email to proove ownership
[14:47] <popey> -typos
[14:48] <zyga> I will be back soon
[14:49] <popey> om26er: tested locally, the snap works fine, subl alias works
[14:51] <popey> om26er: ok, added icon and a screenshot.
[14:51] <ondra> cjwatson yeah using snapcraft snap in LP build will be so much better and predictable
[14:51] <popey> om26er: want me to push to stable?
[14:52] <ondra> cjwatson and if we can specify channel to use, that would be dream :D
[14:55] <nessita> popey, hey there, can I help with anything?
[14:56] <popey> nessita: hi, kaliy was asking about snap re-ownership
[14:57] <nessita> kaliy, hey there. If you own the snap, we'll need an email sent from the same email address owning the snap, including the target owner, and getting some ack'd from the new owner
[14:57] <nessita> kaliy, with that I can proceed with the snap transfer
[15:01] <niemeyer> pedronis: #4771 LGTM with some additional suggestions
[15:01] <mup> PR #4771: store: add Store.SnapAction to support the new install/refresh api endpoint <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4771>
[15:02] <cjwatson> ondra: That's exactly what we're working on, yes
[15:03] <ondra> cjwatson yeah!
[15:08] <popey> om26er: i need to go afk in a bit, want me to publish this snap? :)
[15:33] <zyga> re
[15:43] <mup> PR snapd#4949 opened: tests: fix quoting issues in econnreset test <Created by zyga> <https://github.com/snapcore/snapd/pull/4949>
[16:02] <pedronis> niemeyer: meeting?
[16:02] <kaliy> nessita: ack! to which email should I send that?
[16:02] <niemeyer> There!
[16:02] <nessita> kaliy, pinging privately to give you the email
[16:45]  * kalikiana out
[17:04] <niemeyer> mborzecki: Where's the nvidia PR?
[17:04] <mborzecki> niemeyer: https://github.com/snapcore/snapd/pull/4908
[17:04] <mup> PR #4908: [RFC] cmd/snap-confine: attempt to detect if multiarch host uses arch triplets <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4908>
[17:34] <niemeyer> mborzecki: DO you have a moment for a call?
[17:34] <mborzecki> niemeyer: give me a sec
[17:35] <mborzecki> niemeyer: standup ho?
[17:35] <niemeyer> Okay.. I need to change clothes as well as it's getting unreasonably warm.. will be there in a minute
[18:05] <cachio> zyga, is it ok the change for #4943 ?
[18:05] <mup> PR #4943: tests: adding debian sid to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4943>
[18:06] <mup> PR snapd#4682 closed: tests: new spread test for physical-memory-control interface <Decaying> <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4682>
[18:10] <zyga> cachio:  I’m afk shopping for groceries
[18:10] <zyga> Looking now
[18:10] <cachio> hehe, it is ok
[18:13] <zyga> Nice
[18:13] <zyga> Thank you!
[18:18] <mup> PR snapd#4950 opened: test: move interfaces-removable-media to manual until issue on fedora is fixed <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4950>
[18:19] <cachio> pedronis, could you plase see this #4950
[18:19] <mup> PR #4950: test: move interfaces-removable-media to manual until issue on fedora is fixed <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4950>
[18:19] <cachio> we have the master broken for this issue
[18:19] <cachio> pedronis, I am working in a solution be I moved that to manual to unblock other PRs
[18:22] <pedronis> cachio: if it takes a while we should probably switch not to manual but have an if at the beginning of the sections
[18:23] <pedronis> I mean take a while to fix
[18:27] <cachio> pedronis, you mean to skip just that part?
[18:27] <cachio> for fedora
[18:27] <pedronis> yes
[18:27] <pedronis> mmh
[18:28] <cachio> not sure how long it will take as the snap is failing
[18:28] <cachio> it is not seem to be a test issue
[18:28] <cachio> I can do that change
[18:28] <pedronis> cachio: sorry, now that I think of it
[18:29] <pedronis> should we use the systems filter?
[18:29] <cachio> yes
[18:29] <pedronis> systems: [-fedora-*]  or something like that?
[18:31] <cachio> updated
[18:34] <pedronis> thanks
[18:36] <cachio> pedronis, thanks to you for reviewing
[18:37] <mup> PR snapcraft#2041 opened: kernel plugin: add kmod as build-package <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2041>
[18:57] <Caelum> zyga: I update my second PR and now I'm looking at your notes on the package
[19:10] <mup> PR snapd#4950 closed: test: move interfaces-removable-media to manual until issue on fedora is fixed <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4950>
[19:18] <niemeyer> Taking a break for exercising.. back for a meeting at the top of the hour
[19:18] <niemeyer> o/
[19:33] <jdstrand> zyga: hi! fyi, on 16.04 system with up to date master:
[19:33] <jdstrand> $ ./run-checks --static
[19:33] <jdstrand> ...
[19:33] <jdstrand> Running vet
[19:33] <jdstrand> interfaces/apparmor/spec.go:129: arg l for printf verb %s of wrong type: *github.com/snapcore/snapd/snap.Layout
[19:33] <jdstrand> exit status 1
[20:19] <zyga> jdstrand: oh, looking
[20:19] <zyga> looks like a bug in vet
[20:19] <zyga> does this fix it for you?
[20:19] <zyga> https://www.irccloud.com/pastebin/90wGfR4u/
[20:32] <cachio> niemeyer, #4943 ready
[20:32] <mup> PR #4943: tests: adding debian sid to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4943>
[20:37] <kyrofa> zyga, are snaps confined on Debian?
[20:41] <mup> PR snapd#4951 opened: interfaces/desktop-legacy: allow access to gnome-shell screenshot/screencast <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4951>
[20:42] <mup> PR snapd#4896 closed: store: support macaroon refreshes in store.SnapAction <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4896>
[20:43] <mup> PR snapd#4771 closed: store: add Store.SnapAction to support the new install/refresh api endpoint <Critical> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/4771>
[20:57] <mup> PR snapd#4772 closed: tests/lib/fakestore/store:  teach the fake store to fake the new install/refresh endpoint <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/4772>
[21:02] <niemeyer> cachio: \o/
[21:03] <mup> PR snapd#4943 closed: tests: adding debian sid to google backend <Created by sergiocazzolato> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4943>
[21:05] <cachio> niemeyer, just fedora remains in linode
[21:07] <cachio> niemeyer, I could disable selinux for the google image and it should work, while we can work on fix the issues around it
[21:07] <cachio> niemeyer, so we have all the machines in google
[21:13] <niemeyer> cachio: How is it working in Linode
[21:13] <niemeyer> ?
[21:13] <cachio> selinux disabled
[21:14] <niemeyer> cachio: So disabling in Google sounds fine
[21:14] <cachio> niemeyer, it is gonna be temporal
[21:15] <cachio> I'll make the change in that case
[21:15] <niemeyer> cachio: Yeah, we can work on this spearately
[21:15] <niemeyer> separately
[21:15] <niemeyer> cachio: If Linode doesn't have it we won't lose anything and can migrate and work on that later
[21:16] <cachio> niemeyer, yes, that's the idea
[21:16] <cachio> otherwise we will never end with the movement
[21:16] <niemeyer> Yep
[21:42]  * cachio afk
[23:07] <Caelum> this go stuff is weird, I can't even figure out how to build anything out of a git clone