[00:34] I wonder [00:34] are implicitly created accounts subject to the name blacklist ? [00:42] How long does qastaging take to update after a buildbot run finishes? [00:42] 40ish minutes [00:42] Let's see how it's going. [00:43] Bah [00:43] buildbot poller missed it. [00:43] So it won't start for another 5 minutes. [00:44] And it will take 30 minutes to update. [00:44] OK, I can probably get some QA done tonight then [00:45] What do you have that's QAable on qastaging? [00:45] It's pretty much all dogfood, but it's easier to wait for qastaging so that the deployment report is up to date ... [00:46] Heh [00:46] That's what I thought. [00:46] gmb: https://bugs.launchpad.net/launchpad/+bug/484712 [00:46] <_mup_> Bug #484712: Potential synchronisation of comments between Launchpad bugs via remote bug trackers

< https://launchpad.net/bugs/484712 > [00:46] gmb: would like feedback/status update (if only to unassign yourself and say that it hasn't been tested...) [00:48] wgrant: Speaking of which; can I commandeer mawson in a bit, after I'm done with a couple of chores? You seem to be the only other person logged in. [00:48] cjwatson: Sure, I'm just abusing its database. [00:48] Nothing that should affect you. [00:49] That won't get clobbered by a code update? [00:49] No. [00:49] Oh, of course, NDT means obviously not [01:04] Query count test failures are a little painful now... [01:04] They include full tracebacks :) [01:25] heh, bad linkificaition on https://bugs.launchpad.net/launchpad/+bug/499438 [01:26] <_mup_> Bug #499438: Better handling of fatal upload errors

< https://launchpad.net/bugs/499438 > [01:27] cjwatson: what do you think the reaction would be to disabling anonymous ftp uploads ? [01:29] Hard to say [01:30] from a quick look at cocoplum:~lp_queue/ubuntu-queue/, it looks as though the bulk of our uploads are FTP right now [01:30] yes, I would expect that [01:30] lp_archive@cocoplum:~$ grep --count upload-ftp /srv/launchpad.net/production-logs/lp_queue/process-upload.log [01:30] 68268 [01:30] ^- unscientific check [01:30] lp_archive@cocoplum:~$ grep --count upload-sftp /srv/launchpad.net/production-logs/lp_queue/process-upload.log [01:30] the reason to suggest this is that a lot of the UI poorness around uploads is coupled to depending on good package metadata (including signatures) for error notifications [01:30] 4789 [01:31] perhaps we should find out why most people aren't using sftp uploads first [01:31] if we knew that 'user foo' did the upload, we could always notify use foo, regardless of the package metadata status [01:31] SFTP provides no progress information. [01:31] And client support in Ubuntu is recent. [01:31] our current dput.cf defaults to FTP [01:31] I don't think it's reasonable to disable it in LP until and unless that's changed, at the very least, including in stable releases [01:31] I think we should simplify our upload processing code for SFTP [01:32] and then get Ubuntu to change (or try changing) to SFTP [01:32] wgrant: in principle SFTP supports progress information [01:32] wgrant: what makes you say that? [01:33] cjwatson: The current client does not. [01:33] YM dput? [01:33] The vast majority of current uploads, both PPA and Ubuntu, are FTP [01:33] Yes. [01:34] I'm not sure the default dput.cf even has an SFTP PPA section. [01:34] Because it requires configuration. [01:34] (we rely on username matching, not just key) [01:36] oh, and Debian's dput doesn't have SFTP support yet [01:36] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505173 [01:36] does that matter particularly? [01:37] it's another data point, and I'm sure it affects some percentage of users [01:37] It would be pretty unpleasant to make it impossible to upload to PPAs except from Ubuntu. [01:37] People do use Debian, you know :) [01:38] wgrant: it wouldn't be impossible: lftp etc can do it, and folk can apply the patch [01:38] https://bugs.launchpad.net/launchpad/+bug/499438 is what sparked these questions [01:38] <_mup_> Bug #499438: Better handling of fatal upload errors

