| poolie | flacoste, hi? | 00:02 |
|---|---|---|
| flacoste | hi poolie | 00:03 |
| huwshimi | Does anyone know if the little bug icon on the left hand side of bug listings has any more meaning than just showing the importance of the bug? | 00:16 |
| wgrant | huwshimi: It's just the importance. | 00:17 |
| huwshimi | wgrant: Makes sense. I guess it was just a historical thing | 00:18 |
| wgrant | huwshimi: Now you've lost me. | 00:20 |
| huwshimi | wgrant: Oh I just mean, it didn't seem to have any more meaning than showing the importance, which is duplication of the importance column and so was probably still there because it has always been there. | 00:21 |
| wgrant | I find it's pretty handy to be able to see the importance while scanning down the first few words of the summary. | 00:22 |
| wgrant | But it predates the coloured importance column. | 00:22 |
| wgrant | In fact, it dates back to the days of separate severity/priority columns. | 00:22 |
| huwshimi | wgrant: That's good to know, thanks | 00:23 |
| wallyworld_ | thumper: hey, i found out the hard way that we allow branch stacking to form a loop | 00:42 |
| wallyworld_ | well, there are tests which do it anyways | 00:42 |
| wallyworld_ | surely that's not something we would expect to have occur in real life? | 00:43 |
| lifeless | bzr doesn't support it | 00:45 |
| lifeless | but, it can happen | 00:45 |
| lifeless | so we need to handle it gracefully | 00:46 |
| mwhudson | you can create such branches with vfs level access if nothing else, so it would be bad if the db melted in this situation | 00:46 |
| wallyworld_ | yeah, i've rolled back a trigger i added to db-devel and will rework it to handle this | 00:47 |
| poolie | hi huwshimi | 00:50 |
| huwshimi | poolie: Hey | 00:50 |
| poolie | huwshimi, jelmer is keen to look at the branch pages too some time | 00:50 |
| huwshimi | poolie: Ok great. I think what might happen is that it might end up being a feature level project sometime. It's just cropped up a few times recently that we need to clean up some of our basic features | 00:53 |
| lifeless | poolie: hundreds? no, 75 :) | 00:53 |
| StevenK | Now on revision 13999. | 02:58 |
| StevenK | Someone land something! | 02:58 |
| wgrant | I have an MP up. | 03:03 |
| wgrant | StevenK: https://code.launchpad.net/~wgrant/launchpad/overridable-dbconfig/+merge/76316 | 03:04 |
| wgrant | It's even already tested. | 03:04 |
| wgrant | Actually, the db-stable merge will be r14000 :) | 03:04 |
| wgrant | hloeung gets it :( | 03:04 |
| nigelb | Did we reach 14000? | 03:18 |
| wgrant | nigelb: Yep. | 03:19 |
| wgrant | [Branch ~launchpad-pqm/launchpad/devel] Rev 14000: Merging db-stable at revno 10994 | 03:19 |
| nigelb | awwww | 03:19 |
| nigelb | Dammit | 03:20 |
| nigelb | wgrant: | 03:20 |
| nigelb | Err | 03:20 |
| nigelb | Do you know if the app servers all of the same rev now? | 03:20 |
| wgrant | nigelb: codehosting, librarian, mailman, ftpmaster and ppa are all behind a bit. | 03:20 |
| wgrant | codehosting and mailman are being upgraded now. | 03:21 |
| wgrant | librarian, ftpmaster, ppa are a bit more of a challenge. | 03:21 |
| nigelb | wgrant: I'm thinking in terms of my db patch | 03:21 |
| wgrant | So was I :) | 03:21 |
| nigelb | HA | 03:21 |
| nigelb | I'm not sure which service that falls into though. | 03:22 |
| wgrant | All of them. | 03:22 |
| wgrant | That particular patch affects *every* service. | 03:22 |
| nigelb | WIN. | 03:22 |
| wgrant | So we need at least 13932 everywhere. | 03:23 |
| wgrant | http://paste.ubuntu.com/694210/ was the status 20 minutes ago. | 03:23 |
| wgrant | 13996 is the rev that's deploying now. | 03:23 |
| wgrant | You can see the first host had it 20 minutes ago. | 03:23 |
| nigelb | AH, nice! | 03:24 |
| wgrant | (mizuho == librarian, forster == mailman, cocoplum == ftpmaster, germanium == ppa, crowberry == codehosting) | 03:25 |
| nigelb | How many squads are there? Teal, Yellow, Orange, Red, and any more? | 03:34 |
| wgrant | That's all. | 03:34 |
| wgrant | Teal was formed by the merge of Blue and Green. | 03:34 |
| wgrant | After members of Blue departed. | 03:34 |
| nigelb | Blue departed? | 03:34 |
| wgrant | Green started small, and a couple of members of Blue left, so it was decided to merge Blue and Green into a single squad. | 03:35 |
| nigelb | ah | 03:36 |
| james_w | lifeless, hi | 03:40 |
| nigelb | He's supposed to be away, but he was around earlier. | 03:41 |
| wgrant | james_w: He's not meant to be here on Wednesdays at the moment. | 03:41 |
| james_w | wgrant, then he shouldn't ping me :-) | 03:41 |
| wgrant | And, in a manner rather unlike his usual, he indeed is sometimes not here on Wednesdays. | 03:41 |
| nigelb | heh | 03:41 |
| nigelb | He was around in the morning | 03:41 |
| nigelb | "Think of it as priorities: today my priority is my family. But I may do somework. On work days my priority is work, but I may look after my family." | 03:42 |
| StevenK | I thought since there were two codehostings, they could go into NDT | 03:44 |
| wgrant | StevenK: They can be updated without downtime, but it requires handholding. | 03:44 |
| wgrant | And takes more than an hour. | 03:44 |
| wgrant | so they're not in the usual nodowntime set. | 03:44 |
| wgrant | They must be explicitly requested. | 03:44 |
| wgrant | I documented this on LPS last week :) | 03:44 |
| StevenK | And forster is just ... odd | 03:45 |
| mrevell | Hallo | 07:53 |
| lifeless | ola | 07:53 |
| rvba | Morning mrevell. | 07:53 |
| adeuring | good morning | 08:07 |
| === almaisan-away is now known as al-maisan | ||
| poolie | danilos, hi, if i put up a patch that just turned off those mails (maybe by a flag) would anyone actually complain? | 08:36 |
| poolie | re bug 855150 | 08:36 |
| _mup_ | Bug #855150: excessive translation import template mails (also poor phrasing) <mail> <spam> <translations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/855150 > | 08:36 |
| danilos | poolie, well, many would be happy (especially ubuntu packagers), but some would be worried that their files have not been imported with such a change | 08:38 |
| poolie | the worry would come from us suddenly stopping (that could be handled by an announcement) or because they do count on getting them | 08:39 |
| danilos | poolie, fwiw, I'd say just go for it, but make sure not to silence the emails when there are errors: i.e. silence only the "no problems" emails | 08:39 |
| poolie | yeah | 08:39 |
| poolie | i think one of the other bugs says the "errors" mail goes to the wrong people | 08:39 |
| danilos | poolie, from us suddenly stopping (iow, they have learned to expect them) | 08:39 |
| poolie | but that's perhaps at least not as common | 08:39 |
| danilos | poolie, I think that one might be wrong, the error goes to the committer, which is the right person, the fact that it doesn't say that is a different bug, but hey... :) | 08:40 |
| poolie | hm | 08:41 |
| poolie | the person who last committed? | 08:41 |
| poolie | they may not know or care about translation though | 08:41 |
| danilos | poolie, well, since LP is able to generate templates from a tree, they may have broken it even if they don't care about it (eg. introduced problematic _() marking or something) | 08:42 |
| poolie | oh totally | 08:42 |
| poolie | very likely | 08:43 |
| poolie | but, i suspect an error mail from launchpad will not get them to fix it | 08:43 |
| poolie | they will need a more personal mail from a person within their project who does know/care about gettext | 08:43 |
| danilos | poolie, well, we did talk about having a 'translation driver' for a project long time ago, we just never did it, but as I said, this particular area is very badly structured and would need a lot of improvements | 08:44 |
| danilos | poolie, import queue core mechanics are very (and I mean *very*, circa 2005) code that we never had time to properly clean up, but only stacked things on top | 08:45 |
| danilos | very _old_ | 08:45 |
| === gmb` is now known as gmb | ||
| poolie | mrevell, +1 on the unexplained oops being awful, fwiw | 09:03 |
| wgrant | That has my full support as well. | 09:24 |
| jtv | cjwatson: quick note while otp: sid's been converted to transitional debian domination, and all active debian publications are now Published, not Pending, without exception. Conversions should complete in a few hours, and then we'll land permanent debian domination. The permanent form will finally delete all packages that Debian has deleted. | 09:26 |
| jtv | cjwatson: the transitional form's dealing nicely with withdrawn package versions & failed builds. | 09:26 |
| cjwatson | jtv: OK, that should make life simpler for us. Thanks. | 09:45 |
| jtv | cjwatson: note that we've already seen 2 cases of Debian regressing to an earlier version; in those cases, the latest-but-deleted Debian version will also become Deleted in LP. | 09:46 |
| cjwatson | uh | 09:47 |
| cjwatson | do you have specific examples? the Debian archive is set up to never go backwards in versions, like ours | 09:47 |
| cjwatson | I'm not aware of any historical incidences of that rule being violated | 09:48 |
| jtv | We found 1 instance of this in sid… wgrant, what was that package in sid where the latest-published version was no longer in the latest Sources list? | 09:49 |
| wgrant | cjwatson: One was in experimental, where it was deleted and then reappeared with a lower version. I didn't find that entirely unexpected. | 09:50 |
| wgrant | The sid case was similar, but rather unexpected. | 09:51 |
| * wgrant finds the links. | 09:51 | |
| wgrant | But in both cases they were removed some time before the lower version appeared. | 09:51 |
| wgrant | http://packages.qa.debian.org/t/tcc.html is the experimental case | 09:51 |
| wgrant | http://packages.qa.debian.org/i/ixp4xx-microcode.html the very odd, but plausible, unstable one. | 09:51 |
| wgrant | 2.4-3 was skipped during a maintainer change, then uploaded 2 years late, or something. | 09:52 |
| wgrant | After it had been removed. | 09:52 |
| wgrant | One of the strangest occurences I've seen. | 09:52 |
| wgrant | Also, it was uploaded with armel binaries. | 09:52 |
| wgrant | Ah, it's probably an armel-specific package, I guess. | 09:52 |
| wgrant | Yes. | 09:53 |
| cjwatson | Wow, that's weird. | 09:54 |
| wgrant | Yes. | 09:54 |
| wgrant | The reappearance is weird enough. | 09:54 |
| wgrant | The version and content of the changelog is... unbelievable. | 09:55 |
| wgrant | But it apparently happened. | 09:55 |
| cjwatson | We should've reported that to Debian, really | 09:55 |
| wgrant | Well, we only discovered it like 2 hours ago. | 09:55 |
| cjwatson | I'm not seeing the experimental case | 09:56 |
| jtv | I guess this means it's in the pool but not really published—so kind of unnoticed garbage? | 09:56 |
| cjwatson | it seems to have reappeared with the *same* version | 09:56 |
| wgrant | cjwatson: + vs ~ | 09:56 |
| cjwatson | (and same changelog) | 09:56 |
| wgrant | cjwatson: Took me a while to notice. | 09:56 |
| cjwatson | oh yes | 09:56 |
| wgrant | jtv: It is published. | 09:56 |
| cjwatson | "ROM; Wrong version number" | 09:56 |
| cjwatson | sigh | 09:56 |
| wgrant | Heh. | 09:56 |
| wgrant | I didn't know they did that... | 09:56 |
| cjwatson | ftpmaster should've told the maintainer to take a hike | 09:56 |
| wgrant | Yes. | 09:56 |
| wgrant | Although it *is* experimental, I guess... | 09:56 |
| cjwatson | I know they'd refuse to do that in unstable | 09:57 |
| wgrant | I would have thought they'd refuse it in experimental too, so you never know. | 09:57 |
| wgrant | What fun may lie ahead. | 09:57 |
| cjwatson | mm | 09:57 |
| cjwatson | the ixp4xx-microcode case looks like joeyh being unaware of the later versions | 09:58 |
| wgrant | Indeed. | 09:58 |
| wgrant | But I wonder how. | 09:58 |
| cjwatson | and dak having forgotten about it so it didn't reject | 09:58 |
| wgrant | Unless -4 and -5 didn't have binaries. | 09:58 |
| wgrant | Ah, it was removed for not building any binaries. | 09:58 |
| wgrant | That is interesting. | 09:58 |
| wgrant | Ahhh. | 09:59 |
| wgrant | -4 and -5 had *arm* binaries only, it seems. | 09:59 |
| wgrant | So I guess when arm was dropped it ran out of binaries and got removed... | 10:01 |
| wgrant | Anyway, those two seem to be the only cases of that happening since we started importing Debian. | 10:01 |
| wgrant | cjwatson: ixp4xx-microcode is probably harmless, since the only binaries for the bad versions are for arm, which is long dead... do we want to tell Joey or someone about it anyway? | 10:08 |
| cjwatson | Might not hurt; it should perhaps be bumped to 2.4-6 anyway | 10:12 |
| cjwatson | Would anyone object to me taking bug 804252? It looks relatively trivial but I think it would eliminate a reasonably common source of user-visible error; I currently have http://paste.ubuntu.com/694372/ and am about to run it through tests | 10:27 |
| _mup_ | Bug #804252: Please support InRelease files <Launchpad itself:Triaged> < https://launchpad.net/bugs/804252 > | 10:27 |
| wgrant | cjwatson: Is apt safe these days? | 10:28 |
| wgrant | I haven't looked at it recently. | 10:28 |
| wgrant | And last time I did it didn't come out too well. | 10:28 |
| wgrant | It's also slightly non-trivial to support it for primary and !primary. | 10:29 |
| wgrant | As primary signing is still done by a non-native post-publication shell script. | 10:29 |
| wgrant | Everything else (mm, maybe not partner) is done using different, native code. | 10:29 |
| cjwatson | apt's broken validation was fixed a while back | 10:30 |
| cjwatson | oh yes, I didn't notice cronscripts/publishing/distro-parts/ubuntu/publish-distro.d/10-sign-releases | 10:31 |
| cjwatson | validation> assuming you mean bug 784473 | 10:34 |
| _mup_ | Bug #784473: Treats partial InRelease signature as verifying the entire file <apt (Ubuntu):Fix Released> <apt (Ubuntu Natty):Fix Released> <apt (Ubuntu Oneiric):Fix Released> < https://launchpad.net/bugs/784473 > | 10:34 |
| cjwatson | http://paste.ubuntu.com/694375/ should deal with the shell script case | 10:35 |
| cjwatson | although it doesn't look like there are applicable test? | 10:35 |
| cjwatson | *tests | 10:35 |
| wgrant | That's very probably not tested, right. | 10:36 |
| cjwatson | Is there anything else I should be looking at regarding apt? Since this is deployed in Debian I'd be surprised if it actually failed hard or anything | 10:37 |
| wgrant | cjwatson: It didn't fail hard, it was just trivially exploitable, and I'm not entirely confident with having our archive keys doing inline signatures until someone actually audits apt slightly. | 10:38 |
| wgrant | But maybe. | 10:38 |
| cjwatson | I thought that's what Marc had done in that bug report above | 10:40 |
| cjwatson | I can follow up with him if you'd like and find out what security's confidence level is | 10:41 |
| cjwatson | Given that we had a report of Release/Release.gpg skew just this morning, I'd like to do something about this, though | 10:41 |
| wgrant | Sorry, missed half of the conversation here. | 10:42 |
| wgrant | Yeah, it's probably safe, but I am somewhat wary of inline signatures given that just about nobody seems to implement them properly :/ | 10:42 |
| wgrant | Your diff is probably fine, though. | 10:43 |
| cjwatson | I'll mail the security team and see what they think | 10:45 |
| === jam1 is now known as jam | ||
| === al-maisan is now known as almaisan-away | ||
| === Pendulum_ is now known as Pendulum | ||
| === almaisan-away is now known as al-maisan | ||
| === matsubara-afk is now known as matsubara | ||
| benji | I'm having an ec2 land issue that I wondered if anyone else had seen (jtv has had some ec2 land issues lately, but looking back at his messages they don't seem related): ec2: ERROR: You must have an ssh agent running with keys installed that will allow the script to access Launchpad and get your branch. | 13:26 |
| benji | I'm not aware of any changes to my setup that would have precipitated the error. | 13:27 |
| bigjools | I get that all the time in KDE | 13:27 |
| bigjools | ssh-add before you start ec2 | 13:28 |
| === mtaylor_ is now known as mtaylor | ||
| sinzui | jcsackett, ping | 13:48 |
| jcsackett | sinzui: hello. | 13:48 |
| sinzui | jcsackett, do you need an enchantment to land your branch | 13:49 |
| jcsackett | sinzui: it looks like it. same error, nothing has gotten around it. | 13:49 |
| * jcsackett is incredibly frustrated with ec2 and his environ. | 13:49 | |
| sinzui | jcsackett, I will land it now. matsubarawill want to test this today | 13:50 |
| * jcsackett nods | 13:50 | |
| jcsackett | thanks, sinzui. | 13:50 |
| sinzui | jcsackett, do you have a few minutes to mumble about what we do next? | 13:50 |
| jcsackett | sinzui: sure, just a moment. | 13:52 |
| === abentley changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: abentley | Critical bugs: 256 - 0:[#########]:256 | ||
| === al-maisan is now known as almaisan-away | ||
| === almaisan-away is now known as al-maisan | ||
| === al-maisan is now known as almaisan-away | ||
| rvba | abentley: Hi, would you please mentor a review of mine? Gavin is my mentor and I'm reviewing one of Gavin's branch ;) | 14:24 |
| abentley | rvba: sure. | 14:24 |
| rvba | abentley: Thanks: https://code.launchpad.net/~allenap/launchpad/longpoll-merge-diff-event/+merge/76407 | 14:24 |
| abentley | rvba: as someone with domain knowledge (I wrote the original code), I'd ask whether this is the right place for this. This not catching every time BMP.preview_diff is updated, only every time a Job updates it. | 14:29 |
| abentley | rvba: I don't know that any code duplication is required. Anything that would be duplicated can be moved into a function called by both tests. | 14:30 |
| rvba | abentley: Very good point. | 14:30 |
| rvba | abentley: Right. | 14:31 |
| abentley | allenap: What do you think about emitting an event every time BMP.preview_diff is updated, instead of every time a UpdatePreviewDiffJob updates it? | 14:34 |
| rvba | abentley: So I guess your advice would be to hook up the event generation directly in lib/lp/code/model/branchmergeproposal.py? | 14:34 |
| abentley | rvba: I'd certainly look into that. | 14:35 |
| === almaisan-away is now known as al-maisan | ||
| allenap | abentley: Sounds good to me. I have spotted one problem... | 14:40 |
| allenap | BranchMergeProposal already relies on ObjectModifiedEvents being sent out at particular times. | 14:41 |
| allenap | The merge_proposal_modified subscription handler for example, which sends email. | 14:41 |
| allenap | So emitting extra events is going to create more mail. | 14:42 |
| === al-maisan is now known as almaisan-away | ||
| allenap | I may have to create a PreviewDiffUpdated event. | 14:44 |
| abentley | allenap: A PreviewDifffUpdated event that derives from OjbectModifiedEvent, but is blacklisted from generating email? | 14:45 |
| allenap | abentley: I think it would probably not inherit from ObjectModifiedEvent. | 14:46 |
| allenap | Just from IObjectEvent. | 14:46 |
| abentley | allenap: Since it does represent a modification of an object, and since ObjectModifiedEvent is our standard way of communicating that, I'd be inclined to make it inherit from it at least. | 14:47 |
| rvba | allenap: If a ObjectModifiedEvent is already emitted ... doesn't it mean that we already have what we want? | 14:48 |
| abentley | allenap: but can't you just change the mail handler to skip preview-diff-only events? | 14:48 |
| allenap | Alternatively I could just do lp.app.longpoll.emit(bmp) instead of zope.event stuff. | 14:48 |
| allenap | rvba: They're only emitted by browser code, not the job code. | 14:48 |
| rvba | allenap: ah ok. | 14:48 |
| allenap | abentley: Yeah, that's probably the most elegant way to do it. | 14:48 |
| abentley | allenap: I have been trying to find a "pre-change" hook for Storm columns, but so far, no dice. | 14:49 |
| allenap | abentley: There's storm_validator (?) to abuse ;) | 14:50 |
| abentley | allenap: Storm also has its own events, but they're not meant for API clients to use. | 14:51 |
| allenap | abentley: I could subclass Storms column/property and override __set__ and __delete__. | 14:53 |
| abentley | allenap: there's this thing I've seen a few times where there's a read-only property and a private version of the property, and a public setter. That might be the best way to go. | 14:58 |
| allenap | abentley: Hehe :) | 14:59 |
| abentley | What's funny? | 14:59 |
| allenap | abentley: That's the pattern used in Job.status/_status, the one I tried to replace with a storm_validator a while back. | 15:10 |
| allenap | I thought you were alluding to that. | 15:10 |
| abentley | allenap: I was, but I'd forgotten you made the change. | 15:10 |
| abentley | allenap: ISTM that Int accepts variable_kwargs, which will let you specify an event system, which will have 'emit' invoked on it when the value changes. | 15:17 |
| allenap | abentley: Ah, interesting! Thanks. | 15:18 |
| jcsackett | jam: are you around/have a few moments? | 15:19 |
| cr3 | flacoste: heads up, I just created a mailing list for ~launchpad-results to which we added ~launchpad yesterday so you will probably not want the ~launchpad folks to get emails from thatlist | 15:31 |
| === matsubara is now known as matsubara-lunch | ||
| flacoste | cr3: they won't receive mail from the list unless they subscribe to it | 15:40 |
| flacoste | cr3: so everything should be fine | 15:40 |
| cr3 | flacoste: excellent, thanks! | 15:41 |
| jcsackett | sinzui: up for another quick round of mumbling? | 15:54 |
| sinzui | yes | 15:54 |
| === matsubara-lunch is now known as matsubara | ||
| === beuno is now known as beuno-lunch | ||
| === salgado is now known as salgado-lunch | ||
| === deryck is now known as deryck[lunch] | ||
| === abentley is now known as abentley-lunch | ||
| * gary_poster tries to remember who was on the soyuz team, to try to ask someone if https://bugs.launchpad.net/launchpad/+bug/855479 is reasonable or not...bigjools not here. StevenK and wgrant hopefully sleeping. Celso Somewhere Else. ...am I forgetting someone? | 16:55 | |
| _mup_ | Bug #855479: Daily recipe does not patch changelog to current release <Launchpad itself:New> < https://launchpad.net/bugs/855479 > | 16:55 |
| gary_poster | or maybe that's codehosting, in which case we are significantly more without knowledgable resources... | 16:57 |
| gary_poster | abentley-lunch...if you have a moment, am I right that this is about what Paul was working on right before he left for U1? If so, do you know if this is a reasonable bug, or if it's user error? It looks reasonable, but I really don't know. I can try asking Paul if you are not sure. | 17:01 |
| gary_poster | https://bugs.launchpad.net/launchpad/+bug/855479 | 17:01 |
| _mup_ | Bug #855479: Daily recipe does not patch changelog to current release <Launchpad itself:New> < https://launchpad.net/bugs/855479 > | 17:01 |
| === beuno-lunch is now known as beuno | ||
| === salgado-lunch is now known as salgado | ||
| === deryck[lunch] is now known as deryck | ||
| flacoste | gary_poster: jelmer can probably have an informed opinion too | 17:39 |
| flacoste | gary_poster: jelmer was on the soyuz team for more than a year | 17:39 |
| gary_poster | flacoste, ok cool, thanks | 17:39 |
| flacoste | it might be a problem with bzr-builder which he maintains with the bzr team | 17:40 |
| gary_poster | jelmer, if you are around, the question is just this. Do you know if this is a reasonable bug, or if it's user error? It looks reasonable, but I really don't know. https://bugs.launchpad.net/launchpad/+bug/855479 | 17:40 |
| _mup_ | Bug #855479: Daily recipe does not patch changelog to current release <Launchpad itself:New> < https://launchpad.net/bugs/855479 > | 17:40 |
| abentley-lunch | gary_poster: I don't think he was working on that specifically, but yes, the code team was working on recipes when he left. | 17:40 |
| gary_poster | abentley-lunch, ok cool. Do you have any ideas on this? | 17:40 |
| abentley-lunch | gary_poster: it would definitely be a bzr-builder issue. | 17:41 |
| gary_poster | ok. Since you don't say the bug is broken, I'll assume it is real, and triage it high and move on. | 17:42 |
| gary_poster | thanks abentley-lunch | 17:42 |
| abentley-lunch | gary_poster: Well, it looks like bzr-builder already accomodates specifying the distribution. | 17:43 |
| abentley-lunch | gary_poster: so presumably it's a matter of supplying that flag. | 17:43 |
| gary_poster | abentley-lunch, oh ok. On https://code.launchpad.net/~diwic/+recipe/alsa-hda-daily it looks like he is correctly specifying what he wants (Maverick and Natty). Is this something he should have done differently, or something we need to expose, or...? | 17:44 |
| james_w | http://paste.ubuntu.com/694633/ | 17:45 |
| abentley-lunch | gary_poster: I don't think it's something we need to expose. We have the data, we just need to use it. | 17:46 |
| gary_poster | james_w, that's the likely fix? | 17:46 |
| gary_poster | abentley-lunch, ok I think I've got it, thanks | 17:46 |
| james_w | gary_poster, yep | 17:47 |
| gary_poster | thanks james_w, cool | 17:47 |
| === abentley-lunch is now known as abentley | ||
| gary_poster | abentley, we have no tests for that machinery AFAICT. Am I right, am I missing something, or do you not know? Given that, I'm tempted to apply the patch James gave, and ask for a review from someone who claims to be an expert (you? bigjools?) | 17:59 |
| abentley | gary_poster: we have no automatic tests. We should not be cavalier about that. Breaking the buildd would have serious consequences. | 18:00 |
| gary_poster | abentley, agreed, but do we have any protection mechanism other than "ask the expert"? | 18:00 |
| abentley | gary_poster: There are tests we can run manually, i.e. test_buildd_recipe | 18:01 |
| abentley | gary_poster: That will require a local soyuz: https://dev.launchpad.net/Soyuz/HowToUseSoyuzLocally | 18:02 |
| gary_poster | abentley: test_buildd_recipe: ah, I see. good. So...if we changed 'maverick' to 'natty' in that file maybe it would trigger the broken behavior? local soyuz: cool, though I'm not really comfortable with my background knowledge. I'll make notes in the bug for now. | 18:08 |
| abentley | gary_poster: It depends on the existing changelog contents, but yes. | 18:12 |
| gary_poster | cool, great | 18:12 |
| gary_poster | thank you abentley | 18:12 |
| abentley | gary_poster: you're welcome. | 18:12 |
| bac | c | 19:03 |
| lifeless | incoming | 19:57 |
| lifeless | nigelb: what did you want to ask me ? | 20:03 |
| lifeless | sinzui: is bug 46385 part of disclosure ? | 20:04 |
| _mup_ | Bug #46385: Malone should prohibit filing bugs on obsolete packages <lp-bugs> <motu> <Launchpad itself:Triaged> < https://launchpad.net/bugs/46385 > | 20:04 |
| lifeless | sinzui: I think its a dup of some of your vocab stuff | 20:05 |
| sinzui | lifeless, I think that is fixed | 20:05 |
| lifeless | thanks | 20:05 |
| sinzui | I know I cannot report a bug against a package that was in dapper, but not in oneiric | 20:06 |
| sinzui | I tested this recently | 20:06 |
| === matsubara is now known as matsubara-afk | ||
| james_w | OOPS-2090STAGING85 | 20:22 |
| james_w | no bot :-( | 20:23 |
| james_w | is it worth my time waiting for that oops to show up on lp-oops? | 20:28 |
| james_w | https://lp-oops.canonical.com/?oopsid=2090STAGING85 | 20:39 |
| james_w | any clues | 20:39 |
| james_w | it's a new one on me | 20:39 |
| james_w | oh | 20:40 |
| james_w | it's saying "you must be authenticated to do this" | 20:40 |
| james_w | 500 seems wrong there | 20:40 |
| mwhudson | whuh? | 20:46 |
| mwhudson | looks like you can _almost_ subscribe people to blueprints without being logged in? | 20:47 |
| mwhudson | presumably the model check is usually done in the view | 20:49 |
| mwhudson | er | 20:49 |
| mwhudson | s/model/permission/ | 20:49 |
| mwhudson | yeah, subscribe is in ISpecificationPublic | 20:51 |
| mwhudson | i guess there needs to be ISpecificationAnyPerson too? | 20:52 |
| mwhudson | oops, i see i managed to break feature flags | 20:55 |
| benji | mwhudson: at the moment a virtual ISpecificationAnyPerson is "created" in lib/lp/blueprints/configure.zcml on lines 176-179 by naming attributes | 20:57 |
| mwhudson | benji: ah ok | 20:58 |
| benji | if you have an attribute or two to add, putting them there would be reasonable; moving linkBug and unlinkBug to a real ISpecificationAnyPerson would be reasonable too | 20:58 |
| mwhudson | so i guess subscribe just needs to move out of ISpecificationPublic then | 20:59 |
| benji | it looks that way to me | 21:00 |
| benji | in fact, there are several mutators there that look suspicious | 21:01 |
| === abentley changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 256 - 0:[#########]:256 | ||
| === lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 256 - 0:[#########]:256 | ||
| mwhudson | https://code.launchpad.net/~mwhudson/launchpad/feature-flag-xmlrpc-2/+merge/76493 anyone? | 22:34 |
| lifeless | wgrant: when you arrive - would like input on bug 87012 | 22:38 |
| _mup_ | Bug #87012: Cannot start developing next ubuntu release before the prior one is released <lp-soyuz> <soyuz-publish> <Launchpad itself:Triaged> < https://launchpad.net/bugs/87012 > | 22:38 |
| lifeless | mwhudson: is the old code rolled back ? | 22:39 |
| mwhudson | lifeless: yes | 22:40 |
| lifeless | so why is your branch linked to the rollback bug ? | 22:40 |
| mwhudson | lifeless: because i don't know the correct process i guess | 22:40 |
| lifeless | ok | 22:40 |
| lifeless | so reopen your bug | 22:40 |
| lifeless | the rollback bug was fixed when curtis rolled it back (and will be released when that deploys) | 22:41 |
| mwhudson | ah ok | 22:41 |
| lifeless | in http://bazaar.launchpad.net/~mwhudson/launchpad/feature-flag-xmlrpc-2/revision/14013 | 22:42 |
| lifeless | line 130 of the scopes.py diff. | 22:42 |
| lifeless | why? | 22:42 |
| lifeless | oh | 22:42 |
| lifeless | nvm | 22:43 |
| sinzui | jcsackett, in approved you branch to remove the flags, *but* I do not want it landed until next week. | 22:44 |
| jcsackett | sinzui: works for me. | 22:44 |
| jcsackett | sinzui: not like i can land right now anyway. :-P | 22:45 |
| sinzui | I cannot use qastaging for my official source package branch because of ssl errors | 22:46 |
| sinzui | I have a api script ready for staging when it gets the right revisions | 22:47 |
| mwhudson | lifeless: thanks | 22:50 |
| lifeless | wgrant: ping | 23:10 |
| lifeless | wgrant: could also use a comment on bug 69755 | 23:11 |
| _mup_ | Bug #69755: Gina shouldn't use the maintainer for the sourcepackagerelease owner <lp-soyuz> <Launchpad itself:Triaged> < https://launchpad.net/bugs/69755 > | 23:11 |
| StevenK | huwshimi: Prod. | 23:52 |
| huwshimi | StevenK: Hey | 23:53 |
| StevenK | huwshimi: O hai Mr UI person. Could you please glance at bug 690570, along with my MP for it: https://code.launchpad.net/~stevenk/launchpad/include-ppa-url/+merge/76499 , and tell me what you think of my proposed solution? | 23:54 |
| _mup_ | Bug #690570: Include URL to Private PPA in Private PPA activation email <disclosure> <lp-soyuz> <p3a> <ppa> <Launchpad itself:Triaged> < https://launchpad.net/bugs/690570 > | 23:54 |
| huwshimi | StevenK: Sure | 23:54 |
| wgrant | lifeless: My analysis has always matched what you've written there, but I have never verified that enough to actually Invalid the bug. | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!