=== JanC_ is now known as JanC [00:50] PR snapcraft#777 opened: go plugin: don't put debugging symbols in generated binaries [03:16] Bug #1621304 opened: In the profile setup, pressing enter after filling the email address does nothing [03:22] does anyone have a nodejs snappy sample for reference in addition to the "shout" on in the demos? thanks === chihchun_afk is now known as chihchun [05:38] Bug #1621323 opened: On the all-snaps image, the snapweb interfaces are not connected === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:18] mvo, tvoss, I heard something about dbus session bus support or something. Is there something being baked related to that? [06:24] hey Kaleo_ - no dbus session bus work is happening currently from the core team afaik, is that something important for you/your team? [06:24] mvo, I think so [06:24] mvo, wwho is the core team? [06:24] -w [06:33] Bug #1621339 opened: Unable to complete UC16 beta first boot if ESC is pressed after last step [06:33] hey mvo! Great job for yesterday's image! I'm curious if you think we'll have a snapd release today with the "revert fix" we discussed about the other day? As this is the last day for us to prepare the image for Monday's event [06:35] mvo, I've uploaded a i386 snap of test-snapd-thumbnailer-consumer (there was only an amd64 version): is that the right way to support multiple archs? automated review failed, can you let it through? [06:35] Kaleo_: the most important person to talk to would be gustavo as he will design the feature. however he/we are busy with the "ga" release [06:35] https://myapps.developer.ubuntu.com/dev/click-apps/5863 [06:35] Kaleo_: yes and yes [06:35] thanks [06:35] mvo, great [06:36] Kaleo_: feel free to join our standups to talk about specific feature you need [06:36] didrocks: pavel was working on this last I checked, give me a minute to look over the open PRs [06:36] thx! [06:37] didrocks: I really would love to do something for you, even something cheap and hackish like "revert --devmode" so that it preserves the flag, chippaca was also looking at it, but because of the image rush I did not pay too much attention [06:37] Kaleo_: approved, enjoy [06:37] mvo, thank you :) [06:38] mvo: yeah, I guess it. But indeed, I can hide the --devmode typing quickly when doing the revert and that would work (even if snapd is only in -proposed, I can install my image with it) ;) [06:39] didrocks: lets keep talking over the course of the day, at this time most people are still sleeping :) at least the relevant ones [06:39] Kaleo_: my pleasure! [06:39] I will promote the candidate ubuntu-core images to stable very soon, so if people want to do last minute tests on those :) [06:40] mvo: ok, I'll let you just ping me once people are ready for this :) [06:41] mvo: does it has reexec? that case, I'll need to ensure I'm adding the magic variable to /etc/environment in case I have to use snapd from -proposed (and so, the package version) [06:43] didrocks: the version in xenial-updates that got promoted yesterday has re-exec disabled [06:43] didrocks: because the sru process is now working really well for us and also because it causes some hard to understand behavior [06:43] ok! [06:44] Kaleo_: we don't need the core Team right now to unblock your work, I'm getting a coffee refill right now, will be online in a few [06:45] tvoss, COFEE [06:45] +F [07:01] Kaleo_: the core team, so Jamie specifically is aware of our requirements, let's coordinate a little on what we put on their plate [07:01] Kaleo_: for the time being, we will unblock you and get you a session dbus in a classic environment [07:02] hey hey [07:02] tvoss, sounds good [07:03] tvoss, and that means DBUS_SESSION_BUS_ADDRESS needs to be set right? [07:03] Kaleo_: yeah, we are taking care of that stuff [07:03] Kaleo_: I think we can have something be eow [07:03] by, even [07:03] tvoss, ok [07:19] PR snapd#1816 closed: libvirt interface to allow snaps to access libvirtd on a classic host [08:07] hmpf ... so the grade hackery didnt help [08:07] all ubuntu-core snaps are stuck :( [08:22] ogra_: yeah [08:22] ogra_: if you could give the pi3 image a quick try, that would rock [08:22] i'll take a deeper look into patching our snapcraft [08:22] mvo, both downloading atm ... i only get 200k/s from cdimage for some reason :/ [08:27] anyone versed in glib-test, is ther any sanity into how -p and -s options work for selecting tests to run [08:27] mvo: guten Morgen [08:27] they seem to do nothing sensible at all, I'm trying to follow the source to see what's going on [08:28] a simple test on some-unit-test-binary -s /stuff-to-skip/ just does nothing and runs all tests with that prefix [08:28] similarly to -p [08:28] ogra_, mvo: IIRC you could reproduce bug 1620559, right? would you mind telling your testing result to it, so that we can mark it v-done? [08:28] Bug #1620559: /etc/resolv.conf is empty on snappy