< https://launchpad.net/bugs/499438 > [01:39] cjwatson: whats the right way forward to get Ubuntu to promote SFTP for uploads - I'm primarily concerned with new PPA users, the set of folk most likely to make packaging fubars anyhow [01:39] I doubt I'm capable of thinking of a problem that complex at 1:40 [01:39] am [01:39] fair enough [01:40] I will probably raise it again [01:40] lifeless: Initial config is the difficult bit. [01:40] right [01:40] We can't provide a default config, so we have to tell people to edit their dput.cf [01:40] Like we did 4 years ago :/ [01:40] or get credentials from lptools, which we use for a bunch of other things too [01:40] unless we're very careful, all we achieve is rearranging the deckchairs on the UI. [01:41] lifeless: lptools? [01:41] lptools, which ~nobody has installed [01:41] bzr launchpad-login ? [01:41] Exactly. [01:41] Nobody uses lptools.; [01:41] cjwatson: thats true, OTOH deckchairs the user can see are easier to examine than ones they cannot :) [01:41] didn't a bunch of ubuntu-dev-tools get shuffled over to lptools ? [01:41] I was fairly sure they did, during the last cycle [01:42] ubuntu-dev-tools declares no package relationships on lptools [01:42] so if they did, it was shuffled out of sight [01:42] lifeless: All I can see that is doing is having more people ask "Why can't I just upload using dput?" [01:42] yeah, I can see [01:42] could use ubuntu-dev-tools [01:42] Other sites seem to rely on uniqueness of SSH keys. [01:42] StevenK: a) experienced folk can, b) new folk follow docs on the wiki, and *then* also mess up [01:43] It's true that a few tools were moved, but they were the sorts of things only pretty LP-aware people used anyway [01:43] lp-get-branches, lp-grab-attachments, lp-project-upload, lp-list-bugs, lp-set-dup, lp-shell [01:43] you didn't want to reason about this at 1:40am [01:43] so don't :) [01:43] you asked me to come up with a solution :) [01:43] picking holes is easier ;) [01:44] heh [01:44] cjwatson: qastaging update finished 4 minutes ago, btw. [01:44] thanks. upgrading mawson [01:44] so, as long as we never need to go spelunking on germanium again to determine what went wrong, I will accept nearly any hole you care to poke [01:44] I think pushing it back onto the users machine where they can locally diagnose and get up-front errors is a good thing [01:45] I wonder if there's any way to push errors over the FTP session [01:45] There is. [01:45] We do it already. [01:45] Which we don't do for SFTP [01:45] But lifeless knows that well, so I assume he a reason to ignore it. [01:45] +has [01:45] it has limits, and we will happily email the wrong person if the package is a plain copy from e.g. Debian [01:46] one of the limits is that core twisted tries very hard to turn such events into OOPSes [01:46] (oh no something went wrong, must alert the admin) [01:46] thats probably fixable, but even then we still can't notify *anyone else* that the problem occured. [01:47] e.g. via upload subscriptions [01:47] I agree in principle that SFTP is a good thing to use; the road to making it mandatory probably isn't short though. [01:47] I guess that's all I'm really saying [01:47] making it the default for new users would go a long way [01:47] Yes [01:47] we could just say 'try over sftp' to any experienced user with an undiagnosable problem [01:47] e.g. deprecate but not disable ftp [01:48] Or if we can't figure out the user's LP login, fall back to FTP [01:48] The experienced users aren't going to have trouble :) [01:48] You'd still win if we reduced the incidence of spelunking significantly [01:48] Just not as much [01:48] mmm, I'd like something more aggressive than 'if we can't figure it out' [01:48] e.g. opt-in to ftp [01:48] "What's your LP login? Type 'lifeless' to use FTP" [01:49] (remember too that we have folk dealing with private packages etc, so the default really wants to be non plaintext [01:49] cjwatson: :) [01:49] cjwatson: put that in for april 1st please [01:49] I have a better April 1st way ahead of that, which I've been failing to implement for five years :) [01:50] Actually, seriously, interactivity wouldn't be awful [01:50] poor andi [01:50] still confused by LP's UI. [01:50] Again? [01:50] just have /usr/share/dput/sftp.py ask you and save the answer somewhere [01:50] 3 imports one project [01:50] cjwatson: +1 [01:50] enhancement: figure it out automatically without asking. but that's nice-to-have. [01:51] (I'm assuming sftp.py gets a terminal.) [01:51] And then have sftp.py fall back internally to FTP on abject failure. [01:51] (With loud warnings.) [01:51] mwhudson was talking about anonymous-ssh, so we could utilise that too ... [01:51] StevenK: not useful here [01:51] Let me not attempt to figure out the confidentiality properties of anonymous SSH [01:52] StevenK: the point is knowing the user so we can notify sensibly [01:52] cjwatson: Or fall back to trying $USER ? [01:52] StevenK: fixes a raft of corner cases that we have today, anonymous-ssh wouldn't do that [01:52] StevenK: *handwave* that kind of thing [01:52] I wonder what the performance difference is for large uploads over SFTP vs. FTP [01:53] lifeless: SFTP for uploads still doesn't solve notifications for syncs ... [01:53] cjwatson: SFTP should be faster (tcp window already open) [01:53] Syncs will all be API soon enough, so you'll at least have a username [01:53] lifeless: haha my bugmail disagreed last I checked [01:53] indeed, and *I'm not talking about syncs* :P [01:54] failing to fix problem B doesn't make a solution to problem A better or worse [01:54] having a single solution to A and B is nice, of course. [01:54] (the HPN people talk about FTP as a comparator for their none-cipher work) [01:55] but you need to demonstrate a link between them for it to be worth considering - whats the link between syncs, where we know all the package data is intact, and uploads, where its all arbitrary [01:55] comparand. blah. I keep getting that wrong. [01:55] cjwatson: interesting [01:55] Ur, help. What does http://paste.ubuntu.com/792323/ mean when upgrading dogfood? [01:55] you keep both pieces? [01:56] the dogfood config has old and deleted config keys [01:56] Haha [01:56] Ah, yes, let me fix that. [01:56] Yeah, wgrant broke it [01:57] I don't think it's the DF config that's broken. It's just that the prod configs are out of date. [01:58] cjwatson: Should be fixed. [02:01] wgrant: Thanks; should I carry on with the build or did you do that? [02:02] cjwatson: I didn't touch it. [02:02] Come on, do you think it can build that quickly? :) [02:02] Heh [02:04] inferring username from ssh key is technically easy i guess [02:04] and that UNIQUE constraint on sshkey would have been interesting a few years back :-) [02:04] Now that there's more than just a few keys, yeah... [02:05] I thought that's why we added the UNIQUE constraint [02:05] There isn't one, AFAIK. [02:05] Indeed not. [02:06] Adding one might not be a terrible idea. [02:07] There is one key with 19 links, another with 20... [02:07] 650ish with 2 links, 40 with more than 2 [02:10] :-( [02:10] That doesn't block lifeless' project though; we have the username to work with, not just the key [02:10] Yeah [02:13] lifeless: also, about owners and notifications, some people want to be owners to just administer and not have rights [02:14] micahg: yes, thats why we have separate roles, though wgrant is campaiging that this doesn't make sense [02:14] lifeless: No. [02:15] lifeless: I'm campaigning that the owner special case doesn't make sense. [02:15] I am campaigning that admin+membership should be separated. [02:15] Currently you have a list of members, and a list of admins who are members, and a single not-quite-admin-but-not-member. [02:16] When a list of members and a list of admins who may also be members would work fine. [02:16] with the recent change to admins promoting admins, hmm [02:16] perhaps [02:18] that would solve the DMB use case as well [02:18] Yup. [02:20] Morning jtv. [02:20] hi there wgrant, happy 2012 [02:21] Likewise. [02:21] thank you === jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jtv | Firefighting: - | Critical bugtasks: 3*10^2 [02:27] lifeless: So, how do you propose to find transitive dependencies without a resolver? :) [02:29] wgrant: I thought you meant something different apparently [02:36] jtv: https://bugs.launchpad.net/launchpad/+bug/506497 - is that more done now? [02:36] <_mup_> Bug #506497: import-queue-gardener gives file path a higher priority than a manually assigned template

