/srv/irclogs.ubuntu.com/2018/08/16/#snappy.txt

mupPR snapcraft#2214 closed: sentry: support disabling error reporting <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2214>02:03
mupPR snapcraft#2215 closed: provider changes <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2215>02:03
mupPR snapd#5665 opened: tests: set ubuntu-core-18 as manual <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5665>02:34
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
mupPR snapd#5663 closed: overlord/devicestate: fix tests, set seeded in registration through proxy tests <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5663>04:59
mborzeckimorning05:05
mvohey mborzecki, good morning05:06
mborzeckimvo: hey, you're up early05:06
mvomborzecki: yeah, a one-off05:06
mborzeckimvo: did i miss anything interesting yday?05:06
mvomborzecki: not that much, a bit of thinking about what the best place for the udevmonitor is in the code, but that is more something for pawel. master is broken right now, thats not good (core18 seems to be not booting)05:07
mvomborzecki: but other than that it was relatively tame05:07
mborzeckimvo: master broken, how so?05:07
mvomborzecki: yesterday two PRs got merged that had subtle interrelatiations05:08
mvomborzecki: which broke unit tests05:08
mborzeckimvo: is the fix on review already? anyting i can help with?05:08
mvomborzecki: tests are fine again, samuele fixed those last night05:09
mvomborzecki: but spread is unhappy05:09
mvomborzecki: because of core1805:09
mvomborzecki: no idea why yet, there was a new kernel yesterday and of course a new snapd05:09
mvomborzecki: so maybe one of those broke things05:09
mborzeckimvo: aah interesting05:10
mvonice (ish) - "error: invalid xz chunk" in early boot05:17
mborzeckimvo: initramfs is xz compresses?05:18
mvomborzecki: yes and the kernel itself too iirc05:18
mborzeckimvo: uboot then? or is it amd64?05:19
mvomborzecki: amd6405:19
mborzeckimvo: https://github.com/kdave/grub/blob/master/grub-core/fs/squash4.c#L34805:21
mvomborzecki: the initrd seems to be the issue https://paste.ubuntu.com/p/zYBWc8rkZT/05:27
mvomborzecki: the kernel itself is gzip compressed05:27
=== chihchun_afk is now known as chihchun
mborzeckimvo: i guess decompressing it locally works right?05:30
mvomborzecki: yes05:30
mvomborzecki: but that is with xz/unxz05:30
mvonot the grub code05:30
zygaGood morning!06:43
zygaNew backdrop, day one :-)06:43
mvozyga: good morning06:46
zyga:-)06:46
zygaFirst day of real work after returning06:46
zygaIs anything on fire?06:46
mvozyga: core18 is not booting but the kernel was just reverted so hopefully it will be RSN06:48
zygaIn GCE or everywhere?06:49
mborzeckizyga: hey06:58
mborzeckimvo: there are some PRs that could land07:01
mvomborzecki: which ones07:02
mborzeckimvo: https://github.com/snapcore/snapd/pull/565707:02
mupPR #5657: interfaces: add cpu-control for setting CPU tunables <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5657>07:02
mvomborzecki: cool07:02
mborzeckimvo: this is real simple one https://github.com/snapcore/snapd/pull/564007:02
mupPR #5640: tests: skip unsupported architectures for fedora-base-smoke test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5640>07:02
mborzeckimvo: this one too https://github.com/snapcore/snapd/pull/565107:03
mupPR #5651: cmd/libsnap: unify detection of core/classic with go <Created by zyga> <https://github.com/snapcore/snapd/pull/5651>07:03
zygaI will begin the day with code reviews07:03
mborzeckihttps://github.com/snapcore/snapd/pull/5662 i'll restart the build in this one07:04
mupPR snapd#5657 closed: interfaces: add cpu-control for setting CPU tunables <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5657>07:04
mupPR snapd#5658 closed: interfaces: add cpu-control for setting CPU tunables (2.35) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5658>07:04
mupPR #5662: tests: avoid using the journalctl cursor when it has not been created yet <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5662>07:04
mborzeckimvo: fwiw this one can land too https://github.com/snapcore/snapd/pull/564507:06
mupPR #5645: tests: new test for udisks2 interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5645>07:06
mupPR snapd#5645 closed: tests: new test for udisks2 interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5645>07:07
mupPR snapd#5665 closed: tests: set ubuntu-core-18 as manual <Created by sergiocazzolato> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5665>07:07
mvomborzecki: 5635 should be an easy win07:08
mupPR snapd#5631 closed: snapstate: ensure normal snaps wait for the "snapd" snap on refresh <Core18> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5631>07:09
mupPR snapd#5635 closed: tests: enable lxd again everywhere <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5635>07:09
mborzeckicoffee time07:11
=== pstolowski|afk is now known as pstolowski
pstolowskiheyas07:12
zygagood morning pawel :)07:13
mvohey pstolowski07:16
pstolowskimvo: hey! thanks for the feedback on udev mon!07:16
mborzeckipstolowski: hey07:24
pedronismvo: hi,  how are things?  let me know when you think we can chat07:34
mvopedronis: just dealing with some autopkgtest failures, after that should be fine, so maybe in ~1h ?07:35
pedronisok, great07:35
mupPR snapd#5666 opened: tests: fix autopkgtest failures in cosmic <Created by mvo5> <https://github.com/snapcore/snapd/pull/5666>07:37
zygagood morning pedronis :)07:37
=== gurmble is now known as grumble
Chipacamvo: morning08:36
mvoChipaca: good morning08:36
Chipacamvo: who amongst us knows of our use of fwupdate? you, ogra, ...?08:36
mvoChipaca: I don't, but probably field engineering08:37
mvoChipaca: iirc its just in some of their devices08:37
Chipacamvo: asking because people are asking to drop it from main, replacing it wiht fwupd08:37
zygahey Chipaca08:41
zygaChipaca: interesting08:41
zygawe used one vs the other a while ago because of a customer request08:41
Chipacazyga: on core itself, or in images for that customer?08:42
Chipacacore itself doesn't ship it08:42
zygaI think it's an image with extra tooling08:43
Chipacathat is, http://cdimage.ubuntu.com/ubuntu-core/16/ doesn't have it :-)08:43
zygabut my memory is rusty now08:43
Chipacazyga: mvo: https://bugs.launchpad.net/ubuntu/+source/fwupdate/+bug/1787254/comments/708:45
mborzeckizyga: hah, so you've rewritten your memory in Rust?08:47
Chipacamborzecki: I think he meant 'rustig'08:47
zygamborzecki: I cannot remember since you hold onto that idea now08:48
mborzeckizyga: it's outlived by other memories08:49
mborzeckiChipaca: i'm sure this one would interest you too https://github.com/snapcore/snapd/pull/566708:50
ChipacaDENIED08:50
* Chipaca marks everything CHANGES REQUESTED today08:50
mborzeckiChipaca: may i offer you some cookies? :)08:51
ChipacaNO08:51
Chipacayes08:51
mborzeckidenied :)08:51
* Chipaca goes to make his own cookies, with blackjack and … hooks? chocolate jack daniels hook cookies?08:52
mborzeckiso go 1.11 changes gofmt slightly?08:54
Chipacamborzecki: why the change to the instancekey?08:54
zygamborzecki: oh, that would be fun08:55
=== mup_ is now known as mup
niemeyermup is back.. I still need to fix its identifying logic with nickserv so that he can speak here when he logs back in09:07
niemeyermup: You ok, right?09:07
mupniemeyer: I apologize, but I'm pretty strict about only responding to known commands.09:07
niemeyermborzecki: That happened in other releases of gofmt as wlel09:08
mborzeckiniemeyer: this one is quite subtle https://talks.godoc.org/github.com/mvdan/talks/2018/go1.11.slide#609:11
Chipacamborzecki: no more winxp support /o\ !!!09:11
niemeyermborzecki: Weird.. I don't recall seeing the first case I think09:12
niemeyerAh, maybe because I already split out the long names anyway so it's visually nicer09:13
niemeyerI've fired a new review board:09:13
niemeyerhttps://forum.snapcraft.io/t/review-sprint-6/690109:14
Chipacawhat does "Last release where godoc has a command-line interface" mean? 'godoc' is going away?09:14
ograChipaca, try cyphermox ... not sure who in field has any knowledge here, probably tony and alfonso09:14
niemeyerI know some of you are already on a review sprint somewhat, so just keep going :)09:14
Chipacaogra: I'll chat with tony later, i think09:14
ogra+109:15
niemeyerChipaca: godoc vs. go doc09:17
Chipacaniemeyer: but 'go doc' sucks :-/09:17
Chipacabah09:18
Chipacamaybe in .11 'go doc' grows an http server mode and all is well09:18
mupPR snapd#5662 closed: tests: avoid using the journalctl cursor when it has not been created yet <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5662>09:20
niemeyerChipaca: I doubt.. that's the opposite of what happened09:20
niemeyerChipaca: It used to have an http server09:20
niemeyerRight now it's a CLI, which isn't going away as I understand it09:21
niemeyerWhile godoc remains the web server09:21
niemeyerDoesn't seem bad..?09:21
Chipacaniemeyer: right, but 1.11 is the "last release where godoc has a command-line interface"09:21
niemeyerChipaca: Yeah, that's the subject.. :)09:22
Chipacaniemeyer: a command-line interface is how I launch the http server09:22
niemeyerChipaca: go doc will still have the CLI.. godoc will still have the web UI09:22
Chipacaniemeyer: if it doesn't have a command-line interface, it's just a library (or a gui app?)09:22
niemeyerChipaca: Ah, one of us misunderstands.. I think what's going away is the text output09:23
ChipacaI'm fine with that. I hope it's that.09:23
niemeyerChipaca: Of godoc.. it remains a web server09:23
niemeyerChipaca: https://tip.golang.org/doc/go1.11 =>09:24
ChipacaOTOH, we won't be using .11 until NEVER09:24
niemeyer"Go 1.11 will be the last release to support godoc's command-line interface. In future releases, godoc will only be a web server. Users should use go doc for command-line help output instead. "09:24
mvoChipaca: sorry was in a meeting, I have a look at 178725409:25
Chipacaniemeyer: phew09:25
Chipacaniemeyer: also! also! The godoc web server now shows which version of Go introduced new API features. <309:25
niemeyerChipaca: Oh, sweet!  Is there standard syntax we can use to tag our APIs?09:25
Chipacaniemeyer: I just read that bit, no idea :-)09:26
Chipacaniemeyer: it doesn't seem to be done with synta09:26
Chipacax09:26
niemeyerAww09:29
mborzeckihttps://github.com/snapcore/snapd/pull/5640 is an easy win09:36
mupPR #5640: tests: skip unsupported architectures for fedora-base-smoke test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5640>09:36
mupPR snapd#5640 closed: tests: skip unsupported architectures for fedora-base-smoke test <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5640>09:38
mupPR snapd#4951 closed: interfaces: add screencast-legacy for video and audio recording <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4951>09:42
ograChipaca, pedronis https://pastebin.canonical.com/p/fZ29ck4wfG/ (sorry for the secured pastebin, not sure there is confidential info in the logs)09:57
ograthis is from this mornings auto-refresh ... sadly i cant tell if the 1:30 timeout happened there since i was sleepig when it happened09:58
pedronisI see,  the logs looks regular there's as many "Waiting for system reboot" as there are "Requested system restart"10:02
ograyeah, and the timestamps indicate that there was no 1:30 timeout10:04
pedronisso at leasr from snapd own point of view, is shutting down as expected10:04
ograright ...10:04
ograi guess i'll have to wait for another one where it actually happens :(10:04
ograthis is annoying, i have seeen it a lot and on all my VMs for days ... typically if the core update happens right after booting up though10:05
mupPR snapd#5667 closed: store: backward compatible instance-key handling for non-instance snaps <Parallel installs> <Squash-merge> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5667>10:05
ograi'll make sure to leave one VM off tonight so it does the refresh immediately after boot tomorrow10:05
mupPR snapd#5668 opened: store: backward compatible instance-key handling for non-instance snaps (2.35) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5668>10:08
mborzeckimvo: ^^ a backport of 5667 for 2.3510:08
mvomborzecki: thank you10:11
niemeyerpstolowski: #4767 has reviews10:12
mupPR #4767: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>10:12
pstolowskiniemeyer: yes, thanks, i've almost finished addressing the new comments10:13
niemeyerpstolowski: Sorry, I meant to say I just had new ones too10:18
pstolowskiniemeyer: ah, ok, i saw mvo's comments only, allright10:18
mupPR snapcraft#2218 opened: many: replace yaml.safe_load() with CSafeLoader <Created by chipaca> <https://github.com/snapcore/snapcraft/pull/2218>10:27
mupPR snapd#5668 closed: store: backward compatible instance-key handling for non-instance snaps (2.35) <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5668>10:45
niemeyerzyga: #5307 reviewed10:46
mupPR #5307: cmd,interfaces,tests: add mnt interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5307>10:46
zygathanks10:46
mupPR snapd#5659 closed: tests: remove manual from openvswitch test <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5659>10:46
zyganiemeyer: thank you, I'm going through another review now but I'll address this one today10:48
niemeyerzyga: Thanks!10:49
mupPR snapd#5561 closed: overlord/snapstate: parallel snap install <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5561>10:52
mupPR snapd#5669 opened: asserts,image: support gaget tracks in the model assertion <Created by mvo5> <https://github.com/snapcore/snapd/pull/5669>10:59
mvomborzecki: btw, does 5596 have spread tests for parallel installs already? would be cool to add there to see itin action10:59
cachiomvo, hey11:00
cachiowhat did you do to fix core-18 builds?11:00
mvocachio: I asked the kernel team to revert to r137 of the pc-kernel snap11:04
mvocachio: the r140 version breaks11:04
mvocachio: its not clear yet why sadly11:04
cachiomvo, ahhh, nice11:04
mvocachio: but I was able to reproduce locally and I saw the grub failure in my qemu run11:04
mvocachio: I ran with SPREAD_QEMU_GUI=1 which made it easier (I think serial port would probably also have worked, but not sure)11:05
cachiomvo, I though it was a problem with the image11:05
cachiowith a dependency11:05
cachiobut didn't realize it was the kernel snap11:06
cachionice catch11:06
* niemeyer lunches11:06
mvocachio: yeah, it was very non-obvious what triggered it :/ I looked at the recent changes and noctied the kernel snap update from a couple of hours ago11:06
mborzeckimvo: the spread tests require a bit most stuff in the master branch11:06
mborzeckimvo: i'll be opening another bit after we're done with the review sprint11:07
mvomborzecki: oh, we are in a review sprint?11:08
mborzeckimvo: shh, dont' tell anyone :P https://forum.snapcraft.io/t/review-sprint-6/690111:08
mvomborzecki: hm, 2h ago? now I don't feel so bad anymore for not reading the memo in time11:09
mvoogra: fwiw, I also updated the pi* builds to use the bionic chroots (to be consistent with the whole ubuntu 18 idea :)11:11
ogramvo, makes sense for core 18 indeed11:12
mvoogra: lets hope no subtle issues come up11:13
ogramvo, well, you need to solve the update issues with dtb''s and firmware files in the gadget11:13
mvoogra: you mean for upgrades? yeah, that is going to be "fun"11:13
ogramvo, but IIRC you and niemeyer worked out plas for that with ondra, so i guess we're fine (are we ?)11:13
ograyeah11:14
ogra16 to 18 gadget upgrades11:14
ogras/plas/plans/11:15
mborzeckizyga: could you take a look at https://github.com/snapcore/snapd/pull/5654 later on?11:16
mupPR #5654: cmd/snap-confine: establish snap directory mappings for parallel instances <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5654>11:16
mupPR pc-amd64-gadget#8 opened: snapcraft.yaml: bump version number <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/8>11:18
zygamborzecki: yes, added to my queue :)11:19
mborzeckizyga: great, thanks11:19
mupPR pc-i386-gadget#6 opened: snapcraft.yaml: bump version number <Created by mvo5> <https://github.com/snapcore/pc-i386-gadget/pull/6>11:19
mupPR pc-i386-gadget#6 closed: snapcraft.yaml: bump version number <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/pc-i386-gadget/pull/6>11:24
mupPR pc-amd64-gadget#8 closed: snapcraft.yaml: bump version number <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/8>11:24
ograniemeyer, since you were asking for non-dismissive arguments regarding the unified pi gadgets, i'd appreciate if you could read https://forum.snapcraft.io/t/model-assertions-for-core18/6870/6 (if you did not read it yet) ... note that i do not expect an answer or change of the decision and i will let the topic rest, but i'd at least like that the decision making parties know all the technical backgrounds11:29
=== verterok` is now known as verterok
=== alan_g is now known as alan_g|lunch
mupPR snapd#5670 opened: daemon, overlord/snapstate: set instance name when installing from snap file <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5670>12:08
=== pstolowski is now known as pstolowski|lunch
pstolowski|lunchmvo: would you like to have another look at https://github.com/snapcore/snapd/pull/4767 or can i land?12:10
mupPR #4767: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>12:10
mupPR snapd#5636 closed: snap: fix advice json <Squash-merge> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5636>12:13
zygapstolowski|lunch: updated https://github.com/snapcore/snapd/pull/565112:17
mupPR #5651: cmd/libsnap: unify detection of core/classic with go <Created by zyga> <https://github.com/snapcore/snapd/pull/5651>12:17
mupPR snapd#5666 closed: tests: fix autopkgtest failures in cosmic <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5666>12:24
mvopstolowski|lunch: sure, I check the disconnect hooks PR now12:40
mvonice, down to 39 prs12:42
niemeyerGo go! :)12:45
* Chipaca goes12:53
=== pstolowski|lunch is now known as pstolowski
pstolowskizyga: thanks12:59
mvoniemeyer: I have a conflicting meeting today, I will see if I can leave it early and may join later12:59
mvoniemeyer: one important piece for the standup is that we need to figure out why r140 of the pc-kernel snap does not boot13:00
mupPR snapd#5651 closed: cmd/libsnap: unify detection of core/classic with go <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5651>13:03
=== alan_g|lunch is now known as alan_g
zygajdstrand: I have some questions about the changes to dbus wrt apparmor, when would be a good time to ask you some of those?13:06
jdstrandzyga: hey, ask away13:07
zygajdstrand: thanks, I'll write my questions down and paste after the standup13:08
Chipacamvo: https://www.amazon.co.uk/dp/B003U4NO7Y13:11
mvoChipaca: heh, the moto of my life13:55
* zyga runs for lunch13:59
Chipacaniemeyer: https://forum.snapcraft.io/t/defer-snapd-refresh-on-wake-from-suspend/4943?u=chipaca14:01
niemeyerThanks14:08
mupPR snapd#5671 opened: tests: basic test for parlalel installs from the store <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5671>14:12
Chipacamborzecki: for what installs?14:13
Chipaca:-)14:13
mborzeckiChipaca: plaplapel14:20
mborzecki:)14:20
mborzeckiniemeyer: https://github.com/snapcore/spread/pull/67 that's the MATCH fix14:35
mupPR spread#67: spread: run MATCH in a subshell <Created by mvo5> <https://github.com/snapcore/spread/pull/67>14:36
niemeyermborzecki: Thanks! Let me merge that and release it14:36
niemeyermborzecki: Please give it a shot14:42
mvopstolowski: could you please check https://github.com/snapcore/snapd/pull/4767#discussion_r210180691 - I wonder if the name of the test still matches what is done given that its now a (retry) error14:48
mupPR #4767: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>14:48
pstolowskimvo: i'm sorry, i think i missed it, checking14:49
mvopstolowski: thanks! one more https://github.com/snapcore/snapd/pull/4767/files#r195361520 - i think GH was hidding those from you :) I had to manually expand14:50
mupPR #4767: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>14:50
mvopstolowski: if you need to do code change give me a shout and I send a diff to you, but only then, its not super important but if it does a full test run anyway I might as well propose my diff14:51
pedronismborzecki: in your task/todo sequencing when are you thinking of attacking alias code and other places that assume snap-id <-> 1 snap14:51
pedronis?14:52
mupPR snapcraft#2219 opened: Release changelog for 2.43 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2219>14:52
niemeyerTaking a break here14:55
pstolowskimvo: grr, indeed, thanks. i'm not sure why i missed them, i'm pretty sure i looked at the 'files' tab, not 'conversation'14:55
pstolowskimvo: pushed14:55
mvopstolowski: no worries14:55
mvopstolowski: thank you14:55
pstolowskii hope travis is still in good and cooperative mood today ;)14:57
* pstolowski is knocking the wood14:58
pedronismvo: btw some of the tasks/todo we discussed this morning were mentioned here:  https://forum.snapcraft.io/t/seeding-snaps-that-plug-the-content-interface/5579/314:59
cachio__niemeyer, about the secrets for the spread cron project15:00
cachio__niemeyer, what can I do for that?15:00
mborzeckipedronis: up next is adding mkdir of for snap name in handlers code when instance one is installed and cleanup, then i plan to look into aliases and the store hash stuff after that15:00
mborzeckipedronis: that's paralell to stuff being landed which happens at it's own pace15:01
pedronismborzecki: ok, there might be more code that has similar issues as aliases, we can discuss when you get to alias stuff15:01
mborzeckipedronis: ack15:01
mborzeckipedronis: off the top of your head do you recall what that might be?15:02
pedronismborzecki: refreshing assertions and relatedly refresh-control/validation code15:02
pedronisin some cases might just be that we do things too many times (instead of once), other they might be bug15:03
pedronismborzecki: as I said, its code that is sort of assuming that  one snap id <->  1 snap so far15:03
=== chihchun is now known as chihchun_afk
mvopedronis: nice, thank you15:05
pedronismborzecki: also Update code might have that problem15:05
Chipacaniemeyer: I went through all your feedback on the snapshotstate pr and replied (but I didn't have any argument with any of it, it's all "yep, done")15:05
pedronisor maybe you fixed that already15:05
mborzeckipedronis: as in snapstate.Update?15:05
pedronisUpdateMany15:05
pedronismborzecki: this kind of code:   snapst := stateByID[update.SnapID]15:06
pedronisseems to still be there15:07
mborzeckipedronis: yeah, see that, ok, so that piece is up next then15:08
pedronismborzecki: so there is various code like that15:08
pedronisin the places I mentioned15:08
pedronismost of it I think is close/around Update/UpdateMany15:09
mborzeckipedronis: thanks, noted that down15:11
pedronismborzecki: it mostly lives in snapstate and assertsstate I think15:12
mborzeckiwish i had a tool to integrate org-mode notes with the forum :) hopefully's niemeyer will fill that gap15:13
* cachio__ lunch15:14
mupPR snapd#5672 opened: tests: make nfs test available for more systems <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5672>15:16
mvojdstrand: if you have a moment, a comment on https://github.com/snapcore/snapd/pull/5615#discussion_r210516258 would be great, not sure if its worth persuing or if I should land as is and just iterate if the people using it have problems (i.e. if those are symlinks for them as well)15:27
mupPR #5615: interfaces: add new "sysfs-name" to i2c interfaces code <Created by mvo5> <https://github.com/snapcore/snapd/pull/5615>15:27
mupPR snapd#4767 closed: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4767>15:33
jdstrandmvo: commented15:34
mvojdstrand: ta!15:35
pstolowskiwoot, yay \o/15:35
mupPR snapd#5673 opened: ifstate: extra common code into checkAutoConflicts() <Created by mvo5> <https://github.com/snapcore/snapd/pull/5673>15:36
mvopstolowski: yeah, good stuff!15:37
jdstrandzyga: you mentioned something about a list of questions after a meeting?15:38
zygajdstrand: re, yeah sorry I just got carried away by things I was doing locally15:56
zygajdstrand: so I was looking at that PR that reacts to dbus changes15:57
zygajdstrand: and I wasn't quite sure how some of the actual differences made by the patches fit into labelling and activation15:57
zygajdstrand: let me pull up an example15:58
mupPR snapd#5615 closed: interfaces: add new "sysfs-name" to i2c interfaces code <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5615>15:58
jdstrandzyga: it might help if I mention that clients don't have to do anything to activate a service, they just start using it. how they start is client dependent16:00
jdstrandzyga: hostnamectl does via a GetAll(). I know others do Introspect()16:00
zygaright, I see16:00
jdstrandzyga: so I just focused on those rather than discarding the label check entirely16:01
zygajdstrand: as a quick patch in the branch let's look at https://github.com/snapcore/snapd/pull/5664/commits/64ea1623b9b383cd649da48d315e54bc56d37822 - I was expecting to see removal of peer=(label=unconfined), instead there is some more logic16:01
jdstrandzyga: figuring if we get a bug, we would address it16:01
mupPR #5664: interfaces: workaround for activated services and newer DBus <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5664>16:01
jdstrandzyga: I added Get and GetAll proactively16:02
zygaI also don't understand why some have send and some both send and receive16:02
zygaaha16:02
jdstrandzyga: they should be send16:02
jdstrandI can fix that16:03
zygaso I can expect various patches to add Introspect and Get, GetAll16:03
zygalike this one https://github.com/snapcore/snapd/pull/5664/commits/06f8e5b7f0e33c454b2ea8516958d61cca39761a16:03
mupPR #5664: interfaces: workaround for activated services and newer DBus <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5664>16:03
jdstrandzyga: well, each interface is slightly different. I noticed in that interface there was only the Inhibit rule, no Get, GetAll or Introspect, so I updated it16:04
zygajdstrand: ok, with the send vs receive resolved and with your explanation on new methods I think I understand what this is doing16:05
zygathanks, I will approve it now16:05
jdstrandzyga: I'll check for receive/send and make sure it is correct. it is likely just in a couple of places where I copied a broad send/receive rule to a particular path and forgot to remove the receive16:06
t1mphello16:09
zygahey t1mp16:09
t1mpquestion: why is snapcraft trying to pull my package wheel file from PyPI, if I built that in a previous part with the python plugin?16:10
zygakyrofa, sergiusens: ^16:10
t1mphmm, let me check something, maybe I have that explicitly defined somewhere :)16:11
ograbecause you didnt feed enough cake to snapcrafts AI ?16:11
niemeyerChipaca: Thanks!16:11
* Chipaca checks his pockets16:11
t1mpogra: yeah, probably something like that :)16:11
ogra:)16:11
Chipacaniemeyer: you're welcome!16:11
sergiusenst1mp: maybe it is not on the expected path.16:11
t1mpI didn't want to build the python wheel file in snapcraft actually because I did that in a previous stage on jenkins. But I don't see a way to use a local .whl instead of pulling it from PyPI, except building it in an earlier stage16:12
jdstrandmvo: oh, I was surprised you merged PR 5615...16:12
mupPR #5615: interfaces: add new "sysfs-name" to i2c interfaces code <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5615>16:12
sergiusenst1mp: pip has some rules that if you download the wheel to specific locations would satisfy the dependency16:12
sergiusensbut I will need to forward you to a search engine to find that path.16:12
jdstrandmvo: I commented here https://github.com/snapcore/snapd/pull/5615#discussion_r210643334 - that is what I meant before. sorry if I was unclear16:13
t1mpsergiusens: ah ok, that might be useful. I think that is something to put in the pip config file, which I could just copy into the snap16:14
t1mpthanks :)16:14
mvojdstrand: I replied via mail, apparently someone looked at this and considered it okay16:14
jdstrandah. I'm still slogging through email16:15
mvojdstrand: I'm not sure it is but even if it is not I will have to add one extra commit16:15
* jdstrand nods16:15
mvojdstrand: so if I add the commit now or later seems to be the same, testing it as is leaves the (small) chance it may actually be not symlinks in the kernel they use16:15
mvojdstrand: but if its symlinks and its not stable we have a problem :(16:15
jdstrandmvo: it might not be so bad. depends on what the target is16:16
mvojdstrand: aha, if its always the same range you mean? yeah, then it will be okay16:16
jdstrandmvo: eg, maybe /sys/devices/**/i2c/<name>/** or something16:17
* mvo nods16:17
jdstrandthe /sys/devices/**/ would be the non-deterministic part, but we could glob that away16:17
jdstrandat least, that is my hope :)16:17
mvojdstrand: yeah, it appears to be like this on amd64 at least so I should probably do the followup in any case to make this useful on amd6416:18
mvojdstrand: but dinner first :) thanks for your input, thats good stuff16:18
jdstrandmvo: enjoy! :)16:19
mvojdstrand: I added a comment and will work on it later/tomorrow.16:20
mvottfn16:20
jdstrandmvo: thanks! :)16:21
=== pstolowski is now known as pstolowski|afk
pedronisChipaca: not sure exactly what you are struggle on, but gave one of the examples I had in mind16:35
pedronis*struggling on16:35
Chipacapedronis: thank you16:35
Chipacapedronis: I probably just need a break16:35
Chipacapedronis: :-)16:35
Chipacaalso i need to stop context-switching like a deranged chipmunk16:36
Chipacapedronis: as for you, go away :-) let's talk tomorrow if I'm still stuck.16:37
=== cachio__ is now known as cachio
om26eralan_g: Hello!16:40
alan_gom26er, hellp16:41
om26eralan_g: This tutorial is useful https://tutorials.ubuntu.com/tutorial/graphical-snaps#0 but is there a more "complete" one that actually launches a Qt/Gtk based app on UbuntuCore system ?16:41
om26erwe have a snap that works fine on wayland desktop and are looking to make that a kiosk-mode app.16:42
alan_gom26er, not yet. But there's an example: https://forum.snapcraft.io/t/shipping-later-qt-with-snap/687316:43
om26eralan_g: how far along is Mir/Wayland on UbuntuCore being "production" ready ?16:44
om26erfor now we are doing a demo but I believe if this goes well, we'll be doing a full-blown product, so wanted to know.16:44
* zyga -> walk16:45
alan_gom26er, Basically, it works now. There's one thing we want to iron out, but that shouldn't worry you: https://community.ubuntu.com/t/snaps-and-sharing-mirs-wayland-socket/7539/116:46
alan_ggreyback, is working on that, and will update and extend the tutorials "real soon now".16:47
greybackom26er: hey, I'll share something like that when I've all theekinks ironed out16:49
om26eralso the "layouts" feature is also experimental, though I hope it'll graduate some time soon ?16:49
om26ergreyback: that'd be helpful. I am currently trying to run a PySide2 (Qt for Python) app on a UbuntuCore based system. namely Siemen's SIMATIC ipc327e.16:51
om26erit runs on my wayland session (desktop) (fully confined)16:52
greybackom26er: ack. What version of Qt are you using?16:52
om26ergreyback: Qt 5.11, its shipped with PySide's .whl16:52
om26ersource https://download.qt.io/snapshots/ci/pyside/5.11/latest/pyside2/?C=M;O=D16:53
greybackom26er: ok, good, it's nice and new. That shouldn't have any issues with Mir16:53
Chipacapedronis: I was not adding the taskset to a change. Can I have a dunce emoji?16:58
alan_gom26er, BYW if you need to test with a Mir based Wayland session there's https://snapcraft.io/egmde17:03
pedronisChipaca: ah, couple of methods of state don't return tasks unless they are attached to a change17:17
om26ercool my snap PySide2 snap works in egmde session.17:25
om26ers/snap//17:25
cachiokyrofa, hey18:37
niemeyercachio: We can see the spead-cron issue soon if you'll be around18:40
cachioniemeyer, yes18:40
cachiojust ping me18:40
niemeyerCool18:41
kyrofaHey there cachio18:53
cachiokyrofa, hey, quick question, are you setting travis for snapcraft on gce west zone?18:54
cachioI saw some instances on us-west1-b yesterday18:54
kyrofacachio, indeed I am, west1-b18:54
kyrofaYep, probably us18:55
cachiokyrofa, ahh, could you please use the us-east1-b for travis?18:55
cachioso machines with more than 2 hours will be automatically removed18:55
kyrofaAh, we only garbage collect that region eh? Sure, we can switch18:56
cachioyes, it is by region18:56
cachiothanks18:56
Chipacaniemeyer: snapshotstate is ready for a look19:03
mborzeckicachio: you around? left a note for you https://github.com/snapcore/snapd/pull/5624#discussion_r21070798519:04
mupPR #5624: tests: get the linux-image-extra available for the current kernel <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5624>19:04
cachiomborzecki, sure19:04
mborzeckicachio: there was a typo in the code i suggested :P i missed a space19:04
cachiomborzecki, let me test it with the new kernels19:11
cachiomborzecki, I see a difference between your function and the one I did, and it is that what we return when the first option does not match19:13
niemeyerChipaca: Danke!19:18
niemeyercachio: Alright.. do you have a build log for the failure?19:19
Chipacaniemeyer: nichts zu danken19:19
cachioniemeyer, yes, 1 min please19:19
cachioniemeyer, https://travis-ci.org/snapcore/spread-cron/builds/416898556#L54819:20
niemeyerChipaca: danke für deine Freundlichkeit19:20
niemeyer(hope Google Translate did a good job there... ;P)19:21
cachioniemeyer, Chipaca Jeder spricht Deutsch mit Google Translate19:22
niemeyercachio: Hmmm.. that's a strange log19:22
niemeyercachio: I hope it's just auth, because it doesn't really look like it19:23
cachioniemeyer, we can try generating the secrets for this project and see19:23
* niemeyer installs travis client from some guy named kyrofa 19:25
mborzeckicachio: hm with this change you'll install the package matching your kernel (probably something we want?)19:27
cachiomborzecki, yes19:28
cachioI tested that with the problematic kernel and worked19:28
cachiomborzecki, I'll push the change19:29
cachiomborzecki, lets see how it goes19:30
niemeyerkyrofa: It's not working :(19:30
niemeyer% travis encrypt foo19:30
niemeyerOutdated CLI version, run `gem install travis`.19:30
niemeyerNo such file or directory - git19:30
niemeyerfor a full error report, run travis report19:30
kyrofaWhat.19:31
kyrofaI didn't realize it did a version check19:31
cachiomborzecki, if you give the +1 I can merge it wwhen the tests are in green19:31
cachiomborzecki, so I can update the ubuntu xenial 64 images19:31
niemeyerkyrofa: Most things I run seem to result in that error19:31
niemeyer--help works tho19:31
mborzeckicachio: +1'ed :)19:32
kyrofaniemeyer, yeah it must check it server-side. I'll update it19:32
cachiomborzecki, thanks19:32
kyrofaWhat the heck. They tagged it four hours ago19:32
niemeyercachio: Can you please put an "env" call just above the spread call so I can have a vague idea of what's the context there?19:41
cachioniemeyer, sure19:42
cachioniemeyer, https://travis-ci.org/snapcore/spread-cron/builds/41697234519:44
sergiusensniemeyer cachio another option is to setup the encrypted keys from https://travis-ci.org/snapcore/spread-cron/settings19:56
sergiusensI cannot see that url fwiw as I am not in a relevant team for that19:56
sergiusensI don't know what key is used there though19:58
cachiosergiusens, well, not sure which is the problem itself20:01
cachioniemeyer, is it not fixed by doing the same you did for snapd project?20:02
niemeyercachio: SHould be, but I'll need to find a working travis tool.. will need to get dinner before that20:02
cachioniemeyer, sure20:02
mupPR snapd#5624 closed: tests: get the linux-image-extra available for the current kernel <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5624>20:02
=== Son_Goku is now known as Conan_Kudo
=== Conan_Kudo is now known as Son_Goku
mupPR snapd#5674 opened: tests: add the original function to fix the errors on new kernels <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5674>20:41
jdstrand_zyga: wrt fedora base, I forgot about this: https://forum.snapcraft.io/t/process-for-reviewing-base-snaps/304020:41
=== jdstrand_ is now known as jdstrand
niemeyercachio: I've sent the data for travis.yaml in spread-cron privately21:04
niemeyercachio: Please add it and give it a shot21:04
niemeyerAnd with that success I call it a night and end on the right foot.21:11
niemeyerSee you all tomorrow.. same time, same place21:12
kyrofaniemeyer, travis snap should be better now21:15
cachioniemeyer, see you, thanks for this help21:20

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