[00:46] <huwshimi> I really, really, really, really wish we had an A/B testing framework in Launchpad
[00:48] <rick_h_> heh, do we have the metrics to be able to put A/B testing to use?
[00:49] <huwshimi> rick_h_: That's what I mean
[00:50] <huwshimi> we have feature flags that could be used to set up the A and B, but we need random user assignment and result reporting to make it useful
[00:51] <rick_h_> yea, it's a tough product to define what metric we'd want for each A/B case
[00:52] <rick_h_> what's the current use case?
[00:52]  * rick_h_ is bored and curious
[00:54] <huwshimi> rick_h_: A proper a/b testing framework allows you to hook in tests for results. The test could be "number of people who get to a certain page" or "number of people who click a link" etc.
[00:56] <rick_h_> huwshimi: yea, but LP is so different depending on who visits/use case that it's a bit fun to think of what would be better
[00:57] <huwshimi> rick_h_: Isn't that the point of doing an A/B test?
[01:00] <huwshimi> poolie: Could the feature flags system be modified so that instead of showing to a group it could pick users at random?
[01:00] <poolie> sure could
[01:01] <poolie> i would like that very much
[01:01] <poolie> there is a bug asking for it
[01:01] <huwshimi> poolie: Ooh
[01:01] <poolie> i am happy to either help or to be bribed/distracted in to doing it
[01:01] <poolie> but i need to go out and do some trip prep stuff so probably not today
[01:03] <huwshimi> poolie: Wow, ok, this makes getting an A/B testing framework possible. It would be farily easy to write the javascript data collection side of things
[01:04] <poolie> the other thing we need is to log it somehow
[01:04] <poolie> either from the http server or something else
[01:04] <poolie> maybe js
[01:04] <huwshimi> poolie: Yes, there would need to be an AJAX call to log the resaults
[01:05] <huwshimi> *results
[01:25] <huwshimi> rick_h_: Are you still around?
[01:25] <huwshimi> rick_h_: If you are, I have a conflict when I merge your changes for the loading notification. Any ideas? http://paste.ubuntu.com/754337/
[01:26] <rick_h_> huwshimi: looking
[01:26] <huwshimi> rick_h_: Cheers
[01:27] <rick_h_> huwshimi: bah, yea I moved a couple things that it's not liking, sec
[01:27] <huwshimi> np
[01:28] <rick_h_> huwshimi: http://paste.mitechie.com/show/455/ is what it should be. That's merged with rocketfuel-get this evening so should be up to date
[01:29] <huwshimi> rick_h_: Cheers :)
[01:30] <huwshimi> rick_h_: Hmm... I lose the order/config bar completely
[01:30] <rick_h_> huwshimi: make sure that your css combo script in bin gets updated.
[01:31] <rick_h_> huwshimi: yea, make sure the css combo script is updated and you've got "indicator" css in the combo
[01:31] <huwshimi> ah I see
[01:34] <huwshimi> hmmmm....
[01:37] <huwshimi> rick_h_: Still nothing
[01:37] <huwshimi> rick_h_: The indicator css is there and working
[01:37] <rick_h_> huwshimi: any hints?
[01:37] <huwshimi> rick_h_: But still no order bar
[01:38] <huwshimi> rick_h_: The order bar div is completely empty
[01:38] <huwshimi> oh wait, I have js errors
[01:38] <StevenK> poolie: I'm a little unsure about the branch you've put up
[01:38] <rick_h_> huwshimi: ok, cool. Maybe typo in cleaning up the merge?
[01:38] <StevenK> poolie: It looks mostly UI related, so I'd prefer huwshimi look it over.
[01:40] <poolie> StevenK, ok with me, huwshimi do you mind?
[01:40] <poolie> he reviewed the predecessor anyhow
[01:40] <poolie> btw i'm happy to say google is now apparently enjoying the results of the microformat work
[01:40] <huwshimi> poolie: Sure, mind linking me to the mp?
[01:41] <StevenK> huwshimi: https://code.launchpad.net/~mbp/launchpad/888353-microformats-2/+merge/83856
[01:41] <huwshimi> StevenK: Thanks
[01:41] <huwshimi> I'll take a look soon
[01:42] <poolie> thanks
[01:42] <poolie> ok i'm out for a bit, see you later
[01:44] <huwshimi> rick_h_: on this line "this.set('model', new namespace.BugListingModel({" it says undefined is not a function""
[01:44] <rick_h_> huwshimi: in chrome?
[01:45] <huwshimi> rick_h_: yea
[01:45] <rick_h_> try on firefox in case you're hitting the chrome issue
[01:45] <rick_h_> there's a known chrome issue that is in progress of rollback/fix
[01:45] <rick_h_> unrelated to the spinner
[01:46] <rick_h_> but BugListingModel is defined in line 37, and this sholdn't be undefined, so not sure what it's not liking there
[01:48] <huwshimi> rick_h_: Firefox says: "namespace.BugListingModel is not a constructor"
[01:49] <rick_h_> huwshimi: can you pastebin your whole file then? Something is up. It's defined back in 52
[01:49] <rick_h_> huwshimi: http://paste.mitechie.com/show/456/ if you want to rnu diff locally
[01:51] <huwshimi> rick_h_: Oh, something's very wrong with my file. It's about 70 lines shorter :)
[01:51] <rick_h_> huwshimi: ah ok. Yea, that'll do it
[01:51] <huwshimi> oh, there we go.
[01:51] <huwshimi> rick_h_: just pasted over your new file and it works now. Thanks :)
[01:51] <rick_h_> huwshimi: re-pushing my branch is case I missed somehting
[01:52] <rick_h_> huwshimi: ah ok
[01:53] <huwshimi> rick_h_: Thanks, I might grab your new branch. This is still not working for me.
[01:53] <huwshimi> (in other ways now)
[01:53] <rick_h_> huwshimi: ok, yea should just be able to  bzr branch bzr+ssh://bazaar.launchpad.net/~rharding/launchpad/buglists-loading-885272/
[01:54] <rick_h_> into your lp-branches dir, update the links, and then make run
[01:55] <huwshimi> rick_h_: Have you just remerged the branch with devel?
[01:55] <rick_h_> huwshimi: sec I will
[01:55] <rick_h_> did it this afternoon, but will redo a rocketfuel-get on it and repush
[01:55] <huwshimi> cheers
[01:56]  * rick_h_ is still figuring out how best to work around stuff
[01:56] <StevenK> rick_h_: rf-get in your devel branch, and then bzr merge ../devel in your other branch
[01:57] <rick_h_> huwshimi: ok, updated and pushed
[01:57] <huwshimi> rick_h_: Cheers mate
[01:57] <rick_h_> StevenK: ok, I've been doing some rf-get right in my branch itself, bad side effects?
[01:59] <StevenK> rick_h_: I'm not sure -- that ^ is how I work
[01:59] <rick_h_> StevenK: ok cool, thanks
[02:05] <huwshimi> rick_h_: You did push the changes? It might just be taking a whiel
[02:06] <huwshimi> *while
[02:06] <rick_h_> huwshimi: yes, I pushed but "No new revisions or tags to push."
[02:06] <rick_h_> so shouldn't be anything new there if you're waiting for new files
[02:07] <huwshimi> rick_h_: And you did an update of devel (or rocketfuel-get) before you merged devel with your branch?
[02:08] <huwshimi> rick_h_: Only checking cause when I merge your changes with a fresh branch I get a conflict
[02:08] <rick_h_> huwshimi: yes, on rev 14404
[02:08] <StevenK> jtv: O hai! https://code.launchpad.net/~stevenk/launchpad/death-to-lazr-testing-tales/+merge/83889
[02:08] <jtv> hi
[02:09] <jtv> Does that come with coffee?
[02:09] <StevenK> Pft, it's +1/-19, like it needs any
[02:09] <jtv> I don't care what it needs.  It's what I need that counts.
[02:09] <rick_h_> huwshimi: ah, sec
[02:11] <wgrant> lifeless: As long as we link to the final page.
[02:11] <wgrant> I guess.
[02:11] <wgrant> We probably need to redirect.
[02:13] <lifeless> wgrant: ECONTEXT
[02:13] <wgrant> ML archives.
[02:13] <wgrant> We can't just show the oldest message by default.
[02:13] <StevenK> jtv: Haha
[02:13] <wgrant> We would have to default to the last page.
[02:13] <lifeless> we can show the list of indices.
[02:14] <jtv> StevenK: it's not funny.
[02:14] <wgrant> lifeless: Hm?
[02:14] <lifeless> like $every $other $mhonarc $site $out $there
[02:14] <wgrant> That's no argument.
[02:14] <rick_h_> StevenK: what make do I need to do db updates?
[02:14] <wgrant> mhonarc is pretty terrible. Basing arguments on what its other users do is illy.
[02:14] <wgrant> s
[02:14] <lifeless> its other users are using it as it was intended
[02:15] <lifeless> I notice now that we don't have monthly groupings
[02:15] <rick_h_> huwshimi: looks like I'm learning new stuff. rocketfuel-get only updates devel, no matter if it's run from another branch. So merging and resolving now
[02:15] <lifeless> so its all messages ever that get reindexed
[02:15] <StevenK> rick_h_: To get them rolled out, or to make them?
[02:15] <lifeless> wgrant: so most static archiver sites have a page that says
[02:15] <lifeless> 'jan 2001'
[02:15] <rick_h_> roll out to my local db, I've gotten changes from devel and getting missing column oops
[02:15] <lifeless> 'feb 2001'
[02:15] <lifeless> etc
[02:16] <rick_h_> StevenK: ^^ sorry
[02:16] <lifeless> I'm proposing we in the interim, link to that
[02:16] <StevenK> rick_h_: Oh, 'make schema'
[02:16] <rick_h_> StevenK: ty
[02:17] <huwshimi> rick_h_: Ah, yes it does. Sometimes you'll get pqm errors if you have conflicts. If you have branches that have been hanging around for a while it's good to do a devel merge just to resolve any issues before you submit for testing
[02:17] <wgrant> lifeless: Well, we don't have such a page, but OK.
[02:17] <lifeless> wgrant: I'm fairly sure mhonarc knows how to make one
[02:18] <rick_h_> huwshimi: yea, and this was pulled from deryck's branch so no idea how old it is to start out
[02:18] <huwshimi> rick_h_: Yeah, that's where it gets hairy. You can always do a devel merge to be sure.
[02:20] <rick_h_> oh boo, reset my db so lost my feature flags
[02:21] <huwshimi> rick_h_: Don't you hate that :)
[02:22] <rick_h_> ok, wtf...all my code is gone now
[02:22] <rick_h_> bah, this is probably due ot the rollback or osmething arggg
[02:25] <wgrant> StevenK: Your sorting in the canonical.lazr branch is wrong.
[02:25] <wgrant> subunit, lazr, testools
[02:26] <rick_h_> huwshimi: ok, pushing changes, gets rid of the js error
[02:26] <rick_h_> working on getting records back in db so I can test the actual paging and such, but think that might do it
[02:28] <rick_h_> huwshimi: ok, tests that it works now
[02:43] <StevenK> wgrant: Oh sigh
[02:43] <StevenK> wgrant: Fixed.
[02:43] <huwshimi> rick_h_: perfect, all working now :)
[02:44] <rick_h_> huwshimi: awesome, thanks for your patience withme
[02:44] <huwshimi> rick_h_: No, no, all good!
[02:44] <StevenK> rick_h_: Write a script to populate the db.
[02:44] <StevenK> rick_h_: Or 'make iharness' at a pinch
[02:44] <rick_h_> StevenK: yea, on my todo
[02:44] <rick_h_> haven't peeked at the db much yet
[02:45] <StevenK> Don't look too close, your eyes will bleed.
[02:45] <rick_h_> StevenK: was actually thinking I need to look at the api and see if I can script stuff using that instead
[02:45] <rick_h_> StevenK: heh yea, most dbs, and with this one being a bit old, I bet there's some scary in there
[02:46] <StevenK> rick_h_: So if you're populating objects to test and play, I'd suggest you just write a script that makes use of LaunchpadObjectFactory.
[02:47] <huwshimi> rick_h_: Just going to eat some lunch and then send through some feedback for you
[02:47] <StevenK> rick_h_: For example, I want a product, I don't care what it is: product = factory.makeProduct()
[02:47] <rick_h_> StevenK: ok cool, will look it up, taking notes
[02:48] <StevenK> rick_h_: LaunchpadObjectFactory is what is used in tests when you see self.factory...
[02:49] <rick_h_> ah makes sense, I've really only done much on the JS side of things so far.
[02:49] <StevenK> Haha, I've tried to stay away from the JS side of things.
[03:06] <wallyworld_> lifeless: we show private teams in the bug subscriptions portal (it used to oops but now fixed). but we explicitly filter out private teams from the branch subscription portal. should we be consistent here?
[03:06] <wallyworld_> nb we filterout private teams the user cannot see
[03:07] <wallyworld_> but we now have a mechanism for rendering private teams even if the user cannot see them
[03:08] <lifeless> so, AIUI the new rules we are saying that subscribing to an object discloses the team
[03:09] <lifeless> so yes, they should be shown; OTOH have we fixed up any erroneous (e.g. to public branches) subscriptions of private teams yet
[03:10] <wallyworld_> no, not afaik
[03:12] <lifeless> we probably want to address that before making the teams visible to any viewer of public artifacts
[03:14] <wallyworld_> i'd have to check - do we allow public bugs to have private subscribers?
[03:14] <wgrant> lalalalala
[03:15] <wallyworld_> since if we do allow it for public bugs, shouldn't we allow it for public branches also?
[03:15] <lifeless> I think wgrant means 'we have not implemented the UI/business rules around this area, nor around that of handlings privacy transitions of objects
[03:16] <wgrant> s/implemented/devised/
[03:16] <wallyworld_> so, what's the damage in allowing a viewer of a public branch to see that a private team is subscribed to the branch?
[03:17] <lifeless> there is none; as long as the private team was told they would disclose their existence
[03:17] <wallyworld_> sure. that's how it is now for bugs
[03:17] <wallyworld_> with the recent changes
[03:19] <wallyworld_> lifeless:  if we want to not expose any private subscribers, then i should stop work on this branch entirely, since we will be exposing the existence of private branch owners, reviewers, committers also
[03:20] <lifeless> wallyworld_: well we do, subject to the previously discussed caveats
[03:20] <lifeless> wallyworld_: which is that if someone doesn't want to be disclosed, they can't interact with the branch
[03:21] <wallyworld_> yes. that point never came up though in our standup when my work on this branch was discussed
[03:21] <lifeless> we probably need to refine the definition of interact too, to acknowledge that there are subscribers we don't know about (as anyone we notify could be a multiplier), and anyone that can see a page can poll it
[03:22] <lifeless> I will nab sinzui tomorrow about that
[03:22] <wallyworld_> so i guess i can complete the work andbefore landing we may need to do some other work
[03:22] <lifeless> you can just ff it perhaps
[03:23] <wallyworld_> could do, but it's already out there for bugs
[03:23] <wallyworld_> we just went ahead and deployed it
[03:24] <lifeless> heh
[03:24] <wallyworld_> not sure if any private teams have complained or noticed
[03:24] <lifeless> you probably want to check with sinzui
[03:24] <lifeless> I'm not in any position to second guess him - I haven't been tracking the detail on how you've been approaching this
[03:24] <wallyworld_> i sort of thought the policy was that it is now ok to expose a team's name / existence
[03:25] <wallyworld_> i'll check tomorrow
[03:25] <lifeless> my understanding is that we settled on 'when the team interacts with something' and 'team interactions will prompt to permit the interaction'
[03:25] <lifeless> its the second bit I suspect is missing
[03:25] <wallyworld_> yes
[03:26] <wgrant> The second bit requires an API break.
[03:26] <wgrant> In dozens of places.
[03:27] <wallyworld_> maybe we decided against it then. i can't recall
[03:27] <lifeless> I'd worry a little if we had
[03:28] <lifeless> because we have a number of policies intended to prevent accidental discovery of private team names
[03:28] <lifeless> and not doing the second bit will deeply devalue them
[03:28] <wallyworld_> my memory is fuzzy, so i'm not sure one way or the other
[03:29] <wgrant> I thought we were going to skip that, because of the enormous and ever-expanding scope creep it would entail.
[03:29] <wgrant> Given recent happenings, I don't think we need any more of that...
[03:29] <wallyworld_> i seem to recall that the discussion was that private team names could be exposed
[03:29] <wallyworld_> and that people would have to given them cryptic names
[03:29] <wallyworld_> if they didn;t want others to guess things
[03:34] <lifeless> noone told me :)
[03:35] <wgrant> We don't have a compelling, pretty, feasible private team design.
[03:35] <wgrant> We no longer have a compelling, pretty, feasible private artifact design.
[03:36] <wallyworld_> lifeless: perhaps we can all have a chat with sinzui tomorrow to clear it up. in case i/we have misunderstood anything
[03:38] <lifeless> sure
[03:38] <lifeless> I'm here all week :P
[03:38] <wgrant> Wait a sec.
[03:38] <wgrant> It's Wednesday.
[03:38] <wgrant> Why *are* you here?
[03:38] <lifeless> lynne told me off for frittering leave away :P
[03:38] <wgrant> Heh
[03:39] <wallyworld_> but you're here when you are on leave too
[03:41] <StevenK> wallyworld_: Multiple people have told lifeless at one time or another that he sucks at leave.
[03:42] <wallyworld_> i just think he is so attached to his nick that he would hate to not live up to it
[03:48] <lifeless> other way around
[03:48] <lifeless> the nick has to live up to me
[03:49]  * wallyworld_ wonders if lifeless is the chicken or the egg
[03:51] <StevenK> I can't use = to compare dates in postgres?
[03:51] <StevenK> (I don't care about the time)
[03:53] <lifeless> you can, but you'll need to cast to date first
[03:55] <StevenK> WHERE datecreated = '2011-11-30'::date; == 0 rows
[03:56] <StevenK> But max(datecreated) shows 2011-11-30
[03:56] <lifeless> datecreated isn't a date
[03:56] <lifeless> WHERE datecreated::date == '2011-11-30';
[03:56] <StevenK> Ah
[03:56] <lifeless> or (for more efficiently
[03:57] <lifeless> WHERE datecreated BETWEEN 2011-11-30 00:00 and 2011-11-30 23:59:59.99
[03:57] <lifeless> or something
[03:58] <StevenK> lifeless: I added a few things into the db using the factory and iharness and forgot to grab their names -- I just wanted the quickest way to grab the details
[03:59] <StevenK> Hm. members=[foo] has invited them
[04:02]  * StevenK wishes alert worked better with zsh
[04:20] <lifeless> so
[04:21] <lifeless> lazr_dbschema or lazr_postgresql ?
[04:21] <StevenK> The former
[04:21] <lifeless> or lazr_slony
[04:21] <StevenK> With a ., I hope
[04:21] <lifeless> nooo
[04:22] <lifeless> epic pain and suffering apply to namespaces
[04:22] <StevenK> lazr.restful, lazr.restfulclient ?
[04:22] <lifeless> terrible
[04:22] <lifeless> bugs open for years about import issues in their debs
[04:22] <lifeless> heinous tree layout to boot
[04:22] <StevenK> The _ offends me
[04:22] <StevenK> But fair point
[04:23] <rick_h_> it could be worse lazrPostgreSQL
[04:26] <StevenK> rick_h_: Don't make me send you to bed with no dinner.
[04:26] <rick_h_> heh, too late, had dinner, but I should go to bed
[04:27] <wgrant> lazr.restful* aren't as problematic as lazr.uri.
[04:27] <wgrant> But they're still not good.
[04:27] <StevenK> Sigh, 31degC makes me sad.
[04:27] <micahg> StevenK: beats 33degF
[04:27] <wgrant> Heh, it's like 14 down here.
[04:28] <wgrant> micahg: Cold is easy to solve. Heat is not.
[04:28] <StevenK> micahg: I'll take it
[04:28] <wgrant> while cold: apply clothing
[04:28] <wgrant> while hot: raise ImMelting()
[04:29]  * micahg has this magical thing called A/C
[04:29] <StevenK> Haha
[04:29] <StevenK> No A/C here, and no option for it.
[04:29] <rick_h_> what?!
[04:29] <StevenK> Rented apartment
[04:30] <rick_h_> A/C is why I went to college and got a good job. So i can just keep that running all summer and manage to pay the bill
[04:31] <jtv> StevenK: it's a bit over 32°C here, but turns out a fan helps.
[04:32] <jtv> Maybe that's just because it's winter here, but it feels nice & cool.
[04:33] <lifeless> jtv: you're in europe atm ?
[04:33] <jtv> Nope.
[04:34] <lifeless> ah, 'winter'
[04:34] <jtv> You caught me.  We don't _really_ have winter here.
[04:34] <StevenK> Australia has summer and lack-of-summer.
[04:35] <jtv> That's what I thought, until an Australian friend moved back there and emailed me a map, making me guess where he lived.
[04:36] <jtv> Thinking it was always hot in Australia, I said "what maniac called that place Sunnyvale?"
[04:36] <jtv> The answer: wow, you guessed our location!  We don't understand the name either — it's never sunny here.
[04:42] <spm> StevenK: one of my Uncles was in Mt Hagen in PNG for many many years. He said they had two seasons. The Wet Season, and the Wetter Season.
[04:43] <StevenK> Haha
[04:43] <spm> and canberra has all four seasons. so nyah.
[04:44] <huwshimi> spm: What, all the way from grey to misty?
[04:45] <spm> huwshimi: um. no. that's melbourne. you don't get grey and misty on 600mm average rainful.
[04:46] <huwshimi> spm: My first experience of Canberra involved not seeing the sun the whole time I was there.
[04:46] <spm> gees. my inlaws in mackay had one 24 hour period that copped more rain then we get in an average year.
[04:46] <huwshimi> spm: granted, it was only  a little over 24 hours :)
[04:47] <spm> huwshimi: heh, very unlucky then. a rubbish day here is when you can actually see a cloud in the sky. :-)
[04:47] <huwshimi> overnight bus, get in a 6am, misty, all day, misty, practice, misty, play gig at night, still misty, bus out at 4am
[04:47] <spm> ah yes. winter fogs. they can be special.
[04:48] <StevenK> spm: At $LAST_JOB, we found a part of southern NT that recieved 3000mm of rain.
[04:48] <StevenK> In 48 hours.
[04:48] <spm> although, the year before I moved here. they had a running joke. What do you call the day after two days of rain? Monday. Apparently it rained 12+ consecutive weekends.
[04:49] <spm> Ha!
[04:49] <spm> Tully would be the good one to check. in FNQ.
[04:49] <StevenK> A lake formed.
[05:19] <StevenK> PrivatePersonLinkageError: Cannot link person (name=team-name-100003, visibility=PRIVATE) to <TeamMembership at 0xfeb68d0> (name=None)
[05:19] <StevenK> ... so we can't have private subteams?
[05:19] <wgrant> Correct. That would make the team's membership opaque.
[05:20] <wgrant> In the current rules, the owner might not even be permitted to see that the member existed.
[05:20] <StevenK> Right, so there is no point testing for the private subteam case in terms of MixedVisibility?
[05:20] <wgrant> Not until we define and implement new rules.
[05:22] <StevenK> So according to lifeless, private superteams should not be disclosed
[05:22] <wgrant> Right, they're not important.
[05:23] <lifeless> StevenK: depends on the viewer :) But yes, not automatically disclosed.
[05:23] <StevenK> So I'm confused, since that is the major cause of MixedVisibilityError
[05:23] <wgrant> Those need to be hidden.
[05:24] <wgrant> When we allow private subteams, they must be shown.
[05:24] <wgrant> There's no reason to show private superteams to everyone.
[05:24] <wgrant> That benefits nobody.
[05:24] <StevenK> Right, so I should fix Person:+index to only return private superteams if the user is a member of the subteam?
[05:25] <wgrant> If the user has permission to view the subteam.
[05:25] <wgrant> Er
[05:25] <wgrant> To view the superteam.
[05:25] <StevenK> I'm just worried that is expensive.
[05:25] <wgrant> Which membership in the subteam would convey.
[05:25] <wgrant> But it's not the only way.
[05:25] <wgrant> Howso?
[05:25] <lifeless> StevenK: try:except: around it
[05:25] <wgrant> It's already shown as <hidden> because we know they don't have access.
[05:25] <wgrant> So we know whether they have access or not.
[05:26] <StevenK> But that's the TALES formatter, we aren't filtering the list
[05:26] <wgrant> That's irrelevant.
[05:26] <wgrant> We have the information.
[05:26] <wgrant> So we can filter on it.
[05:26] <StevenK> I'm just questioning the cost of calling checkPermission on each superteam
[05:26] <wgrant> Clearly it's fine, because we already do it.
[05:27] <StevenK> Oh, it's just done in the formatter.
[05:27] <wgrant> Otherwise we wouldn't know to raise the soft oops.
[05:27] <StevenK> Duh
[05:27] <StevenK> Obviously, my brain is made out of silicon.
[05:31] <StevenK> Ewww, Person.select()
[05:44] <lifeless> argggh
[05:44] <lifeless> stuck ec2 instance
[05:44] <lifeless> 500dollar ec2 bill
[05:45] <nigelb> wow
[05:45] <StevenK> WIN
[05:45] <wgrant> ow
[05:45] <nigelb> Extra Large instance?
[05:45] <nigelb> Wait, how long was it stuck?
[05:45] <lifeless> $0.68 per High-CPU Extra Large Instance (c1.xlarge) instance-hour (or partial hour) 729 Hrs 495.72
[05:46] <nigelb> wait, it remained stuck for 729 hours?...
[05:46] <lifeless> apparently
[05:46] <StevenK> No, that can't be right
[05:46] <StevenK> Probably a few weeks, plus other usage
[05:46] <lifeless> a whole month, yes.
[05:46] <StevenK> Since a month is only 730 hours.
[05:46] <nigelb> Oh another note.
[05:47] <nigelb> If you use 1.5 hours, amazon chargse for 2 hours. (assuming the instance is killed after that)
[05:47] <lifeless> we setup the teardown after it sets up
[05:47] <lifeless> no, one instance, I'm pretty sure
[05:47] <lifeless> my net has been shite
[05:47] <StevenK> You don't use ec2 for anything else?
[05:47] <lifeless> so I suspect a ec2 instance was kicked off and never had the shutdown timeout called
[05:47] <lifeless> StevenK: no
[05:47] <StevenK> Ah
[05:47] <lifeless> StevenK: or rather, yes, I don't use it for anything else.
[05:48] <nigelb> Well, lessson learnt at least :)
[05:48] <StevenK> It is well known that lifeless' Internet is crap.
[05:48] <nigelb> Maybe someone should check how many instances are around at any time and when it was procurred.
[05:48] <lifeless> what lesson? don't use 'ec2 land' ?
[05:48] <nigelb> hah
[05:49] <nigelb> like a status page showing all currently running instances and when it was taken, should help track it down better.
[05:49] <StevenK> lifeless: rvb has a cronjob that checks ec2 ls
[05:49] <huwshimi> lifeless: Will stuck instances show up with 'ec2 list'
[05:49] <StevenK> nigelb: We have that, 'bin/ec2 ls'
[05:49] <lifeless> huwshimi: if you think to run it, yes
[05:49] <nigelb> ahh
[05:49] <wgrant> They show up in the numbers at the bottom.
[05:49] <huwshimi> lifeless: Haha, ok :)
[05:49] <wgrant> They don't necessarily show up in the list, however.
[05:49] <lifeless> I normally have a widget - aws-status - that shows all my instances
[05:49] <lifeless> however, it hasn't been updated to indicators
[05:50] <lifeless> so I don't have it anymore
[05:50] <nigelb> StevenK: heh, I got very excited and tried it out :P
[05:50] <nigelb> and realized I don't have access ;)
[05:51] <wgrant> You do have access :)
[05:51] <StevenK> I think you can have access, you just have to pay for it
[05:51] <nigelb> hah.
[05:52] <nigelb> Oh, you guys use your own accounts and then expense it?
[05:52] <wgrant> Yep
[05:52] <StevenK> Right
[05:53] <nigelb> AHHHH
[05:53] <nigelb> ok, that makes sense. I thoguht y'all were sharing one account.
[05:53] <StevenK> So if you run ec2 test twice a month it should cost you about $5.50
[05:53] <nigelb> (that's what we do at work)
[05:54] <nigelb> We have one account which is paid by corporate card and 3 of us get the keys to that
[06:08] <spm> o/ nigelb
[06:20] <nigelb> Hey spm :)
[06:50] <StevenK> lifeless: I can't find the mail again, but I find newest first for mailman to be *backward* from every other mailman instance I play with.
[06:56] <lifeless> I agree
[06:56] <lifeless> as wgrant says thats not a good reason to do/not do something
[06:56] <lifeless> but newest first is just terribly slow the way things are structured today
[06:57] <StevenK> lifeless: It just gives me pause to think when looking. Since it performs like a utter dog too, I say change it.
[07:03] <wgrant> Oldest-first would work if we didn't have a single archive for all-time.
[07:03] <wgrant> s/would work/might be acceptable/
[07:03] <StevenK> Right
[07:26] <huwshimi> So, how do we upgrade our version of cssutils?
[07:26] <huwshimi> The current version can't handle some css3 syntaxes
[07:27] <wgrant> We're currently using 0.9.66
[07:27] <wgrant> Er
[07:27] <wgrant> 0.9.6
[07:27] <wgrant> See versions.cfg
[07:28] <huwshimi> wgrant: Yup and there's a (stable) version 0.9.7 that supports what I need
[07:29] <wgrant> huwshimi: Grab a tarball, add it to download-cache alongside the old one, update versions.cfg.
[07:35] <huwshimi> wgrant: Where does our config look to grab stuff from?
[07:35] <huwshimi> wgrant: pypi?
[07:35] <wgrant> huwshimi: No, it doesn't look online. It looks in download-cache/dist
[07:36] <wgrant> You'll see lots of eggs and tarballs in there.
[07:36] <huwshimi> wgrant: Oh right, so I need to commit a new tarball?
[07:36] <wgrant> huwshimi: Right.
[07:36] <huwshimi> ah
[07:36] <wgrant> huwshimi: There's no PQM/reviews for that branch. You can commit/push directly.
[07:37] <huwshimi> wgrant: But I need to push the change to lp for the versions.cfg change though right?
[07:37] <wgrant> Right.
[07:42] <huwshimi> wgrant: Do I need to do anything else to make launchpad start using the new version?
[07:43] <huwshimi> wgrant: Do I need to get it to build a new egg or something
[07:43] <wgrant> huwshimi: No. buildout will automatically create the egg from the tarball once you update versions.cfg
[07:43] <huwshimi> wgrant: Oh, I guess I better run buildout :)
[07:43] <huwshimi> oops, thanks :)
[07:45] <wgrant> Ah, I see, yes.
[07:47] <huwshimi> Oh, I guess it would help if I changed the versions.cfg of the branch I was using too
[08:12] <huwshimi> Does anyone know how to enable the beta banner for a page locally?
[08:54] <mrevell> Hi
[09:07] <adeuring> good morning
[12:20] <gmb> Oh, hey, leaving a partial DB patch lying around will break things. Who'da thunk?
[12:23] <nigelb> stub: You might enjoy this - http://thedailywtf.com/Articles/Directive-595.aspx
[13:03] <rick_h_> morning
[14:24] <abentley> rick_h_: The updated spinner looks good to me.
[14:24] <rick_h_> abentley: ok cool, Since deryck is going to be here soon I'll want to sanity check with him and if that works then will submit for review/land
[14:24] <rick_h_> /want/wait
[14:25] <abentley> rick_h_: cool.
[14:25] <rick_h_> abentley: did you see the emails with huw from last night? Are we supposed to be jumping to the top of the page on next/prev?
[14:26] <abentley> rick_h_: Yes.  In an email today, I explained that deryck was going to do that, but I don't think it should be associated with the spinner, just updating the batch.
[14:27] <rick_h_> abentley: right, ok.
[14:35] <abentley> bac: would you consider re-reviewing https://code.launchpad.net/~abentley/launchpad/person-bug-listings/+merge/83860?  I've made an important change.
[14:36] <bac> abentley: ok
[14:36] <abentley> bac: Thanks.  The change is that the view_name is now provided by LP and used by the javascript.
[14:44] <bac> abentley: it looks good but i have to wonder if there isn't a better way to get the viewname?  i don't have any bright ideas but what you've done feels kludgy.
[14:46] <dobey> jelmer: were you going to add me to ~vcs-imports?
[14:47] <jelmer> hi dobey
[14:47] <jelmer> dobey: sorry, I hadn't understood that you actually wanted to be in ~vcs-imports. One sec, I'll add you.
[14:47] <abentley> bac: I don't know of a better way to get the view name.  I believe using getGlobalSiteManager().registeredAdapters() was gary_poster's suggestion.
[14:47] <dobey> jelmer: oh sorry. yes please. thanks :)
[14:47] <bac> abentley: ok
[14:47] <jelmer> dobey: welcome :)
[14:49] <bac> abentley: done.
[15:13] <benji> Hey guys, I'm working with the LOSAs to get a small DB permission change for a script to fix a critical regression; in an email stub said that I "need someone to manually apply the permissions to production" but neither I nor the LOSA know what exactly that means.  He asks if "running ./security.py wouldn't work?"  Hints?
[15:25] <deryck> abentley, adeuring -- standup in 4 ok?
[15:26] <abentley> deryck: sure.
[15:26] <adeuring> deryck: sure
[15:26] <deryck> cool
[15:42] <bac> hi jelmer
[15:42] <jelmer> hi bac
[16:12] <benji> flacoste: I am in need of someone I can ask a DB deployment question.
[16:17] <flacoste> benji: shoot!
[16:18] <flacoste> i'll do my best to answer
[16:18] <benji> flacoste: I'm working with the LOSAs to get a small DB permission change for a script to fix a critical regression; in an email stub said that I "need someone to manually apply the permissions to production" but neither I nor the LOSA know what exactly that means.  He asks if "running ./security.py wouldn't work?"
[16:19] <flacoste> benji: yes, if we run it as we do as part of nodowntime, that should do the trick
[16:19] <benji> flacoste: thanks
[17:11] <gmb> sinzui: I have a question about bug 894390, if you've got a second.
[17:11] <_mup_> Bug #894390: It's possible for Person.account and EmailAddress.account to be different for the same person <db> <merge-deactivate> <openid> <users> <Launchpad itself:In Progress by gmb> < https://launchpad.net/bugs/894390 >
[17:12] <sinzui> I do
[17:15] <gmb> sinzui: Okay. Quickly put, then: Will anything really bad happen if we move the code that changes email.account and email.person out of MergePeopleView._doMerge() and into the job code?
[17:15] <gmb> I realise that we're then deferring the check for other email addresses on the dupe account
[17:15] <sinzui> quick answer nothing bad
[17:16] <sinzui> gmb, I wanted to do it
[17:16] <gmb> But at the moment that check / change is preventing me from putting in a simple constraint to ensure that Person.account and EmailAddress.account point to the same place.
[17:16] <sinzui> I think it is a bit tricky because of timing and rules checks
[17:17] <gmb> Yeah.
[17:18] <sinzui> gmb, that view code is using the removeSecurityProxy too? I think we really do want that code in the model level
[17:18] <gmb> sinzui: Yup, I thought that too :)
[17:18] <gmb> sinzui: Are we only caring about the user in doing the check in the view? I.e. do we mostly care that they get told if the merge can't happen?
[17:18] <gmb> (Because we could conceivably do all that in a rabbity fashion, hand-wave, etcetera)
[17:20] <sinzui> gmb: yes. We really want the user to know that they are done confirming *many* email addresses. The code is counting down to 0
[17:20] <sinzui> Then we tell the user we are going to do it
[17:20] <gmb> Hrrrm.
[17:20] <sinzui> We can count down to 1 maybe
[17:22] <gmb> Hmm, possibly.
[17:23] <gmb> sinzui: Actually, if we did the check for emailset.getByPerson(self.dupe).count() > 1 (or whatever) early on in _doMerge(), wouldn't it have a similar effect?
[17:23] <gmb> Oh, no.
[17:23] <gmb> Bother.
[17:23] <gmb> That doesn't actually solve the problem *at all*
[17:40] <deryck> lunch time for rick_h_ and I.
[18:45] <sinzui> abentley, Do you have time to review https://code.launchpad.net/~sinzui/launchpad/dsp-vocab-unknown-distro
[18:46] <abentley> sinzui: I can get to it in a bit.
[19:10] <abentley> sinzui: Is it intentional that test_getInputValue_package_spn_dsp_picker_feature_flag and test_getInputValue_package_dsp_dsp_picker_feature_flag have identical comments?
[19:11] <sinzui> no :(
[19:15] <abentley> sinzui: around 171 and 187, I think you can simplify getUserBrowser().open(canonical_url(bug)) to getViewBrowser(bug)
[19:15] <sinzui> I certainly an
[19:16] <sinzui> can
[19:17] <abentley> sinzui: technically, test_setDistribution should have a comment, though I don't know what I'd say.
[19:18] <abentley> sinzui: And there should be a docstring on setDistribution itself.
[19:19] <sinzui> I would say it permits the callsite to set the vocab's distribution after the vocab was instantiated by another mechanism
[19:20] <abentley> sinzui: Okay,  r=me with those text changes.
[19:20] <sinzui> thank you
[19:21] <abentley> sinzui: Could you review one for me?
[19:21] <sinzui> yes I can
[19:22] <abentley> sinzui: https://code.launchpad.net/~abentley/launchpad/history-model-fix/+merge/83995
[19:23] <abentley> sinzui: I can provide some context if you like.
[19:23] <sinzui> Does this fix my back button? I sometimes need to go back twice to go back one page?
[19:24] <abentley> sinzui: On the new bug listings?
[19:24] <sinzui> yes
[19:24] <abentley> sinzui: It's not a bug I've observed, but I think it might fix that.
[19:26] <sinzui> abentley, lint lists 6 files, the diff shows 1
[19:26] <abentley> sinzui: I don't think lint takes prerequisite branches into account.
[19:26] <sinzui> ahh there is a preqeq
[19:27] <sinzui> r=me
[19:27] <abentley> sinzui: thanks!
[19:35] <lifeless> sinzui: hi
[19:35] <lifeless> sinzui: mailman
[19:37] <sinzui> yes mailman
[19:37] <sinzui> never postwoman
[19:37] <lifeless> is it easy to turn on monthly indexes vs all-time ?
[19:38] <sinzui> lifeless, I think it is the same work as what I described in my reply to your email. I am not familiar with the switch/flags in the file, but I think it is simple to add and a few days to generate
[19:38] <lifeless> coooool
[19:39] <lifeless> do you feel like doing it yourself?
[19:39] <lifeless> cause, you have like +10000 from me if you want to
[19:40] <sinzui> I will consider it for Friday. I have committed to fixing the so-called "bug supervisor" label on the advanced bug search form for Friday morning
[19:40] <lifeless> \o/
[19:42] <lifeless> sinzui: separately
[19:43] <lifeless> sinzui: wallyworld_ asked me yesterday about disclosing team names on branch pages; I said my understanding was that was fine as long as we'd cleaned up existing subscriptions to remove teams that don't want to be disclosed
[19:43] <lifeless> this turned into a discussion about whether that was work we'd decided to do or not, or something
[19:43] <lifeless> 16:25 < lifeless> my understanding is that we settled on 'when the team interacts with something' and 'team interactions will prompt to permit the interaction'
[19:44] <lifeless> 16:25 < lifeless> its the second bit I suspect is missing
[19:44] <lifeless> 16:25 < wallyworld_> yes
[19:44] <lifeless> 16:26 < wgrant> The second bit requires an API break.
[19:44] <lifeless> 16:26 < wgrant> In dozens of places.
[19:44] <lifeless> 16:26 < wallyworld_> maybe we decided against it then. i can't recall
[19:44] <lifeless> 16:27 < lifeless> I'd worry a little if we had
[19:44] <lifeless> 16:28 < lifeless> because we have a number of policies intended to prevent accidental discovery of private team names
[19:44] <lifeless> 16:28 < lifeless> and not doing the second bit will deeply devalue them
[19:44] <lifeless> 16:28 < wallyworld_> my memory is fuzzy, so i'm not sure one way or the other
[19:44] <lifeless> 16:28 < wgrant> I thought we were going to skip that, because of the enormous and ever-expanding scope creep it would entail.
[19:44] <lifeless> 16:29 < wgrant> Given recent happenings, I don't think we need any more of that...
[19:44] <lifeless> 16:29 < wallyworld_> i seem to recall that the discussion was that private team names could be exposed
[19:44] <lifeless> 16:29 < wallyworld_> and that people would have to given them cryptic names
[19:44] <lifeless> 16:29 < wallyworld_> if they didn;t want others to guess things
[19:44] <lifeless> 16:32 -!- timrc<EMAIL_ADDRESS>has joined #launchpad-dev
[19:44] <lifeless> 16:34 < lifeless> noone told me :)
[19:44] <lifeless> 16:35 < wgrant> We don't have a compelling, pretty, feasible private team design.
[19:44] <lifeless> 16:35 < wgrant> We no longer have a compelling, pretty, feasible private artifact design.
[19:44] <lifeless> 16:36 < wallyworld_> lifeless: perhaps we can all have a chat with sinzui tomorrow to clear it up. in case i/we have misunderstood anything
[19:44] <lifeless> -fin
[19:46] <sinzui> I think my team was slowly understanding what I meant by traversal. wallyworld_ did produce a branch that seem to do the right thing to check if a user may access a subordinate object
[19:46] <sinzui> we have not solved the important case yet to say we really know how to do this...eg stop avoiding the private team p3a subscription problem
[19:47] <lifeless> anyhow, I believe you have a standup. Perhaps I can join at the end of that and we can have a brief chat? I don't want to be adding confusion to your team when they ask me things :)
[19:47] <sinzui> lifeless, We do not yet know how to present pages when the user as restricted access
[19:47] <sinzui> okay
[19:51] <sinzui> lifeless, https://code.launchpad.net/~wallyworld/launchpad/view-private-branch-artifacts-605130/+merge/83915 shows the draft that wallyworld_ took after discovering the bug was about traversal
[19:55] <timrc> Not that I'm going to add anything of value here, but most of our (Commercial Engineering)  privacy needs could be met if running own instance of Launchpad were more feasible
[19:55] <timrc> let the firewall naturally provide most of the security for us
[19:56] <timrc> doesn't solve the problem of privacy for external customers though (unless they too ran their own instances of Launchpad)
[19:57] <lifeless> timrc: AIUI thats bogus :)
[19:57] <lifeless> timrc: because you have multiple vendors you collaborate with, and you don't want mutual-disclosure amongst them
[19:58] <timrc> if we could bring up separate launchpad instances for each, though?
[19:58] <timrc> that would imply Launchpad were much lighter than it is today, though
[19:58] <lifeless> it would be a totally different thing at that point
[20:06] <timrc> there has been customer interest to put image building behind the firewall but what of the archive? on the face of things launchpad seems perfectly suited for that, but in practice, that would be a nightmare
[20:06] <flacoste> more like a set of bugzilla instances :-)
[20:06] <flacoste> which means, no collaboration between them
[20:06] <flacoste> which isn't what LP is about
[20:09] <timrc> flacoste, how do private projects within launchpad.net collaborate today?
[20:10] <flacoste> timrc: well they use multiple bug tasks
[20:10] <timrc> I thought that was going away :)
[20:10] <flacoste> you asked today?
[20:10] <timrc> lol ok
[20:10] <flacoste> but you are right
[20:10] <timrc> fair enough
[20:10] <flacoste> that's changing to use linking between issues
[20:10] <flacoste> so that it's easier to manage the conversations
[20:11] <flacoste> and easier to understand who has access to what
[20:11] <flacoste> but linked issues will still make it easier to collaborate than setting separate bugzilla instances
[20:11] <flacoste> which really never talk to each other
[20:11] <flacoste> as a back story
[20:11] <flacoste> Canonical and Ubuntu started by using bugzilla itself
[20:12] <flacoste> and then quickly saw that trying to talk to upstream would never scale with it
[20:12] <flacoste> and that's when LP was born
[20:12] <timrc> Federate your Launchpad instances so BigCo's launchpad instance is comprised of all the data from launchpad.net and launchpad.bigco.com
[20:12] <flacoste> well, its bug tracker at least
[20:12] <flacoste> timrc: yep, that would be another way of doing it
[20:12] <flacoste> but more work
[20:12] <flacoste> and you guys have waited long enough already ;-)
[20:13] <timrc> lol
[20:14] <lifeless> federation has the same issues FWIW
[20:15] <lifeless> 'if I reply to this bug, who sees the response'
[20:15] <lifeless> 'who is this bug accessible to'
[20:15] <lifeless> 'who should control accessibility to this bug'
[20:15] <timrc> depends on where the bug originates?
[20:15] <lifeless> sure
[20:15] <timrc> if the bug originates on launchpad.bigco.com than by default it's only visible to people with access to launchpad.bigco.com
[20:15] <lifeless> but if you get notified on bugs that are just federated in
[20:16] <lifeless> and you reply with proprietary info because you are confused...
[20:16] <abentley> deryck: chat?
[20:17] <deryck> abentley, deep in sprinting right now.
[20:17] <abentley> deryck: okay.
[20:17] <deryck> abentley, is this about something you're hacking on?
[20:17] <abentley> deryck: Yes.
[20:17] <timrc> lifeless, we have a nice banner that says "this bug is private"... I can envision the same here
[20:17] <lifeless> timrc: right, but you see that its not something improved by federating
[20:18] <deryck> abentley, is this something you need me for, or could someone else pre-imp you?
[20:18] <lifeless> timrc: federating doesn't naturally solve it
[20:18] <timrc> lifeless, it seems more intuitive, the separation seems clearer
[20:19] <abentley> deryck: I wanted some policy direction, but I think I can get started without it.
[20:19] <timrc> you don't set a privacy bit, it's implied by organizational structure
[20:19] <lifeless> I think federating is a good way to think about the problem
[20:20] <lifeless> but I don't think the act of federating itself solves much, not if you have it all automated
[20:21] <deryck> abentley, ok, cool.  Thanks!
[20:25] <timrc> okay, well thanks for humoring me :) i know your time is precious
[20:26] <timrc> I am trying to find a critical bug I can work on in my spare time -- need you guys focused on privacy! ;)
[20:29] <jcsackett> abentley: free for a review? https://code.launchpad.net/~jcsackett/launchpad/fancy-filebug-part2/+merge/84004
[20:31] <abentley> jcsackett: I don't understand the difference between a private bug and a private-by-default bug.
[20:32] <abentley> jcsackett: Do you know why these ribbons are implemented in JavaScript?
[20:35] <jcsackett> abentley: private by default is projects where all reported bugs are automatically marked as private.
[20:36] <abentley> jcsackett: I got confused because I didn't understand were were talking about a bug that doesn't exist yet.
[20:36] <jcsackett> abentley: ah, yes, this is on +filebug, so as you're reporting it.
[20:36] <jcsackett> sorry if my mp didn't make that clear.
[20:37] <jcsackett> as to the javascript, abentley, it was written originally for existing bugs, so that it would dynamically display when a bug was marked as private or public once it already existed.
[20:37] <jcsackett> it seemed better to just reuse that even in non-dynamic situations then create another display.
[20:37] <jcsackett> and in the case of toggling the security related stuff, the dynamic part is actually desireable.
[20:38] <abentley> jcsackett: It just seems bad not to provide these ribbons to non-JS users.
[20:39] <abentley> jcsackett: Our new beta banner was based on these ones, so I've filed Bug 891697 about it.
[20:39] <_mup_> Bug #891697: Beta banner is not shown if JavaScript is disabled. <Launchpad itself:Triaged> < https://launchpad.net/bugs/891697 >
[20:40] <jcsackett> abentley: that's fair.
[20:40] <jcsackett> abentley: i *believe* the old privacy display (the grey stripey edging) still shows when you're looking at a private bug if you don't have JS.
[20:40] <jcsackett> but having something like the banner still work would be better.
[20:40] <abentley> jcsackett: oh, that's good.
[20:41]  * timrc tests that
[20:43] <abentley> r=me.  I prefer "set up" rather than "setup" for the verb, but I guess both are used.
[20:43] <timrc> jcsackett, it does indeed show the grey stripey edge
[20:43] <jcsackett> abentley: thanks. i've updated your bug to explicitly include the privacy banner, b/c the same considerations apply.
[20:55] <poolie> hi all
[21:09] <sinzui> abentley, I share your observation about the privacy banner. It was interactive. We removed the hide button, so it is just structure and CSS now. in fact, we still load the old css. you will see the old background stripe on the left when the page loads :(
[21:14] <lifeless> thats good if js is disabled ;)
[21:21] <flacoste> sinzui: timrc disabled js and confirmed that the old background strip appears
[21:22] <flacoste> hi poolie
[21:22] <poolie> hi there
[21:22] <flacoste> benji: are we ready to renable the translations jobs?
[21:23] <flacoste> benji: a user complained again on #launchpad
[21:23] <sinzui> lifeless, flacoste it is not good, it is only acceptable. The page could have used the pretty CSS by default!
[21:23] <benji> flacoste: we are (well, they weren't jobs before, but now are)
[21:23] <flacoste> sinzui: right
[21:24] <flacoste> benji: care to file a RT for it? I'll put it at the top of the queue
[21:24] <timrc> gray stripey edge is definitely subtle
[21:24] <benji> flacoste: the only problem remains that there is a disagreement about how exactly that is done, or if anything needs to be done at all
[21:24] <flacoste> benji: what's the disagreement about?
[21:24] <timrc> I've grown to depend on the red bar to make sure I'm not about to do something regrettable
[21:24] <timrc> if only I had it for other aspects of my life
[21:25] <benji> flacoste: I wasn't around when it was last discussed but the way it was communicated to me was that nothing needed to be done and the jobs would simply begin running
[21:25] <flacoste> benji: i doubt that
[21:25] <benji> flacoste: you and me both :)
[21:25] <flacoste> benji: right, we need a new cron job
[21:25] <flacoste> there is a generic script to run these jobs
[21:26] <flacoste> but the arguments to the script are job-specific
[21:26] <flacoste> iow, the config section to use
[21:26] <benji> right (cronscripts/run_jobs.py)
[21:27] <benji> flacoste: I'll file an RT to add "cronscripts/run_jobs.py pofile_stats" to the crontab or equivalent.
[21:28] <flacoste> benji: thx, let me know the # so that i can adjust the priority
[21:28] <benji> flacoste: will do
[21:34] <benji> flacoste: RT #49635
[21:34] <_mup_> Bug #49635: adept is _really_ slow.  <adept (Ubuntu):Fix Released by mornfall> < https://launchpad.net/bugs/49635 >
[21:37] <flacoste> benji: thx
[21:37] <benji> np
[21:41] <lifeless> sinzui: so what time is the clal ?
[21:42] <sinzui> 19 minutes
[21:42] <sinzui> we use mumble
[21:42] <lifeless> kk
[21:42] <sinzui> I suspect we are the last team to use mumble
[21:44] <poolie> o/ sinzui
[21:47] <sinzui> poolie, Last year, I had mumble on all the time and talked many times a day. Used mumble about 7 time a week now. :(
[21:47] <poolie> that is more often than me
[21:47] <poolie> if i had better audio hardware
[21:47] <poolie> i would use it more
[21:47] <poolie> not sure what that would look like though
[21:49] <lifeless> if it worked better in .nz I would use it more ;)
[21:54] <beuno> sinzui, in U1 we only use mumble, a lot of us are on it for the full working day and move between rooms to talk to people
[21:55] <sinzui> beuno, That is what I remember the ~launchpad team was doing 12 months ago
[21:58] <mwhudson> lifeless: it's been fine for me lately
[21:58] <mwhudson> of course i have super internet in the office
[21:58] <mwhudson> (by nz standards)
[21:59] <lifeless> beuno: I can't work like that - too much distractions (see for instance the research into productivity losses in open plan offices)
[22:00] <beuno> lifeless, right, so my work is basically interrupt-based, so if anyone is blocked on something, they can just jump in and talk
[22:00] <beuno> when I need to focus, I close it
[22:01] <lifeless> beuno: they can do that to me too; but when its not happening I am focused ;)
[22:01] <beuno> lifeless, it's a bigger barrier if you need to ping someone on irc, get them to log in, adjust their mic, etc etc etc
[22:02] <beuno> if I'm already there, it's cheap and quick
[22:02] <abentley> sinzui: We never really did that on the Code team.
[22:02] <lifeless> beuno: perhaps
[22:02] <beuno> lifeless, then we also have a policy where developers always work in pairs, so they have their own channels
[22:02] <beuno> I can get dragged into those
[22:03] <beuno> or other developers can get pinged to join them
[22:03] <beuno> it's been quite good for us
[22:03] <beuno> OTOH, when it's hammer time, people even drop off of IRC   :)
[23:18] <sinzui> StevenK, bug 603732
[23:19] <_mup_> Bug #603732: If there is no driver a maintainer should be able to accept a bug nomination <bugnominations> <lp-bugs> <planning> <series> <Launchpad itself:Triaged> < https://launchpad.net/bugs/603732 >
[23:33] <sinzui> wallyworld_, Do you want to talk about launchpad.LimitedView on mumble
[23:34] <wallyworld_> sinzui: ack
[23:42] <poolie> is it just me who sees ec2 host keys getting cached in my real keyring by ec2test?


