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:00 |
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:01 |
jdstrand | it might be possible with PRIO_PGRP. it'll need investigating | 00:02 |
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:04 |
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:05 |
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:06 |
jdstrand | I'll add that to my current policy work trello card | 00:07 |
jdstrand | Trevinho: ^ | 00:08 |
jdstrand | ok, gone for real | 00:08 |
Trevinho | jdstrand: :-). Thanks. | 00:08 |
Pharaoh_Atem | mhall119: CentOS 6 uses upstart | 01:18 |
Pharaoh_Atem | mhall119: specifically, upstart 0.6.5 | 01:22 |
=== chihchun_afk is now known as chihchun | ||
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:13 |
foxmask | bonjello | 07:21 |
liuxg | zyga, ping | 07:50 |
dholbach | hey hey | 08:01 |
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:27 |
zyga | liuxg: hey | 08:34 |
zyga | liuxg: how can I help you | 08:34 |
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:35 |
zyga | liuxg: can you tell me more about the target device, did you perform all development locally? | 08:36 |
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:37 |
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:38 |
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:39 |
zyga | liuxg: are you developing against master or against a particular tagged release? | 08:40 |
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:41 |
mup | Bug #1641869 opened: openvswitch interface <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1641869> | 08:44 |
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:50 |
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:51 |
liuxg | zyga, currently, I have to reinstall the snapd every time. | 08:52 |
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> | 08:53 |
=== chihchun is now known as chihchun_afk | ||
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:12 |
didrocks | mvo: any idea? ^ | 09:16 |
zyga | didrocks: can you report a bug with all the details | 09:16 |
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:17 |
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:18 |
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:19 |
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:20 |
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:21 |
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:22 |
mup | Bug #1641885 opened: jailmode doesn't work with snap try or snap install <Snappy:New> <https://launchpad.net/bugs/1641885> | 09:26 |
=== chihchun_afk is now known as chihchun | ||
didrocks | zyga: ^ | 09:27 |
zyga | didrocks: thanks, I already triaged it | 09:31 |
zyga | tvoss: experimenting now | 09:34 |
zyga | tvoss: I hope to reproduce the issues you saw first | 09:35 |
tvoss | zyga: thanks | 09:35 |
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:54 |
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 | 09:56 |
liuxg | zyga, this is the difference http://paste.ubuntu.com/23479536/ http://paste.ubuntu.com/23479540/ is there anything I missed? | 10:03 |
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:27 |
jamespage | is there a good howto on writing and testing a new interface for snapd/snappy? | 10:31 |
jamespage | nm found http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html | 10:35 |
jamespage | pointed me to my error | 10:35 |
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:46 |
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:47 |
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:48 |
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:50 |
=== JanC is now known as Guest44518 | ||
=== JanC_ is now known as JanC | ||
mup | PR snapd#2274 opened: interfaces: use sysd.{Disable,Stop} instead of sysd.DisableNow() <Created by mvo5> <https://github.com/snapcore/snapd/pull/2274> | 10:55 |
mup | PR snapcraft#902 closed: Snap revision prune <Created by seawaywen> <Closed by seawaywen> <https://github.com/snapcore/snapcraft/pull/902> | 11:00 |
mup | PR snapcraft#905 opened: Snap revision prune <Created by seawaywen> <https://github.com/snapcore/snapcraft/pull/905> | 11:09 |
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:11 |
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:23 |
didrocks | http://snapcraft.io/docs/reference/interfaces for the list | 11:24 |
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:28 |
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:30 |
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:31 |
tsdgeos | didrocks: ok | 11:32 |
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:36 |
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:37 |
Exquisitus | yes it is | 11:39 |
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 [===================================================================================================] 100% Error while processing...| | 11:40 |
Exquisitus | There has been a problem while analyzing the snap, check the snap and try to push again. | 11:40 |
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:41 |
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:42 |
Chipaca | jdstrand: poke | 11:46 |
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:48 |
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:49 |
mup | PR snapd#2276 opened: Add openvswitch-support interface <Created by javacruft> <https://github.com/snapcore/snapd/pull/2276> | 11:50 |
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:54 |
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:55 |
sergiusens | didrocks which branch? The store needs to provide more information first :-) | 11:56 |
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:57 |
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]` | 11:58 |
mup | Bug #1641631 changed: Raspberry Pi images do not support boot from USB <Snappy:Invalid> <https://launchpad.net/bugs/1641631> | 12:00 |
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:02 |
Exquisitus | @sergiusens: thanks a lot , you are better than Jesus | 12:06 |
nothal | Exquisitus: No such command! | 12:06 |
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:07 |
didrocks | Exquisitus: you need to add it in the part shipping this file | 12:12 |
mup | PR snapd#2255 closed: tests: improve refresh-undo test <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2255> | 12:15 |
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:16 |
Exquisitus | you mean in the yaml? | 12:18 |
didrocks | yes, in your snapcraft.yaml | 12:19 |
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:20 |
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:21 |
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:23 |
Exquisitus | exactly the symlink comes from maven that has the jdk dependency | 12:27 |
sergiusens | didrocks hence the bug | 12:29 |
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:30 |
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:46 |
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:48 |
Exquisitus | ok shall I open it on github? | 12:52 |
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:53 |
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:54 |
sergiusens | didrocks we have a bug for push already | 12:58 |
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 ^ | 12:59 |
Exquisitus | ah ok | 13:00 |
sergiusens | didrocks OLS just needs poking ;-) | 13:20 |
didrocks | sergiusens: they don't look at bugs? :p | 13:23 |
ogra_ | zyga, bbb and linux-generic-bbb in the store ... | 13:23 |
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:24 | |
mup | PR snapcraft#906 opened: indicators: support TERM=dumb <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/906> | 13:36 |
=== chrisccoulson_ is now known as chrisccoulson | ||
=== ben_r_ is now known as ben_r | ||
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:41 |
mup | PR snapd#2277 opened: snap: add new `snap prepare-image --devmode` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/2277> | 13:48 |
=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
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:17 |
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:19 |
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:20 |
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:22 |
ypwong | Is it possible to put firmware in gadget snap? Because driver is already in kernel snap but firmware is not. | 14:41 |
Cameron_ | I have a question | 14:44 |
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:49 |
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 | 14:50 |
Elleo | is there a way I can get the original $HOME value from within a snap (not the modified ~/snap/<snapid>/ version?) | 15:03 |
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:10 |
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:20 |
tvoss | zyga: in flight, whatever is in my ppa is going to be SRU'd though, plus version bump :) | 15:27 |
zyga | k | 15:29 |
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:30 |
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:31 |
mup | PR snapd#2147 closed: asserts: validate optional account username <Created by emgee> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2147> | 15:42 |
mup | PR snapcraft#907 opened: readme: rocket instead of irc <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/907> | 15:45 |
=== chihchun is now known as chihchun_afk | ||
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:58 |
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 | 15:59 |
jdstrand | mvo: http://paste.ubuntu.com/23481011/ | 16:04 |
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:22 |
qengho | Oh, maybe it should be calling "snapctl set"?! | 16:23 |
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:25 |
=== JanC_ is now known as JanC | ||
mup | PR snapcraft#903 closed: store: download without login <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/903> | 16:33 |
shuduo | slangasek: hi | 16:47 |
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> | 16:58 |
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:00 |
jdstrand | zyga: ok. note, this isn't an emergency PR. fine to pick it up tomorrow afaic | 17:01 |
slangasek | shuduo: hello | 17:09 |
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:11 |
slangasek | shuduo: those snaps are on the stable channel now | 17:12 |
slangasek | shuduo: so that problem no longer exists | 17:12 |
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:13 |
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:14 |
shuduo | slangasek: sorry just found Luke Williams reported a http 500 error. sorry my mistake | 17:15 |
zyga | tvoss: more green :) | 17:30 |
zyga | tvoss: I just pushed a few trivial patches back | 17:31 |
zyga | tvoss: I'll get some tea and see how this unfolds | 17:32 |
=== pmcg1 is now known as pmcgowan | ||
zyga | tvoss: I will also go over the diff and fix any small things I was thinking about | 17:32 |
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:41 |
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> | 17:58 |
zyga | tvoss: not fully green but greener | 18:09 |
tvoss | Hi | 18:37 |
tvoss | zyga: sounds promising, I'll grab a quick bite, with you after that | 18:38 |
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:46 |
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:47 |
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:48 |
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> | 18:57 |
mup | PR snapd#2279 opened: interfaces: add alsa (LP: #1598309) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2279> | 19:23 |
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:02 |
mterry | (and if so, is there a way to stop it doing that without doing the bother of cleanbuild?) | 20:05 |
balloons | ka | 20:08 |
balloons | kalikiana_, happy to see the interface landed :-) | 20:08 |
ahoneybun | mhall119: anyway to force a snap to look for a file somewhere> | 20:18 |
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:19 |
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:23 |
sergiusens | mterry mind logging a bug for that? | 20:24 |
mterry | sergiusens: sure | 20:25 |
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:35 |
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:36 |
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:37 |
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:38 |
mhall119 | ahoneybun: it depends on the code how to tell it that | 20:52 |
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:09 |
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:15 |
ahoneybun | mhall119: the yaml file you mean? | 21:28 |
ahoneybun | http://pastebin.ubuntu.com/23482554/ | 21:28 |
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:09 |
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:16 |
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:25 |
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:26 |
flexiondotorg | But also not fail during the build step when being built on Launchpad as a snap. | 23:27 |
mup | Bug #1642082 opened: Timestamp error when we try to sign a model assertion <Snappy:New> <https://launchpad.net/bugs/1642082> | 23:41 |
liuxg_ | hi | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!