| * maxb looks mournfully at the daily builds taking all the builders | 00:01 | |
| persia | Do they score below other tasks? | 00:02 |
|---|---|---|
| wgrant | persia, maxb: They will soon be staggered throughout the day. | 00:12 |
| persia | That's interesting, but how are they scored? | 00:13 |
| wgrant | The same as any other build, I believe. | 00:13 |
| wgrant | We have considered lowering them. | 00:14 |
| wgrant | But that tends to make people angry. | 00:14 |
| lifeless | fairness is hard | 00:14 |
| lifeless | we will get to it | 00:14 |
| lifeless | but first performance | 00:14 |
| lifeless | wgrant: whats the staggering for ? | 00:14 |
| wgrant | lifeless: All daily builds are currently requested by a daily cron job. | 00:15 |
| wgrant | They will soon be requested throughout the day, as their branches become stale. | 00:15 |
| wgrant | So we will no longer have several hundred builds requested in 30 seconds. | 00:15 |
| persia | My thought was that something resulting from dput was a direct expression of immediate interest in build, whereas recipe builds tend to be based on scheduling, which may not correlate closely to interest. That said, I don't much care, as I don't use that pool of builders :) | 00:15 |
| === zyga is now known as zyga-afk | ||
| wgrant | persia: Yes, it's been tried, but people disagree :) | 00:16 |
| * persia grumbes generally at people | 00:17 | |
| maxb | My dputs express an immediate interest | 00:22 |
| maxb | This is why when I actually notice a queue, I submit them with medium urgency :-) | 00:22 |
| persia | maxb, urgency has less influence than you'd think. | 00:23 |
| maxb | It has enough to jump in front of the daily build queue | 00:23 |
| wgrant | persia: All PPA builds have the same score. | 00:24 |
| persia | Depends on timing. I haven't checked the scoring algorithm recently, but I seem to remember that the time-based adjustments were larger than the priority-based adjustments. | 00:24 |
| wgrant | medium bumps it by 5-10, IIRC, which is quite enough to put you right in front. | 00:24 |
| wgrant | The time-based adjustments are no longer active. | 00:24 |
| persia | There's no time bonus for PPA builds? | 00:24 |
| persia | Aha! | 00:24 |
| maxb | The time-based adjustments sucked, but they are now off, which is nice | 00:24 |
| persia | In that case, it doesn't matter. Those using dput who care can arrange to jump the queue. | 00:24 |
| maxb | I never understood why anyone wrote time-based adjustments for what is essentially a FIFO queue, anyway | 00:25 |
| maxb | Oh, and retried builds come in at their original score now, don't they? | 00:25 |
| wgrant | maxb: I don't know. Most of the scoring algorithm is terribly overcomplicated and we want to delete it. | 00:26 |
| persia | I thought it was to avoid a resource collision for Ubuntu, so that stuff in "universe" would sometimes build, even if stuff in "main" was uploaded, which wouldn't necessarily otherwise happen from a strict FIFO perspective because of the main bonus. | 00:26 |
| lifeless | so | 00:26 |
| wgrant | That could be it. | 00:26 |
| lifeless | please don't think too hard about this | 00:26 |
| lifeless | soyuz scheduling fairness is nonexistant | 00:26 |
| persia | lifeless, Because we're getting rid of scoring entirely? | 00:26 |
| maxb | The wording on the "your build has been retried" page is now inaccurate, I think | 00:26 |
| persia | lifeless, Because it's not fair, it's subject to gaming, which is why it's interesting :) | 00:26 |
| lifeless | scoring is an implementation detail caching the result of whatever queueing algorithm we've run; scoring could stay and we can reengineer | 00:27 |
| lifeless | or we might nuke it | 00:27 |
| lifeless | I don't want to prejudge what whichever team comes along to do fairness will do | 00:27 |
| wgrant | Soon, once we stagger daily builds and have some new builders, scores will become largely irrelevant, because everything will build fairly quickly. | 00:27 |
| lifeless | wgrant: oh the optimism | 00:28 |
| persia | wgrant, Ideally, although with finite resources, there's always potential for delays. | 00:28 |
| wgrant | We cope very well at the moment, except for the daily build spike. | 00:29 |
| maxb | It's vastly better now than at times past when the chromium/mozilla dailys took over the farm for some hours | 00:30 |
| === Meths_ is now known as Meths | ||
| === Whoopie_ is now known as Whoopie | ||
| === Ursinha is now known as Ursinha-afk | ||
| === zyga-afk is now known as zyga | ||
| mrevell | Good morning | 09:08 |
| === danilos changed the topic of #launchpad to: Launchpad: https://launchpad.net/ | Codehosting down from 12.00 UTC for 20 mins http://is.gd/wgw0sI | Read https://help.launchpad.net/ for help | On-call help contact: danilos | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: https://dev.launchpad.net/ | ||
| mdz | I'm getting spammed with bug watch notifications for upstream importance going from a known state to Unknown | 10:33 |
| mdz | known problem? | 10:33 |
| allenap | mdz: Yes, I'm trying to figure out why now. | 10:40 |
| allenap | mdz: Bug 707478 for reference. | 10:40 |
| ubot5 | Launchpad bug 707478 in Launchpad itself "Freedesktop bug watches are (incorrectly) updated with "importance unknown"" [Critical,In progress] https://launchpad.net/bugs/707478 | 10:40 |
| mdz | allenap, thanks | 10:40 |
| === JanC_ is now known as JanC | ||
| === bilalakhtar_ is now known as cdbs | ||
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| danilos | fta, hi, I'm looking for your block post, and I wonder how exactly does the "merging" happen in step 2 of "Receiving from Launchpad"? | 12:32 |
| fta | danilo, hi, which step 2 are you referring to? | 12:35 |
| fta | danilos, ^^ | 12:35 |
| danilos | fta, "the converter runs with all the selected grd templates for the considered branch, reads the gettext files just fetched in the previous step and merges the strings matching the (possibly older) template (yellow 4)" | 12:36 |
| danilos | fta, from my position, this is the place where you can choose to prefer Launchpad (branch) over upstream translations (grd files) | 12:37 |
| fta | danilos, oh, that part doesn't concern lp. it's when i take a grd template from one of the upstream branches, along with its associated xtb files (also from upstream) and i add the gettext strings i got from the last lp export | 12:37 |
| danilos | fta, of course, you'd have to instead feed this into the Launchpad as well, which is not something you do | 12:38 |
| danilos | fta, right, I misunderstood it for a moment :) | 12:38 |
| fta | i'm not feeding back to lp the strings i got from a lp export | 12:39 |
| fta | so you're saying i'm supposed to do that now? | 12:40 |
| danilos | fta, right, I see that... so, as I said earlier, since LP is not designed to know about this yet (you basically have a translations fork), so the best thing to do is to actually merge them before committing | 12:40 |
| danilos | fta, right | 12:40 |
| fta | but if i do that, lp will see me as translator, right? | 12:41 |
| danilos | fta, ideally, Launchpad would have a notion of forks, and we'd have a chromium-browser project with just the upstream translations, and another chromium-browser-daily (or something) which would fork the translations | 12:41 |
| danilos | fta, not if you keep the Last-Translator correct (Launchpad should export it: the important thing is that it needs email to recognize someone as a translator, and I think we don't export the email when someone has hidden their email address, when you might be listed as the translator) | 12:41 |
| danilos | s/email/email address/ | 12:42 |
| danilos | fta, also, Launchpad won't try to change translator of any string that is already there | 12:43 |
| danilos | fta, so, you won't be set as the translator for any strings you got from LP | 12:43 |
| danilos | fta, unless there's a bug which'd do that | 12:43 |
| danilos | fta, now, there might be a few other bugs that simply need fixing | 12:44 |
| danilos | fta, i.e. we should have never lost any translations anyway, so there should be no increase in the number of untranslated strings | 12:45 |
| fta | so what about all the strings that used to be "updated in lp"? | 12:45 |
| fta | i had thousands of those before the change | 12:45 |
| danilos | fta, well, they've now been overridden by the new imports | 12:46 |
| fta | all of them? i doubt it | 12:46 |
| danilos | fta, were there any strings that were untranslated upstream, were translated in lp, and are not untranslated in lp? | 12:46 |
| danilos | fta, if there were, that's a very important and critical bug for us | 12:46 |
| fta | it's difficult to tell.. but i think a lot of improvements have been lost | 12:48 |
| fta | looking at the bzr revs... | 12:48 |
| danilos | fta, right, it would be good to point a few cases out because that makes it easier for me to investigate | 12:49 |
| fta | let's try with the blue strings in this weeks old screenshot: http://ftagada.wordpress.com/2011/01/07/more-chromium-translations-landed-upstream/ | 12:50 |
| danilos | fta, for instance, it is exepcted that any "pure" upstream import overrides the LP translation today (they used to work in a relatively arbitrary fashion in the past: sometime it did, sometime it didn't) | 12:50 |
| danilos | fta, sure | 12:50 |
| danilos | fta, well, if they were "updated in LP", then they were most likely overridden, as explained above | 12:51 |
| fta | danilos, i'm not sure upstream changed all of those in their last batch | 12:52 |
| danilos | fta, oh, so you say you didn't even upload a PO file containing them because there were no changes? note that one string change in the entire PO file might be indicative instead | 12:52 |
| danilos | fta, do you think it'd be ok to do the merge step before you feed the translations back into LP? that would solve a big number of problems | 12:56 |
| danilos | fta, I'd be happy to help get the translations back before LP messed them up for you, if I figure out a nice way to do it | 12:56 |
| danilos | fta, I know it would appear uglier for you, but at least we can always recreate upstream translations and figure out the diff that way if we really need to (i.e. to show how many improvements there are in a LP-hosted project) | 12:58 |
| fta | danilos, http://paste.ubuntu.com/558535/ | 13:03 |
| fta | danilos, for me, it's a bug. it's not a case where upstream improved the string, the last updated value is the one in lp | 13:05 |
| === mrevell_ is now known as mrevell | ||
| danilos | fta, right, I agree that the desired behaviour is for LP to keep the better version, but LP can't really know which one is | 13:19 |
| danilos | fta, so, LP makes sure that upstream matches the real upstream | 13:20 |
| fta | danilo, that string didn't change in the imported branch, so lp should know | 13:20 |
| danilos | fta, it has even been our long-standing policy to not let forks get translated, because people used to register entire projects just to translate one language | 13:20 |
| danilos | fta, well, we do want to have a different translation policy where you can set your project to prefer LP strings instead, but we've not done it yet | 13:21 |
| danilos | fta, I do see you point, but LP could never really tell that in the past either | 13:22 |
| fta | danilos, i think you didn't get my point. i'm totally ok to get the updated-in-lp strings moved to need-review if a new version is imported (and preferred by default), but here, it's not a new version, it's the same old string that the lp translator improved | 13:22 |
| danilos | fta, yeah, what I am saying that LP never kept track if that was the same string the last time or not | 13:23 |
| fta | oh, that's bad | 13:23 |
| danilos | fta, it worked very arbitrarily on what string it would prefer | 13:23 |
| fta | it seems all the translators work is lost every time upstream touches something in a template | 13:24 |
| danilos | fta, well, kind of; it would be very expensive to calculate each time and to basically keep snapshots of each upstream import and LP translation in the DB | 13:24 |
| fta | why, it's in the imported branch, you have the info there | 13:25 |
| fta | no need for snapshots | 13:25 |
| fta | that's what i'm doing btw | 13:25 |
| fta | i only have 2 versions, the upstream files and the lp export branch | 13:25 |
| danilos | fta, heh, sure it is, but not all projects have branches attached, so we'd still have to worry about the other case (manual uploads) | 13:25 |
| danilos | fta, and, processing that would be very slow | 13:26 |
| danilos | fta, I do see your point, and that would be a nice improvement, but I believe it would be pretty hard | 13:26 |
| fta | it already takes hours.. | 13:26 |
| danilos | fta, exactly | 13:26 |
| danilos | fta, it's not because it takes hours processing your branch, but because of all the branches there are to process | 13:27 |
| danilos | fta, we do need to improve the performance of imports though, they have gotten slower with our upgrade to postgres 8.4 as well :( | 13:28 |
| fta | do you mean it's all done in a single batch? it's not a batch per project?? | 13:28 |
| danilos | fta, it's a batch for ubuntu and batch for everything else (all projects together), yes | 13:28 |
| fta | d'oh! | 13:29 |
| danilos | fta, we have lots of horizontal scalability today, so we could make it a batch per project, but we didn't originally, and this only means more work | 13:29 |
| danilos | that we can hardly get to, but yes it'd be nice :) | 13:29 |
| fta | danilos, i'll see what i can do to merge the lp strings in the import branch, but it won't solve the problem for all the strings that has been lost since this mess started | 13:39 |
| fta | -has+have | 13:40 |
| danilos | fta, right, that's what we'll have to manually figure out if we can... basically, any import after Jan 12th might have caused a few regressions so it'd be probably be nice to reimport translations from that date | 13:41 |
| fta | oh my. | 13:44 |
| === Ursinha is now known as Ursinha-lunch | ||
| danilos | fta, yeah, I know, I am sorry about that; I can probably get a list of strings that have been submitted from LP but are not active anymore with direct DB queries, if you think that'd help | 13:46 |
| fta | danilo, i assume that ownership of those strings will be lost then | 13:46 |
| danilos | fta, oh, no, they are all in DB, just hidden | 13:46 |
| danilos | fta, so they'll just be reactivated | 13:47 |
| danilos | fta, (the problem with a direct DB query is that it would return us all discarded suggestions as well, so if there was more than one string suggested in LP, we wouldn't know which to take; but maybe these cases are rare and far apart and this would let us fix the majority of cases) | 13:48 |
| fta | the problem is that in that interval, i have a/ the lp changes b/ the upstream massive update c/ a template that i started to import d/ me adding support for the new json translation format and e/ a massive rewrite of a template upstream | 13:52 |
| fta | i can feel a headache starting... | 13:53 |
| fta | and of course, daily updates of the templates and lp contribs | 13:53 |
| danilos | fta, right, so I think it'd probably be best to try to get Launchpad provided strings which are not used anymore and see how many of them there are (that's something I can do for you) | 13:54 |
| danilos | fta, there's a total of 7710 strings on staging across all languages in Chromium that have been submitted through Launchpad but are not active at the moment | 14:10 |
| fta | danilos, that much? woww. i expected something like 2~3000 | 14:11 |
| fta | danilos, oh, i see, new langs, with 3300 strings each | 14:12 |
| danilos | fta, not all of them might be "inadvertently" lost; some of these might be actually bad translations | 14:12 |
| danilos | fta, well, new langs should still have the translations "active" | 14:12 |
| danilos | fta, these are all strings *ever* submitted into chromium browser through LP that are currently not active; there's more than 19000 strings which are active, which means that these have been pushed upstream in the meantime | 14:13 |
| fta | danilos, nope, not 19000, as i landed just one template | 14:14 |
| danilos | fta, this number might include a bunch of suggestions people have made, because when a translation from LP is discarded, it remains in as an old suggestion, so I can't tell them apart | 14:14 |
| fta | http://people.ubuntu.com/~fta/chromium/translations/trunk/converter-output.html | 14:14 |
| fta | only the green ones in the chromium_strings template | 14:15 |
| fta | this template was not translated at all before | 14:15 |
| danilos | fta, I mean 19000 translations that we have in the DB have originally came in through LP, and are probably upstream already | 14:15 |
| fta | danilos, remember that a few months ago, i changed the formating, so most are probably garbage | 14:16 |
| danilos | fta, right, any hint how I could exclude those (i.e. anything I can exclude with LIKE in SQL?) | 14:16 |
| fta | a date | 14:17 |
| fta | ? | 14:17 |
| fta | the baseline is r90 in the import branch, and r89 in the export branch | 14:17 |
| fta | everything that happened afterwards is weird | 14:18 |
| danilos | fta, so I excluded obsolete messages (forgot about that) and we are now down to 7300 (not much of an improvement) | 14:19 |
| danilos | fta, ro r90 and r89 is exactly around the LP rollout time, so that's what I expected | 14:20 |
| danilos | fta, basically, we started overwriting all the strings in LP with ones from LP | 14:20 |
| fta | danilos, you meant from upstream, right? | 14:21 |
| danilos | fta, right, instead of the second "LP" :) | 14:21 |
| === matsubara-afk is now known as matsubara | ||
| === jml changed the topic of #launchpad to: Launchpad: https://launchpad.net/ | Read https://help.launchpad.net/ for help | On-call help contact: danilos | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: https://dev.launchpad.net/ | ||
| danilos | fta, so, if you think this might be useful, here's the raw export of these currently inactive translations first created in LP: http://people.canonical.com/~danilo/tmp/chromium-strings.txt.gz | 14:29 |
| === Ursinha-lunch is now known as Ursinha | ||
| fta | danilos, in that form, it's difficult for me to use. and it lacks some info i need to do a merge with my tools | 14:33 |
| maxb | Hmm. I have just discovered a third branch which is stuck in a "waiting for the branch scanner" state for a long period | 14:33 |
| danilos | fta, it should be relatively easy to parse with automatic tools, and it's easy to add more details that do exist in the DB | 14:35 |
| danilos | fta, it has (in order) potemplate name, English string, language code, translation, and date translation was submitted | 14:41 |
| danilos | anyway, got to reboot now | 14:41 |
| danilos | maxb, btw, are you keeping track of them in a bug? I know I've found a few branches that are out of date which translation export tries to write to (and so it fails) | 15:38 |
| maxb | Not as yet, I'd only just stumbled across the third | 15:40 |
| maxb | I was hoping someone could have a quick look and decide whether this was something that needed developer or losa attention | 15:41 |
| === deryck is now known as deryck[lunch] | ||
| hv | hi, is there a plan to offer VPS hosting (either openvz or xen) for launchpad users? | 15:52 |
| benji | hv: I'm not aware of any plans along those lines. | 15:55 |
| danilos | maxb, generally, bazaar experts team can handle that, or a user by pushing another revision to the branch | 15:56 |
| danilos | maxb, afaik, but bazaar experts should know if that's the case :) abentley, how about you? maxb found a few branches that are in "updating" state for a long while | 15:57 |
| maxb | danilos: hmm. But, we should probably try to find out what broke the original scan | 15:57 |
| maxb | Also, two of them are vcs-imports, to which you need to have some sort of superpower to access | 15:57 |
| maxb | write-access, I mean | 15:57 |
| danilos | maxb, some of the things we are aware of... eg. killing a script run can cause the state to be messed up | 15:58 |
| danilos | maxb, right, that's what I meant with bazaar-experts | 15:58 |
| abentley | danilos, I don't know of a bug offhand. These things should show up in oops reports, though. | 16:00 |
| === doko_ is now known as doko | ||
| abentley | danilos, I don't think any users can write to import branches, even bazaar-experts. | 16:01 |
| danilos | abentley, right, thanks | 16:01 |
| danilos | abentley, so do you think it'd be worth filing a bug and later seeing if it's a duplicate or not? (I'd rather get a duplicate than not have a bug at all) | 16:02 |
| abentley | danilos, what would the bug be? branch scanner doesn't retry if scanning a branch fails? | 16:02 |
| danilos | abentley, well, it would be "branch scanner stuck" from a users' perspective, I think | 16:03 |
| abentley | danilos, so the bug would be that we're not telling the user that the scan failed? | 16:04 |
| danilos | abentley, I don't know, if that's the problem, then yes | 16:04 |
| maxb | abentley: We have one problem branch which is not a vcs-import. Do you have time to do a no-op write on it so we can see if it resolves itself? https://code.launchpad.net/~mogray5/infinitypfm/infinitypfm-0.5 | 16:05 |
| abentley | danilos, I don't want to file a bug that the branch scanner can fail-- we can't fix every case. | 16:05 |
| abentley | danilos, of course, filing a bug for the individual oopses would make sense. | 16:06 |
| danilos | abentley, well, we can fix a bunch of these cases | 16:06 |
| maxb | Perhaps the bug could be "There should be a report on branches which would be displaying "Updating branch..." in the web UI >N hours after their last change" | 16:06 |
| danilos | maxb, yeah, and we could probably clear the status on them automatically if we don't have time to fix every individual bug | 16:06 |
| maxb | Some scanner failures result in the failure reason being presented in the UI, and the "Updating branch..." message going away. In theory, any scanner failure which doesn't shouldn't be *that* hard to fix to at least report itself sanely | 16:07 |
| abentley | maxb, I've triggered a rescan on lp:~mogray5/infinitypfm/infinitypfm-0.5 | 16:10 |
| maxb | no change, I guess something broke againi | 16:14 |
| abentley | danilos, I've filed https://bugs.launchpad.net/launchpad/+bug/708110 | 16:15 |
| abentley | danilos, scanner failures are already oopses, so I don't think there's a need to increase their priority. | 16:16 |
| danilos | abentley, right, thanks | 16:17 |
| leonardr | what's the procedure for unblocking the rollout? should i do ec2 land or just qa locally, push it through, and let buildbot see if it works? | 16:18 |
| abentley | leonardr, per lifeless' message, you should do a --rollback landing. | 16:19 |
| leonardr | let me check and see what's already happened... | 16:21 |
| leonardr | ok, i think i got it | 16:26 |
| shadeslayer | can i make a test account on staging.launchpad? | 16:36 |
| shadeslayer | and will it be destroyed later on? | 16:36 |
| leonardr | shadeslayer: i'm pretty sure you can create a test account and it will be deleted within a week | 16:41 |
| shadeslayer | alrighty :) | 16:41 |
| danilos | shadeslayer, you might have some issues creating a login because email doesn't go out from staging | 16:46 |
| shadeslayer | danilos: worked fine :) | 16:47 |
| shadeslayer | we just need to test commenting on a bug | 16:47 |
| danilos | shadeslayer, excellent :) | 16:47 |
| leonardr | ok, the blockage-removal branch is in ec2... | 16:47 |
| jcsackett | hm. it's hailing here. the last time this happened, i lost internet for three days... | 16:50 |
| === deryck[lunch] is now known as deryck | ||
| === danilos changed the topic of #launchpad to: Launchpad: https://launchpad.net/ | Read https://help.launchpad.net/ for help | On-call help contact: - | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: https://dev.launchpad.net/ | ||
| danilos | jcsackett, keep a strong hold of it this time around | 16:55 |
| === leonardr is now known as leonardr-afk | ||
| lifeless | jcsackett: did you call out 'here inter inter internet'? | 17:00 |
| jcsackett | lifeless: i even shook a bag of treats! nothing worked. :-P | 17:01 |
| lvh | Hi. I'd like to add an existing project to Launchpad. It's ISC licensed. That license isn't in the list, but it's equivalent to some of the permissive ones that are. Is it considered very bad form to list it as newBSD/MIT/X11 (which are all pretty much equivalent: do what you want, but add this notice)? | 17:23 |
| lvh | It's not technically correct, but it's hardly dishonest. | 17:24 |
| lvh | (Okay, it's not entirely the same thing as MIT/X11. It's MIT/X11 sans the no advertising clause.) | 17:25 |
| maxb | There's an "Other/Open Source" option, why not use that? | 17:26 |
| lvh | Err, this was a while ago, either that didn't exist or required manual verification, or something. I forgot which one. | 17:29 |
| lvh | But yeah, that sounds good, I'll do that | 17:29 |
| lvh | thanks | 17:29 |
| maxb | It probably still requires manual verification, but you can still use the new project whilst that verification is yet to occur | 17:30 |
| === mnepton is now known as mneptok | ||
| lvh | aha | 17:33 |
| === Lcawte|Away is now known as Lcawte | ||
| maxb | boo, no CHR | 17:38 |
| maxb | I'm trying to set up a code import for MINA, but the project doesn't appear in Launchpad. I infer from errors in the registration process that it is registered but deactivated | 17:38 |
| lifeless | 'mina' ? | 17:40 |
| maxb | yes | 17:40 |
| lifeless | title 'english finish' | 17:40 |
| maxb | !? | 17:40 |
| maxb | Could you rename that to mina-nonsense-deactivated or something? | 17:41 |
| lifeless | sinzui: can we change ownership of projects? | 17:41 |
| maxb | If the existing project metadata is that weird, it's probably just a coincidental id collision? | 17:42 |
| lifeless | yah | 17:43 |
| lifeless | not touched since 2007 | 17:43 |
| === bigjools-afk is now known as bigjools | ||
| lifeless | maxb: make a new one | 17:43 |
| maxb | Thanks | 17:44 |
| maxb | ouch, the new project licence widget seems even more broken | 17:46 |
| sinzui | maxb: I fix landed a few days ago | 17:54 |
| sinzui | maxb: the yui upgrade broke it a few weeks ago | 17:54 |
| sinzui | lifeless: only a losa can change the project owner | 17:56 |
| sinzui | If I could change an owner, I would have done so to fix about 600 licenses | 17:56 |
| Chex | sinzui: do you need me to do that change? | 18:12 |
| sinzui | Chex: I was offlined. I do not know *what* might need changing | 18:12 |
| maxb | If it's the one recently above, no. | 18:13 |
| maxb | The decision was to rename the old project to allow the id to be reused with a brand new one | 18:13 |
| maxb | oh, well, that applies to mine. I don't know about sinzui's 600 licenses | 18:14 |
| Chex | maxb: yes was talking about your request :) no problem | 18:17 |
| === Meths_ is now known as Meths | ||
| === leonardr-afk is now known as leonardr | ||
| slangasek | hi, does someone here have the ability to unsubscribe a LP user from bug mail? | 20:10 |
| slangasek | user jlgutisu3 seems to have subscribed himself to all bug mail for one of the Ubuntu stable releases in error and now is replying to everything asking people to speak only in spanish because he doesn't understand english | 20:11 |
| slangasek | and I'd guide him how to unsubscribe, except I can't myself see where he is subscribed | 20:11 |
| deryck | slangasek, if you'll open a question against launchpad we can assign to a losa to unsub him | 20:11 |
| slangasek | will do, thanks | 20:12 |
| deryck | np | 20:12 |
| slangasek | https://answers.launchpad.net/launchpad/+question/142981 | 20:14 |
| deryck | info added and assigned to losas for the real work | 20:20 |
| slangasek | thanks again :) | 20:20 |
| poolie | did wontfix go away? | 21:16 |
| poolie | or is there an acl on setting it? | 21:16 |
| lifeless | cannot wontfix if you are not a bug supervisor/driver/owner | 21:18 |
| bac | mwhudson: what's the name of your simple presentation program? where can it be found? | 21:29 |
| mwhudson | bac: console-presenter | 21:29 |
| mwhudson | & lp:console-presenter :-) | 21:29 |
| bac | thanks! | 21:29 |
| === StevenK changed the topic of #launchpad to: Launchpad: https://launchpad.net/ | Read https://help.launchpad.net/ for help | On-call help contact: StevenK | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: https://dev.launchpad.net/ | ||
| nhandler | So does anyone know why I am unable to push to lp:classbot/devel (doing so causes bzr to crash) | 22:10 |
| nhandler | ErrorFromSmartServer: Error received from smart server: ('error', "We are missing inventories for revisions: [StaticTuple('nhandler@ubuntu.com-20100920220053-yztqc4i042olpvnp',)]") | 22:11 |
| wgrant | nhandler: What's the error message? | 22:11 |
| wgrant | Ah. | 22:11 |
| wgrant | That's not good. | 22:11 |
| nhandler | wgrant: No it is not. It has been coming up for a while, but only when I push to that one branch. Other branches work just fine | 22:11 |
| wgrant | You might be better off asking #bzr. | 22:11 |
| nhandler | wgrant: Alright. I wasn't sure if it was an LP or bzr issue. I'll try asking there. Thanks. | 22:12 |
| wgrant | It's definitely a bzr issue. | 22:12 |
| === Lcawte is now known as Lcawte|Away | ||
| cjohnston | Whats up with the horribly long wait time for downloading translations? | 22:44 |
| poolie | lifeless, ah, the main other thing i wanted from you was a review of https://dev.launchpad.net/LEP/BuildFromBranchIntoMain#preview | 23:13 |
| poolie | jml, don't suppose you're still online? | 23:14 |
| lifeless | poolie: he has stuff on wed evening | 23:15 |
| poolie | it is pretty late anyhow | 23:15 |
| udienz | anyone from Launchpad admin online? | 23:39 |
| udienz | https://answers.launchpad.net/launchpad/+question/36290 | 23:39 |
| udienz | stil get trouble | 23:39 |
| udienz | owh fixed now, thanks for quick response | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!