[02:27] thomi I just did a run through the commit logs, nothing stands out that would prevent this, plugin loading code has stayed unchanged === chihchun_afk is now known as chihchun [04:49] If I want to file a bug against snapd, what project do I file the bug under in lp? Is it snappy? === JanC is now known as Guest89378 === JanC_ is now known as JanC [04:58] nvm think I have my answer. === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:32] good morning [06:35] morning :) [06:58] PR snapd#1491 opened: use more consistent "snap %q (rev %s)" task descriptions [07:02] kyrofa, sergiusens: does https://github.com/ubuntu/snappy-playpen/issues/145 look like a snapcraft bug to you? [07:39] PR snapd#1437 closed: snapstate: use snapstate.Type in backend.RemoveSnapFiles [07:44] PR snapd#1480 closed: many: rename SideInfo.OfficialName to SideInfo.RealName [07:49] PR snapd#1492 opened: overlord/auth: add Device/SetDevice to persist device identity in state [07:51] PR snapd#1493 opened: store/auth: add SnapUbuntuStoreAuthService with device identity methods [08:00] PR snapd#1494 opened: tests: add content sharing interface spread test [08:19] PR snapd#1495 opened: snapstate: rename OfficialName to RealName in the new tests [08:20] 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] PR snapd#1496 opened: tests: add spread test for tried snaps removal [08:41] PR snapd#1495 closed: snapstate: rename OfficialName to RealName in the new tests [08:45] /buffer 7 [09:37] PR snapd#1497 opened: tests, integration-tests: port auth errors test to spread [09:54] ogra_: hey, how goes? [09:54] ogra_: would you know if our future rpi3 image will be armhf or arm64 based? [09:54] ogra_: if armhf, how hard would it be to do an arm64 one for a third-party? [09:54] lool, we'll have both i think [09:55] ogra_: both officially supported? [09:55] (at least i plan to have snaps for both in the store, not sure which we'll make official [09:55] ) [09:55] i'll bring that up at the sprint [09:56] we'll be most likely missing firmware blobs for BT and wifi for arm64 [09:56] i havent played with that yet [09:57] ogra_: How much work will it be to have both? [09:58] 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] ogra_: and on the testing and support side? [09:58] you mean when both are official ? well, twice as much :) [09:59] (manual smoke testing etc) [09:59] * jamiebennett nods [09:59] i think it is fine to have the arm64 build unsupported [09:59] ack [09:59] for official arm64 we have the dragonboard [10:08] 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] is bug #1576282 relevant here? [10:10] Bug #1576282: Snaps built from deb can't be gettext translated [10:11] 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] hugh, that’s ugly! [10:11] ogra_, looking at your suggestion in the bug report [10:12] for plain libc translations LOCPATH should help [10:12] afaik niemeyer plans to have some generic preloader thing builtin in snapd at some point ... that will make it easier [10:12] 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] yeah, most likely [10:17] morphis: i notice the tpm part on the wiki page has a source-type field which i think shouldnt be there [10:18] joc_: it should be origin-type [10:18] didrocks added that [10:18] joc_: fixed that [10:18] morphis: yep just added a part myself, maybe should remove it so it doesnt get copied by others [10:19] good :) [10:19] I talked with didrocks yesterday and thought he added origin-type and not source-type [10:19] didrocks: was there any reason to use source-type instead? [10:20] morphis: hum, sorry, I'm lost context? [10:20] I didn't touch the tpm part [10:20] or not intentionally :p [10:20] didrocks: or was it dholbach? :-) [10:20] don't remember [10:20] the "d" guys :) [10:21] this is the only changed I did: https://wiki.ubuntu.com/snapcraft/parts?action=diff&rev2=16&rev1=15 [10:21] seems it's dholbach, indeed: https://wiki.ubuntu.com/snapcraft/parts?action=diff&rev2=15&rev1=11 [10:21] ogra_, actually, it seems the UITK exposes a i18n.bindtextdomain(domainName, dirName) method to QML [10:21] oSoMoN, oh ! thats neat ... [10:22] I’ll test it [10:22] if it works, you should perhaps mention it in the bug [10:22] will definitely doo [10:22] -o [10:23] didrocks: yeah [10:47] 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] 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] looking at UbuntuI18n::setDomain(…), this should work, as it calls bindtextdomain with $APP_DIR/share/locale/ [10:54] oSoMoN: are you sure bindtextdomain works? I remember that seb128 looked at this closer than I did [10:54] IIRC, there was an issue if you don't set it to prefix [10:57] didrocks, well, if the uitk look into $APP_DIR whatever that is... [10:57] didrocks, what do you mean by set it to prefix? [10:57] doesn't work for non-UbuntuUITK code [10:58] since most upstream dp $datadir/locales [10:58] which is set from the prefix at buildtime [10:58] 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] Bug #1576282: Snaps built from deb can't be gettext translated [10:59] oSoMoN, i guess it depends ... if they use the same bindtextdomain in the backend you will have the exact same problem [11:01] sadly the issue is in the lowest level of the stack === hikiko is now known as hikiko|bbi === hikiko|bbi is now known as hikiko|bbl [11:08] 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] oSoMoN, yeah, which is what I wrote no? [11:16] oSoMoN, non-UbuntuUITK C code use $datadir/locales which is set according to prefix at buildtime [11:16] seb128, yes, that’s why I’m confused by ogra_’s comments, are there two separate issues maybe? [11:16] oSoMoN, dunno about uitk, I guess it they handle it it's handled [11:16] no idea [11:20] if UITK just uses the bindtextdomain fromm gettext any setting of a path will be ignored ... thats what i mean [11:20] wrapping the UITK around the funbction wont change its behaviour [11:21] expect if the uitk read the env and do something like bindtextdomain(getenv($somevar))+"usr/share/locale") [11:21] try stracing it :) [11:22] seb128, with its own bindtextdomain ? [11:22] that would indeed work [11:22] if it just hooks into gettext there wont be a getenv ... [11:27] dholbach, man... I have no idea what's going on with that qmake thing [11:31] dholbach, I wonder if it means qmake's support for out-of-source builds is not that great [11:33] oSoMoN, you might want to open a new bug rather than commenting on this one btw [11:33] oSoMoN, that bug is specifically about code hardcoding a path to bindtextdomain() at buildttime [11:33] oSoMoN, your issue is different and with the uitk, that should work [11:34] seb128, agreed, will do [11:35] oSoMoN, thanks [11:39] 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] oSoMoN, I guess it's possible yes [11:40] seb128, how would I go about shipping the locale definitions in my snap? [11:44] not sure there is a standard way, fwded you an email discussing the freecad example which had some hacks for that [11:50] PR snapd#1497 closed: tests, integration-tests: port auth errors test to spread [11:54] PR snapd#1496 closed: tests: add spread test for tried snaps removal [11:56] 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] (or install freecad and take a look at thw wraper in /snap/freecad/current/ ) [12:02] PR snapd#1484 closed: tests, integration-tests: port unity test to spread [12:40] sergiusens: are your pkg-config changes in snapcraft 2.12? [12:46] PR snapcraft#631 closed: Fix the store integration tests [12:53] PR snapd#1498 opened: tests, integration-tests: port systemd service check test to spread [12:53] mhall119 no, 2.12 was released before I fixed it === hikiko|bbl is now known as hikiko [12:59] didrocks: which part? [13:01] sergiusens, elopio is jenkins having problems today? I can't reach results, and now they don't seem to be triggering [13:10] kyrofa we might need to telegram elopio [13:10] sergiusens, you're seeing that too then, eh? [13:12] sergiusens: how can I try your patch in a cleanbuild then? [13:12] kyrofa not really [13:13] sergiusens, ah, I triggered them manually... we'll see what happens [13:13] Whoa, and failed [13:14] Immediately [13:14] kyrofa I've been working on all this red https://github.com/snapcore/snapcraft/compare/master...sergiusens:refactor/push [13:14] sergiusens, looooovely! [13:14] I love that kind of red [13:15] kyrofa and it is now sort of readable too ;-) less spaghettiesh [13:15] Yeah, very nice [13:15] sergiusens: nice! [13:27] josepht: desktop/* [13:30] 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] didrocks: did you do a 'snapcraft update' to the get the latest parsed output locally? [13:31] josepht: oh, I thought that was fetched from the description in the git repo [13:31] ok, it's copied there as well [13:32] josepht: any chance to have a different one per "parts" from the same namespace? [13:32] (like desktop/qt5 have a different description from desktop/gtk3) [13:34] 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] 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] josepht: yeah, that's what I did with the new one :) [13:36] I'll file a bug [13:36] didrocks: thank you [13:36] yw, thanks to you :) [13:37] yw as well :) [13:46] kyrofa maybe fgimenez can help out [13:46] kyrofa I see on that "other" channel that elopio redeployed da jenks [13:47] fgimenez, snapcraft's jenkins is super broken (not sure about snapd's) [13:48] fgimenez, e.g. http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/1094/ [13:48] kyrofa, sergiusens yep, the redeploy has just finished, all should be working now [13:48] kyrofa, let me check... [13:48] fgimenez, ah, okay I just retriggered them, see if things are working [13:48] Nope, immediate failures [13:49] fgimenez, the one just ran: http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/1095/ [13:52] kyrofa, it seems to complain about the available images, let me see what is it looking for... [13:52] fgimenez, alright, thanks for checking it out :) [13:52] kyrofa, np :) i'll let you know how it goes [13:55] kyrofa my refactor only has 6 unit test errors! [13:55] kyrofa and only because it wants to mock stuff that I made dissappear :-) [13:56] sergiusens, nice! [14:01] 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] 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] fgimenez, yeah, autopkgtests seem to be running now [14:05] fgimenez, just example tests now [14:05] kyrofa, ok on it [14:08] 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] hmm [14:10] do we have any snapcraft.yaml example for SW that uses sourceforge ? [14:10] especially for downloading the source [14:15] 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] PR ubuntu-core/snappy-jenkins#186: fixed regions and variable expansion [14:16] let me know if anything else is missing [14:16] fgimenez, thank you! Looks great :) [14:17] kyrofa, yw :) === tyhicks` is now known as tyhicks [15:03] kyrofa before I move on, I would really like an initial review on https://github.com/snapcore/snapcraft/pull/632 [15:03] PR snapcraft#632: WIP Refactor/push [15:04] PR snapcraft#632 opened: WIP Refactor/push [15:07] sergiusens, alrighty [15:14] sergiusens, yeah the direction looks good. Missing some good error handling, but I assume that stuff is coming [15:14] kyrofa except KeyError? [15:15] kyrofa yeah, that is missing ;-) [15:15] Yeah, that :P [15:15] kyrofa going to go the exception route and create a StoreReviewError or something like that [15:15] getting rid of so many if/else on keywords really made me happy [15:16] Yeah I bet [15:17] kyrofa so happy I lost track of time last night and went to bed really late :-P [15:17] S4ruman [15:18] ogra_: Regarding "afaik niemeyer plans to have some generic preloader thing builtin in snapd at some point ... that will make it easier" [15:18] ogra_: I actually have it pretty much ready [15:19] ogra_: It's not inside snapd though, but a library on its own [15:19] ogra_: Worked on that over the weekend while fighting an app [15:25] PR snapd#1482 closed: store, many: start using the new details endpoint [15:26] PR snapd#1488 closed: store: switch search to new snap-specific endpoint [15:26] niemeyer, cool [15:26] thanks for cllearifyin [15:26] g [15:54] PR snapd#1499 opened: tests: use systemd-run for starting and stopping the unity app [15:56] * kyrofa bashes head on desk and goes to make more coffee [16:02] 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] and unpublishing doesnt clean that up [16:02] ogra_, let me check! [16:02] ogra_, I see 3 nethacks: nethack-amd64 nethack-armhf and nethack -- is the last one? [16:02] (and renaming obviously only renames the representation in the store, not the packagename) [16:03] yeah [16:03] looks like is busted somehow, let me check [16:03] i dont mind if you remove it completely [16:04] in case thats needed [16:04] ogra_, I may do that, but let me fully check [16:04] ogra_, let me delete the package and you can register the name right after [16:05] nessita, btw, ircproxy, upnp-server and packageproxy will have the same issue (and i plan fesh uploads for them) [16:05] elopio, this is successful, right? http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/1099/console [16:05] elopio, looks like it just didn't clean up right? [16:05] so it might make sense to remove them too [16:05] ogra_, nethack deleted, feel free to re-register [16:05] great [16:06] sergiusens, short of the (incorrectly failing) tests, does #622 look good? [16:06] ogra_, let me check details for ircproxy, upnp-server and packageproxy [16:06] they can all go as well [16:06] nope ... "new snap" still tells me the namespace is taken [16:08] ah, because i wown it already :P [16:08] direct upload works [16:10] kyrofa what test is failing? care to record that in a comment with the traceback? [16:18] sergiusens, I'm actually not sure what's happening on autopkg [16:18] sergiusens, http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/1099/console [16:18] It looks like a testbed issue, but I'm not certain [16:22] kyrofa good thing I told elopio to keep an eye on jenkins :-P [16:28] 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] PR snapcraft#619: Add source-checksum option for tar and zip sources (bug 1585913) [16:29] oh great, my FAVORITE spam bot just commented on my PR twice again.... :P [16:29] (jk) [16:50] PR snapd#1498 closed: tests, integration-tests: port systemd service check test to spread [16:52] PR snapd#1499 closed: tests: use systemd-run for starting and stopping the unity app [16:52] PR snapcraft#633 opened: qmake plugin: Stop doing out-of-source builds === dpm is now known as dpm-afk [17:37] zyga_: hey, so, snap-confine has a 1.0.34 tag but the debian/changelog still says UNRELEASED for 1.0.34 [17:40] sergiusens, any idea what's happening here? https://travis-ci.org/snapcore/snapcraft/jobs/142820726 [17:40] Not the most descriptive failure I've seen [17:40] 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] kyrofa I asked josepht to look at it, the wiki is probably broken and our tests rely on it [17:41] sergiusens, ah [17:41] kyrofa I think work is already in progress to move to fake servers [17:41] Good deal [17:41] sergiusens, kyrofa: yes, the desktop entry is broken [17:42] I love it-- an errant wiki entry takes down our CI [17:46] josepht do you know how to fix it? [17:46] sergiusens: yeah, I think so [17:48] 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] ssweeny: when filing a bug, please add the 'snapd-interface' tag [17:49] jdstrand, will try, thanks! (it works perfectly in dev mode and I'm working through confinement issues) [17:51] 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] i think that's what's being resolved for $XDG_CACHE_DIR [17:53] or $XDG_CACHE_HOME rather [17:54] sergiusens: the parser seems to be getting a stale/cached version of the wiki [18:02] 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] jdstrand, is there any way around that? [18:05] ssweeny: hmm, $HOME/snap/${SNAP}/${REV}/.cache should be allowed. can you paste the denial? [18:06] jdstrand, oh nevermind... it's denying access to mount, haha [18:06] Wait no... that's allowed [18:07] I stand by the mount space theory [18:07] jdstrand, it turns out I installed the snap as root and it created the rev directory with root ownership [18:07] even under /home/ubuntu/snap/... [18:08] 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] ssweeny: yes that is an annoying bug [18:08] installing as root shouldn't be the issue. running as root before running as yourself would [18:09] or running another program (eg, snappy-debug) as root on a system that doesn't have ~/snap already will do it [18:09] (since ~/snap is root owned then) [18:12] interesting [18:12] I think I did run as root first [18:16] jdstrand: Would you mind to have a quick look on snapd#1405 when you have a moment? Should be an easy walk [18:16] PR snapd#1405: interfaces: add zigbee-dongle interface [18:16] Hi, is there any HW matrix support available for Snappy? So which CPUs are supported or which HW platforms (rpi, artik, etc...) ? [18:20] 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] s/see is/see it/ [18:21] 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] 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] PR snap-confine#72: use execle() with empty environment when calling snappy-app-dev [18:23] jdstrand, I figure it's the slave mount namespace [18:24] jdstrand, is there any nifty mount instantiations that will allow me to hop out of that in devmode? [18:24] 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] jdstrand, haha, that's exactly what I'm doing but... yuck :P [18:25] kyrofa: otoh, idk. atm I'm working on said semi-urgent issue and don't have time to look right now [18:25] jdstrand, that's alright, no problem [18:25] jdstrand: Thanks! [18:26] niemeyer: sure thing [18:26] jdstrand: ack, looking now [18:27] jdstrand: ack, I'll merge this soon but please add a spread test [18:27] yikes [18:27] jdstrand: ? [18:28] I'll have to think about that. this is a pretty convulated attack [18:28] convoluted [18:28] jdstrand: after this lands I'll release .35 [18:28] joc_: That PR is yours isn't it? [18:28] jdstrand: is there something we could do to just show that PATH is reset? [18:28] jdstrand: what is NULL environment in practice? empty [18:28] zyga: yes, empty [18:28] jdstrand: or inherited from some safe default [18:28] hmmm [18:29] so PATH won't resolve at all, is that what we want? [18:29] joc_: snapd#1405 that is [18:29] PR snapd#1405: interfaces: add zigbee-dongle interface [18:29] zyga: the problem is that only snappy-app-dev will see that environment [18:29] jdstrand: that's right, so as long as it can cope, it is okay [18:29] right? [18:29] zyga: will spread allow me to replace /lib/udev/snappy-app-dev? I guess not since it is in read only part? [18:29] it will [18:30] you build the package, install it and run anything as root [18:30] (as long as you clean up in restore you are good) [18:30] ok, then I can come up with a test [18:31] 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] 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] I may have some questions [18:32] ok [18:32] jdstrand: I'll be here [18:32] jdstrand: hint: spread -list [18:33] jdstrand: then spread $idofthetest [18:33] jdstrand: that will get you started faster [18:39] 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] nessita, why do automated review warnings result in a manual review being required? [18:45] 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] that is an ongoing conversation [18:48] bottom line is, each check needs to be re-reviewed for what should block and what shouldn't [18:49]