[00:16] <mwhudson> hm
[00:16] <mwhudson> i guess i need to learn how to use ubuntu-image now then?
[00:16]  * mwhudson has lunch instead
[01:08] <mwhudson> how do i get ubuntu-image to use a code snap i just made?
[01:17] <sergiusens> stgraber popey fwiw I have a pending task to move to your built-in `ubuntu:` shortcuts
[01:17] <sergiusens> which is the only reason I went with random names, to not conflict with any image repo that might have been pre-existing
[02:26] <deadlock> Hello, guys! I'm trying to run the snap on openSUSE Tumbleweed, but the daemon doesn't starts. Service status [# systemctl status snapd]: http://pastebin.com/cDtiHqVd Anybody knows how solve it?
[02:32] <slangasek> ogra_: fonts, you're not making extensive use of font support and there's a built-in and honestly I'm not sure why we do what we do currently with grub menus on the snappy devices which is definitely different from the designed classic experience
[02:33] <slangasek> ogra_: should be no problem losing unicode.pf2 - but anyway, snapd will need to depend on grub-common (I've filed a bug for this) which will pull some bits back into the image
[02:43] <mwhudson> adsadadsa das
[02:43]  * mwhudson stabs agetty with a spoon
[02:46] <mwhudson> or something
[02:46] <mwhudson> maybe UNIX
[03:12] <mwhudson> why the heck is agetty leaving ICRNL off on the serial line?
[03:12] <mwhudson> and why am i caring about this in 2016
[04:00] <mup> PR snapcraft#794 opened: Improve lifecycle execution of steps <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/794>
[05:24] <pitti> ogra_: eww, no; kill shim with fire, please
[05:25] <pitti> ogra_: I removed shim from yakkety; it was still necessary in xenial for upgrades from trusty
[05:49] <mup> PR snapd#1893 closed: packaging: make sure debhelper-generated snippet is invoked on postrm <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1893>
[05:52] <mup> PR snapd#1889 closed: tests: add yakkety test host <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1889>
[06:36] <dholbach> hey hey
[07:51]  * mwhudson waves
[07:59] <liuxg> camera is not working on qualcom snapdragon 410c board. is there any way to enable it? I am now building a demo for a show.
[08:15] <morphis> mvo, ogra_: are there any good options to debug when I can't configure a ethernet connection via console-conf and serial access isn't available?
[08:19] <ogra_> i assume attaching a screen is also impossible ?
[08:19] <liuxg> mvo, is camera working on 410c board? thanks I followed the example project at https://github.com/snapcore/snapcraft/tree/master/demos/webcam-webui, it is not working. thanks
[08:21] <ogra_> liuxg, if you use a camera that has a supported module it should surely work
[08:21] <abeato> mvo, ogra_ does anybody know how to give more permissions to enable dbus services? it looks like I cannot start a dbus service using dbus-launch in a script in ubuntu core?
[08:21] <ogra_> abeato, do you ship dbus-launch ?
[08:21] <liuxg> ogra_, what is a supported module? My current camera worked with pi2 and pi3 well, but it does not work with the 410c board.
[08:21] <ogra_> and do you make it create sockets inside the confined space ?
[08:22] <abeato> ogra_, yes
[08:22] <abeato> yes
[08:22] <ogra_> hmm, then it should work i imagine ... whats the error
[08:22] <abeato> gimme permissions :p
[08:22] <ogra_> well, syslog/dmesg journalctl ... etc
[08:22] <abeato> ECONNREFUSED
[08:22] <abeato> dmesg looks fine
[08:23] <ogra_> no apparmor denial ?
[08:23] <abeato> no
[08:23] <ogra_> liuxg, dunno,. watch dmesg while you plug it in (dmesg -w)
[08:24] <ogra_> it should tell you if it finds a driver
[08:25] <liuxg> ogra_, http://paste.ubuntu.com/23172681/, is this the correct image?
[08:26] <ogra_> liuxg, yeah, that sounds fine ... so it loads a module (uvcvideo) and also creates an input device for the button
[08:26] <liuxg> ogra_, but it does not get the picture while I run the sample app. on the pi2 and pi3 device, the same camera works fine. it is a little weired.
[08:27] <ogra_> liuxg, and you connected the interface ?
[08:27] <ogra_> or ... rather ... is the interface connected ?
[08:27] <liuxg> ogra_, on the 410c, there is no "camera" interface at all. I used devmode
[08:28] <liuxg> ogra_, this is how it looks like http://paste.ubuntu.com/23172688/
[08:28] <ogra_> zyga, ^^^ in which case would ubuntu-core on a device offer a camera interface ? does the device need to exist on startup ?
[08:28] <liuxg> ogra_, maybe the camera service is not up yet in the ubuntu core?
[08:29] <ogra_> liuxg, did you try rebooting with the camer plugged in ?
[08:29] <ogra_> might be that the video device needs to exist when snapd start
[08:29] <ogra_> s
[08:29] <liuxg> ogra_, yes, I did it. anyway, I changed another camera and reboot to see what happens.
[08:34] <seb128> zyga, hey, is bug #1622678 something for you?
[08:34] <mup> Bug #1622678: /etc/profile.d/snapd.sh is overwriting PATH and XDG_DATA_DIRS <packaging> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1622678>
[08:34] <seb128> zyga, it's a bug in the fedora package it seems
[08:35] <liuxg> ogra_, , thanks. at your suggestion, after I changed one camera, and it worked. Interestly, the camera worked with p2 and pi3, but it does not work with 410c. it does not need to have driver at all.
[08:37] <ogra_> liuxg, i guess there are bits missing in the dragonboard kernel to make it fully work ... file a bug against the linux-snapdragon package ... and attach the pastebin with the dmesg output
[08:37] <ogra_> (the stuff you captured whenplugging in)
[08:38] <liuxg> ogra_, could you please give me link for reporting the bug?
[08:40] <morphis> ogra_, mvo: how are you guys debugging problems on Ubuntu Core and a console-conf which does not let you into the system and network configuration fails?
[08:40] <ogra_> morphis, try asking mwhudson :) i havent really debugged console-conf issues apart from complaining to him :)
[08:41] <morphis> hah :-)
[08:41] <mwhudson> morphis: systemd debug shell, if you're in kvm
[08:41] <morphis> mwhudson: I am not
[08:41] <morphis> being on a device
[08:41] <mwhudson> if you are stuck on serial, it's hard :/
[08:41] <morphis> there is no login and no user :-)
[08:42] <mwhudson> well indeed
[08:42] <mwhudson> morphis: pull sd card, look at logs on your desktop?
[08:42] <mwhudson> if it's on board flash, even less fun
[08:43] <morphis> mwhudson: I have a serial console, so I have the whole log but nothing interesting in it so far
[08:43] <mwhudson> morphis: console-conf logs stuff to /var/log/console-conf/something.log
[08:43] <liuxg> ogra_, mvo, I have reported a bug for it https://bugs.launchpad.net/ubuntu/+source/linux-snapdragon/+bug/1622909
[08:43] <mup> Bug #1622909: Camera is not fully working on snapdragon 410c board <linux-snapdragon (Ubuntu):New> <https://launchpad.net/bugs/1622909>
[08:44] <ogra_> liuxg, right, thats for ppisati
[08:44] <morphis> mwhudson: see PM
[08:44] <liuxg> ogra_, alrightt :)
[08:44] <ogra_> mwhudson, we need some kind of kernel/bootloader cmdline option that allows debugging i think
[08:45] <ogra_> else porters wont get very far
[08:45] <ogra_> some root shell or so
[08:45] <mwhudson> ogra_: has to be something done at image creation time i think?
[08:45] <mwhudson> or it's a bit of a security open door?
[08:45] <ogra_> mwhudson, ??
[08:46] <ogra_> what could i do at image creation time that makes console-conf give me a root shell instead of firing up the UI
[08:46] <mwhudson> uh wait
[08:46] <ogra_> i mean some internal path that can be taken in the code if there is a certain kernel cmdline option
[08:47] <ogra_> since that comes from the gadget you would need a special debug gadget build
[08:47] <mwhudson> ah ok
[08:47] <ogra_> the assertions should keep you safe from someone abusing it then
[08:47] <mwhudson> not something that you get at at boot time
[08:48] <ogra_> heh, not a bootloader selection like we have on desktop, no :)
[08:48] <ogra_> it is fine to make that a tad complex as long as we offer debug abilities at all :)
[08:49] <zyga> ogra_: camera interface is created unconditionally for now
[08:50] <ogra_> morphis, i think thats worth a ML discussion to get input from all deciders on that topic
[08:50] <morphis> ogra_: absolutely
[08:50] <ogra_> we dont really have a plan for people doing bringup ... currently its all just "lock down as much as possible"
[08:50] <mwhudson> ogra_: i guess your best bet for now is to unsquashfs the core snap, chroot squashfs-root adduser ubuntu and remove the drop-in files that start console-conf
[08:50] <ogra_> mwhudson, i doubt that will boot properly afterwards
[08:51] <mwhudson> ogra_: why?
[08:51] <ogra_> the snaps are signed ...
[08:51] <morphis> yes
[08:51] <morphis> you can resign them etc.
[08:51] <mwhudson> ogra_: and make an image using UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL=1 or whatever
[08:51] <ogra_> we need something that gets put into writable from the initrd and that is understood by console-conf
[08:52] <mwhudson> ogra_: i agree that's a better solution
[08:52] <mwhudson> but not one that's going to arrive this evening :)
[08:52] <zyga> seb128: yes, thank you
[08:52] <seb128> zyga, yw!
[08:53] <ogra_> consoleconf=rootshell cmdline option ... -> makes the wrapper script call a systemd debug shell instead of the UI ... or some such
[08:54] <ogra_> mwhudson, yeah, i didnt mean today/night ... a proper implementation needs discussion and approval first ... i guess morphis needs to start a discussion on the ML describing the prob
[08:54]  * mwhudson finds ConditionKernelCommandLine=
[08:55] <ogra_> well, your wrapper is shell, isnt it ?
[08:55] <morphis> ogra_, mwhudson: hm, I could bypass console-conf by creating the complete flag in /var and adding a user to extrausers
[08:55] <mwhudson> yes
[08:55] <mwhudson> morphis: ah yeah, that would work
[08:55] <mwhudson> ogra_: something about starting a root shell makes me super paranoid, maybe i'm overdoing that
[08:55] <ogra_>         for x in $(cat /proc/cmdline); do
[08:55] <ogra_>             case "${x}" in
[08:55] <ogra_>                 # new kernel/os snap vars
[08:55] <ogra_>                 snappy_os=*)
[08:55] <ogra_>                         snappy_os="${x#*=}"
[08:55] <ogra_>                         ;;
[08:56] <ogra_> ...
[08:56] <ogra_> something like that should work
[08:56] <ogra_> (+ esac and done ... )
[08:57] <ogra_> mwhudson, that is why i want discussion and approval first ... including security people etc
[09:05] <ogra_> wow
[09:06] <ogra_> morphis, did you know that on big.Little the cores can have different cache sizes ... but the arch allows you to migrate processes aroudn from core to core ?
[09:06] <ogra_> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-September/455679.html
[09:06] <ogra_> how gross
[09:10] <ogra_> slangasek, well, given that grub-common is 11MB installed i'd rather see us split grub-editenv into its own package and depend on that ... though long term mvo wants to include grub config handling into snapd itself like we do for uboot with uboot.go
[09:17] <mwhudson> ogra_: hardware bug according to mark rutland on cross-distro
[09:18] <ogra_> oh,. heh you are subscribed :)
[09:27] <zyga> mwhudson: hey, still no update on collab-maint, still fighting some issues
[09:27] <mwhudson> zyga: yay debian
[09:28] <mwhudson> zyga: happy to pull anything you have off github or lp in the meantime
[09:28] <zyga> mwhudson: I didn't do any downstream work lately, still doing upstream things
[09:36] <pedronis> mwhudson: you can use a local snap  with ubuntu-image with --extra-snaps lOCAL.snap (it can even be one of those listed in the model assertion)
[09:36] <pedronis> it will be installed unasserted
[09:36] <mwhudson> pedronis: yeah i figured that out in the end
[09:37] <mwhudson> (by reading the source)
[09:41] <mvo> ogra_: its probably straightfowrad to write that code, might be quicker than to split the pkgs
[09:48] <morphis> mwhudson: creating /var/lib/console-conf/complete should disable console-conf, right?
[09:49] <ogra_> morphis, but wont give you any login ability
[09:49] <mwhudson> morphis: yes
[09:49] <ogra_> (you need a user too)
[09:49] <morphis> ogra_: I've created a local user
[09:49] <ogra_> ah
[09:49] <ogra_> :)
[09:49] <morphis> placing files manually in /var/lib/extrausers
[09:50] <ogra_> that might soon be more complicated ... i'll have to at least add the adm group there as a default group ... so in the future you will have to add, not replace ...
[09:51] <morphis> ogra_: so a >> rather than a > :-)
[09:51] <ogra_> red: dont take for granted that these files are/stay empty
[09:51] <ogra_> *read
[09:51] <ogra_> yeah :)
[10:03] <morphis> ogra_: empty passwords are not forbidden in the system?
[10:03] <ogra_> we dont do anything special
[10:03] <morphis> ok
[10:03] <morphis> then a :: should just work
[10:52] <mup> PR snapd#1856 closed: asserts: required account key name header <Created by emgee> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1856>
[10:54] <ogra_> mvo, looks like i'm done with removing grub (i only actually kept the grub-editenv binary in place) ... amd64 went from 75+ to 66MB ! everything is still working fine (all tested)
[10:57]  * ogra_ knows the above will make manik and zyga very happy :)
[11:24] <mup> PR snapd#1896 opened: cmd/snap: match UX document for message when buying without login <Created by pete-woods> <https://github.com/snapcore/snapd/pull/1896>
[11:53] <liuxg> does anyone successful read data via bluetooth in ubuntu core? My snap app works well in the ubuntu classic (desktop and NUC). However, it does not work in the raspberry pi devices. thanks. I am not so sure whether the bluetooth device has been enabled or not.
[11:59] <zyga> liuxg: I've seen successful data transfer with ubuntu-core and bluetooth stack from bluez but it was not on a rasberry pi
[12:00] <liuxg> zyga, how did you set it up? did you have any special steps to set it up? For my case, https://github.com/liu-xiao-guo/sensortag-test, my project works well on classic ubuntu.
[12:03] <zyga> liuxg: it was a while ago, we created a snap with bluez inside, the tests used bluetoothctl to pair and communicate with some devices
[12:03] <zyga> liuxg: the goal was to automate bluetooth setup and testing
[12:03]  * ogra_ guesses the kernel does not set u the device correctly yet on the pi 
[12:03] <ogra_> s/u/up/
[12:04] <liuxg> zyga, is it possibe to share me the source code? I have just packaged the bluetoothctl command.
[12:05] <liuxg> zyga, when the command is run, I cannot input anything there. Is this a problem?
[12:05] <zyga> liuxg: did you install the bluez snap?
[12:05] <zyga> liuxg: I think all of that was public, I don't recall where it is
[12:05] <zyga> liuxg: maybe ask morphis, I think he might know
[12:06] <liuxg> zyga, the output is like http://imgur.com/a/3b7hr, yes, I have bluez inside the package.
[12:06] <liuxg> zyga, this is my snapcraft.yaml file https://github.com/liu-xiao-guo/sensortag-test/blob/master/snapcraft.yaml
[12:07] <liuxg> zyga, I packaged it into my package. I once installed the bluez package.
[12:09] <liuxg> zyga, how did you make use of the bluez snap? I am currently using devmode to do that. I know bluez has a "bluez" slot.
[12:11] <zyga> liuxg: do you use the bluez plug in your snap>
[12:11] <zyga> liuxg: please report the mkdir error there, make sure to report which snap versio you had there
[12:12] <liuxg> zyga, no, I am now using it . previously not.
[12:12] <zyga> liuxg: check snapd sources as AFAIR we have a test that uses bluez plug/slot now
[12:12] <zyga> liuxg: (or perhaps it was proposed recently)
[12:13] <liuxg> zyga, do you mean here at https://github.com/snapcore/snapd/tree/master/tests/lib/snaps?
[12:14] <zyga> liuxg: grep for the interface name in the tests directory
[12:16] <liuxg> zyga, yes, thanks. I found it there in the main dir. I will take a look at it
[12:27] <morphis> liuxg: you have to run bluetoothctl as root
[12:27] <morphis> sudo /snap/bin/bluez.bluetoothctl
[12:27] <morphis> the source of the snap is at https://code.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/bluez
[12:36] <mup> PR snapcraft#795 opened: WIP: snap-build generation and pushing support <Created by caio1982> <https://github.com/snapcore/snapcraft/pull/795>
[12:37] <liuxg> morphis, ok. thanks. how can I set it up? is the section in the doc enough? https://git.launchpad.net/~canonical-hwe-team/+git/artik_doc/tree/artik-guilde.txt
[12:38] <morphis> liuxg: what do you mean by set it up?
[12:39] <mup> PR snapd#1881 closed: cmd/snap: i18n option descriptions <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1881>
[12:41] <mup> PR snapd#1880 closed: asserts: use gpg --fixed-list-mode to be compatible with both gpg1 and gpg2 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1880>
[12:42] <liuxg> morphis, how do I use bluetoothctl command? should I use it?
[12:42] <morphis> liuxg: depends, what are you going to do?
[12:43] <liuxg> morphis, ok. for my case, it scans (les) the sensortag. maybe not needed?
[12:44] <morphis> liuxg: so you want to pair and connect the sensortag?
[12:45] <liuxg> morphis, I think it does not need to pair, at least for the case of running on my desktop.
[12:48] <liuxg> morphis, what is the correct command to make the connection? for my case, my app is "sensortag", and I have defined plug "bluez". snap connect bluez:sensortag bluez:service?
[12:48] <morphis> snap connect sensortag:bluez bluez:service it is
[12:48] <morphis> we just name the slot "service" on the bluez snap
[12:49] <morphis> liuxg: next thing is, you can use bluetoothctl only as a user and not run it programmatically
[12:49] <liuxg> morphis, then I think this document is a little bit confusing https://github.com/snapcore/snapd/blob/master/tests/main/interfaces-bluez/task.yaml
[12:49] <zyga> tyhicks: should this happen?
[12:49] <morphis> liuxg: why confusing?
[12:49] <zyga>     signal (send) set=("int") peer=@LIBEXECDIR@//mount-namespace-capture-helper,
[12:50] <zyga> Sep 13 14:47:48 autopkgtest kernel: audit: type=1400 audit(1473770868.312:13): apparmor="DENIED" operation="signal" profile="/usr/lib/snapd/snap-confine" pid=5532 comm="ubuntu-core-lau" requested_mask="send" denied_mask="send" signal=int peer="/usr/lib/snapd/snap-confine//mount-namespace-capture-helper"
[12:50] <liuxg> morphis, it says " bluez:client" instead of "client:bluez"
[12:51] <zyga> tyhicks: ah, ignore me, I see the problem
[12:52] <morphis> liuxg: as I said above, we're giving the plug and slot in the bluez snap names
[12:52] <morphis> so we have
[12:52] <morphis> plugs:
[12:52] <morphis>   client:
[12:52] <morphis>     interface: bluez
[12:52] <morphis> and
[12:52] <morphis> slots:
[12:52] <morphis>    service:
[12:52] <morphis>      interface: bluez
[12:52] <morphis> and then this is totally correct :-)
[12:53] <morphis> it ensures you connect just a single plug/slot within your snap
[12:53] <morphis> otherwise you connect all which are using the interface bluez
[12:53] <liuxg> morphis, ok.. I got it.  I thought " snap connect bluez:client bluez:service" was the command for use. I need to replace the "client" there.
[12:54] <morphis> liuxg: in your case you need: snap connect sensortag:bluez bluez:service
[12:54] <morphis> liuxg: next thing is, you can use bluetoothctl only as a user and not run it programmatically
[12:54] <liuxg> morphis, got it. thanks
[12:55] <morphis> liuxg: you can write a python client to talk to bluez, see https://git.kernel.org/cgit/bluetooth/bluez.git/tree/test/ for examples
[12:55] <morphis> liuxg: and https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc for the API documentation
[12:56] <liuxg> morphis, thanks. I will read them
[12:57] <morphis> liuxg: and regarding your question what you have to do to get the sensortag connected: discover it, pair it, connect it
[12:58] <morphis> then all the GATT things become available
[12:58] <liuxg> morphis, so, what should be command for use? bluetoothctl?
[12:59] <mup> PR snapd#1897 opened: snap: run all tests with gpg2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/1897>
[12:59] <liuxg> morphis, I still get some errors like http://paste.ubuntu.com/23173499/, I think the bluetooth is not set up correctly.
[13:00] <morphis> liuxg: can you talk with bluez when using the bluetoothctl coming with the bluez snap?
[13:01] <liuxg> morphis, strangely, in my place, when i run the command like "sudo /snap/bin/bluez.bluetoothctl", in the "[bluetooth]#" prmopt , I cannot type anything there.
[13:01] <liuxg> morphis, no.
[13:01] <ogra_>  is that a pi2 or a pi3 ?
[13:02] <liuxg> morphis, ogra_, it is snapdragon device
[13:02] <ogra_> note that we use the same kernel for both ... but if there is a special module used by pi3 it might not be enabled
[13:02] <ogra_> oh, you said pi above
[13:02] <liuxg> ogra_, morphis, I want to get this working for a demo in a qualcomm event. We do not have much to show.
[13:02] <morphis> liuxg: what does journalctl --no-pager -u snap.bluez.bluez.service give you?
[13:03] <ogra_> ogra@dragonboard:~$ dmesg |grep Blu
[13:03] <ogra_> [   15.016483] Bluetooth: RFCOMM TTY layer initialized
[13:03] <ogra_> [   15.017965] Bluetooth: RFCOMM socket layer initialized
[13:03] <ogra_> [   15.022818] Bluetooth: RFCOMM ver 1.11
[13:03] <ogra_> [   15.027751] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[13:03] <ogra_> [   15.031521] Bluetooth: HIDP socket layer initialized
[13:03] <ogra_> dragon should definitely have BT enabled and running by default
[13:03] <liuxg> morphis, http://paste.ubuntu.com/23173514/
[13:04] <morphis> hm
[13:04] <liuxg> morphis, ogra_ http://paste.ubuntu.com/23173518/
[13:04] <morphis> liuxg: can you give the full journal --no-pager then?
[13:04] <morphis> liuxg: you need to connect bluez:client too
[13:05] <morphis> only then "sudo /snap/bin/bluez.bluetoothctl" is supposed to work
[13:05] <liuxg> morphis, that is huge
[13:05] <morphis> liuxg: do a: snap connect bluez:client bluez:service
[13:05] <morphis> then: sudo /snap/bin/bluez.bluetoothctl
[13:05] <liuxg> morphis, do I need to start the board? After I install the bluez, I did not reboot
[13:05] <morphis> no
[13:06] <liuxg> morphis, yes, this time, I see it works
[13:08] <morphis> good
[13:08] <morphis> liuxg: inside bluetoothctl
[13:08] <morphis> power on
[13:08] <morphis> scan on
[13:08] <morphis> then it should starting finding your device
[13:11] <liuxg> morphis, http://paste.ubuntu.com/23173542/ how can I pair the device?
[13:12] <morphis> liuxg: agent on
[13:12] <morphis> before you call pair <MAC>
[13:12] <liuxg> morphis, http://paste.ubuntu.com/23173549/
[13:13] <morphis> liuxg: try a: connect <MAC>
[13:13] <liuxg> morphis, after I pair the device, I do not need to pair again, right?
[13:14] <morphis> nope
[13:15] <liuxg> morphis, http://paste.ubuntu.com/23173557/
[13:16] <zyga> jdstrand: https://github.com/snapcore/snap-confine/pull/137
[13:16] <mup> PR snap-confine#137: chdir to original directory after setns <Created by zyga> <https://github.com/snapcore/snap-confine/pull/137>
[13:16] <liuxg> morphis, can I quit this bluetoothctl? then run my app?
[13:16] <morphis> liuxg: type "exit"
[13:17] <liuxg> morphis, http://paste.ubuntu.com/23173562/
[13:19] <liuxg> morphis, after exiting, my app still fails to connect to the device. the snap app works in the classic ubuntu
[13:20] <morphis> what does it say?
[13:22] <liuxg> morphis, after exiting the bluetoothctl, I run my app, the error message is like http://paste.ubuntu.com/23173571/, basically, it is the same as before.
[13:22] <morphis> liuxg: so what does your app actually do?
[13:22] <morphis> does it talk to bluez over dbus?
[13:24] <liuxg> morphis, i reuse a project on the github. https://github.com/liu-xiao-guo/bluepy, I do not think it uses dbus
[13:25] <morphis> liuxg: then bluez wont help you at all :-)
[13:25] <morphis> if it doesn't use bluez
[13:26] <morphis> liuxg: so how does it then talk with the bluetooth kernel stack?
[13:26] <liuxg> morphis, oh, that is bad. this is just weird to me. it works on the classic ubuntu.  Previously, I thought the bluetooth was not set up correctly.
[13:27] <morphis> liuxg: lets take a different view on this, what is the use case you actually want to demo?
[13:28] <liuxg> morphis, it does use bluze https://github.com/liu-xiao-guo/bluepy/blob/master/bluez-5.29/src/log.c
[13:28] <morphis> ok
[13:29] <liuxg> morphis, from the ubuntu core, it uses bluetooth to connect to a sensortag device http://www.ti.com/tool/TIDC-CC2650STK-SENSORTAG, we can push the data to mobile or cloud.
[13:36] <popey> Anyone packaged a desktop app which accepts keyboard input from arrows, enter key, escape, but _not_ from alphabetic characters?
[13:39] <ogra_> isnt that aa matter of the app and what keycodes it accepts ?
[13:41] <popey> the same app works fine when not in snap
[13:42] <ogra_> https://github.com/ogra1/nethack/blob/master/snapcraft.yaml ...
[13:42] <ogra_> console-setup ... ?
[13:42] <popey> perhaps, lets see, thanks
[13:43] <ogra_> (though there i added it for the font handling)
[13:44] <jdstrand> zyga: ack
[14:05] <popey> ogra_: that didn't do it :(
[14:08] <ogra_> yeah, was just a wild guess
[14:19] <sergiusens> fgimenez any update on our testing infra?
[14:20] <sergiusens> elopio said you'd check
[14:21] <fgimenez> sergiusens, yes, the provision scripts seem to be broken, it seems to be related to the way the nodes are being labeled
[14:22] <fgimenez> sergiusens, but nothing yet, i'll ping you with any progress
[14:22] <sergiusens> SamYaple the pip branch looks good, just added a simple comment in there
[14:42] <jdstrand> ogra_: oh! linux-generic-bbb. is this a community kernel? should I update the review tools for it? (will it get autouploads based on -generic in the archive?)
[14:43] <ogra_> jdstrand, well, it is knd of a community kernel ... effectively it is the same as all our others, just using linux-generic on armhf
[14:43] <ogra_> i didnt want to grab the linux-generic name though ... assuming we might want to use it for something official later
[14:45] <jdstrand> ogra_: on a personal note (I have two bbbs), is there scripting/whatever to just get what floats into -security or will you be doing that manually?
[14:45] <ogra_> jdstrand, for now it is only for playing around with the BBB ...
[14:46] <ogra_> jdstrand, i have some lp-lib scripting on my TODO
[14:46] <ogra_> today i simply watch the -changes MLs and just bump the version (which triggers a rebuild) in the tree
[14:47] <ogra_> every time i see a new -meta hist -proposed or -security
[14:47] <jdstrand> ok thanks. until the snap declarations are in place, I'll leave this as manual review, but I'll add a note for other reviewers to approve so you aren't blocked on me
[14:49] <jdstrand> ogra_: what is the recommended gadget snap? I have in my notes 'beagleblack', is that still up to date?
[14:51] <ogra_> yeah, i doubt i'll need any new uploads soon though ... not before we have a working gadget at least
[14:52] <ogra_> well, currently we have none
[14:52] <ogra_> either beagleblack or we find a new name
[14:52]  * ogra_ wouldnt mind calling it just bbb
[14:54] <jdstrand> ogra_: to be clear, I was talking about https://myapps.developer.ubuntu.com/dev/click-apps/4014/rev/7/ ('beagleblack' from the store for series 16, from mvo), not me creating a gadget
[14:54] <ogra_> jdstrand, yes, me too
[14:54] <jdstrand> just wondering if that is still the right thing to use
[14:54] <jdstrand> ok
[14:54] <jdstrand> cool
[14:54] <jdstrand> thanks
[14:54] <ogra_> no, it isnt
[14:55] <ogra_> it hasnt been ported for ubuntu-image
[14:55] <ogra_> and u-d-f is now obsolete
[14:56] <jdstrand> ogra_: I see. if you come up with a gadget snap to use and upload, if you remember, would you mind pinging me?
[14:56] <ogra_> will do
[14:56] <ogra_> if elopio doesnt get to it before me :)
[14:56] <jdstrand> I'd like to move at least one of these to series 16
[14:56] <ogra_> he was the one pushing for it :)
[14:57]  * jdstrand thanks elopio :)
[14:57] <ogra_> :)
[14:57] <jdstrand> ogra_: and thank you too :)
[14:58] <ogra_> np, doing a kernel is just a matter of changing a few lines in the existing scripts (as long as there is a package in the archive)
[15:01] <SamYaple> sergiusens: it was not intentional to change the import order. please ignore
[15:01] <ogra_> slangasek, so i'm trying to get an ubuntu-image that only creates a 500MB image ... i cloned https://github.com/CanonicalLtd/ubuntu-image, edited snapcraft.yaml to use "source: ." and changed all occurences of "4000000000" to "500000000" in ubuntu_image/builder.py ... yet it still produces a 4GB image :/
[15:02] <ogra_> (interestingly it also forces me to use sudo for a loop mount, i thought that bit was gone with teh fixed mcopy)
[15:05] <slangasek> ogra_: the sudo loop mount is because you're on xenial with old e2fsprogs
[15:05] <ogra_> ah
[15:05] <ogra_> well, i dont get that on my laptop
[15:05] <ogra_> where i use the ubuntu-image from the store
[15:05] <slangasek> ogra_: yes, because the snap has bundled newer e2fsprogs :)
[15:06] <ogra_> ah, because i built it locally ... understood
[15:06] <ogra_> so why dont i get a 500MB image with these changes ? i cant see "4000000000" being used anywhere else in the code
[15:06] <slangasek> As for the image size, hmm.  I was going to be working on that today, tracking down all the hard-coded sizes and changing it to size the writable partition to the contents
[15:07] <slangasek> maybe there's a 3.6G hard-coded somewhere also, don't know for sure
[15:07] <slangasek> regardless, feel free to leave it to me to hack on todya
[15:08] <ogra_> well, i wanted to test the new ubuntu-core ony my dragon and i actually only have a 3.9GB card spare :)
[15:09] <ogra_> i find it more worrying that the card is trash after dding a to big image to it ... i dont understand why ... the end of the img should only be zeros
[15:10] <liuxg> dholbach, do you know whether the classic server image at https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/ works for pi3 device?
[15:10] <dholbach> liuxg, sorry, I hvae no idea - I think they're different though - ogra_ ^ can you confirm?
[15:11] <ogra_> liuxg, i dont think it does
[15:11] <ogra_> pi3 needs its own uboot binary
[15:11] <liuxg> dholbach, ogra_, but on the page, it says "Get started with a Raspberry Pi 2 (or 3)".
[15:11] <ogra_> well, they try it
[15:11] <liuxg> ogra_, so where can I find the image for the pi3?
[15:11] <ogra_> *then try it
[15:11] <ogra_> i have never used classic on a pi3
[15:12] <liuxg> ogra_, it seems that it is not working. I got a color screen output. but the image works for pi2 for sure.
[15:12] <ogra_> right
[15:12] <ogra_> no idea about that
[15:12]  * ogra_ only does snappy on pi3
[15:13] <liuxg> ogra_, it is because another colleague got confirmation from didier, so I had a try.
[15:14] <iliv> is there a way to define CFLAGS, LDFLAGS, etc. in snapcraft.yml?
[15:14] <ogra_> slangasek, oh, bah ... i see why my hack doesnt get used ... obviously the snapcraft build does a git clone ... and then does a py3versions -d ... which does another git clone it seems
[15:15] <ogra_> iliv, there surely is ... dont ask me how though :)
[15:15] <iliv> how? :)
[15:15] <ogra_> haha
[15:15] <ogra_> liuxg, well, use the snappy images, they definitely work :)
[15:16] <liuxg> ogra_, yeah, I just want to try whether the bluetooth works on classic :)
[15:16] <ogra_> i doubt it
[15:17] <ogra_> same kernel ... similar setup
[15:17] <stgraber> zyga: any idea when we'll be getting a new snap-confine?
[15:17] <liuxg> ogra_, ok.. I got it. thanks!
[15:20] <zyga> stgraber: as soon as I can land ns sharing, I was aiming for last Friday but there were a few more things to polish
[15:21] <stgraber> ok
[15:22] <slangasek> ogra_: speaking of testing images, did you see the discussion about the pi3 not unxz'ing?  did you create this image or did mvo?
[15:23] <ogra_> slangasek, mvo_ did and i pinged him about it yesterday morning
[15:23] <ogra_> he wanted to re-do it
[15:23] <ogra_> (i havent checks if he did though)
[15:23] <mvo_> ogra_: uh, I did not, sorry
[15:23] <mvo_> ogra_: let me do it now
[15:23]  * zyga added some extra sanity checks to snap-confine and fires another spread run
[15:23] <ogra_> mvo_, thanks
[15:30] <mup> PR snapd#1895 closed: store: refactor auth/refresh tests <Created by matiasb> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1895>
[15:36] <mvo_> ogra_, slangasek: how about a new set (not just pi3) that is still based on the snaps from the beta but has 3.8gb instead of 4gb (or even less) to ensure it fits on 4gb sd cards?
[15:37] <ogra_> mvo_, that requires a new ubuntu-image first ... the size is hardcoded
[15:37] <slangasek> mvo_: I'm going to fix that bug properly today, if you'd like to wait for it to land
[15:37] <mvo_> ogra_: sure, but that it not hard to change
[15:38] <slangasek> properly == autosizing the image based on the writable partition's content size
[15:38] <ogra_> mvo_, thats what i thought ... i gave up after 1.5h trying :P
[15:38] <mvo_> slangasek: aha, sure, depends a bit on "today" as your today is a bit longer than my today :)
[15:38] <mvo_> ogra_: oh? hm
[15:38] <slangasek> mvo_: yes, you'll be offline by the time I'm done
[15:38] <mvo_> ogra_: in any case, looks like slangasek has it under control
[15:38] <mvo_> slangasek: ok, I will just redo pi3 then
[15:38] <ogra_> mvo_, though i'm trying with a local snap ... i think it still pulls to much remote stuff when i call snapcraft and overwrites my local hackery
[15:41] <ogra_> [FAILED] Failed to start Run snappy firstboot setup.
[15:41] <ogra_> See 'systemctl status snapd.firstboot.service' for details.
[15:41] <ogra_> GRRRRRRRRR !!!!!
[15:41] <ogra_> damned
[15:43] <ogra_> mwhudson, sooo .... i finally managed to test the wlan config in console-conf ... it pretends to work, but does not give me the final info about IP and ssh login on the finish page ...
[15:45] <ogra_> hrm ... so why does the firstboot service fail
[15:55] <mvo_> ogra_, slangasek: pi3 updated
[15:55] <mvo_> ogra_: if you have a pi3, wouldbe great if you could do a quick test
[15:56] <ogra_> mvo_, oh, one FYI ... not sure you saw last nights backlog .. LP builds of ubuntu-core to edge do not get published, despite the store saying so in the UI ... you need to manually unpublish them all and re-publish via the UI to make it work
[15:56] <ogra_> mvo_, i do have a pi3 buit cvurrently no spare SD big enough
[15:59] <mvo_> ogra_: meh, how annoying, are the right people aware of this?
[15:59] <ogra_> mvo_, yep ... the bug also got updated ... that was the reason why i couldnt snap refresh --edge on the released images
[16:02] <ogra_> Feb 11 16:28:07 localhost snap[1623]: error: assertion is signed with expired public key "-CvQKAwRQ5h3Ffn10FILJoEZUXOv6km9FwA80-Rcj-f-6jadQ89VRswHNiEB9Lxk"
[16:02] <ogra_> from "canonical"
[16:02] <ogra_> Feb 11 16:28:07 localhost systemd[1]: snapd.firstboot.service: Main process exited, code=exited, status=1/FAILURE
[16:02] <ogra_> hah !
[16:03] <ogra_> so that is why my dragoboard image doesnt work
[16:03] <ogra_> we really need such errors more prominent
[16:03] <mvo_> ogra_: uh, Feb 11? what date is you dragonboard?
[16:03] <ogra_> mvo_, just built right now
[16:03] <ogra_> i'm testing the new ubuntu-core with dtropped tasks
[16:04] <mvo_> ogra_: I mean, the log says its "Feb 11"
[16:04] <mvo_> ogra_: what does "date" print on your dragonboard?
[16:04] <ogra_> eb 11 16:30:29 localhost rsyslogd-2007: action 'action 11' suspended, next retry is Thu Feb 11 16:30:59 2016 [v8.16.0 try http://www.rsyslog.com/e/2007 ]
[16:04] <ogra_> Feb 11 16:30:29 localhost systemd[1]: Stopping Ubuntu Core Firstboot Configuration ttyMSM0...
[16:04] <ogra_> Sep 13 16:00:47 localhost systemd-timesyncd[1627]: Synchronized to time server 91.189.89.199:123 (ntp.ubuntu.com).
[16:04] <ogra_> Sep 13 16:00:47 localhost rsyslogd-2007: action 'action 11' suspended, next retry is Tue Sep 13 16:01:17 2016 [v8.16.0 try http://www.rsyslog.com/e/2007 ]
[16:04] <ogra_> Sep 13 16:00:47 localhost systemd[1]: Time has been changed
[16:04] <ogra_> thats fixrtc ...
[16:05] <ogra_> it uses some imaginary date thats not the epoch before it can sync the time
[16:05] <ogra_> (well, actually it should use the last mount date of the SD ... but thats a first boot)
[16:05] <mvo_> ogra_: what year is it imagining?
[16:05] <ogra_> good question :)
[16:06] <mup> PR snapd#1898 opened: many: clean out left over references to integration tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/1898>
[16:06] <ogra_> Filesystem created:       Tue Sep 13 15:32:20 2016
[16:06] <ogra_> Last mount time:          Thu Jan  1 00:00:25 1970
[16:06] <ogra_> Last write time:          Thu Jan  1 00:00:25 1970
[16:07] <ogra_> hmm, i wonder where that feb 11 comes from
[16:07] <mvo_> ogra_: I think that is the issue, however that is a bit tricky, we probably need to make snapd not fuzzy about really old times
[16:08] <mvo_> ogra_: right now its pretty strict about key valid times
[16:08] <ogra_> http://paste.ubuntu.com/23174192/
[16:08] <mvo_> aha
[16:08] <ogra_> dumpe2fs -h "$ROOTDISK" 2>/dev/null|grep "Filesystem created"
[16:08] <ogra_> thast what it uses to find a date
[16:09] <ogra_> (if there is no last mount time)
[16:10]  * zyga iterates on snap-confine
[16:10] <zyga> I fixed a few more aa issues
[16:10] <zyga> fingers corossed, maybe this time it will work
[16:10] <ogra_> mvo_, but that means it should be fine on second boot and the firstboot job should run then
[16:11] <ogra_> and as far as i can tell it doesnt
[16:11] <ogra_> bah and the wlan setup doesnt persist over a reboot
[16:13] <ogra_> Sep 13 15:33:30 localhost systemd[1]: Found device /sys/subsystem/net/devices/wlan0.
[16:13] <ogra_> Sep 13 15:33:31 localhost sh[1497]: sed: can't read /run/systemd/netif/leases/*: No such file or directory
[16:13] <ogra_> Sep 13 15:33:33 localhost sh[1497]: message repeated 2 times: [ sed: can't read /run/systemd/netif/leases/*: No such file or directory]
[16:13] <ogra_> oh, lovely
[16:13] <zyga> I need to patch spread restore in snap-confine to ensure there were no denials
[16:13] <zyga> and then patch any tests that are designed to trigger denials to clean the buffer
[16:13] <zyga> I found a few interesting issues just by accident
[16:14] <ogra_> hmpf
[16:14] <ogra_> Sep 13 15:33:29 localhost systemd[1]: snapd.firstboot.service: Main process exited, code=exited, status=1/FAILURE
[16:14] <ogra_> Sep 13 15:33:29 localhost systemd[1]: Failed to start Run snappy firstboot setup.
[16:14] <ogra_> Sep 13 15:33:29 localhost systemd[1]: snapd.firstboot.service: Unit entered failed state.
[16:14] <ogra_> Sep 13 15:33:29 localhost systemd[1]: snapd.firstboot.service: Failed with result 'exit-code'.
[16:14] <ogra_> this time it doesnt complain about the key
[16:22]  * ogra_ sighs ... no way to get wlan up manually in the netplan world it seems
[16:22] <ogra_> and no way to get a local user in the console-conf world anymore
[16:23] <ogra_> this is annoying
[16:23] <nacc> i thought the local user was tied to your lp id?
[16:23] <nacc> ogra_: --^
[16:23] <ogra_> nacc, its not local
[16:23] <ogra_> its an ssh user
[16:23] <nacc> ogra_: oh right
[16:24] <ogra_> there is no password set
[16:24] <nacc> using lp keys, makes sense
[16:24] <nacc> and w/o network, you can't ssh in :)
[16:24] <ogra_> without working network, no ssh
[16:24] <ogra_> without password, no serial login
[16:26]  * ogra_ sighs and starts another 20min dd 
[16:26] <mup> PR snapd#1886 closed: tests: fix spread tests on yakkety <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1886>
[16:31] <mup> Bug #1623119 opened: wlan setup done by console-conf not persistent <Snappy:New> <nplan (Ubuntu):New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1623119>
[16:31]  * ogra_ files bug 1623119  so pitti and mwhudson can battle over it who is at fault
[16:31] <mup> Bug #1623119: wlan setup done by console-conf not persistent <Snappy:New> <nplan (Ubuntu):New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1623119>
[16:33] <ogra_> and another one for mwhudson
[16:34] <ogra_> bug 1623120
[16:34] <mup> Bug #1623120: console-conf does not show ssh credentials on last page when wlan is involved <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1623120>
[16:34] <mup> Bug #1623120 opened: console-conf does not show ssh credentials on last page when wlan is involved <Snappy:New> <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1623120>
[16:34] <kgunn> ogra_: just checking, is the dragonboard image "good'
[16:34] <kgunn> here http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/
[16:34] <kgunn> ?
[16:34] <ogra_> yes
[16:34] <kgunn> k
[16:35] <kgunn> ogra_: is it still risky atm if you roll your own off edge?
[16:35] <kgunn> like it eats itself or something :)
[16:35] <ogra_> you will hit the issues i'm currenmtly hitting above see the backlog of the last 1h
[16:36] <kgunn> ogra_: good enough...cool, i will use the beta image
[16:37] <ogra_> sudo snap refresh ubuntu-core --edge
[16:37] <ogra_> that should work
[16:37] <kgunn> k
[16:37] <kgunn> ogra_: yeah, i'm on ~aug 20 image i think
[16:37] <kgunn> currently
[16:37] <ogra_> yeah, you want the one from http://cdimage.ubuntu.com/ubuntu-snappy/16.04/current/ as base
[16:37] <ogra_> anything before that is dead beef
[16:38] <SamYaple> the pip/url/glob thing is solved and tests are passed
[16:46] <popey> ogra_: i think bug 1580463 might be what I'm hitting
[16:46] <mup> Bug #1580463: Snap blocks access to system input methods (ibus, fcitx, ...) <snap-desktop-issue> <snapd-interface> <verification-failed> <apparmor (Ubuntu):Fix Released by tyhicks> <im-config (Ubuntu):Fix Released by jdstrand> <snapd (Ubuntu):Fix Released> <apparmor (Ubuntu Xenial):Fix Committed by
[16:46] <mup> tyhicks> <im-config (Ubuntu Xenial):In Progress by jdstrand> <snapd (Ubuntu Xenial):Fix Released> <apparmor (Ubuntu Yakkety):Fix Released by tyhicks> <im-config (Ubuntu Yakkety):Fix Released by jdstrand> <snapd (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1580463>
[16:49] <ogra_> popey, aha !
[16:49] <ogra_> yeah, that makes sense
[16:49] <mup> Bug #1623125 opened: fixrtc script does not catch "Last mount time: n/a" string <Snappy:Triaged by ogra> <initramfs-tools-ubuntu-core (Ubuntu):Triaged by ogra> <https://launchpad.net/bugs/1623125>
[16:50] <popey> tyhicks: jdstrand is 1580463 perchance on your radar?
[16:54] <mup> PR snapd#1899 opened: [store] don't discard error body from request device session call <Created by emgee> <https://github.com/snapcore/snapd/pull/1899>
[16:58] <jdstrand> popey: I'm quite familiar with that bug. curious why you are asking about it?
[16:58] <zyga> all snap-confine regression tests now pass
[16:58] <zyga> that'
[16:58] <jdstrand> zyga: nice! :)
[16:58] <zyga> that's not all but it's encouraging
[16:58] <zyga> there's still a bug there that I hit on main test suite
[16:58] <zyga> and I still need to check a few things for the apparmor profile
[17:14] <mup> PR snapd#1846 closed: overlord/auth,store: fix raciness in updating device/user in state through authcontext and other issues <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1846>
[17:14] <mup> PR snapd#1898 closed: many: clean out left over references to integration tests <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/1898>
[17:27] <mup> PR snapcraft#796 opened: Only discover dependencies on files coming from that part <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/796>
[17:32] <elopio> can I modify the frequence of the autoupdates?
[17:32] <elopio> Chipaca: I think you might know this one ^
[18:21] <popey> jdstrand: because I have packaged an app which we suspect may be hitting it
[18:22] <popey> jdstrand: it's a game which accepts no keyboard input when snapped, but is fine when not snapped
[18:26] <popey> jdstrand: http://popey.com/~alan/bussard_snap.tgz contains the snap, yaml etc
[18:37] <mup> PR snapcraft#785 closed: Check if option is url for pip <Created by SamYaple> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/785>
[19:15] <mup> PR snapd#1900 opened: interfaces: miscellaneous policy updates for default, browser-support and camera <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1900>
[19:27] <kyrofa> Yeesh, welcome back everyone
[19:28] <kyrofa> Guest94770, might want to fix that
[20:17] <dobey> uhm, how the heck am i supposed to know if i have to pass --dangerous, --force-dangerous, or nothing, for "snap install local.snap" to work?
[20:18] <sergiusens> dobey !! I can't release snapcraft anymore due to this :-)
[20:19] <dobey> sergiusens: the worst part about this is that i'm downloading a snap from the store and installing it, so it came from a trusted source!!
[20:19] <kyrofa> dobey, then you shouldn't need the --[force-]dangerous flag
[20:20] <kyrofa> dobey, that's just for local snaps
[20:20] <dobey> kyrofa: right. i downloaded a snap from the store, and am installing it with "pkexec snap install foo.snap"
[20:20] <kyrofa> Ah ha, then it's not fetching the assertions, so still a local snap
[20:20] <kyrofa> So you DO need it
[20:21] <dobey> but how do i know WHICH one i need?
[20:21] <dobey> because it's changed three times now apparently
[20:21] <kyrofa> dobey, try --dangerous, if that doesn't work, use the force one
[20:21] <kyrofa> :P
[20:21] <dobey> kyrofa: and what if --dangerous works but the install fails for some other reason?
[20:22] <kyrofa> dobey, then I'd ask to see a pastebin
[20:22] <dobey> this is in a script we ship
[20:22] <dobey> kyrofa: what i mean is, i don't want to run "snap install" 3 different times just because the command line option changed, and now i can't tell if the error is because of that, or because of something else
[20:23] <kyrofa> I agree that the churn is annoying, but the error you should get due to using --force-dangerous should be "unrecognized option" or some such
[20:24] <kyrofa> Which should be obviously different from a failure deeper in the install process, no?
[20:24] <dobey> kyrofa: well i presume they all exit with exit code 1
[20:25] <kyrofa> dobey, ahh, "in a script" I see what you mean now
[20:25] <dobey> i don't want to have get into parsing stderr/stdout too
[20:25] <kyrofa> dobey, indeed, I see where you're coming from now
[20:26] <dobey> kyrofa: yes, i'm trying to install snaps from the existing click scope, with the smallest changes possible. and i had it working two weeks ago before i went on vacation, but now this --force-dangerous is required, and apparently that will be --dangerous soon :(
[20:27] <kyrofa> dobey, well this isn't ideal anyway, because like you said, you shouldn't need to use --dangerous if you know it's a signed snap, and the scope should only be installing those
[20:27] <dobey> i was basically ready to land this, and then bam, new snappy broke it
[20:28] <dobey> right
[20:28] <kyrofa> dobey, the people I'd ask are EOD, but there much be a way to handle this case
[20:28] <kyrofa> dobey, you should email the list
[20:28] <kyrofa> s/much/must/
[20:29] <kyrofa> dobey, some way to say "hey, grab the assertion from the store," or at least provide the ability for the scope to grab the assertion and provide it to the install command
[20:31] <dobey> the latter would be quite complicated i think, if we'd have to then do two separate downloads
[20:31] <dobey> but snap could clearly parse the filename as $snapid_$revision.snap and then grab the assertions for that
[20:31] <kyrofa> Yeah. Though I suspect that's the more likely to happen since they probably want to enable self-signed assertions, etc.
[20:32] <kyrofa> But yeah, shoot for that
[21:07] <mwhudson> ogra_: still around?
[21:14] <mwhudson> um, is it known that the snapd.firstboot job runs on every boot?
[21:14] <dobey> oh it just makes the rev always be "x1" when you do --force-dangerous :(
[21:15] <kyrofa> dobey, yeah, it's a local install: x1, x2, and so on
[21:15] <kyrofa> dobey, it's been that way for a while. That's why you need the assertion
[21:29] <tsimonq2> elopio: you might want to keep teward in the loop on your nginx snap
[21:30] <elopio> sure. who's teward?
[21:30] <tsimonq2> Ubuntu "maintainer"
[21:30] <tsimonq2> Thomas Ward
[21:31] <tsimonq2> he has upload access to nginx and might be interested in what you're doing
[21:31] <tsimonq2> elopio: upstreaming, remember? ;)
[21:31] <elopio> tsimonq2: yes. That's the kind of help I need to get it working strict. Thanks tsimonq2
[21:32] <tsimonq2> no problem elopio :)
[21:32] <tsimonq2> (there's a reason I subscribe to these emails :P)
[21:33] <tsimonq2> elopio: he's always told me email is the best contact method
[21:33] <tsimonq2> teward@ubuntu.com
[23:06] <mup> Bug #1593407 opened: Guest session cannot run snaps <xenial> <Snappy:New> <lightdm (Ubuntu):Triaged> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1593407>
[23:34] <mup> PR snapd#1901 opened: firstboot: do not overwrite any existing netplan config <Created by mwhudson> <https://github.com/snapcore/snapd/pull/1901>