[00:01] PR snapcraft#1052 closed: Make git pulls less error prone due to history changes [00:19] Bug #1645445 changed: Turtlebot needs /dev/kobuki [00:21] PR snapd#2806 opened: interfaces/io-ports-control: use /dev/port, not /dev/ports [00:22] Bug #1646559 changed: should periodically refresh ssh keys that were obtained from SSO/store for local users [00:40] Bug #1662723 opened: Removing a snap with `snap remove ` doesn't remove everything [01:22] Bug #1662723 changed: Removing a snap with `snap remove ` doesn't remove everything === markusfluer1 is now known as markusfluer === chihchun_afk is now known as chihchun [03:49] PR snapcraft#1116 opened: Changed "snappy try" to "snap try" [04:17] Bug #1634890 changed: File system not resized in some devices [06:04] PR snapcraft#1117 opened: [wip] build and push the API docs to github pages [06:27] Bug #1662772 opened: systemd[1]: Failed to start Set the hostname to the value stored on the writable partition [06:31] PR snapcraft#1075 closed: travis: allow to pass --channels parameter to generate proper config [06:31] PR snapcraft#1118 opened: Trigger beta tests on travis every day [06:40] PR snapcraft#1109 closed: meta: allow `post-stop-command` for an app entry in `apps` [08:10] Snaps don't install in lxd containers unless the squashfuse package is installed, but I can't find the relevant bug report to link. [08:14] Found it: Bug #1628289 (although it claims to be FIX COMMITTED in xenial, comments indicate otherwise) [08:14] Bug #1628289: snapd should depend on squashfuse (for use in containers)

