[00:00] jono: is the broken run running lucid ? [00:00] lifeless, no, on Precise [00:00] but I think I sourced the issue [00:01] I have a loop which runs any outstanding scripts and it was running it again after the first script had started [00:01] when changed the loop to wait enough time for the script to complete, it worked fine [00:19] lifeless, so it looks like I am still getting this SSLError about the read timing out [00:24] jono, this is from a launchpadlib script? [00:24] do you have a proxy? [00:24] poolie, yes, in a lplib script, and no proxy [00:25] sometimes it runs fine, sometimes I get the SSLError [00:25] ... [00:25] hm [00:25] mtu problem perhaps? [00:25] please pastebin the traceback? [00:25] jono: butfirst, make a new gpgkey (don't!, I'm teasing) [00:26] lifeless, lol [00:26] poolie, one sec [00:27] poolie, http://pastebin.ubuntu.com/845199/ [00:27] hm, it's failing when starting to read the request [00:28] it's possible it's timing out on the server [00:28] i wonder if you have old code that's connecting to edge.l.n? [00:29] I only wrote this yesterday [00:29] I don't think it talks to edge [00:31] i would probably try getting a packet capture next, i guess [00:31] do you know how to do that in tcpdump or wireshark? [00:33] poolie, sorry, no [00:33] ok [00:33] btw are you jono bacon or some other jono? :) [00:33] ... [00:34] ok try [00:34] sudo tcpdump -i eth0 -p ip net 91.189.89.0/24 and tcp port 443 -w /tmp/lp.dump [00:34] (you might need to install it) [00:34] then put that file somewhere [00:34] poolie, jono bacon [00:35] you're intentionally running the .py~ version? [00:35] no, that is a backup file, but it is the same [00:35] let me double check [00:36] poolie, I am on wireless, is that wlan0 ? [00:36] oh right [00:36] hm [00:36] there is another thing you can do which is [00:36] maybe a bit easier [00:37] in your script, before you import launchpadlib [00:37] insert [00:37] import httplib2;httplib2.debuglevel = 2 [00:40] ok I just ran it and it worked [00:40] will run a few more times until the problem happens [00:41] that may help and be easier [00:42] getting a capture when it does occur could be helpful [00:42] in telling whether it's a client, server or network error [00:42] :l [00:42] got it [00:42] want me to pastebin it? [00:42] That sounds good [00:43] yep [00:43] ok, here is the output from the script first: http://pastebin.ubuntu.com/845209/ [00:44] what should I do with the dump file? [00:45] put it on chinstrap or something [00:45] http://jonobacon.org/files/lp.dump [00:49] :/ [00:49] there's nothing obvious to me [00:50] what is different between the machine where it works and where it doesn't? [00:51] poolie, same machine [00:51] although I have tried it on two machines also [00:51] it seems to happen randomly [00:51] oh ok [00:51] which would suggest it is a server issue [00:51] yeah i guess it is [00:56] jono, i guess you should write your app to just catch the exception and retry [00:56] thanks poolie [00:56] mmmm [00:56] poolie, do I need to file a bug about this? [00:56] * lifeless suspects another client side SSL bug [00:56] like the last one that had some bzr users in a tizzy [00:57] are we using openssl or gnutls ? There was a gnutls issue recently IIRC [01:01] that has different symptoms [01:01] it's possible it's the same bug [01:02] actually that seems unlikely but it's possible it's a similar bug, or a reflection of a similar deep problem [01:02] jono it would be worth filing a bug [01:02] even if we don't know what the target should be :) [01:03] what would be awesome is if you can write a program that just loops until it fails [01:03] then we can try it on different clients, or a developer can reproduce it [01:03] sure, will see what I can do [01:03] mm it would be interesting too to know whether it's always the same url or set of urls [01:03] which would perhaps indicate an lp fault [01:07] jono, i don't think this is the problem but, after you write that script, it would be a bit interesting to see if [01:07] sudo sysctl -w net.ipv4.tcp_mtu_probing=1 [01:07] fixes it === SamB_ is now known as SamB [08:11] czajkowski: Thank you very much for your response [08:11] benonsoftware: no promblem [08:11] *problem [08:12] * benonsoftware is proberly going to stay up tonight reading each license :P === david is now known as davidcalle === czajkowski changed the topic of #launchpad to: https://launchpad.net/ | Help contact: czajkowski | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide: https://help.launchpad.net/ | Support: https://answers.launchpad.net/launchpad | For packaging help: join #ubuntu-packaging [09:13] Hallo [09:20] Hallo mrevell [09:21] Hey there danhg [09:21] How's Yam Yam Land? [09:22] Pretty good. How's Barthelona? [09:35] Hi, is it possible to remove an OpenPGP key from my Launchpad account (not only deactivate)? [09:35] I lost that key and I generated a new one. [09:36] * benonsoftware has lost keys many times :P [09:39] nyuszika7h: you should be able to remove it yourself there on your lp ac [09:40] czajkowski: I can only deactivate it [09:40] nyuszika7h: and your lp ac is ? [09:40] czajkowski: ~nyuszika7h [09:41] Key that I deactivated is 2048R/6A9D469C [09:41] czajkowski: hi Laura, I have a question about batch validation of translations import when you have a minute (I'll wait in line ;-)) [09:42] nyuszika7h: let me look [09:42] Ok [09:44] You can't fully remove keys. This is apparently by design [09:44] nyuszika7h: if you upload the new one you can replace it [09:44] czajkowski: I already uploaded the new one. [09:44] czajkowski: I'm just wondering why does launchpad not remove things like that, or let a normal user do it? (I'll hope in line :P) [09:44] Then again, there's little need to remove keys [09:44] I also signed the Ubuntu Code of Conduct with the new key, and removed the old signature. [09:44] s/removed/deactivated/ [09:45] nyuszika7h: Is there a reason deactivating the old key is not good enough? [09:46] maxb: I lost it, and I can't get it from anywhere because I don't have any backups of it. [09:46] right. so deactivate it, which you've already done [09:47] nyuszika7h: which is enough [09:47] odony: how can I help [09:47] Ok [09:48] czajkowski: we've just branched off a new trunk->stable branch for our project and created a new series for it, then enable bidi auto-sync of translations on it, in order to preserver our trunk translations [09:48] The only reason you might need a key removed entirely was if you wanted to move it to a different Launchpad identity [09:48] czajkowski: so the initial import has run, but it filled the translation queue with hundreds of PO files that we have to validate one by one (confirm language auto-detection and translation domain) [09:48] And if that was the case, you're stuck, because it's not possible (without raw SQL, which the admins now refuse to do) [09:49] czajkowski: the thing is, all those PO files were already approved and reviewed in out trunk, but now we have to do it all again manually.... is there any way to speed this up? [09:49] odony: i'm about to find out from jtv [09:49] * jtv reads backlog [09:50] maxb, odony: There should be no need whatsoever to approve PO files manually. [09:50] jtv: perhaps it is because our PO layout is not 100% standard? [09:50] I'm not part of the PO conversation, I'm only a part of the PHP conversation [09:51] *PGP [09:51] The layout makes all the difference, yes. [09:51] The standard layout is: [09:51] Each PO file in the same directory as its template, [09:51] jtv: e.g. our main branch has about 200 translation domains and this is the layout: /domain/i18n/xx.po [09:51] and named after the language code. [09:51] That in itself should be fine, [09:52] as long as the template is /domain/i18n/yyyy.pot [09:52] I used yyyy; bad example. I mean "your domain name" [09:52] jtv: and the templates are /domain/i18n/domain.pot [09:52] not "4-digit year" :-) [09:52] Then that should work. [09:58] jtv: actually I'm not too sure what happened, some of the PO files are stuck in the queue in Needs Review state, but the translations seem to have been imported because the same domain appears partially translated in the statistics for that series [10:01] Hey [10:01] http://launchpadlibrarian.net/92966336/autotools-dev_20110511.1_20120210.1.diff.gz says "A required database is unavailable. See http://identi.ca/launchpadstatus for maintenance and outage notifications." [10:01] and no messages from launchpadstatus in a month [10:02] lool: 1000-1005 UTC is an outage window [10:02] lool: it's back [10:02] It's back now [10:02] Was down for 86 seconds. [10:02] should the link be changed though? or should a bot be setup to announce it on launchpadstatus? [10:04] jtv: I guess I should first wait a few hours, our templates list is complete in the series but only the first few ones have a non-zero count of translations - I imagine this means the import is still in progress [10:04] jtv: https://translations.launchpad.net/openobject-addons/6.1/+templates [10:04] odony: sorry for the delay; also in a phone call [10:05] jtv: np, take your time :) [10:06] odony: the existing translations don't necessarily prove that imports happened. By default, it shares translations from other series for the same project/template/language. [10:06] odony: the imports normally shouldn't take very long. Scheduling is round-robin, so you'd see one of your files being imported, then a few minutes of imports for other projects, then one of yours again. [10:07] jtv: ok... didn't know translations were shared between series [10:07] odony: I don't think that happened when you started using Launchpad Translations. :) [10:08] But now, if a string is in 2 series (same template), translate one and it'll be instantly translated in the other series as well. [10:09] jtv: sounds good, and actually explains an issue we had where our trunk translations started to bleed onto our previous 6.0 stable series.. causing bugs in the process ;-) (because we use special PO comments for internal purposes, and their format had changed) [10:10] jtv: that's actually weird.... I mean the msgid would be the same in the 2 series, but the comments were not... so I assume it should be using the one from the right series when exporting the actual PO, shouldn't it? [10:10] jtv: s/the one/the ones/ (meaning the comments) [10:18] odony: off the phone. :) [10:19] jtv: :) [10:19] odony: we never really anticipated the comments being so significant, really; I think the comment will be whatever was imported most recently. [10:22] jtv: ok, that would indeed have been our trunk comments... I understand better. Anyway we worked around it and it was really no big deal [10:22] jtv: so, assuming the translation count basically comes from other series, we still have hundreds of PO sitting in the import queue and waiting to be manually reviewed... what can we do about them? ignore them because they're in fact identical to the translations that are shared? [10:22] jtv: e.g. https://translations.launchpad.net/openerp-web/6.1/+imports?field.filter_status=NEEDS_REVIEW&field.filter_extension=all === debfx_ is now known as debfx [10:22] * jtv has a look [10:24] I'll just go through a bunch of checkboxes now, things that _might_ be blocking automatic approval. May take a while. [10:24] The paths look OK; there's a template in the same directory. [10:24] jtv: thanks... the openerp-web project has a different layout from what I mentioned with a leading /addons dir, but the problem looks similar in our main openobject-addons project https://translations.launchpad.net/openobject-addons/6.1/+imports?field.filter_status=NEEDS_REVIEW&field.filter_extension=all [10:25] There are also no weird elements in the path that might confuse things. [10:25] jtv: normally the naming of the po files is also standard [10:25] Yes, the names look fine. [10:25] (I'll just stick with the openerp-web one for now; it's easy to spread oneself too thin with so complex a piece of software.) [10:26] jtv: sure [10:26] Now let me see if there's really just one template in that directory. Maybe there's too and the queue gardener can't choose. [10:26] ok [10:28] Nope; no competing templates. [10:28] There's one matching template, and it's active. [10:28] alright [10:32] odony: sorry, X crash. The disadvantage of alpha-testing operating systems. [10:32] odony: np ;-) [10:32] err s/odony/jtv d'oh [10:32] Talking to yourself? :) Now, I haven't seen any reason why these uploads would not be approved. So I'll have to dig a little deeper. I'm going to dive into the log files. [10:34] jtv: thanks a lot for taking the time to look.. I'm willing to try and automate the approval of the imports using lplib if that works, but I'd love to understand the inner working of the import system better as well [10:34] Sensible; this should be automatic. [10:35] Nothing remarkable in the logs either. :( [10:35] hmm [10:36] That's an older log file though; I'm getting an update. [10:38] meanwhile the importing of our main templates is almost half done [10:38] this beast is huge apparently ;-) [10:41] odony: I suppose! It also depends on what else is going on the queue. You can see the global import queue at https://translations.launchpad.net/+imports [10:42] There's a backlog of 502 approved entries, which need importing. That can happen with large batches of uploads. [10:43] jtv: interesting :) [10:43] There's a massive backlog of "needs review" entries though. [10:44] The queue gardener loops over all of those, oldest to newest, so it could simply be that it's slow at the moment. [10:44] jtv: funny thing that the oldest ones in Needs Review seem to be one of ours [10:45] Yes — never approved because they had unwanted country/region codes in their filenames. [10:45] Deleting a bunch of those might speed things up for everyone. :) [10:45] jtv: yes, I should definitely be doing that [10:48] jtv: the CC code in the PO name isn't bad, is it? if we have local variations of some languages that's the correct name, isn't it? e.g. es.PO for Spanish and es_CR.po for Costa Rican Spanish [10:50] It's not “bad” in the sense of technically incorrect, but it is “bad” in the sense of inconvenient. Since you _generally_ won't want such regional variations (because it fragments your translation effort, and because it overlaps with the region-less language codes) those variations are considered inactive. [10:50] So translations won't be approved for them by default. [10:51] jtv: I see... the thing is, our community insists that these languages need specific variations, and they make merge proposals with these variations [10:51] You *can* approve them manually if you're sure that's what you want, and once you've done that, a later upload with the exact same path will be approved automatically. [10:51] But that does mean that you need to approve them. [10:51] Custom language codes _may_ help you get around this. [10:52] It's a bit embarrassing because I wrote them myself; I don't remember whether they do. [10:52] jtv: :D [10:52] It may be possible to create a custom language to map, say, es_CR to Costa-Rican Spanish (which, yes, is just a duplicate of the normal mapping) and the queue gardener may then understand that you do want that language. [10:53] Although generally what we've seen is that even the Spanish translators manage to keep their language unified. [10:53] jtv: good to know, might try that, but indeed we should try to avoid it [10:54] jtv: Actually we have a special way to handle translations: when a user decides to use the Costa Rican translations for instance, we will still load all missing ones from the es.po, which is a kind of "translation inheritance" [10:54] jtv: I don't suppose there is any such notion in Launchpad [10:54] Not dynamically; not in the same way we share translations between series. [10:54] We do, however, have the “Using as a guide” option in the UI. [10:55] So if you translate to es_CR, you can pick Spanish there and you'll get the Spanish translations as automatic suggestions. [10:55] In most cases I suspect the translator can just click on the right one. [10:55] jtv: indeed, but as it doesn't actually share them, translators would still need to do them one by one [10:56] What we've found sometimes with large communities is that you get people treating these more subtle distinctions between languages as a license to re-word everything. [10:56] jtv: given that we have 14k+ terms to translate, they usually prefer to duplicate the es.po files in a merge proposal, and then work from there [10:57] license to re-word everything indeed... that might be the case for us too... though I think there are cases where they do really need to change a few words.. [10:57] I suppose it makes sense; theoretically you could also leave most strings untranslated and have the user's system fall back to the "mother language" at runtime, but then we don't have any way of tracking which ones have been reviewed. [10:57] specific legal and accounting terms for example.... [10:57] Yes, you guys are just about the only project I've seen that really needs that, and handles it well. [10:57] jtv: yes that's what we do too, but then the statistics and reviews are all wrong on LP ;) [10:58] Your situation is a bit unusual in that it's relatively rare for open-source projects to interact quite so much with real-world things that depend on countries. [10:59] Laws and taxes, for instance. [10:59] jtv: true... we're certainly quite specific in that fashion [11:00] For other projects, I would say those differences are basically cosmetic (with the exceptions of pt_BR/pt and the two main versions of written Chinese). [11:00] jtv: I would imagine so, indeed [11:01] You've got a bunch of localization projects that really are for countries. Which is good and proper, but sometimes a bit confusing because so many other people register their own projects just to translate somebody else's project to a new language! [11:01] but for us, even Belgium French has a few noticeable differences from France French in accounting terminology, making some features unsuited for the other country without the proper translation care [11:01] yes, it can be quite confusing [11:02] Yes, I've seen the uploads (and spent many hours approving them :) [11:02] :-/ [11:02] Don't worry about it. We want your project to run smoothly, although we're limited in what we can do in terms of engineering because it's such an isolated use-case. I'd definitely give the custom language codes a try. [11:03] do you know if launchpadlib would let me manage the translation imports programmatically? [11:03] I've seen something about import queue items in the API ref, but not sure I can alter anything from there [11:03] I believe the Ubuntu folks have been doing something like that. Let me have a look at the code. [11:03] jtv: thanks! [11:05] odony: ah, I'm being silly. The UI has an ajax-y little pop-up status selector on the import queue entries. [11:05] You get those too, right? [11:05] Those use the very same API, from your account. So yes, you can do that. :) [11:06] jtv: yes I see them for our own import items [11:07] jtv: so it means that's automatically exposed via launchpadlib? great! [11:07] Yes. But you still shouldn't _need_ to, so it'd be nice if we could figure out why it's not happening automatically. [11:08] jtv: sure :-) But I can at least clean up past years of old imports without having to ask anyone to click through thousands of Needs Review items [11:08] \o/ [11:09] jtv: :D [11:10] The code for this is massively convoluted; you can see it in http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/files/head:/lib/lp/translations/model/translationimportqueue.py (may need a reload) [11:10] jtv: is there anything I can do to help find out why the gardener would not automatically process our PO files? like upload some test POs or something? [11:11] No need, thanks. It would probably introduce more unknowns, making it easy to miss the real problem. [11:11] At the moment the queue gardener is taking more than an hour to run, and one run this morning failed. Still, I'd expect some progress by now. [11:12] (The failure may simply have been because it got interrupted by an upgrade.) [11:13] thanks for the link to the code! [11:15] jtv: looking at _attemptToApprove() it looks like the Needs Review status is not permanent but only the initial one? or is it permanent if the "No import target selected yet." message is displayed? [11:16] jtv: anyway, don't let me bother you with questions about the code.. sorry ;) [11:24] odony: you put your finger on one of the most essential aspects of the whole thing. Needs Review is the initial status, and it's up to the gardener to come up with something more definite later. [11:28] jtv: aah, so I can't really know if a given (recent) import is permanently stuck in Needs Review or simply waiting for some gardener love... can I? [11:29] odony: exactly! Even if we could decide it that moment, a human action could change everything. [11:29] That's why the gardener just keeps trying. [11:32] could you push a build before a little bit in the queue? just wondering :/ [11:33] Would have like to get the package build and published for 8HAM.... for a client.. but look like the system is busy :( [11:33] jtv: so cleaning up our Needs Review mess in the global queue would really help everyeone... but at the same time a single human action (or import queue patch) could automatically fix them all too... cool :) [11:34] odony: from a server's perspective, it's all one big mess, typical of us biological meatbags. But yes, the code is pretty smart in some ways even if it's convoluted in others. [11:35] jtv: sounds familiar ;) [11:35] :) [11:39] damn.. it has been push from Start in 2 hours to 3 hours. hehe [11:41] odony: I'll need to step out for a bit now, and unfortunately I don't have a lot more time to look into the non-approval mystery. One thing I do note from the logs is that because of the interruption it's _possible_ (the information is a bit sketchy) that the gardener simply hasn't gotten around to your uploads yet. [11:43] jtv: that could make sense.. and your explanation for the forced approval of all country-specific PO files reminded me that it is usually only country-specific files that I see sitting in the queue [11:43] Yeah, those are just a bit more difficult because of what we discussed. [11:44] jtv: so it could simply be that we should just wait until the normal translations are imported, and I will handle myself the country-specific ones [11:44] jtv: thank you very much for your help and kindness! [11:44] No need to keep the one waiting for the other; they are decoupled. I'd try the custom language codes. [11:44] Best of luck, I've always enjoyed watching your project in action! [11:44] jtv: thanks :) [11:45] jtv: I will be sure to try the custom codes too [11:58] odony: only back in for a few seconds, but: there's been progress! [11:58] The gardener just completed a full run. [11:58] * jtv is out again [12:52] Hi all. [12:52] How do I checkout lp:inkscape using http:// or https:// ? [13:07] Anyone? [13:08] rindolf: lp: will use HTTP by default, unless you've run bzr lp-login [13:08] rindolf: if you have no launchpad id configured, bzr branch lp:inkscape will DTRT [13:08] Otherwise you can use the direct HTTP URL: http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk [13:29] jtv: yay, our intuition was correct, and indeed now we only have 23 Needs Review left in openerp-web series 6.1, all of them are country-specific, so I'll try custom language codes to fix it now :) [13:30] odony: wasn't an intuition — I was pointing out that it was possible, and I merely had no other guesses left. :) [13:31] jtv: hehe === Ursinha` is now known as Ursinha === bigjools is now known as bigjools-afk === matsubara is now known as matsubara-lunch === warp11 is now known as warp10 === EyesIsServer is now known as Eyes|Infinite [16:44] Hello. [16:45] is there a way to receive bug mail on a different email address? [16:53] yes, click on the yellow warning icon next to 'Email' on your user page [16:54] that will take you to /~yourname/+editemails where you can add another address and pick what subscriptions go where [17:00] mgz, I can add an email, but all notifications will go there, the ones from answers and code. [17:01] the idea is just to filter the bug mail to a different address. [17:01] yeah, I don't think you can split email about bugs from email about code reviews. [17:03] webm0nk3y ^^^^ [17:04] webm0nk3y: I would go with an email filter that forwards and deletes bug mail. [17:04] elopio: what I did was set my default email as the only i wanted to get bugs and then change all my subscriptions to go to a different email [17:04] elopio: you can't really control bug email specifically [17:05] Hi launcpad team, the email I sent to everyone was sent when i clicked on a 'contact administrators of this list to request a change." I did not send it to the entire list. [17:05] s/launcpad/launchpad [17:05] czajkowski: ^^ [17:07] webm0nk3y: how did you do that first thing? [17:07] "set my default email as the only i wanted to get bugs" [17:07] elopio: I have 5 emails registed in launchpad [17:07] elopio: I change my default contact email to be the one i want bugs to go to [17:08] webm0nk3y: ah, ok. But you'll also get answers notifications and other stuff. [17:09] elopio: yep... a sad side effect [17:10] webm0nk3y: or a nice feature request :) === bigjools-afk is now known as bigjools === matsubara-lunch is now known as matsubara === czajkowski changed the topic of #launchpad to: https://launchpad.net/ | Help contac | Launchpad is an open source project: https://dev.launchpad.net/ | This channel is logged: http://irclogs.ubuntu.com/ | User Guide: https://help.launchpad.net/ | Support: https://answers.launchpad.net/launchpad | For packaging help: join #ubuntu-packaging [19:17] hi === deryck is now known as deryck[lunch] [19:18] I think something is wrong with launchpad merge proposals [19:18] anyone interested looking at my merge request to see if I'm not missing something obvious? [19:23] er, false alarm, wrong project, wrong brnach === deryck[lunch] is now known as deryck === matsubara is now known as matsubara-afk