[07:07] <pitti> mvo: replied to bug 1457491 now, with a solution tested in a wily cloud instance
[07:08] <mvo> pitti: \o/
[07:08] <mvo> pitti: thanks abunch
[07:58] <zyga> good morning :)
[08:03] <zyga> mvo: did you have luck with git-lp yesterday?
[08:04] <zyga> mvo: today will focus entirely on the python3-project plugin, I want to get to a point where separately-installed projects can see each other successfully
[08:04] <zyga> mvo: I have some code but it's not fully working yet
[10:27] <clobrano> hi there, I was wondering if ubuntu core has suspend/hibernate functionality and how to test it
[10:29] <ogra_> clobrano, no, i dont think we have this yet
[10:29] <ogra_> could you file a whishlist bug ?
[10:31] <clobrano> ogra_: sure I can. Could you give me a hint about how to do it? :)
[10:31] <ogra_> there is a link in the channel topic ;)
[10:32] <clobrano> ogra_: oh, that was easy enough :D
[10:32] <ogra_> ;)
[10:34] <ogra_> ppisati, ^^should the kernels theoretically suppport suspend and hibernate ? (i know we dont ship any userspace bits for it currently)
[10:35] <clobrano> ogra_: actually writing on /sys/power/state works
[10:36] <ogra_> clobrano, yeah, but you will most likely not be able to wake it up again
[10:36] <clobrano> ogra_: if you're lucky to have a power button you will :)
[10:37] <ppisati> clobrano: which kernel?
[10:37] <ogra_> well, does it work ?
[10:37] <clobrano> ogra_: yes, it does
[10:38] <clobrano> ppisati: 3.19.0-23
[10:38] <ogra_> oh !
[10:38] <ppisati> ogra_: rpi2 doesn't have any /sys/power/state file, so the answer is no
[10:38] <ppisati> clobrano: which hw?
[10:38]  * ogra_ wouldnt have expected it to work at all
[10:39] <ppisati> ogra_: /me guesses he tested the amd64 img
[10:39] <clobrano> ppisati: I flashed a pendrive and I'm testing on a notebook
[10:39] <clobrano> ppisati: yep
[10:39] <ogra_> ah
[10:39] <ppisati> right, so
[10:39] <ogra_> sorry, my brain is so arm centric :)
[10:39] <clobrano> so no suspend on other systems, right?
[10:39] <ppisati> ogra_: on BBB no, suspend to disk might work but we need the correct fw and a dedicated partition
[10:40] <ogra_> yeah
[10:40] <ppisati> ogra_: on rpi2, at least on this 3.19, there's no power state file, so no again
[10:40] <ogra_> clobrano, right, thats what i would suspect
[10:40] <ppisati> for the BBB the only kernel that supports suspend to ram is the TI one
[10:40] <clobrano> I'll file a whishlist bug then
[10:40] <ogra_> thanks !
[10:40] <clobrano> ;)
[10:40] <ppisati> so either someone try to port all the power management stuff from there, or it will have to use the TI kernel
[10:41] <ppisati> on rpi2, i don;t know, i might do some more research when i'm done with other stuff
[10:42] <ppisati> uhm
[10:42] <ppisati> ubuntu@raspy2:~$ cat /boot/config-3.19.1-12-generic-bcm2709 | grep -i suspend
[10:42] <ppisati> CONFIG_ARCH_SUSPEND_POSSIBLE=y
[10:42] <ppisati> # CONFIG_ARM_CPU_SUSPEND is not set
[10:42] <ppisati> CONFIG_OLD_SIGSUSPEND3=y
[10:42] <ppisati> # CONFIG_SUSPEND is not set
[10:43] <clobrano> mmh, I'd like to test it on my rpi2 as soon as I get home :D
[10:54] <imuguruz_> ogra_: I'm working at Erle Robotics and I'm trying to execute a piece of software we use. The software that is running in Rpi2 or BBB sends data to my laptop through UPD under ethernet. I see that the communication in the RPi2 Snappy is not as reliable as in Snappy BBB. I have executed the same piece of software in Raspbian and works OK. I think something is going on under Snappy in Rpi2
[10:54] <imuguruz_> Not a Linux expert
[10:54] <imuguruz_> thanks
[10:56] <ogra_> imuguruz_, hmm, can you open a bug for it and attach your /var/log/syslog file from the RPi image so we can see if there are any apparmor denials ?
[10:56] <imuguruz_> sure
[10:57] <ogra_> (could well be that the app confinement needs some fine tuning here)
[10:57] <ogra_> a link to the bug page is in the channel topic
[10:58] <imuguruz_> ok
[11:12] <ppisati> ogra_: have you ever tried the 'break=$something' on arm kernels?
[11:12] <ppisati> ogra_: to debug the initramfs i mean
[11:12] <ogra_> not recently, but it should work
[11:12] <ppisati> crap
[11:12] <ppisati> i've a vivid image here
[11:13] <ppisati> and when i try the premount target
[11:13] <ppisati> i don't get any shell
[11:13] <ogra_> the initrd is identical to the amd64 one ... and there i used it this week
[11:13] <ppisati> albeit busybox is there
[11:13] <ogra_> hmm
[11:13] <ogra_> wrong console= args ?
[11:13] <ppisati> uhm no
[11:13] <ppisati> the image boot fine
[11:14] <ogra_> well, what does your cmdline have ? only one console=ttyS0 ?
[11:14] <ppisati> ogra_: i've a lot of stuff there
[11:14] <ogra_> if you have something pinting to tty1 or some such your input wouldnt be taken from the serial console
[11:14] <ppisati> it's the cmd line from the bcm bootloader on the raspi2
[11:15] <ppisati> right
[11:15] <ppisati> i need to trim that forest
[11:15] <ogra_> +1
[11:17] <imuguruz_> ogra_: done
[11:17]  * ogra_ sees bug 1489412
[11:17] <ogra_> thanks !
[11:17] <imuguruz_> you're welcome!
[11:17] <imuguruz_> happy to contribute
[11:22] <ogra_> hmm, no specific denials ... that i would assign to your problem
[11:23] <ogra_> (interestingly a lot others that i wouldnt have expected )
[11:24] <ogra_> jdstrand, could you take a look at the syslog in the above bug ? there are quite some DENIALS for snaps from the store (unrelated to the bug itself, but i think xkcd-webserver should rather be denial-free :) )
[11:25] <ogra_> hmm
[11:27] <ogra_> webdm seems to fail with udp issues too ... i wonder if we have two snaps wrangling over the socket
[11:31] <ogra_> ooh ... i have an idea what it could be
[11:39] <ogra_> imuguruz_, you can try to append "smsc95xx.turbo_mode=N" to the default cmdline in /boot/uboot/cmdline.txt and reboot ? the USB NIC on the RPi2 might drop packages when the turbo mode is enabled
[11:40]  * ogra_ ponders to put that as default into the 15.04.3 image 
[11:40] <imuguruz_> ogra_: ok, will try right now
[11:43] <imuguruz_> ogra_: in /system-boot/cmdline.txt?
[11:44] <ogra_> right
[11:44] <imuguruz_> ok, done
[11:44] <ogra_> (sorry, i was assuming you edit on a running system :) )
[11:44] <imuguruz_> now let's try it
[11:44] <ogra_> yeah
[11:53] <imuguruz_> ogra_: works better but not well
[11:53] <ogra_> hmm
[11:53] <ogra_> do you have many USB devices attached ?
[11:54] <imuguruz_> one, keyboard
[11:54] <imuguruz_> i don't need it, so i'll try again without keyboard and hdmi
[11:58] <imuguruz_> more fluid, but not at as good as in BBB Snappy or Raspbian
[11:58] <ogra_> hmm
[11:59] <ogra_> i dont reallly know what kernel and config raspbian uses ... will have to check that ...
[12:03] <imuguruz_> v 3.18.11-v7
[12:04] <ogra_> we are on 3.19 (and about to switch to 4.x) ... and the version sadly doesnt tell what tree they used
[12:04] <ogra_> but i'll find out
[12:16] <ogra_> imuguruz_, you could try to also add: dwc_otg.dma_enable=1 dwc_otg.dma_burst_size=256  ... i just read that this should improve things alongside disabling the turbo mode
[12:19] <ogra_> http://elinux.org/R-Pi_Troubleshooting#Crashes_occur_with_high_network_load btw ...
[12:56]  * Chipaca wonders why emacs now freezes on startup with "Loading pylint..."
[12:56] <ogra_> it wants to telll you that you should use vim ?
[12:58] <imuguruza> ogra_: ok
[13:01] <sergiusens> Chipaca: I just dropped all those legacy things and moved to notepad.exe under wine
[13:01] <sergiusens> :-P
[13:02] <Chipaca> ogra_: i truly believe that vim and emacs are completely equivalent, and the fact that i use one instead of the other is due to random chance, but switching from one to the other is extremely expensive
[13:03] <sergiusens> Chipaca: it is expensive, I switched to atom one day after getting fed up with vim and it's plugin system; I thought I'd move back but I'm still using atom in vim mode ;-)
[13:04] <Chipaca> it's a bit like why we use D-glucose instead of L-glucose
[13:07] <jdstrand> ogra_: the net-admin is almost certainly bug #1465724 which tyhicks and I discussed here yesterday (kernel bug, harmless). the xkcd one is also harmless. I guess I could put an explicit deny rule in there
[13:07] <nothal> Bug #1465724: net_admin apparmor denial when using Go <Snappy:Confirmed> <http://launchpad.net/bugs/1465724>
[13:08] <bzoltan_> ogra_:  is there a raspberry pi A/B+ image somewhere?
[13:09] <ogra_> bzoltan_, you mean the first gen RPi ?
[13:09] <bzoltan_> ogra_:  yes
[13:09] <ogra_> thats not armv7
[13:10] <bzoltan_> ogra_: yes armv6l
[13:12] <ogra_> bzoltan_, ubuntu doesnt support pre-v7
[13:15] <bzoltan_> ogra_:  I used to have ubuntu on my pandaboard es2 ... in 12.04 the video driver got busted, but in headless mode it was OK
[13:15] <zyga> ogra_: is ubuntu-device-flash a good way to get a devel rpi2 image
[13:15] <zyga> ogra_: or should I get a prebuilt one somewhere?
[13:15] <bzoltan_> ogra_:  sorry for my ignorance, but what is the technical reason of not supporting first gen Pi?
[13:16] <ogra_> bzoltan_, we dont have packagesd that coould run on that ancient arch
[13:16]  * bzoltan_ has two 1stGenRPi boards
[13:16] <ogra_> *packages
[13:16] <sergiusens> we have no archive for that
[13:16] <zyga> bzoltan_: hey man, how are you?
[13:16] <ogra_> zyga, yeah, u-d-f is the best way
[13:16] <zyga> ogra_: on vivid or do I need wily?
[13:17] <bzoltan_> zyga:  hello there ... I started to do a hobby IoT project with RPi :) the new wind you know
[13:17] <ogra_> just grab the device tarball and pi2 snap from http://people.canonical.com/~platform/snappy/raspberrypi2/
[13:17] <ogra_> zyga, it will work on both
[13:17] <zyga> bzoltan_: nice
[13:17] <zyga> bzoltan_: I got a pi2 myself just today
[13:18] <zyga> bzoltan_: though my needs are more mudane
[13:18] <zyga> ogra_: hmm, how do I run it? (what's the release to use? 15.04?)
[13:18] <bzoltan_> zyga: ohh Pi2 I have since it came out ...serving well as media box :)
[13:18] <zyga> bzoltan_: I have 1st gen pi and two beagles
[13:18] <bzoltan_> zyga:  But I want to play with the 1st boards too
[13:19]  * zyga looks up 
[13:19] <bzoltan_> zyga: beagle I have one .. and a panda ... + 4 N810 + 2 N900 +1N950 +N9 :)
[13:19] <zyga> ah
[13:19] <zyga> bzoltan_: I don't have a panda anymore, still have a beagle
[13:19] <zyga> (this turns into a who-has-what contest ;)
[13:19] <ogra_> zyga, udo ubuntu-device-flash core --channel=edge --oem pi2_0.15_all.snap --developer-mode --device-part=device-pi2-0.15.tar.xz -o pi2.img rolling
[13:19] <bzoltan_> zyga: and I just bricked an Arduiono Mini... freaking sensitive piece
[13:19] <zyga> ogra_: thank you!
[13:19] <ogra_> zyga, that would get you a "latest wily" image
[13:20] <bzoltan_> zyga:  Panda I used with Ubuntu desktop :) awesome hw
[13:20] <zyga> ogra_: is that the best image to follow?
[13:20] <zyga> ogra_: e.g. vs 15.04/
[13:20] <ogra_> zyga, udo ubuntu-device-flash core --channel=edge --oem pi2_0.15_all.snap --developer-mode --device-part=device-pi2-0.15.tar.xz -o pi2.img 15.04
[13:20] <zyga> ah, thanks
[13:20] <ogra_> would give you the latest un-QA-ed 15.04 build
[13:21] <zyga> zyga@virtual-fx:~$ sudo ubuntu-device-flash core --channel=edge --oem pi2_0.15_all.snap --developer-mode --device-part=device-pi2-0.15.tar.xz -o pi2.img rolling
[13:21] <zyga> Determining oem configuration
[13:21] <zyga> pi2_0.15_all.snap failed to install: snappy package not found
[13:21] <zyga> hmm?
[13:21] <ogra_> did you download it to $PWD ?
[13:21] <sergiusens> zyga: download that snap ;-)
[13:21] <ogra_> else you need to supply the path
[13:21] <zyga> ahhh
[13:21] <zyga> no
[13:21] <zyga> where from?
[13:21] <sergiusens> zyga: .snap means on disk (we can make that error message clearer)
[13:21] <ogra_> i'll upload it to the store before next 15.04 image
[13:21] <zyga> sorry, I'm a bit of a noob here
[13:22] <ogra_> then you dont need to download anymore
[13:23] <zyga> sergiusens, ogra_: so where's the pi2_0.15_all.snap?
[13:23] <ogra_> at the url i pointed you to above
[13:23] <ogra_> next to the device tarball :P
[13:24] <zyga> ogra_: oh, I missed that
[13:24] <zyga> ogra_: sorry, thanks I get it now
[13:24] <ogra_> :)
[13:46] <imuguruza> ogra_: same as before
[13:46] <imuguruza> thanks anyway for the link
[13:47] <ogra_> imuguruza, hmm, k
[14:20] <sergiusens> elopio: you around and about yet?
[14:40] <zyga> mvo, sergiusens: I think I fixed python3-project plugin
[14:40] <zyga> to work correctly now
[14:40] <zyga> I'll have a branch for review in a moment
[14:40] <zyga> but the simple trick is this: run python3 from stage dir
[14:40] <zyga> use --prefix=/usr
[14:40] <zyga> use --root=installdir
[14:41] <zyga> that seems to do the right thing for what I tried so far
[14:41] <zyga> I'll do some bigger tests in a second
[14:41] <sergiusens> zyga: thanks, I guess this can apply to py2 as well?
[14:41] <zyga> sergiusens: yes
[14:41] <mvo> zyga: woah, you rock
[14:42] <zyga> sergiusens: and if you combine that with setuptools hack
[14:42] <zyga> sergiusens: then it can almost be the pip plugin
[14:42] <zyga> sergiusens: to the point where I wonder if it's better to do a special source URL
[14:42] <zyga> sergiusens: pip:whatever(==version)
[14:42] <zyga> sergiusens: and get the tarball and carry on from there
[14:42] <zyga> sergiusens: I'll try with something that has C extensions next
[14:42] <zyga> sergiusens: as I suspect it's "not that easy" ;)
[14:42] <zyga> but I think this is very promising
[14:43] <sergiusens> zyga: well we need to write a specific pip plugin anyways ;-)
[14:43] <zyga> sergiusens: essentially it now works with dependencies for free
[14:43] <sergiusens> zyga: with setup tools you mean? My hackish solution did get me all the deps without me worrying which was good :-)
[14:44] <zyga> sergiusens: python3-setuptools
[14:44] <zyga> sergiusens: if you use the ubuntu plugin internally
[14:44] <sergiusens> \o/
[14:44] <zyga> sergiusens: anyway, wait, I just need a few more iterations, I just wanted to let you guys know this is close to being universally useful
[14:45] <zyga> sergiusens: the one thing that is still a pain is /usr/bin/python{,3,3.4} shebangs
[14:45] <zyga> sergiusens: that's the ubuntu plugin to fix this though
[14:45] <zyga> sergiusens: those are staright from the package
[14:46] <zyga> sergiusens: alternatively I could build a custom python from debian sources but the fact that sideloading changes paths would break everything
[14:46] <zyga> sergiusens: unless I hard-code --prefix for python to /apps/$name/current/
[14:46] <zyga> sergiusens: but that seems evil
[14:46] <zyga> sergiusens: and racy (current symlink replacement)
[14:46] <zyga> *straight
[14:47] <sergiusens> zyga: I don't mind ignoring the shebang and calling out python[2,3]
[14:47] <zyga> actually... .python has the right sys.prefix
[14:47] <zyga> sergiusens: yeah but that breaks generated scripts
[14:47] <zyga> sergiusens: that sucks a lot
[14:47] <sergiusens> but ideally those shebangs should be clean
[14:48] <zyga> sergiusens: it only works when you run one progam
[14:48] <zyga> sergiusens: and that program never runs anything
[14:48] <zyga> sergiusens: if it runs another (non exposed) program youre SOL
[14:48] <zyga> sergiusens: I can fix setuptools generated scripts
[14:48] <zyga> sergiusens: I wonder what's the (long?) tail that remains after that
[14:48] <zyga> anyway, back to work
[14:50]  * zyga would love for caching to be a bit smarter; rm -rf snap/ stage/ parts; is a slow way to iterate
[15:15] <mindbender1> I asked this question on #ubuntu and was pointed here. So where is snappy used mostly?
[15:16] <mindbender1> A simple Google search us not very clear on this.
[15:16] <imuguruza> mindbender1: you can uset in embedded platforms like BeagleBone Black, RaspberryPi 2 o Odroidc1, for example
[15:21] <mindbender1> Okay so mostly for embedded, small devices, and cloud?
[15:21] <mindbender1> Not very much for desktop.
[15:21] <clobrano> I'm looking at apparmor configuration, but how I can understand which capabilities (I mean, the names of the caps and their context) I need for an app?
[15:24] <zyga> I have a _crazy_ working version
[15:24] <zyga> I'll clean it up
[15:24] <zyga> it now fixes shebangs for python
[15:24] <zyga> for python3-project parts (python2 will be treated the same way)
[15:24] <clobrano> mindbender1: I think Canonical is moving to adopt snappy as package manager even for desktop
[15:31] <sergiusens> elopio: I bumped the build dep
[15:44] <jdstrand> oh, I was going to answer clobrano
[15:57] <sergiusens> zyga: nice
[15:58] <zyga> sergiusens: btw, there's something weird when I snap python3:
[15:59] <zyga> sergiusens: Snapping python3
[15:59] <zyga> cp: uwaga: plik źródłowy „usr/lib/python3/dist-packages/setuptools/script” pojawił się więcej niż raz
[15:59] <zyga> cp: nie można wykonać stat na „(dev).tmpl”: Nie ma takiego pliku ani katalogu
[15:59] <zyga> sergiusens: "source file usr/lib... occurs more than once
[15:59] <zyga> sergiusens: unable to stat "..." no such file or directory
[15:59] <zyga> sergiusens: have you seen that?
[15:59] <zyga> sergiusens: it seems harmless (so faR)
[16:15] <sergiusens> zyga: no, I haven't, let me check
[16:16] <zyga> sergiusens: I patched the python3 part to pull in 'python3-setuptools' and 'python3-pkg-resources'
[16:17] <sergiusens> zyga: s/part/plugin/?
[16:20] <zyga> sergiusens: plugin
[16:45] <zyga> sergiusens: I need an architectural advice
[16:45] <zyga> sergiusens: can a part depend on something from another path
[16:46] <zyga> sergiusens: and if so, should that part look at the stage area or at the uninstalled part?
[16:46] <zyga> sergiusens: in practical terms
[16:46] <zyga> sergiusens: I'd like to force this sequenec:
[16:46] <zyga> sergiusens: part A: build
[16:46] <zyga> sergiusens: part A: stage
[16:46] <zyga> sergiusens: part B: build (can take advantage of A)
[16:46] <zyga> sergiusens: part B: stage
[16:46] <zyga> sergiusens: what do you think?
[16:48]  * zyga found two more bugs in snapcraft 
[16:48] <zyga> quoting :)
[16:58]  * zyga found another bug in part.env() 
[17:01] <zyga> eh
[17:01] <zyga> quoting is fundamentally broken
[17:01] <zyga> sometimes we depend on expansions, sometimes not
[17:02] <zyga> mvo: do you know what's the point of common.run() and assemble_env() there?
[17:02] <zyga> mvo: why not subprocess.check_call()
[17:05]  * zyga smells go in all of that code
[17:05] <zyga> the 0 return codes
[17:05] <zyga> I'd much rather have exceptions really
[17:05] <zyga> it's not pythonic
[17:27] <sergiusens> zyga: isn't that what 'after' is for?
[17:29] <sergiusens> zyga: but mixing parts was a no no... I can revisit as soon as I am more interiorized with snapcraft
[17:30] <zyga> sergiusens: mmmm, so how would you expect python libraries to work together?
[17:31] <zyga> sergiusens: would you (offtopic) accept de-goification patches that remove non-pythonic code like return subprocess.call(...) == 0 ?
[17:32] <sergiusens> zyga: lol de-goification; I don't know who wrote this code originally (but I think either of the folks who did knew more about python), but yeah, I added a bunch of tasks that involve cleanups
[17:32] <zyga> sergiusens: fantastic, so I won't hold back
[17:32] <zyga> sergiusens: thanks
[17:33] <zyga> sergiusens: so please tell me how you think python parts should work
[17:33] <zyga> sergiusens: and I'll have a nice set of patches for you
[17:33] <zyga> sergiusens: (including fixing all the shell quoting bugs in the code)
[17:33] <sergiusens> zyga: https://trello.com/search?q=%23technical in case you want to go crazy
[17:34] <zyga> mmm
[17:34] <zyga> nice
[17:36] <zyga> sergiusens: if python parts cannot meaningfully depend on each other, then the part that pulls in the top-level thing will need to pip-install (equivalent) everything
[17:36] <zyga> sergiusens: now the question is
[17:36] <zyga> sergiusens: is it the right assumption that nobody will ship more than one part like that
[17:36] <zyga> sergiusens: so my snap has parts A and B (both python3-projects, for example)
[17:37] <zyga> sergiusens: and they technically both depend on the C library
[17:37] <zyga> sergiusens: should it get bundled twice?
[17:37] <zyga> sergiusens: and if so, this would require major changes to how it's done now
[17:37] <zyga> sergiusens: as each A an B would essentially bundle python with a special prefix
[17:37] <zyga> sergiusens: what do you think
[17:41] <sergiusens> zyga: I think the key here is in using the 'after' keyword
[17:41] <sergiusens> zyga: in a C/autotools whatever app, you can do something like depend on another part being built; take a look at my wiki branch for a quick example
[17:42] <zyga> sergiusens: mmm, I'll try, I used requires: but that didn't stage them
[17:42] <zyga> sergiusens: I'm fine with after if it works
[17:43] <sergiusens> zyga: http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/snapcraft/yaml.py#L120
[17:44] <zyga> sergiusens: I've been there :-)
[17:44]  * zyga tries
[17:44] <sergiusens> zyga: maybe the python plugin needs to extend PYTHONPATH into he env
[17:44] <zyga> sergiusens: yeah, I already did that
[17:44] <zyga> my patch is pretty big now
[17:44] <zyga> more like 3-4 different things there
[17:45] <sergiusens> zyga: yeah, I always have that problem. I just split after, I gave up on using pipelines as I end up putting everything in the same pipe as I start getting excited :-P
[17:48] <zyga> sergiusens: hmm, I must be missing somethnig, it's not staging things
[17:49] <zyga> sergiusens: snapcraft.yaml: http://paste.ubuntu.com/12207670/
[17:50] <zyga> sergiusens: output of snapcraft build http://paste.ubuntu.com/12207680/
[17:50] <zyga> sergiusens: (I need to introduce you to python3-guacamole)
[17:50] <sergiusens> zyga: I think I saw a g+ post
[17:50] <sergiusens> ;-)
[17:50] <zyga> sergiusens: 0.10 has some amazing features coming up
[17:51] <zyga> sergiusens: here, my patched python3-application part/plugin is trying to run python3 from stage directory
[17:51] <zyga> sergiusens: as that's where everything is supposed to be, er, staged, right?
[17:52] <zyga> sergiusens: the whole build sequence (correct me if I'm wrong) feels like [part.build() for part in parts]; I'm still unsure how stage works
[17:52] <sergiusens> zyga: iirc, staging happens after all parts have built, use after, but on line 83 we should see an extended PYTHONPATH
[17:53] <sergiusens> you said you added that already?
[17:53] <zyga> sergiusens: yes, but it's not working, Python3ProjectPlugin.env() is not getting called
[17:53] <zyga> sergiusens: but wait
[17:53] <zyga> sergiusens: it's irrelevant, it's not going to work this way
[17:54] <zyga> sergiusens: each python3project part needs _staged_ python3
[17:54] <zyga> sergiusens: will after enforce that?
[17:54] <zyga> sergiusens: did I mess up the snapcraft.yaml
[17:54] <sergiusens> zyga: nope
[17:54] <zyga> ahh
[17:54] <sergiusens> zyga: and nope
[17:54] <zyga> okay
[17:54] <zyga> mmmmm
[17:54] <zyga> so .. how would you feel about incremental staging?
[17:54] <zyga> it'd be hard to point parts at un-staged python3
[17:55] <zyga> and then point that python3 at each un-staged python3project part
[17:55] <sergiusens> zyga: I would need to take that to the architects, here's me channelling it through rsalveti ^
[17:55] <zyga> sergiusens: okay, thanks
[17:55] <zyga> sergiusens: in the meantime, I have a way out:
[17:55] <zyga> sergiusens: use one python3project
[17:55] <zyga> sergiusens: and solve deps internally with pip
[17:56] <zyga> sergiusens: so snapcraft.yaml will really only list one part
[17:56] <sergiusens> zyga: I think that would be the defacto path forward
[17:56] <zyga> rsalveti: I' love what you think about this
[17:56] <zyga> sergiusens: this feels broken anyway, since parts are not reusable
[17:56] <sergiusens> zyga: as pip is on the roadmap for pluginizing
[17:56] <zyga> sergiusens: yeah, I wonder how it would solve this issue
[17:56] <zyga> sergiusens: what I have now is equivalent to pip
[17:56] <zyga> sergiusens: I _do_ handle deps like pip does now
[17:56] <sergiusens> zyga: yeah, not in python at least, they are in c/c++
[17:57] <zyga> sergiusens: wait, what? I'm lost -- how would the upcoming pip plugin solve this exact issue
[17:57] <zyga> sergiusens: would it also allow one big part
[17:57] <zyga> sergiusens: or would it try to solve the many-parts problem?
[17:58] <sergiusens> zyga: one big part, just like when using go.
[17:58] <zyga> sergiusens: and if I have one big part
[17:58] <zyga> sergiusens: and I want another big part
[17:58] <zyga> sergiusens: I cannot get that because unlike go, there's no static linking
[17:58] <zyga> sergiusens: and you'll get file conflicts
[17:58] <zyga> sergiusens: this smells like a design issue
[17:58] <zyga> sergiusens: parts cannot be mixed together
[17:59] <zyga> sergiusens: __unless__ each pip part uses custom prefix and bundles python
[17:59] <zyga> sergiusens: that would be pretty tragic though IMHO
[17:59] <sergiusens> zyga: that is solved in the stuff I'd be working on if I wasn't talking here :-) (conflicting files)
[17:59] <zyga> sergiusens: so identical files won't conflict?
[17:59] <zyga> sergiusens: that'd be great
[18:00] <zyga> sergiusens: okay, thanks for all your time
[18:00] <zyga> sergiusens: I will iterate tomorrow, I still think that without incremental staging this cannot be solved
[18:00] <zyga> sergiusens: (runtimes need to run)
[18:28]  * rsalveti reading backlog, back from lunch
[18:36] <rsalveti> zyga: a part can depend on another part by using after
[18:36] <rsalveti> and the plugin itself can handle the dependencies/reuse of parts
[18:36] <rsalveti> to avoid conflicts, we do need to flatten the dependencies, each as a normal part
[18:36] <rsalveti> but that is not yet done
[18:37] <zyga> rsalveti: I'd like to understand how that interacts with staging, e.g. a in incremental build process (librarya, libraryb, program[liba, libb]) will need a common staging area to discover other pieces
[18:37] <zyga> rsalveti: for the case where I care (python3) sergiusens pointed me to an upcoming design document
[18:38] <rsalveti> right, a part is built separately but it can stage the resulted binaries and libraries
[18:38] <zyga> rsalveti: and I suspect that will be enough
[18:38] <zyga> rsalveti: so if you agree that staging can be incremental (part after part) then I'm in agreement and I see no problems
[18:38] <rsalveti> right
[18:38] <rsalveti> don't see why not
[18:38] <zyga> rsalveti: excellent, I'll work on that with sergiusens
[19:00] <elopio> ogra_: when is this released? https://code.launchpad.net/~mvo/snappy-hub/lp1480248-norootwait/+merge/269032
[19:38] <mvo> elopio: it was in the review queue in the store, I now approved it
[19:45] <elopio> mvo: great, thanks.
[20:57] <sergiusens> elopio: do we need to install python3-jsonschema manually https://code.launchpad.net/~sergiusens/snapcraft/validation/+merge/269120/comments/677688 ?
[20:57] <sergiusens> elopio: python3-mccabe would be good there too
[21:59] <elopio> sergiusens: I've installed them.
[22:03] <sergiusens> elopio: \o/
[22:06] <sergiusens> elopio: btw, now that you are back https://code.launchpad.net/~sergiusens/snapcraft/icon-meta/+merge/269446 ;-)
[22:31] <zyga> re