/srv/irclogs.ubuntu.com/2018/07/05/#snappy.txt

mupPR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>02:10
mupPR core-build#22 closed: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>02:10
mupPR core-build#26 closed: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>02:10
mupPR core-build#11 opened: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>02:11
mupPR core-build#22 opened: unit testing for sync_dir() <Created by mvo5> <https://github.com/snapcore/core-build/pull/22>02:11
mupPR core-build#26 opened: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>02:11
DarrenRStarrHello good people. I was wondering. Is there an example/boilerplate for making a kernel module snap?04:45
mborzeckimorning05:21
mupPR snapd#5468 opened: dirs: improve distro detection for Antegros  <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5468>05:39
mupPR snapd#5463 closed: Optimize snap install time 1 <Created by alfonsosanchezbeato> <Closed by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5463>06:29
mupPR snapd#5469 opened: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>06:32
mupPR snapd#5464 closed: vendor: switch to latest bson <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5464>06:43
mvomborzecki: thanks for the merge06:46
mborzeckimvo: hi, would it be possible to pick #5468 for 2.34?06:51
mupPR #5468: dirs: improve distro detection for Antegros  <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5468>06:51
mvosil2100: you are in the SRU team, right? if you could look at my bionic snapd upload with a tiny fix for the boot dealy workaround, that would be great. the xenial version of this can be rejected, I think xenial is not affected by this bad kernel update06:51
mvomborzecki: sure thing06:51
mborzeckithat os-release thing is a bit messy unfortunately06:52
mvomborzecki: make sure to tag for 2.3206:53
mvo2.3406:53
mborzeckiit's tagged (labeled) for 2.34 already06:54
mvomborzecki: great06:54
sil2100mvo: sure! I'm having my SRU shift today so I'll look at it for sure07:08
mvosil2100: thank you07:10
=== pstolowski|afk is now known as pstolowski
pstolowskiheyas07:11
abeatohm, systemd-activate is not in bionic anymore07:16
abeatowhich is the alternative for it?07:16
abeatoha, systemd-socket-activate must be07:16
mupPR snapd#5468 closed: dirs: improve distro detection for Antegros  <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5468>07:17
pstolowskizyga: hey, can you take a look at https://github.com/snapcore/snapd/pull/5416 ?07:40
mupPR #5416: interfaces/hotplug: add hotplug Specification and HotplugDeviceInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/5416>07:40
zygapstolowski: yes, sorry for not reviewing that last evening07:40
mvomborzecki: quick question on 5458 - cachio says "grep -c" exits 1 when no result is found - so is your change (to use it) safe?07:46
mborzeckimvo: looking07:47
mvomborzecki: I mean, with "wc -l" last we never have the last command in the pipeline failing, with grep -c it *might* happen07:47
mvomborzecki: and since we check before restarting snapd we will be back at the same bug we are fixing, no?07:48
mborzeckimvo: if grep -c fails, then the output is empty, so -gt tests will fail07:48
mvomborzecki: also in the "refreshes_before=" assignment ?07:49
mborzeckimvo: yes, test "" -gt "" fails in such case07:49
zygapstolowski: have a look07:49
mborzeckimvo: haha it fails in zsh07:50
mborzeckitest "" -gt ""07:50
mborzeckibash: test: : integer expression expected07:50
mvomborzecki: grep -c will print "0", no?07:50
mvomborzecki: I mean, refrehes_before will be zero with the new and the old code07:50
mvomborzecki: the risk is that if grep -c returns an exit 1 then the last command in the pipe failed and that causes set -e to kick in and abort (unless I'm reading this wrong)07:51
mborzeckimvo: but it's in a subshell07:51
mborzeckimvo: see it now, pff let me fix it07:52
mborzeckimvo: simple || true should do the trick07:54
mvomborzecki: http://paste.ubuntu.com/p/6DbZ8m5xZN/ if you want to play. thanks !07:54
mvomborzecki: yeah, that will also work07:54
mvomborzecki: feel free to merge once the grep -c is fixed, the PR looks fine07:56
mvo5460 is an easy win07:58
mborzeckimvo: pushed, will wait for it to get green and merge07:59
mupPR snapd#5460 closed: tests: use grep to avoid non-matching messages from MATCH <Simple> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5460>08:00
mvomborzecki: ta08:03
zygapstolowski: is that sensible?08:16
zygasorry, waking up much too late here08:16
mupPR snapd#5470 opened: tests: fixes for the autopkgtest failures in cosmic <Created by mvo5> <https://github.com/snapcore/snapd/pull/5470>08:17
pstolowskizyga: re Object and DevPath - happy to drop Object, just not 100% sure they're alyways the same, that's the only reason i've both, not to close any doors (although, it's easy to add it back if needed)08:20
zygapstolowski: ok, let's drop it for now under the assumption that they are indeed the same; if we find this is wrong we need to re-think some stuff08:20
pstolowskizyga: ok, np, thanks for the review08:21
Chipacamwhudson has all the fun08:22
ChipacaI too want to skip the office and go whalewatching08:22
zygaChipaca: whales of fun08:22
Chipacaonly whalewatching i could do is at the mall though, so maybe i'll pass08:22
zygaChipaca: I was doing hornethunting instead of whalewhatching08:23
Chipacazyga: hornets, or F/A-18 hornets?08:24
Chipacazyga: or even hawker hornets08:25
Chipacathose are cool08:25
zygaChipaca: my odds would be poor with those :)08:27
mborzeckizyga: probably the same as against japanese hornets :P08:31
Chipacadid we have a testutil for 'this looks like a timestamp'?08:37
zygammmm, not that I recall08:43
Chipacanm, fixed it by not having the timestamp in the first place08:46
Chipacain fact i'm questioning the whole 'send the timestamp' idea08:46
sil2100mvo: accepted the snapd bionic upload o/ As for xenial, in theory we do have the -hwe kernels in xenial that are 4.15 based, will those not cause problems?08:47
mvosil2100: oh, good point, let me quickly check if the bad kernel hit xenial as well08:48
mvosil2100: yes it did, so probably a good idea to have the fix in xenial too08:49
sil2100I think the same bits were in the -hwe kernel I published on Monday08:49
sil2100Ok then!08:49
mvosil2100: nice catch!08:49
ogra_mvo, i "accidentially" created a universal pi gadget that boots all pi's from one gadget ... and was wondering, i assume we are changing names for core18 images, so we could probably use that unified approach in 18 by default ? https://github.com/ogra1/pi-kiosk-gadget/commit/24ce020e094447abbad4d37a2856e23483b281dd08:52
zygaogra_: oh, nice, how does it work?08:55
ogra_zyga, config.txt allows filters per-device since a while08:55
ogra_nobody ever tried them ...08:55
ogra_... i'm actually working on a universal browser-kiosk image atm and got tired to always have to build two gadgets, so i tried it out ;)08:56
ogra_(thats what i meant by "accidentially" ;) )08:56
zyganeat08:58
ogra_zyga, http://people.canonical.com/~ogra/snappy/kiosk/pi-kiosk.img.xz in case you want to try (sadly seeding the giant chromium-mir-kiosk snap on firstboot takes 15-20min so one needs to be patient)08:59
mvoogra_: interessting.08:59
mvoogra_: one complication is upgrades, on an upgrade the current thinking is that you get a new core18 model assertion09:00
ogra_mvo, right, but i was assuming we change gadget names anyway and need an upgrade path for the naming09:01
mvoogra_: but as part of the upgrade logic we could put in the new config.txt - I assume this is backward compatible too? i.e. the old uboot.bin from the current gadget understands this too?09:01
ogra_so we could as well turn everyone to a universal pi gadget in that step09:01
mvoogra_: so far we had no need to change the gadget names for 1809:01
mvoogra_: we can/could, its definitely a compelling option09:02
ogra_i'm using the same source tag of the upstream tree that all core16 image use for the blobs, so yeah, fully compatible to todays gadgets09:02
ogra_the feature actually got added a few commits before the tag we use in core 16 so that should be safe09:03
mvoogra_: great09:03
mupPR snapd#5462 closed: many: use extra "releases" information on store "revision-not-found" errors to produce better errors (2.34) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5462>09:05
mupPR snapd#5471 opened: dirs: fix antergos typo <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5471>09:06
mborzeckisilly typo fix ^^09:06
mborzeckihad to stare at the screen for a while to spot the difference09:07
ogra_pedronis, (and probably sil2100 ) https://bugs.launchpad.net/ubuntu-image/+bug/178021709:09
mupBug #1780217: new connections: stanza causes validation error in ubuntu-image <Ubuntu Image:New> <https://launchpad.net/bugs/1780217>09:09
sil2100ogra_: yeah, indeed, the connections: part wasn't around when we had the parser prepared09:15
ogra_yeah09:16
ogra_it's pretty new (i think i'm actually the first one to try using it)09:16
mvosil2100: maybe add a switch --ignore-unknow or something to make the parser more accepting stuff that is unknown so that people can easier experiment09:17
mvosil2100: or even just warn about unknown options by default instead of hard failing09:17
ogra_doesnt snapd have a parser that u-image could call out to ?09:17
ogra_seems awkward that validation needs to be maintained in two places09:18
mvoogra_: there is separation of concern here, snapd ignore most of the partitioning bits but u-i needs to parse that. conversely u-i can ignore stuff like connections or snaps because snapd will handle that09:19
ogra_oh, right ... gadget.yaml is special09:19
sil2100mvo: good idea, we didn't really think about future changes to the gadget.yaml spec it seems ;)09:20
sil2100Anyway, let me get these things fixed today-ish09:21
ogra_sil2100, i'm not in a hurry (i have hacks for my test images that help with the issue) so no need to drop something else for it or some such09:22
zygajdstrand: please enqueue https://github.com/snapcore/snapd/pull/546909:24
mupPR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>09:24
mwhudsonChipaca: turns out the midwinter fireworks might get canceled because of this whale09:25
mwhudsonso i don't get _all_ the fun09:26
ogra_neither does the whale (who knows probably he'd appreciate fireworks :) )09:27
Chipacamwhudson: I am unconvinced09:32
Chipacamvo: i just got the MATCH bug on core18 :-)09:33
zygamwhudson: is the whale something special where you live?09:39
zygaChipaca: did you bring any MATCHes09:40
zygaChipaca: do you have a debug shell?09:40
Chipacazyga: this was from travis so no09:40
zygain the end working on software is fun because of MATCH like bugs09:40
zygawhere we look at a 3 liner09:40
Chipacazyga: but am now trying to repro it with debug09:40
zygaand then look at the error09:40
zygaand then say WAT09:40
zygaand are awed by the eventual understanding09:40
pedronismvo: hi, thanks for merging that backport, there is also #544209:41
mupPR #5442: many: expose publisher's validation throughout the API (2.34) <Created by pedronis> <https://github.com/snapcore/snapd/pull/5442>09:41
mvopedronis: aha, looking09:41
mupPR snapd#5442 closed: many: expose publisher's validation throughout the API (2.34) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5442>09:43
mwhudsonzyga: yeah, it's pretty unusual09:46
mwhudsonzyga: dolphins, seals, even orca are somewhat normal, but a baleen whale?09:46
pedronismvo: thanks09:53
* zyga wrote pretty lengthy review for a one liner: https://github.com/snapcore/snapd/pull/5466 09:55
mupPR #5466: tests: remove extra ' which breaks interfaces-bluetooth-control test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5466>09:55
zygamwhudson: nice, I never saw a whale09:55
mwhudsonzyga: me neither until today!09:56
zygamwhudson: I think I saw a dolphin as a child when one was (rarely) spotted near to where I was at the seaside here09:56
mwhudsoni've never been around when the orca are in the harbour09:56
zygamwhudson: imagine how it must feel to dive next to such a creature!09:56
mwhudsonzyga: i thought the paddle boarders were being quite brave enough09:57
mwhudsonzyga: have you seen the bbc series 'the blue planet'?09:57
zygais the whale stuck there or just passing by?09:57
zygamwhudson: yes, I have it on BD09:57
mwhudsonone of the making of segments has a diver getting a bit too close to a whale + calf09:58
zygawatching that makes me think I made some bad life decisions by working on computers all day long09:58
zygatoo close? maybe I missed that part09:58
mwhudsonas far as anyone can tell the whale is just hanging out09:58
mwhudsonit's been here for three days now?09:58
zygadid you take that photo with your phone?09:59
mwhudsoni can't imagine there's a lot of krill in the harbour but what do i know09:59
zygaor with a telelens?09:59
mwhudsonyeah09:59
mwhudsondoesn't the terrible unsharp mask give it away? :)09:59
zygahaha, well, maybe this is a smoker whale who likes the smell of oil and gasoline ;-)09:59
zygahaha, kind of :D09:59
zygaif you have a camera now would be a great time to take some time off and photograph it10:00
zygamaybe that could go to the community showcase10:00
* mvo seconds that10:00
mwhudsoni guess it was ~300 metres away when i saw it10:00
zygaubuntu wacky whale anyone :D10:00
mwhudsonwell unsurprisingly there are billions of much better photos on twitter & fb etc10:00
zygayeah, that is how the times are10:00
mwhudsonhttps://www.facebook.com/photo.php?fbid=10155927798194830&set=a.383547374829.165096.535824829&type=3&theater10:01
zygaI kept saying that someone should make an app for finding photos made at the time / place where one was with juts their phone10:01
mwhudsonfor example10:01
zygabut then I learned one of the heavyweights did just that10:01
zyga(forgot which now)10:01
zygawoah10:01
niemeyerMornings10:01
zygafantastic photo10:01
zygahey Gustavo :)10:01
niemeyermborzecki: Some comments in #545910:01
mupPR #5459: cmd/snap: add 'debug paths' command <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5459>10:01
mborzeckiniemeyer: hey, thanks for the review!10:03
niemeyermborzecki: Heya, np10:03
mupPR snapd#5471 closed: dirs: fix antergos typo <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5471>10:04
mborzeckiniemeyer: given your comemnt, that would be SNAP_MOUNT,  SNAP_BIN, SNAPD_LIBEXEC10:05
zygafatal: unable to access 'https://github.com/kardianos/govendor/': Failed to connect to github.com port 443: Connection timed out10:05
zygaI wonder if there's something simple we can pass to govendor to retry those10:05
mborzeckizyga: that's go get10:06
zygaaha10:06
zygaseems not10:07
zygawe could grep10:07
zygabut :/10:07
zygamvo: do you think we should grep for "Failed to connect" and retry?10:07
zygamborzecki: can you look at https://github.com/snapcore/snapd/pull/545710:11
mupPR #5457: many: lessen the use of core-support <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5457>10:11
niemeyermborzecki: Not sure I get the question10:11
mupPR snapd#5466 closed: tests: remove extra ' which breaks interfaces-bluetooth-control test <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5466>10:11
zygamborzecki: now that https://github.com/snapcore/core/pull/92 has landed we need this10:11
mupPR core#92: Remove core-support plug <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/core/pull/92>10:11
zygaCC mvo10:11
niemeyermborzecki: ... there's no SNAP_BIN there, only SNAPD_BIN, and the suggested entries match exactly the ones in the PR in the same order and with almost the same names10:12
mborzeckiniemeyer: yeah, so i'm wondering if we should use SNAP_MOUNT instead, since we refer to the path as snap mount dir elsewhere (and SNAP_BIN for that matter)10:16
mvozyga: I looked at this one, no?10:17
zygamvo: yes just letting you know we need to merge it :)10:17
niemeyermborzecki: The review provides the exact background for $SNAP_ vs. $SNAPD_.. did you read it? :)10:17
zygamvo: or tests will complain about missing core-support-plug10:17
zygamvo: looking at core PRs I'd suggest to look at and close https://github.com/snapcore/core/pull/3810:19
mupPR core#38: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>10:19
pstolowskizyga: addressed your feedback to https://github.com/snapcore/snapd/pull/541610:19
mupPR #5416: interfaces/hotplug: add hotplug Specification and HotplugDeviceInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/5416>10:19
zygapstolowski: perfect, looking10:19
niemeyermborzecki: It's of course okay to disagree.. but it sounds like you didn't read it.. what do you think of these points?10:20
mupPR core#91 closed: hooks: add a check to ensure that the image is build with ppa:snappy-dev/image <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/core/pull/91>10:20
zygapstolowski: reviewed10:21
niemeyermborzecki: I'm usually much more careful when I need to expose such names to the external world via an API than when it just sits inside our code which can easily change10:21
niemeyermborzecki: The mount dir of a snap is actually at /snap/<snap name>/<revision>10:22
niemeyerWhich we call $SNAP for the snap10:23
niemeyermborzecki: snap.Info.MountDir also returns /snap/<snap>/<rev>, not /snap10:25
zygadrat, I don't have my opensuse account password here10:25
zygaI'll ask my wife later today10:25
mborzeckiniemeyer: sry, kids are around, what i meant is that the tests and configure flags and the `dirs` package variable name is some premuation of snap mount dir,, that's why i found SNAPD_(MOUNT|BIN) a bit confusing10:29
niemeyermborzecki: Sure, and that's what the comment in the review addresses.. in other cases we generally try to leave SNAP_* for snap-specific namespaces10:31
niemeyermborzecki: $SNAP_COMMON, $SNAP, $SNAP_DATA, ...10:31
niemeyermborzecki: While SNAPD_* is for snapd.. $SNAPD_DEBUG, ...10:31
mborzeckiack10:31
niemeyermborzecki: Inside the code we have both.. dirs.SnapMountDir, and snap.Info.MountDir.. the first maps to SNAPD_MOUNT, while the latter is snap-specific and exposed as $SNAP10:32
niemeyerzyga: COmment on #545710:39
mupPR #5457: many: lessen the use of core-support <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5457>10:39
=== sabdfl_ is now known as sabdfl
zygalooking10:44
zyganiemeyer: replied10:46
niemeyerzyga: Replied the reply...10:48
niemeyerI wish GH would notify instead of us using IRC that way :)10:48
zygahaha, yes10:48
zyganiemeyer: replied again10:50
zygaI wonder why github shows me someone is typing but then doesn't show me the actual post. I need to refresh the page... wierd10:51
niemeyerzyga: You say it's not removing the testing of the interface, which is a bit ironic given that the comment is under a line removed that tested the existence of the interface :)10:51
zygano, you misunderstand10:52
zygathat is not what is tested10:52
niemeyerMan.. do I need to copy & paste the test? :)10:52
niemeyer details: |10:52
niemeyer     The "snap interface" command displays a listing of used interfaces10:52
niemeyer execute: |10:52
niemeyer-    snap interface | MATCH 'core-support\s+ special permissions for the core snap'10:52
zygasnap interface lists interfaces that are _present_ in the system as plugs or slots10:52
zygait doens't list interfaces that are known but not present as plugs or slots10:52
niemeyerAh.. okay, that's what I missed10:53
zygaI could change that to say "snap interface --all | MATCH" but that was not the point of the test so I changed it slightly10:53
niemeyerzyga: And what about this:10:53
niemeyer-    snap interface core-support > out.yaml10:53
niemeyer+    snap interface network > out.yaml10:53
niemeyer-    diff -u out.yaml snap-interface-core-support.yaml10:53
zygaand hence used the network interface instead10:53
zygathis just shows how plugs and slots are reported by "snap interface IFACENAME"10:54
niemeyerzyga: Do we have other tests for it?10:54
zygathis is why I also added the test snap to have a connection10:54
zygafor the core-support test, no I don't believe we do10:54
zygait used to be tested by various core configuration test10:54
zyga*tests10:54
zygabut those stopped exercising that code10:55
zygafrom my POV that interface is stuck as-is until we can understand why some snaps are abusing it10:55
zygaand shift them away from it10:55
niemeyerSo we're back to the same point10:55
niemeyerWe should either remove the interface, or tes it10:55
niemeyertest it10:55
zygawell, I disagree, I didn't remove an existing test for the functionality of this interface since we didn't have one10:55
zygawe cannot remove the interface, I can add a test for the interface but this is orthogonal to the change I made here10:55
zygaI hope you agree about this point specifically10:55
zygaFYI, I clarified my last comment10:57
zyga(on GH)10:57
niemeyerzyga: I see.. the test goal was just checking "snap interface" itself, not the core one specifically10:59
zygayes10:59
zygaexactly so10:59
pstolowskimborzecki: google:arch-linux-64:tests/main/interfaces-content-default-provider failure on arch  - https://api.travis-ci.org/v3/job/400340808/log.txt10:59
mborzeckipstolowski: mount isuse?11:00
niemeyerzyga: We probably have tests for that interface originally, but they were about the hook which don't need the interface anymore11:00
pstolowskimborzecki: yes11:00
zyganiemeyer: yes, I think so as well11:00
niemeyerzyga: So why do we need the interface again?11:00
pstolowskimborzecki: can i restart or do you want to take a look at the log?11:00
mborzeckipstolowski: go ahead and restat11:00
pstolowskik11:00
zyganiemeyer: we found that one of our customers has a snap declaration for using it on some of their snaps11:00
zyganiemeyer: they are probably using it for the unconfined systemctl access11:00
zyganiemeyer: I believe we are trying to get in touch with them to discuss this11:01
pstolowskimborzecki: is this test flakiness or something deeper?11:01
zyganiemeyer: I would have removed it a few days ago but jdstrand suggested we do a store-side search to ensure it is really unused11:01
mborzeckipstolowski:  no clue yet, there's a forum topic tracking this problem11:01
mborzeckipstolowski: it's usually associated with I/O errors on loop devices11:01
niemeyerzyga: Well, that's definitely not what this is supposed to do11:01
zyganiemeyer: interesting observation, no? I think this is something to learn from11:02
zyganiemeyer: yeah but I don't think we should pull the rug from under their feet without asking first11:02
niemeyerzyga: How's that not blocked with the declaration?11:02
niemeyerzyga: Pretty sure jdstrand wouldn't hand that off11:02
mvojdstrand: hey, I created a core16 base snap, it is essentially core without snapd, exactly the same build etc. could you please whitelist that in the store so that people can start using it? sergio was keen to use it for his latest snapcraft work11:02
zyganiemeyer: they have their store, they just signed a declaration that grants this11:02
niemeyerzyga: Okay, let's just drop this then11:03
zygamm?11:03
zygadrop the interface you mean?11:03
niemeyerzyga: Drop the permissions granted by the interface11:04
zygakeep the interface but make it empty or remove it entirely?11:04
niemeyerzyga: Keep the interface, drop permissions11:04
zygaok11:04
zygacan we land this PR then, I will open a new one that drops the actual permissions11:04
zygawe need this PR because we removed core-support-plug from core11:04
niemeyerzyga: Yeah, the PR is fine11:05
niemeyerzyga: Who's the contact on our end?11:05
zygathanks! sorry for not including more context in the PR itself11:05
zyganiemeyer: I think lool11:05
niemeyerlool: ping11:05
niemeyerzyga: I'll also revive the conversation about the fact people granting arbitrary permissions like that for their devices is completely bogus11:06
zyganiemeyer: but I need to re-check, pedronis noticed this as he helped to find this11:06
zyganiemeyer: thank you11:06
zyganiemeyer: we may have some extra constraint on interface policy11:06
niemeyerzyga: np, thanks for the info11:06
pedronisniemeyer: we didn't ping anybody so far,  I wanted to mention it in the standup yesterday11:06
zyganiemeyer: that really limits it to specific snaps in a way that cannot be forced from the store11:06
zyganiemeyer: so that in the future things like that don't happen11:06
niemeyerzyga: No, the bug here is people being able to sign snap-declarations blindly11:06
zyganiemeyer: snice this ties our hands as to what we can do for internal bits11:07
zyganiemeyer: I see, ok11:07
pedronisniemeyer: about the blocking of this self-granting, we will have more control as part  of the work planned in this cycle11:07
zyganiemeyer: without counter signature and review?11:07
niemeyerzyga: Exactly11:07
zygayeah, this makes sense11:07
niemeyerpedronis: Okay, I'll try to put something on the agenda for the sprint11:07
zygaok, I'll prepare another PR now11:07
pedronisniemeyer: I need to resync with jdstrand on that11:07
niemeyerpedronis: We need to act on this.. we discuss it as high-priority a few times, but we didn't really get any work items on the schedule yet11:08
niemeyer*discussed11:08
pedronisniemeyer: we do11:08
niemeyerpedronis: Oh?11:08
pedronisone sec11:08
pstolowskizyga: hmmm. gnome-calculator stopped working on 18.04, it wants me to connect gnome interface (which somehow got disconnected at some point); I reconnected it and it is connected per 'snap interfaces', but apparmor says: audit: type=1400 audit(1530788803.989:110): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="snap.gnome-calculator.gnome-calculator"11:10
pstolowskipid=22099 comm="apparmor_parser11:10
zygathe STATUS is just spam, it doesn't say anything bad11:11
zygapstolowski: can you tell me how this happened11:11
zygaI know of one other case but we didn't manage to either reproduce it or figure out how it came to be11:11
zygapstolowski: please tell me all you know11:11
pstolowskizyga: i've no idea. i'm running stable. i've just made a copy of state.json before reconnecting, so i can try to find something there. there were no 'snap changes' reported11:12
zygawas this in a VM with random tests running or on your machine?11:13
zygacan you look at logs from snapd (all of them)11:13
pstolowskizyga: so this must have happened some time ago, i just didn't notice until i tried to use gnome-calculator today11:13
zygaaha11:13
zygawhat is your uptime?11:13
pstolowskizyga: 3 days11:13
pstolowskizyga: and it's not VM, it's my main box11:14
zygahmmm hmm11:14
zygacan you please collect fstab files for that snap11:14
Chipacagrr grr MATCH grr11:14
zygathe two, one in /var/lib/snapd/mount and the other in /run/snapd/ns11:14
zygapstolowski: also, since you have a mount namespace, can you please collect the mountinfo from that namespace (ping if you need aid)11:15
zygapstolowski: my only theory is as follows11:16
zygapstolowski: oh one more detail please, collect timestamps from all the files, including the .mnt file11:17
zygapstolowski: content connections are non-fatal, if you conncet but we fail to mount, we just carry on11:17
zygapstolowski: we do mark the thing as not mounted though11:17
zygapstolowski: something is either causing that to unmount11:17
zygapstolowski: or the logic is wrong and we thing we mounted (I need to ensure this is strictly tested)11:18
zygapstolowski: I wonder if refreshing content snap is doing the right thinh11:18
zyga*thing11:18
zygaI will look into this soon11:18
zygapstolowski: please collect this in the forum, I suspect there's one thread about this but if no, make one11:18
pstolowskizyga: re namespaces, you need mount output after sudo nsenter -m/run/snapd/ns/gnome-calculator.mnt ?11:18
zygacat /proc/self/mountinfo11:19
pstolowskiok11:19
zygabut yes11:19
diddledanergh. SNAPCRAFT_BUILD_ENVIRONMENT=lxd has always been a pain for me when running `snapcraft clean ...` the pull step seems to pull the parts' sources as uid 1000 which doesn't seem to be mapped properly to my host userid and thus clean cannot delete the files11:20
mupPR snapd#5470 closed: tests: fixes for the autopkgtest failures in cosmic <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5470>11:20
zyganiemeyer: can you please approve 545711:21
niemeyerzyga: Sorry, just working on the side effects of this mess11:23
zyganiemeyer: sure, no worries :)11:23
diddledanpaste of an affected source tree on my host: http://paste.ubuntu.com/p/XPW37s4gTq/ and within the build container: http://paste.ubuntu.com/p/hvPFZQqGMz/11:23
zyganiemeyer: this is the follow up https://github.com/snapcore/snapd/pull/547211:23
mupPR #5472: interfaces: make core-support a no-op interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5472>11:24
mupPR snapd#5472 opened: interfaces: make core-support a no-op interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5472>11:24
niemeyerzyga: Too late, but this was abusing "many:"11:24
zygaThank you!11:24
zyga:-)11:24
niemeyerzyga: This was actually a single directory11:24
zygaah, sorry, I probably kept the name from earlier branch11:25
zygayep11:25
mupPR snapd#5457 closed: many: lessen the use of core-support <Core18> <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5457>11:25
zygaok little by little :) core 18 here we come11:25
* Chipaca ~> lunch11:28
niemeyerzyga: Follow up LGTM except for summary (comments there)11:28
zygathanks!11:29
pstolowskizyga: https://forum.snapcraft.io/t/gnome-calculator-suddenly-disconnected-from-gnome-platform-snap-reconnecting-doesnt-help/625611:30
zygapstolowski: looking11:31
pstolowskizyga: let me know if there is anything else to capture; i'll look into state in a moment11:31
zygapstolowski: please add fstab files11:31
zygathey are essential11:31
zygaand timestamps on all the three files11:31
zygaand snap changes for the content snap (if any)11:31
* diddledan twiddles his thumbs11:32
zygapstolowski: also snap list --all would help, for the inactive revisions11:32
zygadiddledan: hey, sorry for not being able to help you11:32
zygaI saw your question but I don't know enough about snapcraft to help11:32
diddledan:-)11:32
pstolowskizyga: sure, doing11:33
zygathanks11:33
pstolowskizyga: updated11:36
zygapstolowski: you missed /run/snapd/ns/11:38
zygathat has more fstab files :)11:38
zyga(and the important one is there)11:38
pstolowskiaha. ok11:41
pstolowskizyga: how about now?11:42
pstolowskipedronis: disconnect-hooks PR is ready for re-review.. it grew a bit unfortunately. changes worth nothing are: individual disconnects, a "automatic-disconnect" flag on disconnect tasks, handling of undo (connect-* hooks run if disconnect hooks are undone).11:44
niemeyerzyga: #5454 also +1d with a trivial11:46
mupPR #5454: interfaces: prefer "snapd" when resolving implicit connections <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5454>11:46
niemeyerzyga: Thanks for the nice breakdown of those issues, btw11:46
=== pstolowski is now known as pstolowski|lunch
Chipacaniemeyer: reminder to take a look at #1779859 when you can11:47
mupBug #1779859: tracks should be ordered <Snap Store:Confirmed> <https://launchpad.net/bugs/1779859>11:47
zyganiemeyer: thank you!11:48
zygapstolowski|lunch: ah, you've gone for lunch11:49
zygaafter you are back, please run snap-update-ns on that snap11:49
zygaI'm super curious what the result will be11:49
zygaguys, I need to run, my dog makes it crystal clear what I should be doing now (not hacking)11:49
PLA1Hi. I have two 18.04 machines both up-to-date. One has snap version 2.32.9+18.04 and the other snap version 2.33.1. How can I get the other machine up to 2.33.1? I've tried `apt install snap`. Having a boot issue with the other machine and wonder if it is affected by this https://forum.snapcraft.io/t/snapd-service-delays-startup-in-ubuntu-18-04-with-4-15-0-24/6205 Thanks.11:53
ChipacaPLA1: how are you checking the versions of snapd?11:53
PLA1snap version11:54
niemeyerChipaca: Done!11:54
Chipacaniemeyer: taw11:54
ChipacaPLA1: do you have snaps installed in the one that says 2.32.9+18.04?11:55
PLA1I don't think there are any snaps installed on either machines. What is that command to list?11:55
ChipacaPLA1: try 'snap list core'11:55
PLA1The 2.33.1 has core installed the other does not.11:56
ChipacaPLA1: that's your answer: install core (snap install core) to get 2.33.1 in the other one as well11:57
PLA1OK. Thanks.11:57
PLA1Both at 2.33.1 now. Lets see if that fixes his boot problem. Thanks!11:58
zygare12:04
zygawow, I can work from here :)12:04
zygapstolowski|lunch: one more idea to explore once you are back12:08
Chipacazyga: where's 'here'?12:09
zygaChipaca: hop into standup12:09
zygahhh12:09
zygadarn12:09
zygaI didn't take my token :P12:09
zygalet me ask my son for help12:09
Chipacamost boring standup EVAR12:12
Chipacafeaturing me having lunch like a caveman12:14
zygahahah12:14
zygapstolowski|lunch: run journalctl | grep 'Unmounted Mount unit for gnome-*'12:15
zygapstolowski|lunch: this will show us some history of the mount units12:16
zygathis can eliminate any chance that event propagation caused this12:16
zygathanks, I'll tend to other tasks until you are back12:16
loolniemeyer: pong12:20
* zyga tunes in 12:20
zygaChipaca: I'll ping you once my kids arrive with the token :P12:21
mupPR snapd#5473 opened: overlord: have SnapManager use a passed in TaskRunner created by Overlord <Created by pedronis> <https://github.com/snapcore/snapd/pull/5473>12:21
jdstrandzyga: re https://github.com/snapcore/snapd/pull/5469> ok12:22
mupPR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>12:22
Chipacazyga: the byzantine generals needed kids, clearly12:22
mupPR snapd#5474 opened: many: finish sharing a single TaskRunner with all the the managers <Created by pedronis> <https://github.com/snapcore/snapd/pull/5474>12:23
zygaChipaca: how many do I need for the minimal algorithm to wokr?12:23
zyga*work12:23
Chipacazyga: 3, but uniformly 3 levels deep12:24
zygaChipaca: drat12:24
zygaChipaca: well, I can perhaps say that now :)12:24
zygaChipaca: 3rd is on the way now12:24
zygaChipaca: I'm in the standup if you want to chat12:24
Chipacazyga: congrats!12:24
mupPR snapd#5416 closed: interfaces/hotplug: add hotplug Specification and HotplugDeviceInfo <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5416>12:25
mupPR snapd#5475 opened: Remove unneeded calls to daemon-reload <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5475>12:25
Chipacazyga: you're not in the standup12:25
PLA1Snap had nothing to do with the problem. Not sure what it is but I moved the other box from LightDM to GDM. Good to go. Thanks again.12:27
mupPR snapd#5476 opened: snapstate: make sure all *link-*snap tasks carry a snap type and further hints <Created by pedronis> <https://github.com/snapcore/snapd/pull/5476>12:28
zygathanks John12:29
Chipacazyga: np12:29
zyganiemeyer: this is not urgent but could you please append https://github.com/snapcore/snapd/pull/5307 to your review list12:32
mupPR #5307: cmd/snap-confine: allow hard-coded mounts to be optional <Created by zyga> <https://github.com/snapcore/snapd/pull/5307>12:32
zygapstolowski|lunch: were those messages from pre-reboot? we only need the one from _this_ boot12:35
pstolowski|lunchzyga: added journalctl output, looks totally fine12:36
niemeyerzyga: The comment I made there earlier still seems relevant.. this PR is unused and untested.12:36
niemeyerzyga: Can we please have these changes together with the tests that demonstrate how this is supposed to work?12:36
loolzyga: what's the PR we're considering? lots of PR discussed  :-)12:36
zyganiemeyer: I specifically explained why that is, those are tested in the two follow-up PRs, that code doesn't have any more tests and adding them here would be non trivial12:36
zyganiemeyer: there is a spread test at the end, I believe12:37
zygapstolowski|lunch: yes, but was it from all the boots or just from the current one?12:37
niemeyerzyga: No, no tests12:37
zyganiemeyer: I can put the remaining patches into this PR, sure12:37
zyganiemeyer: I missed this when reading: zyga: Can we please have these changes together with the tests that demonstrate how this is supposed to work?12:38
zygathanks!12:38
niemeyerzyga: Breaking down independent PRs is nice, but it feels a bit over the limit to be pushing logic that is completely untouched by anything12:38
jdstrandmvo: re core16> ack. I manually approved r1. for r2-r6, please request a manual review and I'll approve12:40
ogra_jdstrand, the process-control interface allows me to send signals to processes, but doesnt allow me to exec kill or pkill from the core snap, couldnt we allow these two commands so one doesnt need to ship them in the snap ?12:42
jdstrandniemeyer (cc pedronis): fyi, the brand store declaration work is on the spreadsheet for this cycle already12:43
pedronisjdstrand: yes, pointed that out on a different channel12:43
jdstrandah yes, I see that now12:44
zygamvo: I'm re-working the last patch of the set, I think this will correctly handle all the edge cases, transitions and what not12:50
mvozyga: \o/12:51
zygamvo: I will share a little while after the standup as I'm making some more changes based on experiments and some thinking12:51
mvozyga: can't wait to see/try it12:51
mvozyga: sure12:51
zygamvo: let's HO then to discuss if this is sane12:51
mvook12:51
=== pstolowski|lunch is now known as pstolowski
mupPR snapd#5454 closed: interfaces: prefer "snapd" when resolving implicit connections <Core18> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5454>12:58
niemeyerzyga, mvo, all: Won't attend the standup.. have a conflict today13:00
mupPR snapd#5472 closed: interfaces: make core-support a no-op interface <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5472>13:00
mvoniemeyer: ta13:01
mvo70894713:01
mvoniemeyer: thanks for the heads up13:01
ogra_hmm, how can snap and snapd be at different versions in "snap version" output .. thats weird https://forum.snapcraft.io/t/creating-a-python-daemon-to-interact-with-gpio/6177/1013:07
ahoneybunwow :     1min 38.255s snapd.seeded.service13:08
jdstrandogra_: added to the list for the next batch of updates13:09
ogra_ahoneybun, pfft ... try on an arm board13:09
ogra_jdstrand, thanks, thats really helpful i think13:09
ogra_ahoneybun, i have an image seeding 2 snaps (mir-kiosk and chromium-mir-kiosk) that takes 20+ minutes for the first boot (15 of that just seeding chromium)13:10
ogra_i'd *love* to have an 1:38 firstboot :)13:10
Chipacaogra_: they can get out of sync if somebody has cobbled together the system out of random bits they found on the internet13:16
ogra_Chipaca, well, this seems to be a dell customer with an edge gateway (the caracalla gadget seems to be in use, there are interfaces called caracalla)13:17
Chipacaogra_: this is a core system, so no re-exec13:17
ogra_right13:17
Chipacaogra_: because you're supposed to already be booting from core13:17
ogra_no re-exec but also snap and snapd come from the same core snap usually13:18
Chipacaogra_: so I'd first inquire how they built or otherwise obtained the system13:18
Chipacaogra_: e.g. if they copied it in some weird way13:18
Chipacaogra_: i mean: if all were ok, it's impossible13:19
Chipacaogra_: so something is not ok13:19
Chipacaogra_: i'd start with #0: users lie13:19
Chipacaogra_: and go from there :-)13:19
ogra_yeah, i asked if he tinkered with the install in some form13:21
jdstrandroadmr: hi! can you pull r1093 of the review tools?13:23
jdstrandmvo: that has the core16 override adjustments ^13:23
roadmrjdstrand: hello! certainly, I'll start the usual paperwork13:23
roadmrjdstrand: when time permits, could you help reply to this folk: https://forum.snapcraft.io/t/my-snap-lbe-device-management-was-rejected-on-the-store/6242/2 Also we were wondering if there's like a boilerplate text (perhaps more detailed than what the review tools say) we could use for people requesting snapd-control. If what the tools reply is enough in your opinion, that works as well13:25
jdstrandroadmr: I thought your answer was great. there is boilerplate in the wiki: "The snapd-control interface is reserved for snaps that require device ownership and the ability to control all aspects of snaps on the system and is not usually needed for typical snaps. If the access is required, consider using a brand store or create a forum topic at https://forum.snapcraft.io/ using the 'store' category if this can be discussed in public or the 'sensitive13:27
jdstrandroadmr: I can adjust the review-tools too. let me try to do something for r1094 real quick13:28
roadmrjdstrand: yes, that's pretty much what the tools say, which I thought was clear13:29
roadmrin that respect, what this person did was correct, he came to the forum, and in there we can explain in more detail and discuss with them13:29
jdstrandroadmr: it isn't clear who should respond. really, this is a brand store question13:33
jdstrandroadmr: I'll ping kyleN in the topic13:34
roadmrjdstrand: right... well in a sense it's not a brand store question since his snap exists in the global store. So if he doesn't make a good case for that, a simple "denied but you can register a snap name to your brand store and do it there - don't have one? talk to Kyle!" might be good.13:35
jdstrandroadmr: Ok, I'll adjust the wiki then13:38
roadmrthanks jdstrand13:38
mvojdstrand: \o/13:38
pstolowskizyga: what was the command you wanted me to try?13:45
pstolowskiTrevinho: ping13:47
zygapstolowski: sudo /usr/lib/snapd/snap-update-ns gnome-calculator13:58
zygamvo: re, I'm back home now, it was too hot in the sun13:58
zygamvo: I'm mid-way through lunch (which doubles as bfast)13:58
zygamvo: I'll give you an update soon13:58
roadmrbrunch. What even is brunch?14:00
jdstrandroadmr: how is this: https://paste.ubuntu.com/p/DbWDvmQGyG/ ?14:01
niemeyermvo: Do you have sec for a quick call?14:02
niemeyerpedronis: You too if you have a moment14:02
roadmrjdstrand: great, looks good! more informative about the prospect of brand stores14:04
mvoniemeyer: sure14:08
niemeyermvo, pedronis: https://meet.google.com/dob-pjfr-rkz14:08
pstolowskizyga: this didn't help14:10
pstolowskiwillcooke: ping14:11
zygapstolowski: that's consistent with what I suspected then14:13
zygapstolowski: thank you14:13
mborzeckihttps://www.reddit.com/r/linux/comments/8waf37/ubuntu_1804_linux_kernel_update_causes_boot/14:18
pstolowskizyga: np14:21
willcookepstolowski, hey14:22
pstolowskiwillcooke: hey, who is the best person to talk about gnome-calculator snap (and other gnome- snaps)?14:23
willcookepstolowski, kenvandine14:23
pstolowskiwillcooke: great, thanks14:23
willcookepstolowski, he's travelling this week to GUADEC, so he might not be active on IRC - if you get stuck drop an email our way14:24
kenvandinepstolowski, i'm arround, but in a meeting14:24
kenvandinepstolowski, and email would be best14:24
pstolowskikenvandine: sure14:27
roadmrjdstrand: pardon the silliness, where's the wiki with the text you pastebinned earlier?14:29
jdstrandroadmr: https://wiki.canonical.com/AppStore/Reviews14:31
roadmrjdstrand: thanks! We'll keep it as reference for the future14:32
jdstrandroadmr: I suggest also subscribing to the page14:33
roadmrDone! good idea jdstrand, thanks14:33
pedronisniemeyer: was afak having a break14:35
niemeyerpedronis: No worries, all good, we can sync tomorrow in the standup if we don't have an earlier opportunity14:36
zygamvo: still iterating over this14:36
zygamvo: I think the idea is sound but maybe not the direct implementation I went for14:36
zygamvo: (large and boring change)14:36
mvozyga: ok14:42
zygamvo: tests are not failing anymore, let me see if spread works14:45
* zyga -> coffee and more shade14:49
zygamy laptop is super hot from the sun14:49
* genii slides zyga a fashionable parasol14:50
roadmrgenii: it's for the laptop, I bet zyga is happy to get some sunshine after the long polish winter :)14:53
mvopedronis: are you ok with the current state of 5422, i.e. does the todo capture the plan correctly?14:53
mvoniemeyer: your opinion on 5440 would be great, no need for an in-depth code review (also that is welcome as well of course), more the question in the PR description. in a nutshell the question is: right now if refresh.timer is set we ignore refresh.schedule. should we do the same if "reresh.schedule=managed" is set? because in the old code we look at this special "managed" propoerty first before looking at refresh.timer/sc14:56
mvohedule. it means we *might* break people with refresh.schedule=managed but refresh.timer=some-thing-else (hope the question make sense, the PR also explain it slightly more verbosely)14:56
niemeyerThe question makes sense, but it's not clear what "should we do the same" means in this context14:57
niemeyerIt could mean two different things: 1) Respect refresh.schedule=managed; 2) Respect refresh.timer=managed14:58
mupPR snapd#5458 closed: tests: check catalog refresh before and after restart snapd <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5458>14:58
mupPR snapd#5467 closed: tests: stop restarting journald service on prepare <Blocked> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5467>14:58
niemeyermvo: I think we should keep the invariant: if we set refresh.timer, the value of the old setting doesn't matter anymore, whatever its value15:00
zygaroadmr: yes, this year the summer has really arrived early, with the exception of last week it's a record-breaking year in many cases15:00
roadmrzyga: like my neighbor says, "the weather is all f**d up"15:00
niemeyermvo: Then, we should respect "managed" in the new setting, in a way equivalent to how we respected it in "refresh.schedule" before15:01
roadmrrecord heat, then record cold... ti's all insane15:01
Chipacaroadmr: add more energy to a system and you're going to see more extremes to any oscillations you saw before (as long as you don't break it)15:02
* Chipaca crosses fingers15:02
roadmrChipaca: oh we're well on our way to break it :(15:02
Chipacaroadmr: eh, probably not15:03
Chipacaroadmr: i mean, we might all die, but it looks like earth'll be just fine15:03
Chipacawe should start burying stuff for non-human archeologists of the future just to mess with them though15:04
mvoniemeyer: the PR implements the behavior that if refresh.timer is set the setting of refresh.schedule is ignored, so it seems the PR is fine and my questions is answered15:04
roadmrChipaca: https://wiki.canonical.com/Quotes#A_matter_of_rates15:04
pstolowskizyga: as expected, nothing interesting in my state.json wrt gnome-calc issue15:05
niemeyermvo: Cool, I can review this afternoon it if you want, or LGTM if you think that's good enough info15:07
mupPR snapd#5430 closed: tests: enable new fedora image with test dependencies installed <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5430>15:07
mupPR snapd#5448 closed: tests: start using the new opensuse image with test dependencies <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5448>15:07
zygapstolowski: can you corelate the mount/unmount logs you gave from journalctl with your reboot to check if _any_ of those happened since your last boot15:08
mupPR snapd#5399 closed: tests: moving install of dependencies to pkgdb helper <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5399>15:08
zygapstolowski: I believe you can do this with journalctl -b -115:08
* zyga checks15:08
zygahmm15:09
zygarun journalctl --list-boots15:09
zygaactually it's just journalctl -b 015:10
zygapstolowski: ^15:10
pstolowskizyga: here you go, not sure if it's interesting:15:14
pstolowskihttps://www.irccloud.com/pastebin/aUJvZDwq/15:14
mupPR snapd#5242 closed: tests: new test for joystick interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5242>15:14
pstolowskizyga: and my system was started on Jul 1, 20:4815:14
mvopedronis: 5197 looks good, I would love a test tweak but I'm inclinded to merge just to get it into 2.34 - or is there a reason not to have it there?15:16
pedronismvo: afaik  the text  hasn't been finalized15:17
pedronismvo: sparkiegeek should know more15:18
mvopedronis: aha, I see he added a coment ~1h ago15:18
mvopedronis: there is an updated text, I can update/push if you want. I readded blocked for now to ensure it does not get in prematurely15:19
pedronismvo: ah, I missed that, yes we have a message, yes please update15:20
zygapstolowski: so according to this your system has booted on the 1st, started the two units and never stopped them15:20
zygapstolowski: that is useful, thank you15:20
mvopedronis: will do, thank you15:20
zygapstolowski: I will do some experiments, this is all I needed now15:21
* zyga forgot about the coffee and left it on the fire for too long15:21
* Chipaca ~> cuppa tea15:21
mvopedronis: are you ok with the current state of 5422, i.e. does the todo capture the plan correctly? (not sure if you saw this or if I missed the reply)15:21
pstolowskizyga: np. i'll keep it in the state it is now for some time in case we want to check something else15:22
pedronismvo: yes15:23
mvopedronis: thanks15:24
pedronismvo: are you going to cut a new 2.34 tomorrow?15:28
mvopedronis: yes, thats my plan, do final 2.34 tomorrow to ensure it can be tested over my vacation in beta/candidate15:28
mvopedronis: anything from your side that should be in it?15:28
pedronismvo: I'm discussing with Chipaca about:  https://forum.snapcraft.io/t/showing-edge-and-beta-in-search-results/4004/915:29
AuroraAvenueIs there a list of games that are snaps on ubuntu on the net sommewhere ?15:29
mvoreviews for 5440, 5422 would be great15:29
mvopedronis: thanks, let me look15:29
pedronismvo: we don't have a PR yet,  it would be small, once we know what exactly needs to go in it15:30
mvopedronis: ok15:31
mvopedronis: it should be fine if its done until tomorrow evening15:31
mvopedronis: 5197 is updated15:33
cachiomborzecki, to use amazon linux image15:33
cachiohttps://paste.ubuntu.com/p/Jt3fhhgYgP/15:33
cachioyou can build spread based on the PR15:34
cachiountil it is merged15:34
zygamvo: there?15:38
mvozyga: yes15:40
zygasorry, my reverse-i-search foo is rusty15:40
zygawhat is the suite to run core18 tests against?15:40
zygaI want to run the suite that shows core18 with snapd.snap and try interfaces and see what is broken now15:42
mvozyga: spread -v google:ubuntu-core-18-64 but you need to enable it in spread.yaml first, one sec15:42
mvozyga: http://paste.ubuntu.com/p/pz2ksT63jw/15:43
zygathanks15:43
Chipacawhat's a snap that's not devmode, but not in stable? if you know of one offhand15:44
zygammm15:45
mvozyga: I get dinner but please keep me updated, I will read backlog15:45
mvoChipaca: test-snapd-eds15:46
mvoChipaca: only available for i386/amd64 though if that matters15:46
zygamvo: ack15:46
Chipacamvo: cheers15:47
mvoyw15:47
zyga[m]vo: tests are running now15:49
mvozyga: woooooooooooooo15:49
mvozyga: can't wait for results15:49
zygahaha, the point of [m]vo is so that you _dont_ read now, enjoy your dinner :)15:49
mvozyga: once the interfaces tests work and are pushed I will push a new core18-all-tests-all-fixes PR so that we can run this in gce15:49
mvozyga: ;)15:50
zygaack15:50
* mvo really goes now15:50
mvozyga: or you can do that (push that PR), I don't mind :)15:50
=== pstolowski is now known as pstolowski|afk
zyga[m]vo: made some tweaks and re-started, I think it's a bit or a rabbit hole though, I stashed some changes that were going too deep16:18
=== twobitsp1ite is now known as twobitsprite
mupPR snapd#5311 closed: tests: start active system units on reset <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5311>16:37
zygamy network is not happy today16:48
zygaI ran out of my LTE plan16:48
zygawell, maybe not too bad16:50
ogra_use buckets17:05
zygathis ISP has unlimited LTE that's just capped17:07
zygabut capping at 5Mbit is not that terrible actually17:08
zygaI will buy a new connection tomorrow as the contract is running out already17:08
zygaand the new one has an outdoor all-year antenna17:08
zygaand much better plan17:08
zygawith enough steel rod I can go above the treeline17:09
zyga(though not super sure about that as trees are up to 30m tall17:10
zyga(a bit tall)17:10
zyga30-40 meters according to wikipedia17:11
zygamaybe not above treeline then17:11
zygaran core18 tests and didn't notice I stashed the change with main re-enabling17:12
zygarunning with those now17:13
mupPR snapd#5477 opened: tests: change the poll interval used by the network-bind-consumer snap <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5477>17:22
zygamvo: hmm17:22
zygahttps://www.irccloud.com/pastebin/63my3N4t/17:23
zygaany ideas?17:23
zygasnap changes 11 (install basic snap) https://www.irccloud.com/pastebin/zcHdhpuE/17:24
zygamvo: other tests are running, I'll let you know once they finish17:25
mvozyga: yes, snap install basic needs some of my core18 PRs, the problem is that the fake store does not have core and that is not installed by defalt on core1818:07
mvozyga: don't worry aobut this one, its understood and under control18:07
* mvo would love reviews for 5197 5440 542218:08
zygamvo: with my patches I got this far18:55
zygahmm18:56
zygasome pastebin failures18:56
mvozyga: how far?18:59
mvozyga: awsome, push it18:59
=== chiluk_ is now known as chiluk
* cachio afk20:16
mupPR snapd#5478 opened: many: run core18 tests <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5478>20:52
mupPR snapcraft#2176 opened: [WIP] tests: use pytest as test runner <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2176>22:51
mupPR snapd#5479 opened: store, daemon, client, cmd/snap: expose "scope", default to wide <Created by chipaca> <https://github.com/snapcore/snapd/pull/5479>23:13

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