=== nhandler_ is now known as nhandler [00:08] anyone else seeing connection timeouts when accessing edge? [00:09] periodically, yes [01:36] The same user I & numerous others reported is still at it [01:36] https://edge.launchpad.net/~ubuntunerd-nospammail/+karma [01:36] he created more issues approx 5 hrs ago & another bug task just over 1 min ago [01:37] [21:40:10] https://answers.edge.launchpad.net/launchpad/+question/100682 [01:47] spm: can you take care of this ^^^ [01:50] kermiac: which bug has been modified? [01:50] the most recent as in [01:51] I'm not sure, must've been something I'm not subscribed to. Still looking atm. I just noticed he's been at it again, we're discussing it on #ubuntu-bugs atm [01:52] spm: bug 495361 is the latest 1 I have [01:52] Launchpad bug 495361 in xubuntu-meta "[Xubuntu] No window manager at startup" [Undecided,Invalid] https://launchpad.net/bugs/495361 [01:58] bug 446669 is from 6hrs ago - def after he received the warning [01:58] Launchpad bug 446669 in phpldapadmin "E_STRICT: Declaration of AJAXTree::draw_dn() should be compatible with that of PLMTree::draw_dn()" [High,Confirmed] https://launchpad.net/bugs/446669 === kermiac is now known as kermiac_ [01:59] sorry, gotta afk for a while [02:00] Um, we can't be sure that the warning was received, only that it was sent. [02:00] Some people don't actually read email. [02:01] And given the email address, I do wonder if it's been spam trapped or something [02:02] persia: your thoughts? I'm about 90% inclined atm to suspend with a note that this is to encourage them to contact us asking why. ??? [02:03] spm: I'm unsure. Had there not been an explicit time frame in the warning, I'd be all for suspending now. [02:03] yeah. that's the other 10%... :-/ [02:03] As it is, I think that there would be benefit to sending another notice indicating that continued disruptive behaviour has shortened the timeframe. [02:03] good idea; ta. [02:04] But it seems to be the major topic of conversation in #ubuntu-bugs, which implies, to me, that it's keeping people from actually working on bugs, which is anti-productive. [02:04] JFDI [02:04] heh. That was an easy 10% :) [02:04] 48 hours is way to long to let an idiot continue being an idiot [02:05] 1 person and a sense of fairness vs the needs of the many.... :-/ [02:05] RIght. [02:05] the many carry bigger bats [02:06] But it's probably worth changing the "How do we handle requests for account suspension" documentation to not give a timeframe, and then suspend either after some time without response of if a sufficiently of continued disruption occurs. [02:06] Because once the "48-hour" mail is sent, it looks bad not to honor it. [02:08] what will suspending this user mean? is it just deleting his account. or are there ways to ban him from launchpad? [02:08] oki, suspended. In the hope that they do contact us, or read their email... to find out why. [02:08] thekorn: suspension. basically locked out. [02:09] delete is typically only used in extreme cases; eg obvious spammers for drugs etc [02:11] ok, so he can get a new @nospam address, setup a new account and start spamming again, and it will take some time again until this attrackts our attention [02:11] let's hope this does not happen [02:12] thanks for takeing care of him [02:12] spm: do you know anything about the interaction between bugzilla.mozilla.com and LP? [02:13] micahg: a little; it's a moderate source of pain. [02:13] spm: will it break anything in LP if the LP acccount in bugzilla is disabled until we fix syncing? [02:14] micahg: no idea; my 2c - do what you need to do; we'll pick up the pieces if needs be. [02:14] spm: k, thanks :) [02:15] upstream was getting frustrated :) [02:15] heh, at worst, it identifies a bug in how that process deals with such an event. :-) [02:15] fair cop [02:15] * wgrant wonders why spamming other bugtrackers isn't a critical bug. [02:18] * micahg agrees with wgrant [02:18] thekorn: There's no sane way to identify individuals: only email addresses. [02:20] persia, I know, so my idea is not not supsend such spammers and find ways to handle/revert their changes, in this case we would know who is spamming, [02:21] maybe permanently redirecting them to staging [02:21] thekorn: That's an interesting idea, but probably requires a lot of deep plumbing. [03:16] ty spm [03:17] np [08:30] Hey [08:30] I'm facing a weird bug with membership [08:31] I got a your membership will expire email in a team I'm admin of [08:31] And I can't renew it [08:31] https://launchpad.net/~plymouth-dev/+members [08:31] I'm supposed to contact one of the *other* administrators for some reason [08:58] lool, that is weird... one of the registry guys should be around later, but if you've time it'd be worth a bug so it doesn't get lost. [09:04] Any translations admins or mods here? [09:05] dpm: ^^? [09:05] noodles775: I filed 520848 [09:06] Lord-Readman, what's your question (I'm not an LP developer but I can manage the translations imports queue, if that is what you need) [09:06] well I have approved imports, but they are not imported [09:07] and usually they do it at the same time [09:07] what is the difference? [09:09] https://translations.launchpad.net/~robert-readman/+imports I have 4 approved [09:09] but not imported [09:10] if you could take a look dpm that would be great [09:11] Lord-Readman, ah, it's an Ubuntu import. I can take a look, but in the future you might want to ask at #ubuntu-translators where more Ubuntu people with admin rights on the imports queue can have a look at it as well [09:12] ah sorry [09:12] Lord-Readman, it's just as fine to ask here, no need to apologise :-) [09:18] Lord-Readman, it did not get imported automatically because the importer is trying to figure out the language. I've approved it manually, so no worries, but on subsequent imports I'd recommend changing the name of the PO files you upload to simply en_GB.po, which will speed up the process of them getting imported. In any case, the "Will be imported into English (United Kingdom) (en_GB) translation of virt-manager in Ubuntu Lucid package "virt-manager"" mes [09:18] sage in the imports queue entry shows that it would have been imported eventually [09:19] ah I normally just upload with the same filename as it gave on the download === matsubara-afk is now known as matsubara === salgado is now known as salgado-afk === mrevell is now known as mrevell-lunch === mrevell-lunch is now known as mrevell [13:18] When searching for bugs within project usb-creator, i am unable to create a search returning bug #457721. Am I doing something wrong or is there a bug in launchpad? [13:18] Launchpad bug 457721 in usb-creator "Should only show the disk block device under certain circumstances" [High,Triaged] https://launchpad.net/bugs/457721 === jml is now known as jml-afk [13:21] edakiri: That's a bug in the Ubuntu package of usb-creator. Try searching at https://bugs.launchpad.net/ubuntu/+source/usb-creator [13:39] is there a way to get from 'pick a project' to the +source part? [13:40] "Search bug reports: One Project: Choose" is what i mean by 'pick a project' . https://bugs.launchpad.net/ [13:41] no === jml-afk is now known as jml === jamalta is now known as jamalta-afk === matsubara is now known as matsubara-lunch === salgado-afk is now known as salgado [15:24] <_stink_> hey folks. i want to submit a feature request for LP, but if i go to https://bugs.launchpad.net/launchpad, there aren't any open bugs. maybe they're all closed, but this makes me think i should be going elsewhere to submit this. advice? [15:43] _stink_, we generally file bugs against the launchpad components, i.e. malone, rosetta, soyuz, launchpad-code, launchpad-registry, or launchpad-foundations. [15:44] _stink_, but if you can't work out where to file, you can file against /launchpad and we'll re-target it. [15:44] <_stink_> deryck: rock on, thanks [15:44] np === salgado is now known as salgado-brb [16:01] Hi, can somebody add a redirect from ~dcteam to ~ubuntu-dc? [16:01] * ~ubuntu-us-dc === matsubara-lunch is now known as matsubara === Ursinha is now known as Ursinha-food [16:48] lpRN]eIWRe> [17:12] andrea-bs: You may want to check backscroll, and, depending on what you find, take some action. === deryck is now known as deryck[lunch] [17:15] persia: oops! :-( thank you for the info [17:16] andrea-bs: Sorry it took so long to notice :) [18:21] Launchpad claims it pulls external bug status daily but it looks like #512459 hasn't updated since 2010-02-08 from its corresponding Debian bug. what's up with that? === deryck[lunch] is now known as deryck [18:22] tlyu: bug status is slightly borked from debian. [18:22] tlyu, we're doing lots of work on our bug syncing currently. So it can be hit or miss currently. By sometime in April, this should be solid again. [18:23] thanks. will unlinking and relinking the bug cause it to update? [18:23] tlyu, no. [18:24] tlyu, the updates are processed offline from Launchpad. This is part of what we're changing to, so that you can force an update from the UI. [18:24] ok. if i want the Launchpad state to accurately reflect Debian, should i adjust it manually? [18:31] tlyu, you have to remove the bug watch to update manually. [18:50] jcastro, ping [18:51] deryck, hi! [18:55] allenap: thanks for working on that syncing bug :) === Ursinha-food is now known as Ursinha === DumbSpammer is now known as OpenOcean === salgado-brb is now known as salgado === siretart_ is now known as siretart === matsubara is now known as matsubara-afk [20:23] hi, I'm trying to checkout launchpad using rocketfuel-setup, and bzr is consuming over 900MB, causing my computer to start swapping to disk. [20:24] is this *supposed* to happen? === sale_ is now known as sale === doctormo_ is now known as doctormo [20:39] lfaraone: yikes.... is it going over bzr+ssh or http? [20:40] maxb: the latter, I think. [20:40] maxb: uh, actually it might be http, I didn't give it my launchpad credentials.. [20:41] Well, do you have a ssh key in launchpad, and that ssh key available locally? If not we can rule ssh out straight away [20:41] maxb: okay, it's not SSH then :) [20:42] right... well, I've found bzr's dumb http to be pretty awful about big branches [20:43] (currently using virt: 1162m, that's more ram than I have on the system!) [20:43] maxb: so this is a bug, I take it. [20:44] maxb: is there another transport I can use with launchpad, without putting an SSH key on the computer? [20:45] No, there isn't [20:47] I'm trying it here .... not only is it doing a dreadful job of saturating my bandwidth, it's swiftly heading in the direction of a gig of mem [20:49] I killed it because it was getting shockingly slow [20:50] huh, even bzr+ssh seems to have just stalled, too [20:51] This is ridiculous [20:52] I can now safely say that if I needed to branch launchpad afresh, I'm not sure I could, with it behaving the way it is [20:52] lfaraone: what bzr version ? [20:52] maxb: and yours ? [20:53] lp:bzr/2.1 [20:53] lifeless: Bazaar (bzr) 2.0.2 [20:53] lfaraone: 2.1 is a lot better at memory in theory ;) [20:53] maxb: C extensions built ? [20:53] lifeless: well, I'm using what's in the repos. [20:53] lifeless: yes [20:53] maxb: file a bug please [20:53] So theory isn't being borne out in practice [20:54] lifeless: I'm assuming that "make" in the tree will have done the right thing? [20:54] It certainly looked like it did [20:54] maxb: make will build the extensions, yes. [20:55] maxb: if you have bzrlib/*.so numbering ~5 then it did [20:55] I have 14 [20:56] yeah thats fine [20:58] um. Is it expected that I have time to go make a cup of coffee whilst 'bzr heads' runs on my ~/launchpad/lp-branches? [20:58] * persia thinks it's the new bzr caffiene-level-check feature running in the background [20:59] (or would that be "check-caffiene-level" to match the naming convention?) [20:59] nothing is expected [20:59] but I doubt heads uses the fast apis available in 2.1 yet [21:00] There's "fast" and there's "so slow the command might as well not exist" :-/ [21:00] get an lsprof dump of it and file a bug; we can go from there [21:02] hm. bazaar is still using 350~mb of ram in ssh+bzr transport mode. [21:02] which isn't *as* terrible :) [21:03] it will be doing far fewer round trips too [21:03] server side processing is much more efficient [21:05] fewer round trips sounds lovely :) [21:26] lfaraone: success yet? :-) [21:26] maxb: "[#########\ ] 171815KB 556KB/s | Fetching revisions:Inserting stream " [21:27] mhm [21:27] The protocol is annoyingly inefficient [21:27] good news is it's only using 108m [21:28] An entire devel repo is only 155MB of data [21:29] maxb: uh, should I worry about "bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/shipit/trunk/"." [21:29] No, that bit's Canonical-proprietary [21:47] maxb: now we're working! if only "make schema" were to work more quickly... :) === salgado is now known as salgado-afk [23:05] Yesterday, I created a Launchpad branch for our translations to be exported to. Then, I created an empty bazaar branch on my local machine (bzr init) and finally pushed it to Launchpad (bzr push --use-existing-dir lp:wiserearth). I expected the transltion files to be exported to this branch since I associated the two. I still have an empty branch. What step am I missing? [23:22] zobi1: you ran bzr init twice; don't do that for a single project [23:22] zobi1: 'init' makes something brand new, what you want is 'branch' - make a new branch of something you've already got [23:23] lifeless: I don't have anything I would like to put in. I would like to get an export of the translation files that are on Launchpad. [23:23] hmm, I'm not sure enough of the code bits here sorry [23:25] lifeless: when I set up the new branch on Launchpad as an export branch for the existing translation files on Launchpad, I expected the branch to be populated with those files. But for some reason that is not happening. [23:26] It only happens once a day, I believe. [23:27] For some reason the documentation assumes certain steps to be taken by the users, rather than walk you through. [23:27] wgrant: I set this up 2 days ago. [23:27] Anyway to find out what time of the day the export happens?