[00:00] <jdstrand> it is that the sandbox doesn't have a way to express "setpriority for myself or children"
[00:00] <Trevinho> mh, can't be something apparmor could be instructed to do?'
[00:00] <jdstrand> neither apparmor nor seccomp have that ability, so you could set the priority of any other process to higher than your own
[00:00] <Trevinho> mh, ok
[00:01] <jdstrand> sure it could, that is just dev work and there is other stuff before that
[00:01] <Trevinho> sure, sure... Just to give an idea :-)
[00:01] <ahoneybun> bladernr`: yea the issue is that it's not looking at $SNAP/share/
[00:01] <Trevinho> if it was feasible or not...
[00:01] <ahoneybun>   /share/pithos
[00:01] <ahoneybun> mhall119: any ideas?
[00:01] <ahoneybun> http://pastebin.ubuntu.com/23477531/
[00:01] <Trevinho> jdstrand: and... since you're here... is there anything going on for https://bugs.launchpad.net/snap-confine/+bug/1620442 ?
[00:01] <mup> Bug #1620442: snap fails because XDG_RUNTIME_DIR is set to /run/user/1000 <snapd-interface> <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1620442>
[00:01] <jdstrand> it should be. process-control will be there for while it isn't implemented
[00:02] <jdstrand> it might be possible with PRIO_PGRP. it'll need investigating
[00:04] <Trevinho> cool, let me know if there's somethiung possible... Otherwise maybe looking for procs coming from the snap as the possible targets would be maybe easier... dunnow
[00:04] <jdstrand> Trevinho: as for auto-connecting process-control-- that is possible via snap declarations and the store. a reviewer can say 'sure this developer is trusted so I'll let this snap auto-connect process-control'
[00:05] <Trevinho> ah, cool
[00:05] <jdstrand> ok, I need to have some dinner
[00:05] <jdstrand> Trevinho: see you later! :)
[00:05] <Trevinho> jdstrand: as I was trying some electron apps... and well, the hack there is to just use browser-support plug, but... in theory once they've setpriority everything else would be unneed.
[00:05] <Trevinho> jdstrand: sure, enjoy it!
[00:06] <jdstrand> re https://bugs.launchpad.net/snap-confine/+bug/1620442, I've commented in the bug but haven't worked on it yet
[00:06] <mup> Bug #1620442: snap fails because XDG_RUNTIME_DIR is set to /run/user/1000 <snapd-interface> <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1620442>
[00:07] <jdstrand> I'll add that to my current policy work trello card
[00:08] <jdstrand> Trevinho: ^
[00:08] <jdstrand> ok, gone for real
[00:08] <Trevinho> jdstrand: :-). Thanks.
[01:18] <Pharaoh_Atem> mhall119: CentOS 6 uses upstart
[01:22] <Pharaoh_Atem> mhall119: specifically, upstart 0.6.5
[07:13] <mup> PR snapd#2254 closed: docs: fix path for source files location in HACKING.md <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2254>
[07:21] <foxmask> bonjello
[07:50] <liuxg> zyga, ping
[08:01] <dholbach> hey hey
[08:27] <mup> PR snapd#2250 closed: store: use range requests if partial files are available <Created by chipaca> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2250>
[08:34] <zyga> liuxg: hey
[08:34] <zyga> liuxg: how can I help you
[08:35] <liuxg> zyga, thanks for your reply. today, I tried to duplicate your "reboot" interface. However, I did not find it after I successfully build the snapd following your instructions.
[08:36] <zyga> liuxg: can you tell me more about the target device, did you perform all development locally?
[08:37] <liuxg> zyga, your article at http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html is very informative. I am now trying it on Ubuntu Destkop 16.04. I want to understand how an interface/slot is implemented.
[08:37] <zyga> ok
[08:37] <zyga> liuxg: did you use refresh-bits to run snapd on your system?
[08:37] <liuxg> zyga, I read yoru blog, and my reboot.go is like "http://paste.ubuntu.com/23479268/". is this correct?
[08:38] <liuxg> zyga, yes, I followed your instructions at http://www.zygoon.pl/2016/06/making-your-first-contribution-to-snapd.html
[08:38] <liuxg> zyga, after successfully build the code, but I did not see the "reboot" interface there.
[08:39] <zyga> liuxg: ok, can you do two things please, first, pull new devtools, I made some improvements that I just pushed now
[08:39] <zyga> liuxg: second, please pastbin your diff against master in snapd, that will help me to figure out what may be the problem
[08:39] <liuxg> zyga, http://imgur.com/a/QCzcB, this the result
[08:39] <zyga> liuxg: I suspect it might be related to the base asserrtion (maybe)
[08:40] <zyga> liuxg: are you developing against master or against a particular tagged release?
[08:41] <liuxg> zyga, ok.. thanks. I  will pull the latest devtool. By the way, reh previous ./restore-bit restore cannot revert back to the previous snapd. My colleauge also got this problem.
[08:41] <liuxg> zyga, I am developing against the master
[08:44] <mup> Bug #1641869 opened: openvswitch interface <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1641869>
[08:50] <zyga> liuxg: ah, this is a known issue, it's related to the fact that snapd migrates the state format
[08:50] <mup> PR snapd#2212 closed: spread tests: fix snap mode check <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2212>
[08:50] <liuxg> zyga, so, do you have fix for it?
[08:51] <zyga> liuxg: no, I don't know what the fix should be yet, backing up and restoring the state might be a simple start but it is hardly sufficient
[08:51] <zyga> liuxg: snapd might grow support for reverting to older patch level (data format)
[08:52] <liuxg> zyga, currently, I have to reinstall the snapd every time.
[08:53] <mup> PR snapd#2065 closed: interfaces/builtin: use udev to export GPIOs to userspace <Blocked> <Reviewed> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2065>
[09:12] <didrocks> zyga: jailmode not working with snap try or snap install in snapd   2.16ubuntu3 is a known issue?
[09:12] <didrocks> I have a snap in devmode, installed it in jailmode and it's still allowed do listen to network or do similar things
[09:16] <didrocks> mvo: any idea? ^
[09:16] <zyga> didrocks: can you report a bug with all the details
[09:17] <zyga> didrocks: and snap list output at the end please
[09:17] <didrocks> zyga: I would like to have confirmation, but I can report a bug
[09:17] <didrocks> as it's just a question of having a snap in devmode, install it with --jailmode
[09:17] <didrocks> (and yeah, snap list confirms it's in jailmode)
[09:18] <zyga> didrocks: hmm, can you look at /var/lib/snapd/apparmor/profiles/
[09:18] <zyga> didrocks: and look at the head of the relevant profiles of the app
[09:18] <zyga> didrocks: if you pastebin that I will have confirmation
[09:19] <didrocks> zyga: http://paste.ubuntu.com/23479407/
[09:19] <mup> PR snapd#2260 closed: tests: add test that ensures the right content for /etc/os-release <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2260>
[09:20] <mup> PR snapd#2205 closed: snap, image: fix `snap download` and `snap prepare-image` running as user <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2205>
[09:20] <mup> PR snapd#2207 closed: store: check hash in store.Download() (if we have a hash) <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2207>
[09:20] <zyga> didrocks: confirmed
[09:20] <zyga> profile "snap.chuck-norris-webserver.node-service" (attach_disconnected,complain) {
[09:20] <zyga> "complain" is the devmode trigger
[09:20] <zyga> didrocks: can you report a bug with instructiosn on how to reproduce, I will fix it
[09:21] <mup> PR snapd#2222 closed: tests: do not hardcode the size of /dev/ram0 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2222>
[09:21] <didrocks> zyga: with some tests I hope for not regression again :p
[09:21] <zyga> didrocks: obviously
[09:22] <zyga> ogra_: he
[09:22] <zyga> ogra_: hey :)
[09:22] <zyga> ogra_: do you happen to have a gadget/kernel snap for beagle bone black?
[09:26] <mup> Bug #1641885 opened: jailmode doesn't work with snap try or snap install <Snappy:New> <https://launchpad.net/bugs/1641885>
[09:27] <didrocks> zyga: ^
[09:31] <zyga> didrocks: thanks, I already triaged it
[09:34] <zyga> tvoss: experimenting now
[09:35] <zyga> tvoss: I hope to reproduce the issues you saw first
[09:35] <tvoss> zyga: thanks
[09:54] <mup> PR snapcraft#904 opened: WIP: Use pylxd instead of lxd command line (LP: #1641520) <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/904>
[09:56] <shuduo> hello, i'm helping one customer to migrate their kernel snap from u-d-f to ubuntu-image. now we always meet timeout error as below:
[09:56] <shuduo> sudo /snap/bin/ubuntu-image -c beta --image-size 4G --extra-snaps ./bubblegum96-gadget_0.1.0_arm64.snap --extra-snaps ./bubblegum96-kernel_3.10.0_arm64.snap -o bubblegum96.img bubblegum96.model
[09:56] <shuduo> error: cannot fetch and check prerequisites for the model assertion: Get https://assertions.ubuntu.com/v1/assertions/account-key/6PVAOu6V-pOb7bCSIB9W0WRSnVZwySqShrne8zWWWhIh6oW65o1ynHD4XoT3wSzF?max-format=0:
[09:56] <shuduo> net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
[09:56] <shuduo> COMMAND FAILED: snap prepare-image --channel=beta --extra-snaps=./bubblegum96-gadget_0.1.0_arm64.snap --extra-snaps=./bubblegum96-kernel_3.10.0_arm64.snap bubblegum96.model /tmp/tmpk_f88lrl/unpack...subprocess.CalledProcessError: Command '['snap', 'prepare-image', '--channel=beta', '--extra-snaps=./bubblegum96-gadget_0.1.0_arm64.snap', '--extra-snaps=./bubblegum96-kernel_3.10.0_arm64.snap',
[09:56] <shuduo> 'bubblegum96.model', '/tmp/tmpk_f88lrl/unpack']' returned non-zero exit status 1
[09:56] <shuduo> is it a store problem or something mistake in command line of ubuntu-imag? thanks
[10:03] <liuxg> zyga, this is the difference http://paste.ubuntu.com/23479536/ http://paste.ubuntu.com/23479540/ is there anything I missed?
[10:27] <liuxg> zyga, Just now, I tried it again. I found that I missed the changes in the all.go, which was not mentioned in your blog. Here are all of the changes http://paste.ubuntu.com/23479617/. thanks for your help.
[10:31] <jamespage> is there a good howto on writing and testing a new interface for snapd/snappy?
[10:35] <jamespage> nm found http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html
[10:35] <jamespage> pointed me to my error
[10:46] <zyga> jamespage: hey
[10:46] <zyga> jamespage: :-)
[10:46] <jamespage> zyga, got me going in the right direction - I'd missed the addition to the implicit slots array
[10:47] <zyga> jamespage: that's great, I'm planning on writing something new along the path there
[10:47] <zyga> jamespage: suggestions on what would help are very much welcome
[10:47] <zyga> liuxg: hey, I'm glad you sorted that out
[10:48] <liuxg> zyga, yeah, I spent some time to figure it out. Frankly, I am not familar with the snapd design. Your blog is great!
[10:50] <jamespage> zyga, I just need to figure out why openvswitch startup is trying to use systemctl :-)
[10:50] <liuxg> zyga, I just tried the interface, and it truly rebooted my computer :)
[10:55] <mup> PR snapd#2274 opened: interfaces: use sysd.{Disable,Stop} instead of sysd.DisableNow() <Created by mvo5> <https://github.com/snapcore/snapd/pull/2274>
[11:00] <mup> PR snapcraft#902 closed: Snap revision prune <Created by seawaywen> <Closed by seawaywen> <https://github.com/snapcore/snapcraft/pull/902>
[11:09] <mup> PR snapcraft#905 opened: Snap revision prune <Created by seawaywen> <https://github.com/snapcore/snapcraft/pull/905>
[11:11] <wililupy> Question: Is it possible to make a snap auto-connect to slots? For example, my snap automatically consumes the network and network-bind slots, but I have to manaully connect network-observe and network-control.
[11:23] <didrocks> wililupy: if you are a device owner, you can do that through assertions
[11:23] <didrocks> but not on other devices, as those interfaces are considered privileges and not connected automatically on purpose
[11:24] <didrocks> http://snapcraft.io/docs/reference/interfaces for the list
[11:28] <tsdgeos> is this expected? http://paste.ubuntu.com/23479868/
[11:28] <tsdgeos> or is it bad packaging?
[11:28] <tsdgeos> shouldn't it be using the libs from the snap and not from / ?
[11:30] <didrocks> tsdgeos: for base packages, if you don't ship them, it's using the system ones
[11:30] <didrocks> like libc, opensll…
[11:30] <didrocks> ssl*
[11:31] <Exquisitus> Hello, I have a problem publishing my snap
[11:31] <Exquisitus> There has been a problem while analyzing the snap, check the snap and try to push again.
[11:31] <Exquisitus> it is really too vague
[11:31] <Exquisitus> what could be the problem?
[11:31] <Exquisitus> thanks
[11:31] <didrocks> Exquisitus: hey, that's the only message you are getting?
[11:31] <didrocks> (mind doing a screenshot?)
[11:32] <tsdgeos> didrocks: ok
[11:36] <tsdgeos> didrocks: how is that going to work once those libraries get ABI changes? one won't be able to use the same snap in xenial and say zesty?
[11:37] <didrocks> tsdgeos: in order to protect yourself against those, you need to stage them in your snap, indeed
[11:37] <didrocks> (like the libc breakage we got between 15.04 and series 16)
[11:39] <Exquisitus> yes it is
[11:40] <Exquisitus> exquisitus@paponfix ~/P/iri-snapcraft> snapcraft push iri_1.1.0_amd64.snap  Uploading iri_1.1.0_amd64.snap. Uploading iri_1.1.0_amd64.snap [                                                                                                   ]   0% Uploading iri_1.1.0_amd64.snap [[11:40] <Exquisitus> There has been a problem while analyzing the snap, check the snap and try to push again.
[11:41] <Exquisitus> I already tried to push 5 times
[11:41] <Exquisitus> ...
[11:41] <didrocks> ah, I guess sergiusens's branch will help getting more debug output
[11:41] <didrocks> but I think you shuld see it as well on the web server
[11:41] <didrocks> https://myapps.developer.ubuntu.com
[11:41] <didrocks> do you have moreinfo there?
[11:42] <didrocks> (I guess you created your snap with snapcraft snap?)
[11:42] <mup> PR snapd#2275 opened: interfaces/builtin: allow additional shared memory for webkit <Created by zyga> <https://github.com/snapcore/snapd/pull/2275>
[11:46] <Chipaca> jdstrand: poke
[11:48] <Exquisitus> didrocks: exactly I did everything command line
[11:48] <didrocks> Exquisitus: ok, so have a look at the web interface, it should give you more detailed information
[11:49] <sergiusens> Exquisitus check your email, you will have a link to the failure
[11:49] <didrocks> sergiusens: is that something your new branch will fix as well? Like you are getting more info from the store?
[11:50] <mup> PR snapd#2276 opened: Add openvswitch-support interface <Created by javacruft> <https://github.com/snapcore/snapd/pull/2276>
[11:54] <Exquisitus> ah thanks
[11:54] <Exquisitus> https://myapps.developer.ubuntu.com/dev/click-apps/6305/rev/1/
[11:54] <didrocks> Exquisitus: only you have access to it
[11:55] <Exquisitus> lol
[11:55] <Exquisitus> package contains external symlinks: usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts lint-snap-v2_external_symlinks
[11:55] <Exquisitus> that's the error.
[11:55] <didrocks> so, you have your answer :)
[11:55] <didrocks> you have symlinks pointing outside of your snap, which isn't allowed
[11:56] <sergiusens> didrocks which branch? The store needs to provide more information first :-)
[11:57] <didrocks> sergiusens: the one you pointed to me last thursday
[11:57] <sergiusens> didrocks I am so lost; sorry
[11:57] <Exquisitus> oook... how I'm supposed to fix this? Jesus
[11:58] <sergiusens> Exquisitus I don't think Jesus will help, we can though
[11:58] <sergiusens> Exquisitus for the part adding this add a new entry `snap: [-usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts]`
[12:00] <mup> Bug #1641631 changed: Raspberry Pi images do not support boot from USB <Snappy:Invalid> <https://launchpad.net/bugs/1641631>
[12:02] <sergiusens> there's a bug for this too LP: #1617296
[12:02] <mup> Bug #1617296: The JDK plugin results in a dangling symlink <Snapcraft:New for gnuoy> <https://launchpad.net/bugs/1617296>
[12:06] <Exquisitus> @sergiusens: thanks a lot , you are better than Jesus
[12:06] <nothal> Exquisitus: No such command!
[12:07] <Exquisitus> Thanks sergiusens, you are better than Jesus
[12:07] <Exquisitus> XD
[12:07] <Exquisitus> sergiusens: only a thing, where actually I'm supposed to add snap: [-usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts]?
[12:12] <didrocks> Exquisitus: you need to add it in the part shipping this file
[12:15] <mup> PR snapd#2255 closed: tests: improve refresh-undo test <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2255>
[12:16] <mup> PR snapd#2248 closed: tests: make refresh-undo wait a bit for the output of the restarted v1 service <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2248>
[12:18] <Exquisitus> you mean in the yaml?
[12:19] <didrocks> yes, in your snapcraft.yaml
[12:20] <Exquisitus> source: https://github.com/iotaledger/iri.git     plugin: maven     snap: [-usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts]
[12:20] <Exquisitus> that way?
[12:20] <Exquisitus> sorry for bad formatting
[12:21] <didrocks> well, I can't say if yes or no, but if snap: is at the same level than plugin:, yes
[12:21] <didrocks> sergiusens: if the file is coming from the maven plugin, shouldn't be that one handle those symlinks and ignoring them?
[12:23] <mup> PR snapd#2158 closed: many: remove unnecessary snap name parameter from buying endpoint <Created by pete-woods> <Merged by pete-woods> <https://github.com/snapcore/snapd/pull/2158>
[12:27] <Exquisitus> exactly the symlink comes from maven that has the jdk dependency
[12:29] <sergiusens> didrocks hence the bug
[12:30] <didrocks> sergiusens: oh, I did miss your line about the bug, sorry, seeing it now
[12:30] <didrocks> Exquisitus: do you mind opening another bug on lack of information from the store on snapcraft push?
[12:46] <Exquisitus> https://github.com/snapcore/snapcraft/pull/761
[12:46] <mup> PR snapcraft#761: Remove dangling symlink from JDK plugin <Created by gnuoy> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/761>
[12:46] <Exquisitus> thanks it worked now
[12:48] <didrocks> Exquisitus: do you mind opening the bug I asked about above? (the one about lack of information on snapcraft push)
[12:48] <didrocks> happy that it's working now!
[12:52] <Exquisitus> ok shall I open it on github?
[12:53] <Exquisitus> because there's already one: https://github.com/snapcore/snapcraft/pull/761
[12:53] <mup> PR snapcraft#761: Remove dangling symlink from JDK plugin <Created by gnuoy> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/761>
[12:54] <Exquisitus> didrocks: sorry where should I open the bug? happy to do it
[12:54] <didrocks> Exquisitus: https://launchpad.net/snapcraft
[12:54] <didrocks> thx! :)
[12:54] <didrocks> and not the JDK plugin bug
[12:54] <didrocks> but the other one, what you came for first: "no information on snapcraft push on why it failed"
[12:58] <sergiusens> didrocks we have a bug for push already
[12:59] <sergiusens> didrocks LP: #1602095
[12:59] <mup> Bug #1602095: Uploading a snap that requires a manual review shows an error that's not great <store> <Snapcraft:New> <Software Center Agent:New> <https://launchpad.net/bugs/1602095>
[12:59] <didrocks> sergiusens: thanks you!
[12:59] <didrocks> Exquisitus: no need then ^
[13:00] <Exquisitus> ah ok
[13:20] <sergiusens> didrocks OLS just needs poking ;-)
[13:23] <didrocks> sergiusens: they don't look at bugs? :p
[13:23] <ogra_> zyga, bbb and linux-generic-bbb in the store ...
[13:24] <ogra_> zyga, and http://people.canonical.com/~ogra/snappy/all-snaps/stable/current/ for the image
[13:24]  * ogra_ goes back into vacation mode
[13:36] <mup> PR snapcraft#906 opened: indicators: support TERM=dumb <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/906>
[13:41] <zyga> ogra_: thank you! woot :)
[13:41] <zyga> ogra_: do you have one for beagle c4?
[13:41] <ogra_> nope
[13:41] <ogra_> (the kernel should work for the C4, i think there is a dtb for it in linux-generic)
[13:48] <mup> PR snapd#2277 opened: snap: add new `snap prepare-image --devmode` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/2277>
[14:17] <jdstrand> mvo: hey, so bug https://bugs.launchpad.net/snappy/+bug/1638656 is rather annoying for me. for various reasons, I am doing snappy development in an lxd container, but the snapd testsuite fails
[14:17] <mup> Bug #1638656: snapd testsuite fails when run inside an lxd container <Snappy:New> <https://launchpad.net/bugs/1638656>
[14:19] <jdstrand> mvo: which means I run tests manually, which leads to the issues in the avahi-observe PR. do you have a feeling for when that might be fixed if at all?
[14:19] <mup> Bug #1641958 opened: The Cliqz snap will not run from either menu or CLI <Snappy:New> <https://launchpad.net/bugs/1641958>
[14:19] <jdstrand> mvo: what is interesting about those failures is that they are all failing in /tmp
[14:20] <jdstrand> mvo: and I know that lxd sets up a /tmp like snappy does. /me wonders if he can make lxd not do that as a workaround
[14:20] <jdstrand> (I also don't know if that is the cause, it is just 'interesting')
[14:22] <mvo> jdstrand: let me have a look
[14:22] <mup> Bug #1641960 opened: Unable to locate package snapd in Debian RPi <Snappy:New> <https://launchpad.net/bugs/1641960>
[14:22] <mvo> jdstrand: this rings a bell
[14:41] <ypwong> Is it possible to put firmware in gadget snap? Because driver is already in kernel snap but firmware is not.
[14:44] <Cameron_> I have a question
[14:49] <willcooke> zyga, yo!  The Armbian guys are going to get a beta kernel with apparmour in for testing.  Will ping you as soon as I get it
[14:49] <willcooke> zyga, @ OPi Zero ^
[14:49] <zyga> willcooke: are you aiming for core or classic first?
[14:50] <zyga> willcooke: and thanks for pinging back! exciting stuff
[14:50] <willcooke> zyga, classic first, because they've done pretty much all the work already
[14:50] <zyga> ok
[14:50] <zyga> yeah, seems sensible
[15:03] <Elleo> is there a way I can get the original $HOME value from within a snap (not the modified ~/snap/<snapid>/ version?)
[15:10] <zyga> tvoss: is the util-linux SRU done?
[15:10] <zyga> tvoss: I see  *** 2.20.1-5.1ubuntu20.11 0
[15:10] <zyga> tvoss: from your PPA
[15:20] <jdstrand> mvo: thanks! let me know if you want me to test something. I'd love to be able to run ./run-tests :)
[15:20] <jdstrand> mvo: err, run-checks
[15:27] <tvoss> zyga: in flight, whatever is in my ppa is going to be SRU'd though, plus version bump :)
[15:29] <zyga> k
[15:30] <zyga> tvoss: a big :'-( for not having nsenter tehre
[15:30] <tvoss> zyga: not sure I'm following :)
[15:30] <tvoss> oh, in util-linux
[15:30] <zyga> tvoss: yes
[15:31] <zyga> it's invaluable as an analysis tool
[15:31] <tvoss> zyga: okay, time for another sru then
[15:31] <zyga> yeah, no worries :)
[15:42] <mup> PR snapd#2147 closed: asserts: validate optional account username <Created by emgee> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2147>
[15:45] <mup> PR snapcraft#907 opened: readme: rocket instead of irc <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/907>
[15:58] <mvo> jdstrand: ha! fun (or not), I created an lxd container and couldn't reproduce
[15:58] <mvo> jdstrand: but I think I did not follow the instructions correctly, let me try again
[15:58] <jdstrand> jdstrand: hmmm. that is 'fun' :)
[15:58] <jdstrand> mvo: fyi, I am using the lxd snap
[15:59] <mvo> jdstrand: I think I can lxc as root
[15:59] <mvo> jdstrand: ohhhhh
[15:59] <mvo> jdstrand: I'm using the package
[15:59] <mvo> jdstrand: let me try with the snap
[16:04] <jdstrand> mvo: http://paste.ubuntu.com/23481011/
[16:22] <qengho> I'm looking for a migration path to config hook from old handmade config file. Can a configure hook call "snap set" safely? Assume the condition changes that makes it call snap-set in the first run, like config file moved aside and not detected thereafter.
[16:23] <qengho> Oh, maybe it should be calling "snapctl set"?!
[16:25] <didrocks> qengho: yeah, your configure script can only call snapctl, not snap
[16:25] <didrocks> (and you don't need the snap name in snapctl)
[16:33] <mup> PR snapcraft#903 closed: store: download without login <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/903>
[16:47] <shuduo> slangasek: hi
[16:58] <jdstrand> zyga: hey, ok, spread-test added to https://github.com/snapcore/snap-confine/pull/181 but it doesn't run due to something in the test infrastructure (see my comment in the PR)
[16:58] <mup> PR snap-confine#181: add compatibility architectures for supported architectures (LP: #1592022) <Created by jdstrand> <https://github.com/snapcore/snap-confine/pull/181>
[17:00] <zyga> jdstrand: looking
[17:00] <zyga> jdstrand: ah I saw this myself
[17:00] <zyga> jdstrand: I'll update packaging to take account of the merged patches
[17:00] <mup> PR snapd#2278 opened: tests: add test that ensures that we do not garbage collect the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/2278>
[17:00] <zyga> jdstrand: I'll take a quick break and be back soon
[17:01] <jdstrand> zyga: ok. note, this isn't an emergency PR. fine to pick it up tomorrow afaic
[17:09] <slangasek> shuduo: hello
[17:11] <shuduo> slangasek: hi, i notice you have reported a netowrk issue of store https://lists.ubuntu.com/archives/snapcraft/2016-October/001355.html
[17:11] <shuduo> slangasek: i wonder if the issue is still exist or already fixed
[17:12] <slangasek> shuduo: those snaps are on the stable channel now
[17:12] <slangasek> shuduo: so that problem no longer exists
[17:13] <shuduo> slangasek: i'm helping a customer to migrate their kernel snap from u-d-f to ubuntu-image and encounter network time out issue
[17:13] <shuduo> sudo /snap/bin/ubuntu-image -c beta --image-size 4G --extra-snaps ./bubblegum96-gadget_0.1.0_arm64.snap --extra-snaps ./bubblegum96-kernel_3.10.0_arm64.snap -o bubblegum96.img bubblegum96.model
[17:13] <shuduo> error: cannot fetch and check prerequisites for the model assertion: Get https://assertions.ubuntu.com/v1/assertions/account-key/6PVAOu6V-pOb7bCSIB9W0WRSnVZwySqShrne8zWWWhIh6oW65o1ynHD4XoT3wSzF?max-format=0:
[17:13] <shuduo> net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
[17:13] <shuduo> COMMAND FAILED: snap prepare-image --channel=beta --extra-snaps=./bubblegum96-gadget_0.1.0_arm64.snap --extra-snaps=./bubblegum96-kernel_3.10.0_arm64.snap bubblegum96.model /tmp/tmpk_f88lrl/unpack...subprocess.CalledProcessError: Command '['snap', 'prepare-image', '--channel=beta', '--extra-snaps=./bubblegum96-gadget_0.1.0_arm64.snap', '--extra-snaps=./bubblegum96-kernel_3.10.0_arm64.snap',
[17:13] <shuduo> 'bubblegum96.model', '/tmp/tmpk_f88lrl/unpack']' returned non-zero exit status 1
[17:14] <slangasek> shuduo: that thread is not about a network timeout issue at all.  If you are trying to do an offline snap prepare-image, I'm afraid that's not something I have knowledge about
[17:15] <shuduo> slangasek: sorry just found Luke Williams reported a http 500 error. sorry my mistake
[17:30] <zyga> tvoss: more green :)
[17:31] <zyga> tvoss: I just pushed a few trivial patches back
[17:32] <zyga> tvoss: I'll get some tea and see how this unfolds
[17:32] <zyga> tvoss: I will also go over the diff and fix any small things I was thinking about
[17:41] <jdstrand> mvo: note though that I have a complete setup in bug #1638656 where I was able to reproduce in an lxd container from a deb
[17:41] <mup> Bug #1638656: snapd testsuite fails when run inside an lxd container <Snappy:New> <https://launchpad.net/bugs/1638656>
[17:58] <mup> PR snapd#2225 closed: Implement lxd-client interface exposing the lxd snap (LP: #1634880) <Created by kalikiana> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2225>
[18:09] <zyga> tvoss: not fully green but greener
[18:37] <tvoss> Hi
[18:38] <tvoss> zyga: sounds promising, I'll grab a quick bite, with you after that
[18:46] <zyga> tvoss: so according to https://travis-ci.org/snapcore/snapd/builds/176117575 the only task that failed is *restore* on     - linode:ubuntu-14.04-64:tests/upgrade/basic
[18:47] <zyga> tvoss: there are some faliures to prepare on other releases that need to be investigated and fixed
[18:47] <zyga> tvoss: the restore failure is E: Packages were downgraded and -y was used without --allow-downgrades.
[18:47] <zyga> tvoss: I think that's some of the assumption that doesn't hold in the ppa case
[18:47] <zyga> tvoss: in any case, I think we are super close
[18:48] <zyga> tvoss: I'm actually EOD now but I'll continue tomorrow
[18:48] <zyga> tvoss: with my service tweak and small apparmor change it looks like everything really works now
[18:48] <zyga> tvoss: I'll check which tasks are disabled on 14.04 and see if we can re-enable them, if any
[18:57] <tvoss> Zyga, ack sounds good, I'll take a look at the upgrade failurr, have a good idea why it is failing
[18:57] <mup> PR snapcraft#907 closed: readme: rocket instead of irc <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/907>
[19:23] <mup> PR snapd#2279 opened: interfaces: add alsa (LP: #1598309) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2279>
[20:02] <mterry> When I build a snap locally with snapcraft, I will see a more extensive LD_LIBRARY_PATH in its command-*.wrapper files than I see with a snap build in an LP bileto silo.  Is that simply becuase I'm not using cleanbuild and snapcraft is stuffing bits of my local environment in there?
[20:05] <mterry> (and if so, is there a way to stop it doing that without doing the bother of cleanbuild?)
[20:08] <balloons> ka
[20:08] <balloons> kalikiana_, happy to see the interface landed :-)
[20:18] <ahoneybun> mhall119: anyway to force a snap to look for a file somewhere>
[20:19] <ahoneybun> GLib.Error: g-file-error-quark: Failed to open file '/share/pithos/pithos.gresource': open() failed: No such file or directory (4)
[20:19] <ahoneybun> I think it needs to look in $SNAP/share/pithos/ for it
[20:23] <mup> PR snapd#2280 opened: interfaces: miscellaneous policy updates (LP: #1639988, 1614269, 1639614, 1605216, 1629996, et al) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2280>
[20:24] <sergiusens> mterry mind logging a bug for that?
[20:25] <mterry> sergiusens: sure
[20:35] <mterry> sergiusens: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1642041
[20:35] <mup> Bug #1642041: LD_LIBRARY_PATH values are inconsistent when working with others <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1642041>
[20:35] <sergiusens> mterry meh, not an Ubuntu bug! Those we sort of not keep track of ;-)
[20:36] <sergiusens> mterry much less when we make snapcraft a snap :-)
[20:36] <mterry> sergiusens: then close that bug tracker down
[20:36] <mterry> move it where ya like
[20:37] <mterry> I guess you can't close down an ubuntu tracker
[20:37] <sergiusens> mterry I can't we use it for SRU bugs :-)
[20:37] <sergiusens> mterry I'll make sure I move the bug
[20:37] <mterry> sergiusens: ubuntu is where I get my snapcraft binary...
[20:37] <sergiusens> mterry thanks for it!
[20:37] <sergiusens> mterry yeah, but we have no one triaging ubuntu bugs
[20:38] <sergiusens> so it sort of gets lost
[20:38] <mterry> well. ok
[20:38] <sergiusens> and we have no elegant way to close them as our debian/changelog only mentions the SRU bug per agreement with the release team
[20:52] <mhall119> ahoneybun: it depends on the code how to tell it that
[21:09] <mup> PR snapcraft#889 closed: cache: snap revision caching on 'push' <Created by squidsoup> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/889>
[21:15] <mup> PR snapcraft#893 closed: Add a script to retry autopktests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/893>
[21:28] <ahoneybun> mhall119: the yaml file you mean?
[21:28] <ahoneybun> http://pastebin.ubuntu.com/23482554/
[23:09] <mup> PR snapd#2281 opened: dirs,interfaces,overlord,snap,snapenv,test: export per-snap XDG_RUNTIME_DIR per user (LP: #1620442) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2281>
[23:16] <mup> Bug #1620442 opened: snap fails because XDG_RUNTIME_DIR is set to /run/user/1000 <snapd-interface> <Snappy Launcher:In Progress by jdstrand> <Snappy:In Progress by jdstrand> <https://launchpad.net/bugs/1620442>
[23:25] <flexiondotorg> sergiusens, Yo
[23:25] <flexiondotorg> Is there an environment variable I can rely on being set to determine snapcraft is doing the build?
[23:26] <flexiondotorg> I am adding some logic to one of my Python projects setup.py.
[23:26] <flexiondotorg> So that is can be pip installed for non-snap users.
[23:27] <flexiondotorg> But also not fail during the build step when being built on Launchpad as a snap.
[23:41] <mup> Bug #1642082 opened: Timestamp error when we try to sign a model assertion <Snappy:New> <https://launchpad.net/bugs/1642082>
[23:49] <liuxg_> hi