/srv/irclogs.ubuntu.com/2020/02/06/#snappy.txt

=== plars_ is now known as plars
=== Raboo__ is now known as Raboo
=== chesty_ is now known as chesty
bdxhello01:48
bdxI just threw up this question on discourse: https://forum.snapcraft.io/t/lxd-profile-for-content-interface-bind-mounts/1534401:48
bdxtrying to get some hits01:48
bdxpossibly ill dig a little deeper and ask on the lxd side of things too as it seems to be more of a lxd/lxc thing01:49
bdxthought I would start here01:50
bdxthanks!01:50
mborzeckimorning06:30
mborzeckimeh, wish we could access the console of spread nodes07:51
Saviqhey, is there a way to make snapd skip confinement when:07:59
Saviqsystem does not fully support snapd: apparmor detected but insufficient permissions to use it07:59
mborzeckiSaviq: i don't think so, where did you get that message?08:02
pstolowskimorning08:02
mborzeckipstolowski: hey08:02
Saviqmborzecki: I've a VPS (a container actually) at a friend's08:03
Saviqit's his custom kernel, though08:04
mborzeckiSaviq: looking at the code, we're trying to poke /sys/kernel/security/apparmor/profiles as root with some comments that problems can happen in unprivileged lxd08:08
mborzeckiSaviq: anyways, it's a sanity check so further snapd operation will be blocked sadly, we dont' really have a mechanism to degrade apparmor support in this scenario08:10
Saviqack, thanks :/08:11
Saviqmborzecki: so the solution would be to get permissions to actually set up apparmor inside the container?08:11
mborzeckiSaviq: yes, i believe so08:12
mborzeckiSaviq: simplest check would be to run aa-status as root inside the container08:13
Saviq"You do not have enough privilege to read the profile set."08:13
mborzeckiSaviq: yeah, that's what snapd is hitting too, maybe zyga remembers more details about that08:31
mborzeckimvo: pedronis: hi08:32
mvohey mborzecki08:32
mvoand good morning pedronis08:32
Saviqmborzecki: thanks, will negotiate with the hoster ;)08:32
mborzeckimvo: i was looking through 'reflash magic' setup, did an update to grub script, but there's more problems08:32
mvomborzecki: uh, like what?08:32
pedronismvo: I fixed Stop, bit ugly (indeed it needs to use syscall.Select)08:36
mborzeckimvo: ah, w8, maybe not :P sorry to cause panic, thought we added --image-size <somelargesize> to the u-i08:37
mvopedronis: thank you, did you push it already?08:37
pedronismvo: no, I need to clean up what I have08:37
mvopedronis: cool08:37
mvopedronis: yeah, sleeping over it I think without a proper fix this is too nasty so thank you so much for fixing it08:37
pedronismvo: I don't know about nasty, but is definitely confusing08:38
pedronisbecause a Stop that doesn't stop is confusing :)08:38
mvopedronis: exactly :)08:38
mborzeckimvo: have you tried this maybe https://gist.github.com/mvo5/fa14638782fe30949998096d7b3c6314#gistcomment-3167661?08:39
mvomborzecki: did you try it for the netlink socket?08:39
mvomborzecki: let me quickly give it a  go08:39
mvomborzecki: I think the issue is that go is "smart" and determines if it can poll the socket or not and for netlink there is just no support08:40
mborzeckimvo: right, the change i did is make it nonblocking before wrappint ig as os.NewFile(), the implementation chceks whether the fd i non-blocking and sets up a poller for it08:40
pedronismvo: I tried that08:40
pedronissorry08:41
pedronismborzecki: I tried that08:41
pedronisbut go doesn't consider it non-blocking08:41
pedronisand doesn't set up netpoll for it08:41
pedronisfor a netlink socket08:41
pedronisbecause it's actually the reverse08:42
mborzeckipedronis: i stepped through it with debugger, and was hitting the non-block kind08:42
mborzeckipedronis: which go version did you use?08:42
pedronismborzecki: yea, but that's not relevant08:42
pedronisit's whether netpoll is happy with08:42
pedroniswhich it isn't indeed08:42
pedronisgo wil set up non blocking itself08:42
pedronisif netpoll is happy08:42
mvoit's interessting, I tried mborzecki version with netlink and it seems to stop the socket https://paste.ubuntu.com/p/Y2z9dh8rDT/08:44
* mvo scatches head08:44
pedronisdifferent go versions?08:44
mvopedronis: I have 1.12 on one and 1.13 on the other, let me try again08:45
pedronison 1.1008:45
pedronisit didn't work for me08:45
* mvo tries that too08:45
mborzeckipedronis: mvo: https://github.com/golang/go/commit/ea5825b0b64e1a017a76eac0ad734e11ff557c8e 1.11+08:47
mborzeckithat would explain what pedronis saw08:48
pedronisanyway we are still 1.908:48
mborzecki:/08:48
mvoyeah08:48
mvothat makes sense now08:48
mvoslightly sad08:48
mborzeckimvo: do we care if it leaks though?08:49
pedronismborzecki: it's messy interface wise08:49
pedronisespecially in tests08:49
pedroniswe would need to change the interface to not have a Stop08:50
pedronisetc08:50
pedronisit's not pleasant to reason about08:50
mborzeckipedronis: maybe we could do some extra mocking for tests08:51
pedronismborzecki: as I said I have a fix08:51
pedronisis not beatiful, but I will make localized and leave a TODO for when we are 1.11+ or something08:51
mborzeckipedronis: mvo: do we need to check udev monitor as well?08:53
pedronismborzecki: there's an indirection there that doesn't make the problem apparent08:53
pedronisbut yes osutil/udev has the same kind of bug08:53
mborzeckimvo: do you know if there's a way to access the console of spread system when cachio is not around yet?08:58
mvomborzecki: afaik there is none :(08:59
mupPR snapd#8097 opened: tests/lib/prepare: fix hardcoded loopback device names for UC images <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8097>09:07
mborzeckimvo: trivial change ^^09:08
mvomborzecki: ta, looking09:08
mupPR snapd#8092 closed: timeutil: add a unit test case for trivial schedule <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8092>09:26
mupPR snapd#8098 opened: httputil: remove workaround for redirect handling in go1.7 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8098>09:53
mupPR snapd#8099 opened: httputil: remove go1.6 transport workaround <Created by mvo5> <https://github.com/snapcore/snapd/pull/8099>09:58
zygaHey, just waving. Still sick and weak. Sorry10:20
mvozyga: hey, nice to see you! get well10:21
zygaUh, I hate this state I’m in. I’ll check back later.10:21
mvozyga: yeah, being sick sucks10:22
zygapstolowski: could you please re review the uio branch. We removed some code.10:24
pstolowskizyga: will do10:27
pedronismvo: I pushed this branch: https://github.com/pedronis/snappy/tree/netlink-channel-n-stop10:37
mvopedronis: thanks, looking10:40
zygapedronis: if you guys want I have a epoll.go package10:41
mvopedronis: this is super nice, thanks for this10:48
mborzecki        cp -a "$SNAPD_UNPACK_DIR/usr/lib/snapd/snap-bootstrap" unpacked-initrd/main/usr/lib/snapd/snap-bootstrap10:50
mborzecki#8097 trivial pr, needs 2nd review10:50
mupPR #8097: tests/lib/prepare: fix hardcoded loopback device names for UC images <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8097>10:50
mborzeckiand a bit of my clipboard :)10:50
mvomborzecki: haha10:50
mvopedronis: do you want to propose it as a separate pr or should I cherry pick it into my netlink pr?10:50
mborzeckimvo: what's funny is that the same repackign code running in qemu builds a working kernel snap, but one on gcp panics with no init, probably borked initrd10:51
pedronismvo: mmh,  ideally we should split in everyhting but the new netlink bits10:51
pedronisand then you could pick those10:52
mborzeckiglad at least we can download the build uc20 image from spread system10:53
mvopedronis: sounds good,I can take your code and chunk it into smaller PRs, I guess this is what you asked?10:54
pedronismvo: yes, one PR with the non netlink-bits10:55
pedronisand the rest picked up by your PR10:55
pedronismvo: thanks if you can do that, I'm doing spec work atm10:55
pedronismvo: sorry, I mean the not new netutil netlinks bits10:56
pedronisbasically osutil/udev and o/ifacestate10:56
mvopedronis: thanks, yeah, happy to do that10:57
mupPR snapd#8097 closed: tests/lib/prepare: fix hardcoded loopback device names for UC images <Simple 😃> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8097>11:14
jameshsergiusens: did you see my query on the forum? (re. github actions)11:23
pedronisjamesh: hi, did you see my last bit of comments on #7456 ?11:26
mupPR #7456: usersession/client: add a client library for the user session agent <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7456>11:26
jameshpedronis: yeah.  I'm just tidying up some of the tests for it.  In these cases we have an error message from the agent, so I'm not sure whether we want to lose that when the error value is badly formed11:28
mupPR snapd#8100 opened: httputil: add support for extra snapd certs <Created by mvo5> <https://github.com/snapcore/snapd/pull/8100>11:28
mupPR snapd#8054 closed: snap: add `snap pack --compression=<comp>` options <Performance 🚀> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8054>11:29
ijohnsonmborzecki: I'll miss SU today and be out for 2ish hours, so if you want me to try anything more on uc20 spread testing, let me know, I might not be back til after your EOD11:31
pedronismvo: are you going to tweak those comments you commented on? when you make the PRs11:31
* pedronis lunch11:36
mborzeckiijohnson: i'll leave notes in the standup doc for you11:37
ijohnsonSounds good11:40
mvopedronis: yes, happy to11:54
mupPR snapd#8101 opened: netlink: fix/support stopping goroutines reading netlink raw sockets <Created by mvo5> <https://github.com/snapcore/snapd/pull/8101>12:04
=== mpt_ is now known as mpt
mborzeckimeh, more uc20 image woes https://paste.ubuntu.com/p/S3TP4BBPQT/12:15
mvomborzecki: did the kernel/initrd change or is this in the dev branch?12:16
mborzeckimvo: nothing changed, supposedly the same kernel image i'm using, somehow when built on gcp this does not mount12:18
mvomborzecki: so this is the repackaging and it's not quite working?12:19
mvomborzecki: is this with the new snap-bootstrap? maybe we regressed here :(12:19
mupPR snapd#8102 opened: o/ifacestate: move ResolveDisconnect to ifacestate <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8102>12:20
mborzeckimvo: i called snap-bootstrap manually, and the line is correct, tells to mount /dev/disk/by-label/ubuntu-seed under /run/mnt/ubuntu-seed12:20
pstolowskipedronis: ^ i hope this captures the idea we discussed12:20
pedronispstolowski: thanks, will look12:20
mvopedronis: re 8100> picking up the certs immediately, we could do what we do for the proxy and have a "Certs func(*http.Request) (*x509.CertPool)" (just like we do for proxy. is that what you have in mind here?12:21
pstolowskibbiab12:22
pedronismvo: I don't know , just fearing it will be a bit messy12:26
mvopedronis: I can explore the callback option, then at least it's equally messy to how we support the proxy :)12:26
pedronismvo: thanks for pushing #8101, of course I cannot review it :)12:38
mupPR #8101: netlink: fix/support stopping goroutines reading netlink raw sockets <Created by mvo5> <https://github.com/snapcore/snapd/pull/8101>12:38
mborzeckihmm i think i know what's going on12:48
pedronispstolowski: see #810113:08
mupPR #8101: netlink: fix/support stopping goroutines reading netlink raw sockets <Created by mvo5> <https://github.com/snapcore/snapd/pull/8101>13:09
pedronispstolowski: is this correct https://github.com/snapcore/snapd/pull/7863#discussion_r375827782 ?13:26
mupPR #7863: interfaces: add uio interface <Created by zyga> <https://github.com/snapcore/snapd/pull/7863>13:26
mborzeckiyay, got a working image in gcp13:27
pedronis\o/13:27
pstolowskire13:27
=== ricab is now known as ricab|lunch
mborzeckiwell, at least i did manage to download the image and make sure it boots and seeds inside qemu locally ;)13:31
mborzeckihaha too soon, seeding not complete13:32
mupPR snapd#8103 opened: snap-bootstrap: store encrypted partition recovery key <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8103>13:33
mborzeckiat least a familiar problem https://i.imgur.com/BOn7yOX.png13:34
mborzeckibut it did work on gcp13:35
mborzeckiyay!13:35
mupPR snapcraft#2912 opened: meta: do not prime commands with adapter == "none" <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2912>13:42
mupPR snapcraft#2913 opened: spread: disable journal debug dump unless configured <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2913>13:45
ijohnsonmborzecki: any progress ?14:45
* ijohnson is around for a little while14:45
mborzeckiijohnson: got it to work14:46
mborzeckiijohnson: pushing changes14:46
mborzeckiijohnson: still something off about ubuntu-core-initramfs, somehow i need to use the /usr/lib/ubunto-core-initramfs/main as skeleton of the rootfs, not the unpacked one14:47
ijohnsonmborzecki: that's great that you got it to work14:47
ijohnsonare you booting from 20.04 now or did you revert to 18.04 ?14:47
mborzeckiijohnson: 20.0414:47
mborzeckiijohnson: it needed a little tweak in grub script14:47
ijohnsonah okay, you fixed the grub.cfg and script then14:47
ijohnsongreat14:48
mborzeckiijohnson: please take a look at the PR, i've tried to comment all the quirks14:49
ijohnsonlooking now14:49
mborzeckineed to leave now, back in 2h or so14:49
ijohnsonack14:49
mupPR snapd#8098 closed: httputil: remove workaround for redirect handling in go1.7 <Created by mvo5> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8098>15:01
mupPR snapd#8099 closed: httputil: remove go1.6 transport workaround <Created by mvo5> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8099>15:01
=== ricab|lunch is now known as ricab
jdstrandmvo: hey, I don't know the status of 2.43 point releases, but if you are doing another one, cherry-picking https://github.com/snapcore/snapd/pull/8091#issuecomment-582935623 might make sense. we have (at least) two different forum topics and a bug on it...15:06
mupPR #8091: interfaces/greengrass-support: add /dev/null -> /proc/latency_stats mount <Created by dostiharise> <https://github.com/snapcore/snapd/pull/8091>15:07
jdstrandmvo: and the url above is to a comment discussing that possibility in case you want to respond15:07
mvojdstrand: thanks, will cherry pick15:08
mvojdstrand: there will be another one to include uio15:08
mvojdstrand: I added the 2.43 milestone, than kyou15:09
pedronismvo: having a break and then will work on the uio backporting prep15:09
jdstrandmvo: thank *you* :)15:09
mvopedronis: thank you, I focus on reviews and download now15:10
jdstrandpedronis, mvo: fyi, I have one more 2.44 review (it's a big one though). I hope to do that tomorrow. I'll then make a concerted effort to squeeze in the non-2.44 reviews while I work on other things15:12
* cachio lunch15:21
mvojdstrand: thanks15:22
mupPR snapd#8104 opened: interfaces/builtin: backport verifySlotPathAttribute (2.43) <Created by pedronis> <https://github.com/snapcore/snapd/pull/8104>15:36
pedronisijohnson: #8091 can be merged, right? and then backported15:39
mupPR #8091: interfaces/greengrass-support: add /dev/null -> /proc/latency_stats mount <Created by dostiharise> <https://github.com/snapcore/snapd/pull/8091>15:39
ijohnsonsorry was a bit afk15:43
ijohnsonpedronis: let me look at the PR, but did it change?15:44
pedronisijohnson: ?15:44
ijohnsonpedronis: that PR is fine, it can be merged I wasn't sure why you were asking me if it could be merged15:44
pedronisijohnson: because I haven't looked into it at all, but you reviewed and is all green15:45
ijohnsonpedronis: yes it has +1 from jdstrand so it's fine15:45
pedronisI tend to not merge things that I didn't even skim15:45
pedroniseven if they are all green15:45
ijohnsonack, np15:45
jdstrandI can merge it15:45
ijohnsonthanks jdstrand15:45
jdstrandI've been told I can merge simple things like that :)15:45
jdstrandijohnson: but note, I discussed this with mv o eralier and he will cherrypick15:46
ijohnsonjdstrand: cool yeah I was just going to say I defer to mvo about 2.43 vs 2.4415:46
jdstrandijohnson: done. it is milestoned for 2.43 (by mvo)15:47
mvoyeah15:47
pedronismvo: sorry, seems I wasn't clear in #8063, anyway I can work on it at some point soon15:48
mupPR #8063: cmd/snap: implement 'snap remove-user' <Created by chipaca> <https://github.com/snapcore/snapd/pull/8063>15:48
mupPR snapd#8091 closed: interfaces/greengrass-support: add /dev/null -> /proc/latency_stats mount <Created by dostiharise> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/8091>15:48
mvo8091 is now cherry picked15:48
mvopedronis: oh, sorry, I misunderstood15:49
mvopedronis: I can look at this too (or download) either way is fine15:49
pedronismvo: download probably needs more attention giving it seems we need to understand if we have a bug or not15:50
pedronis*given15:50
mvopedronis: ok, I'm looking at this right now anyway so I will just keep doing that15:50
mvopedronis: fwiw, I also see what john sees, I don't get 206 from the cdn, only 200 with the old and the new code, investigating now16:34
pedronismvo: fun with FdSet being platform dependent in the netlink stuff, trying to see if I can avoid need +build stuff16:36
mvopedronis: uh, fun :(16:37
mborzeckire16:38
ijohnsonhey mborzecki I ran a spread test of your branch and it passed on gce for me16:40
ijohnson\o/16:40
mborzeckiyay :P16:40
ijohnsonI don't think the tests on travis have been run yet however16:40
mborzeckithat's ok, they'll get their chance16:40
ijohnsonyeah still in "received" state16:40
mborzeckiijohnson: but i understand the base/modeenv branch worked for you right?16:41
ijohnsonit would be good to get someone else to +1 your branch and I can merge it in my PM when it goes green (hopefully 🤞)16:41
ijohnsonmborzecki: which PR ?16:41
ijohnson807316:42
ijohnsonerr16:42
ijohnson#8076?16:42
mupPR #8076: boot: add TryBase and BaseStatus to modeenv; use in snap-bootstrap <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8076>16:42
mborzeckiijohnson: 8075++16:42
ijohnsonhaha, I have not tried it in spread, but it worked locally with qemu before, I was going to merge master into thos PR's after the spread tests are working so hopefully we can get a real spread test of the changes16:43
pedronisijohnson: are 8075 and 8076 even landable alone, or we can only land 8077 ?16:47
ijohnsonpedronis: 8075 is fine because kernel= in the modeenv is not used anywhere anymore16:48
ijohnsonpedronis: 8076 is fine because it's just snap-bootstrap reading base_status and try_base, but nothing will write those into the modeenv until 807716:49
ijohnsonso yes both of those PR's are standalone16:49
ijohnsonI still need a 2nd review on 8076 however16:49
ijohnson8075 could be merged today if mbrozecki's branch is green16:49
ijohnson(it has 2 +1s)16:50
pedronisijohnson: my plan was to review 8076 after 8075 is in16:50
ijohnsonpedronis: sounds good, I am hopefully I can get 8075 in today so you could review 8076 tomorrow16:50
pedronismvo: mabye I fixed it, cross/go-build passes now16:51
mvohm, so "curl -v -L -o /dev/null  -r 1000000 https://api.snapcraft.io/api/v1/snaps/download/TJEfggNhgEJ4XKJ8o7ahsvRklz5kRK5w_29.snap" does not seems to work, it seems our cdn just ignores the range header16:51
* mvo is puzzled if he misses anyhing16:52
mvopedronis: oh, nice!16:52
pedronismvo: maybe ask the store people16:53
mvopedronis: yeah, asking there now16:59
mupPR snapd#8069 closed: tests: build the initramfs + kernel snap for UC20 spread tests <UC20> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8069>17:00
mupPR snapcraft#2914 opened: meta: ensure Application passthrough is scrubbed for snap.yaml <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2914>17:09
mborzeckiijohnson: i'm logging out for today, feel free to push fixes to 8094 if needed and land it, once it's merge i'd like to investigate why there's a problem using unpacked initrd 'main' root, perhaps we're still missing something there (or just a bug in u-c-i)17:29
pedronismvo: of course it needs to do something sane even if range doesn't work17:30
pstolowskipedronis, mvo i'm having failure of nested/classic/hotplug tests on 8101; i'm going to check if it regressed with master too. fwtw i see this: Feb 06 17:30:26 feb061718-477082 snapd[11297]: udevmon.go:110: udev monitor stopping timed out17:33
pstolowskiFeb 06 17:30:27 feb061718-477082 snapd[11478]: udevmon.go:148: udev event error: Internal error: bad file descriptor17:33
pstolowskibut perhaps it's shutdown code and unrelated to the test failure17:34
pedronispstolowski: that migh be a prexisting behavior17:34
mvopedronis: yeah, part of the problem is that we don't check for 206 on range so we already do the wrong ting17:34
pstolowskicachio: can you check if  we're running nested tests for hotplug nightly?17:34
pedronispstolowski: I think the disconnect in udevmon might be a bit of a hammer17:35
cachiopstolowski, passed 14h ago17:35
cachiohttps://travis-ci.org/snapcore/spread-cron/builds/64668331117:35
pedronispstolowski: it might need more tweaks17:36
pstolowskicachio: thanks, we're running it on 16.04 only though?17:37
cachiopstolowski, 16 and 1817:39
pstolowskicachio: i don't see 18 in that log, is it a separate log?17:39
cachiopstolowski, 16 -> core and classic17:39
cachio18 -> core17:39
cachiopstolowski, https://travis-ci.org/snapcore/spread-cron/builds/646683311#L582917:39
pstolowskicachio: was there a specific reason we don't run it on 18 classic17:41
pstolowski?17:41
ijohnsonpedronis: cachio: what are your thoughts on organizing the spread tests to have a dir "tests/core/..." with all the UC specific tests in there and then having tests in there specific to say uc20 just be named so like "tests/core/uc20-basic" and filter with systems: in the task.yaml ?17:41
pedronisijohnson: yes, something like that17:42
ijohnsonI just found a couple of tests that still are only run on uc16, but really should be run on uc18 as well as now uc20, and I think organizing the tests that way would make it less likely we run into this kind of thing for uc20 and uc22 etc.17:42
pstolowskicachio: hmm maybe it was something with qemu, i don't remember anymore...17:42
ijohnsonI may prototype that a bit this PM17:42
cachiopstolowski, checking17:42
cachiopstolowski, we are running ../bin/spread -v google:tests/nightly/ google-nested:ubuntu-16.04-64:tests/nested/classic/ google-nested:ubuntu-16.04-64:tests/nested/core/ google-nested:ubuntu-18.04-64:tests/nested/core/17:44
cachioI don't rememer why we are not running classic suite on 1817:45
pedronispstolowski: from those logs  it sounds like it was stuck in ReadEvent, which means the select was confused, or ReadEvent isn't quite doing what we expect17:45
pstolowskicachio: yeah that's weird, it's even listed in spread.yaml under nested/classic17:45
cachiopstolowski, I can add it17:45
cachiopstolowski, in 1 minutes17:45
pstolowskicachio: it may fail right now, i'm checking it with master17:46
pedronispstolowski: you might have to add more logging to understand what is happening17:46
cachiopstolowski, added17:48
pstolowskipedronis: it didn't fail on master17:51
pstolowskipedronis: but i'll re-run it a couple of time with & without the changes17:52
pstolowskispread -debug google-nested:ubuntu-18.04-64:tests/nested/classic/hotplug17:52
pstolowski^ for the record17:53
pstolowskicachio: thanks17:53
cachiopstolowski, np17:53
pedronispstolowski: as I said it's quite possibly that is not working, consider that udevmon tests fake the underlying bits18:01
pedronispstolowski: you'll need more debuggin logs in conn.go to know what's happening18:02
pstolowskipedronis: yep, i'll invesitgate, will pick it up tomorrow morning18:03
pedronispstolowski: thank you18:09
=== pstolowski is now known as pstolowski|afk
=== ijohnson is now known as ijohnson|lunch
=== ijohnson|lunch is now known as ijohnson
mupPR snapd#8104 closed: interfaces/builtin: backport verifySlotPathAttribute (2.43) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8104>18:51
mupPR snapd#8105 opened: store: detect if server does not support http range headers <Created by mvo5> <https://github.com/snapcore/snapd/pull/8105>18:52
mvopedronis: thanks so much for 810418:56
mvopedronis: sorry that I had to open another PR but I think we need to deal with 200 vs 206 better18:56
pedroniswas #8080 backported ?19:08
mupPR #8080: dirs: manjaro-arm is like manjaro <Bug> <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8080>19:08
ijohnsonpedronis: mvo: are there any high priority PR's for me to review? I'm still reviewing pawel's preseed PR, but seems there are other things in motion right now that might be important to review too ?19:13
ijohnsonoh I guess mvo is offline now19:13
pedronisijohnson: mostly Pawel's PRs atm, and anything old that can be reviewed or things about test themselves19:18
ijohnsonpedronis: ack19:19
pedronisijohnson: there's quite a bit of in-progress stuff that is not yet ready for review19:19
ijohnsonright19:19
* ijohnson is waiting on many spread runs to test fixes for the uc20 spread PR19:19
mupPR snapcraft#2912 closed: meta: do not prime commands with adapter == "none" <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2912>19:49
mupPR snapcraft#2913 closed: spread: disable journal debug dump unless configured <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2913>19:52
mupPR snapcraft#2915 opened: rust plugin: respect Cargo.lock if present in project <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2915>20:07
pedronisijohnson: I think #8105 can also be reviewed20:17
mupPR #8105: store: detect if server does not support http range headers <Created by mvo5> <https://github.com/snapcore/snapd/pull/8105>20:17
ijohnsonpedronis: ack, I'm almost done with 770520:17
* cachio afk20:24
=== hggdh is now known as hggdh-msft
roadmrer... snapcraft...20:42
roadmrYou are required to register this snap before continuing. Refer to 'snapcraft help register' for more options.20:42
roadmrWould you like to register 'hello-roadmr-1' with the Snap Store? [y/N]: y20:42
roadmrYou already own the name 'hello-roadmr-1'.20:42
roadmrO_o20:42
ijohnsonError: the name 'hello-roadmr-1' already owns you20:43
mupPR snapcraft#2916 opened: status: implement using the new channel-map endpoint <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2916>20:43
sergiusensroadmr: interesting, was that for push?20:47
roadmrsergiusens: yep - it's working now, all I had to do was change the snap's version from 2020-02-06-01 to 2020-02-06-02 O_o20:53
roadmrsergiusens: I'm filing a bug about license: not being validated by snapcraft; looks like if base: core18, the expected snap client to validate the license isn't found, apparently a hardcoded path21:01
roadmrsergiusens: snapcraft says  "Could not find '/snap/core/current/usr/bin/snap', validation of the license string will only take place once pushed to the store."21:01
sergiusensroadmr: yeah, at the time of implementation when discussed with chipaca way back, this was the only path for snapd, we probably need to consider the snapd snap now too21:02
roadmrsergiusens: ok - if you don't have a bug and want one, maybe you can add a snapcraft task to this one https://bugs.launchpad.net/snapstore/+bug/186224221:02
mupBug #1862242: license: field in meta/snap.yaml is not validated store-side <Snap Store:New> <https://launchpad.net/bugs/1862242>21:02
roadmr(we need store-side validation anyway so it's up to you how to handle this snapcraft-side)21:02
sergiusensroadmr: strange thing about your error though, we check the error codes and ask for registration if the result contains resource-not-found21:06
roadmrsergiusens: yes, that other thing is super weird :/ but somehow I got past it21:10
mupIssue core20#20 opened: Unpublish the core20 snap for i386 <Created by anonymouse64> <https://github.com/snapcore/core20/issue/20>21:18
mupPR snapd#8106 opened: tests: add "core" suite for UC specific tests <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8106>21:49
=== heather1 is now known as hellsworth
mupPR snapd#8094 closed:  tests: repack the initramfs + kernel snap for UC20 spread tests <UC20> <Created by bboozzoo> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8094>22:15

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