[01:32] <blr> is there a way to use 'stage-packages' in isolation, i.e. I just want a 1-1 packaging of something already in the archive?
[02:13] <vir17> what are the available "plugins" for the yaml file?
[07:42] <dholbach> good morning
[08:13] <fgimenez> good morning
[08:29] <sturmflut> Good morning! Just out of curiosity: If I were to build my own self-hosted distribution based on Snappy Ubuntu Core, how would I do that?
[09:14] <noizer> Hi an short question.
[09:15] <noizer> i set some filesets into my part of the yaml file but they wont copy it to the part dir when im building my applicaiton
[09:41] <noizer> kyrofa_ Hi have question about the yaml file. I want to snap an python application but do you have a good example how i need to work to get the job done
[09:42] <JamesTait> Good morning all!  Happy Monday, and happy Freedom Day! 😃
[09:42] <noizer> Good morning :D
[10:20] <ogra_`> mvo, if you do "Chroot chroot "foo" >chroot/foo.txt then your later commands that run outside the chroot would need to use chroot/chroot/foo.txt (assuming the first command actually creates the dir )
[10:20] <ogra_`> ;)
[10:21] <ogra_`> hmm, or not :P
[10:21] <ogra_`> ignore that
[10:21] <mvo> ogra_`: I'm confused, aha, ok
[10:22] <ogra_`> trying to decypher the vivid build failures
[10:27] <ogra_> ah, but i wasnt to wrong :)
[10:27] <ogra_> we cd into the chroot dir before you try to cp from chroot/...
[10:27]  * ogra_ fixes
[10:28] <noizer> ogra_ Hi. just a short question im making an python application but what is the best way to copy alle the necessary files to a snap?
[10:31] <ogra_> noizer, http://paste.ubuntu.com/14848777/ that will get you a basic python interpreter installation
[10:32] <noizer> I understand that but the code how do I copy the files or does i neet to make a setup.py just lik pypi
[10:34] <ogra_> noizer, how about that http://paste.ubuntu.com/14848791/
[10:34] <ogra_> though i think you could also use a setup.py
[10:35] <ogra_> but i'd have to refer to the examples for that, never did that
[10:35] <noizer> ok can i copy a complete directory at one line?
[10:35] <ogra_> sure
[10:36] <ogra_> (at least in snapcraft 2.0 ... )
[10:37] <noizer> yea im using snapcraft 2.0
[10:37] <noizer> is the syntax like that ?:
[10:38] <noizer> ?
[10:38] <noizer> that:      /dir/ : bin/destinationdir/
[10:38] <ogra_> drop a few slashes :)
[10:39] <ogra_> http://paste.ubuntu.com/14848805/
[10:39] <ogra_> that would copy opt from my snap dir into the package
[10:48] <noizer> ogra_ thx for the help and the fast support all the time :D
[10:54] <ogra_> :)
[11:04] <ogra_> mvo, vivid rebuild running (FYI)
[11:04] <mvo> ogra_: yay, thanks
[11:29] <ogra_> ppisati, so for our dt problem on dragonboard ... i was wondering how hard it would be for you to cp it to apq8016-sbc-sdcard-boot.dtsi and add the one line patch, so we can use the sdcard version in snappy
[11:30] <ogra_> (i suspect fixing the little-kernel to initialize the controller differently will cause boot issues)
[12:25] <ppisati> ogra_: actually i'm chainloading uboot after LK
[12:25] <ppisati> ogra_: but probably mine is slightly more recent
[12:25] <ppisati> ogra_: look, i'm debugging a race in the wifi init
[12:25] <ogra_> ppisati, where did you get the lk ?
[12:25] <ppisati> ogra_: and if everything goes well i'll push another update out today
[12:25] <ppisati> ogra_: hold on
[12:28] <kyrofa> Good morning
[12:30] <ppisati> ogra_: http://pastebin.ubuntu.com/14849122/
[12:36] <ogra_> ppisati, hmm, i see you are using a newer u-boot ...
[12:36] <ogra_> where did you get the lk though ?
[12:38] <ogra_> i wonder why your alsa is messed up ... are you using the right DT ?
[12:39]  * ogra_ had alsa only fail with the msm8916-mtp file
[12:40] <asac> martintrojer_: hi!
[12:40] <ppisati> ogra_: it's all your stuff
[12:40] <ogra_> oh
[12:40] <ppisati> ogra_: i compiled a new uboot to add bootz support
[12:41] <ppisati> ogra_: and i'm using this dtb
[12:41] <ogra_> hmm, my uboot should have that
[12:41] <ppisati> ogra_: apq8016-sbc.dtb
[12:41] <martintrojer_> asac: 'lo
[12:41] <ppisati> ogra_: i'm going out for lunch, i can publish my uboot somewhere if you want
[12:41] <ogra_> ppisati, yeah, thats the correct one.... why do i see the mmc1 init error then ... weird
[12:42] <ogra_> ppisati, only the patch ... here is mine http://bazaar.launchpad.net/~ogra/+junk/dragonboard/view/head:/uboot.patch
[12:42] <ogra_> oh
[12:42] <ogra_> seems you are right, bootz isnt set there
[12:43] <ogra_> oh, wait ... because amr64 uses a special boot command
[12:44] <ogra_> right
[12:44] <ppisati> ogra_: sorry, can't find my patch ATM
[12:44] <ogra_> booti
[12:44] <ppisati> ogra_: here is the binary
[12:44] <ppisati> ogra_: http://people.canonical.com/~ppisati/dboard_uboot/u-boot.img
[12:44] <ogra_>  booti ${linux_addr} ${ramdisk_addr}:${initrd_size} ${fdt_add}
[12:44] <ppisati> ogra_: i'm they just fixed it upstream
[12:45] <ppisati> ogra_: i'm not using initrd either
[12:45] <ogra_> turning booti into bootz ?
[12:45] <ogra_> well, the initrd shouldnt have any influence regarding the mmc1 init error i would think
[12:46] <ppisati> ogra_: no,. i was wrong
[12:46] <ppisati> ogra_: i'm still using booti
[12:46] <ppisati> ogra_: it's probably just the updated version then
[12:47] <ogra_> ok, i'll check that
[12:47] <ogra_> would be good to get along without patched DT
[12:49]  * ppisati disappears for a bit
[12:58] <ogra_> mvo, do you have your all-snap build scripts somewhere ?
[12:59] <mvo> ogra_:  lp:~mvo/snappy/mksnap-os-kernel
[12:59] <ogra_> thx
[12:59] <mvo> ogra_: you probably need more stuff though, os snap, gadget snap
[12:59] <ogra_> yeah
[13:00] <mvo> ogra_: I can push you the ones I used for the previous image
[13:00] <ogra_> cool, thanks
[13:00] <mvo> ogra_: one sec, meeting right now
[13:00] <ogra_> no hurry
[13:40] <sergiusens> kyrofa, I made a better change https://github.com/ubuntu-core/snapcraft/pull/285/files
[13:40] <kyrofa> sergiusens, ah, just move it down?
[13:40] <kyrofa> sergiusens, good idea
[13:41] <kyrofa> sergiusens, though honestly, I refactored that in my PR anyway... what if I just move it down?
[13:41] <kyrofa> sergiusens, otherwise it'll just conflict
[13:41] <kyrofa> sergiusens, ha! Actually, I already did
[13:42] <kyrofa> sergiusens, https://github.com/ubuntu-core/snapcraft/pull/283/files#diff-0d5dc26743422dade0478e577247a141R124
[13:53] <kyrofa> niemeyer, sorry it took so long, but I managed to document the application launching process here: https://docs.google.com/document/d/1eaXHeFMEKMoWKFjmr5XMOW1vLywCjzoXd5SNJOUi_GE
[13:53] <kyrofa> niemeyer, mvo kindly filled in the u-c-l details (thanks mvo!)
[13:57] <noizer> ogra_ Hi i just installed nginx in my snap but does i need to make a service of it or not?
[13:57] <noizer> to get nginx started
[14:01] <sergiusens> kyrofa, sure
[14:01] <kyrofa> sergiusens, I have another STAGE_DIRECTORY-like suggestion: the source location when building the part. This particularly applies to the cmake plugin, which does an out-of-source build (as it should be, of course)
[14:01] <kyrofa> sergiusens, but when configuring e.g. mysql, if I want to use things included in the src I need to say -DWITH_X=path/to/src/X-dir
[14:04] <noizer> kyrofa can you look a moment to my question that i asked to ogra_ i think he is afk
[14:05] <kyrofa> noizer, yes, any service you want to run within your .snap must be declared as such
[14:09] <niemeyer> kyrofa: Thanks, let's talk this afternoon.. I need to step out to have lunch as we have the weekly Snappy meeting in a few minutes
[14:09] <kyrofa> niemeyer, no problem :)
[14:09] <noizer> kyrofa ok thx for the answer
[14:12] <ppisati> ogra_: i'm building a new kernel for the dboard410c, it contains a couple of fixes (one for ethernet on usb dongle and another for a wifi init race)
[14:12] <ppisati> ogra_: as soon as it's done i'll delete the previous one
[14:16] <noizer> kyrofa i want to remove an application but it won't work completely. here is some output: http://pastebin.com/CqZDAuxU
[14:19] <kyrofa> noizer, no clue what's happening there. It looks like you were in the middle of a commit when you built the snap?
[14:19] <ogra_> ppisati, ok
[14:20] <noizer> kyrofa not realy
[14:20] <noizer> but that was installed previously xD
[14:25] <jdstrand> beuno: hi! two questions: 1) do you have any objections with me doing some big code cleanups to the review tools with the snap.yaml updates I'll be working on (think, starting fairly anew with snap.yaml) and 2) is it cool for me to force that if you are a squashfs that you must use snap.yaml?
[14:27] <beuno> jdstrand, +1 and +1
[14:27] <Guest5410> jdstrand, FWIW, we have tests in the store to enforce that.
[14:28]  * Guest5410 sighs
[14:31] <JamesTait> Finally!
[14:34] <JamesTait> jdstrand, while you're working on that, IIUC readme.md is no longer required (instead we take the summary and description properties from snap.yaml).
[14:35] <JamesTait> mvo and/or sergiusens - feel free to correct me. 😉
[14:35] <sergiusens> JamesTait, jdstrand that is indeed correct
[14:36] <sergiusens> jdstrand, I say +1 to squashfs implies snap.yaml (but not too tightly coupled in the code)
[14:39] <jdstrand> JamesTait: yes-- I will be using the snap.yaml spec to implement this
[14:40] <jdstrand> sergiusens: re coupling-- well, no more so than it already is. we said squashfs signifies 16.04. basically, I'd like to say no package.yaml in 16.04 as well right away if I can get away with that
[14:40] <JamesTait> jdstrand, I assumed as much, just wanted to make sure it was on your radar. 😉
[14:40] <jdstrand> JamesTait: appreciated :)
[14:41] <mvo> jdstrand: +1 for now package.yaml in 16.04
[14:44] <sergiusens> jdstrand, right, just thinking about 16.10 and squashfs having a different snap.yaml
[14:44] <beuno> there will be no 16.10!
[14:44] <beuno> rolling until 18.04!
[14:44] <sergiusens> beuno, well, rolling
[15:12] <noizer> kyrofa what did I wrong. He installed flask but not tornado and yaml as library for python http://pastebin.com/xiXE78Sm
[15:17] <kyrofa> noizer, huh?
[15:17] <kyrofa> noizer, I don't see a problem there-- what went wrong?
[15:17] <noizer> when im installing my application and then i look in my site-packages there isn't tornado installed
[15:17] <noizer> :s
[15:18] <kyrofa> noizer, do you have any errors when creating the snap?
[15:20] <noizer> no
[15:20] <noizer> wait i will try something again
[15:21] <noizer> he is now building the snap again a moment please
[15:32] <noizer> kyrofa got an error verry strange : Parts 'flask' and 'yaml' have the following file paths in common which have different contents:
[15:33] <noizer> so it was an old snap file that i had installed :s
[15:33] <kyrofa> noizer, please pastebin the build log
[15:35] <noizer> kyrofa http://pastebin.com/fpJP1AL1
[15:36] <sergiusens> elopio, should I give you time to look at https://github.com/ubuntu-core/snapcraft/pull/282 ?
[15:37] <elopio> sergiusens: wow, that's big. I'm in a meeting with Federico. If you are happy with kyrofa's review, merge it.
[15:38] <elopio> I'll take a look afterwards. Seemed good with my quick glance.
[15:39] <sergiusens> elopio, yeah, I added lots of tests ;-)
[15:43] <jdstrand> mvo: oh, btw, while I am going to focus on snap.yaml stuff first I think, I did want to let you know that with a patched squashfs I was able to verify an amd64 snap on a powerpc machine (so I'm not worried about endianess any more). need to work out a few other details, but if you were worried, don't be at this point
[15:45] <noizer> kyrofa do you have any solution ps I'm using snapcraft 2.0
[15:49] <elopio> fgimenez: I was trying to say that this create cloud image job doesn't take a lot of time.
[15:49] <elopio> could we create one image per job, and then delete it?
[15:49] <elopio> not per job, per test execution.
[15:51] <fgimenez> elopio, we need to create the image, convert to qcow2 and upload to glance, less than 5min i think, but each image is valid until a new version is created
[15:51] <elopio> fgimenez: right, that would be a lot of wasted resources when there are no changes.
[15:52] <elopio> ok, lets figure out how to subscribe to new versions.
[15:52] <elopio> fgimenez: do you know if there's a good plugin for jenkins that keeps polling?
[15:53] <fgimenez> elopio, yes urltrigger, we are using it for the image creation jobs
[15:53] <fgimenez> elopio, https://wiki.jenkins-ci.org/display/JENKINS/URLTrigger+Plugin
[15:53] <noizer> kyrofa the error is at line 592
[15:54] <elopio> fgimenez: great, it lets you even check the json response. I'll use it.
[15:55] <kyrofa> noizer, ah, it seems that's bug #1531570
[15:57] <noizer> kyrofa is there an solution for that?
[15:58] <kyrofa> noizer, you can work around it as I mentioned in the comment, or you can try putting them all in one part using requirements.txt perhaps?
[15:58] <noizer> kyrofa or install them manualy in an other os and copy them to the correct dir
[16:00] <kyrofa> noizer, you might try the requirements.txt first, if that works for you
[16:00] <noizer> kyrofa is there an example of that?
[16:01] <kyrofa> noizer, not in snapcraft, it's a pip thing
[16:01] <kyrofa> noizer, https://pip.readthedocs.org/en/1.1/requirements.html might be helpful
[16:02] <pindonga> kyrofa, re: proper login on snapcraft... I just became aware snappy itself has login support as well
[16:02] <pindonga> so I think you should attempt to mimick what's being done there
[16:02] <pindonga> looked at the code and looks quite right to me
[16:02] <kyrofa> pindonga, regarding the OTP etc.?
[16:02] <pindonga> yes
[16:02] <kyrofa> pindonga, excellent, we'll check it out! Thank you :)
[16:03] <elopio> fgimenez: https://search.apps.ubuntu.com/api/v1/package/ubuntu-core.canonical
[16:03] <pindonga> kyrofa, it might even make sense trying to read the config file written by snappy (so to avoid having multiple config files)
[16:04] <kyrofa> pindonga, without having looked at it, why does snappy have a login option?
[16:04] <pindonga> kyrofa, there are certain use cases that need it, eg downloading private packages
[16:04] <kyrofa> pindonga, ahh
[16:05] <kyrofa> pindonga, that makes sense then
[16:06] <fgimenez> elopio, great! thx, that's all we need, the only thing missing is the version string to assign to the image, it should be compatible with our current schema (plain numbers from system-image) and the schema from official images (dates as in 20160129)
[16:06] <lool> LefterisJP: hey!
[16:08] <elopio> fgimenez: if we are listening to the three snaps, why don't we just use a timestamp?
[16:08] <elopio> I mean one timestamp.
[16:09] <LefterisJP> lool: hey :)
[16:10] <fgimenez> elopio, we need to be able to know from snappy-cloud-image if we need to create a new image, we need some hint in the latest image name to be able to compare with the info from the snaps
[16:11] <fgimenez> elopio, now the source is system-image, and the cloud images have the same version number that the images have there, so we can easily compare both
[16:12] <elopio> fgimenez: but system-image is going away. So, we put three url triggers, one for each snap. When anyone fires, we create a new image, and put a timestamp on it.
[16:12] <elopio> I might be missing something of course, because I don't get why we need to compare.
[16:15] <fgimenez> elopio, yes, we could rely in the external trigger, now we are using it just for preventing the jobs to be executed by cron, the job itself checks again if we should create the instance or not
[16:16] <elopio> fgimenez: got it. Well, I won't mind to collect the three versions and build a name from that. Whatever you prefer.
[16:17] <mvo> jdstrand: \o/ thanks, that is great news
[16:17] <elopio> fgimenez: last thing I wanted to talk today is about gocheck.
[16:17] <jdstrand> np
[16:18] <elopio> fgimenez: let's see how niemeyer resolves it, and if there's no progress at the end of the week I can propose again the ugly hack to get the list command for plars and team.
[16:19] <fgimenez> elopio, ok, let me know if you need any help with that
[16:20] <elopio> fgimenez: well, if you have a better implementation in mind and want to give it a go sending it upstream, I won't stop you. I wouldn't ask that of you either :)
[16:22] <beuno> JamesTait, so, are you changing crt to not require readme.md for 16.04 snaps?
[16:25] <sergiusens> beuno, mvo just triple confirming; I can land skills for snapcraft? Is there an OS already built?
[16:25] <sergiusens> built/uploaded to the store
[16:26] <JamesTait> beuno, I can do, if it won't interfere with what jdstrand is working on.
[16:26] <beuno> sergiusens, I don't know. Will it affect the store in any way?
[16:28] <sergiusens> beuno, well; only in the sense that everything might be denied or marked invalid
[16:29] <beuno> sergiusens, if you get me a snap built with skills, I can run it through and check for you
[16:29] <sergiusens> beuno, sounds good
[16:29] <beuno> sergiusens, in all likelyhood, it'll be click-reviewers-tools
[16:29] <beuno> so you can easily check locally as well
[16:29] <jdstrand> JamesTait (and beuno): it would be incorporated in my larger work. if needed, JamesTait or I can make a quick change
[16:30] <JamesTait> jdstrand, I realise it's still early days, but do you have a sense of ETA for the rework yet?
[16:30] <jdstrand> sergiusens, beuno: I can say for sure the review tools won't like it
[16:30] <jdstrand> JamesTait: I imagine this week. I am wholly focused on it
[16:30] <JamesTait> Ack, thanks.
[16:31] <sergiusens> jdstrand, if the error does not prevent manually putting into the store I'm fine
[16:31] <sergiusens> putting/approving
[16:31] <jdstrand> sergiusens: it would be no worse than other squashfs. if you give me a snap I can make super sure for you
[16:32] <sergiusens> jdstrand, k, thanks
[16:32] <JamesTait> jdstrand, just an additional heads-up: we've been discussing in OLS "outsourcing" the package metadata extraction wholly to click-reviewers-tools and having it return metadata in a standardised format, rather than having the whole click/snappy1.0/snappy2.0 detection logic in the store as well.
[16:33] <JamesTait> jdstrand, letting you know just in case it's a really bad idea or makes things much more difficult.
[16:33] <jdstrand> JamesTait: so, you give a snap to the review tools in some way, and it spits back something the store can consume?
[16:34] <JamesTait> jdstrand, exactly.
[16:34] <jdstrand> JamesTait: I think that is a really good idea
[16:34] <jdstrand> keep this stuff in one place
[16:34] <JamesTait> Excellent. ☺
[16:34] <JamesTait> I'll find out whose idea it was and route karma/beers appropriately. 😝
[16:35] <jdstrand> I imagine the review tools side would loop back to me (which is fine)
[16:36] <mvo> sergiusens: there is no updated OS snap in the store yet but I will upload one now that the store is open
[16:38] <sergiusens> mvo, great; do we have the opening/closing hours for the store? I hope it is not like the starbucks photo ogra_ posted on g+ :-) https://plus.google.com/+OliverGrawert/posts/fje7cEH4oa2
[16:38] <ogra_> haha
[16:38] <ogra_> wow
[16:39] <ogra_> i just wiped the .ics files from my phone and clicked "sync" in the calendar app ....
[16:39]  * ogra_ guesses he shouldnt recommend doing that to anyone .... flushed my whole gcal at google :P
[16:40] <wigglewo1> Does anyone know of there are email posted somewhere that say snappy updates are available?
[16:41] <wigglewo1> posted or emailed to general public
[16:42] <ogra_> what kind of updates ?
[16:42] <ogra_> to the snappy binary ?
[16:42] <ogra_> (OS updates happen automatically on all images that are supported)
[16:43] <ogra_> updates to the stable images are usually announced on the snappy-devel mailing list after they went out
[16:43] <wigglewo1> i know that but if the automatic updates are diabled then how does one find out about updates?
[16:44] <ogra_> well, if you run stable you m8ight want to follow that ML
[16:44] <wigglewo1> what is ML
[16:44] <ogra_> if you use any rolling channel ... well, you should check regulary by simply running "sudo snappy update ubuntu-core"
[16:44] <ogra_> mailing list
[16:45] <wigglewo1> thanks where do i find the mailing list
[16:45] <ogra_> https://lists.ubuntu.com/mailman/listinfo/snappy-devel
[16:46] <wigglewo1> thank you
[16:46] <ogra_> :)
[16:47] <wigglewo1> are you familiar with apticron? and does that work differently?
[16:48] <ogra_> no, never heard of apticron
[16:48] <wigglewo1> ok thanks
[16:49] <kyrofa> elopio, regarding the INFOs from requests-- are you suggesting I move that line into log.py? Or do something different altogether?
[16:50] <elopio> kyrofa: yes, you can put this:
[16:50] <elopio> logging.getLogger("requests").setLevel(logging.WARNING)
[16:50] <elopio> in the log.configure.
[16:50] <kyrofa> elopio, ah, that will be much nicer, I'm glad you caught that. I've never noticed log.py before, heh
[16:55] <sergiusens> JamesTait, beuno jdstrand http://people.canonical.com/~sergiusens/snappy/shout_0.52.0_amd64.snap there's a skills snap
[16:55] <JamesTait> Handy, thanks sergiusens!
[16:59] <sergiusens> elopio, have time for a quick hangout?
[17:00] <Chipaca> pitti, got a systemd ordering/dependency question for you
[17:00] <Chipaca> pitti, when would be a good time?
[17:00] <elopio> sergiusens: sure. I have a sore throat, so if it's not quick, we'll have to come back to text chatting. Snapcraft daily channel?
[17:01] <sergiusens> elopio, yeah
[17:01] <sergiusens> elopio, well this https://plus.google.com/hangouts/_/canonical.com/snapcraft
[17:08] <Chipaca> pitti, basically we have a bunch of services depending on a target, and that target can take arbitrarily long to load. the services are being wanted by multi-user, but we don't want to block multi-user on these
[17:08] <pitti> Chipaca: just ask, that's easier :) (drive-by, dinner now, but will come back for a bit later tonight)
[17:09] <pitti> Chipaca: well, that sounds like a circular dependency then -- you must break it somewhere :)
[17:10] <pitti> Chipaca: without knowing any details, conceptually they probably shouldn't be wanted by multi-user then?
[17:10] <Chipaca> pitti, ah, maybe i didn't explain properly. go have dinner, i'll try to explain better in a bit
[17:14] <jdstrand> sergiusens (fyi beuno and JamesTait): this is what the store should see with the skills snap: http://paste.ubuntu.com/14850654/. so 'yes' no worse than squashfs, readme.md, etc
[17:18] <sergiusens> jdstrand, that's good enough for me.
[17:18] <jdstrand> sergiusens: the review tools in the archive is oddly a little more grumpy with that over a snapcraft 2.0.1 build snap
[17:19] <sergiusens> jdstrand, probably because 2.0.1 includes a package.yaml and readme.md for backwards compat; but already uses 'apps' instead of "services" and "binaries"
[17:19] <jdstrand> sergiusens: don't you run the review tools automatically? if so, I should figure that out now and update the archive
[17:19] <jdstrand> oh yes, that would make sense
[17:19] <jdstrand> if no package.yaml, it will think it is a click
[17:20] <jdstrand> ok, let me look at that MP from earlier today and upload that to xenial
[17:20] <jdstrand> sergiusens: go ahead with your merge/landing/etc
[17:20] <sergiusens> mvo, did you push already; or asked differently; does `snappy update` work on amd64?
[17:21] <sergiusens> jdstrand, thanks, just waiting on OS support to make sure all the pieces work :-)
[17:23] <noizer> kyrofa Is it possible to enter the container to test some things?
[17:23] <kyrofa> sergiusens, should I --include-binaries in the copy-package?
[17:23] <kyrofa> sergiusens, not super clear on what that does :P
[17:23] <kyrofa> noizer, what container?
[17:24] <noizer> the snap so i can do some python scripting for do some test
[17:24] <noizer> kyrofa
[17:26] <kyrofa> noizer, running xenial (rolling), right?
[17:26] <noizer> kyrofa yes
[17:27] <sergiusens> kyrofa, yes you should
[17:27] <kyrofa> noizer, so first of all, the word "container" indicates something at least somewhat virtualized, e.g. lxc, etc. Snaps don't run in a container, they're just very confined. But to actually answer your question, there's no way to modify the squashfs mount, so you'd need to make some overlayfs games to do that
[17:28] <kyrofa> s/need to make/need to play/
[17:28] <kyrofa> sergiusens, otherwise it'd what... grab the source package only?
[17:28] <sergiusens> kyrofa, yeah, and rebuild
[17:29] <kyrofa> sergiusens, very good
[17:33] <Chipaca> kyrofa, maybe 'snappy shell' is what noizer is looking for?
[17:35] <kyrofa> Chipaca, perhaps, I don't have any experience with it (it doesn't show up as an option for me, must be new?)
[17:35] <ogra_> sudo snappy enable-classic
[17:35] <ogra_> snappy shell classic
[17:35] <ogra_> ;)
[17:35] <kyrofa> Ohh
[17:35] <Chipaca> yes, but, snappy shell potato
[17:36] <Chipaca> gives you a shell in the security context of potato
[17:36] <kyrofa> Chipaca, interesting. But you still can't modify the install snap, right?
[17:36] <kyrofa> installed*
[17:36] <Chipaca> right. But you can 'try some things'
[17:36] <kyrofa> Chipaca, hey, I learned something new. Thanks for that!
[17:37] <ogra_> you can also spt-get install snapcraft ;)
[17:37] <ogra_> and build your snaps in there
[17:37] <Chipaca> ssh, don't tell people about spt-get yet
[17:37] <ogra_> *apt
[17:37] <ogra_> haha
[17:37] <kyrofa> ogra_, yeah I've used classic, I just didn't realize snappy shell was a more generic command
[17:38] <Chipaca> pitti, so: snappy-wait4network.service is a oneshot that runs and just waits for network. If a snap is installed that has a service with an external port, then that service is made to come after wait4network, and wanted by multi-user. If network never comes up, multi-user is never reached.
[17:39] <Chipaca> pitti, that last little detail is purportedly a bug :-)
[17:39] <Chipaca> pitti, basically we want the whole tree under wait4network to be "ignored", as far as reaching multi-user is concerned
[17:40] <ogra_> well, you want loopback
[17:40] <Chipaca> wait4network waits for a route
[17:40] <ogra_> is that blocked by that service too ?
[17:40] <ogra_> ah
[17:40] <ogra_> right, thats the one that never finishes if we have auto in /e/n/i with no network cable attached
[17:41] <Chipaca> and a snap with a service with an external port installed
[17:42] <ogra_> does systemd not provide a simply way for timingt out a job ?
[17:42] <ogra_> *simple
[17:42] <ogra_> (like a timeout option :) ))
[17:43] <Chipaca> yes
[17:43] <Chipaca> but we don't want it to timeout
[17:43] <Chipaca> (and it'd be in the minutes, this timeout)
[17:44] <ogra_> hmm
[17:44] <ogra_> what if i have a service i want to use through loopback only ? i suppose it would wait forever if there is no real network then ?=
[17:45] <ogra_> (if assigning a port also makes it depend on that service file)
[17:45] <Chipaca> ogra_, then you don't define an external port for it
[17:45] <Chipaca> ogra_, there are internal ports
[17:45] <ogra_> oh, i thought they were dropped
[17:45] <Chipaca> they will be, once we move to caps
[17:45] <ogra_> right
[17:45] <Chipaca> the problem will remain :-)
[17:45] <ogra_> indeed :)
[17:46] <sergiusens> jdstrand, fwiw, the store accepted my app (failed reviews though)  https://myapps.developer.ubuntu.com/dev/click-apps/3989/rev/4/
[17:46] <Chipaca> ogra_, hence head scratching, and pitti invoking
[17:46] <ogra_> yeah
[17:47] <Chipaca> i'd go ask in #systemd but last time i went they said we should have systemd in initrd
[17:47] <Chipaca> which i agree on in principle, but in practice i'm not in a hurry to get there
[17:47] <sergiusens> ogra_, kyrofa, Chipaca what noizer want is the yet to be made snappy try
[17:47] <ogra_> yeah,
[17:47] <kyrofa> sergiusens, yeah, I did know that one :P
[17:48] <Chipaca> sergiusens, the tricky bit is the snappy except
[17:48] <Chipaca> i'll let myself out
[17:48] <kyrofa> Chipaca, the finally is really terrible
[17:48] <sergiusens> Chipaca, because it should be catch? :-)
[17:49] <jdstrand> sergiusens: cool. do you need me to accept it?
[17:49] <sergiusens> jdstrand, if you want to, sure (it's the same snap, except I uploaded with the to be release snapcraft upload command)
[17:50] <sergiusens> *d
[17:50]  * sergiusens is still waiting for ubuntu-core to finish downloading
[17:51] <Chipaca> sergiusens, kyrofa, i think we all should get each other big "NERD" mugs
[17:51] <kyrofa> Hahaha
[17:51] <ogra_> you dont have one yet ?!?
[17:53] <jdstrand> sergiusens: if you request a manual review, I'll approve it
[17:53] <jdstrand> sergiusens: fyi, uploaded review tools 0.36 to xenial so it won't be so grumpy
[18:01] <sergiusens> jdstrand, :-)
[18:01] <sergiusens> jdstrand, we plan on releasing snapcraft 2.1 today as well
[18:01] <sergiusens> jdstrand, and this is our next milestone fwiw https://launchpad.net/snapcraft/+milestone/2.2
[18:03] <jdstrand> sergiusens: cool
[18:03] <jdstrand> sergiusens: fyi, accepted
[18:56] <sergiusens> mvo, updating does not work in rolling in case it was unknown to you
[18:56] <kyrofa> sergiusens, 1.0.1 release went smoothly. Thanks for answering my questions :)
[18:57] <sergiusens> kyrofa, nice
[18:58] <kyrofa> sergiusens, is https://github.com/ubuntu-core/snapcraft/pull/283 good to go, then?
[18:59] <sergiusens> kyrofa, I am just missing a live upload; unless you have tried that yourself
[18:59] <sergiusens> I will trust you ;-)
[18:59] <kyrofa> sergiusens, only to staging
[18:59] <kyrofa> sergiusens, but I can do live
[19:00] <sergiusens> kyrofa, that should be good enough; don't you want to try against production
[19:00] <sergiusens> kyrofa, one of the examples maybe
[19:03] <kyrofa> sergiusens, verified-- works great :)
[19:05] <sergiusens> kyrofa, the minute I press merge, I remember I didn't check the commit message :-P
[19:05] <sergiusens> kyrofa, is this mentioned https://bugs.launchpad.net/snapcraft/+bug/1539814 or should I  just dup?
[19:06] <kyrofa> sergiusens, it is :)
[19:06] <kyrofa> sergiusens, question is, did I do it right? I wasn't sure whether to do LP: #1, #2 or use two different LP lines
[19:06] <kyrofa> sergiusens, I went with two
[19:06] <sergiusens> kyrofa, I think you did it right
[19:06] <sergiusens> kyrofa, we'll see ;-)
[19:07] <kyrofa> sergiusens, gbp dch picks it up both ways, but one way it's (LP: #1, #2) and the other it's (LP: #1)(LP: #2)
[19:09] <kyrofa> sergiusens, for my future reference, if I need to do something asynchronously in python, is multiprocessing better than multithreading?
[19:09] <kyrofa> sergiusens, the way I solved the progress bar problem was driven completely by my experience in C++
[19:10] <kyrofa> sergiusens, but your comments from earlier lead me to believe there's a better way to do that in python?
[19:12] <sergiusens> kyrofa, multithreading is not that good in python; Chipaca might spank you :-P
[19:12]  * kyrofa runs away from Chipaca
[19:39] <sergiusens> zyga, any idea how to test if my migration-skill built snaps actually work?
[19:40] <sergiusens> zyga, or can you try and see if 'shout.sergiusens' on the store works?
[19:51] <zyga> sergiusens: I'll check, mvo merged this yesterday
[19:53] <sergiusens> zyga, yeah, but I have no idea to know if it is doing the right thing; I copied a snappy binary over but ubuntu-core-launcher fails to aa_*
[19:55] <pitti> Chipaca: re
[19:56] <pitti> Chipaca: snappy-wait4network.service sounds very similar to network-online.target
[19:56] <kyrofa> sergiusens, why does the ROS example have all the exclusions now
[19:56] <kyrofa> ?
[19:56] <pitti> Chipaca: normally multi-user.target does/should not depend on network-online.target, unless you have things like /var or /home on NFS
[19:57] <pitti> Chipaca: so if you want snappy-wait4network.service to not block multi-user.target, then you can't make it an one-shot that is  "starting" forever
[19:57] <kyrofa> sergiusens, I seem to remember it having to do with shebang stuff
[19:57] <pitti> Chipaca: option 1 is to make it daemon-like, i. e. not "oneshot" -- then it'll just block m-u for as long as it takes to start that listening thingy
[19:57] <sergiusens> kyrofa, so it doesn't conflict with what catkin brings in
[19:58] <pitti> Chipaca: option 2 is to make snappy-wait4network.service WantedBy=network-online.target instead of m-u.target
[19:58] <sergiusens> kyrofa, and yeah, it is related; but I eventually want to get rid of the file migration thing
[19:58] <kyrofa> sergiusens, didn't we fix that with the always-link change?
[19:58] <sergiusens> kyrofa, no; but we also still remove useless stuff for a snap, so it should be fine
[19:58] <pitti> ogra_: sure, units time out starting/stopping by default after 90s (units can tweak or disable that, but most don't)
[20:01] <kyrofa> sergiusens, ohhh, the roscore plugin......
[20:01] <kyrofa> sergiusens, okay good. This'll clean up nicely then
[20:01] <sergiusens> kyrofa, yeah
[20:06] <elopio> I'm going to have lunch.
[20:07] <elopio> sergiusens: if you look for me to give you a hand with the release and I don't reply, insist pinging on telegram. I'm not feeling so well and might end up sleeping deeply.
[20:07] <elopio> bbl
[20:08] <sergiusens> elopio, no worries, I'm still debating if I should merge the migration skill stuff as there isn't a working image yet
[20:14] <kyrofa> sergiusens, that would indeed make it difficult to test other changes built on top of master if it merged...
[20:21] <kyrofa> Chipaca, what kind of parameters does `snappy shell` accept?
[20:21] <kyrofa> Chipaca, oh you're probably eating or something huh
[20:21] <kyrofa> Chipaca, you can ignore me :)
[20:28] <sergiusens> lol
[20:28] <sergiusens> kyrofa, yeah, that is why I didn't merge it
[20:29] <sergiusens> just hoping mvo can answer when he gets back
[20:43] <kyrofa> sergiusens, what incantation of u-d-f will create a rolling all-snaps amd64 image nowadays? I just realized the canonistack version is too old
[20:46] <sergiusens> kyrofa, welcome to my world of not knowing and being blocked most of the evening :-P
[20:59] <wigglewo1> hello - looking for direction on how to publish a snap to the snappy store - are there published instructions?
[21:16] <rickspencer3> wigglewo1, well ...
[21:16] <rickspencer3> the web page is pretty self-explanatory, I think
[21:16] <rickspencer3> wigglewo1,  have you looked at https://myapps.developer.ubuntu.com
[21:16] <rickspencer3> ?
[21:17] <rickspencer3> once you sign in, click on Ubuntu Core at the top
[21:17] <rickspencer3> and then fill in the form
[22:40] <bdmurray> My beaglebone never seems to boot snappy. I've followed the steps at https://developer.ubuntu.com/en/snappy/start/#try-beaglebone although I didn't "remove the bootloader available in the eMMC" partition.
[22:45] <zyga> bdmurray: hold the user button
[22:45] <zyga> bdmurray: and do remove the other bootloader as otherwise you will never boot into the SD card
[22:46] <bdmurray> zyga: hold the user button during boot?
[22:51] <zyga> bdmurray: yes
[22:51] <zyga> bdmurray: it forces the SoC to use SD card to boot
[22:52] <bdmurray> and then you use dd on the device to remove the bootloader? the instructions don't make that clear.
[22:53] <zyga> bdmurray: you can do that from uboot or after snappy boots
[22:54] <zyga> bdmurray: AFAIR I used uboot's command to erace the mmc
[22:54] <zyga> erase*
[22:55] <bdmurray> zyga: okay, thanks I'm working on a snap of some python software and when I run it on the bbb I get a bad interpreter message.
[22:56] <bdmurray> https://paste.ubuntu.com/14852967/
[23:00] <zyga> bdmurray: did you use snapcraft?
[23:00] <zyga> bdmurray: you can use snapcraft to build a snap with python
[23:01] <bdmurray> zyga: yes, i did
[23:01] <zyga> bdmurray: there are existing examples that do just that in snapcraft source
[23:01] <zyga> bdmurray: try building one of them and ensure it works
[23:01] <zyga> bdmurray: if that doesn't work, ask sergiusens
[23:01] <zyga> bdmurray: note that beagle is no longer officially supported
[23:02] <zyga> bdmurray: though I bet that python won't care here, the image you might be using might be out of date
[23:02] <bdmurray> its still listed at the developer portal
[23:03] <zyga> bdmurray: it is supported by the community, in practice it might lag behind our officially supported platforms, especially now when we are developing at a very rapid pace
[23:03] <zyga> bdmurray: I have two beagles in my office, both running snappy, though I'm using raspberry pi for my daily development now
[23:10] <bdmurray> Is there a way to get snapcraft to use my local mirror?
[23:11] <zyga> bdmurray: perhaps but I don't know the details, ask sergiusens
[23:15] <sergiusens> bdmurray, USE_LOCAL_SOURCES=1 and python is included in the snap, you need to build on the arch you want to target
[23:52] <bdmurray> sergiusens: How do you recommend building on armhf?