[00:03] <hggdh> this specific bug can be marked as triaged; there is nothing else we can do here
[00:05] <hggdh> sccman: in this case, the bug went to triaged/wishlist
[00:07] <hggdh> sccman: also, please do not hesitate is asking here if you have doubts on triaging
[00:08] <hggdh> sccman: and yes, we need people to help :-)
[01:03] <sccman> How do you mark bug reports as Wishlist?
[01:04] <rbasak> Not everyone has permission to set the Importance field for what are I hope obvious reasons :)
[01:04] <rbasak> If you need something changing and can't do it yourself, please ask here.
[01:04] <sccman> What "obvious reasons" are those?
[01:05] <sccman> :)
[01:05] <rbasak> Otherwise everything would end up Critical, since to a bug reporter his or her bug is always Critical.
[01:05] <sccman> Oh. Makes sense.
[01:06] <sccman> Unless you prevent people from marking Critical.
[01:06] <rbasak> Then all bugs would end up High :)
[01:06] <sccman> But it's up to the makers lol
[01:07] <rbasak> This is the right place to ask for privileged bug status changes. We're always looking for more volunteers to help. If you show that you understand how to set the privilege fields, we'd be happy to give you permission to do that directly.
[01:07] <sccman> True.
[01:07] <sccman> Where would you say you guys need the help with the most?
[01:14] <rbasak> Good question. I'm not sure.
[01:14] <rbasak> Everything :)
[01:14] <rbasak> I think it's really a case of matching a volunteer's skills (and motivation/interest) to what needs doing
[01:14] <sccman> There's no job that's in real demand in Ubuntu?
[01:14] <sccman> I mean in particular that is.
[01:14] <sccman> Like if you work for a company and they say they're "desperate" for X personnell?
[01:14] <rbasak> The bug database is a massive list of what users would like us to be doing :)
[01:14] <sccman> Fair enough.
[01:15] <sccman> The users are the customers after all lol
[01:16] <rbasak> Ubuntu isn't a single entity with a single direction.
[01:17] <rbasak> *Canonical* have goals, but they hire employees for what they need.
[01:17] <sccman> Right.
[01:18] <rbasak> But Ubuntu itself does whatever the project participants want to do, except when those goals are in conflict (which is rare).
[01:18] <sccman> I see.
[01:18] <rbasak> Of course everyone wants an Ubuntu developer to appear to fix *their* bug.
[01:19] <rbasak> I don't mean that in a bad way. It's pretty much tautological.
[01:19] <rbasak> And separate from bugs, there are features. Right now we want people to work on snaps for third party projects. That's a big area of focus for Canonical right now.
[01:20] <sccman> Every user wants their problems fixed with computers. Even Microsoft and Apple lol
[01:20] <sccman> They want the computer to fix their lives like magic.
[01:20] <rbasak> Because snaps solve a bunch of problems for Ubuntu users, and we have a solution for it.
[01:20] <sccman> What are snaps?
[01:20] <rbasak> https://snapcraft.io/
[01:21] <rbasak> It solves the problem of packaging software outside a distribution.
[01:21] <rbasak> Eg. if you're a software vendor and you want to ship some software directly to Ubuntu users.
[01:22] <rbasak> Or if you're an Ubuntu user and you want to try some cool new software that didn't ship with Ubuntu because it didn't exist at the time, and you want to try it out without risking destabilising your system or risking security.
[01:23] <sccman> How is that different from the package manager?
[01:23] <sccman> Like apt and pacman?
[01:24] <rbasak> apt package repositories must be tightly integrated with each other in order to work.
[01:24] <rbasak> It's difficult for a third party to provide a package from outside the distribution with the required level of integration.
[01:25] <rbasak> Separately, users trust the distribution repository because everything in it has been vetted by the distribution.
[01:25] <rbasak> And you have to trust *something*.
[01:25] <rbasak> Third party packages don't have to pass the same quality requirements, so they can vary wildly in quality.
[01:26] <rbasak> For example some may "call home" and leak user data from your home directory.
[01:26] <rbasak> These things are unacceptable in distributions and so generally get rejected, removed, fixed, etc. as soon as they're spotted.
[01:26] <rbasak> But if you use third party repositories, you have no control over what that repository can do on your system.
[01:27] <rbasak> snaps provide isolation and confinement so you can safely install a snap on your system without having to worry about this.
[01:27] <rbasak> (the just-published hardware vulnerability aside)
[01:30] <sccman> Isn't it just another third-party respository?
[01:30] <sccman> I'm not trying to bash snapcraft, I'm only trying to understand.
[01:33] <sccman> Maybe a better question would be...how does it offer more control over what a repository does?
[01:33] <rbasak> Snaps come from third parties, yes. But snapd, the (sort of) package manager that runs on your system, runs package contents "confined". As well as just installing something on your system, it also manages the rnning of it.
[01:33] <sccman> It sounds like it has heavy security in it.
[01:33] <rbasak> "Confined" means that when the process is run, it doesn't have access to a bunch of things unless it is given that access.
[01:33] <rbasak> Right
[01:34] <rbasak> For example, if I install and run a snap, it can't just stream video from my webcam.
[01:34] <rbasak> But a program installed by apt can.
[01:34] <rbasak> With snaps, I have to explictly connect that interface for it to be able to do it.
[01:34] <rbasak> A bit like permissions on Android apps.
[01:35] <rbasak> This makes third party snap repositories "safe" when compared to third party apt repositories.
[01:35] <sccman> Hmm
[01:37] <sccman> It sounds like it's a third-party repository, but yet it's not. Almost like it's apt-get but with a little more liberal security standards.
[01:37] <sccman> For a lack of a better term.
[01:40] <rbasak> Instead of vetting taking place at the point the package is included in the distribution, the vetting takes place at the time the program is run on a user's system.
[01:40] <rbasak> This removes the need for manual vetting.
[01:40] <rbasak> In contrast, a third party apt repository receives no vetting.
[01:41] <sccman> Oh okay.
[01:42] <sccman> And I'm sure it would give developers more flexibility so they don't have to meet Ubuntu's strict standards.
[01:43] <sccman> They won't be restricted as much by Ubuntu's standards in their features.
[01:50] <rbasak> Right
[01:51] <sccman1> How would you describe the users of snapcraft?
[01:53] <sccman> Sorry been messing with pidgin lol
[01:57] <sccman1> How would you describe the users of snapcraft?
[02:05] <rbasak> I'm not sure I understand the question.
[02:08] <sccman> Well it's obviously solving a group of people's problems, otherwise nobody would use it :)
[02:11] <sccman> All published software will, at the end of the day, be used by its users. However not all users will use the software. Linux for example is typically used for people who are more tech-savvy versus Windows and Mac's audience is more geared towards everyday non-technical users.
[02:11] <sccman> versus Windows' and Mac's audience will gear toward*
[02:13] <sccman> In marketing there's typically a target group of people that you gear your products to. I was wondering if you happen to have any insight on that :)
[02:13] <sccman> Maybe if you overheard.
[02:43] <hggdh> sccman: I will give you an example: I use pycharm (from jetbrains.com). Up to nowish, pycharm was distrivuted as a tgz (compressed tarball). Now they offer a snap for it
[02:44] <hggdh> and I jumped over to the pycharm snap... now I do not have to worry about updating it, and I can (theoretically) install it on any Linux distro that supports snap
[02:44] <hggdh> Now... I am waiting for CLion to be snapped as well, then I am happy :-)
[02:55] <rbasak> For a long time, third parties have shipped software to Ubuntu users by hacking something together.
[02:55] <rbasak> All PPAs and third party apt repositories are fundamentally a hack.
[02:56] <rbasak> The target, IMHO, should be to have snaps replace all of those.
[02:59] <hggdh> +1
[18:19] <padv> Can somebody please close LP: #776376 this package has been deleted in artful on 2017-07-28 by Steve Langasek (From Debian) ROM; no longer used; Debian bug #863235 and Ubuntu 11.04 is no longer supported
[18:24] <rbasak> padv: I don't just want to change a bug status without an explanation. Could you write the reason into the bug, please?
[18:29] <padv> rbasak: I added the reason into the bug report and was able to mark it Fix Released (did know I could do that)
[18:29] <padv> rbasak: Thanks for your help
[18:29] <padv> rbasak: s/did/didn't
[18:30] <hggdh> it is actually not fix released, if the package was dropped. Invalid would be better
[18:30] <hggdh> padv: and yes, you can move to fix released. You just cannot move it out of it
[18:31] <padv> hggdh: sorry can you change to Invalid
[18:32] <rbasak> I don't like Invalid, because that suggests it was Invalid at the time it was filed, which isn't necessarily true.
[18:32] <rbasak> We usually set Won't Fix for EOL bug reports.
[18:32] <rbasak> So I did that.
[18:32] <hggdh> rbasak: cool, and I agree
[18:32] <padv> rbasak: Thanks!
[18:32] <rbasak> Though in this case I think it's quite clearly a system issue rather than a bug.
[18:33] <padv> hggdh: Thanks for agreeing
[18:33] <rbasak> But to explain that, and apologise for telling them now rather than at the time of the report when it would be useful, is quite an essay to write :-/