< https://launchpad.net/bugs/506497 > [02:36] jtv: also would like your input on https://bugs.launchpad.net/launchpad/+bug/506516 [02:36] <_mup_> Bug #506516: Failed migration of ubuntu kdeaddons to message-sharing

< https://launchpad.net/bugs/506516 > [02:37] lifeless: probably not done, but I'm not even sure those tools still work. [02:37] jtv: should I invalid it? or incomplete? [02:39] lifeless: incomplete. [02:41] lifeless: what would you think of marking bug 529957 invalid since we build translation packages out of the Firefox/Thunderbird sources now? [02:41] <_mup_> Bug #529957: XPIPO file uploads should be disabled < https://launchpad.net/bugs/529957 > [02:42] micahg: have we ditched the XPIPO support? [02:42] micahg: should we drop it? [02:43] micahg: (also does that mean thunderbird is not translatable in Ubuntu using LP?) [02:43] lifeless: I should check with chrisccoulson first, but I think so, at least once the Firefox migration in lucid/maverick is complete which should be some time this month [02:43] lifeless: thunderbird actually never was IIRC [02:43] so I don't think we should invalidate the bug while we have the code it talks about around [02:43] but we could change it to be 'this code can be deleted' [02:45] well, I guess one day if we ever get a way to push translations back upstream, we could import from the source uploads and push changes upstream, but I guess in that scenario, we don't need the xpipo code either [02:54] * StevenK stabs the screwed up security model SPRBs use. [03:06] jtv: so, thoughts on bug https://bugs.launchpad.net/launchpad/+bug/509109 and https://bugs.launchpad.net/launchpad/+bug/506516 ? [03:06] <_mup_> Bug #509109: Deadlock in message-sharing-merge while migrating brasero

