[00:02] 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] 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] sergiusens: urgh ... unsquashfs failures? https://jenkins.ubuntu.com/server/job/git-ubuntu-ci/350/console [00:04] i just had two of the four fail that way [00:05] sergiusens: but the other two got past that point, it seems [00:05] 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] sergiusens: oh ok, retry should work? [00:06] sergiusens: or is there a better ... solution? [00:06] nacc: I am not in the store team, but a retry could work, yes [00:06] sergiusens: thanks! [00:06] we'll see what it does :) [00:07] nacc: btw, why aren't you using launchpad buildd and such? [00:37] I can understand people not doing so for per-commit CI [00:38] Though I hope we'll support that kind of thing at some point [00:43] sergiusens: what cjwatson said [00:44] sergiusens: in any case, some jobs are showing the link error for libgpg-error still [00:44] but not all [00:44] sergiusens: which feels like a worse place to be than we were [00:44] i'll start debugging in the AM [01:28] PR snapcraft#2039 closed: Release changelog for 2.40.1 [02:34] PR snapcraft#2040 opened: lifecycle: always prime dependencies [05:19] morning [05:20] something wrong with the store? the download seems to be capped at 50-60kBps === chihchun_afk is now known as chihchun [05:57] good morning [05:57] * zyga goes to wake the kids [05:57] mborzecki: yes, store is affected by ceph issue [05:58] ceph has fallen apart/ [05:58] ? === chihchun is now known as chihchun_afk [06:18] mborzecki: not sure what happened really [06:18] it's online but very slow apparently [06:19] * zyga is almost done with the kids [06:24] not if only kids made me breakfast in return :) [06:41] 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] PR #4931: configcore: give a chance to immediately recompute the next refresh time when schedules are set [06:43] pstolowski|afk: I'll play with #4946 [06:43] PR #4946: ifacestate: don't surface stale connections === pstolowski|afk is now known as pstolowski [07:03] morning [07:04] moin moin [07:04] o/ pstolowski [07:05] hey kalikiana === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [07:19] zyga: yes, it needs to be done differently to be correct [07:19] pedronis: thanks for confirming that [07:20] that's why I marked it blocked [07:34] PR snapd#4920 closed: timeutil: in Human, count days with fingers [07:36] pstolowski: hey, I pushed to https://github.com/snapcore/snapd/pull/4946/files [07:36] PR #4946: ifacestate: don't surface stale connections [07:36] can you please have a look [07:38] zyga: thanks, looking [07:44] zyga: looks good, thanks for extra test [07:54] 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] pstolowski: can you walk me through an example please [08:00] (sorry for the lag, my daughter is just leaving for school now) [08:06] 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] zyga: and nb, i wonder if remove hook shouldn't be called earlier in the sequnce, it's probably run too late [08:07] pstolowski: when remove hook fails, what happens then? [08:08] zyga: ah, ignore remove-hook failure, no problem there, we set ignoreError:true on it [08:09] zyga: so yeah, the only problem is if any other task fails and discard-conns is not reached [08:10] I need to run to the dentist, bbl === pstolowski is now known as pstolowski|denti [08:10] pstolowski: sure [08:10] pstolowski|denti: when you are back, do we undo stuff when any of those fail? [08:10] zyga: no, we don't have undo on snap removal, afair it's very hard to undo those [08:11] (something we discussed on different occasion with pedronis afair) === pstolowski|denti is now known as pstolowski|bbl [08:15] PR snapcraft#2013 closed: tests: run tests on Trusty on Travis [08:16] zyga, mborzecki: #4931 is updated [08:16] PR #4931: configcore: give a chance to immediately recompute the next refresh time when schedules are set [08:17] lookinbg [08:17] zyga: the change is simple, testing it a bit less so [08:18] PR snapcraft#1800 closed: grammar: on..to statement [08:18] PR snapcraft#1900 closed: many: handle copying of symlink permissions gracefully [08:38] zyga: do you know what the plan for nvidia is? [08:38] mborzecki: review your branch with gustavo [08:38] mborzecki: and I think we'll do 2.32.2 with this [08:40] zyga: oh ok [08:45] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1648681.html [09:08] not a happy store day [09:09] zyga: we're just helping you improve your error handling ;) [09:19] sparkiegeek: oh yes, we need to get creative on the word "http" :-) [09:19] * zyga hugs sparkiegeek [09:19] it's good that we have plenty of reviews to make :) [09:24] 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] om26er: someone else has registered it, back in 2016 [09:26] but never uploaded anything [09:26] I'll ping them a mail to let them know we'd like to take it over [09:27] popey: yeah, that would make sense [09:27] 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] pedronis: I reviewed #4931 [09:28] PR #4931: configstate: give a chance to immediately recompute the next refresh time when schedules are set [09:29] om26er: mail sent [09:29] lets give it a few days for them to respond [09:29] om26er: perfect! [09:30] om26er: I use the deb still but I use sublime everywehre so I'm super happy to switch [09:30] 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] aha, so you are our first user ;-) [09:31] well crap, their email bounces [09:31] zyga: I also contacted upstream, so you got anything to add there: https://forum.sublimetext.com/t/modern-instalation-snap-package/31123 [09:31] is wbond the upstream? [09:31] zyga: yes [09:32] popey: bummer, wonder what's next for us. [09:32] PR snapd#4921 closed: skip test if no user "daemon" in build jail [09:32] I'm going to take it. [09:32] if you registered a snap over a year ago, never uploaded anything and deleted your email address... [09:33] pedronis: can you please look at https://github.com/snapcore/snapd/pull/4911 [09:33] PR #4911: daemon,client: add build-id to /v2/system-info [09:33] I'm inclined to merge it but I wanted to double check [09:34] do we still know if we need it? [09:34] I don't think we need it but it's actually very useful for other reasons [09:34] snap version is how we ask people to report bugs and give us initial hints [09:35] om26er: done, snapcrafters has sublime-text now [09:35] popey: do we need to ask for 'classic' confinement again ? [09:36] also what about remove the name sublime-text-3 completely, is that possible ? [09:36] Yes, I would recommend asking for both the alias and classic confinement in one post [09:36] we can just unpublish the sublime-text-3 so nobody can see it [09:38] popey: we already have a alias request in forum.snapcraft.io, so only created a new request for classic confinement [09:38] Awesome [09:38] Nice work om26er :) === pstolowski|bbl is now known as pstolowski [09:39] back [09:44] popey: have you also enabled auto builds for that new name ? [09:44] not yet. [09:45] hmm, I think for classic confinement request to proceed we would need to have something in the build queue. [09:46] ...same goes for alias request [09:46] one moment, I have to remve s-t3 first [09:46] https://usercontent.irccloud-cdn.com/file/JzviDh1g/ [09:46] ^ [09:47] 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] pedronis: ack, thank you and enjoy your lunch :) [09:49] https://usercontent.irccloud-cdn.com/file/fNwd5Kq9/ [09:49] ^ om26er [09:50] was there a CI wobble? https://github.com/snapcore/snapd/pull/4932 [09:50] PR #4932: interfaces/content: add rule so slot can access writable files at plug's mountpoint [09:50] log complaining of odd things [09:50] zyga: pushed updates to #4942 [09:50] PR #4942: cmd/snap: user session application autostart v3 [09:50] om26er: all done from here? [09:51] mborzecki: yay, thanks for that, I'm looking forward to using it [09:51] popey: seems so, yes [09:51] awesome [09:51] o/ thanks again! [09:52] popey: add me as a collaborator ? [09:55] om26er: can you please ping me once the snap is published [09:55] zyga: sure, will do. [10:01] PR snapd#4947 opened: spread: disable StartLimitInterval option on opensuse-42.3 [10:01] 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] zyga: the build failed because it requires classic confinement, that I believe will be granted by jdstrand (and also the alias). [10:05] om26er: did it fail or just got flagged on upload? [10:05] zyga: the latter. [10:25] * zyga reviews 4772 [10:25] that's a biggie [10:25] I'm reading and scrolling and scrolling [10:25] and thinking, gee, how long is this [10:25] then noticed the header :) [10:42] E: Unable to locate package linux-image-extra-4.15.0-12-generic on ubuntu 18.04 in spread [10:54] pstolowski: missing update perhaps? [10:55] or archive not fully sync? i've restarted the test, let's see if it persists [10:55] nowadays archive cannot be partially synced [11:27] zyga: I have a nitpick about #4911 [11:27] PR #4911: daemon,client: add build-id to /v2/system-info [11:28] pedronis: I'll tweak tha [11:28] that [11:30] pedronis: done [11:45] pedronis: review on the big store PR [11:46] * zyga breaks for 15 minutes [11:59] * zyga debugs current 18.04 issue [12:01] off to pick up my daughter from school, bb for standup [12:07] hmm [12:07] I know what's wrong now [12:07] cachio: ping [12:07] zyga, hey [12:08] cachio: two questions [12:08] what is our kernel in google ubuntu bionic image? [12:08] 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] PR #13: Bugfix/review tools reenable [12:08] which is very odd [12:08] second [12:08] we need to regenerate that image [12:08] and get a more recent kernel [12:08] because modules for this kernel are no longer in the package [12:08] this must be done ASAP or we must disable bionic tests [12:09] we fail because essentially this happens: [12:09] google:ubuntu-18.04-64 ...# apt-cache policy linux-image-extra-4.15.0-12-generic [12:09] N: Unable to locate package linux-image-extra-4.15.0-12-generic [12:09] N: Couldn't find any package by glob 'linux-image-extra-4.15.0-12-generic' [12:09] N: Couldn't find any package by regex 'linux-image-extra-4.15.0-12-generic' [12:09] zyga, the ubuntu bionic image is not generated by us [12:09] zyga, let me try with the last image [12:09] cachio: ah, I see [12:09] yeah, let's try today's image [12:10] yes [12:10] if this works I'll send the PR [12:11] PR snapd#4721 closed: tests: update interface tests to remove extra checks and normalize tests [12:12] cachio: have a look at 4948 [12:12] PR snapd#4948 opened: spread: use more recent bionic snapshot [12:14] zyga, aoorived [12:14] zyga, just wait to see the test results [12:14] thanks, let's see if something blows up along the way [12:14] I'm running it locally here and it's past the point where it broke earlier [12:15] zyga, this images are being updated every day with latest changes [12:15] yeah, it's something w may have to repeat until release [12:15] previously I made to detect automatically the last one and use it [12:15] after release I assume our image will be an alias to the latest stable bionic image [12:15] but we had problems too [12:15] yes [12:31] zyga: I upadted #4931 , let me know if it's clearer [12:31] PR #4931: configstate: give a chance to immediately recompute the next refresh time when schedules are set [12:31] thanks, looking [12:39] PR snapd#4877 closed: snap-confine: fallback to /lib/udev/snappy-app-dev if the core is older [12:39] * kalikiana lunch [12:42] * zyga considers closing https://github.com/snapcore/snapd/pull/4349 [12:42] PR #4349: Make snapd.autoimport configurable [12:42] we have plenty of PRs and this one doesn't seem to move now [12:42] ogra_: ^ [12:42] zyga, what should move there ? [12:43] ogra_: the PR got NACKed, is there ongoing discussion or other reason to keep it open? [12:43] note that we can always reopen things [12:43] zyga, it ends with a question from alex to gustavo that got never answered [12:43] we're just struggling with the number of open PRs [12:43] zyga, we need this feature for a customer ... [12:43] one way or the other [12:43] What's the PR? [12:44] my suggestion was turned down, a question was asked what a better approach would be and that is where it stands now [12:44] niemeyer: #4349 [12:44] PR #4349: Make snapd.autoimport configurable [12:44] PR snapd#4948 closed: spread: use more recent bionic snapshot [12:45] thanks Sergio! [12:45] we need to merge master into most important PRs that are ready to land now [12:46] zyga, niemeyer, the way more important one is #4819 though ... thats slowly getting urgent [12:46] PR #4819: interfaces/serial: change pattern not to exclude /dev/ttymxc* [12:46] cachio: I made a back port of the google update for 3.32 but it seems we are still using linode there [12:46] (i think koza adjusted it properly to be mergeable) [12:46] ogra_: I'll look now [12:46] ... that one also has an open alex question :) [12:48] that one looks mergeable now, with the updates given it adds one specific new pattern and corresponding tests [12:48] hmm [12:48] * zyga needs to read the tests in detail though [12:48] PR snapd#4349 closed: Make snapd.autoimport configurable [12:48] right, but we need to do something about the fact that it will bite us again with the next customer [12:49] so long term a more graceful regex is needed [12:49] (manufacturers tend to invent their own tty names for serial ports ... thats not uncommon) [12:49] ogra_: what names those serial ports? that's a specific kernel driver picking such name? [12:50] zyga, the BSP kernel typically [12:50] or the devicetree [12:50] ogra_: Closed, commented, let us know [12:51] ogra_: I believe it will largely fix itself with hotplug [12:52] zyga, point is ... vendors tend to make up new ttyXXX names when introducing a new board [12:53] 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] 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] (but i'm preaching that since we started adding this list in #2626 ... ) [12:54] PR #2626: interfaces: relax path requirements for serial [12:54] koza: hey [12:54] koza: looking at #4819, can you tell me what the various test changes are for [12:54] PR #4819: interfaces/serial: change pattern not to exclude /dev/ttymxc* [12:54] koza: I was expecting just some new test chunk [12:55] PR snapd#4672 closed: tests: adding test for removable-media interface [12:55] koza: not alterations to existing tests [12:55] 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] *addon [12:56] 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] ogra_: we cannot open it up to arbitrary tty string AFAIR but I understand what you are saying [12:58] zyga, can you explain why we cannot open it up with a less strict regex ? [12:59] (nobody explained the reason for this ever... which caused alex' question in that PR) [12:59] 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] mborzecki: that's pretty useful [13:00] probably covers most of what you'd see in the wild [13:00] 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] ogra_: as chipaca there commented, /dev/tty, /dev/ttyN are off-limits [13:00] yes [13:01] so a regex that makes sure you have a letter there would suffice [13:01] oh [13:01] standup [13:01] zyga: gogogo [13:02] 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] *no [13:03] ogra_: I'll work on landing this PR and we can discuss with jdstrand if a more open regex is ok [13:04] zyga, great (i talked to jdstrand in budapest and he said he would support opening it up) [13:04] ok [13:04] (if you read the old PR he already supported it there ;) ) [13:06] it's true. we shouldn't do it without niemeyer though since the current approach is based on his decision [13:07] yes [13:07] note the other day I mentioned a middle ground: take ogra_'s list and expand the regex for everything we know about [13:07] if we had done that, the latest one would've already been allowed [13:07] yep :) [13:07] so I suspect future boards will tend to just work if we do that [13:08] unless a vedor adds a new name :) [13:08] hence 'tends' :) [13:08] (which happens more frequent than one would think sadly :) ) [13:10] (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] jamesh: hey, did you see https://github.com/flatpak/xdg-desktop-portal/issues/167#issuecomment-376810447 [13:18] zyga, answered [13:32] re [13:38] zyga: thanks and sorry for confusing ;-) [13:38] nah, ok [13:38] I'm just dumb today [13:47] niemeyer: btw the first PR of the chain is #4771, the rename to SnapAction etc is there [13:47] PR #4771: store: add Store.SnapAction to support the new install/refresh api endpoint [13:50] niemeyer: I scheduled something with Bret after your lunch break [13:50] pedronis: Thank you! [14:10] kyrofa is sergio around or on holidays? [14:14] ondra, sergio is on holidays for the rest of this week and next. Can I help? === nsg_ is now known as nsg [14:28] popey: Hey! did you add me as a collaborator for sublime-text ? [14:29] om26er: no. I don't think we should. The requirements for classic confinement prohibit it. [14:29] om26er: sorry, been on and off the keyboard as I'm on holiday [14:29] (currently getting my car tyres replaced) :) [14:31] alright ok. I had rights to android studio and sublime previously ;-) [14:32] * zyga break [14:33] kyrofa already chatted to ev https://bugs.launchpad.net/snapcraft/+bug/1759592 [14:33] Bug #1759592: kernel build fails for lack of modprobe [14:33] 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] jdstrand: yes :( [14:33] roadmr: what is that about? [14:33] jdstrand: we've been having wobbly/slow transfers (uploads/downloads) since yesterday. [14:33] ok [14:33] ondra, and that's a regression from 2.35, sounds like? [14:33] kyrofa just getting frustrated that yet another break for kernel snap build in LP. Close to give up on LP builds [14:34] roadmr: so retriggering the review should allow it to continue? [14:34] 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] jdstrand: that constitutes an invalid squashfs causing those errors you see. [14:34] kyrofa this is for deb, so before builds were failing because of wrong initrd location [14:34] * jdstrand nods [14:34] jdstrand: sometimes, yes; if the retry manages to get a full download, it'll work. Worth a try. [14:34] jdstrand: it'll all normalize once our storage goes back to full speed [14:34]