[18:21] <ubuntucloud467> ola
[18:21] <ubuntucloud467> podem me ajudar numa coisa?
[23:30] <smolyn> we're using ubuntu ec2 instances and occasionally seeing really sluggish machines showing 93% idle, but with some processes showing 9999% cpu use!  any ideas?


[00:47] <amurray> GunnarHj: we had some folks enquiring about the ibus CVE-2019-14822 update - this is still blocked on the glib2.0 SRU in LP: #1844853 - is this still being worked on?
[01:40] <GunnarHj> amurray: The eoan SRU is being worked on; see bug #1850932. As regards the other releases I'm not sure.  It's not the same with didrocks and the Yaru team.
[09:07] <Wimpress> *without
[09:07] <Laney> moin Wimpress
[09:07] <Laney> what's going in in ldn?
[09:07] <Laney> condolences for having to commute
[09:08] <Wimpress> Selling a kidney for train ticket and having standing room only is objectionable.
[09:08] <didrocks> Wimpress: we were part of all the fun! :)
[09:09] <didrocks> you have a second one for the way back at least :p
[09:09] <Wimpress> Laney: Working on bootstrapping the appliances images work. Group of us here.
[09:09] <oSoMoN> hullo Laney
[09:10] <Laney> oic
[09:10] <Laney> hey oSoMoN
[09:13] <Laney> bet you've not got any snow :>
[09:14] <marcustomlinson> hey didrocks, I was just about to say no, but it just started up again now :P
[09:14] <didrocks> ahah
[10:19] <Laney> didrocks: is there a preferred way to contact the MIR team? or just email?
[10:23] <Laney> or cpaelzer ^-
[10:23]  * Laney has an MIR exception ready to discuss, as pre-discussed :-)
[10:31] <didrocks> the meeting time is the best place/time IMHO, but if it's urgent, it can be discussed beforehand
[10:34] <Laney> not really, but I would have expected it to be something to read at leisure and not during a meeting
[10:34] <Laney> as you wish
[10:36] <didrocks> I guess we have empty enough content meeting to discuss it there. Otherwise, just open a MIR, set it as incomplete and write the details there
[10:36] <didrocks> the advantage of the meeting is that it's more interactive and we have more than one person on it
[10:36] <didrocks> (hopefully :p)
[10:41] <Laney> ok!
[10:41] <didrocks> see you in a few hours then ;)
[10:45] <cpaelzer> Laney: ack to "if not urgent then at the meeting"
[10:47] <Laney> I was going by e.g. what the TB do
[10:47] <Laney> email -> get on agenda -> discuss at meeting
[10:48] <Laney> so people can prepare beforehand
[10:52] <jibel> xnox, RikMills so, window-mocker has been developed specifically for unity tests with autopilot. If unity doesn't run the functional tests anymore windowmocker can completely be removed from the archive.
[10:58] <RikMills> jibel: and it does not? if so, very much agreed
[11:10] <jibel> RikMills, windowmocker is used by the search tests and last update is from 2013. I doubt these tests are still running but it'd need a confirmation from the current devs of unity. Besides if windowmocker is removed it'll skip these tests but won't completely break the test suite.
[11:12] <jibel> Trevinho, ^ do you know if the autopilot tests of unity are still used?
[11:13] <jibel> Trevinho, we'd like to remove python-windowmocker which depends on qt4 from the archive and it's only used by these tests
[11:43] <Laney> xnox: can you remind me what the status of uploading the oem archive keyring is please?
[11:45] <xnox> Laney:  i am yet to do it. Are you after the package name?
[11:45] <xnox> or like the key file name?
[11:45]  * xnox should do it today, such that it sits in the new queue
[11:46] <Laney> package name, I don't really care about the keyfile name
[11:46] <Laney> UNLESS
[11:46] <Laney> we ship it outside of trusted.whateveritis.d and use [deb signed-by=/path/to/oem-...]
[11:47] <Laney> in the oem-foo-meta packages
[11:47] <Laney> which might be sensible? in which case yes, since I'll specify that in the MIR template
[11:47] <Laney> s/template/exception/
[11:48] <xnox> ooooh deb signed-by sounds interesting => does it only use the one key for that archive?
[11:48] <xnox> i was thinking to simply ship it in trusted.gpg.d
[11:48] <Laney> yeah
[11:48] <xnox> like dbgsyms / cdimage / archive keys are
[11:49] <Laney> see sources.list(5)
[11:49] <Laney> right, perhaps those pre-date this concept but it's probably sensible to use it where possible?
[11:49] <xnox> Laney:  i guess you can still use that, even though the signed-by=/etc/apt/trusted.gpg/oem.... ?
[11:50] <xnox> Laney:  i guess you can still use that, even though the signed-by=/etc/apt/trusted.gpg.d/oem.... ?
[11:50] <Laney> presumably
[11:50] <Laney> but then it would let *other* repos be signed by that key
[11:50] <xnox> right, those that are not scoped
[11:51] <Laney> would be cool for e.g. add-apt-repository to use this too
[11:58] <xnox> But then where should the keys be placed?
[11:59] <Laney> dunno
[11:59] <Laney> /usr/share/ somewhere?
[11:59] <xnox> add-apt-repository is system config so should be like /etc or /var
[11:59] <xnox> (most of them are)
[12:00] <xnox> /etc/apt/sources.d/foo.list & foo.asc ?
[12:00] <xnox> /etc/apt/sources.list.d/foo.list & foo.asc ?
[12:00]  * xnox fails at typing
[12:00] <Laney> or /var/lib/
[12:00] <Laney> presumably Julian would have some opinions here ...
[12:01]  * xnox opens a bug report
[12:02] <Laney> anyway, what is the package name? oem-archive-keyring?
[12:04] <xnox> https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1862764
[12:06] <xnox> Laney:  ubuntu-oem-keyring (which matches ubuntu-cloud-keyring which is for ubuntu-cloud.archive.canonical.com)
[12:06] <Laney> ok!
[12:07]  * Laney makes a fake oem package which works inside qemu for testing in VMs
[12:19] <RikMills> jibel Trevinho; lovely, unity FTBFS in focal ppa with cmake not being able to find compiz. so dropping window-mocker dep might need work
[12:21] <Laney> have you guys tried talking to k_alam about unity?
[12:22] <Laney> email or discourse might be best for that
[12:30] <mitya57> RikMills: do you have a link to build log?
[12:35] <RikMills> mitya57: https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/experimental/+sourcepub/10990496/+listing-archive-extra
[12:35] <RikMills> seems I can't spell unity.....
[12:43] <mitya57> RikMills: thanks. I am on a meeting at job now, will take a look later.
[12:45] <mitya57> RikMills: ah, compiz-dev ships /usr/share/cmake-3.15/FindCompiz.cmake. Looks like it needs a rebuild against cmake 3.16 to update the path.
[12:55] <mitya57> RikMills: I am building it in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3924/+packages now. If you make a MP against unity I can test-build it in the same PPA.
[12:56] <RikMills> mitya57: its not a done deal on dropping the dep yet. need to hear back from unity devs
[12:57] <mitya57> Ok
[13:21] <sergiusens> kenvandine: hey, btw, I have the "Reminders" window popup with Online Accounts (calendar) and Gnome Calendar
[13:22] <Trevinho> RikMills: I'm all fine with that, as per the testing side can probably all be removed safely
[13:22] <Trevinho> RikMills: as for the cmake thing, may be because of some compiz cmake macros not working anymore?
[13:23] <RikMills> Trevinho: thanks. yeah, sounds like compiz needs rebuild for cmake in -proposed
[13:32] <Laney> whoops, found my weekly update un-submitted!
[14:21] <hellsworth> good morning desktopers
[14:21] <kenvandine> good morning hellsworth
[14:21] <hellsworth> hi kenvandine
[14:21] <kenvandine> hellsworth: i've got epiphany building anr running :)
[14:21] <kenvandine> minor tweak
[14:21] <hellsworth> oooh what was it
[14:21] <kenvandine> LD_LIBRARY_PATH
[14:25] <hellsworth> aaah
[14:26] <kenvandine> hellsworth: probably needs a tweak in the extension
[14:27] <hellsworth> can you show me what path you used in epiphany?
[14:27] <kenvandine> hellsworth:  this needs to be add to LD_LIBRARY_PATH:
[14:27] <kenvandine>  $SNAP/gnome-platform/usr/lib
[14:28] <marcustomlinson> that's odd
[14:28] <oSoMoN> good morning hellsworth
[14:28] <kenvandine> some of the libs in the platform snap aren't installed in the arch path
[14:28] <marcustomlinson> I would've expected that path to have been carried over from dekstop-helpers
[14:28] <kenvandine> me too
[14:28] <marcustomlinson> https://github.com/ubuntu/snapcraft-desktop-helpers/blob/af0979e1e810732f75c39dbf85f8b6c32e3991e4/common/desktop-exports#L63
[14:29] <marcustomlinson> must have been missed
[14:29] <kenvandine> meeting time!
[14:30] <kenvandine> #startmeeting Desktop Team Weekly Meeting - 2020-02-11
[14:30] <meetingology> Meeting started Tue Feb 11 14:30:07 2020 UTC.  The chair is kenvandine. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[14:30] <meetingology> Available commands: action commands idea info link nick
[14:30] <kenvandine> Roll call:  didrocks, duflu (out), jamesh (out), jibel, kenvandine, laney (out), marcustomlinson, oSoMoN, seb128 (out), tkamppeter, trevinho, robert_ancell (out), Wimpress (out), hellsworth
[14:30] <marcustomlinson> \o
[14:30] <hellsworth> o/
[14:30] <kenvandine> oh, i'm not sure if seb128 is out :)
[14:31] <oSoMoN> o/
[14:31] <jibel> he is
[14:31] <didrocks> hey
[14:31] <kenvandine> ok
[14:31] <marcustomlinson> meanwhile seb128 watches from the bushes fighting the urge to speak and give away his location
[14:31] <kenvandine> :)
[14:33] <kenvandine> let's get started
[14:33] <kenvandine> #topic rls-ff-bugs
[14:33] <kenvandine> http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-ff-incoming-bug-tasks.html
[14:34] <kenvandine> oh weird... i can't open the bug links in firefox
[14:34] <kenvandine> i get a dialog asking to download it
[14:35] <oSoMoN> file a bug :)
[14:35] <hellsworth> :)
[14:35] <marcustomlinson> I see a lot of duflu on those open bugs
[14:36] <kenvandine> restarting the browser fixed it
[14:36] <oSoMoN> turning it off and on again…
[14:36] <kenvandine> yeah, lots of duflu
[14:38] <marcustomlinson> oh I see, these are mostly champagne additions
[14:38] <marcustomlinson> all actually
[14:38] <Laney> Daniel seems to be adding champagne to lots of bugs
[14:38] <Laney> not sure that's how this is supposed to work
[14:39] <kenvandine> indeed
[14:39] <Laney> de-tag those and follow up with a mail to the team(s) explaining it?
[14:41] <kenvandine> it might still follow the spirit of champagne
[14:41] <kenvandine> let's discuss this again in the leads meeting
[14:41] <kenvandine> before de-tagging
[14:42] <Laney> seriously hope it doesn't
[14:43] <kenvandine> well, these could have been tagged by finding the same issue and tagging the existing bug instead of filing new
[14:44] <kenvandine> looks like tracking is fine
[14:45] <kenvandine> moving on
[14:45] <kenvandine> #topic rls-ee-bugs
[14:45] <kenvandine> nothing desktop in incoming
[14:46] <kenvandine> bug 1853768 is in tracking but not assigned
[14:47] <hellsworth> says its fixed in focal
[14:47] <kenvandine> yeah, but eoan needs the SRU
[14:48] <kenvandine> that's the only one not assigned
[14:48] <kenvandine> besides the NM bug
[14:50] <RikMills> Trevinho: https://code.launchpad.net/~rikmills/unity/+git/unity/+merge/378891
[14:50] <mitya57> kenvandine: I wanted to take care of SRUing it, but I'm waiting for the current yaru-theme in eoan-proposed to migrate.
[14:50] <kenvandine> mitya57: can we assign it to you?
[14:50] <mitya57> Yes
[14:50] <kenvandine> thanks
[14:50] <kenvandine> moving on
[14:51] <kenvandine> #topic rls-bb-bugs
[14:51] <kenvandine> nothing for desktop incoming
[14:52] <kenvandine> only un-assigned bugs in tracking are NM
[14:52] <kenvandine> #topic update_excuses_by_team.html#desktop-packages
[14:52] <kenvandine> Laney: you're up
[14:53] <Laney> Don't have super much to say, could someone take a look at the regressions underneath gobject-introspection maybe?
[14:55] <Laney> and there's a libreoffice regression noted there, not sure if that's something to be concerned with
[14:55] <Laney> otherwise python3-defaults is making it look sad but that's not on us to handle
[14:55] <hellsworth> marcustomlinson: libreoffice shouldn't be blocking python3 anymore since the LO ubuntu4 deb is in proposed?
[14:55] <marcustomlinson> yeah fingers crossed that'll be sorted out soon
[14:55] <marcustomlinson> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libreoffice
[14:55] <marcustomlinson> tests running
[14:56] <kenvandine> no volunteers for gobject-introspection?
[14:57] <marcustomlinson> here's a rubbish suggestion, how about we just hit retry on all the failures
[14:57]  * marcustomlinson runs away
[14:58]  * marcustomlinson is sort of serious though
[14:58] <hellsworth> i'm full with LO and gnome snapcraft extension
[14:58] <hellsworth> i wish i could help but i'm already trying not to drown
[14:58] <kenvandine> ok, moving on
[14:58] <kenvandine> #topic aob
[14:59] <hellsworth> nothing from me
[15:00] <Laney> gnome updates
[15:01] <Laney> it would be good if people could volunteer to do a couple of these to spread it around a bit
[15:01] <kenvandine> i guess we didn't make good progress since last week?
[15:02] <Laney> https://people.canonical.com/~platform/desktop/versions.html not really
[15:02] <hellsworth> Laney what has to be done with these to update them?
[15:04] <Laney> wrangling the packaging
[15:04] <hellsworth> i need more specifics
[15:04] <hellsworth> i see libreoffice in that list. what do i need to do to that to "wrangle the packaging"
[15:04] <Laney> yeah sorry, but it's hard to be specific
[15:04] <oSoMoN> I'm late on feature work and trying to stay afloat, but I'll make some room for some updates this week
[15:05] <Laney> basically get the package, check what changed between the version we have and the new one, and adjust accordingly
[15:05] <Laney> adding / updating build-dependencies, stuff like that
[15:05] <Laney> https://people.canonical.com/~platform/desktop/gnome.html maybe that's a better one to look at
[15:05] <hellsworth> is there any documentation on this process?
[15:05] <oSoMoN> dropping or rebasing ubuntu-specific patches on top of upstream/debian
[15:05] <marcustomlinson> hellsworth: we don't follow rc releases from Debian in libreoffice, so ignore it
[15:06] <hellsworth> oooh these packages are out of date with respect to debian and you're asking for them to be updated
[15:06] <Laney> the high level goal is to get gnome 3.35.90 into focal
[15:07] <kenvandine> debian or upstream
[15:07] <kenvandine> working towards the gnome RC
[15:07] <hellsworth> all of these packages have gnome 3.35.90 in the debian or upstream package?
[15:07] <Laney> there's some documentation: https://wiki.ubuntu.com/DesktopTeam/git https://wiki.debian.org/Gnome/Git https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/
[15:08] <hellsworth> Laney: thanks but i think i understand now
[15:08] <kenvandine> ok, moving on
[15:08] <Laney> usually it's us (& endless folks, & some others) who do the update in Debian too
[15:08] <kenvandine> any more aob?
[15:09] <Laney> (thanks oSoMoN!)
[15:09] <hellsworth> i'll try updating one sometime in the near future
[15:09] <kenvandine> well that's a wrap
[15:09] <kenvandine> #endmeeting
[15:09] <meetingology> Meeting ended Tue Feb 11 15:09:39 2020 UTC.
[15:09] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-desktop/2020/ubuntu-desktop.2020-02-11-14.30.moin.txt
[15:09] <kenvandine> thanks all
[15:09] <hellsworth> thanks
[15:09] <oSoMoN> thanks
[15:09] <marcustomlinson> thanks
[15:09] <Laney> yeah it's one of those 'core' things that it'd be good to have more people able to participate in
[15:09] <Laney> thanks
[15:10] <hellsworth> makes sense
[15:11] <Laney> Trevinho: did you say you were working on mutter & shell 3.35?
[15:11] <didrocks> thx
[15:12] <Trevinho> Laney: I started preparing yeah, although I had to go back at some MRs
[15:12] <Trevinho> but ideally I want to do it this asap
[15:12] <Laney> ok greaT
[16:35] <RikMills> language-selector build depends on pyqt4-dev-tools! can this be dropped please?
[16:48] <gQuigs> chrisccoulson: any thoughts on Flash for 20.04? https://discourse.ubuntu.com/t/ubuntu-20-04-and-flash/13814/2
[16:49] <gQuigs> also (only slightly related as they both let me write a cleaner apparmor profile) - is the shell script still needed? https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1860734
[16:50] <oSoMoN> gQuigs, I need to look into that one
[17:39] <hellsworth> when a user contacts the team members for a package (libreoffice in this case), their email presumably goes to several people besides myself. In my email it looks like this one person emailed me so there's no reply all. so how should i respond so that the other team members see the response (and know it's already been responded to)?
[17:50] <marcustomlinson> hellsworth: good question, as far as I know there's no way to do this. The sender may receive multiple replies to the same question. oSoMoN is this correct?
[17:51] <marcustomlinson> I mean, you could manually cc everyone from here: https://launchpad.net/~libreoffice/+members#active
[17:51] <marcustomlinson> the admins I mean
[17:51] <hellsworth> yeah i thought about manually cc'ing folks but i thought there might be a better way or maybe the other team members were already somehow alerted
[17:52] <hellsworth> ok i'll manually cc in the future
[17:52] <hellsworth> marcustomlinson: oSoMoN I've already responded to Hildo (subject: Ubuntu 16.04)
[17:53] <doko> yes, everybody gets the email, appearing to be sent directly to you
[17:53] <hellsworth> fyi, i plan to respond to all of the libreoffice inquiries as they come in. i don't want you two to worry about them unless I need help answering a question
[17:53] <hellsworth> doko: yes but then no one knows that it's been responded to already by one of the other team members
[17:53] <marcustomlinson> thanks hellsworth
[17:54] <marcustomlinson> hellsworth: when people ask about newer versions of libreoffice on previous releases of ubuntu (as is 90% of these messages), you can punt the snap
[17:54] <doko> that's LP ...
[17:55] <doko> or CC the list on your replies
[17:56] <hellsworth> marcustomlinson: yup that's what i'm seeing/doing so far :)
[17:56] <hellsworth> but i will start cc'ing the list
[18:02] <oSoMoN> hellsworth, that sounds like a good plan, thanks for taking this on!
[18:10] <hellsworth> my pleasure
[18:32] <marcustomlinson> hellsworth: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libreoffice
[18:32] <marcustomlinson> \o/
[18:33] <marcustomlinson> finally libreoffice should start unblocking stuff
[18:33] <hellsworth> woo!
[18:33] <hellsworth> yeah i had this tab pinned, waiting for the results :)
[18:34] <hellsworth> why does it say armhf passed when the tests were skipped?
[18:34] <hellsworth> it looks like the tests on armhf actually ran
[18:34] <marcustomlinson> hellsworth: "ran"
[18:35] <hellsworth> well they "ran" for 5 hours
[18:35] <marcustomlinson> hellsworth: oh yeah the tests ran, I just disabled 3
[18:35] <marcustomlinson> all the others ran as normal
[18:36] <marcustomlinson> there's something up with extensions on armhf
[18:37] <marcustomlinson> hellsworth: you have a todo for this right?
[18:37] <hellsworth> oh i see
[18:37] <hellsworth> i do. i created a trello card
[18:37] <marcustomlinson> cool
[18:37] <marcustomlinson> thanks
[18:39] <hellsworth> do you want me to add you to it?
[18:39] <hellsworth> i figured not
[18:43] <hellsworth> marcustomlinson: i just learned about https://launchpad.net/~libreoffice/+archive/ubuntu/ppa
[18:43] <hellsworth> how can i update it?
[18:43] <hellsworth> i would like to be able to update the description
[18:44] <hellsworth> or is this maintained by rictoz?
[18:50] <marcustomlinson> hellsworth: yes that's ricot_z
[18:51] <marcustomlinson> hellsworth: you can contribute if you wish of course
[18:52] <hellsworth> ok thanks
[18:57] <marcustomlinson> okidokes, I'm off. good evening all
[18:57] <kenvandine> hellsworth: epiphany in the candidate channel was built with the gnome-3-34 extension
[18:58] <hellsworth> wat that's awesome!
[18:58] <hellsworth> i still haven't worked my way back to epiphany yet today
[18:58] <kenvandine> automated builds will of course fail...
[18:58] <hellsworth> sure
[18:58] <kenvandine> i triggered a build with the right version of snapcraft
[18:58] <hellsworth> oh also gnome-3-34-1804-sdk in candidate has mm-common and gtkmm in it
[18:58] <kenvandine> hellsworth: so it is built on LP
[18:58] <hellsworth> nice!!!!!
[18:58] <kenvandine> hellsworth: oh... awesome
[18:59] <hellsworth> i intend to try snapping gnome-system-monitor with it to try it out
[18:59] <hellsworth> maybe today
[18:59] <hellsworth> idk
[18:59] <hellsworth> too many things to do
[18:59] <kenvandine> cool
[18:59] <kenvandine> :)
[18:59] <hellsworth> :)
[18:59] <kenvandine> hellsworth: did you look at tweaking LD_LIBRARY_PATH in the extension?
[18:59] <kenvandine> to add $SNAP/gnome-platform/usr/lib
[19:00] <hellsworth> no. i made a note to do it.
[19:00] <kenvandine> cool
[19:00] <hellsworth> been looking at LO bugs, usn refreshes, responding to LO queries, trying to dig through email
[19:00] <kenvandine> understood
[19:00] <kenvandine> good progress though
[19:01] <hellsworth> thanks
[19:01] <hellsworth> little by little :)
[19:55] <ricotz> hellsworth, hi :), please leave those backport to me
[19:55] <hellsworth> ricotz: okey dokey :)
[19:55] <hellsworth> thanks
[19:56] <hellsworth> i was more just trying to make sure i wasn't missing something that i was supposed to be doing
[19:56] <hellsworth> still learning the LO land :)
[21:34] <hellsworth> kenvandine: i built snapcraft with the added LD_LIBRARY_PATH, installed it, and am building epiphany now. fingers crossed :)
[21:35] <hellsworth> i'm also building gnome-system-monitor with the gnome-3-34 extension too :)
[21:39] <kenvandine> hellsworth: cool
[21:47] <hellsworth> turns out that gtkmm is not actually in the build snap because i still had snapcraftctl build still commeted
[21:47] <hellsworth> 🤦
[21:56] <rodicio> test
[21:56] <rodicio> Hi. Anyone speak Spanish?
[23:55] <doko> marcustomlinson: libreoffice-gtk still depends on libreoffice-gtk2 which isn't built anymore


