[01:40] jdstrand: I guess it's fine. I can't really test this until we get the snap moved though :) [02:03] Bug #1615566 changed: snapcraft SDK [02:21] Bug #1615030 changed: Ability to completely remove a snap from the snap store [03:13] Bug #1612909 opened: Unable to install snappy in Fedora === chihchun_afk is now known as chihchun === BlueT is now known as BlueT_Lien [08:12] o/ === ant_ is now known as Guest15611 [08:20] mwhudson: hey, can you tell me what is your workflow for snap-confine in debian [08:21] mwhudson: I have the repo from alioth, I see some work towards 1.0.40 [08:21] mwhudson: I'd like to finish that and release it to sid and yakkety === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [09:16] jdstrand: dh-apparmor is not in main, yet snap-confine build-depends on it [09:16] jdstrand: somehow it never caused issues but isn't this against the policy/ [09:37] niemeyer: latest spread (from a snap) gives me this output: 2016/08/23 11:36:40 Allocating &{linode ubuntu-16.04-64-grub ubuntu-16.04-64-grub %!s(int=1) %!s(*spread.Environment=&{ [] map[]}) []}... [09:38] niemeyer: similarly the output is very wrong after that [10:02] Hi folks. General question: I've got a simple one file python2 script that I'd like to snap. I have my snapcraft.yaml in the same folder. was hoping that I'd just be able to do this?: http://paste.ubuntu.com/23080902/ but it doesn't seem to be able to find it in the scripts directory: "[Errno 2] No such file or directory: .../prime/scripts/script.py". Do I need a makefile? [10:04] Bug #1616006 opened: clean remove of snapd [10:08] autonomouse: you need setuptools support AFAIK [10:09] zyga, ok, I'll look into that now. thanks [10:18] mvo, urgh ... i guess we didnt update the pi3 gadget along ... http://paste.ubuntu.com/23081105/ [10:18] davidcalle: heya [10:18] davidcalle: do we have online references on building kernel snaps? e.g. on snapcraft.io [10:19] Hello everyone, I do not know if this is the right place to ask. Are there restrictions in running a docker container that needs to access a serial port? I do not know, permits or other? In docker normally just expose the device with --device [10:19] davidcalle: if not, I have seen various base materials fly around that would be good starting points for a kernel page [10:20] ysionneau: what was your issue with docker? [10:21] heart: privileged containers are required for this; it migth work, if it doesn't I'd be interested in the error you're gettig [10:21] heart: note however that this is basically giving root to anything running in that container [10:22] ogra: indeed, looks like this is missing [10:22] yeah, just comitted and pushed [10:22] lool: naturally, I think I have some problem even with privileged mode. I continue to investigate and let you know [10:24] lool: I'm working with a dell edge gateway [10:25] mvo, https://myapps.developer.ubuntu.com/dev/click-apps/5596/rev/2/ ... please approve [10:28] ogra: done [10:28] thx === hikiko is now known as hikiko|ln [10:43] PR snapd#1721 opened: dependencies: update godeps [10:45] mvo, hmm ... http://paste.ubuntu.com/23081147/ [10:46] ogra: hm, no netwokring? [10:46] (pi3 with the snappy_boot script chaNGES IN TEH GADGET) [10:46] EEK [10:46] ogra: ha! CAPSLOCK [10:46] geez, i need to rip off that caps key [10:46] ogra: I remapped mine - ctrl:nocaps [10:46] mvo, deliberately since the pi3 now has wlan support [10:46] so the cable is unplugged [10:46] ogra: oh, this may be a general image bug [10:47] butu before it actually told me that the networking job is waiting [10:47] mvo, well, i actually think its a systemd bug (or at least the systemd network bringup part) that it does not sense if a cable is plugged in [10:47] pitti, ^^^ [10:48] (and it is now about 2years old too ... ) [10:48] should not be hard to check for a connected cable really ... [10:48] ogra: hm, pi2 without network cable booted ok [10:49] i guess you need two NICs ? [10:49] ogra: possible, I can see if I find a wlan thing [10:49] i'll do a re-flash after my test runs [10:50] and will check if plugging it in actually makes a difference (the dragon only has wlan, the pi2 only eth) [10:50] sigh ... cloud-init still not finished [10:50] thats close to a 5 min firstboot now :/ [10:51] ah, now i have the prompt [10:51] ubuntu@localhost:~$ cat /etc/network/interfaces.d/enxb827ebc92b03 [10:51] allow-hotplug enxb827ebc92b03 [10:51] iface enxb827ebc92b03 inet dhcp [10:51] ubuntu@localhost:~$ [10:51] aha [10:52] sdo it created a config for the wired NIC ... regardless if it is in use [10:53] (and i remeber we had an additional option in there to wotrk around that bug in 15.04 ) [10:57] mvo, hmm, funny, it doesnt hang on the second boot [10:57] so it is the combo of firstboot and the allow-hotplug line [10:57] ogra: oh, I think I know [10:57] ogra: there is a race in the network bringup code [10:57] yay [10:57] :P [10:58] ogra: there is a fix in a PR :) [10:58] \o/ [10:58] ogra: I will extract it and push a separate pr, its currently part of a big brnach [10:59] ok [11:06] * ogra does a quick ubuntu-core armhf build to check the upgrade mechanism [11:12] mvo, in snapweb, all installed snaps listed after the first boot are marked non-removable, *except* the kernel ... [11:12] i guess we dont want users to allow removing the only kernel that is installed ? [11:13] ogra: definitely not [11:13] is that info from snapd thats wrong or is it a snapweb bug [11:13] guys see the design , https://github.com/keshavbhatt/snapcraft-gui [11:13] ogra: `$ sudo snap remove pi2-kernel [11:13] error: cannot remove "pi2-kernel": snap "pi2-kernel" is not removable [11:13] ` [11:13] ogra, mvo: ifupdown doesn't block boot on allow-hotplug, is that what's hanging? [11:13] ogra: so that won't work [11:13] ogra: snapweb is buggy [11:13] anyway, too little information/context here -- please file a bug with the details if there is any [11:13] mvo, right, but it shouldnt even show me the "remove snaüp" button [11:14] pitti, seems to be the interaction with snappy firstboot ... still, why is systemd not checking the cable state and just ignore the interface ? [11:14] ogra: yes, bug [11:15] mvo, right, where ? :) [11:15] * ogra wants to file it [11:15] is it snapd giving wrong info or is it snapweb not respecting it [11:16] ogra: what are you using? ifupdown or networkd? [11:16] pitti, ifupdown obviously [11:16] ifupdown support for hotplugging/cable state is quite bolted on, but it works in general, so again -> bug [11:17] ogra: "obviously" → not really any more :) [11:17] (i'm not sure what creates the /e/n/i entry though ... that might be snapd) [11:17] pitti, obviously because we have an /e/n/i file after first boot :) [11:17] for the NIC [11:17] PR snapd#1721 closed: dependencies: update godeps [11:18] PR snapd#1715 closed: asserts,overlord/devicestate: simplify private key/key pairs APIs, they take just key ids [11:19] mhall119, https://github.com/keshavbhatt/snapcraft-gui === hikiko|ln is now known as hikiko [11:32] PR snapd#1722 opened: many: support install and remove by revision [11:43] bull: very cool! [11:45] davidcalle, ty did you compiled it ?? [11:46] bull: yes, runs just fine [11:47] wow :D ty [12:24] ogra, am I doing this the right way? e.g. bug 1616048 and bug 1616045 [12:24] Bug #1616048: Create interface for ofono [12:24] Bug #1616045: Create interface for the power daemon [12:25] I look at snapd/interfaces/builtin and can't find it, then I search for a bug for it in the snapd package on launchpad. [12:25] jgdx, yeah, i belive that is right ... there is a tag you should set for interfaces [12:25] * ogra looks for it [12:26] snapd-interface [12:26] set that too, then zyga and jdstrand see it on their lists [12:26] ogra, cool, thanks. I think I'm going to create ~20 of these [12:27] :) [12:35] lool: any news about a build with the bug fix on snapweb for armhf? [12:36] ysionneau: no, elopio has a solution to provide one, but I +1-ed his pull request yesterday after he EOD-ed [12:36] ysionneau: he should be up soon; however the fix is merged in snapweb master if you want to rebuild [12:38] dooes that include a fix for bug 1610026 ? [12:38] Bug #1610026: snapweb fails to start after reboot [12:39] jgdx: are you planing to work on the ofono interface for snapd? [12:40] morphis__, no [12:40] jgdx: ok [13:19] hmm, do we have any example snap that uses a bzr branch in the "source:" option ? [13:34] ogra https://github.com/snapcore/snapcraft/blob/master/demos/libpipeline/snapcraft.yaml [13:36] sergiusens, ah, awesome, thanks ! [13:37] PR snapcraft#749 closed: Allow registering private packages [13:49] wililupy: I had asked for permission to comment/edit on https://docs.google.com/document/d/1mo_Xkg9yBotGRg4qMYYuVn1d35NwGLpCkxE3T_p85P8/edit?ts=57bc4e2f#heading=h.d2h64kdfycq but it seems it's not the latest one [13:50] wililupy: FYI there were some "mlnx" references in the one you sent to Dell but I guess that's ok [13:50] wililupy: there were a couple of things I wanted to suggest for simplification [13:52] ogra - i apologize, i checked my logs and dont have enough history. Can you re-link me to the latest RPI2 images for snappy? [13:53] lazyPower: https://people.canonical.com/~mvo/all-snaps/16/ [13:53] s/snappy/ubuntu core/ [13:53] ah, ta lool [13:55] the fast frenchman ! [13:55] :) === JanC is now known as Guest58470 === JanC_ is now known as JanC [14:12] zyga (cc jdstrand): regarding dh-apparmor, only run time depends need to be in main now [14:12] zyga: the policy changed during the 16.04 dev cycle [14:19] WOAH ! [14:19] cjwatson, https://launchpadlibrarian.net/280537082/buildlog_snap_ubuntu_xenial_armhf_pi2-kernel_BUILDING.txt.gz ... i have split the Makefile from the kernel snap branch into its own bzr tree, this is what i get when trying to build now [14:20] is that LP, the firwall or actually bzr (as it claims) [14:21] ogra: we talked about that bug before, I think; https://bugs.launchpad.net/snapcraft/+bug/1606203 [14:21] Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' [14:21] oh, i remember .. the huge amount of output confused me [14:22] I analysed it at the time and was pretty sure it was a bzr bug, but I don't remember the precise chain of reasoning [14:23] hmm ... i could perhaps just switch to git, but i exactly wanted to avoid mixing bzr and git for the kernel snaps [14:27] kyrofa, sergiusens, ^^ any chance this could be quickly fixed in snapcraft (unsetting http_proxy for bzr source pull) ? [14:36] i guess a simple os.putenv('http_proxy'.'') would do ? [14:36] sergiusens: mvo ever seen a bug like this? [14:36] http://pastebin.ubuntu.com/23081827/ [14:37] it says change in progress, but then no change listed? [14:37] or "del os.environ['http_proxy']" rather [14:41] kgunn: hm, what does "snap change 34" show? [14:41] kgunn: but definitely strange [14:43] mvo: http://pastebin.ubuntu.com/23081849/ [14:43] ...it's all ok actually [14:43] now [14:43] you were just to impatient :) [14:43] at least, it acted like it had not removed the pkg, but in reality it had [14:44] no it timed out... [14:44] snapd works async (super annoying if you ask me) [14:44] but it really was removed [14:57] mvo: hey, is https://github.com/snapcore/snapd/pull/1720#issuecomment-241602474 something you can help with or should I go to the store? [14:57] PR snapd#1720: interfaces: add lxd-support interface [15:04] kgunn: it looks like what I've seen when trying to remove snaps which were still running. I believe there's a bug for that. [15:07] kgunn, yeah I just recently ran into that as well [15:07] kgunn, I caused it by restarting services by hand instead of letting systemd do it [15:08] PR snapd#1723 opened: image: prepare-image: import snap assertions as well [15:08] kyrofa: i did admittedly kill a process [15:08] kgunn, which means when the snap was being removed, it asked systemd to stop everything and then tried to unmount, but my service was outside systemd [15:08] (so the mount was still in use) [15:09] PR snapd#1724 opened: snap: add `snap download` implementation [15:27] PR snapd#1697 closed: interfaces/builtin: allow bind in the network interface [15:31] PR snapcraft#740 closed: Allow debugging cleanbuild runs [15:37] PR snapcraft#750 closed: storeapi: remove dependency on the 'success' attr [15:41] jdstrand, I should be good to go as far as running snaps with an encrypted home is concerned nowadays, right? [15:42] kyrofa: yes. snap-confine is now in -updates [15:43] kyrofa: and it has the policy changes needed for that [15:43] kyrofa: were you seeing a problem? there was a weird ubuntu-image bug related to ecryptfs, but that is different than what you're asking about [15:44] jdstrand, no, I saw the bug and never bothered to try [15:45] ah [15:45] yes, it should all be fixed now [15:45] jdstrand, my background with bugs relating to ecryptfs is... bad. Last time it just got eaten [15:45] (the click chroot thing for the SDK) [15:45] hmm [15:45] eaten [15:45] well, if you are seeing issues with policy, feel free to talk to me. if it is misbehaving, you can talk to tyhicks [15:46] Sounds good, glad to know it should all be fixed now! [15:46] Thank you :) [15:48] the click chroot issues were systemd and schroot bugs [15:49] PR snapd#1725 opened: overlord/hookstate: use snap run posix parameters [15:51] I ended up fixing them because everyone kept calling them ecryptfs bugs but they were both years old schroot bugs that were never fixed [15:51] jdstrand: heya, around? [15:51] tyhicks, heh [15:52] jdstrand: couple of questions related to docker snap === chihchun is now known as chihchun_afk [15:52] jdstrand: currently it uses /var/run/docker.sock [15:52] kyrofa: do you know if any of the snapcraft plugins copy the parts//src dir to the build dir? [15:52] jdstrand: I find that problematic for 2 reasons [15:52] joc_, dump, I believe [15:52] jdstrand: one is that it conflicts with the .deb, so you can't snap install on classic if you had the deb and vice-versa [15:53] jdstrand: the other reason is that it kind of breaks the model where one could simply fork the docker snap and rename it, or embed it into another snap (e.g. snap containing docker runtime + docker images) as it's not relocatable anymore [15:53] jdstrand: tianon suggested you wanted to keep the docker.sock name though [15:53] I mean the /var/run pathname [15:53] kyrofa: it makes the snapcraft help sources text a bit redundant, particualy for the source-subdir, as nothing seems to do what is described [15:53] * zyga votes +1 for $SNAP_DATA-based socket [15:54] (and interface attrs and hooks) [15:54] jdstrand: other question is: do you mind approving the docker 15.04 snap in the review queue? [15:54] jdstrand: it adds the /home permissions you said were ok to add for 15.04 [15:54] kyrofa: we were just investigating why a python3 part was failing and realised that attribute is ignored by the plugin but it's not mentioned anywhere [15:54] zyga: yeah, I was thinking like a docker-socket bin to get the socket name for people that want to get it programatically [15:55] lool: that will be exposed with the snapctl tool I suspect [15:55] lool: you can use it to ask for an attribute easily [15:56] joc_, I'm not sure I understand where you're coming from, here [15:56] zyga: so the docker snap would set an attribute and it could be queried? [15:56] like config, but runtime? [15:56] yes [15:56] that's the hook a few people are working on [15:56] kyrofa, pstolowski [15:56] lool: I am [15:56] yeah, that sounds like a good fit when that's avail [15:57] joc_, so you're having a problem with source-subdir? [15:57] lool: ideally I would like to see the socket in SNAP_DATA [15:57] kyrofa: basically i'm saying there is a bug that the help text for the python3 plugin doesnt say the source-subdir will not have any effect [15:58] kyrofa: but was also thinking there is bug with "snapcraft help sources" output because almost no plugins do what that says with respect to source-subdir [15:58] joc_, or just a bug in the python3 plugin. The code looks like it should work fine-- what do you see happening? [15:59] * kyrofa reads `snapcraft help sources` [15:59] lool: renaming it in /run to be /run/snap.docker.sock or something would be ok too. I don't object to it being somewhere else-- I just wanted to make sure that it was understood that if it was moved that might break other tools that expect it in a particular location. if that is understood and people are ok with it, fine (also, there is nothing saying that if it was in SNAP_DATA now that we couldn't change it back) [15:59] kyrofa: all the easy_install commands etc are run in the src dir [15:59] jdstrand: it's certainly true that it will break existing constructs [15:59] joc_, yeah that's a bug in python3. Indeed, I agree that there's a bug in `help sources`, but it's because the source-subdir docs are wrong [16:00] jdstrand: I'm not really sure how to avoid this and move the socket though [16:00] joc_, this is what SHOULD happen: [16:00] unless we implement a complex mechanism in the .deb and in the snap to try to take the socket if it's unowned, but that seems broken too [16:00] or just fail install [16:01] BTW, most people install the docker .deb from docker inc which we can't change for this [16:01] lool: I' [16:01] lool: I think I heard on the list not to worry about conflicting with debs. that in the fullness of time snap install or something higher would guide the user in some manner [16:01] joc_, the entire `source` should be copied build, including the subdir. However, the subdir should be the working directory [16:01] lool: I've implemented something that lets us poke arbitrary holes as "quirks" for various snaps [16:01] lool: and that now users can just remove the deb [16:01] joc_, the docs are how things used to work, but then we realized that projects typically need the rest of the project tree [16:01] jdstrand: fair enough [16:02] Looks like that never got updated, though [16:02] jdstrand: I'll suggest adding an upstream flag so that people don't hardcode the pathname in docker run commands though [16:02] something like --share-daemon or so [16:02] kyrofa: yeah makes sense [16:02] cool [16:04] mvo: your rpi2 image from the 19th has been trying to boot for 5 minutes. Is that normal? [16:07] ah, it was snapweb failing to start. Just what manik said yesterday, probably. [16:09] * ogra sighs so unsetting http_proxy doesnt survive the selftest in snapcraft when building it :( [16:11] why does the test even care :/ [16:11] ogra: tell me more. What do you mean with snapcraft selftest? [16:12] elopio, i need to move parts of the kernel snap build int a separate bzr branch ... which resulted in this beautiful error https://launchpadlibrarian.net/280537082/buildlog_snap_ubuntu_xenial_armhf_pi2-kernel_BUILDING.txt.gz [16:12] which seems to be bug 1606203 [16:12] Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' [16:13] elopio, so i tried a quick hack http://paste.ubuntu.com/23082327/ ... [16:14] which results in https://launchpadlibrarian.net/280550295/buildlog_ubuntu-xenial-amd64.snapcraft_2.15.1+ppa1_BUILDING.txt.gz [16:14] i dont really get why the bzr test in snapcraft would care about me deleting a (most likely non--existing) env var [16:16] ogra: ah, that's a test to make sure that the env var is deleted :) [16:17] elopio, not really, see the paste [16:17] ii dont touch the test code at all [16:17] i only del the var before calling pul [16:17] *pull [16:17] let me see... [16:18] its a super dumb patch [16:19] ogra: what the error is saying is that those attributes are not in os.environ. [16:19] perhaps i should use os.unsetenv() instead ... [16:19] elopio, yes, they indeed wont be unless a build happens in LP [16:19] (i mean a snapcraft build, not the build of the snapcraft package) [16:20] and i dont really want to set them, since that would actually taint the test [16:20] i would like it to just ignore it [16:21] ogra: why don't you do os.environ["HTTP_PROXY"] = "" [16:22] i can surely try that, do you think the test wont complain then ? [16:23] * ogra tries [16:23] you will get a different result for sure. That's all I can say :) [16:23] lol [16:23] well, ppushed to the PPA, lets see [16:24] (one day all image bulds will actually work without me hacking up snapcraft ... ) [16:28] that would be nice. But this thing of removing the proxy env var from a plugin doesn't seem likely to get upstream. [16:28] kyrofa: hey, got one you might have an idea on.... [16:28] elopio, well, it makes building bzr projects oon LP impossible [16:29] elopio, and a fix in bzr is very unlikely to happen [16:29] so, i'm needing to run a script as part of my snapcraft step [16:29] using something that will be in stage [16:29] and then make sure the output of that goes into prime [16:29] ogra: but isn't that a launchpad problem? snapcraft should just use whatever env vars are set in the system. [16:30] elopio, no, it is a bzr bug [16:30] see bug 1606203 [16:30] Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' [16:30] kyrofa: so i want it to be a post-step to the first part [16:30] isn't there a "gate on" [16:30] kgunn: after: [first-part] [16:30] to make sure the script is in stage [16:30] ah thanks elopio [16:30] after... [16:31] that's what i couldn't recall [16:31] * ogra hugs elopio ... the snapcraft package built with that change [16:31] * ogra taps foot waiting for the PPA publisher so i can try if it actually fixes the kernel snap build [16:32] 5^_^ [16:32] * elopio goes to swimming lessons. bbl. [16:32] enjoy ! [16:32] ogra: it would be awesome to have a snap that is the Linux kernel [16:32] ogra: with all the different channels too! [16:33] tsimonq2, well, the kernel snap i build is far more then the linux kernel (it is more a "hardware enablement snap" ... [16:33] we just call it the kernel snap ... for our images [16:33] but the kernel team actually has plain linux snaps [16:33] talk to ppisati_ :) [16:34] ppisati_: are there kernel snaps I can try? :D [16:41] PR snapd#1725 closed: overlord/hookstate: use snap run posix parameters [16:41] kgunn, in a meeting at the moment, but I'll take a look in a sec :) [16:43] Pharaoh_Atem: hey [16:48] ogra just use launchpad git [16:48] bzr is clearly unsupported [16:48] sergiusens, well, ut is still the quasi default ... [16:48] *it [16:49] ogra not for kernel stuff ;) [16:49] well, i dont do kernel stuff [16:50] i do build stuff :P [16:51] as a git hater i was surprised to easily find my way around in github ... but that is because for every prob i can find some howto or help doc ... [16:51] using LP git means i actually need to be familiar with git at a level i dont trst myself yet [16:53] sergiusens, so reading between your lines i guess you agree with elopio that there is no chance to fix bug 1606203 at all in snapcraft ? [16:53] lool: I was able to build snapweb ... but for amd64, I don't even know how to cross compile it for armhf [16:53] Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' [16:54] s/fix/work around/ [16:57] (note that your argument works both ways ;) if bzr is dead anyway snapcraft could as well just ship a tivial hack for the workaround) [16:59] PR snapd#1726 opened: store,tests: have just one envvar SNAPPY_USE_STAGING_STORE to control talking to staging [17:04] ogra should be fixed in launchpad or bzr itself [17:04] sergiusens, well, neither will happen it seems [17:04] ogra so you default to bullying snapcraft? ;-) [17:04] "bullying" with a two line change, yeah [17:05] ogra you might as well just disable the proxy in bzr for that matter [17:06] I am already bitter that we need to do that preload thing to support the g* things, don't make me add more hacks :-) [17:06] g* things ? go you mean ? [17:07] * ogra watches https://code.launchpad.net/~snappy-dev/+snap/pi2-kernel/+build/3413 ... [17:08] PR snapd#1727 opened: dirs,snap: define methods for SNAP_USER_DATA and SNAP_USER_COMMON [17:08] aaand it works \o/ [17:09] to bad you wont accept it :/ [17:16] kgunn, ah, sounds like elopio answered your question [17:17]