[06:57] <mup> PR snapd#2921 closed: releasing package snapd version 2.22.6 <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2921>
[07:03] <mup> PR snapd#2922 opened: many: merge 2.22.6 back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/2922>
[07:36] <_prasen_> https://github.com/mectors/sensortag
[07:36] <_prasen_> hi
[07:36] <_prasen_> while building this snapcraft filw
[07:37] <_prasen_> i get a error of property does not match the schema
[07:39] <_prasen_> Issues while validating snapcraft.yaml: The 'parts/move/filesets/sensortag-in' property does not match the required schema: 'bin/sensortag-in' is not of type 'array'
[08:21] <mup> PR snapd#2893 closed: tests: bail out if core snap is not installed <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2893>
[08:21] <mup> PR snapd#2917 closed: osutil: remove duplicate build_id from other branch <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2917>
[08:37] <zyga> hi
[08:37] <zyga> _prasen_: probably outdated repo, snapcraft is changing over time
[08:44] <_prasen_> how do i fix this?
[08:44] <_prasen_> should it be of type string?
[08:44] <_prasen_> is this a problem of vim?
[08:47] <zyga> _prasen_: no, this is not related to vim
[08:47] <zyga> _prasen_: I don't know, sorry, just waking up after long evening work
[08:48] <zyga> _prasen_: I'd suggest yu ask mectors to correct this repository
[08:48] <_prasen_> hahahhahaha
[08:48] <_prasen_> i am like starting my day
[08:48] <_prasen_> though its well past noon
[08:48] <_prasen_> working with yaml for first time
[08:49] <_prasen_> so saw that there could be errors due to ansi indent
[08:49] <_prasen_> zyaga: will do that
[08:49] <_prasen_> zyga*
[08:49] <_prasen_> zyga: ty _/\_
[08:51] <zyga> _prasen_: good luck :)
[08:54] <zyga> mvo: do you think you could do a 2nd review of https://github.com/snapcore/snapd/pull/2848
[08:54] <mup> PR snapd#2848: cmd/snap-update-ns: add compare function for mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/2848>
[08:54] <zyga> mvo: it's been out for 9 days and I'd like to push forward
[09:29] <mup> PR snapd#2477 closed: interfaces/builtin: first cut at repowerd interface <Created by afrantzis> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2477>
[10:45] <mup> PR snapd#2818 closed: Allow specifying another store via commandline option for the download command <Created by morphis> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2818>
[10:57] <mup> PR snapd#2847 closed: tests: enable docker test <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2847>
[11:01] <ppisati> uhm
[11:01] <ppisati> what am i doing wrong?
[11:01] <ppisati> https://travis-ci.org/snapcore/snapcraft/jobs/204522771
[11:04] <ppisati> ogra_: i know you are not the right person but, do you know who's the snapcraft/store guy here for this ^?
[11:04] <ppisati> mvo: you too ^
[11:05] <ogra_> ppisati, fgimenez
[11:05] <ppisati> fgimenez: ^
[11:05] <ogra_> he's the master of tests :)
[11:05] <mvo> ppisati: sergiusens is usually the goto person for snapraft* but let me have a look
[11:05] <ppisati> yeah, it's more like 'it explodes while trying to download a snap'
[11:06] <mvo> ppisati: this looks like the store was giving a connection reset during the tests
[11:06] <mvo> ppisati: so a simple retry, sometimes we have these problems (store or cdn, one of those)
[11:06] <mvo> ppisati: I can restart the job for you if you want
[11:06] <mup> PR snapd#2848 closed: cmd/snap-update-ns: add compare function for mount entries <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2848>
[11:07] <ppisati> mvo: can i do it myself? so i won't bother anyone next time
[11:08] <mvo> ppisati: I'm not sure, it may well be that you can't and only people with certain privs in the snapcore group can. I restarted it now
[11:08] <ppisati> mvo: ta
[11:15] <niemeyer> jdstrand: Easy one, maybe: snapd#2855
[11:15] <mup> PR snapd#2855: interfaces/builtin: add intel realsense udev rules into camera interface <Created by swem> <https://github.com/snapcore/snapd/pull/2855>
[11:18] <mup> PR snapd#2836 closed: release: assume higher version of supported distros will still work <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2836>
[11:21] <mup> PR snapd#2857 closed: interfaces/builtin: add /boot/uboot/config.txt access to core-support <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2857>
[11:27] <mup> PR snapd#2817 closed: many: switch channels on refresh if needed <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2817>
[11:45] <_prasen_> working behind corporate proxy, while running snapcraft a part needs npm to install a sdk. to pass the proxy variables to npm we need to set proxy and https-proxy var's in .npmrc file
[11:46] <_prasen_> and for npm install we have to pass the flags : --without-ssl , --insecure
[11:46] <_prasen_> how do i tell snapcraft to take these flags
[11:58] <mup> PR snapd#2839 closed: debian/tests: map snapd deb pockets to core snap channels for autopkgtest <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2839>
[12:06] <fgimenez> ogra_, ppisati hey :) for snapcraft-related issues about tests and CI elopio is the right person to ask
[12:06] <ogra_> thanks
[12:13] <mup> PR snapd#2923 opened: cmd/snap-update-ns: add function for sorting mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/2923>
[12:32] <mup> PR snapd#2870 closed: tests: failover test for rc.local crash <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2870>
[12:38] <jdstrand> niemeyer: ack
[12:39] <jdstrand> morphis: hey, is there a slot implementation of upower-observe?
[12:40] <zyga> jdstrand: o/
[12:41] <jdstrand> hey zyga :)
[12:41] <mvo> ppisati: looks like your test is green now
[12:44] <morphis> jdstrand: yes, we added that recently
[12:45] <jdstrand> morphis: right. I mean, do you have a snap that slots upower-observe
[12:45] <morphis> yes we do
[12:46] <morphis> jdstrand: but not yet in stable
[12:46] <morphis> snap install --candidate upower
[12:46] <jdstrand> morphis: great, thanks!
[12:47] <morphis> jdstrand: any specific reason you're asking for or just for reference?
[12:49] <jdstrand> morphis: I am preparing a PR to mediate socket(PF_NETLINK, ...) and saw that upower uses udev, and I need to add 'socket PF_NETLINK - NETLINK_KOBJECT_UEVENT' to its PermanentSlot policy and want to test that it is enough
[12:50] <morphis> ah ok
[12:54] <jdstrand> morphis: there are a few slots that you guys wrote that I've made adjustments to and will ping you in the PR
[12:55] <morphis> jdstrand: thanks
[13:03] <zyga> jdstrand: did you see that error I reported for zesty yesterday?
[13:04] <mup> PR snapd#2922 closed: many: merge 2.22.6 back into master <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2922>
[13:04] <jdstrand> zyga: I did. I commented in the bug
[13:04] <zyga> jdstrand: it's not an urgent thing but I'd like to fix it as zesty freezes and it breaks all the tests
[13:04] <zyga> jdstrand: thank you!
[13:05] <zyga> jdstrand: I'll try the kernel that jj recommended
[13:27] <mup> PR snapd#2833 closed: many: allow core refresh.schedule setting <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2833>
[13:28] <mup> PR snapd#2810 closed: snap: use snap-confine from the core snap <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2810>
[13:28] <mup> PR snapd#2874 closed: kmod: added Specification for kmod security backend <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2874>
[13:45] <mup> PR snapd#2878 closed: data/selinux: merge SELinux policy module <Created by Conan-Kudo> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2878>
[13:45] <Son_Goku> 🎉
[13:46] <Son_Goku> zyga: this means that now proper snapd selinux integration can begin
[13:46] <Son_Goku> since we have "official" labels for things :)
[13:46] <zyga> Son_Goku: :-)
[13:46] <zyga> Son_Goku: I'm happy to see this
[13:46] <zyga> Son_Goku: I'm sleepy after 2AM release last night
[13:46] <zyga> Son_Goku: but with the main fire out I think next week will see some releases
[13:47] <Son_Goku> I'm thinking that we should regenerate the packaging from gofed
[13:47] <zyga> Son_Goku: though I'm on holidays since Tue
[13:47] <zyga> Son_Goku: all of it?
[13:47] <zyga> Son_Goku: for snapd or for deps?
[13:47] <Son_Goku> snapd
[13:47] <Son_Goku> there's been a lot of churn and I don't know what things are anymore :(
[13:47] <zyga> Son_Goku: we can, I think that's ok
[13:48] <Son_Goku> now that the SELinux policy is merged into the repo, I can start rebasing my packaging on that
[13:48] <Son_Goku> :D
[13:49] <Son_Goku> zyga: do we have a file that declares what our deps are in snapd?
[13:49] <Son_Goku> I'm not completely familiar with how this works in golang
[13:49] <zyga> Son_Goku: yes, it's called...
[13:49] <zyga> Son_Goku: vendor/vendor.json
[13:50] <Son_Goku> ah, so it's in the vendor directory
[14:18] <mhall119> jdstrand: I tried to push a php-based snap to the store and got this:
[14:18] <mhall119> found errors in file output: unusual mode 'rwx-wx-wt' for entry './var/lib/php/sessions'
[14:19] <mhall119> I didn't do anything special, and php is installed via stage-packages
[14:21] <jdstrand> mhall119: what is the name of the snap?
[14:24] <mhall119> laravel-mhall119
[14:25] <jdstrand> mhall119: can you request manual review in the store?
[14:25] <mhall119> I can, but I also want to make sure this doesn't happen for every php-based snap if we can avoid it
[14:25] <jdstrand> mhall119: I understand. I will fix the review tools for that
[14:26] <jdstrand> rwx-wx-wt is unusual, but it doesn't hurt anything
[14:27] <mhall119> jdstrand: requested
[14:44] <ppisati> fgimenez: can you help me with some snapcraft tests?
[14:46] <fgimenez> ppisati, i can try but probably better to ask elopio, i'm not actively working on them
[14:47] <ppisati> fgimenez: k
[14:47] <ppisati> elopio: ^
[14:53] <mup> PR snapd#2924 opened: interfaces: specs for apparmor, seccomp, udev <Created by stolowski> <https://github.com/snapcore/snapd/pull/2924>
[14:54] <mup> PR snapd#2891 closed: interfaces/udev: added spec <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2891>
[14:55] <mup> PR snapd#2890 closed: interfaces/apparmor: add spec <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2890>
[15:00] <mup> PR snapd#2883 closed: seccomp: added Specification for seccomp backend <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2883>
[15:01] <fgimenez> hey kyrofa :) i'm trying to do some tests on the nextcloud image, have a minute for some questions?
[15:02] <mhall119> jdstrand: do you need a bug report for that unusual file permission?
[15:07] <zyga> jdstrand: can I add the snippet that will make the zesty regression no break all the PRs for snapd?
[15:07] <zyga> jdstrand: (along with a note and a bug reference)
[15:07] <zyga> jdstrand: note that this is just for jailmode on classic snaps so pretty isolated
[15:46] <Son_Goku> sergiusens: hey
[15:46] <Son_Goku> have you made any progress on the repo refactor thing?
[15:54] <kyrofa> fgimenez, ah, sorry, responded to your internal ping first, heh
[15:54] <fgimenez> kyrofa, np! thanks :)
[16:00] <lool> ppisati: hey!
[16:01] <lool> ppisati: so https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1652504?comments=all is apparently hitting one of the demos for MWC
[16:01] <mup> Bug #1652504: Recent updates broke Ubuntu on Raspberry Pi 3 <armel> <kernel-da-key> <regression-update> <xenial> <yakkety> <flash-kernel (Ubuntu):Confirmed for fo0bar> <linux (Ubuntu):Confirmed for fo0bar> <https://launchpad.net/bugs/1652504>
[16:01] <lool> ppisati: I'm not sure they need video output (checking with them), but they've just passed this bug to me
[16:04] <lool> ppisati: ok, it's not critical, they're just giving us a heads up
[16:04] <mup> PR snapd#2925 opened: [WIP] interfaces: migrate existing intarfaces to use new kmod and seccomp spec <Created by stolowski> <https://github.com/snapcore/snapd/pull/2925>
[16:10] <ppisati> lool: i thought ryan fixed that already
[16:11] <lool> ppisati: do yo know where the fix is?
[16:11] <ppisati> lool: actually, it doesn't break video, your board won't boot at all
[16:11] <ppisati> lool: wait wait
[16:11] <ppisati> lool: that bug, was because ryan's image didn't have the correct address for the dtb
[16:11] <lool> ok
[16:12] <ppisati> lool: if you are hitting that bug, your board won't boot at all
[16:12] <ppisati> lool: but you mention a problem with video output
[16:12] <lool> ppisati: that's what they said
[16:12] <lool> I'm proxying here
[16:13] <ppisati> lool: ok, if you want to loop me in any conversation
[16:13] <lool> ppisati: so the workaround/fix is to correct DTB addr and we'll land that soon and can be applied manually in the mean time?
[16:13] <ppisati> lool: i can test if that bug was fixed in the meantme
[16:13] <lool> ppisati: we're on their slack
[16:13] <lool> I've invited folks here
[16:13] <ppisati> lool: let me reinstall the image, so i can check what's the status
[16:14] <lool> ppisati: thanks man
[16:23] <mup> PR snapcraft#1158 closed: packaging: snapcraft as a snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1158>
[16:29] <mdye> @ppisati hi there, @lool passed on the word that we had trouble with video after updating our ryan's pi3 image to kernel 4.4.0-1042-raspi2
[16:29] <nothal> mdye: No such command!
[16:30] <mdye> bad slack habits :)
[16:31] <lool> mdye: Hey!
[16:31] <mdye> lool: ahoy!
[16:31] <ppisati> mdye: fb or mir?
[16:32] <lool> ppisati: ^ mdye is setting up a jetson tx1 + pi3 boards demo for MWC; he's also a really awesome guy  :-)
[16:32] <mdye> ha, thx
[16:33] <mdye> ppisati: so the jist is we build a pi3 image from ryan's base in a chroot; I use FLASH_KERNEL_SKIP=1 to get kernel updates installed successfully in the chroot
[16:33] <ppisati> mdye: ok
[16:33] <mdye> the config.txt on the updated pi3 has device_tree_address=0x100 and device_tree_end=0x8000 (which I think are the original addresses from earlier images)
[16:35] <mdye> the result is a system that will boot the kernel, but the kernel command line "console=tty1" isn't applied such that the console never outputs messages after uboot hands control over to the kernel
[16:37] <ppisati> mdye: uhm, that is weird
[16:37] <ppisati> mdye: is you did a dist-upgrade, you should get a new firmware too
[16:37] <ppisati> *if
[16:37] <ppisati> mdye: that would move the dtb address around, and your board wouldn't boot then
[16:37] <ppisati> mdye: i'm reinstalling an image to check, hold on
[16:38] <mdye> ok, thx
[16:43] <mup> PR snapd#2861 closed: [WIP] interface hooks: expose attrs to the interface API, snapctl enhancements (step #4) <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2861>
[16:43] <mup> PR snapd#2896 closed: httputil: copy some headers over redirects <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2896>
[16:43] <mup> PR snapd#2925 closed: [WIP] interfaces: migrate existing interfaces to use new kmod and seccomp spec <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2925>
[16:55] <mup> Bug #1667359 opened: After a reboot store was not accessible <Snappy:New> <https://launchpad.net/bugs/1667359>
[16:57] <mup> PR snapd#2923 closed: cmd/snap-update-ns: add function for sorting mount entries <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2923>
[16:59] <zyga> jdstrand: hey
[17:04] <mup> Bug #1667385 opened: devmode flag disappears after disabling+re-enabling a snap <Snappy:New> <https://launchpad.net/bugs/1667385>
[17:05] <zyga> jdstrand: can you please have a look at https://github.com/snapcore/snapd/pull/2827
[17:05] <mup> PR snapd#2827: cmd: add helpers for mounting / unmounting <Created by zyga> <https://github.com/snapcore/snapd/pull/2827>
[17:06] <zyga> jdstrand: I think it is good to land now
[17:06] <zyga> jdstrand: and I waaaaant it to land :)
[17:08] <zyga> jdstrand: the new patches are: https://github.com/snapcore/snapd/pull/2827/commits/6573f698a22db592006cf6af7d5284cf66a891e4 and https://github.com/snapcore/snapd/pull/2827/commits/9e24bee9f0cb94aef73c23667fd80364db66d3bb
[17:08] <mup> PR snapd#2827: cmd: add helpers for mounting / unmounting <Created by zyga> <https://github.com/snapcore/snapd/pull/2827>
[17:14] <mup> PR snapd#2872 closed: tests: do not use core for "All snaps up to date" check <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2872>
[17:14] <slunatecqo> Hi - question about ubuntu Core. I have a working machine in KVM, and when I want to ssh into it, it asks key passphrase. When I enter it correctly, it asks users password, which I don't know... any ideas?
[17:14] <kyrofa> slunatecqo, you uploaded your SSH public key to your SSO account, etc.?
[17:15] <slunatecqo> kyrofa: yes - the key is set up - after I enter its passphrase it asks for user password
[17:15] <nacc> slunatecqo: is the 'it' ssh? ssh -vvv may help see if it rejected your key, if so
[17:15] <kyrofa> slunatecqo, which implies to me the key you're using doesn't match up to a key authorized on the device
[17:16] <kyrofa> slunatecqo, indeed, try nacc's advice
[17:17] <jdstrand> zyga: I'll add it to the list. not sure it will be today, but will be able to first thing next week (off tomorrow)
[17:17] <slunatecqo> nacc: yeah... thats it.. the passphrase should be blank, but for some reason ssh says "debug2: no passphrase given, try next key"
[17:21] <zyga> jdstrand: I'm off next week
[17:21] <zyga> jdstrand: if you can I'd appreciate it, the diff is tiny
[17:21]  * zyga back to other things
[17:21] <zyga> slunatecqo: it means that it tried your ssh key (which was encrypted) but they it tried password auth
[17:22] <zyga> slunatecqo: the key associated with your account is not the key you've used
[17:22] <slunatecqo> zyga: yeah. I understand.... thanks
[17:29] <mup> PR snapd#2873 closed: tests: several improvements to the nested suite <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2873>
[17:30] <mup> PR snapd#2926 opened: cmd/snap-update-ns: move test data and helpers to new module <Created by zyga> <https://github.com/snapcore/snapd/pull/2926>
[17:31] <slunatecqo> Ok - one more. I just installed docker in fresh UbuntuCore. running any container gives me "container command XXXX could not be invoked"
[17:32] <zyga> slunatecqo: not sure about that, what is your environment?
[17:33] <slunatecqo> environment?
[17:33] <slunatecqo> I am running ubuntu-core-16-amd64.img using qemu-KVM
[17:33] <zyga> mmm
[17:33] <zyga> slunatecqo: can you please report that
[17:33] <zyga> slunatecqo: I'm sure people will want to look at it and fix it
[17:35] <slunatecqo> where? launchpad bugs?
[17:35] <zyga> slunatecqo: yes please, on launchpad.net/snappy
[17:41] <mup> Bug #1667408 opened: docker container command XXXX could not be invoked <docker> <Snappy:New> <https://launchpad.net/bugs/1667408>
[17:41] <kyrofa> slunatecqo, lool might have some thoughts if he's around
[17:42] <slunatecqo> kyrofa: is it ok to ask directly him? on some IRCs it is not...
[17:42] <lool> slunatecqo: which docker is this?
[17:42] <lool> slunatecqo: 1.13?
[17:42] <kyrofa> slunatecqo, I sorta did ;)
[17:42] <lool> slunatecqo: 1.13 is known broken unfortunately
[17:42] <slunatecqo> lool: Docker version 1.11.2, build v1.11.2-snap-38fd0d3
[17:43] <kyrofa> slunatecqo, not the best to directly ping people for generic questions, but in this case I know lool is The Docker Guy
[17:43] <slunatecqo> kyrofa: thank you :-)
[17:43] <lool> slunatecqo: are you on classic or on core?
[17:44] <slunatecqo> KVM image from here https://developer.ubuntu.com/core/get-started
[17:44] <slunatecqo> lool: so I guess core :D
[17:44] <lool> Yes
[17:46] <lool> slunatecqo: how are you installing and running?
[17:47] <lool> slunatecqo: my whole knowledge is recap-ed in https://docs.google.com/document/d/1JHa6tkuR9PtpnAVVmAJIAKuyKBy8E9ZkvG5Wbc6HZSY/edit#heading=h.j2sflymhgsj8
[17:47] <lool> which might be slightly out of date
[17:47] <lool> it's also possible that some regressions occurred
[17:47] <slunatecqo> https://bugs.launchpad.net/snappy/+bug/1667408 here is the bug reported
[17:47] <mup> Bug #1667408: docker container command XXXX could not be invoked <docker> <Snappy:New> <https://launchpad.net/bugs/1667408>
[17:47] <slunatecqo> basically just snap install docker
[17:48] <slunatecqo> ah - that will be it... the image is armhf?
[17:49] <slunatecqo> no... doesnt solve the problem..
[17:53] <slunatecqo> lool: have to leave now for few minutes. Could you write ideas to the bug on launchpad?
[18:09] <lool> slunatecqo: I suggest you open a bug against github.com/docker/docker and link it back on Launchpad
[18:09] <lool> slunatecqo: docker is directly publishing the snap
[18:10] <lool> slunatecqo: I wont have time to debug this this week and am travelling the next 2.5 weeks
[18:10] <pmcgowan> is there any way to determine when the next refresh check is scheduled?
[18:11] <lool> slunatecqo: I dont have a clean Core environment handy, but I did give this a try on classic and it worked there: http://paste.ubuntu.com/24054379/
[18:11] <lool> slunatecqo: so it's probably specific to core
[18:31] <mup> PR snapd#2927 opened: cmd: add .indent.pro file to the tree <Created by zyga> <https://github.com/snapcore/snapd/pull/2927>
[18:56] <zyga> pmcgowan: hey, there are some controls for that coming
[18:56] <zyga> pmcgowan: it's mostly implemented
[18:56] <zyga> pmcgowan: but not released yet
[18:56] <mup> Bug #1606674 changed: Unable to drive Adruino over USB from Arduino IDE snap <isv> <snapd-interface> <snapd:Triaged by zyga> <https://launchpad.net/bugs/1606674>
[18:56] <zyga> pmcgowan: you can set schedule in a very detailed way
[18:56] <pmcgowan> zyga,ok, it seems one of my systems runnign xenial isnt doing refreshes
[18:57] <pmcgowan> zyga, wondering how to debug
[18:57] <zyga> pmcgowan: what's the version of snapd?
[18:57] <pmcgowan> its got core 16.04.1
[18:57] <pmcgowan> 2.22.3 snapd
[18:57] <kyrofa> jdstrand, raw-usb doesn't seem to cover /dev/ttyUSB*, right?
[18:57] <zyga> pmcgowan: what does "snap info core" say?
[18:58] <pmcgowan> zyga, http://pastebin.ubuntu.com/24054592/
[18:58] <pmcgowan> refresh --list shows 8 snaps
[18:59] <zyga> wow
[18:59] <zyga> don't refresh yet please
[18:59] <zyga> one sec
[19:00] <zyga> pmcgowan: can you pastebin snap changes
[19:00] <pmcgowan> zyga, http://pastebin.ubuntu.com/24054598/
[19:00] <pmcgowan> not very interesting
[19:01] <jdstrand> kyrofa: correct. it allows access to /dev/bus/usb/*, not /dev/.... /dev/ttyUSB* is covered by the serial-port interface
[19:01] <zyga> pmcgowan: can you run journalctl -ux snapd
[19:01] <zyga> anything broken?
[19:01] <kyrofa> jdstrand, which again is gadget only
[19:01] <jdstrand> today, yes
[19:01] <kyrofa> jdstrand, talking about bug #1606674 here
[19:01] <mup> Bug #1606674: Unable to drive Adruino over USB from Arduino IDE snap <isv> <snapd-interface> <snapd:Triaged by zyga> <https://launchpad.net/bugs/1606674>
[19:02] <zyga> kyrofa: we need hotplug
[19:02] <kyrofa> zyga, yes. But I don't see that on the horizon
[19:02] <pmcgowan> zyga, http://paste.ubuntu.com/24054608/
[19:02] <kyrofa> And this has been an issue from the beginning
[19:03] <pmcgowan> zyga, assume you meant -u
[19:03] <kyrofa> zyga, we need something to unblock
[19:03] <jdstrand> kyrofa: I think it is on the horizon. it was discussed as important in The Hague. best to ask JamieBennett on the priority
[19:04] <zyga> pmcgowan: -ux is for failures but this is good
[19:04] <pmcgowan> zyga, ah, yes no matches
[19:04] <jdstrand> kyrofa: niemeyer said in The Hague that he would design hotplug and then present it for review. I don't know where that fell in the prioritization discussions after
[19:04] <zyga> pmcgowan: systemctl status snapd.refresh.timer
[19:05] <zyga> kyrofa: I think we need to work on hotplug and not to stopgaps
[19:05] <jdstrand> kyrofa: also, this should work in devmode. https://bugs.launchpad.net/snapd/+bug/1606674/comments/2
[19:05] <mup> Bug #1606674: Unable to drive Adruino over USB from Arduino IDE snap <isv> <snapd-interface> <snapd:Triaged by zyga> <https://launchpad.net/bugs/1606674>
[19:05] <pmcgowan> zyga, I did have it off at some point but its been on a wile now http://pastebin.ubuntu.com/24054611/
[19:05] <zyga> pmcgowan: how about snap list
[19:06] <jdstrand> fwiw, I agree with zyga on focusing on hotplug instead of stop gaps cause that will unblock a lot
[19:06] <kyrofa> jdstrand, devmode is not the answer when you're done developing and want to ship something
[19:06] <pmcgowan> zyga, http://paste.ubuntu.com/24054612/
[19:06] <jdstrand> kyrofa: of course, but the bug talks about it not working in devmode
[19:06] <zyga> pmcgowan: ok, can you, just for debugging, save /var/lib/snapd/state.json somewhere
[19:06] <zyga> pmcgowan: and then sudo snap refresh
[19:07] <pmcgowan> sure
[19:07] <zyga> and hold your fingers croessed
[19:07] <zyga> thanks!
[19:07] <zyga> maybe you will uncover why this happens
[19:07] <pmcgowan> zyga, I think that works, but then it doesnt update again for days
[19:07] <kyrofa> jdstrand, indeed, though it was clarified in the comments that was a normal permission issue
[19:07] <jdstrand> kyrofa: I suggest escalating this via the snappy team's stakeholder process
[19:07] <zyga> kyrofa: yes, +1 on that process
[19:07] <jdstrand> kyrofa: yes, that is the comment I gave the url to :)
[19:07] <zyga> kyrofa: it's rally the best thing we can do
[19:08] <jdstrand> kyrofa: JamieBennett holds a weekly stakeholder meeting iirc. he can help you participate in the process
[19:08] <pmcgowan> zyga, yeah its getting everything
[19:09] <zyga> pmcgowan: including core?
[19:09] <pmcgowan> yes
[19:09] <zyga> (let's see what we get)
[19:09] <pmcgowan> btw why did the versioning go from 16.04.1 to 16-2
[19:09] <zyga> pmcgowan: $reasons, we want something we cannot yet get so this is a stub
[19:10] <zyga> pmcgowan: we'll get 16-$snapd_version
[19:10] <zyga> pmcgowan: when snapcraft can
[19:10] <pmcgowan> ah
[19:17] <niemeyer> pmcgowan: Heya
[19:18] <pmcgowan> niemeyer, hey
[19:18] <niemeyer> pmcgowan: So what happens when you type "snap refresh core"?
[19:18] <niemeyer> Sorry if I missed that in the backlog
[19:18] <zyga> niemeyer: we have a copy of the old state
[19:18] <zyga> niemeyer: for forensics
[19:18] <pmcgowan> niemeyer, snap refresh got everything (except devmodes)
[19:18] <zyga> pmcgowan: I'd appreciate if you send that to us in private
[19:19] <pmcgowan> niemeyer, it always manually works
[19:19] <pmcgowan> zyga, can email to you
[19:19] <niemeyer> pmcgowan: What happens when you run, more specifically?
[19:19] <niemeyer> pmcgowan: "snap refresh core"
[19:19] <pmcgowan> niemeyer, it already refreshed but quite sure it would work
[19:19] <zyga> pmcgowan: please
[19:20] <zyga> do you think it is worth aborting and checking just core
[19:20] <niemeyer> pmcgowan: So manually it works, but it wasn't running automatically?
[19:20] <pmcgowan> correct
[19:20] <zyga> niemeyer: the timer was set and enabled
[19:21] <zyga> niemeyer: but last ran ... 21 days ago
[19:21] <pmcgowan> at some  point I had disabled the timer
[19:21] <pmcgowan> but it was on since a week I think
[19:21] <zyga> pmcgowan: but it was meant to run in two hours based on your pastebin above
[19:21] <zyga> is it possible that the timer no longer works for whatever reason
[19:21] <zyga> (e.g. runs as real root)
[19:23] <niemeyer> The systemd timer is no longer respected..
[19:23] <zyga> ?!
[19:23] <niemeyer> It's internal now..
[19:23] <zyga> in 2.21.3?
[19:23] <zyga> hmmm
[19:23] <niemeyer> Or am I mixing that with code that is yet to come?
[19:23]  * niemeyer looks
[19:23] <zyga> niemeyer: I think we live on the ege, let's see what was on 2.21.3
[19:24] <pmcgowan> zyga, I had 2.22.3 fwiw
[19:25] <zyga> right, sorry
[19:25] <mup> PR snapd#2920 closed: wrappers/services: RemainAfterExit=yes for oneshot daemons w/ stop cmds <Created by ssweeny> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2920>
[19:25] <zyga> 22 is the only version with further point releases
[19:27] <niemeyer> zyga: Nevermind.. the logic I'm talking about hasn't landed yet
[19:27] <niemeyer> pmcgowan: What do you have on "snap changes" by now?
[19:28] <zyga> niemeyer: omg
[19:28] <zyga> niemeyer: it's not doing refreshes in that version
[19:28] <zyga> just the timer can do that
[19:28] <niemeyer> pmcgowan: Also, please: "systemctl cat snapd.refresh.service" and "systemctl cat snapd.refresh.timer"
[19:29] <niemeyer> zyga: Not sure I understand what you mean
[19:29] <niemeyer> zyga: Yes, just the timer can do that, and it's the timer that does that.. ?
[19:29] <pmcgowan> niemeyer, http://paste.ubuntu.com/24054719/
[19:30] <zyga> niemeyer: sorry, I misread your earlier statement, I thought we managed to release a version that doesn't refresh internally and ignores the timer
[19:30] <zyga> pmcgowan: snap version
[19:30] <zyga> pmcgowan: is it 2.22.6?
[19:30] <niemeyer> Nope
[19:30] <niemeyer> We actually never released a version that ignores the timer
[19:31] <pmcgowan> zyga, yes
[19:31] <niemeyer> This is up for review and pending high-level conversations
[19:31] <pmcgowan> niemeyer, zyga lets see if it works now, I don't want to waste your time
[19:32] <pmcgowan> zyga, niemeyer earlier today I saw that the system time was storing local to the rtc, and I suspected that messed up the timer
[19:32] <pmcgowan> since the local time was set after snapd ran
[19:32] <pmcgowan> but I fixed that, so maybe I then just didnt wait long enough
[19:32] <zyga> pmcgowan: what's the delta between local and utc?
[19:32] <pmcgowan> 5 hours
[19:32] <zyga> ha
[19:32] <niemeyer> pmcgowan: journalctl -u snapd.refresh.service
[19:32] <zyga> so you only had 1/6 of chance to update
[19:33] <pmcgowan> niemeyer, no entries
[19:33] <zyga> or am I reading it wrong?
[19:33] <niemeyer> pmcgowan: That means the timer has never ever run
[19:34] <pmcgowan> hmm
[19:34] <niemeyer> Well, sorry, that's actually not true.. your system might not be persisting the logs
[19:35] <pmcgowan> niemeyer, maybe I somehow have the service disabled
[19:35] <niemeyer> pmcgowan: systemctl status snapd.refresh.timer?
[19:35] <zyga> niemeyer: default journal is not going across boots I think
[19:36] <niemeyer> Yeah, it requires a mkdir
[19:36] <zyga> right
[19:36] <pmcgowan> http://pastebin.ubuntu.com/24054758/
[19:37] <pmcgowan> is the service just not started?
[19:37] <zyga> pmcgowan: the service is just a oneshot AFAIR
[19:37] <zyga> pmcgowan: runs snap refresh
[19:38] <pmcgowan> well maybe it was the time thing, in which case it should start working
[19:38] <zyga> niemeyer: set your system to local time (like windows)
[19:38] <zyga> niemeyer: and see what you get
[19:39] <zyga> niemeyer: just let it sit for 24 hours
[19:39] <zyga> niemeyer: I think you're almost as far from UTC, right?
[19:39] <Pharaoh_Atem> niemeyer is on my timezone, I think
[19:39] <Pharaoh_Atem> UTC-5?
[19:39] <niemeyer> pmcgowan: That log says the timer was started 3h ago
[19:39] <zyga> timedatectl set-local-time true (AFAIR)
[19:40] <pmcgowan> niemeyer, yes
[19:40] <zyga> hmmm
[19:40] <pmcgowan> although  it spits out two lines of adding hh:mm:ss
[19:40] <niemeyer> pmcgowan: And there are logs
[19:40] <niemeyer> pmcgowan: Can you please try this again:
[19:40] <niemeyer> pmcgowan: journalctl -u snapd.refresh.timer
[19:41] <zyga> niemeyer: recall that in http://pastebin.ubuntu.com/24054592/ we saw the core snap was last refreshed on 2017-02-02 13:25:08 -0500 EST
[19:41] <pmcgowan> http://pastebin.ubuntu.com/24054781/
[19:41] <niemeyer> zyga: That's irrelevant.. we don't fiddle with the systemctl timer I don't think
[19:42] <zyga> niemeyer: we don't fiddle with it no, but if it ran 3 hours ago then... what happened/
[19:42] <pmcgowan> why does it say adding 5h then adding 4h
[19:42] <niemeyer> pmcgowan: So how come it had no entries and now it does?
[19:42] <zyga> pmcgowan: that's a systemd randomization thing
[19:42] <niemeyer> pmcgowan: Did you run "systemctl restart snapd.refresh.timer" by any chance?
[19:42] <zyga> pmcgowan: did you reboot in the last three hours?
[19:42] <pmcgowan> niemeyer, the service had no entries
[19:43] <niemeyer> @pmcgowan Ah, sorry, gotcha
[19:43] <nothal> niemeyer: No such command!
[19:43] <niemeyer> pmcgowan: Did you reboot your system ~3h ago?
[19:44] <pmcgowan> zyga, up 3:13
[19:44] <pmcgowan> yes
[19:44] <zyga> so it could have ran earlier
[19:44] <zyga> but we don't have logs
[19:44] <zyga> but I think syslog is preserved
[19:44] <zyga> maybe there is a trace in syslog beore the boot
[19:44] <zyga> can you check at around that time?
[19:45] <niemeyer> pmcgowan: Okay.. my theory so far is that the timre was indeed not enabled, but it's hard to validate it
[19:45] <niemeyer> pmcgowan: Can you please enable the logs persistently by doing "mkdir /var/log/journal"
[19:45] <pmcgowan> niemeyer, sure
[19:46] <pmcgowan> zyga, what should I look for?
[19:46] <niemeyer> pmcgowan: and systemctl restart systemd-journald
[19:46] <zyga> pmcgowan: for the service name maybe
[19:46] <zyga> pmcgowan: not sure how it is logged
[19:46] <zyga> pmcgowan: ideally for a trace that it ran and maybe for the output
[19:47] <niemeyer> Uh oh, wait
[19:48] <niemeyer> pmcgowan: grep 'snap.*refresh' /var/log/syslog | pastebinit
[19:48] <pmcgowan> zyga, there is a failure in there http://pastebin.ubuntu.com/24054813/
[19:49] <pmcgowan> niemeyer, http://paste.ubuntu.com/24054819/
[19:49] <zyga> hmmm
[19:49] <zyga> niemeyer: theory: related to exit code of refresh
[19:49] <zyga> niemeyer: maybe we refresh once, nothing to do, we return an error and systemd skips running this?
[19:50] <zyga> DNS error
[19:50] <zyga> hmmm
[19:51] <niemeyer> zyga: I was wrong.. the snapd I have from edge is ignoring refreshes from the timer.. I'm about to figure when that started
[19:51] <niemeyer> Commit was on Feb 1st
[19:52] <zyga> niemeyer: 2.22.3 was on Date:   Fri Feb 17 21:04:27 2017 +0100
[19:52] <zyga> (tagged)
[19:52] <EEight_> hey, i am trying to upload a snap to myapps.dev via jenkins, is there a way to use snapcraft login --username xxx --password xxx?
[19:53] <niemeyer> zyga: Nope, wasn't disable on 2.22.3
[19:53] <zyga> EEight_: no but you can copy the auth data
[19:53] <niemeyer> wasn't disabled
[19:53] <zyga> niemeyer: look up in history
[19:54] <EEight_> zyga: can you give me more information (auth data)?
[19:54] <zyga> niemeyer: mvo probably commited it on Feb 1st but it landed later
[19:54] <zyga> EEight_: look at .snap/auth.json
[19:54] <niemeyer> zyga: Was never released
[19:55] <niemeyer> zyga: It's in master only
[19:55] <niemeyer> Thus edge
[19:55] <niemeyer> pmcgowan: Were you on edge by any chance?
[19:55] <zyga> I see
[19:55] <zyga> niemeyer: it was tracking stable
[19:56] <zyga> niemeyer: there's a pastebin at the start of the converstation, let me pull it up
[19:56] <zyga> http://pastebin.ubuntu.com/24054592/
[19:56] <EEight_> zyga, where to find this file (no .snap in my home)
[19:57] <zyga> EEight_: snap login
[19:57] <zyga> EEight_: the it will be there
[19:57] <zyga> (sudo snap login)
[19:58] <EEight_> zyga, excellent got it, then how to pass that to snapcraft login for uploading my snap on myapp.devs...
[19:59] <zyga> kyrofa: ^^^
[19:59] <niemeyer> pmcgowan: That syslog is a bit suspect
[19:59] <niemeyer> pmcgowan: How come the time goes back and forth and back and forth
[19:59] <zyga> niemeyer: wow
[19:59] <zyga> niemeyer: maybe ntp is not aware of local time
[20:00] <niemeyer> A crazy clock would be a great reason for timers not to work :)
[20:00] <zyga> niemeyer: and kicls in
[20:00] <zyga> niemeyer: and then ... some other component does the same
[20:00] <pmcgowan> niemeyer, thats the local time screwup
[20:00] <zyga> pmcgowan: is this a VM?
[20:00] <pmcgowan> no
[20:00] <niemeyer> pmcgowan: Ok, but it's not just a screw up
[20:00] <zyga> hmmm
[20:00] <niemeyer> pmcgowan: It's going back and forth multiple times
[20:00] <pmcgowan> I think once each reboot
[20:00] <pmcgowan> or do you see otherwise
[20:00] <zyga> niemeyer: now that you menitoned it that clock is everything but monotonic
[20:01] <niemeyer> pmcgowan: I don't have reboot information there.. I just see that on Feb 23 alone it went 10, 15, 10, 16, 11, ...
[20:01] <pmcgowan> what I thought it was doing was booting to utc, then reseting to local time one the network was checked
[20:02] <pmcgowan> niemeyer, thats each boot, and the last boot I had local turned off
[20:02] <pmcgowan> thinking that was screwing with the refresh timer
[20:02] <niemeyer> pmcgowan: OKay, that may well be the case.. can you dig into an older syslog file with that same grep line
[20:03] <zyga> pmcgowan local time is stored in the hardware clock
[20:03] <zyga> pmcgowan: tha's what the systemd knob controls AFAIR (for compat with windows)
[20:03] <niemeyer> pmcgowan: syslog.1 or 2.gz
[20:03] <zyga> pmcgowan: do you dual boot?
[20:03] <pmcgowan> niemeyer, sure which grep again?
[20:03] <niemeyer> pmcgowan: Well, not really.. the hardware clock stores *a* time.. it's the O.S. that gives it meaning, and that's configurable
[20:04] <niemeyer> Sorry, that was for zyga
[20:04] <niemeyer> pmcgowan: Let me copy, just a sec
[20:04] <niemeyer> pmcgowan: grep 'snap.*refresh' /var/log/syslog.1 | pastebinit
[20:04] <zyga> niemeyer: yes, that's correct
[20:05] <zyga> niemeyer: I meant that the knob on systemd instructs it to store the local time into the clock
[20:05] <zyga> niemeyer: vs UTC as is done by default
[20:05] <kyrofa> EEight_, I'm afraid zyga is incorrect
[20:05] <kyrofa> EEight_, snapcraft login isn't the same as snap login
[20:06] <kyrofa> EEight_, but it's similar. Running `snapcraft login` saves a macaroon in .config/snapcraft/snapcraft.cfg
[20:06] <zyga> kyrofa: ah, too bad
[20:06] <pmcgowan> niemeyer, no hits
[20:06] <pmcgowan> on .1 or .2
[20:06] <kyrofa> EEight_, you can encrypt that file and use it in CI, though I recommend you create a store account for your bot
[20:06] <kyrofa> (rather than giving it your macaroon)
[20:07] <niemeyer> pmcgowan: Any hits on any of the other files?
[20:08] <kyrofa> EEight_, note that snapcraft has an `enable-ci` command
[20:08] <EEight_> kyrofa, snapcraft login, not possible to pass the username and password directly on the command line?
[20:08] <kyrofa> Which does this for you
[20:08] <kyrofa> But it only supports travis at the moment
[20:08] <kyrofa> You might investigate adding support for jenkins
[20:09] <pmcgowan> niemeyer, http://paste.ubuntu.com/24054941/
[20:09] <kyrofa> EEight_, I'm afraid not
[20:10] <EEight_> kyrofa, ok, so the solution is to encrypt the macaroon and pass that to snapcraft?
[20:11] <kyrofa> EEight_, in CI, you'll need to un-encrypt that file and place it in ~/.config/snapcraft/snapcraft.cfg
[20:11] <kyrofa> EEight_, at that point, snapcraft will be "logged in" if you will
[20:12] <kyrofa> EEight_, note that encryption is not required here, but I assume you'll be storing it in a source tree somewhere, in which case note that macaroon is essentially a password
[20:13] <kyrofa> EEight_, i.e. don't share it in the clear
[20:14] <ahasenack> hi guys, do you know if /usr/bin/lsb_release was removed from the core snap?
[20:16] <zyga> ahasenack: not sure but I'd recommend to use /etc/os-release instead
[20:16] <ahasenack> zyga: the tool is a convenient way to avoid having to parse the file (but parse the tool's output)
[20:17] <alex-abreu> kyrofa, ping
[20:18] <zyga> ahasenack: the file is easier to parse and you don't have to run a separate process
[20:18] <alex-abreu> kyrofa, quick question, where do you see the configure hooks logs?
[20:18] <ahasenack> zyga: still, if it was removed in an update, sounds like an important change
[20:18] <pmcgowan> zyga, niemeyer it just did a refresh check
[20:21] <kyrofa> alex-abreu, you mean stdout/stderr? They belong to the task as I recall, which means you don't see them unless the hook fails
[20:22] <kyrofa> alex-abreu, note that you can run the hook directly with `snap run --hook`
[20:22] <alex-abreu> kyrofa, yes
[20:22] <kyrofa> If you're just talking about developing
[20:25] <alex-abreu> kyrofa, the hook then runs in the same context as the one defined when running as part of snap-confine?
[20:25] <niemeyer> pmcgowan: Nice. I really don't know what to make from it.. the complete silence on the logs for several days hints at a manually disabled timer, which I think you said had happened, right?
[20:25] <kyrofa> alex-abreu, indeed
[20:26] <niemeyer> pmcgowan: That plus the crazy clock makes me feel like the environment is a bit unhealthy
[20:26] <niemeyer> pmcgowan: In either case, we're changing that timer mechanism and making it internal
[20:26] <niemeyer> pmcgowan: So one way or another, the problem will be fixed
[20:26] <pmcgowan> niemeyer, I can except it was my system setup
[20:26] <pmcgowan> I do suspect the rtc clock setting, I could try later to put it back and see what happens
[20:27] <niemeyer> pmcgowan: I'll remember to review the timer logic and consider what would happen in such skews
[20:27] <niemeyer> pmcgowan: The new logic, that is
[20:27] <pmcgowan> great thanks for the help
[20:27] <alex-abreu> kyrofa, mmmh ... a hook has access to SNAP_COMMON right?
[20:27] <kyrofa> alex-abreu, it should, yes
[20:28] <kyrofa> alex-abreu, though note that things in there are typically owned by root if you're running into permissions issues and aren't running `snap run` via sudo
[20:32] <zyga> ahasenack: we don't guarantee it will be present there
[20:32] <ahasenack> zyga: ok, so after some debugging... We have a snap that calls /usr/bin/lsb_release
[20:32] <ahasenack> zyga: on existing systems that upgraded to the latest core snap, our snap keeps working somehow
[20:33] <ahasenack> zyga: but if these are rebooted, then our snap doesn't find /usr/bin/lsb_release anymore
[20:33] <zyga> ahasenack: let me look
[20:33] <ahasenack> zyga: https://bugs.launchpad.net/snappy/+bug/1619420 is about the lsb_release removal
[20:33] <mup> Bug #1619420: snappy removal of dpkg-query breaks lsb_release --all <cloud-init:New> <Snappy:Fix Committed by ogra> <livecd-rootfs (Ubuntu):Fix Committed by ogra> <https://launchpad.net/bugs/1619420>
[20:33] <zyga> ahasenack: on core systems?
[20:33] <ahasenack> it was indeed removed
[20:33] <ahasenack> zyga: no, ubuntu
[20:33] <zyga> ahasenack: maybe it was removed on ubuntu
[20:33] <ahasenack> zyga: /usr/bin/lsb_release was removed from the core snap
[20:33] <zyga> ahasenack: yeah, I just checked
[20:33] <ahasenack> see comment #11 and #14 in that bug
[20:34] <ahasenack> zyga: ok, that broke our snap, we will fix it, but the question I have now
[20:34] <ahasenack> zyga: is why upgraded systems kept working
[20:34] <ahasenack> are they seeing the old core snap?
[20:34] <zyga> ahasenack: no idea
[20:34] <zyga> ahasenack: maybe
[20:34] <zyga> ahasenack: snap info core
[20:34] <zyga> ahasenack: if you have such a system around that would be good
[20:35] <ahasenack> we just rebooted it
[20:35] <ahasenack> I think I have a snap list --all
[20:36] <mup> PR snapd#2924 closed: interfaces: specs for apparmor, seccomp, udev <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2924>
[20:37] <zyga> ahasenack: I'll gladly help you figure out what's going on with the core snap but I think the fate of lsb_releaes is sealed
[20:37] <zyga> it's a dead thing
[20:37] <ahasenack> it's ok
[20:38] <ahasenack> what I wanted to understand now is the dynamics of core updates, what happens to existing snaps when the core one is updated
[20:38] <ahasenack> what do they see
[20:38] <zyga> ahasenack: nothing
[20:38] <ahasenack> it *looks* like they saw the old core filesystem, or perhaps a mix
[20:38] <zyga> ahasenack: they see the old core till the machine reboots
[20:38] <ahasenack> or maybe it was just a case of a dangling fd
[20:38] <ahasenack> ah
[20:38] <zyga> ahasenack: unless the app is not running
[20:39] <zyga> ahasenack: we persist the mount namespace across app runs
[20:39] <ahasenack> zyga: if the app snap is restarted, it still sees the old core?
[20:39] <zyga> ahasenack: as long as it was not removed
[20:39] <zyga> ahasenack: yes
[20:39] <zyga> ahasenack: we keep three revisions of core around
[20:39] <ahasenack> zyga: ok, and if the app snap is updated?
[20:39] <ahasenack> it also keeps seeing the old core?
[20:41] <zyga> ahasenack: yes
[20:41] <zyga> ahasenack: that's a bug I'm fixing for the past month
[20:41] <zyga> ahasenack: or more now
[20:41] <zyga> ahasenack: that won't change soon actually but we plan to change the mount namespace the app exists in
[20:41] <ahasenack> zyga: ok, is there a case where the app snap would see the new core, outside of a reboot?
[20:41] <ahasenack> it would have to be removed and reinstalled?
[20:42] <zyga> ahasenack: technically when the app changes it will see its new self on top of the core it ran with when you stated it for the first time since last boot
[20:42] <zyga> ahasenack: not at present
[20:42] <ahasenack> zyga: what if core got updated, say, 5x?
[20:42] <ahasenack> I have core v1, app snap v1
[20:43] <ahasenack> then core v2 removed lsb_release, app still sees it because core v1 is still there
[20:43] <ahasenack> and so on, but you said we only keep 3 revisions around
[20:43] <zyga> ahasenack: yes
[20:44] <zyga> ahasenack: once the rootfs is removed strange things will happen
[20:44] <ahasenack> zyga: at some point I will have core v3, v4, v5 (v5 being current)
[20:44] <ahasenack> none with lsb_release (continuing on this example)
[20:44] <ahasenack> then my app snap would fail outside of the reboot scenario?
[20:44] <zyga> ahasenack: I'm working on snap-update-ns that goes into the snap's mount namespace and does updates
[20:44] <zyga> ahasenack: I'm not entirely sure but I suspect so
[20:45] <ahasenack> ok
[20:45] <ahasenack> that's fine, I'm just trying to gather the failure scenarios for our bug
[20:45] <ahasenack> where we are working on parsing /etc/os-release instead of relying on the presence of /usr/bin/lsb_release
[20:45] <zyga> ahasenack: which language are you using?
[20:45] <zyga> ahasenack: there are libraries for this for anything out there
[20:46] <ahasenack> go
[20:47] <ahasenack> we want to be sure we are on xenial
[20:47] <ahasenack> never thought lsb_release would be gone, because, well, lsb stands for linux standards base :)
[20:49] <zyga> ahasenack: lsb is as dead now as it was before
[20:50] <ahasenack> hehe :)
[20:58] <zyga> ahasenack: thank you
[20:58] <zyga> ahasenack: you made me realize we have a nasty bug
[20:58] <zyga> ahasenack: anyway
[20:59] <ahasenack> "good" :)
[20:59] <zyga> ahasenack: the core is okay, unless I can do what I think I did before when removal of the squashfs file made crazy things happen
[20:59] <zyga> maybe it was a kernel bug though
[20:59] <zyga> but what is buggy at present is that if your app was running
[20:59] <zyga> and you update
[20:59] <zyga> and even restart the app
[20:59] <zyga> it will see the old core snap
[20:59] <zyga> I'll fix that ASAP
[21:01] <zyga> https://bugs.launchpad.net/snapd/+bug/1667479
[21:01] <mup> Bug #1667479: mount namespace is not discarded when core snap changes revision <snapd:New for zyga> <https://launchpad.net/bugs/1667479>
[21:02] <zyga> jdstrand: FIY, small omission /o\
[21:05] <alex-abreu> kyrofa, we dont seem to run in a proper snap context when running snap run --hook ... my snapctl call fail
[21:05] <zyga> alex-abreu: yes, known issue
[21:06] <alex-abreu> zyga, ah do you have a bug # ?
[21:06] <zyga> alex-abreu: the context you get when your hook runs for real is special (kind of a transaction)
[21:06] <zyga> alex-abreu: no, pawel was handling that, I don't recall
[21:06] <zyga> alex-abreu: there's an unfinished branch that adds a generic context for all the run cases so that you can always use snapctl
[21:06] <zyga> alex-abreu: but still the run in a real (internal) run is special as we abort the transaction if the hook fails
[21:07] <zyga> alex-abreu: let me look if there's a bug for this
[21:07] <zyga> alex-abreu: I don't see one
[21:09] <alex-abreu> thank you
[21:10] <zyga> alex-abreu: please report it, I'll make sure pawel knows
[21:10] <zyga> alex-abreu: sorry for the inconvenience
[21:10] <alex-abreu> zyga, np, thank you for the heads up on that, ...
[21:18] <kyrofa> alex-abreu, ah, right, snapctl can't be called without snapd generating the hook context variable
[21:18] <kyrofa> alex-abreu, as zyga mentioned, pawel is working on making snapctl usable from apps as well, which will allow it to be used from snap run as well
[21:19] <alex-abreu> kyrofa, yes, ... is there still a plan to expand snapctl to have systemctl like caps for like the current snap owned daemons etc.?
[21:19] <kyrofa> alex-abreu, snapd generates a cryptographic token for each hook run that ties it to a specific snap (i.e. so you can run `snapctl get` without also supplying the snap name)
[21:20] <kyrofa> alex-abreu, that's also probably pawel's domain these days
[21:20] <alex-abreu> kyrofa, yes I saw that and tried to follow what snapd was doing around that
[21:20] <alex-abreu> ah so pawel is the person to bother then
[21:27] <zyga> kyrofa: pawel is a bit pulled around but I think he wants to go back there
[21:51] <stokachu> do i need to ask to have a track created?
[21:53] <stokachu> also how do i set my 2.1/stable as the default track users get when running snap install conjure-up --classic
[21:59] <kyrofa> stokachu, yes, I believe you need to ask
[22:00] <kyrofa> stokachu, who? I'm not quite sure
[22:30] <stokachu> kyrofa, cool thanks
[22:38] <mup> PR snapd#2927 closed: cmd: add .indent.pro file to the tree <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2927>
[22:38] <mup> PR snapcraft#1161 opened: channels: Add track support to commands <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1161>
[22:39] <ToyKeeper> Gah, I can't seem to get spread to respect my kill timeout.  It's defaulting to 15 minutes, which isn't long enough for this test to run, and ignoring my configured value.
[22:40] <ToyKeeper> I've got "kill-timeout: 60m" in tests/main/gccgo/task.yaml (in snapd), but it's having no effect.
[22:41] <kyrofa> zyga, any ideas on that? ^^
[22:42] <ToyKeeper> I probably just need to set it at a project level instead of task level, if I can find the right place for it.
[22:45] <mup> PR snapd#2880 closed: tests: empty init (systemd) failover test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2880>
[23:00] <mup> PR snapd#2928 opened: tests: 2 workers on 14.04 and core 64, drop fixme system <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2928>
[23:33] <mcphail> 'error: snap "whatever" requires classic or confinement override' is a rather ugly and uninformative error message