[13:26] <cddd> how can i find 32 bit version
 Try debian, no 32 lubuntu version after 18.04 lts and 18.10. (re @lubuntu_bot: (irc) <cddd> how can i find 32 bit version)


[16:46] <stormchaser3000_> hello. i am running ubuntu gnome and snapd wont configure when running apt upgrade
[16:46] <stormchaser3000_> no error message displayed
[16:46] <stormchaser3000_> just sits there with "Setting up snapd (2.16ubuntu3) ..."
[16:50] <stormchaser3000_> i tried removing snapd and installing it but i just get the hting that tells me to configure the unconfigured packages


[00:31] <yofel> penguin42: if it's completely transparent then the blur effect is probably not working. An alternative would be a different plasma theme if blur doesn't work
[00:31] <penguin42> yofel: It's bluring, but the problem is it's just blurring black, so getting no contrast
[00:32] <yofel> meh
[00:33] <penguin42> yofel: The font in the menu is black, and being mostly transparent whatever colour it's going to be it's going to be the wrong one
[00:35] <yofel> now I wonder if we really don't have a setting to disable transparency in plasma themes o.O
[00:36] <yofel> disabling effects completely isn't much of a workaround
[00:39] <penguin42> yofel: Hmm interesint
[00:39] <penguin42> My Desktop theme is air, yet the 'Translucent background' bit was set to Oxygen transparent background
[00:39] <yofel> o.O
[00:40] <yofel> I was just going to ask, because Air is at worst dark-grey here on Konsole
[00:40] <penguin42> and that's a lot better; it's only a vaguely transparent menu - where as the Oxygen one was frankly well almost transparent
[00:40]  * penguin42 wonders hth that happened
[00:41] <yofel> set and forget? ^^
[00:41] <penguin42> I don't even remember seeing that section, so it's possible I forgot it really well
[02:19] <Bluefoxicy> well
[02:20] <Bluefoxicy> puppet 3.0 won't go into Debian Sid until after the next release
[02:20] <Bluefoxicy> because they're in feature freeze for their next stable
[02:20] <Bluefoxicy> this seems dumb.  If you update unstable, you cannot have a separate update that goes into testing
[02:28] <yofel> and putting it into experimental isn't an option?
[13:56] <BluesKaj> Hey all
[13:56] <penguin42> Hey BK
[14:08] <san> Hi Huys
[14:08] <san> *Guys
[14:08] <san> unity help required?
[14:09] <san> my Unity is broken with gnome 3.7.4
[14:09] <san> any way to resolve it?
[16:21] <Bluefoxicy> http://anonscm.debian.org/gitweb/?p=pkg-puppet/puppet.git;a=summary  AHA@!
[21:08] <Phosphate> Does anyone have experience with 13.04 on a Nexus 7? Is it possible to use the soft keyboard during setup or do you need a micro usb host adapter for a keyboard?
[22:42] <ironhalik> anyone can tell me anything about 13.04 battery life as compared to 12.10?