[04:09] <elopio> sergiusens: I didn't look for a way to remove the leftover messages. I just filed a bug for zyga: https://bugs.launchpad.net/plainbox/+bug/1484596
[04:20] <sergiusens> elopio: bummer, it is so annoying :)
[04:23] <sergiusens> elopio: here's another one https://code.launchpad.net/~sergiusens/snapcraft/testing-fixes/+merge/269146
[04:23] <sergiusens> 3rd and last
[04:23]  * sergiusens goes for some zzzzz
[07:28] <zyga> mvo: hey
[07:28] <zyga> mvo: around?
[07:33] <mvo> hey zyga, good morning
[07:34] <zyga> mvo: hey, I'm trying to understand how a part of snapcraft you wrote works
[07:34] <zyga> mvo: I'm thinking of the python3-project plugin
[07:35] <zyga> mvo: specifically it seems to be a bit broken IMHO, but perhaps I'm missing something
[07:35] <mvo> zyga: ok, what part is unclear? or everything :) ?
[07:35] <zyga> mvo: could you please show me how to use two python3-project parts where A depends on B?
[07:35] <zyga> mvo: how it's supposed to work, I already read the code and patched a few things
[07:36] <zyga> mvo: but before I patch more, I want to see if I'm doing something sane
[07:36] <zyga> mvo: I was trying to structure the plugin after virtualenv, so that each subseqeuent part, after it's staged, can be imported by the rest of the snapcraft assembly process
[07:36] <zyga> mvo: (I wasn't thinking of using virtualenv, just to follow the same principle)
[07:37] <zyga> mvo: also, from what I see, setuptools depenencies are not followed at all, so the developer has to put everything together manually, right?
[07:38] <mvo> zyga: yeah, so dependencies are not resolved (yet) thats something that must be done manually right now
[07:38] <zyga> right, thanks for confirming that
[07:39] <mvo> zyga: we haven't used it in the scenario you describe, it may well be broken for that, how do you patches look right now? and in what way does it break exactly? code crashes or files not copied ?
[07:39] <zyga> mvo: ok, thanks, so currently it just crashes trying to run the setup of the 2nd part as it cannot import the 1st part
[07:39] <zyga> mvo: what I'm doing now, is to change how setup is invoked
[07:40] <zyga> mvo: I'm using --root relative to installdir and a fixed prefix
[07:40] <zyga> mvo: and I'll be probably using a different layout, but I need to see how to control the environment first
[07:40] <zyga> mvo: I found plugin.env() but it's not being called, I saw it's something related to handler.code but I've yet to connect the dots
[07:41] <zyga> mvo: I want to write an env function there that uses PYTHON* viariables to set everything up
[07:41] <mvo> zyga: aha, I see. there is a env() method that is available to add e.g. PYTHONPATH, there is also the after= directive to ensure on part is build before another
[07:41] <zyga> mvo: it also may be a factor that I'm working from a virtualenv in the first place (snapcraft itself is in a virtualenv)
[07:41] <zyga> mvo: and I want to make sure it's working regardless of that fact
[07:42] <zyga> mvo: I added env() but it's not getting called yet
[07:42] <zyga> as in ...
[07:42] <mvo> zyga: right
[07:43] <zyga> ttp://paste.ubuntu.com/12197674/
[07:43] <zyga> mvo: I'll dig through this and improve it anyway I can
[07:44] <zyga> mvo: I need the plugin to work with roughly anything I can throw at it for an active project we're doing in cert so I'll probably ask you for a few reviews as I go
[07:45] <mvo> zyga: sure, thanks. sergio will also be around later to help with that, once I finish my current snappy branch I can take a deeper look to see why env() is not doing what you expect
[07:45] <zyga> mvo: thanks
[07:46] <zyga> ah
[07:46] <zyga> small fix is to use /usr/bin/python3 instead of python3
[07:46] <zyga> that addresses the virtualenv factor
[07:47] <zyga> mvo: are you using virtualenv for development?
[07:52] <mvo> zyga:  I don't use virtualenv
[07:58] <zyga> mvo: how do you develop snapcraft then?
[07:59] <mvo> zyga: in my normal wily env
[07:59] <zyga> mvo: just running it straight from the tree?
[07:59] <zyga> mvo: ok, thanks for the tip
[07:59] <zyga> mvo: is python 3.5 default there?
[07:59] <zyga> mvo: I'm on vivid
[08:04] <mvo> zyga: its available but not default (yet)
[08:04] <mvo> zyga: not sure what the plans of the distro team are, I assume they want to make it default but its a rc at this point aiui
[08:13] <ogra_> mvo, i see you closed bug 1479711 ... do we consider bugs "fix released" if the fix is only in wily ?
[08:13] <ogra_> (just a general question)
[08:13] <zyga> ogra_: o/
[08:14] <ogra_> hey zyga
[08:14] <mvo> ogra_: I would say yes unless there is a 15.04 task, feel free to add one though
[08:15] <ogra_> k, thanks
[08:15] <mvo> ogra_: I wonder if we should maybe do a 15.10 "release" and move current trunk to 15.04, nothing radical in there AFAICS and mostly useful and stable for 15.04 people. but this of course needs wider discussion
[08:16] <ogra_> well, would that work ? given the potential differences in both releases (newer go version, gcc5 etc)
[08:17] <ogra_> if that doesnt get in our way, yeah sure
[08:17] <mvo> ogra_: that we need to explore, but it might be good enough to just build trunk on 15.04 and some specific packages (like the initramfs improvements)
[08:18] <zyga> ha
[08:18] <zyga> small bug in logging in snapcraft :)
[08:19] <ogra_> yeah, it definitely makes sense for stabilizing the stable image
[08:19] <ogra_> to keep the focus there ...
[08:19] <ogra_> (and it will make everyone more cautious sbout landing his changes as a nice sideefect :) )
[08:19] <zyga> and perhaps some more in various places, logging is broken wrt all arguments
[08:20] <mvo> yeah, thats my goal, optimize our time and spend less time porting, either via developing for 15.04 and merging from that into trunk or by moving trunk closer to 15.04
[08:20]  * zyga starts proposing fixes
[08:27] <zyga> https://code.launchpad.net/~zyga/snapcraft/fix-logging-setup/+merge/269163
[08:28] <zyga> mvo: who's the lead reviewer for snapcraft?
[08:28] <mvo> zyga: sergio right now, but let me have a look, I can cover TZ wise
[08:29] <zyga> mvo: cool, you can expect a lot of patches from me soon :)
[08:29] <mvo> zyga: cool :)
[08:29] <zyga> mvo: btw, do you want to use git with snapcraft (I am)
[08:29] <zyga> mvo: it's pretty cool :)
[08:29] <zyga> helps sorting through patches a lot
[08:30] <mvo> is the tarmac problem solved? that was the only thing holding us back
[08:30] <zyga> mvo: bzr on the server
[08:30] <zyga> mvo: git locally
[08:30] <zyga> mvo: I'm using git-lp that I wrote (and I'm using all the time for the past three years)
[08:33] <mvo> zyga: nice, where can I find it?
[08:34] <zyga> mvo: https://github.com/zyga/git-lp
[08:34] <zyga> https://github.com/zyga/git-lp/wiki
[08:35] <zyga> mvo: if you have any issues just ping me
[08:35]  * mvo looks
[08:35] <zyga> mvo: it's just a single file, drop it in $PATH somewhere
[08:35] <zyga> mvo: apply the damn patch to bzr and you're all set
[08:36] <zyga> (instructions on the wiki might be a bit stale, I wrote them at around 12.04 time frame)
[08:36] <mvo> uh, I vaguely remember the patch
[08:36] <zyga> :D
[08:49] <zyga> mvo: how often does snapcraft merge processor (tarmac?) runs?
[08:49] <mvo> zyga: should be every 10min, but I think there was a commit message missing, I set one now
[08:51] <zyga> mvo: ah, sorry, I'm used to autogenerated commit messages
[08:51] <zyga> thanks
[08:51] <mvo> no worries
[08:51] <mvo> and yes, that is (much) nicer
[08:53] <zyga> ok, the other half of the change is now pushed
[08:53] <zyga> mvo: https://code.launchpad.net/~zyga/snapcraft/fix-logging-calls/+merge/269167
[08:58] <mvo> meh, its still updating the diff
[08:58]  * mvo waits (im)patiently
[08:58] <zyga> mvo: yeah, is is oddly slow
[08:59] <zyga> mvo: I have another branch to sweeten the wait
[08:59]  * zyga cannot wait till he gets to the part of improving plainbox-based tests
[09:00] <zyga> mvo: https://code.launchpad.net/~zyga/snapcraft/fix-process-leak/+merge/269172
[09:00] <zyga> it's pretty odd because all the delta shows up fine http://bazaar.launchpad.net/~zyga/snapcraft/fix-logging-calls/revision/136
[09:01] <zyga> and the one on the 2nd branch is already generated
[09:06] <zyga> mvo: both branches are reviewable now
[09:06] <mvo> zyga: and are reviewed :P
[09:06] <zyga> oh, sorry :)
[09:06] <mvo> thanks again zyga, much appreciated!
[09:06] <zyga> thank you :)
[09:06] <zyga> mvo: I have plenty more :-)
[09:06] <mvo> thats good
[09:07] <mvo> keep them coming and we will name the next release after you :)
[09:07] <zyga> hahaha :-0
[09:07] <zyga> :-)
[09:07] <zyga> when I'll run out of ideas I'll start fixing pep-8 issues and adding docstrings everywhere
[09:08] <mvo> lol
[09:09] <ogra_> ricmm, any luck with the sfdisk hacking ?
[09:11] <ogra_> mvo, so i guess we can create a raspberry subtree on snappy-hub to push the RPi setup to  ?
[09:11] <mvo> ogra_: its seems to be, yes
[09:11] <mvo> ogra_: thats what I heard yesterday :)
[10:20] <imuguruza> longsleep: just one rapid question: device tree needs to recompile for exposin /dev/spidev0.0 right??
[10:20] <imuguruza> Thanks in advance!
[10:21] <imuguruza> (Talking about your OdroidC1 Snappy image)
[10:21] <imuguruza> I meant /dev/spidev0.1
[10:28] <zyga> mvo: I have a bigger one now
[10:28] <mvo> zyga: nice
[10:29] <zyga> mvo: https://code.launchpad.net/~zyga/snapcraft/fix-1486659/+merge/269190
[10:29] <zyga> mvo: have look, I tested it obviously but there are no tests for that yet
[10:30] <zyga> mvo: I'll get to add tests but I'm not familiar with how to do it yet and I still think it's important to merge fixes for real issues, even if they are not tested automatically
[10:32] <zyga> mvo: there's one more issue that i didn't know how to fix, if the selected key is encrypted and there's no agent around, it will propmt the user, I wanted to prevent that somehow but I'm not sure how yet
[10:33] <zyga> mvo: also, if you want me to split this branch into separate branches & file bugs for various sub-issues, I can do that easily
[10:37] <mvo> zyga: thanks, I think its fine and I agree with the reasoning , I have a look now (or maybe after lunch if I don't finish in time :)
[10:40] <zyga> mvo: thanks
[10:44] <zyga> sergiusens: ping
[10:44] <zyga> sergiusens: around? :-)
[10:46] <sergiusens> zyga: yeah, but need to get some coffee, so start typing and I'll get back to you ;-)
[10:46] <zyga> sergiusens: thanks, I have a few ideas I want to discuss with you
[11:34] <plars> zyga: hey
[11:35] <zyga> plars: hey
[11:35] <ricmm> ogra_: nothing yet ;) working on that this afternoon
[11:35] <zyga> plars: in a meeting
[11:35] <zyga> plars: I got your message
[11:35] <plars> zyga: I'm still not having much luck getting chainloading to work with inception in kvm, and still issues with mountpoints
[11:35] <plars> zyga: sure, np... just sometime today, maybe we can walk through it
[11:35] <zyga> plars: I will fix that today
[11:36] <ogra_> ricmm, so should we start in parallel on two approaches (me going the parted route) ? just to be safe ?
[11:36] <zyga> plars: I'm working on some improvements though they also intersect with other parts of the stack
[11:36] <zyga> plars: I'll tell you more later today
[11:36] <plars> zyga: I also have some other stuff I was changing in my local branch, but wasn't sure where to push it to. There's no project that I could find
[11:36] <zyga> plars: I'll make one shortly
[11:36] <zyga> plars: right now you can just push it to any git repo
[11:37] <zyga> plars: I can work with that
[11:38] <ricmm> ogra_: yea take a look at doing it with parted
[11:38] <ogra_> great ...
[11:38] <ricmm> if I get something for this we can change to it due to size improvements I guess
[11:38] <ricmm> but you already know how to do it with parted, so best to move forward
[11:38] <ogra_> it also seems like you cant really resize GPT partitions at all ...
[11:38] <ogra_> all docs i can find delete the old one and create a new one with all tools
[11:39] <ogra_> i have to test what resize in parted actually does ... if we need to delete and re-add that means even more math and scripting :/
[11:40] <ogra_> silly GPT !
[11:51] <ogra_> ppisati, btw, i dont think a watchdog will help with the 0byte kernel and dtb files ... we should have checks in the bootloaders and do the auto-fallback there
[11:52] <ogra_> (not sure how hard that is to do in grub ... in uboot it is surely possible to check the size and file existence)
[11:53] <emilebosch> hi guys, can someone tell me a little bit how to create a snappy package with postgreql and rails in it., are there any examples online somewhere?
[11:53] <zyga> sergiusens, mvo: I would appreciate feedback on this mr, I have more things in the pipe and I (_crazy_ schedule) need to know I can land things effectively https://code.launchpad.net/~zyga/snapcraft/fix-1486659/+merge/269190
[11:53] <zyga> if you are blocked/cannot review things/disagree with the changes, i'd like this feeback sooner rather than later
[11:54] <ogra_> emilebosch, take a look at snapcraft https://developer.ubuntu.com/en/snappy/snapcraft/your-first-snap/
[11:54] <ogra_> (it is still very young and rough on the edges, please file bugs if you find issues)
[11:55] <emilebosch> ogra_: thanks, i just want to know a bit on the internals in order to understand how the services work. are they converted to systemd targets?
[11:56] <ogra_> if you define a service in the package.yaml a systemd unit is created for it, yes
[11:57] <emilebosch> ogra, ok so are snaps than basically lxd containers?
[11:57] <emilebosch> with a systemd as init?
[11:57] <ogra_> no, there are no containers ...
[11:58] <ogra_> a snap runs natively on your system but wrapped by a launcher and confined by apparmor
[11:58] <emilebosch> huh.  now i am confused. ok i need to read about the internals instead of annoying you guys, where can i find it
[11:58] <emilebosch> aaah
[11:58] <emilebosch> feels a bit weird now since ubuntu is moving to lxd/lxd
[11:59] <ogra_> there is an lxc/lxd framework in the works and there is also a docker framework in the snap store ... but you would have to explicitly depend on them and have them installed for contsainer use
[11:59] <ogra_> but by default snaps are just jailed on the system without containers around them
[12:02] <emilebosch> ogra what would be the upgrade scenario’s for snaps? in the sense lets say i have an app that runs a database then in release a new version how would it be upgraded?
[12:03] <ogra_> your snap has a data dir where it stores such stuff ... that data dir is migrated (copied for now) durinng upgrades
[12:03] <emilebosch> thanks
[12:04] <ogra_> it is reflected in the $SNAP_APP_DATA_DIR env var that is exported to your snaps environment when things start
[12:05] <emilebosch> ok awesome. is ther emore in-depth documentation avialable?
[12:05] <ogra_> https://developer.ubuntu.com/en/snappy/guides/security-policy/
[12:06] <ogra_> that should list all the vars ...
[12:06] <ogra_> and indeed there are https://developer.ubuntu.com/en/snappy/guides/package-metadata/ and https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/
[12:07] <ogra_> and a very basic tutorial at https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/
[12:10] <emilebosch> awesome thanks ogra_
[12:12] <ogra_> mvo, looking at http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/1196 ... doesnt the build also create an initrd.img that should be deleted ?
[12:17] <mvo> ogra_: that is moved earlier unless I miss something
[12:22] <ogra_> ok
[12:22] <ogra_> i did only see the patch ... slightly out of context indeed
[12:23] <mvo> zyga: sorry for the delay, all approved now
[12:23] <zyga> mvo: thanks a lot, no need to worry :-)
[12:24] <zyga> mvo: a related question, where should *.snap files go?
[12:24] <zyga> are they expected to build to current working directory?
[12:33] <mvo> zyga: I think that was the plan, mterry was working on this part, I need to check the source/spec to be certain
[12:33] <zyga> mvo: if you have a link handy I'd like to see as well
[12:34] <zyga> joc_: https://code.launchpad.net/~zyga/snapcraft/extra-run-features have a look at this please
[12:34] <zyga> joc_: get this branch somwehere on the side and tell me if that lets you run snapcraft run to play with real wifi
[12:35] <zyga> the corresponding MR is https://code.launchpad.net/~zyga/snapcraft/extra-run-features/+merge/269202
[12:37] <mvo> zyga: I look at this now
[12:37] <zyga> mvo: thanks
[12:37] <zyga> mvo: the use case is this
[12:37] <zyga> mvo: well, it's all explained there :)
[12:38] <zyga> mvo: but it makes development faster as you can just assemble/run
[12:38] <zyga> mvo: and often you don't need to involve real hardware
[12:39] <zyga> my usb wifi dongle stopped working
[12:39] <zyga> or maybe not?
[12:39]  * zyga tries
[12:41] <cwayne> i havent been able to get mine working on rpi2 with the newer image
[12:41] <cwayne> zyga: ^ not sure if thats related at all, but fyi  :)
[12:41] <ogra_> cwayne, oh, ?
[12:41] <zyga> cwayne: I don't have a rpi2
[12:42] <cwayne> ogra_: yeah, it keeps saying that it failed to associate with the driver and there's auth failures, even though i've looked over the psk 10,000 times and its correct
[12:42] <ogra_> cwayne, if the driver is in the kernel/modules it should just work by adding the necessary data to /etc/network/interfaces
[12:42] <zyga> sigh
[12:42] <zyga> yes it's dead
[12:42] <cwayne> ogra_: i've even copied the /etc/network/interfaces from my rpi1 with raspbian with the same dongle and it works there
[12:43]  * zyga needs to buy another wifi eh
[12:43] <ogra_> smells like a driver issue then ... i know others use wlan dongles just fine ... do you know what driver it usually uuses ?
[12:43] <cwayne> i'd had it working on an older image, but i've also physcially moved it, maybe its not getting a strong enough signal..
[12:43] <zyga> ogra_: which dongle are you using?
[12:44] <zyga> ogra_: amazon links appreciated
[12:44] <ogra_> zyga, i dont :P
[12:44]  * ogra_ has wires
[12:44] <zyga> why do we always have to be on the front lines ;-)
[12:44] <ogra_> zyga, iirc rickspencer3 uses one on his BBB
[12:44] <rickspencer3> hi ogra_
[12:45] <ogra_> hey rickspencer3
[12:45]  * rickspencer3 looks for context
[12:45] <ogra_> rickspencer3, you use a wlan dongle on your BBB, dont you ?
[12:45] <rickspencer3> ogra_, no, I could not get either of mine to work
[12:45] <ogra_> zyga, looks for recommendations for buying one that works
[12:45] <ogra_> oh
[12:45] <zyga> ogra_: see
[12:45] <rickspencer3> zyga, if you get one that definitively works, can you let me know?
[12:45] <ogra_> yeah :(
[12:45] <rickspencer3> :)
[12:46] <zyga> ogra_: I'll buy you one
[12:46] <zyga> rickspencer3: absolutely rick
[12:46] <cwayne> i got this one: http://www.amazon.com/gp/product/B00FWMEFES?psc=1&redirect=true&ref_=oh_aui_detailpage_o03_s00
[12:46] <zyga> rickspencer3: I'll get a few and try what works
[12:46] <cwayne> and it did work before
[12:46] <cwayne> maybe i just need to move it or something.. who knows
[12:46] <zyga> cwayne: looks like http://www.amazon.es/TP-LINK-TL-WN725N--Nano-Adaptador-garant%C3%ADa/dp/B008IFXQFU/ref=sr_1_1?ie=UTF8&qid=1440593083&sr=8-1&keywords=wifi+usb
[12:46] <zyga> cwayne: I wonder what's the chipset inside
[12:46] <zyga> anyway, cha-ching, let's get an see
[12:47] <ogra_> zyga, hmm, i havent seen one of these NANO adapters tht had a linux supported chipset (though that was like 1.5y ago when i looked at them last)
[12:48] <zyga> ogra_: there's just one rpi2 now, right?
[12:48] <zyga> anyone that I get is good
[12:49] <zyga> joc_: any luck?
[12:49] <zyga> joc_: does it work for you
[12:49] <ppisati> ogra_: yeah
[12:50] <ppisati> ogra_: my point there was that
[12:50] <ppisati> ogra_: the hack that i implemented in uboot
[12:50] <ppisati> ogra_: is that, either you boot the kernel
[12:50] <ppisati> ogra_: or it forcefully reboots the board
[12:50] <ppisati> ogra_: so the a/b logic has another chance to run or whatever we put there
[12:51] <ppisati> ogra_: and once the kernel takes over
[12:51] <ppisati> ogra_: uboot can't do anything
[12:51]  * zyga looks for a master bug to get python3-project projects to see each other
[12:52] <mvo> ppisati: hi, I hope I don't get on your nerves yet but did you had a chance to check https://bugs.launchpad.net/snappy/+bug/1471868 - its a bit confusing, looks like the kernel is doing funny stuff if init is broken (and it seems to be different depending on architecture)
[12:53] <ppisati> well, the kernel can't do anything
[12:53] <ogra_> ppisati, well, just blindly resetting wont make the ab switch ... you need to actively set snappy_ab to the opposite value too ... else you just create a loop
[12:53] <ppisati> if there's no init
[12:53] <ppisati> it doesn't know what to do
[12:54] <ppisati> iirc it even looks in a couple of places
[12:54] <ppisati> for alternate inits
[12:54] <ogra_> yeah
[12:54] <ppisati> but if the fs is corrupted
[12:54] <ogra_> 4 or 5 even
[12:54] <ppisati> and it cannot exec any of time
[12:54] <ppisati> you are screwed
[12:54] <ppisati> it can probably panics and reboot
[12:54] <ppisati> but i've to check
[12:54] <mvo> ppisati: so this is a test when its broken and I think its doing the right thing on arm (panics) but not on amd64
[12:54] <ogra_> it should panic
[12:55] <mvo> ppisati: we broke init deliberately for the test of course
[12:55] <mvo> ppisati: feel free to downgrade/comment if there is nothng that the kernel can do of course, its all part of the robustness dance :)
[12:56] <ppisati> ogra_: well, the watchdog sets a timer in hw
[12:56] <ppisati> ogra_: and if it expires, it restes the board
[12:56] <ppisati> ogra_: i mean, i cant change a var in the exec
[12:57] <ppisati> ogra_: because the reset is done in hw, i can't run a trigger for example
[12:57] <ppisati> mvo: that's weird, i've to test it
[12:58] <mvo> ppisati: thanks! no real rush, I'm mostly curious about it
[12:59] <mvo> (well, we should fix it eventually but its not omg-now priority or anything)
[12:59] <ppisati> mvo: can you make a list of all these 'robustness thing' bugs?
[12:59] <mvo> ppisati: sure, I think I subscribed you to all of them, but I'm happy to add a tag, is "failover-robustness" good?
[12:59] <mvo> (as tagname?)
[13:00] <ppisati> mvo: snappy robustness or something like that?
[13:01] <mvo> ppisati: works for me, so snappy-robustness as tag in LP and I send you the url that shows all such bugs?
[13:01] <ppisati> mvo: that would be perfect
[13:01] <ogra_> ppisati, right, thats why i mean a watchdog is the wrong approach, since we need to switch over from a to b (or the opposite)
[13:02] <ppisati> ogra_: once mvo is done collecting all the robustenss bugs, we can discuss about it
[13:02] <ogra_> yeah
[13:12] <rickspencer3> arg, I can't remember how to hw-assing to the gpio pins
[13:12] <rickspencer3> (BeagleBoneBlack)ubuntu@localhost:~$ sudo snappy hw-assign bike-and-bus-sensor.sideload '/sys/class/gpio/'
[13:12] <rickspencer3> invalid hardware device
[13:12] <rickspencer3> ?
[13:12] <ogra_> didnt you open a bug about it yesterday ?
[13:13] <zyga> joc_: ha, the option is already very seful
[13:13] <zyga> useful
[13:13] <rickspencer3> ogra_, differnet bug
[13:13] <zyga> joc_: SNAPCRAFT_RUN_QEMU_ARGS="-smp 2" snapcraft run
[13:13] <zyga> joc_: and you can write a simple "amd I SMP" test case
[13:13] <zyga> joc_: go for it!
[13:13] <rickspencer3> ogra_, yesterday I figured out how to do hw-assign for the pins, but now I forget :/
[13:14] <joc_> zyga: just trying the wifi thing - bit of pain cos think need root to access the wifi dev
[13:15] <zyga> joc_: oh
[13:15] <zyga> joc_: hmm
[13:15] <zyga> joc_: patch snapcraft to use sudo there
[13:15] <zyga> joc_: or
[13:15] <zyga> joc_: add yourself to the appropriate group
[13:15] <zyga> joc_: (2nd thing should be better but requires you to login again)
[13:16] <ogra_> rickspencer3, https://bugs.launchpad.net/bugs/1488618
[13:16] <ogra_> (there is a workaround)
[13:16] <rickspencer3> ogra_, yeah, that's a different bug, actually
[13:16] <joc_> zyga: the device is root:root
[13:17] <zyga> joc_: ah, I see
[13:17] <zyga> joc_: that's crap
[13:17] <rickspencer3> and I've applied the work around :)
[13:17] <zyga> joc_: you an try an udev rule to change permissions
[13:17] <zyga> joc_: but I think running it via rut is easier
[13:17] <zyga> joc_: just patch cmd.py to have sudo there
[13:17] <joc_> k
[13:17] <ogra_> rickspencer3, hmm, looks to me like the worakaround should give you full access
[13:17] <zyga> joc_: I'll add an option to make that a possible choice on command line
[13:17] <ogra_> without even needing to call hw-assin again
[13:18] <rickspencer3> ogra_, the work around gives me access only to export
[13:18] <rickspencer3> so it provides access to the program that creates gpio files
[13:18] <rickspencer3> but hten I need access to those files once created
[13:18] <rickspencer3> which, I think, worked yesterday
[13:18] <rickspencer3> but today I can't figure out that I did
[13:18] <ogra_> rickspencer3, well, just add more lines for the other nodes in there
[13:18] <ogra_> whatever you need
[13:19] <rickspencer3> yeah, I can hack around it, but I swear I could just use hw-assign yesterday, so I think I am doing something silly
[13:20] <ogra_> well, the bug says /sys/class is generally denied ... so i would be surpised if you got it working yesterday without hacksd
[13:20] <ogra_> *hacks
[13:21] <ogra_> probably jdstrand can clearify
[13:22] <rickspencer3> well, all I can say is, I had it working with a different snap yesterday
[13:22] <joc_> zyga: seemed to work ok with a sudo added to the kvm call
[13:22] <rickspencer3> it could have been a fluke, i.e. something else I didn't do wrong yesterday that I did wrong today :)
[13:22] <ogra_> func validDevice(device string) bool {
[13:22] <ogra_>  return strings.HasPrefix(device, "/dev") || strings.HasPrefix(device, "/sys/devices")
[13:22] <ogra_> }
[13:23] <ogra_> these are the only two allowed paths when using hw-assign
[13:25] <zyga> joc_: cool, thanks for confirming this
[13:29] <cwayne> ogra_: so i moved my rpi2 physically closer to the AP and now it connects, so there's that :)
[13:30] <ogra_> cwayne, yay
[13:30] <cwayne> zyga: ^
[13:30] <zyga> cwayne: coool
[13:35] <jdstrand> rickspencer3, ogra_: currently we should allow access to the devices that are exported. the problem was that we blocked export/unexport
[13:36] <rickspencer3> jdstrand, well, today I am getting blocked on the exported device :(
[13:36] <jdstrand> rickspencer3: so once you exported, hw-assign should work as expected (hw-assign foo /sys/devices/...)
[13:36] <jdstrand> rickspencer3: what is the denial?
[13:36] <ogra_> jdstrand, /sys/class ...
[13:36] <ogra_> not /sys/devices :)
[13:37] <rickspencer3> jdstrand, I have 2
[13:37] <rickspencer3>  audit: type=1400 audit(1440595711.301:11): apparmor="DENIED" operation="open" profile="bus-and-bike-sensor.sideload_bus-and-bike-sensor_0.1" name="/sys/devices/platform/ocp/481ac000.gpio/gpio/gpio68/direction" pid=726 comm="bus-and-bike-se" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
[13:37] <jdstrand> ok, that one should work with hw-assign
[13:38] <rickspencer3> jdstrand, can you give me the command for hw-assign, I couldn't make it work
[13:40] <jdstrand> sudo hs-assign bus-and-bike-sensor.sideload '/sys/devices/platform/ocp/481ac000.gpio/**'
[13:40] <jdstrand> err
[13:40] <rickspencer3> ug
[13:40] <jdstrand> sudo snappy hw-assign bus-and-bike-sensor.sideload '/sys/devices/platform/ocp/481ac000.gpio/**'
[13:40] <jdstrand> now, the /sys/devices/... could be just /sys/devices/platform/ocp/481ac000.gpio/gpio/gpio68/direction
[13:40] <rickspencer3> wow, taking a while :)
[13:41] <emilebosch> is there anywhere a git repo wiht sample snaps?
[13:41] <emilebosch> or just some apps snappyfied?
[13:41] <jdstrand> but with the glob you shouldn't have to do extra stuff
[13:41] <rickspencer3> let me try rebooting and see what happened
[13:41] <jdstrand> rickspencer3: don't reboot
[13:41] <rickspencer3> too late
[13:41] <rickspencer3> sorry
[13:41] <jdstrand> did the command complete?
[13:41] <rickspencer3> jdstrand, yes
[13:41] <jdstrand> ok that's fine
[13:41] <rickspencer3> I waited for the command to complete :)
[13:41] <rickspencer3> for once I was not too impatient
[13:41] <jdstrand> hehe
[13:43] <jdstrand> rickspencer3: did it work?
[13:43] <rickspencer3> so, here I am again
[13:43] <rickspencer3> : type=1400 audit(1440596552.734:17): apparmor="DENIED" operation="open" profile="bus-and-bike-sensor.sideload_bus-and-bike-sensor_0.1" name="/sys/class/gpio/export" pid=1142 comm="bus-and-bike-se" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
[13:43] <rickspencer3> I thought I fixed that in the apparmour file
[13:43] <jdstrand> ok, yes, that is what requires the workaround rule
[13:43] <jdstrand> oh, I know what happened
[13:44] <ogra_> emilebosch, bzr branch lp:~snappy-dev/snappy-hub/snappy-examples
[13:44] <jdstrand> you added the workaround rule to the profile, then used hw-assign which rewrote the profile
[13:44] <ogra_> (no git ... but bzr :) )
[13:44] <emilebosch> aarg
[13:44] <jdstrand> rickspencer3: ^
[13:44] <emilebosch> ok berw install bzr
[13:44] <rickspencer3> oh
[13:44] <rickspencer3> jdstrand, I did, but, looks like the apparmor profile got regenerated
[13:44] <jdstrand> the good news is, it sounds like mvo was going to hop on this so the workaround rule won't be needed
[13:45] <jdstrand> rickspencer3: yes. the hw-assign blew it away
[13:45]  * jdstrand adds comment to the bug
[13:45] <rickspencer3> ok, I fixed the file and reran the parser
[13:45]  * rickspencer3 reboots
[13:47] <rickspencer3> \o/
[13:47] <rickspencer3> thanks jdstrand that got it working again
[13:48] <jdstrand> that reboot shouldn't be required if you are restarting the correct service. if you feel compelled to try to chase that down, please file a bug and we can chase it down
[13:48] <jdstrand> rickspencer3: sure, np. sorry I forget to mention/didn't think about the fact that hw-assign regenerates the profile yesterday
[13:48] <rickspencer3> meh
[13:48] <rickspencer3> I would have gotten there since the same app armor denial came back
[13:49] <rickspencer3> now I have a happily blinking led again :)
[13:49] <jdstrand> yeah!
[13:49]  * rickspencer3 moves on to controlling it from a web api :)
[13:58] <ogra_> rickspencer3, next step, phone webapp ?
[13:59] <rickspencer3> hehe
[13:59] <ogra_> (though that might be tricky without avahi )
[13:59] <rickspencer3> ogra_, I am going to get the next bus prediction from my local transport companies api
[14:00] <rickspencer3> and first blink a light depending on when the next bus is coming
[14:00] <rickspencer3> then do something similar for the city bikes near me
[14:00] <rickspencer3> then I will add some info the lcd screen
[14:00] <ogra_> ah
[14:00] <ogra_> so you dont want a webapp but integration with the phone notifications !
[14:01] <rickspencer3> yeah, phone notifications could be next
[14:01] <rickspencer3> but, I was just thinking it would be like ambient information
[14:01] <rickspencer3> "oh, bikes are running low, maybe I should leave now instead"
[14:01] <rickspencer3> "hmmm looks like we can take our time, it will be a while before the next bus"
[14:01] <rickspencer3> that kind of thing\
[14:01] <ogra_> yeah
[14:02] <rickspencer3> I'm thinking that if I get really tricky, I can make a web config UI, then other people in DC can make their own, just add their stop and bike station ids :)
[14:07] <mvo> ppisati: https://bugs.launchpad.net/snappy/+bugs?field.tag=snappy-robustness <- the list we talked about earlier
[14:09] <ppisati> ogra_: ^
[14:16] <mvo> pitti: silly question, how can I see if m systemd "ubuntu-snappy.boot-ok.service" was executed before or after the "rc.local" script? and if it was run before, is there a way to ensure that ubuntu-snappy.boot-ok.service is run last (ideally very last :) ?
[14:16] <pitti> hey mvo
[14:17] <pitti> mvo: there is no "very last" concept in any recent init system, I'm afraid (not even in SysV with insserv)
[14:17] <mvo> pitti: hm, do you have a idea what might be the closest approximation?
[14:17] <pitti> mvo: you can check systemctl show -p ExecMainStartTimestampMonotonic ubuntu-snappy.boot-ok.service
[14:17] <mvo> pitti: after getty is run or something?
[14:17] <pitti> (that gives you subsecond precision)
[14:18] <pitti> mvo: and compare that to the time stamp in rc-local.service
[14:18] <pitti> mvo: or just check the journal which one was starting/started after which
[14:18] <mvo> pitti: yeah, thats helpful
[14:18] <pitti> mvo: After=multi-user.target is fairly late
[14:19] <mvo> pitti: I think thats the culprit, our book-ok script runs before rc.local
[14:19] <mvo> pitti: cool, let me try this
[14:19] <pitti> mvo: I've heard of several people wanting their unit to be the "very last", they can't *all* be that :)
[14:19] <mvo> pitti: ahah, if its late enough thats ok
[14:19] <pitti> mvo: but most stuff runs < multi-user.target, at that point you can definitively call the boot a "success"
[14:19] <mvo> pitti: I just want to be sure that it made it to the prompt
[14:19] <mvo> pitti: thanks (as always!) for you great and prompt help :)
[14:19] <pitti> mvo: soif that's the intention ("is my boot okay?), then After=multi-user.target sounds about right
[14:20] <mvo> great
[14:20]  * mvo will add it
[14:20]  * pitti hugs mvo
[14:20]  * mvo hugs pitti
[14:20] <mvo> and one more bug down
[14:20] <mvo> .)
[14:20] <pitti> mvo: FTR, I saw LP #1457491, still in my queue; sorry for the delay
[14:21] <mvo> pitti: aha, yeah, thats another one where I would prefer if it could go to auto-reboot if a certain kernel cmdline is set
[14:21] <mvo> pitti: i.e. I guess I just need something like a custom preexec script or something
[14:21] <pitti> mvo: probably just OnFailure=reboot.target
[14:22] <pitti> (or something such; I haven't checked the details yet)
[14:22] <mvo> aha, cool
[14:22] <mvo> thats pretty amazing if its that simple
[14:22] <pitti> and I'm not very familiar with the OnFailure= bit yet, need to test this
[14:22]  * pitti tries hard to catch up with mail/bug/IRC queue
[14:23] <mvo> pitti: no worries, not urgent really :) I can dig with the new OnFailure info a bit more myself
[14:41] <ogra_> ppisati, gigantic :P
[16:38] <elopio> mvo: I don't get why snappy-from-branch is not working for your branch. When I pring $(which snappy) it shows /tmp/adt-run.wnFI56/tree/_integration-tests/bin/snappy
[16:44] <elopio> ah, sudo which snappy prints /usr/bin/snappy
[17:50] <mvo> elopio: ohhh, of course, thanks!
[17:51] <mvo> elopio: I fix tomorrow then, have you commented in the mp already? if not, please do so that I don't forget about it agian :)
[17:51] <elopio> mvo: I can't preserve the user path. An alias doesn't work, because ExecCommand adds the full path to the binary. And go doesn't seem to like passing PATH=$PATH in the command args.
[17:57] <sergiusens> elopio: tell sudo not to wipe the env
[17:58] <elopio> sergiusens: -E doesn't work. -i doesn't work.
[18:04] <rickspencer3> I seem to recall that there was some kind of cli command that I could issue that would let systemd tell me what messages my app wrote out
[18:05] <rickspencer3> does anyone remember what I mean?
[18:22] <elopio> sergiusens: https://code.launchpad.net/~elopio/snappy/sudo_path/+merge/269252
[18:22] <elopio> that's the only way I could make it work.
[18:29] <rickspencer3> jdstrand, if I am seeing this:
[18:29] <rickspencer3> Aug 26 18:26:45 localhost kernel: [   74.556368] audit: type=1400 audit(1440613605.338:11): apparmor="DENIED" operation="capable" profile="bus-and-bike-sensor.sideload_bus-and-bike-sensor_0.1" pid=1561 comm="bus-and-bike-se" capability=12  capname="net_admin"
[18:29] <rickspencer3> can I just add net_admin to my caps or something?
[18:29] <jdstrand> this is that bug from before
[18:29] <rickspencer3> this is being hit when I write Go code that accesses an https resource
[18:29]  * jdstrand finds it
[18:30] <jdstrand> https://bugs.launchpad.net/snappy/+bug/1465724
[18:30] <rickspencer3> jdstrand, so, this seems like a common thing to do, no?
[18:31] <rickspencer3> use Go to access an https resource?
[18:31]  * rickspencer3 thought this was fixed a while ago
[18:31] <jdstrand> yes, but the denial should be harmless. is it keeping your app from running?
[18:31] <jdstrand> we reviewed it and it is just an out of order check in the kernel
[18:32] <jjohansen> jdstrand: no cap net_admin should not be handed out like candy
[18:32] <rickspencer3> jdstrand, yes, it keeps my app from running
[18:32] <jjohansen> it allows modifying routing tables, interface config, masquerading
[18:32] <rickspencer3> so far as I can tell, anyway
[18:32] <jdstrand> jjohansen: no one is proposing that
[18:33] <jjohansen> jdstrand: give it out to every go app is handing it out like candy
[18:33] <jdstrand> jjohansen: no one is proposing doing that :)
[18:33] <jdstrand> jjohansen: it is a kernel bug
[18:33] <jdstrand> jjohansen: see https://bugs.launchpad.net/snappy/+bug/1465724/comments/9
[18:34] <rickspencer3> jdstrand, maybe it isn't keeping my app from running, hard to say
[18:34] <jdstrand> rickspencer3: ok, for now you have to modify the profile to add 'capability net_admin,' to unblock you. the bug was deprioritized because we thought it was a harmless denial. we'll up the priority
[18:34] <elopio> rickspencer3: fwiw, we have this card: https://trello.com/c/V5pmALwm/197-document-the-files-and-logs-that-help-to-diagnose-problems-in-a-snap
[18:35] <rickspencer3> jdstrand, I just add that to the end of the app armor profile?
[18:35] <rickspencer3> I can try it, and see if it fixes my app
[18:35] <jdstrand> rickspencer3: ah, well, if you add that rule and it starts working, then it likely is the cause, but if it still doesn't work, then it probably isn't
[18:35] <jdstrand> rickspencer3: yes, before the trailing '}', like before
[18:36] <sergiusens> elopio: here you go: https://code.launchpad.net/~sergiusens/snapcraft/validation/+merge/269120
[18:36] <sergiusens> elopio: I'll trade ;-)
[18:37] <rickspencer3> elopio, right, so I am printing debug information from my code, but I forget how to read it
[18:37] <rickspencer3> I recall there is some trick to telling journalctl how to look at your debug output
[18:37] <elopio> sergiusens: wait on mine, because it stopped working :/
[18:38] <elopio> sergiusens: and you probably owe me like 400 lines. This is not fair trade ;)
[18:38] <jdstrand> sudo journalctl --unit <name of file in /etc/systemd/system>
[18:39] <rickspencer3> jdstrand, for what it is worth, adding the cap didn't fix my app ;)
[18:41] <tyhicks> rickspencer3: that's good to know - I was fairly sure that the AppArmor denial wouldn't affect go apps but I wasn't 100% sure
[18:41] <rickspencer3> right
[18:42] <jdstrand> rickspencer3: ok, thank you for the feedback
[18:42] <sergiusens> elopio: it's mostly tests ;-)
[18:42] <elopio> sergiusens: ready now. I forgot to make it writable.
[18:42] <jdstrand> tyhicks: we might want to reconsider the current priority of that bug because it is confusing to the developer
[18:43] <tyhicks> jdstrand: I agree that it is confusing
[18:54] <elopio> sergiusens: tests are also code!
[18:54] <elopio> If you prick them, do they not bleed?
[18:56] <sergiusens> elopio: not in production ;-)
[18:56] <sergiusens> :-P
[19:27] <elopio> sergiusens: I don't understand why you have to quote the version.
[19:32] <sergiusens> elopio: because if not, it is not a string according to the yaml spec
[19:33] <sergiusens> elopio: and python assigns an int to it for things like '1', '2'
[19:33] <elopio> sergiusens: but isn't the vendor a string? And it has no quotes.
[19:33] <sergiusens> elopio: if it can detect it is a string, it will be a string
[19:33] <sergiusens> elopio: there are no letters in 1
[19:34] <elopio> I find it confusing. Can't we overwrite the parsing to make the version always a string?
[19:34] <sergiusens> elopio: notice that if it were 1.1 it would also be an int, but maybe 1.1.1 would be a string
[19:34] <elopio> yeah, I understand now.
[19:34] <sergiusens> elopio: maybe, I need to look into the engine a bit more
[19:35] <elopio> but I wonder if this is a common practice in yamls. Or just something that's forced on us because of python being too smart.
[19:35] <sergiusens> elopio: well I know how to fix this in go :-)
[19:36] <sergiusens> elopio: I bet there is a way in python and I have it somewhere to check; in any case, version is deprecated
[19:43] <elopio> sergiusens: we are not going to have versions?
[19:48] <elopio> that's enough for my back this morning, I'll have lunch and take a break. bbl.
[20:41] <sergiusens> elopio: is python 3.4 available for trusty?
[20:42] <sergiusens> elopio: and yeah, versions are meaningless, at least manual ones; just look at all our packages ;-)


