/srv/irclogs.ubuntu.com/2018/03/28/#snappy.txt

sergiusensnacc: if you are seeing failures to upload; this has been going on all day (not related to 2.40) and something snapstore related00:02
naccsergiusens: 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 happens00:03
naccsergiusens: urgh ... unsquashfs failures? https://jenkins.ubuntu.com/server/job/git-ubuntu-ci/350/console00:04
nacci just had two of the four fail that way00:04
naccsergiusens: but the other two got past that point, it seems00:05
sergiusensnacc: that is a corrupted download of the core snap; this is part of the general store slow down we are all waiting to get fixed00:05
naccsergiusens: oh ok, retry should work?00:05
naccsergiusens: or is there a better ... solution?00:06
sergiusensnacc: I am not in the store team, but a retry could work, yes00:06
naccsergiusens: thanks!00:06
naccwe'll see what it does :)00:06
sergiusensnacc: btw, why aren't you using launchpad buildd and such?00:07
cjwatsonI can understand people not doing so for per-commit CI00:37
cjwatsonThough I hope we'll support that kind of thing at some point00:38
naccsergiusens: what cjwatson said00:43
naccsergiusens: in any case, some jobs are showing the link error for libgpg-error still00:44
naccbut not all00:44
naccsergiusens: which feels like a worse place to be than we were00:44
nacci'll start debugging in the AM00:44
mupPR snapcraft#2039 closed: Release changelog for 2.40.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2039>01:28
mupPR snapcraft#2040 opened: lifecycle: always prime dependencies <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2040>02:34
mborzeckimorning05:19
mborzeckisomething wrong with the store? the download seems to be capped at 50-60kBps05:20
=== chihchun_afk is now known as chihchun
zygagood morning05:57
* zyga goes to wake the kids05:57
zygamborzecki: yes, store is affected by ceph issue05:57
mborzeckiceph has fallen apart/05:58
mborzecki?05:58
=== chihchun is now known as chihchun_afk
zygamborzecki: not sure what happened really06:18
zygait's online but very slow apparently06:18
* zyga is almost done with the kids06:19
zyganot if only kids made me breakfast in return :)06:24
zygagood 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 area06:41
mupPR #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:41
zygapstolowski|afk: I'll play with #494606:43
mupPR #4946: ifacestate: don't surface stale connections <Created by stolowski> <https://github.com/snapcore/snapd/pull/4946>06:43
=== pstolowski|afk is now known as pstolowski
pstolowskimorning07:03
kalikianamoin moin07:04
kalikianao/ pstolowski07:04
pstolowskihey kalikiana07:05
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
pedroniszyga: yes, it needs to be done differently to be correct07:19
zygapedronis: thanks for confirming that07:19
pedronisthat's why I marked it blocked07:20
mupPR snapd#4920 closed: timeutil: in Human, count days with fingers <Created by chipaca> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4920>07:34
zygapstolowski: hey, I pushed to https://github.com/snapcore/snapd/pull/4946/files07:36
mupPR #4946: ifacestate: don't surface stale connections <Created by stolowski> <https://github.com/snapcore/snapd/pull/4946>07:36
zygacan you please have a look07:36
pstolowskizyga: thanks, looking07:38
pstolowskizyga: looks good, thanks for extra test07:44
pstolowskizyga: 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?)07:54
zygapstolowski: can you walk me through an example please08:00
zyga(sorry for the lag, my daughter is just leaving for school now)08:00
pstolowskizyga: 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 think08:06
pstolowskizyga: and nb, i wonder if remove hook shouldn't be called earlier in the sequnce, it's probably run too late08:07
zygapstolowski: when remove hook fails, what happens then?08:07
pstolowskizyga: ah, ignore remove-hook failure, no problem there, we set ignoreError:true on it08:08
pstolowskizyga: so yeah, the only problem is if any other task fails and discard-conns is not reached08:09
pstolowskiI need to run to the dentist, bbl08:10
=== pstolowski is now known as pstolowski|denti
zygapstolowski: sure08:10
zygapstolowski|denti: when you are back, do we undo stuff when any of those fail?08:10
pstolowski|dentizyga: no, we don't have undo on snap removal, afair it's very hard to undo those08:10
pstolowski|denti(something we discussed on different occasion with pedronis afair)08:11
=== pstolowski|denti is now known as pstolowski|bbl
mupPR snapcraft#2013 closed: tests: run tests on Trusty on Travis <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/2013>08:15
pedroniszyga, mborzecki: #4931 is updated08:16
mupPR #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:16
zygalookinbg08:17
pedroniszyga: the change is simple, testing it a bit less so08:17
mupPR snapcraft#1800 closed: grammar: on..to statement <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1800>08:18
mupPR snapcraft#1900 closed: many: handle copying of symlink permissions gracefully <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1900>08:18
mborzeckizyga: do you know what the plan for nvidia is?08:38
zygamborzecki: review your branch with gustavo08:38
zygamborzecki: and I think we'll do 2.32.2 with this08:38
mborzeckizyga: oh ok08:40
zygahttps://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1648681.html08:45
zyganot a happy store day09:08
sparkiegeekzyga: we're just helping you improve your error handling ;)09:09
zygasparkiegeek: oh yes, we need to get creative on the word "http" :-)09:19
* zyga hugs sparkiegeek 09:19
zygait's good that we have plenty of reviews to make :)09:19
om26erpopey: kindly register the name 'sublime-text' under snapcrafters as I don't have the permissions to do so.09:24
* zyga would love to see sublime-text with subl alias 09:25
popeyom26er: someone else has registered it, back in 201609:26
popeybut never uploaded anything09:26
popeyI'll ping them a mail to let them know we'd like to take it over09:26
om26erpopey: yeah, that would make sense09:27
om26erzyga: 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:27
zygapedronis: I reviewed #493109:28
mupPR #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:28
popeyom26er: mail sent09:29
popeylets give it a few days for them to respond09:29
zygaom26er: perfect!09:29
zygaom26er: I use the deb still but I  use sublime everywehre so I'm super happy to switch09:30
zygait 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
om26eraha, so you are our first user ;-)09:30
popeywell crap, their email bounces09:31
om26erzyga: I also contacted upstream, so you got anything to add there: https://forum.sublimetext.com/t/modern-instalation-snap-package/3112309:31
zygais wbond the upstream?09:31
om26erzyga: yes09:31
om26erpopey: bummer, wonder what's next for us.09:32
mupPR 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
popeyI'm going to take it.09:32
popeyif you registered a snap over a year ago, never uploaded anything and deleted your email address...09:32
zygapedronis: can you please look at https://github.com/snapcore/snapd/pull/491109:33
mupPR #4911: daemon,client: add build-id to /v2/system-info <Created by mvo5> <https://github.com/snapcore/snapd/pull/4911>09:33
zygaI'm inclined to merge it but I wanted to double check09:33
pedronisdo we still know if we need it?09:34
zygaI don't think we need it but it's actually very useful for other reasons09:34
zygasnap version is how we ask people to report bugs and give us initial hints09:34
popeyom26er: done, snapcrafters has sublime-text now09:35
om26erpopey: do we need to ask for 'classic' confinement again ?09:35
om26eralso what about remove the name sublime-text-3 completely, is that possible ?09:36
popeyYes, I would recommend asking for both the alias and classic confinement in one post09:36
popeywe can just unpublish the sublime-text-3 so nobody can see it09:36
om26erpopey: we already have a alias request in forum.snapcraft.io, so only created a new request for classic confinement09:38
popeyAwesome09:38
popeyNice work om26er :)09:38
=== pstolowski|bbl is now known as pstolowski
pstolowskiback09:39
om26erpopey: have you also enabled auto builds for that new name ?09:44
popeynot yet.09:44
om26erhmm, I think for classic confinement request to proceed we would need to have something in the build queue.09:45
om26er...same goes for alias request09:46
popeyone moment, I have to remve s-t3 first09:46
popeyhttps://usercontent.irccloud-cdn.com/file/JzviDh1g/09:46
popey^09:46
pedroniszyga: I will re-look in a bit,  I'm in a twisty maze of conflicts and also it getting close to lunch09:47
zygapedronis: ack, thank you and enjoy your lunch :)09:47
popeyhttps://usercontent.irccloud-cdn.com/file/fNwd5Kq9/09:49
popey^ om26er09:49
greybackwas there a CI wobble? https://github.com/snapcore/snapd/pull/493209:50
mupPR #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
greybacklog complaining of odd things09:50
mborzeckizyga: pushed updates to #494209:50
mupPR #4942: cmd/snap: user session application autostart v3 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4942>09:50
popeyom26er: all done from here?09:50
greybackmborzecki: yay, thanks for that, I'm looking forward to using it09:51
om26erpopey: seems so, yes09:51
popeyawesome09:51
popeyo/ thanks again!09:51
om26erpopey: add me as a collaborator ?09:52
zygaom26er: can you please ping me once the snap is published09:55
om26erzyga: sure, will do.09:55
mupPR snapd#4947 opened: spread: disable StartLimitInterval option on opensuse-42.3 <Created by stolowski> <https://github.com/snapcore/snapd/pull/4947>10:01
om26erpopey: 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:01
om26erzyga: the build failed because it requires classic confinement, that I believe will be granted by jdstrand (and also the alias).10:03
zygaom26er: did it fail or just got flagged on upload?10:05
om26erzyga: the latter.10:05
* zyga reviews 477210:25
zygathat's a biggie10:25
zygaI'm reading and scrolling and scrolling10:25
zygaand thinking, gee, how long is this10:25
zygathen noticed the header :)10:25
pstolowskiE: Unable to locate package linux-image-extra-4.15.0-12-generic on ubuntu 18.04 in spread10:42
zygapstolowski: missing update perhaps?10:54
pstolowskior archive not fully sync? i've restarted the test, let's see if it persists10:55
zyganowadays archive cannot be partially synced10:55
pedroniszyga:  I have a nitpick about #491111:27
mupPR #4911: daemon,client: add build-id to /v2/system-info <Created by mvo5> <https://github.com/snapcore/snapd/pull/4911>11:27
zygapedronis: I'll tweak tha11:28
zygathat11:28
zygapedronis: done11:30
zygapedronis: review on the big store PR11:45
* zyga breaks for 15 minutes11:46
* zyga debugs current 18.04 issue11:59
mborzeckioff to pick up my daughter from school, bb for standup12:01
zygahmm12:07
zygaI know what's wrong now12:07
zygacachio: ping12:07
cachiozyga, hey12:07
zygacachio: two questions12:08
zygawhat is our kernel in google ubuntu bionic image?12:08
zygaI 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/Linux12:08
mupPR #13: Bugfix/review tools reenable <Created by mvo5> <Merged by elopio> <https://github.com/snapcore/snapd/pull/13>12:08
zygawhich is very odd12:08
zygasecond12:08
zygawe need to regenerate that image12:08
zygaand get a more recent kernel12:08
zygabecause modules for this kernel are no longer in the package12:08
zygathis must be done ASAP or we must disable bionic tests12:08
zygawe fail because essentially this happens:12:09
zygagoogle:ubuntu-18.04-64 ...# apt-cache policy linux-image-extra-4.15.0-12-generic12:09
zygaN: Unable to locate package linux-image-extra-4.15.0-12-generic12:09
zygaN: Couldn't find any package by glob 'linux-image-extra-4.15.0-12-generic'12:09
zygaN: Couldn't find any package by regex 'linux-image-extra-4.15.0-12-generic'12:09
cachiozyga, the ubuntu bionic image is not generated by us12:09
cachiozyga, let me try with the last image12:09
zygacachio: ah, I see12:09
zygayeah, let's try today's image12:09
cachioyes12:10
zygaif this works I'll send the PR12:10
mupPR 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:11
zygacachio: have a look at 494812:12
mupPR snapd#4948 opened: spread: use more recent bionic snapshot <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4948>12:12
cachiozyga, aoorived12:14
cachiozyga, just wait to see the test results12:14
zygathanks, let's see if something blows up along the way12:14
zygaI'm running it locally here and it's past the point where it broke earlier12:14
cachiozyga, this images are being updated every day with latest changes12:15
zygayeah, it's something w may have to repeat until release12:15
cachiopreviously I made to detect automatically the last one and use it12:15
zygaafter release I assume our image will be an alias to the latest stable bionic image12:15
cachiobut we had problems too12:15
cachioyes12:15
pedroniszyga: I upadted #4931 , let me know if it's clearer12:31
mupPR #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
zygathanks, looking12:31
mupPR 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 lunch12:39
* zyga considers closing https://github.com/snapcore/snapd/pull/434912:42
mupPR #4349: Make snapd.autoimport configurable <Blocked> <Decaying> <Created by ogra1> <https://github.com/snapcore/snapd/pull/4349>12:42
zygawe have plenty of PRs and this one doesn't seem to move now12:42
zygaogra_: ^12:42
ogra_zyga, what should move there ?12:42
zygaogra_: the PR got NACKed, is there ongoing discussion or other reason to keep it open?12:43
zyganote that we can always reopen things12:43
ogra_zyga, it ends with a question from alex to gustavo that got never answered12:43
zygawe're just struggling with the number of open PRs12:43
ogra_zyga,  we need this feature for a customer ...12:43
ogra_one way or the other12:43
niemeyerWhat's the PR?12:43
ogra_my suggestion was turned down, a question was asked what a better approach would be and that is where it stands now12:44
zyganiemeyer: #434912:44
mupPR #4349: Make snapd.autoimport configurable <Blocked> <Decaying> <Created by ogra1> <https://github.com/snapcore/snapd/pull/4349>12:44
mupPR snapd#4948 closed: spread: use more recent bionic snapshot <Critical> <Created by zyga> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4948>12:44
zygathanks Sergio!12:45
zygawe need to merge master into most important PRs that are ready to land now12:45
ogra_zyga, niemeyer, the way more important one is #4819 though ... thats slowly getting urgent12:46
mupPR #4819: interfaces/serial: change pattern not to exclude /dev/ttymxc* <Created by bergotorino> <https://github.com/snapcore/snapd/pull/4819>12:46
zygacachio: I made a back port of the google update for 3.32 but it seems we are still using linode there12:46
ogra_(i think koza adjusted it properly to be mergeable)12:46
zygaogra_: I'll look now12:46
ogra_... that one also has an open alex question :)12:46
zygathat one looks mergeable now, with the updates given it adds one specific new pattern and corresponding tests12:48
zygahmm12:48
* zyga needs to read the tests in detail though12:48
mupPR 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 customer12:48
ogra_so long term a more graceful regex is needed12:49
ogra_(manufacturers tend to invent their own tty names for serial ports ... thats not uncommon)12:49
zygaogra_: what names those serial ports? that's a specific kernel driver picking such name?12:49
ogra_zyga, the BSP kernel typically12:50
ogra_or the devicetree12:50
niemeyerogra_: Closed, commented, let us know12:50
zygaogra_: I believe it will largely fix itself with hotplug12:51
ogra_zyga,  point is ... vendors tend to make up new ttyXXX names when introducing a new board12:52
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 there12:53
zygaogra_: 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 path12:54
ogra_(but i'm preaching that since we started adding this list in #2626 ... )12:54
mupPR #2626: interfaces: relax path requirements for serial <Created by jocave> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2626>12:54
zygakoza: hey12:54
zygakoza: looking at #4819, can you tell me what the various test changes are for12:54
mupPR #4819: interfaces/serial: change pattern not to exclude /dev/ttymxc* <Created by bergotorino> <https://github.com/snapcore/snapd/pull/4819>12:54
zygakoza: I was expecting just some new test chunk12:54
mupPR 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
zygakoza: not alterations to existing tests12: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_*addon12:55
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 though12:56
zygaogra_: we cannot open it up to arbitrary tty string AFAIR but I understand what you are saying12:57
ogra_zyga, can you explain why we cannot open it up with a less strict regex ?12:58
ogra_(nobody explained the reason for this ever... which caused alex' question in that PR)12:59
mborzeckizyga: 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/securetty12:59
zygamborzecki: that's pretty useful13:00
mborzeckiprobably covers most of what you'd see in the wild13:00
ogra_zyga, i understad that we do not want to open access to tty[0-n] here ... but everything else *is* a serial tty13:00
zygaogra_: as chipaca there commented, /dev/tty, /dev/ttyN are off-limits13:00
ogra_yes13:00
ogra_so a regex that makes sure you have a letter there would suffice13:01
zygaoh13:01
zygastandup13:01
mborzeckizyga: gogogo13:01
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 strictness13:02
ogra_*no13:02
zygaogra_: I'll work on landing this PR and we can discuss with jdstrand if a more open regex is ok13:03
ogra_zyga, great (i talked to jdstrand in budapest and he said he would support opening it up)13:04
zygaok13:04
ogra_(if you read the old PR he already supported it there ;) )13:04
jdstrandit's true. we shouldn't do it without niemeyer though since the current approach is based on his decision13:06
ogra_yes13:07
jdstrandnote the other day I mentioned a middle ground: take ogra_'s list and expand the regex for everything we know about13:07
jdstrandif we had done that, the latest one would've already been allowed13:07
ogra_yep :)13:07
jdstrandso I suspect future boards will tend to just work if we do that13:07
ogra_unless a vedor adds a new name :)13:08
jdstrandhence 'tends' :)13:08
ogra_(which happens more frequent than one would think sadly :) )13:08
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:10
alexlarssonjamesh: hey, did you see https://github.com/flatpak/xdg-desktop-portal/issues/167#issuecomment-37681044713:11
kozazyga, answered13:18
kalikianare13:32
kozazyga: thanks and sorry for confusing ;-)13:38
zyganah, ok13:38
zygaI'm just dumb today13:38
pedronisniemeyer:  btw the first PR of the chain is #4771,  the rename to SnapAction etc is there13:47
mupPR #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:47
pedronisniemeyer: I scheduled something with Bret after your lunch break13:50
niemeyerpedronis: Thank you!13:50
ondrakyrofa is sergio around or on holidays?14:10
kyrofaondra, sergio is on holidays for the rest of this week and next. Can I help?14:14
=== nsg_ is now known as nsg
om26erpopey: Hey! did you add me as a collaborator for sublime-text ?14:28
popeyom26er: no. I don't think we should. The requirements for classic confinement prohibit it.14:29
popeyom26er: sorry, been on and off the keyboard as I'm on holiday14:29
popey(currently getting my car tyres replaced) :)14:29
om26eralright ok. I had rights to android studio and sublime previously ;-)14:31
* zyga break14:32
ondrakyrofa already chatted to ev https://bugs.launchpad.net/snapcraft/+bug/175959214:33
mupBug #1759592: kernel build fails for lack of modprobe <Snapcraft:New> <https://launchpad.net/bugs/1759592>14:33
jdstrandroadmr: 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
roadmrjdstrand: yes :(14:33
jdstrandroadmr: what is that about?14:33
roadmrjdstrand: we've been having wobbly/slow transfers (uploads/downloads) since yesterday.14:33
jdstrandok14:33
kyrofaondra, and that's a regression from 2.35, sounds like?14:33
ondrakyrofa just getting frustrated that yet another break for kernel snap build in LP. Close to give up on LP builds14:33
jdstrandroadmr: so retriggering the review should allow it to continue?14:34
roadmrjdstrand: 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
roadmrjdstrand: that constitutes an invalid squashfs causing those errors you see.14:34
ondrakyrofa this is for deb, so before builds were failing because of wrong initrd location14:34
* jdstrand nods14:34
roadmrjdstrand: sometimes, yes; if the retry manages to get a full download, it'll work. Worth a try.14:34
roadmrjdstrand: it'll all normalize once our storage goes back to full speed14:34
roadmrjdstrand: I'll try to get an ETA on that14:34
jdstrandroadmr: yep, cool. thanks!14:34
ondrakyrofa locally this is unlikely to fail, as usually you have modprobe installed14:35
kyrofaondra, okay, we need to SRU another quick fix as well, so I'll get this fix in there as well, hang tight14:35
jdstrandroadmr: with the r1015, I wanted to not assume anything (not that those changes would cause this)14:35
cachiozyga, which info do you need for #494314:35
mupPR #4943: tests: adding debian sid to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4943>14:35
ondrakyrofa may be add LP build as part of release test14:35
roadmrjdstrand: yes, makes sense, but I'm certain it's unrelated. We've been seeing this since before 1015 was rolled out14:36
roadmrjdstrand: (things broke yesterday morning, 1015 rolled out today wee hours)14:36
jdstrandroadmr: yep. not saying it was related, just wanted to touch base14:36
roadmrjdstrand: appreciated :) thanks14:36
cachiozyga, https://paste.ubuntu.com/p/B5QY2GDBkB/14:36
cachiozyga, I don't see errors on logs14:37
kyrofacjwatson, 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:38
cachiozyga, https://paste.ubuntu.com/p/kM7zMJtQHB/14:39
popeyom26er: we should fix that :S14:42
popeyom26er: sublime-text amd64 is in edge14:44
cjwatsonkyrofa: Yes14:45
popeyi need to put an icon in the store om26er14:45
om26erpopey: yeah and a screenshot as well14:45
cjwatsonondra: 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 tests14:46
cjwatsonNot immediately helpful to you, but it is definitely something we've discussed and have work in progress to improve14:46
kaliyhi. who could I ping to transfer ownership of a snap in the store?14:46
popeyom26er: i have also closed the sublime-text-3 channels14:46
popeykaliy: nessita  is who usually processes mine, and requires an email to proove ownership14:47
popey-typos14:47
zygaI will be back soon14:48
popeyom26er: tested locally, the snap works fine, subl alias works14:49
popeyom26er: ok, added icon and a screenshot.14:51
ondracjwatson yeah using snapcraft snap in LP build will be so much better and predictable14:51
popeyom26er: want me to push to stable?14:51
ondracjwatson and if we can specify channel to use, that would be dream :D14:52
nessitapopey, hey there, can I help with anything?14:55
popeynessita: hi, kaliy was asking about snap re-ownership14:56
nessitakaliy, 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 owner14:57
nessitakaliy, with that I can proceed with the snap transfer14:57
niemeyerpedronis: #4771 LGTM with some additional suggestions15:01
mupPR #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:01
cjwatsonondra: That's exactly what we're working on, yes15:02
ondracjwatson yeah!15:03
popeyom26er: i need to go afk in a bit, want me to publish this snap? :)15:08
zygare15:33
mupPR snapd#4949 opened: tests: fix quoting issues in econnreset test <Created by zyga> <https://github.com/snapcore/snapd/pull/4949>15:43
pedronisniemeyer: meeting?16:02
kaliynessita: ack! to which email should I send that?16:02
niemeyerThere!16:02
nessitakaliy, pinging privately to give you the email16:02
* kalikiana out16:45
=== pstolowski is now known as pstolowski|afk
niemeyermborzecki: Where's the nvidia PR?17:04
mborzeckiniemeyer: https://github.com/snapcore/snapd/pull/490817:04
mupPR #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:04
niemeyermborzecki: DO you have a moment for a call?17:34
mborzeckiniemeyer: give me a sec17:34
mborzeckiniemeyer: standup ho?17:35
niemeyerOkay.. I need to change clothes as well as it's getting unreasonably warm.. will be there in a minute17:35
cachiozyga, is it ok the change for #4943 ?18:05
mupPR #4943: tests: adding debian sid to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4943>18:05
mupPR 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:06
zygacachio:  I’m afk shopping for groceries18:10
zygaLooking now18:10
cachiohehe, it is ok18:10
zygaNice18:13
zygaThank you!18:13
mupPR 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:18
cachiopedronis, could you plase see this #495018:19
mupPR #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
cachiowe have the master broken for this issue18:19
cachiopedronis, I am working in a solution be I moved that to manual to unblock other PRs18:19
pedroniscachio: if it takes a while we should probably switch not to manual but have an if at the beginning of the sections18:22
pedronisI mean take a while to fix18:23
cachiopedronis, you mean to skip just that part?18:27
cachiofor fedora18:27
pedronisyes18:27
pedronismmh18:27
cachionot sure how long it will take as the snap is failing18:28
cachioit is not seem to be a test issue18:28
cachioI can do that change18:28
pedroniscachio: sorry, now that I think of it18:28
pedronisshould we use the systems filter?18:29
cachioyes18:29
pedronissystems: [-fedora-*]  or something like that?18:29
cachioupdated18:31
pedronisthanks18:34
cachiopedronis, thanks to you for reviewing18:36
mupPR snapcraft#2041 opened: kernel plugin: add kmod as build-package <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2041>18:37
Caelumzyga: I update my second PR and now I'm looking at your notes on the package18:57
mupPR 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:10
niemeyerTaking a break for exercising.. back for a meeting at the top of the hour19:18
niemeyero/19:18
jdstrandzyga: hi! fyi, on 16.04 system with up to date master:19:33
jdstrand$ ./run-checks --static19:33
jdstrand...19:33
jdstrandRunning vet19:33
jdstrandinterfaces/apparmor/spec.go:129: arg l for printf verb %s of wrong type: *github.com/snapcore/snapd/snap.Layout19:33
jdstrandexit status 119:33
zygajdstrand: oh, looking20:19
zygalooks like a bug in vet20:19
zygadoes this fix it for you?20:19
zygahttps://www.irccloud.com/pastebin/90wGfR4u/20:19
cachioniemeyer, #4943 ready20:32
mupPR #4943: tests: adding debian sid to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4943>20:32
kyrofazyga, are snaps confined on Debian?20:37
mupPR snapd#4951 opened: interfaces/desktop-legacy: allow access to gnome-shell screenshot/screencast <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4951>20:41
mupPR 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:42
mupPR 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:43
mupPR 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>20:57
niemeyercachio: \o/21:02
mupPR snapd#4943 closed: tests: adding debian sid to google backend <Created by sergiocazzolato> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4943>21:03
cachioniemeyer, just fedora remains in linode21:05
cachioniemeyer, I could disable selinux for the google image and it should work, while we can work on fix the issues around it21:07
cachioniemeyer, so we have all the machines in google21:07
niemeyercachio: How is it working in Linode21:13
niemeyer?21:13
cachioselinux disabled21:13
niemeyercachio: So disabling in Google sounds fine21:14
cachioniemeyer, it is gonna be temporal21:14
cachioI'll make the change in that case21:15
niemeyercachio: Yeah, we can work on this spearately21:15
niemeyerseparately21:15
niemeyercachio: If Linode doesn't have it we won't lose anything and can migrate and work on that later21:15
cachioniemeyer, yes, that's the idea21:16
cachiootherwise we will never end with the movement21:16
niemeyerYep21:16
* cachio afk21:42
Caelumthis go stuff is weird, I can't even figure out how to build anything out of a git clone23:07

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!