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