[13:22] <gary_poster> bac benji danilos gmb, aloha.  slight change to morning meeting call: please have kanban board up-to-date 5 min before call (3 min from now).  I will review before call, and just ask questions about things I wonder about.  Then I'll circle through everyone once and ask if they have anthing to add, then we're done.
[13:22] <gmb> ok
[13:22] <gary_poster> gmb, hey, how goes the db war?
[13:23] <gary_poster> oh, also, I'm going to use Skype
[13:23] <gary_poster> barring any objections
[13:23] <bac`> none from me
[13:23] <gmb> gary_poster: It turned out to be a one-line fix. I had to tell Person.merge() to ignore BugSubscriptionFilterMutes when merging. That wasn't obvious from the failures though. I went from having 30-odd test failures to 0
[13:23] <gary_poster> cool
[13:23] <gmb> Skype works for me.
[13:23] <gary_poster> heh
[13:23] <gary_poster> ok cool
[13:24] <gary_poster> gmb, did you happen to merge db-devel or something similar (given the upcoming deploy, maybe devel already has db-devel stuff)?
[13:25]  * gary_poster can't qa the bits I need to 'cause qastaging is down. :-/
[13:25] <gmb> gary_poster: No. I fixed the failures and pushed and ran. When's the DB deploy? Wednesday AM?
[13:26] <gary_poster> gmb, yeah, I think so.  I saw that devel is in RC until qa is finished
[13:26] <gary_poster> my interest is in making an MP though
[13:26] <gmb> Ah.
[13:26] <gmb> gary_poster: I can merge db-devel and push now for you.
[13:26] <gary_poster> I have necessary changes both from your branch and from trunk-ish
[13:26] <gary_poster> awesome thank you
[13:27]  * gary_poster starting to stare an kanban board...
[13:28] <gary_poster> yay, my stuff is qa'd by wgrant!
[13:30] <gary_poster> danilos, benji, skype plz?
[13:30] <danilos> gary_poster, ack
[13:30] <gary_poster> thanks
[13:30] <gmb> gary_poster: lp:~gmb/launchpad/team-subscription-opt-out and lp:~gmb/launchpad/team-subscription-opt-out-apis now contain db-devel.
[13:31] <gary_poster> yay, thank you gmb
[13:31] <benji> gary_poster: there now
[13:31] <gmb> AAAAH.
[13:32] <gmb> gary_poster: Please try again.
[13:32] <danilos> gary_poster, I am here
[13:40] <bac> benji: skype?
[13:40] <benji> bac: sure
[13:41] <bac> benji: what is your skype id?
[13:41] <benji> bac: um... let me see
[13:41] <benji> bac: benji_york
[13:41] <gary_poster> benji_york
[13:55] <danilos> bac, benji, gary_poster, gmb: fwiw, my refactoring branch does change the structural_subscriptions.js quite a bit, at least for the setup code
[13:55] <bac> danilos: ok.  shouldn't affect my work
[13:55] <gary_poster> danilos, yeah I was afraid of that. :-) I have a branch thst changes JS
[13:55] <gary_poster> I'll figure out what to do about it in a few minutes
[13:57] <danilos> gary_poster, I did a lot of sanity refactoring and got rid of that context-passing-around hack that we had as well in the process
[13:57] <gary_poster> danilos, cool
[13:57] <danilos> gary_poster, I am hoping nobody gets affected too much though
[13:57] <gary_poster> :-) I'll see.  it was good stuff to do anyway.
[13:59] <gmb> gary_poster: I just submitted AWS expenses for March. Can you sign them off when you get a chance?
[13:59] <gary_poster> will do gmb, thanks for heads up
[14:00] <gmb> np
[14:00] <gmb> Thanks
[14:04] <bac> feature flag enabled for ~yellow on staging
[14:06] <gary_poster> gmb, approved expenses.  https://code.launchpad.net/~gary/launchpad/muteteamsub-email/+merge/56154 is now ready when you are.
[14:06] <gmb> Ooo, a trade of web forms.
[14:06] <gmb> On it.
[14:06] <gary_poster> :-) thanks
[14:07] <danilos> gary_poster, oh, I've filed the amazon ec2 expense as well (just now so hoping it doesn't transfer into next month :)
[14:07] <gary_poster> :-) k looking
[14:09] <gary_poster> approved danilos.  I'm thinking about what I should do to handle your changes.  Maybe I should merge your refactor branch now?  Or would you suggest I wait until later for some reason?
[14:10] <danilos> gary_poster, I'd be very happy if you branch now, I don't expect big changes there (and if I do, I'd do it as a separate branch)
[14:10] <danilos> gary_poster, what particular bits are you changing?
[14:11] <danilos> gary_poster, it's for muting/unmuting links on the subscriptions list?
[14:11] <gary_poster> right
[14:11] <gary_poster> I doubt that will be affected much but
[14:11] <gary_poster> I wonder if the tests might be
[14:11] <gary_poster> (which I started, and then stopped because I wondered if I might be stomping on you)
[14:12] <danilos> gary_poster, I didn't change any tests so far (they all pass, though), and I fully expect to have to pretty soon now since I did split it all up into smaller functions
[14:13] <danilos> gary_poster, iow, I only expect to be introducing new tests, and my changes are only from make_edit_handler and "below"
[14:13] <gary_poster> danilos.  ack.  One exciting bit is that there are no tests for the edit form rendering, as you probably know
[14:13] <gary_poster> right, cool
[14:13] <danilos> gary_poster, yeah, and I think my refactor should help with some of that when we get to it
[14:14] <gary_poster> ok, but since your changes are make_edit_handler and below...
[14:14] <gary_poster> then you won't be writing tests for edit stuff now?
[14:14] <gary_poster> So I can?
[14:14] <gary_poster> (without fear of duplicating work)
[14:15] <danilos> gary_poster, well, "only below" is probably not completely correct, but I am not doing any tests yet, no
[14:15] <gary_poster> ok
[14:15] <danilos> gary_poster, if you are planning to do tests, however, I strongly suggest you merge my branch first
[14:15] <gary_poster> then I'll start working on thos in just a few.  I have other stuff I should get to first
[14:15] <danilos> ack
[14:16] <gary_poster> ok, danilos, will do.
[14:40] <gmb> gary_poster: Your branch is r=me.
[14:41] <gary_poster> cool, thanks gmb.  I have something else for your attention in just 1 sec...
[14:41] <gmb> ok
[14:47] <gary_poster> gmb, please take a glance at https://dev.launchpad.net/LEP/BetterBugSubscriptionsAndNotifications/FeatureReviewNotes
[14:47] <gary_poster> You might be able to fill in a couple fo XXXs (or remove them as appropriate)
[14:49] <gmb> Ok, will do.
[15:12] <gmb> gary_poster: I've removed a couple of XXXs and left the rest (that I didn't know much about) alone.
[15:13] <gmb> gary_poster: Should I take a look at the Bug 1 muting timeout problem?
[15:13] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubunt
[15:15] <gary_poster> gmb, ...sure.
[15:16] <gary_poster> and thank you
[15:16] <gmb> np
[15:19] <gary_poster> danilos, just merged.  18 conflicts. ;-) will work on resolving in a few.
[15:19] <gary_poster> (18 all within the one js file)
[15:19] <gary_poster> most are very small
[15:19] <gary_poster> but some not so much :-P
[15:20] <gary_poster> danilos, nice yellow sub btw :-)
[15:21] <gary_poster> ...not clear on what triggered mup to get excited there...
[15:23] <benji> gary_poster: Bug 1 was mentioned earlier.  I wonder if the general heft of Bug 1 makes mup take a long time to do its thing.
[15:23] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubunt
[15:23] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubunt
[15:23] <benji> I guess I can DOS mup by mentioning Bug 1 a lot.
[15:23] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubunt
[15:24] <gary_poster> ah true
[15:24] <gary_poster> heh
[15:26] <danilos> gary_poster, not sure what you mean with "yellow sub"?
[15:30] <gary_poster> danilos, I though you might be source of icon change in https://launchpad.net/~yellow ?
[15:31] <gary_poster> So, I should let jml and diogo get the new flag
[15:31] <gary_poster> I could add them to ~yellow
[15:32] <gary_poster> But I'm inclined to ask jml if he wants a particular team to be added to the flag
[15:32] <gary_poster> any opinions?
[15:37] <benji> gary_poster: I'm doing QA for the structual susbscription JS and I noticed that for the "are added or changed in any way" radio button we use "(more options...)" and for "Bugs must match this filter" we use just "(...)".  Is that intentional?
[15:39] <gary_poster> benji, yeah.  I thought at that point it would be clear, and didn't want the clutter.
[15:39] <benji> k
[15:39] <gary_poster> don't feel strongly about it, but OTOH would not be keen on a change unless we got people actually being confused or compaining about it
[15:47] <gary_poster> in case this affects anyone, here's a rough outline of my plans right now.  I'm going to address the JS conflicts, since danilos is still around, in case I need to confer with him.
[15:47] <gary_poster> Then, because I kind of need to wait for either danilos' branch or gmb's API branch to land on db-devel for me to get a sane MP diff, I'm going to switch to small things such as my long-outstanding expenses.
[15:47] <gary_poster> Then I'll get back to the UI branch, and hopefully have an MP waiting for gmb in the morning with tests.
[15:47] <gary_poster> Finally, maybe worth noting is that I will be out tomorrow for a few hours after our call, and will continue to do that every Tuesday until the baby pops out.
[16:11] <benji> gary_poster: here are my QA items for structual subscriptions: http://pastebin.ubuntu.com/589310/; how should I handle them?
[16:13] <gary_poster> benji, this is in regards to landing the client branch, right?
[16:13] <benji> right
[16:15] <gmb> gary_poster: So, this timeout... as far as I can tell it's a query that takes too long, but there isn't much info available in the OOPS reports: https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1914I723. Can you think of any way that I make useful headway here? I'm a bit stumped.
[16:15] <gary_poster> benji, ok.  first, if this is blocking any card from being qa-ok, mark it as qa-ok.  We are feature flagged.
[16:18] <benji> gary_poster: these branches were landed with no-qa; so we're good there, these problems aren't big so I assume the two cards I have in the QA lane should be moved to deployable.
[16:18] <benji> my main question is what should I do with this list of small things
[16:19] <gary_poster> benji, yes.  List of small things: 1 sec.
[16:19] <benji> no rush
[16:22] <gary_poster> gmb, I'd try to figure out where the sql is coming from.  I'm guessing you agree. :-) Since you are asking, I'm guessing you are not sure what the source is.  I'd try running mute locally with the "show my all the SQL environmental variable.  If that gives you enough to figure it out, great.
[16:22] <gary_poster> If it does not, we might need to do a pdb *with the SQL env variable also*.  I'd do it in zope.publisher.publish debug_call myself, since we have no freaking idea.  Then you can dig around until you see the SQL being generated, and figure out the source that way.
[16:23] <gmb> gary_poster: Okay, that sounds like as good a way to go as any. Thanks.
[16:23]  * gmb refuels the tea tank before starting
[16:23] <gary_poster> :-)
[16:24] <gary_poster> benji, no activity animation: please look at the card in the design section of the backlog starting with ""Unsubscribe" on IBug:..." and make sure it encompasses your concern.
[16:24] <gary_poster> dialog hangs around oddly: I'm not clear on that one.
[16:24] <gary_poster> I don't knw what it means
[16:24] <gary_poster> Maybe make a new card?  Maybe try to describe it for me first here?  your call <shrug>
[16:25] <gary_poster> tag text box: new card
[16:25] <gary_poster> status "Unknown": new card + I suggest an associated bug
[16:25] <gary_poster> overlay start out closer to top of page: new display card
[16:25] <benji> gary_poster: sorry, I forgot that I started making those notes just for me; the dialog appears to get cought deconstructing (or maybe resetting) itself; I click the "do it" button and the dialog gets smaller but still has most of the form visible then it hangs there for a second and then disappears
[16:26] <gary_poster> huh
[16:26] <gary_poster> yeah, a card in "display tweaks" sounds appropriate.
[16:26] <benji> k
[16:26] <gary_poster> For all of those, feel free to make a bug as well
[16:26] <benji> k
[16:26] <gary_poster> but a card is my top priority
[16:27] <gary_poster> Thank you benji, those are good catches.
[16:28] <benji> I'm good at being picky.
[16:28] <gary_poster> :-)
[16:31] <gary_poster> gmb, look for "parent_message" in Bug.index_message in lib/lp/bugs/model/bug.py.
[16:31] <gary_poster> looks like source
[16:31] <gmb> Aha.
[16:31] <gmb> Thanks.
[16:32] <gary_poster> np
[17:08]  * gary_poster was trying to figure out js test failures but then saw the MP
[17:28]  * gary_poster lunches
[18:42] <bac> benji: what is the URL that the edit link should point to?
[18:44] <gary_poster> +subscriptions on the bug target bac.  I *think* it is on bugs.*
[18:45] <bac> gary_poster: ok, that's what i figured
[18:45] <gary_poster> actually it is on all
[18:45] <gary_poster> or at least https://bugs.launchpad.net/launchpad/+subscriptions and https://launchpad.net/launchpad/+subscriptions
[18:47] <gary_poster> cool
[18:52] <benji> bac: sorry, was finishing up lunch... https://bugs.staging.launchpad.net/manuel/+subscriptions
[18:52] <bac> benji: thanks
[18:59] <benji> bac: I have a couple little things to do and then I'll be ready for some pillar divvying
[19:01] <bac> benji: ok
[19:48] <gary_poster> Be prepared for shock and awe: I actually filed my expenses!  It's amazing.
[20:01] <benji> bac: heh, cool
[20:12] <gary_poster> On kanban card, "Administrivia" cards are now "Miscellaneous" cards
[21:36] <bac> benji: fwiw, the refactoring you suggested last week (create 'add_subscribe_link) made today's work much easier.
[21:37] <benji> bac: cool
[21:37] <benji> I guess I'm not entirely full of hot air. ;)
[22:10] <benji> Reason #61 I like telecommuting: Even a home body like me can look forward to going outside on a nice spring day.


[08:24] <fwereade> davecheney, heyhey
[08:25] <rogpeppe> fwereade, davecheney: morning'
[08:25] <fwereade> and rogpeppe, also heyhey
[08:25] <fwereade> and TheMue :)
[08:26] <TheMue> fwereade: morning, and who else? ;)
[08:26] <fwereade> TheMue, dave and rogpeppe
[08:26] <TheMue> fwereade: ah
[08:26] <rogpeppe> i have only just opened up the computer, to be fair :-)
[08:26] <TheMue> davecheney: hello and rogpeppe: heya
[08:27] <rogpeppe> TheMue: yo@
[08:27] <rogpeppe> !
[08:27]  * TheMue too
[08:27] <rogpeppe> my fingers still aren't working too well
[08:28] <davecheney> hello
[08:32] <fwereade> davecheney, and possibly rogpeppe, I was meaning to ask
[08:32] <fwereade> davecheney, rogpeppe: is it just a tools problem that's blocking non-precise deploys?
[08:32] <rogpeppe> fwereade: yes
[08:32] <rogpeppe> fwereade: AFAIK
[08:32] <davecheney> fwereade: i have a proposal for that
[08:33] <fwereade> davecheney, rogpeppe: in that case ISTM that davecheney's approach is sane
[08:33] <rogpeppe> fwereade: we just need to compile mongodb for quantal
[08:33] <rogpeppe> fwereade: at least, that was the blocker i saw
[08:33] <davecheney> rogpeppe: i'm only considering deploying from quantal -> LTS
[08:33] <fwereade> rogpeppe, ah, ok, makes sense
[08:33] <davecheney> we can consider the other permutations another day
[08:33] <rogpeppe> davecheney: we want to be able to do LTS -> quantal too
[08:33] <davecheney> but making a quantal/raring mongo will enable that
[08:33] <davecheney> rogpeppe: we *might*
[08:34] <davecheney> i haven't seen a request for that yet
[08:34] <rogpeppe> davecheney: so that we can run the builddb charm for quantal from precise
[08:34] <davecheney> rogpeppe: what is the story with mongo
[08:34] <fwereade> davecheney, we want to be able to deploy to and from anything basically
[08:34] <davecheney> fwereade: sure, i agree, but i'm only focusing on things we *need* this week
[08:34] <davecheney> wants can come later :)
[08:34] <rogpeppe> davecheney: we just need to build a quantal version
[08:34] <davecheney> rogpeppe: i thought we were screwed on licencing
[08:34] <fwereade> davecheney, that's fine indeed :)
[08:35] <rogpeppe> davecheney: i haven't heard that - what's the story?
[08:35] <davecheney> rogpeppe: mark saied we aren't allowed to distribute that binary
[08:35] <rogpeppe> davecheney: the mongo binary?
[08:35] <davecheney> ja
[08:35] <rogpeppe> davecheney: well we're fucked then
[08:36] <davecheney> yes
[08:36] <davecheney> is mark working this week ?
[08:36] <davecheney> rogpeppe: ideally if we could get a 2.2 backport into the archive
[08:36] <davecheney> that would solve our problem
[08:36] <rogpeppe> davecheney: how would that help?
[08:37] <rogpeppe> davecheney: and how come we're allowed to distribute the binary via apt-get ?
[08:37] <davecheney> rogpeppe: as I understand it the current mongo in precise has TLS enabled
[08:37] <davecheney> is that correct
[08:37] <davecheney> ?
[08:38] <rogpeppe> davecheney: i dunno. i don't think so, but i'll check
[08:38] <davecheney> rogpeppe: if so, the licencing issue becomes someone elses' problem
[08:38] <davecheney> we just ride on the archives' coat tails
[08:39] <rogpeppe> davecheney: no the default version does not have tls enabled
[08:39] <davecheney> rogpeppe: right, back to being screwed then
[08:40] <rogpeppe> davecheney: i thought AGPL allowed distribution in binary form
[08:40] <davecheney> openssl is not AGPL :(
[08:40] <davecheney> and by linking statically to it
[08:40] <davecheney> we polute the binary
[08:41] <davecheney> but, we might get lucky as the source of the program that builds the binary is available
[08:41]  * davecheney IANAL
[08:42] <rogpeppe> davecheney: we weren't planning to link to openssl, were we?
[08:42] <rogpeppe> davecheney: ah, of course
[08:42] <rogpeppe> davecheney: mongo itself
[08:42] <rogpeppe> doh!
[08:42] <davecheney> welcome to open sores licencing shitfighting
[08:44] <rogpeppe> davecheney: openssl is so shit internally too. not worth fighting for.
[08:45] <rogpeppe> davecheney: the license doesn't seem too onerous actually: http://www.openssl.org/source/license.html
[08:45] <rogpeppe> davecheney: (either of them)
[08:45] <rogpeppe> davecheney: "
[08:45] <rogpeppe> Actually both licenses are BSD-style
[08:45] <rogpeppe>   Open Source licenses.
[08:45] <rogpeppe> "
[08:46] <davecheney> rogpeppe: I need mark to respond
[08:46] <davecheney> but for the moment lets assume we're in the clear
[08:47] <rogpeppe> davecheney: it looks like we should be. those licenses don't seem to disallow anything other than redistributing without the license
[08:49] <rogpeppe> davecheney: oh, here's the issue: http://people.gnome.org/~markmc/openssl-and-the-gpl.html
[08:50] <davecheney> right, openssl is bsd 3 clause
[08:50] <davecheney> am i correct ?
[08:50] <rogpeppe> davecheney: yeah
[08:51] <rogpeppe> davecheney: so it imposes some restrictions (you must distribute acknowledgements) that GPL doesn't allow you
[08:51] <rogpeppe> davecheney: what a mess
[08:53] <davecheney> sounds like the Apache Harmony vs the Java TCK nonsense
[08:57] <rogpeppe> davecheney: i don't know about that
[08:57]  * rogpeppe googles
[08:58] <davecheney> rogpeppe: http://en.wikipedia.org/wiki/Apache_Harmony#Difficulties_to_obtain_a_TCK_license_from_Sun
[08:58] <davecheney> almost identical story to the one above
[08:59] <davecheney> to do X, we need Y, but using Y implys we can't be X
[09:01] <davecheney> error: Failed to load data for project "juju-core": Get https://api.launchpad.net/devel/juju-core: EOF
[09:01]  * davecheney shakes fist at LP
[09:03] <rogpeppe> davecheney: if either mongodb or openssl were reasonable pieces of code, it should not be hard to do a GPL-compatible replacement for the way that mongo uses it
[09:03] <rogpeppe> davecheney: sadly both are convoluted to hell
[09:05] <davecheney> so i have heard
[09:05] <rogpeppe> davecheney: i spent a significant proportion of yesterday delving deeply into the openssl code
[09:05] <rogpeppe> davecheney: so i could find a particular constant
[09:06] <rogpeppe> davecheney: to implement x509.Encrypt
[09:06] <rogpeppe> oops
[09:06] <rogpeppe> davecheney: to implement x509.EncryptPEMBlock
[09:06] <rogpeppe> davecheney: because mongo does not support reading unencrypted PEM blocks
[09:07] <rogpeppe> davecheney: it epitomises everything that's wrong with C-as-it-has-turned-out
[09:08]  * davecheney pats rogpeppe on the shoulder
[09:08] <davecheney> i bet it's a rats nest of macros and #ifdefs
[09:08] <rogpeppe> davecheney: yup
[09:09] <rogpeppe> davecheney: and unnecessary layers of abstraction
[09:12] <rogpeppe> davecheney: so this issue means that none of the Go source code is GPL-compatible AFAICS
[09:13] <rogpeppe> davecheney: and i always thought the BSD license was the less restrictive one
[09:13] <davecheney> rogpeppe: it is a modified 2 arg, right ?
[09:13] <rogpeppe> davecheney: well, i guess it is, but just an incompatible set of restrictions
[09:14] <rogpeppe> davecheney: "Redistributions in binary form must reproduce ..."
[09:15]  * davecheney checks
[09:15] <davecheney> i don't know enough about this stuff
[09:15] <davecheney> i'm not sure i want to ,either
[09:15] <rogpeppe> GPL should allow components to add copyright notice distributions
[09:15] <rogpeppe> i'm sure that this incompatibility is against its original aims
[09:16] <davecheney> rogpeppe: i think go is ok in this respect
[09:17] <davecheney> the wording in the 2nd clause in
[09:17] <davecheney> http://golang.org/LICENSE
[09:17] <davecheney> differs from the complaint in http://people.gnome.org/~markmc/openssl-and-the-gpl.html
[09:18] <rogpeppe> "
[09:18] <rogpeppe> You may not impose any further
[09:18] <rogpeppe>   restrictions on the recipients' exercise of the rights granted herein.
[09:18] <rogpeppe> "
[09:18] <davecheney> oh for fucks sake
[09:18] <rogpeppe> the 2nd clause in the go license seems like it does that
[09:18] <rogpeppe> yeah
[09:18] <davecheney> maybe this is an ordering issue
[09:19] <davecheney> the order in which you stack licences would allow for some interesting permutations
[09:21] <rogpeppe> davecheney: so you can't distribute a Go program that links against a GPL program, but you can distribute a Go program as GPL
[09:21] <rogpeppe> davecheney: that kinda makes sense
[09:22] <davecheney> sounds like witchcraft
[09:22] <rogpeppe> davecheney: i see now how 10gen make money
[09:22] <davecheney> you can't sell wisky with water in it, but you can pour wisky over ice
[09:22] <davecheney> or something
[09:22] <davecheney> rogpeppe: for 10gen i imagine it is more about indemity
[09:22] <davecheney> or providing indemnity to their customers
[09:23] <davecheney> which is a massive issue for the more regulated companies in our industry
[09:23] <rogpeppe> davecheney: i doubt it - why else would they sell the OpenSSL version separately?
[09:23] <rogpeppe> davecheney: well, i'm sure indemnity is part of it too
[09:23] <davecheney> you are probably right, heinoius money grabbing
[09:28] <rogpeppe> davecheney: actually, this just might be a good thing
[09:30] <davecheney> mmm
[09:30] <rogpeppe> davecheney: actually.... i think we're all ok
[09:30] <rogpeppe> davecheney: AGPL != GPL
[09:30] <rogpeppe> davecheney: see http://www.gnu.org/licenses/agpl-3.0.html section 7
[09:31] <rogpeppe> davecheney: "you may [...] supplement the terms of this License with terms: [...] requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; "
[09:32] <davecheney> the source of Juju is AGPL, i dunno if that applies to a file we reference in binary form
[09:32] <rogpeppe> davecheney: mongo license is AGPL
[09:32] <davecheney> orly
[09:33] <rogpeppe> davecheney: which i'd always thought of as more restrictive than GPL, funnily
[09:33] <davecheney> it's more free, which depends on your POV
[09:34] <rogpeppe> davecheney: anyway, by my reading of it, we *can* distribute mongodb binaries :-)
[09:35] <rogpeppe> davecheney: IANALBASOTI
[09:35] <davecheney> sounds good enough for now
[09:35] <davecheney> yes, everyone in the chan who is a lawyer, raise your hand
[09:36] <davecheney> rogpeppe: so, where does that leave us
[09:36] <davecheney> mongo == good
[09:36] <rogpeppe> davecheney: yeah
[09:36] <rogpeppe> davecheney: AGPL == good
[09:36] <davecheney> but you're getting screwed over by certs
[09:36] <rogpeppe> davecheney: that's fine, go needs EncryptPEMBlock anyway
[09:37] <rogpeppe> davecheney: although it is annoying
[11:00] <Aram> hello.
[11:01] <TheMue> Aram: hi
[12:53] <hazmat> rogpeppe, we do have lawyers avail
[12:54] <hazmat> mramm, was looking into it afaicr
[12:54] <rogpeppe> hazmat: i just wanted to assure myself that all was not lost :-)
[12:55] <mramm> hazmat: rogpeppe: well we can move to encrypted channels in the rest API
[12:55] <rogpeppe> mramm: what about the channels from the API servers to the mongodb servers?
[12:55] <mramm> the thing there is that you could snoop data if you can snoop the network
[12:55] <mramm> right
[12:56] <mramm> you wouldn't have control, just access to data, which is not great, but probably not catastrophic
[12:56] <rogpeppe> mramm: if you can change network packets, you have control
[12:56] <mramm> true
[12:57] <rogpeppe> mramm: from my extremely crude reading of the AGPL, i don't *think* there should be a problem with us distributing the mongodb/openssl binaries.
[12:57] <rogpeppe> mramm: but as hazmat says, we have lawyers. i'd like to know what they think.
[12:58] <mramm> yes
[12:59] <mramm> I think we might be able to get away with distributing under a modified AGPL that allows advertising
[12:59] <mramm> but we might need to talk 10gen into doing the same
[12:59] <mramm> and elliot at 10gen seems to think he has a solution to the problem coming
[13:00] <mramm> but I'm not in the loop on what that is
[13:02] <mramm> and we can also just setup VPN of some sort to handle transport level security
[13:03] <mramm> so it's definitely true that "all is not lost"
[13:03] <mramm> we will be able to route around the problem if we need to
[13:04] <fwereade> Aram, ping
[13:04] <Aram> yes
[13:04] <Aram> fwereade: ^
[13:04] <fwereade> Aram, I'm thinking about subordinates
[13:05] <Aram> what about them.
[13:05] <fwereade> Aram, and ISTM that what I need is basically precisely a machiner, but watching a slightly different set of units
[13:06] <fwereade> Aram, but I wanted you input on the current MachinePrincipalUnitsWatcher
[13:06] <fwereade> Aram, and whether or not you anticipate changes to API or semantics at any point
[13:06] <Aram> fwereade: so what set of units you want to watch?
[13:07] <fwereade> Aram, the subordinates of one specific unit
[13:07] <Aram> I see.
[13:07] <Aram> well.
[13:07] <Aram> hmm.
[13:07] <Aram> there will be changes in the implementation that will make this easier, hopefully this week.
[13:07] <Aram> but in semantics or API, I don't think so.
[13:08] <fwereade> Aram, so it remains just Added/Removed with all other changes swallowed?
[13:09] <Aram> (actually the MachinePrincipalUnitsWatcher and the MachineUnitWatcher use a diferent API in my latest branches than in trunk).
[13:09] <Aram> personally I would change it to return more events.
[13:10] <Aram> but I don't think niemeyer would approve.
[13:10] <Aram> for the time being I suspect it's a safe bet that this behavior won't change.
[13:10] <fwereade> Aram, always a fine line to walk ;)
[13:10] <Aram> although it has disadvantages IMO.
[13:11] <fwereade> Aram, I'll go with the current behaviour for now then, see where it takes me; cheers
[13:12] <Aram> fwereade: it kind of bugs me that each collection watcher starts N individual watchers, but in some client of the collection watcher, like the firewaller or whatever, you start N individual watchers yourself anyway.
[13:13] <fwereade> Aram, yeah, I feel that it's undergone somewhat forced/accelerated evolution and it needs to settle a bit
[13:13] <Aram> fwereade: I'
[13:14] <Aram> fwereade: I'd either make collection watchers return everything (no filtering) OR make them report only new objects as they become alive and no other event.
[13:19] <Aram> fwereade: I did an experiment yesterday making the machine units watcher return everything with no filtering. the "problem" was that you got an event for the principal when you added a subordinate, because the principal is also modified in the process, but maybe that's ok.
[13:20] <fwereade> Aram, yeah, I don't see that as a major problem myself
[13:21] <Aram> fwereade: well, one issue might be that it essentially returns implementation details, right now the principal is modified in the process of adding a subordinate, but in the future it need not be.
[13:22] <fwereade> Aram, I guess it all comes back down to agreement on what changes it is guaranteed for and which it isn't
[14:18] <Aram> TheMue: have any idea why a firewaller will pick a close port event, but it will not pick the same close port event if the firewaller was stopped, and then restarted?
[14:19] <Aram> I have a mental idea of what kind of race is going on, but it's somewhat hard for me to debug it, probably because of the unfamiliarity of the code.
[14:19] <Aram> TheMue_: have any idea why a firewaller will pick a close port event, but it will not pick the same close port event if the firewaller was stopped, and then restarted?
[14:20] <Aram> I have a mental idea of what kind of race is going on, but it's somewhat hard for me to debug it, probably because of the unfamiliarity of the code.
[14:20] <TheMue_> Aaarg, disconnected just after the answer.
[14:20] <TheMue_> Aram: I will take a deeper look.
[14:21] <TheMue_> Aram: The last part that has been changed has been the adding of the global mode.
[14:22] <TheMue> Aram: Here the initial open ports are retrieved not by the watchers but by traversing the state.
[14:22] <Aram> hmm
[14:23] <Aram> TheMue: basically this works, but if you uncomment those lines it will fail: http://paste.ubuntu.com/1339904/
[14:25] <TheMue> Aram: Where exactly does it fail? Line?
[14:26] <Aram> TheMue: http://paste.ubuntu.com/1339921/
[14:32] <Aram> TheMue: you say that initial ports are retrieved from the environment, not from the watchers, then how can the firewaller determine if a close port on a unit should have any effect globally, since it doesn't know which units might use that port?
[14:32] <Aram> TheMue: from what you are telling me, the failure seems expected, so how did it work before?
[14:32] <TheMue> Aram: Just going through the code.
[14:32] <TheMue> Aram: It worked.
[14:33] <TheMue> Aram: The initial ports only in global mode are retrieved from the env.
[14:33] <Aram> yeah
[14:33] <TheMue> Aram: But the watchers still work.
[14:33] <Aram> of course.
[14:33] <TheMue> Aram: And this is collated with the already known global ports.
[14:33] <Aram> but when you get a close port event from a unit, how do you know if you should close the port globally?
[14:34] <TheMue> Aram: One moment, will tell you the line number.
[14:35] <TheMue> Aram: Line 228 and the function flushGlobalPorts()
[14:36] <TheMue> Aram: Here is also the fw.globalPortRef[port] to cound the usage
[14:36] <rogpeppe> lunch
[14:36] <Aram> TheMue: who initializes fw.globalPortRef?
[14:38] <TheMue> Aram: It's created in initGlobalMode() and the counters will be increased by flushGlobalPorts() (based on the watchers).
[14:39] <TheMue> Aram: If they would already be counted in initGlobalMode() they would be counted twice.
[14:39] <fwereade> TheMue, on a related note, if you have a mo: how do we handle units which are removed with opened ports? ISTM that they will keep those ports open, but I am also unfamiliar with the code
[14:40] <TheMue> fwereade: In global mode ports will be closed after the final unit using this port.
[14:40] <TheMue> fwereade: Otherwise directly.
[14:41] <Aram> fwereade: I think it's fine, removal of a unit event makes fw call flush machine which calls flushGLobalPorts and does the refcound decrement
[14:42] <TheMue> fwereade: If you change it to dying the firewaller gets notified by the watcher.
[14:42] <fwereade> Aram, ah! forgetUnit
[14:42] <fwereade> TheMue, thanks
[14:42] <TheMue> fwereade: yw
[14:42] <fwereade> TheMue, wait, when what becomes Dying?
[14:42] <fwereade> TheMue, do we do something when the unit becomes Dying?
[14:43] <Aram> TheMue: take a look at this, maybe you see an obvious flaw with it: https://codereview.appspot.com/6820112
[14:43] <TheMue> fwereade: I would have to look more exactly.
[14:43] <Aram> I'm not sure that the failure I see is due to my code, but rather to just enabling a race, but maybe my code sucks.
[14:44] <TheMue> fwereade: Will look at Arams review before.
[14:44] <fwereade> TheMue, I just didn't unerstand what you meant by:
 fwereade: If you change it to dying...
[14:44] <TheMue> fwereade: Please later, I'm not working concurrent
[14:45] <fwereade> TheMue, ok, I would appreciate a clarification when you have a mo :)
[14:45] <TheMue> fwereade: Yep, will do afterwards.
[14:45] <fwereade> TheMue, cheers
[14:46] <TheMue> fwereade: Have to look the exact flow in the code
[14:46] <fwereade> TheMue, I just want to know what you meant by "it" in "setit to dying" above... I don't think you need to look at the code...
[14:48] <TheMue> fwereade: Has just been a quick rememberance. The important part is that the watchers notify the fw and the fw combines these changes to get aware which ports it has to open/close.
[15:07] <TheMue> Aram: Hmm, so far it looks good. The loops over the removed and added units are almost the same, only that you now have a list with names and a list with units. But I'll again check the part above.
[15:08] <TheMue> Aram: The retrieval of the lifecycle state is now somewhat strange. Shall it be changed this way everywhere? I liked the fact that the watchers emit changes according to the state.
[15:08] <Aram> TheMue: could you be more specific or rephrased that? I don't understand what you mean.
[15:11] <TheMue> Aram: Sure, so far the change itself contained Added and Removed. Now you get all changes and have to check the state on you own. That looks strange.
[15:11] <Aram> TheMue: well that's how the new style watchers are now.
[15:11] <TheMue> Aram: I liked the old way, or a return of Alive, Dying, Dead to be more close to the states.
[15:11] <Aram> eventually, all old style watcher will be like this.
[15:12] <Aram> we took the decision of doing it this way at Lisbon.
[15:12] <TheMue> Aram: OK, then I think it's well discussed. Forget my question.
[15:14] <fwereade> TheMue, I'm looking at the firewaller again
[15:14] <TheMue> fwereade: Feel free
[15:14] <fwereade> TheMue, in the watch loops for unitData and serviceData, you defer watcher.Stop()
[15:15] <fwereade> TheMue, is that intentional
[15:15] <fwereade> ?
[15:15] <fwereade> TheMue, ie, doing so swallows errors, but I can see a fuzzy justification for why we might want to
[15:16] <Aram> TheMue: so you don't see anything egregious about my code?
[15:16] <fwereade> TheMue, but I need help clarifying what it is and whetherit exists ;)
[15:16] <TheMue> Aram: So far not, it looks fine to me.
[15:16] <Aram> hmm.
[15:17] <TheMue> fwereade: Sorry, here I have to go into history when they wen in. Since the earliest steps the fw has had several changes.
[15:17] <fwereade> TheMue, sure, this is pretty tightly focused though
[15:17] <Aram> I think that there's a race in the firwaller, and my code helped bring it to the surface, but the actual fault is in the firewaller, not my code.
[15:17] <fwereade> TheMue, why do we ignore errors in sd.watcher and ud.watcher?
[15:18] <Aram> TheMue: btw, if I change the MachineUnitsWatcher to report everything, not only lifecycle changes, this test passes.
[15:18] <TheMue> fwereade: Please one after the other.
[15:19] <fwereade> TheMue, I asked the same question in two different ways, I thought
[15:19] <TheMue> And btw, lunchtime. Today later, daughter came just back.
[15:20] <fwereade> TheMue, ok, I'll see what happens if I get stricter :0
[15:40] <fwereade> rogpeppe, Aram, TheMue: I have to go early today, but before I do... I just proposed https://codereview.appspot.com/6811091 ...
[15:41] <fwereade> which makes service and unit watchers just return ids instead of entities
[15:41] <fwereade> but I now want to go a step further, and cause machine/unit/service watchers to just send `struct {}{}`
[15:41] <Aram> fwereade: heh, I already did that as well.
[15:42] <fwereade> rationale is that whoever started the watch should damn well know what enitity they mean
[15:42] <Aram> I might have even proposed it about two weeks ago.
[15:42] <Aram> but gustavo didn't like a prereq
[15:42] <fwereade> Aram, crap, sorry, I never saw that
[15:42] <Aram> so he didn't even look over it
[15:42] <fwereade> Aram, ah hell
[15:42] <Aram> and never went in
[15:42] <Aram> anyway
[15:56] <rogpeppe> fwereade: i totally agree, but i've said that a few times to gustavo and had no agreement
[15:56] <TheMue> back
[15:57] <fwereade> rogpeppe, hum, ok -- the issue is that it lets me dodge the damn-stupid-in-hindsight difference in type between unit and machine
[15:58] <fwereade> sorry, unit and machine *ids*
[15:58] <rogpeppe> fwereade: i agree
[15:58] <Aram> fwereade: rogpeppe: one benefit of returning id is that a collection watcher can literally be constructed from N individual watchers muzed together on the same channel.
[15:58] <Aram> s/muzed/muxed/
[15:58] <Aram> not that we do that, just saying.
[15:58] <rogpeppe> Aram: that would be an issue if you passed a channel into a watcher
[15:58] <rogpeppe> Aram: as it is, it's not AFAICS
[15:59] <rogpeppe> fwereade: if you can demonstrate a nice use case for struct{}, i think it would probably be fine
[15:59] <Aram> TheMue: I think I know what the race is.
[15:59]  * TheMue listens
[15:59] <Aram> TheMue: individual machine and unit watchers are started as soon as possible, rather than waiting for the fw to finish reading the environment.
[15:59] <fwereade> rogpeppe, I think the putative deployer makes a nice one
[15:59] <rogpeppe> fwereade: agreed
[16:00] <fwereade> rogpeppe, but maybe for now I'll ponder less-controversial prereqs for doing so -- I should at least fix up MachinePrincipalUnitsWatcher
[16:00] <Aram> rogpeppe: yeah, we don't currently make use of that feature, and the benefit of having watchers return the same type outweighs the potential benefit of muxing watchers in the future.
[16:01] <fwereade> Aram, +1
[16:01] <Aram> fwereade: I have a fix for that as well
[16:01] <Aram> I'm just blocked on debugging this stupid thing
[16:01] <Aram> that's why is not up for review again
[16:01] <fwereade> Aram, ah ok! sorry, would you link me your branch for MPUW so I can see what I'll need to work with?
[16:03] <TheMue> Aram: IMHO not. loop() starts with initGlobalMode() before entering the watchers. But let me have a deeper look.
[16:04] <Aram> fwereade: well, this one: https://codereview.appspot.com/6718052/ but I'll have to work on it some more to use more of the machine units watcher that has changed in the meantime and the prereq is bad as well.
[16:05] <TheMue> Aram: Ah, no, WatchMachines() starts earlier, indeed.
[16:05] <Aram> TheMue: yes, you're right, the environment is read before, but the behavior suggests otherwise. I've put debug prints inside the unit watcher loop, and globalPortRef is not good
[16:05] <Aram> basically empty
[16:07] <Aram> meh
[16:07] <Aram> for whatever reason the unit loop doesn't run enought times.
[16:12] <TheMue> Aram: Maybe the separation in added and removed should be done inside the unitd to avoid receiving from the watcher the next time. The slices of added and removed can then be sent to the main loop as before.
[16:13] <Aram> TheMue: what do you mean?
[16:14] <TheMue> Aram: I'm jist thinking loud, but I'm thinking it will show no effect. :|
[16:14] <TheMue> Aram: It's the new new loop where you initially check if a units is added or removed before you later iterate over those slices to process the units like before.
[16:15] <Aram> TheMue: you want to do it in a single loop?
[16:15] <Aram> why do you think it should make a difference?
[16:16] <TheMue> Aram: No. During this "pre-processing" the unitd can receive the next change, maybe here's the race. So a solution can be to move the pre-processing into the unitd and then send the separated slices to the main loop.
[16:17] <TheMue> Aram: But that's only guessing.
[16:17] <Aram> TheMue: I don't know whay you mean by 'unitd'?
[16:17] <Aram> s/whay/what/
[16:17] <Aram> what is unitd?
[16:18] <TheMue> unitData
[16:18] <TheMue> They are managed as fw.unitds[]
[16:20] <Aram> but unitDatas are created inside the for _, unit := range added { by newUnitData, aren't they?
[16:20] <Aram> so they don't even exist in the preprocessing step\
[16:21] <TheMue> Aram: Yes, those both loops (removed, added) can stay in the fw.loop(), as before. Only the first loop that's new now..
[16:22] <Aram> TheMue: I don't understand what difference that makes, but maybe I am missing something basic.
[16:22] <Aram> oh
[16:22] <Aram> hmm
[16:22] <Aram> no
[16:22] <Aram> I don't see it :).
[16:23] <Aram> I mean that function is called synchronously, as if the code was pasted there.
[16:23] <TheMue> Aram: Yes, you're right. *sigh*
[16:24] <Aram> TheMue: on the other hand you might be right about the race, when that function is executing, more events could be queued for the watcher, and the fw would call that function again with the same units.
[16:24] <Aram> not sure what difference that makes though.
[16:24] <TheMue> Aram: Could be worth a test.
[16:36] <Aram> TheMue: inlining that and doing it all in a single loop, without a preprocessing step, made no difference.
[16:36] <TheMue> Aram: Sh...
[16:42] <Aram> TheMue: I'm out of ideas to try.
[16:47] <Aram> TheMue: the fact that it works if you don't restart the watcher suggests there's something wrong with watcher initialization.
[16:52] <TheMue> Aram: Don't know. It worked so far. So the change seems to effect a different behavior inside the fw.
[16:59] <Aram> TheMue: what about var ports []state.Port inside func (ud *unitData) watchLoop() {?
[16:59] <Aram> this wil start fresh, from nil when watcher is restarted
[16:59] <Aram> but that function compares the new ports with old ports each run
[17:00] <Aram> so it will compare with nil when a watcher is started
[17:00] <Aram> so it won't ever close ports
[17:00] <Aram> yeah
[17:00] <Aram> that's it.
[17:00] <Aram> it compares nil to 80, and can't realize it needs to close 8080
[17:01] <Aram> TheMue: does that make sense?
[17:02] <TheMue> Aram: Sounds good, I'm only wondering why it worked before.
[17:04] <TheMue> Aram: I'll go into the history there tomorrow to get  a feeling.
[17:04] <Aram> TheMue: because the watcher delivered units as they were at that point, so you'd get one even with 80, 8080 and one with 80, but now you have to load the unit manually, and when you load it it's already only 80
[17:04]  * TheMue leaves now, I've got a cold and almost had no sleep last night.
[17:05] <TheMue> Aram: Ah, that sounds reasonable.
[17:05] <Aram> TheMue: have a nice evening
[17:05] <TheMue> Aram: Thx, cu tomorrow
[17:05] <TheMue> Aram: And have a nice evening too


[08:49] <cjwatson> would anyone like to have a look at bug 743163?  iulian said "1:4.2-1 looks good to me but I wouldn't mind if someone else takes another quick look at it, just to be sure that I haven't missed something important"
[08:50] <ubot4> Launchpad bug 743163 in squashfs-tools (Ubuntu) "FFe: Sync squashfs-tools 1:4.2-1 (main) from Debian unstable (main) (affects: 1) (dups: 1) (heat: 506)" [Wishlist,New] https://launchpad.net/bugs/743163
[15:22] <ogra_> lamont`, regular weekly acorn ping ... (it died again over the weekend)
[15:34] <mvo> skaet, slangasek: there is a (straightforward) patch to add basic multiarch support into python-apt in debian that I would like to merge. its a bugfix in a lot of ways, but just to be sure I would like to ask here if its ok or if you need a formal FFe?
[15:44] <skaet> mvo, you're sure no side effects?
[15:47] <ScottK> I'd suggest it's better to get it in sooner and find out for sure.
[15:47] <ScottK> mvo: You'll also want the python3 build fix too (not sure if you're syncing or cherrypicking).
[15:51] <mvo> ScottK: yeah, that one should be in as well
[15:53] <mvo> skaet: reasonable sure, I'm a developer for long enough to never say never, but any side effects would be bugs and currently with multiarch enabled, python-apt (and the support scripts that use it) fall over badly
[15:53] <mvo> but if there are concerns I'm fine doing a FFE
[15:54] <skaet> mvo,  then go ahead - if its primarily a bug fix.   I agree with ScottK,  soon rather than later is better right now.
[16:05] <mvo> thanks! I do it after the call
[16:05] <mvo> (in a call now)
[16:07] <micahg> skaet: good morning, I was wondering, were you going to send out an E-Mail for hardy desktop EOL?
[16:09] <skaet> micahg, yup, its on the to do list.  Decided not to send it out last week,  so it doesn't need to happen simultaneously with Karmic's EOL.
[16:10] <skaet> expect it to come out this week,  just doing a couple more checks.
[16:11] <micahg> ok, thanks, also, does UIF apply to unseeded packages?  (I wanted to get kdiff3 into a proper menu)
[16:13] <skaet> ScottK,  ^^ what's usual and customary here.   (am thinking that since its unseeded,  docs and translations aren't affected, but .... )
[16:13] <ScottK> IIRC it doesn't.
[16:14] <ScottK> However if it's a new feature, FF still applys.
[16:14] <micahg> ok, thanks
[16:30] <joshuahoover> skaet: can we get someone to approve bug #733327 for as a ui ffe?
[16:30] <ubot4> Launchpad bug 733327 in libubuntuone (Ubuntu) (and 1 other project) "[UI FFE] Notify user of missing MP3 support (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/733327
[16:31]  * skaet looking
[16:32] <joshuahoover> thanks
[16:33] <skaet> joshuahoover, why did you make the importance of it undecided?
[16:34] <skaet> and did anyone respond with issues to your post to ubuntu-docs, and ubuntu-translators?
[16:34] <joshuahoover> skaet: oops, forgot to mark the importance to high there
[16:36] <joshuahoover> skaet: we heard back from dbm giving it a +1
[16:39] <skaet> joshuahoover,  ok,  lets get it in - will be good to have it fixed.    I've marked it approved.
[16:39] <joshuahoover> skaet: thank you!
[17:24] <skaet> cjwatson, pitti,   looks like I'm able to disable milestones now - :)   (11.04 beta 1 now disabled)
[17:25] <skaet> am moving over the beta 1 opens to beta 2 now
[19:08] <lamont> rolling outage in the buildds for a new launchpad-buildd  (as discussed last week)
[20:38] <slangasek> what's the state of the art for scanning the archive for particular strings/patterns in code?
[20:44] <slangasek> (trying to evaluate the risk of bug #750585 before proposing it as an FFe)
[20:44] <ubot4> Launchpad bug 750585 in linux (Ubuntu) "support for making linux-libc-dev coinstallable under multiarch (affects: 1) (heat: 8)" [Wishlist,New] https://launchpad.net/bugs/750585


[20:12] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3797 Generating diffs
[20:12] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3797 Successfully built
[21:18] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3797 Proposed pocket (eoan/glibc). Successfully built (eoan/systemd)
[22:17] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3797 Pending binary packages (eoan/systemd). Proposed pocket (eoan/glibc)
[22:21] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3797 Generating diffs
[22:22] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3797 Preparing packages
[22:38] -queuebot:#ubuntu-ci-eng- rbalint, https://bileto.ubuntu.com/#/ticket/3797 Proposed pocket (eoan/glibc). Successfully built (eoan/systemd)


[19:15] <Eickmeyer> OvenWerk1: That's great news! I might be able to repackage it for II, but it's quite late for Hirsute.