| lifeless | can has review ?https://code.launchpad.net/~lifeless/python-oops/extraction/+merge/71128 | 00:24 |
|---|---|---|
| lifeless | diff is there | 00:29 |
| lifeless | bwha, whereforeartthou, reviewer? | 00:41 |
| j-johan-edwards | <pedantry>wherefore means why</pedantry> | 00:47 |
| lifeless | heh | 00:51 |
| lifeless | when going for comic effect, one ignores detail :P | 00:51 |
| * ajmitch 28 | 00:55 | |
| nigelb | 28? | 00:56 |
| ajmitch | was meant to be /win 28 | 00:57 |
| nigelb | typing /me instead of /win sounds... fail :P | 00:57 |
| ajmitch | where the merits of concrete were being discussed | 00:57 |
| ajmitch | oh it was :) | 00:57 |
| StevenK | I wonder how many times ajmitch uses /win instead of /me | 00:58 |
| ajmitch | not often | 00:58 |
| wallyworld | anyone know why we aren't using yui3 grids? they look nice, i have a use for them, and i would like to include them in our yui dependencies | 01:48 |
| wgrant | I thought 3.0 was YUI3 grids. | 01:51 |
| wgrant | Isn't that was does the layout most modern pages? | 01:52 |
| wgrant | eg. Product:+index? | 01:52 |
| wallyworld | wgrant: there's a greds.css we are not including in launchpad.js http://developer.yahoo.com/yui/3/cssgrids/ | 01:54 |
| wallyworld | very easy to use grids with just a css class or two | 01:54 |
| wallyworld | not sure what Product:+index uses | 01:55 |
| j-johan-edwards | Does any Soyuz guru have time to look over a rough ER draft of some schema changes? ( http://www.mediafire.com/?l6rvdmn237c28ku ) | 02:00 |
| j-johan-edwards | I realize reviewers are in short supply at the moment. | 02:00 |
| nigelb | wallyworld: aha, brilliant. You're here. I'm off work sick. Perfect day to finish off that branch. | 02:07 |
| wgrant | j-johan-edwards: Why should this be in LP? | 02:07 |
| wgrant | j-johan-edwards: LP is mostly full of things that shouldn't be in LP. | 02:07 |
| wallyworld | nigelb: hello, too bad you're sick | 02:07 |
| wgrant | Like Soyuz. | 02:07 |
| j-johan-edwards | Indexing of application data in PPAs, and for the main archive | 02:07 |
| j-johan-edwards | LEP Archive-Index, basically | 02:07 |
| StevenK | nigelb: Actually sick, or you wanted to spend the day working on LP? :-P | 02:07 |
| nigelb | StevenK: Taking a day off to work on LP would be sick. BUt I'm also actually sick. | 02:08 |
| nigelb | If I wwanted a day off, next Monday is off anyway. | 02:08 |
| wgrant | j-johan-edwards: So, binarypackagename shouldn't be in there. | 02:08 |
| wgrant | j-johan-edwards: A BinaryPackageRelease contains files, while a BinaryPackageName is related to potentially hundreds of sets of files over many years. | 02:09 |
| StevenK | lifeless: So, are we going to grow another database in the next few months? | 02:09 |
| j-johan-edwards | wgrant: Unfortunately, applications often request a particular package name | 02:09 |
| StevenK | j-johan-edwards: You can still link to the BPN from the BPR | 02:09 |
| wgrant | j-johan-edwards: What's an application? | 02:09 |
| j-johan-edwards | wgrant: So 'wesnoth-common's desktop file may be requesting 'wesnoth' | 02:10 |
| wgrant | Ohh, so it's in addition to the BPR link, right. | 02:10 |
| wgrant | Not as the source of the ApplicationRelease, but a dependency. | 02:10 |
| j-johan-edwards | Yes. Usually it will just be the same package name as the release | 02:10 |
| wgrant | j-johan-edwards: Does LP need the data broken down like this? | 02:10 |
| wgrant | Or could we just store a JSON dict of metadata to publish? | 02:10 |
| wgrant | I'm not sure if LP really needs to be able to inspect this much. | 02:11 |
| j-johan-edwards | That's an interesting idea | 02:11 |
| lifeless | StevenK: in what sense? | 02:11 |
| wgrant | wallyworld: lib/canonical/launchpad/icing/cssgrids? | 02:11 |
| wgrant | wallyworld: (nauseatingly included, but there) | 02:12 |
| wallyworld | wgrant: yes. i've just updated yui-deps.py to process it, otherwise it's not in launchpad.js | 02:12 |
| wallyworld | ah hold on | 02:12 |
| StevenK | lifeless: In the sense that we talk to multiple databases, I guess? | 02:13 |
| wgrant | wallyworld: How have we been using it for more than two years, then? :/ | 02:13 |
| wallyworld | wgrant: there's one in lib/canonical/launchpad/icing/yui/cssgrids | 02:13 |
| wgrant | brb, dying. | 02:13 |
| wallyworld | that's one one i'm talking about | 02:13 |
| wgrant | I guess we're probably still using the external one. | 02:14 |
| wgrant | Should delete that and move to the one in YUI? | 02:14 |
| lifeless | StevenK: no, never. | 02:14 |
| lifeless | StevenK: (assuming you don't just mean sharding) | 02:15 |
| wallyworld | wgrant: the one in lib/canonical/launchpad/icing/cssgrids is the *old* grid implementation i think | 02:15 |
| StevenK | lifeless: So, I'm mostly parroting for wgrant | 02:15 |
| wallyworld | the new > yui3.2 grids are much better | 02:15 |
| lifeless | StevenK: we can grow a microservice whenever, if there is a good definition for the service | 02:15 |
| wgrant | "whenever" | 02:15 |
| StevenK | lifeless: "In 18 months once we have multiple DBs we can devise a migration strategy." | 02:15 |
| wgrant | Yes. | 02:16 |
| wgrant | And the means of having multiple DBs is by using microservices. | 02:16 |
| lifeless | StevenK: unless and until we actually split domains out of the main service, we should put things for those domains in the main service [modulo things that we can define good microservices for, for those we should bring up the microservice and use it] | 02:16 |
| wgrant | j-johan-edwards: It's a fair bit lighter if we basically need one table which fairly opaquely stores the contents of a .desktop file. | 02:17 |
| wgrant | j-johan-edwards: Easier to implement initially, easier to change later. | 02:17 |
| j-johan-edwards | wgrant: Could Launchpad handle storing a JSON file for every single application BPR? While designing the ER I was worried about excess string duplication. | 02:17 |
| lifeless | j-johan-edwards: it would be a lot easier to sensibly discuss this if we had a LEP: a document descring the use cases and expected behaviour | 02:18 |
| lifeless | j-johan-edwards: questions like 'do we need to search the data', 'how often does it change' and 'where will it be presented' | 02:18 |
| wgrant | Potentially evolving ArchiveIndex into a more modern form. | 02:18 |
| j-johan-edwards | lifeless: Actually, we already do. https://dev.launchpad.net/ArchiveIndex ;) | 02:19 |
| lifeless | gnhh unusual place | 02:20 |
| StevenK | lifeless: Says you, who regularly misspells wiki URLs :-P | 02:20 |
| nigelb | wallyworld: I add a CSS class to every bug, and there was the existing work that does it for branches. How would I test this JS code? | 02:21 |
| nigelb | Rather, what am I looking to assert | 02:22 |
| wallyworld | nigelb: you would write a yui test | 02:22 |
| j-johan-edwards | wgrant: Does LibraryFile transparently handle file-deduplication with checksums? That would probably prevent the disk requirements from ballooning too much | 02:22 |
| wgrant | j-johan-edwards: It does. But it's not clear whether we'd want to use the librarian here. | 02:22 |
| wgrant | j-johan-edwards: As lifeless suggests, I'd check over ArchiveIndex and bring it up to date. | 02:23 |
| wallyworld | for examplenigelb: there are several examples you could look at - anything under lp/app/javascript/xxx/tests | 02:23 |
| lifeless | j-johan-edwards: it seems like a document containing conclusions, and there isn't enough logic there to check them. | 02:23 |
| wallyworld | nigelb: there are several examples you could look at - anything under lp/app/javascript/xxx/tests, for example | 02:23 |
| nigelb | ah. | 02:23 |
| nigelb | this is nontrivial. | 02:23 |
| lifeless | j-johan-edwards: for instance, doing a web service search api would be very different to generating an index. | 02:23 |
| nigelb | As usual. | 02:23 |
| wallyworld | you need to mock the io call and return some samlple data | 02:23 |
| lifeless | j-johan-edwards: and we have the goal, for software centre, of scaling to 10's of thousands of apps all with these icons. | 02:24 |
| lifeless | j-johan-edwards: why is this going in the archive ? | 02:24 |
| wallyworld | nigelb: give me a few minutes and i can point you at an example if i can find a simple one | 02:24 |
| nigelb | wallyworld: sure, let me see what I can wwrite in the meanwhile. | 02:25 |
| j-johan-edwards | lifeless: Because Software-center doesn't have direct access to the LP databases. For the same reason that apt uses Packages.gz from the archive. | 02:26 |
| lifeless | j-johan-edwards: those are two totally different things | 02:26 |
| j-johan-edwards | lifeless: If we aren't indexing application data in the archive, where will we index it? | 02:27 |
| wgrant | I see two related things here. | 02:27 |
| wgrant | 1) SC should list applications from enabled PPAs. | 02:27 |
| wgrant | 2) SC should be able to list commercial apps that are in PPAs without them being enabled yet. | 02:27 |
| lifeless | j-johan-edwards: software center can consume LP as an API | 02:27 |
| wgrant | This solves 1) | 02:27 |
| wgrant | It does not solve 2) | 02:27 |
| lifeless | j-johan-edwards: very very easily | 02:27 |
| wgrant | lifeless: Bye bye LP? | 02:27 |
| lifeless | j-johan-edwards: it already does! | 02:28 |
| lifeless | wgrant: hmm? | 02:28 |
| wgrant | lifeless: It only consumes LP indirectly via SCA now. | 02:28 |
| lifeless | wgrant: right | 02:28 |
| wgrant | The load from regular data retrieval would be... non-trivial. | 02:28 |
| lifeless | wgrant: there are a few approaches there | 02:29 |
| lifeless | wgrant: I really wish the LP/SCA/SC integration was clearer | 02:29 |
| lifeless | wgrant: but thats a different discussion :) | 02:29 |
| wgrant | Ooh yes. | 02:30 |
| wgrant | I'm not sure it's a different discussion. | 02:30 |
| lifeless | well | 02:30 |
| wgrant | I'm pretty sure this depends on the outcome of that. | 02:30 |
| wgrant | So I guess it is different. | 02:30 |
| wgrant | But not separate. | 02:30 |
| lifeless | if we want to help j-johan-edwards get his thing done without huge scope creep, it is a different discussion | 02:30 |
| lifeless | its related | 02:30 |
| j-johan-edwards | wgrant: Doesn't binary package release publishing happen seperately of BinaryPackageRelease build? | 02:30 |
| wgrant | And if we want to get this thing done without supporting it for 5 years, we need some idea of what SC is. | 02:30 |
| lifeless | what I'm concerned about is an integration story where we solve a problem in A by making B and C do fugly things | 02:30 |
| j-johan-edwards | wgrant: If so LP could just refuse to return records for unpublished packages | 02:30 |
| wallyworld | nigelb: test_personpicker has a reasonable example (we have about 4 ways of doing it in various tests sadly). search for "We patch Launchpad client to return some fake data for the patch" | 02:31 |
| wgrant | j-johan-edwards: Refuse to return records? | 02:31 |
| lifeless | j-johan-edwards: wgrants point is that SC needs to know about metadata for an app you have *not bought yet* | 02:31 |
| wgrant | Oh. | 02:31 |
| lifeless | j-johan-edwards: which is very closely related to my questions | 02:31 |
| wgrant | I see what you're getting at now. | 02:31 |
| wgrant | What lifeless said. | 02:31 |
| lifeless | j-johan-edwards: putting stuff in the archive only works for archives that are available a priori, and not all all for stuff that you need to do something special to enable. | 02:32 |
| nigelb | wallyworld: is there a commandline way to run the tests? | 02:32 |
| lifeless | s/all all/at all/ | 02:33 |
| j-johan-edwards | lifeless: Do app-install-data-commercial packages exist as LP BPRs? | 02:33 |
| wallyworld | nigelb: yes, but easier when just running one test case to openin your browser the html page correspondingn to the test.js file | 02:33 |
| j-johan-edwards | lifeless: If so I don't see the problem... | 02:33 |
| lifeless | j-johan-edwards: not in the main archive | 02:33 |
| lifeless | j-johan-edwards: commercial packages metadata is only for... the archive the commercial package is in | 02:34 |
| wgrant | j-johan-edwards: They exist in LP. But they can't just be in an ArchiveIndex style index, because clients don't have those archives enabled. | 02:34 |
| nigelb | wallyworld: okay, so as I understand, first create some sample html and let YUI loose on it to run the tests :) | 02:34 |
| lifeless | there is a very fundamental disconnect here :) | 02:34 |
| wallyworld | nigelb: copy an existing html and js file pair - the html file is loaded in the browser and this causes the tests to run | 02:34 |
| nigelb | Already did that. | 02:35 |
| lifeless | j-johan-edwards: so, there are two disjoint use cases for SC: find apps in the mirrorable-archives (ubuntu / linaro / public ppas / private team-based ppas) | 02:35 |
| wallyworld | nigelb: more info at https://dev.launchpad.net/JavascriptUnitTesting | 02:36 |
| lifeless | j-johan-edwards: and secondly, find apps in unlockable archives (the pay-for-an-app story) | 02:36 |
| nigelb | wallyworld: aha, thanks! | 02:36 |
| nigelb | After this I need to write the server side bits too. | 02:36 |
| lifeless | j-johan-edwards: the commercial metadata package stores metadata for the unlockable archives: its a cross-archive data structure. | 02:36 |
| j-johan-edwards | lifeless: Oh... I get it now. There's no way to provide AppInfo.gz for an archive that a non-purchaser client can't access. Is that it? | 02:37 |
| lifeless | j-johan-edwards: *by definition* an archive [technically a suite in this case]-specific data structure won't include data for things from outside that archive | 02:37 |
| lifeless | j-johan-edwards: right | 02:38 |
| lifeless | look at the lep, see the example file does not suggest a url / ppa / anything - its just 'package' | 02:38 |
| lifeless | now | 02:38 |
| lifeless | perhaps SCA /already/ solves this ? | 02:38 |
| wgrant | Well, there was an idea that we would not restrict the metadata. Indeed, I think it may already be unrestricted. | 02:38 |
| wgrant | But we don't want clients having to grab it from *every* archive. | 02:38 |
| lifeless | if SCA already solves this for commercial ppas, which we expect to dwarf the primary archive over time, it raises the question for me, of why not have SCA do it for the main archive too | 02:39 |
| lifeless | or why not put these fields into Packages.gz directly? its where they belong AFAICT | 02:40 |
| lifeless | (sorry that last is a jump... | 02:40 |
| lifeless | I mean, 'if SCA handles the unlockable-PPA case, then we can think much more narrowly about the other case, and wouldn't it be easier to ...' | 02:40 |
| j-johan-edwards | lifeless: how does LP provide private apt archives currently? `apt` usually uses publically accessible URIs to collect repo metadata... | 02:42 |
| lifeless | j-johan-edwards: a sources.list.d entry with an https url containing a username and password | 02:42 |
| j-johan-edwards | Okay. I see two potential solutions: | 02:43 |
| j-johan-edwards | 1) Use permissions to allow access to only AppInfo.gz in private url repos | 02:44 |
| j-johan-edwards | That's the dirty solution | 02:44 |
| j-johan-edwards | 2) Come up with an API for clients to request a comprehensive view of all private PPAs and their associated metadata. | 02:44 |
| j-johan-edwards | Which would be hard | 02:44 |
| lifeless | j-johan-edwards: or have a search api ? | 02:47 |
| lifeless | j-johan-edwards: but! | 02:48 |
| lifeless | j-johan-edwards: private ppa != commercial ppa | 02:48 |
| lifeless | we don't really distinguish them at the moment, but many private ppas would be shocked to have their existence documented, let alone a list of packages present in them exposed. | 02:48 |
| j-johan-edwards | lifeless: Perhaps we can have a MetaArchive table... | 02:50 |
| lifeless | j-johan-edwards: I think perhaps when you say potential solutions, you are thinking 'how can I achieve a file in the archive with this content' | 02:50 |
| lifeless | j-johan-edwards: but! thats not the goal. Thats a way to achieve the goal. The goal is something fuzzier around software centre searches. | 02:50 |
| j-johan-edwards | lifeless: But how can we provide a search API when we have no data structures to determine what data is and is not publically searchable? | 02:51 |
| lifeless | j-johan-edwards: software centre agent is where said api would probably live, its what software centre talks to already | 02:51 |
| lifeless | j-johan-edwards: I need to stop thinking about this now, or I'll be leaving a messy tree to wake up to tomorrow :) - somehow LP and SCA co-operate at the moment on purchase-a-package, so the metadata exists. | 02:53 |
| lifeless | j-johan-edwards: we have a big open question: is this a solved problem for commercial already? If not (and i suspect not if that package contains the index) then design is needed | 02:54 |
| jtv | StevenK: I'd like to create a new derived series on dogfood… mind if I add one to deribuntu? | 02:54 |
| lifeless | (not ER design, architecture design) | 02:54 |
| LPCIBot | Project devel build #962: FAILURE in 5 hr 44 min: https://lpci.wedontsleep.org/job/devel/962/ | 02:54 |
| j-johan-edwards | lifeless: I believe the only metadata currently existing is hand-crated for app-install-data-commercial... so I don't think so | 02:55 |
| lifeless | I suggest an email thread or conference call with (probably minimally) mvo, mpt, and michael nelson or whomever is doing SCA these days | 02:56 |
| lifeless | I would like to participate, and we probably want one of bigjools or wgrant or stevenk as a preferred soyuz afficionado | 02:57 |
| j-johan-edwards | On a side note, Is this chatroom logged (I think my client trashed some conversation above) | 02:58 |
| StevenK | I believe so | 02:58 |
| wgrant | Should be on irclogs.ubuntu.com | 02:58 |
| j-johan-edwards | wgrant: thanks | 02:58 |
| lifeless | wgrant: you will probably enjoy qaing r r13658 | 02:59 |
| wgrant | lifeless: Indeed. | 03:00 |
| lifeless | 230350 | 159 | 03:00 |
| lifeless | bug, count | 03:00 |
| wgrant | I was about to ask. | 03:00 |
| wgrant | Thanks. | 03:00 |
| lifeless | bug 1 has no expanders | 03:01 |
| _mup_ | Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Confirmed for compscibuntu-bugs> <dylan.NET.Reflection:Invalid> <dylan.NET:Invalid> <EasyPeasy Overview:Invalid by ramvi> <GenOS:In Progress by gen-os> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <LibreOffice:In Progress by bjoern-michaelsen> <Linux Mint:In Progress> <The Linux OS Project:In Pr | 03:01 |
| lifeless | and does have ajax widgets | 03:01 |
| wgrant | Hm, it should be over the AJAX threshold. | 03:01 |
| wgrant | Sure they're AJAX widgets and not just links? | 03:01 |
| lifeless | ah you are right | 03:02 |
| wgrant | So you can still get to editstatus. | 03:02 |
| wgrant | So this is possibly not too bad. | 03:02 |
| lifeless | anyhow, 230350 still doesn't render | 03:02 |
| wgrant | There we go. | 03:03 |
| wgrant | Rendered after three refreshed. | 03:03 |
| wgrant | 800 queries, 8.61s. | 03:03 |
| lifeless | OOPS-2049DZ7) | 03:03 |
| lifeless | oh | 03:03 |
| lifeless | duh me | 03:03 |
| wgrant | ? | 03:03 |
| lifeless | what server was I on? | 03:03 |
| wgrant | Hahaha | 03:03 |
| lifeless | assignment will be undiscoverable | 03:04 |
| lifeless | we should file a (high) bug about that, and about the UI downgrading | 03:04 |
| wgrant | Yeah. | 03:04 |
| wgrant | We really should just remove the expanders globally ASAP. | 03:05 |
| wgrant | Looks much nicer. | 03:05 |
| wgrant | lifeless: Can you check how many bugs have >=10 tasks? I guess lots will, due to nominations. | 03:05 |
| lifeless | https://bugs.qastaging.launchpad.net/ubuntu/+source/afflib/+bug/230350?comments=all still bwarfs | 03:06 |
| _mup_ | Bug #230350: Missing Debian Maintainer field <Ubuntu:Invalid> <afflib (Ubuntu):Fix Released by saivann> <alac-decoder (Ubuntu):Fix Released by warp10> <axiom (Ubuntu):Invalid> <beneath-a-steel-sky (Ubuntu):Fix Released> <bibletime-i18n (Ubuntu):Fix Released by txwikinger> <binkd (Ubuntu):Fix Released> <bzr-builddeb (Ubuntu):Won't Fix> <capisuite (Ubuntu):Invalid> <chinput (Ubuntu):Fix Released by warp10> <chmsee (Ubuntu):Fix Released> <ciso (U | 03:06 |
| lifeless | wgrant: 578 | 03:06 |
| wgrant | Fewer than I thought. | 03:07 |
| lifeless | you can grab off dogfood if you want the ids - select bug, count(bug) from bugtask group by bug having count(bug) >= 10; | 03:07 |
| wgrant | Yeah. | 03:07 |
| wgrant | But DF is slow. | 03:07 |
| lifeless | ah, worked on refresh | 03:07 |
| wgrant | And I'm not SSHed in at the moment. | 03:07 |
| wgrant | And you are here. | 03:07 |
| StevenK | GRRRRR. *So* tempted to make a release of storm to fix this import policy violation | 03:12 |
| wgrant | Yes :( | 03:13 |
| StevenK | It is beginning to *really* annoy me | 03:15 |
| lifeless | snapshot I tihnk you mean ?we're running a (minor) fork | 03:16 |
| lifeless | but yes, do that - or nag abel :) | 03:16 |
| StevenK | So lp:storm is not the right place? | 03:16 |
| lifeless | see versions.cfg | 03:16 |
| StevenK | Yes, but that tells me a version string, *not* the branch I should be using | 03:17 |
| wgrant | There isn't a comment about the branch? | 03:18 |
| wgrant | No. | 03:18 |
| StevenK | There is not | 03:18 |
| wgrant | Anyway, there is probably a ~launchpad or ~launchpad-committers storm branch. | 03:18 |
| lifeless | review please? https://code.launchpad.net/~lifeless/python-oops/extraction/+merge/71128 | 03:18 |
| StevenK | wgrant: https://code.launchpad.net/~launchpad-commiters no workies, and I can't see a storm branch in https://code.launchpad.net/~launchpad | 03:20 |
| lifeless | one sec and I'll dig it up | 03:21 |
| wgrant | StevenK: You are unable to spell "committers" | 03:21 |
| wgrant | https://code.launchpad.net/~launchpad-committers/storm/with-without-datetime | 03:21 |
| lifeless | hah, there go | 03:21 |
| lifeless | review #2 please? https://code.launchpad.net/~lifeless/launchpad/useoops/+merge/71139 | 03:22 |
| wgrant | Sorry, I've got stuff I need to finish up today :/ | 03:23 |
| lifeless | no worries | 03:24 |
| lifeless | perhaps StevenK can take mercy? they are small branches | 03:24 |
| StevenK | Tell you what, if you make me lunch, I'll review your branches | 03:24 |
| lifeless | Can I eat it too ? | 03:25 |
| lifeless | (I would if I could) | 03:25 |
| lifeless | if you can review them after lunch, I would really appreciate that | 03:25 |
| lifeless | speaking of which, I should have lunch myself | 03:25 |
| StevenK | Can I just push to this storm branch, or do I need to go through the branch and review dance? | 03:26 |
| lifeless | the best thing to do is make a fresh branch off of trunk for your change | 03:26 |
| lifeless | put that up for review by the storm folk | 03:26 |
| lifeless | and separately land the change into the branch we run | 03:27 |
| lifeless | keep the delta minimal | 03:27 |
| StevenK | It's a one line diff! | 03:27 |
| StevenK | But I knew this was going to be a pain in the bum. | 03:27 |
| lifeless | put it in debian/patches :P | 03:27 |
| lifeless | FWIW I've done precisely this for several of the patches we have - and got them merged to storm | 03:28 |
| * StevenK marks the first of lifeless's branches as "Needs Fixing" | 03:28 | |
| StevenK | Just for that :-P | 03:28 |
| lifeless | hah, thanks | 03:28 |
| StevenK | "The author of this branch needs better material" | 03:28 |
| lifeless | so - go eat | 03:28 |
| lifeless | I'll be back in ~60 myself | 03:28 |
| jtv | StevenK: need some help with IDS… I think I'm skipping a step because I'm getting no DSDs for my new series. | 03:58 |
| StevenK | IDS doesn't create DSDs? | 04:06 |
| jtv | Argh. Of course. Well it does, but not in this case. | 04:07 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| StevenK | Can haz review? https://code.launchpad.net/~stevenk/launchpad/storm-394/+merge/71146 | 04:47 |
| lifeless | StevenK: 404s | 05:11 |
| StevenK | lifeless: Yes, make dies horribly | 05:11 |
| StevenK | Hm | 05:12 |
| StevenK | r393's __init__.py says 0.18.0.99 | 05:12 |
| StevenK | But r394 causes make to blow up | 05:14 |
| lifeless | make or buildout? | 05:14 |
| StevenK | buildout, run by make | 05:15 |
| lifeless | you have to invoke setup.py in a slightly non-default way | 05:15 |
| StevenK | I just ran make release | 05:15 |
| StevenK | Obviously that was silly, so let me delete the tarball from the download-cache | 05:16 |
| wgrant | python setup.py egg_info -bsomesuffix sdist | 05:18 |
| wgrant | I forget was suffix we normally use | 05:18 |
| lifeless | the one in versions.cfg | 05:18 |
| wgrant | python setup.py egg_info -b-lpwithnodatetime-r394 sdist | 05:18 |
| lifeless | no leading hypen | 05:18 |
| lifeless | -blpwithnodatetime-r394 | 05:18 |
| lifeless | I think | 05:18 |
| lifeless | IMBW(tm) | 05:18 |
| wgrant | I don't think so. | 05:18 |
| wgrant | But we'll see soon. | 05:19 |
| StevenK | storm-0.18.0.99-lpwithnodatetime-r394.tar.bz2 | 05:19 |
| StevenK | Looks right to me | 05:19 |
| wgrant | I thought I usually kept the leading -. | 05:20 |
| wgrant | Perhaps it accepts both. | 05:20 |
| StevenK | File "/home/steven/launchpad/lp-branches/storm-394/lib/canonical/launchpad/scripts/oops.py", line 21, in <module> | 05:24 |
| StevenK | from ...oops import uniquefileallocator | 05:24 |
| StevenK | ImportError: No module named oops | 05:24 |
| StevenK | LIFELESS! | 05:24 |
| jtv | Hey, he does that to other people too? | 05:25 |
| wgrant | StevenK: make | 05:25 |
| wgrant | StevenK: Or upgrade from Python 2.4. | 05:25 |
| jtv | Not necessarily in that order. | 05:26 |
| * StevenK runs 'make clean && make' | 05:26 | |
| jtv | While we're here: isn't initialize-from-parent.py supposed to run InitializeDistroSeriesJobs? | 05:27 |
| StevenK | NO | 05:28 |
| lifeless | StevenK: yes ? | 05:30 |
| lifeless | StevenK: we're running python2.6 ... | 05:30 |
| jtv | Well what does run InitializeDistroSeriesJobs? | 05:31 |
| lifeless | StevenK: do you have an oops egg in your eggs directory? | 05:31 |
| lifeless | jobsource probably | 05:31 |
| lifeless | jtv: ^ | 05:31 |
| StevenK | run_jobs, IIRC | 05:31 |
| StevenK | lifeless: I have eggs/oops-0.0.1-py2.6.egg | 05:32 |
| jtv | Ahhh… this is from before we started using utility names as section names. That's why that didn't work earlier. | 05:32 |
| StevenK | And after a make clean and make I still get the traceback | 05:33 |
| jtv | Did you re-link the external source code thingamajig? | 05:36 |
| wgrant | Unnecessary. | 05:36 |
| lifeless | StevenK: what python version is being run ? | 05:36 |
| lifeless | StevenK: can you do bin/py -c 'import oops' | 05:36 |
| lifeless | StevenK: I landed the useoops branch for 0.0.1 through ec2, precisely to avoid WTF moments. | 05:37 |
| StevenK | lifeless: That works. But http://pastebin.ubuntu.com/663179/ | 05:38 |
| lifeless | bin/py -c 'import canonical.launchpad.scripts.oops' | 05:41 |
| lifeless | and | 05:41 |
| lifeless | bin/py --version | 05:41 |
| StevenK | 2.6.6 | 05:42 |
| StevenK | bin/py -c 'import canonical.launchpad.scripts.oops' | 05:42 |
| StevenK | Traceback (most recent call last): | 05:42 |
| StevenK | ... | 05:42 |
| StevenK | (As before) | 05:42 |
| lifeless | urgll | 05:43 |
| lifeless | e | 05:43 |
| lifeless | I wonder if its an import fascist bug | 05:43 |
| lifeless | what happens if you do | 05:43 |
| lifeless | bin/py -c 'import oops.uniquefileallocator; import canonical.launchpad.scripts.oops' | 05:43 |
| StevenK | Uhhh | 05:44 |
| StevenK | steven@liquified:~/launchpad/lp-branches/storm-394% head -n 21 lib/canonical/launchpad/scripts/oops.py | tail -n 1 | 05:44 |
| StevenK | from ...oops import uniquefileallocator | 05:44 |
| wgrant | That's fine. | 05:44 |
| wgrant | New in 2.6, but fine. | 05:44 |
| wgrant | ../../../oops, basically. | 05:44 |
| StevenK | If that is what it translates to: | 05:45 |
| StevenK | steven@liquified:~/launchpad/lp-branches/storm-394% ls -lh ../../../oops | 05:45 |
| StevenK | ls: cannot access ../../../oops: No such file or directory | 05:45 |
| wgrant | I mean in the Python import sense. | 05:46 |
| lifeless | StevenK: what does my most recent request do ? | 05:46 |
| StevenK | lifeless: Sorry. Give the same traceback | 05:46 |
| lifeless | ok | 05:49 |
| lifeless | can you, before that import | 05:49 |
| lifeless | do | 05:49 |
| lifeless | import sys | 05:49 |
| lifeless | print sys.modules['oops'] | 05:49 |
| lifeless | (edit the scripts/oops.py) | 05:50 |
| StevenK | Huh? | 05:51 |
| StevenK | sys.modules['oops'] gives a KeyError | 05:51 |
| lifeless | even when you do bin/py -c 'import oops.uniquefileallocator; import canonical.launchpad.scripts.oops' ? | 05:51 |
| lifeless | so, I know htis works on lucid, its where I tested it >< | 05:53 |
| lifeless | with our PPA and all. | 05:53 |
| StevenK | >>> print sys.modules['oops'] | 05:53 |
| StevenK | <module 'oops' from '/home/steven/launchpad/lp-sourcedeps/eggs/oops-0.0.1-py2.6.egg/oops/__init__.pyc'> | 05:53 |
| lifeless | ok, and then the next line barfs | 05:53 |
| StevenK | Right | 05:53 |
| lifeless | what happens if you remove one of the .'s ? and/or add one? | 05:54 |
| * lifeless speculates about subtle changes in python minor versions messing lifeup | 05:54 | |
| lifeless | you've got 2.6.6, surely its not a pre-rc1 build or something booong ? | 05:55 |
| wgrant | StevenK: Is your new DSP widget meant to contain something like "ubuntu/mozilla-firefox"? | 05:55 |
| StevenK | wgrant: That should work, yes | 05:55 |
| wgrant | :/ I don't want it to. | 05:56 |
| wgrant | Makes it look like you can change the distribution. | 05:56 |
| StevenK | Why not? | 05:56 |
| wgrant | Which is forbidden for SourcePackage tasks. | 05:56 |
| StevenK | Curtis did that | 05:56 |
| StevenK | lifeless: It hasn't changed? | 05:56 |
| wgrant | I might remove the flag bit, then. | 05:56 |
| lifeless | StevenK: what hasn't changed ? | 05:56 |
| wgrant | (it needs to be reworked for my LaunchpadTargetWidget branch) | 05:56 |
| lifeless | I have to go, need to grab groceries before lynne goes to pilates | 05:57 |
| StevenK | lifeless: My python setup? | 05:57 |
| lifeless | I will drop in later; the options I can see are: this is a bong python build (fix, move on). Switch to absolute imports (requires a __future__ statement). Switch to __import__ hackery (fugly). | 05:57 |
| lifeless | StevenK: given that oops is new from yesterday, and the only explicit relative import in the tree, your python setup need not have chnaged to still be at fault | 05:58 |
| StevenK | wgrant: Can haz review? https://code.launchpad.net/~stevenk/launchpad/storm-394/+merge/71151 | 06:06 |
| wgrant | Huh. | 06:10 |
| wgrant | Just got the same oops error myself. | 06:10 |
| wgrant | So you might not be insane. | 06:10 |
| wgrant | StevenK: Done. | 06:10 |
| StevenK | wgrant: Objections to just lp-landing? | 06:11 |
| wgrant | Given what happened with the egg before, yes. | 06:11 |
| StevenK | Bleh | 06:11 |
| * StevenK tosses it at ec2 | 06:11 | |
| wgrant | :) | 06:12 |
| poolie | automatic branch suggestions, awesome | 06:31 |
| jtv | StevenK: about bug 812667… | 06:32 |
| _mup_ | Bug #812667: https://launchpad.net/ubuntu/+series mentions derives from <derivation> <Launchpad itself:In Progress by jtv> < https://launchpad.net/bugs/812667 > | 06:32 |
| jtv | …how about "Successor to"? | 06:33 |
| StevenK | Hmmm | 06:33 |
| jtv | Instead of "Derives from"? | 06:33 |
| StevenK | Based on | 06:33 |
| poolie | quick review of https://code.launchpad.net/~mbp/udd/819910-service-root/+merge/71154 anyone? | 06:33 |
| jtv | StevenK: that makes the distinction from derivation a little obscure to my taste. | 06:34 |
| jtv | "Derived from" is, to me, merely one specific form of "based on." | 06:35 |
| StevenK | jtv: 'Successor to' doesn't really do it for me | 06:36 |
| StevenK | Meh, 'Previous release' ? | 06:36 |
| jtv | Makes it sound a bit as if the previous release is the previous release _of_ the distroseries. | 06:36 |
| StevenK | Well, then, ask Julian | 06:37 |
| jtv | Who is not currently here. | 06:38 |
| jtv | I would say "supersedes," but I don't know if that is always the case (e.g. did etch "supersede" sid?) | 06:39 |
| StevenK | Mu | 06:39 |
| StevenK | sid and etch were utterly distinct, and sid will never release | 06:40 |
| wgrant | etch also doesn't have sid as previous_series, I hope. | 06:40 |
| jtv | That's the point: how will previous_series fit in with the various possible structures? | 06:40 |
| jtv | Anyway, if there's nothing more specific against "successor to" than "doesn't really do it for me" then that makes it the best option so far. Thanks. | 06:44 |
| stub | wgrant: Did you find somewhere we are actually using WITH GRANT OPTION, or are you just being completionist? | 07:34 |
| lifeless | StevenK: (passing through) - still having grief with ... ? | 07:35 |
| adeuring | good morning | 07:37 |
| wgrant | stub: I hope we're not using it. | 07:41 |
| wgrant | stub: Just decided I should handle it, since it won't be revoked automatically. | 07:41 |
| wgrant | stub: And you never know what might happen, given, you know, LP. | 07:41 |
| stub | wgrant: We are not. I was just idly wondering if we should raise errors or log warnings if we see it. | 07:41 |
| wgrant | lifeless: It's broken for me too. | 07:41 |
| wgrant | stub: Crashing fastdowntime sounds like a bad idea. | 07:42 |
| wgrant | lifeless: Might debug later. | 07:42 |
| wgrant | stub: As you can see, the aclitem parsing is mildly evil, but the rest isn't too terrible. | 07:43 |
| stub | yup. There might have been another view or function buried in information_schema or similar that might have made it easier, but how you are dealing with the raw data is fine. | 07:44 |
| wgrant | In 2004 some functions were added to get the grantor/privs/grantee out, but they've since been removed. | 07:45 |
| wgrant | And I couldn't find anything to map the priv chars to names.' | 07:45 |
| wgrant | It differs between versions, but the breakage should be obvious when we try to upgrade. | 07:45 |
| stub | This stuff is actually pretty stable (you know this as you occasionally trip over cruft). | 07:50 |
| stub | Need a better way of handling connections that should be read only in the test suite - this magic _ro stuff is horrible. | 07:51 |
| wgrant | stub: It is really bad, yeah. | 07:54 |
| wgrant | Was wondering if we still needed it at all. | 07:54 |
| wgrant | All the magic roles are slightly bad, but at least admin/read/public have obvious purposes. | 07:54 |
| stub | wgrant: r=stub | 07:59 |
| wgrant | stub: Thanks! | 07:59 |
| wgrant | stub: Were the production clusters rebuilt, or just the DBs? | 08:00 |
| wgrant | During the recent switcheroos, that is. | 08:00 |
| stub | wgrant: IIRC we are using them to ensure that exceptions get raised if you update stuff in a slave store. I think there was an issue with just setting the connection to read_only (such as exceptions not getting raised if you rolled back? I don't recall the details) | 08:00 |
| wgrant | Ahh. | 08:00 |
| wgrant | So it's even more magical than I guessed. | 08:01 |
| stub | yer, but it was also assembled for PG 8.2 | 08:01 |
| stub | Might be a better way now. | 08:01 |
| stub | We could drop the admin role too if we ensure there is a superuser the testsuite can use. | 08:02 |
| wgrant | Indeed. | 08:02 |
| wgrant | It's only a little bit more evil than read, though. | 08:02 |
| wgrant | And the evil is only 6 lines long. | 08:02 |
| stub | Yer. Not sure if we are using read any more. | 08:02 |
| wgrant | Isn't that what people have on staging/qastaging? | 08:02 |
| stub | Probably using read to grant devs access to staging | 08:02 |
| stub | yer\ | 08:02 |
| wgrant | And what LOSAs use for read-only? | 08:02 |
| wgrant | Right. | 08:03 |
| stub | They all log in as postgres I think | 08:03 |
| stub | Want read only, connect to a slave. | 08:03 |
| wgrant | Ah, of course. | 08:03 |
| wgrant | We should probably also write tests for some of this database/ stuff eventually. | 08:06 |
| wgrant | As it's becoming less basic. | 08:06 |
| mrevell | Hello | 08:08 |
| stub | Traditionally, the staging update has been the test suite. But yeah, now it is becoming more complex we could have issues non fatal and not detected on staging (eg. revoke not revoking). | 08:08 |
| stub | Smoketest after staging rollout might be appropriate | 08:09 |
| stub | Or splitting this out standalone with a real test suite. | 08:10 |
| wgrant | Yes. | 08:10 |
| wgrant | It just needs PermissionGatherer and DbSchema mocked out, and it's pretty easily testable. | 08:10 |
| stub | Mock? You want a real db there to prove it works with particular PG releases. | 08:12 |
| wgrant | For some stuff, yes. | 08:12 |
| henninge | rvba: Hi! ;-) | 08:32 |
| rvba | henninge: Hi! | 08:32 |
| henninge | rvba: are you doing the QA for bug 798522? | 08:33 |
| _mup_ | Bug #798522: https://launchpad.net/ubuntu/oneiric/+localpackagediffs should require a comment when blacklisting a package <derivation> <qa-needstesting> <Launchpad itself:Fix Committed by rvb> < https://launchpad.net/bugs/798522 > | 08:33 |
| rvba | henninge: OTP right now but just after the call, I'll do it. | 08:33 |
| === allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: allenap | Critical bugs: 234 - 0:[#######=]:256 | ||
| henninge | rvba: great, thanks! ;-) | 08:36 |
| henninge | allenap: Hi! ;-) | 08:36 |
| allenap | henninge: Good morning :) | 08:36 |
| henninge | allenap: you have a bunch of revisions ready for QA ;-) | 08:36 |
| henninge | allenap: do you need help with any of that? | 08:36 |
| allenap | henninge: I'm looking at them now. Thanks for the offer! I think they'll be quite quick to check, but if I get stuck I'll seek you out. | 08:37 |
| henninge | allenap: cool, thanks | 08:37 |
| wgrant | henninge: Thanks! | 08:38 |
| rvba | henninge: QA done :) | 08:43 |
| henninge | rvba: cool, thanks ;) | 08:44 |
| rvba | np | 08:44 |
| henninge | wgrant: having my own revision way down in the queue helps as a motivator ;) | 08:45 |
| wgrant | henninge: Ah, of course. | 08:47 |
| wgrant | jelmer: Can you QA bug #797915? We'll hopefully be deploying up to the rev before soon, and it'd be nice to be able to have yours too. | 08:48 |
| _mup_ | Bug #797915: large bzr-svn imports fail with branch.fetch_tags enabled <code-import> <qa-needstesting> <regression> <Bazaar Subversion Plugin:Fix Released by jelmer> <Launchpad itself:Fix Committed by jelmer> <gcc-4.6 (Ubuntu):Invalid> <gcc-4.6 (Ubuntu Oneiric):Invalid> < https://launchpad.net/bugs/797915 > | 08:48 |
| jelmer | wgrant: I started an import earlier on qastaging to see if it works now, but it'll take a while before we know | 08:48 |
| wgrant | jelmer: Ah, great, thanks. | 08:49 |
| * henninge was going to ask that, too. ;-) | 08:51 | |
| henninge | wgrant: I heard there was a helper now to list all the bugs fixed by a deployment on the LPS page. | 09:04 |
| henninge | Do you know what and where that is? | 09:05 |
| wgrant | henninge: It was on lpqateam.canonical.com, but the redesign removed it. | 09:07 |
| henninge | oh :( | 09:07 |
| wgrant | henninge: matsubara was going to look at replacing it, but it's not back yet. | 09:07 |
| henninge | yes, that's where I was looking for it. | 09:07 |
| henninge | wgrant: thanks, I'll just do it manually then | 09:07 |
| wgrant | Not too many, fortunately, since we deployed 12 hours ago. | 09:08 |
| henninge | yes, thanks | 09:22 |
| henninge | jelmer: how much is "a while before we know" ? ;-) | 09:23 |
| jelmer | henninge: my guess is about an hour | 09:24 |
| jelmer | the bug is about large branches not importing properly, so it'll take a while before we know if they work now | 09:25 |
| jelmer | otoh small branches still work ok, so there's no regression here | 09:25 |
| wgrant | henninge: We could just deploy that with the next stuff tomorrow morning :) | 09:29 |
| wgrant | Well, lifeless can. | 09:29 |
| henninge | jelmer: would it be ok to not include your revision now or is it rather urgent to get it deployed | 09:30 |
| henninge | if so, I am happy to wait another hour. | 09:30 |
| jelmer | henninge: it would be nice to deploy with it, as it's a critical bug that's affecting some of the platform and Linaro folks | 09:32 |
| henninge | jelmer: np, ping me when you are done. | 09:33 |
| jelmer | henninge: will do, thanks | 09:33 |
| allenap | wgrant: "Bug tasks can now be freely retargeted between products, distributions and distribution source packages." \o/ | 09:42 |
| wgrant | allenap: 10 branches later... | 09:44 |
| allenap | wgrant: Do you know the process for landing to lp:loggerhead? | 09:51 |
| wgrant | allenap: bzr ci | 09:52 |
| allenap | wgrant: Ta. | 09:53 |
| wgrant | It was going to be PQM-managed, but nobody ever set that up. | 09:54 |
| wgrant | So just manual merge+ci. | 09:54 |
| lifeless | wgrant: urgh, that sucks | 10:51 |
| wgrant | lifeless: loggerhead? | 10:51 |
| lifeless | ... | 10:51 |
| wgrant | What sucks? | 10:52 |
| wgrant | I was thinking you mean the loggerhead PQM thing. | 10:52 |
| wgrant | But maybe not. | 10:52 |
| lifeless | wgrant: the ... thing | 10:53 |
| lifeless | wgrant: being broken for you too | 10:53 |
| wgrant | Oh. | 10:53 |
| wgrant | I thought you were ...ing at me. | 10:53 |
| lifeless | no, I was ...ing at you :P | 10:53 |
| bigjools | ... | 10:54 |
| rvba | ?...? | 10:54 |
| bigjools | lifeless: what are my best options right now to get a decent OOPS-like query analysis from scripts? | 10:54 |
| lifeless | one of or systematic ? | 10:55 |
| lifeless | s/of/off/ | 10:56 |
| lifeless | bigjools: anyhow, calling ErrorReportingUtility.handling(...) would be the easiest way | 10:57 |
| lifeless | the dbstatements should already be hooked up for most scripts | 10:58 |
| bigjools | lifeless: systematic would be nice, but in this case I need a one-off | 10:58 |
| wgrant | Most scripts have librarian tracking, but not DB statement logging. | 10:59 |
| bigjools | exactly, I want that | 10:59 |
| wgrant | eg. process-accepted, merge proposal stuff. | 10:59 |
| lifeless | thats a small matter of glueing in the storm tracer | 11:00 |
| wgrant | Yup. | 11:00 |
| wgrant | Just something to watch out for. | 11:00 |
| lifeless | I would offer to do it for you now but 11pm + need to leave here at 8am for a hospital visit | 11:00 |
| bigjools | lifeless: baby coming soon? | 11:01 |
| wgrant | Bleeeergh. | 11:01 |
| lifeless | bigjools: lib/canonical/launchpad/webapp/adapter.py has the storm tracer thats used | 11:01 |
| wgrant | And it installs them. | 11:01 |
| lifeless | bigjools: yeah, we're 37w5d now | 11:01 |
| wgrant | At module load time. | 11:01 |
| lifeless | wgrant: I was fairly sure scripts had dbstatements | 11:01 |
| bigjools | lifeless v2 on its way :) | 11:01 |
| lifeless | wgrant: I seem to recall checkwatches reporting like 10000 sql statements | 11:02 |
| wgrant | It's been a while, though. | 11:02 |
| wgrant | Needs fastdowntime. | 11:02 |
| wgrant | lifeless: Yes, but checkwatches is the most special script we have. | 11:02 |
| lifeless | bigjools: so step 1 - locally - add a call to getUtility(ErrorReportingUtility).handling(...) | 11:02 |
| bigjools | I was thinking that we go to a lot of effort to optimise page loads but I've not seen much done for scripts | 11:02 |
| lifeless | bigjools: look in the oops that is written, and check it has db statements; I think it will. IMBW. | 11:03 |
| lifeless | add that call at the end of the script | 11:03 |
| bigjools | ok | 11:03 |
| bigjools | thanks, sleep well | 11:03 |
| lifeless | it returns the oops object | 11:04 |
| lifeless | so thats (in devel *now* but not tomorrow :P) | 11:04 |
| lifeless | oops = ...handling(..) | 11:04 |
| lifeless | logging.info("logged oops %s", oops.id) | 11:04 |
| lifeless | tomorrow it becomes | 11:05 |
| lifeless | logging.info("logged oops %s", oops['id']) | 11:05 |
| lifeless | if I'm right, its that one line and you are set | 11:05 |
| lifeless | each run will generate and report in its log the oops with the db queries | 11:05 |
| lifeless | if I'm wrong, you'll also need to activate the adapter.py storm tracer | 11:06 |
| lifeless | righto, gnight | 11:08 |
| lifeless | good luck bigjools | 11:08 |
| bigjools | lifeless: splendid, ta | 11:09 |
| * StevenK peers at http://pastebin.ubuntu.com/663335/ | 11:09 | |
| bigjools | what I need next is to create the report so I can see repeated queries | 11:10 |
| bigjools | repeated/long | 11:10 |
| === matsubara-afk is now known as matsubara | ||
| rvba | matsubara: Hi, the branch which improves the js of the reports has landed. | 11:57 |
| matsubara | rvba, cool. I'll update on devpad. | 11:57 |
| rvba | matsubara: great, can you run the reports generation or should we wait for the cron to kick in? (I'd like to QA that soon if it's possible) | 11:58 |
| rvba | allenap: Can I add this MP to you queue? (I've fixed the conflicts) https://code.launchpad.net/~rvb/launchpad/add-comment-bug-823777/+merge/71171 | 11:59 |
| matsubara | rvba, the branch used on devpad is db-stable. can we wait until the fix reach db-stable? I could switch but I don't know what other scripts are using that branch. | 12:04 |
| rvba | matsubara: sure, no problem. | 12:04 |
| matsubara | rvba, thanks. I'll let you know once it's updated | 12:04 |
| rvba | matsubara: great. | 12:05 |
| allenap | rvba: Sure. | 12:07 |
| henninge | which one's correct? "you are not logged in into Launchpad" or "you are not logged in to Launchpad" or "you are not logged into Launchpad" ??? | 12:07 |
| rvba | allenap: Thanks. | 12:07 |
| allenap | henninge: The latter I think. | 12:08 |
| henninge | allenap: are you sure? ;-) | 12:09 |
| allenap | henninge: The former is definitely wrong. | 12:10 |
| henninge | allenap: ok, that helps. thanks | 12:10 |
| henninge | this is n ot for ui, btw, just an email | 12:10 |
| henninge | jelmer: hey, any news? | 12:22 |
| wgrant | Looks good to me, although the svn import caused a hopefully unrelated appserver OOPS. | 12:23 |
| henninge | wgrant: if you feel comfortable, can you please qa-ok the bug? | 12:24 |
| wgrant | Once the OOPS syncs. | 12:24 |
| henninge | ok | 12:24 |
| jelmer | wgrant: It seems the import was interrupted too, which worried me | 12:24 |
| wgrant | Slightly. | 12:25 |
| wgrant | jelmer: But isn't that KeyboardInterrupt likely to be the workermonitor killing the worker because of the OOPS? | 12:27 |
| wgrant | In the logs it's the other way around, but that's all that makes sense. | 12:27 |
| jelmer | wgrant: yeah, but why would the workermonitor be oopsing? | 12:29 |
| wgrant | jelmer: It's nearly synced... | 12:29 |
| wgrant | 00001-00003@SQL-launchpad-main-master SELECT FeatureFlag.date_modified, FeatureFlag.flag, FeatureFlag.priority, FeatureFlag.scope, FeatureFlag."value" FROM FeatureFlag ORDER BY FeatureFlag.flag, FeatureFlag.priority DESC | 12:29 |
| wgrant | 14224-14224@SQL-launchpad-main-master SELECT CodeImportJob.code_import, CodeImportJob.date_created, CodeImportJob.date_due, CodeImportJob.date_started, CodeImportJob.heartbeat, CodeImportJob.id, CodeImportJob.logtail, CodeImportJob.machine, CodeImportJob.ordering, CodeImportJob.requesting_user, CodeImportJob.state FROM CodeImportJob WHERE CodeImportJob.id = 7716186 LIMIT 1 | 12:29 |
| wgrant | Python sucks at threads. | 12:30 |
| wgrant | It was a GIL timeout. | 12:30 |
| wgrant | Nothing to be concerned about. | 12:30 |
| jelmer | s/Python/*/ | 12:30 |
| jelmer | cool | 12:30 |
| wgrant | If smaller imports still worked, I think we should probably just deploy. | 12:30 |
| wgrant | We could retry this, but it takes forever and seemed to be happy enough. | 12:30 |
| wgrant | (the call that failed was just updating the logtail) | 12:31 |
| wgrant | So it was indeed before the job died. | 12:31 |
| wgrant | So probably triggered the workermonitor to kill the job. | 12:31 |
| jelmer | great - the job was doing a lot better overall anyway | 12:31 |
| wgrant | qa-ok it is. | 12:32 |
| wgrant | henninge: ^^ | 12:32 |
| wgrant | Hmm. | 12:34 |
| wgrant | I bet gary_poster was QAing his bug at the time that OOPS happened. | 12:34 |
| wgrant | Let's see. | 12:34 |
| wgrant | :( no. | 12:34 |
| wgrant | Something else must have been murdering the appserver. | 12:34 |
| jelmer | I'm having problems getting through to the appserver now | 12:35 |
| jelmer | (the usual "Sorry, there was a problem connecting to the Launchpad server. ") | 12:35 |
| henninge | wgrant, jelmer: very cool, thanks! ;-) | 12:36 |
| wgrant | gary_poster: FWIW, that huge bug (230550 or whatever it is) was consistently rendering on qastaging in 8.6s earlier. | 12:37 |
| wgrant | So it can render when things aren't broken. | 12:37 |
| wgrant | But only just. | 12:37 |
| gary_poster | wgrant, oh ok | 12:39 |
| gary_poster | wgrant, thanks for letting me know. | 12:39 |
| gary_poster | are you all discussing a problem we need to jump on? qastaging is loading fine for me right now | 12:41 |
| gary_poster | as is launchpad.net | 12:41 |
| === henninge is now known as henninge-afk | ||
| gary_poster | allenap, https://code.launchpad.net/~gary/launchpad/profiler/+merge/71192 is ready if you are. The diff is 907 lines, though. | 12:48 |
| allenap | gary_poster: I'll give it a go. Nearly done with my current one. | 12:48 |
| gary_poster | thanks allenap | 12:48 |
| wgrant | gary_poster: staging's been blocking for 14s and otherwise timing out a bit. Certainly not something that needs to be jumped on -- it's staging. | 12:53 |
| gary_poster | wgrant, ok. Thanks for the explanation. | 12:53 |
| mwhudson | jelmer: re https://answers.launchpad.net/launchpad/+question/167471, last time i looked the svn caches compresses veeeery well :) | 13:06 |
| deryck | Morning, all. | 13:09 |
| === mwhudson_ is now known as mwhudson | ||
| jelmer | mwhudson: It'd be annoying to compress/uncompress it every time we're checking for new revisions in e.g. a small branch in the apache repo | 13:31 |
| mwhudson | jelmer: yes, i guess so | 13:31 |
| === jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: allenap, jcsackett | Critical bugs: 234 - 0:[#######=]:256 | ||
| mwhudson | jelmer: a cache backend that supports compression? | 13:31 |
| mwhudson | not sure what that means | 13:31 |
| jcsackett | allenap: can i throw https://code.launchpad.net/~jcsackett/launchpad/fix-picker-entry-adapters/+merge/71204 into your queue? | 13:32 |
| allenap | jcsackett: Sure. I'm doing a big review for Gary right now, but yours can be next. | 13:32 |
| jcsackett | allenap: awesome, thanks. :-) | 13:33 |
| jelmer | mwhudson: the plan is still to use bzr pack files to store cache data, but that requires some refactoring of the pack code | 13:33 |
| mwhudson | jelmer: ah yes, that would be great i suspect | 13:34 |
| LPCIBot | Project devel build #963: STILL FAILING in 4 hr 52 min: https://lpci.wedontsleep.org/job/devel/963/ | 13:37 |
| jelmer | mwhudson: btw, I've now updated https://code.launchpad.net/~jelmer/launchpad/bzr-code-imports/+merge/70684 to use the safe branch opener from the puller. If you have a chance to have another look, that'd be great. | 13:43 |
| jelmer | the safe branch opener has been extracted from BranchMirrorer and merged with the one from bzrutils | 13:44 |
| mwhudson | jelmer: i saw that change go by (happily) | 13:44 |
| rvba | allenap: Thanks for the review! I've followed your suggestions ... and this is the end of this week's work on this Javascript code: \o/. | 14:00 |
| allenap | rvba: Awesome, I too shall \o/ | 14:00 |
| rvba | allenap: we even shall _o/\o_ | 14:01 |
| allenap | Cool :) | 14:02 |
| allenap | gary_poster: I'm having trouble opening callgrind files with kcachegrind. It says "Check it exists and you have enough permissions to read it." | 14:07 |
| allenap | Fwiw, I have checked the permissions :) Have you seen that problem before? | 14:08 |
| gary_poster | allenap, no... | 14:08 |
| gary_poster | allenap, I've used files from qastaging. Let me see if I can dupe with locally produced files. I haven't changed the internal aspect of how those files are created, but I've touched the periphery, so maybe I messed something up. | 14:10 |
| gary_poster | (allenap, I've been using pstats stuff for my actual analysis locally, fwiw) | 14:10 |
| gary_poster | allenap, wfm | 14:12 |
| allenap | gary_poster: Okay, maybe it's a problem with kcachegrind. Can you try with https://devpad.canonical.com/~gavin/callgrind.out.2011-08-11_15:05:50.484-RootObject:index.html-OOPS-2049X3-Dummy-6 | 14:14 |
| allenap | ? | 14:14 |
| gary_poster | sure allenap, trying | 14:14 |
| gary_poster | allenap, fails for me too. Looking at file, not that I know much about the syntax... | 14:16 |
| gary_poster | allenap, look at the file :-) | 14:17 |
| gary_poster | allenap, oh, no, my download error. lemme try again | 14:17 |
| === henninge-afk is now known as henninge | ||
| henninge | adeuring: did you get my sms | 14:19 |
| henninge | ? | 14:19 |
| adeuring | henninge: no... reminds me that I should update my mobile phone number in the directtory... | 14:19 |
| henninge | adeuring: I used the one I had on my phone - probably the old one. | 14:21 |
| henninge | deryck: Hi, sorry I missed the call! ;) | 14:21 |
| adeuring | henninge: right | 14:21 |
| deryck | henninge: no worries. adeuring warned you might be away. | 14:21 |
| sinzui | bigjools, ping | 14:22 |
| bigjools | sinzui: you punged | 14:24 |
| gary_poster | allenap, I got the right file this time. The problem is that it is a pstats file, not a callgrind file. You can verify by using python -m pstats <file name> and then "stats 40" or something. This is a bug in my branch. Fixing it ought to be easy, but I'm not sure at all how to test it.Mm, I have an idea on something that is barely ok. I'll ping you when I have something in. Thanks for catching this, and sorry yo | 14:24 |
| sinzui | bigjools, I am struggling to remember the name of the method that can check if a SPN or DSP was ever published. You mentioned it in a bug about telling users reporting bug that the package dies not exist. | 14:24 |
| bigjools | sinzui: IArchive.getPublishedSource() | 14:24 |
| sinzui | thanks | 14:25 |
| bigjools | np. That's probably the most important soyuz method to know about. :) | 14:25 |
| allenap | gary_poster: Ah, interesting. I'm glad I bumped into it then :) | 14:25 |
| gary_poster | :-) | 14:25 |
| gary_poster | allenap, fixed: http://pastebin.ubuntu.com/663445/ | 14:40 |
| gary_poster | (change pushed) | 14:40 |
| allenap | gary_poster: Cool. | 14:40 |
| jcsackett | allenap: sinzui looked at my branch, so don't worry about it. | 14:47 |
| allenap | jcsackett: Cool, okay. | 14:47 |
| gary_poster | matsubara, hey. could you make https://launchpad.net/lp-devops-dashboard maintained by ~launchpad please? | 15:05 |
| matsubara | gary_poster, done | 15:06 |
| gary_poster | Thanks matsubara :-) | 15:06 |
| matsubara | np | 15:06 |
| gary_poster | thank you allenap! for #1, answer is because I was working from an original source that did it that way. It is convenient for subclasses that want to share the lock, which we were doing, but we're not doing that anymore with this branch. I'll simplify as you suggest. I'll also do your #2: good idea. Thanks again | 15:12 |
| allenap | gary_poster: Cool, and you're welcome. | 15:14 |
| === allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | Critical bugs: 234 - 0:[#######=]:256 | ||
| matsubara | bigjools, hi | 15:43 |
| bigjools | matsubara: hey | 15:43 |
| === beuno is now known as beuno-lunch | ||
| matsubara | bigjools, you said in a reply to the dashboard email: "Possibly make it show more pending revisions like the deployment report does". What did you mean? | 15:45 |
| matsubara | bigjools, taking https://devpad.canonical.com/~lpqateam/qa_reports/deployment-db-stable.html as an example, what info there you'd like to see in the dashboard? | 15:45 |
| bigjools | matsubara: it only shows one; it would be nicer if it showed more, if not all | 15:45 |
| matsubara | bigjools, you mean all the needstesting ones or everything after the blocking revision? | 15:47 |
| bigjools | matsubara: mainly the needs testing ones | 15:47 |
| bigjools | hopefully it won't be too big a list since we're all awesome at doing QA | 15:48 |
| matsubara | bigjools, ok, thanks for the info. I'm filing bugs from your feedback email. | 15:50 |
| bigjools | matsubara: cool, thanks for taking it on board | 15:50 |
| matsubara | you're welcome | 15:51 |
| === matsubara is now known as matsubara-lunch | ||
| benji | jcsackett: when you get a chance, I have a little JS branch for you: https://code.launchpad.net/~benji/launchpad/bug-823321/+merge/71229 | 16:06 |
| jcsackett | benji: looking at it now. | 16:06 |
| benji | cool | 16:06 |
| jcsackett | benji: i'm a little confused about the logic of always doing checks like (user_has_search === automated_search). given your stated goal, isn't it clearer to just check if user_has_searched is true? or is there something here i'm missing (always very possible)? | 16:11 |
| benji | jcsackett: if user_has_searched and *this* result is from the user searching (!automated) then we want to display the results, that's why we have to check both | 16:13 |
| jcsackett | benji: ah, okay. | 16:14 |
| sinzui | jcsackett, do you have time to mumble? | 16:23 |
| jcsackett | sinzui: sure. | 16:25 |
| jcsackett | sinzui: hm. mumble will not start for me. give me a few moments. | 16:28 |
| sinzui | okay | 16:28 |
| * deryck goes offline for lunch, back very soon | 16:29 | |
| sixstring | sinzui: hey, I just saw pocketlint. pretty cool. | 16:43 |
| henninge | gary_poster: Hi! | 16:44 |
| === beuno-lunch is now known as beuno | ||
| sinzui | sixstring, thanks. Beware of js linting on Oneric. seed segfaults. I may switch to a different js backend if there is no commitment to support it | 17:13 |
| abentley_ | sinzui: I would like SourcePackageNameSet.new to raise InvalidName if the name is invalid. Also, I'd move InvalidName to registry.errors. Thoughts? | 17:20 |
| gary_poster | henninge, hey. was lunching, and may need to take half day | 17:23 |
| === abentley_ is now known as abentley | ||
| === matsubara-lunch is now known as matsubara | ||
| jcsackett | benji: sorry i forgot to update the MP and tell you earlier. r=me on that js branch. | 17:38 |
| benji | jcsackett: no problem; thanks | 17:38 |
| === Ursinha` is now known as Ursinha | ||
| === micahg_ is now known as micahg | ||
| LPCIBot | Project db-devel build #800: FAILURE in 6 hr 58 min: https://lpci.wedontsleep.org/job/db-devel/800/ | 20:37 |
| mtaylor | lifeless: ping | 21:04 |
| thumper | hey mtaylor | 21:06 |
| mtaylor | hey thumper ! | 21:07 |
| mtaylor | thumper: I was just brainstorming about whether or not we could make linked branches in bugs point to external branches or not | 21:07 |
| thumper | mtaylor: not very easily | 21:07 |
| thumper | mtaylor: the link points to a branch id | 21:08 |
| mtaylor | thumper: ah. | 21:08 |
| thumper | although... | 21:08 |
| thumper | I believe there is still the concept of a remote branch | 21:08 |
| thumper | but we were wanting to kill that | 21:08 |
| mtaylor | thumper: I was asking because we were hacking it in bug comments right now: https://bugs.launchpad.net/openstack-ci/+bug/809479 | 21:08 |
| _mup_ | Bug #809479: gerrit integration test <OpenStack Core Infrastructure:Fix Committed> < https://launchpad.net/bugs/809479 > | 21:08 |
| mtaylor | thumper: well, and I'd _thought_ about having something that would make an imported branch and then link to that - but that feels _REALLY_ heavy | 21:10 |
| thumper | mtaylor: doable | 21:12 |
| mtaylor | thumper: I mean, right now I'm just having idle imaginings... I think as we do more with gerrit we'll need to understand what the workflow _actually_ is and what is helpful | 21:13 |
| LPCIBot | Project devel build #964: STILL FAILING in 7 hr 19 min: https://lpci.wedontsleep.org/job/devel/964/ | 21:29 |
| === matsubara is now known as matsubara-afk | ||
| wallyworld_ | sinzui_: we are here | 23:03 |
| wallyworld_ | sinzui_: we can here you | 23:03 |
| jcsackett | sinzui: we both heard you. | 23:03 |
| wallyworld_ | hear | 23:03 |
| jcsackett | we've been chatting. | 23:03 |
| === sinzui_ is now known as sinzui | ||
| sinzui | looks like I had network issues | 23:03 |
| StevenK | http://pastebin.ubuntu.com/663335/ | 23:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!