< https://launchpad.net/bugs/509109 > [03:06] <_mup_> Bug #506516: Failed migration of ubuntu kdeaddons to message-sharing

< https://launchpad.net/bugs/506516 > [03:07] “If they're really a problem, they'll come back.” [03:07] jtv: they were both migration stuff; thats done, right ? [03:08] Yes, though the code may still be in use. [03:08] ah [03:08] the question is, should the maintenance squad sit down and work on them ? [03:10] Not based on these reports, no. I'd just close them. [03:11] Too much has changed since those bugs were reported. If they're really a problem, they'll come back. [03:12] thanks, done. [03:13] hmm, something is seriously odd with multi-project -importance bug sort order [03:18] * StevenK stabs diff generation and/or longpoll [03:20] I wonder that noone has hacked https://bugs.launchpad.net/launchpad-buildd/+bug/516208 into the thing already [03:20] <_mup_> Bug #516208: disable Automake's silent rules < https://launchpad.net/bugs/516208 > [03:26] Right, mawson is all ... whoever-cares' again. [03:27] cjwatson: Did you QA mvo's rev, or is that his to do? [03:28] Launchpad encountered an error during the following operation: generating the diff for a merge proposal. The source branch has no revisions. [03:28] Blink [03:28] StevenK: I did his [03:28] So it's just jelmer's recipe format thing left [03:28] Indeed. Thanks. [03:47] jtv: O hai. I'd like a review, but the branch scanner has de-pramed its toys while scanning my branch. The diff is at http://pastebin.ubuntu.com/792375/ [03:47] StevenK: working on a long one right now, but you'll be next. [03:47] StevenK: Make it rescan? [03:48] wgrant: By pushing agai [03:48] n? [03:48] Yes. [03:48] You may have to push -r-2 then push again, I forget. [03:48] I thought we worked out that -r-2 doesn't work? [03:48] It can't not. [03:49] % bzr push -r-2 [03:49] Using saved push location: lp:~stevenk/launchpad/hide-forbidden-sprbs [03:49] No new revisions to push. [03:49] --overwrite [03:49] And then bzr push quickly? [03:50] No need to be quick. [03:50] But if you want. [03:51] The branch scanner should log branch.unique_name [03:51] Yes. [03:55] Bleh, job logging is complete crap [03:55] You can't get at the logger in the actual job's run() method. [03:58] wgrant: Looks like the scanner choked on it again [03:58] Yay [04:00] StevenK: its not on an attribute? Also why would you need to, thats not the logging API [04:03] - return '%s (ID %d)' % (class_name, ijob_id) [04:03] + return '%s (ID %d) %s' % (class_name, ijob_id, repr(job)) [04:03] I think that will help [04:08] StevenK: wgrant: is https://bugs.launchpad.net/launchpad/+bug/525749 part of disclosure, do you think ? [04:08] <_mup_> Bug #525749: A Branch's visibility setting page contain the word 'visibility'

