#snappy 2016-02-01 <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? <vir17> what are the available "plugins" for the yaml file? <dholbach> good morning <fgimenez> good morning <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? <noizer> Hi an short question. <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 <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 <JamesTait> Good morning all! Happy Monday, and happy Freedom Day! ð <noizer> Good morning :D <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 ) <ogra_`> ;) <ogra_`> hmm, or not :P <ogra_`> ignore that <mvo> ogra_`: I'm confused, aha, ok <ogra_`> trying to decypher the vivid build failures <ogra_> ah, but i wasnt to wrong :) <ogra_> we cd into the chroot dir before you try to cp from chroot/... * ogra_ fixes <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? <ogra_> noizer, http://paste.ubuntu.com/14848777/ that will get you a basic python interpreter installation <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 <ogra_> noizer, how about that http://paste.ubuntu.com/14848791/ <ogra_> though i think you could also use a setup.py <ogra_> but i'd have to refer to the examples for that, never did that <noizer> ok can i copy a complete directory at one line? <ogra_> sure <ogra_> (at least in snapcraft 2.0 ... ) <noizer> yea im using snapcraft 2.0 <noizer> is the syntax like that ?: <noizer> ? <noizer> that: /dir/ : bin/destinationdir/ <ogra_> drop a few slashes :) <ogra_> http://paste.ubuntu.com/14848805/ <ogra_> that would copy opt from my snap dir into the package <noizer> ogra_ thx for the help and the fast support all the time :D <ogra_> :) <ogra_> mvo, vivid rebuild running (FYI) <mvo> ogra_: yay, thanks <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 <ogra_> (i suspect fixing the little-kernel to initialize the controller differently will cause boot issues) <ppisati> ogra_: actually i'm chainloading uboot after LK <ppisati> ogra_: but probably mine is slightly more recent <ppisati> ogra_: look, i'm debugging a race in the wifi init <ogra_> ppisati, where did you get the lk ? <ppisati> ogra_: and if everything goes well i'll push another update out today <ppisati> ogra_: hold on <kyrofa> Good morning <ppisati> ogra_: http://pastebin.ubuntu.com/14849122/ <ogra_> ppisati, hmm, i see you are using a newer u-boot ... <ogra_> where did you get the lk though ? <ogra_> i wonder why your alsa is messed up ... are you using the right DT ? * ogra_ had alsa only fail with the msm8916-mtp file <asac> martintrojer_: hi! <ppisati> ogra_: it's all your stuff <ogra_> oh <ppisati> ogra_: i compiled a new uboot to add bootz support <ppisati> ogra_: and i'm using this dtb <ogra_> hmm, my uboot should have that <ppisati> ogra_: apq8016-sbc.dtb <martintrojer_> asac: 'lo <ppisati> ogra_: i'm going out for lunch, i can publish my uboot somewhere if you want <ogra_> ppisati, yeah, thats the correct one.... why do i see the mmc1 init error then ... weird <ogra_> ppisati, only the patch ... here is mine http://bazaar.launchpad.net/~ogra/+junk/dragonboard/view/head:/uboot.patch <ogra_> oh <ogra_> seems you are right, bootz isnt set there <ogra_> oh, wait ... because amr64 uses a special boot command <ogra_> right <ppisati> ogra_: sorry, can't find my patch ATM <ogra_> booti <ppisati> ogra_: here is the binary <ppisati> ogra_: http://people.canonical.com/~ppisati/dboard_uboot/u-boot.img <ogra_> booti ${linux_addr} ${ramdisk_addr}:${initrd_size} ${fdt_add} <ppisati> ogra_: i'm they just fixed it upstream <ppisati> ogra_: i'm not using initrd either <ogra_> turning booti into bootz ? <ogra_> well, the initrd shouldnt have any influence regarding the mmc1 init error i would think <ppisati> ogra_: no,. i was wrong <ppisati> ogra_: i'm still using booti <ppisati> ogra_: it's probably just the updated version then <ogra_> ok, i'll check that <ogra_> would be good to get along without patched DT * ppisati disappears for a bit <ogra_> mvo, do you have your all-snap build scripts somewhere ? <mvo> ogra_: lp:~mvo/snappy/mksnap-os-kernel <ogra_> thx <mvo> ogra_: you probably need more stuff though, os snap, gadget snap <ogra_> yeah <mvo> ogra_: I can push you the ones I used for the previous image <ogra_> cool, thanks <mvo> ogra_: one sec, meeting right now <ogra_> no hurry <sergiusens> kyrofa, I made a better change https://github.com/ubuntu-core/snapcraft/pull/285/files <kyrofa> sergiusens, ah, just move it down? <kyrofa> sergiusens, good idea <kyrofa> sergiusens, though honestly, I refactored that in my PR anyway... what if I just move it down? <kyrofa> sergiusens, otherwise it'll just conflict <kyrofa> sergiusens, ha! Actually, I already did <kyrofa> sergiusens, https://github.com/ubuntu-core/snapcraft/pull/283/files#diff-0d5dc26743422dade0478e577247a141R124 <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 <kyrofa> niemeyer, mvo kindly filled in the u-c-l details (thanks mvo!) <noizer> ogra_ Hi i just installed nginx in my snap but does i need to make a service of it or not? <noizer> to get nginx started <sergiusens> kyrofa, sure <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) <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 <noizer> kyrofa can you look a moment to my question that i asked to ogra_ i think he is afk <kyrofa> noizer, yes, any service you want to run within your .snap must be declared as such <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 <kyrofa> niemeyer, no problem :) <noizer> kyrofa ok thx for the answer <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) <ppisati> ogra_: as soon as it's done i'll delete the previous one <noizer> kyrofa i want to remove an application but it won't work completely. here is some output: http://pastebin.com/CqZDAuxU <kyrofa> noizer, no clue what's happening there. It looks like you were in the middle of a commit when you built the snap? <ogra_> ppisati, ok <noizer> kyrofa not realy <noizer> but that was installed previously xD <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? <beuno> jdstrand, +1 and +1 <Guest5410> jdstrand, FWIW, we have tests in the store to enforce that. * Guest5410 sighs <JamesTait> Finally! <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). <JamesTait> mvo and/or sergiusens - feel free to correct me. ð <sergiusens> JamesTait, jdstrand that is indeed correct <sergiusens> jdstrand, I say +1 to squashfs implies snap.yaml (but not too tightly coupled in the code) <jdstrand> JamesTait: yes-- I will be using the snap.yaml spec to implement this <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 <JamesTait> jdstrand, I assumed as much, just wanted to make sure it was on your radar. ð <jdstrand> JamesTait: appreciated :) <mvo> jdstrand: +1 for now package.yaml in 16.04 <sergiusens> jdstrand, right, just thinking about 16.10 and squashfs having a different snap.yaml <beuno> there will be no 16.10! <beuno> rolling until 18.04! <sergiusens> beuno, well, rolling <noizer> kyrofa what did I wrong. He installed flask but not tornado and yaml as library for python http://pastebin.com/xiXE78Sm <kyrofa> noizer, huh? <kyrofa> noizer, I don't see a problem there-- what went wrong? <noizer> when im installing my application and then i look in my site-packages there isn't tornado installed <noizer> :s <kyrofa> noizer, do you have any errors when creating the snap? <noizer> no <noizer> wait i will try something again <noizer> he is now building the snap again a moment please <noizer> kyrofa got an error verry strange : Parts 'flask' and 'yaml' have the following file paths in common which have different contents: <noizer> so it was an old snap file that i had installed :s <kyrofa> noizer, please pastebin the build log <noizer> kyrofa http://pastebin.com/fpJP1AL1 <sergiusens> elopio, should I give you time to look at https://github.com/ubuntu-core/snapcraft/pull/282 ? <elopio> sergiusens: wow, that's big. I'm in a meeting with Federico. If you are happy with kyrofa's review, merge it. <elopio> I'll take a look afterwards. Seemed good with my quick glance. <sergiusens> elopio, yeah, I added lots of tests ;-) <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 <noizer> kyrofa do you have any solution ps I'm using snapcraft 2.0 <elopio> fgimenez: I was trying to say that this create cloud image job doesn't take a lot of time. <elopio> could we create one image per job, and then delete it? <elopio> not per job, per test execution. <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 <elopio> fgimenez: right, that would be a lot of wasted resources when there are no changes. <elopio> ok, lets figure out how to subscribe to new versions. <elopio> fgimenez: do you know if there's a good plugin for jenkins that keeps polling? <fgimenez> elopio, yes urltrigger, we are using it for the image creation jobs <fgimenez> elopio, https://wiki.jenkins-ci.org/display/JENKINS/URLTrigger+Plugin <noizer> kyrofa the error is at line 592 <elopio> fgimenez: great, it lets you even check the json response. I'll use it. <kyrofa> noizer, ah, it seems that's bug #1531570 <ubottu> bug 1531570 in Snapcraft "Can't have two python3 parts using setuptools" [Undecided,New] https://launchpad.net/bugs/1531570 <noizer> kyrofa is there an solution for that? <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? <noizer> kyrofa or install them manualy in an other os and copy them to the correct dir <kyrofa> noizer, you might try the requirements.txt first, if that works for you <noizer> kyrofa is there an example of that? <kyrofa> noizer, not in snapcraft, it's a pip thing <kyrofa> noizer, https://pip.readthedocs.org/en/1.1/requirements.html might be helpful <pindonga> kyrofa, re: proper login on snapcraft... I just became aware snappy itself has login support as well <pindonga> so I think you should attempt to mimick what's being done there <pindonga> looked at the code and looks quite right to me <kyrofa> pindonga, regarding the OTP etc.? <pindonga> yes <kyrofa> pindonga, excellent, we'll check it out! Thank you :) <elopio> fgimenez: https://search.apps.ubuntu.com/api/v1/package/ubuntu-core.canonical <pindonga> kyrofa, it might even make sense trying to read the config file written by snappy (so to avoid having multiple config files) <kyrofa> pindonga, without having looked at it, why does snappy have a login option? <pindonga> kyrofa, there are certain use cases that need it, eg downloading private packages <kyrofa> pindonga, ahh <kyrofa> pindonga, that makes sense then <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) <lool> LefterisJP: hey! <elopio> fgimenez: if we are listening to the three snaps, why don't we just use a timestamp? <elopio> I mean one timestamp. <LefterisJP> lool: hey :) <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 <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 <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. <elopio> I might be missing something of course, because I don't get why we need to compare. <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 <elopio> fgimenez: got it. Well, I won't mind to collect the three versions and build a name from that. Whatever you prefer. <mvo> jdstrand: \o/ thanks, that is great news <elopio> fgimenez: last thing I wanted to talk today is about gocheck. <jdstrand> np <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. <fgimenez> elopio, ok, let me know if you need any help with that <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 :) <beuno> JamesTait, so, are you changing crt to not require readme.md for 16.04 snaps? <sergiusens> beuno, mvo just triple confirming; I can land skills for snapcraft? Is there an OS already built? <sergiusens> built/uploaded to the store <JamesTait> beuno, I can do, if it won't interfere with what jdstrand is working on. <beuno> sergiusens, I don't know. Will it affect the store in any way? <sergiusens> beuno, well; only in the sense that everything might be denied or marked invalid <beuno> sergiusens, if you get me a snap built with skills, I can run it through and check for you <sergiusens> beuno, sounds good <beuno> sergiusens, in all likelyhood, it'll be click-reviewers-tools <beuno> so you can easily check locally as well <jdstrand> JamesTait (and beuno): it would be incorporated in my larger work. if needed, JamesTait or I can make a quick change <JamesTait> jdstrand, I realise it's still early days, but do you have a sense of ETA for the rework yet? <jdstrand> sergiusens, beuno: I can say for sure the review tools won't like it <jdstrand> JamesTait: I imagine this week. I am wholly focused on it <JamesTait> Ack, thanks. <sergiusens> jdstrand, if the error does not prevent manually putting into the store I'm fine <sergiusens> putting/approving <jdstrand> sergiusens: it would be no worse than other squashfs. if you give me a snap I can make super sure for you <sergiusens> jdstrand, k, thanks <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. <JamesTait> jdstrand, letting you know just in case it's a really bad idea or makes things much more difficult. <jdstrand> JamesTait: so, you give a snap to the review tools in some way, and it spits back something the store can consume? <JamesTait> jdstrand, exactly. <jdstrand> JamesTait: I think that is a really good idea <jdstrand> keep this stuff in one place <JamesTait> Excellent. âº <JamesTait> I'll find out whose idea it was and route karma/beers appropriately. ð <jdstrand> I imagine the review tools side would loop back to me (which is fine) <mvo> sergiusens: there is no updated OS snap in the store yet but I will upload one now that the store is open <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 <ogra_> haha <ogra_> wow <ogra_> i just wiped the .ics files from my phone and clicked "sync" in the calendar app .... * ogra_ guesses he shouldnt recommend doing that to anyone .... flushed my whole gcal at google :P <wigglewo1> Does anyone know of there are email posted somewhere that say snappy updates are available? <wigglewo1> posted or emailed to general public <ogra_> what kind of updates ? <ogra_> to the snappy binary ? <ogra_> (OS updates happen automatically on all images that are supported) <ogra_> updates to the stable images are usually announced on the snappy-devel mailing list after they went out <wigglewo1> i know that but if the automatic updates are diabled then how does one find out about updates? <ogra_> well, if you run stable you m8ight want to follow that ML <wigglewo1> what is ML <ogra_> if you use any rolling channel ... well, you should check regulary by simply running "sudo snappy update ubuntu-core" <ogra_> mailing list <wigglewo1> thanks where do i find the mailing list <ogra_> https://lists.ubuntu.com/mailman/listinfo/snappy-devel <wigglewo1> thank you <ogra_> :) <wigglewo1> are you familiar with apticron? and does that work differently? <ogra_> no, never heard of apticron <wigglewo1> ok thanks <kyrofa> elopio, regarding the INFOs from requests-- are you suggesting I move that line into log.py? Or do something different altogether? <elopio> kyrofa: yes, you can put this: <elopio> logging.getLogger("requests").setLevel(logging.WARNING) <elopio> in the log.configure. <kyrofa> elopio, ah, that will be much nicer, I'm glad you caught that. I've never noticed log.py before, heh <sergiusens> JamesTait, beuno jdstrand http://people.canonical.com/~sergiusens/snappy/shout_0.52.0_amd64.snap there's a skills snap <JamesTait> Handy, thanks sergiusens! <sergiusens> elopio, have time for a quick hangout? <Chipaca> pitti, got a systemd ordering/dependency question for you <Chipaca> pitti, when would be a good time? <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? <sergiusens> elopio, yeah <sergiusens> elopio, well this https://plus.google.com/hangouts/_/canonical.com/snapcraft <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 <pitti> Chipaca: just ask, that's easier :) (drive-by, dinner now, but will come back for a bit later tonight) <pitti> Chipaca: well, that sounds like a circular dependency then -- you must break it somewhere :) <pitti> Chipaca: without knowing any details, conceptually they probably shouldn't be wanted by multi-user then? <Chipaca> pitti, ah, maybe i didn't explain properly. go have dinner, i'll try to explain better in a bit <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 <sergiusens> jdstrand, that's good enough for me. <jdstrand> sergiusens: the review tools in the archive is oddly a little more grumpy with that over a snapcraft 2.0.1 build snap <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" <jdstrand> sergiusens: don't you run the review tools automatically? if so, I should figure that out now and update the archive <jdstrand> oh yes, that would make sense <jdstrand> if no package.yaml, it will think it is a click <jdstrand> ok, let me look at that MP from earlier today and upload that to xenial <jdstrand> sergiusens: go ahead with your merge/landing/etc <sergiusens> mvo, did you push already; or asked differently; does `snappy update` work on amd64? <sergiusens> jdstrand, thanks, just waiting on OS support to make sure all the pieces work :-) <noizer> kyrofa Is it possible to enter the container to test some things? <kyrofa> sergiusens, should I --include-binaries in the copy-package? <kyrofa> sergiusens, not super clear on what that does :P <kyrofa> noizer, what container? <noizer> the snap so i can do some python scripting for do some test <noizer> kyrofa <kyrofa> noizer, running xenial (rolling), right? <noizer> kyrofa yes <sergiusens> kyrofa, yes you should <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 <kyrofa> s/need to make/need to play/ <kyrofa> sergiusens, otherwise it'd what... grab the source package only? <sergiusens> kyrofa, yeah, and rebuild <kyrofa> sergiusens, very good <Chipaca> kyrofa, maybe 'snappy shell' is what noizer is looking for? <kyrofa> Chipaca, perhaps, I don't have any experience with it (it doesn't show up as an option for me, must be new?) <ogra_> sudo snappy enable-classic <ogra_> snappy shell classic <ogra_> ;) <kyrofa> Ohh <Chipaca> yes, but, snappy shell potato <Chipaca> gives you a shell in the security context of potato <kyrofa> Chipaca, interesting. But you still can't modify the install snap, right? <kyrofa> installed* <Chipaca> right. But you can 'try some things' <kyrofa> Chipaca, hey, I learned something new. Thanks for that! <ogra_> you can also spt-get install snapcraft ;) <ogra_> and build your snaps in there <Chipaca> ssh, don't tell people about spt-get yet <ogra_> *apt <ogra_> haha <kyrofa> ogra_, yeah I've used classic, I just didn't realize snappy shell was a more generic command <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. <Chipaca> pitti, that last little detail is purportedly a bug :-) <Chipaca> pitti, basically we want the whole tree under wait4network to be "ignored", as far as reaching multi-user is concerned <ogra_> well, you want loopback <Chipaca> wait4network waits for a route <ogra_> is that blocked by that service too ? <ogra_> ah <ogra_> right, thats the one that never finishes if we have auto in /e/n/i with no network cable attached <Chipaca> and a snap with a service with an external port installed <ogra_> does systemd not provide a simply way for timingt out a job ? <ogra_> *simple <ogra_> (like a timeout option :) )) <Chipaca> yes <Chipaca> but we don't want it to timeout <Chipaca> (and it'd be in the minutes, this timeout) <ogra_> hmm <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 ?= <ogra_> (if assigning a port also makes it depend on that service file) <Chipaca> ogra_, then you don't define an external port for it <Chipaca> ogra_, there are internal ports <ogra_> oh, i thought they were dropped <Chipaca> they will be, once we move to caps <ogra_> right <Chipaca> the problem will remain :-) <ogra_> indeed :) <sergiusens> jdstrand, fwiw, the store accepted my app (failed reviews though) https://myapps.developer.ubuntu.com/dev/click-apps/3989/rev/4/ <Chipaca> ogra_, hence head scratching, and pitti invoking <ogra_> yeah <Chipaca> i'd go ask in #systemd but last time i went they said we should have systemd in initrd <Chipaca> which i agree on in principle, but in practice i'm not in a hurry to get there <sergiusens> ogra_, kyrofa, Chipaca what noizer want is the yet to be made snappy try <ogra_> yeah, <kyrofa> sergiusens, yeah, I did know that one :P <Chipaca> sergiusens, the tricky bit is the snappy except <Chipaca> i'll let myself out <kyrofa> Chipaca, the finally is really terrible <sergiusens> Chipaca, because it should be catch? :-) <jdstrand> sergiusens: cool. do you need me to accept it? <sergiusens> jdstrand, if you want to, sure (it's the same snap, except I uploaded with the to be release snapcraft upload command) <sergiusens> *d * sergiusens is still waiting for ubuntu-core to finish downloading <Chipaca> sergiusens, kyrofa, i think we all should get each other big "NERD" mugs <kyrofa> Hahaha <ogra_> you dont have one yet ?!? <jdstrand> sergiusens: if you request a manual review, I'll approve it <jdstrand> sergiusens: fyi, uploaded review tools 0.36 to xenial so it won't be so grumpy <sergiusens> jdstrand, :-) <sergiusens> jdstrand, we plan on releasing snapcraft 2.1 today as well <sergiusens> jdstrand, and this is our next milestone fwiw https://launchpad.net/snapcraft/+milestone/2.2 <jdstrand> sergiusens: cool <jdstrand> sergiusens: fyi, accepted <sergiusens> mvo, updating does not work in rolling in case it was unknown to you <kyrofa> sergiusens, 1.0.1 release went smoothly. Thanks for answering my questions :) <sergiusens> kyrofa, nice <kyrofa> sergiusens, is https://github.com/ubuntu-core/snapcraft/pull/283 good to go, then? <sergiusens> kyrofa, I am just missing a live upload; unless you have tried that yourself <sergiusens> I will trust you ;-) <kyrofa> sergiusens, only to staging <kyrofa> sergiusens, but I can do live <sergiusens> kyrofa, that should be good enough; don't you want to try against production <sergiusens> kyrofa, one of the examples maybe <kyrofa> sergiusens, verified-- works great :) <sergiusens> kyrofa, the minute I press merge, I remember I didn't check the commit message :-P <sergiusens> kyrofa, is this mentioned https://bugs.launchpad.net/snapcraft/+bug/1539814 or should I just dup? <ubottu> Launchpad bug 1539814 in Snapcraft "Upload not closing resource correctly" [Medium,New] <kyrofa> sergiusens, it is :) <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 <kyrofa> sergiusens, I went with two <sergiusens> kyrofa, I think you did it right <sergiusens> kyrofa, we'll see ;-) <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) <kyrofa> sergiusens, for my future reference, if I need to do something asynchronously in python, is multiprocessing better than multithreading? <kyrofa> sergiusens, the way I solved the progress bar problem was driven completely by my experience in C++ <kyrofa> sergiusens, but your comments from earlier lead me to believe there's a better way to do that in python? <sergiusens> kyrofa, multithreading is not that good in python; Chipaca might spank you :-P * kyrofa runs away from Chipaca <sergiusens> zyga, any idea how to test if my migration-skill built snaps actually work? <sergiusens> zyga, or can you try and see if 'shout.sergiusens' on the store works? <zyga> sergiusens: I'll check, mvo merged this yesterday <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_* <pitti> Chipaca: re <pitti> Chipaca: snappy-wait4network.service sounds very similar to network-online.target <kyrofa> sergiusens, why does the ROS example have all the exclusions now <kyrofa> ? <pitti> Chipaca: normally multi-user.target does/should not depend on network-online.target, unless you have things like /var or /home on NFS <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 <kyrofa> sergiusens, I seem to remember it having to do with shebang stuff <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 <sergiusens> kyrofa, so it doesn't conflict with what catkin brings in <pitti> Chipaca: option 2 is to make snappy-wait4network.service WantedBy=network-online.target instead of m-u.target <sergiusens> kyrofa, and yeah, it is related; but I eventually want to get rid of the file migration thing <kyrofa> sergiusens, didn't we fix that with the always-link change? <sergiusens> kyrofa, no; but we also still remove useless stuff for a snap, so it should be fine <pitti> ogra_: sure, units time out starting/stopping by default after 90s (units can tweak or disable that, but most don't) <kyrofa> sergiusens, ohhh, the roscore plugin...... <kyrofa> sergiusens, okay good. This'll clean up nicely then <sergiusens> kyrofa, yeah <elopio> I'm going to have lunch. <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. <elopio> bbl <sergiusens> elopio, no worries, I'm still debating if I should merge the migration skill stuff as there isn't a working image yet <kyrofa> sergiusens, that would indeed make it difficult to test other changes built on top of master if it merged... <kyrofa> Chipaca, what kind of parameters does `snappy shell` accept? <kyrofa> Chipaca, oh you're probably eating or something huh <kyrofa> Chipaca, you can ignore me :) <sergiusens> lol <sergiusens> kyrofa, yeah, that is why I didn't merge it <sergiusens> just hoping mvo can answer when he gets back <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 <sergiusens> kyrofa, welcome to my world of not knowing and being blocked most of the evening :-P <wigglewo1> hello - looking for direction on how to publish a snap to the snappy store - are there published instructions? <rickspencer3> wigglewo1, well ... <rickspencer3> the web page is pretty self-explanatory, I think <rickspencer3> wigglewo1, have you looked at https://myapps.developer.ubuntu.com <rickspencer3> ? <rickspencer3> once you sign in, click on Ubuntu Core at the top <rickspencer3> and then fill in the form <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. <zyga> bdmurray: hold the user button <zyga> bdmurray: and do remove the other bootloader as otherwise you will never boot into the SD card <bdmurray> zyga: hold the user button during boot? <zyga> bdmurray: yes <zyga> bdmurray: it forces the SoC to use SD card to boot <bdmurray> and then you use dd on the device to remove the bootloader? the instructions don't make that clear. <zyga> bdmurray: you can do that from uboot or after snappy boots <zyga> bdmurray: AFAIR I used uboot's command to erace the mmc <zyga> erase* <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. <bdmurray> https://paste.ubuntu.com/14852967/ <zyga> bdmurray: did you use snapcraft? <zyga> bdmurray: you can use snapcraft to build a snap with python <bdmurray> zyga: yes, i did <zyga> bdmurray: there are existing examples that do just that in snapcraft source <zyga> bdmurray: try building one of them and ensure it works <zyga> bdmurray: if that doesn't work, ask sergiusens <zyga> bdmurray: note that beagle is no longer officially supported <zyga> bdmurray: though I bet that python won't care here, the image you might be using might be out of date <bdmurray> its still listed at the developer portal <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 <zyga> bdmurray: I have two beagles in my office, both running snappy, though I'm using raspberry pi for my daily development now <bdmurray> Is there a way to get snapcraft to use my local mirror? <zyga> bdmurray: perhaps but I don't know the details, ask sergiusens <sergiusens> bdmurray, USE_LOCAL_SOURCES=1 and python is included in the snap, you need to build on the arch you want to target <bdmurray> sergiusens: How do you recommend building on armhf? #snappy 2016-02-02 <sergiusens> bdmurray, on 15.04 you can snappy install lxd; on 16.04 (probably the recommended target for new dev); snappy enable-classic <wililupy> question: Is webdm still in the Snappy store? I try to install it with sudo snappy install webdm but I get webdm failed to install: snappy package not found <torbit> Hi guys, <torbit> I am trying to pull down the snappy core image for i386 <torbit> I cant seem to get it <torbit> I get a 404 on this : wget http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-amd64-generic.img.xz <torbit> unxz -c ubuntu-15.04-snappy-amd64-generic.img.xz <torbit> does anyone have something that I can pull publicly ? <torbit> anyone online ? <torbit1> Ok seems like it was something on my network . sorry <torbit1> thanks <dholbach> good morning <fgimenez> good morning <renat> Hi all! It's Renat from Screenly again=) <renat> When setting up assign rules in the oem snap - is it possible to add device access rules (MODE="", GROUP="")? <renat> For example, we need to use /dev/vchiq. And I add appropriate option to the assign: section. <renat> assign: rules: - kernel: vhciq <renat> But it device isn't accessible because of very strict access mode. <JamesTait> Good morning all! Happy Tuesday, and happy Hedgehog Day! ð <torbit> Hi folks. I need some help <torbit> I downloaded a generic x86 image <torbit> I would like to know what the OEM part of the docs is exactly. <torbit> I am not getting that part very wekk <torbit> well I mean <kyrofa> Good morning <torbit> good morning kyrofa <torbit> although on my end it is afternoon . Nice sunny day in Nairobi <kyrofa> Hello torbit :) . I'm afraid I don't know much about OEM stuff right now, other than it's a bit in flux right now between 15.04 and 16.04 <ogra_> torbit, essentially it contains the bootloader <torbit> ogra_ : hmmmm. I see <ogra_> amd64 is a bit special here though ... unlike the arm arches it only ships the bootloader config http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files/head:/generic-amd64/ <torbit> well in my case I am working with some intel device. <ogra_> (grub gets simply pulled out of the rootfs when the oem snap gets put into place by ubuntu-device-flash) <torbit> oh. <torbit> that I did not know <mvo_> ogra_: how is the arm64 cdimage.u.c output looking? are we getting close to soemthing that we can consume :) ? u-d-f and the store are fixed so we can move again * mvo_ lunch <ogra_> mvo_, oh, not done yet + <mvo_> ogra_: ok <mvo_> ogra_: just curious, no real rush <ogra_> i need to do the rpi bootloader update today, then i'll move on to cdimage <mvo_> ogra_: at least we can move forward now again with the store fixed <mvo_> ogra_: \o/ ok <ogra_> yeah :) <ogra_> mvo_, we wont be able to build arm64 until we have a kernel package in the archive though <torbit> ogra_: hmmmm. so I guess that means I need to create the root.tar.xz? <ogra_> ppisati said there were still bits blocking it <torbit> am I correct in assuming this ? <ogra_> torbit, for wghat exactly <torbit> ogra_: in my case I am trying to create a bootable disk to flash a device <torbit> so use snappy core <torbit> the device is currently using ubuntu server <ogra_> torbit, sure, but why does the existing setup not work for you <ppisati> ogra_: yes, the dragonboard kernel won't enter the archive as it is, until we have a multi-arm64 kernel etc <ppisati> ogra_: for now you'll have to use my ppa <torbit> ogra_: so this is what I did, I took the generic image , made a bootable flash with DD <ogra_> ppisati, i doubt we want that for cdimage builds ... but i can copy it to the snappy hardware PPA i guess <ppisati> ogra_: k <torbit> ogra_: I plug it in an nothing . <ppisati> ogra_: i'm writing you an email right now <torbit> so I am not too sure what I am doing wrong to be honest <ppisati> ogra_: with uboot etcetc <torbit> ogra_: it is my first time <ogra_> torbit, well, it should work on any x86 system <ogra_> ppisati, ok, thanks ! <torbit> ogra_: tell me does this platform need to have a screen to select this image in the boot loader or does it just boot into it <ogra_> torbit, you might want to take a look at the kernel cmdline on the created usb stick, could be that the early boot defaults to do all output to the serial console <ogra_> it should boot straight through <ogra_> (the first boot takes a while though, it creates ssh keys and such) <torbit> ogra_: hmmm. oooh I see. ok one sec I try this one more time <ogra_> is that 32 or 64bit hardware ? <torbit> ogra_: 32 bit <ogra_> oh <torbit> for sure <torbit> ogra_: it is intel chip based <ogra_> you might need to build an i386 image manually then <torbit> ogra_: can we DM ? <ogra_> the generic x86 image we offer pre-built is using UEFI and a 64bit kernel to boot <torbit> aaaaah <noizer> kyrofa Hi my snappy just rebooted automatically and some things dont work anymore just lik i installed python on my snap but when he executes a command he doesn't find python anymore :s <kyrofa> noizer, I can't remember-- are you on 15.04 or rolling? <ogra_> on rolling (snapcraft 2.0 snaps ;) ) <kyrofa> noizer, hmm, can you check the shebang of the python script you're trying to run? What does it look like? <noizer> yea on rolling <noizer> kyrofa wait i dont use the shebang the command looks like : python file.py <noizer> and then the error is python not found <kyrofa> noizer, is this a daemon, or no? <noizer> no deamon <noizer> but when i do snappy list i don't get the core anymore so I think my snappy is broken :s <noizer> so I will install snappy again <beuno> kyrofa, FYI, you can now upload multiple architectures and releases <beuno> ogra_, ^ <kyrofa> beuno, woo hoo! <kyrofa> beuno, do I need to do anything special? Or will foo_1.2_amd64.snap and foo_1.2_armhf.snap just magically go to the right place as long as the YAML is the same? * ogra_ hugs beuno <beuno> kyrofa, magically <kyrofa> beuno, I like magic * beuno briefly naps in ogra_'s hug <kyrofa> Man that's a long hug <kyrofa> beuno, thanks for the hard work! I'm testing it out now <noizer> Kyrofa i think i found an issue of snappy. The pythonpath is only directed to the dist-packages and not to the site-packages <noizer> is that normal or? <kyrofa> noizer, they should be a symlink <noizer> when i putted some folders in the site-packages, they cant be imported :s <beuno> kyrofa, I'll leave the thanks in its original packing until it's gotten a bit of mileage and people are still happy :) <kyrofa> beuno, haha <kyrofa> noizer, can you run ls -l on the directory containing site-packages? <renat> Hi guys! Let me repeat my question. <renat> When setting up assign rules in the oem snap - is it possible to add device access rules (MODE="", GROUP="")? <renat> For example, we need to use /dev/vchiq. And I add appropriate option to the assign: section. <renat> assign: rules: - kernel: vhciq <renat> But it device isn't accessible because of very strict access mode. <kyrofa> ogra_, renat's question may be best suited for you <sergiusens> kyrofa, elopio https://github.com/ubuntu-core/snapcraft/pull/286 <ogra_> kyrofa, i have no clue about the capability system <ogra_> kyrofa, all i knew about was hw-assign ... i kind of lost track when we dropped that <kyrofa> ogra_, oh I thought OEM was 15.04 <kyrofa> ogra_, I'm getting confused so quickly :P <ogra_> i dont even think in 15.04 there was a way to do it automated <kyrofa> ogra_, ah, now that you mention it, I do remember hearing that <ogra_> it was all a manual call to hw-assign asd i remember <sergiusens> ogra_, that is all 15.04 renat is talking about <sergiusens> ogra_, there was in the oem snap; mvo_ implemented <ogra_> sergiusens, well, do you remember if there was a way to do it from the oem ? <sergiusens> ogra_, surely asac knows about this since he wrote a guide <ogra_> ah, i didnt know <ogra_> i only ever used hw-assign back then <kyrofa> sergiusens, do you know about the mode/group bits? <ogra_> i dont think mode/group will help much ... apparmor will block before you even get to that <sergiusens> ogra_, kyrofa in case it is of interest https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ <ogra_> mode and group should be handled through udev-acl anyway <sergiusens> kyrofa, no, I think it is just tagging <sergiusens> renat, if it is not a service, use sudo <renat> ogra_, not apparmor blocking me <renat> sergiusens, it's a service. Is it possible in 16.04? <sergiusens> renat, stick to 15.04 for now; if it is a service and blocked I don't know, seccomp maybe? <sergiusens> renat, sudo snappy install snappy-debug <renat> sergiusens, thanks. I will try. <sergiusens> jdstrand, maybe you have ideas ^ <dholbach> sergiusens, kyrofa: let me know if you need snapcraft 2.1 uploaded to xenial <dholbach> ah no... you have upload rights for it now, right? <sergiusens> dholbach, hah, I don't need you for that anymore :-P <sergiusens> dholbach, sorry ;-) <dholbach> yeah... I know <dholbach> go go go! <sergiusens> dholbach, still waiting on pocketsphinx though ;-) <kyrofa> sergiusens, so you were able to build a rolling image that worked? <jdstrand> renat: if it is a service, it should be running as root so file perms shouldn't be an issue. I suggest 'sudo snappy install snappy-debug' and then 'sudo snappy-debug.security scanlog' in one console while trying to use the app in another. <renat> jdstrand, understood. thanks. <renat> Seems it's trying to access /proc/4212/mounts <renat> For the some reason <sergiusens> kyrofa, I downloaded from mvo_'s p.c.c <sergiusens> kyrofa, just this morning <kyrofa> sergiusens, ah okay <jdstrand> beuno, mvo_: I saw something about uploads to the store going to the write place. I noticed on a 15.04 bbb system that it is trying to install hello-world.canonical 1.0.18 over and over and over again <jdstrand> s/write/right/ * sergiusens goes for a quick run * jdstrand is curious if these things are related <beuno> jdstrand, good question. What we've enabled, FWIW, is multiple binaries for different architectures andreleases <jdstrand> beuno: so that means that I can have an ar-snap for 15.04 and a squashfs-snap for rolling both targeting !edge and it all works? <beuno> jdstrand, correct <jdstrand> that sounds nice indeed <asac> ogra_: check out the guide <asac> it has that info <jdstrand> mvo_: fyi, something weird is happening on bbb 15.04 and hello-world.canonical starting yesterday <asac> ogra_: https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ <asac> search for assign: <mvo_> jdstrand: what is it? <mvo_> jdstrand: since yesterday you say? do you have some more details? <mvo_> jdstrand: there were some changes to the store related to the multi-dimension uploads <ogra_> asac, well, tell that renat ;) <asac> mvo_: what are multi dimension upload? <ogra_> 4D uploAds ! <asac> 5D at least <asac> >( <ogra_> :) <noizer> kyrofa what was the update of the snappy build because it rebooted it for update (ubuntu 16.04) <kyrofa> noizer, you'd have to ask mvo_ <awe__> hey, can any of you tell me how to view the kernel options for our latest snappy rolling ripi2 image? <kyrofa> noizer, remember you're on rolling, so some instability is not surprising <ogra_> awe__, isnt /proc/config.gz populated ? <davmor2> asac, ogra_: you seem to missing the point, there is no limit to multi ;) <ogra_> (i usually set that by default before giving ppisati my config) <noizer> awe_ what is changed during the update with the rolling version? <noizer> awe__ what is changed during the update with the rolling version? <awe__> ogra_, nope <kyrofa> noizer, can you pastebin your binary wrapper for me? <ogra_> awe__, hmm, then you need to apt-get source the package i fear ... <mvo_> asac: the same name for multiple architectures, i.e. no more ubuntu-core-armhf <ogra_> awe__, https://launchpad.net/ubuntu/+source/linux-raspi2 <davmor2> asac, ogra_: What mvo_ was trying to create with that statement was "XD uploads" :D <awe__> ogra_, thanks dude <noizer> kyrofa http://pastebin.com/647GUD2q <kyrofa> noizer, I mean the one in /snaps/bin/ <asac> mvo_: ok, i wouldnt call it |dimension" <asac> that name is already taken <asac> but just nit pikcing <asac> ttyl <noizer> kyrofa ok <kyrofa> noizer, I know, there are a lot of wrappers :) <mvo_> asac: I agree, we were calling it multi-arch before which is arguable way worse <noizer> kyrofa haha yea there are many wrappers but when my snappy was done with the update he doesnt have any snapp dir anymore :s <ogra_> http://foodnetwork.sndimg.com/content/dam/images/food/fullset/2012/9/25/0/ZB0307H_grilled-chicken-caesar-wrap_s4x3.jpg <ogra_> ;) <kyrofa> noizer, the /snaps directory is gone? <noizer> kyrofa yea he is gone <sergiusens> elopio, kyrofa time to stand <kyrofa> noizer, huh... yeah I'd reflash. Not sure what's going on there <kyrofa> sergiusens, ah, right thanks <noizer> maybe i will try again build a new image and see what he is doing while he is updating? <noizer> kyrofa <jdstrand> mvo_: sorry, got pulled away <awe__> ogra_, that branch was for wily... and I can't seem to come up with the right source package name for 'apt-get source' * awe__ jumps to #ubuntu-kernel <ogra_> awe__, just grab the .deb ... then dpkg -x /part/to/deb . <ogra_> (that will extract it to the current dir, probably create some ./tmp or some such ) <mvo_> jdstrand: no problem, I'm am pretty busy myself with various issues <awe__> I'm not sure where the .deb lives or what it's name is <awe__> if I did, I certainly would do that! ;)- <ogra_> it is linked from the above page i gave you <awe__> that's a wily branch <ogra_> https://launchpad.net/ubuntu/+source/linux-raspi2 shows wily and xenial <jdstrand> mvo_: http://paste.ubuntu.com/14857472/ <awe__> ah, my bad * awe__ goes and looks again <ogra_> clicking on the version will get you to the package <ogra_> (then click on "armhf" there to get the binary deb) <mvo_> jdstrand: so its reinstalling hello-world evey 1h? <ogra_> (under "Builds") <awe__> got it <jdstrand> mvo_: so, starting at 11:00 local (17:00 UTC), snappy started regenerating apparmor profiles on the hour, every hour for hello-world.canonical, but not other snaps <kyrofa> beuno, so I have version X uploaded to the store for armhf. I tried "Upload a New Version" of version X for amd64, and it's complaining that the version is already uploaded. Do I have to change the version per arch? <jdstrand> mvo_: the other snaps that are install (one sideload, snappy-debug and ufw) did not dual-land <jdstrand> I believe ufw may be an ar-based snap in rolling, and snappy-debug you need edge <jdstrand> oh, but his is all 15.04 <mvo_> jdstrand: I suspect its actually reinstalling this every hour? <jdstrand> $ snappy list <jdstrand> Name Date Version Developer <jdstrand> ubuntu-core (854)847-3108 ubuntu <jdstrand> bind9 2016-01-20 IKaMHDSJATaY sideload <jdstrand> hello-world 2015-12-27 1.0.18 canonical <jdstrand> snappy-debug 2016-01-06 0.10 canonical <jdstrand> ufw 2015-12-17 0.35 jdstrand <jdstrand> beagleblack 2015-12-17 1.12 canonical <jdstrand> mvo_: that is what I expect is happening <noizer> kyrofa any idea how i force an update, <jdstrand> s/expect/suspect/ <kyrofa> mvo_, it seems that canonistack hasn't built a rolling image since it moved to all snaps <kyrofa> mvo_, do you know anything about that? <ogra_> we build images in canonistack ? <ogra_> since when * ogra_ thought we dont build rolling images at all ... you always need u-d-f for it <ogra_> kyrofa, nothing moved to all-snaps yet except mvos zstrickland@example.net <jdstrand> kyrofa: aiui, there is nothing that automatically builds the os, kernel and gadget snaps used with these images. that work, aiui, is planned <ogra_> the cdimage builds still only produce the old setup <ogra_> (on my list for this week) <noizer> mvo_ is there a way to update the image with a command line? <ogra_> snappy update ubuntu-core <ogra_> (+ sudo ) <mvo_> jdstrand: will "snappy list -u" show you hello-world as upgradable? * jdstrand checks <mvo_> jdstrand: I'm still puzzled by this :) <kyrofa> jdstrand, ogra_ ah, I keep misunderstanding that. So rolling really is dead right now? * jdstrand taps fingers <jdstrand> mvo_: it does not <jdstrand> $ snappy list -u <jdstrand> ... <jdstrand> hello-world 2015-12-27 1.0.18 <jdstrand> ... <mvo_> jdstrand: hrm, hrm, that is confusing <jdstrand> mvo_: you said a change landed yesterday on the store. I imagine that change was between 1600 and 1700 UTC <mvo_> jdstrand: worth checking with the u1 guys <jdstrand> mvo_: it seems like this is perhaps something that needs to be backed out unless we know that it isn't affecting shipping devices <jdstrand> this would likely disrupt a service for a snap that this is happening to <ogra_> kyrofa, no, it is simply not moved to all snaps yet ... everything should work though <ogra_> (but using system-image) <mvo_> jdstrand: I forwarded your question <kyrofa> ogra_, "dead" = not getting any updates, I mean <ogra_> it is getting them daily ;) <ogra_> in fact all-snaps isnt getting any currently :) <ogra_> (apart from manual builds mvo_ does) <jdstrand> mvo_: thanks <kyrofa> ogra_, huh, okay. Yeah, I really misunderstood :P
{'channel': 'snappy', 'month': 2}