| sergiusens | thomi I just did a run through the commit logs, nothing stands out that would prevent this, plugin loading code has stayed unchanged | 02:27 |
|---|---|---|
| === chihchun_afk is now known as chihchun | ||
| TheMuso | If I want to file a bug against snapd, what project do I file the bug under in lp? Is it snappy? | 04:49 |
| === JanC is now known as Guest89378 | ||
| === JanC_ is now known as JanC | ||
| TheMuso | nvm think I have my answer. | 04:58 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| dholbach | good morning | 06:32 |
| netphreak | morning :) | 06:35 |
| mup | PR snapd#1491 opened: use more consistent "snap %q (rev %s)" task descriptions <Created by mvo5> <https://github.com/snapcore/snapd/pull/1491> | 06:58 |
| dholbach | kyrofa, sergiusens: does https://github.com/ubuntu/snappy-playpen/issues/145 look like a snapcraft bug to you? | 07:02 |
| 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:39 |
| 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:44 |
| 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:49 |
| mup | PR snapd#1493 opened: store/auth: add SnapUbuntuStoreAuthService with device identity methods <Created by wgrant> <https://github.com/snapcore/snapd/pull/1493> | 07:51 |
| mup | PR snapd#1494 opened: tests: add content sharing interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1494> | 08:00 |
| 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:19 |
| 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:20 |
| mup | PR snapd#1496 opened: tests: add spread test for tried snaps removal <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1496> | 08:36 |
| 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:41 |
| pachulo | /buffer 7 | 08:45 |
| 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:37 |
| 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:54 |
| 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:55 |
| 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:56 |
| jamiebennett | ogra_: How much work will it be to have both? | 09:57 |
| 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:58 |
| 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 | 09:59 |
| 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:08 |
| 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:10 |
| 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:11 |
| 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:12 |
| ogra_ | yeah, most likely | 10:13 |
| joc_ | morphis: i notice the tpm part on the wiki page has a source-type field which i think shouldnt be there | 10:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| morphis | didrocks: yeah | 10:23 |
| 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:47 |
| 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:49 |
| oSoMoN | looking at UbuntuI18n::setDomain(…), this should work, as it calls bindtextdomain with $APP_DIR/share/locale/ | 10:50 |
| 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:54 |
| 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:57 |
| 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:58 |
| ogra_ | oSoMoN, i guess it depends ... if they use the same bindtextdomain in the backend you will have the exact same problem | 10:59 |
| ogra_ | sadly the issue is in the lowest level of the stack | 11:01 |
| === hikiko is now known as hikiko|bbi | ||
| === hikiko|bbi is now known as hikiko|bbl | ||
| 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:08 |
| * oSoMoN is not very familiar with the inners of libintl | 11:09 | |
| seb128 | oSoMoN, yeah, which is what I wrote no? | 11:15 |
| 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:16 |
| 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:20 |
| 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:21 |
| 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:22 |
| kyrofa | dholbach, man... I have no idea what's going on with that qmake thing | 11:27 |
| kyrofa | dholbach, I wonder if it means qmake's support for out-of-source builds is not that great | 11:31 |
| 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:33 |
| oSoMoN | seb128, agreed, will do | 11:34 |
| seb128 | oSoMoN, thanks | 11:35 |
| 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:39 |
| oSoMoN | seb128, how would I go about shipping the locale definitions in my snap? | 11:40 |
| seb128 | not sure there is a standard way, fwded you an email discussing the freecad example which had some hacks for that | 11:44 |
| 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:50 |
| 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:54 |
| 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:56 |
| ogra_ | (or install freecad and take a look at thw wraper in /snap/freecad/current/ ) | 11:57 |
| 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:02 |
| mhall119 | sergiusens: are your pkg-config changes in snapcraft 2.12? | 12:40 |
| mup | PR snapcraft#631 closed: Fix the store integration tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/631> | 12:46 |
| 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:53 |
| === hikiko|bbl is now known as hikiko | ||
| josepht | didrocks: which part? | 12:59 |
| kyrofa | sergiusens, elopio is jenkins having problems today? I can't reach results, and now they don't seem to be triggering | 13:01 |
| sergiusens | kyrofa we might need to telegram elopio | 13:10 |
| kyrofa | sergiusens, you're seeing that too then, eh? | 13:10 |
| mhall119 | sergiusens: how can I try your patch in a cleanbuild then? | 13:12 |
| sergiusens | kyrofa not really | 13:12 |
| kyrofa | sergiusens, ah, I triggered them manually... we'll see what happens | 13:13 |
| kyrofa | Whoa, and failed | 13:13 |
| 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:14 |
| sergiusens | kyrofa and it is now sort of readable too ;-) less spaghettiesh | 13:15 |
| kyrofa | Yeah, very nice | 13:15 |
| josepht | sergiusens: nice! | 13:15 |
| didrocks | josepht: desktop/* | 13:27 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:34 |
| 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:35 |
| didrocks | I'll file a bug | 13:36 |
| josepht | didrocks: thank you | 13:36 |
| didrocks | yw, thanks to you :) | 13:36 |
| josepht | yw as well :) | 13:37 |
| sergiusens | kyrofa maybe fgimenez can help out | 13:46 |
| sergiusens | kyrofa I see on that "other" channel that elopio redeployed da jenks | 13:46 |
| kyrofa | fgimenez, snapcraft's jenkins is super broken (not sure about snapd's) | 13:47 |
| 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:48 |
| kyrofa | fgimenez, the one just ran: http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/1095/ | 13:49 |
| 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:52 |
| 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:55 |
| kyrofa | sergiusens, nice! | 13:56 |
| 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:01 |
| 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:04 |
| 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:05 |
| 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:08 |
| 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:10 |
| 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:15 |
| fgimenez | let me know if anything else is missing | 14:16 |
| kyrofa | fgimenez, thank you! Looks great :) | 14:16 |
| fgimenez | kyrofa, yw :) | 14:17 |
| === tyhicks` is now known as tyhicks | ||
| 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:03 |
| mup | PR snapcraft#632 opened: WIP Refactor/push <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/632> | 15:04 |
| kyrofa | sergiusens, alrighty | 15:07 |
| 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:14 |
| 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:15 |
| kyrofa | Yeah I bet | 15:16 |
| sergiusens | kyrofa so happy I lost track of time last night and went to bed really late :-P | 15:17 |
| sergiusens | S4ruman | 15:17 |
| 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:18 |
| 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:19 |
| 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:25 |
| 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:26 |
| 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:54 |
| * kyrofa bashes head on desk and goes to make more coffee | 15:56 | |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| ogra_ | ah, because i wown it already :P | 16:08 |
| ogra_ | direct upload works | 16:08 |
| sergiusens | kyrofa what test is failing? care to record that in a comment with the traceback? | 16:10 |
| 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:18 |
| sergiusens | kyrofa good thing I told elopio to keep an eye on jenkins :-P | 16:22 |
| 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:28 |
| tsimonq2 | oh great, my FAVORITE spam bot just commented on my PR twice again.... :P | 16:29 |
| tsimonq2 | (jk) | 16:29 |
| 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:50 |
| 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> | 16:52 |
| === dpm is now known as dpm-afk | ||
| jdstrand | zyga_: hey, so, snap-confine has a 1.0.34 tag but the debian/changelog still says UNRELEASED for 1.0.34 | 17:37 |
| 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:40 |
| 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:41 |
| kyrofa | I love it-- an errant wiki entry takes down our CI | 17:42 |
| sergiusens | josepht do you know how to fix it? | 17:46 |
| josepht | sergiusens: yeah, I think so | 17:46 |
| 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:48 |
| ssweeny | jdstrand, will try, thanks! (it works perfectly in dev mode and I'm working through confinement issues) | 17:49 |
| 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:51 |
| ssweeny | i think that's what's being resolved for $XDG_CACHE_DIR | 17:52 |
| ssweeny | or $XDG_CACHE_HOME rather | 17:53 |
| josepht | sergiusens: the parser seems to be getting a stale/cached version of the wiki | 17:54 |
| 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:02 |
| jdstrand | ssweeny: hmm, $HOME/snap/${SNAP}/${REV}/.cache should be allowed. can you paste the denial? | 18:05 |
| kyrofa | jdstrand, oh nevermind... it's denying access to mount, haha | 18:06 |
| kyrofa | Wait no... that's allowed | 18:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| ssweeny | interesting | 18:12 |
| ssweeny | I think I did run as root first | 18:12 |
| 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:16 |
| 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:20 |
| 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:21 |
| 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:23 |
| 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:24 |
| 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:25 |
| jdstrand | niemeyer: sure thing | 18:26 |
| zyga | jdstrand: ack, looking now | 18:26 |
| zyga | jdstrand: ack, I'll merge this soon but please add a spread test | 18:27 |
| jdstrand | yikes | 18:27 |
| zyga | jdstrand: ? | 18:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| zyga | jdstrand: then spread $idofthetest | 18:33 |
| zyga | jdstrand: that will get you started faster | 18:33 |
| 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:39 |
| kyrofa | nessita, why do automated review warnings result in a manual review being required? | 18:44 |
| 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:45 |
| jdstrand | that is an ongoing conversation | 18:47 |
| jdstrand | bottom line is, each check needs to be re-reviewed for what should block and what shouldn't | 18:48 |
| 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:49 |
| jdstrand | feel free to file a bug against the review tools | 18:50 |
| jdstrand | kyrofa (cc nessita): ^ | 18:50 |
| kyrofa | jdstrand, alright, thank you | 18:51 |
| kyrofa | jdstrand, any chance you could approve that snap? | 18:55 |
| jdstrand | kyrofa: done | 18:59 |
| * jdstrand leaves sergiusens' nil-snap alone | 18:59 | |
| sergiusens | jdstrand please do :-) | 19:00 |
| kyrofa | jdstrand, thank you! | 19:01 |
| nessita | jdstrand, thanks for answering | 19:05 |
| nessita | kyrofa, we want good packages in the store, so why would your package not have a binary? (besides what jamie said) | 19:06 |
| 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:10 |
| kyrofa | /sharing mechanism | 19:11 |
| kyrofa | jdstrand, ah, an armhf arrived late if you could push the button on that one as well | 19:13 |
| jdstrand | done | 19:14 |
| kyrofa | Thank you! | 19:14 |
| 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:22 |
| kgunn | he has one there listed "experimental" | 19:23 |
| kgunn | i think i'm on cirica may 2nd | 19:23 |
| zyga | re | 19:52 |
| 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:01 |
| jdstrand | zyga: I've almost got a test verifying cgroups work correctly. then the next test for regressing execle should be fast | 20:02 |
| 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:03 |
| 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:06 |
| jdstrand | zyga: ok, added preliminary cgroup test | 20:09 |
| jdstrand | zyga: so, debian/changelog still has 1.0.34 UNRELEASED | 20:09 |
| jdstrand | zyga: can you fix that up? I can then add an entry for this | 20:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| sawdog | I’m assuming that the curl app doesn’t have proper access… | 20:14 |
| zyga | sawdog: I'm not sure what you are doing is what you really want | 20:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| zyga | thomi: using a public pastebin would be easier for others to read | 20:21 |
| thomi | zyga: good point | 20:21 |
| thomi | zyga: http://pastebin.ubuntu.com/18656156/ | 20:22 |
| 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:23 |
| 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:24 |
| 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:28 |
| zyga | thomi: as for sharing, not sure, just a snapcraft design or bug | 20:29 |
| thomi | zyga: I don't understand, sorry - my WIP snapcraft.yaml is http://paste.ubuntu.com/18656658/ - what are you suggesting? | 20:30 |
| 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:31 |
| === chihchun is now known as chihchun_afk | ||
| thomi | sergiusens: any ideas on how to resolve http://paste.ubuntu.com/18656658/ ? | 20:38 |
| 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:41 |
| 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:44 |
| 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:45 |
| zyga | roadmr: yes, though all will work in good time :) | 20:46 |
| roadmr | awesome \o/ | 20:46 |
| zyga | I'm deep in various distributions, not running ubuntu much anymore :) | 20:47 |
| zyga | I'm in suse world now :) | 20:47 |
| roadmr | haha :) | 20:51 |
| roadmr | cross-distro snap support is awesome, thanks for that \o/ | 20:52 |
| slo_ | anyone runs eclipse kura on snappy? | 21:27 |
| mup | PR snapd#1500 opened: many: remove snapstate.Candidate <Created by mvo5> <https://github.com/snapcore/snapd/pull/1500> | 21:28 |
| 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:33 |
| 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:34 |
| zyga | mwhudson: we don't stop to fix security issues :) | 21:35 |
| * zyga goes to push gentoo and fedora bis | 21:35 | |
| 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:36 |
| slangasek | zyga: you don't appear to be a DM, and I imagine you would know if you were :) | 21:37 |
| 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:38 |
| 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:39 |
| mwhudson | zyga: for reference https://wiki.debian.org/DebianMaintainer | 21:40 |
| * mwhudson hits gbp with a stick | 21:41 | |
| zyga | mwhudson: hehe, I might just do it now :) | 21:42 |
| mwhudson | slangasek: can you just say pristine-tar = True in gbp.conf? | 21:42 |
| slangasek | mwhudson: should be possible, yes | 21:44 |
| 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:45 |
| 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:46 |
| mwhudson | ah nope, screwed up gbp again :-) | 21:47 |
| mwhudson | differently this time | 21:47 |
| zyga | packaging tools are so diverse and different | 21:48 |
| mwhudson | once more around ... | 21:51 |
| zyga | sigh, not signed :/ | 21:51 |
| zyga | https://pgp.mit.edu/pks/lookup?op=vindex&search=0x2894E93A28C67B47 | 21:51 |
| zyga | ok, time to call it a day | 21:52 |
| zyga | just fedora bump and time to sleep | 21:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| zyga | added to my reading list, I bet this will end up all over all the distros soon | 21:58 |
| 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:00 |
| mwhudson | oh and i'm patch pilot today | 22:01 |
| zyga | mwhudson: good night, talk to you soon I bet ;) | 22:04 |
| zyga | :-) | 22:04 |
| mwhudson | very probably | 22:05 |
| mwhudson | good night | 22:05 |
| mhall119 | sergiusens: did you ever try to build pantheon-mail snap with your changes? If so, how far did you get? | 22:08 |
| mcphail | If my snapcraft.yaml has 2 parts containing the same build-packages, can I safely remove the duplicates? | 22:25 |
| 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:32 |
| jdstrand | zyga: hrmm | 22:33 |
| 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:34 |
| zyga | jdstrand: running spread tests with the change locally | 22:42 |
| zyga | jdstrand: let's see what fails in practice | 22:42 |
| 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 | 22:45 |
| thomi | ev: any idea on the above? ^^ | 23:08 |
| ev | thomi: have you tried including these missing files in a "snap:” stanza? | 23:21 |
| ev | thomi: if you haven’t seen it yet, https://github.com/ubuntu/snappy-playpen/wiki/Examples is handy | 23:22 |
| 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:23 |
| thomi | actually, it looks like I want something in organize: awesome | 23:24 |
| thomi | so many things I didn't know existed :D | 23:24 |
| mup | PR snapcraft#634 opened: Run the parser integration tests with debug flag <Created by elopio> <https://github.com/snapcore/snapcraft/pull/634> | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!