< https://launchpad.net/bugs/525749 > [04:10] lifeless: Probably, yes. [04:10] Although the summary seems to be inverted. [04:10] indeed [04:12] will you fix? [04:13] wgrant: is https://bugs.launchpad.net/launchpad/+bug/527550 still ? [04:13] <_mup_> Bug #527550: CopyChecker._checkArchiveConflicts erroneously permits copies of sources with failed and unpublished builds

< https://launchpad.net/bugs/527550 > [04:13] That hasn't been touched recently. [04:13] So yes. [04:14] lifeless: So to answer your question, it is not on a attribute. And it would be very useful for say, IDSJ. [04:26] StevenK: but why? logger = logging.getLogger('lp.jobs.foo') [04:26] done [04:26] wgrant: and https://bugs.launchpad.net/launchpad/+bug/527551? [04:26] <_mup_> Bug #527551: Intra-archive copying of a source with a failed build may leave that source uncopyable

< https://launchpad.net/bugs/527551 > [04:29] lifeless: Still there. [04:30] wgrant: and https://bugs.launchpad.net/launchpad/+bug/528459 ? [04:30] <_mup_> Bug #528459: PPA does not delete old packages after new build < https://launchpad.net/bugs/528459 > [04:30] lifeless: Likewise. [04:30] NBS [04:30] lifeless: Because I prefer it was in the same log as the job runner uses [04:31] StevenK: and? thats orthogonal [04:31] StevenK: logger objects are not intended to be passed around willynilly [04:45] StevenK: fixtures.FakeLogger may help you [04:46] jtv: Still dealing with the large review? [04:46] Yes [04:46] But the first container of coffee has arrived, which should speed things up. [04:47] We're slightly hung over (in the non-imbibed sense) from an all-night drive during the holidays. [04:47] (“The holidays” for us being January 2 & 3) [04:51] the lpia PPA queue does not seem to be dispatching to the buildd [04:53] webops: please stab gold and restart buildd-manager [04:53] * wgrant throws some builders at lpia. [04:53] this is terrible. I can nearly do this from memory. [04:54] wgrant: I would just give it one, no one should be using lpia anyways [04:56] wgrant: so this bug - https://bugs.launchpad.net/launchpad-buildd/+bug/533583 [04:56] <_mup_> Bug #533583: build fails where no error is present < https://launchpad.net/bugs/533583 > [04:57] what is the defect/problem ? [04:57] micahg: Since there seem to be about 30 Mozilla builds on the virt builders at the moment, sounds like a good plan. [04:58] it's that time of day :) [04:58] lifeless: sistpoty disagrees with Ubuntu policy. [04:58] Needs to be argued with lamont. [04:59] ISTR another bug to make that not fatal [05:00] * micahg thinks it's a lack of scrolling to the bottom :) [05:04] * lifeless tosses oil on the fire [05:05] lifeless: you didn't have to toss wgrant in as well :) [05:05] he is the oil ? [05:06] nah, I think he was holding it :) [05:16] didn't poolie do this? https://bugs.launchpad.net/launchpad/+bug/547036 [05:16] <_mup_> Bug #547036: The buildd code should be removed from the Launchpad tree

