=== setuid is now known as zZZZzzetuid
mvomborzecki: great job on 7166 - thanks that this is landed now06:56
mborzeckimvo: yw, it was fun :P06:56
mborzeckimvo: btw. got a report from fedora user about snapd dying due to ABRT, got the logs eventually06:56
mborzeckimvo: what happens is that the system goes to sleep, once it's woken up systemd kills snapd due to watchdog timeout :/06:57
mvomborzecki: oh no!06:57
mvomborzecki: we can't be the only ones affected by this, this sounds like a very generic issue - or are we using the watchdog wrong in some way?06:58
mvo(I guess its a bit early to ask these questions :)06:58
zygagood morning07:00
mborzeckizyga:  hey07:00
zygamvo: thank you for the review on https://github.com/snapcore/snapd/pull/754907:02
mupPR #7549: cmd/libsnap: use cgroup.procs instead of tasks <Created by zyga> <https://github.com/snapcore/snapd/pull/7549>07:02
zygaI'm sorry for being absent on Friday07:02
zygaI was a full-time mom for the last three days07:02
pokkGood morning07:04
mvohey zyga - good morning!07:04
pokkzyga: Speaking from experiance imho that is both wonderful and sucks. I hope you get decently paid while home with sick kids at least07:04
zygapokk: paid with hugs and diapers :)07:06
pokkzyga: that's great :)07:06
zygamborzecki: can you do a 2nd review on https://github.com/snapcore/snapd/pull/7549 please07:19
mupPR #7549: cmd/libsnap: use cgroup.procs instead of tasks <Created by zyga> <https://github.com/snapcore/snapd/pull/7549>07:19
mvosil2100: good morning! could you please have a look at the pending snapd SRU in the unapproved queue? and who should I poke about universe SRUs? I did a drive-by rxtx sru to bionic on sunday to fix the arduino IDE in bionic, pretty trivial and was wondering if I need to poke someone else?07:27
sil2100mvo: hey! Let me take a look at those then07:35
mvosil2100: thank you07:35
sil2100hm, weird, someone accepted snapd to disco but didn't for bionic and xenial07:36
sil2100Anyway, looking into that07:36
sil2100mvo: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1840740/comments/307:36
mupBug #1840740: [SRU] 2.41 <verification-needed> <verification-needed-disco> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):New> <snapd (Ubuntu Bionic):Incomplete> <snapd (Ubuntu Disco):Fix Committed> <https://launchpad.net/bugs/1840740>07:36
sil2100mvo: can you address that by any chance?07:37
mvosil2100: uh, sorry, I must have missed that07:37
mvosil2100: will look into a fix, please reject07:37
sil2100mvo: ok! Give me a poke once you re-upload, I can review those then - in the meantime, I'll look at rxtx07:38
mvosil2100: thanks, will probably take a bit until I will reupload, need to medidate over this a bit :/07:39
mvo(mostly the test-case part)07:39
sil2100mvo: I suppose xenial also has the same change, so I'll reject that as well07:40
mupPR snapd#7544 closed: tests: fix snapd-failover test for core18 tests on boards <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7544>07:47
mupPR snapd#7549 closed: cmd/libsnap: use cgroup.procs instead of tasks <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7549>07:50
mborzeckimvo: based on https://github.com/golang/go/issues/19810 i think we could try to replace the time.Ticker in cmd/snapd/main.go with time.After(), but that's about the only idea i have atm07:51
mborzeckiand we ping systemd at twice the required frequency, while systemd should be smart enough to use monotonic timers07:52
=== pstolowski|afk is now known as pstolowski
mborzeckipstolowski: hey08:00
mvomborzecki: ta08:00
mborzeckimvo:  updated https://github.com/snapcore/snapd/pull/754308:12
mupPR #7543: release: make forced dev mode look at cgroupv2 support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7543>08:13
mvomborzecki: thank you, much appreciated. sorry for the nitpicking there but it took me a couple of minutes(!) before my first cup of tea to understand the defer. which probably says more about me than the code :/08:26
mborzeckimvo:  no worries :)08:27
mupPR snapd#7430 closed: overlord/snapstate: add SetTaskSnapSetup helper + unit tests <Created by anonymouse64> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7430>08:52
mborzeckizyga:  some comments in #754708:52
mupPR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>08:52
mborzeckizyga: iirc we'd stil want to degrade gracefully, but maybe my memory is playing tricks08:54
mupPR snapd#7437 closed:  wrappers/services.go: add disabled svc list arg to AddSnapServices <Created by anonymouse64> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7437>08:54
zygamborzecki: I'm not sure, we'll see08:55
zygamborzecki: thank you for the review, I should have posted the more fresh version last week but nothing is lost :) You'll see it soon enough08:55
Chipacamvo: pedronis: more and more i wonder why we did /v2/download instead of just having a download action on /v2/snaps08:55
pedronisChipaca: because of different response ?08:56
Chipacai guess it makes it easier to change our mind / fine-tune the rules for access, but eh08:56
Chipacapedronis: pr'aps. Or maybe because then we can use it to download things that aren't snaps?08:57
pedronisthat might happen08:57
Chipacapedronis: mvo: have you talked about the assertions side of 'snap download' when going via snapd?08:57
Chipacapedronis: mvo: also 'snap known --remote'08:58
pedronisChipaca: mvo added a remote option to the assertion end point08:58
mvoChipaca: yeah08:58
pedronisit has landed08:58
mvoChipaca: we are ready pretty much, hold on a sec08:58
mvoChipaca: I just chunked the PR up into small bits08:59
mborzeckizyga: so far it's looking good, all things considered the change should be rather simple as we discussed before :)08:59
zygamborzecki: yeah, I was just thinking about how to stage it08:59
zygamborzecki: perhaps the next chunk to land for real would be the cgroup alone, without the agent08:59
zygamborzecki: and after that just the agent08:59
zygamborzecki: does that sound okay?08:59
zygamborzecki: I worry that together it will be less approachable09:00
mborzeckizyga: yeah, just the cgroup change would be functionally identical to what we have now09:00
mvoChipaca: https://github.com/snapcore/snapd/compare/master...mvo5:snap-download-via-snapd?expand=1 this is the full pr, it needs a bit of polish still around the edges that are not proposed yet but once my other two prs are  merged the rest is hopefully eay09:00
mvoChipaca: fwiw, 7533 and 751009:00
Chipacamvo: pedronis: completely unrelated and so I either write it down as a TODO, or forget about it: do we want to change the cache (as in store/cache) to use the same format for sha3 as 'snap info'? right now it's different which makes it harder to use the two together09:01
mvoChipaca: I think that makes sense09:01
pedronisChipaca: in which sense together?09:01
pedronisthe cache is an implementation detail09:02
Chipacapedronis: 'snap info --verbose some-snap' tells you the sha, but you can't then look in the cache to know which file it is09:02
pedronisis this for debugging?09:02
pedronisChipaca: it means we need to look at both formats for a while?09:04
Chipacapedronis: you can always 'sudo find /var/lib/snapd/cache | sudo xargs snap info --verbose ' but that is really expensive, particularly on slow machines09:04
Chipacapedronis: yes09:04
Chipacai've added a card09:07
pedronisChipaca: we could also have snap debug list-cache or something09:07
pedronisanyway it's kind of bottom of the queue given all the things09:07
Chipacayeah :)09:07
Chipacapedronis: ooh, snap debug cache might be useful09:08
mvoyeah, thats a nice idea09:08
Chipacanot just for the snap cache09:08
pedronisChipaca: but given is low, it should really go to the forum as backlog, not as a card, we already have cards that need to move back to the forum09:11
pedronisChipaca: 19.10 TODO is really for stuff we must do09:12
pedronisit can go to upcoming if we were sure it would be done soon09:12
pedronisbut we aren't sure of that :)09:12
mborzeckipedronis: #7541 can land10:05
mupPR #7541: seed/seedwriter: support for extra snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7541>10:05
pedronismborzecki: mvo: thanks10:08
mupPR snapd#7541 closed: seed/seedwriter: support for extra snaps <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7541>10:08
pedronismvo: mborzecki: pstolowski:  #7556 is ready for review, is the actual switch to use seedwriter in image.go, there is quite a bit of red in it10:13
mupPR #7556: image,seed/seedwriter: switch image to use seedwriter.Writer <Created by pedronis> <https://github.com/snapcore/snapd/pull/7556>10:14
pedronismvo: #7462 needs a re-review10:14
mupPR #7462: asserts: introduce explicit support for grade for Core 20 models <Created by pedronis> <https://github.com/snapcore/snapd/pull/7462>10:14
mvopedronis: thanks10:15
mvopedronis: I have a look10:16
mvopedronis: just sent you a mail about something unrelated, would be great if you could have a look10:16
mvopedronis: (but not high priority)10:16
Chipacamvo: #7533 now suffering from the context conflict that mborzecki called out10:18
mupPR #7533: client: add support to use the new "download" API <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7533>10:18
pstolowskipedronis: ty10:19
mvoChipaca: let me fix it10:20
pedronisI'll swithc to doing some reviewing after lunch10:20
mvopedronis: thanks10:30
* Chipaca takes a break10:31
mborzecki- Download snap "test-snapd-dbus-consumer" (6) from channel "beta" (stream error: stream ID 1; PROTOCOL_ERROR)10:47
mborzeckimeh, again10:47
mborzeckihow did we fix it the last time?10:48
mvomborzecki: maybe its failing 3 times?10:48
mvomborzecki: we only retry for protocol errror10:49
mvomborzecki: so if it happens multiple times in the same stream eventually it fails iirc10:49
mvomborzecki: what pr is that?10:49
mborzeckimvo:  https://github.com/snapcore/snapd/pull/754310:49
mupPR #7543: release: make forced dev mode look at cgroupv2 support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7543>10:49
mborzeckimvo: https://travis-ci.org/snapcore/snapd/jobs/59446669510:49
mborzeckimvo: from the logs it does not look like snapd retried due to PROTOCOL_ERROR10:52
mvomborzecki: I see some retries here10:52
mvomborzecki: let me look further10:53
mborzeckimvo: i must be looking at other tests, I see a retry due to unexpected EOF and then there's protocol err but no retry10:53
mvomborzecki: oh, interessting, I have one tests here with "Retry because of: stream error: stream ID 1; PROTOCOL ERROR10:55
mvomborzecki: but I have no looked at all of them yet10:56
mborzeckimvo:  one failure also kept getting &errors.errorString{s:"unexpected EOF"}10:56
mvomborzecki: yeah10:57
mvomborzecki: I think I see what you see, one test seems to not retry10:57
mvomborzecki: I wonder if different bits of the code in http2 produce slightly different protocol errors or what is going on there, its very strange10:58
* mvo should look closer before making strong assertions like "very strange"10:58
mborzeckimvo: perhaps, but we look for 'PROTOCOL_ERROR' which appears in the non retry case too10:58
mborzeckimvo:  and it's the same ubuntu 16.04-32 system, so cannot be go version change at play10:59
mvomborzecki: right, in the log it seems like the total time of the attemp is ~3m30 so things looks pretty bad11:03
mvomborzecki: to download yq11:03
mvomborzecki: so maybe just a fastly issue?11:03
zygamborzecki: I updated https://github.com/snapcore/snapd/pull/754711:07
mupPR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>11:07
zygamborzecki: I think it has a chance to pass and get merged now11:07
zygamborzecki: I will put the agent on hold for a sec and do a branch from this to fix setting up cgroup for classic snaps as well (the omission I mentioned earlier)11:08
zygamborzecki: then come back to integrate the agent11:08
zygarogpeppe: hello11:10
rogpeppezyga: hiya11:10
zygarogpeppe: do you have any updates for us? is there a chance to get the SD image?11:10
rogpeppezyga: unfortunately my dad thought he'd dropboxed the image before going away, but only did a zip file with just the script instead, sadly11:11
zygaah, I see11:11
rogpeppezyga: so i'm waiting for him to get back from his travels (soon, I think)11:11
zygathat's okay, just keep us posted if you can get the image11:11
zygathank you :)11:11
zygawe are moving some stuff behind the scenes to make the pi more reliable in conjunction with other developers from beyond the snapd team11:12
zygait's not something that will be done overnight but I think that at least one annoying thing can be fixed in the next one or two releases (the reboot getting stuck there)11:12
Chipacamborzecki: did you save the protocol error log?11:19
mborzeckiChipaca: i still ahve the log opened11:20
Chipacamborzecki: can you get at the 'raw' log?11:20
pedronispstolowski: I did pass over 7355, just nitpicks of various importance11:20
pedronis*a pass11:20
mborzeckiChipaca: sure, just a sec11:20
pstolowskipedronis: ty11:21
mborzeckiChipaca: https://paste.ubuntu.com/p/bFgCsXWvzX/11:22
pedronispstolowski: a question could we/should we consider using SetupMany in setupSecurityByBackend ?11:24
Chipacamborzecki: mvo: AFAICT the problem is that we got protocol error not on doing the request but on downloading11:29
Chipacamborzecki: mvo: i.e., we might need to add the same check to ShouldRetryHttpResponse?11:29
mvoChipaca: aha, I missed that11:29
Chipacanot sure tho11:29
mborzeckiah, it's called directly in the store package11:30
mborzeckiChipaca: duh, but we call SHouldRetryError() there too11:31
Chipacamborzecki: yeah i was wrong (surprise!)11:31
Chipacathe RetryHttpResponse will say yes because it's 20611:32
Chipacawait, no, it'll say no for that same reason11:32
pstolowskipedronis: indeed! good idea, we could save a little there as well. i can do in a followup11:41
mupPR snapd#7557 opened: interfaces/mount: account for cgroup version when reporting supported features <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7557>11:50
mborzeckizyga: ^^11:51
zygamborzecki: we don't have 31 tests yet, right?11:52
mborzeckizyga: we don't, there was an image cachio prepared a while ago, but that was before 31 branched iirc11:52
zygaI see11:52
zygait would be good to discuss this today11:52
zygaI could use 31 image11:52
* Chipaca takes a deep breath and reminds himself he's not here to remove the stupid from random people11:53
* Chipaca goes to check on lunch11:53
* mvo hugs juliank for his command-nof-found upload11:54
ograwill that finally fix core18 ?11:56
mborzeckioff to pick up the kids12:12
pedronismborzecki: did a pass with some questions on the timeutil bits of #744312:14
mupPR #7443: timeutil: fix schedules with ambiguous nth weekday spans <Bug> <Needs Samuele review> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7443>12:15
pedronisChipaca: do you remember why given it takes at most one snap we support taking multiple in the json to /download?12:40
mupPR snapd#7558 opened: boot,dirs,image: various refinements in the prepare-image code switched to seedwriter <Created by pedronis> <https://github.com/snapcore/snapd/pull/7558>12:50
=== ricab is now known as ricab|lunch
mupPR snapd#7543 closed: release: make forced dev mode look at cgroupv2 support <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7543>13:13
bloodearnestChipaca: o/ - to follow up on refresh issues from last week - when do the systemd files get regenerated in the refresh action? It looks like at some point we're getting services started that are pointing at old snaps working directory13:21
Chipacabloodearnest: if you have a recent 'refresh' change13:25
Chipacabloodearnest: you can 'snap tasks --last=refresh'13:25
bloodearnestChipaca: thanks13:26
Chipacabloodearnest: but it is: run pre-refresh hook, stop services, remove aliases, remove current symlink, copy data, … , post-refresh hook, start serviecs13:27
bloodearnestChipaca: does start services include generating the systemd files?13:32
bloodearnestBecause the services seem to be starting up with the old working directory13:32
zygamborzecki: hey13:38
zygamborzecki: can you quickly decide if I should open the named cgroup PR (away from draft mode)13:39
zygamborzecki: or finish the change to include classic snaps as well first13:39
mborzeckizyga: i think it's ok to open it now while to code is small, then classic can be done later as part of #7302 (or an intro to that PR)13:40
mupPR #7302: cmd/snap-confine: add support for parallel instances of classic snaps, global mount ns initialization <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7302>13:40
zygaokay, I'll do so now13:40
zygamborzecki: https://github.com/snapcore/snapd/pull/7547 is open now13:42
mupPR #7547: many: use a dedicated named cgroup hierarchy for tracking <Created by zyga> <https://github.com/snapcore/snapd/pull/7547>13:42
zygamborzecki: do you want to add that snap mount unit to 7302?13:42
ackkzyga, hi, it seems I managed to reproduce the issue with "snap try" and rsyncing files, leading to snapd not finding the executable in the snap13:43
zygahey, cool, do you have it scripted by any chance?13:43
mborzeckizyga: i'll try a separate PR, just to see the whole spread suite run13:43
zygasomething we can play with and debug?13:43
zygamborzecki: Ok13:43
ackkzyga, no, I don't have a way to reproduce it, it just happens13:44
ackkzyga, but I could debug, if you have commands I can run13:44
zygaackk: what is the error message you see that is the immediate problem?13:44
ackk$ maas13:45
ackkexecv failed: No such file or directory13:45
ackkzyga, ^13:45
zygaare you able to execute more commands now to explore this?13:45
ackkzyga, and of course, $SNAP/command-maas.wrapper and $SNAP/bin/maas (which is called by that one) are there13:45
ackkzyga, yeah13:45
zygaackk: can you ls -ld /snap/maas/current13:45
ackkzyga, lrwxrwxrwx 1 root root 2 Oct  7 10:23 /snap/maas/current -> x113:46
zygaackk: snap run --strace=raw maas13:46
zygaackk: is x1 the expected correct revision?13:46
zygaackk: cat /proc/self/mountinfo | grep -F '(deleted')13:46
ackkzyga, yes13:46
zygafix the quote please13:46
ackkzyga, nothing there13:46
ackk$ snap run --strace=raw maas13:47
ackkerror: exit status 113:47
zygaackk: cat /proc/self/mountinfo | grep maas13:47
ackkzyga, FTR this is in a bionic container13:47
zygaright, I recall those are used13:47
zygaand are most likely a factor13:47
zygaI'd love to understand what's the key bit that is broken13:47
ackkzyga, https://paste.ubuntu.com/p/8VcMZhmtrS/13:47
zygaackk: dmesg | grep DENIED13:48
zygaackk: also, sudo nsenter -m/run/snapd/ns/maas.mnt -- in the resulting shell cat /proc/self/mountinfo | grep -F deleted13:49
ackkzyga, on the host or in the container?13:49
ackk(the dmesg)13:49
zygaackk: hmmm, should be the same AFAIK13:49
zygaso either13:50
ackkzyga, I used to run snappy-debug on the host, or I would miss some denials13:50
ackknot sure if it's relevant13:50
zygahmm, perhaps there's something I don't understand about lxd13:50
zygatry on the host please13:50
ackkzyga, https://paste.ubuntu.com/p/JSXhbrR4PV/13:50
ackkzyga, empty result for deleted mountinfo13:51
zyga[92186.616879] audit: type=1400 audit(1570431426.676:2750): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-maas_<var-snap-lxd-common-lxd>" profile="/snap/snapd/4605/usr/lib/snapd/snap-confine" pid=4605 comm="snap-confine" family="netlink" sock_type="raw" protocol=15 requested_mask="send receive" denied_mask="send receive"13:51
zyga<- this is interesting, separately from the issue that affects you13:51
zygaackk: can you navigate around in that nsenter shell, to see if the executables are where you expect13:52
ackkzyga, this would be basically $SNAP right?13:52
zygayeah, but SNAP is not set, so manually13:52
zygaackk: one more idea, SNAP_CONFINE_DEBUG=yes snap run ... (as you run maas otherwise)13:52
ackk$ SNAP_CONFINE_DBUG=yes snap run -- maas --help13:53
ackkexecv failed: No such file or directory13:53
ackkzyga, ^13:53
ackkzyga, afaict executables are there in the right place13:54
zygaDBUG vs DEBUG13:54
zygainteresting, perhaps it is failing to exec something other than the app13:54
ackkzyga, http://paste.ubuntu.com/p/jdKzRHbFsH/13:55
zygaholly molly13:55
zygaI suspect I know what this is13:55
zygafrom the nsenter shell13:55
zygacan you ls -ld /usr/lib/snapd/snap-exec13:55
Chipacabloodearnest: sorry, missed your question. Actually writing the service files is part of the "link-snap" step, i.e. "make snap available to the system"13:56
zygaackk: this is a core18 system?13:56
zygaackk: as in13:56
zygaackk: a classic system with core18 and snapd snap?13:56
ackkzyga, correct13:56
ackkzyga, snap-exect not found13:56
ackkzyga, bingo :)13:57
Chipacabloodearnest: i'm very curious to know what the cause of the weirdness you're seeing is, fwiw13:57
zygaand you happen to follow which snapd channel?13:57
zygaackk: ls -ld /usr/lib/snapd13:57
Chipacabloodearnest: if you're looking at 'snap tasks --last=refresh' note you might also find interesting info in 'snap debug timings --last=refresh'13:57
ackkzyga, http://paste.ubuntu.com/p/wTsT8yPBHF/ tl;dr all stable13:57
ackkzyga, /usr/lib/snapd is there13:58
zygais it a directory?13:58
zygawhat's in it?13:58
ackkzyga, yes: drwxr-xr-x 2 root root 0 Oct  1 05:44 /usr/lib/snapd13:58
ackkzyga, but, empty13:58
zygaI strongly suspect I know what this is13:58
zygamvo: ^13:59
zygaackk: the good news, it's high up our stack13:59
zygaackk: the bad news, it's not your system, it's a real general bug13:59
zygaackk: can you do snap changes please?13:59
ackkzyga, well, makes me feel less bad :)13:59
ackkzyga, in the nsenter or outside?13:59
mvozyga: oh no13:59
zygaackk: outside please13:59
zygaackk: is this reported anywhere?13:59
zygaackk: I think  you might have already14:00
zygamvo: I think the tools problem is more severe14:00
ackkzyga, http://paste.ubuntu.com/p/2MdPHqdyfd/14:00
zygamvo: with enough rotations I suspect we unmount /usr/lib/snapd from actively used namespaces14:00
ackkzyga, I don't remember if I did report it, unfortunately I never found a reliable way to make it fail. since last time we talked about it, it hasn't happened anymore and I tried a loop of rsync's14:00
zygaackk: can you attempt to pinpoint when the issue occurred for you this time?14:00
zygaackk: in that log, at which time was it14:00
zygaackk: was it _before_ all of this?14:01
ackkzyga, no, I mean I've "snap try"'d and removed a bunch of times14:01
ackkzyga, but basically snap try , bunch of rsync -> broken14:01
ackkzyga, I didn't snap try from an already installed snap, if that helps14:01
zygaI wonder if snapd refreshed in the middle of all the "snap try" commands anywhere14:02
Chipacamvo: pedronis: wrt downloads, if we want top drop action and change snaps to snap, we should do that before or together with 751014:02
ackkzyga, the snapd snap says refreshed 33d ago14:03
zygain that case I know less, it's not my initial assumption14:03
pedronisChipaca: for clarity (hopefully) I wrote this, related to channel stuff, https://trello.com/c/GTSFCPG5/292-do-not-switch-tracks-with-risk-only-channel-specification-snap-refresh-switch#comment-5d9b456d31aa8d1b410bcdc214:03
zygaackk: the maas snap has a configure hook?14:03
ackkzyga, yes14:04
ackkwhich does a lot14:04
zygaso each snap try runs stuff14:04
ackkzyga, correct14:04
zygaackk: can you please share the exact rsync command you are using14:04
zygaI'll try to reproduce this with a demo snap with a configure hook14:04
mupPR snapd#7559 opened: tests: change regex to validate access to cdn during snap download <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7559>14:05
ackkzyga, https://paste.ubuntu.com/p/B69smBJ73N/14:05
ackkzyga, where build/dev-snap/prime is the prime dir that gets snap try'd14:06
mvoChipaca: in a meeting right now14:06
zygaand on the container you "snap try build/dev-snap/prime?14:06
ackkzyga, correct14:06
zygahmm, for now I have no more ideas14:07
zygathank you for reporting this again14:07
zygaI'll write a test tomorrow and see if I can hit something14:07
zygayour host is 16.04 or something newer?14:07
zygathe container was 18.04 IIRC14:07
bloodearnestChipaca: thanks, testing a new release now, will report back14:08
ackkzyga, my host is bionic14:10
ackkzyga, sorry, it's dingo14:10
zygaah, perfect.14:10
zygaso I have the same setup readty14:10
zygaok, I'll keep you posted, thank you again14:10
ackkzyga, thank you for the help14:10
=== ricab|lunch is now known as ricab
pedronisChipaca: mvo: I would do that I think (I find the current state confusing with all the extra checks)14:15
pedronismvo: what's the status of this https://github.com/snapcore/core/pull/83 ?14:40
mupPR core#83: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>14:40
mvopedronis: I think it never got reviews :/14:41
mvopedronis: I can fix the conflict and double check that its up-to-date14:41
pedronismvo: reviews from whom? foundations?14:42
pedronisthere's a review by ogra fwiw14:42
mvosil2100: silly question, should the split of snapcore/pi3-gadget be on snapcore/pi-gadget (the "unified" one we use in core18)14:42
mvosil2100: actually I guess I should ask in the PR14:43
ograpedronis, well, more a yoga lesson :) but yeah ... +1 for that one14:44
* cachio lunch14:46
pedroniszyga: is this being or was fixed: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1785410 ?14:46
mupBug #1785410: Can not open Gnome snaps as they are not connected to «gnome platform snap» <amd64> <apport-bug> <bionic> <snapd:Triaged by zyga> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1785410>14:46
mvoChipaca: I missed the earlier bits, what should happen with 7510? we remove "action=download"?14:47
Chipacamvo: either in 7510 or before it, we drop action and change snaps to snap14:48
mvoChipaca: ok, will do14:49
pedronismvo: probably best to call it snap-name,  we might have download by id14:57
mvopedronis: great advise14:58
zygapedronis: not sure if this instance, many similar issues were14:59
zygamany issues having similar observable result14:59
zygaI'll inspect that bug and respond15:00
pedroniszyga: you made a card specifically about this one, that's why I'm asking: https://trello.com/c/CFDRWAg5/206-content-connection-issues-https-launchpadnet-bugs-178541015:00
* zyga breaks to rest 15:08
mupPR snapd#7560 opened: daemon: change /v2/download API to take "snap-name" as input <Created by mvo5> <https://github.com/snapcore/snapd/pull/7560>15:18
mvoChipaca: -^15:20
mvopedronis: a quick review on 7560 would be great, should be quick and simple15:32
pedronismvo: I was already looking at it15:33
* mvo hugs pe15:35
* mvo hugs pedronis 15:35
pedronispstolowski: this is done now, right?  https://trello.com/c/2lsJLlXB/316-revisit-fix-per-revision-snap-configuration-handling16:19
pstolowskipedronis: yes16:22
pedronispstolowski: is it in 2.42 or will it be in 2.43 ?16:27
pedronisChipaca: this is done now:  https://forum.snapcraft.io/t/expose-a-more-consistent-subset-of-systemds-service-directives/2268 ?16:45
mupPR snapd#7560 closed: daemon: change /v2/download API to take "snap-name" as input <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7560>16:48
mupPR snapd#7561 opened: tests: update system-usernames test now that opensuse-15.1 works <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7561>16:50
Chipacapedronis: not yet, not in full16:50
cachiozyga, hey16:51
cachiozyga, I am trygin to fix an issue in opensuse16:52
pedronisChipaca: when you have a moment could you update it to reflect what is missing? or maybe create a new post if you think it's too old to reopen, in which case remove the tagging on the first, thank you16:52
cachioit is just happening with the last update16:52
pstolowskipedronis: 2.42. however it was only a small cleanup (not a fix)17:06
pstolowskipedronis: i mean, nothing for release notes imho17:06
zygacachio: snapd is built without apparmor on opensuse leap17:11
zygathat test should not run there17:11
zygacachio: check exclusion rules please17:11
cachiozyga, systems: [-ubuntu-core-*, -debian-*]17:14
cachioit is currently running on leap 15.117:14
pedronispstolowski: thx, just wanted to know which done lane to use17:32
mupPR snapcraft#2709 closed: incorporate content provider snaps in dependency resolution <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2709>18:25
=== pstolowski is now known as pstolowski|afk
joedborghey zyga, have you got 5 minutes?19:09
mupPR snapd#7562 opened: tests: chech the apparmor_parser when the file exists on snap-confine test <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7562>19:28
=== zZZZzzetuid is now known as setuid
mupPR snapcraft#2743 opened: meta: warn about command mangling <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2743>20:52
mupPR snapcraft#2744 opened: project_loader: load build-environment after snapcraft environment <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2744>22:19

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