[06:41] <dholbach> good morning
[06:46] <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
[06:46] <mvo> hey dholbach, good morning
[06:51] <dholbach> thanks mvo
[07:04] <fgimenez> good morning
[07:27] <zyga> good morning
[08:19] <Chipaca> goood morning!
[08:40] <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)
[08:41] <ogra_> or should we perhaps just push it to the PPA
[08:53] <mvo> ogra_: this is in wily, no?
[08:54] <mvo> ogra_: aha, you mean for 15.04? yeah, going the ppa route is fine here I think
[09:09] <Chipaca> mvo: o/
[09:09] <Chipaca> mvo: so, comapreDirs
[09:09] <mvo> hey Chipaca
[09:09] <Chipaca> mvo: compares the output of ls
[09:09] <mvo> Chipaca: no, compardirs is terrible
[09:09] <Chipaca> mvo: that's a huge red flag
[09:09] <Chipaca> but
[09:09] <Chipaca> BUT
[09:09] <mvo> Chipaca: I was wondering about https://code.launchpad.net/~mvo/snappy/snappy-lp1468831-race/+merge/269155
[09:09] <Chipaca> because it's a controlled test scenario
[09:09] <Chipaca> it wouldn't be too terrible
[09:09] <Chipaca> however
[09:09] <Chipaca> it's comparing the ctimes, which we don't care about
[09:09] <Chipaca> isntead of the mtimes or the atimes which we apparently do care about
[09:10] <mvo> oh, sorry, I get it now, its connected
[09:10] <Chipaca> also it
[09:10]  * mvo shuts up and listens
[09:10]  * Chipaca derails
[09:11] <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
[09:11] <Chipaca> I mean, you can tell ls to --time-style=+%s for example
[09:11]  * mvo nods
[09:11] <Chipaca> but if we're just comparing for equality that's fine
[09:12] <Chipaca> and, given the comment about atime/mtime in RSyncWithDelete, I think we *do* care about equality
[09:12] <Chipaca> so that means the test is wrong, and the fix is hiding it instead of fixing it :)
[09:12] <Chipaca> so
[09:12] <Chipaca> rant mode off
[09:12] <Chipaca> fix mode on
[09:12] <Chipaca> i guess what we want is to have ls print the atime and the mtime, if those are truly what we care about
[09:12] <mvo> yeah, absolutely agreed, I will reject the branch
[09:14] <Chipaca> hm, ls can't print both atime and mtime at the same time
[09:14] <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
[09:15] <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.
[09:16] <fgimenez> elopio, ok np i'll take a look
[09:16] <Chipaca> mvo: default for ls is mtime (i thought it was ctime, for some reason), so we're not preserving it in RSyncWithDelete?
[09:17] <mvo> Chipaca: hm, its using cp -a
[09:18] <Chipaca> mvo: but for single files
[09:18] <Chipaca> mvo: directories it's making itself
[09:18]  * Chipaca wonders why that isn't a single cp call
[09:18] <Chipaca> ah, because of the filesareequal check
[09:18] <Chipaca> so
[09:18] <Chipaca> i know how to unbreak the test, now :)
[09:19] <mvo> yeah, the dirs are indeed missing
[09:19] <mvo> yay, thanks Chipaca
[09:19] <mvo> and sorry for the trouble :/
[09:19] <Chipaca> hah. no worries.
[09:19] <Chipaca> sorry for the rant
[09:20] <mvo> all good, terrible code there
[09:29] <Chipaca> yuss
[09:36] <Chipaca> mvo: how does http://pastebin.ubuntu.com/12244247/ look?
[09:38] <mvo> Chipaca: much nicer
[09:39] <Chipaca> mvo: OTOH i could move that to CopyFile
[09:39] <Chipaca> mvo: and just use CopyFile here
[09:39] <Chipaca> but maybe make it different branches
[09:39]  * Chipaca agrees with himself already
[09:40] <mvo> heh
[09:40] <mvo> cleanup++
[09:42] <Chipaca> mvo: https://code.launchpad.net/~chipaca/snappy/fix-1468831/+merge/269728 would be that then
[09:45] <mvo> \o/
[09:54] <Chipaca> mvo: not top-approving because integration tests
[09:56] <Chipaca> oooh, mp failed?
[09:58] <mvo> helpers/helpers.go:503: impossible type assertion:
[09:58] <mvo>  *syscall.Stat_t does not implement os.FileInfo (missing IsDir method)
[09:58] <mvo> looks like it
[10:00] <Chipaca> dah
[10:00] <Chipaca> mvo: forgot .Sys() :(
[10:01] <Chipaca> mvo: fixed
[10:04] <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?
[10:04] <mvo> Chipaca: indeed, sorry again
[10:05]  * Chipaca takes a break
[10:13] <sergiusens> mvo: thanks for the reviews!
[10:17] <ogra_> sergiusens, wrt bug 1490741 ... shouldnt u-d-f bail out when using a RPi2 snap with a generic tarball ?
[10:18] <ogra_> or did i do something rong with the meta data in the pi2 snap ?
[10:18] <ogra_> *wrong
[10:21] <sergiusens> ogra_: it shouldn't fail, no; it will use the one from s-i
[10:21] <ogra_> thats bad
[10:21] <sergiusens> ogra_: that is the catch to --developer-mode, no hand holding
[10:22] <sergiusens> ogra_: yeah, you need to put this upstream ;-)
[10:22] <ogra_> ah
[10:22] <ogra_> yeah, i think we need a mechanism to define what device tarballs an oem snap can be used with
[10:22] <sergiusens> ogra_: how would you start enabling a board if not?
[10:23] <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
[10:23] <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
[10:23] <sergiusens> ogra_: but the device tarbal is just a tar
[10:23] <ogra_> currently :)
[10:24] <sergiusens> ogra_: when it becomes a snap, I hope the gadget would define it
[10:24] <ogra_> yeah
[10:24] <sergiusens> ogra_: since it would be pulled from the store, so it needs the name
[10:27]  * ogra_ turns the u-d-f task on the bug invalid but keeps the snappy one open then
[10:37]  * Chipaca is trying to figure out https://code.launchpad.net/~fgimenez/snappy/setenv-closure-redefinition/+merge/269717
[10:41]  * ogra_ twiddles thumbs waiting for shadow to be published in the PPA
[10:41] <fgimenez> Chipaca, yes, it's a bit involved :)
[10:42] <fgimenez> Chipaca, in build_test we used var definitions for testing the dependency calls
[10:43] <Chipaca> mhmm
[10:43] <Chipaca> fgimenez: but here's the thing
[10:43] <Chipaca> fgimenez: a var is not a closure
[10:43] <Chipaca> there's nothing to "refresh"
[10:44] <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
[10:45] <fgimenez> Chipaca, when we call this afterwards, it doesn't take the value of the environment variables if we don't redefine it
[10:45] <fgimenez> Chipaca, this used to work before 1.5
[10:46] <Chipaca> hmm
[10:46] <Chipaca> fgimenez: and you get the same error every time without this change?
[10:47] <fgimenez> Chipaca, yep
[10:47] <Chipaca> fgimenez: and if you do "export GOMAXPROCS=1" before running the test?
[10:47] <fgimenez> Chipaca, let me try..
[10:48] <Chipaca> fgimenez: because what changed was that in 1.5 GOMAXPROCS defaults to the number of cores; before it was 1
[10:48] <Chipaca> fgimenez: and getenv is per-process
[10:49]  * Chipaca writes a small testcase to check this just in case
[10:49] <fgimenez> Chipaca, ah! ok, shouldn't GOARCH be the same for all of them?
[10:55] <fgimenez> Chipaca, i'm getting this http://paste.ubuntu.com/12244578/ after removing the var redefinition line
[10:57] <Chipaca> fgimenez: i'll dig into it in a bit
[10:59] <fgimenez> Chipaca, ok thanks! :)
[11:11] <Chipaca> oooooh
[11:12] <Chipaca> fgimenez: shouldn't osGetenv return something?
[11:12] <Chipaca> i mean
[11:12] <Chipaca> fgimenez: in the tests
[11:12] <Chipaca> fgimenez: you're rewriting osGetenv
[11:12] <Chipaca> fgimenez: with fakeOsGetenv
[11:12] <Chipaca> fgimenez: that does not return anything
[11:12] <Chipaca> i.e. it always returns an empty string
[11:14] <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?
[11:15] <fgimenez> Chipaca, yes that makes a lot of sense, let me take a look
[11:15] <Chipaca> actually making it a map[string]struct{string, int, int} would be the way I'd do it, actually
[11:16] <Chipaca> fgimenez: i'll show you what i mean in a diff, give me a few
[11:40] <Chipaca> fgimenez: something like http://pastebin.ubuntu.com/12244793/ might work, but it would involve changing a number of tests appropriately
[11:41] <Chipaca> fgimenez: advantage of this is you have a single place where you track reads, writes and current value of the environment
[11:41] <Chipaca> fgimenez: disadvantage might be that it's a bigger change from where the code is right now
[11:43] <Chipaca> fgimenez: whereas the simpler change would be http://pastebin.ubuntu.com/12244813/
[11:43] <Chipaca> fgimenez: i feel it'll make things harder to follow in the long term, but not particularly strongly :)
[11:44] <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
[11:45] <fgimenez> Chipaca, yep :) thanks for that, i was thinking in the latter option that you proposed, i'll put hands on it
[11:45] <Chipaca> fgimenez: in both cases note i haven't tested the code :)
[11:46] <fgimenez> Chipaca, np :)
[11:50]  * Chipaca is now on lunch break
[13:54] <Chipaca> pitti: i have the silliest systemd question, and sadly for you your name is soldered to systemd in my mind
[13:54] <pitti> hey Chipaca -- heh :)
[13:54] <pitti> Chipaca: you could ask anyone in the vast systemd maintenance team in Ubuntu!
[13:54] <Chipaca> pitti: if I do, e.g.,: sudo journalctl -u urfkill -o json-pretty
[13:55] <Chipaca> pitti: it returns a series of lines, with a json document per line
[13:55] <Chipaca> um
[13:55] <Chipaca> json, not json-pretty
[13:55] <Chipaca> :)
[13:55] <Chipaca> pitti: json-pretty to read it, json to parse it :)
[13:55] <Chipaca> pitti: anyway. you get that, a series of json objects
[13:55] <pitti> right
[13:55] <pitti> looking at it here, for systemd-udevd, as i don't have urfkill
[13:55] <Chipaca> pitti: in the first one, the systemd unit is in the "UNIT" key
[13:56] <Chipaca> pitti: in the following ones, it's in "_SYSTEMD_UNIT"
[13:56] <Chipaca> pitti: this feels like a bug
[13:56] <Chipaca> pitti: but I don't know
[13:56] <pitti> Chipaca: it for sure is
[13:56] <Chipaca> *gasp*
[13:56] <pitti> I mean, I don't see how this would be deliberate
[13:57] <Chipaca> well, it's certainly not what's documented :)
[13:57]  * Chipaca updates his system just in case
[13:57] <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
[13:58] <pitti> yep, should always be _SYSTEMD_UNIT as per systemd.journal-fields(7)
[13:58] <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?
[13:58] <Chipaca> that sounds contrieved though
[13:58] <Chipaca> and aggregates poorly
[13:59] <pitti> yeah
[13:59] <pitti> Chipaca: do you mind filing it at https://github.com/systemd/systemd/issues or should I proxy it for you?
[13:59] <Chipaca> pitti: i wouldn't mind filing it
[14:00] <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?
[14:00] <Chipaca> it is
[14:01] <Chipaca> pitti: it's also only the first one for any service, for you?
[14:01] <pitti> Chipaca: yes, consistently (tried 3)
[14:02] <pitti> Chipaca: in a fresh VM I see two UNIT=, though
[14:02] <pitti> but either way, this is inconsistent and undocumented
[14:02] <Chipaca> pitti: I'll file the bug, you add that to it :)
[14:03] <pitti> ack
[14:05] <Chipaca> pitti: https://github.com/systemd/systemd/issues/1106
[14:07] <pitti> Chipaca: thanks, I'll watch what upstream says and if appropriate look into it
[14:09] <Chipaca> pitti: ta
[14:34] <Chipaca> pitti: there you go then
[14:35] <pitti> Chipaca: ah! so this is "message from pid 1 about unit foo" vs. "message from unit foo"
[14:36] <Chipaca> pitti: yep, so it might be a bug in documentation as opposed to implementation
[14:36] <Chipaca> as the docs don't mention UNIT nor any other mysterious "couple of other keys"
[14:36] <pitti> Chipaca: yeah, I just followed up wrt. that
[14:36] <Chipaca> heh. jinks.
[14:36] <Chipaca> jinx*
[14:37] <Chipaca> anyway, you know what time it is?
[14:37] <Chipaca> time for a cuppa tea
[14:37] <pitti> and again
[14:37] <pitti> Chipaca: good idea!
[14:37] <pitti> Chipaca: I was about to yell "Tool time!" :)
[14:57] <rickspencer3> is there a bug # for snappy-remote install doesn't work with webdm?
[14:57] <Chipaca> pitti: do you know what they mean wrt trusted/untrusted fields?
[14:57] <pitti> "Fields prefixed with an underscore are trusted fields, i.e. fields that are
[14:57] <pitti>        implicitly added by the journal and cannot be altered by client code."
[14:58] <Chipaca> pitti: where's that?
[14:58] <pitti> Chipaca: in man systemd.journal-fields
[14:58] <Chipaca> pitti: gotcha
[14:58] <ted> sergiusens, Do you have a snapcraft branch where you're removing the ubuntu plugin?
[14:58] <pitti> Chipaca: so, a client using libsystemd journal_* can set arbitrary fields, but not those prefixed with _
[14:59] <Chipaca> pitti: k :)
[14:59] <sergiusens> ted: not pushed yet
[14:59] <sergiusens> ted: still in the works (writing tests)
[14:59] <ted> sergiusens, Can you push so I can base off of that?
[15:02] <Chipaca> rickspencer3: how does it not work?
[15:02] <Chipaca> rickspencer3: http://pastebin.ubuntu.com/12246078/
[15:03] <rickspencer3> Chipaca, the last time I tried it, it didn't work, and I was told that it was a bug
[15:03] <rickspencer3> oh
[15:03] <Chipaca> rickspencer3: ah, maybe sergiusens knows more then
[15:04] <rickspencer3> Chipaca, I did $snappy-remote install --url=ssh://webdm.local or something
[15:04] <rickspencer3> Chipaca, oh
[15:04] <rickspencer3> no, you are installing webdm
[15:04] <rickspencer3> I meant installing a different snap using webdm
[15:04] <rickspencer3> instead of the ip address
[15:08] <ogra_> you mean using avahi ;)
[15:14] <ogra_> (webdm.local is an avahi address, perhaps the go implementation that the webdm package ships has issues)
[15:15] <Chipaca> I think it's snappy-remote doing something smart with --url that does not include avahi
[15:15] <Chipaca> it also does not hand it straight off to ssh, which means you can't use fake ssh hostnames
[15:15] <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
[15:15] <Chipaca> *also* also note I don't think avahi will work to kvm
[15:18] <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.
[15:19] <mvo> Chipaca: uh, I'm not sure I understand, thats webdm, it has a service
[15:19] <Chipaca> mvo: yes
[15:19] <Chipaca> mvo: what does "snappy service status webdm" print
[15:20]  * Chipaca forgot the 'status' verb
[15:20] <ogra_> i think i said before that i dont think it is wrong if webdm doesnt start when no network is available
[15:20] <mvo> Chipaca: its on 15.04, do we have snappy service there already?
[15:20] <ogra_> what *is* important though is that it starts as soon as you connect network
[15:20] <Chipaca> mvo: then you don't have the network brouhaha fix :)
[15:20] <mvo> Chipaca: aha!
[15:20] <mvo> Chipaca: now I understand
[15:20] <Chipaca> mvo: it's not backported, and landed in wily together with "service", hence that question
[15:21] <mvo> Chipaca: cool, do you happen to remember the bugnumber?
[15:21] <mvo> Chipaca: I can have a look in a bit then
[15:23] <Chipaca> bug 1466672
[15:24]  * Chipaca hugs --fixes
[15:24] <Chipaca> mvo: ^
[15:24] <mvo> ta
[15:24] <mvo> I will do a backport in a bit
[15:30] <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
[15:30] <ogra_> (in case you feel like trying it)
[15:38] <Chipaca> zomg, next week school starts again
[15:41] <elopio> fgimenez: I'm not sure how to make an anonymous struct inside a for.
[15:41] <elopio> that sounds scary too.
[15:42] <elopio> fgimenez: I was copying the style from here: https://github.com/golang/go/wiki/TableDrivenTests
[15:44] <fgimenez> elopio, yes :) it's just to replace the flagtest var definition in that example with the struct itself, readability could suffer though
[15:45] <fgimenez> elopio, i've seen an example here http://talks.golang.org/2015/tricks.slide?utm_source=golangweekly&utm_medium=email#12
[15:46] <tedg> sergiuse1s: Not sure if it got lost in the various disconnects, can you push your branch so I can build on it?
[15:46] <elopio> fgimenez: yes, -1 for that. Maybe I'm too used to testscenarios.
[15:46] <tedg> sergiuse1s: Should be fine without tests for what I need.
[15:46] <elopio> what I think we should do is to add scenarios to go check.
[15:47] <fgimenez> elopio, that would be great
[15:49] <zyga> ogra_: thanks a lot, I'll check it out
[15:50] <ogra_> thanks
[15:51] <sergiuse1s> tedg: oh, I don't think I can share just yet, still not glued in
[15:53] <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.
[15:55] <sergiuse1s> tedg: I think I understand, going to start the drive back home, we can continue then
[15:58] <tedg> sergiuse1s: K
[16:07] <tedg> barry: Reading through the pip docs and learning about wheels. Do you think we need to support those in Snapcraft?
[16:08] <tedg> Not sure how often they're used, or if everyone just uses the source versions.
[16:11] <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
[16:15] <tedg> barry: Okay. But as I'm reading more that seems separate from pip though, right? Pip can just build wheels?
[16:20] <fgimenez> nice evening everyone o/
[16:21] <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)
[16:24] <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.
[16:46] <ogra_> mvo, hmm, did i hand you https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1490608 yet ? i know you asked for it
[16:46] <mvo> ogra_: yes, you mentioned it and I failed to look at it
[16:46] <ogra_> i guess thats foundations material anyway, no ?
[16:47] <mvo> well, yes, I would still guess if someone of us does it it will be faster
[16:47] <mvo> they are usually super busy
[16:47] <ogra_> nah, they just pretend to ... its all scripted :P
[17:34] <barry> tedg: it may not matter in practice.  i think pip wheelifying packages is mostly an implementation detail
[17:42] <ali1234> o/
[17:43] <ogra_> hey ali1234
[17:44] <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
[17:45] <ali1234> debian jessie appears to have the same version of golang and ubuntu 15.04
[17:45] <ogra_> http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/current/vivid-preinstalled-core-armhf.manifest ...
[17:45] <ogra_> thats the list of files ...
[17:45] <ali1234> i've seen those manifest files
[17:45] <ali1234> but no idea what to do with them
[17:46] <ali1234> like, what tkes the list and builds an image?
[17:46] <ogra_> you would want to build them on raspbian
[17:46] <ali1234> i'd expect most of them already exist
[17:46] <ali1234> raspbian has literally everything debian has afaik
[17:46] <ogra_> we use live-build to build the images ... with modifications and configs living in the livecd-rootfs package
[17:47] <ogra_> there is an old project of mine that i'm about to re-vivie for "building at home"
[17:47] <ogra_> https://launchpad.net/project-rootstock-ng
[17:47] <ali1234> hah, rootstock, i remember that
[17:47] <ogra_> that should allow you to build a rootfs
[17:48] <ogra_> beyond the rootfs you need a device tarball http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/current/ check the armhf one here ...
[17:48] <ali1234> what does that do?
[17:49] <ogra_> carry kernel, firmware blobs and modules
[17:49] <ali1234> rootfs just manages updates and things?
[17:49] <ogra_> no
[17:49] <ogra_> snappy manages the updates
[17:49] <ogra_> currently using the same mechanism the phones use (system-image)
[17:49] <ogra_> soon switching away from that ... (everything becomes a snap )
[17:50] <ogra_> beyond rootfs and device tarball you need an oem snap ... that has your bootloader setup
[17:51] <ogra_> once you have these three you can feed them into ubuntu-device-flash which generates an image for you
[17:51] <ogra_> out of these three files
[17:51] <ogra_> your prob will be that you cant really use the store, even if you get it up and running ...
[17:51] <ali1234> yeah... i've seen the ubuntu-device-flash stuff too
[17:51] <ali1234> i'm not concerned about using the store, i want to package my own software
[17:51] <ogra_> all binaries in the store are built for armhf indeed
[17:52] <ali1234> my only dependency is gstreamer
[17:52] <ali1234> which i assume i'd have to bundle anyway
[17:52] <ogra_> yeah
[17:54] <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?
[17:54] <ogra_> right
[17:55] <ogra_> a lot of the magic is in the initrd, in the snappy binary and in systemd units ...
[17:55] <ali1234> "system-image-snappy-common" - bet debian doesn't have that...
[17:55] <ogra_> (nad in the bootloader setup too)
[17:55] <ali1234> is that package the snappy tool itself?
[17:56] <ali1234> no, that's ubuntu-snappy
[17:56] <ogra_> i think the ubuntu-snappy package buulds it
[17:58] <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
[17:59] <ali1234> okay well that's something to be going with, thanks
[18:00] <ogra_> ali1234, just come back if you have more questions (you surely will) ... i'm curious how that experiment turns out :)
[18:01] <tedg> sergiusens: Oh, okay. Perhaps I should look at a different one then. That was at the top of the backlog.
[18:02] <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
[18:03] <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.
[18:04] <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.
[18:04] <tedg> sergiusens: Which really doesn't make a lot of sense.
[18:09] <tedg> Haha, I lose. The ROS instructions depend on pip :-)
[18:24] <rickspencer3> does anyone know any tricks regarding getting wifi to work on the bbb?
[18:25] <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
[18:26] <ogra_> *driver
[18:26] <rickspencer3> hmmm, I think I did that
[18:27] <ogra_> is the device detected ? do you see an interface for it in /proc/net/dev after you plugged it in ?
[18:34] <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.
[18:34] <rickspencer3> ogra_
[18:34] <rickspencer3> $ ls /proc/net/dev
[18:34] <rickspencer3> /proc/net/dev
[18:34] <ogra_> cat
[18:35] <ogra_> (meow :) )
[18:35] <rickspencer3> just lo and eth0
[18:35] <ogra_> ah, smells like either the driver or some sirmware is missing
[18:35] <ogra_> *frimware
[18:35] <ogra_> bah !
[18:35] <ogra_> check syslog when plugging it in
[18:36] <rickspencer3> ogra_, http://pastebin.ubuntu.com/12247479/
[18:38] <ogra_> rickspencer3, ah, ralink ...
[18:38] <rickspencer3> ogra_, not supported?
[18:38]  * rickspencer3 sobs
[18:38] <rickspencer3> I bought it on a whim because it was specifically supported by bbb debian
[18:39] <ogra_> no, just a constant source of pain :)
[18:41] <rickspencer3> ogra_, sorry, I don't quite grock, are you saying I am out of luck with this particular dongle?
[18:41] <ogra_> seems to need the mt7601u module
[18:42] <rickspencer3> ogra_, ok, what should I do? buy a different dongle?
[18:43] <beuno> rickspencer3, some guy on the mailing list had the same problem
[18:43] <beuno> there might not be a dongle that has the module in our kernel
[18:43] <ogra_> rickspencer3, gimme a bit to read up about it :)
[18:44] <rickspencer3> well, I know that at least one person got at least one dongle working with rpi2 and snappy
[18:44] <beuno> rickspencer3, yeah, the rpi2 kernel comes with some modules
[18:44] <ogra_> hmm, so it should be supported by rt2800usb ...
[18:44] <ogra_> which we also ship in the device tarball
[18:44] <rickspencer3> ogra_, well, this image is oooold
[18:44] <ogra_> (on RPi2 the firmware is missing though )
[18:45] <ogra_> rickspencer3, uname -r ?
[18:45] <rickspencer3> (BeagleBoneBlack)ubuntu@localhost:~$ uname -r
[18:45] <rickspencer3> 3.19.0-23-generic
[18:45] <ogra_> not that old then
[18:45] <rickspencer3> well, I run updates :)
[18:46] <ogra_> try sudo modprobe rt2800usb
[18:46] <ogra_> and see if that thinks it knows the device (re-plug if needed)
[18:46] <rickspencer3> lol
[18:46] <rickspencer3> $ try sudo modprobe rt2800usb
[18:46] <rickspencer3> -bash: try: command not found
[18:46] <ogra_> haha
[18:47] <rickspencer3> ogra_, I reran  cat /proc/net/dev
[18:47] <rickspencer3> still just lo and eth0
[18:47] <ogra_> and syslog
[18:47] <ogra_> (also after re-plugging with the module loaded)
[18:48] <rickspencer3> Sep  1 18:46:29 localhost kernel: [ 1300.551733] usbcore: registered new interface driver rt2800usb
[18:48] <ogra_> nothing else
[18:48] <ogra_> ?
[18:48] <ogra_> even when re-plugging the device ?
[18:49] <rickspencer3> ogra_, no, everything looks the same
[18:49] <ogra_> the musb-hdrc error in your paste actually indicates a deeper prob with USB i think
[18:49] <rickspencer3> /proc/net/dev, syslog, etc...
[18:49] <rickspencer3> awesome!
[18:49] <ogra_> i guess thats one for ppisati
[18:51] <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
[18:52] <rickspencer3> ogra_, ok, rpi2 is coming up next
[18:52] <ogra_> the beagle musb issues are legendary :)
[18:52]  * rickspencer3 finishes transferring bbb to new case
[18:52] <ogra_> and as old as homers oddisey i think
[18:53] <rickspencer3> ogra_, not sure what you mean, is it something that we need to fix generally, is it just my specific dongle?
[18:53] <ogra_> rickspencer3, there are general issues with USB on BBB since forever
[18:54] <rickspencer3> ogra_, right, but are you saying we are out of luck on bbb, or that we need to hack around the issues?
[18:54] <ogra_> it got a lot better over the years but there are still issues
[18:54] <ogra_> well, forst of all you should file a bug and let ppisati know
[18:54] <ogra_> so he can take a look
[19:05] <rickspencer3> ogra_, anything else useful I can add to this?
[19:05] <rickspencer3> https://bugs.launchpad.net/snappy/+bug/1491094
[19:09] <ogra_> rickspencer3, i extended the subject line and will point paolo to it tomorrow
[19:10] <rickspencer3> thanks ogra_