< https://launchpad.net/bugs/547036 > [05:17] jtv: Just how big is this branch? :-P [05:17] wgrant: btw, that ppa et al reset is done and done [05:17] spm: Thanks. [05:51] wgrant: Since jtv appears to be AWOL, would you mind reviewing the diff at http://pastebin.ubuntu.com/792375/ [05:53] wgrant: StevenK: opinions on bug 547036 ? [05:53] <_mup_> Bug #547036: The buildd code should be removed from the Launchpad tree

< https://launchpad.net/bugs/547036 > [05:54] lifeless: poolie fixed it months ago? [05:54] StevenK: He might be back now :) [05:54] wgrant: thats what I thought, was seeking confirmation [05:57] StevenK: see bug https://bugs.launchpad.net/launchpad/+bug/551414 [05:57] <_mup_> Bug #551414: log messages in jobs are discarded

< https://launchpad.net/bugs/551414 > [06:00] jtv1: Still fighting with the large branch? How large is it? [06:00] StevenK: it's not the branch, it's the interruptions [06:02] boo! [06:12] * StevenK nails wgrant to IRC. [06:14] * wgrant kicks Optus in the face :) [06:15] I love that those of us in the 3rd world have better internets. [06:15] * nigelb waves to jtv1 [06:15] Hi nigelb [06:15] Happy new year etc! No time to chat further right now, sorry :) [06:15] heh [06:22] nigelb: What do you call an Indian cricketer with a century next to their name? [06:23] nigelb: A bowler. [06:24] jtv1: what is 'pottery' ? [06:25] We do not speak its name. [06:25] lifeless: it's the code for generating POTemplates from branches. Runs in the build farm. [06:25] thanks [06:25] wgrant: yes we do. I just did. Robert just did. === jtv1 is now known as jtv [06:28] Bah [06:33] LaunchpadTimeoutError: Statement: 'UPDATE Project SET max_bug_heat=(SELECT COALESCE(MAX(heat), 0) FROM [06:33] Yes :) [06:33] staaaaaaaaab [06:33] I've been saying that for well over 18 months now. [06:48] is there a better way? [06:48] https://bugs.launchpad.net/launchpad/+bug/582805https://bugs.launchpad.net/launchpad/+bug/582805 [06:48] <_mup_> Bug #582805: On template generation, we should add a log file to the templates tarball as well < https://launchpad.net/bugs/582805 > [06:48] https://bugs.launchpad.net/launchpad/+bug/582805 [06:48] <_mup_> Bug #582805: On template generation, we should add a log file to the templates tarball as well < https://launchpad.net/bugs/582805 > [06:48] <_mup_> Bug #582805: On template generation, we should add a log file to the templates tarball as well < https://launchpad.net/bugs/582805 > [07:05] 1123 high bugs, and counting [07:08] 330 critical bugs [07:09] what's your point? [07:09] lifeless: are you counting up or down? [07:09] 330 critical bugs and 4 people, even. [07:10] micahg: our bug handling policy says we have three groups of bugs [07:10] the great unwashed [07:10] 6 months of todo (high) [07:10] as much zomg as there is (critical) [07:10] lifeless: I'm familiar :), just wondering which way you're counting on the 6 month pot :) [07:11] lifeless: Huh [07:11] How is high 6 months? [07:11] Given that we have 4 people... [07:11] That's like 10 bugs. [07:11] micahg: and that every quarter we'll review the high to keep it trim; its a year overdue. The first one is a doozy [07:11] wgrant: yes, I'll be doing a couple of passes I suspect [07:11] lifeless: ISTR you doing this recently [07:11] micahg: that was eliminating mediums [07:11]