#snappy 2015-06-01 <miken> I've just pulled the snappy-examples and built the hello-world, but get a bunch of errors and warnings about files which don't exist: http://paste.ubuntu.com/11488439/ Is that expected, or related to my env? <miken> (it does build the snap, but unsure why I see those errors/warnings) <dholbach> good morning <fgimenez> hi mvo, i'm trying the examples at https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-examples <mvo> hey fgimenez, good morning <fgimenez> mvo, morning :) <fgimenez> mvo, on rolling/edge i'm getting the same aa_change_on_exec error you just reported for every snap <mvo> fgimenez: yeah, please use 15.04/edge for now, the rolling images are literally only ~30min old :) I enabled wily this morning on them and this was the first bug I noticed <mvo> fgimenez: I have not investigated further but it appears the apparmor profiles are not created <fgimenez> mvo, ok thx :) on 15.04/stable i'm getting this http://paste.ubuntu.com/11491522/ when trying to use the config hook, have you seen that before? <fgimenez> mvo, in the config-example snap <fgimenez> mvo, didn't try 15.04/edge though, doing it now <mvo> fgimenez: does the directory /var/lib/apps/config-example/1.0.6 exist? <mvo> fgimenez: it does not ring a bell, I will have to install/test in a VM to debug further <fgimenez> mvo, no, the one that exists includes the origin /var/lib/apps/config-example.sideload/1.0.6 <dholbach> mvo, ogra_, asac: http://ubucon.de/2015 :) <mvo> woah, berlin <dholbach> the cfp has started and they'd be happy if we could talk about all the new stuff we're doing and maybe do a workshop or two <mvo> fgimenez: aha, thanks. thats the bug then, the .sideload is not taken into account :/ <mvo> fgimenez: would you mind to file a short bug (this irc log is enough) so that its not forgoten? <mvo> fgimenez: should be easy to fix :) <fgimenez> mvo, of course thx :) <elopio> good morning. <davidcalle> Morning all <beowulf> morning <D_Cent> hi - i have trouble connecting to wi-fi with snappy ubuntu on a raspi2. i followed the wifi tutorial and installed the wireless-tools, etc. but if i connect the wifi dongle via usb, dmesg only shows that a new device was connected without loading any drivers or firmware. the interface wlan0 or similar also doesn't exist. how can i make it work? i had it running previously on an older image, so it should be working <JamesTait> Good morning all; happy Monday, and happy Say Something Nice Day! ð <ogra_> mvo, beuno, hulp ! ... can one of you let chatroom through ? seems the review tools seem to be messed up ("ports is pbsolete in package.yaml") <ogra_> *obsolete <beowulf> ogra_: do you need this asap? <ogra_> beowulf, mectors does i think ... i'm just trying an upload with changed ports directive though <ogra_> mvo, could you take a look at https://myapps.developer.ubuntu.com/dev/click-apps/1526/ ? <ogra_> i dont get why it spits out the two warnings (my snap overview page tells me 0.1-8 is published btw ... only the details page tells me it isnt) <zyga> can I freely change the hostname of a snappy core system? <beuno> om26er, on it <beuno> er <beuno> ogra, on it <beuno> (who is not in the channel :)) <mvo> ogra_: hi, you can ignore those warnings for now, we need to stop generating those .snappy-systemd files, they are no longer needed <beuno> ogra_, I approved it <beuno> the fix is on the store side <beuno> I have it pending <ogra_> beuno, ok, thanks ... if now the snap would actually work :/ <ogra_> beuno, btw, where do i file store bugs ? <beuno> ogra_, https://bugs.launchpad.net/software-center-agent/ * ogra_ has 5 pairs of identical mails for the last uploads ... no mention which version which mail belongs to <ogra_> and my front apps page said the whoile time that 0.1-8 was accepted * beuno nods <ogra_> now why the heck does the chatroom not work anymore :/ <sergiusens> ogra_: maybe seccomp <ogra_> sergiusens, hmm, i dont see any special messages about syscalls <ogra_> what i see is: <ogra_> Jun 1 12:23:01 localhost kernel: 636-721-3251] audit: type=1400 audit(1433161381.662:146): apparmor="DENIED" operation="open" profile="chatroom.sideload_chatroom_0.1-8" name="/" pid=2356 comm="nodejs" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 <ogra_> but that has always been there * ogra_ has an old install around that works fine on an old snappy <sergiusens> ogra_: why would you want to read / anyways ;-) <ogra_> node does for whatever reason <sergiusens> ogra_: amd64 or armhf, I can try and install to see <ogra_> but that never did any harm <ogra_> this is currently amd64 <ogra_> in kvm <Chipaca> mvo: any luck reproducing the issue wrt install not working? <ogra_> my RPi is using a messed up image because i try to fix it :P * ogra_ tries an older node-snapper tarball <mvo> Chipaca: no, but I didn't try further, sorry, I will try again in a little bit <sergiusens> ogra_: the one on the store works fine on 1.8 <sergiusens> ogra_: err <Chipaca> sergiusens: does 'snappy install' work for you in a vm? <sergiusens> ogra_: the one on the store, 1.8, works fine on bbb <ogra_> ARGH !!! <ogra_> sergiusens, because i'm the super idiot today * ogra_ tested with firefox :P <sergiusens> ogra_: no binary for amd64? <ogra_> (only works with chromium) <ogra_> sure, it is multi arch <sergiusens> ogra_: ah, I tried on chrome fwiw <ogra_> yeah, man, i wasted 2h on that :/ * ogra_ adds that info to readme.md for next time :P * ogra_ takes a break, phew ... * Chipaca realises he hasn't updated in ages <rsalveti> hm, our builders are in a funny state <ogra_> rsalveti, which ones ? images ? <rsalveti> normal lp builders <rsalveti> some are busy with the haskell uploads <rsalveti> but at our ppa all I get is 'start on' <rsalveti> no estimation at all <ogra_> hmm <rsalveti> like https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+build/7492026 <rsalveti> mvo: hm, ubuntu-snappy is also ftbfs on i386 for vivid <rsalveti> https://launchpadlibrarian.net/207810741/buildlog_ubuntu-vivid-i386.ubuntu-snappy_1.0.1-1%2B443~ubuntu15.04.1_BUILDING.txt.gz <ogra_> yeah, i just saw the mail <mvo> rsalveti: I noticed but couldn't make sense of the failure yet <ogra_> rsalveti, for the hanging build we should poke cjwatson i think <ogra_> oh, thats a different error ... * ogra_ had some with dependency issues on the weekend <rsalveti> ogra_: yeah, let's wait a bit more and ping him if still stuck <ogra_> yup <rsalveti> yeah, why TestUpdateTimestamp would fail <rsalveti> wonder if a rebuild will make any difference <ogra_> 2015-05-30 02:46:51 ERROR snappy logger.go:199 hello-app.potato failed to install: a package by that name is already installed <ogra_> what about that one ? <rsalveti> wonder if that is testing the error itself <ogra_> does it re-run the test in a loop or some such ? <rsalveti> since the test passed <ogra_> ah <rsalveti> just a guess, didn't yet see the code :-) <rsalveti> let me open a bug for this guy * ogra_ sighs ... i upgraded my laptop to vivid on the weekend ... got close to unusable now :((( <ogra_> constantly to hot (80-90Â°C) <rsalveti> https://bugs.launchpad.net/snappy/+bug/1460650 <ubottu> Ubuntu bug 1460650 in Snappy "(15.04) Rev 443 FTBFS on i386" [Undecided,New] <rsalveti> ogra_: any process in particular eating your cpu? <rsalveti> maybe new browsers <ogra_> no, not at all <rsalveti> vivid is mostly fine for me <ogra_> but starting chromium with no page open bumps the load to 12.00 ... while chromium only takes ~20% of one of the cpu cores (the rest is idle) <ogra_> the frequesncy scaling seems pretty messed up <mterry> mvo, you should open up ownership of lp.net/ubuntu-core-launcher <mterry> Wanted to configure its bug tracker to show its bugs (right now I can't see bugs assigned to it because it's not set up) <sergiusens> nessita: what's the difference between price and prices, if the answer is, 'price' is legacy it's a good answer already :-) <Chipaca> so <Chipaca> on my system <sergiusens> mterry: I just ubuntu bug'ed it <Chipaca> snappy is bailing because it can't read /etc/localtime? <Chipaca> ah, no, it's before that <Chipaca> rats <nessita> sergiusens, correct! (price is legacy and is the price for the default currency( * Chipaca carries on <nessita> __ <nessita> )) <mterry> sergiusens, you did...? <rsalveti> mvo: mterry: just put ubuntu-core-launcher under https://launchpad.net/~snappy-dev <mvo> rsalveti: excellent, thanks <Chipaca> i don't understand this failure :( <ogra_> BAH ... i seem to have half a mobile desktop installed ... no wonder that laptop misbehaves ! <rsalveti> mvo: oh, sorry, I wanted to say that you could put it under ~snappy-dev :-) <rsalveti> only you can change it <sergiusens> nessita: I did.... nothing? <mvo> rsalveti: ups, sure <sergiusens> Chipaca: what's the issue? <sergiusens> Chipaca: btw, can you review my u-d-f change? <Chipaca> sergiusens: snappy internal unpack dies with "operation not supported" <Chipaca> and the strace shows no syscall failure <sergiusens> Chipaca: amd64 or bbb? <Chipaca> sergiusens: mad64 <mvo> rsalveti: updated, the project is now owned by ~snappy-dev <nessita> sergiusens, you meant mterry? <rsalveti> mvo: cool, thanks (mterry ^) <sergiusens> nessita: I did! <mterry> mvo, thanks! :) <sergiusens> mterry: ubuntu-bug ubuntu-core-launcher <rsalveti> but that will use the package bug <sergiusens> rsalveti: yes <Chipaca> the setuid/setgid fails <Chipaca> the setgid, in particular <Chipaca> can i say WAT? <mvo> Chipaca: uh, hope its not something silly as setuid and then setgid :/ in this particular revision <mvo> (i.e. order wrog) <Chipaca> no, it does setgid and then setuid <mvo> wrong even <mvo> ok <Chipaca> and the setgid fails <Chipaca> this is beyond weird, because the snappy we ship works <mterry> mvo, I also see that someone subscribed snappy-dev to snappy bugs. Maybe snapcraft and ubuntu-core-launcher should get the same treatment? <sergiusens> Chipaca: hmm, I face this problem when locally building snappy (I think) <rsalveti> mterry: I did that, yup, makes sense <mterry> rsalveti, thanks! * Chipaca files bug #1460658 <ubottu> bug 1460658 in Snappy "errors returned by syscall are not user-friendly, should not be shipped raw to the user" [Undecided,New] https://launchpad.net/bugs/1460658 <Chipaca> sergiusens: and how did you fix it? <sergiusens> Chipaca: I haven't, sorry * Chipaca -> school run <sergiusens> nessita: can I use the 'id' for a package to get results for it? <sergiusens> nessita: as in using 2277 (id) instead of https://search.apps.ubuntu.com/api/v1/package/beagleblack <nessita> sergiusens, nopes, ID is retured by mistake,never rely on that <mvo> jdstrand: do you know why livecd-rootfs uses the "-M /var/cache/apparmor/.features" flag in ubuntu-touch? this file is not available in our chroot it seems <sergiusens> nessita: so the resource name is always the package_name.origin or alias, correct? <jdstrand> mvo: what is -M an argument to? <mvo> jdstrand: apparmor_parser -M (--features-file) I think <mvo> jdstrand: I'm not sure why its there for touch when they pre-build the /etc/apparmor.d/cache <jdstrand> ah, that is not in the manpage it seems <mvo> yes, I only found it with apparmor_parser -h and have no idea what its doing <jdstrand> mvo: iirc, if you specify a different --cache-loc (-L), then you need to have a .features file in it <mvo> ok <jdstrand> since there is /etc/apparmor.d/cache for system and /var/cache/apparmor for apps, we have a .features file in both <ogra_> echo "I: precompiling click apparmor policies" <ogra_> /sbin/apparmor_parser -M ${FEATURES} -Q --write-cache --cache-loc=/var/cache/apparmor/ `find /var/lib/apparmor/profiles/ -maxdepth 1 -type f -not -path '*/\.*'` <ogra_> (thats from the code) <ogra_> looking in the last image build log it seems to run fine without complaints <ogra_> (touoch that is) <jdstrand> perhaps it is putting a .features file in place so that the compiler will use it instead of querying the kernel? <ogra_> https://launchpadlibrarian.net/207811375/buildlog_ubuntu_wily_armhf_ubuntu-touch_BUILDING.txt.gz <ogra_> i wouldnt know what would put that file there <jdstrand> I think rsalveti and/or jjohansen would know <jdstrand> I know that a .features file is put in place on the running system in each cache directory <jdstrand> the running non-livecd system that is <mterry> tedg, we should try to define a minimal set of snapcraft bits that we think we can move forward with this week <ogra_> jdstrand, what puts it there ? the upstart job ? <jdstrand> and I know you can specify a different features file to adjust cache output <jdstrand> so you could compile caches for another kernel <ogra_> there is definitely no code in livecd-rootfs putting that file in place <ogra_> and i doubt it actually exists in the chroot after bootstrapping <nessita> sergiusens, yes <jdstrand> I'm not sure. I think the parser might <tedg> mterry, Yes, I haven't looked at the current code. I would like to get some stuff starting to work-ish <tedg> mterry, I think we can do that even if all the spec parts aren't perfected. <jdstrand> yes <jdstrand> If cache/.features is missing, create it if --write-cache <mterry> tedg, current code is an empty branch <jdstrand> I'm still going to defer to jjohansen <ogra_> that makes it at least bugfree <tedg> mterry, tabula rasa <ogra_> jdstrand, well, it doesnt seem to do any harm <ogra_> (not sure what mvo's prob is with it) <Chipaca> sergiusens: mvo: it fails when compiled with golang 1.4 (!) <Chipaca> mvo: does this match the failures you were seeing in arm64? <Chipaca> or gogcc <Chipaca> maybe i just need to rebuild my go 1.4 <Chipaca> or switch to wily already <mvo> Chipaca: ohhhh, I have not tried that <mvo> Chipaca: in a meeting right now :/ so can't help just yet <Chipaca> mvo: is this the "15.04.1 release" meeting? <mvo> Chipaca: yes, I almost missed it fighting with gccgo <sergiusens> Chipaca: right, I'm using 1.4 here (locally installed) <Chipaca> sergiusens: vivid's 1.3 worked <Chipaca> sergiusens: locally installed 1.3 also works <Chipaca> I guess I won't be running snappy on my http://wiki.openwrt.org/toh/kingston/mlw221 any time soon <mvo> 16mb flash is going to be hard <ogra_> pfft <ogra_> just write a proper compression that allows pushing 4G into 16M ... <mvo> 4gb of /dev/zero surely <Chipaca> mvo: so, the manifest branch is the one causing the apparmor failures <mvo> Chipaca: the reduce-manifest one? <Chipaca> mvo: yaarp <mvo> ok <elopio> fgimenez: tomorrow I can escape at 11:30, london time. <Chipaca> mvo: still trying to understand why, but i'll get there :) <tedg> Where are the package lists for the default core image? <tedg> seed I guess? <tedg> Is it this? https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu-core.wily <fgimenez> elopio, fine, that is 10:30 my time. i'm already taking a look at the doc <fgimenez> elopio, ping me when you are ready <jdstrand> mvo, Chipaca: if I were to hazard a guess, I would think it has something to do with the 'namespace' changes in click.go <Chipaca> jdstrand: nope :) <jdstrand> oh, what is it? <elopio> fgimenez: great, thanks. <Chipaca> jdstrand: in revision 465 i switched some bits to use the yaml manifest instead of the click manifest <Chipaca> jdstrand: without noticing that things that appeared equal were not so <Chipaca> in my defence, in build we assign the click manifest's Hooks to be the yaml's Integration <Chipaca> but before doing that we do add some things to Integration that are not in the package.yaml <Chipaca> so, I *think* what we want is to grow Integration in the same way every time we load it <Chipaca> I need to check though :) <jdstrand> mvo: fyi, and this doesn't have anything to do with snappy internals, I have adjust the review tools to error if a snap uses 'integration' in its yaml <jdstrand> adjusted* <jdstrand> sergiusens: hey, I'm reflashing my bbb, is udf 0.21-1+174~ubuntu15.04.1 ok to use? <sergiusens> jdstrand: let me check <sergiusens> jdstrand: yes <tedg> So, I thought I'd go to the docs, didn't find my answer there either :-) <tedg> Where is the script/tool/etc that builds the core snap? <jdstrand> sergiusens: thanks <jdstrand> df <tedg> 1243 GB <ogra_> 640k are enough for everyone ! <jdstrand> heh * ogra_ upgrades ubuntu-device-flash * jdstrand hrms <jdstrand> rsalveti, mvo: hello-dbus-app is broken on edge r72. is this the candidate for promotion? <jdstrand> rsalveti, mvo: (on bbb) <damjan> what would it take to port UbuntuCore to the Kindle Paperwhite <ogra_> damjan, depends what bootloader it uses ... if the specs would work etc <damjan> hardware specs? <ogra_> yes <ogra_> you need 4G diskspace and the ability to partition it the right way... we currently only support u-boot on arm as bootloader ... <damjan> it's an 1Ghz imx 508 <damjan> 256MB ram <damjan> there's the 2GB and 4GB flash versions <ogra_> that might eb a little low on ram ... but givenn that there is no UI support in any way yet, perhaps not <ogra_> (i guess for plain cmdline 256M would work) <damjan> afaik it's u-boot <damjan> why does it matter btw? <ogra_> because the automation for rollbacks lives in the bootloader <ogra_> (if you upgrade and something goes wrong the system automatically rolls back to the last working setup) <damjan> it's uboot <jdstrand> rsalveti, mvo: fyi, there is a trello card to add hello-dbus-* to the self tests. if is in 'snappy core stackholders backlog' 'incoming propposals'. I just now added instructions on what to do (should be a very simple test) <jdstrand> rsalveti, mvo: s/if is/it is/ <rroy> Trying to do basic install of docker app on snappy. Installation completes w/o error however a simple `docker ps` fails: <rroy> ubuntu@localhost:~$ sudo snappy install docker Installing docker Starting download of docker.canonical 8.36 MB / 8.36 MB [======================================] 100.00 % 483.05 KB/s Done Name Date Version Developer ubuntu-core 2015-04-10 146 docker 2015-06-01 636-721-3251 ubuntu@localhost:~$ docker ps aa-exec: ERROR: profile 'docker_docker_636-721-3251' does not exist ubuntu@localhost:~$ <rroy> Ugh ... sorry about the formatting. <rroy> As you can see the complaint is regarding a missing "profile" file. I'm guessing I can get away w/ an empty profile file but ... what is the file name/location? <kgunn> seb128: you around ? <seb128> kgunn, yes <rsalveti> jdstrand: ogra_: we only have the features file for touch <rsalveti> ubuntu-touch/includes.chroot/var/cache/apparmor/.features <rsalveti> so I'd guess the pre-cached apparmor stuff is kind of useless for core atm <rsalveti> jdstrand: broken on 15.04/edge? <jjohansen> rsalveti: that does sound broken <jdstrand> rsalveti: yes, r72 <jdstrand> rsalveti: I think it is surrounding the unshare in the launcher because I am getting a disconnected path apparmor denial <rsalveti> jdstrand: and thanks for updating the card, will move it around later today <jdstrand> but it is weird, because it is on run/ <rsalveti> but iirc it was working a few days ago <jdstrand> rsalveti: cool, thanks <jdstrand> I wonder what landed <rsalveti> now don't remember if that was indeed stable or edge <jdstrand> do we have a clear way to see what has changed? <rsalveti> not an easy way, no, ogra_ was working on that <rsalveti> we only got the manifest, but from a few images <jdstrand> I just reflashed my bbb today with edge and got this denial: audit(1433179950.388:19): apparmor="DENIED" operation="connect" info="Failed name lookup - disconnected path" error=-13 profile="hello-dbus-app.canonical_client_1.0.1" name="run/dbus/system_bus_socket" pid=1215 comm="dbus_message.ar" requested_mask="wr" denied_mask="wr" fsuid=1000 ouid=0 <jdstrand> notice 'name=run/...' <jdstrand> that should have a '/' in front of it <rsalveti> indeed <jdstrand> so, we knew we would need to adjust the apparmor template to use 'attach_disconnected' <jdstrand> and in fect, that is done in wily <jdstrand> fact* <jdstrand> but, I wasn't expecting this on 15.04, so I'm curious about the changes that went in <jdstrand> rsalveti: so, the launcher hasn't changed in vivid... <jdstrand> rsalveti: ah, 1.0.2~ppa1 is on the image <rsalveti> right <jdstrand> rsalveti: 'Set up a private mount namespace for /tmp' <jdstrand> so, this means we need a policy update <rsalveti> we use vivid + https://launchpad.net/~snappy-dev/+archive/ubuntu/image <jdstrand> yep, that is where I'm looking * jdstrand sees the old unused libseccomp and deletes it <rsalveti> also noticed we're over the repo size limit in there <rsalveti> maybe because of gcc <jdstrand> oh yeah <jdstrand> rsalveti: so, at this point there is a choice, pull the launcher or have me do a policy update. I'm fine with doing an ubuntu-core-security update-- I can do it tomorrow. this was the other part of the sru I was talking about <jdstrand> rsalveti: but if we go that route, you should block the promotion on that <rsalveti> yeah <rsalveti> jdstrand: that same version is also available in wily (core-launcher) <rsalveti> so I guess we'd need a policy update for both <jdstrand> rsalveti: wily has 1.0.2 <jdstrand> wily already has the policy update <rsalveti> got it <jdstrand> 15.10.1 has: "add attach_disconnected for default policy in preparation of new /tmp <jdstrand> handling" <rsalveti> guess it'd be fine to get this in the ppa and then work on getting the official src in place <jdstrand> that is what I was thinking <rsalveti> cool <rsalveti> jdstrand: do we have a bug for this already? <rsalveti> just so I can put at the milestone <jdstrand> no <jdstrand> I'll file one <rsalveti> awesome, thanks <jdstrand> rsalveti: bug 1460810 <ubottu> bug 1460810 in Snappy "1.0.2 launcher needs corresponding apparmor policy update" [Undecided,New] https://launchpad.net/bugs/1460810 <rsalveti> jdstrand: thanks <jdstrand> rsalveti: fyi, ubuntu-core-security - 15.04.12~ppa1 uploaded to the ppa <rsalveti> jdstrand: awesome, thanks for that <jdstrand> np <rsalveti> got the extra ppa space just in time * Chipaca looks at sys/unix/syscall_linux_arm64.go * Chipaca goes to bed <nessita> sergiusens, so, I have this item to sync with you, about snappy oauth-signing every single request to the index. Any pointers who should I ping about this? <Chipaca> nessita: for snappy? <beowulf> Chipaca: is your snap removed from the store? <Chipaca> beowulf: unpublished <Chipaca> beowulf: should i republish? <Chipaca> people seemed to not like it being there <beowulf> Chipaca: no, it exposed some wonderful errors :) <Chipaca> hee hee :) <beowulf> Chipaca: so i was using it in webdm, then it was unpublished, then i tried to uninstall... <Chipaca> beowulf: webdm doesn't like things disappearing from the store? <beowulf> Chipaca: no sir <Chipaca> *shock* <beowulf> Chipaca: i'm wondering if the store should dissappear metadata, or should webdm handle it, or should i go to bed <beowulf> i think the latter <Chipaca> jdstrand: is https://01.org/intel-kgt relevant to us? <Chipaca> beowulf: the magic 8-ball says "go to bed already" <sergiusens> Chipaca: beowulf this is a similar error to the offline case; I need to fix it <sergiusens> nessita: how soon is that timeline? I think you want to sync with beuno first on the whole concept for ssl/tls #snappy 2015-06-02 <beuno> sergiusens, soon, but orthogonal to ssl/tls <dstokes> is there any way to install packages from file, without having to upload to canonical? <miken> dstokes: yes, you can side-load... let me find the relevant docs <tedg> dstokes, Yes, you just need to set --allow-unauthenticated to avoid it checking for the store key. <dstokes> tedg: what's the command / args for installing? cant find anything in the docs <miken> snappy-remote --url=ssh://you@device install ./hello-world_1.0.5_all.snap <miken> tedg: Is that correct? ^^ That's what I used, from <miken> https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/ <tedg> I haven't used remote, but on the image it's just "snappy install --allow-unauthenticated foo.snap" <tedg> Well, sudo <dstokes> oic <dholbach> good morning <miken> Morning dholbach <fgimenez> good morning <dholbach> hi miken <dholbach> mvo_, sergiusens, rsalveti: do you think anyone of you can reply to seb128's mail on snappy-devel? he's still looking for a way to boot <seb128> dholbach, thanks! yeah, still failing to boot snappy on that uefi machine <seb128> which blocks me for working on the new unity8 desktop snappy iso <mvo_> seb128: I'm not sure what the status here is, we have wily images since yesterday that might help, but in any case I create a card and try to find if I have a machien with uefi bios <seb128> mvo_, hey! where can I get the wily image? I'm happy to try that <mvo_> seb128: sudo ubuntu-device-flash core rolling --channel edge --output wily.img <mvo_> seb128: that should be dd-able <mvo_> seb128: and I added a trello card <seb128> mvo_, ok, great, I'm going to give that a try in a bit and let you know how that works <seb128> thanks! <mvo_> yw <zyga> good morning <beowulf> morning <elopio> good morning. <JamesTait> Good morning all; happy Leave the Office Earlier Day! ð <ogra_> lol <tbr> good moaning <dholbach> ogra_, in the node-snapper example it looks like the tool gets stuck in some point during the installation * tbr starts to write a brief blog post on how to make snappy work on real x86 embedded hardware <dholbach> ogra_, http://pastebin.ubuntu.com/11516722/ <ogra_> dholbach, it compiles <dholbach> then it's compiling for a very long time :) <ogra_> therr should be a spinner in the bottom left though <ogra_> tbr, wheee ! <dholbach> no spinner here <ogra_> then kill it and start over <dholbach> http://pastebin.ubuntu.com/11516757/ - I guess something is happening <ogra_> it uses qemu-arm-static, thats sometimes a little rough <ogra_> whats your host release ? <dholbach> 15.04 <ogra_> (qemu-arm-static stability sadly varies ... it is rock solid in trusty, i saw issues sometimes in utopic and havent built under vivid yet) <ogra_> so if you dont see a spinner, kill it and start over i'd say <ogra_> (we should note that in the doc) <tbr> ogra_: luckily it's fairly simple. install version >x of toos, build image, boot image manually (or by adding startup.nsh), use efibootmgr to set boot order properly (and check on every boot) <dholbach> ogra_, now it succeeds :-/ <ogra_> dholbach, right ... <dholbach> Chipaca, mvo_, do you have an idea what's happening here? http://pastebin.ubuntu.com/11516932/ <dholbach> ogra_, https://code.launchpad.net/~dholbach/node-snapper/not-world-writable/+merge/260806 <dholbach> Chipaca, mvo_: http://pastebin.ubuntu.com/11516978/ <Chipaca> yep <ogra_> dholbach, cool., thanks ... i also noticed yesterday that snappy nor kills the symlinks in $arch/bin/ ... need to find a fix for that one (start-service.sh points to $arch/bin/node which is a symlink to $arch/bin/nodejs) <ogra_> s/nor/now/ <Chipaca> dholbach: remember how we don't support things that are apps becoming frameworks, or viceversa? <Chipaca> dholbach: bottom line, remove the old webdm and install the new one, until we fix that <dholbach> ok <ogra_> for me "snappy update webdm" (on the 15.04 release kvm image) just works <dholbach> I can't quite remember which image it was I used back then <dholbach> "Tags are free form, but some can gain special use, such as an external/ui one which would be picked up by the webdm and used to open the application through the web." <dholbach> ^ is the above true right now? <beowulf> dholbach: what's the source? <beowulf> dholbach: as of this minute, webdm doesn't provide links to external ui, but i don't know what tags are <beowulf> s/but/and <dholbach> beowulf, that's in https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/ <dholbach> (just search for webdm) <beowulf> dholbach: ah right, so the 'ui' tag isn't working right now <dholbach> ok <beowulf> dholbach: it will be by end of today, and then it'll be available on the next version of webdm <dholbach> <3 <elopio> fgimenez: ping, I can start the exploratory now. Are you ready? <beowulf> dholbach: that's much easier to read now :) <beowulf> dholbach: do you know why the icon section says "only SVG"? <dholbach> no, I don't <dholbach> davidcalle, ^ do you know why the icon section on https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/ says "only SVG"? <beowulf> the store converts SVG to PNG, and I don't think we should allow SVG <fgimenez> elopio, yup, ready! <elopio> fgimenez: do you use firefox? want to try meeting using hello? <dholbach> ogra_, can you pull from lp:~dholbach/+junk/chatroom? <dholbach> (can't create an MP for a +junk branch) <davidcalle> dholbach, probably because the branch doc (eg. https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/meta.md) specify the svg format for icons (line25) <fgimenez> elopio, not tried yet, let me set it up <dholbach> davidcalle, ah ok... sorry - it says that in the 15.04 branch as well, just not as "only svg" which I couldn't find in there <dholbach> beowulf, looks like it's currently spec'ed that way, cf https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/meta.md and https://bazaar.launchpad.net/~snappy-dev/snappy/15.04/view/head:/docs/meta.md <elopio> getting some water here and finding a good place. Give me a couple of minutes. <davidcalle> dholbach, beowulf, the doc itself is not from snappy trunk, it's one of the first doc uploaded with the initial snappy announcement, afair it has been reviewed to be kind-of up-to-date with the latest release <davidcalle> I don't know if snappy actually cares about the format, though :) <davidcalle> beowulf, do you know what the plan is for high-res screens and the store? Do we need (or will we need) several png sizes? <elopio> fgimenez: https://hello.firefox.com/zAxKYb3AqB8 <fgimenez> elopio, ok give me a second.. <beowulf> davidcalle: i don't know what the plan is, but the current icon size is 256x256, that's quite large already <elopio> fgimenez: http://pad.ubuntu.com/testing-snappy <ogra_> dholbach, oh, didnt i push that yet ? (i have the same on disk and in the store) .... <davidcalle> beowulf, thanks, can confirm, just tried at 3200x1800, various scalings, looking sharp :) <elopio> fgimenez and I will be doing exploratory testing on snappy here, in case somebody wants to join: https://hello.firefox.com/zAxKYb3AqB8 <dholbach> ogra_, apparently not :) <Chipaca> mvo_: you around? <mvo_> Chipaca: yes <Chipaca> mvo_: hiya! <mvo_> Chipaca: good morning! <Chipaca> mvo_: what happens if a service has no description? <Chipaca> currently we're using the second line of the readme for that <mvo_> Chipaca: a good question - using that is probably not a great idea :/ <Chipaca> but we're only storing it in the click manifest (and in the systemd service file) <Chipaca> until i got to that, i had high hopes of making things work without reverting the "limit click manifest use" branch <mvo_> Chipaca: maybe we should just generate something like "service for {pkgname} - {servicename}" or something <Chipaca> mvo_: "service {servicename} of {qualified name}"? <mvo_> Chipaca: yeah, much better <ogra_> dholbach, pushed this and other changes <Chipaca> k <dholbach> ogra_, and the node-snapper MP? <ogra_> dholbach, no, chatroom <Chipaca> mvo_: not qualified name; we don't know the origin in build :) <mvo_> Chipaca: my brain is still on this gccgo senfile failure, but I think I nailed it now, I feel a bit silly for not spotting the real problem earlier <Chipaca> mvo_: that's good, right? <mvo_> Chipaca: indeed you are right <mvo_> Chipaca: its good that its fixed, not good that I feel silly, but I guess I should relax and celebrate the fix instead :) <ogra_> dholbach, doing node-snapper now ... i'm just totally distracted by http://people.canonical.com/~alan/ogra_loading.gif <Chipaca> mvo_: feeling silly is good <Chipaca> mvo_: because it only happens *after* the "aha" <mvo_> lol <mvo_> very true <dholbach> ogra_, yes, I can imagine <elopio> fgimenez: still 10 minutes to download, it doesn't go down :( <dholbach> ogra_, take your time :) <elopio> and makes the video choppy. I'll go and get more water and the charger... <fgimenez> elopio, np, the video is frozen for me.. ping me when ready <ogra_> dholbach, merged and pushed <dholbach> ogra_, cool, I'll do another test run now <ogra_> wait one sec, i have another change * dholbach waits <ogra_> dholbach, done <elopio> fgimenez: 2 mins. <ogra_> mvo_, http://bazaar.launchpad.net/~ogra/node-snapper/trunk/revision/7 ... why do my symlinks vanish when packaging the snap ? is that intentional ? <elopio> fgimenez: I can see you, but you can't hear me. <elopio> the download is ready. <elopio> I'll rejoin... <fgimenez> elopio, nope, and you are frozen <mvo_> ogra_: I suspect need a update version of snappy, symlinks got fixed by Chipaca some days ago * ogra_ guesses that kind of goes against de-duplication :) <ogra_> ah, cool <mvo_> it was a silly bug * mvo_ notices that its silly to use silly all the time * ogra_ will revert that change once that migrated everywhere then ... <elopio> fgimenez: can you kick me or something? <elopio> It says I can't rejoin. <Chipaca> mvo_: giving up, reverting the manifest thing <fgimenez> elopio, i'm alone in the conversation <mvo_> Chipaca: meh, let me know if I can help in any way :( <Chipaca> unless... <elopio> fgimenez: crazy shit. Now I'm alone in the conversation :) <elopio> fgimenez: lets go to hangouts, this doesn't seem ready: https://plus.google.com/hangouts/_/grwijm4jm7pbk5vu6fg5dgiknaa?hl=es <mvo_> Chipaca: btw, if we ever decide to backport the cp_linux thing to 15.04 you will need to remind me that we need to port the upstream gccgo fix as well <Chipaca> mvo_: or, or, we could make the default non-cp_linux implementation be the fallback <Chipaca> mvo_: but then we'd never find these bugs :) <Chipaca> unless we printed a big fat warning before calling the fallback <mvo_> : <mvo_> :) <dholbach> ogra_, looks like chatroom doesn't start up after installation - do you know how I can debug this? <ogra_> dholbach, syslog ... and you can hack the start script "export NODE_DEBUG=*" <elopio> rsalveti: why is the image in http://cdimage.ubuntu.com/ubuntu-snappy/15.04/edge/ older than the one you get with ubuntu-device-flash? <ogra_> dholbach, did you use the start script unmodified ? <ogra_> dholbach, it might point to node ... if you didnt re-run node-snapper with the last change thats a dead symlink <ogra_> point the script to nodejs instead <dholbach> ogra_, let me check <dholbach> ogra_, still no dice <dholbach> ogra_, how can I emulate the startup of the service? <ogra_> dholbach, show me your start-service.sh <dholbach> ./chatroom.sideload/current/start-service.sh: 27: ./chatroom.sideload/current/start-service.sh: /amd64/bin/nodejs: not found <ogra_> uh <dholbach> ogra_, could it be that "./amd64.." would help there? <ogra_> it uses $SNAPP_APP_PATH/$ARCH/bin/node $MY_EXECUTABLE <ogra_> try dropping a P there <ogra_> seems something changed in the ubuntu-core-launcher that doesnt set the variable anymore <ogra_> (i thought we'd keep that for backwards compatibility ... hmm) <dholbach> ./amd64/bin/nodejs: error while loading shared libraries: libcares.so.2: cannot open shared object file: No such file or directory <ogra_> geez <ogra_> what did you do <ogra_> you see that in syslog when starting it via systemctl ? * ogra_ pushes a change for SNAPP vs SNAP to the branch <sergiusens> beowulf: dholbach yes, tags are true, if a package uses that, webdm will hint it in the package payload <dholbach> ogra_, does it work for you? <dholbach> no... I ran this: <dholbach> (amd64)ubuntu@localhost:/apps/chatroom.sideload/current$ ./amd64/bin/nodejs current/site/server.js <Chipaca> mvo_: do we still support setting apparmor in Integration? <dholbach> not sure if that was the wrong way to do it <ogra_> dholbach, i uploaded it to the store yesterday, yes <ogra_> dholbach, the path to the server.js is wrong ... drop the "current/" there <mvo_> Chipaca: I think we do, we could kill it <ogra_> dholbach, but you cant just run it withouth the ubuntu-core-launcher environment ... use systemctl and syslog <mvo_> i think <Chipaca> mvo_: meh. i've made a note. <dholbach> ogra_, ok, I'll have another look <ogra_> dholbach, also, show me your start-service.sh <dholbach> ogra_, I'll start from scratch - I was just following your instructions <ogra_> me too yesterday :) <dholbach> ogra_, it works! :) <dholbach> shipit! <ogra_> haha <ogra_> note it wonly works properly with chromium * ogra_ just added that info to readme.md <Chipaca> mvo_: still needs tests, but http://bazaar.launchpad.net/~chipaca/snappy/mangle/revision/482?start_revid=482 fixes it; could you take a look and see if the approach seems sane to you? <Chipaca> mvo_: at question is whether i hate clickManifest too much :) <mvo_> Chipaca: looking <mvo_> Chipaca: oh, you can kill the createion of .snappy-systemd in handleServices entirely <mvo_> Chipaca: looks like a good approach, I assume you fix the names ;) ? we should probably do deprecation warnings if we encounter stuff we need to mangle <Chipaca> mvo_: i can? kill snappy-systemd i mean <mvo_> Chipaca: yes, that is only used by the snappy-systemd hook which is no longer in use at all <Chipaca> mvo_: so binaries and services look identical :) <mvo_> heh :) thats good, right? <Chipaca> yep <zyga> hey, is there an api for snappy <zyga> so that I can get stuff like 'snappy list' programmatically without screen-scraping <dholbach> ogra_, I guess there's no way around editing start-service.sh as root, right? <ogra_> dholbach, only by editing it before rolling the snap :) <dholbach> ogra_, the file is owned by root <dholbach> before the rolling of the snap, because node-snapper runs as root <ogra_> ah,. we can change that indeed <zyga> anyone? <zyga> (I'm just after a yes / no answer) <beuno> zyga, yes* <beuno> * sergiusens can tell you more <zyga> beuno: thanks! <zyga> sergiusens: any links on where I can find snappy API? <zyga> sergiusens: (for apps that want to talk to snappy and get data from it) <nessita> beuno, o/ so I mentioned to Sergio the goal to have every request to the store being oauth signed, and he replied that we should first decide on the ssl/tls front <nessita> Chipaca, o/ yes, for snappy <beuno> nessita, I think he's mixing topics <ogra_> zyga, there is work for some REST api ... not sure thats snappy itself or a webdm thing <zyga> ogra_: isn't webdm optional? <zyga> ogra_: I'm looking for alternative to parsing snappy list output <ogra_> zyga, it is optional .. for a remote API you need a webserver though ... which webdm conveniently ships <zyga> ogra_: is app-to-app IPC constrained? <beuno> zyga, the plan is for snappy to provide a rest api, which everything that wants to display data will use <zyga> ogra_: can I write an app that talks to webdm and it will not be broken down the line? <zyga> ok <ogra_> zyga, ask sergio, he designs that :) <beuno> webdm, the cli. etc <zyga> ogra_: will do, thanks! <zyga> sergiusens: I'll be the inner voice in your head <zyga> sergiusens: asking you questions ;) <zyga> ogra_: why is python2.7 on the snappy image btw? is it so that 2.7 webapps can be deployed easily or is there another reason? <ogra_> zyga, by accident ... cloud-init isnt fully ported yet <zyga> ogra_: ah, I see <ogra_> (final target is to get rid of languages ) <zyga> ogra_: and down the line, do you see it becoming a framework of sorts, so that people can do 2.7 webapps? <ogra_> (in the core) <zyga> ogra_: or will it be killed <zyga> ogra_: I see <zyga> ogra_: so all runtimes (perl, pythons) go away and maybe move to frameworks <ogra_> i assume it can be a framework ... or you can just bundle it <zyga> ogra_: are frameworks well defined? is it okay for a framework to ship a language runtime? <ogra_> i'm not so sure :) * ogra_ still hasnt looked at the exact framework definition <zyga> ogra_: is that discussion happening somewhere? <dholbach> ogra_, how do you want to change the permissions? <zyga> ogra_: who makes the calls? <ogra_> in hangouts :P <zyga> ogra_: ok, I'll start showing up in yours <dholbach> ogra_, or shall I just go and write the docs so people use 'sudo' to edit the file? <ogra_> dholbach, oh, i see why that happens, because you chaned world writability :) <ogra_> we could chown the dir to $USER i guess ... shouldnt do harm to the final snap <ogra_> (for the tarball contents and the start script) <ogra_> (snappy chowns everything to the clickpkg user at install time) <dholbach> ogra_, ah yes, that's right :) <dholbach> ogra_, so maybe just change it to $USER once node-snapper is done? <ogra_> yeah, for the arch tarballs before they get tarred up and for the three final files <ogra_> so that the user has all permissionns in case he wants to edit something inside these tarballs manually <dholbach> ogra_, https://developer.ubuntu.com/en/snappy/tutorials/node-to-snap/ - looking good? :) <ogra_> dholbach, in a meeting, gimme a bit <dholbach> ogra_, sure <dholbach> ogra_, I'll hold off of blogging about it for a bit <sturmflut2> https://i.imgur.com/rntFSWS.jpg Awww <beowulf> dholbach: the last paragraph hasn't formatted with a <p> <ogra_> sturmflut2, thats what you get with the intel snap ? <ogra_> cute :) <sturmflut2> ogra_: Yes, a webserver on port 8888 hosting a lot of JavaScript, and I think there's more <sturmflut2> I have to say it was surprisingly painless to boot the Snappy KVM image and install the package <dholbach> thanks beowulf - I'm not sure if I fixed the right way now(?) <ogra_> dholbach, i dont really like the hack in point 6 (where i mv the contents of chatroom/*) ... i wonder if we could make that more elegant <beowulf> dholbach: yep, fixed now :) <ogra_> (that was just a quick hack when elopio found an issue with the original howto, i never cleaned that up) <ogra_> dholbach, but thats only cosmetic, looks great otherwise ! <dholbach> thanks beowulf <dholbach> ogra_, let me think about it <ogra_> it would need some serious re-ordering so we branch into package/ <ogra_> not sure thats worth it <davidcalle> dholbach, do you mind if I make a small layout tweak to your tuto? <dholbach> davidcalle, I'd be happy if you'd do that :-D <davidcalle> dholbach, specifically code -> twelve-col <dholbach> <3 * dholbach writes a quick blog entry <jdstrand> Chipaca, mvo_: fyi, I made it so the review tools error when finding integration in the yaml. that will be in the 0.28 version I am preparing <Chipaca> niiice :) <jdstrand> so +1 on removing it from snappy <zyga> sergiusens: what is snapcraft?> <ogra_> zyga, a magic wand <ogra_> zyga, you want to interview tedg or mterry about it ;) <zyga> ogra_: I tried googling for it but the name kind of hits minecraft instead <tedg> It's a dream :-) <zyga> what is is, in one line? <ogra_> zyga, a magic wand <tedg> zyga, It's the tool we're working on to make building snaps really easy. <ogra_> (in one line ... no wraps) <tedg> zyga, Handle things like pulling in a runtime and packaging it along with your app. <zyga> ah, so ubuntu component store for snappy, kind of? <tedg> Eh, kinda. More like allowing you to use the component stores you're already happy with. Be it PIP or apt or npm. <zyga> sergiusens: quick question for the "by design", I get that security is there by design, I don't disupte that, I'm looking for what the recommendation is for us, should we just ignore confinement and run entirely unconfined or should we seek some options to work within the confinement? <zyga> tedg: is it reasonable to use snapcraft to pull in pulseaudio <zyga> tedg: and make it really work <zyga> tedg: (with hardware access and all the permissions) <zyga> tedg: so that my app can have some sound? <ogra_> sure <tedg> zyga, No, pulse should really be a framework. It's something that shares hardware. <ogra_> no need for snapcraft to do that <zyga> ok <ogra_> https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ <Chipaca> zyga: for a hardware testing tool, i'd expect it to be unconstrained or have a custom apparmor profile <ogra_> that has some hints about HW access <tedg> zyga, Frameworks are more about services that multiplex HW. <zyga> Chipaca, tedg: that both makes sense, thanks <ogra_> orm for system tests you might actually want unconfined, yeah <zyga> I have a feeling we should help drive this so that eg. pulse exists as a framework and we and use it for testing, that python exists as a framework and we can use it (or that snapcraft can bundle it) <ogra_> the latter will be what will happen <zyga> one other idea I had is to have a flag day and rewrite _everything_ on top of some qt api <ogra_> (snapcraft bundling stuff for you) <zyga> but I don't know if that's a good solution even if we did it (does qt really have an API for everything?) <Chipaca> zyga: just to be sure you understand it, frameworks are for hardware access, not for sharing libraries <Chipaca> zyga: having a library in a framework will not enable things that depend on that framework to use that library <zyga> Chipaca: yes, I get that, it's just not clear to me exactly if there will be exactly zero non-hardware frameworks as this seems to be up in the air a little <zyga> Chipaca: ok <davidcalle> dholbach, hah, nevermind, this break numbered lists... Â¯\_(ã)_/Â¯ <zyga> Chipaca: is snapcraft something that I can try now? <mterry> zyga, no <Chipaca> zyga: snapcraft is in the design phase right now. Or vapourware if you will. <zyga> I see <zyga> so while python exists on the image it's not so critical <zyga> it's more important to understand what's down the line and how the roadmap looks like <ogra_> zyga, but if you use some mechanism to bundle your stuff, let the two guys know so they can take that into account in snapcraft :) <zyga> and to know how we plan to fit in <zyga> mterry, tedg: one mechanism we do use now, is to just have a package in a PPA or in the archive (and use known tooling for building it) and to extract bits and pieces from it (.so files) so that we don't have to worry about cross-compilation or daily builds <zyga> as there are no "ppas" for clicks or snaps and many people are working on the project we do rely on some kind of automatic build process <zyga> and limiting that to "run this script and it fetches and repackages stuff from the archive" does simplify it for us * dholbach hugs davi * dholbach hugs davidcalle <zyga> obviously we could rewrite that to build our stuff but then it's a bit more complicated (cross compiling) and time consuming <tedg> zyga, So basically our goal is to make the cross compiling and pulling in dependencies easy. So then you can do that all the time. <zyga> tedg: how do you plan on achieving that? * ogra_ hugs dholbach <tedg> zyga, magic wand :-) <zyga> tedg: and in reality? :-) <zyga> tedg: one thing I'm interested in is this use case <zyga> tedg: you pip install somethig <zyga> tedg: that builds a .so file <zyga> tedg: how do you make that cross-compilable? <tedg> zyga, We plan on doing it by you providing us with a yaml file describing what you want and providing plugins that understand those cases and install them into a snap. <tedg> zyga, We build two of them in and put them in directories appropriate for the architecture they're built for. <zyga> tedg: hmm? <zyga> tedg: I mean, pip, do you plan to patch pip and python to make that work? * dholbach hugs ogra_ back <zyga> tedg: I know theory that it can work, I want to understand if you have any concrete plans for specific cases <zyga> tedg: all python extension build natively so far <zyga> tedg: and it does seem like patch-the-world problem to me <tedg> zyga, We have concrete plans to make that work, we started writing code for it yesterday. <zyga> tedg: without a solution like qemu-arm-static or simiar <zyga> similar* <mterry> zyga, we plan to cross compile in chroots like the sdk does yeah <tedg> zyga, I'm hoping we don't have to patch pip, but if so, we'll work with upstream to make it handle cross-compiling better. <tedg> Honestly, I think that multi-architecture support is something everyone wants (upstreams too) but no one has the time to work on it. It's a priority for us. <zyga> mterry, tedg: I'd love to dogfood anything you can share, my use cases are stuff like python3-lxml2 <zyga> tedg: I agree <zyga> tedg: it's ironic that only debian did it in any sensible capacity <tedg> zyga, Cool, we'll probably harass you in a couple weeks after we start to get things off the ground. We're working with simpler use cases right now to get the basics together. <zyga> tedg: gnu hello? :) <tedg> BSD Hello, we're not handling complex licensing yet ;-) <zyga> haha <zyga> tedg: note that an eula is hardly needed for gnu hello <zyga> tedg: no license needed <dholbach> ogra_, our names are put next to python tutorial thing - is that on your list of things to do right now? <ogra_> python tutorial ? nope <ogra_> i thought barry did one <barry> ogra_: hello? :) <ogra_> i'll have tzo take care for the RPi image for the rest of the week <dholbach> ogra_, barry: I was looking at barry's blog post, but it looks like asac preferred ricmm's approach (https://code.launchpad.net/~ricmm/+junk/example-python-snap/) and we wouldn't have to require python 3.5 <barry> dholbach: python 3.5 isn't required for my approach, it just enables some fancy debugging and hackery <barry> has ricmm published any articles or docs on his approach? <barry> (his is py27 based; i'm firmly py3 :) <barry> also, mine is more of a framework for providing py3 snaps, rather than just an example of one <dholbach> ok... I wasn't siding with any solution, just trying to figure out where to go next <barry> dholbach: sure. let many flowers bloom :) happy to help <asac> dholbach: yes ricmms approach is trivial... works everwhere, doesnt solve everything though, but for getting started its absolutely fine imo <asac> it solves the problem: how to assemble a complete python dependency tree easily. it doesnt solve the native libs etc. parts <asac> or the how to include the intepreter <asac> but since we have python in OS image having that approach as the _simple_ way of getting started sounds good <ogra_> asac, not at all ... if the interpreter is gone from the system all packages that foillowed such a howto will break <ogra_> asac, the point dholbach tries to solve if giving developers something in their hands right now <ogra_> so we either take barry's approach or actually finish ricmm's to pull in the interpreter etc <beowulf> @reviewlist <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir/+merge/260620 | No reviews (3 days old) <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/fix-tests/+merge/260618 | Approve: 1 (3 days old) <nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-banner/+merge/260836 | No reviews (less than a day old) <nothal> https://code.launchpad.net/~stephen-stewart/webdm/link-to-external-ui/+merge/260833 | No reviews (less than a day old) <nothal> https://code.launchpad.net/~stephen-stewart/webdm/remove-not-uninstall/+merge/260775 | No reviews (less than a day old) <dholbach> barry, ^ not sure if you saw the discussion above... <barry> dholbach: nope, thanks <ogra_> beowulf, does the description in webdm come from thr redme.md now (it used to come from the store UI description before) <ogra_> *the <barry> ogra_: that's why i emphasized py3 because it probably will be a while before it
{'channel': 'snappy', 'month': 6}