[01:38] <chrisccoulson> fta - you still there?
[02:32] <LLStarks> ctrl+L on the addon tab: http://imgur.com/aeLej
[02:32] <LLStarks> wat
[02:32] <LLStarks> what kind of madman would do that instead of putting the adressbar in the addon tab?
[12:01] <chrisccoulson> w00t - https://edge.launchpad.net/~mozillateam/+archive/thunderbird-next \o/
[12:14] <fta> chrisccoulson, what is w00t? the ftbfs? ;)
[12:15] <chrisccoulson> heh, not so much ;)
[12:15] <chrisccoulson> i just noticed that. i guess i should use pbuilder occasionally ;)
[12:36] <napster> Can I ask a question related to xul based application development here?
[12:37] <napster> Can I ask a question related to xul based application development here asac ?
[12:38] <asac> napster: this is the wrong place ... its about integrating xul/ffox etc. into ubuntu
[12:38] <asac> not about development
[12:38] <asac> irc.mozilla.org has a few channels around that
[12:38] <asac> topic
[12:40] <napster> asac: oh ok. But I'm unable to connect to that server. It shows nothing when I try /join #addons
[12:40] <chrisccoulson> right, thunderbird builds should work now :)
[12:41] <asac> napster: not sure if that channel is supposed to exist ... start here: https://wiki.mozilla.org/IRC
[12:41] <napster> asac: ty
[12:41] <asac> napster: http://irc.mozilla.org/
[12:41] <asac> thats a more complete list
[12:42] <asac> not sure
[12:42] <asac> you will find out ;)
[12:42] <asac> i am sure
[12:42] <napster> asac: ok, my browser shows nothing for that page but timed out
[12:42] <napster> asac: I mean http://irc.mozilla.org/
[12:43] <asac> works for me
[12:43] <asac> must be on your side
[12:43] <asac> napster: its also a different IRC network: irc.mozilla.org (for your client)
[12:43] <chrisccoulson> napster, you want #xulrunner on irc.mozilla.org
[12:44] <napster> chrisccoulson: asac: yeah, I know, but can't connect to that server at all from my xchat :)
[12:44] <napster> its shows no errors or warning
[12:44] <napster>  Disconnected (Connection timed out).
[12:44] <napster>  Cycling to next server in Mozilla Net...
[12:44] <napster> this is only what I can see
[12:45] <asac> i am no ton that server atm
[12:45] <asac> so no clue
[12:45] <asac> but the website opens for me quickly
[12:45] <asac> might be your IP is a previous spammer one
[12:45] <asac> if you have dynamic IP try to get a new IP
[12:45] <napster> asac: never, I've been to that newtwork for the first time
[12:45] <asac> do you have a static IP?
[12:45] <napster> asac: no
[12:46] <napster> its dynamic
[12:46] <asac> then try to get a new IP
[12:46] <napster> Yeah I guess os
[12:46] <napster> *so
[12:46] <asac> yours might have been used by a intrusive hacker/virus etc.
[12:46] <napster> see you
[12:46] <asac> cu
[12:53] <napster> asac: no hope :(
[12:53] <napster> anyway leave it
[13:00] <asac> your whole IP block might be blacklisted
[13:02] <napster> asac: Thats is awesome. I'm not able to connect because some else has spammed them! Very nice :)
[13:02] <asac> dont know
[13:02] <asac> just a guess ;)
[13:02] <asac> if you can connect to freenode and not irc.mozilla.org i would think it has something to do with you :)
[13:02] <asac> chrisccoulson: does irc.mozilla.org work for you atm?
[13:02]  * asac is not connected there
[13:03] <asac> napster: for the meantime try mibbit.com
[13:03] <asac> its a webinterface ... maybe that has mozilla net support
[13:03] <asac> really sucky thing, but if nothing else works ;)
[13:04] <napster> asac: that sounds good for now. thanks mate
[13:04] <asac> yeah works for me
[13:04] <asac> i am in #addons using mibbit.com ;)
[13:05] <asac> but #xulrunner might be better for you ... not sure
[13:05] <napster> ok
[13:05] <asac> i am mostly did core development ;)
[13:06] <napster> asac: oh, thats good bro
[13:52] <chrisccoulson> asac - sorry, popped out for some lunch
[13:52] <chrisccoulson> yeah, irc.mozilla.org is working here
[13:56] <asac> np
[14:02] <chrisccoulson> fta - have you got a few minutes for setting up the thunderbird dailies?
[14:03] <chrisccoulson> asac - are you able to add me as admin to ~mozillateam? I can't create PPA's at the moment :(
[14:03] <chrisccoulson> micahg alreday tried, but he couldn't do it
[14:15] <fta> chrisccoulson, sure
[14:16] <chrisccoulson> fta - so, the current thunderbird stable branch in natty is now coming from lp:~mozillateam/thunderbird/thunderbird-3.1.head
[14:17] <chrisccoulson> what is currently lp:~mozillateam/thunderbird/thunderbird.head will become the thunderbird-3.3 packages (although I've not made any changes to that branch yet, but i've got the changes ready to push)
[14:17] <chrisccoulson> so, it's basically the same layout as firefox then
[14:23] <asac> chrisccoulson: not?
[14:23] <asac> ok
[14:24] <asac> chrisccoulson: gnomefreak is owner ;)
[14:24] <asac> chrisccoulson: is he ever here?
[14:24] <asac> try to contact him or talk to IS to make you owner of the team
[14:24] <chrisccoulson> asac - i haven't seen hi for a while
[14:24] <chrisccoulson> *him
[14:24] <chrisccoulson> thanks
[14:24] <asac> one sec
[14:30] <fta> maybe clean-up the team too; too many idle people in there
[14:33] <fta> chrisccoulson, today, i have: thunderbird-3.1.head = lp:~mozillateam/thunderbird/thunderbird-3.1.head and thunderbird.head = lp:~mozillateam/thunderbird/thunderbird.head
[14:33] <chrisccoulson> fta - yeah, that looks right
[14:34] <fta> i didn't change anything yet
[14:35] <fta> and the bot has: http://paste.ubuntu.com/574995/
[14:35] <chrisccoulson> fta - ah, ok. so, the "thunderbird" source package will be coming from thunderbird-3.1.head, which is the current stable version
[14:36] <chrisccoulson> athunderbird.head will be "thunderbird-3.3"
[14:36] <chrisccoulson> *and
[14:36] <chrisccoulson> my keys keep not working :(
[14:36] <fta> hmm
[14:43] <fta> chrisccoulson, the stable branch is currently called thunderbird.head right?
[14:43] <fta> the daily is thunderbird-3.1.head
[14:43] <chrisccoulson> oh, i'm confused now :/
[14:43] <chrisccoulson> heh :)
[14:43] <fta> you want me to swap those, is that correct?
[14:45] <chrisccoulson> fta - there are daily builds for thunderbird-3.1? i only see thunderbird in the PPA
[14:45] <fta> chrisccoulson, http://paste.ubuntu.com/575004/
[14:47] <chrisccoulson> fta - assuming i understand the configuration, i think we want something like this: http://paste.ubuntu.com/575003/
[14:48] <fta> the 2nd vpattern is 3.3, not 3.1
[14:48] <chrisccoulson> yeah, i didn't notice that bit ;)
[14:48] <fta> that's what preventing the bot to push the dailies atm
[14:49] <fta> so you need to swap the branches in lp
[14:50] <fta> right?
[14:52] <chrisccoulson> fta - i've branched what is currently lp:thunderbird to lp:thunderbird-3.1.head
[14:53] <chrisccoulson> and then, i have the changes to lp:thunderbird.head stored locally which update it to 3.3
[14:55] <fta> hm, what happened to the old lp:thunderbird-3.1.head branch then?
[14:59] <fta> to be consistent with ff, i should call the daily thunderbird-trunk.head
[15:00] <fta> pff
[15:00] <chrisccoulson> fta - i moved the old lp:thunderbird-3.1.head branch to lp:thunderbird-3.1.head.old, but i didn't realise your bot was still using it when i did that
[15:01] <fta> well, it's not, since trunk moved away from 3.1
[15:02] <fta> n-m, i'll manage
[15:02] <chrisccoulson> thanks
[15:04] <m_conley> Hey all - I've started work on integrating Thunderbird into the Messaging Menu.  Mozilla Labs project page is here:  https://mozillalabs.com/messaging/messaging-menu/
[15:04] <m_conley> Any and all feedback welcome.  :)
[15:04] <fta> chrisccoulson, could you please rename thunderbird.head to thunderbird-trunk.head in lp, to match firefox?
[15:05] <chrisccoulson> fta - yeah, sure
[15:05] <fta> it has thunderbird-3.3 as src package name, right?
[15:06] <chrisccoulson> fta - yeah, it does. ok, i've renamed that now
[15:07] <chrisccoulson> in future, we'll probably just use firefox-trunk and thunderbird-trunk as the source package names too
[15:09] <chrisccoulson> m_conley, that's awesome :-)
[15:09] <m_conley> chrisccoulson: thanks! :D  Pretty stoked.  It needs some polish, but I'm happy to see it mostly work.
[15:12] <chrisccoulson> m_conley, the extension is arch-specific isn't it?
[15:12] <m_conley> chrisccoulson: oh, yes - good point.  :/  I should probably add that to the add-on listing.
[15:12] <m_conley> i386 for now.
[15:12] <chrisccoulson> heh :)
[15:29] <m_conley> chrisccoulson: I may have asked you this before, but when you put together the build structure for your globalmenu-extension... did you just go at it via trial and error, or was there some documentation you were referring to?
[15:37] <chrisccoulson> m_conley, it was mostly just copying config/ and build/, and other bits i knew that i needed. but some of it was trial and error ;)
[15:37] <m_conley> chrisccoulson: gotcha.  thanks. :)
[15:57] <micahg> chrisccoulson: shouldn't thunderbird.head stay the current dev release and a new thunderbird-trunk become thunderbird-3.3?
[16:28] <fta> micahg, we don't have a firefox.head branch
[16:33] <micahg> fta: yep, but we don't have a versioned thunderbird branch at the moment for each release and I'd like to keep it that way
[16:34] <micahg> I'd prefer thunderbird.head to remain the distro head branch
[16:36] <fta> we have thunderbird-3.1.head
[16:36] <fta> you last touched it months ago
[16:41] <micahg> fta: yep, but then it was merged into thunderbird.head
[16:46] <chrisccoulson> i don't mind having thunderbird.head for the current 3.1 stable releases
[16:46] <chrisccoulson> but we should probably do the same for firefox at some point too ;)
[16:46] <chrisccoulson> hmm, third time lucky with the tbird builds :(
[16:47] <micahg> chrisccoulson: it made sense when we weren't doing major version upgrades in stable releases
[16:49] <chrisccoulson> i guess the only issue with it is, when we eventually roll out thunderbird 3.3, users on older releases will get updated to 3.3 if they are using the daily builds
[16:50] <chrisccoulson> whereas, that isn't happening for firefox because we still have the daily builds coming off lp:firefox-3.6.head, and natty is using lp:firefox-4.0.head
[16:50] <micahg> well, that's what happened with firefox I think, when 3.6 was stable
[16:51] <micahg> ah, hmm, I see your point
[16:51] <chrisccoulson> i'm not sure how to handle that
[16:51] <chrisccoulson> but, on the flip-side - when firefox 4 is released, we are going to lose 4.0 daily builds
[16:52] <chrisccoulson> hmmmm L/
[16:52] <chrisccoulson> :/ even
[16:52] <micahg> chrisccoulson: I think we should make the "firefox" dailies come off firefox-4.0 then
[16:52] <chrisccoulson> even for maverick and lucid users?
[16:52] <chrisccoulson> it almost seems like we need more than 1 PPA ;)
[16:52] <chrisccoulson> fta - how does this work for chromium? :)
[16:53] <micahg> chrisccoulson: yeah, that's what we did with 3.6
[16:53] <chrisccoulson> ah, ok
[16:53] <chrisccoulson> if we've done that in the past, then i don't mind doing it again
[16:53] <micahg> chrisccoulson: we can make firefox-3.6.head push a source firefox-3.6 package if we need the dailies still
[16:54] <micahg> chrisccoulson: chromium has channels the users subscribe to, daily, dev, beta, stable
[16:58] <chrisccoulson> ok, i'm happy with keeping lp:thunderbird.head for the current stable (rather than using lp:thunderbird-3.1.head)
[16:59] <chrisccoulson> we should probably discuss workflow at UDS though, we have a lot of branches now and i guess this is going to get more difficult in the future ;)
[16:59] <chrisccoulson> ^^^fta - will you be coming to UDS?
[17:28] <magcius> where is the chromium daily ppa?
[17:29] <micahg> magcius: I think it's ppa:chromium-daily/ppa
[17:31] <magcius> ok.
[17:31] <fta> chrisccoulson, nope.
[17:33] <fta> chrisccoulson, micahg: grr, i already renamed everyting
[17:33] <chrisccoulson> fta - that's ok, don't worry about it ;)
[17:33] <micahg> yeah, it's fine
[17:34] <chrisccoulson> wth is eToken?
[17:35] <chrisccoulson> these issues keep cropping up: http://launchpadlibrarian.net/65515213/DpkgTerminalLog.txt
[17:35] <chrisccoulson> applications should not be adding private locations to the ld search path!
[17:35] <chrisccoulson> grrrrrrrrrrrrr
[17:35] <chrisccoulson> is this going to be another ubuntuzilla? ;)
[17:35] <micahg> chrisccoulson: I don't think that's us
[17:36] <chrisccoulson> no, it's not us. i'm just wondering what it is though
[17:40] <chrisccoulson> it's especially bad adding themselves to the ld search path when they ship such antiquated versions of nss
[17:40]  * chrisccoulson is going to have to get the whip out
[17:40] <micahg> well, installing stuff in /usr/lib is generally frowned upon anyways
[17:40] <chrisccoulson> yeah, they aren't doing that. they're installing nss in to a private location in /opt and then presumably dropping a file in /etc/ld.so.conf.d
[17:40] <micahg> chrisccoulson: I was referring to the eToken stuff :)
[17:41] <chrisccoulson> it's a good job that firefox isn't using the system nss
[17:41] <chrisccoulson> i wonder if it's this? http://www3.safenet-inc.com/support/etoken.aspx
[17:41] <chrisccoulson> i might send them an e-mail
[18:07] <micahg> did you see the news about js185?
[18:08] <chrisccoulson> micahg - not yet, are they doing a tarball release though? i've been pinging them in #jsapi about that ;)
[18:08] <micahg> chrisccoulson: yes, sounds like it's planned
[18:08] <micahg> which means /usr/lib/mozjs185.0.0 hopefully
[18:09] <chrisccoulson> https://bugzilla.mozilla.org/show_bug.cgi?id=628723
[18:09] <ubot2> Mozilla bug 628723 in JavaScript Engine "Create JS 1.8.5 source release" [Normal,New]
[19:39] <micahg> jdstrand: what do you think about bug 728621
[19:39] <ubot2> Launchpad bug 728621 in firefox "Apparmor profile works around a fixed security bug in sun-java6" [Undecided,New] https://launchpad.net/bugs/728621
[19:41] <jdstrand> micahg: seems fine to revert so long as it is tested
[19:41] <micahg> jdstrand: is running through the java test suite on the build sufficient?
[19:41] <jdstrand> micahg: should be. probably something for natty only
[19:43] <micahg> jdstrand: revert only in natty or test only in natty?
[19:44] <jdstrand> micahg: both
[19:45] <micahg> jdstrand: so leave the stable releases alone WRT this
[19:45] <jdstrand> yes
[19:45] <micahg> jdstrand: k, it's in the apparmor abstraction now, so should I prepare a merge request for apparmor?
[19:46] <jdstrand> sure, or a debdiff
[20:15] <fta> jdstrand, micahg: do you want the arm ftbfs fix for this ch release or is it fine to wait for the next one?
[20:15]  * micahg defers to jdstrand on this
[20:16] <fta> btw, the next beta is very active, i won't be surprised to see it become stable very soon
[20:16] <fta> linux/beta (10.0.648.126 -> 10.0.648.127)
[20:16] <micahg> they've also just about reached they're 6 week release deadline
[20:17] <jdstrand> fta: which fix is this, dropping the arch or actually getting armel builds?
[20:18] <jdstrand> s/builds/working builds/
[20:19] <fta> jdstrand, i can get it to build "theoretically", it was my fault, a flag dropped by mistake.
[20:20] <jdstrand> fta: yes, please let's get armel building again with the next upload (but not a special 9.0.597.107~r75357-0ubuntu<IP_ADDRESS> upload)
[20:21] <fta> ok
[20:21] <jdstrand> fta: so whenever google has a new security update for us, we'll get the path then
[20:21] <jdstrand> fta: thanks for finding the fix, even if it is just theoretical :)
[20:28] <fta> ok, fix committed, so i won't forget it
[22:55] <BUGabundo> evening
[22:58] <fta> jdstrand, are the QRT:scripts fully automatic? i mean, would it be possible to run them without a display?
[22:58] <jdstrand> fta: no, they are not automatic in any way. they are interactive
[22:59] <jdstrand> fta: well, test-browser.py. most of QRT:scripts can be run without a display
[23:02] <fta> i guess i should test those one day
[23:03] <fta> chrisccoulson, you didn't change the tb 3.3 src package name yet?
[23:03] <chrisccoulson> fta - i thought i pushed my changes already?
[23:03] <chrisccoulson> 1 sec
[23:06] <chrisccoulson> fta - yeah, it's pushed already
[23:07] <fta> hm
[23:07] <fta> why is my bot pulling the same sources over and over again then?..
[23:08] <fta> oh, no cache
[23:08] <fta> could you please add one?
[23:09] <fta> ff and xul have one already


