=== kiko is now known as kiko-afk [00:09] cprov: May I ask why bug #196782 is deemed to be of such low priority that it has been untargetted? It gives a pretty bad first impression of PPA. [00:09] Launchpad bug 196782 in soyuz "First build in a new PPA fails" [Low,Triaged] https://launchpad.net/bugs/196782 [00:11] Fujitsu: only in the very first job. We can't fight this race-condition effectively. [00:11] so you do nothing, even though it's generating multiple questions in here each week [00:12] Can't you just not let the build be handed out to a builder unless the archive is published? [00:14] Hobbsee: easy - setting it to low priority != 'doing nothing' [00:15] elmo: Untargetting == 'doing nothing for the foreseeable future' [00:15] Hobbsee: exactly what I was saying, it was decided that we have other more important things to be done before this one. [00:16] Speaking of more important things... how's security-in-soyuz doing? [00:16] Fujitsu: well, a) I'd argue, if you can't see past the current LP release schedule, you can't see far ;-), but b) in any event, I think there's more constructive ways to argue for priortization of features [00:17] elmo: what Fujitsu said. [00:17] Fujitsu: very well, soon we will have it running. [00:20] cprov: Is there any public document describing how it will actually be used/ [00:20] Fujitsu: one idea is to not dispatch pending jobs for archives (PPAs) younger than 20 minutes (current publishing interval), but that's so naive that doesn't worth the code, if you know what I mean. [00:21] Fujitsu: no, not a public one. I image we will be writing one before switching. [00:21] cprov: Is there not a timestamp of last publishing that you can check for nullness? I imagine that'd be fairly easy and less than hackish that checking the age of the PPA... [00:21] Fujitsu: btw, do you know exactly how dak works nowadays ? [00:22] cprov: I know fairly well how dak works, but not a whole lot about the dak-LP interactions. [00:23] Fujitsu: checking the source publishing date doesn't really help since we very often build unpublished-sources (build-from-accepted feature). [00:23] cprov: I meant archive publishing date. [00:24] Fujitsu, we don't actually store that. [00:24] Ah. [00:24] cprov, it's ironic that this bug actually happens because of build-from-accepted :) [00:25] kiko-afk: yes, kind of short-blanket problem. [00:26] cprov, random idea: could we not put an empty Packages.gz on-disk when activating the PPA? is that crazy? [00:27] I discounted suggesting that as being too much of a hack. [00:28] Fujitsu, well, maybe it is -- just wondering, you know. [00:28] kiko-afk: i don't see how we can tweak the archive disk from the activating-PPA UI [00:28] cprov, of course, separate boxes. [00:29] cprov, how about not depending on the PPA itself unless at least once source has been published in it? [00:29] cprov, or even one binary [00:29] might one binary work? [00:29] kiko-afk: more often publishing cycle would mitigate this problem and uncover other (archive being changed while being read) [00:30] right [00:30] cprov, I'm thinking don't send the apt sources line for the PPA until we know it's safe to send it. [00:30] what do you think? [00:30] kiko-afk: "blinks" .. that's an good idea [00:30] that might not be too hard to do [00:31] MIGHT [00:31] If I am pulling the launchpad all packages build status index for my ppa, im not setting off any bells, yes? [00:31] (periodically?) [00:31] compbrain: I got a couple of IPs blocked once for pulling a page once an hour. [00:31] That was a while ago, mind you. [00:32] feh. [00:32] compbrain, what are you pulling? [00:32] the all-package status page for our ppa, then pulling package build information for non-complete builds [00:33] compbrain, maybe it's easier if you tell me URLs? [00:33] +archive/+builds [00:33] and +archive/+build/(\d+)/ [00:33] hello [00:34] hi. [00:34] compbrain, that shouldn't be too big a problem -- what's the period? [00:34] hi emgent [00:34] Main page every 15-30, package builds only if their not done about the same, not more than 5 in a given pull [00:35] kiko-afk: This was the reason for the RSS request bug. we've got a svn->source builder->launchpad->test cluster->release procedure going === kiko-afk is now known as kiko-zzz [00:49] The "Timeline" part of a project page is a bit weird, because it doesn't actually involve any times or dates (just milestones, which don't give much of a sense of time...). [00:50] spiv, it's actually more like "Series and releases" [00:50] kiko-zzz: Yeah. Rather than like "line of time" ;) [00:52] Fujitsu: just because we are buddies, bug 207486 [00:52] Launchpad bug 207486 in soyuz "The dependency-lookup method is not restricted to the context PPA" [High,Confirmed] https://launchpad.net/bugs/207486 - Assigned to Celso Providelo (cprov) [00:53] cprov, ah, neat bug, and probably easy to fix. [00:54] kiko-zzz: yes, it won't be hard. [00:54] cprov, it's funny how the PPA stuff really shakes out our multi-archive code [00:55] kiko-zzz: indeed, we keep discovering uncovered callsites [01:00] New bug: #207486 in soyuz "The dependency-lookup method is not restricted to the context PPA" [High,Confirmed] https://launchpad.net/bugs/207486 [01:05] New bug: #207488 in launchpad "should pick up .asc files automatically" [Undecided,New] https://launchpad.net/bugs/207488 [01:10] New bug: #207491 in launchpad "ability to register multiple release url patterns" [Undecided,New] https://launchpad.net/bugs/207491 [01:11] cprov: ping [01:12] emgent: pong [01:12] cprov: please see bug #207490 and bug #207494 [01:12] Bug 207490 on http://launchpad.net/bugs/207490 is private [01:12] Bug 207494 on http://launchpad.net/bugs/207494 is private [01:12] notified keescook too. [01:12] another security issue [01:12] cprov: That's what I thought it would be. [01:12] O_o [01:13] : [01:14] emgent: sorry, pidgin doesn't like me [01:14] emgent: uhm, I see [01:14] cprov: use irssi :) [01:14] emgent: I've fixed other similar bug in the past, but it was in soyuz area. [01:14] spiv, could you report a bug on renaming Timeline? [01:15] yes i know [01:15] emgent: of irssi it's the other way around ;) [01:15] hahah ok :P [01:15] mpt: sure [01:15] how do i remove my email address from a bug update list? [01:15] MacTaylor: Go to the bug, and click `Subscribe/Unsubscribe' in the actions menu on the left. [01:16] Or it might just be Unsubscribe in your case. [01:18] emgent: thanks for filling those bugs, they will be triaged tomorrow morning, I guess (EU & US time) [01:18] np :) [01:31] New bug: #207499 in launchpad ""Timeline" on a project page is misnamed" [Undecided,New] https://launchpad.net/bugs/207499 === cprov is now known as cprov-zZz === salgado is now known as salgado-afk [03:22] Hi All! [03:26] I'd like to raise a blueprint but I'd like to check that no one has addressed this already because it seems like an obviously feature. The ability to send someone to send another launchpad user an email message through launchpad. [03:30] Many LP new users don't make their email addresses public when they add translations (for example). It would be nice to get in contact with them. [03:33] frenchy, that's reported as a bug [03:33] one moment, I'll find it [03:35] There's bug 66105, which is about prospective team members in particular [03:35] Launchpad bug 66105 in launchpad "Team admin can't contact prospective member who hides e-mail addresses" [Medium,Confirmed] https://launchpad.net/bugs/66105 [03:35] For translators in particular, there's bug 8 [03:35] Launchpad bug 8 in rosetta "Translator forums/means of communication" [Wishlist,Confirmed] https://launchpad.net/bugs/8 [03:40] mpt: Thanks. [03:41] Huh, 8, I knew that it must have one of the first things that people complained about. [03:54] Well, that was long before we hid e-mail addresses [03:54] but it would have been useful regardless [04:36] New bug: #207532 in launchpad "Product and Project don't have read-only registrant" [Undecided,New] https://launchpad.net/bugs/207532 [04:37] mpt: So I can create lots of bogus projects, throw them to various groups and people, and there's really no record? Very nice. [04:44] mpt, http://www.design-police.org/ :) [04:45] Comic Sans is illegal. That's what I want to hear. [05:01] http://bancomicsans.com/ [05:03] Hahahah. I like the motto. [06:09] Could a launchpad admin please change the owner of the xubuntu-doc team from ~registry to ~xubuntu-team? Thanks. [06:37] Heh. [06:37] "Successfully registered branch smart-http-fix for this bug." ... "Timeout error" -- on the same page! [06:38] spiv: launchpad is undecisive. [07:05] spiv: just use bzr to associate the branch [07:07] "bzr commit --fixes lp:NNNN" [07:46] morning === stu1 is now known as stub [08:17] hi carlos [08:17] hi [08:18] carlos: would it be possible yet to give me permissions to upload po files to ubuntu/gutsy/+source/ubuntu-docs for all languages, so that I can upload po files with my fixes? [08:18] (would Launchpad then merge the relevant changes and ignore untranslated strings that have been translated since those po files are created?) [08:19] mdke: the only way to do that is being a rosetta-admins member, so unfortunately, no, I cannot do that without doing code changes (this is something we could do, let's say it's a missing feature) [08:20] right ok [08:20] well, I don't know what the answer is, it seems I'm going to have to fix the same mistakes each time I download po files [08:20] mdke: Launchpad will not ignore untranslated strings, but unset them. You would need to remove those strings from the uploaded file so that reversion is not done [08:20] ouch [08:21] mdke: Anyway, we had a bug in Launchpad that was making impossible to do what you want to do if you already uploaded such fixes as 'published' [08:22] that bug is fixed and the fix will be rolledout today [08:22] carlos: it seems that it's impossible anyway :) [08:22] mdke: I suggest you to file a bug to get such permissions as the owner of the source package [08:23] carlos: sure, I can do that... but then I'd have the problem of having to remove all strings from each po file except the one I fixed... [08:23] mdke: there is a command that would do it for you [08:23] really? [08:24] yeah, I think msgfilter is the command you want [08:24] ok, I'll look into that. How will it know which string is the one I want? [08:25] mdke: or maybe msggrep... Danilo should be more helpful with that [08:26] mdke: you need to look for messages without translations [08:26] I suppose I should really filter out all messages except the ones I have touched [08:27] that way if someone has changed a string since I download the po file, that change will be preserved [08:28] mdke: just to be completely sure... could you confirm that you don't have access rights to https://translations.launchpad.net/ubuntu/hardy/+source/ubuntu-docs/+pots/about-ubuntu/ace/+upload ? [08:28] mdke: that would be your best bet, but if you've got all three PO files (i.e. original translation before you fixed it, your fixed translation, and new translation) you can do it mostly automatically with msg* tools [08:28] carlos: I can see that page [08:29] mdke: ok, then you have enough rights and the problem is the bug I told you about [08:29] oh wow [08:29] mdke: hmm, you don't need to worry about it, Launchpad is smart enough to handle those cases [08:29] mdke: if you need help in getting a script to do this kind of merge, I can help you out :) [08:29] when the fix is rolled out, if I want to upload a file, which of the options should I choose? [08:29] mdke: if someone changed a translation after you got the export from Launchpad, those changed messages will be ignored from your upload [08:30] danilos: seems I just need to remove untranslated strings [08:30] mdke: User upload [08:30] carlos: rock [08:30] mdke: I thought you were not going to merge with what we have in Launchpad [08:30] if you get latest version in Launchpad, you don't even need to remove untranslated strings [08:30] mdke: as long as you don't touch the X-Launchpad-Exported header [08:31] I'd prefer not to have to get the latest version, if there is an easier way (like removing untranslated strings) [08:31] mdke: I mean X-Launchpad-Export-Date [08:32] mdke: yeah, but if you want to give priority to some translations from your update (i.e. fixed XML) and other translations from user changes (i.e. their own spelling fixes or whatever), it gets complicated [08:32] mdke: if you do that, you will need to update X-Launchpad-Export-Date so the upload is not rejected/ignored [08:32] ok, you've lost me now :) [08:33] mdke: you should look at it like a kind of wiki lock that will prevent you to overwrite other people's work [08:33] ok [08:33] if you get latest version in Launchpad and apply all your fixes, everything will work [08:33] mdke: well, we have a PO header 'x-launchpad-export-date' which checks exactly this case: if you keep the export date as it is, you'll basically be fixing everything you want _except_ cases where translators have changed the same messages like you have [08:33] if someone changes a string after your download and before your upload [08:34] those changes will produce that your changes in your upload is stored (only for those messages that were changed) [08:34] and you will be notified by email about those messages [08:34] carlos: but that will overwrite other updates from translators as well [08:34] danilos: if he gets latest version from Launchpad, that shouldn't happen [08:34] except for the ones that he wants to fix [08:35] carlos: right, but I believe it's better not to get the latest version from LP, just upload what he already has [08:35] the problem is that if I have 20 po files I want to fix, getting the latest version from Launchpad each time is a PITA [08:35] mdke: if you don't get latest version, you must do what danilo said before, filter out all messages that are not fixes [08:35] carlos: that should not be the case [08:36] bbiab [08:36] danilos: ? [08:36] carlos: actually, the date from lp-export-date would be older than new fixes in LP [08:37] carlos: so it should work exactly as desired [08:37] danilos: that's assuming the header is not removed in ubuntu-docs SVN [08:37] carlos: well, right, that's what I am assuming [08:37] and that the broken messages were not changed since last sync he got for the fixes [08:37] not changed in Launchpad [08:38] carlos: right, but I assume the chances there are small, and he'll still get an email about them and they'll be easy to spot (i.e. look for some XML :)) [08:40] New bug: #207581 in rosetta "Import queue UI: hard to find products that need review" [Undecided,New] https://launchpad.net/bugs/207581 [08:44] carlos, danilos - ok so in summary: [08:45] mdke: yes :) [08:45] provided I keep the lp-export-date the same as it was when i downloaded the po files, LP is clever enough to see which strings I have changed, and ignore any other ones (except in the case where a translator has changed a broken string at a later date, in which case I'll be emailed) [08:45] (as long as I make the upload after the fix is rolled out today) [08:47] correct? [08:47] mdke: right [08:47] brilliant, that's exactly what I want [08:47] so the e-lp-export-date string seems intact in our bzr branch - "X-Launchpad-Export-Date: 2008-02-24 12:17+0000\n" [08:47] since I only edit the files with gedit, I'd expect that these won't change [08:48] thanks guys [08:48] mdke: also, please, remember to update 'PO-Revision-Date' [08:49] if a translator uploaded a new version with a newer date there, your upload will be rejected completely [08:50] danilos: btw, with superfast imports and X-Launchpad-Export-Date feature, I wonder whether this check would be removed... we added it as an optimisation long time ago... Maybe keep it only for syncs with upstream/package imports... [08:51] carlos: what do you mean? what if two translators work on the same file at the same time, one downloads/uploads, another works in LP? [08:51] danilos: X-Launchpad-Export-Date will handle that case correctly [08:52] carlos: right, so I misunderstood you: what check do you want removed then? :) [08:52] danilos: We reject any uploaded file with a PO-Revision-Date older than the one from the latest uploaded file [08:52] carlos: PO-revision-date? [08:52] danilos: yeah [08:52] for user uploads [08:52] carlos: ah, sure, that makes sense [08:52] and keep it for published/imported ones, given that X-Launchpad-Export-Date doesn't applies in that case [08:53] carlos: ok, so if I update that field, it will be ok? [08:53] I won't be overwriting anyone's translations? [08:53] mdke: yeah [08:53] mdke: no [08:53] yeah for the first, no for the second ;-) [08:53] good :) [08:53] carlos: isn't the po-revision-date also useful in cases where newer uploads bypass older ones because the old ones don't get auto-approved? [08:54] ok, late for work - thanks again for your help [08:54] jtv: which usually happens only for imported/published uploads and why I suggest to keep it for those imports [08:54] mdke: you are welcome [08:55] jtv: for user uploads, X-Launchpad-Export-Date field will handle those conflicts [08:55] carlos: in that case, perfect. [08:55] only for the messages with conflicts, instead of reject the whole file like we do with PO-Revision-Date [08:55] carlos: conflict exception? [08:56] jtv: we accept all changes except for the messages with conflicts and notify the user by email [08:58] carlos: it'd definitely remove a nuisance. I have this vague suspicion that some users may not update that field at all. === \sh_away is now known as \sh [10:01] New bug: #207625 in soyuz "Unicode characters improperly displayed in PPA changelog" [Undecided,New] https://launchpad.net/bugs/207625 === jt1 is now known as jtv [11:32] heya people === Hobbsee` is now known as Hobbsee [11:55] hi all, could anyone approve my new translation template (for Envy), please? [11:56] New bug: #207680 in soyuz "Community Admin: Require MOTU archive admin celeb & queue access for universe/multiverse" [High,Triaged] https://launchpad.net/bugs/207680 [11:57] Fujitsu: ^ will be interesting [11:57] Indeed. [11:57] bigjools: is someone supposed to go and create that, or? [11:57] I heard something like that was meant to be happening for s-i-s. [11:58] no, it's internal code [11:58] Seems strange for it to be a celebrity. [11:58] 1.2.4 is going to see a lot of UI changes for admin! [11:58] woot! [11:58] will i see some of my UI bugs about the admin stuff fixed? [11:58] yes [11:58] actually - do you have the numbers handy? [11:59] * No select all checkbox at the top of the queue (https://launchpad.net/ubuntu/gutsy/+queue) https://bugs.edge.launchpad.net/soyuz/+bug/152880 [11:59] * If you accept packages from the UNAPPROVED queue, it says they're accepted, and takes you back to the NEW queue. This should take you back to the UNAPPROVED queue (but the message is good!) https://bugs.edge.launchpad.net/soyuz/+bug/152884 [11:59] * The queue page does not show you what the current override for each package is - ie, if it's main/restricted/universe/multiverse https://bugs.edge.launchpad.net/soyuz/+bug/152886 [11:59] Launchpad bug 152880 in soyuz "no select all packages checkbox at the top of https://edge.launchpad.net/ubuntu/gutsy/+queue" [Medium,Confirmed] [11:59] * No accept/decline button at the top of the queue too - only at the bottom - https://bugs.edge.launchpad.net/soyuz/+bug/152890 [11:59] Launchpad bug 152884 in soyuz "If you accept packages from the UNAPPROVED queue, it says they're accepted, and takes you back to the NEW queue." [Undecided,New] [11:59] Launchpad bug 152886 in soyuz "The queue page does not show you what the current override for each package is" [Undecided,New] [11:59] * Queue should default to 75 items, not 20. https://bugs.launchpad.net/soyuz/+bug/54297 [11:59] Fujitsu: it's a celeb team because it can't be the same as the currently permission uploaders (or you can just approve your own upload) [11:59] Launchpad bug 152890 in soyuz "No accept/decline button at the top of the queue" [Undecided,New] [11:59] Launchpad bug 54297 in soyuz "Increase the default minimum batch size for +queue page" [Wishlist,Confirmed] [12:00] New bug: #207682 in soyuz "Community Admin: Require MOTU buildd admin celeb & access to retry universe/multiverse builds" [High,Triaged] https://launchpad.net/bugs/207682 [12:01] bigjools: any chance on the community admin spec being made public? i'd be interested in reading it. [12:01] bigjools: I would have thought it would make more sense to add per-component/pocket archive admin fields, but I guess a celebrity is just as good as long as only one distro is around. [12:02] Hobbsee: it's not really written yet, I need to work on it, but sure I'll let you have a look when it's done [12:02] bigjools: cool, OK [12:02] Having specs like that somewhat public is surely very important, as people actually have to use them... [12:03] Fujitsu: they won't attempt to use it until it's actually pronounced to work. [12:03] Fujitsu: we didn't see the need to add that level of granularity for archive admin work [12:03] Fujitsu: and actualy, for that sort of stuff, you probably *want* them to be private, as there's bound to be at least one OMGTSIF critical bug, which needs to wait for the next rollout, so the less people who use it, the better. [12:03] in 1.2.5 we'll have extra permissioning for package-specific uploaders though [12:04] bigjools: -security will need completely different teams, won't it? [12:04] security is being done in a private PPA [12:04] As will universe, so that's already fairly granular. [12:04] Fujitsu: YMMV, but that's what we found last time. [12:05] does universe need a different set of archive admin permissions to multiverse>? [12:05] bigjools: That'd be another spec that'd be nice to have a public version of. [12:05] bigjools: Very unlikely. [12:05] no [12:05] (s-i-s, that is) [12:05] ok, good :) [12:06] I'll quickly summarise the plan for you, it will be good to get early feedback [12:06] we have 4 main tasks [12:06] 1. archive admin for MOTU, done via a new celeb that can access universe/multiverse uploads [12:07] 2. MOTU Buildd admin, to retry builds for universe/multiverse [12:07] 3. package-driven permissioning [12:07] 4. queue override in the UI pages [12:07] mmm I missed one, there's 5. post-publication override too [12:08] bigjools: why a separate buildd admin there? [12:09] WRT #2... why not just let component uploaders retry, like in PPA? [12:09] aren't there so few anyway, that it makes sense to let everyone access everything? [12:09] Yep. [12:09] Fujitsu: because it's not quite like the ppa stuff. [12:09] Fujitsu: and do you really trust all the MOTU's to do reprio'ing in a good way? [12:10] a separate team allows for more flexibility [12:10] Hobbsee: hence my `retry' bit. [12:10] bigjools: true [12:10] Fujitsu: oh, just retry. i missed that bit. [12:10] and I know how demanding our users are ;) [12:10] Hobbsee: Rescoring and buildd adminning should still be done build a separate team. [12:10] right, yeah. i misread it then, sorry. [12:10] bigjools: ...cancel builds? pretty please?? :D [12:10] Er, I can't speak English, apparently. [12:11] hehe - it's not in the agenda :( [12:11] bigjools: why? [12:11] bigjools: why is all this new stuff on the agenda with buildd admins, yet something as simple and important as cancelling builds not be there? [12:12] Poking sysadmins to fix buildds isn't really ideal. [12:12] Fujitsu: you haven't done it, i suspect. [12:12] Hobbsee: what you perceive as simple isn't necessarily so [12:12] bigjools: well, relatively speaking. i know nothing in soyuz is simple. [12:12] but I will raise it and see what we can do [12:12] thanks. it would be really good to have. [12:13] I know... it would make our life easier too to be fair [12:13] are you guys going to UDS? [12:14] bigjools: you can't seriously think i got an invite. [12:14] bigjools: i think i whinged far too much for that. [12:15] heh [12:15] there's a fine line between whinging and constructive feedback :) [12:15] bigjools: if i'm actually active, maybe i'll get to prague+1. If not... [12:15] yeah well. apparently i never give constructive feedback, so... [12:16] and I thought it was supposed to be Brits who whinged :) [12:16] maybe the brits learned to shut up and take it like it was, rather than attempting to change it. apparently the aussies haven't learnt that lesson yet [12:17] er, s/was/is/ [12:17] * bigjools ducks out of the conversation at this point! [12:17] heh [12:18] look out for more bugs file for admin - I'm beavering away on them right now [12:18] 1.2.4 is going to get a lot targeted to it [12:18] bigjools: was my list helpful? [12:18] bigjools: Realistically targetted? [12:18] Hobbsee: yes thank you. We won't get around to all of that, but I think at least 2 of them can be done [12:19] Fujitsu: better not to ask that. [12:19] * bigjools has cracked the whip of realism on the Soyuz team [12:19] bigjools: the checkbox, the queue default length, and the wrong url redirect? [12:19] I'm finally convincing cprov not to target 50 bugs to each milestone! [12:19] woot! [12:19] bigjools: Yay! [12:20] our current priority is the LP 2.0 goals, plus any critical bugs [12:20] Hobbsee: the batch size and the override info [12:21] should be easy to do those - I'll also see if we can do a "un/check all" [12:21] bigjools: right. [12:21] * Hobbsee would have classed the wrong url redirect as the most annoying of them, but OK [12:21] guess it depends if you're doing the default queue or not [12:22] yeah it sounds irritating [12:22] Is s-i-s realistically targetted to 1.2.4? [12:22] yup [12:23] it's mostly done already [12:23] ie. very near Hardy release? [12:23] Very nice. [12:23] it won't be done in time for Hardy [12:23] As long as it doesn't explode. [12:23] but soon after [12:23] Right. [12:23] we have a couple of infrastructure privacy issues to fix and then it's going live [12:24] (I mostly do security stuff these days, hence the interest) [12:24] actually, I hope to get it tested before 1.2.4 with security builds that are not embargoed === thekorn_ is now known as thekorn [12:24] Fujitsu: we have the capability to have a separate PPA for MOTU security [12:25] bigjools: How does copying from security PPAs to primary occur? [12:26] right now it's a command line utility, but in this cycle we're adding UI support for it [12:26] So it's the same process as any other PPA? [12:26] pretty much [12:26] But executable by -security rather than -archive, I hope... [12:27] it will use the same permissioning as the private PPA does [12:27] btw if you see P3A anywhere, that's a private PPA :) [12:27] PPPA.... [12:27] Aha. [12:41] New bug: #207701 in soyuz "Community Admin: The queue UI should allow overriding" [High,Triaged] https://launchpad.net/bugs/207701 === al-maisan is now known as al-maisan-lunch === barry-away is now known as barry [12:58] hi barry :) [13:01] emgent: hi! [13:02] emgent: do you have details on how the rename broke your list? [13:08] yep [13:09] 550 5.0.0 ----->>> User mailbox is Full. Quota limit excedeed <<<----- [13:09] ----- The following addresses had permanent fatal errors ----- [13:09]

