/srv/irclogs.ubuntu.com/2017/11/02/#snappy.txt

elopiokyrofa: ugh, that sucks. I'm sorry you had to spend so much time on that.00:05
kyrofaelopio, I blame you. You asked for the change that broke the test00:06
kyrofaelopio, nahh, it was educational, for sure. I learned a lot about unittest :P00:06
kyrofaI updated the branch so it's running again, just to be doubly sure00:07
* elopio sent a long message: elopio_2017-11-02_00:15:43.txt <https://matrix.org/_matrix/media/v1/download/matrix.org/pGtjPKvKcSNwREOGnwTVeFFe>00:15
elopiokyrofa: ahh, you know me, always investing in your personal growth :D00:16
kyrofaHahahaha00:16
kyrofaelopio, do you get the same error for cleanbuild?00:17
kyrofaIndeed, that sounds like a snapd issue00:17
elopiokyrofa, yes anything that calls lxc. It doesn't happen when running from the venv00:18
kyrofaWeird00:18
kyrofaAlright, dinner time here00:18
sergiusenskyrofa well, lesson is, you should run the full suite locally when things fail remotely ;-)00:55
sergiusenselopio mind triggering adt for everything under the sun on the 2.35 branch?00:56
mlwdiddledan: hey dan, are you around?00:56
sergiusenskyrofa now that you rebased instead of adding an individual commit you should add an explanation in the PR00:57
elopiosnappy-m-o autopkgtest 1650 xenial:amd64 xenial:armhf xenial:arm64 zesty:amd64 zesty:armhf zesty:arm64 artful:amd64 artful:armhf artful:arm6400:59
snappy-m-oelopio: I've just triggered your test.00:59
sergiusenselopio do we support bionic?00:59
elopiosergiusens: is it ready? do-release-upgrade doesn't let me upgrade from a.01:00
elopiolxc doesn't have bionic either01:01
sergiusenselopio people are already on it01:01
sergiusenselopio didn't you see the ubuntu-devel list? Already open for development01:01
elopiosergiusens: how? latest daily live is from the 18: http://cdimage.ubuntu.com/daily-live/current/01:02
sergiusenselopio changing sources.list to bionic?01:04
sergiusenselopio we can already upload, debootstrap is the mechanism https://lists.ubuntu.com/archives/ubuntu-devel-announce/2017-October/001231.html01:06
elopiosnappy-m-o autopkgtest 1650 bionic:amd601:15
snappy-m-oComputer says nooo. See logs for details:01:15
snappy-m-o Command '['/tmp/tmpmgtertxg/retry_autopkgtest.sh', '1650', 'bionic:amd6']' returned non-zero exit status 101:15
elopiosnappy-m-o autopkgtest 1650 xenial:amd6401:15
snappy-m-oelopio: I've just triggered your test.01:15
elopioahh, damn01:16
elopiosnappy-m-o autopkgtest 1650 bionic:amd6401:16
snappy-m-oelopio: I've just triggered your test.01:17
elopioapparently, it will run sergiusens01:18
elopiosnappy-m-o autopkgtest 1650 bionic:armhf bionic:arm6401:19
snappy-m-oelopio: I've just triggered your test.01:19
mupPR snapd#4114 opened: interfaces: don't udev tag devmode or classic snaps <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4114>01:44
sergiusens\o/01:57
=== petevg is now known as petevg|afk
sergiusenselopio look at the runaway output on zesty-amd64 :/02:46
elopiosergiusens: that's unfortunate. But well, it's probably time to close that socket properly.02:50
elopioit's weird that the socket is not opened for this test, but maybe it's just printed late or something.02:51
elopioif only I could reproduce it...02:59
mupPR snapd#4115 opened: interfaces/serial-port: udev tag plugged slots that have just 'path' via kernel <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4115>04:52
mupPR snapd#4116 opened: interfaces/hidraw: udev tag plugged slots that have just 'path' via KERNEL <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4116>05:32
mupPR snapcraft#1651 opened: tests: move the rest of ros demos tests to integration <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1651>06:16
elopiosnappy-m-o autopkgtest 1651 xenial:amd64:integrationtests06:27
snappy-m-oelopio: I've just triggered your test.06:27
zyga-solusgood morning06:33
zyga-solusgood morning mvo06:42
zyga-solusmvo: we have a series of PRs from jamie for 2.2906:43
zyga-solusI'll be with you soon06:43
mvozyga-solus: yeah, checking. I just approved 411406:48
pedroniszyga-solus: mvo: hi06:49
mvojdstrand: 4115 is not a 2.29 regression, its fallout from the changes in 2.28, right?06:49
mvohey pedronis06:49
zyga-solushello pedronis, how are you doing?06:50
pedronisok, up early (for me) because we are waiting for people doing some work for the house06:50
zyga-solusmvo: 4115 was a general feature I believe, we always udev tagged devmode but we never did this at a scale introduced in 2.2806:50
mvozyga-solus: yeah, 4115 is not a regression (technically)06:51
zyga-solustechnically that is correct06:51
pedronismvo: I  fixed the configure snapd branch (doing the simplest possible change I think), if you want to look,   it could be mergeable and we can do more in follows up06:51
mvopedronis: cool, I have a look now. thanks for picking this up!06:52
zyga-solusmvo: please don't land 4114 just yet06:52
pedronismvo: I also have a couple more PRs needing review but less urgent than jdstrand stuff obviously06:53
mvozyga-solus: sure, I hold it back. whats your concern?06:54
mvopedronis: thanks, your config fix looks good, I will go over the other two commits and then I think this gets my +106:54
mvopedronis: then I can do more reviews06:54
zyga-solusmvo: I want to see why tests are just for ubuntu, they should not be06:55
zyga-solusmvo: I'll test locally and push a change if they can work everywhere06:55
zyga-solusjust eating breakfast06:55
mvozyga-solus: cool, thanks06:55
mvozyga-solus: I also saw test failures in 14.04/reexec in spread but maybe just a fluke06:55
mvopedronis: hm, you are spot on about IgnoreHookError in configure-snapd. I think we need to make sure we do not fail hard if something is not working with the internal configure06:56
pedronismvo: we set only on install/refresh of core, I suppose we could teach the handler to just log the error if some flag is set on the task06:58
mvopedronis: yeah, I can prepare a followup with this fix06:58
pedronismvo: ok, going to merge it07:00
mvothanks!07:01
pedronisdone07:04
mupPR snapd#4076 closed: many: handle core configuration internally instead of using the core configure hook <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4076>07:05
* zyga-solus is back now07:22
mborzeckimorning everyone07:22
zyga-solusmborzecki: hello!07:23
mborzeckii'm the new guy, starting only today :)07:23
zyga-soluswelcome :)07:23
zyga-solusmborzecki: we have mvo and pedronis around already07:23
mborzeckimvo: pedronis: hi07:24
zyga-solusmborzecki: pawel and john should join soon too07:24
zyga-solus(though perhaps john is off today, not sure)07:24
zyga-solusmborzecki: gustavo I believe is off this week07:24
zyga-solusmborzecki: sergio will join later today07:24
pedronismborzecki: welcome!07:24
mvohey mborzecki - welcome!07:24
mborzeckithanks07:25
zyga-solusmborzecki: fork and build the tree and look around07:26
mborzeckiso how does it work from here? already got an email address, launchpad accounts and SSO work07:26
zyga-solusmborzecki: we're just starting with 2.29 release candidates07:27
zyga-solusmborzecki: great, you also need a github account as that's where the code is (but I'm sure you have one)07:27
zyga-solusmborzecki: mvo can add you to the team that owns snapd, I believe07:27
mvomborzecki: a good starting point is probably to check if our "HACKING.md" is up-to-date ,)07:27
mborzeckiok, cool07:28
zyga-solusha, excellent advice :)07:28
mvomborzecki: i.e. if you can get started following that guide07:28
mvomborzecki: and if its not up-to-date we appreciate PRs about the broken bits :)07:28
mborzeckiack07:28
mvomborzecki: and if you have any questions or anything we are here for you!07:29
zyga-solusmborzecki: also tell us which distro your are using07:29
mborzeckihaha, that's the interesting part, i'm using arch atm07:29
zyga-solusmborzecki: large chunk of the team is on various releases of ubuntu07:29
zyga-solusmborzecki: I'm on ... many :)07:29
mvomborzecki: thats good, our instructions are probably lacking in this area07:29
zyga-solusmborzecki: I don't suppose you have arch commit access, do you?07:30
mborzeckii'll be sure to check them07:30
mborzeckizyga-solus: nope07:30
zyga-solusmborzecki: the current maintainer has abandoned our package so we're kind of stale there07:30
mborzeckiiirc it's in community repo, right?07:30
zyga-solusthat's correct07:30
mborzeckiarch's rules of engagement we kind of weird last time I checked, but i could poke around and see if it's possible to do something like debians nmu07:31
zyga-solusmborzecki: I think we need to indicate the current maintainer as inactive but that requires a motion filed by a TU07:31
zyga-solusmborzecki: and then within some weeks there's a chance to remove that TU from the package and have another TU pick it up07:32
mborzeckihm, so i'm guessing you've already started the process, but it isn't going as smooth as expected?07:32
zyga-solusmborzecki: flexiondotorg was looking at this last time I think, I don't know more07:33
mborzeckifair enough, I'll start with trying to build the current master first and we'll take it from there07:35
mborzeckiwhich go version do you use atm? i recall zyga-solus or niemeyer mentioning 1.6, is it still the case?07:39
zyga-solusmborzecki: we use different versions for each system actually, ubuntu 14.04 and 14.06 are on 1.607:39
zyga-solusmborzecki: so that's the lowest common denominator07:39
zyga-solusmborzecki: on arch and on development versions of ubuntu we use the latest07:39
zyga-solusmborzecki: we also have almost everything in between, I think07:40
mvomborzecki: minimal version is 1.6, not sure we care about less. it should build with everything 1.6+ if not thats a bug worth fixing07:42
pedronismvo:  about reviews,   #4106 and #4111 are the main ones, Chipaca already did a first review07:43
mupPR #4106: many: lookup and use the URL from a store assertion if one is set for use <Created by pedronis> <https://github.com/snapcore/snapd/pull/4106>07:43
mupPR #4111: many: make ignore-validation sticky and send the flag with refresh requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/4111>07:43
pedronismvo: do you remember why we have both  switch-snap  and switch-snap-channel tasks?  they seems to do very similar but not quite identical things07:45
mvopedronis: I think because of a race :/ iirc the snap switch command was actually coded long before it landed and in the meantime we probably did switch-snap-channel but the old switch thing did not get updated for it07:51
pedronismvo: I see, indeed I noticed also the handler for one is in the wrong place07:56
pedronismvo: I probably need to do something like switch-snap-channel for ignore-validation07:56
mvopedronis: will you look at cleaning this up (just noticed the wrong place as well :/07:57
mvopedronis: or shall I create a cleanup PR?07:57
pedronismvo: is not too urgent, also they  really do slightly different things07:58
pedronisso needs a bit of thinking07:58
pedronisI can move the hanlder in a drive-by though07:58
pedronismvo: they probably also need to be added to the change conflict task list08:00
mvopedronis: +108:02
mvopedronis: silly question - do we have the inverse of --ignore-validation? just looking at 4111 and was wondering how this is reset08:06
person112Apologies if this isn't the right place to ask, but can interfaces be shimmed?08:09
person112As in, a snap that offers interfaces that simulate an empty 'Home' or a network that never opens a socket.08:09
pedronismvo:  https://forum.snapcraft.io/t/make-ignore-validation-sticky-and-send-the-flag-over/2139/3  , the reverse of  "snap refresh --ignore-validation foo"  is just  "snap refresh foo"08:09
mvopedronis: ta08:09
pedronismvo: that's the input from Gustavo on the matter08:10
pedronismvo: I double checked, because one  also changes the current SideInfo, switch-snap-channel and switch-snap are not interchangeable, we could add a flag but not sure worth the trouble at this point08:11
mvopedronis: yeah, maybe a comment is enough to explain the subtle details08:12
pedronisI'll just do a small PR to move the handler closer to the other and add them conflict management08:13
mvopedronis: sounds good08:14
mvopedronis: and I see we test the reset of --ignore-validation, great (should have read all the way before asking :)08:14
mvopedronis: 4111 is small enough to consider for 2.29.1, wdyt? how urgently does CE needs it?08:15
pedronismvo: I think they would be happy if it's 4111, the server change was deployed yesterday08:15
pedronissorry08:15
pedronisif it's in 2.2908:16
pedronisbut I didn't promise it08:16
mvopedronis: I milestoned it, for the fix from jdstrand we will need a 2.29.1 anyway so its a good target of opportunity (also low risk afaict)08:16
person112Also, is it posible to change auto-connect defaults for snaps?08:17
pedronismvo: yea, I'm working on the follows up,  but as fix it's ok standalone08:17
mvothanks pedronis08:18
pedronismvo: I have a PR open about showing the flag in snap info,  and I'm working on setting/resetting the flag even if there's no update atm, like we do for channel08:18
* mvo nods08:19
pedronismvo: when do you think we will cut 2.30 ?08:19
mvopedronis: early next week, but there are some important piece that are missing, i.e. the fix for the refresh-schedule we promised for 2.3008:21
mvopedronis: mostly on my plate though08:21
zyga-solusmvo: early next week?08:21
zyga-solusmvo: I thought that would be only after 2.29 goes to stable08:21
zyga-solusmvo: ~3 weeks08:22
mvozyga-solus: the schedule is that 2.29 goes to stable on Monday08:22
* zyga-solus was hoping to have most of layouts in 2.3008:22
zyga-solusaha :)08:22
zyga-solusI guess 3.31 it is then08:22
pedronismvo: I also have some stuff that we want in 2.30 because it was delayed already quite a bit08:22
mvozyga-solus: check https://forum.snapcraft.io/t/the-snapd-roadmap/197308:22
pedronismvo: time to have the milestone to tag stuff?08:22
mvopedronis: +108:22
mvopedronis: milestone added08:23
pedronisthank you08:23
mupPR snapd#4013 closed: repo, daemon: use PlugInfo, SlotInfo <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4013>08:23
pedronismvo: marked thing accordingly (especially #4106 that I mentioned before)08:24
mupPR #4106: many: lookup and use the URL from a store assertion if one is set for use <Created by pedronis> <https://github.com/snapcore/snapd/pull/4106>08:24
pedronismvo: I'm merging #4111,  it's one commit so it should be easy to cherry-pick for 2.2908:46
mupPR #4111: many: make ignore-validation sticky and send the flag with refresh requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/4111>08:46
mupPR snapd#4111 closed: many: make ignore-validation sticky and send the flag with refresh requests <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4111>08:48
mvopedronis: ta08:48
zyga-solusmvo: I pushed a patch to 411409:02
zyga-solusmvo: I left some comments and I'm +1, I can also address them in a quick patch if you agree09:03
mupPR snapd#4117 opened: many: make ignore-validation sticky and send the flag with refresh requests (2.29) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4117>09:03
pedronismvo: I created the cherry-pick ^09:03
mvopedronis: \o/ thank you09:03
mvozyga-solus: checking, thank you!09:04
mupPR snapd#4118 opened: overlord/snapstate: cleanups around switch-snap* <Created by pedronis> <https://github.com/snapcore/snapd/pull/4118>09:04
mvozyga-solus: looks good, thanks09:05
pedronismvo:  and cleanups ^09:06
mvota09:07
mborzeckiall right, as expected the code builds just fine, the tests are mostly ok. there are some issues raised by shellcheck in tests/lib/snaps/test-snapd-service/bin/{start,start-other} and tests/lib/snaps/test-snapd-service/meta/hooks/configure09:32
zyga-solusmborzecki: nice, looks like some low hanging fruit to tweak09:32
mborzeckii can fix those, open a PR, and we'll get through the github accounts and stuff :)09:32
zyga-solusyep, sounds like a good plan09:33
mborzeckibtw. noticed that you're not using gometalinter but rather just the individual tools09:33
* zyga-solus never heard about gometalinter09:34
mborzeckihttps://github.com/alecthomas/gometalinter sort of a frontend/driver to all the linting/checking tools for go09:34
pedronismvo: :( seems master is unhappy09:38
mborzeckido i need to signoff the commits?09:43
zyga-solusmborzecki: not really09:44
zyga-solusmborzecki: I love to but it's just me09:44
mborzeckiok, so another question, any email address or @canonical.com when signing off?09:45
zyga-solusagain, no rule, I use a mix, depending on how I feel about the work09:45
mborzeckifair enough09:45
mvopedronis: I noticed this earlier too, I have a look in a bit09:46
pedronismvo: last one is snapd-reexec failure on 14.04 but I don't understand the issue09:48
mupPR snapd#4119 opened: tests/test-snapd-service: fix shellcheck issues <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4119>09:48
mborzeckifyi my github handle is 'bboozzoo' :)09:49
pedronismvo: seems we are installing the  same core  but don't expect that and don't get a restart09:49
zyga-solusmborzecki: reviewed09:49
zyga-solusmborzecki: I think you can remove the "have you signed the license agreement" stuff from your commit09:50
pedronis+ prev_core=337709:50
pedronis+ snap install --dangerous /var/lib/snapd/snaps/core_3377.snap09:50
pedroniscore 16-2.29+git446.aaee286 installed09:50
pedronisThis leaves core tracking edge.09:50
pedronis+ MATCH 'Requested daemon restart'09:50
mborzeckizyga-solus: i think it's only added by github PR templates, it's not part of the commit message09:51
zyga-solusit's added but when you open the PR you can still remove it09:51
zyga-solusyou can hit the edit button and remove it still09:51
mborzeckidone09:52
mborzeckibtw. should I sign canonical CLA?09:53
zyga-solusmborzecki: I don't think you need now09:56
* Chipaca looks around10:03
zyga-solushey ho Chipaca10:03
Chipacazyga-solus: hiya! how's things?10:03
zyga-solusChipaca: our new colleague, mborzecki is around10:03
mborzeckiChipaca: hi there10:03
Chipacai was trying to spot them but with 283 people it was hard10:03
zyga-solusChipaca: damp10:03
Chipacamborzecki: o/!10:03
zyga-solusChipaca: but it might rain too :)10:04
Chipacazyga-solus: it's officially "are the clothes damp, or just wet" weather here10:04
zyga-solushehe :)10:04
zyga-solusI'm in a mood to visit UK and see10:05
mborzeckizyga-solus: is it not raining in warsaw yet?10:05
zyga-solusmborzecki: I think it stopped now10:05
mborzeckimaybe it's buffering :/, damn weather10:06
zyga-solusmborzecki: "loading more rain" ;) I like that10:06
mborzeckiok, so what should look at now? go through PRs maybe?10:08
zyga-solusmborzecki: look around, we have plenty of PRs to review10:08
zyga-solusmborzecki: I think looking at that and asking questions is useful10:08
zyga-solusmborzecki: you can also check our roadmap on the forum (oh, and do sign up if you haven't already)10:09
mvoChipaca: do you think https://forum.snapcraft.io/t/disk-usage-report/2372 might be a nice first task for mborzecki ?10:10
Chipacamvo: that'll touch osutils, daemon, client, and cmd/snap at a minimum10:11
Chipacamvo: but nothing particularly complex10:11
Chipacamvo: so... yes, probably? unless we want them digging into the overlord straight away10:11
mthaddonhi there - I'm getting "cannot perform operation: mount --rbind /snap /snap: Permission denied" when running a snap I've installed inside an LXC - do I need to add the user to a particular group or something? (snap version 2.28.5 on 16.04)10:12
zyga-solusI think today should be a "figure out the code layout day"10:12
zyga-solusmthaddon: hey!10:12
mthaddono/10:12
zyga-solusmthaddon: hmm hmm10:12
zyga-solusmthaddon: can you tell me if the container is privileged?10:12
zyga-solusmthaddon: as in, not confined at all?10:12
zyga-solusmthaddon: and can you tell me what is on the outside of the LXC container?10:13
mthaddonzyga-solus: I created the LXC with -c security.privileged=true. It's running on a xenial machine10:13
zyga-solusmthaddon: I think, (though stgraber could confirm) that it means there's no apparmor stacking in that case, so whatever is in the container is confined by what is on the outside10:14
zyga-solusmthaddon: which version of snapd do you have on the outside?10:14
mborzeckii'll look around the code and will try to get a custom built snapd up and running, then i can take a look at disk usage10:15
mthaddon2.28.5 on the outside10:15
mvoChipaca: thinking about suitable tasks currently not too hard but also reasonable interessting. do you have ideas?10:15
zyga-solusmthaddon: can you see if you had any apparmor denials?10:15
mvomborzecki: cool, another interessting task might be to update the arch packaging (cc zyga-solus )10:16
zyga-solusoh, that's actually a very good idea10:16
mvomborzecki: or fixing the current test failure in master :)10:16
mvomborzecki: all interessting stuff :)10:17
mupPR snapd#4120 opened: repo: use PlugInfo and SlotInfo for permanent plugs/slots <Created by stolowski> <https://github.com/snapcore/snapd/pull/4120>10:18
mthaddonzyga-solus: I see some, but not at the time of when I run the command that's triggering the error. I had some errors during attempted building of a snap and had to install squashfsfuse and restart the lxc to be able to build the snap (and have core installed), but it eventually worked okay10:18
zyga-solusmthaddon: I recall a case we investigated a good while back10:18
zyga-solusmthaddon: where the problem was that snapd in the inside of a privileged lxd container was actually confined by the apparmor profile of a very out of date snapd on the lxd host10:19
zyga-solusmthaddon: and we ended up saying that that is not supported much10:19
mthaddonis 2.28.5 very out of date?10:20
zyga-solusno, it's not10:20
zyga-solusI'm just trying to grok what may be going on10:20
mthaddongotcha10:21
mupPR snapd#4121 opened: overlord/snapstate: toggle ignore-validation as needed as we do for channel <Created by pedronis> <https://github.com/snapcore/snapd/pull/4121>10:27
zyga-solusmvo: the 14.04 refresh-undo thing is a regression after the release recently?10:28
mupPR snapd#4122 opened: configstate: add support for snapstate.IgnoreHookError <Created by mvo5> <https://github.com/snapcore/snapd/pull/4122>10:29
mvozyga-solus: I'm not sure, I have not investigated yet10:30
pedronismvo: I got the 14.04 snapd-reexec also on a PR10:30
pedronisit seems a real issue10:30
pedronisor something off with versions of things10:30
mvopedronis: 4122 adds the ignore-hook errors to the internal configure (and some more tests, I think I will add more more tests10:31
mvopedronis: yeah, I check that out10:31
mthaddonzyga-solus: should I file an issue for this somewhere to make it easier to follow up on?10:31
mwhudsonmvo: /me points at debian packaging too :)10:32
zyga-solusmthaddon: I think we could use a detailed bug and I should have a look at that10:32
mwhudsonmvo: mostly done, it just needs versions of dependencies checking10:32
pedronismvo: I'll look at it in a bit10:32
zyga-solushey mwhudson10:32
mthaddonzyga-solus: sure, LP or GH?10:32
zyga-solusmthaddon: LP please10:32
mthaddonack10:32
mvomwhudson: oh, the debian PR is updated, nice!10:33
mvopedronis: no rush10:33
mwhudsonmvo: uh not the PR against snapd, no :/10:33
mwhudsonmvo: but the repo on alioth is10:33
mwhudsonzyga-solus: hello10:34
mwhudsonzyga-solus: i am going to bed :)10:34
mvomwhudson: aha, ok10:34
mvomwhudson: we should merge your packaging still :)10:34
mvomwhudson: but another day, I guess its late for you10:34
zyga-soluspstolowski: hey11:00
pstolowskizyga-solus, hi!11:01
zyga-soluspstolowski: which PRs should I get started with to help you out?11:01
pstolowskizyga-solus, the two i've currently can be reviewed independently, and both are prerequisites for the upcoming ones, so pick any ;)11:01
zyga-solusok, I'm going to go through 4120 then11:02
pstolowskizyga-solus, thanks in advance!11:02
pedronispstolowski: I'll see to look at your branches as well this afternoon or tomorrow11:14
pstolowskithanks pedronis!11:15
zyga-solusman, my eyes fail me today11:39
zyga-solusmvo: there's going to be another tiny one for 2.2911:50
zyga-soluspstolowski you found an interesting bug11:50
ogra_popey, are you around ?11:51
zyga-soluspstolowski: 4120 done11:51
ogra_popey, how can i reack "oli" from askubuntu.com ... apparently he wants to delete all my recent snap related posts ... (i went over the 100s of long term unanswered snappy posts to point people to the forum)12:01
ogra_*reach12:01
ogra_seemingly that "breaks the rules of askubuntu, so I'm going to delete the most ..."12:02
zyga-solus quick break12:03
pstolowskizyga-solus, thanks! ah, that, yeah, i rolled my eyes when I saw this, forgot to address it separately12:03
zyga-soluspstolowski: I'll handle the 2.29 change12:03
zyga-solusno worries12:03
zyga-solusI'm adding a new test with some reflection12:03
pstolowskicool12:04
mvozyga-solus: oh, tell me more? but after lunch :)12:07
=== JoshStrobl is now known as JoshStrobl|AFK
mupPR snapcraft#1652 opened: tests: fork skip into snaps_tests <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1652>12:17
sergiusenssnappy-m-o autopkgtest 1652 xenial:amd6412:19
snappy-m-osergiusens: I've just triggered your test.12:19
jdstrandmvo: re 4115 and 4116> not a direct regression, no, but the bug is exacerbated by 2.2812:27
zyga-soluspstolowski: I have a test that catches the error now12:27
zyga-solusjdstrand: hey :)12:27
zyga-solusjdstrand: interesting iface bug pawel found today :)12:27
jdstrandzyga-solus: hey12:28
jdstrandzyga-solus: I haven't seen it yet (just woke up)12:28
zyga-solusjdstrand: I'll send a PR up in 10 minutes12:29
mupPR snapcraft#1651 closed: tests: move the rest of ros demos tests to integration <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1651>12:32
zyga-solusoh boy oh boy12:37
sergiusensoh man oh man12:41
sergiusens:-)12:41
zyga-solusmvo: two PRs up12:55
mupPR snapd#4123 opened: interfaces: fix incorrect signature of ofono DBusPermanentSlot (2.29) <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4123>12:55
mupPR snapd#4124 opened: interfaces: fix incorrect signature of ofono DBusPermanentSlot <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4124>12:55
zyga-soluspstolowski: please merge this into your PR and ensure it's all green12:56
zyga-soluspstolowski: thank you for finding it12:56
zyga-solusjdstrand: ^12:56
zyga-soluspstolowski: you will need trivial changes to type signature checks in the PR that changes them12:57
popeyogra_: there is a meta chat thing on askubuntu. I'd recommend dropping in there13:01
popeyhttps://chat.stackexchange.com/rooms/201/ask-ubuntu-general-room13:02
popeyYou're being discussed13:02
ogra_heh13:04
jdstrandzyga-solus: oh, eww13:08
jdstrandzyga-solus: did you grep the source for other offenders?13:09
zyga-solusjdstrand: not exhaustively, I just pushed this13:09
zyga-solusjdstrand: I'm trying to see how far the bug goes13:10
jdstrandzyga-solus: grep PermanentSlot ./*.go|grep plug: just ofono13:10
zyga-solusjdstrand: beauty of dynamic typing :/13:11
mlwhey diddledan, are you around?13:13
diddledanyello13:13
mlwCould I possibly request you to add gimp-gmic and gimp-data-extras to the stage packages for the gimp snap?13:13
mlwThe former more important than the latter.13:14
diddledanwell the gimp snap compiles gimp from source, rather than repackaging the debian package, so gmic will need compiling too. I've given it a shot and had problems, but I can't remember where I got to13:16
mlwAh, well thanks for looking.13:17
zyga-solusmthaddon: hey, did you report that bug by any chance?13:19
pedronisChipaca: #4110 needs review for example (it's assertion but it's also small/clear hopefully)13:29
mupPR #4110: many:  have a timestamp on store assertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/4110>13:29
zyga-solusmvo: I'll look at 14.04 now, maybe I can find something13:30
mthaddonzyga-solus: https://bugs.launchpad.net/ubuntu/+source/snap/+bug/172957613:32
mupBug #1729576: cannot perform operation: mount --rbind /snap /snap: Permission denied <amd64> <apport-bug> <xenial> <snap (Ubuntu):New> <https://launchpad.net/bugs/1729576>13:32
zyga-solusmthaddon: thank you13:32
zyga-solusmthaddon: I'll check that after investigating master breakage now13:32
mvozyga-solus: thank13:32
mthaddonack13:32
mvozyga-solus: you13:33
mthaddonzyga-solus: it's not blocking me, fwiw13:33
om26erflexiondotorg: hey! re: sublime-text and android-studio, did you upload them to the store ?13:33
mupPR snapd#4125 opened: corecfg:  support setting proxy.store if there's a matching store assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/4125>13:38
zyga-solusjdstrand: question about security-device-cgroups-serial-port, why does it fail on fedora/opensuse/debian13:43
zyga-solusjdstrand: I'm staring at the interactive shell but I cannot figure it out just yet13:43
zyga-solusjdstrand: do you know the reason?13:43
zyga-solusmvo: interestingly 2.29 branches also fail13:49
mlwdiddledan: I've put architectures: [amd64], in my snapcraft.yaml, and I've added the github repo via snapcraft.io. How come it's looking to build both i386 and armhf (the latter which fails) when I've only specified one arch?13:49
diddledanthe architectures command doesn't actually say which architecture to build for. it says "this snap is compatible with". This is a bit of a weird situation13:50
mlwSo how do I tell snapcraft.io not to bother with the others?13:51
diddledanyou can't :-(13:51
mvozyga-solus: fails where?13:51
zyga-solusmvo: on the 14.04 snapd-reexec test13:51
zyga-solusmvo: so this rules out anything in master recently13:51
mvozyga-solus: yeah, I don't have anything in journalctl for the last change (core install, its change 6 for me)13:51
zyga-solusmvo: I'll report when I find something13:52
mlwOk then. Well, last step is to figure out how to get the launcher configured correctly.13:52
mvozyga-solus: funny enough, if `snap change 6|grep Restart` is used things look ok13:52
mvozyga-solus: still very strange that it stopped working all by itself, no recent systemd chnage afaict (last is >2 weeks old)13:53
zyga-solusmvo: yes, I still find it puzzing13:56
* Chipaca shakes his fist at everything13:58
* Chipaca goes for a cuppa13:58
kyrofasergiusens, elopio getting up to speed this morning. How's adt now? Can I help?14:02
mupPR snapd#4126 opened: tests: use `snap change --last=install` in snapd-reexec test <Created by mvo5> <https://github.com/snapcore/snapd/pull/4126>14:02
sergiusenskyrofa should be on path with my quick fix on snapcraft#165214:02
mupPR snapcraft#1652: tests: fork skip into snaps_tests <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1652>14:02
mvozyga-solus: above is a workaround but I'm not happy that I don't understand the root cause14:02
mvozyga-solus: I think we need to get back to this at some point. but right now 2.29.1 takes priority14:03
zyga-solusmvo: aha14:03
kyrofasergiusens, argh. Did we run into pyramid issues again?14:03
sergiusensit might be a while before we get a chance to run though, that's the queue length for the archive bionic 1044 - 1086 988 335 21514:04
kyrofaOnce the test refactor lands (snapcraft#1638) we can fix that14:04
zyga-solusmvo: I have an idea, I will try it out now14:04
mupPR snapcraft#1638:  tests: reorganize unit and integration suites to make them easier to split for travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1638>14:04
sergiusenskyrofa no, with your skip implementation, the location of it, causing a cascading import effect14:04
sergiusenskyrofa well, things need to move out of __init__14:04
sergiusenswe should also have one test package which is lean on auto importing14:05
mvozyga-solus: tell me please :)14:05
kyrofasergiusens, yeah, agreed14:06
pedronismvo: seems it's also failing on 2.2914:07
pedronisalso refresh-undo is failing, sometimes14:08
mvopedronis: yeah, I have pushed a workaround for the failing test14:09
mvopedronis: I don't understand the root cause yet though :(14:09
mvopedronis: I am looking at refresh-undo now too (running locally to see if I can reproduce)14:09
zyga-solusmvo: sorry, some guests just arrived14:12
zyga-solusmvo: I used this to debug an issue on 14.04 earlier14:12
zyga-solusmvo: I hacked the systemd unit to redirect stdout/stderr to /var/log/snapd.log14:12
zyga-solusmvo: it is a low-tech solution to journald being broken14:12
zyga-solusmvo: I'll see what I get with that modification14:12
zyga-solusmvo: tests are in progress, I mainly want to ensure we see the restart log14:14
zyga-solusmvo: so that we know the workaround you proposed for .1 is OK14:14
mvozyga-solus: ok, note that I pushed a workaround for the test, i.e. use snap change --last=install to get the logs. would still be nice to know why journalctl starts misheaving14:14
zyga-solusmvo: right, I want to ensure that workaround is safe for the time being14:14
zyga-solusmvo: I agree about wanting to get to the bottom of the problem14:14
mvozyga-solus: \o/ thanks, we are in agreement14:15
pedronisChipaca: #4112 is also ready for input14:15
mupPR #4112: cmd/snap,client,daemon: show ignore-validation if set in snap info <Created by pedronis> <https://github.com/snapcore/snapd/pull/4112>14:15
kyrofasnappy-m-o, github subscribe 165214:16
snappy-m-okyrofa: I'll send you a message if a test fails in the pull request #1652 (tests: fork skip into snaps_tests).14:16
mupPR #1652: Correct interface connection JSON documentation (used an object inste… <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1652>14:16
kyrofasergiusens, 2.34+git89.a25cfcc is in edge, but that commit is unknown to me14:19
kyrofaDo you know what it is?14:20
sergiusenskyrofa git pull -> "internal: more gracefully determine host OS (#1636)"14:20
mupPR #1636: snap: don't load unsupported implicit hooks <Created by kyrofa> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1636>14:20
sergiusenslol14:20
sergiusensdefault for pounding a number is snapd PRs, oh well14:21
kyrofasergiusens, oh duh, I wasn't up to date. Sorry14:21
mupPR snapd#4124 closed: interfaces: fix incorrect signature of ofono DBusPermanentSlot <Critical> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4124>14:21
kyrofaVery good, we now have a snap that can be used on trusty, that's super exciting14:21
elopiokyrofa: sergiusens when is a good time for you to talk about snapcraft in the code-in? what about 16 UTC?14:30
sergiusenselopio is that an hour and a half from now?14:32
elopiosergiusens: yes14:32
sergiusensno that I am on gnome I have a hard time quickly looking at timezones :-P14:32
sergiusenswhen you say utc I home you mean real utc (not dst) ;-)14:33
sergiusenselopio can it be 1 hour 30 minutes further down?14:33
ogra_dsutc14:33
elopiosergiusens: so, now?14:35
zyga-solushmm, me got no logs at all14:36
zyga-solusWTF14:36
sergiusenselopio further into the future, not the past :-)14:37
sergiusensmove the pointer in time further from now, not closer (now is my reference)14:37
elopiosergiusens: 18UTC works for me.14:38
sergiusenselopio ok, can do if it is 30' at 18:30 as I have a knee appointment for this constant pain I've been having since I left for the past sprint14:39
kyrofasergiusens, that's what you get for fighting with the aikido masters14:42
elopio30 minutes should be enough to get us started and continue distributed. kyrofa what about you?14:43
kyrofaelopio, I'm there14:44
elopiook, so if I understood correctly, from 18:30 to 19:00. I'll send the invite. Please correct it if I misunderstood.14:45
kyrofaWait... I understood 1800-(1830-driving delta)14:46
zyga-solusmvo: drat14:47
zyga-solusmvo: I ran it with extra logging14:47
zyga-solusmvo: and it passed!!!14:47
zyga-solusmvo: I didn't merge your branch yet so it was on vanilla setup14:47
zyga-solusmaybe it is really just random in some way14:47
zyga-solus(I honestly think 14.04 needs love)14:48
elopiosergiusens: do you mean start at 18:30 or finish at 18:30 ?14:48
sergiusenskyrofa elopio if I can pick, 17:30 to 18:0014:49
sergiusensor I will take the meeting from the waiting room ;-)14:49
mvozyga-solus: i was seeing it reliable (4/4) in my 14.04 qemu spread runs14:50
elopiosergiusens: I have the community council meeting from 17 to 18.14:51
elopiokyrofa sergiusens there is still plenty of time for this, what about tomorrow, maybe at 17UTC?14:51
zyga-solusmvo: I was running linode (not enough ram for two vms)14:52
zyga-solusmvo: but it did fail each time earlier14:52
zyga-solusmvo: restarted at 15:47, let's see if it fails now14:52
tpatelDoes private snap auto-update on the refresh schedule if new version is available?14:57
mupPR snapd#4127 opened: interfaces/uhid: unconditionally add existing uhid device to the device cgroup <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4127>14:57
tpatelDoes private snap auto-update on the refresh schedule if new version is available?15:03
mupPR snapd#4128 opened: Revert " wrappers: fail install if exec-line cannot be re-written  <Created by mvo5> <https://github.com/snapcore/snapd/pull/4128>15:03
kyrofatpatel, I thought so. Does that seem to not be the case?15:04
kyrofatpatel, although I see this: https://forum.snapcraft.io/t/automatic-refresh-of-private-snaps/253015:05
kyrofaIs that the behavior you're seeing?15:06
tpatelkyrofa: I have unit in the field for 7 days and I have new snap updated on the store past couple days and haven't seen it getting updated.15:06
kyrofatpatel, please join in on that thread, then. I pinged a snapd dev there to try and get it some attention15:07
=== cachio is now known as cachio_lunch
tpatelkyrofa, ok. I did not see any post for past 14 days on that thread so decided to raise my question here. Thanks though.15:08
kyrofatpatel, the thread is waking up. Please do add your details there15:09
jdstrandmvo: note PR 4127. I didn't tag this one for 2.29 since I discovered it before anyone in nthe field noticed, but it has all the same qualities as 4115 and 4116 for inclusion15:12
mupPR #4127: interfaces/uhid: unconditionally add existing uhid device to the device cgroup <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4127>15:12
jdstrandmvo: so, I'll leave it up to you15:13
mvojdstrand: checking15:14
mvojdstrand: looks good, thanks, I think we want this too, also looks reasonable small and safe15:15
jdstrandmvo: I agree. note that I am off tomorrow, back monday15:15
jdstrandmvo: thanks!15:15
Chipacasergiusens: is there a way for snapcraft to make a snap private, or is it web-only?15:15
mvojdstrand: thank you, special \o/ for all these fixes!15:16
sergiusensChipaca `snapcraft register <snap-name> --private`15:16
jdstrandmvo: fyi, for 4114, 4415 and 4116, I'm getting unrelated spread test failures. linode:ubuntu-14.04-64:tests/main/snapd-reexec pretty consistently, but just now linode:ubuntu-core-16-64:tests/main/lxd failed15:16
jdstrandI've restarted builds several times. not sure if I should stop doing that15:17
jdstrandmvo: can you advise? ^15:18
Chipacasergiusens: no, it's already registered15:18
jdstrandmvo: linode:ubuntu-core-16-64:tests/main/snap-auto-mount popped out in 411615:19
sergiusensChipaca then no, web only (or maybe not even there)15:19
jdstrandanyway, I'm happy to keep pressing restart build and see if one makes it if you want15:19
sergiusensChipaca we have no APIs for this15:19
Chipacasergiusens: it's doable on the web15:19
Chipacasergiusens: ok15:19
Chipacasergiusens: should we? :-)15:20
Chipacait'd make explaining what i did easier (copy-paste from terminal vs saying where to click)15:20
Chipacabut, not important15:20
mvojdstrand: I noticed the snapd-reexec and there is a PR up for it. the lxd one is new as is the snap-auto-mount15:20
Chipacapedronis: do we have a way for the user to check if their macaroon is still valid?15:21
jdstrandmvo: yes, but those are intermittent. I've pressed 'restart build' multiple times and they only just popped up15:21
jdstrandmaybe new PRs since I submitted were comitted...15:21
jdstrandcommitted*15:21
zyga-solusre15:22
zyga-solusit failed now15:22
zyga-soluslooking15:22
jdstrandmvo: I think I'll just document that the failures are unrelated15:22
pedronisChipaca: I'm not sure, this is not our most well worked out area15:24
zyga-solusjdstrand: hey15:24
zyga-solusjdstrand: quick request if you have the time today15:25
zyga-solusjdstrand: can you please look at that one method I mentioned earlier, the one that sets up tmpfs "overlay"15:25
zyga-solusjdstrand: I'll polish tests and everything else but if you disagree about the fundamental design of that I'd rather know earlier15:25
zyga-solusjdstrand: do you need pointers to the code?15:25
pedronisChipaca: refresh itself doesn't gives back an error if your macaroon is expired, it just skips stuff15:26
pedroniswe can probably do a bit better in the new API15:26
Chipacapedronis: auto-refresh does not refresh private, for some reason15:26
mupPR snapd#4129 opened: wrappers: do not error on incorrect Exec= lines <Created by mvo5> <https://github.com/snapcore/snapd/pull/4129>15:26
pedronisChipaca: auto refresh is not different from "snap refresh"15:27
pedronisexcept the user 015:27
pedronisvs what you are15:27
Chipacapedronis: ¯\_(ツ)_/¯15:27
pedronisChipaca: we might have hit the  we don't refresh snaps as the user that installed them15:27
pedronisissue15:27
pedroniswhich we have ignored so far15:28
pedronis(it's a bit of a mess)15:28
pedronisthere are a couple of approaches to that15:29
Chipacapedronis: to unblock these people, should i tell them to snap login as root (without sudo)?15:29
Chipacasounds horrible15:29
pedronisI don't know15:30
pedronisChipaca: remind me why sudo wouldn't work?15:30
Chipacapedronis: because we detect sudo and grab the actual user id15:30
pedronisah15:30
pedronisso yes, maybe15:31
pedronisor they stay without updates15:31
Chipacahmmm15:31
Chipacapedronis: autorefresh is done with userID 0, so no15:40
zyga-solusmvo: ha15:40
zyga-solusmvo: I have a log15:40
pedronisChipaca: no, what?15:40
zyga-solusmvo: and it looks suspicious15:40
Chipacapedronis: doing snap login as root15:40
pedronis?15:41
mvozyga-solus: suspicious in what way? is it not resdtarting15:41
Chipacapedronis: "should i tell them to snap login as root" <- no15:41
zyga-soluscorrect15:41
pedronisChipaca: it would fix stuff no?15:41
zyga-ubuntuerror: when trying to listen on /run/snapd.socket: socket "/run/snapd.socket" already in use15:41
Chipacapedronis: the _snapd user_ is 0, not the system user15:41
zyga-ubuntuthat's the error15:41
zyga-ubuntuthen snapd dies15:41
zyga-ubuntu(I presume)15:41
pedronisChipaca: ah, so whoever logged in first?15:41
Chipacapedronis: no, that's 115:42
Chipaca0 is no-one15:42
zyga-ubuntumvo: I used > rather than >> so I don't know anythin more, restarted now to get earlier logs15:42
pedronisChipaca: mmh, ok15:42
pedronisso no, there's no workaround15:42
pedroniswe need to fix all the things15:42
zyga-ubuntumvo: perhaps we could consider doing this in 14.04 package15:43
zyga-ubuntu+ExecStart=/bin/sh -c "@libexecdir@/snapd/snapd >>/var/log/snapd.log 2>&1"15:43
zyga-ubuntuand add a logrotate.d entry15:43
mupPR snapd#4117 closed: many: make ignore-validation sticky and send the flag with refresh requests (2.29) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4117>15:44
mvojdstrand: can we get 4114 targeted for 2.29 as well please? i.e. start from upstream/release/2.29 and cherry-pick the commits please15:45
mvozyga-ubuntu: hmmm, interessting. and strange. so you get this error when it tries to restart?15:46
zyga-solusmvo: yes, that's the only thing in the log after the test15:47
zyga-solusmvo: I fixed the unit to append to the log now15:47
zyga-solusmvo: so we can know more in 15 minutes15:47
mvocool15:47
pedronisChipaca: I think we are converging toward the idea that private snaps are mostly for development, but this will bite also paid snaps15:47
Chipacapedronis: what does "mostly for development" mean?15:48
Chipacathey still need to be refreshed, surely15:49
pedronisChipaca: I don't know15:51
jdstrandzyga-solus: this popped out: http://paste.ubuntu.com/25873639/ on 17.10 classic with core from candidate15:53
pedronisChipaca: anyway afaict this never worked, it's not a regression, no?15:54
jdstrandzyga-solus: I wasn't doing anything special. I can say that this snap plugs every interface via a corresponding command (I'm writing a spread test)15:54
zyga-solusjdstrand: hey15:54
zyga-solusjdstrand: mvo noticed this on the forum15:54
zyga-solusjdstrand: this is not a new bug but we fixed logging15:55
jdstrandzyga-solus: but ultimately just a missing rule15:55
zyga-solusjdstrand: logs from snap-update-ns now actually show up15:55
jdstrandthat's nice :)15:55
zyga-solusjdstrand: thank you for looking at this!15:55
=== cachio_lunch is now known as cachio
jdstrandzyga-solus: I'm trying to get my spread test working. will you fix the profile or shall I?15:55
zyga-solusjdstrand: note that we had a very very old rule for fonts that we never implemented but this was recently done by jamesh15:56
=== JoshStrobl|AFK is now known as JoshStrobl
pedronisChipaca: or maybe it worked when we were running refresh in a timer and if somebody did login as really root?15:56
zyga-solusjdstrand: I'm looking at 14.04 but I can switch to that next, feel free to ignore if you have more urgent things15:56
cachiomvo, any updates for the 29.1?15:57
jdstrandzyga-solus: I probably won't get to it today (lots to do before I go eow), but if I have time and I see you haven't done it, I'll try15:58
zyga-solusjdstrand: sounds good, I'll try to do it soon15:59
zyga-solusjdstrand: should be easy rule tweak15:59
zyga-solusjdstrand: spread test will be "hardest" ;-)15:59
pedronismvo: did you merged the workaround for 14.04 ?16:00
zyga-soluspedronis: not yet16:01
jdstrandmvo: https://github.com/snapcore/snapd/pull/413016:03
mupPR #4130: interfaces: don't udev tag devmode or classic snaps (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4130>16:03
Chipacapedronis: yeah, refresh timer + no sudo handling would make this work16:04
mupPR snapd#4130 opened: interfaces: don't udev tag devmode or classic snaps (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4130>16:04
jdstrandmvo: do you want me to do the same for 4115, 4116 and 4127?16:04
pedronisChipaca: we discussed killing the timer at some point though16:04
zyga-solusjdstrand: 4130 has unrelated changes16:07
zyga-solusjdstrand: please rebase -i and drop them16:07
jdstranddang it16:08
jdstrandmeh. cherry-pick didn't do what i wanted16:08
kyrofajdstrand, what were you hoping it'd do?16:09
sergiusensmeh, snapd tests flooded the adt queue16:09
jdstrandgrab just my commit16:09
Chipacapstolowski: when do cookies get cleaned up?16:09
kyrofajdstrand, that's exactly what cherry-pick should do. What DID it do?16:10
zyga-solusmvo: I have a full log now16:10
zyga-solusmvo: we are *not* restarting16:10
zyga-solusmvo: I'll pastebin now16:10
Chipacapedronis: we'd have to store the user id in state, right?16:10
jdstrandpulled in a bunch of stuff between 2.29 and master16:10
pedronisChipaca: maybe,   or send all the macaroons we have and let the store figure it out16:10
pedronissomething to do with the new api16:11
Chipacapedronis: can we do that?16:11
Chipacaah16:11
zyga-ubuntuhttp://paste.ubuntu.com/25873750/16:11
jdstrandI think anyway. redoing16:11
mupPR snapd#4130 closed: interfaces: don't udev tag devmode or classic snaps (2.29) <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/4130>16:11
kyrofajdstrand, what did you cherry-pick? A merge commit? :P16:11
pstolowskiChipaca, see removeSnapCookie in snapstate - discardSnap16:11
pedronisChipaca: currently API take only one user macaroon (via header), but the new api could take multiple but not something we can do without discussing with store people16:12
zyga-solusmvo: ah, sorry, my grep was bad; we are restarting16:12
zyga-solusmvo: I think your workaround is safe for 2.2916:12
jdstrandkyrofa: no, the hash from my local branch16:13
mvozyga-solus: cool, waiting for spread to actually run :/16:13
Chipacapstolowski: ok, new question: why doesn't it work? :-)16:13
zyga-solusmvo: is there a topic where I can put this info? I can start a new one16:13
mvozyga-solus: I think we need a new one16:15
zyga-solusdoing that then16:16
Chipacapstolowski: (i have 1 snap installed -- core -- and 59 cookies: 23 for core, the rest for snaps that i no longer have)16:16
jdstrandkyrofa: so I did: git checkout -b foo upstream/release/2.29 ; git cherry-pick <hash from my local branch based on upstream/master>. that pulled in other commits16:17
pstolowskiChipaca, oh. that's bad. I don't know without investigating. we have a spread test that checks that, should work...16:17
* jdstrand reads man page16:17
mvojdstrand: hm, what you did looks correct16:19
pedronisChipaca: one thing to consider/issue, is that we don't have good spread tests for private snaps atm16:20
pstolowskiChipaca, hmm I can confirm I've a few leftovers on my system. but just one cookie file for core. what are the filenames of your cookies for core?16:20
mvojdstrand: I can also help, waiting for tests anyway16:20
kyrofajdstrand, yeah what you did sounds right16:21
kyrofajdstrand, can you push your local branch? I'm curious now16:22
jdstrandactually, the local branch is ok. maybe I messed something up on the github end16:24
* jdstrand tries again16:24
=== petevg|afk is now known as petevg
* zyga-solus runs another 14.04 tes16:26
zyga-solusmy earlier data had a flaw that was causing false positives, I may have a chance to see the real error now16:26
Chipacapstolowski: the filenames of my cookies?16:27
* sergiusens takes a lunch break16:27
jdstrandok, yes. I thought it picked release/2.29 for the merge but it didn't, then confusion ensued16:27
pstolowskiChipaca, /var/lib/snapd/cookie/*16:27
Chipacapstolowski: ah! i meant in staet16:27
jdstrandmvo, zyga-solus: https://github.com/snapcore/snapd/pull/413116:27
mupPR #4131: interfaces: don't udev tag devmode or classic snaps (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4131>16:27
mupPR snapd#4131 opened: interfaces: don't udev tag devmode or classic snaps (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4131>16:27
Chipacastate16:27
mvojdstrand: \o/16:27
Chipacapstolowski: in /var/libi/snapd/cookie i have snap.core16:27
Chipacas/bi/b/16:28
jdstrandmvo: ok, did you want me to do the same for 4115, 4116 and 4127?16:28
mvojdstrand: please16:28
jdstrandok16:28
pstolowskiChipaca, okay, I see junk in my state as well :(16:30
pedronisChipaca: we need to resurrect efforts in that area16:30
pstolowskiChipaca, the logic around snapst.Sequence doesn't work as expected, apparently16:30
mvoChipaca: uh, junk?16:31
Chipacamvo: yeah16:32
Chipacapstolowski: it does work sometimes though, as i have no cookies for xbill :-)16:33
pstolowskiChipaca, is there any magic around snapst.Sequence == 0 or snapst.Sequence == 1? wrong assumptions on my side around them?16:33
pedroniswell, junk, as in, too many cookies16:33
pedronisnot random data16:33
pstolowskiChipaca, yeah, as I said, there is a spread test, but it's a very simple scenario apparently16:33
pstolowskimvo, snap cookies are not always removed and left in the state and on disk16:33
mvopstolowski: hmmm, ok16:34
pedronisare they no removed? or are they created even when there's one?16:34
pedronisone almost never removes core16:35
mupPR snapd#4132 opened: interfaces/serial-port: udev tag plugged slots that have just 'path' via KERNEL (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4132>16:35
pedronispstolowski: do we have a cooke per snap? or per revision?16:35
Chipacai can confirm that it doesn't always work: i just installed a snap, removed it, and the cookie is still there16:36
Chipacanothing refresh-ish about it :-)16:36
pstolowskipedronis, right. too many are created. there should be one per snap, regardless of how many revisions you have16:36
Chipaca(i was fearing it was some weird refresh thing -- but no)16:36
pedroniscreateSnapCookie doesn't check if there is one already afaict16:38
mupPR snapd#4133 opened: interfaces/hidraw: udev tag plugged slots that have just 'path' via KERNEL (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4133>16:38
Chipacaso now i've installed and removed the same snap twice, and the first time it left the cookie behind, the second it didn't16:39
Chipacahmmm16:39
Chipacahmmm16:40
mupPR snapd#4134 opened: interfaces/uhid: unconditionally add existing uhid device to the device cgroup (2.29) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4134>16:40
pstolowskipretty weird, i just tested with brand new snap, all was cleaned up.16:40
ChipacaHAH16:41
pstolowskipedronis, but do LinkSnap does check snapst.Sequence.. should only createCookie for first snap installed. unless this is wrong assumption about sequence16:41
Chipacapstolowski: restart snapd between install and remove16:41
Chipacawe might be being too lazy wrt loading the cookies16:42
Chipacadunno :-)16:42
pedronispstolowski: install a snap, disable it, reenable it, it will create two cookies (for example)16:43
jdstrandmvo: ok, 4114, 4115, 4116, and 4127 all have PRs (4131-4134) which are milestoned to 2.29. let me know if you need anything else16:43
Chipacadelicious, delicious cookies16:44
pedronisI think16:44
mupPR snapd#4135 opened: Workaround unit test failures on Arch <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4135>16:44
pedronisI mean, I fear there are corner cases, such that just using the len of the sequence is not enough16:44
pedronisor maybe not16:45
pedronissomething is off for sure16:45
Chipacapedronis: are you digging into this?16:46
pedronisnot really16:46
pedroniswhat I see is that the code is naive, it will mutate the dict even or error16:47
pedronisthat's usually not what we do16:47
pedroniswe store things back into state usually only when we know the handler is succeding16:48
mvojdstrand: thank you16:49
pedronispstolowski: undoLinkSnap is strange there is code that check len sequence before we manipulate sequence and there is code doing the check after for something else16:53
pstolowskipedronis, Chipaca I think the main problem is in snapmgr.GenerateCookies, i think this is the main source of duplicates16:54
pedroniswhy would it be ?16:54
pedronispstolowski: UnlinkCurrentSnap has no remove cookie16:55
pedronisthat's also strange16:55
Chipacait seems every time i start snapd i get more cookies16:56
Chipacagah!16:56
Chipacapstolowski: you're right16:56
pstolowskipedronis, the snap-cookies map uses cookieId as a key, GenerateCookies uses snap name as a key; I think this was changed at some point16:56
Chipacapstolowski: yep, that's where these are coming from16:56
pstolowskiand this method got out of sync16:57
pedronis:/ blargh16:57
pstolowskiand perhaps there are edge cases as you say pedronis16:57
Chipacabut also, agreed about pedronis wrt cookies not getting cleaned up on handler failure16:57
Chipacas/about/with/16:57
Chipacapstolowski: in a handler every return error needs to undo everything the handler did in there16:57
zyga-solusdrat 14.0416:57
zyga-solussystemd behaves super oddly16:58
zyga-solusquick coffee break16:58
pstolowskipedronis, Chipaca I'll work on a fix. but I'm abit unclear about doDiscardSnap vs UnlinkCurrentSnap, isn't discard snap the only place to do it?16:58
pedronisand there is something strange about unlink-current-snap vs its undo  (the latter create a cookie but the former doesn't remove it)16:58
pedronispstolowski: it depends16:58
pedronisthere are various way to it16:58
pedronisbut whatever you do needs to be balanced16:58
Chipacapstolowski: removing the 'break' in removeSnapCookie should go a long way to cleaning this up :-)16:59
Chipacaanyway. cuppa tea.16:59
* Chipaca afk16:59
pedronispstolowski: it's a bit late for me, but we can chat another day about this,  what I'm noticing is that the remove/creat don't seem symmetrics to me atm17:00
pstolowskiChipaca, I know I know...17:00
pedronisand also that we Set cookies into the state too early in the handlers17:00
pstolowskipedronis, k, thanks for taking a look at this.. I'll investigate further17:00
mupPR snapcraft#1653 opened: internal: don't reuse variable in OsRelease <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1653>17:15
mborzeckiok guys, i'm calling it a day17:15
=== mborzecki is now known as mborzecki|afk
ChipacaYESSS17:31
Chipacait works17:31
* zyga-solus hugs Chipaca 17:31
Chipacazyga-solus: wait until you see it :-)17:31
Chipacaanyway, forum, and then eod17:31
zyga-solusI'm in 14.04 land17:33
zyga-solusgetting closer17:33
zyga-solusfeels very weird17:33
* Chipaca hugs zyga-solus 17:35
Chipacazyga-solus: you're needing them more than me!17:35
zyga-solusChipaca: hehe17:35
Chipacasystemd *and* 14.0417:35
zyga-solusChipaca: the 14.04 abyss hugs me all the time17:35
* ogra_ wasnt aware there is a 14.04 solus 17:35
zyga-solusogra_: offtopic, I recently installed windows on my thinkpad17:36
ogra_so where is the zyga-windows nick then ?17:37
zyga-solusogra_: so ubuntu 17.10, vm with windows 10, WLS inside17:37
zyga-solusogra_: to see what kind of "kernel" features are available :)17:37
ogra_heh17:37
zyga-solusogra_: nah, I don't run irc from zyga-ubuntu-windows-wsl-ubuntu17:37
zyga-solus:D17:37
mupPR snapd#4131 closed: interfaces: don't udev tag devmode or classic snaps (2.29) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4131>17:42
mupPR snapd#4128 closed: Revert " wrappers: fail install if exec-line cannot be re-written  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4128>18:06
zyga-solusmvo: that 14.04 bug is weird18:08
zyga-solusI have a feeling my changes are not being used18:08
zyga-solusI just added "trolololo" to a startup line to see if it shows up18:08
mvozyga-solus: hm, ok18:11
zyga-solusmvo: 10 minutes to find ut18:12
zyga-solusout18:12
zyga-solusha18:14
zyga-solusso curious now18:14
zyga-solusmy changes in outer function are picked up18:14
zyga-solusthose on the inner one are not, so I made a mistake18:15
zyga-soluslooking18:15
zyga-solusha18:16
zyga-solusI see it18:16
zyga-solusok, let's see what this unfolds18:16
zyga-soluswe seem to report one error incorrectly, swallowing the real problem18:18
zyga-solusmvo: OMG :)18:24
zyga-soluseither it's a very simple bug18:24
zyga-solusor it's very non-tricky code18:24
zyga-soluser18:24
zyga-solustricky code18:24
zyga-solusmvo: if you are still around, please open daemon.go18:24
zyga-solushmmm18:25
zyga-solusactually, no :/18:25
zyga-solusdarn18:25
* zyga-solus keeps looking18:25
mvozyga-solus: are you sure its not a external bug?18:28
zyga-solusmvo: no, just me making silly mistakes still18:28
zyga-solusmvo: that lead me astray18:28
mvozyga-solus: to me it smeels like journalctl is swallowing data18:28
zyga-solusyes but attempting to see what's really going on lead me on a goose chase18:30
zyga-solusI should now have both correct logs _and_ not disturb socket activation18:30
mvozyga-solus: great18:31
mvozyga-solus: tests are really slow today, but I hope we can still do 2.29.1 tonight, lets see18:33
zyga-solusmvo: yeah, would be good to do that18:33
zyga-solusthank you for staying longer to ensure that18:33
mvozyga-solus: there is new info from the libreoffice report in the "2.29 release cycle started" thread18:36
zyga-solusoh, great - looking18:37
zyga-solusaha18:37
zyga-solusI can fix those very quickly18:37
zyga-solusmvo: the bug is that we try rw sharing and the rules are for "ro" sharing18:38
zyga-solusoh, curious, we do request "ro"18:39
zyga-solushmm18:39
zyga-solusoh18:42
zyga-solussilly18:42
zyga-solusjdstrand: around?18:43
zyga-solusjdstrand: can you please review https://github.com/snapcore/snapd/pull/413618:44
mupPR #4136: cmd/snap-update-ns: fix mount rules for font sharing <Created by zyga> <https://github.com/snapcore/snapd/pull/4136>18:44
zyga-solusmvo: ^18:44
mupPR snapd#4136 opened: cmd/snap-update-ns: fix mount rules for font sharing <Created by zyga> <https://github.com/snapcore/snapd/pull/4136>18:44
zyga-solusmvo: I'll write a spread test18:44
zyga-solusthere's something weird still18:44
zyga-solusthe denials says flags="rw, bind"18:44
zyga-solusbut we definitely do "ro"18:44
zyga-solusso either a bug in apparmor logging or in snapd18:44
zyga-solusspread will show18:44
mvozyga-solus: this is just a warning, right?18:45
mvozyga-solus: fwiw, the refresh-undo test is also failing and it is also using journalctl output so I strongly suspect this is related18:45
zyga-solusmvo: this is a warning but the bug is real18:46
zyga-solusmvo: warning as in "I tried it and it failed"18:46
mvozyga-solus: ok18:46
zyga-solusmvo: if we could have 4113 it would be easier to test18:46
zyga-solusI'll cherry pick that in and adjust the test to cover this case18:46
zyga-solusmvo: I pushed a spread test, let's see if it passes now18:55
zyga-solusmvo: I'll get back to 14.0418:55
zyga-solusmvo: if you want a low-risk .2 cherry-pick get the 1st commit from 413618:55
zyga-solusmvo: but only if the spread test passes please18:55
mvozyga-solus: ok, please add a PR based on 2.29 for this19:02
mvozyga-solus: for this commit19:02
zyga-solusmvo: sure19:04
zyga-solusdone19:05
zyga-solusIFF the other one passes please merge it19:05
mupPR snapd#4137 opened: cmd/snap-update-ns: fix mount rules for font sharing <Created by zyga> <https://github.com/snapcore/snapd/pull/4137>19:06
zyga-solustagged and renamed19:07
mvozyga-solus: thank you19:45
zyga-ubuntumvo: I'll doze off until tests show something19:45
zyga-ubuntumvo: from what I can see socket activation is not passing the right stuff when things fail19:45
zyga-ubuntumvo: down to the environment, there's nothing there19:46
zyga-ubuntumvo: I'll keep shrinking my debug changes to see if I broke it19:46
zyga-ubuntubut now, mental break19:46
mupPR snapd#4126 closed: tests: use `snap change --last=install` in snapd-reexec test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4126>19:49
zyga-ubuntumvo: https://github.com/snapcore/snapd/pull/4136 has +1 from jdstrand (thank you!)19:53
mupPR #4136: cmd/snap-update-ns: fix mount rules for font sharing <Created by zyga> <https://github.com/snapcore/snapd/pull/4136>19:53
jdstrandnp19:53
zyga-ubuntumvo: the grammar aside (I'll fix that tomorrow) I think it's worth merging19:53
* zyga-ubuntu restarted 14.04 test with no -reuse, to see what happens on a clean system19:54
zyga-ubuntujdstrand: hey19:57
zyga-ubuntujdstrand: not sure if you have time before you go19:58
zyga-ubuntuhttps://github.com/zyga/snapd/blob/feature/transparent-tmpfs/cmd/snap-update-ns/utils.go#L13219:58
zyga-ubuntuif you can just eyeball that quickly19:58
zyga-ubuntuand tell me if this is sane19:59
zyga-ubuntu(just one function)20:00
zyga-ubuntumvo: thank you for merging master back into that fix RP20:19
zyga-ubuntu*PR20:19
mvozyga-ubuntu: yeah, keen to get results20:22
zyga-ubuntuuh20:22
zyga-ubuntuhttps://github.com/snapcore/snapd/pull/4123/commits20:22
mupPR #4123: interfaces: fix incorrect signature of ofono DBusPermanentSlot (2.29) <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4123>20:22
zyga-ubuntuWTF?20:22
zyga-ubuntuthis is weird20:22
zyga-ubuntuI'm 100% sure this was a rebased branch20:23
zyga-ubuntuwith no other stuff in it20:23
zyga-ubuntugithub playing tricks?20:23
zyga-ubuntumvo: I removed 2.29 milestone from https://github.com/snapcore/snapd/pull/413620:24
mupPR #4136: cmd/snap-update-ns: fix mount rules for font sharing <Created by zyga> <https://github.com/snapcore/snapd/pull/4136>20:24
zyga-ubuntumvo: this one is for 2.29 https://github.com/snapcore/snapd/pull/413720:24
mupPR #4137: cmd/snap-update-ns: fix mount rules for font sharing (2.29) <Created by zyga> <https://github.com/snapcore/snapd/pull/4137>20:24
zyga-ubuntumvo: I force pushed on https://github.com/snapcore/snapd/pull/412320:29
mupPR #4123: interfaces: fix incorrect signature of ofono DBusPermanentSlot (2.29) <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4123>20:29
mvozyga-ubuntu: ok, thanks. but it looks not good, tests are not running20:41
zyga-ubuntumvo: where?20:44
zyga-ubuntu4123?20:46
* zyga-ubuntu looks20:46
mvozyga-ubuntu: nowhere, almost none of the 2.29 PRs has started :/20:46
zyga-ubuntutwo failures on 4123, not sure if related to what we saw20:47
zyga-ubuntuyeah, maybe we should call it a night and just carry on tomorrow20:47
mvoyeah, it feels like it unfortunately20:49
sergiusensmvo are you doing adt?20:53
sergiusensthere is starvation going on right now http://autopkgtest.ubuntu.com/running20:54
mupPR snapcraft#1654 opened: autotools: cross-compile using --host instead of env <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1654>20:54
mvosergiusens: travis20:56
mvosergiusens: heh, bionic is doing it!20:57
kyrofasergiusens, yeah, snap builders are starving too20:58
=== JoshStrobl is now known as JoshStrobl|Food
mvozyga-ubuntu: I'm slightly sad but its no good, travis is too slow to wait for it, I will continue with this first thing in the morning21:01
* mvo waves21:01
zyga-ubuntumvo: o/21:01
zyga-ubunturest well21:01
zyga-ubuntu2017-11-02 22:01:49 Cannot allocate linode:ubuntu-14.04-64: no powered off servers in Linode account exceed halt-timeout21:02
zyga-ubuntuwell21:02
zyga-ubuntulinode tries to tell me to EOD21:02
mvohaha21:02
zyga-ubuntumore tomorrow21:02
mvoyeah21:02
mupPR snapcraft#1578 closed: project_loader: quote more environment variable values <bug> <Created by malept> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1578>21:12
kyrofasergiusens, wait... we've been waiting all day and our test hasn't even started yet. Time to run the whole thing locally?21:14
sergiusenskyrofa have you seen the size of the queue?21:15
kyrofaJust now21:15
kyrofaInsane21:15
kyrofaAlthough not for xenial:amd64, and I don't see snapcraft in it21:16
kyrofaWhich is interesting. Maybe I don't now how to use it21:16
kyrofaAll I see there is systemd21:17
zyga-solussergiusens: what is the size of the queue?21:20
kyrofazyga-solus, autopkgtest.ubuntu.com/running21:20
zyga-solusoh21:21
zyga-solus1K221:21
zyga-soluswhat is huge vs ubuntu?21:22
zyga-solusbionic has 4K tests, man21:22
* zyga-solus gets back to family, ttyl21:23
jdstrandzyga-solus: I didn't review it closely. the idea of putting something to the side so you can later get them seems ok in general. I can say that anything that is in the original is mounted twice (ie, in the original dir and then again on top)21:28
jdstrandand you won't be able to clean that up since they are underneath (assuming I didn't mis something)21:28
zyga-solusjdstrand: aha, interesting22:16
zyga-solusjdstrand: I'll think about the possible consequences22:18
zyga-solustomorrow, if we have tests back, not sure about that seeing the queue size, I will make the PR proposable22:18
=== JoshStrobl|Food is now known as JoshStrobl
sergiusenszyga-solus it is too big to have it cleared tomorrow, I don't know if there is fair queuing in play or not, but the archive adt is humongous22:37
sergiusenskyrofa snapcraft is under the upstream tests queue22:37
sergiusenssearch for snapcraft-daily22:37
kyrofaAh22:38

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