[18:46] <bluewireslight> hi
[18:46] <bluewireslight> jose how are you
[18:57] <bluewireslight> how is everybody


[00:15] <infinity> ogra-cb_: http://paste.ubuntu.com/1380830/
[00:15] <infinity> ogra-cb_: Not sure that'll be acceptable.
[04:30] <ScottK> infinity: 17 chrootwaits (at least) on heka, so I put it on manual.
[10:51] <ogra_> infinity, i think for 170M i can live with 24min added to the build, lets do it (and probably get a second builder for the flavours), its still way below the timing of a  build on teh babbage board, so we had worse
[11:30] <infinity> ogra_: And by 24m, you mean 40m?
[11:30] <infinity> ogra_: At least, 48-8 is 40 in my world.
[11:32] <infinity> ogra_: And probably longer on production hardware, I was testing on a PandaES, not a Panda.
[11:32] <infinity> ogra_: So, it'll likely add at least an hour to the build.
[11:44] <ogra-cb_> bah, i kooked at -9 --rsyncable
[11:44] <ogra-cb_> *looked
[11:51] <ogra-cb_> bah plymouth 0.8.8 gets the nexus back into constant reboot loops :(
[11:52] <ogra-cb_> damned
[11:52] <infinity> Is that the "trying to attach to a device called 'none'" bug, or something new?
[11:53] <ogra-cb_> not sure yet, i know in 0.8.5 were some fixes for serial console handling, not sure they fixed empty/bogus console= args as well
[11:53] <infinity> (I'm not even sure why that was a bug... How hard is it to state the device node before trying to open it?)
[11:53] <infinity> s/state/stat/
[11:53] <ogra-cb_> yeah
[11:54] <infinity> Or do something sane when open() returns ENOENT, whatever.
[11:55] <ogra-cb_> well, i havent looked at the 0.8.8 soource yet, the 0.8.4 one was horrid though
[12:06]  * ogra-cb_ puts the plymouth override files back in
[12:07] <ogra-cb_> *sniff*
[12:07] <ogra-cb_> infinity, what about lzma btw ? any chance that runs faster ?
[12:08] <infinity> ogra-cb_: Probably slower, but I'll test for fun.
[12:09] <infinity> ogra-cb_: Lower xz opt levels may be more acceptable too.
[12:10]  * infinity tries xz -4 for kicks.
[12:10] <ogra-cb_> well, gaining 100M would eb good
[12:10] <ogra-cb_> i mean i have to split the desktop seed anyway into a core part and applications ... there was some WI somewhere
[12:20]  * infinity finds --memlimit-compress=limit in the xz manpage, and decides to test that next.
[12:21] <infinity> Although, this doesn't seem to be swapping right now.  Just chewing CPU.
[12:21] <infinity> So maybe memlimit won't help.
[12:22] <infinity> ogra-cb_: I'm going to nap.  I'll throw some more random results at you later, and we'll see if something looks like a reasonable size/speed tradeoff.
[12:22] <infinity> ogra-cb_: Or, we can re-examine the "build the image on nusakan" idea. :/
[12:23] <infinity> ogra-cb_: Unless make_ext4fs is under pretty seriously heavy development, a single backport for cdimage would probably do us fine, right?
[12:23] <ogra-cb_> yeah
[12:24] <infinity> ogra-cb_: (Or, we could just be naughty and keep a privately-built copy in ~cdimage/bin)
[12:24] <ogra-cb_> hehe
[12:24] <ogra-cb_> i bet you could just cp the existing quantal binary in place
[12:25] <infinity> Would speed up ac100, nexus7, and core to do the post-tarball zipping and mangling on nusakan.
[12:25] <ogra-cb_> indeed
[12:25] <infinity> The Q binary depends on some glibc 2.14 symbols, apparently.
[12:25] <ogra-cb_> but it does involve IS in the end if you want to do it properly at some point
[12:25] <ogra-cb_> ah, crap
[12:26] <ogra-cb_> and nusakan is even lucid i think
[12:26] <infinity> Well, some binary in the package does, I didn't look at make_ext4fs itself, just the dpkg deps.
[12:26] <ogra-cb_> iirc xnox did a precise backport too
[12:26] <infinity> Well, the precise package would have the same issue. :P
[12:26] <infinity> Since precise is 2.15
[12:26] <ogra-cb_> right
[12:27] <ogra-cb_> just meaning nothing goes back far enough for lucid
[12:28] <infinity> (base)adconrad@cthulhu:~$ readelf -a /usr/bin/make_ext4fs | grep 'Name: GLIBC'
[12:28] <infinity>   0x0030:   Name: GLIBC_2.11  Flags: none  Version: 8
[12:28] <infinity>   0x0040:   Name: GLIBC_2.14  Flags: none  Version: 7
[12:28] <infinity>   0x0050:   Name: GLIBC_2.8  Flags: none  Version: 6
[12:28] <infinity> Yeah, we'd need to build it for lucid to avoid that.
[12:28] <infinity>   0x0060:   Name: GLIBC_2.4  Flags: none  Version: 5
[12:28] <infinity>   0x0070:   Name: GLIBC_2.3.4  Flags: none  Version: 3
[12:28] <infinity>   0x0080:   Name: GLIBC_2.2.5  Flags: none  Version: 2
[12:29] <infinity> Oh, right, shiny new memcpy in 2.14 is versioned.
[12:32] <infinity> Anyhow.  Nap time.  More pondering tomorrow.
[12:32] <infinity> Or, more accurately, later today.
[12:32] <ogra-cb_> yeah, sleep well
[12:44] <infinity> Oh, that test just finished (-4)
[12:44] <infinity> adconrad@shiva:/srv/test$ time xz -4 -c rootfs.tar > rootfs.tar.xz.4
[12:44] <infinity> real	33m23.931s
[12:44] <infinity> user	32m58.602s
[12:44] <infinity> sys	0m12.578s
[12:44] <infinity> -rw-rw-r-- 1 adconrad adconrad  595792596 Nov 23 15:08 rootfs.tar.gz.9.rsync
[12:44] <infinity> -rw-rw-r-- 1 adconrad adconrad  424087940 Nov 23 15:57 rootfs.tar.xz
[12:44] <infinity> -rw-rw-r-- 1 adconrad adconrad  444655528 Nov 24 05:43 rootfs.tar.xz.4
[12:44] <infinity> That's starting to maybe approach acceptable.  Maybe.  I dunno.
[12:45] <infinity> Doing it on cdimage is likely saner.  We'll talk later.
[15:46] <cjwatson> stgraber: I missed a debian-cd patch, which probably accounts for your problems.  Applied now, so the next daily build should be happier.
[21:20] <xnox> ogra ogra_ ogra-cb_  : ppa:ubuntu-nexus7/ubuntu-nexus7-installer now has android-tools for lucid, precise and quantal.
[23:35]  * cjwatson fixes the bogus overrides that resulted in ubuntu-zh_CN/raring/{amd64,i386} image build failures


[14:19]  * oskarw slaps oskarw around a bit with a large trout
[14:37] <rick_h_> hello party people
[14:51]  * hatch waves
[14:51] <rick_h_> wave
[14:55] <marcoceppi> o/
[15:04] <jcastro> if anyone has any questions please ask them here
[15:06] <hatch> jorges window is still small
[15:06] <hatch> rick is the primary
[15:07] <hatch> now it's a browser
[15:09] <hatch> QUESTION: Does the Juju GUI support local charms yet?
[15:10] <bac> Note that creating your environment in the Juju GUI and exporting it is a quick way to create a new bundle.
[15:14] <hatch> can you zoom in?
[15:14] <hatch> the font is really small
[15:20] <Makyo> Here is a video of quickstart for perusal after the event, as well: http://www.youtube.com/watch?v=LVknLr1spPo
[17:58]  * nwl waves
[17:59] <nwl> jamespage-uds: hangout URL?
[18:04] <gaughen> https://plus.google.com/hangouts/_/hoaevent/AP36tYext7IdEhmvRlOZ0v1zU9WAkQF4w8_FJ9jjqY43dcsYqii8RQ?authuser=0&hl=en
[18:04] <gaughen> that's the hangout
[18:04] <nwl> gaughen: "You're not allowed to join this video call."
[18:05] <gaughen> hrmmm
[18:05] <jamespage> nwl, bah
[18:06] <smoser> o/
[18:06] <jarrod> whirreddd
[18:08] <jarrod> guess we werent invited
[18:08] <smoser> jamespage, we're having technical difficulties ?
[18:08] <jamespage> smoser, yes - should start shortly
[18:09] <jamespage> http://pad.ubuntu.com/uds-1403-ceph
[18:09] <jamespage> OK - lets get going
[18:09] <rbasak> No stream yet.
[18:10] <jamespage> starting now
[18:10] <jarrod> i see pat
[18:10] <rbasak> A refresh fixed it
[18:10] <jarrod> and james
[18:10] <rbasak> I see you now.
[18:33] <jrwren> anecdote: we hit walls with swift. I wish we had used ceph instead.
[18:33] <jarrod> looks like vmware vsan is trying to knock this off
[18:34] <jrwren> use case: millions of objects per single container. swift use of rsyncing sqlite database files does not scale into the millions of objects in a single container.
[18:34] <jarrod> swift doesnt have distributed meta data either
[18:37] <jamespage> thanks folks!
[18:37] <nwl> np
[18:37] <jrwren> ty
[18:38] <beisner> thank you!
[18:55] <gaughen> https://plus.google.com/hangouts/_/hoaevent/AP36tYddHjLdi6z_DFw5pGlEL5PDPvWqACmZbBHURyhP0oI0Y6R4tw?authuser=0&hl=en
[18:57] <beisner> hangout link tested ok
[18:58] <rharper> https://plus.google.com/hangouts/_/hoaevent/AP36tYddHjLdi6z_DFw5pGlEL5PDPvWqACmZbBHURyhP0oI0Y6R4tw?authuser=1&hl=en  <--- I had to change to authuser=1
[18:58] <smoser> http://search.dilbert.com/comic/Random%20Number%20Generator
[19:00] <smoser> http://xkcd.com/221/
[19:15] <smoser> http://pad.ubuntu.com/uds-1403-entropy
[19:16] <smoser> the cloud-init config is TBD from kirkland


[01:06] <Moss23> hi guys, I'm going to install SDK binary, but I have allready installed JRE and maybe JDK through eclipse some time ago, do you think that the installer take care of this ?
[14:56] <persia> Team meeting in 5 minutes in #ubuntu-meeting