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