[00:08] <lifeless> mwhudson: o/
[00:09] <lifeless> mwhudson: is there an index of snaps ?
[00:09] <mwhudson> lifeless: there is https://uappexplorer.com/apps?type=snappy
[00:13] <lifeless> mwhudson: yeah, but its pretty useless AFAICT - this https://uappexplorer.com/apps?type=snappy&q=nginx&sort=relevance
[00:13] <mwhudson> lifeless: yeah no argument there
[00:13] <lifeless> mwhudson: or this - https://uappexplorer.com/app/apache2.mcaps - I can't figure out how to install that
[00:14] <mwhudson> lifeless: creation date suggests that's from the version 15 era
[00:14] <mwhudson> lifeless: this timezone is pretty bad for figuring out what's going on in the snappy world sadly
[00:39] <lifeless> mwhudson: thats sad; https://bugs.launchpad.net/snappy/+bug/1656976 is the next issue
[00:39] <mup> Bug #1656976: classic mode cannot start services <Snappy:New> <https://launchpad.net/bugs/1656976>
[00:41] <mup> Bug #1656976 opened: classic mode cannot start services <Snappy:New> <https://launchpad.net/bugs/1656976>
[06:10] <nhaines> Could I get someone to peek at my app spacedrive?  :)
[06:11] <nhaines> Also, the build failed (except for ppc64el) on Launchpad, which is odd because it's a script and some deb packages.
[06:15] <nhaines> Not sure if this is public or not... https://code.launchpad.net/~nhaines/+snap/spacedrive
[07:49] <mup> Bug #1657021 opened: Operator specified filesystem access <Snappy:New> <https://launchpad.net/bugs/1657021>
[07:55] <zyga> good morning
[08:03] <nhaines> zyga: good morning!
[08:37] <didrocks> Mirv: hey! did you see my ping yesterday about the new runtime?
[08:59] <mup> PR snapd#2641 opened: cmd: fix hardcoded paths to rst2man and support rst2man.py <Created by zyga> <https://github.com/snapcore/snapd/pull/2641>
[09:03] <didrocks> Mirv: Just did a PR for reference: https://github.com/ubuntu/snapcraft-desktop-helpers/pull/34
[09:03] <mup> PR ubuntu/snapcraft-desktop-helpers#34: Runtime refactor <Created by didrocks> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/34>
[09:20] <mup> PR snapd#2642 opened: tests: disable ipv6 before unpacking delta <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2642>
[09:41] <r2geo> Hello, hen building a snap, launchpad throws a GPG error that I suspect is a launchpad problem, not related to my script. Am I correct? It may be related to 1626739? https://paste.ubuntu.com/23815514/
[09:45] <tsdgeos> r2geo: you mean the F1831DDAFC42E99D warning?
[09:46] <r2geo> correct
[09:47] <r2geo> when I install on my pi3, it fails on: $ snap install openhab_r2geo_2.0.0.b4-7_armhf.snap
[09:47] <r2geo> error: cannot find signatures with metadata for snap "openhab_r2geo_2.0.0.b4-7_armhf.snap"
[09:47] <tsdgeos> r2geo: i understand you get that warning also "outside" of snap, right?
[09:48] <r2geo> ? sorry, I don't understand your question
[09:48] <tsdgeos> i you run apt-get update (i.e. nothing snap related)
[09:48] <tsdgeos> you also get that warning, right?
[09:49] <tsdgeos> should be fixed if you run something like
[09:50] <tsdgeos> sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys F1831DDAFC42E99D
[09:50] <tsdgeos> will you make trust the launchpad packages signed by that key
[09:50] <r2geo> on the pi I don't use apt-get update. On my pc I do not get that error. The buildlog was from launchpad
[09:53] <tsdgeos> ah
[09:53] <r2geo> should that key be added to my pc (from which I request launchpad to build)? Or from the pi?
[09:53] <tsdgeos> then i don't know, sorry
[09:53] <r2geo> Just checked, but building on pc does not throw this error
[09:54] <r2geo> so ... as the buildlog is created on launchpad, I suspect there is something wrong there. But I may be wrong. I will create a bug report - still if someone knows, I would be very happy to solve it via IRC. Thanks
[09:57] <mup> PR snapd#2643 opened: many: add stub implementation of snap-alter-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/2643>
[10:50] <mup> Bug #1656340 opened: XDG_RUNTIME_DIR is not created on app startup <Snappy:Confirmed for zyga> <https://launchpad.net/bugs/1656340>
[10:51] <zyga> jdstrand: hey, can you please review https://github.com/snapcore/snapd/pull/2630
[10:51] <mup> PR snapd#2630: many: detect potentially insecure use of snap-confine <Created by zyga> <https://github.com/snapcore/snapd/pull/2630>
[10:59] <Trevinho> ogra_: about the thing I was pointing out last night... https://bugs.launchpad.net/snappy/+bug/1657080
[10:59] <Trevinho> not snap run or unity7 specific
[10:59] <Trevinho> jdstrand: ^
[11:00] <mup> PR snapd#2642 closed: tests: disable ipv6 before unpacking delta <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2642>
[11:09] <mup> Bug #1400802 changed: sudo snappy install should autocomplete <snappy-xp-console> <Snappy:Fix Released> <https://launchpad.net/bugs/1400802>
[11:12] <mup> Bug # changed: 1500755, 1574114, 1574830, 1581596, 1588322
[11:15] <mup> Bug # changed: 1593371, 1593956, 1598656, 1611641, 1622782, 1623589, 1627338, 1635264
[11:18] <mup> Bug #1641590 changed: snap --help outline text <Snappy:Fix Released> <https://launchpad.net/bugs/1641590>
[11:18] <mup> Bug #1641885 changed: jailmode doesn't work with snap try or snap install <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1641885>
[11:21] <mup> Bug # changed: 1643885, 1643888, 1645413, 1646085, 1646479, 1647992, 1653955, 1654585
[11:24] <mup> Bug #1537793 changed: Autoupdate should be less frequent and more randomly distributed <verification-done> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1537793>
[11:24] <mup> Bug #1654666 changed: snapd-xdg-open doesn't work in strict mode <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1654666>
[11:26] <ogra_> Trevinho, ah
[11:27] <mup> Bug #1595064 changed: 'snap refresh' return code unhelpful <amd64> <apport-bug> <canonical-is> <xenial> <Snappy:Fix Released> <https://launchpad.net/bugs/1595064>
[11:27] <mup> Bug #1600083 changed: 'snap' tool bash completion does not complete local file names <Snappy:Fix Released> <https://launchpad.net/bugs/1600083>
[11:27] <mup> Bug #1603481 changed: multiple binaries from the same package <openstack> <Snapcraft:Fix Released by joetalbott> <Snappy:Fix Released> <https://launchpad.net/bugs/1603481>
[11:28] <mup> Issue snapd#2514 closed: seccomp tests fail on Ubuntu 14.04 <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2514>
[11:30] <mup> Bug # changed: 1605258, 1606053, 1616657, 1617890
[11:33] <mup> Bug # changed: 1635016, 1636847, 1640874, 1645961
[11:36] <mup> Bug #1654590 changed: docker interface should account for /run/shm/ in addition to /dev/shm <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1654590>
[11:41] <eduardas_m> hello, I am currently building an embedded system with Yocto/OpenEmbedded. I am considering trying to port Ubuntu Core to my platform to get its update functionality. However I am unsure: does using Ubuntu Core on OEM devices require buying licences from Canonical?
[11:41] <ogra_> zyga, bug 1656976 is on purpose, right ?
[11:42] <mup> Bug #1656976: classic mode cannot start services <Snappy:New> <https://launchpad.net/bugs/1656976>
[11:42] <ogra_> eduardas_m, nope, but we currently only support grub and uboot as bootloaders and you need full access to the source (we require a specific setup for the bootloader)
[11:43] <ogra_> beyond this there is nothing required
[11:46] <eduardas_m> ogra_, thank you for the answer... my platform (DART6UL SoM from Variscite) currently has u-boot 2015.04 revision... where can I check if this is supported?
[11:46] <eduardas_m> also, is it possible to do kernel updates via snaps?
[11:46] <ogra_> eduardas_m, well, you need the source and need to enable/change some config options
[11:46] <ogra_> yes, os and kernel updates
[11:47] <ogra_> eduardas_m, https://github.com/snapcore/pi3-gadget/blob/master/prebuilt/uboot.patch has an example patch
[11:48] <eduardas_m> ogra_, thanks a lot... sounds good so far... will give it a shot
[11:48] <ogra_> CONFIG_ENV_SIZE (with the right size), CONFIG_SYS_REDUNDAND_ENVIRONMENT, CONFIG_ENV_IS_IN_FAT and CONFIG_SUPPORT_RAW_INITRD are hard requirements
[11:50] <zyga> ogra_: I believe so, yes
[11:51] <ogra_> zyga,  iirc we support that you install services that you can also (temporary) start ... i wonder if that affects it
[11:52] <ogra_> (so that you can experiment with apache until the next reboot where it wont be started anymore)
[11:52] <ogra_> at least thats the wording i remember
[11:53] <mup> PR snapd#2644 opened: snapctl: support running by the snap app itself, not only just from hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/2644>
[12:04] <mup> PR snapd#2634 closed: tests: improve debug output when reexec is used  <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2634>
[12:05] <mup> Issue snapd#2541 closed: tests/main/interfaces-network-control-ip-netns test fails on ubuntu 14.04-32 <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2541>
[12:09] <mup> Issue snapd#2576 closed: snap-confine cannot be setuid root on openSUSE <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2576>
[12:11] <mup> Issue snapd#2569 closed: snap-confine cannot perform namespace capture even with CAP_SYS_ADMIN <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2569>
[12:12] <mup> Issue snapd#2568 closed: snapd needs a SELinux profile to run on Fedora <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2568>
[12:13] <mup> Issue snapd#2553 closed: snapd is not tested against Debian <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2553>
[12:14] <mup> Issue snapd#2552 closed: snapd is not tested against Arch Linux <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2552>
[12:15] <mup> Issue snapd#2572 closed: .fstab files generated by snapd for the content interface do not follow the snap.<snap name> scheme <Created by morphis> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2572>
[12:17] <mup> Issue snapd#2603 closed: Disk free space left check <Created by cyberb> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2603>
[12:18] <mup> Issue snapd#2625 closed: feature request: ability to talk to sysctl <Created by battlemidget> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2625>
[12:19] <mup> Issue snapd#2484 closed: Support removing all unused revisions <Created by niemeyer> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2484>
[12:19] <mup> Issue snapd#2594 closed: Please add "install" hook <Created by jacekn> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2594>
[12:24] <mup> PR snapd#2641 closed: cmd: fix hardcoded paths to rst2man and support rst2man.py <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2641>
[12:26] <mup> PR snapcraft#1051 opened: misc: remove snapd "submodule" <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1051>
[12:35] <mup> PR snapcraft#1039 closed: Check the older ubuntu-core snap name for core dynamic linker <Created by thomir> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1039>
[12:38] <mup> PR snapcraft#1045 closed: Handle parser errors better <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1045>
[12:45] <stokachu> can i move my scripts and setup dir from snapcraft to just the snap dir in the top level directory of my project now?
[12:55] <zyga> stokachu: I don't know, sorry
[12:56] <stokachu> thanks
[12:59] <mup> PR snapd#2645 opened: spread: exclude .o and .a files <Created by zyga> <https://github.com/snapcore/snapd/pull/2645>
[12:59] <stokachu> zyga, where did https://github.com/snapcore/snapd/issue/2625 get moved to?
[13:08] <zyga> stokachu: ohhh
[13:08] <zyga> stokachu: hmm that's terrible,one cannot see the issues anymore
[13:08] <zyga> niemeyer: ^ can we have read only issues so that people can see where they were moved?
[13:09] <zyga> stokachu: all of those moved to launchpad.net/snapd but I cannot even give you the URL now :(
[13:18] <stokachu> zyga, ah ok i figured you consolidated issue tracking
[13:37] <eduardas_m> ogra_, my current u-boot has CONFIG_ENV_IS_IN_MMC since the board boots from SD card... is this option compatible with CONFIG_ENV_IS_IN_FAT?
[13:37] <ogra_> nope
[13:37] <ogra_> you need to use a uboot.env blob file
[13:38] <ogra_> the userspace needs to be able to find it where it expects it to change variables on the fly
[13:38] <ogra_> (there is interaction going on betweern snapd and the bootloader that needs to work)
[13:39] <eduardas_m> ogra_, this blob is available for download?
[13:39] <ogra_> look in the branch that has the patch above ... there is a uboot.env.in and there is the command you need to turn it into a uboot.env blob in the README.md
[13:40] <ogra_> (the uboot.env.in should contain your default env like you get it on a serial console with printenv)
[13:50] <eduardas_m> ogra_, thank you... that makes things clearer
[13:55] <env_ro> Hi folks; I do have a question: snapd reads environment variables from /etc/environment file, how could I modify this file since fs is mounted as 'read only'? ;)
[13:56] <env_ro> this is the first question. Second one is about to modifying the console command that connects to ubuntu-one so it obtains public key associated with a given account.
[13:56] <env_ro> If I would be able to modify the above mentioned file (/etc/environment) so I would put there http_proxy settings, would then that initial script connect via the proxy?
[13:57] <env_ro> I'm asking, because I'm not able to install ubuntucore in my lab infrastructure (http proxy is required)
[13:58] <env_ro> So, maybe it would be a good idea if that script would take also the http proxy parameter?
[14:06] <gbisson> Hi all! I'm experiencing with Ubuntu Core on RPi3 and have a few question, first I can't install webdm, it throws: (installation not allowed by "snapd-control" plug rule of interface "snapd-control")
[14:06] <gbisson> so I've used snapweb instead
[14:06] <gbisson> but is it webdm replacement?
[14:06] <gbisson> is the error seen above normal?
[14:15] <env_ro> Hi gibsson. Unfortunately, it appears that noone is here ;)
[14:16] <env_ro> (i am not counting - newbie)
[14:17] <gbisson> env_ro: thanks for your reply though, we're at least 2 listening ;)
[14:17] <gbisson> I'll wait for a little bit, it can be early for some timezones
[14:21] <mup> PR snapd#2368 closed: tests: parameterize remote store <Created by fgimenez> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2368>
[14:23] <ogra_> gbisson, it was renamed to snapweb a while ago
[14:32] <mup> PR snapcraft#1031 closed: store: fix sso_host for dev sso <Created by shawn111> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1031>
[14:32] <zyga> jdstrand: good morning, thank you for triaging that bug
[14:33] <jdstrand> np
[14:33] <jdstrand> it will be nice to have it fixed, but that work is behind upstreaming (at least) atm afaik
[14:34] <zyga> jdstrand: that's a good plan IMHO
[14:35] <zyga> jdstrand: btw, do you know how far are we from upstreaming everything?
[14:39] <stokachu> has anyone run into https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1656580?
[14:39] <mup> Bug #1656580: snapd on trusty fails to install snap with error loading shared library <conjure-up> <snapd (Ubuntu):New> <snapd (Ubuntu Trusty):New> <https://launchpad.net/bugs/1656580>
[14:40] <stokachu> references some apparmor issue
[14:40] <jdstrand> zyga: I know a fair bit made the merge window. I don't have the details. perhaps tyhicks does?
[14:43] <zyga> jdstrand: thanks, I'll ask jjohansen and tyhicks later today
[14:43] <jdstrand> stokachu: fyi, I asked for more information in the bug
[14:44] <stokachu> jdstrand, thanks redeploying 14.04 in my maas lab will get you that info
[14:46] <tyhicks> zyga (cc jdstrand): a ton of patches will land in 4.11 (https://marc.info/?l=linux-kernel&m=148455878701987&w=2) but we're still months away from upstreaming everything
[14:47] <tyhicks> zyga: now that the ball is rolling on the upstreaming effort, I think that the kernel development cycle cadence is going to limit how fast we can upstream things
[14:48] <tyhicks> zyga: while that was a large number of patches, that's all we'll be able to get into the 4.11 kernel so we'll be queueing the next set of patches up for the 4.12 kernel security subsystem merge window
[14:51] <stokachu> jdstrand, hmm 2.21~14.04.2 does't seem to show this problem
[14:51] <stokachu> think that was released this morning
[14:51] <stokachu> still testing though
[14:51] <mup> PR snapd#2645 closed: spread: exclude .o and .a files <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2645>
[14:51] <jdstrand> I know there has been a lot of 14.04 work lately. it doesn't surprise me it might be fixed
[14:52] <stokachu> having systemd issues now but i dont think that apparmor is an issue any longer
[14:53] <stokachu> where does snapd install the systemd files for 14.04?
[14:53] <jdstrand> stokachu: cool. can you followup in the bug? note that when I was playing with 14.04, cgmanager would get in the way of systemd
[14:56] <stokachu> jdstrand, http://paste.ubuntu.com/23816658/ thats what i see with systemd and my snap
[14:56] <stokachu> journalctl -xn didn't give me much info though
[14:59] <stokachu> can't seem to find my systemd service file
[14:59] <stokachu> not in /lib/systemd
[15:00] <stokachu> it looks like the systemd file shouldve been linked into /lib/systemd/upstart on 14.04
[15:07] <zyga> tyhicks: that's some great news, thank you
[15:09] <gbisson> ogra_: thanks!
[15:10] <gbisson> in that case maybe webdm should be removed from the list or have a more explicit error message like "not supported any more, please use snapweb"
[15:10] <zyga> jdstrand, tyhicks: FYI, I have extra data for the apparmor bug at https://github.com/snapcore/snapd/pull/2624 but I need some help to figure out what to collect
[15:10] <mup> PR snapd#2624: Re-associate with pid-1 mount namespace if required <Blocked> <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2624>
[15:10] <zyga> I made it easy to re-run the spread test that uses the test kernel from jjohansen
[15:10] <zyga> and to collect various things
[15:11] <zyga> after running it the erorr I see is different, not sure if that is because of the older base kernel
[15:12] <zyga> this log file has useful references: https://s3.amazonaws.com/archive.travis-ci.org/jobs/192346094/log.txt
[15:12] <eduardas_m> I am trying out Ubuntu Core image on Virtual Box... Ubuntu store account is mandatory to even launch Ubuntu Core?
[15:13] <zyga> scroll to the bottom please then look for:  linode:ubuntu-16.04-64:tests/regression/lp-1644439
[15:13] <zyga> (hmm, I guess I need to stil tweak that to restore correctly)
[15:13] <zyga> the results are much more comprehensive if the single regression test is executed
[15:14] <zyga> eduardas_m: to log in, yes, otherwise anyone on the same network could "own" your device and that's not great for security
[15:14] <niemeyer> zyga, stokachu: No, no way around that unfortunately
[15:14] <zyga> jdstrand, tyhicks: let me know when would be a good time to try some interactive triage/debugging on this
[15:15] <zyga> niemeyer: ah, too bad; on the up side all the reporters got the email that included the new URLs so I hope they can find that
[15:15] <niemeyer> Yeah
[15:15] <niemeyer> and we also only had two issues which were not filed by you or mvo
[15:15] <eduardas_m> zyga, but if I want to use Ubuntu Core to be ported for an OEM device that is really bad
[15:15] <ogra_> eduardas_m, it will launch without it ... but to log in you need one
[15:17] <eduardas_m> ogra_, so lets assume that Ubuntu Core ships with hundreds of OEM devices..each one of these has to be tied to an Ubuntu Store account?
[15:17] <zyga> eduardas_m: if you have something specific in mind I can get you in touch with our commercial people; this scheme is designed to be secure for end users;
[15:17] <ogra_> thre is some way to set a local acocunt using a configuration on a usb stick on first boot
[15:18] <ogra_> but i dont think thats documented or promoted yet
[15:18] <zyga> ogra_: only the owner of the device brand can issue this assertion
[15:18] <zyga> ogra_: and it only (sensibly) applies to unowned devices
[15:19] <zyga> ogra_: and canonical does not issue this assertion yet
[15:19] <ogra_> right
[15:19] <zyga> eduardas_m: being tied an account also lets the user manage the device better, depending on the form factor and interaction methods it would be impossible to do otherwise
[15:20] <tyhicks> ogra_: I just ping you in the github PR but there's a test kernel for you to test: https://bugs.launchpad.net/apparmor/+bug/1656121/comments/2
[15:20] <mup> Bug #1656121: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace <AppArmor:New> <https://launchpad.net/bugs/1656121>
[15:20] <tyhicks> ogra_: bah, my bad... that message wasn't meant for you
[15:20] <tyhicks> zyga: I just ping you in the github PR but there's a test kernel for you to test: https://bugs.launchpad.net/apparmor/+bug/1656121/comments/2
[15:21] <zyga> tyhicks: I tested this kernel, all the stuff I said above was based on that
[15:21] <tyhicks> oh
[15:21]  * tyhicks rereads
[15:21] <ogra_> see ... undocumented, so i know nothing about it obviously ;)
[15:21] <zyga> tyhicks: one sec:
[15:21] <ogra_> tyhicks, heh, i was starting to wonder already :)
[15:22] <zyga> tyhicks: https://github.com/snapcore/snapd/pull/2624/files#diff-f3378ae971fb046662010c5acfd2c35cR21
[15:22] <mup> PR snapd#2624: Re-associate with pid-1 mount namespace if required <Blocked> <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2624>
[15:22] <mup> PR snapd#2347 closed: overlord: flag required-snaps from model as required and prevent removing them <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2347>
[15:22] <zyga> tyhicks: I've automated the testing process for that issue
[15:23] <tyhicks> zyga: since it is a kernel bug, I think you're better off working directly with jjohansen on this when he starts his day
[15:24] <zyga> tyhicks: yes, I agree
[15:25] <renatu> zyga, hey, could you check if you are happy with this MR: https://github.com/snapcore/snapd/pull/2226
[15:25] <mup> PR snapd#2226: interfaces/builtin: add evolution interfaces <Created by renatofilho> <https://github.com/snapcore/snapd/pull/2226>
[15:26] <zyga> renatu: yes
[15:28] <zyga> renatu: done
[15:28] <renatu> zyga, thanks
[15:48] <eduardas_m> I am having trouble logging in to Ubuntu Core on VirtualBox... I am trying my Ubuntu One username and password
[15:49] <eduardas_m> I used a public ssh key I generated on my Ubuntu 14.04 host to put into my Ubuntu One account
[15:49] <kyrofa> Chipaca, unfortunately the bug you referenced was just discussing how unhelpful the error is, not that it was impossible to cleanbuild
[15:50] <kyrofa> Chipaca, but it's a known issue, there was a ML thread about it and we're working on it
[15:59] <mup> PR snapcraft#1050 closed: repo: add multiarch support for stage packages <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1050>
[15:59] <mup> PR snapcraft#1051 closed: misc: remove snapd "submodule" <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1051>
[16:03] <niemeyer> zyga, jdstrand: Do you want to have a quick call to discuss the new interface system?
[16:08] <jdstrand> niemeyer: I guess a call now is fine
[16:08] <jdstrand> tyhicks: fyi ^. I can handle it but if you want to be there ^
[16:10] <zyga> yes
[16:10] <zyga> niemeyer: where shall we meet?
[16:10] <niemeyer> https://hangouts.google.com/hangouts/_/canonical.com/new-interfaces?authuser=1
[16:12] <niemeyer> jdstrand: ^
[16:13] <eduardas_m> what is supposed to be the username/password combination for the ubuntu-core-16-amd64.img?
[16:13] <eduardas_m> is it the username and password of my Ubuntu One account?
[16:14] <ogra_> it is your username ... no password ... it uses the ssh key that you provided in your U1 account to provide ssh login
[16:15] <kyrofa> eduardas_m, there's no local login by default
[16:16] <ogra_> right, only ssh
[16:16] <kyrofa> eduardas_m, the idea is, you go through the first boot wizard, provide your Ubuntu One login info, and it'll pull down the SSH keys you have uploaded. Then you can use those to SSH in
[16:17] <eduardas_m> kyrofa, so I can not log in through tty1 in VirtualBox?
[16:17] <kyrofa> ogra_, how is SSH configured by default? If a password is set, will one be able to SSH in with that password?
[16:17] <eduardas_m> because it prompts me for a password there
[16:17] <kyrofa> eduardas_m, not by default, but you can always set a password once you SSH in
[16:18] <eduardas_m> kyrofa, is this kind of interesting behaviour documented somewhere?
[16:18] <eduardas_m> because I believe a lot of people would benefit from instructions on how to test Ubuntu Core on VirtualBox
[16:20] <kyrofa> eduardas_m, yes indeed. I assume you started with the KVM option? https://developer.ubuntu.com/core/get-started/kvm
[16:21] <mup> PR snapd#2646 opened: tests: fix failing snapd-reexec test <Created by mvo5> <https://github.com/snapcore/snapd/pull/2646>
[16:21] <kyrofa> eduardas_m, note that this behavior is a little out of the ordinary, but it's done to ship a secure image by default
[16:22] <kyrofa> eduardas_m, default passwords etc. are why we have botnets of CCD cameras
[16:24] <eduardas_m> eduardas_m, to be honest I am quite new to linux in general (haven't even spent a year with it) and have very limited experience with VirtualBox and VMware as it is...since KVM is totally unfamiliar to me, I did not even consider it
[16:24] <kyrofa> eduardas_m, oh I don't blame you. I'm NOT new to Linux and I prefer vbox
[16:25] <kyrofa> eduardas_m, but what image did you start with, then?
[16:27] <eduardas_m> kyrofa, I did a VBoxManage convertdd ubuntu-core-16-amd64.img ubuntu-core-16-amd64.vdi --format VDI
[16:27] <kyrofa> eduardas_m, or did you do something directly like this https://kyrofa.com/posts/ubuntu-core-on-virtualbox ?
[16:27] <eduardas_m> I found these instructions online and it was the first thing I tried
[16:27] <kyrofa> eduardas_m, ah
[16:27] <kyrofa> eduardas_m, well, had you gone through the developer.ubuntu.com path, you would have seen docs for this behavior. But no matter!
[16:31] <eduardas_m> kyrofa, thank you for the help so far... will continue exploring Ubuntu Core tomorrow
[17:00] <ogra_> kyrofa, hmm, no idea, since the key always preceeds password i have never tested that
[17:01] <mup> PR snapd#2647 opened: cmd: add autogen.sh <Created by zyga> <https://github.com/snapcore/snapd/pull/2647>
[17:05] <mup> PR snapcraft#1052 opened: Make git pulls less error prone due to history changes <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1052>
[17:23] <zyga> jdstrand: trivial: https://github.com/snapcore/snapd/pull/2648
[17:23] <mup> PR snapd#2648: cmd/snap-confine: use flags rather than magic bool constants <Created by zyga> <https://github.com/snapcore/snapd/pull/2648>
[17:24] <mup> PR snapd#2648 opened: cmd/snap-confine: use flags rather than magic bool constants <Created by zyga> <https://github.com/snapcore/snapd/pull/2648>
[17:30] <mup> PR snapd#2649 opened: many: extract the logging http client and user-agent handling for use in devicestate <Created by pedronis> <https://github.com/snapcore/snapd/pull/2649>
[17:44] <mup> PR snapd#2633 closed: docs: simplify HACKING.md that snapd itself supports setting up the sockets <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2633>
[17:49] <mup> PR snapd#2647 closed: cmd: add autogen.sh <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2647>
[17:54] <zyga> jdstrand: oldie but (hopefully) goldie: https://github.com/snapcore/snapd/pull/2416 -- it has one +1 and I'd love to land it
[17:54] <mup> PR snapd#2416: cmd/snap-confine: add snap-confine command line parser module <Created by zyga> <https://github.com/snapcore/snapd/pull/2416>
[17:57]  * zyga takes a break
[18:04] <pachulo> elopio: are you around?
[18:12] <jdstrand> tyhicks, ratliff: zyga requested a review of https://github.com/snapcore/snapd/pull/2416 again. where should this be in terms of priorities?
[18:12] <mup> PR snapd#2416: cmd/snap-confine: add snap-confine command line parser module <Created by zyga> <https://github.com/snapcore/snapd/pull/2416>
[18:13] <zyga> jdstrand: FYI not a urgent thing, just a poke as I was going over all pull requests
[18:13] <zyga> it should land eventually :)
[18:13] <zyga> jdstrand: feel free to delegate that to someone if you can
[18:13] <jdstrand> tyhicks: ^
[18:15] <ratliff> jdstrand, tyhicks: it seems like a nice refactoring and has been pending for a while, but I would put it below the seccomp arg filtering work that you are focused on this week
[18:16]  * jdstrand adds card and moves to top of the list behind seccomp and other pending interface reviews
[18:17] <zyga> thanks!
[18:23] <mup> PR snapcraft#1053 opened: meta: ensure snap.yaml is desktop free <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1053>
[18:29] <mup> PR snapd#2646 closed: tests: fix failing snapd-reexec test <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2646>
[19:12] <mup> PR snapd#2636 closed: tests: add "quiet" wrapper function that only prints output on failure <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2636>
[19:15] <zyga> jdstrand: the thing from last week, https://github.com/snapcore/snapd/pull/2630 already +1 from mvo and waits from a review from you
[19:15] <mup> PR snapd#2630: many: detect potentially insecure use of snap-confine <Created by zyga> <https://github.com/snapcore/snapd/pull/2630>
[19:16] <zyga> super short apart from the spread test
[19:17]  * zyga should really stop working
[19:17] <jdstrand> zyga: yes, it is on my list
[19:17] <zyga> jdstrand: great
[19:56] <mup> PR snapcraft#1050 opened: repo: add multiarch support for stage packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1050>
[20:01] <tito_> Hi
[20:02] <tito_>  I do have a question regarding this document:
[20:02] <kyrofa> Hey tito_, welcome
[20:02] <tito_> https://docs.ubuntu.com/core/en/guides/build-device/image-building
[20:02] <tito_> hi kyrofa
[20:03] <tito_> in the end, one can see that console-conf is sheduled and that you need physical access to the machine to go through it
[20:04] <tito_> imho , the last section (Known problems and limitations)
[20:04] <tito_> should be extended with a proxy problem...
[20:04] <tito_> because, how could I modify the image so it would use the proxy at that very initial moment?
[20:08] <mup> PR snapcraft#1054 opened: snapcraft as a snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1054>
[20:09] <mwhudson> huh i can't install the core snap in a zesty lxd
[20:09] <mwhudson> - Mount snap "core" (914) ([start snap-core-914.mount] failed with exit status 1: Job for snap-core-914.mount failed.
[20:09] <kyrofa> tito_, indeed, good question. mwhudson how would one use a proxy in console-conf?
[20:10] <mwhudson> kyrofa: missing feature
[20:10] <mwhudson> i think there's a bug for it
[20:10] <tito_> in my project :)
[20:10] <tito_> this was a nearly killer
[20:10] <tito_> The bug mentions about already up and running snappy core system
[20:10] <mwhudson> huh can't find a bug
[20:11] <mwhudson> tito_: can you file a bug here https://bugs.launchpad.net/ubuntu/+source/subiquity
[20:11] <mwhudson> tito_: it shouldn't be incredibly difficult, i hope
[20:11] <tito_> and concerns about snapd service that consumes /etc/environment file
[20:11] <tito_> which, by the way, is mounted on RO partition thus I am unable to configure snapd later :(
[20:12] <tito_> mwhudson - I'm going to do this
[20:12] <tito_> so, does the console-conf python script utilize snapd at some way while connecting to ubuntu.one ?
[20:12] <mwhudson> uh is /etc/environment really not writable? fun times
[20:13] <pedronis> mwhudson: asking, I'm a bit surprised too
[20:13] <tito_> is really really.
[20:13] <mwhudson> yeah seems so
[20:13] <mwhudson> that's fixable too of course
[20:13] <tito_> and is also nearly killer for my project frankly saying
[20:13] <tito_> If we/you/someone would fix those two things
[20:13] <tito_> it would be so perfect
[20:14] <mwhudson> can use systemd drop-in files for snapd.service specifically
[20:14] <tito_> so,I've red somewhere that I could do: systemctl edit snapd.service
[20:14] <mwhudson> but probably it should go in /etc/environment
[20:14] <tito_> right?
[20:15] <mwhudson> yeah that should work i think
[20:15] <tito_> what should i put there ?
[20:15] <tito_> Environment=someproxyaddress:port ?
[20:15] <tito_> tfu
[20:15] <tito_> Environment=http_proxy=someproxyaddress:port
[20:15] <tito_> ?
[20:15] <mwhudson> Environment="http_proxy=blahblah:blah"
[20:15] <mwhudson> & https_ &c
[20:15] <tito_> and then
[20:16] <tito_> systemctl restart snapd.service would restart it with new hook for Environment right?
[20:17] <mwhudson> yes
[20:19] <tito_> (checking :))
[20:22] <pedronis> mwhudson: anyway it might be that /etc/environment is meant more for classic, not sure the thinking there
[20:22] <tito_> pedronis: now, snapd looks for Environment variables in that file
[20:23] <tito_> mwhudson: does not work unfortunately
[20:23] <tito_> root@localhost:/tmp# snap install gcc error: cannot install "gcc": Get https://search.apps.ubuntu.com/api/v1/snaps/details/gcc?channel=stable&confinement=strict: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) root@localhost:/tmp#
[20:23] <mwhudson> bah snapd in my xenial vm has got itself confused
[20:23] <mwhudson> pedronis: the bug is clear, the path to a fix not quite so
[20:24] <mwhudson> Jan 18 09:22:20 ubuntu snapd[2557]: 2017/01/18 09:22:20.086213 patch.go:65: Patching system state from level 3 to 4
[20:24] <mwhudson> Jan 18 09:22:20 ubuntu /usr/lib/snapd/snapd[2557]: patch.go:72: Cannot patch: cannot get snap state for "core": <nil>
[20:24] <tito_> mwhudson: the layout of snapd.service edit looks like: Environment="http_proxy=sss:ppp https_proxy=sss:ppp HTTP_PROXY=sss:ppp HTTPS_PROXY=sss:ppp"
[20:24] <mwhudson> pedronis: any ideas ^ ?
[20:25] <mwhudson> tito_: not sure you want those quotes like that
[20:26] <mwhudson> tito_: i think that syntax will set the value of the env var "http_proxy" to "=sss:ppp https_proxy=sss:ppp HTTP_PROXY=sss:ppp HTTPS_PROXY=sss:ppp"
[20:26] <mwhudson> er minus that first = but you get the idea
[20:27] <mwhudson> pedronis: i was a bit surprised when snapd install core wanted to install ubuntu-core, i guess snapd was too?
[20:33] <tito_> mwhudson: fair point
[20:33] <tito_> but I believe that this trick is overriden by snapd.conf
[20:33] <tito_> which reads /etc/environment anyway
[20:34] <tito_> because setting proxies like that (edit snapd.service) does not work unfortunately
[20:34] <tito_> Ok actually "snapd.conf" is not a proper name, but there is some file that holds already "Environment" entry right?
[20:39] <mwhudson> tito_: environment entries are cumulative
[20:40] <mwhudson> so that's not the reason for it not working
[20:40] <pedronis> mwhudson: you had a very old snapd in that vm?
[20:41] <mwhudson> pedronis: nope, i installed it from scratch yesterday!
[20:41] <pedronis> mwhudson: from scratch ?
[20:41] <pedronis> mwhudson: the base ubuntu-server image has a very old snapd
[20:41] <mwhudson> installed from 16.04.1 media, apt update, apt dist-upgrade
[20:41] <mwhudson> and *then* snap install core
[20:41] <pedronis> that is weird
[20:42] <pedronis> there's a problem if you try to use snapd before doing apt upgrade
[20:42] <mwhudson> ubuntu@ubuntu:~$ snap version
[20:42] <mwhudson> snap    2.20.1+ppa149.4ca4ce07-1
[20:42] <mwhudson> snapd   unavailable
[20:42] <mwhudson> series  -
[20:42] <pedronis> but shouldn't be there after
[20:42] <pedronis> your snapd is dead
[20:43] <mwhudson> indeed
[20:43] <mwhudson> because of the journal entries i pasted above
[20:43] <pedronis> yes, but those make sense only for an old snapd
[20:43] <pedronis> not 2.20 or 2.21 (afaik)
[20:43] <pedronis> (and afaiu)
[20:43] <mwhudson> hmm
[20:43] <tito_> btw: my snap version is 2.16 and I took the image from: http://cdimage.ubuntu.com/ubuntu-core/16/current/
[20:44] <mwhudson> where is the snapd binary?
[20:44] <mwhudson> ubuntu@ubuntu:~$ /usr/lib/snapd/snapd --version
[20:44] <mwhudson> error: cannot read the state file: open /var/lib/snapd/state.json: permission denied
[20:44] <mwhudson> bah
[20:44] <mwhudson> ii  snapd                            2.0.10                amd64                 Tool to interact with Ubuntu Core Snappy.
[20:44] <mwhudson> waaaiiiiiiiiiit what
[20:44] <pedronis> ah
[20:44] <pedronis> that is compatible
[20:45] <pedronis> with the logs
[20:45] <pedronis> you got
[20:45] <mwhudson> maybe i hadn't run dist-upgrade after all :)
[20:45] <pedronis> ok
[20:45] <pedronis> sadly base image has  a very old snapd
[20:45] <tito_> which is 2.16
[20:46] <pedronis> no 2.0.10
[20:46] <tito_> maybe 2.16 does not have the fix for proxy?!
[20:46] <pedronis> fix for proxy?
[20:47] <tito_> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1574702
[20:47] <tito_> this one
[20:47] <mup> Bug #1574702: 'snap' does not appear to use proxy settings <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1574702>
[20:48] <mwhudson> awesome time for a system crash
[20:49] <mwhudson> pedronis: i guess i'll need to purge snapd to fix the mess i have in my vm
[20:49] <pedronis> mwhudson: yes
[20:50] <mwhudson> tito_: oh great
[20:50] <tito_> mwhudson can you tell me what is great ? :)
[20:50] <mwhudson> tito_: that bug
[20:50] <mwhudson> tito_: and, in case it wasn
[20:51] <pedronis> well the fix was adding /etc/environment to the unit afaik
[20:51] <mwhudson> t obvious, i was being sarcastic :)
[20:51] <mwhudson> oh ok
[20:51] <pedronis> (don't know why the bug wasn't updated)
[20:51] <pedronis> I mean go runtime should do the right thing (tm)
[20:51] <pedronis> already
[20:51] <mwhudson> yeah it seems to be odd ball and respect HTTP_PROXY not http_proxy
[20:59] <tito_> I've mixed all possibilities
[20:59] <tito_> and no success :/
[20:59] <pedronis> mwhudson: it should consider either these days
[21:00] <tito_> maybe I should upgrade snapd itself to latest released version (in the network without proxy)
[21:00] <tito_> ?
[21:00] <mwhudson> pedronis: feel free to try sudo snap install --edge --classic go-17-mwhudson if you like :)
[21:00] <mwhudson> (trying that out was the reason i was futzing about in the vm anyway)
[21:01] <mwhudson> snapcraft.yaml at https://code.launchpad.net/~mwhudson/+git/gosnap/+ref/master
[21:01] <mwhudson> tito_: certainly more things are likely to work if you can upgrade snapd
[21:02] <mwhudson> tito_: but i'm not sure about this thing specifically tbh
[21:02] <mwhudson> tito_: did you file a but yet?
[21:02] <mwhudson> i need to afk for a few
[21:02] <mwhudson> *bug
[21:02] <tito_> regarding this console-conf proxying?
[21:02] <tito_> not yet
[21:02] <tito_> (tried all the time to enable proxy in snapd first)
[21:05] <ogra_> kgunn, hmm ... i was just wondering, how hard would it be to run an XMir instance on top of the mir-kiosk snap ... that way one could package an X11 session :)
[21:07] <ogra_> (indeed you'd have to bundle all X apps in the session snap ... )
[21:07] <tito_> I've even installed snap with wget wrapper
[21:08] <tito_> so I have tested the proxy itself
[21:08] <tito_> and it works. But not in case of snapd
[21:08] <kgunn> ogra_: it'd certainly be possible, i dont see why not
[21:08] <tito_> and this trick over Environment in snapd.service config
[21:08] <kgunn> that would be xmir as a system compositor
[21:08] <ogra_> heh ... so unity7 on pi3 on top of mir *g*
[21:10] <pedronis> tito_: afaik it should work , we even use it for the snapd own autopackage tests: https://github.com/snapcore/snapd/blob/master/debian/tests/integrationtests
[21:12]  * pedronis needs to go afk
[21:17] <tito_> folks, I've put the bug for a console-conf + proxy : https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1657254
[21:17] <mup> Bug #1657254: console-conf - unable to connect over proxy <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1657254>
[21:18] <tito_> will back later
[21:18] <tito_> btw - i love this mup bot ;)
[21:26] <tito_> ok guys. will talk to you later
[21:26] <tito_> c u
[21:32] <mwhudson> oh maybe tito_ wasn't running systemctl daemon-reload
[22:00] <pedronis> mwhudson: systemctl edit should do that for you
[22:00] <mwhudson> oh right
[22:00] <pedronis> anyhow
[22:00]  * pedronis -> rest
[22:00] <pedronis> ttfn!
[22:03] <mwhudson> bye
[23:14] <wililupy> Question: What is the context for my snapcraft yaml to stage packages for local deb's?
[23:18] <kyrofa> wililupy, I don't really understand the question
[23:18] <kyrofa> Context?
[23:19] <wililupy> kyrofa: My build machien doesn't have internet access, but I have all my stage debians on a flash drive and I want to use that for staging my dependencies for my snap.
[23:20] <kyrofa> wililupy, eww :P
[23:20] <kyrofa> wililupy, I wouldn't do it that way, then
[23:20] <kyrofa> wililupy, because there's no way to tell snapcraft "I want these stage packages... but don't hit the internet"
[23:20] <kyrofa> wililupy, but you can use .debs as sources
[23:21] <kyrofa> wililupy, how many stage packages are we talking?
[23:21] <wililupy> kyrofa: gotcha. Main thing is that this debian repository is unsigned and untrusted so trying to add it to sources.list fails.
[23:22] <kyrofa> wililupy, yeah if you've got the debs already and don't care about checking for updates etc. just use them as parts
[23:22] <wililupy> 8
[23:22] <wililupy> The rest can be pulled from repos...
[23:22] <kyrofa> wililupy, you could make 8 parts, then, each with a `source: that/one.deb`
[23:22] <kyrofa> and the dump plugin
[23:23] <kyrofa> Or you can use the `make` plugin and write a Makefile that just extracts them all in one go
[23:23] <wililupy> kyrofa: I'll give that a shot.
[23:23] <kyrofa> Oh no, what am I thinkin
[23:23] <kyrofa> You can use scriptlets now instead of the Makefile approach
[23:23] <kyrofa> But yeah, keeping them all as separate parts is probably the easiest if you're okay doing that 8 times
[23:24] <kyrofa> If you had like 20 though, that would get old
[23:24] <wililupy> kyrofa: Thanks, I'll try that and let you know how it goes.
[23:25] <kyrofa> wililupy, sure thing