| === markusfluer1 is now known as markusfluer | ||
| === JanC is now known as Guest31516 | ||
| === JanC_ is now known as JanC | ||
| === chihchun_afk is now known as chihchun | ||
| 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> | 06:57 |
|---|---|---|
| mup | PR snapd#2922 opened: many: merge 2.22.6 back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/2922> | 07:03 |
| _prasen_ | https://github.com/mectors/sensortag | 07:36 |
| _prasen_ | hi | 07:36 |
| _prasen_ | while building this snapcraft filw | 07:36 |
| _prasen_ | i get a error of property does not match the schema | 07:37 |
| _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' | 07:39 |
| 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:21 |
| zyga | hi | 08:37 |
| zyga | _prasen_: probably outdated repo, snapcraft is changing over time | 08:37 |
| _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:44 |
| 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:47 |
| 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:48 |
| _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:49 |
| === chihchun is now known as chihchun_afk | ||
| zyga | _prasen_: good luck :) | 08:51 |
| 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 | 08:54 |
| === chihchun_afk is now known as chihchun | ||
| 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> | 09:29 |
| 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:45 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| mup | PR snapd#2847 closed: tests: enable docker test <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2847> | 10:57 |
| ppisati | uhm | 11:01 |
| ppisati | what am i doing wrong? | 11:01 |
| ppisati | https://travis-ci.org/snapcore/snapcraft/jobs/204522771 | 11:01 |
| 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:04 |
| 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:05 |
| 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:06 |
| ppisati | mvo: can i do it myself? so i won't bother anyone next time | 11:07 |
| 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:08 |
| === chihchun_afk is now known as chihchun | ||
| 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:15 |
| 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:18 |
| 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:21 |
| 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:27 |
| _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:45 |
| _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:46 |
| 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> | 11:58 |
| fgimenez | ogra_, ppisati hey :) for snapcraft-related issues about tests and CI elopio is the right person to ask | 12:06 |
| ogra_ | thanks | 12:06 |
| 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:13 |
| 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:32 |
| === chihchun is now known as chihchun_afk | ||
| jdstrand | niemeyer: ack | 12:38 |
| jdstrand | morphis: hey, is there a slot implementation of upower-observe? | 12:39 |
| zyga | jdstrand: o/ | 12:40 |
| jdstrand | hey zyga :) | 12:41 |
| mvo | ppisati: looks like your test is green now | 12:41 |
| morphis | jdstrand: yes, we added that recently | 12:44 |
| jdstrand | morphis: right. I mean, do you have a snap that slots upower-observe | 12:45 |
| morphis | yes we do | 12:45 |
| morphis | jdstrand: but not yet in stable | 12:46 |
| morphis | snap install --candidate upower | 12:46 |
| jdstrand | morphis: great, thanks! | 12:46 |
| morphis | jdstrand: any specific reason you're asking for or just for reference? | 12:47 |
| 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:49 |
| morphis | ah ok | 12:50 |
| 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:54 |
| morphis | jdstrand: thanks | 12:55 |
| zyga | jdstrand: did you see that error I reported for zesty yesterday? | 13:03 |
| 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:04 |
| zyga | jdstrand: I'll try the kernel that jj recommended | 13:05 |
| 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:27 |
| 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:28 |
| === chihchun_afk is now known as chihchun | ||
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| Son_Goku | ah, so it's in the vendor directory | 13:50 |
| 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:18 |
| mhall119 | I didn't do anything special, and php is installed via stage-packages | 14:19 |
| jdstrand | mhall119: what is the name of the snap? | 14:21 |
| mhall119 | laravel-mhall119 | 14:24 |
| 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:25 |
| jdstrand | rwx-wx-wt is unusual, but it doesn't hurt anything | 14:26 |
| mhall119 | jdstrand: requested | 14:27 |
| ppisati | fgimenez: can you help me with some snapcraft tests? | 14:44 |
| fgimenez | ppisati, i can try but probably better to ask elopio, i'm not actively working on them | 14:46 |
| ppisati | fgimenez: k | 14:47 |
| ppisati | elopio: ^ | 14:47 |
| mup | PR snapd#2924 opened: interfaces: specs for apparmor, seccomp, udev <Created by stolowski> <https://github.com/snapcore/snapd/pull/2924> | 14:53 |
| mup | PR snapd#2891 closed: interfaces/udev: added spec <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2891> | 14:54 |
| mup | PR snapd#2890 closed: interfaces/apparmor: add spec <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2890> | 14:55 |
| 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:00 |
| fgimenez | hey kyrofa :) i'm trying to do some tests on the nextcloud image, have a minute for some questions? | 15:01 |
| mhall119 | jdstrand: do you need a bug report for that unusual file permission? | 15:02 |
| 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:07 |
| === gaughen_ is now known as gaughen | ||
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| Son_Goku | sergiusens: hey | 15:46 |
| Son_Goku | have you made any progress on the repo refactor thing? | 15:46 |
| === mup_ is now known as mup | ||
| kyrofa | fgimenez, ah, sorry, responded to your internal ping first, heh | 15:54 |
| fgimenez | kyrofa, np! thanks :) | 15:54 |
| === mup_ is now known as mup | ||
| lool | ppisati: hey! | 16:00 |
| 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:01 |
| 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:04 |
| === mup_ is now known as mup | ||
| ppisati | lool: i thought ryan fixed that already | 16:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| lool | ppisati: thanks man | 16:14 |
| mup | PR snapcraft#1158 closed: packaging: snapcraft as a snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1158> | 16:23 |
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| 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:29 |
| mdye | bad slack habits :) | 16:30 |
| lool | mdye: Hey! | 16:31 |
| mdye | lool: ahoy! | 16:31 |
| ppisati | mdye: fb or mir? | 16:31 |
| 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:32 |
| 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:33 |
| 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:35 |
| 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:37 |
| mdye | ok, thx | 16:38 |
| === mup_ is now known as mup | ||
| 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:43 |
| === mup_ is now known as mup | ||
| mup | Bug #1667359 opened: After a reboot store was not accessible <Snappy:New> <https://launchpad.net/bugs/1667359> | 16:55 |
| 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:57 |
| zyga | jdstrand: hey | 16:59 |
| === mup_ is now known as mup | ||
| mup | Bug #1667385 opened: devmode flag disappears after disabling+re-enabling a snap <Snappy:New> <https://launchpad.net/bugs/1667385> | 17:04 |
| 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:05 |
| zyga | jdstrand: I think it is good to land now | 17:06 |
| zyga | jdstrand: and I waaaaant it to land :) | 17:06 |
| === mup_ is now known as mup | ||
| 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:08 |
| === mup_ is now known as mup | ||
| === mup_ is now known as mup | ||
| 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:14 |
| 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:15 |
| kyrofa | slunatecqo, indeed, try nacc's advice | 17:16 |
| 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:17 |
| 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:21 |
| zyga | slunatecqo: the key associated with your account is not the key you've used | 17:22 |
| slunatecqo | zyga: yeah. I understand.... thanks | 17:22 |
| === chihchun is now known as chihchun_afk | ||
| 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:29 |
| 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:30 |
| slunatecqo | Ok - one more. I just installed docker in fresh UbuntuCore. running any container gives me "container command XXXX could not be invoked" | 17:31 |
| zyga | slunatecqo: not sure about that, what is your environment? | 17:32 |
| 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:33 |
| slunatecqo | where? launchpad bugs? | 17:35 |
| zyga | slunatecqo: yes please, on launchpad.net/snappy | 17:35 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| lool | slunatecqo: how are you installing and running? | 17:46 |
| 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:47 |
| slunatecqo | ah - that will be it... the image is armhf? | 17:48 |
| slunatecqo | no... doesnt solve the problem.. | 17:49 |
| slunatecqo | lool: have to leave now for few minutes. Could you write ideas to the bug on launchpad? | 17:53 |
| 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:09 |
| 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:10 |
| 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:11 |
| mup | PR snapd#2927 opened: cmd: add .indent.pro file to the tree <Created by zyga> <https://github.com/snapcore/snapd/pull/2927> | 18:31 |
| 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:56 |
| 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:57 |
| pmcgowan | zyga, http://pastebin.ubuntu.com/24054592/ | 18:58 |
| pmcgowan | refresh --list shows 8 snaps | 18:58 |
| zyga | wow | 18:59 |
| zyga | don't refresh yet please | 18:59 |
| zyga | one sec | 18:59 |
| zyga | pmcgowan: can you pastebin snap changes | 19:00 |
| pmcgowan | zyga, http://pastebin.ubuntu.com/24054598/ | 19:00 |
| pmcgowan | not very interesting | 19:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| zyga | pmcgowan: we'll get 16-$snapd_version | 19:10 |
| zyga | pmcgowan: when snapcraft can | 19:10 |
| pmcgowan | ah | 19:10 |
| niemeyer | pmcgowan: Heya | 19:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:23 |
| pmcgowan | zyga, I had 2.22.3 fwiw | 19:24 |
| 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:25 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| pmcgowan | hmm | 19:34 |
| niemeyer | Well, sorry, that's actually not true.. your system might not be persisting the logs | 19:34 |
| 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:35 |
| niemeyer | Yeah, it requires a mkdir | 19:36 |
| zyga | right | 19:36 |
| pmcgowan | http://pastebin.ubuntu.com/24054758/ | 19:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| niemeyer | @pmcgowan Ah, sorry, gotcha | 19:43 |
| nothal | niemeyer: No such command! | 19:43 |
| niemeyer | pmcgowan: Did you reboot your system ~3h ago? | 19:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| === lamont` is now known as lamont | ||
| niemeyer | Uh oh, wait | 19:47 |
| 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:48 |
| 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:49 |
| zyga | DNS error | 19:50 |
| zyga | hmmm | 19:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| zyga | EEight_: snap login | 19:57 |
| zyga | EEight_: the it will be there | 19:57 |
| zyga | (sudo snap login) | 19:57 |
| EEight_ | zyga, excellent got it, then how to pass that to snapcraft login for uploading my snap on myapp.devs... | 19:58 |
| 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 | 19:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| === rumble is now known as grumble | ||
| niemeyer | pmcgowan: Any hits on any of the other files? | 20:07 |
| 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:08 |
| pmcgowan | niemeyer, http://paste.ubuntu.com/24054941/ | 20:09 |
| kyrofa | EEight_, I'm afraid not | 20:09 |
| EEight_ | kyrofa, ok, so the solution is to encrypt the macaroon and pass that to snapcraft? | 20:10 |
| 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:11 |
| 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:12 |
| kyrofa | EEight_, i.e. don't share it in the clear | 20:13 |
| ahasenack | hi guys, do you know if /usr/bin/lsb_release was removed from the core snap? | 20:14 |
| 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:16 |
| alex-abreu | kyrofa, ping | 20:17 |
| 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:18 |
| 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:21 |
| 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:22 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:32 |
| 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:33 |
| 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:34 |
| ahasenack | we just rebooted it | 20:35 |
| ahasenack | I think I have a snap list --all | 20:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| ahasenack | go | 20:46 |
| 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:47 |
| zyga | ahasenack: lsb is as dead now as it was before | 20:49 |
| ahasenack | hehe :) | 20:50 |
| zyga | ahasenack: thank you | 20:58 |
| zyga | ahasenack: you made me realize we have a nasty bug | 20:58 |
| zyga | ahasenack: anyway | 20:58 |
| 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 | 20:59 |
| 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:01 |
| zyga | jdstrand: FIY, small omission /o\ | 21:02 |
| 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:05 |
| 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:06 |
| zyga | alex-abreu: let me look if there's a bug for this | 21:07 |
| zyga | alex-abreu: I don't see one | 21:07 |
| alex-abreu | thank you | 21:09 |
| 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:10 |
| 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:18 |
| 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:19 |
| 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:20 |
| zyga | kyrofa: pawel is a bit pulled around but I think he wants to go back there | 21:27 |
| stokachu | do i need to ask to have a track created? | 21:51 |
| stokachu | also how do i set my 2.1/stable as the default track users get when running snap install conjure-up --classic | 21:53 |
| kyrofa | stokachu, yes, I believe you need to ask | 21:59 |
| kyrofa | stokachu, who? I'm not quite sure | 22:00 |
| stokachu | kyrofa, cool thanks | 22:30 |
| 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:38 |
| 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:39 |
| ToyKeeper | I've got "kill-timeout: 60m" in tests/main/gccgo/task.yaml (in snapd), but it's having no effect. | 22:40 |
| kyrofa | zyga, any ideas on that? ^^ | 22:41 |
| 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:42 |
| mup | PR snapd#2880 closed: tests: empty init (systemd) failover test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2880> | 22:45 |
| 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:00 |
| mcphail | 'error: snap "whatever" requires classic or confinement override' is a rather ugly and uninformative error message | 23:33 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!