[13:09] (reason: 550 unknown user) [13:09] (sorry for little flood) [13:09] ops sorry. I'm dude. correct email is ubuntu-whitehat@lists.launchpad.net. [13:09] just a moment. [13:11] barry: all ok, sorry.. working fine [13:11] :) === \sh is now known as \sh_away [13:11] emgent: phew! that's great to know. i think we'll be able to automate such renames in the future [13:11] thanks for letting us experiment on you :) [13:11] heheh thanks to you :) [13:13] * emgent go to fix horde3 [13:14] Are uploads to -proposed announced anywhere? === \sh_away is now known as \sh === salgado_ is now known as salgado === mrevell is now known as mrevell-lunch === al-maisan-lunch is now known as al-maisan [13:41] hi there [13:41] I keep having trouble opening new bug via email/malone [13:41] is any dev able to look at the error emails and tell me what is wrong? [13:42] BUGabundo: are you signing them? [13:42] ye [13:42] *yep [13:42] I sign all my emails [13:43] ill email back the bounce to LP ML [13:43] so you can have a look [13:44] * Hobbsee is no LP dev. [13:45] I know hob [13:45] sent [13:46] did you get it? [13:46] BUGabundo: can i have a look? [13:47] sure [13:47] all help is good [13:47] please reply here [13:47] I won't be seeing email until tonight [13:47] bug 207733 is cracking me open... [13:47] Launchpad bug 207733 in openoffice.org "[hardy] openoffice about says v2.3 and v2.4" [Undecided,New] https://launchpad.net/bugs/207733 [13:47] email is so old fashion anyway :) [13:48] buuuu [13:48] how do you want poor me to register and reply to LP while offline? [13:49] i'm just joking. this is an internet meme that has been making rounds for a few years now and i never quite get [13:50] but I do agree with you [13:50] social networks [13:50] and IM [13:50] will rule soon [13:51] we had that discussions so many timesssss on jaiku [13:52] BUGabundo: did you send your bounced email? i can't see it yet [13:52] I did [13:52] let me see if I got the ack [13:53] no ack [13:53]