[07:03] <dholbach> good morning
[07:03] <fgimenez> good morning
[07:04] <dholbach> hi fgimenez
[08:59] <JamesTait> Good morning all; happy Hug Your Cat Day! 😃
[11:25] <elopio> good morning.
[11:26] <elopio> hey fgimenez: what do you think about the latest version, ready to promote to stable?
[11:27] <fgimenez> elopio, hi, yes, seems good so far
[11:28] <fgimenez> elopio, i'm finishing the script for the complete upgrade path proposed by rsalveti, that will give us more confidence
[11:28] <elopio> fgimenez: nice, thank you.
[12:00] <sergiusens> rsalveti: mind doing a no change rebuild upload of the archive version of 'ubuntu-snappy' to get the powerpc binaries built? It seems we never built them
[12:13] <Chipaca> rsalveti: where was the 15.04.x blueprint?
[12:13] <sergiusens> Chipaca: https://trello.com/c/wxQzJ9uT/18-create-15-04-1-stable-image
[12:13] <rsalveti> sergiusens: wonder if we would need a no change upload
[12:13] <rsalveti> yeah, that's the one
[12:13] <sergiusens> Chipaca: and the bug task i there
[12:13] <rsalveti> sergiusens: since it was copied from vivid
[12:14] <Chipaca> k
[12:14] <rsalveti> https://launchpad.net/snappy/+milestone/15.04.1
[12:14] <rsalveti> as well
[12:14] <sergiusens> rsalveti: yeah, it was copied from a ppa that probably didn't build for powerpc
[12:14] <sergiusens> rsalveti: yeah, I just gave him the parent link ;-)
[12:14] <sergiusens> Chipaca: from the work items, do you know of anything that can be crossed out?
[12:16] <Chipaca> sergiusens: some of them should be landing about now
[12:17] <sergiusens> Chipaca: do you know anything about the backporting ones?
[12:18] <Chipaca> sergiusens: i've jused approved several backporting MPs
[12:18] <Chipaca> s/jused/just/, and by just i mean an hour or so ago
[12:18] <Chipaca> before lunch
[12:18] <sergiusens> Chipaca: these specifically Backport lp:~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/add-sync-calls
[12:18] <sergiusens> Chipaca: and yeah, I saw :-)
[12:18] <Chipaca> and mvo's 15.04 moar-errors one could land if he's not going to be around
[12:23] <rsalveti> sergiusens: want to do another release and I can sponsor your upload?
[12:23] <rsalveti> sergiusens: or just a rebuild is fine?
[12:24] <sergiusens> rsalveti: just a rebuild, a release forces a lot of catching up on u-d-f
[12:24] <rsalveti> sergiusens: right, sure
[12:24] <sergiusens> rsalveti: I can confirm in a bit though
[12:25] <sergiusens> to triple check why powerpc isn't there
[12:25] <rsalveti> sure, will wait then
[12:26] <Chipaca> do we need to do anything with bug #1449625 for it to be SRUable?
[12:26] <nothal> Bug #1449625: systemd and bin-path exported variables are not in sync <Snappy:Fix Committed> <Snappy 15.04:Fix Committed> <http://launchpad.net/bugs/1449625>
[12:27] <Chipaca> marked it "done" in the trello, but then thought to ask, because it explicitly says SRU there :)
[12:28] <sergiusens> Chipaca: we should probably SRU everything that's making it into lp:snappy/15.04
[12:28]  * Chipaca marks it "done"
[12:30] <Chipaca> do we really support "upgrading to edge"?
[12:30] <Chipaca> i thought that was a corner case brought about by fiddling with files
[12:30] <rsalveti> edge 15.04 or rolling?
[12:41] <sergiusens> Chipaca: we want to support upgrading to edge when we have proper channels and os/kernel snaps
[12:45] <mterry> sergiusens, you mentioned being able to set up tarmac for ubuntu-core-launcher?  Can you also do it for snapcraft?
[12:47] <sergiusens> mterry: yeah, I saw tedg's request :-)
[12:47] <sergiusens> will do it in a bit
[12:47] <mterry> sergiusens, oh didn't know he asked too  :)
[12:58] <sergiusens> Chipaca: nagging welcome ;-) https://code.launchpad.net/~sergiusens/snappy/YouShallNotPass/+merge/261079
[12:58]  * Chipaca prepares the nag
[13:02] <Chipaca> sergiusens: +1'ed with a nit
[13:04] <sergiusens> Chipaca: nice catch ;-)
[13:04] <Chipaca> sergiusens: which makes me realise
[13:04] <sergiusens> Chipaca: pushed
[13:04] <Chipaca> sergiusens: you're not testing the use of it
[13:05] <sergiusens> uh oh :-P
[13:05] <sergiusens> Chipaca: right! Not the error, which I guess I'll do now
[13:05] <Chipaca> :)
[13:08] <sergiusens> Chipaca: o, now I need interpackage architecture stubbing, yay
[13:08] <Chipaca> ...
[13:09] <Chipaca> no, no you don't
[13:09] <Chipaca> just test with "xyzzy" architecture
[13:09] <Chipaca> that is, in the package, put architectures: foo, bar, baz
[13:09] <Chipaca> but properly ;)
[13:10] <sergiusens> Chipaca: oh, I was going to build a test snap, not test the error only ;-)
[13:10] <Chipaca> sergiusens: you're already testing that you detect the "right" arch in the unit test
[13:10] <Chipaca> sergiusens: you just need to test that you report the error in the integration test
[13:11] <Chipaca> sergiusens: yes, i meant in the package.yaml
[13:11] <sergiusens> Chipaca: right, but I rely on UbuntuArchitecture() which depends on the system where you run the test ;-) That's why I said interpackage :-)
[13:11] <sergiusens> so I'll do what I was going to do ;-)
[13:12] <Chipaca> sergiusens: not sure i follow
[13:13] <sergiusens> helpers.UbuntuArchitecture() uses the systems arch, it's all fine if we all run on amd64 but this will all fail when using a different system
[13:13] <sergiusens> meh, I understand myself ;-)
[13:13] <sergiusens> I just need to mock UbuntuArchitecture
[13:13] <Chipaca> sergiusens: um
[13:13] <Chipaca> sergiusens: i don't see that need
[13:13] <Chipaca> hence my questioning it
[13:14] <sergiusens> Chipaca: I'm a lazy typer today https://plus.google.com/hangouts/_/canonical.com/seetheneed
[13:35] <sergiusens> Chipaca: see if you like it now
[13:37] <Chipaca> sergiusens: top-approved
[13:37] <Chipaca> purrfect :)
[13:38] <sergiusens> Chipaca: thanks
[13:38] <sergiusens> Chipaca: I always spend some time figuring out which "test helper" we want :-P not sure if the same happens to you
[13:46] <Chipaca> sergiusens: "write a new one every time" is probably a suboptimal strategy
[15:01] <sergiusens> Chipaca: https://code.launchpad.net/~sergiusens/snappy/YouShallNotPassBeforeEither/+merge/261097
[15:25] <elopio> rsalveti: do you think we will need to test something on the phones in the next months?
[15:25] <elopio> I'm wondering if I can leave them here so somebody else gets them.
[15:25] <rsalveti> elopio: you never know
[15:25] <rsalveti> elopio: I'd suggest you to keep them with you
[15:25] <rsalveti> unless requested by someone else
[15:28] <sergiusens> rsalveti: elopio you only really need one; I guess we will mostly be doing the core work (os and kernel snap)
[15:28] <sergiusens> but would leave ui work to others
[15:29] <rsalveti> right
[15:30] <elopio> yes. That's what I was thinking. I need a phone to call my mother too :)
[15:30] <elopio> I'll ask how hard would it be to get the others back if we happen to need them later.
[15:55] <kyrofa> Chipaca, ping
[15:59] <rickspencer3> jdstrand, so it is it totally legit for me to let to snaps to talk to each other over localhost:whateverports?
[15:59] <sergiusens> rsalveti: how was https://bugs.launchpad.net/snappy/+bug/1424586 Fix Released? Asking in the sense of backporting ;-)
[16:00] <sergiusens> or is that what fgimenez is working on?
[16:00] <sergiusens> if that's the case, mterry just took over the last bug in that list that is !apparmor
[16:01] <sergiusens> rickspencer3: there is language to prevent that in package.yaml but it is not enforced yet (internal vs external)
[16:02] <fgimenez> sergiusens, i'm using the upgrade script just for testing one of the upgrade paths, anyway seems to be a different approach from that bug
[16:03] <jdstrand> rickspencer3: yes, for external ports (see https://developer.ubuntu.com/en/snappy/guides/package-metadata/). for internal ports there are ideas in the vision doc to create firewall rules that could interfere
[16:04] <fgimenez> sergiusens, the bug fix implements what we were talking about in yesterday's standup, modifying channel.ini to allow an update from the current version
[16:04] <jdstrand> rickspencer3: so internal today would work too. also note, ports is in meta.md but we don't do anything with it yet afaik
[16:05] <sergiusens> fgimenez: yeah, that's in selftests iirc
[16:05] <jdstrand> rsalveti: btw, is there a card for that ^. it seems like we should at least have ingress filtering for anything in 'ports/internal'
[16:05] <jdstrand> actually, that gives me a thought
[16:05] <fgimenez> sergiusens, yep, it's one of them
[16:06] <jdstrand> I thinks ports is not implemented in part because we wanted a ports service to say whether or not something was assigned
[16:07] <jdstrand> what if we used netfilter as the database? ie, if you specify 'ports/external' then you get an ACCEPT rule with an id/comment as the PKGNAME_APPNAME and an DROP rule for external interfaces for ports/internal with an id/comment
[16:08] <jdstrand> sergiusens, rsalveti: ^ idea for whoever implements something more with 'ports'
[16:08] <Chipaca> kyrofa: pong
[16:09] <jdstrand> sergiusens, rsalveti: in this manner, snappy can parse iptables output and determine if something on the system is assigned a port
[16:09] <kyrofa> Chipaca, I'm just getting started on a dbus daemon in golang, and I see you've contributed to go-dbus. Do you recommend that lib?
[16:10] <Chipaca> kyrofa: last time i checked, it was the better of the go dbus wrappers
[16:10] <Chipaca> kyrofa: what's your daemon interfacing with?
[16:10] <kyrofa> Chipaca, the Unity8 QML progress widget
[16:12] <Chipaca> kyrofa: so you're binding qt/qml?
[16:14] <jdstrand> rickspencer3: in case it isn't obvious, if you open a port, anyone can connect to it, so things would have to be designed with that in mind
[16:14] <kyrofa> Chipaca, no, I mean that's what it's communicating with via dbus. Perhaps I misunderstood the question?
[16:14] <Chipaca> kyrofa: ah, ok :)
[16:14] <sergiusens> jdstrand: so DENY by default and if declared as an external port we add an ACCEPT and if negotiable we find a free slot and assign it there and somehow send that back to the package
[16:14] <Chipaca> kyrofa: i was just asking because if you were binding qt or glib anyway, it might make more sense to use their dbus implementation
[16:14] <jdstrand> future internal ports intend to help-- you declare an internal port and what apps can connect to it
[16:15] <sergiusens> jdstrand: but iptables doesn't solve the app1 <-> app2 problem though
[16:15] <jdstrand> sergiusens: yes, essentially
[16:15] <kyrofa> Chipaca, ahh, gotcha :)
[16:15] <Chipaca> sergiusens: how "stable" are data dirs? can i tell a guy to ship a symlink to their data dir in their app?
[16:15] <kyrofa> Chipaca, alright, I appreciate your help! I'll dive into using go-dbus :)
[16:15] <jdstrand> sergiusens: no it doesn't yet-- that would come later
[16:15] <sergiusens> jdstrand: we should probably add this to the backlog
[16:15] <jdstrand> sergiusens: that is in the vision doc
[16:15] <Chipaca> kyrofa: enjoy! holler when it breaks :)
[16:16] <kyrofa> Chipaca, ha! Will do ;)
[16:16] <jdstrand> sergiusens: it would probably make sense to look at ufw's default setup, how it sets up chains, etc for inspiration
[16:17] <jdstrand> if you want, I can help with the design
[16:17] <jdstrand> or at least review/comment on it
[16:18] <jdstrand> sergiusens: alternatively to default DROP, you setup only the rules that are specific to what is declared in ports
[16:18] <jdstrand> that might be a safer first step until we understand frameworks better
[16:19] <jdstrand> but we can talk about it
[16:19] <sergiusens> jdstrand: tracked now https://trello.com/c/p8g9U2cV/80-internal-and-external-port-acl
[16:21] <jdstrand> sergiusens: awesome (commented)
[16:22] <jdstrand> sergiusens: it probably will make sense to discuss with th architects team since there will be interactions between snaps and frameworks
[16:22] <jdstrand> sergiusens: eg, a router framework and an unrelated snap. I'd like to be invited to that call with the architects
[16:26] <jdstrand> sergiusens: so, for the vision work (additional filtering of internal ports for app to app filtering), the basic idea is create a net cgroup that tags the network traffic, and then you have rules that reference the tag
[16:27] <jdstrand> sergiusens: I think that should be done as a second step
[16:38] <jdstrand> sergiusens: ok, I'll stop talking here-- I added my thoughts to the card
[16:38] <jdstrand> since it is clear that is what you want ;P
[16:43] <sergiusens> jdstrand: oh, sorry, I'm preparing lunch ;-)
[16:44] <sergiusens> jdstrand: we can discuss here in a bit and then I'll summarize neatly in the card
[16:44] <sergiusens> but food first since it's almost 2pm and I need to eat ;-)
[16:45] <jdstrand> sergiusens: I was just teasing. Everything I have time to discuss today is in the card so I think we are good for nowe
[16:45] <jdstrand> now*
[16:46] <mterry> sergiusens, added a .tarmac.sh to lp:snapcraft
[16:46] <mterry> Missed that in lp:snappy
[17:11] <rsalveti> sergiusens: for bug 1424586, only trunk is fix released
[17:11] <rsalveti> the 15.04 task is still opened
[17:21] <rsalveti> sergiusens: can you check if we can backport the selftests as well?
[17:21] <rsalveti> then we drop the older separated branch completely
[17:22] <rsalveti> and I believe the current self tests are compatible with both 15.04 and rolling
[17:23] <rsalveti> jdstrand: sergiusens: thanks for creating the card
[17:23] <rsalveti> I think ricmm will own that from the arch side of things
[17:23] <rsalveti> ricmm: https://trello.com/c/p8g9U2cV/80-internal-and-external-port-acl
[17:23] <rsalveti> he's our network architect :-)
[17:24] <rsalveti> let me add this as a topic for the archs call to make sure we don't forget
[17:51] <ricmm> rsalveti: yea please add that to go over it tomorrow
[17:52] <rsalveti> already did
[17:52] <ricmm> thx
[18:08] <sergiusens> rsalveti: right, but there is no link to any code so I have no idea what work was done for that
[18:08] <sergiusens> wrt to the bug
[18:08] <rsalveti> right, mvo just added a comment pointing out the branch
[18:08] <rsalveti> but didn't link to the bug
[18:08] <sergiusens> ricmm: rsalveti I also need an 'am I online API' where online can be, lan, wan, internet
[18:08] <rsalveti> https://bugs.launchpad.net/snappy/+bug/1424586/comments/6
[18:08] <sergiusens> rsalveti: ok
[18:09] <rsalveti> sergiusens: hm, right
[18:09] <sergiusens> rsalveti: there, I linked to the bug
[18:09] <rsalveti> thanks
[18:10] <rsalveti> for 15.04 we hopefully can just backport the selftests merge
[18:10] <sergiusens> rsalveti: selftests though, those are cross release still, so there shouldn't be any backport work
[18:10] <sergiusens> rsalveti: since this landed in the selftest series and not in trunk
[18:10] <rsalveti> sergiusens: right, but we still need to merge under the 15.04 branch, right?
[18:10] <rsalveti> sergiusens: but thought selftests were later merged
[18:10] <sergiusens> rsalveti: I don't think selftests are in trunk yet
[18:11] <rsalveti> man, I hate this code browse interface for bzr
[18:12] <rsalveti> yeah, thought mvo had merged that
[18:13] <sergiusens> rsalveti: nope, and I don't see an MP anymore
[18:13] <rsalveti> so all good then
[18:13] <rsalveti> we'll merge for 15.04.2 I guess
[18:13] <sergiusens> rsalveti: I know there were commens from elopio in an original let's "merge it" MP
[18:13] <rsalveti> right
[18:13] <sergiusens> I guess this may have died in relation to his work into converting to go
[18:13] <rsalveti> could be
[18:14] <rsalveti> sergiusens: https://code.launchpad.net/~mvo/snappy/snappy-merge-integration-tests/+merge/259592
[18:14] <rsalveti> yeah, still wip
[18:15] <rsalveti> @reviewlist
[18:15] <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir-15.04/+merge/261104 | No reviews (less than a day old)
[18:15] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-list-row/+merge/260837 | No reviews (1 day old)
[18:15] <nothal> https://code.launchpad.net/~mterry/snappy/rollback-reboot/+merge/261114 | Needs Information: 1 (less than a day old)
[18:15] <nothal> https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934 | No reviews (less than a day old)
[18:15] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1449032-poor-mans-rsync/+merge/260931 | Approve: 1 (less than a day old)
[18:16] <rsalveti> why is it not there?
[18:25] <sergiusens> rsalveti: the webui isn't showing it either (which is why I thought it was destroyed)
[18:25] <rsalveti> weeeeeird
[18:26] <rsalveti> hm, showing fine here
[18:26] <rsalveti> https://code.launchpad.net/~snappy-dev/snappy/snappy/+activereviews
[18:26] <rsalveti> lp:~mvo/snappy/snappy-merge-integration-tests ⇒ lp:snappy
[18:26] <sergiusens> rsalveti: oh, right, I'm looking at lp:snappy/+activereviews
[18:26] <sergiusens> rsalveti: you don't see it in the reviewlist because it's WiP
[18:27] <sergiusens> that should be @worklist ;)
[18:28] <rsalveti> oh, got it
[18:28] <rsalveti> makes sense
[18:28] <rsalveti> it's just that it's really uncommon for people to let the status as wip
[18:37] <mterry> I'm getting "operation not supported" and a failure to install hello-world on latest rolling image
[18:38] <mterry> Anyone else seeing that or is my image just borked?
[18:41] <rsalveti> iirc latest rolling is still not properly in shape
[18:41] <rsalveti> so might just be a valid bug
[18:44] <sergiusens> mterry: rsalveti that's a go 1.4 bug (from Chipaca's findings)
[18:45] <sergiusens> rsalveti: nah, this team does the right thing ;-) If it's not ready for review WiP is the right status :-)
[18:48] <sergiusens> @reviewlist
[18:48] <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir-15.04/+merge/261104 | No reviews (less than a day old)
[18:48] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-list-row/+merge/260837 | No reviews (1 day old)
[18:48] <nothal> https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934 | No reviews (less than a day old)
[18:48] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1449032-poor-mans-rsync/+merge/260931 | Approve: 1 (less than a day old)
[18:48] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-oauth-quoting/+merge/260909 | Needs Fixing: 1 (less than a day old)
[18:51] <mterry> sergiusens, I'm looking at this rollback code
[18:51] <mterry> sergiusens, and actually, we output "Setting %s to version %s" AFTER we rollback
[18:51] <mterry> sergiusens, so there's no feedback for a bit
[18:51] <mterry> sergiusens, I'm going to modify my branch to move that up
[18:52] <sergiusens> mterry: meh
[18:52] <sergiusens> mterry: I think it's too late :-/
[18:53] <mterry> sergiusens, I caught it  :)
[18:53] <mterry> sergiusens, no i didn't
[18:53] <mterry> sergiusens, sight
[18:53] <mterry> oh well
[18:53] <sergiusens> mterry: just leave it, we should have a proper spinner in place
[18:53] <mterry> sergiusens, fair enough
[18:54] <sergiusens> mterry: we can reset trunk if you want ;-)
[18:55] <mterry> yes pls
[18:55] <sergiusens> mterry: ok, one sec
[18:55] <mterry> :)
[18:56] <sergiusens> mterry: done
[18:57] <mterry> sergiusens, wait what?  That is a thing we do?
[18:57] <mterry> sergiusens, I thought you were joking
[18:57] <sergiusens> mterry: sometimes, yes
[18:57] <sergiusens> mterry: we once had someone (not naming names) do something bad with trunk
[18:57] <mterry> sergiusens, you crazy.  OK, let me set branch status
[18:57] <sergiusens> mterry: anyways, no smilies or anything and I take you seriously ;-)
[18:58] <sergiusens> sorry
[18:58] <mterry> sergiusens, that's fair.  I just didn't think it was a real thing, so I didn't take you seriously  :)
[18:58] <mterry> I mean
[18:58] <mterry> I know you can always push --overwrite
[18:58] <mterry> But I thought we had protections against that
[18:59] <sergiusens> mterry: oh, yeah, I know what you mean; but yeah, it's doable and very easy to make a mistake
[19:00] <sergiusens> a common mistake, bzr branch <code>; cd <code>; bzr merge <branch>; bzr push <code>; sleep (a lot); write_core; bzr commit; bzr push (oops)
[19:02] <sergiusens> mterry: it's solvable by putting trunk under a different team and only having the merge bot there
[19:03] <rickspencer3> sergiusens, not sure if you are still here, but are you saying that if I try to send data over localhost:n ... that it will stop working when the security policy is fully implemented?
[19:03] <mterry> sergiusens, yeah I try to never reuse branch directories for that reason
[19:04] <sergiusens> mterry: I can't wait for our git migration ;-)
[19:04] <sergiusens> rickspencer3: I am
[19:04] <sergiusens> rickspencer3: and yes, it would stop if you declare your port as internal (I don't recall the spec completely from the top of my head right now)
[19:08] <rickspencer3> sergiusens, ok, I'll wait until the proper implementation for socket communication
[19:09] <rickspencer3> is there a standard way that folks are parsing yaml in Go?
[19:10] <sergiusens> rickspencer3: we use gopkg.in/yaml.v2
[19:10] <sergiusens> rickspencer3: http://godoc.org/gopkg.in/yaml.v2
[19:22] <mterry> rsalveti, I think we may want bug 1457183 in 15.04.1 too
[19:23] <rsalveti> mterry: yeah, makes sense, thanks
[19:35] <mterry> When is lp:snappy/selftest run?
[20:05] <rsalveti> sergiusens should know if enabled as part of the merging process
[20:05] <rsalveti> but generally we want to run it as part of proposed-migration and after the image gets published
[20:05] <rsalveti> but that is currently disabled, since we had the ps4 outage
[20:06] <sergiusens> rsalveti: I can't run it yet as part of the merging process, well I could but it would take a couple of hours I guess (vm inside a vm)
[20:07] <rsalveti> right
[20:07] <rsalveti> so the goal is to have that, eventually
[20:07] <rsalveti> mterry: so your answer is only when manually testing it
[20:08] <mterry> rsalveti, fair
[20:08] <mterry> but the plan is more
[20:28] <Chipaca> sergiusens: suggestions for "integrate()"?
[20:28] <Chipaca> sergiusens: generateIntegration()?
[20:29] <Chipaca> sergiusens: ohblahdeeOhblahdahIntegrationLalalalalalala()
[20:29] <Chipaca> sergiusens: antiderivative()
[20:34] <sergiusens> Chipaca: doStuff()
[20:34] <Chipaca> sergiusens: doPerformHelpWorker()
[20:34] <sergiusens> Chipaca: legacyIntegrationHooks?
[20:35] <sergiusens> @bugs
[20:35] <nothal> sergiusens: No such command!
[20:35] <sergiusens> @help
[20:35] <nothal> "list" To see the available commands ; "help cmd" for specific command help
[20:35] <Chipaca> well, some of it is legacy, some isn't
[20:35] <sergiusens> @help list
[20:35] <nothal> Lista las órdenes disponibles.
[20:35] <Chipaca> @list
[20:35] <nothal> The available commands are: ['bug', 'critical', 'help', 'last', 'list', 'more', 'ping', 'reviewlist', 'seen']
[20:35] <Chipaca> @critical
[20:35] <sergiusens> yay, half translations
[20:35] <sergiusens> @bug
[20:35] <sergiusens> hmmm
[20:35] <Chipaca> bug is for “bug # yadda”
[20:35] <sergiusens> Chipaca: !hal broke
[20:36] <Chipaca> but @critical isn't
[20:36] <Chipaca> these python programs, coming here, using up all the bugs
[20:36] <sergiusens> @help bug
[20:36] <nothal>  Search a bug and show it's id, title and status
[20:36] <sergiusens> Chipaca: yeah, I want @bugs :-P
[20:36] <Chipaca> @help critical
[20:36] <nothal> show the crtical bugs for self.project (could be a meta project)
[20:36] <Chipaca> verterok: @critical ne marche plus?
[20:37] <sergiusens> Chipaca: do you know about https://bugs.launchpad.net/snappy/+bug/1460152 ?
[20:37] <Chipaca> verterok: also, why doesn't @reviewlist list everything?
[20:37] <Chipaca> ubottu: i know since i last lucked, mvo picked it up somehow?
[20:37] <Chipaca> or maybe somebody assigned to it
[20:37] <Chipaca> ubottu: sorry, i meant sergiusens
[20:37] <Chipaca> ubottu: i never assume that which i am interacting with is intelligent
[20:38] <sergiusens> Chipaca: I am only a human, pleaase don't think I'm intelligent :-)
[20:38] <Chipaca> ubottu: it's merely a convenient abstraction
[20:38] <verterok> Chipaca: what do you mean it doesn't list everything?
[20:38] <Chipaca> verterok: compare
[20:38] <Chipaca> @reviewlist
[20:38] <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir-15.04/+merge/261104 | No reviews (less than a day old)
[20:38] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-list-row/+merge/260837 | No reviews (1 day old)
[20:38] <nothal> https://code.launchpad.net/~mterry/snappy/rollback-reboot-15.04/+merge/261135 | No reviews (less than a day old)
[20:38] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1460152-workaround/+merge/261144 | No reviews (less than a day old)
[20:38] <nothal> https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934 | No reviews (less than a day old)
[20:38] <Chipaca> verterok: and code.launchpad.net/snappy/+activereviews
[20:38] <nothal> https://code.launchpad.net/~chipaca/snappy/removeClick/+merge/260560 | Needs Information: 1 (5 days old)
[20:38] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1459212-check-required-fields/+merge/260509 | Needs Fixing: 1 (6 days old)
[20:38] <nothal> https://code.launchpad.net/~sergiusens/snappy/frameworkPath/+merge/260202 | Needs Information: 1, Approve: 1 (8 days old)
[20:38] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-more-errors-15.04/+merge/260111 | Approve: 1 (8 days old)
[20:38] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-merge-integration-tests/+merge/259592 | Needs Information: 1, Approve: 1 (14 days old)
[20:39] <Chipaca> verterok: in particular, two of mvo's branches and two of my branches don't show up
[20:39] <verterok> Chipaca: help me here, which ones? :)
[20:40] <Chipaca> verterok: of mine, lp:~chipaca/snappy/setActiveClick and lp:~chipaca/snappy/unsetActiveClick
[20:40] <Chipaca> verterok: of mvo, dunno, i just counted
[20:40]  * Chipaca is bad at making set differences
[20:41] <verterok> Chipaca: k, one example is ok
[20:41] <Chipaca> verterok: this is without looking at mvo's git one :)
[20:42] <verterok> yeah, no git branches/repo support last time I checked launchpadlib
[20:42] <Chipaca> no worries
[20:42]  * Chipaca hopes that will come
[20:43] <Chipaca> sergiusens: before i started the ubottu nonesense, did you read my reply?
[20:43] <sergiusens> Chipaca: I think rsalveti said it was on cjwatson's list
[20:43] <sergiusens> Chipaca: about me not being intelligent?
[20:44] <sergiusens> Chipaca: or this new goodie? https://code.launchpad.net/~mvo/snappy/snappy-lp1460152-workaround/+merge/261144
[20:44] <Chipaca> sergiusens: yes. I mean no, about mvo being on the bug
[20:44] <sergiusens> Chipaca: which shows up on the list ;-)
[20:44] <Chipaca> yeah, that one
[20:44] <Chipaca> sergiusens: noticed it suddenly had a patch and a branch on the milestone list
[20:45] <sergiusens> Chipaca: wrt to integrate() add some comment or the word legacy there, we are planning on getting rid of it, right?
[20:45] <Chipaca> sergiusens: we had a drive-by mvo it seems
[20:45] <Chipaca> sergiusens: maybe :) it's mostly for generating the click manifest, so yes
[20:45] <sergiusens> Chipaca: I know of people that had enough mana to summon him :-)
[20:47] <Chipaca> i found a good place to have a sprint!
[20:47] <Chipaca> http://www.waterwaysholidays.com/detail/alvdove15.htm
[20:47] <mterry> jdstrand, where is docker packaging?  I wanted to get the same error you did in bug 1442410
[20:48] <Chipaca> mvo: boo!
[20:51] <mvo> hey Chipaca
[20:51] <mvo> Chipaca: how are you?
[20:51] <Chipaca> me? I'm fine. My irc client doesn't crash all the time.
[20:51] <sergiusens> lol
[20:56] <Chipaca> so, given http://www.washingtonpost.com/blogs/the-switch/wp/2015/06/04/fbi-official-companies-should-help-us-prevent-encryption-above-all-else/
[20:56] <Chipaca> when do we start encrypting snappy?
[21:00] <verterok> Chipaca: it seems the bot was in a weird state, kicked it a bit
[21:00] <verterok> @reviewlist
[21:00] <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir-15.04/+merge/261104 | No reviews (less than a day old)
[21:00] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-list-row/+merge/260837 | No reviews (1 day old)
[21:00] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1460152-workaround-15.04/+merge/261148 | No reviews (less than a day old)
[21:00] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1460152-workaround/+merge/261144 | No reviews (less than a day old)
[21:00] <nothal> https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934 | No reviews (less than a day old)
[21:00]  * Chipaca kicks nothal 
[21:00]  * nothal kicks Chipaca 
[21:01] <verterok> @reviewlist
[21:01] <nothal> https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir-15.04/+merge/261104 | No reviews (less than a day old)
[21:01] <nothal> https://code.launchpad.net/~stephen-stewart/webdm/tidy-up-list-row/+merge/260837 | No reviews (1 day old)
[21:01] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1460152-workaround-15.04/+merge/261148 | No reviews (less than a day old)
[21:01] <nothal> https://code.launchpad.net/~mvo/snappy/snappy-lp1460152-workaround/+merge/261144 | No reviews (less than a day old)
[21:01] <nothal> https://code.launchpad.net/~chipaca/snappy/mangle/+merge/260934 | No reviews (less than a day old)
[21:02] <verterok> Chipaca: something is broken. sorry. will redeploy it
[21:02] <Chipaca> k...
[21:03] <verterok> @critical
[21:04] <Chipaca> sergiusens: afaict lp:~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/add-sync-calls and lp:~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/use-os-sync
[21:04]  * verterok kicks harder
[21:04] <mvo> hey Chipaca, sorr,y looks like my network is a bit unreliable
[21:04] <Chipaca> sergiusens: are meregd already into ubuntu:vivid/ubuntu-core-upgrader
[21:04] <mvo> Chipaca: did you say anything?
 Chipaca: how are you?
