| sinzui | wgrant: mumble? | 00:03 |
|---|---|---|
| jcsackett | wallyworld: bug 707234 | 00:10 |
| _mup_ | Bug #707234: Ajax controls disabled on bugs with many tasks due to multiple redundant copies of person picker make_picker function in view-source:https://bugs.launchpad.net/launchpad-project/+bugs?advanced=1 <disclosure> <javascript> <person-picker> <regression> <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/707234 > | 00:10 |
| sinzui | wallyworld: jcsackett: StevenK: http://www.markshuttleworth.com/wp-content/uploads/2008/12/link-blueprint_web-version2.swf https://devpad.canonical.com/~beuno/ui_movies/Search%20Packages.1.swf https://devpad.canonical.com/~beuno/ui_movies/Subscribe_create_team_3.swf | 00:17 |
| sinzui | wgrant: ^ | 00:39 |
| * wallyworld off to bank to try and get working credit card | 00:40 | |
| StevenK | Hah | 00:41 |
| wgrant | poolie: Hi. | 00:41 |
| * StevenK attempts to work out when his SSL certificates expired. | 00:41 | |
| wgrant | StevenK: Going back to Friday, was DSP the only extra perm required? | 00:42 |
| LPCIBot | Project windmill-devel build #215: STILL FAILING in 1 hr 13 min: https://lpci.wedontsleep.org/job/windmill-devel/215/ | 00:43 |
| StevenK | wgrant: It seemed to be, yes. | 00:44 |
| * wgrant qa-oks | 00:44 | |
| wgrant | abentley: Hi. | 00:50 |
| wgrant | abentley: It the 500 on some error cases the only reason bug #776449 is qa-bad? | 00:51 |
| _mup_ | Bug #776449: Set Ubuntu dependencies for PPA via API <api> <bad-commit-13157> <escalated> <not-pie-critical> <oem-services> <ppa> <qa-bad> <Launchpad itself:Fix Committed by abentley> < https://launchpad.net/bugs/776449 > | 00:51 |
| LPCIBot | Project parallel-test build #33: STILL FAILING in 1 hr 11 min: https://lpci.wedontsleep.org/job/parallel-test/33/ | 00:53 |
| jtv | Morning paduans | 01:18 |
| wgrant | Morning jtv. | 01:21 |
| jtv | hi1 | 01:22 |
| wgrant | Aherm. | 01:27 |
| wgrant | The new picker has a bug. | 01:27 |
| wgrant | Everyone seems to have all IRC nicks. | 01:27 |
| wgrant | I guess the preloading is buggy. | 01:27 |
| wgrant | nicks_by_person = dict((nick.personID, nicks) | 01:28 |
| wgrant | for nick in nicks) | 01:28 |
| wgrant | Oops. | 01:28 |
| mwhudson | haha | 01:29 |
| LPCIBot | Project windmill-db-devel build #387: STILL FAILING in 1 hr 18 min: https://lpci.wedontsleep.org/job/windmill-db-devel/387/ | 02:02 |
| LPCIBot | Yippie, build fixed! | 02:04 |
| LPCIBot | Project db-devel build #632: FIXED in 5 hr 53 min: https://lpci.wedontsleep.org/job/db-devel/632/ | 02:04 |
| wallyworld | wgrant: what's the problem with the nicks? | 02:06 |
| wgrant | wallyworld: The preloading preloads all of the found nicks into everyone that is found to have a nick. | 02:07 |
| wgrant | So if the batch has two people with nicks, both of them will have all of the nicks. | 02:07 |
| LPCIBot | Project windmill-devel build #216: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-devel/216/ | 02:08 |
| wgrant | Bug #796889 | 02:08 |
| _mup_ | Bug #796889: ValidPersonOrTeamVocabulary preloads all IRC nicks into everybody <disclosure> <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/796889 > | 02:08 |
| wallyworld | i can't see how? the lines you refer to above set up a dict used by the lines that follow to preload the cache | 02:08 |
| wgrant | wallyworld: (nick.personID, nicks) | 02:08 |
| wgrant | wallyworld: It creates a dict mapping each nick's person to the whole set of nicks. | 02:09 |
| wallyworld | ah. shit. | 02:09 |
| wgrant | Heh | 02:09 |
| wallyworld | that should be *nuck* | 02:09 |
| wallyworld | nick | 02:09 |
| wallyworld | without the s | 02:09 |
| wgrant | That won't quite work either. | 02:09 |
| wgrant | Since that will only allow one for each. | 02:09 |
| wallyworld | yep. can't argue there. | 02:10 |
| wallyworld | something was in the coolaid that day :-( | 02:10 |
| LPCIBot | Project devel build #801: FAILURE in 5 hr 24 min: https://lpci.wedontsleep.org/job/devel/801/ | 03:04 |
| abentley | wgrant: yes. | 03:12 |
| wgrant | abentley: Great, thanks. | 03:13 |
| poolie | hi wgrant, all | 03:35 |
| wgrant | poolie: Hi. Was going to check with you on QA for your librarian email fix, but I think I did it. | 03:35 |
| poolie | you think you did the qa? | 03:47 |
| wgrant | Yes. | 03:48 |
| poolie | thanks! | 03:48 |
| poolie | +filebug seems pretty screwed | 03:48 |
| poolie | https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1991BA20 | 03:48 |
| poolie | cannot get throuh at all | 03:48 |
| wgrant | Erk. | 03:50 |
| wgrant | BugSummaryJournal contention. | 03:51 |
| wgrant | lifeless: Have you seen that before? | 03:51 |
| wgrant | A timeout on a BSJ INSERT during a BugTask INSERT. | 03:52 |
| wgrant | (but +filebug worked fine for me earlier) | 03:52 |
| wgrant | But there's no UNIQUE :/ | 03:53 |
| wgrant | Must be a table lock somewhere... | 03:53 |
| poolie | that's like ~20 failures over 20 minutes | 03:54 |
| poolie | unless this is just me, i think it's whatevers-above-critical | 03:54 |
| wgrant | It's not just you, and it's not just Ubuntu. | 03:57 |
| wgrant | lifeless: Do you know what was cowboyed? | 03:57 |
| wgrant | lifeless: BugSummaryJournal is somewhat stuck. | 03:58 |
| lifeless | wgrant: how do you mean? | 03:59 |
| wgrant | lifeless: We are seeing dozens of timeouts inserting into BugSummaryJournal. | 03:59 |
| lifeless | wgrant: all of bsj was cowbowed | 03:59 |
| wgrant | lifeless: All *what*? | 03:59 |
| wgrant | Is it exactly what was landed? | 03:59 |
| lifeless | wgrant: except the appserver code to query (read only, always) when doing tag portlets | 03:59 |
| lifeless | the schema, triggers | 04:00 |
| wgrant | 202 timeouts of this kind in the last two hours. | 04:00 |
| wgrant | Three hours. | 04:00 |
| lifeless | thats a problem | 04:01 |
| lifeless | we've done the ndt now right ? | 04:01 |
| wgrant | It doesn't seem to be done yet. | 04:01 |
| lifeless | did this start before the ndt ? | 04:01 |
| wgrant | Ah, the appservers have updated in the last 5 minutes. | 04:01 |
| wgrant | They were not updated when the problem started. | 04:01 |
| wgrant | Let me find the first occurrence. | 04:01 |
| wgrant | There were none yesterday, it seems. | 04:02 |
| lifeless | ok | 04:02 |
| wgrant | chaenomeles/2011-06-14/05755.AR6:Date: 2011-06-14T01:35:55.028700+00:00 | 04:03 |
| wgrant | First occurrence. | 04:03 |
| lifeless | oops id ? | 04:03 |
| wgrant | It's in the path | 04:04 |
| wgrant | AR6 | 04:04 |
| wgrant | Today. | 04:04 |
| wgrant | To OOPS-1991AR6 | 04:04 |
| wgrant | s/To/So | 04:04 |
| LPCIBot | Project parallel-test build #34: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/parallel-test/34/ | 05:05 |
| wgrant | Does someone feel like reviewing https://code.launchpad.net/~wgrant/launchpad/bug-796889/+merge/64490? | 05:12 |
| StevenK | wgrant: Nice work, r=me | 05:14 |
| wgrant | Thanks. | 05:17 |
| === Ursula is now known as Ursinha | ||
| LPCIBot | Project windmill-db-devel build #388: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill-db-devel/388/ | 05:34 |
| === wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 204 - 0:[######=_]:256 | ||
| LPCIBot | Project windmill-devel build #217: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill-devel/217/ | 06:13 |
| wgrant | Looks like codeimports have almost caught up. | 06:22 |
| wgrant | And the failure counts are still small. | 06:22 |
| wgrant | This is nice. | 06:22 |
| LPCIBot | Project windmill-devel build #218: STILL FAILING in 44 min: https://lpci.wedontsleep.org/job/windmill-devel/218/ | 06:58 |
| wgrant | We need a faster test suite. | 07:08 |
| === michaelh1 is now known as michaelh1|away | ||
| lifeless | wgrant: I'm amazed that that picker passed qa with those seqscans | 07:23 |
| nigelb | can I run my own launchpad in ec2 and talk to it? Purely for testing applications that use launchpad data where I don't want to mess up real launchpad. | 07:24 |
| StevenK | nigelb: ec2 demo | 07:24 |
| nigelb | StevenK: there's a script? | 07:24 |
| lifeless | that may be broken, but yeah thats the idea | 07:25 |
| wgrant | lifeless: I knew it was slow, but decided it might just be qas. And it was behind flags and didn't time out too much. | 07:25 |
| lifeless | or you can mess up qastaging as much as you like | 07:25 |
| wgrant | nigelb: You could also use a local instance, or staging or qastaging. | 07:25 |
| StevenK | nigelb: Sure, bin/ec2 demo from a local branch that is pushed | 07:25 |
| lifeless | wgrant: rule 34: its never just [qa]staging | 07:25 |
| wgrant | lifeless: Sure, but given it was behind flags I decided not to investigate. | 07:25 |
| nigelb | wgrant: I want to set it up so that developers working on the community projects can mess up with the same install. | 07:25 |
| lifeless | oh, I missed that. cool. | 07:25 |
| lifeless | wgrant: nice work teal | 07:25 |
| StevenK | nigelb: *Expensive* | 07:26 |
| StevenK | nigelb: Like, hellishy | 07:26 |
| nigelb | StevenK: Oh. :( | 07:26 |
| nigelb | StevenK: Lp takes a ton of ram? | 07:26 |
| nigelb | ram/cpu cycles | 07:26 |
| wgrant | lifeless: ValidPersonOrTeamVocabulary has three variants now. | 07:26 |
| StevenK | nigelb: We run the LP test suite on c1.xlarge instances. $300+ a month | 07:27 |
| nigelb | Oh :| | 07:28 |
| StevenK | nigelb: I'd point developers at qastaging, personally | 07:28 |
| nigelb | StevenK: I asked jml about that at UDS. | 07:28 |
| nigelb | StevenK: basically, we want to mess up with sprints, which we don't have permissions for. | 07:28 |
| nigelb | And since staging and qastaging data is cleared every few weeks, we'll need to keep asking for permissions in either of them | 07:29 |
| StevenK | staging is every week | 07:29 |
| StevenK | qastaging is ... an interesting question | 07:30 |
| nigelb | I use my own launchpad. I was just wondering if I can run a common install. Apparently not :) | 07:31 |
| nigelb | *launchpad instance | 07:31 |
| StevenK | nigelb: You can, for a few hours | 07:31 |
| StevenK | After that, it gets expensive | 07:31 |
| lifeless | wgrant: 3? | 07:32 |
| nigelb | I guess its just easier to run your own launchpad instance. | 07:32 |
| StevenK | nigelb: That $300+ figure is running an instance in ec2 for the entire month | 07:32 |
| lifeless | nigelb: huh, sprints - create a custom project of your own | 07:32 |
| lifeless | nigelb: on qastaging | 07:32 |
| lifeless | nigelb: then you can fiddle with sprints for it to your hearts content | 07:32 |
| wgrant | lifeless: The affiliation rank stuff is under a second flag, in case we wanted to deploy the other improvements while tweaking this. | 07:32 |
| nigelb | \o/ | 07:32 |
| wgrant | lifeless: Of course the affiliation stuff is fine, it's the rest that's buggy :P | 07:33 |
| nigelb | lifeless: thanks. doh. why didn't I think of this. | 07:35 |
| lifeless | nigelb: so you can run one on ec2 if you really want, though if its public acccess you'd need to rebrand it :( - but yeah, qastaging should meet your needs Just Fine | 07:36 |
| nigelb | lifeless: Oh rebranding. I don't event want to go there, too painful :-) | 07:37 |
| StevenK | wgrant: Up for reviewing a short branch of mine? | 07:38 |
| wgrant | StevenK: Sure. | 07:38 |
| wgrant | Ah, diff there already. | 07:39 |
| wgrant | Handy. | 07:39 |
| StevenK | Sorry, was just linking a bug. | 07:39 |
| wgrant | StevenK: I'm not sure we really want to link to that page. | 07:40 |
| === lifeless changed the topic of #launchpad-dev to: Performance Tuesday ! | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 204 - 0:[######=_]:256 | ||
| wgrant | It's pretty crap. | 07:40 |
| wgrant | Particularly for private PPAs, where the technical details section is a bunch of lies. | 07:40 |
| === lifeless changed the topic of #launchpad-dev to: Performance Tuesday ! | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 202 - 0:[######=_]:256 | ||
| wgrant | StevenK: We could possibly link to it from +archivesubcriptions. | 07:41 |
| wgrant | lifeless: Huh, where'd those two go? | 07:41 |
| lifeless | wgrant: http://webnumbr.com/launchpad-critical-bugs is what I'm tracking | 07:41 |
| wgrant | Oh. | 07:41 |
| wgrant | Excludes private ones. | 07:41 |
| wgrant | Right. | 07:41 |
| lifeless | yes | 07:41 |
| lifeless | gone | 07:41 |
| StevenK | wgrant: It was the only good solution that occured, and it sucks. | 07:42 |
| nigelb | Bah, no creampie I guess | 07:43 |
| nigelb | erm | 07:43 |
| nigelb | cream pie on the face. | 07:43 |
| wgrant | StevenK: I don't think it's beneficial. | 07:44 |
| wgrant | Do you? | 07:44 |
| StevenK | I don't think the e-mail is beneficial at all, but sladen obviously thinks it adds value. | 07:45 |
| wgrant | A lot of people think that a lot of things add value. | 07:45 |
| LPCIBot | Project windmill-devel build #219: STILL FAILING in 41 min: https://lpci.wedontsleep.org/job/windmill-devel/219/ | 07:57 |
| rvba | wgrant: Hi William, I've got an MP that really could use your Soyuz expertise ... could you review it? (If you cannot do it I'll grab someone else ;)) | 08:00 |
| rvba | https://code.launchpad.net/~rvb/launchpad/init-series-bug-789091-devel/+merge/63676 | 08:00 |
| wgrant | Wow that is large. | 08:00 |
| wgrant | Hmmm, so we now have 'sequence', 'ordering' and 'priority' as different names for the same concept :/ | 08:01 |
| StevenK | rvba: But this MP still doesn't address the second use-case for IDS? | 08:01 |
| rvba | StevenK: wgrant that's right, the second use case is in a second branch (almost ready) | 08:02 |
| rvba | StevenK: https://code.launchpad.net/~rvb/launchpad/init-series-bug-789091-previous-series/+merge/64414 | 08:02 |
| StevenK | "will be *derived* from the previous_series' parents." | 08:03 |
| rvba | StevenK: and the UI fix for the second use case is in a third branch. | 08:03 |
| StevenK | That makes me very nervous. | 08:03 |
| StevenK | It *should* be derived from previous_series. Only. | 08:03 |
| rvba | StevenK: you're right, it is only the doc that is wrong. | 08:04 |
| rvba | wgrant: I confess this branch has been a real work for me, so don't hesitate to recommend any fixing you'd like to see. It's a big branch so if you agree to review it, I'd be happy to follow your advices to fix it, even if they are plenty ;) | 08:08 |
| wgrant | rvba: I am reading it. | 08:09 |
| rvba | wgrant: thanks a lot. | 08:09 |
| wgrant | rvb: "In result, in case the same package exists in multiple parents, the package from the first parent with this package is the one that will end up in the derived series." | 08:09 |
| wgrant | rvba: That's different from the rest of the behaviour. | 08:10 |
| wgrant | Where the highest version tends to win. | 08:10 |
| wgrant | At least for overlays. | 08:10 |
| wgrant | I don't know how it behaves for non-overlays. | 08:10 |
| rvba | wgrant: right, Julian says it was good enough for now and we could fix this later if we need to .... but that's a good point ... | 08:11 |
| rvba | I'm not sure we can come up with a solution to take the highest version with simple sql queries though ... | 08:11 |
| wgrant | They'd get fairly nasty, yeah. | 08:12 |
| rvba | And this initialisation thing already takes a rather long time to run sometimes. | 08:12 |
| rvba | The advantage of this is that it's pretty simple. | 08:13 |
| lifeless | back | 08:17 |
| rvba | StevenK: doc fixed. MP needs review ;). | 08:27 |
| adeuring | good morning | 08:34 |
| LPCIBot | Project db-devel build #633: FAILURE in 6 hr 36 min: https://lpci.wedontsleep.org/job/db-devel/633/ | 08:41 |
| wgrant | rvba: I've made a first attempt at it. | 08:48 |
| rvba | wgrant: thanks! | 08:49 |
| allenap | wgrant: Thanks for QAing my stuff over(my)night. And for all the other times you've done it :) | 08:52 |
| LPCIBot | Project parallel-test build #35: STILL FAILING in 39 min: https://lpci.wedontsleep.org/job/parallel-test/35/ | 08:55 |
| LPCIBot | Launchpad Patch Queue Manager: [r=benji][bug=746379] Update the "Latest message" column in | 08:55 |
| LPCIBot | DistroSeries:+localpackagediffs when a comment is added in the | 08:55 |
| LPCIBot | expander. | 08:55 |
| rvba | wgrant: Yeah, thanks for that too ;) | 08:55 |
| lifeless | stub: hey, I saw some nice progress towards bugsummary-2 | 09:01 |
| stub | Yer. Triggers and functions written. If they worked, that would be great :-) | 09:01 |
| lifeless | stub: I've proposed nuking readonly mode on the list | 09:02 |
| stub | upstream bug fixes are not sticking atm. need to look at it today. | 09:02 |
| stub | lifeless: I'm just responding. | 09:02 |
| lifeless | cool | 09:02 |
| lifeless | stub: How would we fix having to restart appservers, and the time to rebuild the replica after schema change ? | 09:08 |
| stub | Appservers could automatically failover when the master db connection is unavailable, and automatically switch back when it is available. | 09:09 |
| lifeless | I think thats a different thing isn't it? | 09:09 |
| stub | At the moment it is a manual switch. | 09:09 |
| stub | At the moment we break out the replica from the cluster so we can upgrade the whole cluster. We could leave it in the cluster, but shut down its replication daemon. | 09:10 |
| lifeless | stub: I realised something the other day - the slave rebuild is contributing to our bloat | 09:11 |
| stub | If we then had smarter scripts, instead of detecting 'the cluster is in sync' we would detect 'the nodes we care about for now are in sync', we could do the upgrade live. When done, we bring the dead daemon back and the readonly node should then get the updates applied. | 09:12 |
| stub | lifeless: Yes, it does. | 09:12 |
| lifeless | stub: so, the core of the proposal I am making is 'lets focus on minimal actual downtime'; if we get buyin on doing that (and so far responses have been positive); and if we decide the best way to do that is to leave the readonly codepaths in the appservers - thats fine with me. | 09:13 |
| === michaelh1|away is now known as michaelh1 | ||
| stub | Right. I'd rather not invest time in making RO mode better if we only care about it as a failover mode, because making the extra complexity reliable will be a lot of work and probably cause downtime as we learn. | 09:14 |
| lifeless | exactly | 09:15 |
| lifeless | stub: I'd like to aim for 4-5 second downtime windows | 09:15 |
| lifeless | stub: if we reconfigure-db-connections; kill all current backends (except slony); apply patches; reconfigure-db-connections again | 09:16 |
| mrevell | Hello! | 09:16 |
| lifeless | stub: based on our previous discussions it seems to me we can get pretty darn close | 09:17 |
| stub | We are not a credit card processing system losing thousands of dollars a minute of downtime, and doing real HA is expensive. | 09:19 |
| stub | Right. So better to just pause things in HAProxy. | 09:19 |
| stub | And deal with an exploded master with real downtime if the master explodes. | 09:19 |
| stub | Yer. Appservers need to get more intelligent though and learn to switch themselves over live. | 09:19 |
| lifeless | stub: I wouldn't even pause in haproxy | 09:19 |
| lifeless | stub: its another moving part to change and deal with | 09:19 |
| stub | We could possibly pause everything in pgbouncer | 09:19 |
| lifeless | certainly | 09:20 |
| lifeless | thats something we can iterate towards or even do upfront | 09:20 |
| lifeless | I'm kindof of hopeful to be able to start doing this next week | 09:20 |
| stub | Sounds excellent since I'm on holiday next week ;) | 09:20 |
| lifeless | bleep | 09:21 |
| lifeless | ok, week after :> | 09:21 |
| lifeless | I'd like you around for the first few times | 09:21 |
| stub | I hear there is a sprint on or something | 09:21 |
| lifeless | till we get the quirks out | 09:21 |
| nigelb | My inbox seems to thinki any mail from lifeless is Priority Inbox mail. Interesting. | 09:21 |
| lifeless | good inbox | 09:22 |
| stub | After a while of trying to train it, I realized that there is no such thing as priority email ;) | 09:22 |
| nigelb | It works okay for me so far. Mostly. | 09:22 |
| * stub runs off to the ATM and to grab blinner | 09:25 | |
| lifeless | blinner?! | 09:25 |
| bigjools | I'm guessing he's *really* hungry | 09:27 |
| LPCIBot | Project windmill-db-devel build #389: STILL FAILING in 49 min: https://lpci.wedontsleep.org/job/windmill-db-devel/389/ | 09:31 |
| LPCIBot | Yippie, build fixed! | 09:44 |
| LPCIBot | Project devel build #802: FIXED in 6 hr 40 min: https://lpci.wedontsleep.org/job/devel/802/ | 09:44 |
| * bigjools reads lifeless's wall of email | 09:54 | |
| lifeless | one more coming up | 09:57 |
| bigjools | lifeless: it might be helpful if you could format the emails into distinct sections, I usually end up re-reading your emails as it's hard to take 'em all in in one go | 09:58 |
| lifeless | bigjools: thats good to know - I do sometimes, but I kindof run into 'is this an email or a wiki page' feeling sometimes too | 09:58 |
| bigjools | lifeless: they do read like a steam of consciousness :) | 09:59 |
| bigjools | stream* | 09:59 |
| lifeless | well, I do edit and shuffle and so on; trying to paint a narrative | 09:59 |
| lifeless | my head is nowhere near as organised | 09:59 |
| === almaisan-away is now known as al-maisan | ||
| bigjools | lifeless: in any case, I've been wanting to sort out the schema change downtime story for a loooong time | 10:02 |
| bigjools | most schema changes don't involve interdependent code | 10:02 |
| jtv | gmb: got time for a review? I have two MPs ready including https://code.launchpad.net/~jtv/launchpad/bug-791204/+merge/64390 | 10:14 |
| gmb | jtv: I'm just working on one for danilos, but I'll take a look when I'm done with that. | 10:15 |
| === gmb changed the topic of #launchpad-dev to: Performance Tuesday ! | https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugs: 202 - 0:[######=_]:256 | ||
| stub | A steaming pile of consciousness | 10:15 |
| jtv | great, thanks | 10:15 |
| jtv | A stream of <garble>ss | 10:16 |
| jtv | (Just for the sake of the play on words of course, not my actual opinion!) | 10:17 |
| gmb | danilos: Accepting your "it is thoroughly tested" assertion, r=me. | 10:20 |
| gmb | (Although the evidence for that is pretty strong, I'll grant you) | 10:20 |
| danilos | gmb, heh, thanks :) | 10:20 |
| danilos | gmb, after you get relaxed a bit with the one from jtv (ha), you can pick the following one from me as well: https://code.launchpad.net/~danilo/launchpad/bug-772754-other-subscribers-loading/+merge/64186 (that one is oversized a bit though, hope you don't mind) | 10:22 |
| jtv | danilos: hey hey hey, I had _two_! | 10:22 |
| gmb | danilos: jtv speaks the truth. But I'll try to come to yours early this afternoon. | 10:22 |
| jtv | This could be a fun exercise in scheduling algorithms | 10:23 |
| danilos | jtv, hey, I had three but didn't want to take all the available "room" for others to get their code reviewed :) | 10:23 |
| danilos | jtv, unlike, ahem, some other people | 10:23 |
| lifeless | jtv: the docstrings for match_exact_string etc are misleadning | 10:23 |
| lifeless | jtv: the :return: is incorrect - it returns a storm expression whose result will be True if ... | 10:23 |
| jtv | danilos: hey, if you leave room for other people, don't get all disappointed when other people use it! | 10:23 |
| jtv | thanks lifeless — I'll have a look right away. | 10:24 |
| lifeless | jtv: (AIU the code) | 10:24 |
| gmb | danilos, jtv : http://oo00.eu/ | 10:24 |
| gmb | Anyway. | 10:24 |
| jtv | lifeless: ISWM—you're right | 10:24 |
| jtv | danilos: we've just heard the URL of the banshee. | 10:24 |
| jtv | Go on, ask for whom the bell tolls: it tolled for chromium! | 10:25 |
| jtv | It died. | 10:25 |
| danilos | jtv, gmb: :) | 10:26 |
| lifeless | allenap: hi | 10:26 |
| lifeless | allenap: rabbit: do we reset SIGPIPE when spawning it ? | 10:26 |
| bigjools | lifeless: he's out for a bit, will be back soon | 10:30 |
| lifeless | thanks | 10:31 |
| danilos | jtv, I've been hitting a lot of webkit crashes with epiphany lately, but just on this computer (even though it's identical arch to my laptop and all the same versions are used) | 10:31 |
| danilos | jtv, so I just figured out it's probably your fault and learned to live with it (or maybe hardware, but it's so much nicer to blame you again) | 10:32 |
| jtv | danilos: agreed, it makes perfect sense given that I see the same problem. | 10:33 |
| jtv | See that everyone? This is why I liked the transition to squads! :-) | 10:33 |
| danilos | basically the only reason, I am sure :) | 10:34 |
| jtv | oh yes | 10:34 |
| allenap | lifeless: I haven't done anything special with signals. | 10:38 |
| lifeless | http://bugs.python.org/issue1652 | 10:39 |
| bigjools | danilos: whatever the problem is, it's probably jtv's fault | 10:40 |
| jtv | All of a sudden I'm not so sure about this squads thing any more. | 10:40 |
| danilos | bigjools, glad to hear that, that's how it used to work in the previous team structure as well! | 10:41 |
| allenap | lifeless: That's a great find. I'll try that simple change. (I'll do it in a separate branch from the subprocess changes I made.) | 10:50 |
| lifeless | cool | 10:54 |
| gmb | jtv: r=me on your first branch; your tests need some comments though. | 11:03 |
| jtv | gmb: thanks, will do. I always try writing 'em clear enough that they don't need comments, but after that I don't mind adding them if they're still needed. :) | 11:03 |
| gmb | jtv: Well, I'm lazy, so I tend to say they all need comments otherwise I need to think. | 11:04 |
| jtv | I try to encode the whole story in the function name. :) | 11:04 |
| gmb | jtv: Oh, I know. And that often works. Sometimes though it requires context that I don't have to be able to understand the encoding. | 11:05 |
| jtv | Right — problem is it's very hard for the person who wrote a text to judge that, so that's where I rely heavily upon the reviewer. | 11:06 |
| StevenK | gmb: I have a short branch for you if you're free. | 11:14 |
| gmb | StevenK: Sadly, there's a queue at the moment. I may get to it later but I can't promise anything | 11:15 |
| StevenK | That's okay. I will beg bigjools, since he whinged at me about the bug. | 11:15 |
| StevenK | bigjools: https://code.launchpad.net/~stevenk/launchpad/reject-changes-file-no-email/+merge/64523 please | 11:18 |
| * gmb -> changing locations. BBIW. | 11:50 | |
| === henninge_ is now known as heninge | ||
| === al-maisan is now known as almaisan-away | ||
| jml | lifeless: ping | 12:16 |
| lifeless | hi | 12:17 |
| jml | lifeless: oh hi, was going to ask for a quick chat, but maybe we could do it tomorrow instead | 12:17 |
| lifeless | jml: tonight would be better; tomorrow night leads into thursday morning which is at an uncivilised time | 12:17 |
| lifeless | jml: I need to take recycling out and stuff like that, but in 15-20 I can chat with you | 12:17 |
| jml | lifeless: perfect. skype me when you're ready. | 12:18 |
| === heninge is now known as henninge | ||
| bac | hi bigjools | 13:05 |
| bigjools | bac: hey | 13:06 |
| bac | bigjools: could i have a mid-imp call with you re: bug 519857 | 13:06 |
| _mup_ | Bug #519857: Upload processor OOPSes with bad email addresses <lp-soyuz> <oops> <soyuz-upload> <Launchpad itself:In Progress by bac> < https://launchpad.net/bugs/519857 > | 13:06 |
| bigjools | bac: stevenk already fixed it. | 13:06 |
| bigjools | ah sorry | 13:07 |
| bigjools | no he didn't | 13:07 |
| bigjools | different bug! | 13:07 |
| bigjools | bac: so | 13:07 |
| bigjools | what needs to happen is that no oops gets thrown, and we send an email to whoever signed the changes file | 13:07 |
| bigjools | I just noticed you said mid-imp... | 13:08 |
| lifeless | bigjools: what did you mean by ' | 13:08 |
| lifeless | 21:02 < bigjools> lifeless: in any case, I've been wanting to sort out the schema change downtime story for a loooong time | 13:08 |
| lifeless | 21:02 < bigjools> most schema changes don't involve interdependent code | 13:08 |
| lifeless | ' | 13:08 |
| bac | bigjools: yeah, i was planning to catch the ParseMaintError in process() | 13:08 |
| bigjools | lifeless: we should be able to make schema changes on a live DB | 13:09 |
| bigjools | bac: in this case it's already sending a rejection for another reason | 13:10 |
| bigjools | bac: so we don't really need to do anything other than catch and ignore the error | 13:10 |
| bac | bigjools: what do you mean by "in this case"? | 13:10 |
| bigjools | bac: the traceback on the bug | 13:11 |
| bigjools | it's in the middle of processing a rejection | 13:11 |
| bigjools | which I also suspect is because a previous bit of code already noticed the bogus email address | 13:11 |
| bac | bigjools: i intended the code change to look something like: http://pastebin.ubuntu.com/626527/ | 13:12 |
| lifeless | bigjools: do you mean that most schema changes don't alter the meaning of existing fields, nor require new fields to be populated by appservers (at least initially) ? | 13:12 |
| lifeless | bigjools: if thats what you mean, I agree :) | 13:12 |
| bigjools | lifeless: yes! | 13:12 |
| bigjools | lifeless: and we should structure all our patches to be like that as much as possible | 13:12 |
| lifeless | bigjools: so there are some slony limits that make applying while truely live impossible today, but we can come close. | 13:13 |
| bigjools | bac: I would not do that | 13:13 |
| bac | bigjools: i think the code parts are easy. where i need some guidance is creating new package suite in lib/lp/archiveuploader/tests/data/suite | 13:13 |
| lifeless | bigjools: yes, if this proposal gets off the ground stub and I will start rejecting patches that are /not/ like that | 13:13 |
| bac | bigjools: ok | 13:13 |
| bigjools | bac: the code here has changed *significantly* since the bug was filed, because steve re-wrote the notification stuff | 13:15 |
| bac | bigjools: yes, that was obvious as nothing matched up | 13:15 |
| bac | bigjools: but the problem still exists | 13:15 |
| bigjools | bac: yes - what I would do is catch the error in lib/lp/soyuz/adapters/notification.py - get_recipients () | 13:16 |
| bigjools | and just not add any invalid emails to the recipient list | 13:16 |
| lifeless | benji___: lp:~benji/launchpad/bug-697735 seems to be deleting some db patches. .. | 13:16 |
| bigjools | the changesfile signer will always be valid if we get this far so that's the last-ditch option | 13:17 |
| === benji___ is now known as benji | ||
| bigjools | lifeless: excellent | 13:17 |
| bigjools | bac: "blamer" in that code is the signer | 13:17 |
| benji | lifeless: ooh, that doesn't sound right; thanks, I'll take a look | 13:17 |
| lifeless | benji: === removed file 'database/schema/patch-2208-63-0.sql' | 13:17 |
| lifeless | ... | 13:18 |
| bigjools | bac: so we need a test. For that we make a dodgy package and try to upload it. | 13:18 |
| bac | bigjools: yes, *that* is the part that i got hung up on yesterday | 13:18 |
| bigjools | bac: however thinking about it that's overkill for this case, so we could just do a unit test case for get_recipients | 13:18 |
| bac | bigjools: when i make a bad email address in the changes file i need to sign it | 13:19 |
| bac | bigjools: yes, that may be true now that i'll not be changing process() | 13:19 |
| bigjools | bac: right. fix get_recipients + unit test = simples. | 13:20 |
| bac | bigjools: if i did need to create a new test/data/suite are there any instructions on how to create and sign one? | 13:20 |
| bigjools | then we can QA it with an upload that has a dodgy maintainer | 13:20 |
| bigjools | bac: no :( but it's not too hard. | 13:20 |
| bac | bigjools: i couldn't find any keys, etc | 13:20 |
| bigjools | there's a private key in the tree | 13:20 |
| bigjools | you need to add it to your local keyring | 13:20 |
| bac | i found secring.gpg but it didn't have the right keys | 13:20 |
| bac | bigjools: ok, i'll go down that route and it should be much simpler | 13:21 |
| bigjools | bac: huh so it doesn't, that's odd. I have the key in my keyring, I should add it to the tree then. | 13:22 |
| bac | bigjools: win | 13:22 |
| bigjools | can't remember wtf I got it from! | 13:22 |
| bigjools | probably celso | 13:22 |
| bigjools | bac: ok cool, is that all you need? | 13:22 |
| bac | bigjools: part of soyuz's oral history | 13:22 |
| bac | bigjools: a-ok. thanks for your time. | 13:22 |
| bigjools | nae prob | 13:23 |
| lifeless | night all | 13:25 |
| bigjools | nn | 13:27 |
| * bigjools -> lunch | 13:27 | |
| jtv | gmb: got time for a really small one? It might be fun. https://code.launchpad.net/~jtv/launchpad/bug-797151/+merge/64537 | 13:36 |
| jtv | (It's lower priority than my other one though) | 13:37 |
| gmb | jtv: I'm still working through your other one - got distracted by vittles. I'll take a look after I've looked at Danilo's 900-liner, assuming I have time. | 13:38 |
| jtv | gmb: don't force yourself — the small one is really low-priority, but you might find it a nice "lite bite" after danilo's huge one | 13:39 |
| gmb | jtv: That's what I'm thinking :) | 13:39 |
| jtv | :) | 13:39 |
| LPCIBot | Project parallel-test build #36: STILL FAILING in 1 hr 12 min: https://lpci.wedontsleep.org/job/parallel-test/36/ | 13:55 |
| StevenK | bac, bigjools: I've already fixed the bug? | 14:05 |
| bigjools | StevenK: different bug, ignore | 14:05 |
| jml | brb | 14:29 |
| LPCIBot | Yippie, build fixed! | 14:36 |
| LPCIBot | Project db-devel build #634: FIXED in 5 hr 52 min: https://lpci.wedontsleep.org/job/db-devel/634/ | 14:36 |
| jml | ok. that was a confusing update. | 14:40 |
| bigjools | gmb: may I avail of your reviewership please: https://code.launchpad.net/~julian-edwards/launchpad/link-LCV-bug-783442/+merge/64550 | 15:01 |
| bigjools | ah cock seen some lint already | 15:01 |
| gmb | bigjools: I might be a while; working on a 900-liner from Danilo and then a smaller one from Jeroen, but I'll try to get to it before EoD. | 15:02 |
| bigjools | gmb: ok np | 15:02 |
| * danilos is happy gmb is ignoring the fact that it's nine hundred sixty something, which is closer to 1k ,) | 15:03 | |
| gmb | Sssssh. | 15:04 |
| bigjools | mine's a small branch :) | 15:04 |
| jml | mrevell: do you have any notes from any rounds of disclosure user testing? | 15:13 |
| mrevell | jml, Let me check what I have. | 15:18 |
| gmb | danilos: Your not-quite-1ker is approved :) | 15:42 |
| gmb | Now then, something smaller... | 15:43 |
| danilos | gmb, cool (I read that first as "you are not quite approved" :)) | 15:43 |
| gmb | Heh. | 15:43 |
| danilos | gmb, thanks again, I ain't bothering you with any more reviews then :) | 15:44 |
| gmb | danilos: Heh. I doubt I'll have the time or brain power for them anyway :). | 15:44 |
| james_w | flacoste, seen bug 797088? | 15:51 |
| _mup_ | Bug #797088: Launchpad has removed privileges that UDD importer requires to function <Launchpad itself:New> <Ubuntu Distributed Development:New> < https://launchpad.net/bugs/797088 > | 15:51 |
| flacoste | james_w: now, i did | 15:51 |
| flacoste | james_w: we just need to give core-dev permission to upload to Debian | 15:52 |
| flacoste | or make them a maintainer | 15:52 |
| flacoste | james_w: it's a configuration problem iow | 15:52 |
| james_w | flacoste, he reports a problem with lucid too? | 15:53 |
| flacoste | james_w: that would be surprising | 15:53 |
| james_w | flacoste, http://package-import.ubuntu.com/status/language-pack-nds.html#2011-06-14 14:45:28.882406 | 15:54 |
| james_w | maverick | 15:54 |
| flacoste | james_w: that script is still run as you, right? | 15:55 |
| flacoste | hmm | 15:55 |
| flacoste | it may be checkUpload permission that isn't getting this right | 15:55 |
| flacoste | actually, it might just be that | 15:56 |
| james_w | yep | 15:56 |
| flacoste | the easiest thing would be to make you a maintainer of both Ubuntu and Debian temporarily | 15:58 |
| gmb | bigjools: r=me | 15:58 |
| flacoste | that would solve the permission problem immediately | 15:58 |
| bigjools | gmb: ta | 15:59 |
| flacoste | bigjools: call time | 16:04 |
| flacoste | bigjools: https://launchpad.net/baltix/+series | 16:20 |
| flacoste | bigjools: you cut off | 16:25 |
| flacoste | bigjools: call me back | 16:26 |
| LPCIBot | Project windmill-devel build #220: STILL FAILING in 1 hr 7 min: https://lpci.wedontsleep.org/job/windmill-devel/220/ | 16:38 |
| benji | gmb: boo! I have a review for you: https://code.launchpad.net/~benji/launchpad/bug-697735-2/+merge/64563 | 16:39 |
| gmb | benji: Looking; waiting for the diff. | 16:40 |
| benji | gmb: cool | 16:40 |
| rvba | gmb: Thanks for the review! | 16:40 |
| gmb | rvba: np | 16:41 |
| gmb | benji: I got fed up of waiting for the scanner and looked at the revisions in loggerhead. r=me. Nice work. | 16:55 |
| benji | gmb: cool, thanks for the review | 17:03 |
| gmb | np | 17:03 |
| === lionel__ is now known as lionel | ||
| === gmb changed the topic of #launchpad-dev to: Performance Tuesday ! | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 202 - 0:[######=_]:256 | ||
| * gmb -> afk for a bit | 17:14 | |
| LPCIBot | Project windmill-devel build #221: STILL FAILING in 45 min: https://lpci.wedontsleep.org/job/windmill-devel/221/ | 17:23 |
| jml | I'm doing some LEP restructuring. Let me know if I'm getting in your way. | 17:50 |
| === matsubara is now known as matsubara-lunch | ||
| james_w | flacoste, maxb has a workaround that lessens the impact, but the importer will still be unable to deal with new packages, SRUs etc. | 18:10 |
| flacoste | james_w: i have a code solution | 18:26 |
| james_w | flacoste, cool | 18:26 |
| flacoste | for frozen series, we need to check the UPDATE pocket | 18:26 |
| james_w | flacoste, that will prevent setting official branches for obsolete series? | 18:27 |
| flacoste | probably | 18:27 |
| flacoste | i don't know | 18:27 |
| flacoste | actually | 18:27 |
| flacoste | i don't know the intimates of checkUpload | 18:27 |
| flacoste | but would that be a problem? | 18:27 |
| james_w | it sounds better than what we have, but I'm wondering if we actually want a different set of rules for this | 18:27 |
| flacoste | why should we care about obsolete series | 18:27 |
| flacoste | ? | 18:27 |
| james_w | c.f. changing the packaging links | 18:28 |
| james_w | well, the importer currently sets them up when it does the initial import of an old package | 18:28 |
| flacoste | it could simply not set them up | 18:28 |
| james_w | obviously most will be done already | 18:28 |
| james_w | it could | 18:28 |
| flacoste | obsolete is obsolete | 18:29 |
| james_w | do you still propose setting me/pkg_import to be maintainer of Debian? | 18:29 |
| flacoste | in a way | 18:29 |
| flacoste | either that | 18:29 |
| james_w | yeah, but it's still useful to easily refer to it sometimes | 18:29 |
| flacoste | but i think we should simply mirror the upload privileges from Ubuntu | 18:29 |
| james_w | obviously less useful over time | 18:29 |
| james_w | that sounds sensible | 18:29 |
| flacoste | jml: wow, LEP cleanup spree! nice! | 18:34 |
| flacoste | sinzui: call? | 18:35 |
| sinzui | starting mumble | 18:35 |
| * flacoste bets he's already in mumble | 18:35 | |
| flacoste | and lost | 18:35 |
| flacoste | sinzui: we are in mumble-not-working-first-time-land i think | 18:36 |
| flacoste | i'm hearing you | 18:36 |
| flacoste | but you are obviously | 18:36 |
| flacoste | i just did | 18:36 |
| jml | flacoste: yeah. only a little bit more to go. | 18:39 |
| jml | flacoste: you might want to look over https://dev.launchpad.net/Projects/DerivativeDistributions & add info | 19:02 |
| jml | flacoste: please feel free to do things like add columns or change structure | 19:03 |
| maxb | flacoste: Even if a series is obsolete, there is still some value in constructing a bazaar branch for its history and registering it with launchpad. We also still have a large number of "broken" imports that are being worked through, so retroactively producing history isn't an especially abnormal case. | 19:04 |
| jml | g'night all. | 19:17 |
| === matsubara-lunch is now known as matsubara | ||
| timrc | I'm having a head-scratching moment... I've modified lp/lib/soyuz/model/archive.py to turn "private" into a getter/setter and by doing this, I fail a test in lib/lp/soyuz/tests/test_processaccepted.py (test_accept_copy_archives:133, error: http://pastebin.ubuntu.com/626756/). This particular test runs lib/lp/soyuz/scripts/processaccepted.py which (when I look at output) returns a failure (https://code.launchpad.net/~timrchavez/l | 19:56 |
| timrc | aunchpad/set_ppa_private_from_api_724740-2/+merge/63950) -- I'm not sure if that's actually intended or not (looks like: http://pastebin.ubuntu.com/626766/), which begs the question: how can I retrieve the oops report from the id ? | 19:56 |
| === Ursula is now known as Ursinh | ||
| === Ursinh is now known as Ursinha | ||
| timrc | trying this again.. | 20:01 |
| timrc | I'm having a head-scratching moment... I've modified lp/lib/soyuz/model/archive.py to turn "private" into a getter/setter (https://code.launchpad.net/~timrchavez/launchpad/set_ppa_private_from_api_724740-2/+merge/63950) and by doing this, I fail a te | 20:01 |
| timrc | st in lib/lp/soyuz/tests/test_processaccepted.py (test_accept_copy_archives:133, error: http://pastebin.ubuntu.com/626756/) | 20:01 |
| timrc | This particular test runs lib/lp/soyuz/scripts/processaccepted.py which (when I look at output) returns a failure / generates an oops. I tried to extract details from the 'request' object which gives me an oops report (http://pastebin.ubuntu.com/626766/) -- is there a better way of getting the oops report from the id? | 20:01 |
| Ursinha | +15 | 20:19 |
| Ursinha | argh | 20:19 |
| LPCIBot | Project windmill-db-devel build #390: STILL FAILING in 1 hr 5 min: https://lpci.wedontsleep.org/job/windmill-db-devel/390/ | 20:29 |
| lifeless | poolie: what TZ are you in now :) | 20:31 |
| matsubara | timrc, oops reports are kept in /var/tmp/lperr/ for your local LP instance | 20:32 |
| timrc | matsubara, ah thank you! | 20:33 |
| matsubara | np | 20:34 |
| poolie | hi lifeless, i'm in us/pacific | 20:47 |
| flacoste | james_w, maxb: how about if we always do the check for the development series? would that make sense? | 21:05 |
| lifeless | flacoste: allo allo | 21:05 |
| flacoste | hi lifeless | 21:05 |
| maxb | flacoste: That feels like it could do the right thing | 21:05 |
| james_w | flacoste, are upload permissions series specific? | 21:05 |
| lifeless | IArchive.canUpload is | 21:05 |
| flacoste | james_w: they are archive specific | 21:06 |
| flacoste | plus the series status check | 21:06 |
| james_w | then it sounds ok | 21:06 |
| james_w | if you can e.g. upload to lucid without being able to upload to devel then we probably want the union? | 21:06 |
| lifeless | hang on a second though | 21:06 |
| sinzui | jcsackett: do you have time to mumble | 21:06 |
| * flacoste hangs | 21:07 | |
| lifeless | these branches are meant to end up being what is built | 21:07 |
| flacoste | lifeless: we are talking about the source package metadata really | 21:07 |
| flacoste | so it's not the permission to upload to the branch | 21:07 |
| lifeless | so push to them (and by extension setting the official pointer to an existing branch) is meant to be equivalent to upload | 21:07 |
| lifeless | flacoste: this is the 'setting official branch 401s' right ? | 21:07 |
| flacoste | yes | 21:07 |
| jcsackett | sinzui: sure. i'm on now. | 21:08 |
| flacoste | but they want to set official branch for obsolete series also | 21:08 |
| sinzui | jcsackett: sorry. I fell off | 21:08 |
| maxb | Do I misunderstand? I thought package sets were series-specific? So that would imply package set upload permissions are implicitly series-specific? | 21:08 |
| flacoste | for frozen, one, we should check against the UPDATE pcoket | 21:08 |
| lifeless | so, I'm saying that perhaps setting the official branch should be treated as an upload, even for frozen. Who can upload to obsolete series ? | 21:08 |
| flacoste | i don't think anybody can upload to obsolete series | 21:08 |
| maxb | No one should be able to upload to obsolete series, but the UDD importer should be able to register that it has created an official Bazaar representation of what was uploaded when the series was active. | 21:09 |
| lifeless | righg | 21:10 |
| lifeless | right | 21:10 |
| flacoste | do we really care? | 21:10 |
| flacoste | i mean obsolete is obsolete | 21:10 |
| lifeless | so what we're doing at the moment is getting rid of the special case 'folk in ~ubuntu-branches can do anything' rule; perhaps this suggests that the importer really should be a role. | 21:11 |
| flacoste | we sometime delete the published files there | 21:11 |
| flacoste | not automatically | 21:11 |
| maxb | At the moment we are still at the maturity level in the UDD importer where wanting to erase all the current branches for a package and redo from saved published files is not entirely out of the question. | 21:12 |
| flacoste | sure | 21:13 |
| flacoste | but obsolete series? | 21:13 |
| maxb | Yes | 21:13 |
| flacoste | frozen and current i get | 21:13 |
| flacoste | but obsolete | 21:13 |
| flacoste | i don't | 21:13 |
| flacoste | obsolete is obsolete | 21:13 |
| flacoste | if it's not obsolete it's not obsolete | 21:13 |
| flacoste | if you see what i mean | 21:13 |
| flacoste | we shouldn't care about obsolete series at all in a way | 21:13 |
| flacoste | that's before our time | 21:14 |
| flacoste | i'd want strong justification for introducing special cases just for supporting "uploads" to obsolete series | 21:14 |
| maxb | uploads would be silly, yes. I think this is a demonstration that official branch linkage is _not_ wholly equivalent to uploads | 21:15 |
| flacoste | still | 21:16 |
| flacoste | why do we care | 21:16 |
| flacoste | ? | 21:16 |
| flacoste | the whole point of obsolete, is that we don't have to care anymore | 21:17 |
| maxb | We care because we consider history of packages to be important. | 21:17 |
| maxb | The importer tries to import Debian woody! | 21:18 |
| flacoste | that's misguided to me | 21:19 |
| lifeless | well | 21:20 |
| lifeless | we can import something without linking it to the official series. | 21:20 |
| lifeless | so I think its a separate question | 21:20 |
| flacoste | right | 21:20 |
| flacoste | in a way, it's no business to me if UDD should try to import woody or not | 21:20 |
| flacoste | i do have an opinion, but it's irrelevant unless you ask for it :-) | 21:21 |
| lifeless | Everyone has one :) | 21:21 |
| maxb | A secondary aspect of this is: Launchpad has broken the importer through insufficiently well understood changes - please provide sufficient time to recode the importer if you're going to forcibly withdraw rights to do something it could do before. | 21:21 |
| flacoste | maxb: well, it's more a case of missing qa than anything else | 21:22 |
| flacoste | we didn't intend to remove rights | 21:22 |
| flacoste | but the check we did (could james_w still set official package branch on staging) wasn't the whole story it seems | 21:23 |
| lifeless | maxb: thats a bit harsh | 21:24 |
| lifeless | maxb: we suggested ages ago it should be an LP managed service | 21:24 |
| lifeless | maxb: and this change was discussed with the folk running the importer | 21:24 |
| lifeless | lol | 21:27 |
| lifeless | flacoste: check out https://bugs.launchpad.net/null/+bug/420937 | 21:27 |
| flacoste | in a away | 21:27 |
| lifeless | 'Directly subscribed | 21:27 |
| lifeless | No subscribers' | 21:27 |
| flacoste | in a way, i could special case OBSOLETE | 21:27 |
| flacoste | and if the distroseries is OBSOLETE, use the current devel one | 21:27 |
| flacoste | with a XXX to a bug in the importer | 21:27 |
| flacoste | or no bug if we don't want to support changing sourcepackage metadata for OBSOLETE | 21:28 |
| flacoste | i'd like that the same permission check would be used for the other regression we had (can't change packaging link when there is an upstream with shared translations) | 21:28 |
| flacoste | lifeless: what do you think of the above^^^ | 21:28 |
| maxb | I don't mean to be harsh, I'm just a bit confused why, having discovered this issue, continuing to deny the importer these permissions seems to be an option under consideration | 21:28 |
| lifeless | maxb: we're basically doing development that was skipped in the initial implementation | 21:29 |
| flacoste | yeah | 21:29 |
| flacoste | it's not clear if we want to support those permissions | 21:29 |
| lifeless | these are questions that were invisible with the celebrity and identified as work that should be done | 21:29 |
| flacoste | but i agree that removing functionality should allow for a smooth transition on your side | 21:30 |
| flacoste | that's why i'm suggesting the OBSOLETE special cases (instead of the ubuntu-branhces special case, which I really don't want to reintroduce) | 21:30 |
| lifeless | flacoste: uhm, so I think the translations link is less risky than setting these branches | 21:30 |
| lifeless | translations link could well use the rule the branch setting uses, just not the other way around | 21:31 |
| flacoste | agreed, but i'd rather we still one logic | 21:31 |
| flacoste | the more strict one | 21:31 |
| lifeless | yeah | 21:31 |
| flacoste | which should work fine for the other case also | 21:31 |
| flacoste | agreed | 21:31 |
| lifeless | I think that we should ask the TB | 21:31 |
| lifeless | erm | 21:31 |
| lifeless | actually | 21:31 |
| flacoste | about setting OBSOLETE series | 21:31 |
| flacoste | ? | 21:31 |
| lifeless | the importer isn't a debian uploader | 21:31 |
| lifeless | lets talk debian for just a minute | 21:31 |
| lifeless | ubuntu upload rights won't let the importer upload to debian | 21:32 |
| flacoste | no | 21:32 |
| lifeless | so we're going - if someone queries LP - to have an 'uploader' to Debian-in-LP | 21:32 |
| flacoste | but we can give it upload righ on launchpad | 21:32 |
| lifeless | this is at best weird. | 21:32 |
| flacoste | i agree | 21:32 |
| lifeless | so I have an alternative proposal | 21:32 |
| flacoste | but not weirded than having Registry Administrator be the maintainer | 21:33 |
| flacoste | for Debian in Launchpad | 21:33 |
| lifeless | add a role to distribution called 'package importer' | 21:33 |
| lifeless | flacoste: I think its weirder, or at least its additional explanation. | 21:33 |
| flacoste | for Debian, i was thinking of creating a team called 'LAunchpad Debian Maintainers' | 21:33 |
| flacoste | owned by Registry Admin | 21:33 |
| flacoste | and with the importer in it | 21:33 |
| flacoste | that would actually clarify things a bit | 21:34 |
| lifeless | So the question is - is that simpler than directly representing 'there is this service that can write to any official branch and set any official branch for any series in $distro' | 21:34 |
| lifeless | I'm not a big fan of directly modelling every little thing | 21:35 |
| * flacoste neither | 21:35 | |
| lifeless | this seems to be a biggish thing though | 21:35 |
| lifeless | consider that: | 21:36 |
| lifeless | - long term we don't want the package importer triggering builds [this came up in tb discussion I think] | 21:36 |
| lifeless | - the package importer would like to edit obsolete packages which normal uploaders cannot | 21:36 |
| flacoste | (I'm -1 on that second item FTR) | 21:37 |
| flacoste | gardening obsolete data isn't a use-case i'd like to support | 21:37 |
| lifeless | - and it would like to edit debian and linaro and perhaps more in future but normal uploaders have no use case for doing this | 21:37 |
| lifeless | flacoste: I'd like to put that gardening question aside; it is something that was previously deliberately supported; we should ask the TB whether they really care IF we decide its too hard to support | 21:38 |
| flacoste | that sounds like YAGNI | 21:38 |
| lifeless | flacoste: editing debian is a current job for it; when linaro goes all derived distro that will also be a job for it | 21:39 |
| bac | flacoste: :( | 21:39 |
| flacoste | bac: i pushed your guilt-trip button? ;-) | 21:40 |
| bac | yeah... | 21:40 |
| bac | where is that reset? | 21:40 |
| LPCIBot | Project parallel-test build #37: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/parallel-test/37/ | 21:40 |
| flacoste | bac: it's called daily meditation | 21:40 |
| flacoste | lifeless: it don't think 'too hard' is the criteria here | 21:41 |
| flacoste | lifeless: it's more of a "limt the set of things we support" criteria | 21:41 |
| maxb | Regards "gardening" - I think gardening deserves to be special - for example, the importer MUST be able to push to branches for the release pocket of a released distroseries, but normal uploaders probably shouldn't | 21:45 |
| lifeless | when we started this | 21:52 |
| lifeless | we said 'lets use upload rights, they exist and should include the right people and the importer is essentially getting upload rights' | 21:52 |
| lifeless | my points above were saying that we're running into feedback of various sorts from the folk who will be using what we create, that says upload isn't all that good a fit | 21:53 |
| lifeless | In terms of what we support, I think the distro really drive that | 21:54 |
| flacoste | i'm going to fix to special case OBSOLETE series | 21:54 |
| flacoste | and punt on whether to model a package-importer or not | 21:54 |
| flacoste | that way the importer can work tomorrow | 21:54 |
| flacoste | and eventually we'll iterate again to make this 'correct' at some point | 21:55 |
| flacoste | what we'll have short-term is better than what we had before | 21:55 |
| flacoste | it might need further tweaks eventually | 21:55 |
| lifeless | sure; I think in parallel we should ask the TB their thoughts - they may love having the ability to fiddle with this data for obsolete [by any uploader] | 21:56 |
| lifeless | or they may hate it | 21:56 |
| lifeless | either way we'l get input into how urgently we should come back to it | 21:57 |
| flacoste | sure | 21:57 |
| lifeless | sinzui: any idea about the cause of https://launchpadlibrarian.net/73532151/screenshot4.png ? | 22:28 |
| lifeless | (bug 797413) - I'm trying to assess for triage | 22:28 |
| sinzui | wow that is new | 22:28 |
| _mup_ | Bug #797413: Launchpad 'h' font broken <Launchpad itself:New> < https://launchpad.net/bugs/797413 > | 22:28 |
| sinzui | lifeless: I cannot say what is wrong. | 22:30 |
| sinzui | lifeless: 'h', 'L' and 'i' are the tallest letters in Ubuntu font. since the i is not broken, I do not know what is wrong with the 'h' | 22:31 |
| lifeless | speaking of fonts | 22:32 |
| lifeless | any chance we can make our text darker ? | 22:32 |
| lifeless | (asking as a user, not TA) | 22:34 |
| === salgado is now known as salgado-afk | ||
| flacoste | lifeless: the contrast we have is within the W3C accessibility chart | 22:48 |
| flacoste | interesting that my tests to check permission on frozen and obsolete series is passing :-/ something fishy with the tests i guess | 22:49 |
| flacoste | but that's for tomorrow | 22:49 |
| lifeless | flacoste: >< | 22:49 |
| flacoste | time to go | 22:49 |
| lifeless | flacoste: well, chart or not, we do get a stream of bugs about it, and at least for me, I have to run on max brightness to read the text easily. | 22:49 |
| sinzui | lifeless: The font colour is #333 which is defined in both the web standards and Ubuntu light themes. They should be the same. We know something is amiss when they are not | 22:52 |
| sinzui | lifeless: I believe the goal is to make the Ubuntu web experience look like a desktop experience | 22:53 |
| lifeless | sinzui: ah, so I don't run the normal ubuntu theme... because its too hard on my eyes | 22:54 |
| sinzui | lifeless: I hope the new drive for accessibility will be addressed in the light themes then. I personally miss them. Oneiric alpha 1 does not ship with a working default theme. | 23:00 |
| === matsubara is now known as matsubara-afk | ||
| poolie | abentley, hi | 23:07 |
| poolie | bryce was asking why you retargeted https://bugs.launchpad.net/python-keyring/+bug/796873 | 23:07 |
| _mup_ | Bug #796873: ec2 land generates gnomekeyring.IOError if run over an ssh session <Python Keyring:New> < https://launchpad.net/bugs/796873 > | 23:07 |
| abentley | poolie: it looks like the appropriate project to me. | 23:08 |
| lifeless | wow | 23:24 |
| lifeless | > 50% of our active reviews are approved-but-not-landed | 23:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
