[02:27] <sergiusens> thomi I just did a run through the commit logs, nothing stands out that would prevent this, plugin loading code has stayed unchanged
[04:49] <TheMuso> If I want to file a bug against snapd, what project do I file the bug under in lp? Is it snappy?
[04:58] <TheMuso> nvm think I have my answer.
[06:32] <dholbach> good morning
[06:35] <netphreak> morning :)
[06:58] <mup> PR snapd#1491 opened: use more consistent "snap %q (rev %s)" task descriptions <Created by mvo5> <https://github.com/snapcore/snapd/pull/1491>
[07:02] <dholbach> kyrofa, sergiusens: does https://github.com/ubuntu/snappy-playpen/issues/145 look like a snapcraft bug to you?
[07:39] <mup> PR snapd#1437 closed: snapstate: use snapstate.Type in backend.RemoveSnapFiles <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1437>
[07:44] <mup> PR snapd#1480 closed: many: rename SideInfo.OfficialName to SideInfo.RealName <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1480>
[07:49] <mup> PR snapd#1492 opened: overlord/auth: add Device/SetDevice to persist device identity in state <Created by wgrant> <https://github.com/snapcore/snapd/pull/1492>
[07:51] <mup> PR snapd#1493 opened: store/auth: add SnapUbuntuStoreAuthService with device identity methods <Created by wgrant> <https://github.com/snapcore/snapd/pull/1493>
[08:00] <mup> PR snapd#1494 opened: tests: add content sharing interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1494>
[08:19] <mup> PR snapd#1495 opened: snapstate: rename OfficialName to RealName in the new tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/1495>
[08:20] <didrocks> josepht: hey! it seems that the cronjob imported my new part definition. However, it didn't refresh with the new description, any idea what's happening?
[08:36] <mup> PR snapd#1496 opened: tests: add spread test for tried snaps removal <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1496>
[08:41] <mup> PR snapd#1495 closed: snapstate: rename OfficialName to RealName in the new tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1495>
[08:45] <pachulo>  /buffer 7
[09:37] <mup> PR snapd#1497 opened: tests, integration-tests: port auth errors test to spread <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1497>
[09:54] <lool> ogra_: hey, how goes?
[09:54] <lool> ogra_: would you know if our future rpi3 image will be armhf or arm64 based?
[09:54] <lool> ogra_: if armhf, how hard would it be to do an arm64 one for a third-party?
[09:54] <ogra_> lool, we'll have both i think
[09:55] <lool> ogra_: both officially supported?
[09:55] <ogra_> (at least i plan to have snaps for both in the store, not sure which we'll make official
[09:55] <ogra_> )
[09:55] <ogra_> i'll bring that up at the sprint
[09:56] <ogra_> we'll be most likely missing firmware blobs for BT and wifi for arm64
[09:56] <ogra_> i havent played with that yet
[09:57] <jamiebennett> ogra_: How much work will it be to have both?
[09:58] <ogra_> not much i guess, once i have a snapcraft.yaml for the unofficial side it is just a snapcraft run away to build a kernel snap ... and gadgets change really rarely
[09:58] <jamiebennett> ogra_: and on the testing and support side?
[09:58] <ogra_> you mean when both are official ? well, twice as much :)
[09:59] <ogra_> (manual smoke testing etc)
[09:59]  * jamiebennett nods
[09:59] <ogra_> i think it is fine to have the arm64 build unsupported
[09:59] <jamiebennett> ack
[09:59] <ogra_> for official arm64 we have the dragonboard
[10:08] <oSoMoN> is there anything special to do to enable a snapped app to run translated (translations are correctly shipped with the package under /usr/share/locale/)?
[10:10] <oSoMoN> is bug #1576282 relevant here?
[10:10] <mup> Bug #1576282: Snaps built from deb can't be gettext translated <snap-desktop-issue> <Snapcraft:New> <snapcraft (Ubuntu):Confirmed> <https://launchpad.net/bugs/1576282>
[10:11] <ogra_> oSoMoN, yeah, you need to hack something up ... if your app uses gettext you should preload something that allows the bindtextdomain function to use a custom path
[10:11] <oSoMoN> hugh, that’s ugly!
[10:11] <oSoMoN> ogra_, looking at your suggestion in the bug report
[10:12] <ogra_> for plain libc translations LOCPATH should help
[10:12] <ogra_> afaik niemeyer plans to have some generic preloader thing builtin in snapd at some point ... that will make it easier
[10:12] <oSoMoN> ogra_, I’m working on webbrowser-app, which uses the i18n.tr() mechanism from the UITK, which I believe uses bindtextdomain under the hood
[10:13] <ogra_> yeah, most likely
[10:17] <joc_> morphis: i notice the tpm part on the wiki page has a source-type field which i think shouldnt be there
[10:18] <morphis> joc_: it should be origin-type
[10:18] <morphis> didrocks added that
[10:18] <morphis> joc_: fixed that
[10:18] <joc_> morphis: yep just added a part myself, maybe should remove it so it doesnt get copied by others
[10:19] <joc_> good :)
[10:19] <morphis> I talked with didrocks yesterday and thought he added origin-type and not source-type
[10:19] <morphis> didrocks: was there any reason to use source-type instead?
[10:20] <didrocks> morphis: hum, sorry, I'm lost context?
[10:20] <didrocks> I didn't touch the tpm part
[10:20] <didrocks> or not intentionally :p
[10:20] <morphis> didrocks: or was it dholbach? :-)
[10:20] <morphis> don't remember
[10:20] <ogra_> the "d" guys :)
[10:21] <didrocks> this is the only changed I did: https://wiki.ubuntu.com/snapcraft/parts?action=diff&rev2=16&rev1=15
[10:21] <didrocks> seems it's dholbach, indeed: https://wiki.ubuntu.com/snapcraft/parts?action=diff&rev2=15&rev1=11
[10:21] <oSoMoN> ogra_, actually, it seems the UITK exposes a i18n.bindtextdomain(domainName, dirName) method to QML
[10:21] <ogra_> oSoMoN, oh ! thats neat ...
[10:22] <oSoMoN> I’ll test it
[10:22] <ogra_> if it works, you should perhaps mention it in the bug
[10:22] <oSoMoN> will definitely doo
[10:22] <oSoMoN> -o
[10:23] <morphis> didrocks: yeah
[10:47] <oSoMoN> didrocks, hey, I’m looking at https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/qt/launcher-specific#L29 , is this known to work correctly?
[10:49] <oSoMoN> didrocks, I made a snap of webbrowser-app, the packages includes the mo files under $SNAP/share/locale/, but the app is not getting translated
[10:50] <oSoMoN> looking at UbuntuI18n::setDomain(…), this should work, as it calls bindtextdomain with $APP_DIR/share/locale/
[10:54] <didrocks> oSoMoN: are you sure bindtextdomain works? I remember that seb128 looked at this closer than I did
[10:54] <didrocks> IIRC, there was an issue if you don't set it to prefix
[10:57] <seb128> didrocks, well, if the uitk look into $APP_DIR whatever that is...
[10:57] <oSoMoN> didrocks, what do you mean by set it to prefix?
[10:57] <seb128> doesn't work for non-UbuntuUITK code
[10:58] <seb128> since most upstream dp $datadir/locales
[10:58] <seb128> which is set from the prefix at buildtime
[10:58] <oSoMoN> seb128, but for QML apps using the UITK, that should work, right? see my comment at https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1576282/comments/3
[10:58] <mup> Bug #1576282: Snaps built from deb can't be gettext translated <snap-desktop-issue> <Snapcraft:New> <snapcraft (Ubuntu):Confirmed> <https://launchpad.net/bugs/1576282>
[10:59] <ogra_> oSoMoN, i guess it depends ... if they use the same bindtextdomain in the backend you will have the exact same problem
[11:01] <ogra_> sadly the issue is in the lowest level of the stack
[11:08] <oSoMoN> ogra_, I’m not sure I understand, I thought the issue was that apps normally had calls to bindtextdomain with a hardcoded path set at build time
[11:09]  * oSoMoN is not very familiar with the inners of libintl
[11:15] <seb128> oSoMoN, yeah, which is what I wrote no?
[11:16] <seb128> oSoMoN, non-UbuntuUITK C code use $datadir/locales which is set according to prefix at buildtime
[11:16] <oSoMoN> seb128, yes, that’s why I’m confused by ogra_’s comments, are there two separate issues maybe?
[11:16] <seb128> oSoMoN, dunno about uitk, I guess it they handle it it's handled
[11:16] <seb128> no idea
[11:20] <ogra_> if UITK just uses the bindtextdomain fromm gettext any setting of a path will be ignored ... thats what i mean
[11:20] <ogra_> wrapping the UITK around the funbction wont change its behaviour
[11:21] <seb128> expect if the uitk read the env and do something like bindtextdomain(getenv($somevar))+"usr/share/locale")
[11:21] <ogra_> try stracing it :)
[11:22] <ogra_> seb128, with its own bindtextdomain ?
[11:22] <ogra_> that would indeed work
[11:22] <ogra_> if it just hooks into gettext there wont be a getenv ...
[11:27] <kyrofa> dholbach, man... I have no idea what's going on with that qmake thing
[11:31] <kyrofa> dholbach, I wonder if it means qmake's support for out-of-source builds is not that great
[11:33] <seb128> oSoMoN, you might want to open a new bug rather than commenting on this one btw
[11:33] <seb128> oSoMoN, that bug is specifically about code hardcoding a path to bindtextdomain() at buildttime
[11:33] <seb128> oSoMoN, your issue is different and with the uitk, that should work
[11:34] <oSoMoN> seb128, agreed, will do
[11:35] <seb128> oSoMoN, thanks
[11:39] <oSoMoN> seb128, could the first statement of your bug report («the core image doesn't have locales definition») be the actual issue I’m facing?
[11:39] <seb128> oSoMoN, I guess it's possible yes
[11:40] <oSoMoN> seb128, how would I go about shipping the locale definitions in my snap?
[11:44] <seb128> not sure there is a standard way, fwded you an email discussing the freecad example which had some hacks for that
[11:50] <mup> PR snapd#1497 closed: tests, integration-tests: port auth errors test to spread <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1497>
[11:54] <mup> PR snapd#1496 closed: tests: add spread test for tried snaps removal <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1496>
[11:56] <ogra_> oSoMoN, see  http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/nethack.sh and http://bazaar.launchpad.net/~ogra/+junk/nethack/view/head:/snapcraft.yaml for plain locale stuff
[11:57] <ogra_> (or install freecad and take a look at thw wraper in /snap/freecad/current/ )
[12:02] <mup> PR snapd#1484 closed: tests, integration-tests: port unity test to spread <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1484>
[12:40] <mhall119> sergiusens: are your pkg-config changes in snapcraft 2.12?
[12:46] <mup> PR snapcraft#631 closed: Fix the store integration tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/631>
[12:53] <mup> PR snapd#1498 opened: tests, integration-tests: port systemd service check test to spread <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1498>
[12:53] <sergiusens> mhall119 no, 2.12 was released before I fixed it
[12:59] <josepht> didrocks: which part?
[13:01] <kyrofa> sergiusens, elopio is jenkins having problems today? I can't reach results, and now they don't seem to be triggering
[13:10] <sergiusens> kyrofa we might need to telegram elopio
[13:10] <kyrofa> sergiusens, you're seeing that too then, eh?
[13:12] <mhall119> sergiusens: how can I try your patch in a cleanbuild then?
[13:12] <sergiusens> kyrofa not really
[13:13] <kyrofa> sergiusens, ah, I triggered them manually... we'll see what happens
[13:13] <kyrofa> Whoa, and failed
[13:14] <kyrofa> Immediately
[13:14] <sergiusens> kyrofa I've been working on all this red https://github.com/snapcore/snapcraft/compare/master...sergiusens:refactor/push
[13:14] <kyrofa> sergiusens, looooovely!
[13:14] <kyrofa> I love that kind of red
[13:15] <sergiusens> kyrofa and it is now sort of readable too ;-) less spaghettiesh
[13:15] <kyrofa> Yeah, very nice
[13:15] <josepht> sergiusens: nice!
[13:27] <didrocks> josepht: desktop/*
[13:30] <josepht> didrocks: they look the same to me on the wiki[1] and in the parsed output[2]   [1] https://wiki.ubuntu.com/snapcraft/parts [2] https://parts.snapcraft.io/v1/parts.yaml
[13:30] <josepht> didrocks: did you do a 'snapcraft update' to the get the latest parsed output locally?
[13:31] <didrocks> josepht: oh, I thought that was fetched from the description in the git repo
[13:31] <didrocks> ok, it's copied there as well
[13:32] <didrocks> josepht: any chance to have a different one per "parts" from the same namespace?
[13:32] <didrocks> (like desktop/qt5 have a different description from desktop/gtk3)
[13:34] <josepht> didrocks: it might be possible if we allow a 'description' field for a part in snapcraft.yaml.  Can you file a bug please and we'll see if we can add that?
[13:35] <josepht> didrocks: for the time being you could have the general description include a list of specific descriptions (it would be a lot of description for each part)
[13:35] <didrocks> josepht: yeah, that's what I did with the new one :)
[13:36] <didrocks> I'll file a bug
[13:36] <josepht> didrocks: thank you
[13:36] <didrocks> yw, thanks to you :)
[13:37] <josepht> yw as well :)
[13:46] <sergiusens> kyrofa maybe fgimenez can help out
[13:46] <sergiusens> kyrofa I see on that "other" channel that elopio redeployed da jenks
[13:47] <kyrofa> fgimenez, snapcraft's jenkins is super broken (not sure about snapd's)
[13:48] <kyrofa> fgimenez, e.g. http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/1094/
[13:48] <fgimenez> kyrofa, sergiusens yep, the redeploy has just finished, all should be working now
[13:48] <fgimenez> kyrofa, let me check...
[13:48] <kyrofa> fgimenez, ah, okay I just retriggered them, see if things are working
[13:48] <kyrofa> Nope, immediate failures
[13:49] <kyrofa> fgimenez, the one just ran: http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/1095/
[13:52] <fgimenez> kyrofa, it seems to complain about the available images, let me see what is it looking for...
[13:52] <kyrofa> fgimenez, alright, thanks for checking it out :)
[13:52] <fgimenez> kyrofa, np :) i'll let you know how it goes
[13:55] <sergiusens> kyrofa my refactor only has 6 unit test errors!
[13:55] <sergiusens> kyrofa and only because it wants to mock stuff that I made dissappear :-)
[13:56] <kyrofa> sergiusens, nice!
[14:01] <fgimenez> kyrofa, this one seems to be fine http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/1098/console, there was a problem with a variable expansion
[14:04] <kyrofa> fgimenez, yeah that one looks like it's running okay. Still seeing image errors here: http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/1191/console
[14:05] <kyrofa> fgimenez, yeah, autopkgtests seem to be running now
[14:05] <kyrofa> fgimenez, just example tests now
[14:05] <fgimenez> kyrofa, ok on it
[14:08] <fgimenez> kyrofa, examples was pointing to the wrong region, should be fixed now http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/1192/console
[14:10] <ogra_> hmm
[14:10] <ogra_> do we have any snapcraft.yaml example for SW that uses sourceforge ?
[14:10] <ogra_> especially for downloading the source
[14:15] <fgimenez> kyrofa, this PR will make the fixes permanent https://github.com/ubuntu-core/snappy-jenkins/pull/186, when landed these errors won't raise again in the next redeploys
[14:15] <mup> PR ubuntu-core/snappy-jenkins#186: fixed regions and variable expansion <Created by fgimenez> <https://github.com/ubuntu-core/snappy-jenkins/pull/186>
[14:16] <fgimenez> let me know if anything else is missing
[14:16] <kyrofa> fgimenez, thank you! Looks great :)
[14:17] <fgimenez> kyrofa, yw :)
[15:03] <sergiusens> kyrofa before I move on, I would really like an initial review on https://github.com/snapcore/snapcraft/pull/632
[15:03] <mup> PR snapcraft#632: WIP Refactor/push <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/632>
[15:04] <mup> PR snapcraft#632 opened: WIP Refactor/push <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/632>
[15:07] <kyrofa> sergiusens, alrighty
[15:14] <kyrofa> sergiusens, yeah the direction looks good. Missing some good error handling, but I assume that stuff is coming
[15:14] <sergiusens> kyrofa except KeyError?
[15:15] <sergiusens> kyrofa yeah, that is missing ;-)
[15:15] <kyrofa> Yeah, that :P
[15:15] <sergiusens> kyrofa going to go the exception route and create a StoreReviewError or something like that
[15:15] <sergiusens> getting rid of so many if/else on keywords really made me happy
[15:16] <kyrofa> Yeah I bet
[15:17] <sergiusens> kyrofa so happy I lost track of time last night and went to bed really late :-P
[15:17] <sergiusens> S4ruman
[15:18] <niemeyer> ogra_: Regarding "afaik niemeyer plans to have some generic preloader thing builtin in snapd at some point ... that will make it easier"
[15:18] <niemeyer> ogra_: I actually have it pretty much ready
[15:19] <niemeyer> ogra_: It's not inside snapd though, but a library on its own
[15:19] <niemeyer> ogra_: Worked on that over the weekend while fighting an app
[15:25] <mup> PR snapd#1482 closed: store, many: start using the new details endpoint <Reviewed> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1482>
[15:26] <mup> PR snapd#1488 closed: store: switch search to new snap-specific endpoint <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1488>
[15:26] <ogra_> niemeyer, cool
[15:26] <ogra_> thanks for cllearifyin
[15:26] <ogra_> g
[15:54] <mup> PR snapd#1499 opened: tests: use systemd-run for starting and stopping the unity app <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1499>
[15:56]  * kyrofa bashes head on desk and goes to make more coffee
[16:02] <ogra_> nessita, help ... i'm trying to upload a new nethack snap ... the old one was for 15.04 and it seems the store thinks the old one is a click ... when i upload a new revision i'm told click and snap can't be mixed ... trying to register a new package tells me the name is taken
[16:02] <ogra_> and unpublishing doesnt clean that up
[16:02] <nessita> ogra_, let me check!
[16:02] <nessita> ogra_, I see 3 nethacks: nethack-amd64 nethack-armhf and nethack -- is the last one?
[16:02] <ogra_> (and renaming obviously only renames the representation in the store, not the packagename)
[16:03] <ogra_> yeah
[16:03] <nessita> looks like is busted somehow, let me check
[16:03] <ogra_> i dont mind if you remove it completely
[16:04] <ogra_> in case thats needed
[16:04] <nessita> ogra_, I may do that, but let me fully check
[16:04] <nessita> ogra_, let me delete the package and you can register the name right after
[16:05] <ogra_> nessita, btw, ircproxy, upnp-server and packageproxy will have the same issue (and i plan fesh uploads for them)
[16:05] <kyrofa> elopio, this is successful, right? http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/1099/console
[16:05] <kyrofa> elopio, looks like it just didn't clean up right?
[16:05] <ogra_> so it might make sense to remove them too
[16:05] <nessita> ogra_, nethack deleted, feel free to re-register
[16:05] <ogra_> great
[16:06] <kyrofa> sergiusens, short of the (incorrectly failing) tests, does #622 look good?
[16:06] <nessita> ogra_, let me check details for ircproxy, upnp-server and packageproxy
[16:06] <ogra_> they can all go as well
[16:06] <ogra_> nope ... "new snap" still tells me the namespace is taken
[16:08] <ogra_> ah, because i wown it already :P
[16:08] <ogra_> direct upload works
[16:10] <sergiusens> kyrofa what test is failing? care to record that in a comment with the traceback?
[16:18] <kyrofa> sergiusens, I'm actually not sure what's happening on autopkg
[16:18] <kyrofa> sergiusens, http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/1099/console
[16:18] <kyrofa> It looks like a testbed issue, but I'm not certain
[16:22] <sergiusens> kyrofa good thing I told elopio to keep an eye on jenkins :-P
[16:28] <tsimonq2> key kyrofa, Jenkins passes in snapcraft#619 - what's next? I think I need a unit test, how would I go about doing that? (I mean, in the Zip and Tar sources or in a separate class?)
[16:28] <mup> PR snapcraft#619: Add source-checksum option for tar and zip sources (bug 1585913) <Created by tsimonq2> <Conflict> <https://github.com/snapcore/snapcraft/pull/619>
[16:29] <tsimonq2> oh great, my FAVORITE spam bot just commented on my PR twice again.... :P
[16:29] <tsimonq2> (jk)
[16:50] <mup> PR snapd#1498 closed: tests, integration-tests: port systemd service check test to spread <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1498>
[16:52] <mup> PR snapd#1499 closed: tests: use systemd-run for starting and stopping the unity app <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1499>
[16:52] <mup> PR snapcraft#633 opened: qmake plugin: Stop doing out-of-source builds <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/633>
[17:37] <jdstrand> zyga_: hey, so, snap-confine has a 1.0.34 tag but the debian/changelog still says UNRELEASED for 1.0.34
[17:40] <kyrofa> sergiusens, any idea what's happening here? https://travis-ci.org/snapcore/snapcraft/jobs/142820726
[17:40] <kyrofa> Not the most descriptive failure I've seen
[17:40] <ssweeny> jdstrand, I'm trying to snap a python app (checkbox/plainbox if that's important) and I keep getting errors where python is trying to run /sbin/ldconfig. I think it's some internal python thing that's doing it. Any advice on how to proceed?
[17:41] <sergiusens> kyrofa I asked josepht to look at it, the wiki is probably broken and our tests rely on it
[17:41] <kyrofa> sergiusens, ah
[17:41] <sergiusens> kyrofa I think work is already in progress to move to fake servers
[17:41] <kyrofa> Good deal
[17:41] <josepht> sergiusens, kyrofa: yes, the desktop entry is broken
[17:42] <kyrofa> I love it-- an errant wiki entry takes down our CI
[17:46] <sergiusens> josepht do you know how to fix it?
[17:46] <josepht> sergiusens: yeah, I think so
[17:48] <jdstrand> ssweeny: for now install in devmode. you can also file a bug stracing the process and seeing what it is doing. You can add '/sbin/ldconfig ixr,' to /var/lib/snapd/apparmor/profiles/snap.your.snap then run 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.your.snap' and see if that work for you (please mention that in the bug)
[17:48] <jdstrand> ssweeny: when filing a bug, please add the 'snapd-interface' tag
[17:49] <ssweeny> jdstrand, will try, thanks! (it works perfectly in dev mode and I'm working through confinement issues)
[17:51] <ssweeny> jdstrand, also it's trying to write to $HOME/snap/${SNAP}/${REV}/.cache and it's being denied. Are hidden files in the user writable area blocked by default?
[17:52] <ssweeny> i think that's what's being resolved for $XDG_CACHE_DIR
[17:53] <ssweeny> or $XDG_CACHE_HOME rather
[17:54] <josepht> sergiusens: the parser seems to be getting a stale/cached version of the wiki
[18:02] <kyrofa> jdstrand, you remember that overlayfs script you had a while back? Just for ease of use I decided to throw it in a snap, but it seems the private mount space won't let me actually use it, even in devmode
[18:02] <kyrofa> jdstrand, is there any way around that?
[18:05] <jdstrand> ssweeny: hmm,  $HOME/snap/${SNAP}/${REV}/.cache should be allowed. can you paste the denial?
[18:06] <kyrofa> jdstrand, oh nevermind... it's denying access to mount, haha
[18:06] <kyrofa> Wait no... that's allowed
[18:07] <kyrofa> I stand by the mount space theory
[18:07] <ssweeny> jdstrand, it turns out I installed the snap as root and it created the rev directory with root ownership
[18:07] <ssweeny> even under /home/ubuntu/snap/...
[18:08] <jdstrand> kyrofa: I can't so for sure why it would not work, but the plethora of bind mounts that we have, it wouldn't surprise me. it might need a different invocation from within a snap (haven't tried)
[18:08] <jdstrand> ssweeny: yes that is an annoying bug
[18:08] <jdstrand> installing as root shouldn't be the issue. running as root before running as yourself would
[18:09] <jdstrand> or running another program (eg, snappy-debug) as root on a system that doesn't have ~/snap already will do it
[18:09] <jdstrand> (since ~/snap is root owned then)
[18:12] <ssweeny> interesting
[18:12] <ssweeny> I think I did run as root first
[18:16] <niemeyer> jdstrand: Would you mind to have a quick look on snapd#1405 when you have a moment?  Should be an easy walk
[18:16] <mup> PR snapd#1405: interfaces: add zigbee-dongle interface <Blocked> <Reviewed> <Created by jocave> <https://github.com/snapcore/snapd/pull/1405>
[18:16] <slo_> Hi, is there any HW matrix support available for Snappy? So which CPUs are supported or which HW platforms (rpi, artik, etc...) ?
[18:20] <kyrofa> jdstrand, indeed, if you install hello-world in --devmode and bindmount $HOME/foo to $HOME/bar in hello-world.sh, only hello-world.sh can see is. If you open another session it's not mounted at all
[18:21] <kyrofa> s/see is/see it/
[18:21] <jdstrand> niemeyer: I'll add it to my list (though note I'm working on a semi-urgent issue and may not get to it today, but should be able to tomorrow if not today)
[18:23] <jdstrand> zyga_, tyhicks: fyi, https://github.com/snapcore/snap-confine/pull/72. I think this should be part of the /ubuntu-core-launcher/snap-confine SRU that is being worked on
[18:23] <mup> PR snap-confine#72: use execle() with empty environment when calling snappy-app-dev <Created by jdstrand> <https://github.com/snapcore/snap-confine/pull/72>
[18:23] <kyrofa> jdstrand, I figure it's the slave mount namespace
[18:24] <kyrofa> jdstrand, is there any nifty mount instantiations that will allow me to hop out of that in devmode?
[18:24] <jdstrand> kyrofa: that wouldn't surprise me. that said, you can deliver it as snap and execute it from /snap/name/current/script (yucky, but... ;)
[18:25] <kyrofa> jdstrand, haha, that's exactly what I'm doing but... yuck :P
[18:25] <jdstrand> kyrofa: otoh, idk. atm I'm working on said semi-urgent issue and don't have time to look right now
[18:25] <kyrofa> jdstrand, that's alright, no problem
[18:25] <niemeyer> jdstrand: Thanks!
[18:26] <jdstrand> niemeyer: sure thing
[18:26] <zyga> jdstrand: ack, looking now
[18:27] <zyga> jdstrand: ack, I'll merge this soon but please add a spread test
[18:27] <jdstrand> yikes
[18:27] <zyga> jdstrand: ?
[18:28] <jdstrand> I'll have to think about that. this is a pretty convulated attack
[18:28] <jdstrand> convoluted
[18:28] <zyga> jdstrand: after this lands I'll release .35
[18:28] <niemeyer> joc_: That PR is yours isn't it?
[18:28] <zyga> jdstrand: is there something we could do to just show that PATH is reset?
[18:28] <zyga> jdstrand: what is NULL environment in practice? empty
[18:28] <jdstrand> zyga: yes, empty
[18:28] <zyga> jdstrand: or inherited from some safe default
[18:28] <zyga> hmmm
[18:29] <zyga> so PATH won't resolve at all, is that what we want?
[18:29] <niemeyer> joc_: snapd#1405 that is
[18:29] <mup> PR snapd#1405: interfaces: add zigbee-dongle interface <Blocked> <Reviewed> <Created by jocave> <https://github.com/snapcore/snapd/pull/1405>
[18:29] <jdstrand> zyga: the problem is that only snappy-app-dev will see that environment
[18:29] <zyga> jdstrand: that's right, so as long as it can cope, it is okay
[18:29] <zyga> right?
[18:29] <jdstrand> zyga: will spread allow me to replace /lib/udev/snappy-app-dev? I guess not since it is in read only part?
[18:29] <zyga> it will
[18:30] <zyga> you build the package, install it and run anything as root
[18:30] <zyga> (as long as you clean up in restore you are good)
[18:30] <jdstrand> ok, then I can come up with a test
[18:31] <jdstrand> zyga: we want an empty environment, coping in a shell script is difficult. the next thing I'm going to do is to rewrite the shell script, but that doesn't need to be part of 1.0.35
[18:31] <jdstrand> zyga: let me add a comment like tyhicks suggested and then work on spread. it will take me a bit-- this is my first spread test and I haven't set up the spread env yet
[18:32] <jdstrand> I may have some questions
[18:32] <zyga> ok
[18:32] <zyga> jdstrand: I'll be here
[18:32] <zyga> jdstrand: hint: spread -list
[18:33] <zyga> jdstrand: then spread $idofthetest
[18:33] <zyga> jdstrand: that will get you started faster
[18:39] <jdstrand> zyga: oh, by cope maybe you meant if snappy-app-dev can handled not having PATH set, for example. yes-- anything the shell needs, if it isn't there, the shell will provide (PATH, HOME, PWD, etc), but passing a NULL environment means the user can't control those things
[18:44] <kyrofa> nessita, why do automated review warnings result in a manual review being required?
[18:45] <kyrofa> nessita, like this one: "Could not find compiled binaries for architecture 'arm64' lint-snap-v2_architecture_specified_needed (arm64)" at worst it's simply a mistake, at best (like my case) on purpose
[18:47] <jdstrand> that is an ongoing conversation
[18:48] <jdstrand> bottom line is, each check needs to be re-reviewed for what should block and what shouldn't
[18:49] <jdstrand> and we need to think about how to present to the user and the uploader
[18:49] <jdstrand> we probably need to do that, have errors block and warnings display but not block
[18:50] <jdstrand> feel free to file a bug against the review tools
[18:50] <jdstrand> kyrofa (cc nessita): ^
[18:51] <kyrofa> jdstrand, alright, thank you
[18:55] <kyrofa> jdstrand, any chance you could approve that snap?
[18:59] <jdstrand> kyrofa: done
[18:59]  * jdstrand leaves sergiusens' nil-snap alone
[19:00] <sergiusens> jdstrand please do :-)
[19:01] <kyrofa> jdstrand, thank you!
[19:05] <nessita> jdstrand, thanks for answering
[19:06] <nessita> kyrofa, we want good packages in the store, so why would your package not have a binary? (besides what jamie said)
[19:10] <kyrofa> nessita, because snappy doesn't support it being a binary
[19:10] <kyrofa> nessita, so one must run the script straight out of the snap
[19:10] <kyrofa> nessita, but the snap is still a useful deployment mechanism
[19:11] <kyrofa>  /sharing mechanism
[19:13] <kyrofa> jdstrand, ah, an armhf arrived late if you could push the button on that one as well
[19:14] <jdstrand> done
[19:14] <kyrofa> Thank you!
[19:22] <kgunn> ogra_: yo, for stitching a core 16 edge image....should i still be using the u-d-f on mvo's file share?
[19:23] <kgunn> he has one there listed "experimental"
[19:23] <kgunn> i think i'm on cirica may 2nd
[19:52] <zyga> re
[20:01] <zyga> jdstrand: about the exec bug, I'll do something with suse but then release .35 with tests or without tests before I EOD
[20:02] <jdstrand> zyga: I've almost got a test verifying cgroups work correctly. then the next test for regressing execle should be fast
[20:03] <zyga> jdstrand: fantastic!
[20:03] <zyga> jdstrand: I'll work on running spread tests on sid this week
[20:03] <jdstrand> zyga (cc niemeyer): gotta say, spread was really easy to get started with
[20:03] <zyga> jdstrand: and suse/fedora/arch - depending on what is the easiest one
[20:06] <zyga> jdstrand: not sure if you already know about it, -reuse and -keep accelerate iteratio cycle
[20:06] <zyga> you just re-run on the same host all the time, no allocation required
[20:06] <jdstrand> oh yes
[20:06] <jdstrand> using -reuse a lot
[20:09] <jdstrand> zyga: ok, added preliminary cgroup test
[20:09] <jdstrand> zyga: so, debian/changelog still has 1.0.34 UNRELEASED
[20:10] <jdstrand> zyga: can you fix that up? I can then add an entry for this
[20:11] <sawdog> Hi folks, I was redirected here via the Ubuntu channel; I’m asking:  so I’m running on a Gigabyte IOT gateway box, have Core installed on a USB stick and am trying to get it installed on the internal MMC. I installed curl via snappy so I can grab the image and download it so that I can dd the image to the internal MMC; but using curl to redirect the output to a file, I get a permission denied. I’m assuming this is because curl
[20:11] <sawdog> doesn’t have the appropriate access granted to write to my disk?
[20:11] <zyga> jdstrand: hmm, that's complicated, this is release to debian with separate packaging now
[20:11] <zyga> jdstrand: (non-native)
[20:11] <sawdog> I did do a snappy hw-assign curl.tetor /dev/sda5
[20:12] <zyga> jdstrand: the packaging here is just used for spread testing
[20:12] <sawdog> which granted access to the device, but same behavior; —> 0Warning: Failed to create the file ubuntu-core-15.04-intel-nuc.img.xz: Warning: Permission denied curl: (23) Failed writing body (0 != 9922)
[20:12] <zyga> jdstrand: add the changelog entry anywhere you want, it is not essential
[20:12] <zyga> (for packaging)
[20:12] <jdstrand> zyga: ok, then I'll let you handle the debian/changelog entry?
[20:12] <zyga> jdstrand: yep
[20:13] <jdstrand> zyga: I tell you waht, I'll add it here so you know what to add later
[20:13] <zyga> ok
[20:13] <zyga> jdstrand: I will do the rest and coordinate releases
[20:14] <sawdog> I’m assuming that the curl app doesn’t have proper access…
[20:15] <zyga> sawdog: I'm not sure what you are doing is what you really want
[20:16] <zyga> sawdog: snappy has a few bits that need to understand boot and this will likely break
[20:16] <zyga> sawdog: I'd recommend asking on the mailing list, it will probably require a longer and more comprehensive answer
[20:17] <sawdog> zyga: Ah, it seemed like from the docs I could download an .img.xz - xzcat that pipped to dd and write it to the internal MMC
[20:18] <sawdog> e.g this is from the docs online:
[20:18] <sawdog> Decompress the image and write to the disk downloaded:
[20:18] <sawdog> Using the NUC eMMC board:
[20:18] <sawdog> xzcat ubuntu-core-15.04-intel-nuc.img.xz | sudo dd of=/dev/mmcblk0 bs=32M; sync
[20:18] <zyga> sawdog: it depends on finer details
[20:18] <sawdog> but I need to download the compressed image - which is where I’m at; writing it to my usb drive (e.g. /dev/sda5)
[20:19] <zyga> sawdog: anyway, I need to work on something, I', sorry but I cannot help you now
[20:19] <sawdog> looks like I’m facing an AppArmor violation with curl
[20:19] <thomi> Hi all, while building a snap with more than one python-based part, I'm getting this error when trying to build the snap: https://pastebin.canonical.com/160364/ Does anyone know how to fix this?
[20:21] <zyga> thomi: using a public pastebin would be easier for others to read
[20:21] <thomi> zyga: good point
[20:22] <thomi> zyga: http://pastebin.ubuntu.com/18656156/
[20:23] <zyga> jdstrand: ready?
[20:23] <zyga> thomi: just add all the python bits to one shared part
[20:23] <zyga> thomi: that's what I did before
[20:23] <zyga> thomi: I mean all the stage-packages
[20:23] <jdstrand> zyga: I pushed a couple more commits. almost have a regression test
[20:24] <thomi> zyga: unfortunately that's not do-able here. One of the parts isn't using the python build plugin, as it's a custom build system
[20:24] <thomi> zyga: also, I'll want to share one of the parts for others to re-use
[20:28] <zyga> jdstrand: k, I'll wait
[20:28]  * zyga packages $Nth go package for suse
[20:28] <zyga> thomi: that's okay, my point is that you can move *all* stage-packages to a dedicated part
[20:28] <zyga> thomi: then use after to build when those are ready
[20:29] <zyga> thomi: as for sharing, not sure, just a snapcraft design or bug
[20:30] <thomi> zyga: I don't understand, sorry - my WIP snapcraft.yaml is http://paste.ubuntu.com/18656658/ - what are you suggesting?
[20:31] <zyga> thomi: I don't know what wxpython plugin is doing
[20:31] <zyga> thomi: ask sergiusens perhaps, sorry
[20:31] <thomi> ok, thanks
[20:38] <thomi> sergiusens: any ideas on how to resolve http://paste.ubuntu.com/18656658/ ?
[20:41] <thomi> zyga: hey - do you have any objection if I take your excellent pmr tool and turn it into a proper lp project and work on it? We're using it in onlineservices, and want to make a few modifications
[20:44] <zyga> thomi: woot, not at all
[20:44] <zyga> thomi: I'm very glad someone found it interesting! :)
[20:44] <thomi> zyga: awesome, thanks
[20:44] <zyga> thomi: I guess it spread through roadmr :D
[20:44] <zyga> thomi: I may send some pull requests your way :)
[20:44] <roadmr> zyga: yes, I am the virus :)
[20:44] <zyga> haha, that's fantastic roadmr :)
[20:44] <zyga> how are you doing? :)
[20:45] <zyga> it'd be really cool if pmr was a snap
[20:45] <roadmr> great! how about you? having snap-fun?
[20:45] <zyga> so it can use confinement to protect user data from malicious pull requests
[20:45] <zyga> and would be available everywhere
[20:45] <roadmr> ahh, great :) though that may interfere with e.g. test scripts that use fancy stuff, lxc and so on, right?
[20:46] <zyga> roadmr: yes, though all will work in good time :)
[20:46] <roadmr> awesome \o/
[20:47] <zyga> I'm deep in various distributions, not running ubuntu much anymore :)
[20:47] <zyga> I'm in suse world now :)
[20:51] <roadmr> haha :)
[20:52] <roadmr> cross-distro snap support is awesome, thanks for that \o/
[21:27] <slo_> anyone runs eclipse kura on snappy?
[21:28] <mup> PR snapd#1500 opened: many: remove snapstate.Candidate <Created by mvo5> <https://github.com/snapcore/snapd/pull/1500>
[21:33] <zyga> slangasek: hey, can you please release snap-confine to debian
[21:33] <zyga> slangasek: if you are around, I just published the upstream tarabll
[21:33] <zyga> slangasek: I sent a patch to mwhudson, not sure if it got applied yet (I didn't check)
[21:33] <mwhudson> zyga: i've done both of those things
[21:33] <zyga> mwhudson: oh, fantastic
[21:34] <zyga> mwhudson: can you do 1.0.35-1 please?
[21:34] <mwhudson> haha
[21:34] <mwhudson> you guys don't stop do you
[21:34] <zyga> mwhudson: btw, glad to see you around :) how have you been?
[21:34] <zyga> mwhudson: if you add me to comitters/uploaders I can co-maintain the package
[21:35] <zyga> mwhudson: we don't stop to fix security issues :)
[21:35]  * zyga goes to push gentoo and fedora bis
[21:36] <mwhudson> zyga: oh are you a DM?
[21:36] <mwhudson> i've been OK, had my head in go toolchain land for most of the last year
[21:36] <zyga> mwhudson: no :-(
[21:36] <zyga> mwhudson: well, not sure actually, but I haven't been updating my debian packages lately
[21:37] <slangasek> zyga: you don't appear to be a DM, and I imagine you would know if you were :)
[21:38] <zyga> slangasek: yeah, I got lost in the paperwork
[21:38] <zyga> slangasek: I think I should apply, it's super annoying sometimes
[21:38] <mwhudson> yeah, it's not overly hard
[21:38] <mwhudson> if you have a key signed by a DD anyway
[21:38] <mwhudson> the waiting is the hardest part
[21:39] <zyga> mwhudson: hmm, I don't know if I do, I had that many years ago but I lost that key with a laptop hdd years ago
[21:39] <mwhudson> zyga: so, step 1) ;-)
[21:40] <mwhudson> zyga: for reference https://wiki.debian.org/DebianMaintainer
[21:41]  * mwhudson hits gbp with a stick
[21:42] <zyga> mwhudson: hehe, I might just do it now :)
[21:42] <mwhudson> slangasek: can you just say pristine-tar = True in gbp.conf?
[21:44] <slangasek> mwhudson: should be possible, yes
[21:45] <mwhudson> zyga: you should fix that VENDOR_ARGS=--disable-confinement thing in master :-)
[21:45]  * zyga checks if hrw is a DD
[21:45] <zyga> mwhudson: in upstream master?
[21:45] <mwhudson> yeah
[21:45] <zyga> mwhudson: yes, I plan to change that entirely
[21:45] <zyga> mwhudson: by dropping packaging upstream
[21:45] <mwhudson> ah ha, yes that would solve that problem
[21:46] <zyga> mwhudson: and adjusting spread tests to fetch debian packaging, generate a new tarball, building *that* package and then merry-carrying-on
[21:46] <zyga> mwhudson: just bigger than what I wanted to tackle now
[21:46] <mwhudson> fair enough
[21:46] <zyga> (I'm discovering suse packaging the hard/practical way)
[21:47] <mwhudson> ah nope, screwed up gbp again :-)
[21:47] <mwhudson> differently this time
[21:48] <zyga> packaging tools are so diverse and different
[21:51] <mwhudson> once more around ...
[21:51] <zyga> sigh, not signed :/
[21:51] <zyga> https://pgp.mit.edu/pks/lookup?op=vindex&search=0x2894E93A28C67B47
[21:52] <zyga> ok, time to call it a day
[21:52] <zyga> just fedora bump and time to sleep
[21:53] <mwhudson> zyga: 1.0.35-1 will be in debian soon
[21:53] <mwhudson> zyga: are there release notes i can crib for debian/changelog?
[21:53] <mwhudson> or i can just say "New upstream release" and leave it at that
[21:54] <zyga> mwhudson: there are, let me show you
[21:54] <zyga> https://github.com/snapcore/snap-confine/blob/master/debian/changelog#L13
[21:54] <zyga> mwhudson: btw, how did you end up packaging snap-confine? :-)
[21:55] <mwhudson> zyga: um well i ended up on the foundations team and helping with snapd packaging made sense cause it's in go
[21:55] <mwhudson> and then snap-confine is related to snapd?
[21:55] <mwhudson> :)
[21:56] <zyga> btw, do you think golang shared libraries will hit yakkety?
[21:56] <mwhudson> they have!
[21:56] <zyga> and if so, how does that work in practice
[21:56] <zyga> ohh!
[21:56] <zyga> is that used in any other distro?
[21:56] <mwhudson> not sure, fedora might have something?
[21:57] <mwhudson> it's still very much in its infancy, i got about halfway to getting lxd to use them and then hit a grotty upstream circular dependency problem
[21:57] <zyga> how can I check that shared libraries are in use?
[21:57] <mwhudson> zyga: https://docs.google.com/document/d/1IOlBWWgcDeB9PfRORENESYj8iJt4W2EwsbYcpg4akBE/edit#heading=h.j590j9v4qbxg
[21:57] <zyga> ldd will say something?
[21:57] <mwhudson> yeah
[21:58] <zyga> added to my reading list, I bet this will end up all over all the distros soon
[22:00] <zyga> I need to spend some time tomorrow to build my VM host :/
[22:00] <zyga> so many distros
[22:00] <mwhudson> heh
[22:00] <mwhudson> ok, uploaded to debian
[22:01] <mwhudson> oh and i'm patch pilot today
[22:04] <zyga> mwhudson: good night, talk to you soon I bet ;)
[22:04] <zyga> :-)
[22:05] <mwhudson> very probably
[22:05] <mwhudson> good night
[22:08] <mhall119> sergiusens: did you ever try to build pantheon-mail snap with your changes? If so, how far did you get?
[22:25] <mcphail> If my snapcraft.yaml has 2 parts containing the same build-packages, can I safely remove the duplicates?
[22:32] <mup> PR snapd#1439 closed: daemon, overlord: add buy endpoint to REST API <Reviewed> <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1439>
[22:33] <jdstrand> zyga: hrmm
[22:34] <jdstrand> zyga: the apparmor profile for snap-confine is wrong. you moved the binary to /usr/lib/snapd/snap-confine but /etc/apparmor.d/usr.bin.snap-confine doesn't reflect that
[22:42] <zyga> jdstrand: running spread tests with the change locally
[22:42] <zyga> jdstrand: let's see what fails in practice
[22:45] <thomi> Can anyone point me at some docs that explain how snapcraft decides what should get copied from 'stage/' to 'prime/' ? I have files in 'stage' that aren't getting copied into the snap, and they're required for the snap to run correctly
[23:08] <thomi> ev: any idea on the above? ^^
[23:21] <ev> thomi: have you tried including these missing files in a "snap:” stanza?
[23:22] <ev> thomi: if you haven’t seen it yet, https://github.com/ubuntu/snappy-playpen/wiki/Examples is handy
[23:23] <thomi> ev: I haven't - I assumed there'd be something like that, but was looking for docs https://github.com/ubuntu/snappy-playpen/wiki/Examples looks perfect, thanks
[23:23] <thomi> ev: is there a way we can link to that from snapcraft.io/create?
[23:24] <thomi> actually, it looks like I want something in organize: awesome
[23:24] <thomi> so many things I didn't know existed :D
[23:50] <mup> PR snapcraft#634 opened: Run the parser integration tests with debug flag <Created by elopio> <https://github.com/snapcore/snapcraft/pull/634>