[00:12] <liuxg> has anyone successfully deployed a python project with installed packages like django? I have a little problem here. thanks
[00:13] <liuxg> sergiusens, ping
[00:55] <genii> meh
[01:01] <Chipaca> jdstrand: tyhicks: so it turns out the perl locale warnings of config are because it uses aa-exec, which is perl. I misremembered about it being deeper in the stack :-)
[01:02] <Chipaca> i'm wondering if there's any situation where we want to run config with the user's locale, and coming up with "maybe?" :-(
[01:14] <liuxg> Chipaca, have you tried to install a python project onto snappy system?
[01:15] <Chipaca> liuxg: yes
[01:15] <Chipaca> liuxg: I put it into a snap
[01:15] <liuxg> Chipaca, I've got a problem https://bugs.launchpad.net/snapcraft/+bug/1523384. could you please help to confirm it is a bug?
[01:16] <liuxg> Chipaca, basically, I want to install some extra packages into the snap.
[01:16] <Chipaca> liuxg: looks like dholbach already confirmed it's a bug
[01:18] <liuxg> Chipaca, is there any alternative way to do it?
[01:19] <Chipaca> liuxg: well, I don't know why you end up with a symlink there
[01:19] <Chipaca> that seems wrong, for starters, but I don't know
[01:21] <liuxg> Chipaca, i do not know it either. I just simply use the tool to do it. In fact, it seems that dholbach also got the same problem for another project inside one of the examples of snapcraft.
[01:23] <liuxg> Chipaca, anyway, thanks for helping.
[01:25] <Chipaca> liuxg: normally i'd be able to look into this, but i'm only getting 5kB/s so can't realistically pull snapcraft i'm afraid
[07:41] <dholbach> good morning
[09:22] <mvo_> ogra_: is there anything with rpi2 rolling that I should be aware of? I created an image the other day and it does not boot. but might be a issue with pretty much anything (bad u-d-f, bad sd card). I will try again
[10:13] <JamesTait> Good morning all; happy Tuesday, and happy Pretend To Be A Time Traveler Day! 😃
[10:46] <ogra_> mvo_, not that i know of, mine works here and has autoupdate turned on
[10:46] <mvo_> ogra_: could you paste the commandline you used? maybe I did something wrong there
[10:47] <ogra_> ugh, that was a month ago or so :)
[10:47]  * ogra_ tries to get it together again :)
[10:49] <ogra_> sudo ubuntu-device-flash core rolling --channel edge --oem pi2.canonical/stable --enable-ssh --device raspi2_armhf --output raspi2-rolling.img
[10:49] <ogra_> (i didnt have to use /stable back then though)
[12:03] <mvo_> ogra_: works now, thank! the --device was missing
[12:04] <ogra_> ah, cool
[13:41] <kyrofa> dholbach, when you're able would you mind looking this over? https://github.com/ubuntu-core/snapcraft/pull/159
[13:47] <dholbach> kyrofa, sure
[13:49] <kyrofa> dholbach, it's a bit of a book I'm afraid, but I tried to make it relevant
[13:53] <dholbach> so far it reads just fine :)
[13:58] <kyrofa> dholbach, crap, I've never used snappy-remote. Does that just sideload via ssh?
[13:58] <dholbach> yes
[13:58] <dholbach> kyrofa, nice work - I didn't go through the example myself yet, but the text is just fine - I just added two small comments
[13:59] <kyrofa> dholbach, good ones, I'm fixing the snapcraft.yaml brief now, thank you! I'd like to be consistent with other docs regarding how snaps are sideloaded-- snappy install or snappy-remote, you tell me
[14:02] <dholbach> kyrofa, I just thought that snappy-remote might be easier
[14:03] <kyrofa> dholbach, alright I'll update that as well :)
[14:06] <renat> Hi all! It's renat from screenly. I have a question. Here: https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ documented that application should create /home/user/apps/<app-name>/<version>/ directory itself. But I'm getting permission denied when trying to create it from the application. How that directory should be created?
[14:15] <davidcalle> mvo_, ogra_ , do you happen to know? ^
[14:15] <mvo_> renat: sorry for this mistake in the docs, the dir is created automatically by the generated wrapper and is available via the SNAP_APP_USER_DATA_PATH environment variable
[14:16] <kyrofa> renat, checkout the /apps/bin/<your_executable_wrapper> and you'll see it created
[14:20] <davidcalle> mvo_: I've just fixed it in the doc, but can you check the other fields of this table?
[14:20] <renat> Thanks. Now I can see it in the wrapper script. But /home/user/apps directory is not created.
[14:22] <renat> Ahh... Now I can see it.
[14:22] <renat> In /home/bubntu/
[14:28] <kyrofa> renat, right, it uses $HOME so it's whatever user is running it
[14:29] <renat> kyrofa, thanks. Is it possible to extend /apps/bin/<executable_wrapper> script to create other directories too?
[14:30] <kyrofa> renat, such as?
[14:30] <kyrofa> renat, remember the security policies are pretty tight-- it creates pretty much everything you can access
[14:31] <kyrofa> renat, but the actual answer to your question is no. You'd have to either do it in the binary itself or create a wrapper script that creates the directories and then calls your binary
[14:32] <renat> kyrofa, We need to share very heavy files downloaded from the internet between 2 snaps. So I need to create a directory, for example /home/assets. I've already modified security-override file. But I still cannot create that directory from the application itself.
[14:37] <kyrofa> renat, getting apparmor denials?
[14:38] <renat> kyrofa, yes.
[14:38] <kyrofa> renat, can you paste in the denials as well as the generated profile?
[14:38] <kyrofa> renat, (pastebin, heh)
[14:39] <renat> kyrofa, Sure. Understood. 2 min
[14:41] <plars> elopio: so I was able to get a test binary built I think, with go test -c integration-tests/tests - but it's not clear what I could do with it
[14:41]  * ogra_ would also sugest to have someone from the security team to take a look at your role changes to make sure they are safe
[14:41] <plars> elopio: it doesn't seem to take any args on its own, or anything like that
[14:41] <plars> elopio: not even the ones we talked about yesterday
[14:46] <renat> kyrofa, sorry for disturbing you. Now I can see that files created after I used "bruteforce" security config. I will try to revert everything back and if I will get any issue - ask a question again.
[14:50] <elopio> plars: it does, pass -h to it.
[14:51] <elopio> it receives things like check.f, to filter.
[14:51] <kyrofa> renat, no need to apologize, you're why we're here!
[14:51] <plars> elopio: no, it just tries to run no matter what I pass to it
[14:51] <elopio> plars: ah, tries to run the init. That's the news I have for you.
[14:52] <elopio> plars: yesterday I found a command check.list to list the tests. That's the good news.
[14:52] <plars> elopio: oh? where does that init get defined?
[14:52] <elopio> the bad news is that we are wrapping the gocheck runner because it doesn't allow to change the results reporter.
[14:52] <plars> argh
[14:52] <elopio> so I can give you a quick fix today. Or a correct fix in a couple of weeks, because we need upstream changes.
[14:52] <kyrofa> renat, do note, though-- it sounds like you're trying to use Snappy in a way it was not intended (sharing dependencies between .snaps). If you could share some more information about what exactly you're trying to achieve there may be a better way
[14:53] <elopio> plars: also I need to revert this init change: https://github.com/ubuntu-core/snappy/blob/master/integration-tests/tests/base_test.go#L37
[14:53] <elopio> that one is easy, I'm starting with that now.
[14:55] <plars> elopio: ah, right. That looks like what it's trying to do
[14:55] <elopio> plars: it will accept check.f though, and run the tests that match after the init.
[15:12] <ogra_> mvo_, hmm, your sudo change seems to have broken the world
[15:18] <kyrofa> dholbach, I've updated that PR to address the points you raised
[15:31] <davmor2> ogra_: Don't try blaming mvo_ for your inability to use sudo correctly, you know it's your fault ;)
[15:33] <ogra_> mvo_, hmm, seems --ingroup can a) only be used once (only the first one is respected) and b) makes the specified group the default group for that user which c) omits creation of the "ubuntu" group
[15:33] <ogra_> mvo_, i'll split that into multiple adduser lines instead ...
[15:34] <mvo_> ogra_: thanks and *urgh*
[15:34] <mvo_> ogra_: sorry for that, I was not aware that adduser has these limitations, a bit disappointing
[15:35] <ogra_> its written in the manpage (i didnt know you can only use it once thouh)
[15:40] <ogra_> mvo_, oh, and btw, this group assignment is happening in the real /etc/group in the readonly fs so "ubuntu" is hardcoded there ... we might need to look if we can move the adm and sudo groups over to /var/lib/extrausers
[15:41] <ogra_> (i.e. if sudo and rsyslog actually get along with this)
[17:40] <elopio> kyrofa: build-packages installs them in the host, doesn't pull them into the snap.
[18:18] <kyrofa> elopio, thank you! Funny, I was just experimenting with that :)
[18:19] <elopio> I added a build-package, a stage-package and a node-package to my yaml. I'm getting a different error now, not sure if that's progress :)
[18:21] <kyrofa> elopio, hahaha
[18:26] <kyrofa> elopio, let's say I have a source tree that can build several things, and I want to create different .snaps out of it. How would I do that is the `snapcraft.yaml` needs to be at the root?
[18:26] <kyrofa> Just rename them as necessary?
[18:27] <elopio> kyrofa: yes, you can't currently.
[18:27] <elopio> I think we need to allow snapcraft.yamls in subdirectories, I send an email to the mailing list but didn't got many replies as I expected.
[18:28] <kyrofa> elopio, perhaps that comes back to your yaml-not-in-root question from ealier
[18:28] <kyrofa> Yeah
[18:28] <kyrofa> elopio,  I'll respond with that question, then ;)
[18:28] <elopio> maybe also supporting different yaml files in the same dir, but then the parts and install dirs need to be handled differently too.
[18:30] <kyrofa> Even something like make, use `snapcraft -f subdir/snapcraft.yaml`
[18:36] <elopio> kyrofa: yes, that's what I want.
[18:38] <elopio> the question would be where to put the part and step dirs. But well, those are details. We just need people to agree that's a good use case to support.
[18:41] <deenlee> this channel
[18:44] <kyrofa> elopio, agreed
[19:13] <camako> I have added the snappy ppa and did "apt-get update/upgrade", but I'm getting
[19:13] <camako> E: Unable to locate package snappy-tools
[19:14] <camako> when I do 'sudo apt-get install snappy-tools'
[19:14] <ogra_> what would "snappy-tools" be ?
[19:14] <camako> I'm on xenial (desktop). Anyone know what might be wrong?
[19:14] <ogra_> on xenial you dont need the PPA
[19:15] <ogra_> what do you want to do ?
[19:15] <camako> I'm assuming tools for snappy?
[19:15] <camako> I'm following a doc created by kgunn
[19:15] <ogra_> snappy-tools is a PPA name, not a package name
[19:15] <camako> ah ok.. he probably has it wrong in the doc
[19:16] <ogra_> anyway, what do you plan to do ?
[19:16] <camako> the end goal is to help him with bring up a mir server on snappy
[19:16] <camako> he was getting me started with snappy with some instructions
[19:17] <ogra_> well, install snapcraft ... that should get you everything you need installed
[19:17] <ogra_> (and technically snaps should nowadays only be built using it)
[19:17] <camako> further down in the instructions I see 'snapcraft assemble' so I guess you're right
[19:45] <kyrofa> elopio, I have two options: shell out to a binary, or try using past.translation to use python2 lib in python3. I don't like either. Thoughts?
[19:49] <elopio> kyrofa: can you start with why you need a python2 lib?
[19:49] <kyrofa> elopio, rosdep is a python2 binary, but it also has a python2 API
[19:50] <elopio> kyrofa: I think I'd go with the binary.
[19:51] <kyrofa> elopio, alright, thank you :)