[02:34] <I> oh
[02:34] <I> heyyy
[02:34] <I> This thing is funny
=== I is now known as Guest43857
[02:34] <Guest43857> okie
[02:49] <Guest43857> nnn
[02:49] <Guest43857> ???
[03:09] <mup> Bug #1620442 opened: snap fails because XDG_RUNTIME_DIR is set to /run/user/1000 <Snappy:New> <https://launchpad.net/bugs/1620442>
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== King_InuYasha is now known as Son_Goku
[06:54] <mvo> ogra_: so when disabling cloud-init we don't get ssh host keys generated anymore, that was the issue yesterday, I added a simple job for that in ubuntu-core-config, that hopefully fixes this issue
[07:05] <liuxg> ogra_, ping
[07:06] <mvo> liuxg: still early for him, probably not around before
[07:06] <mvo> liuxg: at least 1h
[07:08] <liuxg> mvo, ok. thanks. I just flashed my new raspberry pi 3 device. it is very strange that sometimes my device cannot get an IP (it is connected to my router). I cannot use ssh to see what's happening there.
[07:12] <mvo> liuxg: can you see in your router that the router does not assign an ip? when you can not connect?
[07:13] <liuxg> mvo, yes, that is exactly what happened here. Initally it was fine, and I could connect to it. Then I rebooted, it became something like that. I tried to reboot it a number of times, and at one time, i got an IP again. I thought it was fine. I rebooted, then I could not get the ip again :)
[07:14] <liuxg> mvo, I have checked the cable, and change different cables. there should be no problem with the cable. it works well with raspberry pi 2 device.
[07:16] <liuxg> mvo, I am not sure whether it is a hardware issue or not. This is a newly purchaed board.
[07:17] <mvo> liuxg: the system that configures the network changed to "netplan" recently, it sounds like fallout from that, can you attach a keyboard and monitor to the pi3 maybe? that might be useful to figure out more
[07:18] <liuxg> mvo,  the thing is that my HDMI does not seem to work.
[07:20] <liuxg> mvo, do you have any older image which did not use netplan? I want to have a try with that. thanks
[07:21] <mvo> liuxg: not 100% certain but http://people.canonical.com/~mvo/all-snaps/16/old/all-snaps-pi2.img.xz is a good candidate
[07:22] <liuxg> mvo, I am using raspberry pi 3 instead of pi 2. the pi 2 works well here. however, it does not have the bluetooth. I want to use the bluetooth on pi 3 to do a demo.
[07:27] <mvo> liuxg: aha, ok. in this case you need ogra, I don't have any pi3 images available
[07:27] <mvo> liuxg: sorry
[07:27] <liuxg> mvo, yeah, that is why I am trying to reach mvo. thanks for your helping on this.
[07:49] <zyga> o/
[07:58] <LY> Is Ubuntu 16.04 supported on NUC6i5syk
[08:05] <zyga> LY: hello, can you be more specific about the device? is this an intel nuc?
[08:08] <LY> NUC is a mini PC from Intel
=== ant_ is now known as Guest58458
[08:11] <LY> http://ark.intel.com/products/89188/Intel-NUC-Kit-NUC6i5SYK
[08:12] <zyga> LY: I believe all intel CPUs are supported
[08:13] <LY> is there any web page to look at
[08:14] <ogra_> liuxg, http://people.canonical.com/~ogra/snappy/all-snaps/ but that might be missing a lot of fixes
[08:15] <ogra_> (already two weeks outdated and the next image will look totally different)
[08:15] <liuxg> ogra_, where can I find the latest software? I flashed the software and refreshed the system. After that I cannot get the IP again.
[08:16] <liuxg> ogra_, you are apprecited to give me a download link. I will use the pi 3 as a demo device in the tomorrow's Amazon hackathon event here.
[08:16] <ogra_> liuxg, you *must* run the console-conf tool else the device wont have a network config (console-conf sets up the netplan configuration) ... either use a serial cable or HDMI
[08:16] <ogra_> i guess that you dopt get an IP is becausse netplan was never set up
[08:16] <ogra_> *dont
[08:17] <mup> PR snapd#1841 closed: store: switch device session to use device-session-request assertion <Critical> <Created by matiasb> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1841>
[08:17] <ogra_> note that obn newer images you also dont have a user or any way to log in without running the console-conf firstboot wizard
[08:17] <liuxg> ogra_, my HDMI is not working unfortunately. I do not know how to enter the login screen.
[08:17] <liuxg> ogra_, then do you have an older image?
[08:17] <ogra_> well, the only other way is a serial cable
[08:17] <ogra_> yes, under the url above
[08:18] <ogra_> as i said, it is two weeks old ...
[08:18] <liuxg> ogra_, with that, intially, I used ssh and I got into it, but now no matter how I reboot the system, I cannot get the IP. I do not know why it is inconsistent.
[08:19] <ogra_> because it auto-upgrades i guess
[08:19] <mup> PR snapd#1850 closed: tests: remove silly [Service] entry from snapd.socket.d/local.conf <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1850>
[08:19] <ogra_> so after the upgrade it waits for the console-conf input
[08:20] <liuxg> ogra_,  so, I should disconnect it first when it boots, then connect to it again, plugin and ssh. let me try this.
=== Guest58458 is now known as antdillon
[08:20] <ogra_> liuxg, well, once it is connected the upgrade can always happen
[08:20] <ogra_> it happens in background
[08:20] <zyga> morphis: o/
[08:21] <liuxg> ogra_, I know, but I might have already logged in :)
[08:21] <ogra_> not sure what job you need to disable to have it not do that
[08:21] <morphis> zyga: hey!
[08:21] <liuxg> ogra_, it is weird that it worked for me for a while, and then it stopped.
[08:22] <ogra_> yes, because we upgrade ubuntu-core all the time
[08:22] <mvo> ALL THE TIME - actually ;)
[08:22] <ogra_> haha
[08:23] <mvo> (SCNR)
[08:23] <ogra_> mvo, no cloud-init looks lovely here !
[08:23] <liuxg> ogra_, I even did a refresh, and it did upgrade the system. after that, what should I do ?
[08:23] <ogra_> liuxg, you would have to run the tool
[08:23] <ogra_> for which you need any kind of console access
[08:24] <liuxg> ogra_, I need to run " console-conf"? that's it?
[08:24] <ogra_> no
[08:24] <mvo> ogra_: yeah, kvm is happy, I'm checking pi2 now
[08:24] <ogra_> it runs on all ttys ... you just need to hit enter
[08:25] <liuxg> ogra_, do you mean I just need to hit enter after I boot the device?
[08:25] <ogra_> liuxg, yeah, on a tty
[08:25] <liuxg> ogra_, you said that I should set the netplan, right?
[08:25] <ogra_> no. console-conf does that
[08:25] <liuxg> ogra_, ok. in fact I have a cable, but I do not see the screen
[08:26] <mup> PR snapd#1851 opened: interfaces: serial-port use udevUsbDeviceSnippet <Created by jocave> <https://github.com/snapcore/snapd/pull/1851>
[08:27] <ogra_> mvo, so the image seems to work just fine ... but i still have the IP changing on second boot (then it persists) ... and indeed i can still not install snaps
[08:27] <ogra_> beony this this image looks really good
[08:27] <mvo> ogra_: do you have a /etc/resolv.conf error? this is on pi2 or kvm?
[08:27] <liuxg> ogra_, this problem does not happen to pi2
[08:27] <ogra_> ogra@localhost:~$ ping web.de
[08:27] <ogra_> ping: unknown host web.de
[08:27] <ogra_> ogra@localhost:~$
[08:27] <ogra_> oha ...
[08:27] <mvo> ogra_: /etc/resolv.conf?
[08:27] <ogra_> that worked with all images yesterday
[08:28] <mvo> ogra_: what does it look like? and pi2 or kvm?
[08:28] <ogra_> ogra@localhost:~$ cat /etc/resolv.conf
[08:28] <ogra_> # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
[08:28] <ogra_> #     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
[08:28] <ogra_> ogra@localhost:~$
[08:28] <ogra_> pi2
[08:28] <mvo> ogra_: yeah, that looks very wrong
[08:28] <mvo> ogra_: I mean, empty
[08:28] <ogra_> yeah
[08:28] <ogra_> i guess yesterday cloud-inuit did set it up
[08:28] <mvo> ogra_: I seeded libnss-resolve again, I had hoped it would fix it
[08:29] <mvo> ogra_: yes, I suspect so too
[08:30] <mvo> ogra_: I suspect some race, I had it on firstboot (empty resolv.conf), second boot is fine, trying more now
[08:30] <ogra_> does libnss-resolv need any config  ?
[08:31] <ogra_> mvo, well, there is definitely a massive difference between first boto and the setup after console-conf ran ... else my IP wouldnt change
[08:31] <ogra_> *boot
[08:32] <ogra_> hmm, manually restarting the resolvconf service has no effect
[08:36] <mvo> ogra_: hm, all my subsequent boots are fine so far, quite annoying
[08:36] <mvo> ogra_: i.e. they have the same IP and get a valid resolvconf file
[08:36] <ogra_> pitti, wheer should i find the actual network config now ... beyond netplan
[08:36] <ogra_> mvo, for me it is the exact opposite
[08:37] <pitti> ogra_: cat /run/systemd/network/
[08:37] <pitti> err, ls
[08:37] <pitti> well, "in"
[08:37] <ogra_> ah, i was looking in /etc/systemd/network/
[08:38] <pitti> they are not original config, just generated, so they shouldn't be in /etc/
[08:38] <ogra_> yeah
[08:38] <ogra_> well, that part looks fine ... still my IP changes exactly once
[08:38] <ogra_> right after the system told me which one to use to log in :P
[08:38] <mvo> ogra_: hrm, hrm, no idea what it is, but really hard to reproduce for me, both pi2 and kvm give me a valid resolv.conf, however fgimenez reorted he also had this issue on kvm
[08:38] <pitti> different machine-id for firstboot vs. second boot?
[08:39] <ogra_> pitti, nope
[08:39] <pitti> resolv.conf is a bug, but unrelated to the IP
[08:39] <ogra_> machine-id is created on first boot by initrd ... before any network is up
[08:40] <pitti> no, installing libnss-resolve should auto-add itself to /etc/nsswitch.conf and enable the service
[08:40] <pitti> no config necessary
[08:41] <ogra_> pitti, http://paste.ubuntu.com/23140573/
[08:41] <mvo> ogra_: does nsswitch.conf look valid?
[08:41] <mvo> ogra_: i.e. have "resolve" in the hosts?
[08:42] <ogra_> hosts:          files resolve dns myhostname
[08:42] <ogra_> networks:       files
[08:42] <ogra_> pitti, this time i dont really see any difference in the client requests ...
[08:43] <mvo> can't reproduce this still, a bit annoying, all working for me
[08:43] <ogra_> uid and mac are identical
[08:43] <mup> PR snapd#1852 opened: asserts: update trusted account-key asserts with names <Created by emgee> <https://github.com/snapcore/snapd/pull/1852>
[08:43] <ogra_> pitti, but i can fully reliably reproduce it ... after console-conf ran the IP changes once
[08:44] <ogra_> which is very unfortunate since it doesnt match what console-conf gave you for login
[08:46] <ogra_> mvo, well, my install is reliably broken regarding name resolution ... i dont get any resolv.conf setup here
[08:46] <ogra_> so if you have any other ideas :)
[08:46] <ogra_> happy to test
[08:46] <pitti> "systemctl status systemd-resolved" → running?
[08:47] <ogra_> i think not ... let me check again
[08:47] <ogra_> ogra@localhost:~$ systemctl status systemd-resolved
[08:47] <ogra_> ● systemd-resolved.service - Network Name Resolution
[08:47] <ogra_>    Loaded: loaded (/lib/systemd/system/systemd-resolved.service; disabled; vendor preset: enabled)
[08:47] <ogra_>    Active: inactive (dead)
[08:47] <ogra_>      Docs: man:systemd-resolved.service(8)
[08:47] <ogra_> aha
[08:47] <pitti> /lib/systemd/system/systemd-resolved.service.d/resolvconf.conf  runs resolvconf
[08:47] <pitti> ... which updates /etc/resolv.conf
[08:48] <ogra_> yeah, and manually starting it fixes it
[08:48] <ogra_> so why does it think it was vendor-disabled ?
[08:48] <pitti> without libnss-resolve we need to find something else to call it with the DNS servers picked up by networkd, that's what I still need to think about
[08:48] <ogra_> oh, i read that wrong, sorry
[08:48] <pitti> ogra_: probably more likely "not enabled"
[08:48] <ogra_> yeah
[08:49] <ogra_> but thats weird, given that mvo says it works for him ... for me it only worked before console-conf
[08:50] <mvo> ogra_: uh, its disabled for me as well!
[08:50] <pitti> ogra_: do you have a /etc/systemd/system/multi-user.target.wants/systemd-resolved.service symlink?
[08:50] <ogra_> why do you have name resolution then ?
[08:50] <ogra_> ogra@localhost:~$ ls -l /etc/systemd/system/multi-user.target.wants/systemd-resolved.service
[08:50] <ogra_> ls: cannot access '/etc/systemd/system/multi-user.target.wants/systemd-resolved.service': No such file or directory
[08:50] <ogra_> nope
[08:50] <mvo> I bet writable path again :(
[08:50] <ogra_> nah
[08:50] <pitti> so /var/lib/dpkg/info/libnss-resolve\:amd64.postinst didn't run
[08:51] <ogra_> mvo, that dir is mouonted in initrd
[08:51] <ogra_> hmm ... unless
[08:51] <pitti> I was suspecting mounting /etc/systemd/system from fstab, but apparently not that then
[08:51]  * ogra_ chacks the writable-paths file
[08:51] <ogra_> oh man
[08:51] <ogra_> ogra@localhost:~$ grep systemd /etc/system-image/writable-paths
[08:51] <ogra_> # systemd
[08:52] <pitti> this shoudl already happen during building the image, no?
[08:52] <pitti> I mean creating the enablement symlink and running libnss-resolve's postinst
[08:52] <ogra_> ogra@localhost:~$ grep systemd /etc/system-image/writable-paths
[08:52] <ogra_> # systemd
[08:52] <ogra_> /etc/systemd/system                     auto                    persistent  transition  none
[08:52] <ogra_> /var/lib/systemd/random-seed            auto                    persistent  transition  none
[08:52] <ogra_> /var/lib/systemd/rfkill                 auto                    persistent  transition  none
[08:52] <ogra_> /etc/systemd/network                    auto                    persistent  transition  none
[08:52] <ogra_> /etc/systemd/system.conf.d              auto                    persistent  transition  none
[08:52] <ogra_> /etc/systemd/user.conf.d                auto                    persistent  transition  none
[08:52] <ogra_> we need to rip it out there indeed
[08:53] <mvo> ogra_: its also not in /snap/ubuntu-core/current/etc/systemd/system/multi-user.target.wants hm, hm
[08:53] <ogra_> mvo, yeah, thats a mess ... we bind mount the dir twice
[08:53] <ogra_> once from initrd, once from fstab
[08:53] <ogra_> that cant work
[08:53] <mvo> ogra_: well, if its not in the pristine ubuntu-core snap, something is wrong in the livecd-rootfs install, no?
[08:54] <ogra_> 	# Mount the systemd overlay so that we have a complete root partition during boot
[08:54] <ogra_> 	mkdir -p "${rootmnt}/writable/system-data/etc/systemd/system"
[08:54] <ogra_> 	mount -o bind "${rootmnt}/writable/system-data/etc/systemd/system" "${rootmnt}/etc/systemd/system"
[08:54] <ogra_> from the initrd
[08:54] <pitti> if [ "$1" = configure ] && [ -z "$2" ]; then
[08:54] <pitti>     echo "First installation detected..."
[08:54] <pitti> ^ do you have that line in the image build log?
[08:54]  * ogra_ checks https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/4472
[08:55] <pitti> yep
[08:55] <ogra_> Setting up libnss-myhostname:armhf (229-4ubuntu7) ...
[08:55] <ogra_> First installation detected...
[08:55] <ogra_> seems so
[08:55] <pitti> and it also shows update-rc.d
[08:55] <ogra_> Setting up libnss-myhostname:armhf (229-4ubuntu7) ...
[08:55] <ogra_> First installation detected...
[08:55] <ogra_> twice
[08:55] <pitti> also from linbnss-resolve
[08:55] <pitti> (the other is from -myhostname)
[08:55] <pitti> so that should have created the symlink
[08:55] <ogra_> oops, yeah, wrong paste
[08:56] <pitti> oh, and as it added it to nsswitch.conf it must have run
[08:56] <ogra_> right, but the code above doesnt copy anything
[08:56] <ogra_> it blindly bind mounts
[08:56] <ogra_> then adds it to fstab
[08:56] <ogra_> then writable-paths tries to copy something but doesnt find anything
[08:56] <ogra_> i guess
[08:57] <ogra_> we need copy code in the initrd and remove the dir from writable-paths
[08:58] <ogra_> hmm
[08:59] <ogra_> thats a bit tricky ... we actually want to copy from the squashfs ...
[09:01] <ogra_> oh, fun !
[09:01] <ogra_> 138                         # mount all /etc dirs right now, not later when fstab is
[09:01] <ogra_> 139                         # processed, as it will cause races.
[09:01] <ogra_> 140                         case $1 in
[09:01] <ogra_> 141                             /etc*)
[09:01] <ogra_> 142                                 [ -d "${rootmnt}/writable/system-data/$1" ] || mkdir -p "${rootmnt}/writable/system-data/$1"
[09:01] <ogra_> 143                                 mount -o bind "${rootmnt}/writable/system-data/$1" "${rootmnt}/$1"
[09:01] <ogra_> 144                                 ;;
[09:01] <ogra_> 145                             *)
[09:01] <ogra_> pitti, so your etc code *is* in the initred
[09:01] <ogra_> *initrd
[09:01] <pitti> what is "my etc code"?
[09:02] <pitti> you mean systemd-resolved.service  enablement symlink?
[09:02] <ogra_> pitti, the code we talked about yesterday
[09:02] <ogra_> all of /etc is bind mounted from initrd
[09:02] <pitti> ah, for setting up /etc in the initrd?
[09:03] <pitti> I thought you said /writable was now spelled /
[09:03] <ogra_> after the initrd, yes
[09:03] <pitti> (I do remember that code, but it was from touch times)
[09:05] <ogra_> but it only bind mounts ... doesnt look like it copies existing content from the target
[09:05] <ogra_> which would explain why we miss the files/links
[09:07] <ogra_> oh
[09:07] <ogra_> mvo, do you use a working model assertion ?
[09:07] <ogra_> ogra@localhost:~$ ls /snap/
[09:07] <ogra_> ogra@localhost:~$
[09:07] <ogra_> ...
[09:11] <ogra_> ogra@localhost:~$ sudo mount -o loop /var/lib/snapd/snaps/ubuntu-core_483.snap /mnt/
[09:11] <ogra_> ogra@localhost:~$ ls /mnt/etc/systemd/system/multi-user.target.wants/
[09:11] <ogra_> cgmanager.service  cron.service        pppd-dns.service  rsyslog.service        snapd.firstboot.service  ssh.service
[09:11] <ogra_> cgproxy.service    networking.service  remote-fs.target  snapd.boot-ok.service  snapd.service            ubuntu-fan.service
[09:11] <ogra_> ogra@localhost:~$
[09:11] <ogra_> hmm, yeah, it is definitely missing here too
[09:12] <ogra_> pitti, so what would create the systemd-resolved.service symlink ?
[09:12] <ogra_> normally
[09:12] <pitti> ogra_: libnss-resolve.postinst → systemctl enable systemd-resolved
[09:12] <ogra_> and that works inside chroots ?
[09:12] <ogra_> systemctl i mean
[09:12] <pitti> it should, let me check
[09:13] <pitti> Setting up libnss-resolve:amd64 (231-4ubuntu1) ...
[09:13] <pitti> First installation detected...
[09:13] <pitti> Checking NSS setup...
[09:13] <pitti> Created symlink /etc/systemd/system/multi-user.target.wants/systemd-resolved.service → /lib/systemd/system/systemd-resolved.service.
[09:13] <pitti> (in a yakkety schroot)
[09:13] <pitti> but this "Created symlink.." is missing from the image build log
[09:13] <ogra_> hmm, we dont get that much output
[09:13] <ogra_> the log stops at First installation detected...
[09:14] <ogra_> err
[09:14] <ogra_> at the NSS line actually
[09:14] <ogra_> Setting up libnss-resolve:armhf (229-4ubuntu7) ...
[09:14] <ogra_> First installation detected...
[09:14] <ogra_> Checking NSS setup...
[09:14] <ogra_> Setting up watchdog (5.14-3ubuntu0.16.04.1) ...
[09:14] <pitti> yes, as nsswitch.conf gets updated
[09:14] <ogra_> i dont see the "Created symlink"
[09:16] <ogra_> (the fun question here is, why does name resolution work in console-conf (it downloads the ssh key from LP just fine)
[09:16] <ogra_> )
[09:16] <pitti> because nss-resolve
[09:16] <pitti> or wait, the daemon isn't running
[09:16] <ogra_> and why doesnt it work after console-conf then ?
[09:16] <nhaines> kyrofa: I was poking at Nextcloud quite a bit, and I think it's time to upgrade my cloud server.  But the snap is really out of date.  Do you have any plans for that or should I roll my own?  Also, should I complain really loudly that upstream didn't accept your patcH?
[09:22] <fgimenez> ogra_, here it works for a while and after some time it stops working, the name resolution is lost http://paste.ubuntu.com/23140676/
[09:23] <ogra_> pitti, i dont see any code in the debian dir of the currenmt systemd package that would call "enable systemd-resolved.service"
[09:23] <pitti> ogra_: debian/libnss-resolve.postinst
[09:23] <ogra_> wheer should that run ...
[09:24] <pitti> the insert_nss_entry did run
[09:24] <ogra_> pitti, well, either i'm blind or that isnt there
[09:24] <ogra_> right
[09:24] <ogra_> but not the enable
[09:24]  * pitti blinks -- it's right there..
[09:24] <pitti> ogra_: oh! xenial?
[09:25] <ogra_> pitti, http://paste.ubuntu.com/23140681/
[09:25] <pitti> I'm looking at yakkety, we started https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-local-resolver in yakkety only
[09:25] <ogra_> thast what i see looking at the source of the systemd package
[09:25] <ogra_> right ... so thats our issue i guess
[09:26] <pitti> ok, that explains it; should have thought about that earlier
[09:27] <ogra_> do you want to fix it in systemd or should i add a livecd-rootfs hook ?
[09:27] <pitti> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=62d8aa9f5
[09:27] <pitti> the starting is irrelevant for chroots, just live systems
[09:27] <pitti> ogra_: I can SRU it if that doesn't block you for too long
[09:27] <ogra_> it might ...
[09:28] <ogra_> mvo, ^^^ opinion ?
[09:28] <pitti> in the meantime, you can add a "systemctl enable systemd-resolved.service" after installing libnss-resolve to the image build scripts
[09:28] <ogra_> right
[09:28] <mvo> ogra_: let me re-read, was distracted
[09:28] <pitti> and point to the SRU bug to drop it again once it's fixed
[09:28] <ogra_> yeah
[09:28] <ogra_> let me add it as a temp solution
[09:28] <pitti> oh wait
[09:28] <pitti> there's more to it
[09:29] <pitti> you also wouldn't have /lib/systemd/system/systemd-resolved.service.d/resolvconf.conf in xenial
[09:29] <pitti> and a few fixes to resolved itself
[09:29] <ogra_> oh my
[09:29] <pitti> so hold your horses please, using resolved in xenial isn't what we can do very easily
[09:30] <ogra_> well, luckily release is on thu. only :P
[09:30]  * ogra_ grins
[09:30] <pitti> (and remove nss-resolve from the image build scripts again)
[09:30] <ogra_> hahahaha
[09:30] <pitti> Ubuntu == devel series for me :)
[09:31] <mvo> pitti: if we can get it into the ppa:snappy-dev/image that would unblock us
[09:31] <pitti> hm, I thought I had a resolveconf hook in networkd on xenial
[09:31] <ogra_> thats pretty gross though :)
[09:31] <mvo> oh, ok, so revert this again
[09:31] <mvo> hm,
[09:31] <ogra_> (using the PPA for a whole init system backport i mean)
[09:31] <pitti> nonono
[09:31] <mvo> so what is the best bet for working resolv.conf for us?
[09:32] <pitti> mvo: let me check/think about this for a sec
[09:32] <pitti> I'm just done being tvoss' slave for systemd on 14.04 for snapd, so now I can be your's :)
[09:32] <mvo> yay
[09:32]  * mvo cracks the wip
[09:32] <mvo> and the whip as well
[09:33] <ogra_> lol
[09:33] <ogra_> dont crack the WIP on purpose ... we do that enough already by accident
[09:34] <pitti> so yeah, we didn't integrate networkd on xenial at all yet
[09:34] <pitti> all the resolver/networkd/netplan work went into y only
[09:35] <pitti> oh, wrong, we already do have systemd-networkd-resolvconf-update.{path,service}
[09:36] <ogra_> oh ... another fun fact ...
[09:36] <ogra_> ogra@localhost:~$ sudo systemctl enable systemd-resolved.service
[09:36] <ogra_> Created symlink from /etc/systemd/system/multi-user.target.wants/systemd-resolved.service to /lib/systemd/system/systemd-resolved.service.
[09:36] <ogra_> ogra@localhost:~$ ls /mnt/etc/systemd/system/multi-user.target.wants/
[09:36] <ogra_> cgmanager.service  cron.service        pppd-dns.service  rsyslog.service        snapd.firstboot.service  ssh.service
[09:36] <ogra_> cgproxy.service    networking.service  remote-fs.target  snapd.boot-ok.service  snapd.service            ubuntu-fan.service
[09:36] <ogra_> ogra@localhost:~$
[09:37] <ogra_> hmm, perhaps i should look in the right dir ... ignore that
[09:37] <ogra_> it is there as it should ...
[09:37]  * ogra_ reboots to see what happens
[09:37] <pitti> mvo, ogra_: is systemd-networkd-resolvconf-update.path running for you?
[09:38] <ogra_> where do i find out ?
[09:38] <pitti> systemctl status systemd-networkd-resolvconf-update.path
[09:38] <mvo> pitti:  Active: active (waiting)
[09:38] <pitti> ack, good
[09:38] <pitti> mvo: sudo systemctl status systemd-networkd-resolvconf-update.service ?
[09:38] <pitti> did it ever run?
[09:38] <ogra_> here too ... though note that i just ran "sudo systemctl enable systemd-resolved.service" before the reboot
[09:39] <pitti> ogra_: yeah, should be unrelated
[09:39] <ogra_> ogra@localhost:~$  systemctl status systemd-networkd-resolvconf-update.path
[09:39] <ogra_> ● systemd-networkd-resolvconf-update.path - Trigger resolvconf update for networkd DNS
[09:39] <ogra_>    Loaded: loaded (/lib/systemd/system/systemd-networkd-resolvconf-update.path; static; vendor preset: enabled)
[09:39] <ogra_>    Active: active (running) since Tue 2016-09-06 08:24:29 UTC; 21s ago
[09:39] <pitti> (also, please undo any resolved stuff on your image)
[09:39]  * ogra_ disbales and reboots again
[09:40] <ogra_> *disables
[09:40]  * ogra_ praises mvo again for disabling cloud-init ... the first time i see reasonable boot times on arm
[09:41] <ogra_> ogra@localhost:~$ systemctl status systemd-networkd-resolvconf-update.path
[09:41] <ogra_> ● systemd-networkd-resolvconf-update.path - Trigger resolvconf update for networkd DNS
[09:41] <ogra_>    Loaded: loaded (/lib/systemd/system/systemd-networkd-resolvconf-update.path; static; vendor preset: enabled)
[09:41] <ogra_>    Active: active (waiting) since Tue 2016-09-06 08:25:28 UTC; 37s ago
[09:41] <ogra_> ogra@localhost:~$
[09:41] <ogra_> after reboot
[09:41] <ogra_> ogra@localhost:~$ ping web.de
[09:41] <ogra_> ping: unknown host web.de
[09:41] <ogra_> ogra@localhost:~$
[09:41] <pitti> I took a xenial VM, added a network config, removed it from ifupdown, and /etc/resolv.conf has my nameserver
[09:41] <pitti> hmm
[09:42] <pitti> ogra_: systemctl status systemd-networkd-resolvconf-update.service
[09:42] <ogra_> pitti, without a running systemd-resolved.service ?
[09:42] <pitti> ogra_: yes
[09:42] <pitti> plain OOTB xenial cloud image
[09:43] <ogra_> ogra@localhost:~$ systemctl status systemd-networkd-resolvconf-update.service
[09:43] <ogra_> ● systemd-networkd-resolvconf-update.service - Update resolvconf for networkd DNS
[09:43] <ogra_>    Loaded: loaded (/lib/systemd/system/systemd-networkd-resolvconf-update.service; static; vendor preset: enabled)
[09:43] <ogra_>    Active: inactive (dead) since Tue 2016-09-06 08:26:00 UTC; 1min 37s ago
[09:43] <ogra_>   Process: 2608 ExecStart=/bin/sh -c for timeout in `seq 30`; do out=$(sed -n "/^DNS=/ { s/^DNS=/nameserver /; p}" /run/systemd/netif/state); [ -z "$out" ]
[09:43] <ogra_>  Main PID: 2608 (code=exited, status=0/SUCCESS)
[09:43] <pitti> oh, so it did run
[09:43] <pitti> grep DNS /run/systemd/netif/state
[09:43] <ogra_> ogra@localhost:~$ cat /run/systemd/netif/state
[09:43] <ogra_> # This is private data. Do not parse.
[09:43] <ogra_> OPER_STATE=routable
[09:43] <ogra_> ogra@localhost:~$
[09:43] <pitti> le huh, no DNS server through DHCP?
[09:44] <pitti> none in "networkctl status" either, I assume?
[09:44] <ogra_> ogra@localhost:~$ networkctl status
[09:44] <ogra_> ●        State: routable
[09:44] <ogra_>        Address: 192.168.2.22 on enxb827eb04db1c
[09:44] <ogra_>                 fe80::ba27:ebff:fe04:db1c on enxb827eb04db1c
[09:44] <ogra_>        Gateway: 192.168.2.1 (DrayTek Corp.) on enxb827eb04db1c
[09:44] <pitti> I have "DNS: 10.0.2.3" here
[09:44] <pitti> ok, so that's not at all the direction I was suspecting
[09:45] <pitti> mvo: does "networkctl status" show a "DNS:" for you?
[09:45] <ogra_> on my desktop i dont have DNS in there either
[09:45] <ogra_> (though i guess that doesnt tell anything ... NM manages the network there)
[09:45] <pitti> ogra_: supposedly you use NM there and networkd isn't even running
[09:45] <pitti> yes
[09:46] <pitti> "journalctl -t systemd-networkd" SVP
[09:46] <ogra_> ogra@wall2:~$ grep domain-name-servers /etc/dhcp/dhcpd.conf
[09:46] <ogra_> option domain-name-servers 217.237.150.115, 217.237.151.205;
[09:46] <ogra_> #  option domain-name-servers ns1.internal.example.org;
[09:46] <ogra_> ogra@wall2:~$
[09:46] <ogra_> thats what my DHCP should provide
[09:47] <pitti> "grep -r DNS= /run/systemd/netif" -> nothing there?
[09:47] <ogra_> http://paste.ubuntu.com/23140773/
[09:47] <ogra_> ogra@localhost:~$ grep -r DNS= /run/systemd/netif
[09:47] <ogra_> ogra@localhost:~$
[09:47] <ogra_> bah
[09:47] <pitti> ok, so DHCP was received, but no name servers
[09:47] <ogra_> i hate IRC and slashes !
[09:48] <ogra_> ogra@localhost:~$ grep -r DNS= /run/systemd/netif
[09:48] <ogra_> /run/systemd/netif/leases/3:DNS=217.237.150.115 217.237.151.205
[09:48] <ogra_> /run/systemd/netif/links/3:DNS=217.237.150.115 217.237.151.205
[09:48] <ogra_> /run/systemd/netif/links/3:MDNS=no
[09:48] <ogra_> ogra@localhost:~$
[09:48] <pitti> ah!
[09:48] <ogra_> IRC swallows lines that startz with slash
[09:48] <ogra_> nothing in tehj journalctl output though+
[09:49] <pitti> yes, so my awful shell hack in /lib/systemd/system/systemd-networkd-resolvconf-update.service is not working
[09:49] <pitti> it's fortunately gone in y, but not yet in x
[09:50] <ogra_> but given that just enabling systemd-resolved.service works, what would be the issue with that ?
[09:50] <ogra_> as a workaround at least
[09:51] <pitti> ogra_: well, in xenial resolved still has a number of bugs and crashes, I wouldn't recommend it yet
[09:51] <ogra_> k
[09:51] <pitti> works for simple cases, but we got reports about problems with DNSSEC or domains which are only served by particular interfaces etc.
[09:51] <nhaines> pitti: would you say those bugs haven't not yet been resolved?
[09:52] <pitti> some of them have, but there is still a privacy issue in y open that's on my list
[09:52] <ogra_> nhaines, no, he hasnt resolved the resolved bugs yet
[09:53] <ogra_> pitti, well, i think we could live with a few bugs for RTM if we know it will be fixed by final release
[09:53] <pitti> ogra_: can you please file a bug with the symptom (missing DNS in /etc/resolv.conf) and the output of the above grep? against systemd? (for SRUing)
[09:53] <pitti> ogra_: I can give you an instant fix for the image build, and we SRU the proper fix
[09:54] <ogra_> pitti, yeah
[09:54] <pitti> ogra_: can you please edit /lib/systemd/system/systemd-networkd-resolvconf-update.service:
[09:54] <pitti> ExecStart=/bin/sh -c 'for timeout in `seq 30`; do out=$(sed -n "/^DNS=/ { s/^DNS=/nameserver /; p}" /run/systemd/netif/state /run/systemd/netif/leases/* | sort -u); [ -z "$out" ] || break; sleep 1; done; echo "$out" | /sbin/resolvconf -a networkd'
[09:54] <pitti> ogra_: if it's readonly, copy it to /etc/systemd/system/ and edit it there
[09:55] <ogra_> reboot ?
[09:56]  * ogra_ reboots
[09:57] <pitti> ogra_: sure, that or restart the network, but reboot should work
[09:57] <ogra_> ogra@localhost:~$ ping web.de
[09:57] <ogra_> PING web.de (82.165.230.17) 56(84) bytes of data.
[09:57] <ogra_> 64 bytes from bap.web.de (82.165.230.17): icmp_seq=1 ttl=248 time=17.0 ms
[09:57] <ogra_> ^C
[09:57] <ogra_> \o/
[09:58] <ogra_> so i guess just dumping the file into /etc/systemd/system from livecd-rootfs is the quick fix for us
[09:58] <ogra_> hmm
[09:58] <pitti> ogra_: ok, great; can you please file that bug and add some seddery to the image build scripts until then?
[09:58] <ogra_> or not ... better to only change it in the readonly side
[09:58] <pitti> ogra_: TBH I'd sed it in /lib; having files in /etc in writable is hard to upgrade from
=== JanC_ is now known as JanC
[09:58] <ogra_> pitti, yeah
[09:59] <ogra_> so the last network bit is ... why do i get a different ip on first boot ... (or why do i get one at all)
[10:00] <pitti> ogra_: sed -i '/^ExecStart=/ s!netif/state!& /run/systemd/netif/leases/* | sort -u!' /lib/systemd/system/systemd-networkd-resolvconf-update.service
[10:00] <ogra_> i guess the NIC should not even go up when console-conf hasnt run yet
[10:00] <ogra_> pitti, ok
[10:00] <pitti> ogra_: I think during firstboot there is some catch-all policy that tries to run DHCP on every interface
[10:00] <pitti> ogra_: do you have more than one?
[10:01] <ogra_> ogra@localhost:~$ cat /proc/net/dev
[10:01] <ogra_> Inter-|   Receive                                                |  Transmit
[10:01] <ogra_>  face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
[10:01] <ogra_>   sit0:       0       0    0    0    0     0          0         0        0       0    0    0    0     0       0          0
[10:01] <ogra_> enxb827eb04db1c:   34780     336    0    0    0     0          0         0    17005     118    0    0    0     0       0          0
[10:01] <pitti> ogra_: hypothesis: you have two, you get two DHCP responses, and the other one gets a response/the IP first
[10:01] <ogra_>     lo:   25600     320    0    0    0     0          0         0    25600     320    0    0    0     0       0          0
[10:01] <ogra_> only one
[10:02] <ogra_> but yeah, i see the dhcp request before the system even gets to console-conf
[10:02] <pitti> hm, what does that then
[10:02] <pitti> I thought console-conf woudl isntall that default policy, but apparently not then
[10:02] <ogra_> there must be some other default thing
[10:03] <ogra_> which we priobably want to disable
[10:03] <pitti> some firstboot something presumably (I hope that defualt policy goes away after console-conf
[10:03] <ogra_> well, the IP stays after second boot
[10:03] <pitti> I've seen some "match: { name: "en*" } dhcp4: true" thing somewhere
[10:03] <ogra_> udev ?
[10:04] <pitti> no, snappy specific
[10:04] <ogra_> hmm
[10:04] <ogra_> note that on this system specifically the snappy firstboot stuff doesnt run
[10:04] <ogra_> still broken here
[10:04] <ogra_> so i doubt it is that
[10:05] <pitti> ogra_: https://github.com/snapcore/snapd/pull/1830/files
[10:05] <mup> PR snapd#1830: firstboot: only configure en* and eth* interfaces by default <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1830>
[10:05] <pitti> thta's what I've seen recently
[10:05] <ogra_> i thought it was cloud-init ... but that is also gone in the current image
[10:05] <pitti>  firstboot/firstboot.go
[10:05] <pitti> thus presumably the snappy.firstboot.service thing
[10:05] <ogra_> right
[10:05] <ogra_> doesnt run
[10:05] <ogra_> [  OK  ] Started OpenBSD Secure Shell server.
[10:05] <ogra_>          Stopping Network Service...
[10:05] <ogra_> [  OK  ] Stopped Network Service.
[10:05] <ogra_>          Starting Network Service...
[10:05] <ogra_> [FAILED] Failed to start Run snappy firstboot setup.
[10:05] <ogra_> See 'systemctl status snapd.firstboot.service' for details.
[10:05] <pitti> ogra_: check if it does run when console-conf is active?
[10:05] <ogra_> [  OK  ] Started Network Service.
[10:05] <ogra_> it never runs
[10:05] <pitti> so it did run
[10:06] <pitti> (failed, sure, but that stil means it could have written the default policy before it failed)
[10:06]  * mwhudson blinks
[10:06] <ogra_> (it cant because i dont have a proper model assertion)
[10:06] <ogra_> mvo, ^^^
[10:06] <mwhudson> ogra_: snapd.firstboot.service does two things, the first is writing /etc/netplan/01-snapd-config.yaml, the second is the thing that fails
[10:06] <mwhudson> i'm fairly sure
[10:06] <ogra_> could indeed be that the model assertion check is only at the end or some such
[10:07] <pitti> uh, is that still in /etc?
[10:07] <pitti> this really belongs into /run and removed ASAP
[10:07] <ogra_> ogra@localhost:~$ ls /etc/netplan/
[10:07] <ogra_> 00-snapd-config.yaml
[10:07] <ogra_> ogra@localhost:~$
[10:07] <mwhudson> pitti: console-conf overwrites it
[10:07] <ogra_> sadly i cant check what is in there before console-conf
[10:07] <ogra_> because we dont have the ubuntu user anymore
[10:07] <ogra_> i cant get in
[10:07] <pitti> ogra_: systemd.debug-shell
[10:08] <pitti> Ctrl+Alt+F9
[10:08] <ogra_> on serial console ?
[10:08] <pitti> hm, that's tricky indeed :)
[10:08] <ogra_> heh
[10:08] <mwhudson> jtag!
[10:09]  * mwhudson unhelpfuls
[10:09] <ogra_> well, if we are sure thats the issue, mvo could just rip that out of firstboot.go i guess
[10:09] <pitti> we need a secret "escape to shell" key in console-conf, clearly :)
[10:09] <zyga> o/
[10:09]  * zyga needs a review on https://github.com/snapcore/snap-confine/pull/125
[10:09] <mup> PR snap-confine#125: Combine mount namespace setup into one function <Created by zyga> <https://github.com/snapcore/snap-confine/pull/125>
[10:09] <ogra_> sounds like it needs to go anywway
[10:09] <pitti> ogra_: no, I'm not sure at all
[10:09] <pitti> with just one NIC there is no reason why the DUID should be different on first boot
[10:09] <zyga> mwhudson: wanna look?
[10:09] <pitti> (and received IP)
[10:10] <zyga> mwhudson: this is just prep work for upcoming mount namespace sharing
[10:10] <ogra_> pitti, well, if one runs dhclient and the other runs networkd ...
[10:10] <pitti> unless something calls dhclient manually, instead of networkd
[10:10] <ogra_> *snap* :)
[10:10] <pitti> but why would it install a netplan policy and then run dhclient?
[10:10] <mwhudson> zyga: i want to go to bed unfortunately
[10:10]  * zyga was about to ping _morphis about it
[10:10] <zyga> mwhudson: sure, no worries :)
[10:10] <zyga> mwhudson: I was surprised to see you up so late
[10:10]  * ogra_ needs to take care of the cats ... back in 10 or so
[10:10] <zyga> _morphis: ^^ how about you?
[10:10] <mwhudson> ogra_, pitti: uh is there a /etc/network/interfaces as well or something like that?
[10:11] <ogra_> mwhudson, nothing in it though
[10:11] <pitti> no interfaces.d/ either?
[10:11] <mwhudson> ok good
[10:11] <ogra_> unless netplan actually wipes it
[10:11] <zyga> ssweeny: or you perhaps?
[10:11] <pitti> no, it doesn't, that would be rude
[10:11] <mwhudson> not unless you ask it to, and we don't
[10:11] <ogra_> ogra@localhost:~$ cat /etc/network/interfaces.d/
[10:11] <ogra_> cat: /etc/network/interfaces.d/: Is a directory
[10:11] <ogra_> ogra@localhost:~$ ls /etc/network/interfaces.d/
[10:11] <ogra_> ogra@localhost:~$
[10:11] <ogra_> err
[10:12] <ogra_> ogra@localhost:~$ cat /etc/network/interfaces
[10:12] <ogra_> # interfaces(5) file used by ifup(8) and ifdown(8)
[10:12] <ogra_> # Include files from /etc/network/interfaces.d:
[10:12] <ogra_> source-directory /etc/network/interfaces.d
[10:12] <pitti> SLASH SLASH
[10:12] <ogra_> ogra@localhost:~$
[10:12] <pitti> (oh, I thought it was hiding the ls results again)
[10:12]  * ogra_ -> cats ... else my ears blow up
[10:13]  * mwhudson crashes
[10:14]  * pitti off to running and lunch, bbl
[10:18] <mvo> ogra_: firstboot runs correctly but it fails to stamp for some reason, was looking into this
[10:21] <ogra_> mvo, ah, k, i thought that was the assertion thing still
[10:21] <mvo> ogra_: I don't know why it fails on pi2, it works on kvm(the firstbot stamp)
[10:21] <didrocks> mvo: hum, is it known that snap revert doesn't restore the apparmor profile as it should?
[10:21] <mvo> ogra_: but snap list works, right? if that works and shows snaps then the firstboot stuff worked
[10:21] <ogra_> mvo, nope
[10:22] <mvo> didrocks: definitely not
[10:22] <didrocks> even if the snap was installed in devmode, it's not restored
[10:22] <ogra_> snap list doesnt work and i see nothing in /snap
[10:22] <didrocks> installed a snap
[10:22] <mvo> ogra_: oh, snap changes?
[10:22] <didrocks> upgraded
[10:22] <didrocks> snap revert
[10:22] <mvo> ogra_: snap change 1?
[10:22] <didrocks> Sep  6 12:21:28 tidus kernel: [16442.393449] audit: type=1400 audit(1473157288.721:3153): apparmor="DENIED" operation="open" profile="snap.face-detection.service" name="/dev/video0" pid=23620 comm="face-detection-" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[10:22] <didrocks> which was allowed before ^
[10:22] <ogra_> ogra@localhost:~$ snap changes
[10:22] <ogra_> error: no changes found
[10:22] <ogra_> ogra@localhost:~$ snap change 1
[10:22] <ogra_> error: cannot find change with id "1"
[10:22] <ogra_> ogra@localhost:~$
[10:22] <mvo> ogra_: sudo systemctl status snapd.firstboot.service
[10:23] <ogra_> mvo, http://paste.ubuntu.com/23140968/
[10:23] <zyga> morphis: hey
[10:23] <zyga> morphis: around?
[10:24] <morphis> zyga: yes
[10:24] <mvo> ogra_: could you pastebin /var/lib/snapd/state.json please? you have not logged into this system yet, right? snap login was not run? because if so, don't pastebin it will contain credentials
[10:26] <ogra_> {"data":{"patch-level":3},"changes":{},"tasks":{},"last-change-id":0,"last-task-id":0}
[10:26] <zyga> morphis: https://github.com/snapcore/snap-confine/pull/125
[10:26] <mup> PR snap-confine#125: Combine mount namespace setup into one function <Created by zyga> <https://github.com/snapcore/snap-confine/pull/125>
[10:26] <ogra_> mvo, thats all
[10:26] <ogra_> mvo, and i have run console-config indeed
[10:27] <zyga> morphis: just small reorg/cleanup so that all the essential mount stuff happens in a spot that is easy to work with once mount namespace sharing shows up
[10:27] <morphis> zyga: ok, but this doesn't fix the problem with one snap mount sth in /media, right?
[10:28] <ogra_> pitti, bug 1620559 for you
[10:28] <mup> Bug #1620559: /etc/resolv.conf is empty on snappy <Snappy:New> <systemd (Ubuntu):New> <https://launchpad.net/bugs/1620559>
[10:29] <zyga> morphis: nope, this is just a cleanup thing
[10:30] <mup> Bug #1620559 opened: /etc/resolv.conf is empty on snappy <Snappy:New> <systemd (Ubuntu):New> <https://launchpad.net/bugs/1620559>
[10:30] <zyga> morphis: I had a look at the code and I have an idea
[10:30] <zyga> morphis: I need to investigate it a little further though
[10:30] <morphis> zyga: ok
[10:30] <didrocks> mvo: is that enough info for you? https://bugs.launchpad.net/snappy/+bug/1620560
[10:30] <mup> Bug #1620560: Revert command doesn't reset the right apparmor profile <amd64> <apport-bug> <xenial> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1620560>
=== morphis82 is now known as morphis
[10:31]  * didrocks won't again be able to demo revert next week it seems :/
=== hikiko is now known as hikiko|ln
[10:33] <mup> Bug #1620560 opened: Revert command doesn't reset the right apparmor profile <amd64> <apport-bug> <xenial> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1620560>
[10:34] <mvo> didrocks: should be, I will look in a wee bit
[10:35] <didrocks> thx!
[10:35] <ogra_> mvo, fix for DNS uploaded ... i'll trigger new ubuntu-core snaps once livecd-rootfs finished
[10:36] <ogra_> mvo, so should i try to delete the state file and reboot to see what firstboot creates then ?
[10:37] <mvo> ogra_: please do
[10:37] <mvo> ogra_: another showstopper :/
[10:37] <didrocks> mvo: FYI, I try to reload in unconfined mode the profile, but still doesn't work:
[10:37] <didrocks> Sep  6 12:36:33 tidus kernel: [17346.954285] audit: type=1400 audit(1473158193.260:3432): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.face-detection.service" pid=25891 comm="apparmor_parser"
[10:37] <didrocks> restarting the service
[10:37] <didrocks> Sep  6 12:36:54 tidus kernel: [17368.030680] audit: type=1400 audit(1473158214.336:3433): apparmor="DENIED" operation="open" profile="snap.face-detection.service" name="/sys/bus/usb/devices/" pid=25900 comm="face-detection-" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[10:37] <didrocks> (and others like /dev/video0…)
[10:37] <ogra_> mvo, also, how do i use the model assertion now ? i'm still building with the local one
[10:37] <didrocks> so can be something wrong in the profile resetted
[10:38] <ogra_> you said you have one for the pi ?
[10:38] <ogra_> ogra@localhost:~$ sudo systemctl status snapd.firstboot.service
[10:38] <ogra_> ● snapd.firstboot.service - Run snappy firstboot setup
[10:38] <ogra_>    Loaded: loaded (/lib/systemd/system/snapd.firstboot.service; enabled; vendor preset: enabled)
[10:38] <ogra_>    Active: failed (Result: exit-code) since Tue 2016-09-06 08:27:33 UTC; 11s ago
[10:38] <ogra_>   Process: 2431 ExecStart=/usr/bin/snap firstboot (code=exited, status=1/FAILURE)
[10:38] <ogra_>  Main PID: 2431 (code=exited, status=1/FAILURE)
[10:38] <ogra_> Sep 06 08:27:27 localhost.localdomain systemd[1]: Starting Run snappy firstboot setup...
[10:38] <ogra_> Sep 06 08:27:33 localhost.localdomain snap[2431]: error: need a model assertion
[10:38] <ogra_> ...
[10:38] <ogra_> mvo, ^^^^
[10:39] <mvo> ogra_: uhh
[10:39] <mvo> ogra_: ls /var/lib/snapd/seed/assertions ?
[10:39] <ogra_> well, the image was built with the locally hacked together assertion
[10:39] <mvo> ogra_: is that your locally build image ;) or one from me?
[10:39] <mvo> ogra_: ha!
[10:39] <ogra_> and with that env var set
[10:39] <mvo> ogra_: that explains it all
[10:39] <ogra_> ok
[10:39] <mvo> ogra_: yeah, you need the real one, check msg
[10:40] <ogra_> mvo, can i hack that up for pi3 and dragonbaord ro do we need them created
[10:40] <ogra_> *or
[10:41] <ogra_> mvo, also, i guess i shouldnt set UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL=1 anymore ?
[10:42] <mvo> ogra_: well, I can send you one (untested) for the dragonboard, but for pi3 we need to create a new one, that is a bit involving because it needs a special signature
[10:42] <ogra_> oh, why is that different ?
[10:48] <mvo> ogra_: we have no signed model assertion for that yet
[10:48] <ogra_> k
[10:49] <zyga> didrocks: hey
[10:49] <zyga> didrocks: about https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1620560
[10:49] <mup> Bug #1620560: Revert command doesn't reset the right apparmor profile <amd64> <apport-bug> <xenial> <Snappy:In Progress by zyga> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1620560>
[10:49] <zyga> didrocks: do you have the system that had this issue
[10:49] <zyga> didrocks: can you pastebin snap changes please
[10:49] <zyga> didrocks: or add it to the bug report
[10:49] <zyga> didrocks: and then "snap change 123" where 123 are some interesting events (like revert)
[10:52] <ogra_> mvo, so now my console-conf hangs at "Contacting store ..."
[10:52] <ogra_> i assume it is supposed to eventually do something ? (sits there since 5 min now)
[10:52] <ogra_> oh
[10:52] <ogra_> now i get an errtor
[10:53] <ogra_>         error: bad user result: cannot create user "ogra@ubuntu.com": Get
[10:53] <ogra_>     https://login.ubuntu.com/api/v2/keys/ogra%40ubuntu.com: dial tcp: lookup
[10:53] <ogra_>                          login.ubuntu.com: no such host
[10:53] <ogra_> hah
[10:53] <ogra_> DNS
[10:53] <mvo> ogra_: yeah, no dns
[10:53] <ogra_> damn
[10:53]  * ogra_ waits for livecd-rootfs to finish 
[10:53] <mvo> ogra_: lets wait for your fix and hope that that was really all we needed
[10:53]  * mvo lunch
[10:53] <ogra_> well, i guess i can hack the SD
[10:55] <ogra_> ah, crap ... not as easy ...
[10:59] <ogra_> bah .... and now my serial is messed up
[11:00] <ogra_> \o/
[11:00] <ogra_> ogra@localhost:~$ snap list
[11:00] <ogra_> Name         Version       Rev  Developer  Notes
[11:00] <ogra_> pi2          16.04-0.15    25   canonical  -
[11:00] <ogra_> pi2-kernel   4.4.0-1021-2  12   canonical  -
[11:00] <ogra_> ubuntu-core  16.04.1       483  canonical  -
[11:00] <ogra_> ogra@localhost:~$
[11:00] <ogra_> mvo, works !!
[11:01]  * ogra_ installs classic
[11:02] <ogra_> Processing triggers for libc-bin (2.23-0ubuntu3) ...
[11:02] <ogra_> (classic)ogra@localhost:~$
[11:02] <ogra_> whee !
[11:02] <zyga> didrocks: ?
[11:03] <zyga> morphis: any chance for that review?
[11:03] <zyga> morphis: if no I'd like to know now so that I can merge it and iterate
[11:11] <ogra_> hmm
[11:12] <ogra_>           error: bad user result: cannot communicate with server: Post
[11:12] <ogra_>        http://localhost/v2/create-user: dial unix /run/snapd-snap.socket:
[11:12] <ogra_>                        connect: no such file or directory
[11:12] <ogra_> thats not so good i suppose
[11:12] <ogra_> wow
[11:13] <ogra_> so putting something into writable/system-data/etc/systemd/ will not get me any units in there after first boot
[11:16] <pitti> ogra_: thanks for the bug report, will prep/upload SRU later (I have a few other things queued anyway)
[11:16] <ogra_> yeah, no hurry (if the workaround works at least)
[11:17] <pitti> ogra_: well, the workaround is the fix, it just needs to get into the package properly :)
[11:17] <ogra_> (and if the PPA publisher ever publishes livecd-rootfs i can actually test it :P )
[11:18] <ogra_> damn ...
[11:19] <ogra_> hacking up the image definitely doesnt work
[11:19] <ogra_> now firstboot fails again
[11:19] <jgdx> didrocks, hey, how do I debug this: I have a package in build-packages which contents is not in parts/<part>/install
[11:20] <didrocks> zyga: updated
[11:20] <jgdx> it's libgsettings-qt-dev and this is some relevant output: http://pastebin.ubuntu.com/23141137/
[11:21] <didrocks> jgdx: the content is never in parts/<part>/install of build-packages
[11:21] <didrocks> build-packages are build requirements, they are not installed on the system
[11:21]  * ogra_ doesnt get it 
[11:21] <jgdx> didrocks, okay, but it fails none the less: http://pastebin.ubuntu.com/23141141/
[11:22] <zyga> didrocks: thanks
[11:23] <didrocks> jgdx: can you make a verbose cmake build? That way, you can see the -I and other includes path
[11:24] <jgdx> didrocks, okay, but where are those headers located? Should be located*
[11:25]  * ogra_ sighs ... why do DNS timeouts always take the lifetime of a hamster 
[11:25] <ogra_> *twiddle tumbs*
[11:26] <zyga> ogra_: because pidgeons ;-)
[11:26] <didrocks> jgdx: I think snapcraft unpack them in parts/<partname>/ubuntu/ but upstream can confirm/deny :)
[11:26] <ogra_> zyga, ha, i knew there was a relation 1
[11:26] <ogra_> !
=== hikiko|ln is now known as hikiko
[11:29] <jgdx> didrocks, okay. Can you please name names? :)
[11:30] <jgdx> didrocks, and here's the verbose make failure: http://pastebin.ubuntu.com/23141161/
[11:30] <didrocks> jgdx: sergiusens and kyrofa may help you
[11:30] <jgdx> didrocks, thanks!
[11:30] <didrocks> yeah, I don't see /ubuntu
[11:30] <didrocks> yw ;)
[11:30] <jgdx> sergiusens, kyrofa, could you please take a look at that backlog ^
[11:31] <jgdx> didrocks, well /ubuntu has a bunch of debs in download, and a couple of files in folders /var and /etc
[11:32] <jgdx> i.e. no headers in /ubuntu
[11:32] <didrocks> might be another folder than this one which is for stage-packages then, I didn't look closely at build-packages
[11:44]  * jgdx re-reads docs on build vs stage packages
[11:45] <jgdx> I thought -dev packages would go in the build-packages section, but I guess that's not entirely correct
[11:45] <ogra_> pitti, hmm, the fix doesnt seem to work
[11:46] <ogra_> oops, i take that back
[11:46] <ogra_> the store was just veeeeery sloooow
[11:47] <ogra_> pitti, and FYI, i seem to keep the same IP now
[11:47] <ogra_> whatever it was, it seems fixed
=== chihchun is now known as chihchun_afk
[11:51] <ogra_> BAH
[11:51] <ogra_> ogra@localhost:~$ htop
[11:51] <ogra_> mkdir: cannot create directory ‘/home/ogra/snap/htop’: Permission denied
[11:51] <ogra_> ogra@localhost:~$
[11:53] <ogra_> looks like snapd or snap-confine now have issues
[11:53] <ogra_> sigh
[11:53] <ogra_> ogra@localhost:~$ ls -lh
[11:53] <ogra_> total 4.0K
[11:53] <ogra_> drwxr-xr-x 3 root root 4.0K Sep  6 11:47 snap
[11:53] <ogra_> GRRRR !
[11:54] <ogra_> zyga, ^^^^ didnt you fix that one ?
[11:55] <zyga> I did
[11:55] <ogra_> well, still there
[11:55] <zyga> can you reproduce this?
[11:55] <zyga> I bet that is not snap-confine
[11:55] <zyga> did you sudo run any snaps?
[11:55] <ogra_> i'm pretty sure i can ... if your first snap contains a binary that requires to be run with sudo
[11:55] <zyga> aj
[11:56] <zyga> I didn't fix that,
[11:56] <ogra_> i.e. i always install the classic snap first
[11:56] <zyga> hmmm
[11:56] <zyga> that was never reported
[11:56] <ogra_> which requires you to run "sudo classic" to enable the shell
[11:57] <zyga> right
[11:57] <zyga> can you plresqe report that
[11:57] <zyga> snap confine creates the directory as the user
[11:57] <zyga> but sudo just switches the user
[11:57] <zyga> ogra_: note that today (unless my memory fails me) snap run may also create the directory
[11:58] <zyga> mvo: ^^ does snap-run + exec mkdir $HOME/sanp/$SNAP_NAME/{$SNAP_REVISION,$SNAP_COMMON} ?
[11:59] <ogra_> zyga, bug 1620592
[11:59] <mup> Bug #1620592: if your first installed snap contains a binary needing sudo ~/snap is created with root.root ownership <Snappy:New> <https://launchpad.net/bugs/1620592>
[11:59] <ogra_> now you have a report :)
[12:00] <mup> Bug #1620592 opened: if your first installed snap contains a binary needing sudo ~/snap is created with root.root ownership <Snappy:New> <https://launchpad.net/bugs/1620592>
[12:01] <zyga> ogra_: thanks
[12:02] <pitti> ogra_: err, what? it's a kind of maaa-giiic? ♪ ?
[12:02] <pitti> ogra_: anyway, thanks for confirming!
[12:02] <ogra_> pitti, perfect song for this week btw ;)
[12:02] <zyga> pitti: sudo snap-confine just mkdir's stuff as root
[12:03] <ogra_> (would have been freddy mercury's 70th yesterday)
[12:03] <pitti> ooh
[12:03] <qengho> dang.
[12:03] <pitti> zyga: sorry, ECONTEXT?
[12:03] <ogra_> so yay ... we have working pi2 images ... now on to dragonboard ...
[12:04] <ogra_> (after lunch)
=== ant_ is now known as Guest47626
[12:10] <mvo> zyga: snap run should create the dirs now, yes
[12:10] <mvo> zyga: once that lands
[12:11] <didrocks> hum, the store keeps resetting my connection
[12:12] <didrocks> starting to download ubuntu-core, but then:
[12:12] <didrocks> - Download snap "ubuntu-core" from channel "stable" (read tcp 10.42.0.81:55008->77.242.195.171:443: read: connection reset by peer)
[12:12] <didrocks> (after downloading few MB)
[12:12] <ogra_> peer ! that evil norwegian !
[12:12] <didrocks> ahah :)
[12:12] <pitti> ogra_: ... Steinbrueck?
[12:13] <ogra_> pitti, does he also reset connections ?
[12:13] <ogra_> i thought he only uses fahrradketten :)
[12:13] <pitti> ogra_: yes, he has a lot fewer now that he's not a minister any more
[12:13] <ogra_> true
[12:13] <ogra_> :)
[12:15] <didrocks> nessita: any known issue on the store side for those connections to be continuously reset? ^
[12:15] <didrocks> (and hey! ;))
[12:16] <nessita> didrocks, not that I know of, but let me check
[12:17] <nessita> didrocks, and hi! :-) Is this when downloading snaps?
[12:17] <didrocks> nessita: yeah, snap install <anything>, (trying to download ubuntu-core as first snap installed on this system)
[12:17] <didrocks> small rpi2 with the cloud image on it
[12:18] <nessita> didrocks, is this only affecting you or someone else? any chance your ISP is acting up?
[12:18] <ogra_> "small rpi"
[12:18] <didrocks> nessita: could be, I tried on my laptop, no issue here
[12:18] <noise][> didrocks: any strange network hops on your lan?
[12:18] <ogra_> vs the 1m^2 rpi ?
[12:18] <didrocks> but it could be something is acting up on my rpi2 connexion
[12:18] <noise][> from the pi to the world
[12:18] <didrocks> noise][: none from what I saw, at least, pings aren't lost
[12:19] <noise][> try a longer tcp/http conn to some other host?
[12:19] <zyga> pitti: don't worry
[12:19] <noise][> e.g. download a file from elsewhere (without hidden reconns)
[12:19] <zyga> mvo: so that with snap-confine and snap-run both doing this, should we do something about it
[12:19] <didrocks> noise][: ok, trying to wget an iso or so
[12:20] <ogra_> zyga, definitely .... but not urgent for RTM i'dsay
[12:20] <zyga> mvo: specifically, about using patching the sudo bug
[12:20] <noise][> a conn-reset mid download is unlikely to be from the CDN side
[12:20] <zyga> ogra_: you are right, I will fix that for 1.0.42 after RTM
[12:21] <didrocks> nessita: noise][: used successfully wget http://cdimage.ubuntu.com/ubuntu/daily-live/current/yakkety-desktop-i386.iso
[12:21] <didrocks> no drop
[12:22] <didrocks> could it be that snapd, the go tcp stack is more sensible to small drops?
[12:23] <mvo> zyga: what is the sudo bug? sorry that I am missing context here
[12:23] <mvo> zyga: aha, the one ogra reported
[12:24] <liuxg> ogra_, tomorrow, I will go to office to find a monitor and try it out there. If I can see the display in the monitor, i just login and type anything in the console, it should work, right?
[12:24] <mvo> zyga: I think snap run fixes that
[12:24] <mvo> zyga: it does not use HOME, it uses user.Current().HomeDir from go
[12:24] <mvo> zyga: for the mkdir
[12:24] <ogra_> liuxg, no, if you see the login prompt you hit enter and it should bring up the config too
[12:25] <ogra_> mvo, so pi2 looks releasable to me
[12:25] <ogra_> with latest ubuntu-core
[12:25] <liuxg> ogra_, I have a USB keyboard at home, can I do it at home now even without the monitor? I insert it into one of the USB port, is this fine?
[12:26] <ogra_> if you cant see anything ? i doubt it
[12:27] <liuxg> ogra_, ok, I got it, once I have done it this way, it should work straightforwardly, and I will not do it any more, right? by the way, will this be fixed in the coming releases?
[12:28] <ogra_> fixed ?
[12:28] <liuxg> ogra_, I mean in the future, if I flash a new release software, shall I do the same again?
[12:29] <liuxg> ogra_, for the current pi 2 image, I do not need to do anything like this and it works out of the box.
[12:32] <mvo> ogra_: ok, creating new test images
[12:32] <ogra_> liuxg, if you flash an image you alsways need to do the first setup
[12:33] <ogra_> mvo, a pi3 medel assertion would really help ...
[12:33] <ogra_> given that it is trivial to create the gadget
[12:33] <ogra_> (i'm pretty scared about the dragonboard with the 7 partitions ... )
[12:34] <liuxg> ogra_, thanks. I got it.
[12:34] <ogra_> liuxg, the console-conf is now a hard requirement ... you need to set up the network and the SSO user
[12:34] <ogra_> the image gets tied to your store account now
[12:35] <zyga> tyhicks`: jdstrand: https://github.com/snapcore/snap-confine/pull/126
[12:35] <mup> PR snap-confine#126: Add support module for namespace sharing <Created by zyga> <https://github.com/snapcore/snap-confine/pull/126>
[12:35] <zyga> morphis: ^^
[12:35] <Kaleo_> mvo, what's the next step with the test-snapd-thumbnailer-consumer snap? :)
[12:35] <zyga> stgraber: ^^
[12:35] <liuxg> ogra_, so what is the account for login? my store account or the default "ubuntu"?
[12:36] <mvo> Kaleo_: I approved it, you just need to publish it now
[12:36]  * zyga has a few more patches for snap-confine today
[12:36] <ogra_> liuxg, "ubuntu" is gone ... the firstboot config asks you for your store account ... contacts the store, verifies the credentials and pulls your ssh key from LP ...
[12:36] <zyga> jdstrand, tyhicks`: this is high priority for me, the code, even if lands, is not live, I just want to find holes in my reasoning along the way
[12:36] <ogra_> liuxg, and you can only log in via ssh now ... password-less with the ssh key
[12:36] <zyga> ogra_: fill them with 0s ;)
[12:36] <ogra_> zyga, whom ?
[12:37] <Kaleo_> mvo, done, thanks!
[12:37] <zyga> ogra_: the dragonboard partitions
[12:37] <ogra_> haha
[12:37] <ogra_> yeah, i'm sure the board will like that
[12:37] <zyga> ogra_: it will NOPit ;-)
[12:37] <jgdx> any way to avoid having this happen? http://pastebin.ubuntu.com/23141319/
[12:37] <ogra_> heh
[12:38] <liuxg> ogra_, this is really new to me. so what is the correct ssh command to login? ssh my_canonical_email_address@IP_address?
[12:39] <ogra_> liuxg, the tool tells you at the end
[12:39] <ogra_> usually "ssh $LP_NAME@$IP"
[12:39] <liuxg> ogra_, you mean after I press enter? OK. I will have a try tomorrow, thanks for your kind help :)
[12:39] <ogra_> it prints it on the screen
[12:40] <ogra_> after you press enter the tool starts and asks you for the nextwork config
[12:40] <ogra_> *network
[12:40] <ogra_> after that it asks for your account data and does the store auth dance... then iit tells you how to ssh into the board
[12:41] <ogra_> but you really need a working console for this
[12:41] <liuxg> ogra_, thanks. I understand it better.
[12:42] <liuxg> ogra_, I do not know why my HDM does not work with my p3. it works with my DELL laptop. The monitor is also a DELL model. it does not work with the p2 as well.
[12:43] <ogra_> yeah, thats bad ... and you have no TV or some such you could use instead ?
[12:43] <liuxg> ogra_, I have TV, I am not sure whether it works with it. it is a Samsung model.
[12:43] <ogra_> well, it should
[12:44] <liuxg> ogra_, again, thank you!
[12:44] <ogra_> np
[12:45] <Kaleo_> mvo, will it take time before it's available to "snap install" ?
[12:46] <Kaleo_> mvo, oh, no it's instant just it was only published in the edge channel, thanks
[12:49] <mvo> Kaleo_: correct, almost instant
[12:53] <mup> PR snapd#1853 opened: osutil: call sync after cp if requested. overlord/snapstate/backend: switch to use osutil instead of another buggy call to cp <Created by chipaca> <https://github.com/snapcore/snapd/pull/1853>
[13:03] <liuxg> ogra_, I finally see the hdmi output, it firstly showed "no network initialization", and now, it shows 4 strawberry on the screen.
[13:08] <liuxg> ogra_, I did not see the login prompt, it just showed "No network initialization". I am now flash the image again to see how it works.
[13:08] <Kaleo_> jdstrand, we have an app in a snap connected to the home interface which requests a thumbnail of an image in the home folder to the thumbnailer service via dbus, the thumbnailer service uses aa_query_label to verify that the app has indeed the rights to read that file and it returns a non 0 value indicating that the app does not have access
[13:09] <ogra_> liuxg, hit enter
[13:09] <Kaleo_> jdstrand, have you ever seen that?
[13:10] <jdstrand> Kaleo_: I'm familiar with that technique. it is going to need to be updated for the snappy world
[13:10] <liuxg> ogra_, I did that. seems no response. I finally saw 4 red strawberries on the screen. I do not know what happened before. I am making the new disk. By the way, I changed a HDMI input in my monitor, and this one seems working with the pi device :)
[13:10] <JamieBennett> ogra_, I hear dragonboard images are close, on-track for tomorrow?
[13:10] <Kaleo_> jdstrand, oh ok. so is that we won't use aa_query_label anymore? or is aa_query_label going to support snappy stuff or something else?
[13:10] <ogra_> JamieBennett, not at all ... we only just got pi images to work
[13:10] <jdstrand> Kaleo_: tvoss put together a plan for pulseaudio recording that other trusted helpers should follow
[13:11] <zyga> jdstrand: o/
[13:11] <Kaleo_> jdstrand, neat, tvoss you have a link?
[13:11] <JamieBennett> ogra_, Ah, OK. np for a later release.
[13:11] <ogra_> JamieBennett, i'm only now starting on the dragonboard gadget .... there were to many basic issues we had to fix first
[13:11] <ogra_> JamieBennett, and for the pi3 i need someone from niemeyer's team to create a model assertion for me
[13:11] <ogra_> the pi3 should be a thing of a few minutes
[13:12] <ogra_> JamieBennett, given that console-conf cant set up wifi yet i guess dragonboard wont be a lot of fun(we dont allow console liogins anymore and the dragon has no wired network)
[13:13] <JamieBennett> ogra_, makes sense
[13:13] <ogra_> but i'll do my best to get an image ready today even without network i want to make sure we have something booting
[13:13] <ogra_> (my hopes are not high though, given how much we had to tinker with ubuntu-image to get the basics for pi2 right)
[13:14] <jdstrand> Kaleo_ (cc tvoss): it is this I believe: https://docs.google.com/document/d/1mwLfShu3K8LNa1cYySqhM0fp06TZoKygG0bs2KB9Z4I/edit#heading=h.va0l2byp04q9, however it hasn't been approved yet by the snappy team (they/we.ve been working on rtm things for a bit)
[13:14] <jdstrand> zyga: hey
[13:18] <Kaleo_> jdstrand, I think I understand what the idea is in that document
[13:18] <Kaleo_> jdstrand, but I'm not sure what it means for thumbnailer and whether or not it should call aa_query_label
[13:19] <liuxg> ogra_, I had some output like http://imgur.com/a/2qtcf, does it mean that my ethernet card on the board is not working properly?
[13:21] <jdstrand> Kaleo_: each trusted helper will need to be examined and transitioned for snappy. several of the trusted helpers on touch like media-hub and thumbnailer had little shortcuts in them like this
[13:21] <ogra_> liuxg, no, ignore that ...
[13:21] <Kaleo_> jdstrand, oh, was that a shortcut?
[13:22] <Kaleo_> jdstrand, I had no idea
[13:22] <jdstrand> Kaleo_: I can't remember the exact details for thumbnailer otoh
[13:22] <Kaleo_> jdstrand, ok
[13:22] <jdstrand> do you have a link to the code?
[13:22] <Kaleo_> jdstrand, yes, hang on
[13:22] <ogra_> liuxg, the raspberrys should go away at some point ... or they go away if you hit enter
[13:22] <ogra_> try it
[13:22] <liuxg> ogra_,  why is the Net Initialization skipped　during the boot?  now I see 4 strawberries, I have a USB keyboard, hitting enter takes no effect.
[13:22] <ogra_> just wait tile the leds on the board stop blibnking wildly
[13:22] <Kaleo_> jdstrand, http://bazaar.launchpad.net/~unity-team/thumbnailer/trunk/view/head:/src/check_access.cpp#L59
[13:23] <liuxg> ogra_, OK. I wait for more time ...
[13:23] <Kaleo_> jdstrand, literally, every time an app asks for a thumbnail via dbus, thumbnailer calls query_file()
[13:23] <zyga> jdstrand, tyhicks`: https://github.com/snapcore/snap-confine/pull/127/files (much smaller)
[13:23] <mup> PR snap-confine#127: Don't leak root filesystem when using pivot_root <Created by zyga> <https://github.com/snapcore/snap-confine/pull/127>
[13:24] <Kaleo_> I was expecting aa_query_label to set allowed to 1 when querying the thumbnail of an image in the home directory _because_ the home interface is connected by the snap who asks for the thumbnail
[13:25] <jdstrand> Kaleo_: ok, so this is obtaining the security label and then seeing if something running under that label can access the file under its own profile. This seems reasonable in a snappy world. what is the issue you are having?
[13:25] <Kaleo_> jdstrand, exactly. the issue is that it says that the label cannot access the file
[13:25] <Kaleo_> jdstrand, allowed = 0
[13:25] <jdstrand> Kaleo_: what is the file it is trying to access?
[13:26] <jdstrand> zyga: ok (note tyhicks` won't be on for a little bit yet). also, I'm going to forward you a thread between me and tyhicks` re ssweeny's /run/media mounts not propogating as I think it may play a factor in this rework
[13:27] <Kaleo_> jdstrand, for example /home/kaleo/Images/phone/Camera/IMG_20160805_165531106.jpg
[13:27] <Kaleo_> jdstrand, and I would get things such as Sep  1 18:07:16 tequila com.canonical.Thumbnailer[5162]: thumbnailer-service: [18:07:16.618] Apparmor label "snap.gallery-app.gallery-app" has no access to "/home/kaleo/Images/phone/Camera/IMG_20160805_165531106.jpg"
[13:27] <jdstrand> Kaleo_: is that the actual file or is that a sumlink to somewhere?
[13:27] <Kaleo_> jdstrand, that's an actual file
[13:28] <jdstrand> Kaleo_: can you paste /var/lib/snappy/apparmor/profiles/snap.gallery-app.gallery-app ?
[13:28] <liuxg> ogra_, how long should I wait for the boot-up? still the strawberries are there after I hit the enter key. the "green" led is still blinking. I do not know what it does.
[13:28] <ogra_> green is heartbeat
[13:28] <ogra_> if only that blinks it should be done
[13:29] <liuxg> ogra_, the 'red' one is stable now.
[13:29] <ogra_> stable off ?
[13:30] <Kaleo_> jdstrand, yep, comign
[13:30] <liuxg> ogra_, no, iis stable "red", and it is not off
[13:30] <morphis> zyga: nice!
[13:30] <Fl1nt> Hi guys, any reason why ubuntu Core is not yet available in a 16.04 fashion??
[13:31] <liuxg> ogra_, is there anything wrong with my board? the red led is alway on.
[13:31] <ogra_> that sounds like your SD is broken
[13:31] <ogra_> liuxg, i really dont get why you still dont have a seriaql cable
[13:31] <ogra_> it is nearly impossible to work with developer boards without one
[13:32] <ogra_> and it doesnt realöly cost more than $10-15
[13:32] <liuxg> ogra_, oh, really? then I swith one card. I have no time to buy it. would you please show me the one you get?
[13:33] <zyga> jdstrand: thank you
[13:34] <mvo> ogra_: pardon my ignorance, the sudo issue your reported that ~/snap is owned by root? is there a bugreport for tihs?
[13:34] <zyga> mvo:     - https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1620560
[13:34] <mup> Bug #1620560: Revert command doesn't reset the right apparmor profile <amd64> <apport-bug> <xenial> <Snappy:In Progress by zyga> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1620560>
[13:34] <ogra_> liuxg, https://www.amazon.de/gp/product/B00KVUSI30 is the one i have
[13:34] <zyga> er
[13:34] <zyga> sorry
[13:34] <zyga> wrong link
[13:35] <ogra_> mvo, yes, zyga triaged it already
[13:35] <zyga> https://bugs.launchpad.net/snap-confine/+bug/1620592
[13:35] <liuxg> ogra_, thanks. you connect it to serial pins, right? I will buy one.
[13:35] <mup> Bug #1620592: if your first installed snap contains a binary needing sudo ~/snap is created with root.root ownership <Snappy Launcher:Triaged> <Snappy:New> <https://launchpad.net/bugs/1620592>
[13:36] <ogra_> liuxg, right
[13:37] <zyga> jdstrand: thanks, I suspected the same thing when I was changing that code today
[13:38] <Kaleo_> jdstrand, http://pastebin.ubuntu.com/23141511/
[13:40] <jdstrand> Kaleo_: it seems there may be a bug in the aa_query_file() call or that the label check needs to be updated for the stacking work. I'm going to need to point you at tyhicks` for this. tyhicks`: http://bazaar.launchpad.net/~unity-team/thumbnailer/trunk/view/head:/src/check_access.cpp#L59 is failing with 'Apparmor label "snap.gallery-app.gallery-app" has no access to "/home/kaleo/Images/phone/Camera/IMG_20160805_165531106.jpg"' even though snap.galler
[13:41] <Kaleo_> jdstrand, oki doki
[13:41] <Kaleo_> jdstrand, thank you
[13:41] <jdstrand> Kaleo_: np
[13:43] <jdstrand> zyga: wrt /run/media, is this something that you're able to work on now with your other mount work? (we were pulled in cause you were out). if you need us, we can continue working on it, but personally I'd like to see where your mount work ends up before looking at this again (moving target and all)
[13:43] <zyga> jdstrand: not today, I need to fix some old issue wrt connect/disconnect in snapd
[13:43] <zyga> jdstrand: I can work on that after
[13:43] <jdstrand> zyga: sure, I just meant in general
[13:43] <jdstrand> ok, thanks
[13:43] <zyga> jdstrand: yes, sure
[13:44] <jdstrand> awesome
[13:44] <zyga> jdstrand: I'd like to review and land snap-confine fixes and features ASAP
[13:46] <liuxg> ogra_, I used another SD card, and it looks like it is the same.. the red is always  on.. does it mean that the board has problems? it worked initially and used the "ubuntu" to login this afternoon
[13:47] <jdstrand> zyga: sure, I'm sure tyhicks` and I can do that this morning
[13:47] <ogra_> mvo, soo ... dragonboard doesnt work ... http://paste.ubuntu.com/23141530/
[13:47] <zyga> jdstrand: thank you, I'm sure you can :)
[13:49] <ogra_> mvo, the new gadget.yaml is at snappy-systems/snappy-hub if you want to take a look
[13:49] <mvo> ogra_: checking
[13:49] <ogra_> looks like snap prepare-image does expect something ubuntu-image doesnt provide
[13:50] <ogra_> liuxg, no idea ... without any output from the serial console this is really hard to tell
[13:50] <ogra_> liuxg, you can change the console= arg to point to tty1 in the cmdline.txt file on the system-boot partition of the SD
[13:50] <liuxg> ogra_, I do not know what is really happening here. did you ever try to flash the image dated on Aug 23rd? I am not sure whether China great wall has any impact or not when updating/grading.
[13:51] <ogra_> well, i cant tell you whjat happening without any output
[13:51] <ogra_> *what's
[13:51] <john-mcaleely> are there some images for all-snaps on dragonboard somewhere?
[13:51] <ogra_> and yes, i usually boot my images once before publishing them
[13:51] <mvo> ogra_: can you point me to the snapdragon snapcraft.ymla please
[13:51] <jdstrand> didrocks: hi! I'm not sure if you saw, but wondering if whenever you have a chance if you could look at https://github.com/ubuntu/snapcraft-desktop-helpers/pull/7
[13:51] <mup> PR ubuntu/snapcraft-desktop-helpers#7: common/desktop-exports: don't dereference target symlink on upgrades <Created by jdstrand> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/7>
[13:51] <liuxg> ogra_, by changing the console to tty1, I can see sth on the monitor?
[13:52] <ogra_> mvo, in the gadget tree on snappy-hub/snappy.-systems
[13:52] <Fl1nt> anyone?
[13:52] <ogra_> liuxg, you should
[13:52] <liuxg> ogra_, I will have a try, thanks
[13:52] <mvo> ogra_: I mean the kernel
[13:52] <Kaleo_> jdstrand, (new bug report for reference https://bugs.launchpad.net/snappy/+bug/1620635)
[13:52] <ogra_> mvo, under meta/gadget.yaml
[13:52] <mup> Bug #1620635: libapparmor's aa_query_label() always returns allowed = 0 for snaps <Snappy:New> <https://launchpad.net/bugs/1620635>
[13:52] <mup> Bug #1620635 opened: libapparmor's aa_query_label() always returns allowed = 0 for snaps <Snappy:New> <https://launchpad.net/bugs/1620635>
[13:52] <ogra_> mvo, lp:dragonboard-kernel-snap
[13:52] <ogra_> but that hasnt changed in a while
[13:53] <mvo> ogra_: thanks
[13:53] <didrocks> jdstrand: oh I didn't, will have a look later (probably tomorrow morning)
[13:54] <ogra_> john-mcaleely, probably by end of the week
[13:54] <john-mcaleely> ah, ok thanks ogra_ :-)
[13:54] <ogra_> john-mcaleely, theer are some but these are 100% obsolete at http://people.canonical.com/~mvo/all-snaps/
[13:54] <ogra_> using old gadget, and old image build tool etc
[13:54] <jdstrand> didrocks: thanks! :)
[13:55] <ogra_> and are wrongly confiogured
[13:55] <john-mcaleely> ogra_, understood. I will boot those with caution...
[13:55] <ogra_> well, they will fall apart
[13:55] <ogra_> withouot warning
[13:56] <mvo> ogra_: thanks, debugging
[13:56] <liuxg> ogra_, so, I change console=ttyAMA0,115200 to "console=tty1,115200", right?
[13:56] <ogra_> just console=tty1
[13:56] <ogra_> no speed
[13:56] <Kaleo_> fgimenez, did you ever have "Error connecting: Cannot autolaunch D-Bus without X11 $DISPLAY" in your spread test due to a service being dbus activated?
[13:57] <liuxg> ogra_, so the whole line is :dwc_otg.lpm_enable=0 console=tty1 elevator=deadline
[13:57] <didrocks> jdstrand: thx to you :)
[13:58] <ogra_> mvo, i have no idea if my gadget.yaml will work or not ... thats the first shot ...
[13:58] <mvo> ogra_: sure, looking why you get the error
[13:58] <fgimenez> Kaleo_, nope never saw that before sorry
[13:59] <Kaleo_> fgimenez, extra question, test snaps need to support multiple architectures?
[13:59] <fgimenez> Kaleo_, in the old unity test we needed to setup $DISPLAY in the test's enviroment to be able to run ubuntu-clock-app, but not sure how to pipe it to be used by the dbus activated service
[13:59] <Kaleo_> fgimenez, :/
[13:59] <fgimenez> Kaleo_, yes, at least amd64 and i386
[14:00] <liuxg> ogra_, this time, I see the output
[14:00] <Kaleo_> fgimenez, I must have missed the documentation regarding how to do that: is it both arch in one snap?
[14:00] <Kaleo_> fgimenez, how is it achieved?
[14:00] <ogra_> liuxg, right, if the scrolling stops you hit enter and should get the config tool
[14:00] <liuxg> ogra_, it asks me to input localhost.localdomain login:
[14:00] <ogra_> that sounds broken
[14:01] <ogra_> oh, wait, that was an old image ...
[14:01] <ogra_> try ubuntu ubuntu
[14:01] <ogra_> but that image will explode with the next auto-upgrade
[14:01] <liuxg> ogra_, yes it worked
[14:01] <ogra_> (and you cant really easily prevent the auto upgrading)
[14:02] <liuxg> ogra_, I do not know why in the first place, it did not show me that
[14:02] <liuxg> ogra_, what should I do next?
[14:02] <ogra_> because there was no console= entry for tty1
[14:02] <fgimenez> Kaleo_, afaik you should build it in the different archs, for i386 i used a vm created with adt-buildvm-ubuntu-cloud -a i386, installed snapcraft in there, built and uploaded the snap
[14:02] <ogra_> just use it ... but as i said, it will fall apart with the next auto-upgrade
[14:02] <ogra_> thats all obsolete old stuff
[14:03] <ogra_> and there is no backwards compatibility
[14:03] <ogra_> you can try a snap refresh and see what happens after reboot
[14:03] <liuxg> ogra_, with old image, it was tricky to get it continued there. should I do a refresh?
[14:03] <Kaleo_> fgimenez, so it's different .snap files, 1 per arch?
[14:04] <ogra_> fgimenez, geez, so compilcated ...
[14:04] <ogra_> Kaleo_, just set up a snap in LP for it
[14:04] <Kaleo_> ogra_, oh how is that?
[14:04] <ogra_> and have to build all arches (and auto-upload)
[14:04] <liuxg> ogra_, this time, I get the ip address for the device. waiting for it to boot ..
[14:04] <ogra_> Kaleo_, go to your bzr or git tree on LP ...
[14:05] <ogra_> Kaleo_, there is a "create snap package" link
[14:05] <ogra_> then fill the form :)
[14:05] <fgimenez> ogra_, good to know, thx! :)
[14:05] <ogra_> :)
[14:06] <Kaleo_> ogra_, ahah
[14:06] <Kaleo_> ogra_, but the snap is part of the snapd git tree
[14:06] <ogra_> if you saved the form there will be a "request builds" link
[14:07] <ogra_> oh
[14:07] <Kaleo_> ogra_, I suppose I can just push a temp tree
[14:07] <ogra_> well, you could import it to LP git ...
[14:07] <Kaleo_> ogra_, but what's the manual technique?
[14:07] <ogra_> or push a tem tree
[14:07] <Kaleo_> ogra_, is there some documentation?
[14:07] <Kaleo_> ogra_, is it a single .snap file in the end?
[14:07] <ogra_> i have no experience with git on LP though
[14:07] <ogra_> Kaleo_, it is an automagic build and upload to the store
[14:08] <ogra_> into the channels you picked in the form
[14:08] <Kaleo_> ogra_, yep, I wonder how I can do that on my machine: build for multiple archs
[14:08] <Kaleo_> and what the result looks like
[14:08] <ogra_> it can auto-build on commits otr it can be built manually by manual request ... as you like
[14:08] <ogra_> you would need actual HW
[14:09] <davidcalle> Kaleo, afaik, we don't have fat snaps, one build per arch
[14:09] <ogra_> at least if you dont build for x86 only
[14:09] <ogra_> for x86 only you could use VMs
[14:09] <ogra_> or chroots ...
[14:10] <ogra_> but armhf or arm64 or ppc64el or s390x (which are all supported arches) would need real HW
[14:10] <kyrofa> nhaines, hey, thanks for taking Nextcloud for a spin!
[14:11] <kyrofa> nhaines, it's not really out of date-- 10 was literally just released! I'm giving it a little time before I update it in the snap so all the kinks can be worked out
[14:11] <kyrofa> Because every snap automatically updates. Don't want to be too close to the bleeding edge
[14:12] <kyrofa> nhaines, so yes, that snap is officially maintained by nextcloud-- it'll be updated soon
[14:12] <Kaleo_> ogra_, oh ok, so there must be a trick in the store to upload each arch specific snap file
[14:12] <ogra_> Kaleo_, no. you just upload them
[14:12] <Kaleo_> ogra_, and it will detect it automatically ok
[14:12] <ogra_> yeah
[14:13] <Kaleo_> ogra_, thanks
[14:13] <ogra_> np
=== tyhicks` is now known as tyhicks
[14:15] <Kaleo_> ogra_, is that the same way for clicks??
[14:16] <ogra_> Kaleo_, i dont think so
[14:16] <ogra_> but it has been quite a while since i touched clicks
[14:16] <ogra_> perhaps it changed
[14:19] <Kaleo_> ok
[14:22] <ogra_> mvo, oooh
[14:22] <ogra_> Fetching drangonboard-kernel
[14:22] <ogra_> error: cannot find snap "drangonboard-kernel": snap not found
[14:22] <niemeyer> sergiusens: The release command doesn't take more than a single channel?
[14:22] <ogra_> drangonboard != dragonboard ...
[14:22] <niemeyer> sergiusens: Hello, btw! :)
[14:22] <ogra_> mvo, so i fear we need a new model assertion
[14:23] <mvo> oh, typo!
[14:23] <sergiusens> niemeyer that is how it was spec'ed; I brought it up in Heidelberg, but we haven't had time to finalize on the change
[14:23] <ogra_> yeah
[14:23] <ogra_> reading the error 200 times helps :P
[14:23] <sergiusens> it is contradictory with the release command which does take multiple channels
[14:24] <niemeyer> sergiusens: I think people just assumed it would be obvious
[14:24] <niemeyer> sergiusens: The fact we don't have closing also makes the problem worse
[14:24] <sergiusens> niemeyer I am waiting on `close` to be finalized store side
[14:24] <mvo> ogra_: just edit and fix for now
[14:25] <mvo> ogra_: and pass the environment to skip
[14:25] <niemeyer> sergiusens: Yeah, the tricky bits are definitely on the store side
[14:25] <mvo> ogra_: this should unblock you to test if it boots
[14:25] <ogra_> hmm, k
[14:25] <niemeyer> sergiusens: Can we have the release command fixed soonish meanwhile?
[14:25] <mvo> ogra_: in the meantime I trigger a new assertion
[14:25] <niemeyer> sergiusens: I can easily script it locally, but it feels bad to force everybody to be using that UI
[14:26] <ogra_> mvo, yeah, i dont belive it will produce something bootable ... but you never know :)
[14:26] <ogra_> yeah, next weeor
[14:26] <ogra_> error: cannot find boot config in "/tmp/tmp2moc952b/unpack/gadget"
[14:26] <ogra_> *error
[14:27] <niemeyer> sergiusens: Given the precedence on --release, the comma-separated list would be fine I think
[14:27] <ogra_> oh, you need that awful dangling symlink in the gadget snap
[14:27] <ogra_> sigh
[14:27] <ogra_> who came up with that
[14:27] <sergiusens> niemeyer err, sorry, you can release to multiple channels on puch `snapcraft push <snap-file> --release <channel1,channel2,...>`; you cannot `snapcraft release` to multiple channels; but I can add the same semantics as `push` if we agree to that
[14:27] <sergiusens> the implementation is not really the problem, it is not going overboard on the UX to the point it becomes confusing to all
[14:28] <sergiusens> niemeyer an hello back at you :-)
[14:28] <sergiusens> niemeyer I'll get to it and will be there in 2.17 (next release)
[14:28] <sergiusens> niemeyer I hope close is finalized too in order to have that in as well
[14:28] <niemeyer> sergiusens: Yeah, same semantics of --release is sensible.. I actually tried that locally precisely due to the docs on --release
[14:28] <mup> Bug #1620650 opened: After installing krita from beta channel, krita crashes when opening the snap. <Snappy:New> <https://launchpad.net/bugs/1620650>
[14:30] <mhall119> ogra_: I've created https://bugs.launchpad.net/snappy/+bug/1620650 how do I link it to the upstream bug report?
[14:30] <mup> Bug #1620650: After installing krita from beta channel, krita crashes when opening the snap. <Snappy:New> <https://launchpad.net/bugs/1620650>
[14:32] <ogra_> error: cannot find boot config in "/tmp/tmpbh08e912/unpack/gadget"
[14:32] <ogra_> COMMAND FAILED: snap prepare-image --channel=edge  dragonboard-model.assertion /tmp/tmpbh08e912/unpackuncaught exception in state machine step: [1] prepare_image
[14:32] <ogra_> mvo, ^^^
[14:32] <ogra_> mvo, what exactly is it looking for ?
[14:33] <SamYaple> sergiusens: python plugin has been working amazingly! The pyc files still stick around but I have a solution for that as soon as you finish up the plugin
[14:33] <SamYaple> the recursive find isn't working
[14:33] <ogra_> mhall119, also affects project or allso affects distribution/package ... one iof them should offer you an url entry
[14:34] <zyga> ara: is there any system that has modern-ish nvidia hardware and intel graphics that I could ssh into to do some testing and poking?
[14:36] <mvo> ogra_: uboot.conf in the gadget root dir
[14:36] <mvo> ogra_: a symlink to uboot.env is sufficient
[14:37] <ogra_> ogra@anubis:~/datengrab/devel/branches/snappy-systems/dragonboard$ ls -l uboot.conf
[14:37] <ogra_> lrwxrwxrwx 1 ogra ogra 9 Sep  6 16:30 uboot.conf -> uboot.env
[14:37] <ogra_> ogra@anubis:~/datengrab/devel/branches/snappy-systems/dragonboard$
[14:37] <mvo> ogra_: this will probably go away soon, right now its needed
[14:37] <ogra_> it is there
[14:37] <mvo> ogra_: ok, let me check
[14:37] <ogra_> i took the pi2 as example :)
[14:37] <mhall119> ogra_: distro/project offers me a URL, but won't let me choose ubuntu/calligra
[14:38] <ogra_> mhall119, well, then i have no idea
[14:39] <mhall119> "Bug watches can not be added for Ubuntu, as it uses Launchpad as its official bug tracker. Alternatives are to add a watch for another project, or a comment containing a URL to the related bug report." is what LP gives me
[14:40] <ogra_> didnt you say upstream ?
[14:40] <cjwatson> mhall119: upstream would be calligra, not ubuntu/calligra
[14:40] <ogra_> right
[14:40] <mhall119> cjwatson: is there a way to not include a distro?
[14:40] <cjwatson> mhall119: select "Also affects project", not "Also affects distribution/package"
[14:41] <cjwatson> I would love to rewrite that UI
[14:41] <ogra_> +1
[14:41] <cjwatson> well, I say "love"
[14:41] <ogra_> :)
[14:41] <mhall119> oh, ok, so after choosing just the package, then it takes me to a new screen where I can link the upstream bug
[14:41] <cjwatson> choosing just the *project*, not the package
[14:41] <cjwatson> best to keep that straight in your head
[14:42] <cjwatson> but yes
[14:42] <mhall119> you overestimate my head :)
[14:42] <mhall119> done and done, thanks cjwatson and ogra_
[14:42] <pstolowski> didrocks, hey, we're trying to repro #1620560 (no luck so far), can you attach your snapcraft.yaml so that we test the same scenario?
[14:42] <mup> Bug #1620560: Revert command doesn't reset the right apparmor profile <amd64> <apport-bug> <xenial> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1620560>
[14:43] <ogra_> mvo, hmm, could it be a prob that the dragonboard gadget is arch all ? i see pi2 is arch armhf
[14:44] <mvo> ogra_: hm, one sec, I thnk I have an idea
[14:46] <jdstrand> tyhicks: fyi, going through email, Kaleo_ filed this for that thumbnailer issue: https://bugs.launchpad.net/bugs/1620635
[14:46] <mup> Bug #1620635: libapparmor's aa_query_label() always returns allowed = 0 for snaps <Snappy:New> <https://launchpad.net/bugs/1620635>
[14:46] <ogra_> a dragon borat !
[14:46] <ogra_> http://www.clothestopose.co.uk/ekmps/shops/clarke/images/welsh-dragon-mankini-106-p.jpg
[14:46] <tyhicks> jdstrand: thanks - he pinged me
[14:46]  * tyhicks looks at it now
[14:47] <mvo> ogra_: hm, typo in my u-d-f script
[14:47] <mvo> ogra_: can you please bzr pull, you should get r300
[14:47] <ogra_> u-image you mean ?
[14:47] <mvo> ogra_: that should fix this issue
[14:47] <ogra_> sure
[14:47] <mvo> ogra_: in my u-d-f code
[14:47] <ogra_> u-d-f ?
[14:47] <ogra_> i dont use u-d-f
[14:47] <mvo> ogra_: ubuntu-image?
[14:48] <ogra_> yes, indeed
[14:49] <ogra_> i used ubuntu-image all day ... the pi2 images i tested were build using u-image
[14:49] <mvo> ogra_: sweet
[14:50] <mvo> ogra_: ok, let me try that
[14:50] <ogra_> so i'm doing the same for the dragon borat now :)
[14:51] <dpm> that sounds like a fun combination...
[14:51] <ogra_> dpm, http://www.clothestopose.co.uk/ekmps/shops/clarke/images/welsh-dragon-mankini-106-p.jpg
[14:51] <ogra_> ;)
[14:51] <mvo> ogra_: the yaml parser of u-i is unhappy, let me have a look at this
[14:51] <ogra_> k
[14:52] <dpm> why did I know I shouldn't have clicked on that link?
[14:52] <ogra_> hahaha
[14:52] <dpm> :)
[15:00] <mvo> ogra_: give me some more minutes, I think I'm getting closer
[15:00] <ogra_> no hurry ... i'll get some fresh coffee and such
[15:00] <mvo> sounds good
[15:00] <mvo> tea
[15:00] <mvo> hmmmmm
[15:00] <ogra_> :)
[15:02] <mup> PR snapd#1854 opened: Generate account-key-request "since" header in UTC <Created by cjwatson> <https://github.com/snapcore/snapd/pull/1854>
[15:03] <mup> PR snapd#1855 opened: overlord/boot: have firstboot support assertion files with multiple assertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/1855>
[15:14] <mvo> ogra_: its tricky, slowly getting closer
[15:21] <liuxg> ogra_,  I just refresh my system, and after boot, it stops at the screens http://imgur.com/a/MNkQJ  the progess is 20% and it stops there.
[15:23] <mvo> ogra_: I pushed a new dragonboard gadget snap with some yaml fixes, can you please give it a go? with that my ubuntu-image can build an dragonboard image (no idea if it boots of course)
[15:26] <ogra_> mvo, did you push the changes to the branch ?
[15:27] <ogra_> oh
[15:27] <ogra_> i shouldnt have taken the pi2 stuff blindly :P indeed it also needs the gpt type
[15:28] <ogra_> yup. seems that built
[15:31] <ogra_> mvo, not even a burp on the serial console with that image
[15:32] <ogra_> mvo, and it seems the order is a complete mess
[15:32] <ogra_> looks like the vfat is sdc1
[15:33] <mhall119> nessita: the krita developer keeps encountering this bug: https://bugs.launchpad.net/software-center-agent/+bug/1620679
[15:33] <mup> Bug #1620679: Store emails incorrectly state that beta/edge packages are published when they are not <Software Center Agent:New> <https://launchpad.net/bugs/1620679>
[15:34] <ogra_> mvo, is the yaml processed from bottom to top ? do i need to reverse the entires ?
[15:34] <nessita> mhall119, let me see
[15:34] <mvo> ogra_: I pushed everything to the bracnh
[15:35] <mvo> ogra_: it was incorrect structure and the gpt uuid for the vfat thing
[15:35] <ogra_> yeah, i see that
[15:35] <ogra_> but still ... the vfat ends up as first partition
[15:35] <nessita> mhall119, will try to have someone working on it
[15:35] <ogra_> mvo, i'm also üpretty sure that content: wont work if we need img files dd'ed
[15:36] <ogra_> mvo, at least by the definition in https://github.com/CanonicalLtd/ubuntu-image/blob/gadget-yaml/docs/gadget-yaml.rst
[15:37] <SamYaple> what is the best practice way to run arbitary commands shell when building a snap?
[15:37] <ogra_> hmm, no, i was on an old copy
[15:37] <ogra_> content: image:_ is correct
[15:38] <mvo> ogra_: oh, I don't claim it will work :)
[15:38] <mvo> ogra_: just that its now correct yaml that u-i understands
[15:38] <ogra_> mvo, well, why is the vaft the first partition ?
[15:38] <ogra_> *vfat
[15:39] <ogra_> and actually the only partition
[15:39] <mvo> ogra_: you sound like I might have any idea ;)
[15:39] <ogra_> seems it didnt even bnother to create anything but the vfat
[15:39] <mvo> ogra_: heh
[15:39] <mvo> ogra_: maybe just not implemented yet? let me look at the code
[15:39] <mvo> ogra_: you can still use u-d-f ;)
[15:39] <mvo> ogra_: I can create you an image I think, but let me first look at u-i
[15:40] <ogra_> well, given u-i works for everything else it would be nice to have it work here as well
[15:40] <mhall119> thanks nessita, it's not a blocker, but I do have to keep reminding him to go in and hit the publish button
[15:41] <ogra_> err
[15:41] <ogra_> Number  Start (sector)    End (sector)  Size       Code  Name
[15:41] <ogra_>    1            2048         7812466   3.7 GiB     FFFF  sbl1
[15:41] <ogra_> now thats curious
[15:41] <nessita> mhall119, yeah, makes total sense, already asked psivaa to take a look :-)
[15:41] <ogra_> it created a 3.7G partition
[15:42] <mvo> ogra_: yeah, looks totally bogus
[15:42] <ogra_> i have the feeling the structure parsing is all wrong ... it took the name of the first entry but applied everything from the vfat
[15:43] <psivaa> nessita: mhall119: i'll start working on it straightaway
[15:43] <ogra_> and obviously ignored any of the size entries
[15:43] <mvo> ogra_: its not totally wrong, if you pass "-w /tmp/workdir" you can see under /tmp/workdir/.images that the partitions are created, not sure if sizes etc are correct, but there is something there
[15:43] <didrocks> pstolowski: really? and you are installing a snap that requires special permissions?
[15:44] <pstolowski> didrocks, a snap that requires a specific dbus path
[15:44] <pstolowski> didrocks, zyga tried too with some other snap (not sure about the details), no luck either
[15:44] <ogra_> mvo, well, the GPT doesnt know about them
[15:45] <bull_> guys :) i set up daily build for snapcraft-gui on launchpad which grab fresh code from github repo , build the code and publish the debian binary to my PPA :) so you can add repo to check how hot the gui version f snapcraft is :P
[15:45] <didrocks> pstolowski: I can even push you the snap files directly
[15:45] <didrocks> uno momento
[15:46] <pstolowski> didrocks, even better
[15:46] <bull_> read more here :P    https://github.com/keshavbhatt/snapcraft-gui#install-on-ubuntu-1604-and-above
[15:46] <sergiusens> SamYaple good to know, I'll fixup the py2/3 check and it should be mostly ready
[15:46] <ogra_> mvo, what should -w /tmp/workdir do ? i dont see u-i create anything in /tmp
[15:46] <mvo> ogra_: yeah, not arguing that its buggy :) just saying its not totally off, it does something correct
[15:46] <sergiusens> SamYaple interesting that the pyc stuff doesn't work as there is an integration test there, it might be busted if it truly isn't :-(
[15:46] <mvo> ogra_: it should keep its temp files there so that this can be inspected
[15:47] <ogra_> weird
[15:47] <ogra_> it doesnt
[15:47] <didrocks> pstolowski: you just need a webcam (to ensure it initializes)
[15:47] <didrocks> pstolowski: so, http://people.canonical.com/~didrocks/tmp/face-detection_1.0_amd64.snap and http://people.canonical.com/~didrocks/tmp/face-detection_2.0alpha1_amd64.snap
[15:47] <pstolowski> didrocks, k
[15:47] <SamYaple> sergiusens: oh. hmm. well ignore what i said for now and ill dig into it. if there is a test, it probably is me doing something wrong
[15:47] <didrocks> pstolowski: install 1.0 with --devmode, then 2.0alpha1 with --devmode
[15:48] <mvo> ogra_: oh, if you use the snap you need a different dir than /tmp - you get a private snap tmp
[15:48] <didrocks> and then revert, and see the denial in syslogs
[15:48] <mvo> ogra_: on a tempfs
[15:48] <mvo> ogra_: so stuff will be created there but you won't see it
[15:48] <ogra_> ah
[15:48] <mvo> ogra_: super confusing when working on classic :/
[15:48] <didrocks> pstolowski: if you want to enable camera, use face-detection --enable-camera
[15:48] <didrocks> pstolowski: you even have a web interface on localhost:8080 ;)
[15:49] <didrocks> pstolowski: keep me posted
[15:49] <sergiusens> SamYaple well now that there we use pip for everything we can also just add --no-compile
[15:49] <sergiusens> I think that would do the trick
[15:49] <pstolowski> didrocks, oki. now i wonder if --devmode is relevant. i tested mine in strict
[15:49] <bull_> damn
[15:49] <mup> PR snapd#1856 opened: asserts: required account key name header <Created by emgee> <https://github.com/snapcore/snapd/pull/1856>
[15:49] <didrocks> pstolowski: could be
[15:49] <bull_> who is mup :D
[15:50] <ogra_> mvo, right, nopw i see it creates part 0-7 and root
[15:50] <didrocks> sergiusens: oh hey! I think you didn't consider golang module in the go plugin which compiles some C code, correct? (like using pkgconfig)
[15:51] <mvo> ogra_: yeah, I add some debug now, I think its all broken
[15:51] <mvo> ogra_: ;)
[15:51] <ogra_> as usual :P
[15:56] <Fl1nt> guys, what kind of isolation security can we expect from snappy?
[15:56] <SamYaple> sergiusens: yea i added it locally, but that still leaves around pyc files
[15:56] <Fl1nt> I mean, do snappy rely on seccomp for example?
[15:56] <SamYaple> sergiusens: its still something that i was planning on adding
[15:56] <SamYaple> sergiusens: speeds up install
[15:57] <Fl1nt> is there an official documentation related to this sec topic?
[15:57] <ssweeny> jdstrand, did you get anywhere with the shared mount stuff?
[15:57] <jdstrand> Fl1nt: we use a bunch of technologies in combination for strong confinement. seccomp is one, yes. you might be interested in https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/
[15:58] <Fl1nt> jdstrand: nice one thx :D
[15:58] <jdstrand> ssweeny: yes. tyhicks and I narrowed it down to how '/' was mounted and tyhicks came up with a possible solution. zyga is reworking the mount stuff and we've forwarded our investigation to him
[15:59] <jdstrand> Fl1nt: np
[16:00] <ssweeny> jdstrand, awesome, thanks for looking into this!
[16:00] <ssweeny> zyga and tyhicks too
[16:01] <jdstrand> yes, everyone should be thanked :)
[16:01] <Fl1nt> I'm a beginner on snappy but it catch my eyes as I really think of it as a perfect mix between LXD and Docker, additionally, if coupled with some sort of orchestrator and a A/B partitioned system it could became a perfectly fitting solution on my side project ^^
[16:01] <pstolowski> didrocks, ok. easily reproduced with your snaps
[16:01] <SamYaple> Fl1nt: yep you are not the only one
[16:01] <mup> PR snapd#1857 opened: tests: add spread test that ensures running a snap as root does not create a… <Created by mvo5> <https://github.com/snapcore/snapd/pull/1857>
[16:01] <SamYaple> Fl1nt: there are dozens of us!
[16:01] <mup> Bug #1620693 opened: Permission denied to access /sys/kernel/mm/hugepages/ <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1620693>
[16:02] <Fl1nt> The opposite would have been really bizarre :D I think I'll dig a little bit more on it and see if my project can be based on it.
[16:03] <Fl1nt> Does snapd using "interfaces" too as the snaps can provides or consumes them?
[16:03] <didrocks> pstolowski: and not with another one with --devmode?
[16:03] <didrocks> pstolowski: at least, good that you can reproduce :)
[16:04] <pstolowski> didrocks, i haven't tried my dummy snap with --devmode yet
[16:05] <SamYaple> Fl1nt: yea. look at 'plugs'
[16:05] <mup> PR snapd#1840 closed: many: use symlinks instead of wrappers <Critical> <Reviewed> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1840>
[16:06] <didrocks> pstolowski: I would love to remove --devmode, but there are 2 issues I'm getting: sqlite3 is doing chown when run as root (but chowning to euid which is 0 as well) and seccomp denies it
[16:06] <didrocks> I think we discussed with jdstrand having fchown apparmor mediation to allow fchown if uid == euid
[16:06] <mhall119> is there a way to upgrade a snap I installed from the beta channel to the version in the stable channel?
[16:06] <mhall119> or do I have to uninstall and reinstall?
[16:07] <didrocks> pstolowski: the other issue is that opencv tries to list the available webcams via /sys/bus/usb/devices
[16:07] <Fl1nt> SamYaple: Thx ! really nice so! Anyone aware of a community project trying to create a "snap cloud" orchestrator?
[16:07] <didrocks> I don't think we have an interface to allow that (zyga?) ^
[16:07] <didrocks> mhall119: snap refresh --channel=beta doesn't work?
[16:09] <mhall119> didrocks: ah, that works
[16:09] <mhall119> I tried it with snap install, but not snap refresh
[16:10] <zyga> ssweeny: it won't happen today though, probably down the week
[16:10] <popey> dpm: lets move here :)
[16:10] <ssweeny> zyga, that should be fine
[16:10] <liuxg> ogra_, is bluetooth enabled on pi 3? thanks
[16:10] <ogra_> liuxg, no idea
[16:11] <ogra_> the firmware should be there ...
[16:11] <liuxg> ogra_, I cannot connect it. strange. the same software works on Desktop
[16:11] <SamYaple> Fl1nt: I am not. im pretty close to that area too
[16:12] <liuxg> ogra_, how can I check whether it is enabled or not?
[16:12] <ogra_> no idea
[16:12] <ogra_> and i have not the time right now to dig into this
[16:12] <popey> dpm: doing a make VERBOSE=1, to see if I can figure out where it's breaking
[16:12] <Fl1nt> SamYaple: My heart is bouncing between bootstrapping one and attaching myself to an Openstack/K8S or Nomad related project
[16:14] <mvo> ogra_: sorry, dragonboard parititioning is in a really bad state, that is something for barry or slangasek to look at, it looks like the way u-i drives sgdisk just does not quite work (or our gadget.yaml is broken :)
[16:14] <jdstrand> didrocks, pstolowski: now that we have seccomp arg filtering support in snap-confine, I will be adjusting the policy for these sorts of things. I just need to get to some rtm items first
[16:14] <ogra_> i would not be surprised if it was both :)
[16:14] <ogra_> mvo, well, slangasek is back tomorrow iirc
[16:14] <slangasek> or today
[16:14] <popey> got it dpm - cd /home/alan/tmp/ubuntu-terminal-app/build/src/plugin/qmltermwidget && cp /home/alan/tmp/ubuntu-terminal-app/src/plugin/qmltermwidget/src/qmldir /home/alan/tmp/ubuntu-terminal-app/build/src/plugin/qmltermwidget/../QMLTermWidget
[16:15] <popey> dpm: ^ that (whatever it is) is puting the qmldir file as QMLTermWidget
[16:15] <slangasek> but I think you have a few critical bugs filed against ubuntu-image itself that I need to work through before I start taking a look at the dragonboard gadget snap
[16:15] <jdstrand> didrocks: I think you can use the camera interface for that now
[16:15] <jdstrand> didrocks: (the usb cameras one)
[16:15] <didrocks> jdstrand: great to hear that's on its way (for fchown)
[16:15] <didrocks> jdstrand: hum, I'm using the camera interface, but it doesn't give access to listing this /sys dir
[16:16] <dpm> popey, ack
[16:16] <jdstrand> didrocks: I made updates to camera recently for that
[16:16] <ogra_> slangasek, well, i have a working pi2 image here ... built with u-image ... i just tested lvm ... that sadly blows up with having grub.cfg mounted under /boot/uboot ...
[16:16] <didrocks> jdstrand: ah, maybe not released yet?
[16:16] <ogra_> s/lvm/kvm/
[16:16] <jdstrand> didrocks: actually, it will probably be in 2.15
[16:16] <didrocks> snap    2.13+ppa207-1
[16:16] <didrocks> snapd   2.13+ppa207-1
[16:16] <jdstrand> its committed in trunk
[16:16] <jdstrand> it's
[16:17] <didrocks> jdstrand: ok, sounds excellent then! I thought it would be a security issue to be able to list every usb devices on the system, but it's not?
[16:17] <slangasek> ogra_: your gadget.yaml is using things like 'size: 16' for a partition whose contents are 16k in size; size without suffix is bytes, not K.  That's probably the issue here
[16:17] <popey> dpm: got it to build by removing the file QMLTermWidget and mkdiring it before running make
[16:17] <ogra_> slangasek, trying to builod a dragonboard image with the new gadget gets me a single partition image though ...
[16:17] <dpm> that somehow rings a bell
[16:17] <ogra_> slangasek, hmm, that might indeed be
[16:17] <dpm> popey, I think I had this problem quite a while ago,
[16:18] <popey> dpm: it runs too, from the build dir.
[16:18] <SamYaple> Fl1nt: if you go openstack, youll have to deal with nova. it hasn't worked to well for the docker plugin, so keep that in mind
[16:18] <jdstrand> didrocks: it is. '# Allow detection of cameras. Leaks plugged in USB device info'
[16:18] <slangasek> ogra_: we will be doing further work to toughen up the parsing to reject such things, and I'll also make a note to update the docs to document this
[16:18] <dpm> not with terminal but can't remember what I had to do
=== bull_ is now known as bulldog
[16:18] <popey> heh
[16:18] <jdstrand> didrocks: but camera is not auto-connected, so we allow the info leak for now
[16:18] <popey> dpm: wonder if shipping an empty QMLTermWidget is sufficient
[16:18] <bulldog> hi popey
[16:18] <popey> hello bulldog
[16:18] <popey> bulldog: hows things?
[16:18] <ogra_> slangasek, WELL, FEEL FREE TO MAKE CHANGES AS NEEDED TO TEH GADGET
[16:18] <ogra_> EEEK
[16:18] <nacc> heh
[16:18]  * ogra_ rips off the caps key 
[16:19] <bulldog> popey, i  i set up daily build for snapcraft-gui on launchpad which grab fresh code from github repo , build the code and publish the debian binary to my PPA :) so you can add repo to check how hot the gui version f snapcraft is :P
[16:19] <slangasek> ogra_: ENOTIME, working on ubuntu-image itself today
[16:19] <ogra_> ok
[16:19] <popey> bulldog: nice, now make a snap ㋛
[16:19] <didrocks> jdstrand: makes sense! Thanks for those good news :)
[16:19] <Fl1nt> SamYaple: That exactly why I'm so reluctant to work on an additional project for OS indeed :D But I deeply think that OS is the most closest project to what's enterprises are waiting for in terms of infrastructure management.
[16:19] <ogra_> slangasek, but note that with mvo's tree everything seems to work rather well already
[16:19] <bulldog> popey,  snapcraft-gui is capable of doing almost everything now
[16:20] <ogra_> slangasek, also, we wont need cyphermox' cloud-init tree merged it is now disabled in ubuntu-core
[16:20] <bulldog> popey, i will try to write snapcraft recipe for it , and will snap it with snapcraft-gui :D
[16:20] <popey> :)
[16:20] <popey> Snap-Inception!
[16:20] <kgunn> anyone ever seen something like this?
[16:20] <kgunn> Sep  6 16:19:57 localhost ubuntu-core-launcher[3625]: *** buffer overflow detected ***: /snap/mir-client/x1/usr/lib/aarch64-linux-gnu/qt5/examples/quick/demos/clocks/clocks terminated
[16:20] <mvo> slangasek: is it bytes? it seems like its blocks or something, when I look at the .disks dir its not 16 bytes :)
[16:20] <ogra_> slangasek, there is supposed to be some external switch later to switch it on ... current images wont run it
[16:21] <mvo> slangasek: well, I guess it does not matter, its wrong, thats for sure in the gadget.yaml
[16:21] <kgunn> e.g. is that the ubuntu-core-launcher complaining?
[16:21] <kgunn> or mir-client
[16:21] <slangasek> ogra_: and then what happens when we turn cloud-init back on in a later version of ubuntu-core, and we have all these deployed images in the wild with no cloud-init preseed?
[16:21] <bulldog> popey, ppa:keshavnrj/snpacraft-gui if u wana try it :)
[16:21] <popey> bulldog: maybe later, thanks
[16:21] <bulldog> np
[16:22] <slangasek> for that matter, how are we supposed to produce a working cloud image for testing without the use of cloud-init?
[16:22] <ogra_> slangasek, we wont turn it on in core
[16:22] <ogra_> slangasek, u-image or the gadget will toggle that
[16:22] <ogra_> so only if you build a new image from scratch you can have cloud-init
[16:22] <slangasek> hmm, ok
[16:22] <slangasek> I guess that works
[16:22] <ogra_> and then apply the config correcvtly
[16:22] <slangasek> mvo: <cough> rounding
[16:22] <ogra_> so we dont need all these workarounds we used to have
[16:23] <Fl1nt> ogra_, slangasek, please don't remove cloud-init from ubuntu-core as a way to programatically provision such a node before having at least provided an alternative tool :-(
[16:23] <mvo> slangasek: LOL
[16:23] <slangasek> mvo: it's quite possible the dragonboard snap will still fail even after we fix the definition, there *may* be some assumptions in the current code that partitions will always be multiples of 1M in size
[16:23] <ogra_> Fl1nt, it isnt removed, only disabled ...
[16:23] <mvo> slangasek: yeah, I think I saw that in the code
[16:23] <Fl1nt> ah, ok, didn't understood it that way :D
[16:24] <ogra_> Fl1nt, it caused unbearable boot times and lots of issues on the actual images
[16:24] <Fl1nt> is a gadget a preferred way to provision a specific ubuntu-core flavored node?
[16:24] <Fl1nt> +using
[16:24] <ogra_> the gadget is your image definition
[16:24] <slangasek> ogra_: were there unbearable boot times separate from us not having the cloud-init metadata in place telling it not to go wandering around the network?
[16:25] <zyga> tyhicks: will you have the tie
[16:25] <zyga> tyhicks: will you have the time to review the ns sharing patch today?
[16:25] <ogra_> slangasek, well, you never booted a beaglebone image ;) but no this specific one was the network thing
[16:25] <Fl1nt> Ok, so I'll try to change the way I create my ubuntu-core images
[16:25] <ogra_> taking about 5mins to time out every boot
[16:26] <ogra_> Fl1nt, there will only be one way :)
[16:27] <ogra_> Fl1nt, you will have your specific gadget for cloud images ... and that will also allow you to apply your cloud-init config
[16:27] <Fl1nt> No, I mean, the way I start a node with a default ubuntu-core for x86 and then use cloud-init to specialise it. I'll rather use a gadget to describe my final intended image
[16:27] <slangasek> ogra_: ok, well, it seems odd to me that a decision was made to make cloud-init enablement a toggle, adding another layer of complexity to the system, when the fix for that cloud-init behavior on top of u-i was in progress
[16:28] <ogra_> slangasek, but there is no good reason to use cloud-init at all for images that dont have cloud specific setups
[16:28] <ogra_> slangasek, console-conf gives us all we need
[16:28] <ogra_> for images on real HW at least
[16:29] <slangasek> ogra_: console-conf gives you the interactive experience, it doesn't give you the preseeded-in-the-image experience
[16:29] <ogra_> andf on the arm images it really slows down the boot to run cloud-init
[16:29] <ogra_> (and tit runs *every* boot)
[16:29] <slangasek> well, ok
[16:29] <slangasek> but "it runs every boot" should be fixed, not papered over
[16:30] <ogra_> i thought thats a design thing
[16:30] <ogra_> you can not have it not run
[16:30] <slangasek> and now you will have to separately say "yes, turn on cloud-init" and "here's some image pre-configuration to be passed into cloud-init"
[16:30] <zyga> is there any desire to rewrite cloud-init in C or something similar?
[16:30] <slangasek> I don't believe it's a design decision
[16:31] <Fl1nt> zyga: an alternative from CoreOS written in GOlang is available
[16:31] <ogra_> slangasek, well, if i want non-interactive config i need cloud-init
[16:31] <zyga> Fl1nt: is it feature complete/
[16:31] <ogra_> and the gadget should define that
[16:32] <Fl1nt> zyga: so far from my (little) experiments it is.
[16:32] <Fl1nt> It can manipulate network, files, payloads, systemd etc
[16:32] <slangasek> Fl1nt: however, we are defining new cloud-init schemas as part of snappy for things that don't previously exist
[16:33] <Fl1nt> ah, didn't know that :)
[16:33] <slangasek> in general, cloud-init is actively developed, so switching implementation languages is not as simple as just grabbing one from somewhere else
[16:34] <ogra_> slangasek, in any case ... whatever we release as RTM doesnt really matter ... niemeyer told me yesterday that it is fine if users have to re-flash to get to GA so even if we go fully back to cloud init oon the fly thats fine ... users will then have to re-flash
[16:34] <ogra_> (contrary to how i understood RTM i.e. that there wouldnt be any re-flashes anymore)
[16:35] <slangasek> ogra_: "RTM" being "release to manufacturer", how is it fine for upgrades to require re-flashes again?
[16:35] <niemeyer> ogra_: I didn't say it was fine.. I said we would do it if we really had to, but we're trying not to
[16:35] <ogra_> so we seem to have all wiggle room we might need
[16:35] <slangasek> ah, I see the message has been diluted by a game of telephone ;)
[16:35] <ogra_> hmm
[16:37] <mvo> ogra_: meh, now I get an "sbl1.mbn : permssion denied error" when building the dragonboard
[16:37] <ogra_> huh ?
[16:38] <ogra_> permission denied ?
[16:39] <niemeyer> slangasek: We don't (I don't, at least) expect those images to be in final devices, btw.. I'm not a fan of RTM/GA language, but I lost that specific argument
[16:39] <ogra_> the file is world readable in the gadget
[16:40] <slangasek> niemeyer: hmm, ok
[16:41] <tyhicks> zyga: I think jdstrand was going to try to help you out with reviews - do you want me to look at that specific one?
[16:42] <zyga> tyhicks: either of you should look at it, jdstrand said he will in a couple of hours
[16:42] <zyga> tyhicks: I just want to know someone will soon, that's all
[16:42] <jdstrand> well, I said in a little bit
[16:42] <jdstrand> I suspect it will be sooner than that when I will start :)
[16:44] <tyhicks> zyga: we'll make sure that at least one of us have a look today
[16:44] <zyga> thanks guys :)
[16:45] <bulldog> mhall119,  hi :)
[16:46] <jdstrand> zyga: so, mountinfo module is merged. the lxc pivot_root is closed. the new pivot_root is merged. the one you want to have us look at is https://github.com/snapcore/snap-confine/pull/126 (cc tyhicks) ?
[16:46] <mup> PR snap-confine#126: Add support module for namespace sharing <Created by zyga> <https://github.com/snapcore/snap-confine/pull/126>
[16:46] <zyga> jdstrand: yes
[16:46] <jdstrand> ok
[16:46] <zyga> jdstrand: thats the essence, the stuff following up after that will be trivial applications of those functions in main()
[16:47] <mhall119> hello again bulldog
[16:48] <bulldog> wow :P mhall119  i thought u not here
[16:49] <bulldog> mhall119, i made ppa for snapcraft-gui on launchpad , which auto build code from github
[17:04] <sborovkov> Hello. Just tried installing snap from the private store. And had this - panic: user: unknown userid 1000. There is also stack trace. Is this like known issue? (snap did install in the end though)
[17:08] <sborovkov> Oh cool. This made system go crazy as well. Login service's no starting after restart.
[17:09] <mhall119> sborovkov: what private store are you referring to?
[17:09] <Fl1nt> ok guys, have to been AFK a while, see you and many thanks for those intels ;-)
[17:09] <mhall119> and what package did you install?
[17:10] <ogra_> mhall119, i bet one from his company store :)
[17:10] <sborovkov> indeed
[17:10] <sborovkov> I think I've been running in this for couple of days already. Before did not see it in real time
[17:10] <sborovkov> but after restart login service would hang and refuse to start
[17:11] <sborovkov> and I can't even switch TTY with attached keyboard.
[17:11] <ogra_> sborovkov, the ubuntu user was dropped ... (though if you upgraded the entry should still be there) and the login prompt gets intercepted now until you ran the manual configuration tool
[17:11] <ogra_> sborovkov, if you hit enter you should get into a config dialog
[17:11] <mup> PR snapd#1858 opened: interfaces: add stub selinux backend <Created by zyga> <https://github.com/snapcore/snapd/pull/1858>
[17:12] <sborovkov> ogra_: hmm. problem is my snap shows full screen now. Can't see anything besides that. So ubuntu user is dropped on classic as well?
[17:12] <ogra_> (though the new user this sets up will not have a local login ... )
[17:12] <sborovkov> How do I run manual config tool?
[17:13] <ogra_> we never had an ubuntu user on classic :)
[17:13] <jdstrand> _morphis: fyi, I left feedback in https://myapps.developer.ubuntu.com/dev/click-apps/5870/
[17:13] <ogra_> sborovkov, good question ... i dont think anyone took into account that there could be a snap grabbying the tty before the console-conf tool can run
[17:13] <jdstrand> roadmr: hey, can you pull r737? this is semi-urgent. there were a couple of debug print statements that I think trip up the store
[17:13] <sborovkov> ogra_: o_O are you sure there was no such user
[17:14] <ogra_> yes
[17:14] <ogra_> unless you create it
[17:14] <sborovkov> ogra_: I mean I just flashed that image and logged in with ubuntu/ubuntu
[17:14] <roadmr> jdstrand: ooh sure
[17:14] <ogra_> classic usually runs an installer or an oem configurator that allows you to pick your own user name
[17:15] <jdstrand> _morphis: fyi ^
[17:15] <ogra_> either the debian-installer for non graphical or ubiquity fo rgraphical installs
[17:15] <sborovkov> ogra_: hmm. alright. https://wiki.ubuntu.com/ARM/RaspberryPi I was always using ssh ubuntu@pi. And logging in to it without any issues. Hmm
[17:16] <sborovkov> ogra_: Ok, so I guess I will just reflash, upgrade, run console-conf? And it should work, right?
[17:16] <ogra_> sborovkov, well, i'm talking about snappy based images ...
[17:16] <ogra_> classic images have not changed
[17:17] <sborovkov> ah.
[17:17] <ogra_> (though it is weird that yours have an ubuntu user ... smells wrong to me)
[17:17] <sborovkov> ok. though you were talking about classic since I had this on classic.
[17:17] <ogra_> (but perhaps it is like tha, i havent used a classic image on a pi)
[17:18] <sborovkov> alright thanks
[17:18] <sborovkov> oh well I have to reflash anyway. can't get to tty there
[17:18] <ogra_> (you should really mention that you run classic in the beginning, i dont think anyone expects that in here)
[17:19] <sborovkov> Sorry, I thought I did. Now looking at it I mention it midway in conversation in 1 place.
[17:19] <ogra_> (even though we recommended that as an interim solution for a while ... we're all focused on snap based images :) )
[17:41] <mup> Bug #1620635 changed: libapparmor's aa_query_label() always returns allowed = 0 for snaps <AppArmor:Confirmed> <Snappy:Won't Fix> <apparmor (Ubuntu):Confirmed> <https://launchpad.net/bugs/1620635>
[17:50] <mup> Bug #1620755 opened: x509: certificate signed by unknown authority <certificate> <Snappy:New> <https://launchpad.net/bugs/1620755>
[17:51] <SamYaple> I am a bit confused as to how to use the 'dump' plugin rather than the 'copy' plugin. is the idea that now an outside process with move the appropriate files into the */prime directory in appropriate place?
[17:52] <SamYaple> is there an example I can reference?
[17:55] <popey> SamYaple: i would continue using the copy plugin for now. the dump plugin has a couple of significant bugs, which should be fixed in snapcraft 2.17 I believe
[17:55] <SamYaple> popey: threw that deprecation warning in there early then?
[17:56] <popey> perhaps :)
[17:56] <SamYaple> :) thanks
[18:27] <mup> PR snapd#1854 closed: cmd/snap: generate account-key-request "since" header in UTC <Created by cjwatson> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1854>
=== JanC is now known as Guest18007
=== JanC_ is now known as JanC
=== chiluk_ is now known as chiluk
[20:44] <mup> Bug #1620771 opened: /home symlink, snaps don't work <link> <snap> <symlink> <Snapcraft:Invalid> <Snappy:New> <https://launchpad.net/bugs/1620771>
[20:44] <mup> Bug #1620815 opened: Test failures in github.com/snapcore/snapd/cmd/snap at 0187d66 <Snappy:New> <https://launchpad.net/bugs/1620815>
[20:47] <kgunn> kyrofa: yo, was poking around for best way to deal with arch in building my snap helper files
[20:47] <kgunn> found this
[20:47] <kgunn> http://askubuntu.com/questions/757668/how-to-build-multi-arch-snaps
[20:48] <kgunn> is dpm's method still the state of the art?
[20:48] <kgunn> or is there something else
[20:48] <mup> PR snapd#1853 closed: osutil: call sync after cp if requested. overlord/snapstate/backend: switch to use osutil instead of another buggy call to cp <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1853>
[21:13] <mwhudson> good morning
[21:13] <mwhudson> how on fire is everything today
[21:13] <SamYaple> matchstick
=== zeroedout_ is now known as zeroedout
[21:54] <niemeyer> mwhudson: Nicely on fire ;)
[21:55] <sam__> is there documentation to us webdm's "setting" tab to configure an application? (if anyone knows webdm)
[22:00] <zyga> mwhudson: o/
[22:00] <zyga> mwhudson: have a good day :)
[22:03] <zyga> jdstrand: thanks for the review!
[22:06] <zyga> github seems to be having some issues noiw
[22:07] <mcphail> Can I poke someone (anyone) about https://bugs.launchpad.net/snappy/+bug/1574851 ? Graphical snaps are still not running with nvidia proprietary drivers. It would be great to get this fixed
[22:07] <mup> Bug #1574851: libgl not found on nvidia machines (so far) <Snappy:Triaged> <nvidia-graphics-drivers-361 (Ubuntu):Confirmed> <https://launchpad.net/bugs/1574851>
[22:12] <zyga> jdstrand: ha,
[22:12] <zyga> jdstrand: I was trying to reply to your comment on O_EXCL on the lock file and github kept failing
[22:12] <zyga> jdstrand: now i know why :D
[22:12] <zyga> jdstrand: you removed that comment, right?
[22:14] <jdstrand> I did
[22:15] <jdstrand> that was a not seeing the forest for the trees comment that tyhicks called me on :)
[22:16] <zyga> jdstrand: I acked a few things, thanks a lot for the review! I will go over everything first thing tomorrow
[22:16] <jdstrand> but there is a 3rd O_EXCL comment that still applies (not to use it, but why not to use it)
[22:16] <jdstrand> zyga: yw :)
[22:16] <zyga> yes, I saw, on the mnt file
[22:16] <zyga> all in all, I think this is somewhat tricky code
[22:16] <jdstrand> indeed
[22:16] <zyga> I was worried about the child setting the parent process death signal a bit too late in pathalogical cases
[22:17] <jdstrand> which is why an abundance of comments is good (which you've already done btw :)
[22:17] <zyga> but there's no way, that I can see, to protect against that, since this prctl knob is reset across fork
[22:17] <mwhudson> niemeyer: anything i can help with?
[22:17] <zyga> :-)
[22:32] <mup> PR snapd#1859 opened: daemon: bail from enable and disable if revision given, and from multi-op if unsupported optons given <Created by chipaca> <https://github.com/snapcore/snapd/pull/1859>
[23:34] <mup> PR snapd#1859 closed: daemon: bail from enable and disable if revision given, and from multi-op if unsupported optons given <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1859>
[23:36] <niemeyer> mwhudson: Actually, maybe :)
[23:37] <niemeyer> mwhudson: But the problem is a bit blocked on design
[23:37] <mwhudson> niemeyer: that seems to be a common theme!
[23:37] <niemeyer> mwhudson: we need to create a mechanism to have local users on ubuntu-core that do not depend on network
[23:38] <mwhudson> niemeyer: fwiw slangasek is trying to / going to try to set up a call between the three of us in the next couple of days
[23:38] <mwhudson> niemeyer: ah right
[23:38] <slangasek> oh, niemeyer is still around
[23:39] <niemeyer> slangasek: Yeah.. I have wine next to me though, so I might not be entirely trustable
[23:39] <slangasek> niemeyer: does that just mean "preserve the capability of cloud-init for local users"?
[23:39] <niemeyer> slangasek: Hmm
[23:40] <slangasek> I wouldn't expect to let someone set up a local account via console-conf, for instance
[23:40] <niemeyer> slangasek: Right, that's the trickery
[23:40] <niemeyer> slangasek: .. and why I don't have a great answer
[23:40] <niemeyer> slangasek: We want to solve the problem without opening a hole
[23:41] <mwhudson> niemeyer: this is the thing where the long term answer is providing an assertion from the store somehow?
[23:41] <slangasek> ok; so would it be possible to have a call this week to flesh out the design, to unblock mwhudson?
[23:42] <niemeyer> mwhudson: No, it's a more mundane problem.. someone that is cooking the actual device notices a problem and wants to debug it
[23:42] <slangasek> right
[23:43] <niemeyer> mwhudson: Talking to the network inside a factory is generally unreasonable..
[23:45] <mwhudson> ah