#snappy 2015-09-01 <dholbach> good morning <mvo> elopio: hi, if you are still up, I wonder if I should top-approve sergios branches for snapcraft or if he prefers to do that himself <mvo> hey dholbach, good morning <dholbach> thanks mvo <fgimenez> good morning <zyga> good morning <Chipaca> goood morning! <ogra_> mvo, do we want to wait til there is any feedback on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791661 for the SRU of bug 1323732 ? seems a user has issues creating users in 15.04 (on the ML) <ubottu> Debian bug 791661 in shadow "support for alternative passwd location (i.e. libnss-extrausers)" [Wishlist,Open] <ubottu> bug 1323732 in adduser (Ubuntu Vivid) "adduser should support managing additional password/shadow/group files from libnss-extrausers" [Undecided,New] https://launchpad.net/bugs/1323732 <ogra_> or should we perhaps just push it to the PPA <mvo> ogra_: this is in wily, no? <mvo> ogra_: aha, you mean for 15.04? yeah, going the ppa route is fine here I think <Chipaca> mvo: o/ <Chipaca> mvo: so, comapreDirs <mvo> hey Chipaca <Chipaca> mvo: compares the output of ls <mvo> Chipaca: no, compardirs is terrible <Chipaca> mvo: that's a huge red flag <Chipaca> but <Chipaca> BUT <mvo> Chipaca: I was wondering about https://code.launchpad.net/~mvo/snappy/snappy-lp1468831-race/+merge/269155 <Chipaca> because it's a controlled test scenario <Chipaca> it wouldn't be too terrible <Chipaca> however <Chipaca> it's comparing the ctimes, which we don't care about <Chipaca> isntead of the mtimes or the atimes which we apparently do care about <mvo> oh, sorry, I get it now, its connected <Chipaca> also it * mvo shuts up and listens * Chipaca derails <Chipaca> i was going to say "also it compares the time format instead of asking ls to use something smarter", but i'm not sure that would be a win <Chipaca> I mean, you can tell ls to --time-style=+%s for example * mvo nods <Chipaca> but if we're just comparing for equality that's fine <Chipaca> and, given the comment about atime/mtime in RSyncWithDelete, I think we *do* care about equality <Chipaca> so that means the test is wrong, and the fix is hiding it instead of fixing it :) <Chipaca> so <Chipaca> rant mode off <Chipaca> fix mode on <Chipaca> i guess what we want is to have ls print the atime and the mtime, if those are truly what we care about <mvo> yeah, absolutely agreed, I will reject the branch <Chipaca> hm, ls can't print both atime and mtime at the same time <elopio> fgimenez: ping. I made some good progress on the subunit repo. Can you please check the pull requests? https://github.com/elopio/subunit/pulls <elopio> I couldn't find how to do something like prerequisits in git, so if you don't start from the older it might be a mess. <fgimenez> elopio, ok np i'll take a look <Chipaca> mvo: default for ls is mtime (i thought it was ctime, for some reason), so we're not preserving it in RSyncWithDelete? <mvo> Chipaca: hm, its using cp -a <Chipaca> mvo: but for single files <Chipaca> mvo: directories it's making itself * Chipaca wonders why that isn't a single cp call <Chipaca> ah, because of the filesareequal check <Chipaca> so <Chipaca> i know how to unbreak the test, now :) <mvo> yeah, the dirs are indeed missing <mvo> yay, thanks Chipaca <mvo> and sorry for the trouble :/ <Chipaca> hah. no worries. <Chipaca> sorry for the rant <mvo> all good, terrible code there <Chipaca> yuss <Chipaca> mvo: how does http://pastebin.ubuntu.com/12244247/ look? <mvo> Chipaca: much nicer <Chipaca> mvo: OTOH i could move that to CopyFile <Chipaca> mvo: and just use CopyFile here <Chipaca> but maybe make it different branches * Chipaca agrees with himself already <mvo> heh <mvo> cleanup++ <Chipaca> mvo: https://code.launchpad.net/~chipaca/snappy/fix-1468831/+merge/269728 would be that then <mvo> \o/ <Chipaca> mvo: not top-approving because integration tests <Chipaca> oooh, mp failed? <mvo> helpers/helpers.go:503: impossible type assertion: <mvo> *syscall.Stat_t does not implement os.FileInfo (missing IsDir method) <mvo> looks like it <Chipaca> dah <Chipaca> mvo: forgot .Sys() :( <Chipaca> mvo: fixed <Chipaca> mvo: in https://code.launchpad.net/~mvo/snappy/lp1480248-test-reenable/+merge/269176 you say elopio's comment is addressed, but .. you forgot to push it? <mvo> Chipaca: indeed, sorry again * Chipaca takes a break <sergiusens> mvo: thanks for the reviews! <ogra_> sergiusens, wrt bug 1490741 ... shouldnt u-d-f bail out when using a RPi2 snap with a generic tarball ? <ubottu> bug 1490741 in goget-ubuntu-touch (Ubuntu) "ubuntu-device-flash creates an rpi2 image that won't boot" [Undecided,New] https://launchpad.net/bugs/1490741 <ogra_> or did i do something rong with the meta data in the pi2 snap ? <ogra_> *wrong <sergiusens> ogra_: it shouldn't fail, no; it will use the one from s-i <ogra_> thats bad <sergiusens> ogra_: that is the catch to --developer-mode, no hand holding <sergiusens> ogra_: yeah, you need to put this upstream ;-) <ogra_> ah <ogra_> yeah, i think we need a mechanism to define what device tarballs an oem snap can be used with <sergiusens> ogra_: how would you start enabling a board if not? <sergiusens> ogra_: well, with what mvo is doing right now and with what I did here http://blog.sergiusens.org/posts/Recovering-Ubuntu-Core/ that is no longer going to be necessary <ogra_> oh, it should all be open while developing ... but package.yaml should have an optional enttry that can bind us to a certain device tarball <sergiusens> ogra_: but the device tarbal is just a tar <ogra_> currently :) <sergiusens> ogra_: when it becomes a snap, I hope the gadget would define it <ogra_> yeah <sergiusens> ogra_: since it would be pulled from the store, so it needs the name * ogra_ turns the u-d-f task on the bug invalid but keeps the snappy one open then * Chipaca is trying to figure out https://code.launchpad.net/~fgimenez/snappy/setenv-closure-redefinition/+merge/269717 * ogra_ twiddles thumbs waiting for shadow to be published in the PPA <fgimenez> Chipaca, yes, it's a bit involved :) <fgimenez> Chipaca, in build_test we used var definitions for testing the dependency calls <Chipaca> mhmm <Chipaca> fgimenez: but here's the thing <Chipaca> fgimenez: a var is not a closure <Chipaca> there's nothing to "refresh" <fgimenez> Chipaca, well, maybe the wording is not correct, we first define the var here http://bazaar.launchpad.net/~fgimenez/snappy/setenv-closure-redefinition/view/head:/_integration-tests/testutils/build/build.go#L46 <fgimenez> Chipaca, when we call this afterwards, it doesn't take the value of the environment variables if we don't redefine it <fgimenez> Chipaca, this used to work before 1.5 <Chipaca> hmm <Chipaca> fgimenez: and you get the same error every time without this change? <fgimenez> Chipaca, yep <Chipaca> fgimenez: and if you do "export GOMAXPROCS=1" before running the test? <fgimenez> Chipaca, let me try.. <Chipaca> fgimenez: because what changed was that in 1.5 GOMAXPROCS defaults to the number of cores; before it was 1 <Chipaca> fgimenez: and getenv is per-process * Chipaca writes a small testcase to check this just in case <fgimenez> Chipaca, ah! ok, shouldn't GOARCH be the same for all of them? <fgimenez> Chipaca, i'm getting this http://paste.ubuntu.com/12244578/ after removing the var redefinition line <Chipaca> fgimenez: i'll dig into it in a bit <fgimenez> Chipaca, ok thanks! :) <Chipaca> oooooh <Chipaca> fgimenez: shouldn't osGetenv return something? <Chipaca> i mean <Chipaca> fgimenez: in the tests <Chipaca> fgimenez: you're rewriting osGetenv <Chipaca> fgimenez: with fakeOsGetenv <Chipaca> fgimenez: that does not return anything <Chipaca> i.e. it always returns an empty string <Chipaca> fgimenez: may i suggest you keep an environ map[string]string in the test, and set things in it from fakeSetenv, and return things from it in fakeGetenv? <fgimenez> Chipaca, yes that makes a lot of sense, let me take a look <Chipaca> actually making it a map[string]struct{string, int, int} would be the way I'd do it, actually <Chipaca> fgimenez: i'll show you what i mean in a diff, give me a few <Chipaca> fgimenez: something like http://pastebin.ubuntu.com/12244793/ might work, but it would involve changing a number of tests appropriately <Chipaca> fgimenez: advantage of this is you have a single place where you track reads, writes and current value of the environment <Chipaca> fgimenez: disadvantage might be that it's a bigger change from where the code is right now <Chipaca> fgimenez: whereas the simpler change would be http://pastebin.ubuntu.com/12244813/ <Chipaca> fgimenez: i feel it'll make things harder to follow in the long term, but not particularly strongly :) <Chipaca> fgimenez: also note you would have spotted this error earlier if you didn't use the "bare return" thing as much as you do <fgimenez> Chipaca, yep :) thanks for that, i was thinking in the latter option that you proposed, i'll put hands on it <Chipaca> fgimenez: in both cases note i haven't tested the code :) <fgimenez> Chipaca, np :) * Chipaca is now on lunch break <Chipaca> pitti: i have the silliest systemd question, and sadly for you your name is soldered to systemd in my mind <pitti> hey Chipaca -- heh :) <pitti> Chipaca: you could ask anyone in the vast systemd maintenance team in Ubuntu! <Chipaca> pitti: if I do, e.g.,: sudo journalctl -u urfkill -o json-pretty <Chipaca> pitti: it returns a series of lines, with a json document per line <Chipaca> um <Chipaca> json, not json-pretty <Chipaca> :) <Chipaca> pitti: json-pretty to read it, json to parse it :) <Chipaca> pitti: anyway. you get that, a series of json objects <pitti> right <pitti> looking at it here, for systemd-udevd, as i don't have urfkill <Chipaca> pitti: in the first one, the systemd unit is in the "UNIT" key <Chipaca> pitti: in the following ones, it's in "_SYSTEMD_UNIT" <Chipaca> pitti: this feels like a bug <Chipaca> pitti: but I don't know <pitti> Chipaca: it for sure is <Chipaca> *gasp* <pitti> I mean, I don't see how this would be deliberate <Chipaca> well, it's certainly not what's documented :) * Chipaca updates his system just in case <pitti> Chipaca: it's the same with -o verbose or export, i. e. not just a presentation problem; I guess it's actually wrong in the db <pitti> yep, should always be _SYSTEMD_UNIT as per systemd.journal-fields(7) <Chipaca> pitti: i wonder whether it's different on purpose, so you get the unit the first time and don't bother if it's not there because it's the same? <Chipaca> that sounds contrieved though <Chipaca> and aggregates poorly <pitti> yeah <pitti> Chipaca: do you mind filing it at https://github.com/systemd/systemd/issues or should I proxy it for you? <Chipaca> pitti: i wouldn't mind filing it <pitti> Chipaca: cool, thanks; if this is blocking you I'll see to fix it this week, but I suppose it's easy enough to work around for now? <Chipaca> it is <Chipaca> pitti: it's also only the first one for any service, for you? <pitti> Chipaca: yes, consistently (tried 3) <pitti> Chipaca: in a fresh VM I see two UNIT=, though <pitti> but either way, this is inconsistent and undocumented <Chipaca> pitti: I'll file the bug, you add that to it :) <pitti> ack <Chipaca> pitti: https://github.com/systemd/systemd/issues/1106 <pitti> Chipaca: thanks, I'll watch what upstream says and if appropriate look into it <Chipaca> pitti: ta <Chipaca> pitti: there you go then <pitti> Chipaca: ah! so this is "message from pid 1 about unit foo" vs. "message from unit foo" <Chipaca> pitti: yep, so it might be a bug in documentation as opposed to implementation <Chipaca> as the docs don't mention UNIT nor any other mysterious "couple of other keys" <pitti> Chipaca: yeah, I just followed up wrt. that <Chipaca> heh. jinks. <Chipaca> jinx* <Chipaca> anyway, you know what time it is? <Chipaca> time for a cuppa tea <pitti> and again <pitti> Chipaca: good idea! <pitti> Chipaca: I was about to yell "Tool time!" :) <rickspencer3> is there a bug # for snappy-remote install doesn't work with webdm? <Chipaca> pitti: do you know what they mean wrt trusted/untrusted fields? <pitti> "Fields prefixed with an underscore are trusted fields, i.e. fields that are <pitti> implicitly added by the journal and cannot be altered by client code." <Chipaca> pitti: where's that? <pitti> Chipaca: in man systemd.journal-fields <Chipaca> pitti: gotcha <ted> sergiusens, Do you have a snapcraft branch where you're removing the ubuntu plugin? <pitti> Chipaca: so, a client using libsystemd journal_* can set arbitrary fields, but not those prefixed with _ <Chipaca> pitti: k :) <sergiusens> ted: not pushed yet <sergiusens> ted: still in the works (writing tests) <ted> sergiusens, Can you push so I can base off of that? <Chipaca> rickspencer3: how does it not work? <Chipaca> rickspencer3: http://pastebin.ubuntu.com/12246078/ <rickspencer3> Chipaca, the last time I tried it, it didn't work, and I was told that it was a bug <rickspencer3> oh <Chipaca> rickspencer3: ah, maybe sergiusens knows more then <rickspencer3> Chipaca, I did $snappy-remote install --url=ssh://webdm.local or something <rickspencer3> Chipaca, oh <rickspencer3> no, you are installing webdm <rickspencer3> I meant installing a different snap using webdm <rickspencer3> instead of the ip address <ogra_> you mean using avahi ;) <ogra_> (webdm.local is an avahi address, perhaps the go implementation that the webdm package ships has issues) <Chipaca> I think it's snappy-remote doing something smart with --url that does not include avahi <Chipaca> it also does not hand it straight off to ssh, which means you can't use fake ssh hostnames <ogra_> also note that you can only have the same avahi address once in your network ... i.e. if you have a BBB on the same network running another webdm instance that calls for issues <Chipaca> *also* also note I don't think avahi will work to kvm <Chipaca> mvo: wrt bug 1491011, if your snappy doesn't have a service, you don't have the fix. If it does have service, and you're seeing this, then caca. <ubottu> bug 1491011 in Snappy "[webdm] fails to start webdm on rpi2 if no network is attached" [Undecided,New] https://launchpad.net/bugs/1491011 <mvo> Chipaca: uh, I'm not sure I understand, thats webdm, it has a service <Chipaca> mvo: yes <Chipaca> mvo: what does "snappy service status webdm" print * Chipaca forgot the 'status' verb <ogra_> i think i said before that i dont think it is wrong if webdm doesnt start when no network is available <mvo> Chipaca: its on 15.04, do we have snappy service there already? <ogra_> what *is* important though is that it starts as soon as you connect network <Chipaca> mvo: then you don't have the network brouhaha fix :) <mvo> Chipaca: aha! <mvo> Chipaca: now I understand <Chipaca> mvo: it's not backported, and landed in wily together with "service", hence that question <mvo> Chipaca: cool, do you happen to remember the bugnumber? <mvo> Chipaca: I can have a look in a bit then <Chipaca> bug 1466672 <ubottu> bug 1466672 in Snappy 15.04 "webdm failed to start / Failed to listen 507-653-2812:5353" [Undecided,New] https://launchpad.net/bugs/1466672 * Chipaca hugs --fixes <Chipaca> mvo: ^ <mvo> ta <mvo> I will do a backport in a bit <ogra_> zyga, you had issues wirth missing firmware IIRC ... there is a http://people.canonical.com/~ogra/snappy/test/device-pi2-0.16.tar.xz that contains all of linux-firmware now <ogra_> (in case you feel like trying it) <Chipaca> zomg, next week school starts again <elopio> fgimenez: I'm not sure how to make an anonymous struct inside a for. <elopio> that sounds scary too. <elopio> fgimenez: I was copying the style from here: https://github.com/golang/go/wiki/TableDrivenTests <fgimenez> elopio, yes :) it's just to replace the flagtest var definition in that example with the struct itself, readability could suffer though <fgimenez> elopio, i've seen an example here http://talks.golang.org/2015/tricks.slide?utm_source=golangweekly&utm_medium=email#12 <tedg> sergiuse1s: Not sure if it got lost in the various disconnects, can you push your branch so I can build on it? <elopio> fgimenez: yes, -1 for that. Maybe I'm too used to testscenarios. <tedg> sergiuse1s: Should be fine without tests for what I need. <elopio> what I think we should do is to add scenarios to go check. <fgimenez> elopio, that would be great <zyga> ogra_: thanks a lot, I'll check it out <ogra_> thanks <sergiuse1s> tedg: oh, I don't think I can share just yet, still not glued in <tedg> sergiuse1s: Hmm, okay. The problem I'm running into is needed a global package library. Putting things in python-project causes them to conflict with python the base one. <sergiuse1s> tedg: I think I understand, going to start the drive back home, we can continue then <tedg> sergiuse1s: K <tedg> barry: Reading through the pip docs and learning about wheels. Do you think we need to support those in Snapcraft? <tedg> Not sure how often they're used, or if everyone just uses the source versions. <barry> tedg: yes, i think so. the python ecosystem is definitely transitioning to wheels, although for python modules which include extension modules (e.g. sharedlibs), it's problematic on linux. there's ongoing discussions about how that will work. pure python, np <tedg> barry: Okay. But as I'm reading more that seems separate from pip though, right? Pip can just build wheels? <fgimenez> nice evening everyone o/ <barry> tedg: yes. pip will build wheels, although our debuntu version of pip is in serious need of an update (it's on my todo) <tedg> barry: Is there any reason I'd want to have pip build wheels and install from those? Seems like a no-op for our purposes. <ogra_> mvo, hmm, did i hand you https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1490608 yet ? i know you asked for it <ubottu> Launchpad bug 1490608 in parted (Ubuntu) "parted allows to fix broken GPT only interactively" [Undecided,New] <mvo> ogra_: yes, you mentioned it and I failed to look at it <ogra_> i guess thats foundations material anyway, no ? <mvo> well, yes, I would still guess if someone of us does it it will be faster <mvo> they are usually super busy <ogra_> nah, they just pretend to ... its all scripted :P <barry> tedg: it may not matter in practice. i think pip wheelifying packages is mostly an implementation detail <ali1234> o/ <ogra_> hey ali1234 <ali1234> so my problem is essentially that i want all the read-only goodness of snappy, but my hardware is designed around the raspberry pi model a+, and the 2b simply won't fit <ali1234> debian jessie appears to have the same version of golang and ubuntu 15.04 <ogra_> http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/current/vivid-preinstalled-core-armhf.manifest ... <ogra_> thats the list of files ... <ali1234> i've seen those manifest files <ali1234> but no idea what to do with them <ali1234> like, what tkes the list and builds an image? <ogra_> you would want to build them on raspbian <ali1234> i'd expect most of them already exist <ali1234> raspbian has literally everything debian has afaik <ogra_> we use live-build to build the images ... with modifications and configs living in the livecd-rootfs package <ogra_> there is an old project of mine that i'm about to re-vivie for "building at home" <ogra_> https://launchpad.net/project-rootstock-ng <ali1234> hah, rootstock, i remember that <ogra_> that should allow you to build a rootfs <ogra_> beyond the rootfs you need a device tarball http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/current/ check the armhf one here ... <ali1234> what does that do? <ogra_> carry kernel, firmware blobs and modules <ali1234> rootfs just manages updates and things? <ogra_> no <ogra_> snappy manages the updates <ogra_> currently using the same mechanism the phones use (system-image) <ogra_> soon switching away from that ... (everything becomes a snap ) <ogra_> beyond rootfs and device tarball you need an oem snap ... that has your bootloader setup <ogra_> once you have these three you can feed them into ubuntu-device-flash which generates an image for you <ogra_> out of these three files <ogra_> your prob will be that you cant really use the store, even if you get it up and running ... <ali1234> yeah... i've seen the ubuntu-device-flash stuff too <ali1234> i'm not concerned about using the store, i want to package my own software <ogra_> all binaries in the store are built for armhf indeed <ali1234> my only dependency is gstreamer <ali1234> which i assume i'd have to bundle anyway <ogra_> yeah <ali1234> so step 1 would be to check if debian has all the packages from the device image manifest and then port any that are missing? <ogra_> right <ogra_> a lot of the magic is in the initrd, in the snappy binary and in systemd units ... <ali1234> "system-image-snappy-common" - bet debian doesn't have that... <ogra_> (nad in the bootloader setup too) <ali1234> is that package the snappy tool itself? <ali1234> no, that's ubuntu-snappy <ogra_> i think the ubuntu-snappy package buulds it <sergiusens> tedg: oh, you are working on the pip plugin, no wonder your questions, I guess you missed the comment, but zyga was close to having a pip plugin in place <ali1234> okay well that's something to be going with, thanks <ogra_> ali1234, just come back if you have more questions (you surely will) ... i'm curious how that experiment turns out :) <tedg> sergiusens: Oh, okay. Perhaps I should look at a different one then. That was at the top of the backlog. <sergiusens> tedg: well no worries if you decide to tackle it, not sure zyga has the same agenda we do, but he said he was close <tedg> sergiusens: I can pause what I'm doing to talk to him tomorrow (I think he's EU timezone) and start on another plugin. <tedg> sergiusens: I think that we really want to have the shared root ubuntu package support for it, otherwise you have to play with the python plugin. <tedg> sergiusens: Which really doesn't make a lot of sense. <tedg> Haha, I lose. The ROS instructions depend on pip :-) <rickspencer3> does anyone know any tricks regarding getting wifi to work on the bbb? <ogra_> rickspencer3, plugging in a device we ship the deriver for and following https://wiki.debian.org/WiFi/HowToUse#Command_Line should be enough i think <ogra_> *driver <rickspencer3> hmmm, I think I did that <ogra_> is the device detected ? do you see an interface for it in /proc/net/dev after you plugged it in ? <pindonga> hi, I'm getting this from snapcraft when building a package using the ubuntu plugin... any idea what I'm missing? no repository found in /etc/apt/sources.list or sources.list.d at /usr/bin/dget line 355. <rickspencer3> ogra_ <rickspencer3> $ ls /proc/net/dev <rickspencer3> /proc/net/dev <ogra_> cat <ogra_> (meow :) ) <rickspencer3> just lo and eth0 <ogra_> ah, smells like either the driver or some sirmware is missing <ogra_> *frimware <ogra_> bah ! <ogra_> check syslog when plugging it in <rickspencer3> ogra_, http://pastebin.ubuntu.com/12247479/ <ogra_> rickspencer3, ah, ralink ... <rickspencer3> ogra_, not supported? * rickspencer3 sobs <rickspencer3> I bought it on a whim because it was specifically supported by bbb debian <ogra_> no, just a constant source of pain :) <rickspencer3> ogra_, sorry, I don't quite grock, are you saying I am out of luck with this particular dongle? <ogra_> seems to need the mt7601u module <rickspencer3> ogra_, ok, what should I do? buy a different dongle? <beuno> rickspencer3, some guy on the mailing list had the same problem <beuno> there might not be a dongle that has the module in our kernel <ogra_> rickspencer3, gimme a bit to read up about it :) <rickspencer3> well, I know that at least one person got at least one dongle working with rpi2 and snappy <beuno> rickspencer3, yeah, the rpi2 kernel comes with some modules <ogra_> hmm, so it should be supported by rt2800usb ... <ogra_> which we also ship in the device tarball <rickspencer3> ogra_, well, this image is oooold <ogra_> (on RPi2 the firmware is missing though ) <ogra_> rickspencer3, uname -r ? <rickspencer3> (BeagleBoneBlack)ubuntu@localhost:~$ uname -r <rickspencer3> 3.19.0-23-generic <ogra_> not that old then <rickspencer3> well, I run updates :) <ogra_> try sudo modprobe rt2800usb <ogra_> and see if that thinks it knows the device (re-plug if needed) <rickspencer3> lol <rickspencer3> $ try sudo modprobe rt2800usb <rickspencer3> -bash: try: command not found <ogra_> haha <rickspencer3> ogra_, I reran cat /proc/net/dev <rickspencer3> still just lo and eth0 <ogra_> and syslog <ogra_> (also after re-plugging with the module loaded) <rickspencer3> Sep 1 18:46:29 localhost kernel: [ 1300.551733] usbcore: registered new interface driver rt2800usb <ogra_> nothing else <ogra_> ? <ogra_> even when re-plugging the device ? <rickspencer3> ogra_, no, everything looks the same <ogra_> the musb-hdrc error in your paste actually indicates a deeper prob with USB i think <rickspencer3> /proc/net/dev, syslog, etc... <rickspencer3> awesome! <ogra_> i guess thats one for ppisati <ogra_> rickspencer3, if you want to try the same on the RPi, i have a device tarball in preparation that contains all wifi firmware we have at http://people.canonical.com/~ogra/snappy/test/device-pi2-0.16.tar.xz ... perhaps the Pi works better here <rickspencer3> ogra_, ok, rpi2 is coming up next <ogra_> the beagle musb issues are legendary :) * rickspencer3 finishes transferring bbb to new case <ogra_> and as old as homers oddisey i think <rickspencer3> ogra_, not sure what you mean, is it something that we need to fix generally, is it just my specific dongle? <ogra_> rickspencer3, there are general issues with USB on BBB since forever <rickspencer3> ogra_, right, but are you saying we are out of luck on bbb, or that we need to hack around the issues? <ogra_> it got a lot better over the years but there are still issues <ogra_> well, forst of all you should file a bug and let ppisati know <ogra_> so he can take a look <rickspencer3> ogra_, anything else useful I can add to this? <rickspencer3> https://bugs.launchpad.net/snappy/+bug/1491094 <ubottu> Launchpad bug 1491094 in Snappy "wifi USB dongle fails to work" [Undecided,New] <ogra_> rickspencer3, i extended the subject line and will point paolo to it tomorrow <rickspencer3> thanks ogra_ #snappy 2015-09-02 <seshu> hello <zyga> good morning <dholbach> good morning <fgimenez> good morning <dholbach> mvo, hey hey <dholbach> can you kick off a build of https://code.launchpad.net/~snappy-dev/+recipe/snapcraft-daily? <dholbach> why is it not set to automatic? <dholbach> or daily <dholbach> or whatever the setting is <mvo> dholbach: sure, let me check why its not automatic <dholbach> <3 <mvo> fixed and triggered a new build <dholbach> mvo, https://code.launchpad.net/~dholbach/snapcraft/build-deps-syntax/+merge/269853 * mvo hugs dholbach <ogra_> ppisati, mind to take a look at bug 1491094 ? <ubottu> bug 1491094 in linux (Ubuntu) "wifi USB dongle fails to work with musb-hdrc error" [Undecided,Incomplete] https://launchpad.net/bugs/1491094 <dholbach> mvo, once it's merged we can try to build the branch again ;-) <ppisati> ogra_: BBB? or rpi2? <ppisati> ogra_: i guess the first <dholbach> mvo, merged <ogra_> ppisati, yeah ... <ogra_> ppisati, sadly rick seems to be back on US timezone, so it might take a bit to get a full syslog <ppisati> ogra_: do you know if he receive just a single warning or more than one? <Chipaca> *yawn* <Chipaca> mo'in people <ogra_> ppisati, i had him re-plug it a few times and he said thats all that is printed in syslo <ogra_> g <ppisati> ogra_: so just a single warning, i guess <ogra_> as i understand it it should use the rt2800usb ... but seems the kernel doesnt even get that far <ogra_> (we also tried plugging with the module manually loaded which according to rick made no difference at all ... ) <ppisati> and on a x6 box, it worked, right? <ppisati> testing on a vivid kernel would be awesome <ogra_> i thinnk so ... <ppisati> *x86 <ppisati> let me add some comments to the lp bug <ogra_> cool, thanks <ppisati> this thing <ppisati> "Product: Ð" <ppisati> this is particularli scary <ogra_> thats minicom i bet <ogra_> (getting the actual syslog would likely help a lot) <ogra_> ppisati, there is another bug where your input might help ... bug 1489412 <ubottu> bug 1489412 in Snappy "RPi2: connection not realiable" [Undecided,New] https://launchpad.net/bugs/1489412 <ogra_> i'm notz really sure what to do with it ... turning off turbo mode on the NIC seems to help a little, but doesnt make the issue go away <ppisati> ogra_: so, about the smsc9xx there <ppisati> ogra_: i spinned a new kernel with min_free = 32k <ppisati> and i rebased on the latest 3.19 stable <ppisati> ogra_: but i didn't update the meta yet <ogra_> ah, cool, i'll make sure to pull that in for 15.04.3 <ppisati> ogra_: when is the release? <ogra_> my script doesnt use the meta, it just pulls the newest binary kernel from your PPA <ogra_> not sure <ogra_> mvo, do we have some schedule for 15.04.3 ? <ogra_> or ETA <mvo> ogra_: I'm not aware of one <ogra_> ppisati, so the debian way then :) when its ready <ppisati> :( <ppisati> i would like to have some testing before we mass deploy <ppisati> you know... <ogra_> (which means if you want something specifically, we can hold it back for that) <ogra_> well, we can indeed ask for testing and haven people use the 15.04 edge channel <ppisati> about the first bug, i have a match for that usb vendor/product id on a 4.2 wily kernel: <ppisati> drivers/net/wireless/mediatek/mt7601u/usb.c: { USB_DEVICE(0x148f, 0x7601) }, <ppisati> but i don't have that match on 3.19 <ppisati> and <ppisati> Documentation/usb/hotplug.txt: USB_DEVICE (vendorId, productId) <ogra_> ah <dholbach> https://code.launchpad.net/~dholbach/snapcraft/require-ant/+merge/269864 <dholbach> hey rsalveti, I was playing around with snapcraft a bit more - do you think I should triage the list of open bugs right now and tag the ones which have to do with first user experience or something, so we can have all of them in one list? if yes, which name should we use? <dholbach> mvo, ^ too <dholbach> https://code.launchpad.net/~dholbach/snapcraft/require-ant/+merge/269864 is a quick fix I could do myself :) <guest42315> Snappy Ubuntu Core on Banana Pi BPI-M2 http://forum.banana-pi.org/t/snappy-ubuntu-core-on-banana-pi-bpi-m2/432 <ogra_> guest42315, nice ! <Chipaca> pitti: script -qfc <pitti> Chipaca: heh, nice trick! do you know how much overhead that has? <Chipaca> pitti: about 23 <Chipaca> maybe 24 <pitti> I mean per line/read/block <pitti> (what's that unit?) <Chipaca> pitti: sorry, i was being mean. I have no idea of overhead, but I don't think it's much. It does create a file. <pitti> script -qfc "sh -c 'sleep 30 & echo payload'" /dev/null |cat <pitti> even that works <pitti> but this unifies stdout and stderr, doesn't it? <Chipaca> hm, probably <Chipaca> is that bad? <pitti> ah yes, it does <pitti> I need to keep them separate/intact, yes <pitti> but it's a nice trick anyway for other use cases, much simpler than using redirection and tail -f <pitti> and having to clean up tail <pitti> so thanks for the trick! <Chipaca> pitti: and if you take it deeper? <Chipaca> pitti: e.g. script -qfc '1>stdout 2>stderr commands here' <pitti> I played around with exec, redirections, fifos, bash's <(command) all morning; it's ridiculously difficult <pitti> Chipaca: yeah, and then tail -f them both; that's what autopkgtest does on the "outside", as that only needs to be set up once per test <pitti> but once for every single command is heavier (and also it's brittle as hell), so I was hoping there was something simpler <Chipaca> ah, you probably also want -e, to get the exit code of the process <pitti> it took me two months or so to get that "background tail -f" robust enough, and it's still far from perfect <Chipaca> pitti: are you ssh'ing in, or how are you running these things? <pitti> Chipaca: depends on the backend; "schroot", "lxc-attach", "ssh", or via a socket for Qemu's case (serial console) <Chipaca> uff <Chipaca> pitti: for ssh, a simple -t works <Chipaca> ie ssh -t yadda yadda <Chipaca> pitti: what you want is to have a tty <pitti> right, with PTYs there's no problem <Chipaca> pitti: but it's simple enough, i think, in C <Chipaca> pitti: so maybe you need to write a little C :) <pitti> yeah, in C it wouldn't be a problem at all <pitti> just that I can't assume that I'm able to compile anything on the target <Chipaca> then write C :) <pitti> my testbed could be a read-only phone or snappy without even a compiler <Chipaca> pitti: it's standard library C; you can cross-compile it without breaking a sweat <pitti> Chipaca: well, setting that up (lots of C code and making autopkgtest depend on lots of cross compilers and dynamically shoveling binaries to the testbed) sounds a lot harder than my ugly 15 lines of "kill leftover processes" shell hack :/ <Chipaca> arm-linux-gnueabihf-gcc-4.9 -Wall -o blah blah.c && scp/put/cp/whatevs && etc <pitti> maybe perl <pitti> perl-base is still essential <Chipaca> pitti: I'd expect you to say that two months ago, before spending two months on tail :) <ogra_> pitti, store the PIDs in a file and loop over it with kill when the parent dies ? <ogra_> via a trap cleanup command ... <Chipaca> pitti: perl works, also, i think <pitti> anyway, quite a number of people have answered, and I found some related discussions on various forums <pitti> so at least I'm now reasonably sure that I wasn't missing something obvious <Chipaca> ogra_: you'd have to strace -f to grab all the clones & forks <ogra_> Chipaca, well, or just start everything through a wrapper function <Chipaca> pitti: "try" from libio-pty-perl's examples is probably a good place to start <Chipaca> anyway. to lunch. <ogra_> ogra@anubis:~/datengrab/images/snappy$ sudo ubuntu-device-flash core --channel edge --device device-pi2-0.16.tar.xz --oem pi2.canonical --developer-mode --install webdm -o kvm-rolling.img rolling <ogra_> [sudo] password for ogra: <ogra_> WARNING: this option should only be used to build azure images <ogra_> Determining oem configuration <ogra_> great ... <ogra_> now if it could tell me *WHICH* option "this option" is :P <ogra_> ah, obviously --device ... <tbr> debug output is overrated <ogra_> heh <rickspencer3> hey, is there an easy way to change the channel that my bbb is on? <rickspencer3> I think I'd like to get daily updates on it <ogra_> rickspencer3, no idea if that works ... but try system-image-cli --switch (with a lot of -vvv to increase verbosity) * rickspencer3 tries <ogra_> i guess switching channels will become easier as soon as we dropped system-image <rickspencer3> ogra_, does it not need an argument for the channel to switch to? <ogra_> sure, like on the phone <ogra_> (up to you want you want to switch to) <rickspencer3> ogra_, so, I want to switch to 15.04 edge, is there somewhere that shows me how to formulate that argument? <ogra_> ubuntu-core/15.04/edge ... <ogra_> note that this channel is on manual though <ogra_> only gets builds if we upload changes to the PPA or before a release <rickspencer3> manual is good for edge, I think <rickspencer3> ogra_, oh, is there a better channel if I want to test latest bug fixes, etc...? <Chipaca> fwiw, channel switching is Not Supported <ogra_> wily ... ubuntu-core/rolling/edge ... that has daily builds but also the highest chance of breaking <ogra_> Chipaca, i think it worked for me last time on RPi ... but cant roll back or some such <rickspencer3> ogra_, so, the argument is ubuntu-core/rolling/edge ? <ogra_> yes <Chipaca> i'm not saying it won't work; i'm saying if it works, huzzah, but if it breaks oh well :) <ogra_> yeah <rickspencer3> and it will get automatically update each day, and maybe break a lot? <ogra_> i dont remember what was broken on my RPi test ... but iirc it initially worked ... and either didnt upgrade or didnt roll back anymore <rickspencer3> I guess I can just get another sd card and put a more stable version on it :) <ogra_> yeah <rickspencer3> looks like it is trying to upgrade it :) <rickspencer3> [systemimage] Sep 02 12:35:29 2015 (1239) Upgrade path is 155 :) <rickspencer3> (note the ":)" is mine <ogra_> well, we should add more smileys to log output :) <ogra_> you could then also indicate error severity through them ;) <ogra_> :/ <- bad ... :( <- severely bad ... X( <- totally dead <rickspencer3> ogra_, that would be brilliant <rickspencer3> or just emojis <rickspencer3> says it is rebooting, I'll take that as a good sign <ogra_> well, UTF8 is often broken in serial terminal apps :) <ogra_> but yeah, emojis would rock <rickspencer3> emoticons it is, let's get the spec started ;) <rickspencer3> well, it didn't reboot itself * rickspencer3 reboots, braces for impact <rickspencer3> ogra_, so, it rebooted and my led blinking snap started! <rickspencer3> I take that as a good sign <rickspencer3> is there a way for me to confirm that I am now on the channel that I wanted to be on? <ogra_> rickspencer3, sudo snappy list -v <ogra_> abd system-image-cli -i <rickspencer3> ubuntu-core 2015-07-29 4 ubuntu* <rickspencer3> ubuntu-core 2015-09-02 155 ubuntu <ogra_> seems it didnt switch <rickspencer3> oh? <rickspencer3> oh well, I guess I'll just set up a new sd card with the right channel later <ogra_> * indicates the active one <rickspencer3> at least it didn't hose my board <ogra_> you can force the swtich ... one sec <ogra_> fw_printenv |grep ^snappy_ab <ogra_> what does that print ? <rickspencer3> (BeagleBoneBlack)ubuntu@localhost:~$ fw_printenv |grep ^snappy_ab <rickspencer3> Cannot access MTD device /boot/uboot/uboot.env: No such file or directory <ogra_> oh <ogra_> hmm, you said this install is old .. <ogra_> seems it is really old :) <rickspencer3> ogra_, if this is going to become a yak shaving exercise, I suggest that we call channel switching "unsupported" and I can flash a new sd card at my leisure <ogra_> we *do* call it unsupported ;) <rickspencer3> well, right, that's my point ;) <ogra_> but you are running into issues with an ancient bootloader setup <rickspencer3> ok, sounds like a reflash is in order anyway, then <ogra_> it wouldnt even switch on normal upgrade i fear <ogra_> yeah <rickspencer3> are there any docs on how I would use use snappy config? <ogra_> well, it isnt very user friendly yet <rickspencer3> I want to write a snap where you can define the gpio pin to use after installing the snap <ogra_> you need to create a yaml file and pipe it into the command <rickspencer3> ogra_, so, I could write go code that takes an argument in a form post <rickspencer3> uses that to write a yaml file <ogra_> i think sergiusens had some demo code for that <ogra_> piping from a here doc <rickspencer3> then pipes that yaml file in snappy config? <ogra_> oh, if you want to do it on image level you should be able to define it in the package.yaml of a custom oem snap <rickspencer3> ogra_, no, I want to do it on the snap level <rickspencer3> i.e. the snap is in the store <ogra_> (where you would also define your app snap as a requirement) <rickspencer3> then it can be configured to use the specified gpio pins <ogra_> ah, right, yeah , then you need to create a yaml file and run snappy config manually after install <rickspencer3> so the end user will have to edit the yaml file on the board and run the command <rickspencer3> ouch <ogra_> nah, it will be more userfriendly <ogra_> but this is the status quo <ogra_> we have to many other construction areas atm ... config is only very basic yet <rickspencer3> ok, I'll look at sergiusens code when he wakes up if he can point me to it :) <sergiusens> rickspencer3: I don't have any code <rickspencer3> oh <rickspencer3> lol * sergiusens has been awake for 3 hours already <sergiusens> ogra_: rickspencer3 you can also do snappy install [snap] [config] <rickspencer3> sergiusens, I meant "wake up" in a totally figurative way :) <rickspencer3> sergiusens, is there documentation that I can use anywhere? <ogra_> ah, thats new to me <sergiusens> ogra_: it's in the --help (snappy install --help) <rickspencer3> so, my idea for the snap is that when the board is ready to be connected to over ssh, it blinks a led <ogra_> sergiusens, yeah i tried "snappy help" :P <ogra_> (no, i'm lying indeed) <rickspencer3> is there a way that a snap could easily tell if ssh is ready? <rickspencer3> i.e. from Go code? <sergiusens> rickspencer3: so you indeed want a config to configure where that LED is <rickspencer3> sergiusens, yeah <sergiusens> rickspencer3: you would need special permissions to check it at the service level <sergiusens> rickspencer3: the thing you can do today is poll the port and wait for the ssh signature <rickspencer3> there are 2 things I don't know: 1. how to determine if ssh is running, 2. how to allow the developer to config the gpio pin <rickspencer3> sergiusens, I can't do that with just the normal network permissions? <rickspencer3> seems like I could do a loop and just ping it over localhost? <sergiusens> rickspencer3: yes, we don't have any security in place for fine grained networking :-/ <rickspencer3> sergiusens, yes I can do that, or yes I can't do that? <sergiusens> rickspencer3: ping over localhost or over the main interface <Chipaca> ogra_: rickspencer3: cdparanoia has emoticons for status output <sergiusens> rickspencer3: yes you can! <rickspencer3> ok, that sounds easy enough <Chipaca> :-) Normal operation, low/no jitter <Chipaca> :-| Normal operation, considerable jitter <Chipaca> :-/ Read drift <Chipaca> :-P Unreported loss of streaming in atomic read operation <Chipaca> 8-| Finding read problems at same point during reread; hard to correct <Chipaca> :-0 SCSI/ATAPI transport error <Chipaca> :-( Scratch detected <Chipaca> ;-( Gave up trying to perform a correction <Chipaca> 8-X Aborted read due to known, uncorrectable error <Chipaca> :^D Finished extracting <ogra_> hah <sergiusens> Chipaca: that reminds me of mac system 7 <Chipaca> c.Check(logs, DeepEquals, []map[string]interface{}{{"a": 1}, {"a": 2}}) <Chipaca> ... obtained []map[string]interface {} = []map[string]interface {}{map[string]interface {}{"a":1}, map[string]interface {}{"a":2}} <Chipaca> ... expected []map[string]interface {} = []map[string]interface {}{map[string]interface {}{"a":1}, map[string]interface {}{"a":2}} * Chipaca goes looking for somebody to wap over the head <mvip> Alexander -- this is Viktor from Screenly. Sorry, forgot your nick, but please just wanted to join the channel and say hi. <Chipaca> asac: ^ <mvip> Thanks :) <mvip> Oh and i see mectors is hanging out here too :) <mectors> mvip of course <mvip> :) <rickspencer3> o/ mvip <mvip> Need to brush up on my bitchx skills. Haven't spent much time on IRC in the last decade :) <bartkusedvinas> Hello there. I need some help that I can't find yet on Google. How do I add to may #cloud-config DOCKER_OPTIONS :/ does anyone use it? <bartkusedvinas> Is it possible to write to /var/lib/apps/docker/507-653-2812/etc/docker.conf via cloud-config? <mvip> Are there any examples out there of running X11 apps in snaps? <mvip> bartkusedvinas: isn't /var residing on /, which is mounter r/o? <bartkusedvinas> you are right, it is read only <tedg> zyga: There is a rumor that you're working (and close to completing) pip support for snapcraft. Is it true? <mvip> bartkusedvinas i'm by no mean a Snappy expert, but my guess is that it's mounted as r/o on boot. As such, you can not modify that file (unless you hackishly re-mount it *inside* cloudinit) <tedg> bartkusedvinas: Snaps themselves have a configuration interface, which the docker framework should use. I'm not sure if it is though. <bartkusedvinas> mvip: sounds right... tho, i bet that those who are using docker want to add DOCKER_OPTIONS='-H tcp://507-653-2812:4243' <bartkusedvinas> however i can't find what is the right approch to do so <ogra_> bartkusedvinas, the shipped cloud-init is only used for bringing up the system ... <ogra_> not for tinkering with snaps <tedg> mvip: I think that deb2snap was used to make some Xapps run, but I can't think of an example. <tedg> mvip: Is there are particular one you're trying to run? Many have Mir backends available as well. <ogra_> bartkusedvinas, well, you are likely not using docker standalone ... but run something in it <ogra_> bartkusedvinas, for that something you would create a snap that uses the docker framework <ogra_> and in that snap you would set such options <mvip> tedg: Well, yeah, have some things in mind, but was just curious if there were any examples out there. `deb2snap` seems somewhat hackish. <tedg> mvip: It is :-) <mvip> tedg: :) <mvip> Just out of curiousity, how's Docker configured on Snappy. Is it run on the host, or is it running within a snap? <mvip> Because I saw a Docker snap when I was playing with it on the RasPi <tedg> mvip: I wrote up an examle using Qt/QML, but that is with the Mir backend: http://gould.cx/ted/blog/Creating_a_QML_snap_with_Snapcraft <ogra_> bartkusedvinas, i guess kickinz1|afk could help (if he werent afk) he maintains the docker framework snap and also the owncloud snap that uses it <mvip> tedg: Oh cool. Thanks. <kickinz1> mvip docker is a framework snap <mvip> kickinz1 ah ok <mvip> still getting used to the Snappy lingo <ogra_> ha, speaking of the devil :) <bartkusedvinas> thanks. i want to try snappy as alternative to coreos <bartkusedvinas> with coreos i had the following cloud-config which would open access to docker https://gist.github.com/edvinasbartkus/8ed0e61a7c7980c087f1 <bartkusedvinas> so I would be able to use deploy tools to deploy to coreos docker's my containers <ogra_> yeah, this is the stuff you would do in a start script of the snap i talked about <bartkusedvinas> i see <ogra_> http://paste.ubuntu.com/12253305/ i.e. this is the start script used by the owncloud snap <ogra_> i assume you would have something similar in a coreos-docker.snap <mvip> kickinz1 so if Docker is a Snappy framework, i then presume it is running on the host and then snappy is responsible for communicating with Docker, right? <kickinz1> mvip, yes, docker is running on the host, there are some specific apparmor profile management. <bartkusedvinas> I was expecting to find some easy recipie like this https://gist.github.com/edvinasbartkus/a99dd8bf12f717c7c6f5 :)) <mvip> kickinz1 got it. Thanks. <bartkusedvinas> @orgra_ thanks for the hint to the script. will try to improvise my way ;) <nothal> bartkusedvinas: No such command! <kickinz1> mvip, but for now you can connect directly to docker-daemon, be aware, that if you want to do some docker build, docker load/save, you need to have your files in $HOME/apps/docker.$VERSION/ <bartkusedvinas> @nothal yeah, i am aware :) i was expecting just to have such easy solution :P <nothal> bartkusedvinas: No such command! <kickinz1> $HOME/apps/docker/$VERSION/ <ogra_> bartkusedvinas, well, i'm pretty sure such an easy setup is possible too ... <mvip> kickinz1 got it. <ogra_> bartkusedvinas, the point in snappy is that you are completely confined ... so you would never modify any of the system setup of docker but ship your own <Chipaca> pitti: question for you sir <Chipaca> pitti: what should "journalctl -q -u something-that-does-not-exist" print, given the -q? <bartkusedvinas> @ogra_ thanks <nothal> bartkusedvinas: No such command! <ogra_> you should leave out the @ :) <bartkusedvinas> oh :) sorry for being newby <bartkusedvinas> and even spelling like a newbie :)) <pitti> Chipaca: you mean wrt. the -- No entries --? -q is documented as "Suppresses any warning messages regarding inaccessible system journals when run as a normal user.", but I see how one would want to shut up that message too :) <ogra_> no worries ... <ogra_> usually the ubuntu bots dont use @ but ! ... nothal is special in this channel <Chipaca> pitti: the "No journal files were found." was more the thing i was expecting it to suppress <Chipaca> as it stands -o json outputs json except when it doesn't <Chipaca> making it somewhat annoying :) <pitti> Chipaca: I don't get that <pitti> $ journalctl -q -u something-that-does-not-exist <pitti> -- No entries -- <pitti> $ <Chipaca> $ journalctl -q -u potato <Chipaca> No journal files were found. <Chipaca> -- No entries -- <dholbach> sergiusens, is there a switch for snapcraft to force-rebuild everything? or how do you normally use it? (rm -rf parts stage snap; snapcraft)? <pitti> Chipaca: but this should be fixed anyway -- "-- no entries --" is quite useless for json output/parsing too <zyga> tedg: hehe <zyga> tedg: yes, let's talk <zyga> tedg: I'm working on this hard <zyga> tedg: and I'd love to have an accomplice <tedg> zyga: Do you have a branch pushed? <zyga> tedg: no, I got into a few blockers, if you want we can sync and talk about that but I'm packed with meetings now <zyga> tedg: we could invite you to a meeting in 25 minutes (monthly catch up on snappy) <zyga> tedg: that could help as wel <zyga> well <tedg> zyga: Uhm, okay. I'm not looking for more meetings ;-) * ogra_ notes down ... ted ... looking for more meetings ... <tedg> Heh, thanks ogra_ <ogra_> :) <zyga> lol <zyga> tedg: so let's just talk here <zyga> tedg: tell me about your approach <zyga> tedg: and I'll tell you what I did and what I got stuck on <tedg> zyga: I was looking at adding a field to the python projects for adding a requirements.txt <tedg> zyga: Grab it, install it, party on. â my approach :-) <zyga> tedg: mmm <zyga> tedg: have you run into the numerous issues in python3app implementation today <zyga> tedg: it's pretty much all wrong now <zyga> tedg: it bleeds the python stuff from the system into the snap stage area <tedg> Not sure what python3app is? python3-project ? <zyga> yep <zyga> I never remember if it's -project or -application <zyga> but yes <zyga> e.g. you pip install requirements and it ignores stuff you have locally installed <tedg> Ah, I don't have anything from pip locally installed :-) <zyga> not from pip <zyga> from the system <zyga> I have patched that heavily <tedg> So it needs to restrict its search path. Sounds like an envvar? <zyga> tedg: more than that <zyga> tedg: you really need to run the python from the stage area <zyga> tedg: there's no clean way to do it otherwise <zyga> tedg: and you essentially need to do what virtualenv does to be correct <tedg> Sure, but that's handled by setting up the path correctly. <zyga> tedg: then there are some interesting issues related to that but that's <zyga> tedg: path? yeah <zyga> tedg: well <zyga> tedg: no, just running the right python explicitly <tedg> Eh, okay. That can work too. <zyga> tedg: anyway, it's clear that you just run the right python with the right extra PYTHONHOME helpers and perhaps python -S (so that site is not imported) <zyga> tedg: then you get empty python and pip install works <zyga> tedg: I ran into some other issues though <zyga> tedg: and that's where
{'channel': 'snappy', 'month': 9}