[00:25] bitpushr: Hi there. I was just investigating a question you had earlier about ssh access. [00:25] bitpushr: afaict, once the first-boot script completes successfully, it's not possible to re-trigger the ssh import. [00:26] bitpushr: Re-flashing so you can re-run the first-boot process is the only option I'm aware of, sorry :/ ( mwhudson may know more, but he's on leave atm). [00:39] Bug #1572038 opened: snap find doesn't find partial names [00:39] Bug #1606539 opened: handler errors from `snap create-user` gracefully [00:42] Bug #1572038 changed: snap find doesn't find partial names [00:42] Bug #1593989 opened: snap installed .desktops collide with .deb installed .desktops in unity7 [00:48] hey all, ran into an issue installing lxd on core-16. I can't create the lxd group that it needs [00:48] any way to do that? [00:51] PR snapcraft#941 opened: Support symlinks within deb sources [01:51] PR snapcraft#930 closed: parser: support remote dependencies [02:06] PR snapcraft#932 closed: cli: implement `enable-ci travis --refresh` command [02:15] PR snapcraft#939 closed: Replace coveralls with codecov [03:03] PR snapcraft#942 opened: store: return specific error when already owned [03:54] PR snapd#2397 opened: interfaces: add iio [07:05] bonjello [07:37] hey hey [07:39] hey dholbach! [07:39] hey seb128 [07:39] dholbach, happy friday! [07:40] and the same to you :) [07:40] happy Friday dholbach :) [07:40] hey guys :) [08:03] tvoss: hey [08:03] tvoss: just finishing something on the arg parsing side and then going back to feedback from reviews [08:03] zyga: good morning :) sounds good to me [08:08] fgimenez, morning, did you look into the autopkgtest failure of snapd on zesty/ppc64el? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd [08:10] hi jibel, nope, i think that mvo has been tackling it [08:12] fgimenez, and is he looking into the failures in xenial too? [08:13] fgimenez, we'd need 2.18 in proposed if there is a release of 2.19 next week [08:13] jibel, not sure but i think so, he can confirm [08:39] PR snapcraft#943 opened: Replace subTests with TestScenarios [09:33] hello, My app is in gnome software but today I log on there and there are two versions of my app on there is it something I have done wrong? [09:34] gerry_: can you look at /var/lib/snapd/desktop/applications/ [09:34] gerry_: are there multiple desktop files for your app there? [09:37] zyga: no just one but it has the icon of the one that appeared in gnome-software today [09:38] gerry_: I suspect that what you see then is a glitch in the gnome-software then [09:38] gerry_: can you report that and attach some screenshots perhaps [09:38] gerry_: maybe you see your app in the store and your app locally installed [09:38] gerry_: and those are separate for some reason (no idea really, not my area of expertise) [09:39] morphis__: hey [09:39] morphis__: how's projects? [09:39] * zyga fixed some tests and runs spread to verify [09:40] gerry_: for gnome-software you want to find robert ancel AFAIK [09:42] zyga: hey! [09:42] zyga: you mean any specific ones :-) [09:42] zyga: ok thank you very much for your help [09:43] morphis__: in general, are things going OK? [09:43] gerry_: his IRC nickname is robert_ancell [09:44] (double l, sorry for getting that wrong earlier) [09:44] gerry_: you may have better luck finding him earlier though as he is from new zeland [09:45] zyga: yeah, so far everything is fine :-) [09:45] zyga: you got the problem with the content itnerface fixed already? [09:46] morphis__: do you mean the multiple entries or something else? [09:46] morphis__: the content interface is not broken AFAIK but needs new features to support some interesting use cases [09:47] morphis__: that bug you spoke about at a call a while ago is fixed [09:47] morphis__: (and the other one as well, I updated LP bugs) [09:47] zyga: just one thing the one that has appeared today has "*3rd party" on it where as the my entry does not have that? [09:48] zyga: ah good, yeah especially the use case to share a local socket was of interest for us [09:48] zyga: which snapd/snap-confine do we need to get that working? [09:48] gerry_: that's a gnome-software tag, I would recommend that you file bugs on snappy / gnome-software for each of those that feels wrong to you; some are missing features, some are OK but need to be explained (bugs can be converted to questions that can show up in a FAQ on launchpad) [09:49] morphis__: that should work, I didn't try it myself but the code looks fine [09:49] morphis__: I think .44 [09:49] morphis__: maybe earlier but I'd have to check tags [09:50] zyga: ok, so nothing which is in stable yet, right? [09:50] morphis__: actually [09:51] morphis__: it's a snapd fix and it might be out now [09:51] * zyga looks [09:51] because that side was in snapd [09:53] morphis__: can you just try, use $SNAP_DATA as described there: https://github.com/snapcore/snapd/wiki/Content-Interface [09:53] zyga: ah ok, let me try that then [09:57] morphis__: and feel free to edit that wiki [09:58] morphis__: really, it is very useful if you do [09:58] zyga: oh I see, I can do that [09:58] zyga: can everyone? [10:00] morphis__: yes [10:00] :) [10:00] it's a wiki! [10:00] good :-) [10:00] morphis__: I should link it to the interfaces page [10:00] morphis__: I'll do that shortly [10:00] ok [10:00] zyga: btw. you saw my replies on https://bugs.launchpad.net/snappy/+bug/1646415 ? [10:00] Bug #1646415: cannot run configure hook [10:02] * zyga looks [10:02] no, not yet [10:02] hmm, odd [10:02] I looked at the code and we parse hooks in meta/snap.yaml [10:02] I bet you really need that hook to be defined there [10:02] maybe something is out of sync [10:03] I'll check with gustavo [10:03] or maybe [10:03] pstolowski: ^^ do you know?] [10:03] the person who is on the hook about hooks :) [10:04] :) [10:04] looking [10:07] hum [10:07] are launchpad snap builds on yakkety know to be buggy? [10:07] "W:GPG error: http://ppa.launchpad.net/snappy-dev/tools/ubuntu yakkety InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY F1831DDAFC42E99D, E:The repository 'http://ppa.launchpad.net/snappy-dev/tools/ubuntu yakkety InRelease' is not signed." [10:08] cjwatson, ^ you might know? [10:08] seb128, at the start of the build ? thats normal iirc [10:09] (the build finishes properly, right ? ) [10:09] ogra_, no, the build errors out on that after trying to install the build-packages [10:09] https://launchpadlibrarian.net/295822697/buildlog_snap_ubuntu_yakkety_amd64_ghex-udt_BUILDING.txt.gz [10:09] ogra_, ^ [10:11] well, if you look at the top of the log you see the exact same which passes [10:11] that same branch was building fine on xenial [10:11] morphis, zyga the hook-example looks good. having meta/hooks/configure is enough. we have similar spread tests [10:11] I just tried to change to yakkety and now got that [10:12] ogra_, do you know if I'm doing something wrong there and what? [10:12] i guess because not all packages are in the PPA for yakkety [10:12] but I'm not building using a ppa [10:12] I selected to build from the archive [10:12] so I guess it's a launchpad setup issue? [10:14] yeah, i wonder what it tries to pull from there [10:24] morphis, zyga I can look at this later today [10:26] pstolowski: thank you, if you are right then snap.Info may lie sometimes :/ [10:27] zyga, i think we would see these spread tests fail. so not sure what's wrong [10:36] pstolowski: spread test may not fail even if what I said is true [10:38] zyga, hmm why not? [10:39] PR snapcraft#942 closed: store: return specific error when already owned [10:40] pstolowski: if the hook manager is not using hook info from snap info, for example [10:43] ralsina: hey, when do you think this commit https://github.com/snapcore/snapcraft/commit/6c012194bde will hit the snapcraft server (or, can it backported now ;-))? [10:44] Trevinho: I don't work on snapcraft :-) [10:44] Trevinho: so, I hope soon, if you need it! [10:45] ralsina: yeah, but.... Didn't you manage that server or what (IIRC some days ago you got pinged to restart the job)? [10:45] and I don't know how the server-side is managed (if it's just using zeisty or a snapcraft ppa) [10:58] * zyga hugs dholbach [11:05] Trevinho: not really [11:06] oh, ok... so sorry. [11:06] Trevinho: but I can ping the right people. What's the change server side? That link points to snapcraft code [11:06] ralsina: that commit should be included [11:07] Trevinho: you showed a link to a PR in snapcraft, that's client-side code, not server-side [11:07] ralsina: no, it's not... [11:07] ralsina: it's all shared code [11:08] Trevinho: the store is lp:software-center-agent, it's a whole different project [11:09] * ralsina -> school run bbl [11:10] ralsina: oh, wait... I meant a different thing then... this: https://parts.snapcraft.io/v1/parts.yaml [11:10] (the generator of that) [11:19] seb128: https://bugs.launchpad.net/launchpad/+bug/1626739 [11:19] Bug #1626739: Snapcraft build failing in Yakkety for unauthenticated stage-packages [11:21] * dholbach hugs zyga back [11:24] dholbach: visit spain sometimes, great places to see, great food, great weather, sun and no snow :) [11:25] :-) [11:27] PR snapcraft#938 closed: store: return specific error when already owned [11:29] Trevinho: ahhhhh parts, no idea about that, never touched it [11:30] ralsina: sorry for bothering you then... :-) [11:30] Trevinho: np [11:37] Trevinho that was roadmr [11:39] sergiusens: yeah, I figured just two seconds after... :-D [11:39] hahaha [11:40] I remembered the nickanme started with "r"... :-P [11:40] and since I know ralsina does serverside stuff.... :-P [11:40] * Trevinho is terrible with names... Sorry :-) [11:41] Trevinho: it happens :-) [11:41] mv roadmr r-server-side-stuff [11:41] mv ralsina r-server-side-stuff [11:41] aww, clash [11:41] lol [11:41] no, we're in a snappy world... That can't happen! [11:41] Hell, I do touch some server-side-stuff so I just assumed I had forgotten about it [11:41] maybe you want a round-robin queue? [11:42] I get pinged every time someone mentions round-robin [11:42] I didn't even know what it was to start with [11:42] :D [11:42] as you were [12:50] snapcraft's failing for me with an error about held broken packages when it tries to fetch the stage packages; is there any way to get it be more verbose and tell me which packages are causing the issue? running with -d didn't help [12:50] Elleo: while this is totally different from what you may expect try opening a second terminal and run forkstat there [12:51] the output should tell you what apt is doing and may give you a hint of what is going wrong [12:51] cjwatson, thanks, am I reading correctly that there is no workaround suggestion atm? [12:51] zyga: okay, thanks [12:54] seb128: I don't think I have anything at the moment, unfortunately, short of not using stage-packages [12:55] (which is not really a workaround!) [12:55] cjwatson, right, I was going to say that I kind of need those... [12:55] PR snapd#2398 opened: cmd/snap: change terms accept URL following UX review [12:55] well, back on using xenial for now I guess, I might try to backport things to a ppa on top to workaround [12:56] I forget quite why it only affected yakkety [12:56] or post-xenial I guess [12:56] zyga: nothing obvious there, it does a bunch of stuff with apt-key presumably checking signatures when updating, starts a few apt/method/http threads and then stops [12:57] well, it was a long shot [12:57] zyga: I don't get any errors installing other packages on the host system normally, but it looks like oxide is being held for some reason === hikiko is now known as hikiko|ln [12:58] seb128: it's definitely fixable, just a bit complicated because we need to bite the bullet and finally start sending public key material to builders; chances of me getting to it this year are low :-/ [12:59] cjwatson, don't worry, it would be nice if it worked but it's not really blocking anything that needs to land from our side, we just wanted to try to provide gtk apps based on the yakkety gtk version to xenial users, but we can backport the new gtk to xenial in a ppa for that [13:01] cjwatson, why is that PPA enabled at all ? there is nothing relevant in it [13:01] (neither for xenial nor for yakkety) [13:02] imho we could just completely drop it and be done [13:05] ogra_: until the next time we need it [13:05] hmm [13:05] it was definitely needed pre-xenial [13:05] seems the last time was in 2015 [13:06] (looking at the packages in there) [13:06] and it's very useful to have that kind of facility available [13:06] true indeed [13:06] right, it was absolutely necessary pre-xenial because the archive didn't have snapcraft [13:06] in the future y'all might well decide that you want a newer version of snapcraft used by LP regardless of what's in the distribution [13:06] this is how we do that kind of thing [13:07] yeah, understood [13:19] PR snapd#2399 opened: Add /dev/uhid to bluetooth-control interface [13:28] morphis__: hey, remember that configure bug, can you tell me whicih version of snap-exec you have in you core [13:28] which* [13:28] morphis__: is that in a core or classic system? [13:29] morphis__: gustavo just made me realise that without sufficiently up-to-date core snap and snap-exec you won't get it to work [13:33] jdstrand, could you approve camera-app package? https://myapps.developer.ubuntu.com/dev/click-apps/5990 vr 7 and 8 [13:36] PR snapcraft#926 closed: sources: add current dir to ignore list if we're iterating on parent [13:38] jdstrand: hey [13:38] jdstrand: we will deny --jailmode or --devmode when --classic is passed [13:38] jdstrand: I'll make the patch after lunch [13:38] jdstrand: classic confinement seems to work for me locally :) [13:39] jdstrand: I could use a few reviews, I think it can all land toda === DanielLlewellyn[ is now known as diddledan__ === hikiko|ln is now known as hikiko [14:01] zyga: I am using 2.18 here from the core snap from candidate [14:01] its a classic system with SNAP_REEXEC [14:01] morphis__: in a core system or on classic? [14:01] zyga: however lorn was trying it with 2.17.1 from the ubuntu image ppa on classic [14:01] morphis__: ah, snap-exec doesn't use reexec [14:02] that's one of the things we'll fix later [14:02] zyga: but for me with SNAP_REEXEC and 2.18 the configure hook is working well [14:03] zyga: just for lorn it is 2.17.1 from the ppa without SNAP_REXEC and there it isn't working [14:12] roadmr: hi! fyi, r807 supports classic. I've got another unrelated bug I'd like to fix, but feel free to pull 807 if that works for you timing-wise [14:13] jdstrand: we have a streak of holidays and release next week, could you have a look at one essential part of snap-confine that's there for classic quickly [14:13] tedg, renato__: fyi, that ^ also has the unity8 workaround you asked for [14:14] jdstrand: Great! [14:14] jdstrand: essentially this: https://github.com/snapcore/snap-confine/commit/43f5041deb8ed061f8a38f4342a5c3065b8ec3cf [14:14] zyga: are those what you asked for earlier today? [14:14] Is anyone else able to build snaps on LP? [14:14] Seems I'm getting parts update errors. [14:14] jdstrand: it's piled up there, I didn't open PRs since github makes those uber long when stacking branches [14:14] tedg, I built camera some minutes ago [14:14] jdstrand: but this is the essence, regardless of argument parsing changes (if we do the cheap way or if we do the full way) [14:15] tedg, try again. I got that in one of the builds but worked nice on the second try [14:15] zyga: can you give me a prioritized list of what must be reviewed today? [14:15] jdstrand, thanks. I am happy to not disturb you with reviews :D [14:15] jdstrand: this is the essential patch, everything else is optional [14:15] ok [14:16] jdstrand, btw. My eds/unity8-pim is ready for review :D [14:16] jdstrand: if you +1 I'll land it without the intermediate argument parsing and error improvements [14:16] renato__: ack (I have it on my list already, might be today but maybe early next week) [14:16] jdstrand, thanks, [14:16] renato__: approved [14:19] zyga: fyi, the commit message is not quite right. I think you mean "to essentially switch the sandbox off entirely" [14:20] jdstrand: yes, good catch [14:20] jdstrand: I'll correct that before it lands [14:23] jdstrand: oh awesome! sure, I'll put that in the pipeline (but not smoke it) (pretty sure I've used this joke before) [14:25] roadmr: hehe [14:26] zyga: this is totally unimportant and unrelated to this PR, but in snap-confine.c you have [14:26] #ifdef HAVE_SECCOMP [14:26] sc_load_seccomp_context(seccomp_ctx); [14:26] #endif [14:26] zyga: but for apparmor you have: [14:26] sc_maybe_aa_change_onexec(&apparmor, security_tag); [14:27] zyga: and the ifdef for HAVE_APPARMOR is in sc_maybe_aa_change_onexec() [14:27] zyga: why not just: [14:27] zyga: why not just in snap-confine.c: [14:27] #ifdef HAVE_APPARMOR [14:27] sc_aa_change_onexec(...) [14:27] #endif [14:27] ? [14:28] zyga: basically, the 'maybe' caught me eye while doing the review :) [14:28] my* [14:30] PR snapd#2400 opened: snap: support for parsing and exposing on snap.Info aliases [14:33] PR snapcraft#943 closed: Replace subTests with TestScenarios [14:37] jdstrand: because that gets rid of the extra ifdef [14:38] jdstrand: and maybe apparmor is not enabled on boot [14:38] zyga: I'm not saying get rid of the ifdef. I'm asking why it isn't in hte same place as the seccomp one [14:39] zyga: or, why not put the seccomp one in sc_maybe_load_seccomp_context(...) [14:39] ? [14:40] jdstrand: because seccomp leaks the types around, I may return to it and to the same though [14:40] jdstrand: I wasn't touching seccomp lately :) [14:40] jdstrand: I plan to unify the code when we have more review time [14:40] zyga: it isn't important. I just thought it odd that the ifdef was in one place for seccomp and in another for apparmor [14:40] * zyga -> quick break for lunch [14:40] * zyga nods [14:40] zyga: what is important is I reviewed the patch you asked me to :) [14:41] zyga: just a request for a comment. also thanks for the --devmode/--jailmode update :) [14:48] PR snapd#2401 opened: snap: abort install with ctrl+c [14:49] cjwatson: sergiusens: Seeing some build errors that looks like snapcraft can't update its parts. Happening on other snaps too, but here's an example: https://code.launchpad.net/~ted/+snap/unity8-session-xmir-preload [14:50] I can update parts locally, so I don't think that's an issue. [14:50] Not sure what else to try to debug it. [14:54] Hm, I wonder why that would have changed. [14:55] Actually, I'm not sure that has anything to do with parts. [14:55] tedg: The actual error is from apt. I think it's just that a parts update happened to be right before it. [14:56] My guess would be that the set of packages pulled by the unity8 part is in fact not coinstallable when pulled from that PPA. [14:57] It's a little hard to tell, but hopefully cleanbuild would reproduce the same thing if you gave it an appropriate set of apt sources. [14:57] Oh, I figured it was a generic error message left over from converting things over to snap building :-) [14:58] Hmm, okay. I'm not sure what could have happened there, but a lot of people pushing into that PPA. [14:58] Thanks cjwatson ! [14:58] jdstrand: thank you, checking now [14:58] jdstrand: wooooot [14:58] jdstrand: thanks :) [14:58] quick question, are the XDG_* environment variables already set based upon SNAP_USER_DATA, or do I have to make sure I do that myself? [14:59] easy answer: .... it depends [14:59] :) [14:59] I'll just set it myself, then :P [14:59] there are desktop launcher parts you can use ... [14:59] if you use them, they set these vars [15:00] if you dont, you need to set them yourself ... [15:00] you can check whats set by installing hello-world [15:00] and then running hello-world.env [15:00] it will print the default environment the hello-world binary sees [15:01] your snap would see something similar [15:01] right [15:04] bartbes: you don't have to do anything, we set $HOME and software correctly derives the rest [15:04] well, if XDG_DATA_HOME is unset, yes [15:05] zyga, well, we dont explicitly set XDG_ vars, do we ? [15:05] zyga: fyi, all the 'pc' gadget uploads you did are approved and just need you to press the publish button [15:05] only the desktop launchers do [15:05] zyga: I also fixed the issue in the review tools that made it get hung up (requested a store pull, but that probably won't happen til next week) [15:06] ogra_: the spec says it's derived from HOME if it isn't set [15:07] well, all i know is that the launchers set it based on $HOME, i wasnt aware it is set by something else now [15:07] (if it actually is) [15:07] bartbes: that's right. as such you don't need to set them. HOME is set to ~/snap/$SNAP_NAME/$REVISION and so your snap will use ~/snap/$SNAP_NAME/$REVISION/.config, ~/snap/$SNAP_NAME/$REVISION/.cache, etc [15:08] ogra_: no, applications need to default to $HOME/.local/share themselves if $XDG_DATA_HOME isn't set [15:08] jdstrand, how if the XDG_ vards arent filled at all and the app looks for them [15:08] we will start setting XDG_RUNTIME_DIR in snapd [15:08] ah [15:08] ogra_: because the toolkits follow the spec [15:08] jdstrand: you know, if they weren't set to begin with, anyway, I want it to be $SNAP_DATA_COMMON, since the information isn't version-specific [15:09] so it doesn't matter, I need to write a wrapper anyway [15:11] bartbes: well, perhaps, but we wouldn't want to diverge from the spec I don't think (that was a conscious decision). we could arguably set HOME to SNAP_USER_COMMON, but that feels a little weird. you are always free to set XDG_... to SNAP_USER_COMMON if that is appropriate for your snap [15:11] that's perfectly sensible [15:12] I'm doing something weird anyway [15:20] ogra_: we don't but software should not set it either as libraries typically do that [15:20] jdstrand: the store issue that affected the pc gadget snap? [15:21] aha [15:21] (and i thought desktop envs usually set it on startup :) ) [15:22] elopio: hey, could you take a look at why the clone is failing on this integration test on github c-i? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-snappy-dev-snapcraft-daily/zesty/amd64/s/snapcraft/20161201_214708_59c43@/log.gz [15:22] hi all. is there documentation on snap recipes in launchpad? i'm having a hard time finding it on help.launchpad.net or snapcraft.io [15:26] jdstrand: this is something I mentioned before a few times; the CE team would love if this landed for their devmode testing snaps. Can you eyeball it quickly (the function has like five syscalls inside) and give me some feedback. I didn't tweak the apparmor profile yet. https://github.com/snapcore/snap-confine/commit/b36fe6c334ca70166a7def06ba4418a764af492e [15:27] cwayne: ^^ [15:27] zyga: <3 [15:28] zyga: jdstrand: this is actually pretty critical to testing our projects [15:28] cwayne: sorry for starving it for so long [15:29] zyga: no worries, totally understand how swamped you guys are :) === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [15:32] zyga: I don't know what store issue you are referring to. I saw that the pc gadget snap was stuck in manual review. I approved it and fixed the review tools trunk so that won't happen again, but that hasn't landed in the store just yet [15:33] jdstrand: yes, that's what I was thinking about with the pc gadget snap [15:33] jdstrand: thank you for fixing that! [15:33] jdstrand: (those are auto built now as you probably know :) [15:38] jdstrand: the store issue was that the gadget snap required to have i386 elf binaries for i386 and I believe this is what you fixed [15:38] PR snapd#2402 opened: debian: disable autopkgtests on ppc64el [15:40] the question i am trying to find documentation on is whether we can target zesty as the primary archive for automatic launchpad builds. i am building ubuntu-image, but i remember reading somewhere (that i can't find now) that only xenial is supported, but that won't work for us because we need e2fsprogs from >=yakkety [15:41] sergiusens, would be nice if the "apps" section of the snapcraft file we could set environment variables to each app. Something like environment:"OXIDE_NO_SANDBOX=1;MY_APP_VAR=True" [15:41] this will avoid create a wrapper file just to export vars [15:42] renato__: I believe you already can [15:42] renato__: we spent lots of time connecting the docs to make that owrk [15:42] renato__: may be disabled but we technically can now [15:42] I don't remember, sorry [15:44] zyga, \o/ this is great, just need to figure out which syntax I should try [15:47] renato__: disclaimer, it may not be enabled at some layer yet but we definitely planned this for a long time so ask sergiusens [15:48] zyga, thanks [15:48] jdstrand: hmmm, snap confine oopses the kernel [15:48] jdstrand: I guess we're pushing the boundaries [15:48] jdstrand: https://pastebin.canonical.com/172640/ [15:49] jjohansen: ^ [15:51] zyga: that's a bad strlen call so just a plain ol' bug (not pushing any limits) [15:51] zyga: can you file a bug with reproducer instructions? [15:52] tyhicks: against the kernel package? [15:52]