[21:05] <Chipaca> * mvo has quit (Client Quit)
 me? I'm fine. My irc client doesn't crash all the time.
 lol
[21:05] <mvo> my irc client is fine, my network is not ;)
[21:05] <Chipaca> fair enough
[21:05] <mvo> I heard ubuntu-core-upgrader, whats up with that?
[21:05] <mvo> seems to be ok now though (the network), fingers crossed ;)
[21:05] <Chipaca> mvo: afaict lp:~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/add-sync-calls and lp:~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/use-os-sync are meregd already into ubuntu:vivid/ubuntu-core-upgrader
[21:06] <mvo> cool, yeah, quite possible
[21:06]  * mvo can't remember but it rings a bell
[21:06] <Chipaca> mvo: that is, i bzr branch'ed ubuntu:vivid/ubuntu-core-upgrader, and merging those two branches gave me no diff
[21:07] <Chipaca> mvo: does this mean the task wrt the upgrader for 15.04.1 is done?
[21:07] <Chipaca> mvo: or is there more to it?
[21:07]  * Chipaca has no idea
[21:07] <mvo> Chipaca: let me quickly double check
[21:07] <Chipaca> mvo: should i be letting you work at all?
[21:08] <mvo> Chipaca: heh :)
[21:09] <mvo> Chipaca: so its merged but it seems like its not uploaded yet, I will push to the PPA for now and we need a proper SRU
[21:09] <Chipaca> mvo: ok. I thought it landed in ubuntu:yadda after being in the archive proper, but obviously not
[21:14] <mvo> Chipaca: I land it now
[21:16]  * rsalveti waves to mvo 
[21:16] <rsalveti> yeah, we can take care of the SRU side later
[21:17] <rsalveti> guess that would include core-upgrader and core-launcher
[21:18] <mvo> hey rsalveti
[21:18] <mvo> rsalveti: yeah
[21:18] <mterry> sergiusens, you said earlier that install problems on rolling were "a go 1.4 bug (from Chipaca's findings)"
[21:18] <mterry> sergiusens, is there a workaround or a bug to track?
[21:18] <Chipaca> mterry: well, well
[21:18] <Chipaca> mterry: there is no bug for the 1.4 thing afaik, maybe there should be
[21:19] <Chipaca> mterry: we'd have to check with a "proper" go 1.4 first
[21:19] <Chipaca> as this was just with my locally-compiled go 1.4, which might have other issues
[21:19] <Chipaca> (it hasn't been a problem before, but)
[21:19] <Chipaca> mterry: what exactly are you seeing?
[21:20] <mterry> Chipaca, when I try to "sudo snappy install" something, I get "operation not supported" and then a message about unpack from /tmp to the real place failed
[21:20] <Chipaca> ah, yes, that sounds exactly like the thing that happened with my 1.4
[21:20] <mvo> Chipaca, mterry: AIUI lp:~mterry/ubuntu-core-launcher/tmpdir-15.04 needs to land in the PPA as well (its not yet, correct?)
[21:21] <Chipaca> mvo: correct
[21:21] <mterry> mvo, I'd like it to land yeah
[21:21] <mvo> cool, shall I do the merge/upload-to-ppa dance or is someone already on it?
[21:22] <mvo> (sorry, I'm a bit out of the loop)
[21:22] <Chipaca> I've +1'ed and top-approved
[21:22] <rsalveti> one other we need review https://code.launchpad.net/~mterry/ubuntu-core-launcher/tmpdir-15.04/+merge/261104
[21:22] <rsalveti> and then upload as well
[21:22] <Chipaca> rsalveti: that's the one mvo just asked about
[21:22] <Chipaca> rsalveti: and the review is done
[21:22] <rsalveti> indeed, sorry, was going over my tabs
[21:22] <Chipaca> (as i'd reviewed the original one, it was quick)
[21:23] <rsalveti> mvo: I can do as well, you should not even be here :-)
[21:24] <rsalveti> the workaround for the apparmor mr should be automatically merged and uploaded, so that is fine
[21:24] <rsalveti> guess we just need to create the backporting branch once that lands in trunk
[21:26] <rsalveti> Chipaca: lol, that article would be a good one for the onion
[21:26] <Chipaca> rsalveti: :-/
[21:27] <mvo> rsalveti: I have a backport branch pushed as well :)
[21:27]  * rsalveti hugs mvo 
[21:28] <mvo> rsalveti: I can do the merge/upload, thats fine (unless you already started that or I duplicate the work of someone else)
[21:28] <rsalveti> didn't yet start, unless Chipaca is on it, I don't think anyone is on it yet
[21:29] <Chipaca> i can't upload, i don't think
[21:29] <rsalveti> you should be able to
[21:29] <rsalveti> you're part of ~snappy-dev
[21:30] <Chipaca> Excellent.
[21:30]  * Chipaca did not just do his mr burns impression
[21:30] <rsalveti> I'll trigger another image once everything is there
[21:30] <rsalveti> and hopefully we should have our first RC
[21:32] <mterry> mvo, I saw your comment about helpers/, which I also helped make worse with my EnvVar stuff
[21:32] <mterry> mvo, maybe we need a second "general" package
[21:32] <Chipaca> mterry: what was the comment?
[21:32] <mvo> mterry: yeah! or maybe I'm overthinking this, I'm not sure yet :)
[21:32] <mterry> on lp:~sergiusens/snappy/YouShallNotPass merge, just saying a func maybe doesn't belong in helpers/
[21:32] <mterry> Chipaca, ^
[21:33] <mvo> but I would love to have a tiny bit more structure in helpers as its a bit of a misc/ dir right now and at some point it was meant to be stuff-missing-in-stdlib or something like that
[21:33] <mterry> Chipaca, so wait.  About the go1.4 bug.  no workaround yet?  Should I just go back to 15.04 for testing?
[21:34] <Chipaca> mterry: given the bug, yes, go back to 15.04
[21:34] <Chipaca> especially as that's what we're releasing rsn :)
[21:35] <Chipaca> mterry: or, compile snappy with 1.3 for W
[21:35] <Chipaca> mterry: until we've sorted that one out
[21:35] <mvo> rsalveti: once the workaround branch lands (assuming it gets a ok fromthe reviewers) we need to trigger the daily build for that branch, let me quickly search the url for that
[21:35] <mterry> Chipaca, pfft, 15.04 is old hat, even if we are shipping a point release  :)
[21:35] <Chipaca> go's "compatibility promise", on which they base not supporting releases for more than ~6 months, has bit us before now, so
[21:35] <mvo> rsalveti: https://code.launchpad.net/~snappy-dev/+recipe/snappy-daily/ <- thats the page
[21:36]  * mvo wishes we had git-dch for bzr or git so that it would auto-create the debian/changelog from the vcs comments
[21:41] <rsalveti> mvo: awesome, thanks
[21:42] <rsalveti> yeah
[21:45] <rsalveti> Chipaca: can I just cross lp:~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/add-sync-calls and lp:~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/use-os-sync ?
[21:46] <Chipaca> rsalveti: AIUI if you're asking, no
[21:46] <Chipaca> rsalveti: mvo said he could do it, you told him you could and that he shouldn't be here
[21:46] <Chipaca> rsalveti: or maybe i misunderstood
[21:47]  * mvo is confused now ;)
[21:47] <rsalveti> Chipaca: sorry, you said earlier that you tried merging jhunt's branches and got a 0 diff
[21:47]  * rsalveti reads backlog
[21:48] <mvo> yeah, the use-os-sync was merged but not uploaded, I uploaded that now to the ppa and to wily
[21:48] <rsalveti> yeah, then all good
[21:49] <rsalveti> crossing then
[21:49] <mvo> https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages should have the info looks like its indeed there
[21:50] <rsalveti> awesome
[21:50] <mvo> Chipaca: I need to buy you tea (or beer) for all the silly mistakes you need to endure in my branches, thanks a lot for spotting these issues
[21:51]  * Chipaca blushes
[21:51] <Chipaca> mvo: you've put up with a lot of nonsense in my branches, glad to be finally paying it back :D
[21:51] <mvo> lol
[21:52] <Chipaca> still have to learn to do reviews like yours though; almost makes me want to put more mps up just to get them :)
[21:53] <Chipaca> ANYway, i should put down the computer and go wash the dishes and get the house ready for the night
[21:53] <mvo> Chipaca: a more serious question about the oauth signing branch, you point out (correctly) that buf.Grow(len(inputString)*3) may be too small and I need to count the bytes. should I simply use len(s)*3 (quotes) *4 (utf-8 len) - or convert the str to bytes before checking the len?
[21:53] <Chipaca> mvo: you're converting it to bytes anyway
[21:54] <Chipaca> mvo: might as well do it earlier
[21:54] <mvo> Chipaca: do that, I will call it a day soon too
[21:54] <mvo> Chipaca: yeah, sounds sensible
[21:54] <mvo> Chipaca: thanks a bunch
[22:17] <mvo> rsalveti: its hopefully all prepared for the release-candidate, just ping me again if there is anything that needs work. I will keep a eye on my mail to see if my MPs get approved
[22:17] <rsalveti> mvo: sure, thanks so much
[22:19] <mvo> your welcome!
[22:19]  * mvo &
[23:46] <rsalveti> sergiusens: https://code.launchpad.net/~mvo/snappy/snappy-lp1460152-workaround/+merge/261144 would only work if the base image (stable) already had such changes, right?
[23:47] <rsalveti> it seems our problem is that we'll be updating from stable to edge using the tools that are currently available at stable
[23:47] <rsalveti> so it would only work after doing another update
[23:48] <rsalveti> guess that's the usual problem of updating using the tools available from the older image (like we had with touch)
[23:53] <rsalveti> added a comment to the MR (for lp:snappy)