| === chihchun_afk is now known as chihchun | ||
| pitti | mvo: replied to bug 1457491 now, with a solution tested in a wily cloud instance | 07:07 |
|---|---|---|
| ubottu | bug 1457491 in Snappy "Upgrade from r41 to r55 on BBB failed to boot and also to failover (drops into rescue systemd mode)" [High,Triaged] https://launchpad.net/bugs/1457491 | 07:07 |
| mvo | pitti: \o/ | 07:08 |
| mvo | pitti: thanks abunch | 07:08 |
| zyga | good morning :) | 07:58 |
| zyga | mvo: did you have luck with git-lp yesterday? | 08:03 |
| 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 | 08:04 |
| clobrano | hi there, I was wondering if ubuntu core has suspend/hibernate functionality and how to test it | 10:27 |
| ogra_ | clobrano, no, i dont think we have this yet | 10:29 |
| ogra_ | could you file a whishlist bug ? | 10:29 |
| 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:31 |
| clobrano | ogra_: oh, that was easy enough :D | 10:32 |
| ogra_ | ;) | 10:32 |
| ogra_ | ppisati, ^^should the kernels theoretically suppport suspend and hibernate ? (i know we dont ship any userspace bits for it currently) | 10:34 |
| clobrano | ogra_: actually writing on /sys/power/state works | 10:35 |
| 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:36 |
| ppisati | clobrano: which kernel? | 10:37 |
| ogra_ | well, does it work ? | 10:37 |
| clobrano | ogra_: yes, it does | 10:37 |
| 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:38 | |
| 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:39 |
| 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:40 |
| ppisati | on rpi2, i don;t know, i might do some more research when i'm done with other stuff | 10:41 |
| 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:42 |
| clobrano | mmh, I'd like to test it on my rpi2 as soon as I get home :D | 10:43 |
| 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:54 |
| 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:56 |
| 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:57 |
| imuguruz_ | ok | 10:58 |
| 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:12 |
| 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:13 |
| 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:14 |
| ppisati | right | 11:15 |
| ppisati | i need to trim that forest | 11:15 |
| ogra_ | +1 | 11:15 |
| imuguruz_ | ogra_: done | 11:17 |
| * ogra_ sees bug 1489412 | 11:17 | |
| ubottu | bug 1489412 in Snappy "RPi2: connection not realiable" [Undecided,New] https://launchpad.net/bugs/1489412 | 11:17 |
| ogra_ | thanks ! | 11:17 |
| imuguruz_ | you're welcome! | 11:17 |
| imuguruz_ | happy to contribute | 11:17 |
| ogra_ | hmm, no specific denials ... that i would assign to your problem | 11:22 |
| ogra_ | (interestingly a lot others that i wouldnt have expected ) | 11:23 |
| 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:24 |
| ogra_ | hmm | 11:25 |
| ogra_ | webdm seems to fail with udp issues too ... i wonder if we have two snaps wrangling over the socket | 11:27 |
| ogra_ | ooh ... i have an idea what it could be | 11:31 |
| 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:39 |
| * ogra_ ponders to put that as default into the 15.04.3 image | 11:40 | |
| imuguruz_ | ogra_: ok, will try right now | 11:40 |
| imuguruz_ | ogra_: in /system-boot/cmdline.txt? | 11:43 |
| 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:44 |
| imuguruz_ | ogra_: works better but not well | 11:53 |
| ogra_ | hmm | 11:53 |
| ogra_ | do you have many USB devices attached ? | 11:53 |
| imuguruz_ | one, keyboard | 11:54 |
| imuguruz_ | i don't need it, so i'll try again without keyboard and hdmi | 11:54 |
| imuguruz_ | more fluid, but not at as good as in BBB Snappy or Raspbian | 11:58 |
| ogra_ | hmm | 11:58 |
| ogra_ | i dont reallly know what kernel and config raspbian uses ... will have to check that ... | 11:59 |
| === chihchun is now known as chihchun_afk | ||
| imuguruz_ | v 3.18.11-v7 | 12:03 |
| 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:04 |
| 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:16 |
| ogra_ | http://elinux.org/R-Pi_Troubleshooting#Crashes_occur_with_high_network_load btw ... | 12:19 |
| * 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:56 |
| imuguruza | ogra_: ok | 12:58 |
| sergiusens | Chipaca: I just dropped all those legacy things and moved to notepad.exe under wine | 13:01 |
| sergiusens | :-P | 13:01 |
| 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:02 |
| 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:03 |
| Chipaca | it's a bit like why we use D-glucose instead of L-glucose | 13:04 |
| 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:07 |
| ubottu | bug 1465724 in Snappy "net_admin apparmor denial when using Go" [High,Confirmed] https://launchpad.net/bugs/1465724 | 13:07 |
| bzoltan_ | ogra_: is there a raspberry pi A/B+ image somewhere? | 13:08 |
| ogra_ | bzoltan_, you mean the first gen RPi ? | 13:09 |
| bzoltan_ | ogra_: yes | 13:09 |
| ogra_ | thats not armv7 | 13:09 |
| bzoltan_ | ogra_: yes armv6l | 13:10 |
| ogra_ | bzoltan_, ubuntu doesnt support pre-v7 | 13:12 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| * 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:19 |
| 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:20 |
| 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:21 |
| ogra_ | then you dont need to download anymore | 13:22 |
| 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:23 |
| zyga | ogra_: oh, I missed that | 13:24 |
| zyga | ogra_: sorry, thanks I get it now | 13:24 |
| ogra_ | :) | 13:24 |
| imuguruza | ogra_: same as before | 13:46 |
| imuguruza | thanks anyway for the link | 13:46 |
| ogra_ | imuguruza, hmm, k | 13:47 |
| sergiusens | elopio: you around and about yet? | 14:20 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| * zyga would love for caching to be a bit smarter; rm -rf snap/ stage/ parts; is a slow way to iterate | 14:50 | |
| mindbender1 | I asked this question on #ubuntu and was pointed here. So where is snappy used mostly? | 15:15 |
| 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:16 |
| 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:21 |
| 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:24 |
| sergiusens | elopio: I bumped the build dep | 15:31 |
| jdstrand | oh, I was going to answer clobrano | 15:44 |
| === jkridner|work is now known as jkridner | ||
| sergiusens | zyga: nice | 15:57 |
| zyga | sergiusens: btw, there's something weird when I snap python3: | 15:58 |
| 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) | 15:59 |
| sergiusens | zyga: no, I haven't, let me check | 16:15 |
| zyga | sergiusens: I patched the python3 part to pull in 'python3-setuptools' and 'python3-pkg-resources' | 16:16 |
| sergiusens | zyga: s/part/plugin/? | 16:17 |
| zyga | sergiusens: plugin | 16:20 |
| zyga | sergiusens: I need an architectural advice | 16:45 |
| zyga | sergiusens: can a part depend on something from another path | 16:45 |
| 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:46 |
| * zyga found two more bugs in snapcraft | 16:48 | |
| zyga | quoting :) | 16:48 |
| * zyga found another bug in part.env() | 16:58 | |
| zyga | eh | 17:01 |
| zyga | quoting is fundamentally broken | 17:01 |
| zyga | sometimes we depend on expansions, sometimes not | 17:01 |
| 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:02 |
| * 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:05 |
| sergiusens | zyga: isn't that what 'after' is for? | 17:27 |
| sergiusens | zyga: but mixing parts was a no no... I can revisit as soon as I am more interiorized with snapcraft | 17:29 |
| zyga | sergiusens: mmmm, so how would you expect python libraries to work together? | 17:30 |
| zyga | sergiusens: would you (offtopic) accept de-goification patches that remove non-pythonic code like return subprocess.call(...) == 0 ? | 17:31 |
| 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:32 |
| 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:33 |
| zyga | mmm | 17:34 |
| zyga | nice | 17:34 |
| 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:36 |
| 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:37 |
| 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:41 |
| 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:42 |
| sergiusens | zyga: http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/snapcraft/yaml.py#L120 | 17:43 |
| 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:44 |
| 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:45 |
| zyga | sergiusens: hmm, I must be missing somethnig, it's not staging things | 17:48 |
| zyga | sergiusens: snapcraft.yaml: http://paste.ubuntu.com/12207670/ | 17:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 17:59 |
| 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:00 |
| * rsalveti reading backlog, back from lunch | 18:28 | |
| 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:36 |
| 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:37 |
| 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 | 18:38 |
| === erkules_ is now known as erkules | ||
| elopio | ogra_: when is this released? https://code.launchpad.net/~mvo/snappy-hub/lp1480248-norootwait/+merge/269032 | 19:00 |
| === jkridner_ is now known as jkridner | ||
| mvo | elopio: it was in the review queue in the store, I now approved it | 19:38 |
| elopio | mvo: great, thanks. | 19:45 |
| 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 | 20:57 |
| elopio | sergiusens: I've installed them. | 21:59 |
| sergiusens | elopio: \o/ | 22:03 |
| sergiusens | elopio: btw, now that you are back https://code.launchpad.net/~sergiusens/snapcraft/icon-meta/+merge/269446 ;-) | 22:06 |
| zyga | re | 22:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!