=== JanC is now known as Guest41566 === JanC_ is now known as JanC === Aria22 is now known as Aria22|away [03:21] so wtf is this supposed to mean? 'NoneType' object has no attribute 'lstrip' [03:42] hi hathor008. I see you are having no more luck than I am lol [03:43] https://gist.github.com/anonymous/0cb3931924b497dad9c73d597716bd74 [03:43] yeah i mean this process is really confusing [03:47] http://askubuntu.com/questions/779315/how-do-i-create-a-snap-for-a-monogame-application [04:07] I'll take a look at your case tomorrow if I can find some time. [04:07] thanks === Aria22|away is now known as Aria === Aria is now known as Aria|away [06:51] hi, I'd like to ask a question about publishing. If I build a snap package but I cannot make it public is there a way, like a private repo, to publish it only in my team or for my IoT devices? [08:48] o/ [08:50] hi === dpm is now known as dpm-afk [09:15] tptr: yes, there's a concept of private snaps (that can be shared with a selected group) [09:20] pedronis: ok thanks, I will keep digging then. [10:39] Whoami [10:40] http://askubuntu.com/questions/779267/snapcraft-snap-failing-because-python-modules-are-missing?noredirect=1#comment1165744_779267 [10:40] Hey people, could someone take a look here? [10:41] heh ... fun that people always start packaging with the hardest tasks :) [10:41] Yeah, I thought that too [10:42] looks like you want some additional python packages there [10:42] But I just couldn't reproduce the error that OP filled in to [10:42] pythoon-apport comes to mind seeing the error [10:43] or rather python3-apport ... (not sure if that one is still needed though, py3 should be the default) [10:43] I don't know too [10:43] same goes for python-dbus ... [10:44] Why is that dependencies listed by setup.py are not getting installed and require being listed apart in the yaml file? [10:45] thats a question for sergiusens :) [10:45] I am not Seth, just was very curious. If you happen to try anything, please answer in this thread ok? [10:46] what i see is that the OP is using python3-* packages everywhere ... could well be that in 16.04 these are just empty transitional packages ... [10:46] I tried a lot of different stuff last night with Seth and we couldn't trace back the cause of errors [10:46] and python-apport is clearly missing [10:46] Uhm, that's a great idea, I didn't checked to see what python3 packages were indeed installing [10:47] even if you get it packaged though ... you will need a lot of interface work still ... we dont have a way yet to attach to the system fonts ot themes from a snap ... you will only be able to run it in devmode for now [10:48] I went to the ubuntuforums.org and couldn't find a topic for discussion on Snaps, where can I suggest a dedicated forum there? [10:48] I see, so it wouldn't be able to change themes and unity options like usual? [10:56] well, you can suggest the snapcraft mailing list (at https://lists.ubuntu.com/mailman/listinfo/snapcraft ) [10:56] and this IRC channel here [10:57] i dont think any developer actually monitors forums much [11:11] Thanks. I will enter the mailing list :) === Aria|away is now known as Aria === Aria is now known as Aria22 === Aria22 is now known as Aria22|away [13:05] ogra_ I don't see AndroUser on anymore nor did I see a mailinglist question so if he comes by, tell him that install_requires in setup.py is automatically taken care of. [13:06] sergiusens, well, the askubuntu thing seems to not find some deps (python-dbus, python-apport namely) [13:06] http://askubuntu.com/questions/779267/snapcraft-snap-failing-because-python-modules-are-missing?noredirect=1#comment1165744_779267 [13:12] ogra_ I bet python-apport is not on pypi or has a different name there [13:13] yeah [13:13] it has already sort of been answered === Aria22|away is now known as Aria === dpm-afk is now known as dpm === Aria is now known as Aria|away === chihchun is now known as chihchun_afk [16:59] Hi. I have a python code running on snappy. It basically just accesses SNAP_USER_DATA. And some networking stuff. But I get a lot of apparmor warnings - any ideas what could be wrong? https://paste.kde.org/pawrdt7xc [17:23] sborovkov seems you installed with devmode [17:23] Not much of a problem if so. It all says ALLOWED [17:25] sergiusens: yeah, I did. Thought that what's allowed in devmode would be forbidden without it :-) [17:26] is that not the case? [17:51] sborovkov, if you don't specify --devmode then the snap runs confined [17:51] once your confinement description is correct, then you can drop the --devmode [17:51] which is a good thing :) [17:53] the point of --devmode is that it is sometimes hard to get the confinement description complete up front [17:53] so --devmode lets you put things into "log only" mode (well, mostly, some things still shoot you in --devmode :)) [17:54] sergiusens, around? [17:59] sabdfl yes I am [18:00] sborovkov let me open your paste again [18:00] sborovkov was mislead by the mention of "warnings" [18:01] sborovkov is ldconfig run by the snap by any chance? [18:04] sergiusens, would this work: [18:04] ah [18:56] sergiusens: sabdfl: I understand that devmode allows everything. But I thought any apparmor "allowed" message mean that it would not work without devmode. [18:58] sergiusens: >is ldconfig run by the snap by any chance - that's relatively simple python program. So I don't understand where ldconfig is coming from at the moment. Thought that may be python is running it... [19:01] sborovkov line 3 indicates this, not sure what your simple program is (or maybe a wrapper script you have going around) [19:05] sborovkov, sergiusens: ldconfig is being ran and that is the cause of nearly all the AppArmor denials [19:06] tyhicks it seems so from line 3. Trying to find out where :-) [19:06] the /proc/.../mounts one isn't much of a problem [19:06] sergiusens: the mount-observe interface allows reading /proc/PID/mounts [19:07] tyhicks but do we need it? I was thinking of it as a harmless error [19:07] for the python runtime case [19:08] sergiusens: tyhicks: I have custom ld.so file. exec "$VIEWER_APP_PATH/lib/ld-linux-armhf.so.3" --inhibit-cache $@ This is how another part of snap is run... But this messages come from python part which is run as usual [19:08] if this is relevant... [19:08] sergiusens: I'm not sure if python will croak if it can't read /proc/PID/mounts - I'd be surprised if it was treated as a fatal error but I'm just not 100% sure [19:10] sergiusens: tyhicks: also do you know if snap installed in --devmode can drop devmode somehow without manual interaction on snap upgrade let's say? [19:10] tyhicks it has been fine so far [19:14] sborovkov: I don't believe we have defined a way for a snap to automatically promote itself from devmode to non-devmode on an upgrade [19:16] tyhicks: understood, thanks. Would using custom ld.so cause any apparmor issues? I have my application built in buildroot and for some reason it does not work without it. [19:16] tyhicks we discussed this with nessita and niemeyer. IIRC going from "production" to devmode would trigger an alert. The other way around wasn't covered but it should be sort of fine, right? [19:18] sergiusens: It should be fine as long as the user is using the snap as it was intended to be used by the snap packager [19:19] sergiusens: it would have the potential to break the user if, for example, he/she is specifying file paths that don't jive with confinement [19:19] that's not really something that we can protect against [19:19] tyhicks right, the "product" would need to be solid to move from devmode to production mode for starters [19:20] sergiusens, correct, the transition from strict to devmode is not automatic but devmode to strict is [19:21] oh, cool [19:22] sborovkov: regarding a custom ld.so> I think you should be able to get away with doing that within confinement since you're using --inhibit-cache [19:22] wait, so how does automatic transition from from devmode to strict can be triggered? [19:23] tyhicks: ok, thanks. [19:28] nessita: do you know how that automatic transition could be triggered? [19:29] sborovkov, when running snap refresh, if the store reports a newer revision, the snap will upgrade [19:29] and the newer revision can be strict (even if the reported revision is devmode) [19:30] nessita: thanks. [19:31] sborovkov, you are welcome! I hope my answer made sense [19:33] nessita: yes. I was just wondering because the application we are developing has some blockers on snappy side (/dev/vchiq inaccessible is the main thing). So was thinking if it would be possible to make images with snap installed in --devmode for alpha version and then later upgrade to proper mode without having people reflash the SD cards [19:34] sborovkov, right, in that scenario you would push a new revision of your snap without devmode, and you need to make sure you publish that snap in the alpha channel [19:34] sborovkov, then all your clients will get that revision on manuel or automatic "snap refresh" [19:37] nessita: so it's a flag in the store then? whether it's devmode or not? [19:41] sborovkov, nopes, is a flag inside each snap binary, so basically when you want to leave devmode and migrate to strict confinementn you need to do a new build and push to the store [19:41] sborovkov, and release that new build in the same channel as the one that had the devmode revision published [19:41] does that make sense? [19:42] Yeah, I just did not know about the flag (or how to set it when building the snap) . Since I though that it's enabled when installing using `--devmode`. [19:45] sborovkov, ah, right. So latest snapcraft allows you to define a confinement: devmode in your snapcraft.yaml that will make the confinement checks be treated as INFO instead of erroing [19:46] nessita: thanks again. Now everything's clear :-) [19:47] great! [19:54] Are config interfaces still gone? [20:23] This might be a 2.0.3->2.0.5 xenial-proposed regression. Not sure. https://bugs.launchpad.net/snappy/+bug/1587175 [20:23] Launchpad bug 1587175 in Snappy "snapd "cannot find mounted snap" error in 2.0.5" [Undecided,New]