[08:28] some values of -p seem to work but the exact criteria are eluding me, it seems the number of slashes in the test name is relevant [08:29] mvo: does networking behave now? [08:29] pitti, it does [08:29] (I guess RTM day wouldn't be the worst day for it to behave :) ) [08:31] pitti: its working fine, thanks again [08:32] pitti, set to verification-done [08:32] danke [08:37] PR snapd#1867 opened: fix incorrect number of implicit interfaces [08:51] Bug #1621378 opened: console-conf should tell the user that the keyboard is US only [08:54] Bug #1621380 opened: console-conf should allow to configure a hostname [08:56] mvo: did you figure out the GOARM problems in the end? [08:56] sergiusens: please! https://bugs.edge.launchpad.net/ubuntu/+bug/1621382 [08:56] Bug #1621382: launchpad building with stage packages broken [08:56] mwhudson: which one of them ;) [08:57] mwhudson: but yeah, after some mild panic attacks we got a images [08:57] mwhudson: network was broken in between and similar but we got it all under control [09:00] mvo, hmm, why did my pi3 just get an ubuntu-core update in the middle of installing the classic snap ? [09:00] eeek ! [09:00] ogra@localhost:~$ snap list [09:00] Name Version Rev Developer Notes [09:00] classic 16.04 14 canonical devmode [09:00] ubuntu-core 16.04.1 424 canonical - [09:00] ogra@localhost:~$ [09:01] mvo, something is wrong with the pi3 image [09:02] ogra_: no kernel? [09:02] ogra@localhost:~$ systemctl status snapd.firstboot.service [09:02] ● snapd.firstboot.service - Run snappy firstboot setup [09:02] Loaded: loaded (/lib/systemd/system/snapd.firstboot.service; enabled; vendor preset: enabled) [09:02] Active: failed (Result: exit-code) since Wed 2016-09-07 21:07:19 UTC; 11h ago [09:02] Main PID: 1448 (code=exited, status=1/FAILURE) [09:02] ogra_: snap change 1? [09:02] ogra@localhost:~$ snap change 1 [09:02] Status Spawn Ready Summary [09:02] Done 2016-09-07T21:07:20Z 2016-09-08T08:45:05Z Generate device key [09:02] Done 2016-09-07T21:07:20Z 2016-09-08T08:45:14Z Request device serial [09:03] ogra_: snap change 2 :) [09:03] thats already the "install classic" call [09:03] no trace of firstboot in snap changes [09:03] ogra_: nothing from firstboot? weeeeh [09:03] also no complaint about a missing model assertion [09:03] very weird [09:04] mvo, dragonboard is fine though ... [09:06] mvo: the hwcap / "please recompile with GOARM=5" one was the one i meant [09:06] mwhudson: oh, yes, that is the libc aux vector getting srubed by apparmor and that contains the information about the availabity of a floating point unit [09:07] ah ok [09:07] yes, sounds about right [09:07] mwhudson: tyler and jamie know the even more gorry details [09:07] but I think this is pretty much it and I changed the apparmor confinment to allow this vector to get passed unchanged [09:08] yeah, go uses it for quite a few things [09:48] elopio: I've fixed the tests for PR #777 [10:10] PR snapd#1867 closed: fix incorrect number of implicit interfaces === hikiko is now known as hikiko|ln [10:56] mvo: could you subscribe snappy-dev to https://bugs.launchpad.net/ubuntu/+source/golang-github-coreos-go-systemd pls? (for MIR) [11:00] hi [11:00] I got this error error: cannot find signatures with metadata for snap when I try to test my snap package [11:00] didn't get this error before [11:01] use the --dangerous option [11:01] i assume you try to do a snap install ? [11:01] yes [11:02] yeah, then use that for snaps not signed by the store [11:02] The Ubuntu Core beta image for Rpi2 is pretty fun. :) [11:02] Is there a story for wireless networking yet? [11:03] ogra_: error: unknown flag `dangerous' [11:03] nhaines, console-conf does not support it yet (it is in the pipe) [11:03] ogra_: "in the pipe" is good to know. [11:03] snapweb didn't work at all for me. [11:03] And 'snap find' is broken now. [11:03] nhaines, you can cheat indeed and put a config into /etc/netwotrk/interfaces.d/wlan0 (and reboot) [11:03] broken ? how ? [11:03] ogra_: now *that* is exactly what I wanted to know. :) [11:04] ogra_: it used to list all snaps; now it simply returns an error. [11:04] thats by design ;) [11:04] not broken [11:04] It is a regression and probably a bad design. ;) [11:04] Although I'm sure it wasn't scalable. [11:04] snap find can only show 100 snaps ... but the sotre has more [11:05] This makes it impossible to discover snaps, though. [11:05] (So I hope design is on it sometime.) [11:05] well, if you have 1mio snaps one day you realyl dont want them listed :) [11:05] ogra_: sure, that's what `less` is for. ;) [11:06] sure ... but the less would only start after retrieving lines for 2h :P [11:06] (and probably cause an OOM) [11:06] :) [11:07] So there are problems. But I was able to have Nextcloud running in all of 30 seconds and I didn't have to do any of that pesky installation or dependencies or configuration. So there's that! [11:08] Should snapweb still be listening on port 4200? [11:08] it should ... but it has bugs and fails to start currently [11:08] btw... wlan -> http://paste.ubuntu.com/23149789/ [11:08] Okay, currently broken, that's good to know, too. [11:09] I'm not certain that "pull all keys from Launchpad" is a "real world" solution, but I'll be damned if it wasn't absolutely perfect for me. :D [11:09] it will auto-update to a fixed version ;) [11:09] Yes, benefit of snappy. ;) [11:11] Although I sort of feel like "wireless networking setup and web administration don't work right now" could have been in the release notes. :P [11:12] But I've been having plenty of fun with snapd on the desktop, and seeing Ubuntu Core 16 start to really take shape is very exciting! [11:12] nhaines: do you want to try a bootleg core snap that might let you configure wifi? :) [11:13] mwhudson: yes, sounds like fun. :) [11:13] Particularly because if it doesn't work I can file a bug and jump back to the beta release. :) [11:14] well, not sure you can actually sideload ubuntu-core easily [11:14] i think we block that [11:14] i think this would be a "make new image and reflash" sort of test [11:14] Not with that attitude! [11:14] heh [11:14] builds started on https://launchpad.net/~canonical-foundations/+snap/snappy-first-boot anyway [11:14] snappy = safety first :) [11:14] now I launch my package and I got "failed: cannot list snaps: access denied" ? [11:15] gouchi, wow, thats a weird one [11:15] havent seen that before [11:15] The real fun of snaps is that betatesting is really painless because reverting to known-good images is as fast as your disk controller. [11:15] yeah [11:15] gouchi: if you're on a classic desktop Ubuntu, try "snap login" again. [11:16] nhaines, well, that should work without [11:16] there must have been some changes to snapd because I could test my package [11:16] unless gouchi's snap calls "snap list" [11:16] internally [11:16] no it doesn't [11:17] yeah, i assumed so [11:17] if you just call snap list manually, does it also throw that error ? [11:17] error: cannot list snaps: access denied [11:17] wow [11:17] is that on desktop ? [11:17] strange I must have done something wrong during my installation [11:18] or "classic" [11:18] I am running on ubuntu 16.04 desktop [11:19] I just followed as usual the installation process here : https://github.com/snapcore/snapd [11:20] you mean you built snapd from source ? [11:20] PR snapd#1868 opened: Support revert flags [11:20] ogra_: yes [11:20] ogra_: sorry for the noise there was wrong permission on /run/snapd.socket [11:21] dont you trust our packages ? :) [11:22] I try time to time the package if it is working but still failed [11:23] I don't understand because opengl software are working [11:29] if somebody wants to look here my snapcraft.yaml and wrapper with the log http://www.hastebin.com/xajesehica.coffee [11:30] I know I should use dump plugin instead of copy ;-) [11:35] ogra_: hmm, /etc/network/interfaces.d/wlan0 didn't seem to work. [11:35] nhaines, i used it on my pi3 and dragonboard [11:36] on a WPA2 network [11:38] Quoting my SSID and trying again. :) [11:38] PR snapd#1869 opened: cmd/snap: serialise empty keys list as [] rather than null [11:40] jdstrand: hey, around? [11:42] Hmm, still nothing. [11:43] any errors ? [11:43] I see in dmesg where the devices was renamed from wlan0. But not where to. [11:43] renamed ? [11:43] well, use your wired connection to debug :) [11:43] [ 15.286248] rtl8192cu 1-1.3:1.0 wlx74da386871f1: renamed from wlan0 [11:43] uuuh [11:44] ogra_: yes, that's what I'm doing. Althuogh... [11:44] realtek [11:44] My ifconfig-fu is now weak. [11:44] thats a USB wlan card, attached externally, right ? [11:44] Yes, I bought it specifically because it works on the RPi2 with no special drivers--particularly with Ubuntu MATE. [11:44] ogra_: correct. [11:45] i bet we dont have the firmware [11:45] Hmm, schade. :) [11:45] check in lsmod if a module is loaded for it [11:45] and grep in syslog for that module name [11:45] i bet you find some error about missing firmware files [11:45] if so, file a bug and let ppisati know about it [11:46] Hmm, rtl8192cu, rtl_usb, rtl9281c_common, and rtlwifi are all loaded. [11:46] that looks ok then [11:46] cat /proc/net/dev ? [11:46] No errors in syslog. [11:47] well, if it was renamed, you need to rename the config file and the name of the device inside [11:47] Oh, it lists wlx74da386871f1. zeros all across. [11:47] Hmpf. :) [11:47] right .. [11:47] these are the new "predictable" network interface names :) [11:48] ask lennart poettering whats predictable about them though :P [11:48] and indeed, it will only work if you pronounce the name three times in a row aloud [11:49] Well, we'll see in 30 seconds I suppo! [11:49] suppose! === dpm_ is now known as dpm [11:54] ogra_: well, that worked! So now my RPi2 running snappy is twice as useful. ;) [11:55] Welll, I suppose I learned something new with /proc/net/dev. Thanks very much for helping me troubleshoot that. :) [11:55] adjust program to write to $SNAP_DATA or $SNAP_USER_DATA because the software needs to read/write in ~/.config [11:55] Also, just imagine me shaking my fist at Lennart Poettering. [11:56] So we need to patch the software to use those env variables ? [12:01] mvo, pedronis: where can people who want to generate an image for supported devices (pi, dragonboard) get a model assertion from? Do they have to always generate one on their own or is it possible to fetch the official signed one from somewhere? [12:02] nhaines, heh, glad it worked [12:02] morphis, afaik thats still in the works, there will be a way to get it generated via the store or LP or so [12:03] ogra_: now to figure out how to change the hostname. Although I do want to file a bug that nano isn't around. :P [12:03] ogra_: ok, so for now I have generate my own one or take it from "somewhere" [12:03] morphis, if you want to do basic boot testing you can use UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL=1 with ubuntu-image [12:03] ah [12:03] so I still need one but can use without signature [12:04] morphis, note though that will only help with boot stuff ... snap commands will not work in the booted image [12:04] ogra_: hm [12:04] (firstboot will refuse to run without a signed model assertion) [12:05] morphis: its possible to get it from the store, it will be in the assertion store in a bit, I can mail you one in the mantime [12:06] mvo: got the pc.model already from your snapd PR [12:06] but was wondering about one for the pi2/pi3 [12:10] well, we need a way to use self signed ones [12:10] since what mvo will give you will be the official canonical assertion ... [12:10] whihc makes your home built images kind of official :) [12:12] seb128: hey [12:12] PR snapd#1870 opened: store: ensure the payment methods method handles auth failure [12:12] seb128: do you know who manages snapd-xdg-open on github? I have a few things pending there without reply [12:15] zyga, hey, attente did most of the work and mvo helped with review&landing I think [12:18] zyga, I don't understand your "package for <...>" issues reports [12:19] zyga, distributions doing packaging isn't an upstream issue [12:19] PR snapd#1871 opened: snap: lessen annoyance of implicit interface tests [12:24] ogra_: yeah [12:24] ogra_, mvo: so what is the one in https://github.com/mvo5/snappy/blob/c230019df76d27ce7c67f3003e1c0ca945030c2d/tests/lib/prepare.sh signed with? [12:25] ogra_: and with that we basically require people to create their own model assertion when they want to build an image which is different to the official one [12:25] exactly [12:26] PR snapd#1869 closed: cmd/snap: serialise empty keys list as [] rather than null [12:27] ogra_: good [12:35] attente: hey, around? could you please add me to snapd-xdg-open on github / review branches [12:36] seb128: the package bugs are just so that we have downstream packages for all the distros [12:36] zyga, that's not an upstream issue... [12:36] seb128: I agree it's not an upstream issue but this is an easy way to track it [12:36] * seb128 sends zyga some postits [12:36] with passwords on them ? [12:37] * seb128 writes "ubuntu/ubuntu" on the postits [12:39] but.. I have all the ubuntu stickers already [12:40] zyga, is there any change you need to commit? I had a look and you don't have anything major there, having an empty README is probably not bothering many people [12:40] or is that to get a 0.1 tarball out? [12:40] seb128: correct [12:40] seb128: this blocks the fedora package [12:40] why? [12:40] PR snapd#1872 opened: tests: use in-tree snap{ctl,-exec} for all tests [12:40] they for sure have git snapshot packages [12:40] seb128: because snapshot vs release packaing [12:40] that's a lame excuse [12:40] seb128: and we should just release [12:41] zyga: hey [12:41] you could grab the package .tar.gz and claim that a release [12:41] jdstrand: hello, nice to see you [12:41] seb128: no, that's not how fedora packaging works [12:41] seb128: anyway, this is a moot discussion [12:41] right [12:41] zyga: you too :) [12:41] jdstrand: I did plenty of updates to the ns-support module [12:42] zyga, well I know if some desktop packages they have that are git snapshot so it's a lame argument to block things they don't want I guess [12:42] jdstrand: there are still a few things but I was wondering if we can merge it and iterate (after a 2nd review with the new changes) [12:42] zyga, but as you said, no point arguing, easy enough to roll a tarball [12:42] zyga: ok, I'll take a look [12:42] let me get through email for anything urgent [12:42] seb128: I mean, I could do a snapshot realease but I really don't want to, part of what I need to do is to ensure that all the distros ship the same thing and it is easier with versions [12:43] right [12:43] jdstrand: I'd like to propose a small branch that actually uses it, along with some simple spread tests, and let people play with the real thing [12:44] seb128: I should also ITP snapd-xdg-open in debian [12:44] Bug #1564369 changed: sudo broken in latest classic [12:44] jdstrand: there will be a change to snap-confine and a new executable snap-discard-namespace [12:44] jdstrand: (not setuid root!) [12:45] zyga: hey, sorry, but i don't have write access to that repo either [12:46] attente: oh, interesting [12:46] so who does? :) [12:46] mvo: FYI, I wrote what-is-mounted that prints json with all the details based on mountinfo [12:46] zyga: should be didrocks and mvo [12:46] I think grep and awk are ok but if we ever need something more complex we should perhaps think about it [12:47] didrocks: do you have commit access to snapd-xdg-open on github.com/snapcore/snapd-xdg-open? [12:47] whoa [12:48] how did the libvirt interface go through without security review? [12:48] zyga, mvo: ^ libvirt should not auto-connect [12:48] well, security ... who cares :P [12:48] it gives a direct path to root [12:48] just like lxd and docker [12:49] jdstrand: should it it auto-connect but be restricted? [12:49] * ogra_ pushes code for an nsa interface that auto-connects ... lets see :P [12:49] ogra_: make sure it doesn't show in snap interfaces [12:49] thats indeed the ppurpose :) [12:50] zyga: there are choices to be made, sure. but there was no discussion or coordination on restricting it [12:51] zyga: there is nothing in snapd that limits its use to a certain snap atm. there is nothing in the review tools that would limit it (other than the fact that the review tools would warn cause it isn't a known interface yet (thank goodness for defensive tools)) [12:51] jdstrand: sure, I don't dispute the no-review part [12:52] it also doesn't have any comments on how much privilege it gives [12:52] jdstrand: sorry, I think this one was my fault. I will push a branch that removes the auto-connect [12:52] I thought there was an understanding that all security policy went through a member of the security team? [12:52] ok [12:53] mvo, hey, do you know if the issue with rpi/vfp detection has already been solved? [12:53] abeato: yes, that is fixed [12:54] mvo, nice, thanks [12:55] mvo: if I comment on the original branch, will you incorporate the changes? (feel free to autoconnect now) [12:55] Hmm, I think the autopkgtest failures on https://github.com/snapcore/snapcraft/pull/726 are a test infrastructure bug of some kind - I already added snapd to Depends in debian/tests/control, but it doesn't appear to be being installed [12:55] PR snapcraft#726: Implement basic form of `snapcraft register-key` [12:55] mvo: err, feel free to make autoconnect false now [12:56] jdstrand: yes, PR on the way [12:56] jdstrand: sorry again [12:56] ok, thanks [12:56] PR snapd#1873 opened: interfaces: disable auto-connect in libvirt interface [12:57] zyga: added [13:01] didrocks: thank you! === pbek_ is now known as pbek [13:04] yw [13:14] mvo: shouldn't snapd rexec itself when I install the edge ubuntu-core snap on my desktop? [13:16] morphis: AFAIR we disabled this lately [13:17] unless you have exported the env var that prevents this it should [13:17] ogra@styx:~/Devel/branches/ubuntu-core-snap$ snap --version [13:17] snap 2.14.2~16.04+ppa224-1 [13:17] snapd 2.14.2~16.04+ppa224-1 [13:17] series 16 [13:17] ubuntu 16.04 [13:17] this is definitely not the binary from the installed package [13:17] but from ubuntu-core [13:18] zyga, ogra_: export SNAP_REEXEC=1 ? [13:19] well, you shouldnt need to export it ... [13:19] at least on my machines i get the in-ubuntu-core binary without any tinkering [13:20] if you want to suppress it you need export SNAP_REEXEC=0 though [13:20]