[08:33] Hrm. Issues like bug 1652643 make a snappy life tedious at times. Bonus points for letting a non-tech-aficionado use LibreOffice on one of my machines. [08:33] Bug #1652643: LibreOffice Snap: unable to access documents in some nested direcotries [08:37] Bug #1612453 changed: `snap connect` requires me to type ubuntu-core [08:56] morning all [08:56] I have a question re auto-aliases and conflicts with other snaps [08:57] jdstand kindly setup auto-aliases for the openstackclients snap yesterday [08:58] however that had a slightly un-intended side effect that now the glance, nova etc snaps are not co-installable with the openstackclients snap, as it ships aliases for commands with the same name as those sanps [08:58] for example [08:58] error: cannot install "glance": snap "glance" command namespace conflicts with enabled alias "glance" for "openstackclients" [09:00] however the glance snap does not provide a 'glance' command :-) [09:05] jamespage: well it could at some point [09:05] because is its snap name [09:05] pedronis, I guess my question is what is the conflict resolution strategy for this type of thing? [09:06] if this is always enforced in this way, we should have policy that means one snap can't auto-aliase a command with the name of another snap right? [09:06] jamespage: yes, that was the idea [09:09] jamespage: I understand this is annoying, the issue here is that in theory any snap has the right to a command called like it [09:10] pedronis, I'm ok with that, I guess my challenge is how that and auto-aliases should be managed [09:11] ideas - when you install the glance snap on a system that already has openstackclients, we might un-alias a conflicting glance command/aliase, and let glance own it. [09:11] jamespage: but is annoying if server/client snap have pairs where we call server foo and client has a command foo [09:11] pedronis, yup that's this use-case [09:12] pedronis, I'll raise a bug so we can track this better [09:12] hello there [09:13] jamespage, unalias sounds bad [09:14] usually people on the openstack controller have both the glance-api that comes with the glance snap and the glance client utility [09:14] they need to work both at the same time [09:15] zioproto, oh I agree [09:15] zioproto, its common todo that [09:15] letme raise this bug [09:15] jamespage: the problem is that well known aliases are also for scripts so random unaliasing them is bad [09:15] paste here the bug link so I can subscribe to it [09:16] mmh, what I mean is more that we need predictable behavior [09:16] https://bugs.launchpad.net/snapd/+bug/1662815 [09:16] Bug #1662815: conflicts between auto-aliases and real snap names [09:16] pedronis, agreed [09:16] zioproto, ^^ [09:19] zyga: I got the point of "version" What if, for example, everyone upload their "version" of vim and actually they are almost the same just uploaded by different person and have different namespace [09:20] kw: nothing [09:20] kw: as long as they have different snap name this is all right [09:21] zyga: I see. interesting :) [09:23] kw: there were some ideas about how to let pepole get an official vim or a fork of vim from a given user (vim being just an example) but there was no agrement on what the semantics would be [09:23] kw: but it is possible we will re-visit this [09:27] zyga: I suppose that people would prefer a copy from author or official one which makes them comfortable [09:29] Bug #1662817 opened: some snaps stop working after revert the core snap === kw is now known as anta === anta is now known as kw [09:39] PR snapd#2806 closed: interfaces/io-ports-control: use /dev/port, not /dev/ports === ackkk is now known as ackk` === leftyfb_ is now known as leftyfb === DavidDuffey is now known as dduffey === chihchun_ is now known as chihchun === StoneTable is now known as aisrael === iahmad_ is now known as iahmad === ackk` is now known as ackk [10:02] PR snapd#2766 closed: tests: improve snap-env test [10:18] is there a plugin or other way to build and install a debian package from source? running debuild and dpkg -i would be enough.. [10:20] cos-, a rather ugly way is https://github.com/ogra1/packageproxy/blob/master/Makefile [10:20] from https://github.com/ogra1/packageproxy [10:20] (it works though) [10:21] https://github.com/ogra1/laidout is another one [10:22] (the latter only uses a binary, the former builds a deb from the upstream source) [10:25] ok, no clean way to do that :-( [10:26] dont judge by my hacks :) [10:27] this is all very old stuff, perhaps there is a cleaner way nowadays [10:28] i just tend to abuse makefiles as scripts for quick results [10:28] cos-: why do you need to rebuild the deb? can't you just suck it in? [10:28] yeah, then you would just put it in stage-packages [10:29] popey: if it exists only in a private git repo [10:41] why is some snap namespace reserved? e.g. i7z [10:54] Will we get to the point of being able to guarantee that a Xenial or later machine has the snapd package installed when it is provisioned? [10:54] I've got a problem with /snap/bin not being in the $PATH of processes spawned before the snapd package got installed (lxd containers in this case) [10:57] I don't know if I should file an lxd bug (because it provisioned a machine without snapd and handed it to Juju),or a Juju bug because it asked for the wrong thing, or an Ubuntu bug because /snap/bin should be on the $PATH in /etc/profile no matter what [11:00] Or if I should be handling it myself, and rebooting the machine after installing the snapd package to get the /etc/profile.d changes in effect everywhere [11:00] kw: so the upstream developer can 'claim' it. [11:00] or someone working with the upstream developer [11:17] PR snapd#2805 closed: snap: improve message after `snap refresh pkg1 pkg2` [11:18] PR snapd#2807 opened: snap: add new `snap switch` command [11:26] ogra_, ping === cmars` is now known as cmars [11:57] vigo, yo [12:09] ogra_, what does this mean? [12:09] 2017-02-08T12:08:04Z INFO snap "core" has bad plugs or slots: core-support (unknown interface) [12:09] when do you get this ? [12:09] I get this refreshing core from candidate [12:10] well stable-> candidate [12:11] well, it is an info message telling oyu that the running core does not have the interface (the new core after the install finished will have it) [12:11] the question is here if snapd is clever enough to re-run any potential config settings that use this interface once the new core is running [12:12] if not, that would be a bug === hikiko is now known as hikiko|ln [12:24] ogra_, great, thanks [12:34] Hello! where can I download model assertion for rpi2 ? need to build an image with default user [12:35] I have the one for pc right now but want to build for rpi2/db [12:37] jdstrand, any reason you can think to not let strict snaps read /usr/share? [12:37] jdstrand, if yes, what about just /usr/share/bash-completion/bash_completion :-) === hikiko|ln is now known as hikiko [13:17] PR snapd#2804 closed: interfaces/core-support: allow modifying systemd-timesyncd and sysctl configuration [13:30] PR snapd#2774 closed: interfaces/mount: add dedicated mount entry type [13:30] PR snapd#2808 opened: interfaces: use mount.Entry instead of string snippets [13:37] Chipaca: this is going to be a can of worms. in general, we should only allow what is required. ok, so for bash completion that is /etc/bash_completion* and /usr/share/bash_completion/*. however, on classic, /etc is mounted in the snap but /usr/share is from core, and core doesn't ship /usr/share/bash-completion/bash_completion, so there is a potentional mismatch, especially when using different cores [13:38] jdstrand, core ships it now [13:38] Chipaca: assuming you fix that (or defer caring), then all the commands in /usr/share/bash-copmpletion/completions/* are probably going to access the filesystem in new and exciting ways [13:39] ogra@localhost:~$ ls /usr/share/bash-completion/bash_completion [13:39] /usr/share/bash-completion/bash_completion [13:39] added last week :) [13:39] that's find, but the /etc vs /usr bit on classic may cause problems and I'm positive will cause problems with say, a fedora core [13:40] * jdstrand wonders why he doesn't have an updated core [13:40] jdstrand: what do you see in snap changes? [13:40] jdstrand: anything that indicates why core is not updating? [13:40] maybe it didn't go to stable? [13:40] yeah, far from that [13:41] jdstrand: oh, you are using stable :) consider switching [13:41] I have r888 [13:41] edge and (not sure) perhaps candidate [13:41] well, my laptop I won't, but I can do that somewhere else [13:42] * jdstrand notes that adding bash_completion was the least of his concerns-- that's easy :) [13:43] (the file, not the functionality) [13:50] jdstrand, core does ship bash completion as of now (on edge) [13:50] jdstrand, all I really need is /usr/sahre/bash-completion/bash_completion, not the completion scripts [13:51] Chipaca, well, on classic you might want them [13:53] ogra_, not from inside confinement [13:54] ^ strict [13:55] ah,. k [13:55] mvo: have you given this bug more thought: hsearch_r failed: No such process? [13:55] jdstrand: yes [13:56] mvo: I updated core and now nothing starts (cause of old snap-confine) [13:56] jdstrand: in the standup right now, I have something but we need to talk more because reverts of core are probably broken right now too [13:56] jdstrand: I have a branch that is still a bit messy [13:56] mvo: I would be interested in seeing that branch when you're ready for me to look at it [13:57] hey when you have a syntax like git+https://github.com/zioproto/kolla-ansible how do I select a specific branch ? [13:58] I mean in python-packages: in the snapcraft.yaml [13:58] jdstrand: preview (slightly messy) https://github.com/snapcore/snapd/compare/master...mvo5:feature/snap-confine-from-core?expand=1 [13:58] jdstrand: but its essentially what we discussed via mail, i.e. snapd wil create correct apparmor profiles for the snap-confine on core === stokachu_ is now known as stokachu [14:00] managed ! #branch=name [14:08] Hi guys, I am using /snap/bin/snappy-debug.security scanlog my_first_app [14:08] zioproto: yeah, same semantics as with pip [14:09] to see why AppArmor is blocking it [14:09] br4nd0m: awesome, how's it working out? [14:09] and I get:* adjust snap to ship 'ip' * adjust program to use relative paths if the snap already ships 'ip' [14:09] hi popey, it's going OK, just got stuck there [14:11] ogra_: Serial console on the Pi is the best invention since the sandwich :) [14:11] haha [14:11] ogra_: Do you know why the wifi is not working on the Pi3 yet? === tsdgeos_ is now known as tsdgeos [14:15] rvr, driver bug, not sure if ppisati ever got around reserching it more (i didnt) [14:16] rvr, it works if you first configure wired, then reboot and call sudo console-conf via ssh ... you can then turn off wired, configure wlan and reboot [14:16] ogra_: I see [14:16] ogra_: I just re-checked during the first boot, and of course failed [14:17] righ, second boot is the key :) [14:18] * Mirv notes that tsdgeos_ should get a shell account or fix internets [14:19] Mirv: oh no [14:19] it's that snap is hardlocking my system [14:19] that's what shoudl be fixed :D [14:19] it cannot be, ogra_ says snappy fixes stuff, not breaks [14:21] mvo: http://paste.ubuntu.com/23954598/ [14:21] mvo: would be nice if I could comment on your branch before the PR... [14:21] jdstrand: oh, nice [14:21] jdstrand: thank you! [14:22] jdstrand: I can make it into a PR, then you can comment [14:22] mvo: there is one other fun wrinkle that I thought of. /etc/apparmor.d/abstractions vs /var/snap/core/current/etc/apparmor.d/abstractions [14:22] mvo: this is something that has always been there but I don't think we ever considered [14:23] mvo: today I think we are lucky cause the core snap is pulling from the archive and so is the classic host and we haven't made changes to the abstractions, so they are in sync [14:24] jdstrand: yeah, good point [14:24] mvo: but it is easy to imagine scenarios when they may be out of sync [14:24] mvo: I don't think that has to be fixed here [14:25] jdstrand: https://github.com/snapcore/snapd/pull/2809/files [14:25] PR snapd#2809: cmd/snap-confine-tests: reformat test to pass shellcheck [14:25] PR snapd#2809 opened: cmd/snap-confine-tests: reformat test to pass shellcheck [14:25] jdstrand: https://github.com/snapcore/snapd/pull/2810 <- so that you can comment more easily [14:25] PR snapd#2810: snap: use snap-confine from the core snap [14:25] jdstrand: I work on that now [14:26] zyga: speaking of shellcheck. I noticed that my build environment was complaining (non-fatally) that shellcheck wasn't there. I then installed it, and it still complained [14:26] PR snapd#2810 opened: snap: use snap-confine from the core snap [14:26] not restarting into "/snap/core/current/usr/bin/snap" ([VERSION=2.21 2.21]): older than "/usr/bin/snap" (2.22.2+17.04) [14:26] what does this mean? [14:26] is it bad? [14:30] tsdgeos_: totally harmless - where do you see that? [14:30] mvo: /var/log/syslog [14:31] tsdgeos_: ok, that is expected. it just means your deb version of snapd is newer than the version in the stable core snap. on zesty that is pretty much always the case because zesty is very ahead :) [14:31] ok, tx [14:33] mvo: we are missing in ver[1] in the printing that message :) [14:33] s/in// [14:33] how do i see what applications are available in the core snap [14:34] stokachu, we onyl guarantee /bin/sh (and recently python) [14:34] ogra_, ok cool, makes it easy [14:34] pedronis: indeed, the message is not as nice as it should be [14:34] stokachu, while theer are indeed a lot more binaries included they can always drop out [14:35] ogra_, ack [14:36] Mirv, since you are here ... [14:36] ogra@localhost:~$ snap install ubuntu-app-platform [14:36] error: cannot install "ubuntu-app-platform": snap not found [14:36] do we not build it for armhf ? [14:36] mvo: commented === rumble is now known as grumble [14:36] (i can actually install the terminal app butz not the needed platform for it) [14:37] jdstrand: re-run autogen, that should fix shellcheck [14:37] jdstrand: it's a configure-time decision [14:37] jdstrand: thank you! [14:38] ogra_: we guarantee a bit more [14:38] zyga, well, libc [14:38] ogra_: look at what the apparmor profile allows for various interfaces [14:38] ogra_: if we say that interface "foo" can run /usr/bin/fooctl then that is what we allow [14:38] zyga, well, thats definitely wrong then [14:38] ogra_: we really do that [14:38] jdstrand: I added a review to mvo's branch [14:38] unless we dropped all our policies [14:39] jdstrand: please read it as well as it is very tricky business [14:39] any binary in the core can drop out at any time [14:39] guys, I need to run to buy some food [14:39] I'll be back in one hour [14:39] we always said we dont give any guarantee for them to be there [14:39] zyga: any reason why we don't build-depends on shellcheck? [14:41] ogra_: is ubuntu-app-platform only in --edge? [14:42] jdstrand, i tried all channels and with/without --devmode [14:42] jdstrand: 14.04 [14:43] zyga, huh ? [14:43] jdstrand: and immense pain on gentoo :) [14:43] shellcheck is in ubuntu since ages ... [14:43] ogra_: it wasn't available last time I looked [14:43] it definitely is [14:43] https://launchpad.net/ubuntu/+source/shellcheck [14:43] hmm [14:44] backports ... thats weird ... i knwo i used it in code in 10.04 [14:44] zyga: I'm talking about Ubuntu's debian/ directory [14:44] zyga: there is no reason Ubuntu's snapd couldn't BuildDepends on shellcheck. am I missing something? [14:45] jdstrand, well, it isnt in 14.04 [14:45] jdstrand: yeah, now it can; it was hard before [14:45] jdstrand: I'll make that so [14:45] as zyga just proved to me ... [14:45] * ogra_ is still baffled [14:45] ogra_: oh, I took your 'ages' comment to include 14.04 :) [14:45] jdstrand, well, as i said above, i'm sure i used shellcheck in 10.04 projects [14:46] well, whatever, I have a note now for it [14:46] so thats super confusing [14:46] but LP doesnt lie [14:46] (i assume) [14:48] jdstrand: can you please approve https://github.com/snapcore/snapd/pull/2811 [14:48] PR snapd#2811: cmd: add sc_is_debug_enabled [14:48] PR snapd#2811 opened: cmd: add sc_is_debug_enabled [14:48] jdstrand: trivial and I plan to use it to avoid debugging-only code in new stuff [14:48] jdstrand: feel free to request name changes, I will follow up if you want that [14:49] * zyga -> shopping [14:50] PR snapcraft#1119 opened: tests: skip the tests that can't be run in arm64 [15:04] sergiusens, hey did you manage to take a crack at refactoring the build/stage-packages backend? [15:30] didrocks: thanks for quick merge on the desktop helper :) [15:31] mterry: yw! :-) [15:32] Hi guys === Flint is now known as Guest45206 [15:32] Quick question, is there a snap packages offering maas-region controller and maas-rack controller or even a maas meta snap package? === Guest45206 is now known as Fl1nt [15:35] cls [15:35] lol [15:36] ok, so: Here I'm back: Quick question, is there a snap packages offering maas-region controller and maas-rack controller or even a maas meta snap package? === chihchun is now known as chihchun_afk [15:39] Is there any way I can provide a mirror for snaps? Basically, a rsync endpoint I could download all the snaps for, then configure snap to fetch the packages from my endpoint instead? [15:55] re [16:01] snap is all unhappy if you try to remove the same thing twice :D [16:02] http://paste.ubuntu.com/23955037/ [16:02] and the spinner stays there foreeeeeeeeeeeever [16:03] PR snapd#2811 closed: cmd: add sc_is_debug_enabled [16:05] ah. not forever [16:05] finished eventaully [16:07] PR snapd#2809 closed: cmd/snap-confine-tests: reformat test to pass shellcheck [16:08] PR snapd#2680 closed: interfaces: shutdown: also allow shutdown/reboot/suspend via logind [16:11] ogra_: even with the modules and firmware directory in /, a freshly created image stops at "Running /scripts/local-premount ..." [16:12] ppisati, squashfs compiled in or as module in the initrd ? [16:13] ogra_: module, but part of initrd (at least if i trust snapcraft haven't manually checked though) [16:13] hmm [16:13] ... [16:13] - CONFIG_SQUASHFS=m [16:13] kernel-initrd-modules: [16:13] - squashfs [16:13] and you have a proper label on the writable partition ? [16:13] Chipaca: http://paste.ubuntu.com/23955092/ [16:13] thats the only two things i could imagine making it stop there [16:13] ogra_: i dd the image, let me check [16:14] oh, also dont forget we have two console= args nowadays [16:14] might be the output switches to tty (in case you are watching serial) [16:14] Chipaca: note, with that I can get command tab completion to work and then argument completion to try to work. but things aren't going to be great. eg, [16:14] $ . /etc/bash_completion [16:14] bash-4.3$ fdisk bash: /bin/lsblk: Permission denied [16:14] ogra_: i was watching serial and the lcd screen [16:14] ah, k [16:15] ogra_: indeed the "Running local-premount" only shows on lcd [16:15] Chipaca: (where after 'fdisk ' I pressed [16:15] ... [16:15] /dev/sdc8: LABEL="system-boot" UUID="2638-BE3F" TYPE="vfat" PARTLABEL="system-boot" PARTUUID="67822573-51a0-4e57-af2a-7f675ff35f0e" [16:15] /dev/sdc9: LABEL="writable" UUID="e0364375-0ae8-4459-8462-2745dfe933a0" TYPE="ext4" PARTLABEL="writable" PARTUUID="fdaaa4cd-7a8e-4f1f-a0f1-4bbb0ea622a8" [16:15] and it appears the correct partition label is there [16:15] looks fine [16:15] well, thats the only thing i could imagie apart from missing kernel config [16:16] though i wouldnt know what could be missing [16:16] Chipaca: but it works fine for things that are allowed in teh policy. eg: [16:16] bash-4.3$ dmesg -- [16:16] --buffer-size --ctime --human --read-clear [16:16] ... [16:16] ogra_: let me do some more debugging [16:16] if you boot with break=premount, does /proc/filesystems have squashfs ? [16:16] perhaps there is more broken in the kernel plugin [16:16] jdstrand, this is for tab completing of snap apps [16:16] * ppisati tries [16:17] jdstrand, so the completion script itself would be shipped in the snap (hypothetically; i'm still at the proof-of-concept step) [16:18] jdstrand, that's why it was only bash-completion (which granted does ship a lot of completers itself; maybe i need to cut that down and ship our own version of it for this?) [16:18] ogra_: ah, i can't stop it at boot prompt [16:18] lovely [16:18] oh [16:18] ppisati: did you enable the correct compression options for squashfs? [16:18] Chipaca: I know tyhicks represented the concerns regarding this since something the snap ships is running outside of confinement (unless we do something to confine it, which I gather is what you are working on) [16:18] ppisati, even with break=top ? [16:19] (that should kick in before *anything runs) [16:19] jdstrand, exactly, what i'm working on is having the completion itself running confined [16:19] zyga: http://pastebin.ubuntu.com/23955117/ [16:19] anyone willing to take a look at my amd64 build log for rust: https://launchpadlibrarian.net/305573480/buildlog_snap_ubuntu_xenial_arm64_ceph-safe-disk_BUILDING.txt.gz ? It's failing but I'm not entirely sure why [16:20] Chipaca: so, there is a choice. I just demonstrated tab completion can work for commands on the system. I think there will be issues with different cores and on classic with host /etc mounted in the snap, but it works in principle [16:20] ppisati: yes, looks good; though you may want to check how this compares to ubuntu kernel on amd64, we changed some things after realizing the settings we used consume gobs of ram [16:20] ogra_: i can't break to the uboot prompt (counter is 0), so i need to regenerate uboot.env with tha option appended [16:20]